ViewX

 Welcome to ClearSCADA help
Copyright Control Microsystems Inc 2000 - 2011.
ClearSCADA 2010 R2 build 4165, May 2011


Using Help Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011


Using Help Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Using Help Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Using Help Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Using Help Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Using Help Guide - Document Scope (About the Guide)

Document Scope

This guide explains the different forms of Help that are available with ClearSCADA. For more information, see Welcome to ClearSCADA Help.


Using Help Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for any user that wants to learn how to use the various forms of ClearSCADA Help.


Using Help Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Using Help Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Online Help

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


Using Help Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Using Help Guide - Welcome to ClearSCADA Help

Welcome to ClearSCADA Help

Welcome to the ClearSCADA Guide to Using Help. This guide is designed to explain how to use the ViewX online help features, including:

  • ToolTips—Simple descriptions of features such as a column headings on Lists or fields on configuration Forms
  • ClearSCADA Help—A suite of on-line help documentation that contains detailed information about system operation, configuration, and management
  • Context Sensitive Help—An interactive help feature that allows users to access detailed help information about a currently displayed feature, for example, information about a specific configuration Form.

The online help features are available to any user and can be accessed via the Help menu (or by positioning the cursor for ToolTips).

NOTE: If you are new to ClearSCADA, we recommend that you work through the ClearSCADA Guide to ViewX and WebX Clients to familiarize yourself with the system.


Using Help Guide - ToolTips

ToolTips

ToolTips provide basic help and are available for many features, including List items and fields on configuration Forms. Each ToolTip contains a simple description.

To display a ToolTip, place the cursor over the item for which you require Help. Do not press a mouse button. If a ToolTip exists for that item, it will appear in the form of a single-line message, displayed near the cursor.

Example:

ToolTips are available for column headings on many Lists. To display a ToolTip for a heading, place the cursor over that heading.

Place the cursor over the ‘Source Name’ heading...
...to display the ToolTip for that heading.

ToolTips are also available for fields on many configuration Forms. To display a ToolTip for a field, place the cursor over that field.

Place the cursor over the ‘Outstation’ field...
...to display the ToolTip for that field.


Using Help Guide - ClearSCADA Help

ClearSCADA Help

ClearSCADA Help provides comprehensive information about ClearSCADA system operation, configuration, and management. ClearSCADA Help is displayed in a browser window.

This section explains how to:

  • Display the ClearSCADA Help Window
  • Understand the Layout of the ClearSCADA Help Window
  • Use the Search Facility, including:
  • Advanced Searches.
  • Use Favorites to Store Frequently Used Help Pages.


Using Help Guide - Display the ClearSCADA Help Window (ClearSCADA Help)

Display the ClearSCADA Help Window

To access detailed help information, you need to display the ClearSCADA Help window as follows:

  • Press the F1 function key

Or:

  • Select the Help menu, then select the Contents option.


Using Help Guide - Layout of the ClearSCADA Help Window (ClearSCADA Help)

Layout of the ClearSCADA Help Window

ClearSCADA Help is displayed in a browser window that contains:

  • Online Help buttons
  • Contents, Search, and Favorites tabs
  • Text Display Area.

Online Help buttons
Contents tab showing the Help Contents
Text display area showing Help for the chosen topic

(If the left-hand pane if it is not visible, you can display it by selecting the [image] Show button.
To close the left-hand pane, select the [image] Hide button.)

Further Information

Help Buttons

Help Contents

Help Search

Help Favorites

Text Display Area.


Using Help Guide - Help Buttons (ClearSCADA Help)

Help Buttons

The Help buttons are shown at the top of the ClearSCADA Help browser window:

The buttons are (from left to right):

  • Hide/Show—Toggles the left-hand pane (that shows the Contents, Search, and Favorites tabs) on and off. The Show button is only available when the left-hand pane is not shown. Similarly, the Hide button is only available when the left-hand pane is shown.
  • Locate—Indicates the location of the currently displayed help page in the contents. For example, if you are currently viewing the ‘Welcome to the Guide to Logic’ help page and you select the Locate button, the ‘Welcome to the Guide to Logic’ branch in the contents tab will be highlighted.
  • Back—Reloads the previous page you were viewing. ClearSCADA Help remembers the order in which you view the pages. So, if you have viewed several different Help pages, you can use the Back button to display the previous Help page in your viewing sequence. For example, if you were looking at the ‘Display a List’ page and then displayed the ‘Sort a List’ page, selecting the Back button would reload the ‘Display a List’ page (the previous page that you viewed).
  • Forward—Reloads the next display in your viewing sequence. This button works in a similar way to the Back button, except that instead of showing the previous Help page in your viewing sequence, it shows the next Help page. The Forward button is only available after you have used the Back button.
  • Stop—The Stop button is not used by ViewX as the Help files are stored on disk and do not need to be loaded from a web server.
  • Refresh—Reloads the Help file in the Text Display Area. This feature is not used by ViewX as the Help files are stored on disk and do not need to be loaded from a web server.
  • Home—Displays the ClearSCADA Help home page.
  • Print—Allows you to print a selected topic or the selected heading and its subtopics (the sections within the selected heading). When you select the Print button, you are prompted to choose a selected topic or a heading and all subtopics. After making your selection, the standard Windows Print window is displayed allowing you to select the required printer, define page settings, start printing, and so on.
  • Options—Provides access to menu options that provide the same functionality as the Help Buttons, for example, the Hide Tabs option works in the same way as the Hide/Show button, the Locate option works in the same way as the Locate button and so on. There is also a Search Highlight On/Search Highlight Off option that toggles the highlighting of searched terms on and off. If you turn the Search Highlight feature off, any terms that you search for will not be highlighted in the Help files that are shown in the Text Display Area.


Using Help Guide - Help Contents (ClearSCADA Help)

Help Contents

The contents of ClearSCADA Help are shown in the Contents tab that is displayed in the left-pane by default. The Contents tab contains a hierarchical list of the available reference information.

If the left-hand pane is not displayed, you can display it by selecting the Show button. If the left-hand pane is displayed, but the contents are not shown, select the Contents tab to display them.

Contents are shown in the Contents tab in the left-hand pane.
The information in the selected help topic is shown in the Text Display Area.

Each category of information is represented by a book icon. To access the various guide books and the topics within them, use the + and - icons to expand and collapse the contents hierarchy as required. When you have located the information you require, select the topic in the Contents list to display the relevant help information in the Text Display Area.

If a book icon has a red asterisk on its corner, it means that this area of the documentation contains new information (we frequently update the documentation to provide information on new features). When you expand a book that has a red asterisk, you will see the contents of that book, which may include other books. Again, those books that contain updated information are represented by a book icon that has a red asterisk in its corner.

Red asterisks indicate that the books contain information that has been updated since the previous version of ClearSCADA Help was released.

The help information is organized into the following categories:

  • ViewX and WebX Clients—This guide provides an overview of the components that make up a ClearSCADA system, along with information on operating your system using the ViewX and WebX interfaces.
  • Core Reference—These are reference guides that provide information on configuring core (non-driver-specific) features and settings using Forms, Mimics, Trends and Logic programs.

This section also includes the following guides:

  • Server Administration—Information on setting up and diagnosing the ClearSCADA system, using the ClearSCADA Server Configuration tool.
  • Security—Information on setting up system security and user accounts, allocating permissions and using Exclusive Control.
  • Database—High-level information about the structure of the ClearSCADA database.

For high-level information on system setup, security, and the structure of the ClearSCADA database, refer to the Server Administration, Security, and Database Guides respectively.

  • Driver Reference—These are reference guides that provide information on driver-specific features and configuration settings, including actions and status attributes.

When configuring an item on a driver, refer initially to the driver-specific guide for information. For instance, when configuring an item on the Modbus driver, refer to the Modbus Driver Guide for help. The driver-specific guides reference other guides where information is not specific to an individual driver.

NOTE: The Help contains several Troubleshooting and System Analysis sections to aid with diagnosing any problems that ClearSCADA has detected. To locate such sections in the Help, search for the word Troubleshooting (see Use the Search Facility).


Using Help Guide - Help Search (ClearSCADA Help)

Help Search

You can use the Search tab to search for a specific string of characters in ClearSCADA Help. This is useful when you need information on a specific aspect of your system and are not certain where the information is located in ClearSCADA Help. By searching for a particular string, you can find each occurrence of that string and then select the Help files that are relevant to your needs.

The Search tab can be displayed in the left-hand pane. To display the Search tab, simply select it in the left-hand pane. If the left-hand pane is not displayed, you can display it by selecting the Show button.

The Search Facility is shown in the Search tab in the left-hand pane.

For more information, see Use the Search Facility.


Using Help Guide - Help Favorites (ClearSCADA Help)

Help Favorites

You can use the Favorites tab to create a list of your ‘favorite’ Help files. You can then access these files quickly from the list instead of using the contents or search facility. The ClearSCADA Help Favorites feature is useful when you need to refer back to the same help page many times—you can access it more quickly by adding it to your Help favorites.

The Favorites tab can be displayed in the left-hand pane. To display the Favorites tab, simply select it in the left-hand pane. If the left-hand pane is not displayed, you can display it by selecting the Show button.

Your Help Favorites are shown in the Favorites tab in the left-hand pane.

For more information, see Use Favorites to Store Frequently Used Help Pages.


Using Help Guide - Text Display Area (ClearSCADA Help)

Text Display Area

The Text Display Area is used to present the help information. It is displayed in the right-hand pane of the ClearSCADA Help window.

When you select a Help topic from the contents or favorites, or you select a Help topic from the search results, the relevant Help file is displayed in the Text Display Area.

The selected Help information is displayed in the Text Display Area.

Many help files contain hyperlinks—text that links to other help files. Hyperlinks are designed to allow you to locate related information easily and quickly. You can easily recognize hyperlinks in ClearSCADA Help as they are underlined and displayed in a different color to the ‘normal’ text.

Hyperlink
‘Normal’ text

If you are reading a Help file and there is a hyperlink to additional, related information, you can access that information by selecting the hyperlink. When you use a hyperlink, the Help file that is displayed is added to your viewing sequence so that you can use the Back and Forward buttons to return to the Help file you were originally viewing as required.


Using Help Guide - Use the Search Facility (ClearSCADA Help)

Use the Search Facility

You can search for all occurrences of a word or term within ClearSCADA Help.

For instance, the Help includes several Troubleshooting and System Analysis sections to aid with any problem that ClearSCADA has detected. To locate such sections in the Help, search for the word Troubleshooting.

Search string
Topic selected from list of search results
Help for the chosen topic, with the occurrences of the search string highlighted

To search for a particular word or term in ClearSCADA Help:

  1. Select the Search tab in the left-hand pane.
  2. Enter the required word or text string in the search field.

To search for all occurrences of a particular string, enter the string within double quotes, for example “performance monitor”.

You can also perform Advanced Searches.

  3. Either:
  • Press the Enter key on the keyboard

or:

  • Select the List Topics button.

The topics that match the search criteria are displayed in the results list below.

  4. In the search results, either double-click on the required topic or select it and then select the Display button to display the help information in the Text Display Area.
    The associated Help is displayed in the Text Display Area, with the occurrences of the search string highlighted.

(If the occurrences of the search string are not highlighted, the search highlight feature is disabled. You can enable it again by selecting the Options Help button then selecting the Search Highlight On option.)


Using Help Guide - Advanced Searches (ClearSCADA Help)

Advanced Searches

In addition to specifying a word or string, you can:

  • Use Wildcards
  • Use Previous Search Strings
  • Use Logic to Refine a Search.

Use Wildcards

You can specify a partial word that includes one or more ‘wildcards’. A wildcard is a character that represents one or more ‘missing’ characters in a word. ClearSCADA Help supports the following wildcard characters:

  • Use a question mark (?) to represent a single unknown character.

Example:

The search word map? returns Help pages that include the following word:

maps

  • Use an asterisk (*) to represent an unknown number of missing characters.

Example:

The search word map* might return Help pages that include any of the following words:

map
maps
mapped
mapping

The occurrences of the words that you search for are highlighted in the Help pages (as long as the Search Highlight feature is enabled - see Help Buttons).

Use Previous Search Strings

To display a list of previous search strings:

  1. Select the combo button to the right of the search string field.
  2. Select an entry from the list.
  3. Display the results of the search string as you would for any search string (see Use the Search Facility).
    You can use the combo button...
    ... to display a list of previous search strings

Use Logic to Refine a Search

To use logic to refine a search:

  1. Enter the first word or string in the search field.
  2. Select the right-hand arrow button to the right of the field.
    A pop-up list of logic operators is displayed.
  3. Choose the required entry from the list of Logic Operators.
  4. Enter a further word or string.
  5. Repeat steps 2 to 4 as required.
  6. Display the results of the search string as you would for any search string (see Use the Search Facility).
    You can use the right-arrow button...
    ... to display a pop-up list of options

Logic Operators

The Logic operators that you can choose from are:

  • AND—Only searches for Help files that contain both the first and the second part of the search string.

Example:

A search string is specified as:
“current data” AND “logged data”

This results in searches being made for files that contain both the string “current data” and “logged data”. Files that only contain one of these strings are ignored.

  • OR—Only searches for Help files that contain either the first or the second part of the search string.

Example:

A search string is specified as:
“current data” OR “logged data”

This results in searches being made for files that contain either the string “current data” or the string “logged data”. Files that contain both of these strings are ignored.

  • NEAR—Only searches for Help files that contain the first part of the search string in close proximity to the second part of the search string.

Example:

A search string is specified as:
“current data” NEAR “logged data”

This results in searches being made for files that contain the string “current data” when it is in close proximity to the string “logged data”.

  • NOT—Only searches for Help files that contain the first part of the search string, but ignores any files that also contain the second part of the search string.

Example:

A search string is specified as:
“current data” NOT “logged data”

This results in searches being made for files that contain the string “current data”. Files that also contain the string “logged data” are ignored.


Using Help Guide - Use Favorites to Store Frequently Used Help Pages (ClearSCADA Help)

Use Favorites to Store Frequently Used Help Pages

You can use the Favorites tab to store the Help pages that you frequently access. The Favorites feature is a useful means of rapidly accessing Help pages that are several layers down within the Help tree structure.

To add a Help page to Favorites:

  1. Display the Help page that you require, either by selecting the page from the Contents tab or by using the Search facility.
  2. Select the Favorites tab in the left-hand pane.
    The title of the Help page is displayed in the Current Topic field at the bottom of the tab.
  3. Select the Add button to add the page to the Favorites list.
    The page title is added to the Topics list.
    ... to display the title of the page in the Current Topic field...
    To add a page to the Favorites tab, display the page that you want to store as a ‘Favorite’ page and then select the Favorites tab...
    The Topics field displays a list of presently stored ‘Favorite’ Help pages
    ... then select the Add button to add the page to the Topics list

To rename an entry within the Topics list:

  1. Right-click on the entry.
    A context sensitive menu is displayed.
  2. Select the Rename option.
    The entry is highlighted ready for you to change the name.
  3. Alter the name as required.
  4. Select elsewhere on the Help display to confirm the name change.

To display a Help page that is listed in the Topics list, either:

  • Double-click on the entry

or:

  1. Select an entry.
  2. Select the Display button.


Using Help Guide - Context Sensitive Help

Context Sensitive Help

ViewX provides a context sensitive help feature that allows you to display help information about the display that you are currently using. When you use context sensitive help there is no need to navigate the ClearSCADA Help contents or perform a Search—ViewX finds the relevant information for you automatically and displays it in the ClearSCADA Help browser window.

Context sensitive help is available for many ClearSCADA displays.

To access context sensitive help:

  1. In View, select the part of the display for which you need information.
  2. Press the F1 function key.
    The relevant ClearSCADA Help file is displayed automatically.

For help information relating to the configuration of digital point states on the Digital Point configuration Form, select the States section then press F1...
...help information about configuring digital point states is displayed. The ClearSCADA Help window is automatically set to display the digital point configuration information; you do not need to navigate through the help contents or conduct a search.

Context sensitive help is displayed in the ClearSCADA Help window. When you have used context sensitive help to access help information, you can use the ClearSCADA Help window to locate other information as required (see ClearSCADA Help).


ClearSCADA Tutorial - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


ClearSCADA Tutorial - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


ClearSCADA Tutorial - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


ClearSCADA Tutorial - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


ClearSCADA Tutorial - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


ClearSCADA Tutorial - Document Scope (About the Guide)

Document Scope

This tutorial provides a brief introduction to a variety of ClearSCADA features, including the Database Bar, Mimics, Trends, and configuration Forms.

For details on the subjects covered in the tutorial, see Welcome to the ClearSCADA Tutorial.


ClearSCADA Tutorial - Intended Audience (About the Guide)

Intended Audience

This tutorial is designed for use by users who are new to ClearSCADA. By following the procedures in this tutorial, users can learn about a variety of ClearSCADA interfaces, concepts and features.

After completing the tutorial, users will be familiar with many of the key aspects of ClearSCADA. They will also have an appreciation of the many benefits a ClearSCADA system offers.


ClearSCADA Tutorial - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


ClearSCADA Tutorial - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Client Administration

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Using Help

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Mimics

ClearSCADA Guide to Trends

ClearSCADA Guide to Security

ClearSCADA Guide to Lists

ClearSCADA Guide to Server Administration.


ClearSCADA Tutorial - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


ClearSCADA Tutorial - Welcome to the ClearSCADA Tutorial

Welcome to the ClearSCADA Tutorial

Welcome to the ClearSCADA tutorial, where you will learn how to configure a variety of the many features of a ClearSCADA system, including Mimics, database points, and connections to SCADA devices.

When your ClearSCADA demo system first runs, the ViewX client interface is launched automatically. ViewX is the full client interface for the ClearSCADA system and it can be used to:

  • Access displays with information about database values, both historic and current
  • Configure database items, including points and graphical displays such as Mimics
  • Respond to alarms
  • Create reports
  • Configure the Logic programs and schedules so that define your system’s behavior.

ViewX is designed to reduce the amount of time and effort required to configure and maintain a SCADA system. To achieve this, it uses an innovative grouping system that works in a similar way to Microsoft® Windows folders.

ClearSCADA uses a grouping system, similar to that found in Microsoft Windows. This provides you with greater control over the way in which your database is structured and allows us to provide features that significantly reduce the cost and time required to configure, maintain and update your SCADA system.

The folders system offers many benefits over traditional tag table interfaces:

  • Greater control over the structure of your database, as you can organize it according to geographical location, function, or another grouping methodology of your own choosing.
  • Reduced time and cost of configuring your database, as Group Templates and Group Instances significantly reduce the amount of configuration work required, no matter how complex your system.
  • Simple to reorganize your database—just drag and drop groups and items, just like you would in Microsoft Windows Explorer.
  • Create new items and reconfigure database items while your system is online
  • Easy to manage security system, with user accounts and permissions to restrict access to system features and database items. Users without a user account use the Guest account which is read-only.

Designed to help first-time ClearSCADA users, this tutorial explains how to use some of the many features of the two main ClearSCADA user interfaces—ViewX and WebX. The tutorial is divided into separate sections, each of which contains easy to follow instructions and helpful explanations that show you how to:

  • Use the ViewX interface
  • Create and configure database items to represent inputs and outputs
  • Configure ClearSCADA to connect with communications devices (for the tutorial, the communications device used is a SCADAPack Modbus controller)
  • Configure Mimics to display 'live' dynamic data
  • Raise and respond to alarms
  • Configure Trends
  • Use Group Templates and Group Instances to reduce the amount of configuration work required
  • Use a WebX client
  • Access the comprehensive online help documentation system.

Before you begin working through the exercises in the tutorial, we recommend that you read the following sections:

  • About the Tutorial
  • Restarting your System.


ClearSCADA Tutorial - About the Tutorial (Welcome to the ClearSCADA Tutorial)

About the Tutorial

The ClearSCADA tutorial is designed to help first-time or inexperienced ClearSCADA users get used to working in ViewX and WebX (the two main ClearSCADA user interfaces). Each section of the tutorial contains easy-to-follow instructions with explanations of the effects of your actions. As you work through the tutorial, you will learn about the common configuration procedures, displays, and methods used for accessing features.

Although each section includes instructions and helpful information, the tutorial is only designed to be a guide to ClearSCADA and is not a substitute for the comprehensive online help documentation or a training course. Also, while the tutorial is aimed at first-time users, we recommend that users have a strong background in both programmable logic controllers (PLCs) and personal computers using Windows.

Throughout the tutorial, we have used the following conventions:

  • Bold text indicates the name of an option or setting that you can select
  • Italic text indicates an action that takes place as a result of your activity
  • Where multiple menu options are required, angle brackets are used. For example, View>Toolbars>File means select the View menu, then select the Toolbars option on the View menu, then select the File menu on the Toolbars menu. We also use this convention when describing the address of items, if the items are in subgroups (Groups within Groups).
  • Angle brackets <> are used to indicate a variable value or property. Unless specifically asked to do so, you should not include the angle brackets in your selections or entries.
  • For more detailed explanations of features mentioned in the tutorial, please refer to the online help sections that are listed under the Further Information headings.
  • At the end of each section, you can see how much you have learned by answering the questions in the Test Your Knowledge section. Each Test Your Knowledge section has questions that relate to the tasks you have performed.

We recommend that you complete each of the tutorial sections in order, but if you wish to skip certain sections, you can do this. However, you may need to import files relating to the sections you have skipped. Instructions on how to import the files are included at the start of the sections.

Finally, if you are working on the tutorial and your system stops running, you will need to restart your server. This is because demo ClearSCADA systems are set to stop running after 2 hours. For information on restarting the ClearSCADA server, see Restarting your System.

If you are ready to start the tutorial, proceed to Using the ViewX Interface.


ClearSCADA Tutorial - Restarting your System (Welcome to the ClearSCADA Tutorial)

Restarting your System

Demonstration systems are set to turn themselves off every 2 hours. If you are working on the tutorial and your system stops running, you will see that the system icon on the ViewX Database Bar shows a red exclamation mark:

The server icon that runs near the clock on the Windows taskbar will also change color to indicate that the ClearSCADA server has stopped running:

If you are working in WebX and ClearSCADA stops running, the WebX client will lose its connection to ClearSCADA. To continue working with your system via WebX, you will need to restart the ClearSCADA server.

To restart your server:

  1. In Windows, run the ClearSCADA Service Manager (it is available from your list of Programs via the Start menu).
    The Service Manager window is displayed.
  2. Set the Service setting to ClearSCADA Server (if it is not already set to ClearSCADA Server).
  3. Select the Start button.
    After a short pause, the ClearSCADA server will start running again and you will be able to resume your work in ViewX or WebX.

Further Information

Restart the Server: see Start and Stop the System Server in the ClearSCADA Guide to Server Administration.


ClearSCADA Tutorial - Using the ViewX Interface

Using the ViewX Interface

When you first install the demo system, ViewX runs automatically. To begin with, it displays a Mimic (graphical display), the Database Bar which contains a hierarchy of Groups, and the Alarm Banner which is shown at the bottom of the ViewX interface.

ViewX is the main ClearSCADA client interface and can provide access to a wide range of features, including:

  • A hierarchy of your database that you can browse easily
  • Mimics
  • Alarm displays
  • Trends
  • Logic programs
  • Queries Lists
  • Event Journal
  • Configuration Forms and Editors
  • OPC current and historic data
  • Security settings.

As you progress through the tutorial, you will learn about many of the ClearSCADA ViewX client features and will come to use the configuration and editing displays. But to begin with, we would like you to complete the following steps so that you have a better understanding of the ViewX interface:

  1. Disable the Alarm Bell
  2. Import the Example Projects
  3. Log on to your System
  4. Menus
  5. Toolbars
  6. Explorer Bars
  7. Document Display Area
  8. Alarm Banner

When you have worked with the various areas of the ViewX interface, you can Test Your Knowledge on the ViewX Interface and see just how much you have learned.


ClearSCADA Tutorial - Disable the Alarm Bell (Using the ViewX Interface)

Disable the Alarm Bell

Before we get started with logging on to your system, we want to make things a little easier by showing you how to disable the Alarm Bell. What is the Alarm Bell? Well, it is a sound that plays when ViewX detects alarm conditions on your system. By default, it makes a 'beep' sound that repeats, and if you have the 'Example Projects' already installed, you will probably be hearing the 'beep' right now. As you’d expect, the sound is designed to attract the attention of users, but if you leave it on during the tutorial, it may become annoying.

If you can hear the Alarm Bell, you can turn it off by taking the following steps:

  1. Move the cursor over the Alarm Bell Button at the bottom-left of the ViewX display.
    The Alarm Bell button is displayed at the bottom of the ViewX display, as part of the Alarm Banner. It shows two numbers, which indicate the number of unacknowledged alarms and the total number of alarms.

  2. Right-click on the Alarm Bell button to display a context sensitive menu.
  3. Select the Disable Bell option. This turns the audible alarm sound off.

Now that you have some peace and quiet, you should check to see if your system already contains the Example Projects:

  • Select the plus icon + next to the System icon to reveal the contents of the System Group. You should see Group folders named Example Projects, Presentation, Symbol Library and users as well as a single Mimic database item named Opening Page. If you cannot see these items, you will need to Import the Example Projects.

If your database already contains the Example Projects, you can skip the importing process and proceed to Log on to your System.

Further Information

Alarm Bell: see Audible Alarms in the ClearSCADA Guide to Alarms.


ClearSCADA Tutorial - Import the Example Projects (Using the ViewX Interface)

Import the Example Projects

To help you quickly get a feel for how a real ClearSCADA system works, we have included Example Projects that you will use throughout this tutorial. On many systems, you’ll find that the Example Projects are already loaded and are available to use straight away. However, if your system does not contain the Example Projects, you are going to need to import them.

To import the Example Projects:

  1. On the Database Bar on the left-hand side of the ViewX window, right-click on the System icon to display its context sensitive menu. Many types of database item have a context sensitive menu that you can use to access displays, controls, and configuration Forms and editors for the selected item.
    Context-sensitive menu for the System item.

  2. Select the Import option. This displays an Import From browse window.
  3. Browse to the following location on your ClearSCADA Demo Disk:
DemoProjects\Example Projects.sde

  4. Select the 'Example Projects.sde' file, then select the Open button on the browse window to confirm your choice.
    A dialog is displayed, informing you that the file may take a long time to import due to its size.
  5. Select the Yes button.
    The Example Projects will import into your database.

Now that you have the Example Projects available, you can proceed to Log on to your System.

Further Information

Importing Data: see Importing and Exporting Database Items in the ClearSCADA Guide to Core Configuration.


ClearSCADA Tutorial - Log on to your System (Using the ViewX Interface)

Log on to your System

When you first run ViewX, you will be logged on as a Guest user by default. The Guest user has been preconfigured to provide read-only access to the features in ClearSCADA. This makes it difficult for unauthorized users to interfere with your system, as the Guest account only allows them to view the database; they cannot use the default Guest account to issue controls or configure items.

As you need to access configuration features, you will need to log on via a user account we have already created for you:

  • Eng—Provides greater access to system features, including access to configuration settings.

On a 'real' system, you could have individual user accounts for each user, with each user account configured to provide specific access permissions.

To log on as the 'Eng' user:

  1. Select the File menu at the top left-hand side of the ViewX window. The File menu will drop down to reveal its contents.
  2. Move the cursor down the menu and select the Log On option. This will close the File menu and cause the Log On window to be displayed.
    The name of the system is shown in the title of the Log On window. In this example, the system name is MAIN but your system may be named differently.

  3. In the username field on the Log On window, enter the following:
Eng

This is the name of the user account that you will use for the majority of the tutorial. It has been preconfigured especially for the tutorial and has suitable security permissions to allow you to perform a wide variety of tasks.

  4. Leave the Password field empty (blank) as the 'Eng' user account does not have a password. On a 'live' system, user accounts can have a username and Password configured for extra security.
  5. Select the OK button to confirm that the username is correct.
    The Log On window is closed and you are logged on to your system as the 'Eng' user.

You will see that part of the ViewX interface, the Alarm Banner, disappears from its usual place at the bottom of the display. This is because users with engineer level permissions (permissions to configure the system, and so on) are often not responsible for responding to the alarms that are shown on the Alarm Banner. However, during the tutorial you will use the Alarm Banner, so you should display it again by following these steps:

  1. Select the View menu
  2. Select the Alarm Banner option on the View menu. This restores the Alarm Banner to its position at the bottom of the ViewX display.
    Alarm Banner shown at bottom of ViewX display.

Now that you have logged on as the 'Eng' user, you can begin to learn about the various parts of the ViewX interface, starting with Menus.

Further Information

Logging On and Off: see System Security in the ClearSCADA Guide to ViewX and WebX Clients.

Alarm Banner: see Alarm Banner in the ClearSCADA Guide to Alarms.

User Accounts: see Overview of User Account Security in the ClearSCADA Guide to Security.


ClearSCADA Tutorial - Menus (Using the ViewX Interface)

Menus

At the top of the ViewX window is the default ViewX menu. This menu provide access to a variety of options, including LogOn, Save, Print, Cut, Copy, and Paste. The menu also allows you to show and hide various parts of the ViewX interface, including the Alarm Banner, and provides access to the online documentation.

To access an option in a menu, simply move the cursor over the required menu name, then left-click to display the menu’s options. Position the cursor over the option you want to use, then press the left-hand mouse button to select the option. Some menu options provide access to one or more submenus.

The View menu’s Explorer Bar option is just one of many menu options that provides access to a submenu. You can make your choice from the submenu.

When you work with displays such as Mimics and Logic programs, further menus become available. These further menus contain options that are relevant to the display you are using, for example, there is an Arrange menu for Mimics that allows you to change the order and alignment of objects on a Mimic.

Further Information

Menus: see Menus in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Toolbars (Using the ViewX Interface)

Toolbars

Many of the options that are contained on the ViewX menus are also available as buttons on toolbars. For example, there is a Save button on the File toolbar which does exactly the same as the File menu’s Save option. By using the toolbars, you can access various options more quickly.

As you become more accustomed to working in ViewX, you learn what each toolbar button represents and using them will become second nature. But as you are starting off, you may need reminding about the purpose of each button. To help you out, ViewX provides a ToolTip for every toolbar button—simply position the cursor over a button, and after a short pause, the ToolTip for the button is displayed. The ToolTip provides the name of the option represented by the toolbar button and also the corresponding keyboard shortcut.

ToolTip for the Events button on the Operate toolbar.

Further Information

Toolbars: see Toolbars in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Explorer Bars (Using the ViewX Interface)

Explorer Bars

To help you navigate the items and data on your system, ViewX includes an Explorer Bar which is displayed on the far-left of the ViewX interface.

Explorer Bar showing Database Bar.

There are several types of Explorer Bar available, but you will use the Database Bar predominantly during the tutorial. The Database Bar contains a hierarchy of the items in your database and allows you to add, create, configure, remove, and organize database items. You can also use it to access status displays and perform actions on individual items.

When you first run ViewX, the Database Bar is displayed by default. At the top of the Database Bar is a system icon. The system icon represents the server to which your client is connected (there can be multiple system icons). If you look closely at the Toolbars just under the menu at the top of the display, you’ll see that the Database Bar button appears to be pressed down. This indicates that the Explorer Bar is currently showing the Database Bar.

Database Bar button is ‘pressed down’ to indicate that the Explorer Bar is displaying the Database Bar.

To help you understand how the Database Bar works, we are going to quickly show you how to navigate through a hierarchy of Groups.

  1. Click on the plus + icon next to the System icon at the top of the Database Bar. This expands the top level 'branch' of the 'tree-structure' to reveal the items on the system.

You will see that your system contains four Groups and a Mimic. The Groups are represented by yellow folder icons, each with plus + icons which indicate that the Groups contain further items. The 'Opening Pages' Mimic is represented by a picture icon.

The Groups and the Mimic have been preconfigured and were either imported into your system at the start of this tutorial or were included in the installation.

  2. Click on the plus + icon next to the 'Example Projects' Group. This expands the 'Example Projects' Group to reveal its contents—further Groups and Mimics.
  3. Click the minus - icon next to the 'Example Projects' Group to collapse its 'branch' and hide its contents.
  4. Take a moment to browse through the various folders in your system. You will see that they contain a variety of items, including Mimics, database points, and custom colors. You will also see a dark red folder icon and green folder icons—these are special types of Groups called Group Templates and Instances. They can be used to significantly reduce the amount of configuration required on your system. We will look at these in more detail later in the tutorial.

Now that you’ve learned how to use the plus and minus icons on the Database Bar, you’ll understand how to navigate the other types of Explorer Bar, as they also use the expand and collapse concept.

Further Information

Explorer Bars: see Explorer Bars in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Document Display Area (Using the ViewX Interface)

Document Display Area

The ViewX Document Display area is the main part of the ViewX display and is shown to the right of the Explorer Bar. You will use the Document Display Area to interact with the various displays in ViewX, including Mimics (graphical displays), Logic programs, Trends, Lists, and configuration Forms. These displays are often referred to as ViewX 'documents'.

A Mimic displayed at maximum size in the Document Display Area.

Whenever you choose to display a ViewX 'document', the 'document' is shown in the Document Display Area. To illustrate how this works, we are going to show you how to display the configuration Forms for some of the internal database points that already exist in your database (internal database points are used to represent inputs and outputs that are only used internally; they do not represent 'real' external I/O):

  1. Display the Database Bar on the Explorer Bar. If it is not already displayed, select the Database Bar button on the Operate Toolbar or select View>Toolbars>Operate from the menu.
  2. Browse to the 'Computers 2000W' internal digital point. It is stored in the following location:

Example Projects>Electricity>Generation>Factory

  3. Right-click on the internal digital point to display its context sensitive menu. Each database item has its own context sensitive menu which provides access to a variety of display, configuration, and control options (relating to that specific item).
  4. Choose the Properties option. The Properties option provides access to the configuration Form for the point. Most types of database item have a Properties option that you can use to access their individual configuration Forms.

The configuration Form for the internal digital point is displayed in the Document Display Area.

  5. On the Database Bar, browse to the 'Lights 1000W' internal digital point. It is stored in the same Group as the 'Computers 2000W' digital point.
  6. Double-click on the 'Lights 1000W' internal digital point to display its configuration Form. You will see that the 'Lights 1000W' Digital Point Form is displayed in front of the 'Computers 2000W' Digital Point Form in the Document Display Area. As the 'Lights 1000W' Digital Point Form is the most recently displayed Form, it is active, but you can make the 'Computers 2000W' Form the active Form by selecting it.

NOTE: You can restrict access to configuration displays such as Forms if required. You can also disable the double-click functionality that allows users to display or edit a document feature. For more information, see User Account Permissions in the ClearSCADA Guide to Security.

  7. Use the Windows buttons at the top left of the configuration Forms to alter the way they are displayed in the Document Display Area:
    Close document
    Close document
    Maximize document
    Minimize document
    Minimize document
    Return document to original size

Now that you understand the purpose of the Document Display Area, it’s time to look at the Alarm Banner.

Further Information

Document Display Area: see Document Display Area in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Alarm Banner (Using the ViewX Interface)

Alarm Banner

When ClearSCADA detects a problem on your system, it raises an alarm which is shown in the Alarm Banner (and is also included on Alarms Lists). The Alarm Banner provides information about currently active alarms on your system and also provides access to the various alarm response features. It is shown at the bottom of the ViewX display by default (but can be hidden from view if required).

When you imported the Example Projects (see Import the Example Projects), some of the imported items caused a number of alarms to be raised. If you look at the Alarm Banner, you will see information about each of these alarms, including:

  • Severity—The importance of the alarm.
  • Time—The time at which the alarm was raised ('triggered')
  • Source—The full address of the database item for which the alarm has been raised. The database item is the source of the alarm.
  • Message—A brief description of the condition that caused the alarm to be raised.
  • Category—Indicates the type of alarm, for example, the points that are in alarm on your system have a Category of Point State (as the points’ values have caused the points to change state, which has triggered alarms).

Alarms in ClearSCADA are color coded, and so the alarms are displayed in different colors. The default color scheme is Red (flashing) for unacknowledged, uncleared alarms, Green (flashing) for unacknowledged cleared alarms, and Brown for acknowledged uncleared alarms.

If you right-click on an alarm in the Alarm Banner, a context sensitive menu for the alarm is displayed. The menu contains options that you can use to respond to alarms, including Acknowledge, Response, and Remove.

On a 'live' system, operators will use these alarm response options to inform other system users that they are aware of an alarm condition and are trying to resolve the situation.

To show you how easy responding to alarms is, we want you to Acknowledge the alarm for the Total Energy Usage point:

  1. In the Alarm Banner, use the Source column or the Message column to identify which alarm relates to the Total Energy Usage point.
  2. Right-click on the alarm, then select the Acknowledge option from the context sensitive menu. This informs ClearSCADA and other users that you have seen the alarm.

As the alarm is an Unacknowledged Cleared alarm, as soon as you select the Acknowledge option, the alarm will be removed from the Alarm Banner. This is because the cause of the alarm is no longer in effect and so the alarm has already been cleared. The alarm only remained on the system because no user had acknowledged the alarm. ClearSCADA only removes an alarm when the cause of the alarm has been resolved and a system user has confirmed that they have seen the alarm (this means alarms are not raised and cleared automatically, which could result in users being unaware of intermittent alarm conditions).

The Alarm Banner is just one of several displays that you can use to access alarm response features. It is also possible to access these features on Alarms Lists, specially configured Mimics, and even on the context sensitive menus for individual items.

Now that you have familiarized yourself with the general layout of the ViewX interface, you can choose to Test Your Knowledge on the ViewX Interface, or you can proceed to the next section of the tutorial: Configuration Basics.

Further Information

Alarm Banner and alarm response actions: see the ClearSCADA Guide to Alarms.


ClearSCADA Tutorial - Test Your Knowledge on the ViewX Interface (Using the ViewX Interface)

Test Your Knowledge on the ViewX Interface

Do you know your way around the ViewX interface? Can you display Explorer Bars, browse to database items and navigate between ViewX windows with ease? Then put your ViewX skills to the test and see how much you have learned:

  1. What is the main display area in ViewX called?
  2. How do you expand a Group so that you can see its contents?
  3. Group folders are represented by yellow folder icons, but what do the red and green folder icons represent?
  4. If you needed to display the configuration Form of a database point, which Explorer Bar would you use to locate the point, and then display its Form?
  5. You are viewing a Mimic in the Document Display Area and then choose to display a configuration Form. When it is displayed, the Form fills the available space so that you can’t see the Mimic any more. How can you switch ViewX’s focus from the Form back to the Mimic?
  6. If you wanted to know which database item is associated with an alarm, which two columns of information would you look at on the Alarm Banner?
  7. How do you inform ClearSCADA (and other users) that you have seen an alarm and are in the process of investigating its cause?
  8. There’s a ToolBar button that you don’t recognize. How can you find out which option it represents?


ClearSCADA Tutorial - Configuration Basics

Configuration Basics

With ClearSCADA, you can configure database items and displays while the system is online, meaning that you can create new items without affecting the running of your system. Many configuration tasks are undertaken in ViewX via a variety of user-friendly configuration displays, including configuration Forms and editors such as the Mimic editor.

So that you get a feel for how the configuration displays look and work, we are going to guide you through some basic configuration tasks. When you have completed these tasks, you will be ready to start working with 'live' I/O (inputs and outputs).

To familiarize yourself with the configuration process in ViewX, you should:

  1. Create a New Group
  2. Rename the 'Default' Mimic in your Group
  3. Add an Internal Analog Point
  4. Use Drag and Drop to Display the Point Data on a Mimic
  5. Put the Mimic into Run Mode
  6. Hand Control the Internal Analog Point
  7. Display a Historic Trend for the Internal Analog Point
  8. Change the Point Configuration to Trigger an Alarm
  9. View an Alarm
  10. Action an Alarm.

When you have completed the tasks in this section, you can Test Your Knowledge on Configuration Basics.


ClearSCADA Tutorial - Create a New Group (Configuration Basics)

Create a New Group

Group folders are used to organize your database so that it is easier for you (and other users) to find whatever items you need. There are three types of Group: 'normal' Group folders, Group Templates, and Group Instances. For the moment, we will focus on 'normal' Groups which are folders that can contain any type of database item, including other Groups. They work in a similar way to folders in Microsoft Windows.

NOTE: To perform the tasks in this step, you have to be logged on as the 'Eng' user (see Log on to your System).

To create a Group:

  1. Right-click on the System icon at the top of the Database Bar.
    A context sensitive menu is displayed.
  2. Select New>Group>Group.
    A new Group database item is added to the hierarchy shown in the Database Bar. It is selected automatically, ready for you to define its name.
  3. Enter the following as the name for the Group:
MyFirstTest

Now that you have created the 'MyFirstTest' Group, you can proceed to Rename the 'Default' Mimic in your Group.

Further Information

Groups: see Groups in the ClearSCADA Guide to Core Configuration.


ClearSCADA Tutorial - Rename the 'Default' Mimic in your Group (Configuration Basics)

Rename the 'Default' Mimic in your Group

When you create a Group, the Group automatically contains a Mimic which is named 'Default'. This is because many systems designers like to have an overview Mimic in each Group—the Mimic acts as a graphical representation of the items stored in that Group. However, you can leave the 'Default' Mimics blank or delete them from your database if you have no need for them.

As you are going to add some dynamic data to the Mimic, it makes sense to rename it to something more appropriate (dynamic data is data that changes according to the values in your database).

To rename your Mimic:

  1. Browse to the 'Default' Mimic in the 'MyFirstTest' Group.
  2. Right-click on the 'Default' Mimic to display its context sensitive menu, then select the Rename option.
    The name of the 'Default' Mimic is selected, ready for you to make your changes.
  3. Enter the following as the new name for the Mimic:
MyTestPlant

  4. Press the Enter key or select any part of the ViewX interface to confirm your entry.

Now that you’ve renamed the 'Default' Mimic to 'MyTestPlant', you can proceed to Add an Internal Analog Point.


ClearSCADA Tutorial - Add an Internal Analog Point (Configuration Basics)

Add an Internal Analog Point

In ClearSCADA, there are two different categories of database point: internal database points and 'normal' database points. Of course, within these categories there are many different types of point, for example, 'normal' database points include analog and digital points for each different driver.

  • 'Normal' database points are used to represent real I/O. For example, database points can represent inputs from and outputs to plant such as sensors, valves, and so on.
  • Internal database points are different as they are not used to represent actual I/O from an external source. Instead, they are used to represent and store values that are only used internally within ClearSCADA.

As you are only just starting out with point configuration, we are going to show you how to:

  • Create an internal analog point.
  • Configure the internal analog point so that it has the Historic feature enabled. This means that ClearSCADA will keep a record of the internal point’s values.

When you have created the internal analog point, you will learn how to display its value on a Mimic, control its value, and view its values on a Trend. This will help you to understand how items are configured and information can be displayed in ClearSCADA.

To add an internal analog point and enable its Historic feature:

  1. Right-click on the 'MyFirstTest' Group and select New>Internal>Analog Point. This will create a new internal analog point in the 'MyFirstTest' Group. The internal analog point is selected automatically, ready for you to define its name.
  2. Name the internal analog point:
InternalWaterLevel

For this exercise, we are going to use the internal analog point to represent the I/O for an imaginary water level sensor (as used in the water industry). On a 'live' system, a 'normal' analog point would be used and it would represent the I/O from a real water level sensor in place in, for example, a reservoir, or tank.

  3. Display the configuration Form for the 'InternalWaterLevel' point by either double-clicking on the point on the Database Bar or by right-clicking on the point and then selecting Properties from its context sensitive menu.

The configuration Form consists of several tabs, each containing a variety of settings. The tabs are shown across the top of the Form, and if you select one, different settings are shown. These tabs are common to many points, but other types of database item have different tabs, for example, a Logic program’s configuration Form only has Identification, User Methods and Logic tabs.

Before you proceed with the next step, take a moment to select the different tabs and look at the settings that are available.

  4. Select the Historic tab. This tab contains the settings that relate to the internal point’s historic data (the record of past values).
  5. Select the Enabled check box to turn on the historic feature for the internal point. As soon as you save the Form, the values for the internal point will be stored online (for a specific time period). If a point does not have Historic enabled, it means that you can only access its current value and state.
  6. In the Trend/List section, select the browse button next to the Offset field. This displays an Offset dialog.
  7. Use the Offset dialog to define the start time of the Interval that will be shown on Historic Trends and Historic Lists for the point. The Interval is the time span that is visible on the X-Axis.
  1. Change the From the Start of the Current setting from Hour to Minute. This instructs ClearSCADA to calculate the Offset from the beginning of the current minute, rather than the beginning of the current hour.
  2. Clear the check box next to the default setting of Subtract 23 Hours. This removes the existing Offset which is in hours.
  3. Select the check box for the Minutes row, and change Add to Subtract and the 0 to 5. This means that when you display an ad hoc Historic Trend for the point, the Interval will start 5 minutes before the start of the current minute. So if you displayed the Historic Trace at 10:30:00, the Historic Trace’s Interval would begin at 10:25:00.
  4. Select the OK button to confirm your choices and close the Offset dialog.
  8. Select the browse button next to the Interval field. This displays an Interval dialog.
  9. Use the Interval dialog to define the length of time that is visible on the X-Axis by default. For this tutorial, disable the default setting of Add 1 Days and define a setting of Add 10 Minutes. This means that when you display an ad hoc Historic Trend for the point, the X-Axis will represent 10 minutes, with the first time shown on the X-Axis being 5 minutes before the start of the current minute (as defined by the Offset).
  10. Select the OK button to confirm your choices and close the Interval dialog.
  11. Save the configuration changes by selecting Save from the File menu, Save on the File toolbar, or by pressing the Ctrl and S keys simultaneously.
  12. Close the internal analog point’s Form.

You’ve now created an internal analog point, configured it to have historic data and defined the settings for the point’s Historic Trend and Historic List. Next, you will Use Drag and Drop to Display the Point Data on a Mimic.

Further Information

Internal Points: see Internal Points in the ClearSCADA Guide to Core Point Configuration.


ClearSCADA Tutorial - Use Drag and Drop to Display the Point Data on a Mimic (Configuration Basics)

Use Drag and Drop to Display the Point Data on a Mimic

Mimics are displays that allow you to present system information in a graphical format. For example, you can create Mimics that contain a visual representation of the plant with dynamic, animated displays showing values from the database. You can configure a Mimic to represent virtually anything, and can easily add dynamic values to it by using ClearSCADA’s drag and drop feature (there are other ways of adding dynamic values and attributes to Mimics, but for the moment we will focus on drag and drop).

As you have created an internal analog point with historic data, we are going to teach you how to use the drag and drop feature to display the point’s value graphically and as a number on a Mimic:

  1. In the Database Bar, double-click on the 'MyTestPlant' Mimic to open the Mimic in Design Mode. Alternatively, you can right-click on the Mimic and select Edit from its context sensitive menu.

When a Mimic is in Design mode, you can add items to it, configure animations, write scripts, and so on. However, you may not be able to see operational features such as the values of animated items. To view operational elements, you will need to switch the Mimic to Run mode—we will explain how to do this later in the tutorial.

  2. With the 'MyTestPlant' Mimic still on display, browse to the 'InternalWaterLevel' point in the Database Bar.
  3. Left-click on the 'InternalWaterLevel' point and keep the left-hand mouse button pressed down.
  4. Keeping the left-hand mouse button pressed down, move the cursor from the Database Bar onto the 'MyTestPlant' Mimic.
  5. Release the mouse button to display a context sensitive menu.
  6. Select Value>Formatted Value from the menu.
    An animated text box is added to the Mimic. It will appear as an empty white box, but it is actually animated to show the formatted value of the point.
  7. Repeat steps 3 to 6 inclusive, only this time select Value>Vertical Bar>Up from the context sensitive menu. This will add an animated bar to the Mimic. The value of the internal analog point will affect the size of the bar.

You’ve now added an animated text box and an animated size bar to your Mimic. The appearance of both animated objects will change according to the value of the internal analog point, but you won’t be able to see the changes until you switch the Mimic to Run mode. So let’s do that next—proceed to Put the Mimic into Run Mode.

Further Information

Animations: see Animations in the ClearSCADA Guide to Mimics.


ClearSCADA Tutorial - Put the Mimic into Run Mode (Configuration Basics)

Put the Mimic into Run Mode

To configure a Mimic, you need to display it in Design mode. But to use the Mimic in the same way as an operator level user, you need to display it in Run mode. When a Mimic is in Run mode, it will display the values and animations that have been configured for it and will provide access to any display and control related context sensitive menus. However, you cannot access any configuration features of the Mimic while it is displayed in Run mode.

To display the 'MyTestPlant' Mimic in Run mode:

  • Deselect the Design Mode button on the File toolbar. You can also toggle between Design and Run modes by using the View>Design menu option.

When you have displayed the 'MyTestPlant' Mimic in Run mode, you will see that the dotted lines of the grid disappear. This is because the Grid feature is only available in Design mode (it is enabled by default and is designed to help you align Mimic objects).

When your Mimic is in Run mode, it should show the black outline of the animated size bar and the white background of the animated text box (as shown above).

With the Mimic in Run mode, you can move on to Hand Control the Internal Analog Point. The control will change the value of the point which will have a noticeable effect on the animated objects on your Mimic.

Further Information

Run Mode and Design Mode: see Displaying a Mimic in the ClearSCADA Guide to Mimics.


ClearSCADA Tutorial - Hand Control the Internal Analog Point (Configuration Basics)

Hand Control the Internal Analog Point

ClearSCADA allows you to send controls to your database points, meaning that you can change their values as required. By performing controls, you can affect the conditions on site. For example, if you have a digital point that represents a valve, you can hand control the point to open or close the valve.

For the tutorial, you are going to perform a series of controls on the internal analog point that you have created. The controls will change the value of the point so that it drops low, then rises in increments. This simulates the dropping and rising of values that could be experienced with a 'normal' database point connected to the I/O of a water level sensor.

To perform a control on the internal analog point:

  1. On the 'MyTestPlant' Mimic, move the cursor over the animated text box or the animated size bar. You will see that the cursor changes from an arrow to a pointing hand when it is over either of the objects.
  2. Press the left-hand mouse button to display a context sensitive menu for the animated object. You will see that it contains many of the same options as the context sensitive menu for the internal analog point (as it is animated by the values of the internal analog point).
  3. Select the Hand Control option to display the Hand Control dialog. You can use this dialog to perform a hand control (manually set the value of the point associated with the animated object).
  4. Set the Value to 10, then select the OK button to confirm the hand control.

You will see that the animated text box now displays 10.00 and the animated size bar shows a black bar that fills up 10% of the entire bar (the bar has a range of 0 to 100 by default).

  5. Using the same technique you learned in steps 3 and 4, set the value of the internal point to 15, 20, then 80 in that order.

When you have set the value to 80, the Mimic should look like this:

You’ve now learned how to create a very simple Mimic that contains dynamic data (data that changes according to the values in the database), and you’ve also learned how to manually control a point using the Hand Control feature. As you have controlled the point to have several different values, and the point has Historic enabled, you can view a record of the point’s values on a Historic Trend or Historic List. So your next task is to Display a Historic Trend for the Internal Analog Point.

Further Information

Hand Control: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Display a Historic Trend for the Internal Analog Point (Configuration Basics)

Display a Historic Trend for the Internal Analog Point

If a point has the Historic feature enabled, ClearSCADA keeps a record of the point’s values for a specific time period. You can view this 'historic' data on various displays, including Historic Trends (Graphs). One of the main benefits of viewing historic data on a Historic Trend is that you can see a graphical representation of how the point’s value changed over time and it is also possible to compare the values of different points on a single Trend.

As you have enabled the Historic feature for your internal analog point, and have manually set various values, you can view its data on a Historic Trend:

  1. On the 'MyTestPlant' Mimic (in Run mode), select the animated size bar or text box to access the context sensitive menu.
  2. Select the Display Historic Trend option to display a Historic Trend showing the internal analog point’s historic data (remember that the Display Historic Trend option is for the internal analog point as it is this point that is used to animate the size bar or text box). You could also access the Display Historic Trend option for the internal analog point by accessing the point’s context sensitive menu in the Database Bar).

Your Historic Trend should show that the internal analog point changed value from 10:00 to 15:00 to 20:00 and then to 80:00.

Before you proceed, close the Historic Trend (but leave the Mimic on display). Once you’ve done that, you can move on to the next section which explains how to access another type of historic display—the Historic List (see Display the Historic List for the Internal Analog Point).

Further Information

Trends and Historic Trends: see Configuring Trends in the ClearSCADA Guide to Trends.


ClearSCADA Tutorial - Display the Historic List for the Internal Analog Point (Configuration Basics)

Display the Historic List for the Internal Analog Point

Historic Lists allow you to view the historic values of a point in a list format, similar in style to an SQL Query list (the Historic List uses an SQL Query to obtain the data from the database). As the historic values are displayed in list format, it is easy to find specific values and information about each value.

To display the Historic List for the internal analog point:

  1. On the 'MyTestPlant' Mimic (in Run mode), select the animated size bar or text box to access the context sensitive menu.
  2. Select the Display Historic List option to display a Historic List showing the internal analog point’s historic data. You could also access the Display Historic Trend option for the internal analog point by accessing the point’s context sensitive menu in the Database Bar.

The Historic List shows information about the 4 values that have been recorded for the internal analog point.

If you right-click on a column heading or any of the historic values, you will see that a context sensitive menu is displayed. The menu contains options that allow you to change the order in which information is shown on the Historic List or even change the content of the Historic List. For example, you can Filter the Historic List so that it only shows values that were recorded during a specific time period.

  3. Close the Historic List.

Next, you are going to Change the Point Configuration to Trigger an Alarm.

Further Information

Historic Lists: see Historic Lists in the ClearSCADA Guide to Lists.


ClearSCADA Tutorial - Change the Point Configuration to Trigger an Alarm (Configuration Basics)

Change the Point Configuration to Trigger an Alarm

A key factor when configuring an analog point is the setting of its alarm threshold limits. Each analog point has a range of possible values, and by defining threshold limits, you can set ViewX to raise an alarm if a point’s value rises above or drops below specified limits.

For the tutorial, you are going to define the High High alarm threshold for the 'InternalWaterLevel' point you have already created. When you have configured the settings for the threshold, you will perform a Hand Control on the point so that its value causes an alarm to be raised ('triggered').

  1. Select the Properties option for the 'InternalWaterLevel' point. You can access the Properties option via the context sensitive menu for the point in the Database Bar or via the context sensitive menus for the animated text box and size bar on the 'MyTestPlant' Mimic.
    The configuration Form for the 'InternalWaterLevel' point is displayed, with the Analog Point tab selected by default.

In the Alarm Limits section, you will see a Limit column of fields, with a field for each limit (Full Scale, High High, High, Low, Low Low, and Zero Scale). You will use these fields to define the thresholds. To the right of each field are Severity, Description, and Color settings for each limit. You can use these settings to define what happens when the point’s value is within the threshold for the limit, how significant values in the threshold limit are, and to provide a description of the limit and associate it with a color.

  2. For the High High threshold, define these settings:
  • Level: 90
  • Severity: Alarm, High (choose High in the combo box to the immediate right of the Severity combo box).

Leave the default Description of High High in place and leave the Color field empty (this is an optional setting).

  3. Save the Form, then close it.
  4. Perform a Hand Control on the 'InternalWaterLevel' point to set its value to 95.

When you set the point value to 95, an alarm is raised as 95 is within the High High threshold limit (which covers the range 90 to 100) for the point. The High High threshold is set to raise a High priority alarm when the value is in this range (the Severity is Alarm, High).

Now that you have triggered an alarm, you can learn how to use the various alarm displays (see View an Alarm).

Further Information

Alarm Limit Thresholds: see Configure the Limits for an Analog Point in the ClearSCADA Guide to Core Point Configuration.


ClearSCADA Tutorial - View an Alarm (Configuration Basics)

View an Alarm

Several different displays indicate that the 'InternalWaterLevel' point has an alarm. These displays use the color red to draw your attention to the alarm, and they include:

  • The Alarm Banner
  • The 'MyTestPlant' Mimic (as it contains objects that are animated by the 'InternalWaterLevel' point’s values)
  • The Alarms List

The alarm is also indicated on any Query lists and status displays that provide information about the 'InternalWaterLevel' point. For this tutorial, we will focus on the Alarm Banner, Alarms List, and the 'MyTestPlant' Mimic.

  1. Examine the entries shown in the Alarm Banner at the bottom of the ViewX display (if the Alarm Banner is not already on display, select View>Alarm Banner from the Main Menu).

You will see that the alarm you have triggered for the 'InternalWaterLevel' point is included in the list of alarms. It is placed at the top of the list and is shown in flashing red text. This is because the alarm you have triggered has the highest priority, as it is:

  • Unacknowledged (no user has notified ViewX that they are aware of the alarm)
  • Uncleared (the conditions that caused the alarm to be raised are still in effect)
  • More recent than any other Unacknowledged Uncleared alarms.
  2. Examine the animated objects on the 'MyTestPlant' Mimic. You will see that they have changed to indicate that the point is in alarm. The formatted value in the animated text box changes color to red and flashes so that it attracts your attention. The bar in the animated size box increases in size to indicate that the value is close to the maximum value of the point (Full Scale) and also changes color to red to indicate an alarm.
  3. With the Mimic in Run mode, select the size bar or text box to display the context sensitive menu for the point, then select the Display Alarms option.
    The Alarms List is displayed.

As there is only 1 alarm for the 'InternalWaterLevel' point, the Alarms List only contains a single alarm.

This Alarms List is filtered so that it only shows alarms for the 'InternalWaterLevel' point. If you wanted to see an unfiltered list of the alarms on the system, you could display the Alarms List for the System item in the Database Bar (which you can also display by selecting the Alarms toolbar button or by pressing the F9 key).

Now that you have seen the alarm on various displays, it is time to 'action' the alarm (respond to it)—see Action an Alarm.

Further Information

Alarm Information: see Alarm Severity, Status, and Category in the ClearSCADA Guide to Alarms.

Alarms List: see Alarms Lists in the ClearSCADA Guide to Alarms.

Alarm Animations: see Alarms on Mimics in the ClearSCADA Guide to Alarms.

Alarm Banner: see Alarm Banner in the ClearSCADA Guide to Alarms.


ClearSCADA Tutorial - Action an Alarm (Configuration Basics)

Action an Alarm

When an alarm is raised, the various alarm displays show the alarm. Typically, alarms are set to flash so that the alarm information catches the attention of a system user, who can then respond to the alarm appropriately.

There are a variety of alarm responses available, but for this part of the tutorial you are only going to use the Acknowledge action. This action informs ViewX and other system users that you have seen the alarm and are investigating the conditions that caused it to be raised. For information on the other alarm response options, see Perform an Action on an Alarm in the ClearSCADA Guide to Alarms.

To acknowledge the 'InternalWaterLevel' point’s alarm:

  1. On the Alarms List for the 'InternalWaterLevel' point, right-click on the High severity alarm.
    This displays a context sensitive menu. The top section of this menu contains some display options as well as the alarm response options.
  2. Select the Acknowledge option. This changes the state of the alarm from Unacknowledged Uncleared to Acknowledged Uncleared, which means you have informed the system and other users that the alarm has been noticed, but the conditions that caused the alarm are still in place.

The change of alarm state causes the alarm to change color from red to olive.

  3. Perform a Hand Control on the 'InternalWaterLevel' point to set its value to 50. As the value of the point is no longer in the High High range, the alarm is cleared (it has been acknowledged and the conditions that caused the alarm to be raised are no longer in place).

Now that you have familiarized yourself with the basics of configuration and responding to alarms, you can choose to Test Your Knowledge on Configuration Basics, or you can proceed to the next section of the tutorial: Your First 'Live' Configuration.


ClearSCADA Tutorial - Test Your Knowledge on Configuration Basics (Configuration Basics)

Test Your Knowledge on Configuration Basics

So you’ve created a Group, configured an internal analog point, added some automatic animations to a Mimic, and responded to an alarm. Well done. But how much can remember about performing these basic configuration tasks and alarm responses?

  1. How do you rename a database item?
  2. When you create a new Group item, the Group contains 1 item by default. What type of item is it?
  3. What does a database point represent?
  4. What is the difference between an internal point and a 'normal' point?
  5. How do you display a configuration Form?
  6. How do you save the changes you make on a configuration Form?
  7. What is a Mimic?
  8. What is the difference between a Trend and a Historic Trend?
  9. How do you display the Historic List for a point?
  10. What configuration setting determines whether a point has historic data?
  11. Apart from the Alarm Banner, where else might you see alarm information?


ClearSCADA Tutorial - Your First 'Live' Configuration

Your First 'Live' Configuration

Your ClearSCADA system can connect to, and interact with, a wide variety of outstations, PLCs, controllers and similar devices. These devices contain 'live' data that is reported to, or retrieved by ClearSCADA and stored in corresponding items in the database. Similarly, ClearSCADA can send controls to the device.

You are now going to configure ClearSCADA to communicate with a hardware device—a SCADAPack Modbus controller that has:

  • Its serial port set to Modbus address 1
  • TelePACE firmware loaded
  • Been connected to a plant simulation equipment
  • A standard Register Assignment
  • Been connected to a COM port on your PC.

While we recommend that you use a SCADAPack Modbus controller (available from your ClearSCADA agent), you can complete this section without any hardware. However, if you don’t have a SCADAPack Modbus controller, you won’t have live I/O to work with, so to achieve different values and states, you will need to perform Hand Controls on your points.

NOTE: You need to have the SCADAPack Modbus driver installed on your system.

As you set up your first 'live' configuration, you will learn how to:

  • Log On to ViewX
  • Create a 'Serial Comms' Group and a 'Site'Group
  • Create a SCADAPack Modbus Direct Channel
  • Configure a SCADAPack Modbus Direct Outstation Set
  • Configure a SCADAPack Modbus Direct Outstation
  • Configure Two SCADAPack Modbus Analog Input Points
  • Configure Two SCADAPack Modbus Digital Input Points
  • Configure Two SCADAPack Modbus Digital Output Points
  • Configure a Mimic to contain Dynamic Data for the Points
  • Display a Historic Trend for the 'AI 1' Analog Input Point
  • Add an Alarms List to the Mimic
  • Filter the Alarms List
  • Create a Trend Database Item
  • Add the 'AI 1' Point’s Historic Values to a Trend
  • Edit the X-Axis
  • Add the 'DI 1' Point’s Historic Values to a Trend
  • Copy the Trend Data to Microsoft Excel.

At the end of this section, you can see how much you have learned by accepting our challenge to Test Your Knowledge on 'Live' Configuration.


ClearSCADA Tutorial - Log On to ViewX (Your First 'Live' Configuration)

Log On to ViewX

To configure the database items required for ClearSCADA to communicate with a SCADAPack Modbus controller, you need to log on via a user account with Configure permissions. The reconfigured 'Eng' user account has sufficient permissions to perform the tasks in this section, so if you are not already logged on as 'Eng', you need to do so:

  1. Select File>Log On to display the Log On window.
  2. In the username field, enter:
Eng
  3. Leave the Password field blank (empty)
  4. Select the OK button to confirm.

You are now logged on as the 'Eng' user and can proceed to Create a 'Serial Comms' Group and a 'Site'Group.

Further Information

Logging On and Off: see System Security in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Create a 'Serial Comms' Group and a 'Site'Group (Your First 'Live' Configuration)

Create a 'Serial Comms' Group and a 'Site' Group

Before you create the items that represent your SCADAPack Modbus device and connection, you are going to create two new Groups: 'Serial Comms' and 'Site'. You will then use these Groups to contain the SCADAPack Modbus items, so that your database is well organized and clear to understand.

To create the two Groups:

  1. Right-click on the System icon in the Database Bar, then select New>Group>Group from the context sensitive menu. This will add a new Group to the System.
  2. Name the Group:
Serial Comms
  3. Create another Group.
  4. Name the second Group:
Site

When you have added the two Groups, you can proceed to Create a SCADAPack Modbus Direct Channel.

Further Information

Organizing Your Database with Groups: see Groups in the ClearSCADA Guide to Core Configuration.


ClearSCADA Tutorial - Create a SCADAPack Modbus Direct Channel (Your First 'Live' Configuration)

Create a SCADAPack Modbus Direct Channel

To communicate with an advanced device such as a SCADAPack Modbus controller, ViewX needs to be able to identify the communication settings such as the port, parity, and the protocol to be used. These settings are defined in a channel. Each advanced driver has its own channels, so for your SCADAPack Modbus controller, you need to configure a SCADAPack Modbus Direct Channel.

To configure a SCADAPack Modbus Direct Channel:

  1. In the Database Bar, right-click on the 'Serial Comms' Group to display its context sensitive menu, then select New>SCADAPack Modbus>Direct Channel to create a new SCADAPack Modbus Channel database item.
  2. Press the Enter key to use the default name for the channel: 'New Direct Channel'.
  3. Double-click on 'New Direct Channel' to display its configuration Form.
  4. Select the Connection tab.
  5. On the Connection tab, configure the following setting:
  • Port—Use the browse button to choose the port to which your SCADAPack Modbus device is connected (COM1, COM2, and so on.)
  6. Still on the Connection tab, configure the remaining settings as follows:
  • Baud Rate—9600
  • Data Bits—8 Bits
  • Parity—None
  • Stop Bits—1 Bit
  • Flow Control—Choose the setting that applies to your connection:
  • None if a 3 wire cable is being used
  • Hardware (RTS/CTS) if a standard null modem cable is being used.

These settings should match those of your SCADAPack Modbus device.

  7. Select the Channel tab
  8. On the Channel tab, select the In Service check box to activate the Direct Channel.
  9. On the Scan Parameters tab, set the Re-establishment Interval to 10 seconds. (The server will attempt to re-establish failed communications via the channel every 10 seconds).
  10. Save the configuration.

With the Direct Channel configured, next you need to Configure a SCADAPack Modbus Direct Outstation Set.

Further Information

SCADAPack Modbus: Please refer to the SCADAPack Modbus Driver Guide in the ClearSCADA online help.


ClearSCADA Tutorial - Configure a SCADAPack Modbus Direct Outstation Set (Your First 'Live' Configuration)

Configure a SCADAPack Modbus Direct Outstation Set

ViewX uses Outstation Sets to represent a Group of outstations that share communication channels. As with channels, each Driver has its own Outstation Sets, with different types of Outstation Set for each type of channel. For example, the SCADAPack Modbus Driver has outstation sets for direct, shared, switched, and PSTN channel types.

As your SCADAPack Modbus controller is connected via a single direct channel, you need to configure a SCADAPack Modbus Direct Outstation Set:

  1. In the Database Bar, right click on the 'Serial Comms' Group and select New>SCADAPack Modbus>Direct Outstation Set from the context sensitive menu. This adds a new SCADAPack Modbus Direct Outstation Set item to the 'Serial Comms' Group.
  2. Press the Enter key to use the default name for the Direct Outstation Set:
New Direct Outstation Set

  3. Double-click on the Direct Outstation Set to display its configuration Form.
  4. Select the Outstation Set tab
  5. Select the In Service check box to activate the Outstation Set.
  6. In the Channel field, use the browse button to locate the 'New Direct Channel' item that you created in step 1. Select the 'New Direct Channel' then select the OK button. This associates the Direct Outstation Set with the Direct Channel.
  7. Select the Modbus tab.
  8. Configure the Set Address so that it is 1.

NOTE: This address is used internally by ClearSCADA to identify the outstation set with which incoming communications are associated. It does not correspond to any settings in the SCADAPack Modbus controller or to the Outstation Address.

  9. Save the configuration changes you have made and close the 'New Direct Outstation Set' configuration Form.

You can now proceed to Configure a SCADAPack Modbus Direct Outstation.

Further Information

SCADAPack Modbus: Please refer to the SCADAPack Modbus Driver Guide in the ClearSCADA online help.


ClearSCADA Tutorial - Configure a SCADAPack Modbus Direct Outstation (Your First 'Live' Configuration)

Configure a SCADAPack Modbus Direct Outstation

So far, you have configured:

  • A Direct Channel to represent the connection between ClearSCADA and your SCADAPack Modbus controller
  • A Direct Outstation Set so that ClearSCADA can recognize several devices using the same channel (this is required even if the channel is only used by one device)

Next, you need to configure an item that represents the device that uses the channel, in this case, a direct SCADAPack Modbus controller (which is represented by a SCADAPack Modbus Direct Outstation in ViewX).

To configure a SCADAPack Modbus Direct Outstation:

  1. In the Database Bar, right click on the 'Site' Group and select New>SCADAPack Modbus>SCADAPack Direct Outstation from the context sensitive menu. This adds a new direct outstation item to the 'Site' Group.
  2. Name the direct outstation:
ScPack

  3. Display the configuration Form for the 'ScPack' direct outstation.
  4. Select the Direct tab.
  5. Select the Promote when Displaying Points check box to activate the promotion feature. ClearSCADA promotes the direct outstation so that when you display the values of any of its points in ViewX, the outstation is scanned more frequently.
  6. Select the SCADAPack tab.
  7. Set the Address to 1. This is the address of the SCADAPack Modbus controller.
  8. Select the Outstation tab.
  9. Select the In Service check box to enable the direct outstation.
  10. Use the browse button feature of the Outstation Set field to locate the 'New Direct Outstation Set' item. Select the outstation set, then select the OK button to confirm your choice and close the browse window. This associates the direct outstation with the direct outstation set (and therefore, with the direct channel too, as you have already configured the outstation set to be associated with the direct channel).
  11. Save the configuration and close the 'ScPack' configuration Form.

You have now configured items to represent the channel and outstation, as well as a set to Group the channel with the outstation. Now you need to configure the database points to represent the inputs and outputs on your SCADAPack Modbus controller.

Proceed to Configure Two SCADAPack Modbus Analog Input Points.

Further Information

SCADAPack Modbus: Please refer to the SCADAPack Modbus Driver Guide in the ClearSCADA online help.


ClearSCADA Tutorial - Configure Two SCADAPack Modbus Analog Input Points (Your First 'Live' Configuration)

Configure Two SCADAPack Modbus Analog Input Points

Each analog input on your SCADAPack Modbus controller can be represented in your system by a SCADAPack Modbus analog point. The configuration of the point defines its alarm limit thresholds, formatting, historic settings, and so on.

Now you are going to create two analog input points which will represent two of the analog inputs on your SCADAPack Modbus controller:

  1. In the Database Bar, right click on the System to display its context sensitive menu, then select New>SCADAPack Modbus> Analog Input Point.
    A new analog input point is created.
  2. Name the analog input point:
AI 1
  3. Display the configuration Form for the 'AI 1' point.
  4. Select the Analog Point tab.
  5. Select the In Service check box to enable the point.
  6. Use the browse button feature of the Outstation field to associate the point with the 'ScPack' Outstation that you have already created.
  7. Set the Address to 30001 (this is the first analog input on your controller).
  8. Set the Retrieval Interval to Interval 1. This sets the analog input point to be scanned at the rate defined for Interval 1, which is configured on the Form for the outstation (in this case, the 'ScPack' outstation has the default setting of 0.1 second for Interval 1).
  9. Select the Historic tab.
  10. Select the Enabled box to activate the historic feature for the point. Your system will now store a record of the point’s values.
  11. Set the Offset to:
S-55S

This time setting represents the current second minus 55 seconds.

  12. Set the Interval to:
1M

This sets the Interval to 1 minute. So the Historic Trend for the point will show 1 minute on the x-axis, with the first time on the x-axis being 55 seconds in the past.

  13. Save the Point Form and then close it.
  14. Select the 'AI 1' point in the Database Bar so that it is highlighted.
  15. From the Main Menu, select Edit>Copy to copy the 'AI 1' point.
  16. From the Main Menu again, select Edit>Paste to add a copy of the 'AI 1' point to your database.
  17. Rename the copy to:
AI 2
  18. Display the configuration Form for the 'AI 2' point.
  19. On the Analog Point tab, set the 'AI 2' point’s Address to 30002.
  20. Save the Point Form and then close it.

Proceed to Configure Two SCADAPack Modbus Digital Input Points.

Further Information

SCADAPack Modbus: Please refer to the SCADAPack Modbus Driver Guide in the ClearSCADA online help.


ClearSCADA Tutorial - Configure Two SCADAPack Modbus Digital Input Points (Your First 'Live' Configuration)

Configure Two SCADAPack Modbus Digital Input Points

Each digital input on your SCADAPack Modbus controller can be represented in your system by a SCADAPack Modbus digital point. The configuration of the point defines whether its states trigger alarms, its retrieval rate, address, and so on.

For this tutorial, you are going to create two digital input points which will represent two of the digital inputs on your SCADAPack Modbus controller:

  1. In the Database Bar, right click on the System to display its context sensitive menu, then select New>SCADAPack Modbus> Digital Input Point.
    A new digital input point is created.
  2. Name the digital input point:
DI 1
  3. Display the configuration Form for the 'DI 1' point.
  4. Select the Digital Point tab.
  5. Select the In Service check box to enable the point.
  6. Use the browse button feature of the Outstation field to associate the point with the 'ScPack' Outstation that you have already created.
  7. Set the Address to 10001 (this is the first digital input point address)
  8. Set the Retrieval Interval to Interval 1.
  9. In the States section, set the Severity of State 1 to Alarm and High. This means that when the point changes state to State 1, a high priority alarm will be raised.
  10. Select the Historic tab.
  11. Select the Enabled check box to activate the historic feature.
  12. Set the Offset to:
S-55S

This time setting represents the current second minus 55 seconds

  13. Set the Interval to:
1M

This sets the Interval to 1 minute. So the Historic Trend for the point will show 1 minute on the x-axis, with the first time on the x-axis being 55 seconds in the past.

  14. Save the Point Form and then close it.
  15. Make a copy of the 'DI 1' point and paste the copy into the 'Site' Group.
  16. Rename the copy:
DI 2
  17. Display the configuration Form for the 'DI 2' point.
  18. On the Digital Point tab, set the Address to 10002.
  19. Save the Point Form and then close it.

Proceed to Configure Two SCADAPack Modbus Digital Output Points.

Further Information

SCADAPack Modbus: Please refer to the SCADAPack Modbus Driver Guide in the ClearSCADA online help.


ClearSCADA Tutorial - Configure Two SCADAPack Modbus Digital Output Points (Your First 'Live' Configuration)

Configure Two SCADAPack Modbus Digital Output Points

Each digital output on your SCADAPack Modbus controller can be represented in your system by a SCADAPack Modbus digital output point. The configuration of the point defines whether its states trigger alarms, its retrieval rate, address, and so on.

For this tutorial, you are going to create two digital output points which will represent two of the digital outputs on your SCADAPack Modbus controller:

  1. In the Database Bar, right click on the System to display its context sensitive menu, then select New>SCADAPack Modbus> Digital Output Point.
    A new digital output point is created.
  2. Name the digital input point:
DO 1
  3. Display the configuration Form for the 'DO 1' point.
  4. Select the Digital Point tab
  5. Select the In Service check box to enable the point.
  6. Use the browse button feature of the Outstation field to associate the point with the 'ScPack' outstation.
  7. Set the Address to 00001 (this is the address of the first digital output on your controller).

ATTENTION: If you are using a 5604 lower I/O module, you should use the address 00003 instead.

  8. Set the Retrieval Interval to Interval 1.
  9. Select the Control tab
  10. Select the Enabled check box next to Action 1. This activates Action 1 for the output point, which means you can perform a control that sets the point to 0. (The effect of the point being set to 0 will vary according to the set up of your controller and the instruments or sensors that are connected to it).
  11. Repeat step 10, only this time select the Enable check box next to Action 2. This allows you to perform a control that sets the point to 1.
  12. Save the Point Form and then close it.
  13. Make a copy of the 'DO 1' point and paste the copy into the 'Site' Group.
  14. Rename the copy:
DO 2
  15. Display the configuration Form for the 'DO 2' point.
  16. On the Digital Point tab, set the Address to 00002 (or 00004 if you are using a 5604).
  17. Save the Point Form and then close it.

NOTE: The Digital Output addresses should be relative to the hardware you are using. If you use a 5604, you need to configure the Digital Output addresses so that they correspond to the 3rd and 4th outputs (00003 & 00004).

You have now configured 6 points to represent some of the inputs and outputs on your SCADAPack Modbus controller. Next, you should Configure a Mimic to contain Dynamic Data for the Points.

Further Information

SCADAPack Modbus: Please refer to the SCADAPack Modbus Driver Guide in the ClearSCADA online help.


ClearSCADA Tutorial - Configure a Mimic to contain Dynamic Data for the Points (Your First 'Live' Configuration)

Configure a Mimic to contain Dynamic Data for the Points

Now that you have configured analog and digital input points and digital output points, you can configure a Mimic to show their values. The Mimic will provide a graphical display that contains an overview of the points’ values.

To configure a Mimic to contain dynamic data for the points:

  1. In the Database Bar, expand the 'Site' Group, then double-click on the 'Default' Mimic to display its editor.
  2. In the Database Bar, select the 'AI 1' point and drag it onto the display area of the Default Mimic. Release the mouse button to display a context sensitive menu.
  3. Select the Name option from the context sensitive menu. This adds a text box to the Mimic, and the text box is automatically configured to be animated by the name property of the 'AI 1' point. So if the name property of the 'AI 1' point changes, the change will be shown on the Mimic automatically—there is no need to update the name value on the Mimic manually.
  4. Repeat steps 2 and 3, only this time select the Value>Formatted Value options. This adds a text box that is animated by the point’s CurrentValueFormatted property (as well as its Foreground, Background and Blink properties, which affect the appearance of the text in the text box).
  5. Repeat steps 2 and 3, only this time select the Value>Vertical Bar>Up options. This adds a vertical size bar that is animated automatically so that the size of the bar changes according to the value of the analog point.
  6. Repeat steps 2 and 3 for each of the digital points.
  7. Repeat step 4 for each of the digital points, only this time select State from the menu instead of Value>Formatted Value.
  8. Organize your Mimic objects so that your Mimic looks like this:
  9. Save the Mimic.
  10. Put the Mimic into Run mode by deselecting the Design Mode toolbar button or deselecting the Design option on the View menu.

When you display a Mimic in Run mode, the Mimic’s configuration features become unavailable and the Mimic displays its dynamic data. Usually, operators will work with Mimics in Run mode.

When you switch a Mimic from Design Mode to Run mode, you may notice that the grid that is automatically turned off, and so the grid dots are no longer visible. This is because grid lines are designed to help align objects during configuration and so are not required during operation.

You will also see that the animated size bars are now sized according to the analog input from your SCADAPack Modbus controller. Many animations are only visible when a Mimic is displayed in Run Mode.

Now you have a Mimic that displays live, 'dynamic' I/O. But the Mimic does more than just display data—it provides access to other displays and controls, as you will see in the next section: Display a Historic Trend for the 'AI 1' Analog Input Point.

Further Information

Displaying Data on a Mimic: see Animations in the ClearSCADA Guide to Mimics.

Considerations when Creating and Configuring a Mimic: see Designing a Mimic in the ClearSCADA Guide to Mimics.


ClearSCADA Tutorial - Display a Historic Trend for the 'AI 1' Analog Input Point (Your First 'Live' Configuration)

Display a Historic Trend for the 'AI 1' Analog Input Point

If you position the cursor over any of the animated objects on your Mimic and left-click, you will see that a context sensitive menu is displayed. The context sensitive menu is associated with the point that is used to animate the Mimic objects, so if you positioned the cursor over an object that is animated by the 'DO 1' point, the context sensitive menu that is displayed contains options that relate to the 'DO 1' point.

Animated Mimic objects provide access to the context sensitive menus for the items that animate their values. This is a useful feature as it means low level users can view item-specific displays and perform controls from a single display: the Mimic.

To see how easy it is to access displays from a Mimic, display the Historic Trend for the 'AI 1' point:

  1. With the 'Default' Mimic displayed in Run mode, position the cursor over the 'Formatted Value' text box for the 'AI 1' point.
  2. Press the left-hand mouse button to display the context sensitive menu for the 'AI 1' point, then select the Display Historic Trend option.
    A Historic Trend for the 'AI 1' point is displayed.
  3. Close the Trend window when you are finished observing the data.

Now that you’ve seen how an animated Mimic object can provide access to displays and controls for a specific item, it is time to add a display to the configuration of a Mimic. Proceed to Add an Alarms List to the Mimic.

Further Information

Historic Trends: see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends.


ClearSCADA Tutorial - Add an Alarms List to the Mimic (Your First 'Live' Configuration)

Add an Alarms List to the Mimic

You can add displays such as Lists and Trends to Mimics so that they are included as part of the Mimic’s configuration. When you display the Mimic, it will contain a reduced version of the original List, Trend, and so on.

Adding displays to Mimics is a great way of presenting information to users in a variety of formats, for example, a Mimic could contain animated text boxes that show the values of a collection of points, and also a list that shows those points in a list format (which makes it easier to compare one point’s values to those of another point).

To learn how adding displays to Mimics works, you are going to add an Alarms List to your 'Default' Mimic:

  1. Display the 'Default' Mimic in Design Mode.
  2. Select the Insert menu, then select the Alarms List option. You will see that when you position the cursor on the Mimic, it changes to a cross hair.
  3. Position the cursor beneath the digital point animations, then press the left-hand mouse button down. Keep it pressed down and move the mouse to draw a rectangle. The rectangle will be the space that is filled by the Alarms List.
  4. Release the left-hand mouse button to add the Alarms List.

The Alarms List shows all alarms on your system by default.

  5. Display the Mimic in Run mode.
  6. Disconnect the serial cable from the SCADAPack Modbus controller.
  7. After a few seconds, a new alarm appears in the Alarms List. Use the scroll bars on the list to scroll to the Message for the new alarm. You will see that it shows:
Communications State - Failed

The colors of the values on the Mimic change color from black to magenta. The magenta color indicates that there has been a communications failure.

  8. Reconnect the serial cable.
  9. After a few seconds, the alarm changes color, from red to green. This indicates that the conditions that caused the alarm to be raised are no longer in place, but the alarm has not been acknowledged by a user.

Now you have added an Alarms List to your Mimic, you can proceed to Filter the Alarms List.

Further Information

Alarms Lists: see Alarms Lists in the ClearSCADA Guide to Alarms.

Embedding Alarms Lists: see Embed an Alarms List on a Mimic in the ClearSCADA Guide to Mimics.


ClearSCADA Tutorial - Filter the Alarms List (Your First 'Live' Configuration)

Filter the Alarms List

By default, the Alarms List you have added is unfiltered - it shows the alarms on your system, irrespective of their severity, the items with which they are associated, the time at which they were raised etc. By using ClearSCADA’s comprehensive filter system, you can restrict the Alarms List so that it only displays alarms that have certain properties.

To learn how the Filter feature works, you are going to filter the Alarms List on your Mimic to show only those alarms that relate to items in the 'Site' Group:

  1. With the 'Default' Mimic of the 'Site' Group displayed in Run mode, select the list icon at the bottom right of the Alarms List to display a context sensitive menu.
  2. Select the Filter option to display the Filter Window.
  3. In the Sources section, select the Add button to display the Add Source window.
  4. Use the browse button feature of the Source field to locate and select the 'Site' Group. The Source field will show:
Site.*

This means that the Alarms List will only show alarms for items that are in the 'Site' Group.

  5. Select the OK button to confirm.
  6. Select the OK button on the Filter window to confirm your filter choice and close the Filter window.

Now the Alarms List only shows alarms directly related to the 'Site' Group.

Further Information

Alarms List: see Alarms Lists in the ClearSCADA Guide to Alarms.

Filtering an Alarms List: see Use the Filter Window to Filter Alarm Entries in the ClearSCADA Guide to Alarms.


ClearSCADA Tutorial - Create a Trend Database Item (Your First 'Live' Configuration)

Create a Trend Database Item

To configure a Trend that contains values from the database, you first need to create a Trend database item. You can then configure the Trend item as required.

For the tutorial, you are going to add a new Trend item to the 'Site' Group that you created earlier in the tutorial (or imported).

To create a Trend database item:

  1. In the Database Bar, right-click on the 'Site' Group to display its context sensitive menu.
  2. Select New>Trend to create a new Trend database item. The Trend is selected automatically, ready for you to define its name.
  3. Define the name of the Trend as:
Point Monitoring

You now have a Trend database item that you can configure, but to configure it, you need to display it in Design mode.

  4. Double-click on the 'Point Monitoring' Trend to display it in Design mode.

You can now proceed to Add the 'AI 1' Point’s Historic Values to a Trend

Further Information

Creating a Trend Item: see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends.


ClearSCADA Tutorial - Add the 'AI 1' Point's Historic Values to a Trend (Your First 'Live' Configuration)

Add the 'AI 1' Point’s Historic Values to a Trend

When you create a Trend, you need to associate it with at least one database item—the Trend can then plot the values (current or historic) of that item.

For the tutorial, you are going to plot the historic values of the 'AI 1' point. This point has been configured to have Historic data.

To plot the historic values of the 'AI 1' point:

  1. In the Database Bar, select the 'AI 1' point. Keeping the left-hand mouse button pressed down, drag the 'AI 1' point onto the Trend editor.
    A context sensitive menu is displayed.
  2. Select the Raw Historic Trace option. This adds a trace to the Trend. The trace is a line that represents the historic values that have been reported for the point (the Processed Historic Trace option adds a trace that represents historic values that have been calculated for the point).

NOTE: You can edit a trace so that it has a different style of appearance, including a Step and a Bar.

  3. On your plant simulator equipment, adjust the values of the first analog input so that the 'AI 1' point has a variety of values. If you are unable to access plant simulator equipment, you can simulate this effect by performing an override on the point:
  1. Right-click on the 'AI 1' point and select Properties to display its Form.
  2. On the Analog Point tab, scroll down to the Override section and select the Enabled check box to allow the point’s value to be manually overridden.
  3. Save the Form
  4. Right-click on the 'AI 1' point in the Database Bar and select its Override action. This displays the Override window.
  5. Enter a value of 90 then select OK to override the point’s value to 90.
  6. Repeat this process, but override the point to have a value of 60 then 25 respectively. These override values will provide some historic data for the point as the point is configured to have Historic enabled.
  4. Right-click on the background of the Trend to display a context sensitive menu.
  5. Select the Pan option. This enables Pan mode which you can use to drag the time line of the Trend (the time line is shown on the x-axis).
  6. Drag the trace that is shown on the Trend to view the plotted values for the point at various times.

The x-axis uses the default settings to determine the amount of time to show on a single interval. However, you can configure the x-axis to show different time scales (see Edit the X-Axis).

If you look at the y-axis, you will see that it is automatically configured to represent the entire range of values that have been configured for the 'AI 1' point (0 to 100). This is because the y-axis uses the default Mode of Range, which means it represents the configured range for the point.

If you plot the values of another point on the Trend, and the point’s possible values are incompatible with the range shown on the y-axis, ViewX will add a new y-axis. The new y-axis will have a range that is suitable for the possible values of the second point. If you continue to add additional traces, the same process will apply—if the y-axes on display have ranges that are incompatible with the points, new y-axes will be created. However, if the existing y-axes have appropriate ranges, the y-axes will be shared.

Now you have added the 'AI 1' point’s historic data to your Trend, you should proceed to Edit the X-Axis.

Further Information

Trends: see Understanding Trends in the ClearSCADA Guide to Trends.


ClearSCADA Tutorial - Edit the X-Axis (Your First 'Live' Configuration)

Edit the X-Axis

The x-axis represents a time scale called the Interval. The Interval is the amount of time that can be seen on the Trend at one time, for example, if the Interval was 30M, the x-axis would represent 30 minutes and the Trend could show 30 minutes’ worth of data at once. The Interval is the amount of time you can see at once on the Trend; it is not the total amount of time on the Trend. By using the Previous Interval and Next Interval features, you can navigate to earlier and later intervals as required.

When you edit the X-Axis, you can define the start time of the Interval that is currently being displayed. To do this, you need to use the Edit X-Axis window to adjust the Interval and Offset settings:

  1. On the Trend, position the cursor just beneath the x-axis, then right-click to display the x-axis’s context sensitive menu.
  2. Select the Edit option to display the Edit X Axis window.
  3. On the Edit X-Axis window, use the combo box under the Continuous check box to select Other.
  4. Set the Offset to:
M-4M

This sets the start time of the x-axis to be 4 minutes ago (the start of the current minute minus 4 minutes).

  5. Set the Interval to:
5M

This sets the x-axis to represent 5 minutes at a time.

  6. Select the OK button to confirm your selections and close the Edit X-Axis window.
    You will see that the x-axis now represents 5 minutes of time, with the first time shown being 4 minutes in the past.
  7. Right-click on the background of the Trend to display a context sensitive menu.
  8. Select the Previous Interval option. This sets the Trend to display the previous interval which is the 5 minutes prior to the 5 minutes you had on display.
  9. Repeat steps 7 and 8 to view several previous intervals on the Trend.
  10. Repeat steps 7 and 8, only this time, select the Next Interval option instead of the Previous Interval option. You will see that the Next Interval option sets the Trend to display the 5 minutes after the 5 minutes that were on display.

You have now edited some of the available settings for the x-axis. Next, you are going to Add the 'DI 1' Point’s Historic Values to a Trend.

Further Information

X-axis Configuration: see Configure the X-Axis in the ClearSCADA Guide to Trends.


ClearSCADA Tutorial - Add the 'DI 1' Point's Historic Values to a Trend (Your First 'Live' Configuration)

Add the 'DI 1' Point’s Historic Values to a Trend

One of the major benefits of Trends is that they allow you to view and compare the values of multiple points simultaneously and in a graphical format.

On your Trend, you already have one trace that represents the 'AI 1' point, so now you are ready to add another trace. For the tutorial, you will add a trace for the 'DI 1' point:

  1. In the Database Bar, select the 'DI 1' point. With the left-hand mouse button still pressed down, drag the point onto the Trend to display a context sensitive menu.
  2. Select the Raw Historic Trace option to add a trace to the Trend. The trace will plot the reported historic values for the 'DI 1' point.

An additional y-axis has been added, as the 'DI 1' point has a different range of possible values than the 'AI 1' point.

  3. Double-click on the 'Site.DI 1' trace in the key below the x-axis. This displays the Edit Raw Historic Trace window.
  4. In the Trace settings, set the Style to Step Last. This changes the type of trace line that is shown—instead of a straight, angled line between markers, the trace will be drawn so that there is a right-angle between markers. The horizontal part of the right-angle is drawn from the previous marker and the vertical part of the right-angle indicates the latest value.
  5. Save the Trend.

Further Information

Trace Configuration: see Configure a Trace in the ClearSCADA Guide to Trends.


ClearSCADA Tutorial - Copy the Trend Data to Microsoft Excel (Your First 'Live' Configuration)

Copy the Trend Data to Microsoft Excel

You can copy data from your Trends to spreadsheet applications such as Microsoft Excel. You can then analyzes the data in the spreadsheet and use it for presentations.

To copy your Trend data to Microsoft Excel:

  1. Toggle the digital input and analog input signals on your plant simulation equipment so that you have noticeably varying values on display on the Trend (this makes it easier to see how the values are copied to a spreadsheet application).
  2. On the Trend, right-click on the x-axis to display a context sensitive menu, then deselect the Continuous option. This turns off the Continuous updating feature so that the Trend does not update during the copying process.
  3. Select the File menu, then select Edit>Copy to copy the data on the Trend.
  4. Run Microsoft Excel.
  5. In Excel, select Edit>Paste to add the data from the traces on your Trend to the Excel spreadsheet.

You’ve now configured items to represent your SCADAPack Modbus controller, its connection to ClearSCADA, and its I/O. You’ve also configured a Mimic to show 'dynamic' data from the controller, and have configured a Trend so that it contains 2 traces. These same principles can be used when configuring other advanced drivers.

So are you ready to Test Your Knowledge on 'Live' Configuration?


ClearSCADA Tutorial - Test Your Knowledge on 'Live' Configuration (Your First 'Live' Configuration)

Test Your Knowledge on 'Live' Configuration

You’ve now configured items that allow ClearSCADA to communicate with a hardware device, in this case, a SCADAPack Modbus controller. Along the way, you have learned how to configure settings using Forms and editors such as the Mimic editor. But how much can you remember about everything you’ve learned? Put yourself to the test:

  1. When configuring database items to represent plant that uses advanced drivers, such as a SCADAPack Modbus controller, there are at least three types of database item that you need to configure. What are they?
  2. What type of database item represents the communications connection between ClearSCADA and a device such as a SCADAPack Modbus controller?
  3. What term is used as a generic term for devices such as SCADAPack Modbus controllers and PLCs?
  4. An outstation set is only used internally by ClearSCADA. But what does ClearSCADA use an outstation set for?
  5. If you want ClearSCADA to keep a record of a point’s values, what setting do you need to enable?
  6. In ClearSCADA, what is meant by the term 'animated object'?
  7. What is dynamic data?
  8. How can you filter an Alarms List so that it only displays alarms related to a specific database item?
  9. A Mimic is displaying a list that shows 'live' I/O from a device. Its list entries suddenly change from black to magenta. What does this mean?
  10. Trends are useful as they allow users to view and compare database values that have been reported over periods of time. They can be used as stand-alone displays but are often added to what other type of display?
  11. What is the difference between a raw historic trace and a processed historic trace?
  12. Why would a Trend need to show more than one y-axis?
  13. You can configure an Offset and an Interval for the x-axis. But what do these settings do?
  14. Which three Trend navigation tools have you used to change the time range that is displayed on the Trend?
  15. How can you change the appearance of a trace?
  16. How do you copy Trend data to a Third Party spreadsheet application?


ClearSCADA Tutorial - Using a WebX Client

Using a WebX Client

You can use a web browser such as Microsoft Internet Explorer to access your system remotely. A PC that accesses the system via a web browser is called a WebX client, and it can be used to access the operational features of ViewX, including alarm response features and controls. This means that operators can log on to your system from anywhere in the world (Internet access required). Your system’s security settings (user accounts, permissions, passwords etc.) also apply to WebX, and help to protect WebX clients from unauthorized access.

As with ViewX, your system’s WebX is protected by your system’s security settings, including user accounts, permissions, and passwords.

NOTE: WebX provides access to operator-level features. For configuration features, you need to use a ViewX client.

For the tutorial, you are going to access your system via Microsoft Internet Explorer, so you need to have this application installed on your PC. The minimum requirement is for Microsoft Internet Explorer 5 with Microsoft XML 3 or Microsoft Internet Explorer 6. For information on these web browser applications, please refer to the Microsoft web site at www.microsoft.com.

If you haven’t completed the earlier sections of the tutorial, you will also need to import some data so that your system has items, values and alarms that you can interact with via WebX:

  1. Log On to ViewX as the user 'Eng' (no password).
  2. In the Database Bar, right-click on the System icon then select Import from its context sensitive menu. This displays the Import From window.
  3. In Windows, browse to C:\Program Files\Schneider Electric\ClearSCADA\Tutorial Files.
  4. Select the SerialComms.sde file
  5. Select the Open button to close the Import From window and import the file.
  6. Repeat this process, only instead of importing the SerialComms.sde file, import the following files:
  • MyFirstTest.sde
  • SiteTemplate.sde
  • SiteABCInstance.sde
  • SiteDEFInstance.sde

When you have installed the relevant Internet Explorer software on your PC and you have imported the data (if required), you can proceed to access your system via the web interface:

  1. Display the WebX Interface
  2. Log on to the System via WebX
  3. Use the Navigation Tools to Access other Displays
  4. Access Database Items via WebX
  5. Display a List of System Alarms via WebX
  6. Display a List of System Events via WebX
  7. Display a Queries List via WebX.

NOTE: If you are automatically logged off when using WebX, you should log back on using the user name of Eng and a blank (empty) password.


ClearSCADA Tutorial - Display the WebX Interface (Using a WebX Client)

Display the WebX Interface

To display the WebX interface, you need to run Internet Explorer and define the relevant address. The address consists of the server name and the port address (port number).

To display the WebX Interface:

  1. Run Internet Explorer.
  2. In the Address field, enter the IP address of your PC then press the Enter key to run WebX.

If you need to find out the IP address of your PC:

  1. Select the Start button on the Windows taskbar
  2. Select Run.
  3. At the prompt, enter:
cmd

  4. Then press the Enter key to run the command prompt.
  5. At the command prompt, enter:
ipconfig

  6. Then press the Enter key. The command prompt will then display information about your connections, including the IP address of your PC.

NOTE: If the WebX page is not displayed, there may be a certificate error. You may need to use an alternative address or port number. For more information, see Run a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.

The WebX home page contains a navigation banner featuring the following buttons:

  • Home—Displays the WebX home page.
  • Database—Displays the System web page, which provides hyperlinks to the items in your database.
  • Alarms—Displays the Alarms List for your system. If your user account has sufficient permissions, you can use the Alarms List to view and manage any alarms on your system.
  • Events—Displays the Event List for your system. If your user account has sufficient permissions, you can use the Alarms List to view any events logged on your system.
  • Lists—Displays the List web page, which provides hyperlinks to the SQL Queries Lists for your system. The Queries Lists work in the same way as in ViewX except that they are view only—you cannot use them to access other displays, actions, etc.
  • Log On—Allows you to log on to the system.

When you have displayed the WebX home page, proceed to Log on to the System via WebX.

Further Information

Understanding WebX: see WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Log on to the System via WebX (Using a WebX Client)

Log on to the System via WebX

When you first display the WebX interface, you are logged on as the Guest user and so have read-only access to your system. As with ViewX, access to your database via the web is dependent on the permissions that are allocated to your user account.

When using the WebX interface, you need to log on to the system before you can access the various features.

To log on to the system via the WebX interface:

  1. Select the Log On button on the WebX home page banner to display the log on page.
  2. In the username field, enter:
  3. Eng
  4. Leave the Password field blank (empty).
  5. Press the Log On button. You are now logged on as the 'Eng' user. You will see that the home page has changed. This is because the 'Eng' user account is associated with a Mimic that acts as the home page. This Mimic is called 'Opening Page' and can also be accessed in ViewX. In the configuration of the 'Eng' user account, the 'Opening Page' Mimic is selected as the Home Page.

If you look at the buttons at the top of the display, you will also see that extra buttons are available, including Documents, Favorites and Diagnostics.

Now that you have logged on, you can use the WebX interface to operate your system. Proceed to Use the Navigation Tools to Access other Displays.


ClearSCADA Tutorial - Use the Navigation Tools to Access other Displays (Using a WebX Client)

Use the Navigation Tools to Access other Displays

The home page for the 'Eng' user is a Mimic that has been configured to be used as a user-friendly interface. It has two text boxes which are animated to act as hyperlinks—when you select them, they take you to a different 'page'. The text boxes show 'Presentation' and 'Projects' and look like buttons on the WebX display.

As we want you to experience the various navigation tools and see the different types of display that can be shown, we are going to ask you to select the Projects button:

  1. On the WebX interface, select the Projects button to display the Projects Overview page. This page shows a map of a geographical area. At its default size, the map shows quite a large area with little detail.
  2. If you have a mouse wheel, roll the wheel forward to zoom in on the map. As you increase the level of magnification, more detail is revealed, including road networks and embedded Mimics that show the locations of different sites.

If you are using a mouse that has no wheel, you can change the magnification level by using the pop-up magnification menu at the bottom-right of the browser window.

  3. Select the 'Water Treatment Overview' embedded Mimic. This embedded Mimic has been configured to act as a hyperlink to another display—the Process Overview Mimic.
  4. On the 'Process Overview' Mimic, select the 'Air Blower 1' item to display a context sensitive menu. As in ViewX, Mimic objects can provide access to context sensitive menus that relate to the database item that is used to animate the Mimic object.
  5. Select Device Menu>Hand Control to display the Hand Control window.
  6. Set the Value to Running, then select the OK button to confirm. You will see that the 'Air Blower' object on the Mimic changes color to indicate that it is running. You have now issued a control via the WebX interface.
  7. Perform another Hand Control to the 'Air Blower 1' object, only this time set its Value back to Stopped.
  8. Select the 'Flow Summary' button on the Mimic. This displays the Flow Summary page.

As the Flow Summary page does not contain any hyperlinks, you cannot use it to access other displays. But you can return to the previous page you viewed by selecting the web browser’s Back button. Each time you press the Back button, you return to the previous page you viewed in sequence. Similarly, if you select the Forward button, you display the next page you viewed in sequence.

Now that you are familiar with some of WebX’s navigation tools, you can proceed to Access Database Items via WebX.

Further Information

WebX Navigation: see Use the WebX Interface in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Access Database Items via WebX (Using a WebX Client)

Access Database Items via WebX

You can use the WebX interface to access displays for individual database items. For each database item there is a status 'page' which provides the latest values and information. As in ViewX, the database items are organized in a hierarchy, with Groups, Group Templates and Group Instances containing other items. However, WebX uses hyperlinks and headings to represent the various types of database items rather than icons.

To access database items via WebX:

  1. Select the Database button from the menu banner. This displays the System page.

The System page is the WebX equivalent of the Database Bar—it provides access to the hierarchy of items in your database. Each database item is represented by a hyperlink. If you select the hyperlink, WebX displays information about the selected item. If you select a hyperlink for a Group, Group Template, or Group Instance, WebX displays another page that provides hyperlinks for the items within that Group, Group Template or Group Instance.

  2. Select the Serial Comms hyperlink to display the Serial Comms page. This page lists the items in the 'Serial Comms' Group and provides hyperlinks for each item. You will see that there are two links for Mimics (one to display the Mimic and another to display information about its status), and there are also links to the Parent Group and the Default View Mimic for the 'Serial Comms' Group as well as the Children (items that are contained in the Group).
  3. Select the New Direct Channel hyperlink to display the information page for the 'New Direct Channel' database item. The information page provides status details on the 'New Direct Channel' database item.
  4. Use the hyperlinks and the web browser’s Back and Next buttons to navigate your database.

When you are comfortable using the navigation features and know how to locate database item displays, you can proceed to the next section: Display a List of System Alarms via WebX.

Further Information

Using WebX to Access Database Items: see Browse your Database on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Display a List of System Alarms via WebX (Using a WebX Client)

Display a List of System Alarms via WebX

You can use WebX to display an unfiltered list of alarms on your system. You can then filter the Alarms List as required and use it to respond to alarm conditions.

To display an unfiltered alarms list:

  1. Select the Alarms button on the menu banner to display the Alarms page.

The Alarms page contains a list of the alarms on your system, and the alarm information is categorized under Severity, Time, Source, Message, and Category headings in the same way as alarms that are shown on the alarm displays in ViewX.

  2. Right-click on one of the alarms in the list to display a context sensitive menu.

    You can see that on the context sensitive menu for the alarm, you have access to the alarm response options such as Acknowledge and Acknowledge with Comment. These alarm response features work in exactly the same way as on a ViewX client, meaning operators and engineers can manage alarms remotely.

NOTE: If there are no active alarms on your system, you can generate alarms by performing Hand Controls on database points. You can use WebX to access the Hand Control action for points—Select Lists> Points, then select OK so that a filter is not applied, then right-click on the required point in the Points List.

  3. Right-click on the background of the Alarms List to display a context sensitive menu.
  4. Select the Filter option to display the Filter window.

You can use the Filter window to restrict the Alarms List so that it only shows alarms that meet certain criteria.

  5. Use the Filter window to restrict the Alarms List so that it only shows alarms that relate to the items in the 'SiteABC' Group Instance. To do this, you need to:
  1. Select the Add button in the Sources section to display the Add Source window.
  2. Use the browse button feature of the Source field to associate the source with the 'SiteABC' Group Instance.
  3. Select the OK button to confirm and close the Add Source window. You will see that the Sources list now contains 'SiteABC.*' which means the Alarms List is filtered to only show alarms for items that are in the 'SiteABC' Group or its subgroups.
  4. Select the OK button to confirm your selection and close the Filter window.
    The Alarms List is filtered so that it only shows alarms for items in the 'SiteABC' Group Instance (it doesn’t have any subgroups).

Now that you have displayed the System Alarms web page and learned how to access the filter settings, you can proceed to the next section: Display a List of System Events via WebX.

Further Information

Alarms: see View and Action Alarms on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.

Filtering an Alarms List: see Use the Filter Window to Filter Alarm Entries in the ClearSCADA Guide to Alarms. This section describes the filter process in ViewX, but the same principles apply in WebX.


ClearSCADA Tutorial - Display a List of System Events via WebX (Using a WebX Client)

Display a List of System Events via WebX

You can also use WebX to display an unfiltered list of events on your system. The Events List is a record of what has occurred on your system, with the event, time of event and user that instigated the event (where applicable) included.

To display an unfiltered list of Events on your system:

  1. Select the Events button on the menu banner to display the System Events page.

The System Events page shows a list of the events logged on your system for a defined time period. The time period is the amount of time defined in the Event List Range for your user account (the Event List Range defined for the system is used for Guest users).

  2. Right-click on an Event to display a context sensitive menu.
  3. Select the Filter option to display the Filter Columns window.

The Filter Columns window shows the filters that are currently in place. The only filter should be a time filter that matches the setting defined in the Event List Range for the 'Eng' user.

  4. Select the Add button to display the Add Clause window. You can use the Add Clause window to apply additional filters to the Event List.
  5. On the Add Clause window, set the Category to user, the operation to Is Equal To and then enter the following in the bottom field:
Eng

This will filter the Events List so that it only shows those events that have 'Eng' as their entry in the user category (events that are related to the activity of the 'Eng' user).

  6. Select the OK button to confirm and close the Add Clause window.
  7. Select the OK button to confirm your selections and close the Filter Columns window.
    The Events List is filtered so that it only shows those events that:
  • Were logged in the period starting from 1 hour prior to the start of the current hour and ending 1 hour after the start of the current hour

And

  • Have 'Eng' as their entry in the user category (indicating events that were generated in response to your actions as the 'Eng' user).
  8. Display the Filter Columns window for the Events List.
  9. Select the user is equal to Eng filter, then select the Remove button to delete this filter.
  10. Close the Filter Columns window.
  11. Right-click on the Events List to display a context sensitive menu.
  12. Select the Sort option to display the Sort Order window.
  13. Use the Sort Order window to define the order in which events are listed:
  1. Select the Add button to display the Add Column window.
  2. Set the Column combo box to Severity. This will add another type of sort order to the Events List—it will sort the list according to the Severity level of the events.
  3. Set the Direction combo box to Descending. This sets the Events List to show the events with the highest level Severity values at the top.
  4. Select the OK button to close the Add Column window.
  5. Select the Severity sort method in the list.
  6. Select the Move Down button to move the Severity sort method down one place in the list. The Sort Order is applied according to the order of sort methods in the list, with the sort order at the top being applied first.
  7. Select the OK button to close the Sort Order window and apply the new sort order.
    The Events List is now sorted so that:
  • The events are listed in time order, with the events with the latest time stamps shown at the top.
  • Any events that have the same time stamp are then sorted according to their Severity. The Severity sort method is only applied to events that have the exact same time stamps, and the highest level severities are shown above the lower level severities.
  • Any events that have the same time stamps and same severity levels are sorted according to their Sequence Number.

You’ve now displayed the System Events List in WebX and have applied a filter and sort order. Next, you will Display a Queries List via WebX.

Further Information

Events in WebX: see View and Action Events on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Display a Queries List via WebX (Using a WebX Client)

Display a Queries List via WebX

You can use WebX to access the SQL Queries Lists that are available on your system, such as the Points List. These Lists provide exactly the same data as the Queries Lists in ViewX.

To display a Queries List:

  1. Select the Lists button on the menu banner to display the Lists page. The Lists page provides hyperlinks to each type of List, for example, links to the Channels List, Points List, and so on.
  2. Select the Points hyperlink to display the Filter Columns window for the Points List. You can use the Filter Columns window to restrict the Points List so that it only displays points with certain properties or values. For this tutorial, you are going to filter the Points List so that it only shows SCADAPack Modbus digital input points.
  3. Select the Add button to display the Add Clause window.
  4. Use the Add Clause window to apply a filter:
  1. Set the top combo box to Type (TypeDesc)
  2. Set the middle combo box to Is Equal To
  3. Set the bottom combo box to SCADAPack Modbus Digital Input Point.

This restricts the list so that it only displays points that have a TypeDesc value of SCADAPack Modbus Digital Input Point (points that are SCADAPack Modbus digital input points).

  5. Select the OK button to confirm your selection and close the Add Clause window.
  6. Select the OK button on the Filter Columns window to confirm your selection and close the Filter Columns window.

The Points List is filtered so that it only displays SCADAPack Modbus digital input points:

Now that you know how to access Queries Lists via WebX, you can Log Off from WebX.

Further Information

Lists in WebX: see View and Action Lists on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Log Off from WebX (Using a WebX Client)

Log Off from WebX

You’ve now learned how to access Mimics, the Alarms List, the Events List, Queries Lists, and information about database items via the WebX interface. You’ve also learned how to apply sorting and filters to lists. Before you Test Your Knowledge on the WebX Interface, you should log off:

  • Select the Log Off button on the menu banner. In WebX, you are logged off as the 'Eng' user. However, you can still use WebX as the 'Guest' user.

Now let’s see how much you have learned—proceed to Test Your Knowledge on the WebX Interface.


ClearSCADA Tutorial - Test Your Knowledge on the WebX Interface (Using a WebX Client)

Test Your Knowledge on the WebX Interface

How much do you know about the WebX interface? Try and answer the following questions:

  1. WebX is designed to allow remote access, but can it be used to access your system from anywhere?
  2. Apart from remote access and appearance, what is the main difference between WebX and ViewX?
  3. What features are used to help prevent unauthorized access via a WebX client?
  4. How do you access WebX?
  5. If you don’t have a mouse with a wheel, how can you zoom in on a Mimic in WebX?
  6. You can use your web browser’s Back and Forward buttons to navigate through WebX displays in the order in which you originally displayed them. But what other ways are there of accessing different WebX displays?
  7. You want to display status information about a specific point. How would you do this in WebX?
  8. You are logged on via a WebX client when an alarm is raised. You are responsible for responding to the alarm, so what do you do?
  9. How can you filter the Alarms List so that it only displays alarms that relate to items in a specific Group?
  10. You display the Events List and its entries are sorted in Time order. You want them to be sorted according to their Severity and so create a new Severity sort method. You apply the Severity method but the Events List still appears to be sorted according to time. Do you know why?
  11. You want to perform a Hand Control on a database point via WebX. How would you achieve this?


ClearSCADA Tutorial - Group Templates and Group Instances

Group Templates and Group Instances

Group Templates and Group Instances are one of ClearSCADA’s most effective database organization features. You can use them to significantly reduce the amount of configuration required to set up your system, and they also allow you to reduce the amount of maintenance required when making alterations to the configuration settings.

To learn about the Group Template and Group Instance features, you are going to convert the 'Site' Group that you created earlier in the tutorial into a Group Template. You will then use the Group Template as a model configuration for Group Instances.

NOTE: For this section, you are going to use the 'Site' Group that you created in the Your First 'Live' Configuration section. If you have not completed the Your First 'Live' Configuration section, you can import the configuration by right-clicking on the system icon in the Database Bar, selecting the Import option, then browsing to the SerialComms.sde file that is located at C:\Program Files\Schneider Electric\ ClearSCADA\Tutorial Files. Select the OK button to import the SerialComms.sde file, then use the same technique to import the Site.sde file that is stored in the same location as the SerialComms.sde file.

When you have the 'Site' and 'SerialComms' Groups in your database you can proceed with the Group Template and Group Instances configuration:

  1. Log On to ViewX
  2. Convert the 'Site' Group into a Group Template
  3. Create Two Group Instances that Reference the Group Template
  4. Reconfigure the Default Mimic in the 'Site'Group Template
  5. Configure the Group Template to Allow Additional Property Overrides

When you have completed the configuration, you can Test Your Knowledge on Group Templates and Instances.


ClearSCADA Tutorial - Log On to ViewX (Group Templates and Group Instances)

Log On to ViewX

To convert a Group into a Group Template and create Group Instances, you need to log on via a user account with Configure permissions. The reconfigured 'Eng' user account has sufficient permissions to perform the tasks in this section, so if you are not already logged on as 'Eng', you need to do so:

  1. Select File>Log On to display the Log On window.
  2. In the username field, enter:
Eng
  3. Leave the Password field blank (empty)
  4. Select the OK button to confirm.

You are now logged on as the 'Eng' user and can proceed to Convert the 'Site' Group into a Group Template.

Further Information

Logging On and Off: see System Security in the ClearSCADA Guide to ViewX and WebX Clients.


ClearSCADA Tutorial - Convert the 'Site' Group into a Group Template (Group Templates and Group Instances)

Convert the 'Site' Group into a Group Template

Group Templates are 'model' collections of database items. They contain items that have been configured, but the items are not 'live'—they provide the configuration 'model' for items in each of the Group Instances that reference the Group Template.

For example, if you have a Group Template that contains a Mimic, 2 Trends, an outstation set, an outstation, a channel and 2 points, you can configure these items in the usual way. But in a Group Template, the items you configure are not used to represent actual displays, connections or devices—they are used to provide the configuration for any Group Instance that references the Group Template. When you associate a Group Instance with the Group Template, the Group Instance will automatically contain ‘live’ versions of the items in the Group Template.

So, if you create 3 Group Instances and configure them to reference the Group Template, each Group Instance will contain a Mimic, 2 Trends, an outstation set, an outstation, a channel and 2 points, and these will have the same configuration settings as defined in the Group Template. You can then use Property Overrides to change individual settings for the items in the Group Instances, such as unique addresses.

By using Group Templates to provide the starting configuration for Group Instances, you can significantly reduce the amount of time and effort it takes to configure your system and apply later configuration changes.

There are two ways to create a Group Template—you can create an entirely new Group Template item or you can convert an existing Group into a Group Template. For the tutorial, you are going to convert the 'Site' Group into a Group Template:

  1. In the Database Bar, right-click on the 'Site' Group to display its context sensitive menu.
  2. Select the Convert To>Group Template option. This converts the 'Site' Group from a normal Group into a Group Template. The items in the Group are no longer 'live' and you will see that the color of the Group folder changes from yellow (normal Group) to burgundy (Group Template).

You have now converted the 'Site' Group into a Group Template and it can be used as a reference model for Group Instances. To make use of the Group Template, you are going to Create Two Group Instances that Reference the Group Template.

Further Information

Converting a Group into a Group Template: see Converting Groups and Group Instances in the ClearSCADA Guide to Core Configuration.


ClearSCADA Tutorial - Create Two Group Instances that Reference the Group Template (Group Templates and Group Instances)

Create Two Group Instances that Reference the Group Template

Group Instances are special types of Groups. Like normal Groups, they are 'live'—the items they contain represent displays, devices, and real inputs and outputs. However, they do have one distinguishing feature: they inherit their configuration from a Group Template.

For the tutorial, you are going to create two Group Instances that reference the 'Site' Group Template. Both Group Instances will automatically contain 'live' versions of the items in the 'Site' Group Template. This means that you will have two Group Instances that work in the same way as the original 'Site' Group (the Group that you converted into the Group Template).

To create two Group Instances that reference the Group Template:

  1. In the Database Bar, right-click on the System icon to display its context sensitive menu.
  2. Select the New>Group>Instance option to create a new Group Instance. You will see that it is represented by a green folder and is selected automatically, ready for you to define its name.
  3. Define the name of the Group Instance as 'SiteABC'
  4. Double-click on the 'SiteABC' Group Instance to display its configuration Form.
  5. On the Reference tab, use the Template field’s browse feature to associate the 'SiteABC' Group Instance with the 'Site' Group Template.
  6. Save the Form.
  7. In the Database Bar, expand the 'SiteABC' Group Instance and look at its contents. You will see that it contains 'live' versions of the items in the 'Site' Group Template.
  8. Use the same techniques as described in steps 1 to 7 to create a second Group Instance that references the 'Site' Group Template. Name the second Group Instance 'SiteDEF'.

You will see that adding the 'SiteDEF' Group Instance breaks the configuration of the 'SiteABC' Group Instance (the broken configuration is indicated by a red cross next to the outstation items). This is because the outstation in the 'SiteDEF' Group Instance has the same address as the outstation in the 'SiteABC' Group Instance, and outstations have to use unique addresses.

By default, SCADAPack Modbus outstations and points in Group Instances can have their addresses overridden with new configuration settings. This is because it is common for outstations and points in Group Instances to require unique addresses. But you can also configure the Group Template to allow any configuration setting to be overridden, as you will see later in the tutorial.

  9. Double click on the 'ScPack' outstation in the 'SiteDEF' Group Instance to display its Form.
  10. Change the address of the 'ScPack' outstation so that it does not clash with the address of the 'ScPack' outstation in the 'SiteABC' Group Instance.
  11. Save the Form.
    If you look at the Database Bar, you will can see that the Group Instances’ configuration is no longer broken (as the outstations have unique addresses).

You have now created a Group Template and Group Instances that reference the Group Template. You have also configured one of the properties that is set to allow overrides by default (the outstation address). Next, you are going to change the configuration in the Group Template and see how it affects the Group Instances—proceed to

Further Information

Group Templates and Group Instances: see Setting Up Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration.


ClearSCADA Tutorial - Reconfigure the Default Mimic in the 'Site'Group Template (Group Templates and Group Instances)

Reconfigure the Default Mimic in the 'Site' Group Template

Now that you have a Group Template with Group Instances that reference it, you can make adjustments to the configuration in the Group Template and these changes will automatically be applied to the Group Instances. To illustrate this, you are going to make a change to the configuration of the 'Default' Mimic in the Group Template:

  1. In the Database Bar, double-click on the 'Default' Mimic in the 'Site' Group Template to display it in Design Mode.
  2. Select the 'ScPack' outstation in the 'Site' Group Template and drag it onto the Mimic. When you release the left-hand mouse button, a context sensitive menu is displayed.
  3. Select the State option to add an animated text box to the Mimic. The text box is animated by the StateDesc property of the outstation (as well as the Foreground, Background, and Blink properties). The StateDesc is a text description of the outstation’s current state. When you add the text box to your Mimic, it should show the description:
All Channels Failed

  4. Save the Mimic
  5. Display the 'Default' Mimic in the 'SiteABC' Group Instance. You will see that it has the outstation state text box. If the outstation and channel are correctly configured and a SCADAPack Modbus controller is connected to your system, the text box should show the description:
Healthy, Multidrop

  6. Display the 'Default' Mimic in the 'SiteDEF' Group Instance. You will see that it has the outstation state text box. The text box should show the description:
Failed

This is because you have not configured to the items in the 'SiteDEF' Group Instance to represent a second SCADAPack Modbus controller.

As you can see, a single change made in the Group Template is automatically applied to its Group Instances. Used carefully, this feature can make configuring, updating and maintaining your system a considerably quicker and easier process.

So far, you have learned how to create Group Templates and Group Instances, and make changes in the Group Template that affect the Group Instances. But what if you need a Group Instance to take some, but not all of its configuration from a Group Template? Can you choose which properties the Group Instance inherits? The answer is yes, and in the next section, you are going to learn how to override properties: proceed to Configure the Group Template to Allow Additional Property Overrides.


ClearSCADA Tutorial - Configure the Group Template to Allow Additional Property Overrides (Group Templates and Group Instances)

Configure the Group Template to Allow Additional Property Overrides

When you configure a Group Instance to reference a Group Template, it automatically inherits the items from the Group Template. Many of the configuration settings for these items are also inherited, and you cannot reconfigure these settings in the Group Instance. However, certain properties, such as addresses (which need to be unique), can be reconfigured. By default, you can change the settings of those properties that need to be unique.

As you configure your system, you may find that you need to configure settings that are unavailable in your Group Instances. For example, you may decide that you want to be able to configure the Historic settings for the points in your Group Instances rather than inherit the Historic settings from the Group Template. To do this, you need to use the Property Overrides feature on the Group Template. With Property Overrides, you can select specific properties of the database items in the Group Template and allow them to be overridden. Any property that you allow to be overridden can be reconfigured in the Group Instances.

Learn how to use the Property Overrides feature by allowing the Historic settings of the points in the Group Instances to be overridden:

  1. In the Database Bar, right-click on the 'Site' Group Template to display its context sensitive menu.
  2. Select the Property Overrides option to display the Property Overrides window.
  3. On the Property Overrides window, expand the branch for the 'AI 1' point, then expand the Historic branch. This reveals the historic properties (these correspond to the fields on the Historic tab of the Point Form).
  4. Select the check box next to the Historic branch (this represents the Enabled check box on the Historic tab of the Point Form) and then select the check boxes for the Historic properties. By doing this, you are allowing the Historic settings of the point to be configured separately in the Group Instance (although the Historic settings of the Group Template will be used as the default Historic settings for the point).
  5. Repeat steps 3 and 4 for the other points in the Group Template.
  6. Select the OK button to confirm your selection and close the Property Overrides window.
  7. Display the configuration Form for any of the points in the Group Instances.
  8. Select the Historic tab.

The Historic tab’s settings are available for you to configure. The configuration changes you apply will only affect the point on which you apply the changes.

Now that you have worked with a Group Template and Group Instances, with a little forward planning, you should be able to configure your system more quickly, with less effort.

But how much have you learned? Test Your Knowledge on Group Templates and Instances.

Further Information

Property Overrides: see Property Overrides in the ClearSCADA Guide to Core Configuration.


ClearSCADA Tutorial - Test Your Knowledge on Group Templates and Instances (Group Templates and Group Instances)

Test Your Knowledge on Group Templates and Instances

You have created a Group Template and Group Instances and have seen how they can be used to reduce the amount of configuration work required to set up and maintain your system. But are you ready to use what you have learned? Put yourself to the test by answering these Group Template and Group Instance questions:

  1. What are the two ways you can create a new Group Template?
  2. What is the difference between a Group Template and a Group Instance?
  3. What is the difference between a Group Instance and a 'Normal' Group?
  4. What does the Property Overrides feature allow you to do?
  5. A Group Template contains a Logic program. This program is used by several Group Instances, and the Logic programs in the Group Instances are identical to the Logic program in the Group Template. An amendment needs to be made to the Logic programs. What is the quickest way to make the amendment?
  6. A point in a Group Instance needs to have its High High alarm threshold limit re-configured. The High High alarm threshold is grayed out on the point’s Form. So how do you reconfigure its High High setting?


ClearSCADA Tutorial - Online Help

Online Help

Throughout the tutorial, you have worked with a variety of ClearSCADA’s user-friendly displays and have seen a small sample of the powerful and innovative features it provides. But as the tutorial draws to an end, we’d like to direct you toward the comprehensive ClearSCADA online help.

An extensive suite of user documentation, ClearSCADA online help provides detailed information on all aspects of ClearSCADA. So whether you are taking your first steps toward configuring a live system or are an experienced engineer looking for an explanation of a specific feature, ClearSCADA online help has all the information you need.

We hope you have enjoyed the tutorial and that it has increased your awareness of the vast capabilities of ClearSCADA. To continue your learning, please:

  1. Display the Online Help
  2. Use the Online Help to Find Additional Information.


ClearSCADA Tutorial - Display the Online Help (Online Help)

Display the Online Help

ClearSCADA’s online help facility provides comprehensive documentation on all aspects of ClearSCADA. Whenever you don’t understand a feature, concept, or setting, just refer to the online help for all the information you need.

Display the online help by pressing the F1 function key or by selecting Help>Contents from the main menu.

Further Information

Display the Online Documentation: see Display the ClearSCADA Help Window in the ClearSCADA Guide to Using Help.

Using the Online Documentation: see Layout of the ClearSCADA Help Window in the ClearSCADA Guide to Using Help.


ClearSCADA Tutorial - Use the Online Help to Find Additional Information (Online Help)

Use the Online Help to Find Additional Information

Now that you have displayed the online help, you have all of the information you need at your fingertips. To begin with, you should read the Welcome to ClearSCADA Help section, which explains how to use the various online help features, including Help Search and Context Sensitive Help.

When you are familiar with the Help window, you can refer to the following sections as required:

  • Welcome to ClearSCADA—introduces ClearSCADA and explains how to use ClearSCADA Help.
  • What’s New in ClearSCADA?—describes the features that have been added to this version of ClearSCADA.
  • Tutorial—the online tutorial that introduces you to various ClearSCADA features and displays.
  • ViewX and WebX Clients—describes how to use the ViewX interface and operational features (non-configuration related features).
  • Core Reference—contains detailed documentation on all of the core ClearSCADA features (all non-driver specific features). These include Core Configuration (including Core Point Configuration), Lists, Mimics, Trends, Alarm Redirection, Expressions, Logic, Security, and Client and Server Administration.
  • Driver Reference—describes all of the driver-specific features (features that are only available if your system has the relevant drivers installed). Note that you may not have all of the drivers installed on your system.
  • Technical Reference—provides highly technical information that is not driver-specific or related to core product features. This information includes documentation on SQL and the Automation Interface.

This tutorial was just the beginning—there is a wealth of information available in the various categories of the Online Help documentation. There, you will find all of the information you need to set up, configure, maintain, and use your ClearSCADA system.

Further Information

Using the Online Documentation: see Layout of the ClearSCADA Help Window in the ClearSCADA Guide to Using Help.

Search for Specific Information: see Use the Search Facility in the ClearSCADA Guide to Using Help.


ViewX and WebX Clients Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


ViewX and WebX Clients Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


ViewX and WebX Clients Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


ViewX and WebX Clients Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


ViewX and WebX Clients Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


ViewX and WebX Clients Guide - Document Scope (About the Guide)

Document Scope

This guide:

  • Provides an operator-level overview of ClearSCADA and its main user interfaces (ViewX and WebX)
  • Provides information about the features and displays that are typically available to operator-level users
  • Summarizes the various Explorer Bars
  • Explains:
  • The common Object menu options and pick actions
  • The common Status Display attributes.

For more information, see Welcome to the ViewX and WebX Clients Guide.


ViewX and WebX Clients Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for operator-level users.

The guide can also be used by engineers and other users who need to familiarize themselves with the features listed in the guide’s Document Scope.


ViewX and WebX Clients Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


ViewX and WebX Clients Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Alarms

ClearSCADA Guide to Mimics

ClearSCADA Guide to Lists

ClearSCADA Guide to Trends

ClearSCADA Guide to Logic

ClearSCADA Guide to Drivers

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Scripting

ClearSCADA Guide to Security

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Server Status Tool.


ViewX and WebX Clients Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


ViewX and WebX Clients Guide - Welcome to the ViewX and WebX Clients Guide

Welcome to the ViewX and WebX Clients Guide

Welcome to the ClearSCADA Guide to ViewX and WebX Clients. In this Guide you will learn how to use the operator features of the two user interfaces provided with ClearSCADA:

  • ViewX Client.
  • WebX Client.
    ViewX
    WebX

If you are new to ClearSCADA, please see Understanding Your System, which describes the various components that comprise a ClearSCADA system.

Both ViewX and WebX clients provide access to a variety of displays that you might use as a ClearSCADA operator, including:

  • Alarms
  • Events
  • Mimics
  • Lists
  • Trends
  • Reports
  • Status Displays
  • Operator Document Stores.

You can access these displays via the Explorer Bars used in ViewX, or the Object Menu on either a ViewX or WebX client. You can also store frequently accessed displays as Favorites.

The displays provide access to the information you need as well as the methods and pick actions you will use to interact with your SCADA system.

Throughout this guide, the ViewX Client is used to describe how to perform operations. The section on the WebX Client describes the WebX interface, and explains how basic navigation and operations in WebX differ from ViewX.


ViewX and WebX Clients Guide - Understanding Your System

Understanding Your System

You can use ViewX (the primary ClearSCADA Man-Machine Interface) or a WebX client to operate your ClearSCADA system. Before you begin to work with either of the interfaces, you need to understand the principles of your system and some of the terminology used in ClearSCADA. By learning about these basic concepts, you will develop an understanding of how your system works and how your actions will affect the system.

To learn about the basic concepts of a ClearSCADA system, see these sections:

  • What is ClearSCADA?, including:
  • ClearSCADA Server
  • ClearSCADA Client.

For further information on the types of ClearSCADA client you might use, see ViewX Client, and see WebX Client.

For information on the types of driver that might be installed on your system, and for an overview of master-slave setups, and direct and PSTN communications, see Welcome to the ClearSCADA Guide to Drivers in the ClearSCADA Guide to Drivers.

For information on the terminology used throughout this guide, see Terminology.


ViewX and WebX Clients Guide - What is ClearSCADA? (Understanding Your System)

What is ClearSCADA?

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) system. It comprises one or more ClearSCADA Server s. The Server contains the database (configuration and data for each item on the system) and communicates with the other devices—outstations, PLCs, sensors and so on—that comprise your system. The Server typically monitors such devices and retrieves their data. The data is processed for use in ClearSCADA (for example, raw analog data might be scaled to a more meaningful range). If configured to do so, the Server can also send instructions (controls) to any of those devices, to, for example, start a pump, or switch off a motor. Such controls can be triggered automatically or manually.

You typically access the Server’s data by logging onto a ClearSCADA client. A ViewX Client is the primary type of ClearSCADA Client. A ViewX client is usually a separate computer workstation that is in permanent communications with the Server. A ClearSCADA system can have multiple ViewX clients. The tasks that you can perform on a ViewX client differ, depending on the permissions assigned to your user account, the type(s) of device with which your ClearSCADA system communicates, and so on. Different levels of user are expected to perform different tasks. For example, an operator should have to access the areas of the system in which they are interested and be able to monitor system activity, via a series of graphical and/or textual displays and Explorer Bars. A configuration engineer would typically have access that would enable them to modify a database item’s configuration. A system administrator should have access that would enable them, for example, to configure the server and client settings and set up the system security. On some systems, system administrator and configuration engineer tasks are assigned to the same user.

If your system setup allows, the Server’s data can also be accessed by logging onto a WebX Client —a PC or laptop that is configured to access ClearSCADA via a Web (Internet or intranet) interface. A WebX client is intended to provide access to ClearSCADA on an occasional basis—for example, by an engineer performing maintenance in the field, who requires access to the alarms that are being raised on the system. A WebX client provides operator, rather than configuration, access to the system.

This guide:

  • Explains the differences and similarities between, and how to use, ViewX and WebX clients (see ViewX Client, and see WebX Client)
  • Introduces the various textual and graphical displays that ClearSCADA supports:
  • Alarms
  • Events
  • Mimics
  • Lists
  • Trends
  • Reports
  • Status Displays
  • Operator Document Stores.
  • Explains the toolbars, Explorer bars, and ‘core’ menu options that enable you to access the data you require and perform the necessary tasks. For information, see:
  • Explorer Bars used in ViewX
  • Object Menu
  • Send a Message to a User on another ViewX Client.


ViewX and WebX Clients Guide - ClearSCADA Server (Understanding Your System)

ClearSCADA Server

A ClearSCADA server contains the database and the driver(s) that are used to communicate with the outstations and other devices on your system. A ClearSCADA system can have more than one server, but only one server can be ‘main’ (run the drivers and communicate with the clients and hardware) at any one time.

Each driver contains additional support to enable the ClearSCADA server to communicate with other devices (such as PLCs or outstations) using one particular communications protocol. For example, the ClearSCADA Modbus driver uses the Modbus protocol to communicate with Modbus PLCs. Each driver scans the devices that are using that particular protocol and for which valid configuration exists in the ClearSCADA database. For more information, see the Driver Reference Suite.

When you use a ClearSCADA client to perform an action on plant, the action is sent from your client to the ClearSCADA server. The driver sends the action to the relevant device, and the device processes the action to control the plant.

The ClearSCADA server requests data from the outstations and other devices at regular user configured intervals. Data can also be requested manually at any time. The data the ClearSCADA server receives is stored in the database, which contains database points that correspond to the plant.

Further Information

ClearSCADA Client.

The types of driver that ClearSCADA supports: see Types of Driver in the ClearSCADA Guide to Drivers.

Master-slave communications: see Master-Slave Communications in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - ClearSCADA Client (Understanding Your System)

ClearSCADA Client

ClearSCADA clients are programs that run on the computers that access the ClearSCADA database (the ClearSCADA database is stored on the ClearSCADA Server). The ClearSCADA clients communicate with the ClearSCADA server via a network connection.

You typically operate ClearSCADA via a ViewX Client or a WebX Client. ClearSCADA also supports other methods of accessing its data, for example, via Microsoft® Excel or Crystal Reports.

Typically, you need to log on to a ClearSCADA client before you can work with your system. You log on by entering a unique user identification name and a password. These details are associated with a user account that allows you entry to the system, along with permissions that determine which features and database items you can access.

Depending on the permissions that have been allocated to your user account, you might be able to:

  • Access displays such as Mimics, Trends, and Lists
  • Alter values and states to manipulate the system and plant—for example, send a control to plant by controlling an output point
  • Manage alarms
  • View status information
  • Manage outstation communications (switch communication lines, promote the outstations, and so on).

When you perform an action (or ‘method’), the relevant instruction is sent to the ClearSCADA Server, where it is processed. The action is then either performed within the ClearSCADA server or is sent to the relevant outstation or other device (depending on the type of action).

If an outstation receives a control (from an action), it processes the data and then sends an instruction to the instruments that operate the plant—for example, a signal to start a pump.


ViewX and WebX Clients Guide - ViewX Client

ViewX Client

A ViewX Client is the main type of ClearSCADA Client. The primary function of a ViewX client is to provide day-to-day user access to ClearSCADA. A ClearSCADA system typically has multiple ViewX clients.

ViewX uses a PC interface (called a client) to monitor and control remote equipment via data that is stored in the ClearSCADA database on a central computer server (the ClearSCADA Server). On a ViewX client, you access the ClearSCADA system via a ViewX window.

As an operator, you will predominantly use ViewX to access:

  • Mimics—Graphical displays that can provide access to action menus (for alarm management, controls, and so on) and related displays such as other Mimics, Trends, Lists (see Mimics).
  • Alarm displays—A variety of displays (Alarm Banner, Alarms Lists, and so on) that provide information about the alarms currently raised on your system. You can use these displays to access the alarm management features (see Alarms).
  • Trends—Displays that show traces of values over a period of time (see Trends).
  • Queries Lists—Lists that you can use to view database items of the same type, or with specific property values. For example, the points on a particular site (see Lists). Queries Lists use SQL Queries to request data from the database.
  • Event Journal—A record of events on your system. You can use the Event Journal (also referred to as the Events List) to trace the causes and times at which specific events occurred (see Events).

Similar displays can also be accessed from a WebX Client.

On a ViewX client, the functions are accessed via drop-down menus, toolbars, or context sensitive menus that can be selected with the mouse. You can also use keyboard shortcuts to access many of the features.

For information on using a ViewX client, see the following sections, which explain:

  • How to Run ViewX
  • System Security, including how to:
  • Log On to ViewX
  • Log Off from ViewX
  • Change your Password via ViewX.
  • The ViewX Window, including the:
  • Menus
  • Toolbars
  • Explorer Bar (see Explorer Bars used in ViewX)
  • Document Display Area
  • Alarm Banner (see Alarm Banner in the ClearSCADA Guide to Alarms)
  • Status Bar.
  • How to Send a Message to a User on another ViewX Client.


ViewX and WebX Clients Guide - Run ViewX (ViewX Client)

Run ViewX

To run ViewX:

  1. Either:
  • Select ViewX from the Windows’ Start menu group.

Or:

  • Select the ViewX desktop shortcut

(If you do not have access to a ViewX desktop shortcut icon, please contact a higher level user.)

The ViewX Window is displayed.

Document Display Area
Toolbars
Menus in the ViewX menu bar
Explorer Bar
Alarm Banner
Status Bar

To access ClearSCADA via ViewX, you typically need to log on to the system (see System Security).


ViewX and WebX Clients Guide - System Security (ViewX Client)

System Security

ClearSCADA security helps to protect the SCADA system from unauthorized access. System access requires a password. The actions that you perform as a user are logged by the system (see Events).

As a system user, you will be assigned access permissions according to the functions you need to perform, and you will only be able to see the functions that this makes available to you.

You will use a ViewX or WebX client that has been configured by a higher level user, which will provide access to the displays and features that you need to carry out your tasks, such as performing actions on database items and managing alarms.

System security allows you to:

  • Log On to ViewX
  • Log Off from ViewX
  • Change your Password via ViewX.


ViewX and WebX Clients Guide - Log On to ViewX (ViewX Client)

Log On to ViewX

For security, your ClearSCADA system has user accounts. Designed to be allocated to individual members of staff, each user account has a unique username and password that have to be entered before a user can gain access to your system. For extra security, passwords can be time limited, so that they have to be changed on a regular basis.

The user accounts are created during the configuration of your system. Typically, you will be allocated a user account that you can use to log on to ViewX. The permissions that have been allocated to your user account determine which features you can access, for example, your user account may prohibit you from accessing configuration features.

Some systems can be configured so that you can gain access to some features without logging on. If you are using ViewX without logging on, it means you are interacting with ClearSCADA via the default Guest user account; if you are using WebX without logging on, it means you are using the default Web user account. These two user accounts do not require you to log on, but are usually configured to provide very limited access to your system(s).

Your ClearSCADA system may provide access to more than one ClearSCADA database. If so, when you log on, you can choose to log on to one particular system, or every system (database) to which your user account and the ViewX client have access.

To Log On to ViewX, you need to:

  1. Display the Log On window. There are several ways of doing this:
  • By selecting the File menu, then selecting the Log On option. This displays a Log On window that allows you to log on to either one specific ClearSCADA database or all of the offered ClearSCADA databases at the same time.
  • By right-clicking on the system icon in the Database Bar and selecting the Log On option from the context sensitive menu. This displays the Log On window for a single system (there is no System option).
  • Selecting the Log On option from any other display, for example, from a Mimic that provides a hyperlink to the Log On window for the system.
  2. When you have displayed the Log On window, you need to enter the following information:
  • System—This field is only available when you display the Log On window by selecting the File menu then Log On option on a system that provides access to Multiple Databases. You can choose to log on to one specific system or to log on to All Systems simultaneously. (The field’s drop-down list comprises the ClearSCADA systems (databases) to which the ViewX client has access.)

When logging on to multiple systems, ClearSCADA attempts to log you on to all of the systems (databases) to which it has access, using the same username and password. If the username and password are not valid for a system, a diagnostic message is displayed. You will need to log on to that system individually.

  • Username—Enter your unique username. This is the username that has been configured for your user account.

If your system is configured to use the Windows delegated log on feature, your user name for ViewX will be the same as your Windows user name.

  • Password—Enter the password for your user account. If you are unsure of the password, please contact a system administrator.

If your system is configured to use the Windows delegated log on feature, your password for ViewX will be the same as your Windows password. For more information on the Windows log on feature, see Using Windows User Authentication with ClearSCADA in the ClearSCADA Guide to Security.

If you attempt to log on to multiple systems (databases) simultaneously and use a password that has expired on one or more of the systems, the Change Password window is displayed. You will need to change the password (see Change your Password via ViewX). The new password is applied to your user account on all systems on which your user account exists and to which the ViewX client has access. The password expiry times begin again starting from the time you set the new password (see Define the Default Security Settings for New User Accounts).

On a ViewX workstation on which the On-Screen Keyboard feature is enabled, a QWERTY keypad is displayed whenever the Username or Password fields are selected. Use either a traditional keyboard or Use the QWERTY Touch Screen Keypad to enter your Username and Password.

  3. Select the OK button.
    The Log On window is closed and you are logged on to the selected system(s).

The systems to which you are logged on are shown in the Status Bar. If you use the same username to log on to all of the systems offered, the Status Bar displays that username. If you use different usernames to log on to different systems, or only log onto one particular system, the Status Bar indicates which username applies to which system, in the format:

<System1>: <Username1>; <System2>: <Username2>

Example:

NOTE: In the unlikely event that logging on causes unexpected ViewX behavior, you may need another user to reset the profile for your user account—see Reset Profile in the ClearSCADA Guide to Security.

ClearSCADA might be configured to allow you to log on to multiple ViewX sessions running on a single PC. This functionality is useful with multi-head setups (see Set Multiple Heads to Log On Automatically when a User Logs on to Head 1 in the ClearSCADA Guide to Client Administration).

To log on to a particular ClearSCADA system:

  1. Either:
  1. Select the File menu.
  2. Select the Log On option.
    The Log On window is displayed.
  3. Select the System you want to log on to from the combo box.

Or:

  1. Right-click on the System Icon [image] on the Explorer Bar for the system you want to log on to.
    A context sensitive menu is displayed.
  2. Select the Log On option.
    The Log On to system window is displayed.

NOTE: Instead of this logon option, your system may open a Log On Mimic where you enter your Username and Password.

  2. Enter your user identity in the Username field.
    Your user identity is the name of the user account that you use to log on. Typically, this will be your own name.
  3. Enter your password in the Password field. The password is defined when the user account is configured.

If you do not know what your password is, please contact a higher level user.

  4. Select the OK button.
    The logon window is closed and you are logged on to the system.

NOTE: In the unlikely event that logging on causes unexpected ViewX behavior, you may need another user to reset the profile for your user account—see Reset Profile in the ClearSCADA Guide to Security.

Further Information

Log Off from ViewX.

Change your Password via ViewX.


ViewX and WebX Clients Guide - Log Off from ViewX (ViewX Client)

Log Off from ViewX

You should log off from ViewX when you finish work, or if you will be leaving the system unattended.

You can log off from all of the ClearSCADA systems (databases) to which you are connected, or just one system.

Your user account may also be configured to log off after a period of user inactivity.

To log off from all systems on to which you are logged:

  1. Select the File menu.
  2. Select the Log Off option.

To log off from a particular system:

  1. Right-click on the System Icon [image] on the Explorer Bar for the system you want to log off from.
    A context sensitive menu is displayed.
  2. Select the Log Off option.


ViewX and WebX Clients Guide - Change your Password via ViewX (ViewX Client)

Change your Password via ViewX

It is important that your user password is kept secret. If another user logs in using your password, any actions they perform will be logged against your name. If you think that your password is not secret, you should change it.

You have to be logged on to ClearSCADA to change your password (see Log On to ViewX). You can only change your password if your user account has the Can Change Password feature enabled and is not authenticated via Windows.

If your system has a password expiry time and the expiry time is reached, you will be prompted to enter a new password the next time you log on (the Change Password window is displayed). This also applies if your setup has multiple systems (databases) and your password has expired on any of the systems. When you enter new password, the password is applied to all of the systems on which your user account exists and to which the ViewX client has access. Any expiry times are re-started from the time you set the password.

To change your user password when you are logged on to ClearSCADA:

  1. Select the File menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Change Password option.
    The Change Password window is displayed.

(You can also display the Change Password window by selecting the Change Password option from your user account’s context sensitive Object Menu. You can display the menu from, for example, your user account’s entry in the Database Bar.)

  3. Enter your existing password in the Old Password field (this is only required if your user account does not have the Security permission for the User item. If your user account does have the Security permission for the User item, the Old Password field is ‘grayed out’ and unavailable for use).
  4. Enter your new password in the New Password field. The field is case sensitive.
  5. Enter the new password again in the Confirm Password field.
  6. Select the OK button to confirm the change, or the Cancel button to abort the change.

Further Information

Change your Password via a WebX Client.

Windows User Authentication: see the ClearSCADA Guide to Security.


ViewX and WebX Clients Guide - The ViewX Window (ViewX Client)

The ViewX Window

When you run ViewX, the window typically contains the following components:

Document Display Area
Toolbars
Menus in the ViewX menu bar
Explorer Bar
Alarm Banner
Status Bar

The Alarm Banner informs you about any existing or recent alarms on the system. You navigate the system using the menus, toolbar buttons, and Explorer Bar. You view the displays you require in the document display area. The Status Bar provides information on the status of the system and user activity.

For more information on these components, see the following sections:

  • Menus
  • Toolbars
  • Explorer Bar (see Explorer Bars used in ViewX)
  • Document Display Area
  • Alarm Banner (see Alarm Banner in the ClearSCADA Guide to Alarms)
  • Status Bar.


ViewX and WebX Clients Guide - Menus (ViewX Client)

Menus

The menus are displayed in the ViewX menu bar at the top of the ViewX window. The menus provide access to a variety of options. To access any of the options, use the mouse to select the required menu, then position the cursor over the required option and select it.

The menus and the options that they contain vary according to your security level and the type of display currently selected in the Document Display Area. For example, the following menu options might be shown when a Mimic is on display:

When you select a menu, a drop-down list of options is displayed. These options provide access to a variety of features.

Some options on the menus provide access to a further menu.

Individual menu options are explained in the relevant sections.

Do not confuse the menus that are available from the ViewX menu bar with the context sensitive menus that are available from Explorer Bars and displays such as Mimics and Lists (see Object Menu).


ViewX and WebX Clients Guide - Toolbars (ViewX Client)

Toolbars

Toolbars are sets of icons that you can use to access specific features. Typically, they provide fast access to the same features that are associated with options in the menus. You need to be familiar with the different toolbar icons to use ViewX effectively. To access one of the features via a toolbar, simply select the relevant option.

There are three types of controls available on toolbars:

  • Instant Action—Clicking on the toolbar button causes the action to be performed immediately, for example Zoom In and Zoom Out.
  • Select/Deselect—Clicking on the toolbar button causes the button to change between Active and Inactive states. While Active, the toolbar button will appear depressed, and causes a continuous effect, for example selecting Pan button causes the mouse cursor to change from ‘Click to Select’ to ‘Click and Drag to Pan Mimic’.
  • List Boxes—Clicking on the toolbar list box will display a list of options. Selecting an option will cause an action in the same manner as an instant action toolbar button.

The ViewX operator-level user toolbars are:

  • File (see File Toolbar)
  • Operate (see Operate Toolbar)
  • Navigate (see Navigate Toolbar).

Other toolbars are available to higher-level users. For information on the Mimic toolbar, see Mimic Editing Toolbar in the ClearSCADA Guide to Mimics. For information on the Alignment toolbar, see Alignment Toolbar in the ClearSCADA Guide to Mimics. For information on the functions available from the Debug toolbar, see the ClearSCADA Guide to Logic, and the ClearSCADA Guide to Scripting.

To display and hide any of the toolbars to which your user account provides access:

  1. Either:
  1. Select the View menu.
  2. Select the Toolbars option.
    A context-sensitive menu is displayed.

Or:

  • Right-click on the toolbar, menu or status bar area.
    A context-sensitive menu is displayed.
  2. Either:
  • Select the option(s) for the toolbar(s) that you want to display. For example, select the File, Operate, and Navigate options if you want to display the File, Operate, and Navigate toolbars respectively.

Or:

  • Deselect the option(s) for the toolbar(s) that you want to hide. For example, deselect the Navigate option to hide the Navigate toolbar.


ViewX and WebX Clients Guide - File Toolbar (ViewX Client)

File Toolbar

You will mostly use the File toolbar to print the current window. Other functions apply to users with higher security permissions.

(If the File toolbar is not available, you can use the Print button on the Operate Toolbar.)


ViewX and WebX Clients Guide - Operate Toolbar (ViewX Client)

Operate Toolbar
1
2
3
4
5
6
7

The Operate toolbar contains buttons that allow you to navigate forward and backward between Mimics, display Alarms and Events Lists, and change the Explorer Bar.

The buttons on the Operate toolbar are:

  1. Back / Forward—Back displays the previously shown display, such as a Mimic, after you navigate between displays using a hyperlink. After clicking on Back, you can then click on Forward to view the display that was shown before you clicked on Back. You can use the Back and Forward buttons, for example, to navigate backwards through multiple Mimics and then navigate forward to the original Mimic.
  2. Home—Only available if a Home Page is configured for the currently logged-on user (or the Guest user if no user is logged on). Select this button to display the default ‘file object’, such as a custom Mimic, that is configured as the Home Page. For more information, see Define the Homepage Settings for a User in the ClearSCADA Guide to Security.
  3. Alarms—Displays a list of the current alarms on your ClearSCADA system(s). The entries in the List are restricted to those alarms to which the ViewX client and your user account have access. For more information, see Alarms Lists in the ClearSCADA Guide to Alarms.
  4. Events—Displays a list of the events on your ClearSCADA system, over a defined time period. The entries in the List are restricted to events associated with those items to which the ViewX client and your user account have access. For more information, see Events.
  5. Explorer Bars—This set of buttons allows you to display (or close) the Explorer Bars (such as the Favorites Bar, and Database Bar) to which your user account provides access. These are explained in detail in Explorer Bars used in ViewX.
  6. Print—This control allows you to print the current window, for example a Mimic, List, Report, or Trend. When printing a List, the entire List will be printed (not just the viewable section of the List).
  7. Toggle Full Screen—Displays ViewX as full screen. When in Full Screen mode, the following are not displayed:
  • ViewX menu bar
  • Explorer bar
  • Status bar
  • Application window frame (title bar, and so on).

This option provides more viewable area for the display of Mimics, but does not allow you to access functions via the ViewX menu bar or Explorer bar. Full screen mode can be toggled using the F11 key.


ViewX and WebX Clients Guide - Navigate Toolbar (ViewX Client)

Navigate Toolbar
1
3
4
5
6
7
2
8

The Navigate toolbar provides quick access to functions that allow you to navigate Mimics, Trends, and historic Lists.

The buttons on the Navigate toolbar are:

  1. Zoom—Use this button to select or specify a specific Mimic Zoom level.
  2. Zoom In / Zoom Out—Use these buttons to increase or decrease the Zoom Level of the Mimic.
  3. Zoom Box—Use this button to zoom into a specific area of a Mimic by drawing a Zoom Box around the area.
  4. Pan—If the Mimic is larger than the main display area at the current zoom level, use this button to change which area of the Mimic is visible.
  5. Zoom Lock—Use this button to return the Mimic to its default zoom level. The Zoom Lock turns off automatically if you zoom in or out again.
  6. Navigator—Use this button to pan the Mimic using a smaller context sensitive window.
  7. View—This combo box lists any Defined Views that have been configured for your Mimic, for example a view that is zoomed in on a particular area of the Mimic. Select the required view from the list.
  8. Previous / Next—Use these buttons to either:
  • Scroll a selected Trend forward and backward.
  • Display the records for the previous or next time intervals on an Events List, or Historic List.


ViewX and WebX Clients Guide - Document Display Area (ViewX Client)

Document Display Area

The ViewX document display area is the main part of the ViewX interface and is where the ViewX displays are shown. These include:

  • Mimics—Graphical displays that usually show dynamic representations of plant and provide access to the actions and controls that you will need to perform your tasks (see Mimics).
  • Trends—Displays that plot the values of points on a Trend with an x-axis and at least one y-axis. These displays are used to compare values over periods of time and to determine patterns in the data, for example determine at what times a point’s value is high (see Trends).
  • Lists—Lists that you can use to display specific items and their various property values. The Lists provide access to the actions and controls that you will need to perform your tasks, and also allow you to compare various different values (see Lists).

Typically, you will perform many of your tasks from Mimics, Trends, and Lists that are shown in the ViewX document display area.

ViewX document display area showing a Mimic

You can change the size of the ViewX document display area by selecting the left-hand side or bottom boundary and dragging it. This either increases or decreases the height or width of the ViewX document display area—the Explorer Bar and Alarm Banner are resized accordingly. (Your user account permissions may not allow resizing of the Alarm Banner.)


ViewX and WebX Clients Guide - Status Bar (ViewX Client)

Status Bar

The status bar is typically displayed at the bottom of The ViewX Window.

System status.
Current user.
Display-specific details.
System event.
Current time (optional).

The status bar displays:

  • System status information—When you place the cursor over an animated area of a Mimic, for example, a description is typically displayed, indicating the action that will occur should you select that animated area.
  • Current user name—The name of the user that is currently logged on to that particular ViewX client.
  • Specific details relevant to the current display—For example:
  • On a List display, this section of the Status Bar shows the number of the currently selected row
  • On a Mimic being shown in Design mode, the area shows the co-ordinates of the cursor position
  • On a configuration Form, the area shows the selected field’s name and type. (A field’s name often differs from its ‘display name’—the name that is shown on the configuration Form in the language determined by the user’s Locale.) Higher level users can use this part of the Status Bar to ascertain a field’s details, as an alternative to using the database Schema. The details can then be specified where required—for example in Queries or Scripts.
  • System event details—By default, the status bar shows condition events (events relating to alarms) and tracking events (events relating to user interaction with the system).

The status bar can also be set to display simple events such as point state changes. However, we do not recommend that you enable this feature as it may cause slow system performance (as your system may have thousands of simple events). For more information, see Specify Whether Simple Events are Displayed in the Status Bar in the ClearSCADA Guide to Lists.

The Status Bar can also be set to display the current time. This feature can be enabled by a user whose user account provides access to the Options window (see Add a Clock to the Status Bar on a ViewX Client in the ClearSCADA Guide to Client Administration).

The status bar is shown at the bottom of the ViewX display by default, but you can hide or re-display it as required:

  1. Either:
  1. Right-click on the toolbar, menu area or the status bar.
    A context sensitive menu is displayed.
  2. Select or deselect the Status Bar option.

Or:

  1. Select the View menu.
  2. Select or deselect the Status Bar option.
    The status bar will display or be hidden.


ViewX and WebX Clients Guide - WebX Client

WebX Client

A ClearSCADA WebX Client is a type of ClearSCADA Client that allows you to connect to your ClearSCADA database from any location, whether on your normal site or off-site. Unlike a ViewX client, a WebX client uses a web browser—such as Microsoft® Internet Explorer 6 or above—to access your system via a web interface. This can be used to enable you, for example, to access your system remotely from a laptop that has Internet Explorer and the ViewXCtrl ActiveX control installed (along with the necessary hardware to provide remote access via the Internet).

A WebX client provides access to many of the same features and functions as a ViewX Client, with minor differences in the interface’s appearance and the way in which some functions are accessed.

The WebX client provides sufficient functionality for operator tasks, but not the advanced features required to make modifications to the ClearSCADA database. A WebX client can be used to perform control actions such changing set points, but cannot be used to configure items in the database.

For more information on the WebX client, refer to these sections:

  • Differences Between the WebX Client and ViewX
  • Run a WebX Client
  • Understand the WebX Interface
  • Browse your Database on a WebX Client
  • Use the WebX Interface.


ViewX and WebX Clients Guide - Differences Between the WebX Client and ViewX (WebX Client)

Differences Between the WebX Client and ViewX

Many of the functions and displays that are available from a ViewX client are also available from a WebX client—see the other sections of this guide for more detail:

  • ViewX Client
  • Object Menu
  • Alarms
  • Events
  • Mimics
  • Lists
  • Trends
  • Reports
  • Status Displays
  • Operator Document Stores.

The differences in how you use a WebX client compared with ViewX mostly relate to how you access items and functions.

The main differences between a WebX client and ViewX are:

  • A WebX client provides operator, rather than configuration, access to the system. (Engineers have to use a ViewX client to make any configuration changes.)
  • A WebX client can only display one window at a time (it cannot display inset windows as pop-ups as in ViewX). Any inset windows are displayed using the entire main display area and you use the Back navigation button to return to the previous screen.
  • A WebX client can only connect to one server at a time.

On ClearSCADA systems that have:

  • Multiple Databases

and:

  • Contain Mimics that include hyperlinks to displays on other ClearSCADA databases

WebX can navigate between the servers that run those databases and therefore display the other display(s) successfully. However, WebX cannot access multiple servers simultaneously. As such, in order for all of the ‘live’ data on a Mimic to update correctly in WebX, all of that data has to be sourced from the same ClearSCADA database as that on which the Mimic itself is located.

Cross-database hyperlink support is possible providing that:

  • The WebX client can obtain a network connection to each server (connecting to one server at a time)

and:

  • The relevant Cross-Database Hyperlinks settings have been configured on each of those servers (see Define the Cross-Database Hyperlinks Settings in the ClearSCADA Guide to Server Administration).
  • Alarms are displayed using a dedicated screen on a WebX client.
  • Audible alarms are not supported on a WebX client.
  • Events are displayed using a dedicated screen on a WebX client.
  • Lists are displayed using a dedicated screen on a WebX client.
  • A WebX client can display the latest generated version of a report, providing that specific criteria are met. This includes the report being made available for display in WebX. For more information, see View the Most Recently Generated Version of a Report on a WebX Client in this guide, and see the ClearSCADA Guide to the Crystal Reports Driver.
  • A WebX client does not have the ViewX toolbars. For displays such as Trends and Mimics the WebX client provides access to options such as Zoom and Pan via a context-sensitive menu. Access the menu by right-clicking on the main display area.
  • A WebX client cannot display the Explorer Bars. Equivalent Database Bar functionality is provided via the Database button. Equivalent Queries Bar functionality is provided via the Lists button.
  • A WebX client can only display single windows that have been saved as Favorites. (Any Favorites that comprise multiple windows, or multiple windows and inset windows, are excluded from the Favorites list in WebX.)

Further Information

Run a WebX Client.


ViewX and WebX Clients Guide - Run a WebX Client (WebX Client)

Run a WebX Client

To run a WebX client:

  1. Either:
  1. Select the Start button.

    The Windows Start menu is displayed.
  2. Select the All Programs option.
  3. Select the Internet Explorer option.

Or:

  • Double-click on the Internet Explorer desktop shortcut

Internet Explorer is displayed.

  2. Enter the address for your ClearSCADA server in the Address field, in one of these formats:

http://<name_of_server>
http://<name_of_server>:<port_number>
https://<name_of_server>
https://<name_of_server>:<port_number>
Where <name_of_server> is the node name of your web server (you may also use its IP address), and <port_number> is the port used by the server. Use the “https” address if your server uses secure http. If the web server is configured to use the default port for its protocol (80 for http, 443 for https), omit the port number.

Your system administrator will be able to provide you with this information.

  3. Press the Enter key.
    Internet Explorer displays your WebX client home page.

A Default View, such as a custom Mimic, is displayed instead of the above image, if the Root Group on your system is assigned a Default View. Such a ‘file object’ might, for example, comprise an overview of your system. For more information, see Defining a Default View in the ClearSCADA Guide to Core Configuration.

To access ClearSCADA via WebX, you typically need to Log On to a WebX Client.


ViewX and WebX Clients Guide - System Security (WebX Client)

System Security

ClearSCADA security helps to protect the SCADA system from unauthorized access. System access requires a password. The actions that you perform as a user are logged by the system (see Events).

As a system user, you will be assigned access permissions according to the functions you need to perform, and you will only be able to see the functions that this makes available to you.

You will use a ViewX or WebX client (workstation) that has been configured by a higher level user. The client and your user account should provide access to the displays and features that you need to carry out your tasks, such as performing actions on database items and managing alarms.

System security allows you to:

  • Log On to a WebX Client
  • Log Off from a WebX Client
  • Change your Password via a WebX Client.


ViewX and WebX Clients Guide - Log On to a WebX Client (WebX Client)

Log On to a WebX Client

As with ViewX, you typically need to log on to a WebX client before you can interact with ClearSCADA. You will usually be able to log on using the same user details that you use to log on to ViewX, as long as that user account provides Web access.

To log on to a WebX client:

  1. Select the Log On button on the WebX client banner.

    The Log On page is displayed.
  2. Enter your user name and password in the Username and Password fields.
  3. Select the Log On button.
    You are now logged on to the system. Your username is shown at the bottom of the WebX client.

The WebX client displays your home page. If none is configured for your user account, the WebX client displays the page you were viewing before you logged on.

Your user account’s configuration determines the menu buttons that are available from WebX’s navigation banner.

Further Information

Run a WebX Client.

Understand the WebX Interface.

Change your Password via a WebX Client.

Log Off from a WebX Client.


ViewX and WebX Clients Guide - Log Off from a WebX Client (WebX Client)

Log Off from a WebX Client

After you Log On to a WebX Client, the Log On button changes to display Log Off.

To log off a WebX client:

Select the Log Off button in the WebX client banner.


ViewX and WebX Clients Guide - Change your Password via a WebX Client (WebX Client)

Change your Password via a WebX Client

It is important that your user password is kept secret. If another user logs in using your password, any actions they perform will be logged against your name. If you think that your password is not secret, you should change it.

You have to be logged onto ClearSCADA to change your password (see Log On to a WebX Client). You can only change your password if your user account has the Can Change Password feature enabled and is not authenticated via Windows.

To change your password via a WebX client:

  1. Select your User Name at the bottom of the WebX interface.
    Select your User Name.

    The Change Password page is displayed.
  2. Enter your Old Password, followed by your New Password. Both fields are case sensitive.
  3. Confirm the spelling and capitalization of your new password by entering it in the Confirm Password field.
  4. Select the Change Password button to confirm the change.

For more information about changing your password, see Change your Password via ViewX.


ViewX and WebX Clients Guide - Understand the WebX Interface (WebX Client)

Understand the WebX Interface

The WebX interface consists of two parts:

  1. A navigation banner with a row of buttons at the top of the window.
  2. A main display area below the buttons.
    Main Display Area
    Navigation Banner

The WebX interface navigation banner contains a number of buttons that you use to access your system. You select a button to access the next page or display for that particular feature. The buttons that are shown vary, depending on the access assigned to your user account, but comprise a combination of the following:

  • Home—Select this button to display your ClearSCADA home page. This is equivalent to the Home button on the ViewX Operate toolbar (see Toolbars).
  • Database—Select this button to display the System web page or default views that provide hyperlinks to the groups and items in your system. This is equivalent to the Database Bar. You can view an item’s properties (see View an Item’s Status on a WebX Client). You can display Mimics, Trends, and so on, in the main display area (see Browse your Database on a WebX Client).
  • Documents—Select this button to access your operator document stores. This is equivalent to accessing your documents via the Operator Documents Bar in ViewX (see Access Your Operator Document Stores on a WebX Client).
  • Alarms—Select this button to display a list of the current alarms on your system, automatically refreshed every 5 minutes. You can use the Alarms List to view and manage Alarms (equivalent to the Alarms button on the ViewX Operate toolbar). For more information, see View and Action Alarms on a WebX Client.)
  • Events—Select this button to display a list of the events on your system (equivalent to the Events button on the ViewX Operate toolbar). For more information, see View and Action Events on a WebX Client.)
  • Lists—Select this button to display the Lists web page, which provides hyperlinks to the Lists in your system. This is equivalent to the Queries Bar in ViewX. You can use the Lists to view the values of items of the same type, for example, view the values of the points on your system. For more information, see View and Action Lists on a WebX Client.
  • Favorites—Select this button to access your Favorites list. This is equivalent to accessing your Favorite displays from the Favorites menu or Favorites Bar in ViewX. As WebX is only able to display one window at a time, any Favorites that comprise multiple windows, or windows and inset windows, will be omitted from the Favorites list in WebX.
  • Diagnostics—Select this button to display information about the performance of your system. The diagnostics information is especially useful to Schneider Electric’s support personnel. The Diagnostics button provides WebX access to the ClearSCADA Server Status Tool. For details about the diagnostics information that can be accessed by users with the relevant security permissions, see Access Server Status Information from a WebX Client in the ClearSCADA Guide to the Server Status Tool.
  • Log On/Log Off—Select this button to display the log on page, which allows you to log on to your system or log off via the WebX client. This is equivalent to logging on via the File menu or the Database Bar’s system icon in ViewX (see Log On to a WebX Client).


ViewX and WebX Clients Guide - Browse your Database on a WebX Client (WebX Client)

Browse your Database on a WebX Client

The ClearSCADA web interface allows you to browse your ClearSCADA system’s database.

To browse the ClearSCADA database:

  1. Select the Database button
    on the WebX client banner.
    The top level of the ClearSCADA database hierarchy is displayed.

Example:

If a Default View is configured for the Root Group on your system, an additional entry is included at the top of the main display area.

Example:

  2. Either:
  • Use the WebX Interface to access the different levels of your database.

or:

  • (If applicable) select the ‘Display Default View’ hyperlink to display the Mimic or other ‘file object’ that is configured as the Root Group’s Default View. Such a view is typically produced as an aid to navigating your database and might, for example, comprise an overview of your system.


ViewX and WebX Clients Guide - Use the WebX Interface (WebX Client)

Use the WebX Interface

This section applies if your system is not customized to use default views.

You can use the links on the database web page (see Browse your Database on a WebX Client) to access different levels of the database—the database web pages correspond to the various levels in the Database Bar tree-structure in ViewX (see Database Bar).

Select the hyperlink in the Parent section to display the group that contains the item that you are currently viewing.
Select a hyperlink in the Children section to display further information about the selected item, or access another display or group.

The Parent group links to the group above the item or page that you are viewing.

The Children group contains items that are part of the group that you are viewing, for example points or Mimics that are part of a group.

You can perform these actions on a WebX client:

  • Follow a hyperlink—The mouse cursor will change to a pointing finger [image] when it is over a hyperlink. Select the hyperlink. A new web page is opened, replacing the one that you were viewing.
  • Move to the level above on the tree—Select the parent group hyperlink.
  • Open a Group—Select the group name hyperlink.

The Web browser remembers the order in which you have viewed WebX pages. The browser should provide buttons that allow you to move back and forth between the pages that you have been viewing. For example, Windows® Internet Explorer® 7 allows you to:

  • View the previous page by selecting the Back button
  • Select the Forward button [image] to reload the next page in your viewing sequence.

Specific actions you can perform on a WebX client include:

  • View an Item’s Status on a WebX Client
  • View a Mimic on a WebX Client
  • Adjust the Magnification of a Mimic on a WebX Client
  • Use the Object Menu on a Mimic on a WebX Client
  • Use Custom Hyperlinks on a Mimic on a WebX Client
  • Access Your Operator Document Stores on a WebX Client
  • View and Action Alarms on a WebX Client
  • View and Action Events on a WebX Client
  • View and Action Lists on a WebX Client
  • View and Action Trends on a WebX Client
  • View the Most Recently Generated Version of a Report on a WebX Client.


ViewX and WebX Clients Guide - View an Item's Status on a WebX Client (WebX Client)

View an Item’s Status on a WebX Client

To view an item’s status:

  1. Navigate to a database web page that contains an item hyperlink (see Use the WebX Interface).
  2. Do one of the following:
  • Select the ‘View Status’ hyperlink. Such a hyperlink exists for items such as Mimics and Trends.
  • If the item is a database item such as a point or outstation, select the item’s name. The name forms a hyperlink on the WebX client.

(For example, with the above database, you might select the ‘Schedule11’ hyperlink, to view the status of that Schedule.)

The item’s Status display is shown.

When you have finished viewing the status information, return to the previously displayed web page by selecting the hyperlink in the Parent section, or the Back button at the top of the browser window.

For more information, see Status Displays.


ViewX and WebX Clients Guide - View a Mimic on a WebX Client (WebX Client)

View a Mimic on a WebX Client

You can display a Mimic on a web page and use it to operate your system in the same way as you would use a Mimic in ViewX.

To view a Mimic on a WebX client:

  1. Navigate to a database web page that contains a Mimic hyperlink (see Use the WebX Interface).
  2. Do one of the following:
  • Select the hyperlink that indicates the Mimic’s name. (For example, with the above database, you might select the ‘Regional Overview’ hyperlink.)
  • If a Group or Group Instance is configured to have an Alarm View, select the Display Alarm View hyperlink in order to display that view. This hyperlink is equivalent to the Display Alarm View option or pick action.
  • If the Group or Group Instance is configured to have a Default View, select the Display Default View hyperlink in order to display that view. This hyperlink is equivalent to the Display Help View option or pick action.

(An Alarm View or Default View can comprise any ‘file object’, such as a Trend or Mimic.)

The Mimic web page is displayed.

Mimic Name

You can also display an Alarm View or Default View in WebX by displaying a suitable List, right-clicking on the required entry on the List and selecting the Display Alarm View or Display Default View option. (The latter option is only available from a Group or Group Instance database item, providing that item is configured to have a Default View.)

Activities that you can undertake while a Mimic is on display include:

  • Adjust the Magnification of a Mimic on a WebX Client
  • Use the Object Menu on a Mimic on a WebX Client
  • Use Custom Hyperlinks on a Mimic on a WebX Client.

For more information on using Mimics, see the ClearSCADA Guide to Mimics.


ViewX and WebX Clients Guide - Adjust the Magnification of a Mimic on a WebX Client (WebX Client)

Adjust the Magnification of a Mimic on a WebX Client

You can use Zoom tools to change how you view a Mimic on a web page in the same way as you would use a Mimic in ViewX.

To zoom a Mimic on a WebX client:

  1. Right-click on a blank area of the Mimic.
    A context sensitive menu is displayed.

Select the required option:

  • Zoom Lock—This option allows you to return the Mimic to its default zoom level. The Zoom Lock turns off automatically if you zoom in or out again.
  • Zoom In—Select this option to magnify the Mimic in default increments.
  • Zoom Out—Select this option to reduce the magnification of the Mimic in default increments.
  • Zoom—Use this option to display a submenu from which you can select the level to which you want to magnify the Mimic.
  • Size To Picture—Use to set the Mimic to a level of magnification that displays the entire Mimic at the maximum size in the available space. The aspect ratio of the Mimic is maintained.
  • Size To Content—Use to set the Mimic to a level of magnification that displays the content of the Mimic at the maximum size in the available space. This differs to the Size to Picture option as it disregards the borders of the Mimic, and sizes the Mimic according to the items it contains.
  • Zoom Box—Select this option to magnify a selected part of the Mimic.
  • Pan—Select this option to move across the Mimic, so that a different section of the Mimic is displayed in the Mimic window.
  • Print—Select this option to send a copy of the Mimic to a printer.

These functions operate in the same way as Zoom functions for Mimics in ViewX (see Operating a Mimic in the ClearSCADA Guide to Mimics).

As with ViewX, if you have a mouse that has a wheel, you can also use the wheel to change the level of magnification on the Mimic.


ViewX and WebX Clients Guide - Use the Object Menu on a Mimic on a WebX Client (WebX Client)

Use the Object Menu on a Mimic on a WebX Client

You can select an item on a Mimic to display a context-sensitive menu that provides access to various options or other displays, in the same way as the ViewX Object Menu.

To use the Object menu on a Mimic on a WebX client:

  1. Select an item on the Mimic.

Providing that the item is configured to provide access to an Object menu, a context sensitive menu is displayed.

The menu options that are displayed vary, depending, for example, on the type of item, its configuration, and current status

Example:

For more information, see Object Menu Options.


ViewX and WebX Clients Guide - Use Custom Hyperlinks on a Mimic on a WebX Client (WebX Client)

Use Custom Hyperlinks on a Mimic on a WebX Client

Your system may include Mimics that have been configured with custom hyperlinks that, when selected, either:

  • Replace the existing display with that of another display, such as another Mimic, Trend, or List

or:

  • Display a ‘custom’ pick action menu that provides access to other items, displays and/or options.

Example:

A pump on a Mimic is configured to display a ‘custom’ pick action menu.

A user selects the pump on the Mimic. The ‘custom’ pick action menu is displayed.

The user selects the required option. In this particular case, the Faceplate option.

The current Mimic display is replaced with one that shows specific status information about the database item, similar to that shown in ‘standard’ Status Displays.

For more information on custom hyperlinks, see the ClearSCADA Guide to Mimics.


ViewX and WebX Clients Guide - Access Your Operator Document Stores on a WebX Client (WebX Client)

Access Your Operator Document Stores on a WebX Client

Your user account can be associated with up to six Operator Document Stores.

To access your Operator Document Stores from a WebX client:

  1. Log on to WebX (see Log On to a WebX Client).
  2. Select the Documents button
    on the WebX client banner.

The top level of your Operator Document Stores is displayed.

  3. Navigate the hierarchy as you would the ClearSCADA database, to locate the document you require (see Use the WebX Interface).

For example:

  • Select a hyperlink in the Children section to access an operator document, or another level of your Operator Document Stores hierarchy.

or:

  • Select the hyperlink in the Parent section to display the group that contains the item or page you are currently viewing.
  4. Select the hyperlink that indicates the required document’s name.
    The selected Operator Document is displayed.


ViewX and WebX Clients Guide - View and Action Alarms on a WebX Client (WebX Client)

View and Action Alarms on a WebX Client

You can use the WebX client to display Alarms Lists. Be aware that the entries in the Alarms Lists are restricted to those alarms to which the WebX client and your user account have access.

To display a list of the alarms to which you have access on a WebX Client:

  1. Select the Alarms button
    on the navigation banner.
    The Alarms List is displayed, showing the current alarms on the ClearSCADA database to which the WebX client is connected.

To display a list of the alarms for a particular Group, Group Instance, or database item:

  1. Either:
  1. Display a Queries List.
  2. Right-click on an item that is in an alarm state on the List.
    A context sensitive menu is displayed.

or:

  1. Display an appropriate Mimic.
  2. Select an item that is configured to display a context sensitive menu and is in an alarm state.
  2. Select the Display Alarms option.
    The Alarms List is displayed. The entries in the List are pre-filtered to only include alarms for the selected item, Group, or Group Instance.

As with other Lists in WebX and ViewX, you can perform various activities on the List, such as sorting the List columns, and filtering the List entries.

Right-click on an entry in the Alarms List to display the context sensitive menu that enables you to perform actions on the List or on the selected entry on that List.

Example:

Alarm-specific options.
Generic Alarms List options.

The options that are displayed vary, depending, for example, on your security permissions. Many of the options are identical to those that are available from an Alarms List on a ViewX client.

For information on the alarm-specific options, see Perform an Action on an Alarm in the ClearSCADA Guide to Alarms.

For information on the generic Alarms List options, see Alarms Lists in the ClearSCADA Guide to Alarms.

This additional option is displayed when you access the menu on a WebX client:

  • Print—Send the contents of the Alarms List to a printer.


ViewX and WebX Clients Guide - View and Action Events on a WebX Client (WebX Client)

View and Action Events on a WebX Client

You can use a WebX client to display Events Lists. Be aware that the entries in the Events Lists are restricted to events for items to which the WebX client and your user account have access.

To display a list of the events to which you have access on a WebX Client:

  1. Select the Events button
    on the navigation banner.
    The Events List is displayed. The List displays the events that have occurred on the ClearSCADA database to which the WebX client is connected, for the time period defined by your user account’s Event List Range.

To display a list of the events for a particular Group, Group Instance, or database item:

  1. Either:
  1. Display a Queries List.
  2. Right-click on an item on the List.
    A context sensitive menu is displayed.

or:

  1. Display an appropriate Mimic.
  2. Select an item that is configured to display a context sensitive menu.
  2. Select the Display Events option.
    The Events List is displayed. The entries in the List are pre-filtered to only include events for the selected item, Group, or Group Instance.

As with other Lists in WebX and ViewX, you can perform various activities on the List, such as sorting the List columns, and filtering the List entries.

Right-click on an entry in the Events List to display the context sensitive menu that enables you to perform actions on the List or on the selected entry on that List:

Many of the menu options are identical to those that are available from an Events List on a ViewX client (see Events Lists in the ClearSCADA Guide to Lists).

These additional options are displayed when you access the menu on a WebX client:

  • Copy to Clipboard—Copies the Events List’s content to your PC’s clipboard. You can then paste the content into any application, such as Microsoft® Excel, that supports pasting from the clipboard.

A dialog is displayed should the Events List have a large number of rows. If this occurs, consider filtering the Events List’s content before pasting the filtered content to the clipboard.

  • Print—Send the contents of the Events List window to a printer.


ViewX and WebX Clients Guide - View and Action Lists on a WebX Client (WebX Client)

View and Action Lists on a WebX Client

You can use a WebX client to display Lists of database values.

To display Lists on a WebX client:

  1. Select the Lists button
    on the navigation banner.
    A hierarchical listing is displayed, indicating the various types of List that exist on your system.
  2. Select the required hyperlink entry in the Lists window.
    The Filter Columns window is displayed.
  3. Enter any filters you want to apply to the List (see Filter a List in the ClearSCADA Guide to Lists).
  4. Select the OK button.
    The List window is displayed.
  5. Right-click on a row in the List.
    A context sensitive menu is displayed.

Example:

Object menu options.
Generic Queries List options.

Many of the options are identical to those that are available from a List on a ViewX client.

The Object menu options vary depending, for example, on the type of item, its configuration and current status (see Object Menu Options).

For information on the generic Queries List options, see Display and Use Lists in the ClearSCADA Guide to Lists.

These additional options are displayed when you access the menu on a WebX client:

  • Copy to Clipboard—Copies the List’s content to your PC’s clipboard. You can then paste the content into any application, such as Microsoft® Excel, that supports pasting from the clipboard.

A dialog is displayed should a List have a large number of rows. If this occurs, consider filtering the List’s content before pasting the filtered content to the clipboard.

  • Print—Send the contents of the List window to a printer.


ViewX and WebX Clients Guide - View and Action Trends on a WebX Client (WebX Client)

View and Action Trends on a WebX Client

ClearSCADA supports several types of Trend (see Trends).

You can display a pre-configured Trend on a web page and use it to operate your system in the same way as you would use a pre-configured Trend in ViewX.

To view and action a pre-configured Trend on a WebX client:

  1. Navigate to a database web page that contains a hyperlink to a Trend item.
    Trend hyperlink.

  2. Select the Trend hyperlink.
    The Trend web page is displayed.

As with Trends in ViewX, you can right-click on the main area of the Trend, the Trend axes, or the Trend key to display context-sensitive menus that enable you to perform a variety of actions on the Trend. For more information, see Using Trends in the ClearSCADA Guide to Trends.

To display a ‘standard’ ad hoc Trend on a WebX client:

  1. Either:
  1. Display a suitable List, such as a Points List (see View and Action Lists on a WebX Client).
  2. Right-click on the entry for which you want to display a ‘standard’ ad hoc Trend.
    A context sensitive menu is displayed.

or:

  1. Display a suitable Mimic (see View a Mimic on a WebX Client).
  2. Select the item for which you want to display a ‘standard’ ad hoc Trend. (The item has to be configured to display a context sensitive menu that includes the relevant menu option(s).)
  2. To display a Trend of current data, select the Display Current Trend option.

To display a Trend of historic data (if historic data is available), select the Display Historic Trend option.

The Trend is displayed. If the Trend plots current data, it will show values from the time that the Trend was displayed.

If required, users with the relevant permissions can add ‘custom’ ad hoc Trends to ClearSCADA. You typically display a ‘custom’ ad hoc Trend by selecting a button or hyperlink on a Mimic (see Use Custom Hyperlinks on a Mimic on a WebX Client).


ViewX and WebX Clients Guide - View the Most Recently Generated Version of a Report on a WebX Client (WebX Client)

View the Most Recently Generated Version of a Report on a WebX Client

You can display the most recently generated version of a report on a WebX client providing certain criteria are met. This criteria includes making a report available for display in WebX. For more information, see the ClearSCADA Guide to Crystal Reports.

To display such a report on a WebX client:

  1. Either:
  1. Display an appropriate List, such as the Reports List (see View and Action Lists on a WebX Client).
  2. Right-click on the required entry in the List.
    A context sensitive menu is displayed.
  3. Select the Display option.

Or:

  1. Display a Mimic that contains a hyperlink to the required report (see View a Mimic on a WebX Client).
  2. Select the report hyperlink.
  3. If a context sensitive menu is displayed, select the Display option.

Or:

  1. Navigate the database to locate the report you require.
  2. Select the hyperlink that indicates the report name.
    (The hyperlink is only available is the report is enabled for display in WebX.)
    With reports that are enabled for display in WebX, you can display the most recently generated version of the report.
    With reports that are not enabled for display in WebX, you can only view the report’s Status display.

The most recently generated version of the report is displayed in printable Adobe® PDF format. (You have to use ViewX to display any reports that are stored historically—you can only view the latest generated version of a report on a WebX client.)

Further Information

For more information on reports, see Reports and see the ClearSCADA Guide to the Crystal Reports Driver.


ViewX and WebX Clients Guide - Explorer Bars used in ViewX

Explorer Bars used in ViewX

Explorer Bars provide more advanced functionality than the menus and toolbars. You can display any one of the Explorer Bars to which your user account has access. The selected Explorer Bar is displayed to the left of the ViewX document display area (see The ViewX Window).

Explorer Bar

Each Explorer Bar provides access to different types of data, such as individual database items, or ‘Queries’ (lists of data, such as the Points List). For more information, see:

  • Understanding the Explorer Bar Tree-Structure.
  • Working with Database Items.

Each of the Explorer Bars can be displayed or hidden via the Operate toolbar (see Display an Explorer Bar in ViewX). The currently active Explorer Bar is indicated by one of the buttons being depressed. (If none of the Explorer Bars are on display, none of the buttons are depressed.) Explorer Bars to which your user account does not have accessed are ‘grayed out’ and unavailable for selection.

You can access the Explorer Bars to which your account has access, via these buttons:

1
2
3
4
5
6
7

  1. Displays the Favorites Bar.
  2. Displays the Database Bar.
  3. Displays the Queries Bar.
  4. Displays the Operator Documents Bar
  5. Displays the Areas of Interest Bar (this button is only displayed if the Area of Interest feature is enabled on your system)
  6. Displays the OPC Data Bar.
  7. Displays the OPC Historic Data Bar.


ViewX and WebX Clients Guide - Display an Explorer Bar in ViewX (Explorer Bars used in ViewX)

Display an Explorer Bar in ViewX

To display an Explorer Bar, either:

  1. Select the View menu.
    A drop-down menu is displayed.
  2. Select the Explorer Bar option.
    A further menu is displayed.
  3. Select the relevant option to display the required Explorer Bar. (For example, select the Favorites option, in order to display the Favorites Bar.) Only the options for the Explorer Bars to which your user account has access are listed. A check mark shown in front of an option indicates the Explorer Bar that is presently on display.

Or:

  1. Right-click on either:
  • The menu bar area at the top of the ViewX window.
  • The toolbar area, above the ViewX work area.
  • The status bar area at the bottom of the ViewX window.

(For more information on the location of any of the above, see The ViewX Window.)

A context sensitive menu is displayed.

  2. Select the Explorer Bar option.
    A further menu is displayed.
  3. Select the relevant option to display the required Explorer Bar. (For example, select the Queries option, in order to display the Queries Bar.) Only the options for the Explorer Bars to which your user account has access are listed. A check mark shown in front of an option indicates the Explorer Bar that is presently on display.

Or:

  1. Select the relevant button on the Operate toolbar (see Explorer Bars used in ViewX). (For example, select the Database button, in order to display the Database Bar.)

The specified Explorer Bar is displayed.


ViewX and WebX Clients Guide - Understanding the Explorer Bar Tree-Structure (Explorer Bars used in ViewX)

Understanding the Explorer Bar Tree-Structure

The entries in each Explorer Bar are displayed in a hierarchical tree-structure.

At the top of the tree-structure on most Explorer Bars is the system that contains the items in a ClearSCADA database. The system is sometimes referred to as the Root. A System or Root Group is represented by this icon:

The icon is appended by the name that has been assigned to the database.

On ViewX clients that provide access to Multiple Databases, a separate System or Root Group is displayed for each database.

Items associated with a particular database are located either directly in the System or Root Group, or within other Groups in that System or Root Group. There may be multiple levels of Groups. Groups on most Explorer Bars are represented by this icon:

You can expand and collapse any of the group folders to view different levels of the hierarchy by selecting the plus (+) or minus (-) symbols that are displayed to the left of each group folder:

Select the plus icon next to the system name to reveal its contents
Select the minus icon next to an expanded folder to collapse the hierarchy so that the contents of the folder are hidden.

On ViewX clients that provide access to Multiple Databases, expand the System or Root Group that represents the database in which you are interested.

Within each group folder, different icons are used to represent the different items within the database. The icons are designed to help you identify the various types of item that exist in the database. For more information, see Working with Database Items.

When you have located the item in which you are interested, you typically right-click on that item to display a context sensitive menu. You then select an option from that menu to perform an activity associated with that item—for example, display a Trend, or view a Status Display. The options that are available vary, depending on the type of Explorer Bar, the type of item and the features and security permissions that are assigned to your user account.


ViewX and WebX Clients Guide - Working with Database Items (Explorer Bars used in ViewX)

Working with Database Items

Each database item shown in an Explorer Bar has an icon and a name.

Name
Icon

Typically, higher level users should have provided each item with a name that indicates what that item represents. For example a Mimic might be named ‘Overview’ to indicate that it provides an overview of a particular region (see Mimics).

Typically, a ClearSCADA system is organized so that it has Groups that contain the database items that represent the various displays, values, and plant. These groups can contain other groups to create a hierarchy.

Systems that have a modular structure might also contain Group Template s and Group Instance s. These are special types of group that are represented by Group folder icons of a different color. On such systems, some Explorer Bars might use these types of group folder:

  • Groups—These are folders that can contain ‘live’ database items (database items that represent actual components of the system, such as a digital input point). Groups are similar to folders in Windows in that they are used to contain items so that the database has a hierarchical ‘tree-structure’. For example, groups can be used to organize the database items into different categories, such as a group for the items in a functional area of a plant, or in a geographical region of a system.

Groups are represented by yellow folders.

  • Group Templates—These are folders that contain ‘model’ configuration. The items within Group Templates are not ‘live’. Instead, they are used as the basis for the configuration of items within Group Instances. If you are an operator-level user, the security settings on your system will typically not provide access to Group Templates, as you have no need to work with them.

Group Templates are represented by brown folders.

  • Group Instances—These are folders that contain ‘live’ items for which much of the configuration is inherited from a Group Template. You can work with items in a Group Instance in the same way as you work with items in a normal Group.

Group Instances are represented by green folders.

For detailed information on Groups, see Groups in the ClearSCADA Guide to Core Configuration.

For detailed information on Group Templates and Group Instances, see Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration.

Each database item is associated with a context sensitive menu, also referred to as an Object Menu, or sometimes action menu or pick action menu. You display an item’s menu by right-clicking on the item’s entry in an Explorer Bar.

The options that are available on the menu vary, depending, for example, on the type Explorer Bar, your user account settings, the type of item, its configuration and current status.

You can perform actions on individual database items within Group folders or Group Instance folders. On some Explorer Bars, such as the Database Bar, you can also perform actions on a Group or Group Instance—this means that the action is performed on each of the relevant items within that Group or Group Instance. For example, you can use the Acknowledge Alarms action on a Group folder to acknowledge alarms on every item in that folder that has unacknowledged alarms (see Perform an Action on an Alarm in the ClearSCADA Guide to Alarms).

Although you can access actions and controls from the Explorer Bar, operator-level users are more likely to access them from Mimics or Lists. Mimics are usually configured to provide access to the required actions and controls directly from the Mimic display.


ViewX and WebX Clients Guide - Favorites Bar (Explorer Bars used in ViewX)

Favorites Bar

The Favorites feature allows you to create and store links to those displays that you frequently use in your work. These links are stored in your Favorites List.

For example, by adding the Mimics, Lists, and Trends that you need to use on a frequent basis to your Favorites List, you can access those displays from the Favorites menu or Favorites Bar (see Add a ViewX Display to your Favorites List). You can also add web pages (see Add a Web Page to your Favorites List) and external documents (see Add an External File to your Favorites List) to your Favorites List.

Standard menu options that allow you to add items to your Favorites List and organize the entries in that List.
Menu options produced by adding items and folders to your Favorites List. Select one of these options to display a particular Favorite.
Favorites menu.

Your Favorites List is associated with your user account. As such, if you log on to ViewX via a different computer, your Favorites are still in place. It also means that other users who log on to the same PC do not have access to your list of Favorite displays.

Favorites Bar.
Favorites List. The displays and folders that you add to your Favorites are listed here.
Add and Organize buttons.

For information on how to display the Favorites Bar, see Display an Explorer Bar in ViewX.

Further Information

Update the URL of a Link in your Favorites List.

Add a Folder to your Favorites List.

Rename a Link or Folder in your Favorites List.

Delete a Link or Folder from your Favorites List.

Use the Organize Favorites Window to Organize your Favorites List.

Access and Display your Favorites.


ViewX and WebX Clients Guide - Database Bar (Explorer Bars used in ViewX)

Database Bar

The Database Bar is an Explorer Bar (see Explorer Bars used in ViewX). It provides access to the database items to which the ViewX client and your user account have access. The items are displayed in a hierarchical ‘tree’ structure that corresponds to the way in which your database is organized (see Understanding the Explorer Bar Tree-Structure).

Database items are contained within folders that correspond to the Groups, Group Templates, and Group Instances that are configured in the database. You can expand individual folders to display their contents, or collapse them to hide their contents.

Depending on your user account’s permissions, you can use the Database Bar to:

  • Manage Alarms
  • Perform actions and controls to manipulate an item, which may also manipulate the physical plant, depending on the type of item (see Object Menu)
  • View Lists or other displays that provide information about an item or group of items. For example, you might access the Alarms List, which will be pre-filtered so that it only shows alarms for the selected Group or item (see Alarms Lists in the ClearSCADA Guide to Alarms)
  • Configure items in the database (see Add an Item to the Database in the ClearSCADA Guide to Core Configuration).

To perform any of the above, right-click on the required item in the Database Bar to display a context sensitive Object Menu. The menu will provide you with options (‘pick actions’) to view or modify the selected item. For information on the options that are common to many database items, see Object Menu Options. For information on the options that are common to driver-specific items, see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.

An icon that displays a red cross in the Database Bar indicates an item that has invalid configuration (see Checking for Invalid Configuration in the ClearSCADA Guide to Core Configuration). Such an item will have a limited subset of menu options available from its context sensitive Object menu, as that item will not be ‘live’.

Further Information

Display an Explorer Bar in ViewX.


ViewX and WebX Clients Guide - Queries Bar (Explorer Bars used in ViewX)

Queries Bar

The Queries Bar is an Explorer Bar (see Explorer Bars used in ViewX). It provides access to Queries Lists such as the Points List (see Lists) and uses a hierarchical ‘tree’ structure (see Understanding the Explorer Bar Tree-Structure).

For information on how to display the Queries Bar, see Display an Explorer Bar in ViewX.

The entries in the Queries Bar represent each of the database tables that store configuration information in the database(s) to which the ViewX client and your user account have access. You can query each of these tables to display information in List format (see Display a Queries List from the Queries Bar in the ClearSCADA Guide to Lists).

The Queries branch comprises tables of the various types of database item that exist on your system, such as users, points, and channels. The entries in the Queries branch vary, depending on the database’s configuration and the drivers that are installed. The data in the tables is pre-filtered—when you display the data in List format, only the type of data that applies to each of the items in the table, and which is deemed to be of greatest use, is included in the List.

The Data Grids branch contains an alphabetical listing of any Data Grids that exist in the database. Data Grids can be used to add ‘custom’ tables to the database (see Configuring Data Grids in the ClearSCADA Guide to Core Configuration).

The Tables branch lists the individual database ‘classes’ from which the Queries branch’s tables obtain their content. The Tables branch includes base classes and sub-classes for every type of item in the database. This includes driver- and item-specific classes for each type of database item that is supported by each driver that is installed. You can use the entries in the Tables branch to display unfiltered Queries Lists. Such Lists are for higher level users that want to ascertain the values of specific properties in the database.

Driver-specific entries exist for database items supported by the drivers that are installed.
You can place the cursor over an entry to display a ToolTip that provides further information about the database items to which a particular class relates.
Entries exist for each database base class and sub-class.

Queries Lists accessed from within the Tables branch typically include hyperlinks to the configuration Forms and/or other displays associated with the database items in the List. Select a hyperlink to access a Form or other display. To return to the Queries List from the display, perform one of the following:

  • If available, select the Back button on the mouse
  • Select the Back button [image] on the Operate Toolbar
  • Select the View menu from the ViewX menu bar, followed by the Go To option and then the Back option
  • Press the ALT and left arrow keys simultaneously.

Further Information

For other ways of displaying a Queries List, see Display a Queries List in the ClearSCADA Guide to Lists.

For information on database classes and the fields within those classes, see the database Schema and the ClearSCADA Guide to the Database.


ViewX and WebX Clients Guide - Operator Documents Bar (Explorer Bars used in ViewX)

Operator Documents Bar

The Operator Documents Bar is an Explorer Bar (see Explorer Bars used in ViewX). It provides quick access to any of the operator document stores to which you have access. An operator document store is a special group that can be used to store documents, such as pre-configured Trends.

Each operator document store can be arranged using a hierarchical ‘tree’ structure (see Understanding the Explorer Bar Tree-Structure).

For information on how to display the Operator Documents Bar, see Display an Explorer Bar in ViewX.

For information on working with an Operator Document Store, see Operator Document Stores.


ViewX and WebX Clients Guide - Areas of Interest Bar (Explorer Bars used in ViewX)

Areas of Interest Bar

The Areas of Interest Bar is an Explorer Bar (see Explorer Bars used in ViewX). The Bar is typically used by higher level users when restricting alarm and event access to specific areas of a ClearSCADA system.

The Areas of Interest button is only included on the Operator Documents Bar (and the Areas of Interest option is only included in the View menu) if the Area of Interest feature is enabled on your system. The feature is used to limit the alarms and events that are displayed on a node (workstation), such that you are only made aware of the alarms and events that are associated with the geographical or logical areas in which you are interested.

For information on how to display the Areas of Interest Bar, see Display an Explorer Bar in ViewX.

For more information on Areas of Interest, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.


ViewX and WebX Clients Guide - OPC Data Bar (Explorer Bars used in ViewX)

OPC Data Bar

The OPC Data Bar is an Explorer Bar (see Explorer Bars used in ViewX). The Bar uses a hierarchical ‘tree’ structure (see Understanding the Explorer Bar Tree-Structure) to allow you to browse the various OPC properties in the database.

The OPC Data Bar is a useful tool for higher levels users for building and configuring the ClearSCADA system, configuring Mimics and Trends, debugging the system, or when connecting other systems to the database. For more information, see Working with the OPC Data Bar in the ClearSCADA Guide to Core Configuration.

Further Information

Display an Explorer Bar in ViewX.


ViewX and WebX Clients Guide - OPC Historic Data Bar (Explorer Bars used in ViewX)

OPC Historic Data Bar

The OPC Historic Data Bar is an Explorer Bar (see Explorer Bars used in ViewX). It provides access to the OPC historic data in the database and uses a hierarchical ‘tree’ structure (see Understanding the Explorer Bar Tree-Structure).

The OPC Historic Data Bar provides access for higher level users that want to access OPC historic data properties in the database and view the property values in the form of Trends (see Working with the OPC Historic Data Bar in the ClearSCADA Guide to Core Configuration).

Further Information

Display an Explorer Bar in ViewX.


ViewX and WebX Clients Guide - Object Menu

Object Menu

The ClearSCADA Object menu is a context sensitive menu that allows you to view the status of, and perform actions on a database item, such as a point or outstation. The options that are available from the menu vary depending, for example, on:

  • The type of item from which the menu is displayed
  • The item’s configuration
  • The item’s current status
  • Your security permissions.

When you display the ClearSCADA Object menu for an individual item, the options on the menu apply to only that particular item. For example, if you select the Acknowledge Alarms option on the Object menu for a point, this will trigger ClearSCADA to acknowledge any active alarm(s) on that particular point (see Perform an Action on an Alarm in the ClearSCADA Guide to Alarms).

When you display the ClearSCADA Object menu for a Group or Group Instance, the options on the menu apply to the group, any subgroups within that group, and the items in that group and subgroups. For example, if you select the Acknowledge Alarms option from a group Object menu, this will trigger ClearSCADA to acknowledge any active alarms on the items in that group and any subgroups. So if the group contains three pumps that each have active alarms, selecting Acknowledge Alarms from the group Object menu will trigger ClearSCADA to acknowledge alarms on those three pumps.

The rest of this section explains:

  • How to Display the Object Menu
  • Those Object Menu Options that are common to many database items
  • How to:
  • Use the Numeric Touch Screen Keypad

and

  • Use the QWERTY Touch Screen Keypad.

(The Touch Screen Keypads only apply to ViewX workstations that are configured to enable On-Screen Keyboard functionality. With such workstations, the appropriate on-screen keyboard is displayed automatically when you select a text entry field on the windows that are associated with certain Object menu options. The keypads provide an alternative means of specifying a value, instead of using a traditional keyboard.)

The options that are available from an Object menu are also referred to as ‘pick actions’ throughout the ClearSCADA documentation.

Pick actions can be triggered manually or automatically. Your system might be configured to trigger specific pick actions automatically, for example on a scheduled basis or in response to alarms being raised. For further information, see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration, and see the ClearSCADA Guide to Alarm Redirection.


ViewX and WebX Clients Guide - Display the Object Menu (Object Menu)

Display the Object Menu

To display the ClearSCADA Object menu, do one of the following:

  • Right-click on an item in the Database Bar.
  • Click on an item in a Mimic that is configured to provide access to the Object menu (see Mimics).
  • Right-click on an entry in a Queries List (see Lists).

The context-sensitive Object menu is displayed. The options vary, depending, for example, on the type of item for which the menu is displayed, and the item’s configuration and current status.

Example:

Further Information

Object Menu Options.


ViewX and WebX Clients Guide - Object Menu Options (Object Menu)

Object Menu Options

This section explains the operator-level Object menu options (‘pick actions’) that are common to many database items. It also lists those higher-level Object menu options that engineers might use during system configuration.

With an option that requires further user input before being executed, a window is displayed. Use the window to specify the required information and then select the OK button to confirm the details and execute the request.

For information on any menu options that are not listed in this section, see the ClearSCADA Guide to Drivers, or the relevant driver guide. (The ClearSCADA Guide to Drivers lists those pick actions that are common to items on many drivers; each driver-specific guide list any pick actions that are specific to that particular driver.)

Some of the Object menus on your system may include additional ‘custom’ menu options—menu options that have been added specifically for items on your system. See a system administrator for the documentation associated with such custom options.

The options that are displayed on an Object Menu vary, but may include a combination of these options:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Disable Alarms
  • Display
  • Display Alarm View
  • Display Alarms
  • Display Current Trend
  • Display Default View
  • Display Events
  • Display Help View
  • Display Historic List
  • Display Historic Trend
  • Display Objects
  • Display Property Changes
  • Display Users (see Display Users in the ClearSCADA Guide to Security)
  • Enable Alarms
  • Hand Control
  • Locate in Database Explorer
  • Locate in OPC Data Explorer
  • Notes
  • Notify User (see Notify User in the ClearSCADA Guide to Security)
  • Remove Alarms
  • Remove with Comment
  • Suppressed Alarm Objects
  • Unacknowledge Alarms
  • Unacknowledge with Comment
  • View Status.

NOTE: Some of the options listed in this ViewX and Web Clients Guide mention the Automation Interface. Such notes are only of interest to high-level users that want to use that built-in interface.

The Object menu may also include a combination of these options, which are relevant to database configuration tasks, or other high-level operations. For information on any of these options, see the ClearSCADA Guide to Core Configuration, unless another guide is mentioned below:

  • Change Main Server—see the ClearSCADA Guide to Server Administration
  • Change Password—see Change your Password via ViewX, and see Change your Password via a WebX Client
  • Color Palette
  • Convert To
  • Delete
  • Disable Execution—see the ClearSCADA Guide to Logic
  • Display Errors
  • Display Instances
  • Display References
  • Edit
  • Execute—see the ClearSCADA Guide to Logic
  • Export
  • Import
  • Import & Merge
  • Locate in Template
  • Locate Template
  • New
  • New Instance
  • Properties
  • Property Overrides
  • Release Exclusive Control—see the ClearSCADA Guide to Security
  • Rename
  • Repair Instance
  • Reset Profile—see the ClearSCADA Guide to Security
  • Restart—see the ClearSCADA Guide to Logic
  • Security—see the ClearSCADA Guide to Security
  • Set Duty User—see the ClearSCADA Guide to Alarm Redirection
  • Set Element
  • Set Value
  • Set Variable—see the ClearSCADA Guide to Logic
  • Take Complete Exclusive Control—see the ClearSCADA Guide to Security
  • Take Partial Exclusive Control—see the ClearSCADA Guide to Security.

Further Information

Display the Object Menu.

Use the Numeric Touch Screen Keypad.

Use the QWERTY Touch Screen Keypad.


ViewX and WebX Clients Guide - Acknowledge Alarms (Object Menu)

Acknowledge Alarms

Associated with: Any item for which an alarm can be raised

Security permission required to access this option: Acknowledge Alarms

Use this option on the Object Menu to acknowledge any unacknowledged alarms on the selected item, Group or Group Instance (and any subgroups).

Select the option on a point to trigger ClearSCADA to acknowledge any unacknowledged alarms on that point.

Select the option on a Group or Group Instance, to trigger ClearSCADA to acknowledge any unacknowledged alarms on the items in that Group or Group Instance (and in any subgroups within that Group or Group Instance).

For more information, see Acknowledge an Alarm in the ClearSCADA Guide to Alarms.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Accept.

Also see Acknowledge with Comment, and see Alarm Response.


ViewX and WebX Clients Guide - Acknowledge with Comment (Object Menu)

Acknowledge with Comment

Associated with: Any item for which an alarm can be raised

Security permission required to access this option: Acknowledge Alarms

Use this option on the Object Menu to add a comment to the Event Journal when ClearSCADA acknowledges any unacknowledged alarms on the selected item, Group or Group Instance (and in any subgroups within that Group or Group Instance).

For more information, see Acknowledge an Alarm with Comment in the ClearSCADA Guide to Alarms.

Also see Acknowledge Alarms.


ViewX and WebX Clients Guide - Alarm Response (Object Menu)

Alarm Response

Associated with: Any item for which an alarm can be raised

Security permission required to access this option: Acknowledge Alarms

Select this option on the Object Menu to indicate that you are aware of an alarm without acknowledging it (see Respond to an Alarm in the ClearSCADA Guide to Alarms).

NOTE: If using this pick action with the Automation Interface, you need to specify the method name SetAlarmResponse.

Also see Acknowledge Alarms.


ViewX and WebX Clients Guide - Disable Alarms (Object Menu)

Disable Alarms

Associated with: Any item for which an alarm can be raised

Security permission required to access this option: Disable Alarms

The Disable Alarms option on the Object Menu is only available on database items that can have alarms. Access to the option is also dependent on the server configuration (which might restrict access to the option).

The Disable Alarms option allows you to disable (hide) alarms for the selected item.

Select the option on an individual database item, such as a point, to disable the alarms on that item.

Select the option on a Group or Group Instance to disable the alarms on the items in that Group or Group Instance (and in any subgroups in that Group or Group Instance).

For more information, see Disable Alarms and Enable Alarms in the ClearSCADA Guide to Alarms.


ViewX and WebX Clients Guide - Display (Object Menu)

Display

Associated with: Mimics, Reports, Trends, Logic programs, and X-Y Plots

Security permission required to access this option: Read

Use the Display option to display the selected ‘file’ object, such as a Mimic, Report, or Trend.


ViewX and WebX Clients Guide - Display Alarm View (Object Menu)

Display Alarm View

This option is only available if an Alarm View is configured for the item or the Group with which the item is associated (see Define an Alarm View in the ClearSCADA Guide to Core Configuration).

Use the Display Alarm View option to display the ‘file object’ (such as a Mimic or Trend) that is configured as the item’s Alarm View.

Use the Alarm View to ascertain further information about any alarm(s) and/or take the appropriate action. For more information about alarms, see Alarms.


ViewX and WebX Clients Guide - Display Alarms (Object Menu)

Display Alarms

Associated with: Any item, Group, or Group Instance

Security permission required to access this option: Read

Select this option on the Object Menu to display an Alarms List (see Alarms Lists in the ClearSCADA Guide to Alarms).

Select the option from an individual database item to display an Alarms List that only includes the alarms for that particular item.

Select the option from a Group or Group Instance to display an Alarms List that only includes alarms for the items in that Group or Group Instance (and in any subgroups within that Group or Group Instance).

Be aware that your user account might be configured to further filter the entries in the Alarms List or otherwise limit the entries to those alarms that are likely to be of interest to you.


ViewX and WebX Clients Guide - Display Current Trend (Object Menu)

Display Current Trend

Associated with: Master station accumulators, and many types of point

Security permission required to access this option: Read

Select this option on the Object Menu to display a Trend of current data for the selected point or accumulator, starting from the current time. The Trend is updated as further values are received and processed (see Trends).


ViewX and WebX Clients Guide - Display Default View (Object Menu)

Display Default View

This option is only available if:

  • You are accessing the Object menu for a Group, Group Instance, or Group Template.
  • That Group, Group Instance, or Group Template is configured to have a Default View (see Defining a Default View in the ClearSCADA Guide to Core Configuration).

Select the Display Default View option to display the ‘file object’ (such as a Mimic or Trend) that is configured as the Group, Group Instance, or Group Template’s Default View.

Use the Default View to ascertain further information about the items within the Group and/or access alarm response actions and controls.

Also see Display Help View, and see Display Alarm View.


ViewX and WebX Clients Guide - Display Events (Object Menu)

Display Events

Associated with: Any item in the database

Security permission required to access this option: Read

Select this option on the Object Menu to display an Events List (see Events).

Select this option from an individual database item to display an Events List that only includes events for that particular item.

Select this option from a Group, Group Instance, or Group Template to display an Events List that only includes events for the items in that Group, Group Instance, or Group Template (including items in any subgroups).

Events Lists are pre-filtered by time—the period for which events are initially shown is defined by the Event List Range specified for your user account (or the Guest or Web user account if you are not logged onto the system). Your user account and security permissions might further restrict the entries in the Events List to those that are likely to be of interest to you.


ViewX and WebX Clients Guide - Display Help View (Object Menu)

Display Help View

This option is only available if:

  • A Help View is configured for the item or the Group with which the item is associated (see Specify a Help View in the ClearSCADA Guide to Core Configuration).

Use the Display Help View option to display the ‘file object’ (such as a Mimic or Trend) that is configured as the item or Group’s Help View.

The Help View should provide help about the item or Group. For example, operating instructions for a piece of equipment.

Also see Display Default View, and see Display Alarm View.


ViewX and WebX Clients Guide - Display Historic List (Object Menu)

Display Historic List

Associated with: Points and master station accumulators that have Historic logging enabled

Security permission required to access this option: Read

Select this option on the Object Menu to display a List of historic values for the selected point or master station accumulator (see Historic Lists in the ClearSCADA Guide to Lists).


ViewX and WebX Clients Guide - Display Historic Trend (Object Menu)

Display Historic Trend

Associated with: Points and master station accumulators that have Historic logging enabled

Security permission required to access this option: Read

Select this option on the Object Menu to display a Trend of historically logged data for the selected point or accumulator (see Trends).


ViewX and WebX Clients Guide - Display Objects (Object Menu)

Display Objects

Associated with: Groups and Group Instances

Security permission required to access this option: Read

Select this option on the Object Menu to display a Queries List of the items that are in the selected Group or Group Instance (see Lists).


ViewX and WebX Clients Guide - Display Property Changes (Object Menu)

Display Property Changes

Associated with: All database items, but only when the Configuration Changes Auditing feature is enabled (see Settings for Configuration Changes Auditing in the ClearSCADA Guide to Server Configuration).

Select this option to view a List of the configuration changes made to an item. For more information, see Display a List of Property Changes in the ClearSCADA Guide to Core Configuration.


ViewX and WebX Clients Guide - Enable Alarms (Object Menu)

Enable Alarms

Associated with: Any item for which an alarm can be raised

Security permission required to access this option: Disable Alarms

The Enable Alarms option on the Object Menu is only available on database items that can have alarms. Access to the option is also dependent on the server configuration (which might restrict access to the option).

The Enable Alarms option allows you to enable (register), alarms for the selected item.

Select the option on an individual database item, such as a point, to enable the alarms on that particular item.

Select the option on a Group or Group Instance, to enable the alarms on the items in the Group or Group Instance and in any subgroups within that Group or Group Instance.

For more information, see Disable Alarms and Enable Alarms in the ClearSCADA Guide to Alarms.


ViewX and WebX Clients Guide - Hand Control (Object Menu)

Hand Control

Associated with: Internal Points

Security permission required to access this option: Control

Use this option on the Object Menu to manually change an internal point’s value.

Select the Hand Control option to display the Hand Control window.

Specify the required value in the Value field:

  • With an analog point, specify a value within the range that is shown to the right-hand side of the Value field.
  • With a digital point, use the combo box to display the list of possible values. Select the required value from the list.
  • With a string point, enter the required string in the Value field.
  • With a time point, either overtype the existing entry, or use the Calendar window to specify the required date (see Specifying the Required Entry in a Date and Time Field in the ClearSCADA Guide to Core Configuration).

Select the OK button to confirm the entry and hand control the point.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name CurrentState for a digital point, or CurrentValue for other types of point.


ViewX and WebX Clients Guide - Locate in Database Explorer (Object Menu)

Locate in Database Explorer

This option is only available if:

  • You are accessing an Object menu from ViewX (other than from the Database Bar)
  • Your user account provides access to the Database Bar.

Select the Locate in Database Explorer option for ClearSCADA to display the Database Bar and highlight the item in the hierarchical ‘tree’ structure within that Explorer Bar.

Also see Locate in OPC Data Explorer.


ViewX and WebX Clients Guide - Locate in OPC Data Explorer (Object Menu)

Locate in OPC Data Explorer

This option is only available if:

  • You are accessing an Object menu from ViewX (other than from the OPC Data Bar)
  • Your user account provides access to the OPC Data Bar.

Select the Locate in OPC Data Explorer option for ClearSCADA to display the OPC Data Bar and highlight the item in the hierarchical ‘tree’ structure within that Explorer Bar.

Also see Locate in Database Explorer.


ViewX and WebX Clients Guide - Notes (Object Menu)

Notes

Associated with: Any item in the database

Security permission required to access this option: Read (to view the notes) and Edit Notes (to add or change the notes)

Select this option on the Object Menu to display the Notes window.

If your user account is assigned the Read, but not the Edit Notes permission for the item, the Notes window is displayed in read only format:

View any existing notes, then select the Close button to close the Notes window.

If your user account is assigned both the Read and Edit Notes permissions for the item, you can either view or modify any existing note, or add a note about the selected item or Group. For example, information about what to do if the item has an alarm.

Any notes you add are logged in the Event Journal (Events List).

The presence of an existing note is also indicated by the item’s entry being assigned the Note color in displays such as Queries Lists (unless another status takes precedence).

Some actions on your system may be configured to display the Notes window whenever those actions are selected (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration). In such situations, the notes typically provide further information about the selected action, or allow you to log information about why a particular action was performed. In order to display the Notes window as part of an action request, your user account has to be assigned both the Read and Edit Notes security permissions for the item on which the action is being performed. Select the OK button on the Notes window to continue with the requested action, or the Cancel button to abort the request.


ViewX and WebX Clients Guide - Remove Alarms (Object Menu)

Remove Alarms

Associated with: Any item for which an alarm can be raised

Security permission required to access this option: Remove Alarms

WARNING

lACK of alarm notification

Use the Remove Alarms option with care. Before using the option, we strongly recommend that you perform a risk analysis to ensure that the removal of existing alarms will not pose a danger to people or equipment.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

Use the Remove Alarms option on the Object Menu to remove any acknowledged alarms on the selected item.

Select the option on a point to remove the acknowledged alarms on that point.

Select the option on a Group or Group Instance to remove the acknowledged alarms on the items in that Group or Group Instance (and in any subgroups within that Group or Group Instance).

For more information, see Remove an Alarm in the ClearSCADA Guide to Alarms.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name RemoveAlarm.

Also see Remove with Comment.


ViewX and WebX Clients Guide - Remove with Comment (Object Menu)

Remove with Comment

Associated with: Any item for which an alarm can be raised

Security permission required to access this option: Remove Alarms

WARNING

lACK of alarm notification

Use the Remove with Comment option with care. Before using the option, we strongly recommend that you perform a risk analysis to ensure that the removal of existing alarms will not pose a danger to people or equipment.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

Use the Remove with Comment option on the Object Menu to add a comment to the Event Journal when ClearSCADA removes any acknowledged alarms from the selected item, Group or Group Instance (and any subgroups within that Group or Group Instance).

For more information, see Remove an Alarm with Comment in the ClearSCADA Guide to Alarms.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name RemoveAlarmWithComment.

Also see Remove Alarms.


ViewX and WebX Clients Guide - Suppressed Alarm Objects (Object Menu)

Suppressed Alarm Objects

Associated with: Any item that is assigned as another item’s ‘Parent Alarm Object’

Security permission required to access this option: Read

Select this option to display a Queries List of currently suppressed ‘child’ items. An item is suppressed if a currently active alarm on this ‘parent’ database item is configured to suppress alarms on that ‘child’ database item.

The List includes the currently suppressed ‘child’ items, regardless of whether those items themselves have alarms or not.

The List is empty if the selected ‘Parent Alarm Object’ item is not currently suppressing any ‘child’ items. (In other words, if it does not have a currently active alarm that is configured to suppress alarms on any ‘child’ items.)

ClearSCADA’s alarm suppression feature is designed to help prevent a ‘flood’ of alarms, whenever a ‘parent’ alarm is raised. For more information, see Alarm Suppression in the ClearSCADA Guide to Alarms.


ViewX and WebX Clients Guide - Unacknowledge Alarms (Object Menu)

Unacknowledge Alarms

NOTE: The Unacknowledge Alarms option is disabled on most systems by default. (Its permission is typically denied on a per server basis.)

Associated with: Any item that has acknowledged uncleared alarm(s)

Security permission required to access this option: Unacknowledge Alarms

If available on your system, you can use this option on the Object Menu to unacknowledge an alarm that is currently acknowledged (see Unacknowledge an Alarm in the ClearSCADA Guide to Alarms).

Select the option on an individual item, such as a point, to unacknowledge any acknowledged alarms on that item.

Select the option on a Group or Group Instance to unacknowledge any acknowledged alarms on the items in that Group or Group Instance (including in any subgroups within that Group or Group Instance).

NOTE: If using this pick action with the Automation Interface, you need to specify the method name UnacceptAlarm.

Also see Unacknowledge with Comment.


ViewX and WebX Clients Guide - Unacknowledge with Comment (Object Menu)

Unacknowledge with Comment

NOTE: This option is disabled on most systems by default. (Its permission is typically denied on a per server basis.)

Associated with: Any item that has acknowledged uncleared alarm(s)

Security permission required to access this option: Unacknowledge Alarms

If available on your system, you can use this option on the Object Menu to unacknowledge an alarm that is currently acknowledged. The option allows you to enter a brief text description as to why the alarm is being returned to the acknowledged state (see Unacknowledge an Alarm with Comment in the ClearSCADA Guide to Alarms).

Select the option on an individual item, such as a point, to unacknowledge any acknowledged alarms on that item.

Select the option on a Group or Group Instance to unacknowledge any acknowledged alarms on the items in that Group or Group Instance (including in any subgroups within that Group or Group Instance).

NOTE: If using this pick action with the Automation Interface, you need to specify the method name UnacceptAlarmWithComment.

Also see Unacknowledge Alarms.


ViewX and WebX Clients Guide - View Status (Object Menu)

View Status

Associated with: Any item in the database

Security permission required to access this option: Read

Select this option on the Object Menu to view an item’s Status display. The Status display provides a summary of status information about the selected item (see Status Displays).


ViewX and WebX Clients Guide - Use the Numeric Touch Screen Keypad (Object Menu)

Use the Numeric Touch Screen Keypad

This section only applies if your ViewX workstation is configured to enable On-Screen Keyboard functionality (see Enable or Disable the On-Screen Keyboard in the ClearSCADA Guide to Client Administration).

When certain menu options (‘pick actions’) are selected, a window is displayed that includes field(s) that require you to specify a numeric value. When the On-Screen Keyboard feature is enabled, a numeric keypad is displayed when you select a numeric input field on a pick action window that supports on-screen keyboard functionality. Designed for use with touch screen displays, the numeric keypad allows you to enter a numerical value using the on-screen keypad, as an alternative to using a traditional keyboard. (For string values, a QWERTY keypad may be available (see Use the QWERTY Touch Screen Keypad).)

To use the numeric touch screen keypad:

  1. On the relevant pick action window, select a field that requires you to specify a numeric value.
    The numeric touch screen keypad is displayed.
  2. If your computer display screen (monitor) provides touch screen functionality, touch the keypad button(s) to specify the value that is required.

If your computer display screen does not provide touch screen functionality, use the mouse to select the keypad button(s) that define the required value.

Ensure that you enter a value that is within the range of supported values for that particular property. (The range varies, depending on the item’s configuration.) The supported range is displayed in parentheses next to the field on the pick action’s window.

Example:

For this particular value, you can enter a number in the range 0.00 to 100.00 inclusive.

The specified value appears in the field on the pick action’s window.

The keypad window closes automatically whenever you select a non-numeric field or close the pick action window. To close the keypad window independently of the pick action’s window, select the Close button on the keypad window.


ViewX and WebX Clients Guide - Use the QWERTY Touch Screen Keypad (Object Menu)

Use the QWERTY Touch Screen Keypad

This section only applies if your ViewX workstation is configured to enable On-Screen Keyboard functionality (see Enable or Disable the On-Screen Keyboard in the ClearSCADA Guide to Client Administration).

When certain menu options (‘pick actions’) are selected, a window is displayed that includes field(s) that require you to specify a string value (alphanumeric value). When the On-Screen Keyboard feature is enabled, a QWERTY keypad is displayed when you select a string field on a pick action window that supports on-screen keyboard functionality. Designed for use with touch screen displays, the QWERTY keypad allows you to enter alphanumerical values using the on-screen keypad, as an alternative to using a traditional keyboard. (For numeric values, a numeric keypad may be available (see Use the Numeric Touch Screen Keypad).)

To use the QWERTY touch screen keypad:

  1. On the relevant pick action window, select a field that requires you to specify a string or alphanumeric value.
    The QWERTY touch screen keypad is displayed.
  2. If your computer display screen (monitor) provides touch screen functionality, touch the keypad button(s) to specify the value that is required.

If your computer display screen does not provide touch screen functionality, use the mouse to select the keypad button(s) that define the required value.

The keypad window closes automatically whenever you select a non-alphanumeric field or close the pick action window. To close the keypad window independently of the pick action’s window, select the Close button on the keypad window.


ViewX and WebX Clients Guide - Alarms

Alarms

An alarm is an indication of an abnormal condition detected by the ClearSCADA system. For example, items in your database may be configured to operate within certain limits, and if an item returns values that are outside those limits, an alarm might be raised.

Each alarm has a Severity that indicates the importance of the alarm...
...and a Category that indicates the type of alarm.

In ClearSCADA, the existence of alarms is indicated in a number of ways, including:

  • An audible alarm—If configured to do so, an audible alarm will sound whenever a new alarm is raised (see Audible Alarms in the ClearSCADA Guide to Alarms).
  • The Alarm Banner—This is the primary alarms display on ViewX clients (see Alarm Banner in the ClearSCADA Guide to Alarms).

The Alarm Banner is usually shown at the bottom of the ViewX display, but it is also possible to display the Alarm Banner at full screen size (this is useful on clients with multiple monitors).

For more information on how to set up a full screen Alarm Banner on a multi-head client, see Configure a Head to Show a Full Screen Alarm Banner in the ClearSCADA Guide to Client Administration.

  • Alarms Lists—Alarms are shown on Alarms Lists and can also be shown on other Lists (see Alarms Lists in the ClearSCADA Guide to Alarms, and see the ClearSCADA Guide to Lists).
  • Animated Mimics—Mimics can be configured to contain animated representations of alarms, to allow the alarms to be viewed and managed from those Mimics (see Alarms on Mimics in the ClearSCADA Guide to Alarms).

Be aware that displays such as Alarms Lists and the Alarm Banner only include alarms to which your user account and the ViewX or WebX client have access. Filters might further restrict the entries that are included in such displays.

When an alarm is raised, you should take the appropriate action (see Perform an Action on an Alarm in the ClearSCADA Guide to Alarms). Typically, you should acknowledge the alarm and then ensure that the abnormal condition that caused the alarm is rectified (if possible). Once ClearSCADA detects that the abnormal condition that caused the alarm is no longer present, it will clear the alarm.

ClearSCADA supports alarm suppression. If other displays indicate that an item is in an alarm state, but no associated alarm entry is included in Alarms Lists or the Alarm Banner, it could be that the item’s alarms are suppressed (omitted from alarm displays). The item’s Status display will indicate if its alarms are suppressed.

Further Information

Activities that Occur when an Alarm is Raised in the ClearSCADA Guide to Alarms.

Alarm Severity, Status, and Category in the ClearSCADA Guide to Alarms.

For further information on alarms, see the ClearSCADA Guide to Alarms.

Certain alarms on your system might be redirected automatically (for example, if those alarms are not acknowledged within a specified time period). For information on redirection, see the ClearSCADA Guide to Alarm Redirection.

Alarm Suppression in the ClearSCADA Guide to Alarms.


ViewX and WebX Clients Guide - Events

Events

Events are records of occurrences on your system. ClearSCADA logs events for user interaction with the system and for automatic system occurrences, such as alarms, point updates, scheduled archiving, and so on. The logging of such events creates an audit trail for system operation and reporting.

You can display an Events List that includes those events that occurred on a particular ClearSCADA system over a defined time-period, or an Events List that is pre-filtered to just include the events for a specific item or Group.

You can use either Events List to view the events and determine what has happened on your system. This is especially useful when attempting to diagnose any problems that ClearSCADA has detected, or determine what tasks other users have performed.

The entries in the Events Lists are displayed using colors that indicate whether any of the events are associated with alarms (see Alarm Status in the ClearSCADA Guide to Alarms).

Events Lists are pre-filtered by time—the period for which events are initially shown is defined by the Event List Range specified for your user account (or the Guest or Web user account if you are not logged onto the system).

The Events List shows the events that have occurred on a single ClearSCADA system. On ClearSCADA systems that have Multiple Databases, you can specify the particular ClearSCADA system (database) for which you want to display events. Your user account might further restrict the events to which you have access.

As with other types of List, you can filter and sort the entries in Events Lists.

For further information on displaying and working with Events Lists, see Events Lists in the ClearSCADA Guide to Lists.


ViewX and WebX Clients Guide - Mimics

Mimics

Mimics are visual displays that provide a visual representation of plant, a geographical location, or a combination of information such as values for a variety of different items.

Mimics can combine symbols and text. Symbols are graphical items that represent database items, and may be used to indicate the state of physical devices.

Mimics can contain live data that is updated as the values in the database change. The live data is referred to as an ‘animation’. The animations can be text or numeric values or they can be represented by moving shapes on the Mimic. For example, a pump may change color to indicate whether it is running, or a piece of text may show whether the pump is healthy, or whether ClearSCADA has detected a fault on the pump.

You can navigate a Mimic (magnify and display specific areas of a Mimic). You can also access actions via context sensitive menus, which include controls that allow you to manipulate the values of points, and options that you can use to manage alarms.

You can access a Mimic via the Database Bar in ViewX, use the Database navigator in WebX, or via an Object Menu or hyperlink on another Mimic.

For more information on configuring and using Mimics, see the ClearSCADA Guide to Mimics.

Further Information

Alarms on Mimics in the ClearSCADA Guide to Alarms.

View a Mimic on a WebX Client.


ViewX and WebX Clients Guide - Lists

Lists

You can display a wide range of information in List form on a ViewX Client or WebX Client.

You can display separate Lists of:

  • Alarms for the ClearSCADA systems (databases) to which a client is connected, a specific area of a system, or for particular database item(s)—see Alarms Lists in the ClearSCADA Guide to Alarms.
  • Events for a single ClearSCADA system, a specific area of that system, or for particular database item(s)—see Events Lists in the ClearSCADA Guide to Lists.
  • Database items for example, Lists of Points, Outstations, or Lists of the database items that are in a particular Group, or associated with a particular outstation—see Queries Lists in the ClearSCADA Guide to Lists.
  • Historic values for an individual point or master station accumulator that has Historic enabled—see Historic Lists in the ClearSCADA Guide to Lists.

The entries in each List are typically displayed using colors that indicate the item’s state.

You can filter and sort the information in each List. You can also access actions via context sensitive menus that are associated with the various items in the Lists. You can use these actions to, for example, access other displays, view further information about an item, perform controls on plant, or manage alarms.

For information on displaying and using Lists, see the ClearSCADA Guide to Lists.


ViewX and WebX Clients Guide - Trends

Trends

Trends are graphical displays that plot the values of database items. They allow you to view and compare the values of points over a specific period of time.

Trends display data with the x-axis representing time, and the y-axis representing data values. Trends can be configured to display multiple traces simultaneously.

ClearSCADA supports several types of Trend:

  • Pre-Configured Trends—These are system-specific Trends that have been configured by high level users as part of your ClearSCADA database configuration. They appear as Trend items in your database, enabling you to access them in the same way as other items such as Mimics:
    You can access a Pre-Configured Trend from, for example, the Database Bar.

Pre-Configured Trends can display multiple traces and may combine current and historic data on the one Trend.

  • Ad Hoc Trends—’Standard’ Ad Hoc Trends are not stored in your database, rather they are generated when you display them. You can display a ‘standard’ Ad Hoc Trend for any point or master station accumulator in your database, by selecting the relevant option from the point or accumulator’s context-sensitive menu (see Object Menu Options). ClearSCADA supports two types of ‘standard’ Ad Hoc Trend:
  • Current—Displays the current data values for the point or accumulator.
  • Historic—Displays the raw or processed historic data for the point or accumulator. This type of Ad Hoc Trend is only available if Historic logging is enabled on the point or accumulator. (Raw data is the source data, whereas processed data comprises the values that result from ClearSCADA performing calculations on the raw data to, for example, adjust the values to a more usable range.)

High level users can configure ‘custom’ Ad Hoc Trends as part of your ClearSCADA database configuration. You typically display ‘Custom’ Ad Hoc Trends via hyperlinks on Mimics. You can also store links to ‘custom’ Ad Hoc Trends in your Favorites list.

  • File Based Trends—Users with the appropriate account permissions can save Trends externally as files on a PC or suitable storage device. Such Trends are not stored as part of the database. For information on accessing such Trends, see Display a File Based Trend in Run Mode in the ClearSCADA Guide to Trends.

Higher level users can also access Ad Hoc Trends for specific items or properties from the OPC Data Bar or OPC Historic Data Bar. For more information, see Working with the OPC Data Bar in the ClearSCADA Guide to Core Configuration, and see Working with the OPC Historic Data Bar in the ClearSCADA Guide to Core Configuration.

For more information on using Trends, see the ClearSCADA Guide to Trends.


ViewX and WebX Clients Guide - Reports

Reports

Crystal Reports™, a third-party application, can be used in conjunction with the ClearSCADA ViewX Client to produce professional customized reports that contain information obtained from your ClearSCADA database.

In order to produce such reports, the relevant ClearSCADA and Crystal Reports components have to be installed on your system, along with the third-party Crystal Reports software.

Actions you can perform on reports are:

  • Generate a report
  • Display a report
  • Print a report
  • Export a report to a variety of formats and destinations. For example, you can save your report to a disk, or export a report in Adobe Acrobat™ format and send it via e-mail to a system engineer or manager.

Your ClearSCADA system will usually be configured to automatically generate and print reports on a regular basis, for example daily, weekly and monthly. You can, however, generate reports at any time.

You can use reports to produce ‘snap-shots’ of the data on your system. To access ‘live’ data you use ClearSCADA displays such as Lists, Mimics, and Trends.

You can display the latest generated version of a report on a WebX client providing that specific criteria are met, such as the report being made available for display in WebX (see View the Most Recently Generated Version of a Report on a WebX Client).

For further information on reports, see the ClearSCADA Guide to the Crystal Reports Driver.


ViewX and WebX Clients Guide - Status Displays

Status Displays

Every item in your database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the current status of the selected item and is particularly useful when debugging the ClearSCADA system. For example, the Status display for a point provides information about the point’s current values, including its alarm state.

This is the Status display for an Internal Analog Point named ‘Test Point 4’.

The information that is shown in a Status display is specific to the selected item. The information shown varies according to:

  • The type of database item (such as a specific type of point, or a specific type of outstation)
  • The item’s configuration—attributes associated with optional features are only included on a Status display if those options are enabled
  • The current state of the item
  • The previous events associated with the item
  • The communications status—some attributes are only included on a Status display once ClearSCADA has successfully communicated with the device that the item represents and has been able to retrieve the relevant information.

For more information on Status displays, see:

  • View a Status Display
  • Use the Status Display Buttons
  • Understand the Status Display
  • Standard Alarm States.

For driver-specific information about the contents of the Status display, see the relevant driver guide. For a list of status attributes that are common to items on many drivers, see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - View a Status Display (Status Displays)

View a Status Display

To view an item’s Status display:

  1. Either:
  • Right-click on the item’s entry in the Database Bar
  • Right-click on the item’s entry in a List (see Lists)
  • If the item is included on a Mimic and its entry is configured to provide access to the Object menu, select that item’s entry on the Mimic (see Controlling Items via a Mimic in the ClearSCADA Guide to Mimics).

A context-sensitive Object Menu is displayed. The options vary, depending on the type of database item, its current state and configuration.

  2. Select the View Status option.
    The Status display for the selected item is displayed.

Higher level users can access further status information about an individual database item or any of that item’s OPC properties using the OPC Data Bar (see Working with the OPC Data Bar in the ClearSCADA Guide to Core Configuration).

Further Information

View an Item’s Status on a WebX Client.

Understand the Status Display.


ViewX and WebX Clients Guide - Use the Status Display Buttons (Status Displays)

Use the Status Display Buttons

When accessed from a ViewX Client, a series of buttons is included at the bottom of the Status display:

Use the buttons to perform these activities:

  • Copy All—Select this button to copy the information in the Status display to your PC’s clipboard. Paste the information from the clipboard into another display or application, as required.
  • Copy—This button becomes available for use once you select one or more attributes on the Status display.

To select the attribute(s) that are of interest, do one of the following:

  • Select a single attribute so that it is highlighted.
  • Select a block of attributes—select the first entry that you require, then hold down the Shift key while you select the last entry you require.
  • Select several individual attributes—select the first entry that you require, then hold down the Ctrl key while you make further selection(s).

Select the Copy button to paste the highlighted content to your PC’s clipboard. Paste the information from the clipboard into another display or application, as required.

  • Refresh—The status values that are shown on the Status display are accurate at the time you select the View Status option. They do not update automatically. Select the Refresh button to update the display to include the data for the current time.
  • Close—Select this button to close the Status display.

Further Information

View a Status Display.


ViewX and WebX Clients Guide - Understand the Status Display (Status Displays)

Understand the Status Display

Each item’s Status Display provides information about that particular item’s current status, in the form of a list of status attributes. The attributes vary, depending on the type of item, its current state, the actions that have been performed on the item, and its configuration.

This section provides information about those status attributes that are common to many types of database item, or that are shown on the Status displays of ‘core’ items. With database items that are associated with a particular driver, further driver-specific status attributes are typically also shown. For information on any attributes that are not listed below, see the ClearSCADA Guide to Drivers, or the relevant driver guide. (The ClearSCADA Guide to Drivers lists those status attributes that are common to items on many drivers.)

Any status attribute that indicates an alarm status displays one of the Standard Alarm States.

Any status attribute that indicates a date and time displays that information using the syntax defined by the user’s Date Format (see Define the Regional Settings for a User in the ClearSCADA Guide to Security, and see Configuring the Guest and Web User Accounts in the ClearSCADA Guide to Security).

Many Status displays include these common or ‘core’ status attributes:

  • Acknowledged Uncleared Alarms
  • Alarm Last Updated
  • Alarm State
  • Created
  • Disabled Alarms
  • Exclusive Control User
  • Full Name
  • Id
  • Last Modified
  • Type
  • Unacknowledged Cleared Alarms
  • Unacknowledged Uncleared Alarms.

In addition to common status attributes, the Status display for a User Account can include these user-specific attributes:

  • Account Enabled
  • Last Logoff Time
  • Last Logon Time
  • Logged On.

Further Information

View a Status Display.

Status Attributes that are Common to Items on Many Drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - Account Enabled (Status Displays)

Account Enabled

Associated with: Users

This status attribute indicates whether a user’s account is currently enabled (available for use). If your account is not enabled, you will not be able to log onto ClearSCADA. For more information on user accounts, see User Accounts in the ClearSCADA Guide to Security.

Possible states: True, or False.


ViewX and WebX Clients Guide - Acknowledged Uncleared Alarms (Status Displays)

Acknowledged Uncleared Alarms

Associated with: Groups and Group Instances

This status attribute indicates the total number of Acknowledged Uncleared alarms that exist for items in the Group or Group Instance (including any subgroups). Acknowledged Uncleared alarms are alarms have been acknowledged, but for which the condition that triggered the alarm still exists (see Alarm Status in the ClearSCADA Guide to Alarms).

Example:

6


ViewX and WebX Clients Guide - Alarm Last Updated (Status Displays)

Alarm Last Updated

Associated with: Any item for which an alarm can be raised

This status attribute displays the date and time of an item’s last alarm update.

Use the attribute in conjunction with other attributes on the item’s Status display to ascertain the present alarm status of the item.

Example:

02/Nov/2007 14:29:17.928


ViewX and WebX Clients Guide - Alarm State (Status Displays)

Alarm State

Associated with: Any item for which an alarm can be raised

This status attribute displays the summary state of an item’s current alarms and indicates whether alarms can be raised for that item.

With many types of database item, a single alarm is used to raise awareness of any abnormal condition that ClearSCADA has detected on that item. The severity of the alarm is typically specified on the <Item Type> tab of the item’s configuration Form.

With points, in addition to a severity for any non-state-related alarms, separate alarms and severities can be associated with individual point states or limits. These are typically specified on the <Point Type> tab of each point’s configuration Form. With output points, a further severity can be specified for any control-related alarms (typically specified on the Control tab).

The Alarm State attribute summarizes the status of an item’s alarms, indicating if any alarms currently exist.

If the attribute indicates an alarm state, ascertain further information about the actual alarm(s) by looking at the item’s other status attributes, or by using the Display Alarms pick action to display the item’s Alarms List.

Possible states:

  • Normal—No alarms currently exist for this item. Any cleared alarms have been acknowledged. Alarms can be raised for this item should an alarm situation occur.
  • Disabled—Alarms are presently disabled (hidden) for this item. The name of the user that was logged onto the node from which the alarms were disabled is displayed. If alarms are disabled for a user-defined period of time, the date and time at which the alarms cease to be disabled is also listed. For more information, see Disable Alarms and Enable Alarms in the ClearSCADA Guide to Alarms.
  • Acknowledged Uncleared—The alarm associated with this item has been acknowledged, but the condition that triggered the alarm still exists.
  • Unacknowledged Cleared—The condition that triggered an alarm on this item no longer exists. The message associated with the cleared alarm has yet to be acknowledged.
  • Unacknowledged Uncleared—An alarm exists for this item. The associated alarm message has not yet been acknowledged.

For further information on working with alarms, see Alarms.

(Do not confuse the Alarm State status attribute with the State Alarm attribute.)


ViewX and WebX Clients Guide - Created (Status Displays)

Created

Associated with: All items

This status attribute is only displayed for new items. It is replaced with the Last Modified attribute as soon as an item’s configuration is modified.

The Created attribute indicates the date and time at which an item was added to the database. The attribute also lists the name of the user that was logged onto the system from that node (workstation) at the time.

Example:

14/Jun/2007 12:29:13.891 by JKSmith
(Indicating that an item was added to the database at the time and date that is specified. ‘JKSmith’ was the user that was logged onto the workstation at that time.)


ViewX and WebX Clients Guide - Disabled Alarms (Status Displays)

Disabled Alarms

Associated with: Groups and Group Instances

This status attribute indicates the total number of items within the Group or Group Instance (including any subgroups) that have their alarms disabled.

Example:

6

Alarms are disabled using the Disable Alarms pick action (see Disable Alarms and Enable Alarms in the ClearSCADA Guide to Alarms). When an item’s alarms are disabled, that item’s entry on any ClearSCADA displays such as Queries Lists uses the Alarm Disabled color (unless another system color takes priority over that color). The individual item’s Alarm State status attribute also indicates whether the item’s alarms are disabled.


ViewX and WebX Clients Guide - Exclusive Control User (Status Displays)

Exclusive Control User

Associated with: All items that are under Exclusive Control

This status attribute is only displayed if the Exclusive Control feature is enabled on your system and an item is currently under Exclusive Control (see Exclusive Control in the ClearSCADA Guide to Security).

The status attribute displays the name of the user that currently has Exclusive Control of the item.

Further Information

Take Complete Exclusive Control: see Taking Exclusive Control in the ClearSCADA Guide to Security.

Take Partial Exclusive Control: see Taking Exclusive Control in the ClearSCADA Guide to Security.

Release Exclusive Control: see Releasing Exclusive Control in the ClearSCADA Guide to Security.


ViewX and WebX Clients Guide - Full Name (Status Displays)

Full Name

Associated with: All items

This status attribute displays the full name of an item, including its full path in the database.

The ‘name’ part of the attribute is that specified for the item in the database (and displayed in the Name field on the Identification tab of the item’s configuration Form). The ‘path’ part of the attribute includes dot separators to indicate the hierarchy of Groups (and/or the Group Instance, or Group Template), within which the item is located.

The Full Name of an item must not exceed 254 characters, including separation dots and blank spaces.

Example:

Eastern Region.Zone 1.Control Switch 3
(Indicating that the item that is assigned the name ‘Control Switch 3’ is in the Group ‘Zone 1’, which itself is within the Group ‘Eastern Region’.)

(If it is not apparent from an item’s name, use the Type status attribute to ascertain the type of item for which you are viewing status information.)

Further Information

ClearSCADA Naming Restrictions: see Naming Restrictions in the ClearSCADA Guide to Core Configuration.


ViewX and WebX Clients Guide - Id (Status Displays)

Id

Associated with: All items

The Id status attribute is only displayed if the user account with which you are logged on to ClearSCADA is allocated the Configure permission for the selected item (the item for which you are viewing status information).

The Id attribute displays an item’s unique identifier.

Every driver item is assigned a unique Id number—ClearSCADA assigns the number automatically when that item is added to the database.

Id numbers enable SQL to retrieve ‘dynasets’ of data, so minimizing the loading on both the server and client, particularly when requesting large quantities of data. Id numbers can also be used with the Automation Interface (see the Server Automation technical reference online Help).


ViewX and WebX Clients Guide - Last Logoff Time (Status Displays)

Last Logoff Time

Associated with: Users

This status attribute indicates the date and time that a user last logged off ClearSCADA.

Example:

24/Jun/2009 13:10:19.368


ViewX and WebX Clients Guide - Last Logon Time (Status Displays)

Last Logon Time

Associated with: Users

This status attribute indicates the date and time that a user last logged onto ClearSCADA.

Example:

24/Jun/2009 08:10:15.977

Also see Logged On.


ViewX and WebX Clients Guide - Last Modified (Status Displays)

Last Modified

Associated with: All items

This status attribute replaces the Created status attribute once an item’s configuration has been modified.

The Last Modified attribute indicates:

  • The date and time at which an item’s configuration was last modified
  • The name of the user that was logged onto the system from that node (workstation) at the time
  • The number of times that the item’s configuration has been modified.

Example:

18/Nov/2007 13:35:11.368 by JKSmith (Version 3)
(Indicating that the item’s configuration was last modified at the date and time specified above. ‘JKSmith’ was the user that was logged onto the workstation at the time that the item’s configuration was last modified. The Version number indicates that the item’s configuration has been modified 3 times since the item was added to the database.)


ViewX and WebX Clients Guide - Logged On (Status Displays)

Logged On

Associated with: Users

This status attribute indicates whether a user is currently logged onto ClearSCADA.

Possible states: True, or False.

Also see Last Logon Time, and see Last Logoff Time.


ViewX and WebX Clients Guide - Type (Status Displays)

Type

Associated with: All items

This status attribute comprises a standard description of the type of item.

Use the attribute in conjunction with the Full Name status attribute and, if applicable, the Source status attribute, to ascertain a particular item’s function and location on your system.

Example:

Modbus Digital Point
(Indicating that the item is the type of digital point that is supported by ClearSCADA’s Modbus driver. (The point represents digital data on a device with which ClearSCADA communicates using the Modbus protocol, via ClearSCADA’s Modbus driver.))


ViewX and WebX Clients Guide - Unacknowledged Cleared Alarms (Status Displays)

Unacknowledged Cleared Alarms

Associated with: Groups and Group Instances

This status attribute indicates the total number of Unacknowledged Uncleared alarms that exist for items in the Group or Group Instance (including any subgroups). Unacknowledged Uncleared alarms are alarms that remain unacknowledged, but for which the condition that triggered the alarm no longer applies (see Alarm Status in the ClearSCADA Guide to Alarms).

Example:

4


ViewX and WebX Clients Guide - Unacknowledged Uncleared Alarms (Status Displays)

Unacknowledged Uncleared Alarms

Associated with: Groups and Group Instances

This status attribute indicates the total number of Unacknowledged Uncleared alarms that exist for items in the or Group Instance (including any subgroups). An alarm remains unacknowledged and uncleared while the condition that triggered the alarm still exists and no user has acknowledged that they are aware of the alarm (see Alarm Status in the ClearSCADA Guide to Alarms).

Example:

2


ViewX and WebX Clients Guide - Standard Alarm States (Status Displays)

Standard Alarm States

Status attributes that represent an alarm status indicate whether alarms are enabled for the selected item and whether any alarms currently exist. Each alarm status attribute displays one of these possible states:

  • Enabled Inactive—The alarm feature is enabled for the item, but no alarms currently exist.

This indicates the item’s ‘normal’ operating condition. ClearSCADA has not detected any abnormal conditions for the item.

  • Enabled Active—The alarm feature is enabled and an alarm currently exists for the item. This indicates that ClearSCADA has detected an abnormal condition, which should be investigated.

The item’s Alarm Status is Unacknowledged Uncleared.

  • Enabled Cleared—The alarm feature is enabled for the item. An alarm situation did exist, but the abnormal condition that caused the alarm is no longer apparent, therefore ClearSCADA has cleared the alarm.

The alarm message that indicates that the alarm has cleared has not yet been acknowledged—as such, the item’s Alarm Status is Unacknowledged Cleared.

  • Enabled Acknowledged—The alarm feature is enabled for the item and an alarm currently exists. The alarm message has been acknowledged, but as the abnormal condition that caused the alarm still exists, the alarm entry has not been cleared.

The item’s Alarm Status is Acknowledged Uncleared.

  • Disabled Inactive—The alarm feature is disabled for the item, so no alarms can be raised. The item is in a state that corresponds to its ‘normal’ operating condition—if the alarm feature was enabled, no alarms would be raised (ClearSCADA has not detected any abnormal conditions for the item).
  • Disabled Active—The alarm feature is disabled for the item. The item in a state that corresponds to an active alarm—if the alarm feature was enabled, an Unacknowledged Uncleared alarm would exist.
  • Disabled Cleared—The alarm feature is disabled for the item, so no alarms can be raised. The item is in a state that corresponds to an Unacknowledged Cleared alarm—if the alarm feature was enabled, there would be an unacknowledged but cleared alarm.
  • Disabled Acknowledged—The alarm feature is disabled for the item. The item is in a state that corresponds to an Acknowledged Uncleared alarm—if the alarm feature was enabled, there would be an acknowledged but uncleared alarm.

A fleeting alarm is an alarm that only exists for the instant that an abnormal condition occurs. A fleeting alarm typically indicates an abnormal occurrence that is not associated with a specific state. As such, the database item that is in alarm cannot return to a particular state to indicate that the abnormal occurrence no longer exists (for example, a protocol error on an outstation).

Where an alarm can be fleeting, one of these states may be displayed:

  • Enabled Active Fleeting—The alarm feature is enabled for the item and a fleeting alarm existed at the instant that the Status display was viewed, last refreshed, or at the time that ClearSCADA was last able to retrieve the item’s data.
  • Disabled Active Fleeting—The alarm feature is disabled for the item, so no alarms can be raised. At the instant that the Status display was viewed or refreshed, the item was in a state that corresponded to an active fleeting alarm.

A state other than Enabled Inactive is appended with the date and time at which the change in alarm status occurred:

Example:

Enabled Cleared at Mar/19/2009 10:32:27.171

If the item is in an Acknowledged Uncleared alarm state, the name of the logged on user at the time the alarm was acknowledged is included. Comment details are included if the alarm was acknowledged using the Acknowledge with Comment pick action.

Example:

Enabled Acknowledged by RJones at Mar/19/2009 13:35:56.875, comment "Maintenance engineer notified”

Other information is displayed if the item is in an alarm state, and the ability to acknowledge the alarm is restricted to another User, User Group, or ViewX workstation (see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection).

Example:

Enabled Active at Mar/19/2009 14:34:01.542 Responsible user "USERS.User Groups.Duty Engineers”
(Indicating that the alarm can only be acknowledged by a user that belongs to the ‘Duty Engineers’ User Group.)

Alarm suppression can be used to help prevent a ‘flood’ of alarms (see Alarm Suppression in the ClearSCADA Guide to Alarms). With any ‘child’ alarms that are suppressed while a ‘parent’ alarm is active, the child item’s alarm status indicates this suppression.

Example:

Enabled Active at Mar/16/2009 10:59:00.758 (Suppressed)


ViewX and WebX Clients Guide - Favorites

Favorites

If your user account provides access to the Favorites Bar, you can use ClearSCADA’s Favorites feature to store links to those displays that you frequently need to access. The links that you can store are not just limited to those to ClearSCADA displays; you can also store links to external documents and web pages.

The following sections explain how to:

  • Add a ViewX Display to your Favorites List
  • Add an External File to your Favorites List
  • Add a Web Page to your Favorites List
  • Update the URL of a Link in your Favorites List
  • Add a Folder to your Favorites List
  • Rename a Link or Folder in your Favorites List
  • Delete a Link or Folder from your Favorites List
  • Use the Organize Favorites Window to Organize your Favorites List
  • Access and Display your Favorites.


ViewX and WebX Clients Guide - Add a ViewX Display to your Favorites List (Favorites)

Add a ViewX Display to your Favorites List

You can add entries for many types of ViewX display to your Favorites List. Once a display’s link has been added to your Favorites List, you can use the link to access that display via the Favorites Bar. You can also add entries to your Favorites List that allow you to view multiple ViewX displays simultaneously.

To add single or multiple Trends, Mimics, Reports, and/or Lists to your Favorites List:

  1. Use the Database Bar to locate the ViewX display(s) that you want to add to your Favorites List.
  2. Double-click on each item you require (for example, a Trend).
    The item (for example, a Trend) is displayed.
  3. If you want to:
  • Add an entry for a single ViewX display to your Favorites List, go to step 4.
  • Add an entry to your Favorites List that enables you to display several ViewX displays simultaneously, either:
  • Display any inset windows that you require. (Inset windows can be displayed from Mimics that include hyperlinks which allow other displays to be shown in separate windows that overlay the original Mimic.)

Or:

  • If your user account allows you to display more than one ‘document’ (display) simultaneously in ViewX, display any inset windows and/or repeat steps 1 and 2 until the other required displays are open in ViewX.

NOTE: Be aware that a WebX client can only display one window at a time. As such, any Favorites that comprise multiple windows, or both window(s) and inset windows, will be unavailable for display in WebX.

  4. Ensure that the window(s) are sized and ordered in the way that you want ClearSCADA to display them whenever you select the Favorite from your Favorites List.

(If necessary, organize the windows manually, or use the options on the Window menu. (The Windows menu is only available if your user account allows you to display multiple ‘documents’ simultaneously in ViewX.))

  5. Either:
  1. Select the Favorites menu.
    A drop-down menu is displayed.
  2. Select the Add to Favorites option.

Or:

  1. Select the Favorites button [image] to display the Favorites Bar.
    (For other ways of displaying the Favorites Bar, see Display an Explorer Bar in ViewX.)
  2. Select the Add button at the top of the Favorites Bar.

The Add Favorite window is displayed.

  6. Optionally use the Name field to rename the entry. The text in this field is the text that will appear as an entry in the Favorites menu and your Favorites Bar.
  7. Use the Type field to specify how many of the windows that are presently on display in ViewX are to be included in the new entry in your Favorites List.

Choose from:

  • Current Window Only—This is the default option. Only the window that is currently selected in ViewX will be displayed whenever you select this Favorite from your Favorites List or the Favorites menu.
  • Current Window and Insets—The window that is currently selected in ViewX, along with any of its inset windows, will be displayed whenever you select this Favorite from your Favorites List or the Favorites menu.

Ensure that you select the ‘source’ window before selecting Current Window and Insets, so that both that window and the inset windows that are currently on display are included as the Favorites entry. (If an inset window is the currently selected window, only that inset window will be displayed whenever the Favorite is selected from the Favorites List or Favorites menu. (The ‘source’ window and any other currently displayed inset windows will be omitted from the Favorites entry.))

Mimics can include hyperlinks that allow access to other displays, either in place of the original Mimic, or in inset windows that overlay the Mimic. You can display inset windows in addition to the ‘source’ window (the Mimic from which the inset windows have been displayed) regardless of whether your user account allows you to display multiple documents in ViewX.

Example:

A Mimic is displayed in ViewX, along with its inset window of a Calendar.

The ‘source’ window (the Mimic from which the inset window has been displayed) is the currently selected window.

The Current Window and Insets option is used to add the displays to Favorites. Whenever the Favorites entry is selected, both the Mimic and its inset window are displayed. The windows are sized and positioned as they were when the entry was added to Favorites.

  • All Windows—All of the windows that are currently on display in ViewX will be displayed whenever you select this Favorite from your Favorites List or the Favorites menu.

This option is only applicable if your user account allows you to display multiple ‘documents’ (Mimics, Trends, and so on) in ViewX.

Example:

Two Mimics, a Logic diagram, and a pre-configured Trend are displayed in ViewX.

The All Windows option is used to add the displays to Favorites. Whenever the Favorites entry is selected, all of the windows are displayed. The windows are sized, positioned, and ordered as they were when the entry was added to Favorites.

  8. In the Create In field, select the folder to which you want to add the new Favorite.

(Select the New Folder button if you want to create a new folder to hold the Favorite.)

  9. Select the OK button to confirm your settings and close the Add Favorite window.
    Your Favorites List will now include the entry that you have added
    Newly added entry.

The Favorites menu will also include an entry for the new Favorite display:

Newly added entry (in this case, for a pre-configured Trend).

Further Information

Add an External File to your Favorites List.

Add a Web Page to your Favorites List.


ViewX and WebX Clients Guide - Add an External File to your Favorites List (Favorites)

Add an External File to your Favorites List

You can add files from third party applications to your Favorites List. This allows you to access any of your Favorite displays from the ViewX Favorites List, not just ViewX displays.

To add a link to a Microsoft® Word document:

  1. Size the ViewX and Windows Explorer windows so that you can see ViewX and the document (in the Windows Explorer window) at the same time.
  2. Select the document in Windows Explorer. Do not release the left-hand mouse button.
  3. Drag the document onto the Favorites Bar in the ViewX window.
  4. Release the left-hand mouse button.
    A link to the Word document is added to your Favorites List. The link displays the full path of the document.
  5. If required, rename the link (see Rename a Link or Folder in your Favorites List), so that it has a shorter, but meaningful name.
    Newly added entry.


ViewX and WebX Clients Guide - Add a Web Page to your Favorites List (Favorites)

Add a Web Page to your Favorites List

You can add web page links to your Favorites List. This allows you to access frequently used Internet or intranet sites from the ViewX Favorites List.

To add a link to a web site:

  1. Use Internet Explorer to open the web site for which you want to add a link.
  2. Re-size the Internet Explorer window and the ViewX window so that you can see the Favorites List in the ViewX window and the Address field of the Internet Explorer window simultaneously.
  3. Select the Internet Explorer icon next to the address on the Internet Explorer window. Do not release the left-hand mouse button.
    Internet Explorer icon.

  4. Drag the Internet Explorer icon onto the Favorites List in the ViewX window. (To add the icon to a folder in your Favorites List, drag the icon onto the relevant folder.)
  5. Release the left-hand mouse button.
    A link to the web site is added to your Favorites List.
    Newly added entry.


ViewX and WebX Clients Guide - Update the URL of a Link in your Favorites List (Favorites)

Update the URL of a Link in your Favorites List

By default, the links that you add to your Favorites List have a Name and a full path URL. These values are shown on the Favorites Properties dialog, which you can use to:

  • View the full path URL of a link in your Favorites List
  • Change the URL of a link in your Favorites List. If the location of a target file or web page changes or is incorrect, you can use the Favorites Properties dialog to update the link with the new location.
  • Allocate a concise, meaningful name to the link. This is particularly useful when a URL is long and not particularly descriptive of the target file or web page. Renaming a link does not affect the URL of the link.

To view or update the URL of a link in your Favorites List:

  1. Right-click on the link in your Favorites List.
    A context sensitive menu is displayed.
  2. Select the Properties option.
    The Favorite Properties window is displayed, showing both the name of the link and its URL.

If required, you can change the URL and/or rename the link to that URL:

  1. Overtype the existing URL and/or Name.
  2. Select OK to confirm the change and update the entry in your Favorites List and the Favorites menu.

Further Information

Add an External File to your Favorites List

Add a Web Page to your Favorites List

Rename a Link or Folder in your Favorites List.


ViewX and WebX Clients Guide - Add a Folder to your Favorites List (Favorites)

Add a Folder to your Favorites List

Ideally, you should organize the links in your Favorites List, so that they are grouped in folders. This improves the efficiency of the Favorites feature, as it allows you to structure your links into logical groups, rather than have the entries appear in a long list.

To add a folder to your Favorites List, either:

  1. Right-click on an entry in your Favorites List. (To add a folder to another folder, right-click on the existing folder.)
    A context sensitive menu is displayed.
  2. Select the New Folder option.
    A new folder is added to your Favorites List. The folder is selected automatically, ready for you to define its name.

Or:

  • Use the Organize Favorites window to add a folder to your Favorites List and/or move some of your Favorites into that folder (see Use the Organize Favorites Window to Organize your Favorites List).


ViewX and WebX Clients Guide - Rename a Link or Folder in your Favorites List (Favorites)

Rename a Link or Folder in your Favorites List

When you add a link to your Favorites List, it automatically includes its full address. This can result in links with names that are excessively long.

You can use the Rename feature to change the names of links so that they are more usable. Ideally, you should ensure that the names of links are concise but meaningful.

You can also rename any folders that you have added to your Favorites List.

To rename a link or folder, either:

  1. Right-click on the link or folder in your Favorites List.
    A context sensitive menu is displayed.
  2. Select the Rename option.
    The name of the link or folder is selected automatically, ready for you to edit it.
  3. Enter the new name.
  4. Press the Enter key or select another part of the interface to confirm the name change.

Or:

  • Use the Organize Favorites window to rename the link or folder (see Use the Organize Favorites Window to Organize your Favorites List).

Further Information

Update the URL of a Link in your Favorites List.


ViewX and WebX Clients Guide - Delete a Link or Folder from your Favorites List (Favorites)

Delete a Link or Folder from your Favorites List

You can delete a link or folder from your Favorites List if it is no longer required.

ATTENTION: If you delete a folder, the contents of that folder will also be deleted.

To delete a link or folder, either:

  1. Right-click on the link or folder.
    A context sensitive menu is displayed.
  2. Select the Delete option.
    The link or folder is removed from the Favorites List.

Or:

  • Use the Organize Favorites window to delete the link (see Use the Organize Favorites Window to Organize your Favorites List).

Or:

  1. Select the obsolete link or folder in your Favorites List.
  2. Press the Delete key on the keyboard.
    A message is displayed, asking you to confirm whether you want to delete the selected item.
  3. Select the Yes button to confirm the request.
    The link or folder is deleted from your Favorites List and the Favorites menu.


ViewX and WebX Clients Guide - Use the Organize Favorites Window to Organize your Favorites List (Favorites)

Use the Organize Favorites Window to Organize your Favorites List

You can use the Organize Favorites window to organize the entries in your Favorites List.

To organize your Favorites List using the Organize Favorites window:

  1. Either:
  1. Ensure that the Favorites Bar is displayed.
  2. Select the Organize button at the top of the Favorites Bar.

Or:

  1. Select the Favorites menu.
    A drop-down menu is displayed.
  2. Select the Organize Favorites option.

The Organize Favorites window is displayed. A copy of your Favorites List is displayed in the field on the right-hand side of the window. (Click on a folder if you want to display the contents of that folder.)

You may need to re-size the Organize Favorites window to view the complete names of your Favorites. To re-size the window, select one of its edges, and keeping the left-hand mouse button pressed down, drag the cursor in the required direction. When you release the mouse button, the window is resized.

  2. Use the Organize Favorites window to perform any of the following:
  • Add a New Folder—Use the New Folder button to add a new folder in which to store some Favorites.
    A new folder is added to the Favorites List tree-structure (shown in the list on the right-hand side of the Organize Favorites window). The folder is selected automatically, ready for you to define its name.

Type in the name of the folder. Press the Enter key on the keyboard, or select another part of the interface, to confirm the name entry.

  • Rename a Folder or Link—Select a link or folder from the list on the right-hand side of the window, then select the Rename button.

Type in the new name, then press the Enter key, or select another part of the interface, to confirm the name entry.
The link or folder will display the new name.

  • Move a Folder or Link—Select the link or folder that you want to move. Do not release the left-hand mouse button. Drag the link over to its required position in the Favorites tree-structure and release the mouse button.

Example:

To move a link into a folder, drag the link onto the required folder. The link is placed in the selected folder.

To move a link out of a folder, drag the link from its present location to its new position (either the root of the Favorites tree-structure, or another folder). The link is moved to its new location.

Alternatively, select the link or folder that you want to move and then select the Move button.
The Browse for Folder window is displayed.

Use the window to select the required location for the folder or link, then select the OK button.
The link is moved to the new location.

  • Delete a Folder or Link—Select an obsolete link or folder, then select the Delete button.
    A confirmation window is displayed.

Select the Yes button to delete the link or folder.
The link or folder is removed from the Favorites List.

ATTENTION: If you delete a group, its contents are also deleted.

You can also delete an obsolete link or folder by selecting the link or folder, then pressing the Delete key on the keyboard. Again, a confirmation window is displayed, asking you to confirm the deletion.

  3. Once you have finished organizing the entries in your Favorites List, select the Close button on the Organize Favorites window.
    The window is closed. Your Favorites List and the entries in the Favorites menu are updated in line with your changes.


ViewX and WebX Clients Guide - Access and Display your Favorites (Favorites)

Access and Display your Favorites

Use either of these methods to access your Favorites and display the required ViewX display, external file, or web page:

  1. Use the Favorites Menu to Access your Favorites.
  2. Use the Favorites Bar to Access your Favorites.


ViewX and WebX Clients Guide - Use the Favorites Menu to Access your Favorites (Favorites)

Use the Favorites Menu to Access your Favorites

To use the Favorites menu to access your Favorites:

  1. Select the Favorites menu.
    A drop-down menu is displayed. The options that are displayed below the command separator line correspond to the folders and links that you have added to your Favorites List.
    Standard menu options that allow you to add items to your Favorites List and organize the entries in that List.
    Menu options produced by adding items and folders to your Favorites List. Select one of these options to display a particular Favorite.
    Favorites menu.

  2. Select the option that you require.
    If the option represents a link, the associated document or web page is displayed.

If the option represents a folder in your Favorites List, a further menu is displayed. Select the required entry from that menu. (If that menu contains options that represents further folders, repeat the process until you select the option that represents the link that you require.)

An arrow indicates that further menu level(s) are available.


ViewX and WebX Clients Guide - Use the Favorites Bar to Access your Favorites (Favorites)

Use the Favorites Bar to Access your Favorites

To access your Favorites via the Favorites Bar:

  1. Select the Favorites button [image] on the Operate toolbar.
    The Favorites Bar is displayed.

(For other ways of displaying the Favorites Bar, see Display an Explorer Bar in ViewX.)

  2. Either:
  1. Select the required link from the Favorites List.

Or:

  1. Select the required folder.
    The tree-structure expands to show the contents of that folder.
  2. Select the required link from the folder.
    (If the folder contains subfolders, repeat the above step as required.)

The item represented by the selected link is displayed.


ViewX and WebX Clients Guide - Operator Document Stores

Operator Document Stores

Typically, a user that logs on via an operator level user account does not have the Configure Database permission and so can only view and operate the items in the database. The Operator Document Store feature allows an operator level user to create and edit certain types of documents, such as Trends, and save them in the operator document store. These documents can then be viewed and edited by any user with access to the operator document store.

The documents that are created in the user’s operator document store are stored in a specially partitioned area of the database. Operator level users can only add documents to the operator document stores and edit the documents via the Operator Documents Bar.

Each user account can be associated with up to six Operator Document Stores—one for their individual user account, one for the system, and up to four for their User Groups (one for each User Group). Your user account is associated with your Operator Document Stores by a high level engineer with the permissions to configure the database.

You can access the contents of your Operator Document Store(s) from either a ViewX client or a WebX client (see Access Your Operator Document Stores).

A ViewX Client provides additional functionality to a WebX Client, allowing you to manage, as well as access, your Operator Document Store(s). From a ViewX client, you can:

  • Create a New Document in an Operator Document Store
  • Add a Copy of a Document to your Operator Document Store
  • View a Document in your Operator Document Store
  • Edit a Document in your Operator Document Store
  • Rename a Document in your Operator Document Store
  • Delete a Document in your Operator Document Store
  • Export a Document from your Operator Document Store
  • Import a Document into your Operator Document Store
  • Save a Copy of a Document into an Operator Document Store
  • Organize your Operator Document Stores.


ViewX and WebX Clients Guide - Access Your Operator Document Stores (Operator Document Stores)

Access Your Operator Document Stores

Your user account can be associated with up to six Operator Document Stores: one store for the Root Group, one store for each User Group (up to a maximum of four), and one store for your user account. Your user account is associated with Operator Document Stores by a higher level user during the configuration process.

From a ViewX Client, you can add, edit, rename, delete, import and export any of the documents that are stored in your Operator Document Stores. However, before you can work with the documents, you first have to access your Operator Document Stores.

To access the Operator Document Stores that are associated with your user account:

  1. Log on to ViewX.
  2. Display the Operator Documents Bar (see Display an Explorer Bar in ViewX).

(If the options for displaying the Operator Documents Bar are unavailable, it means your user account has not been associated with any Operator Document Stores or your user account does not have the Configure permission for the Operator Document Stores database items.)

  3. Expand the hierarchy in the Operator Documents Bar to view the Operator Document Stores to which you have access. You can add documents such as Trends to the Operator Document Stores. You can also edit, rename, delete, import or export any of the documents in the Operator Document Stores.

You can also Access Your Operator Document Stores on a WebX Client, but can only manage your Operator Document Stores from a ViewX client.

Further Information

Create a New Document in an Operator Document Store

Add a Copy of a Document to your Operator Document Store

View a Document in your Operator Document Store

Edit a Document in your Operator Document Store

Rename a Document in your Operator Document Store

Delete a Document in your Operator Document Store

Export a Document from your Operator Document Store

Import a Document into your Operator Document Store

Save a Copy of a Document into an Operator Document Store

Organize your Operator Document Stores.


ViewX and WebX Clients Guide - Create a New Document in an Operator Document Store (Operator Document Stores)

Create a New Document in an Operator Document Store

You can create a new document such as a Trend in any of the Operator Document Stores to which you have access. You can then configure the new document as required. Any other users that also have access to the Operator Document Store can also configure the new document.

To add a new document to one of your Operator Document Stores:

  1. Log on to ViewX.
  2. Display your Operator Document Stores (see Access Your Operator Document Stores).
  3. Right-click on the Operator Document Store that is to contain the new document (or right-click on the Group within an Operator Document Store that is to contain the new document).
    A context sensitive menu is displayed.
  4. Select the New option for the type of document you wish to create. For example, if you want to create a new Trend, select the New Trend option.
    The new document is added to the selected Operator Document Store. It is selected automatically, ready for you to define its name.
  5. Enter a suitable name for the document, then press the Enter key or select another part of the interface to confirm your entry.

When you have added a new document to an Operator Document Store, you can configure it by using the Edit option (see Edit a Document in your Operator Document Store).


ViewX and WebX Clients Guide - Add a Copy of a Document to your Operator Document Store (Operator Document Stores)

Add a Copy of a Document to your Operator Document Store

You can add a copy of a document such as a Trend to any of the Operator Document Stores to which you have access. You can then configure the copy of the document as required. Any other users that also have access to the Operator Document Store can also configure the copy of the document.

To add a copy of a document to one of your Operator Document Stores:

  1. Log on to ViewX.
  2. In the Database Bar, locate the document that you want to add to one of your Operator Document Stores, then display it. For example, if you want to add a copy of a Trend named ‘River Level’ to your Operator Document Store, display the ‘River Level’ Trend.
  3. Select the File menu, then select the Save in Operator Documents option.
    The Save in Document Store window is displayed.
  4. Use the Save in Document Store window to define the name of the document copy and specify its location in your Operator Document Stores:
  1. In the Name field, enter a suitable name for the document copy.
  2. Use the Create In combo box to select the Operator Document Store that is to contain the copy of the document.

If you want to place the copy in a Group within one of your Operator Document Stores, select the required Operator Document Store in the combo box, then select the >> button to display the hierarchy.

  • Use the New Group button to create a hierarchy of Groups as required. Then select the Group that is to contain the copy of the document.
  5. Select the OK button to confirm your selections and save a copy of the document in the selected Operator Document Store.

When you have added a copy of a document to an Operator Document Store, you can edit it, rename it, export it, and so on.


ViewX and WebX Clients Guide - View a Document in your Operator Document Store (Operator Document Stores)

View a Document in your Operator Document Store

You can access the contents of your Operator Document Store(s) from either a ViewX Client or a WebX Client. However, you can only manage the contents of your Operator Store(s) from a ViewX client.

To display a document that is stored in one of your Operator Document Stores:

  1. Log on to ViewX.
  2. Display your Operator Document Stores (see Access Your Operator Document Stores).
  3. Expand your Operator Document Stores until you locate the document that you want to display.
  4. Either:
  • Right-click on the document, then select the Display option from the context sensitive menu.

Or:

  • Double-click on the document.

The document is displayed.

When you have displayed a document in ViewX, you can toggle it between Run mode and Design mode in the same way as an engineer level user (a user with the Configure Database permission for a wide range of database items).

When you display a document such as a Trend in Design mode, you can access the configuration features that are normally restricted for use by engineer level users. For more information on how to configure your document, please refer to the documentation that describes the configuration process for the type of item. For example, if you have displayed a Trend, refer to the ClearSCADA Guide to Trends for information on how to configure the Trend.

For information on accessing an operator document from WebX, see Access Your Operator Document Stores on a WebX Client.


ViewX and WebX Clients Guide - Edit a Document in your Operator Document Store (Operator Document Stores)

Edit a Document in your Operator Document Store

You can edit any document that is stored in your Operator Document Store(s), even if your user account does not have the Configure Database permission. As long as you have access to an Operator Document Store, you can configure the documents that are stored within it.

To configure a document that is stored in your Operator Document Store:

  1. Log on to ViewX.
  2. Display your Operator Document Stores (see Access Your Operator Document Stores).
  3. Expand your Operator Document Stores until you locate the document that you want to configure.
  4. Either:
  • Right-click on the document, then select the Edit option from the context sensitive menu.

Or:

  • Double-click on the document.

The document is displayed in Design mode.

The configuration features are available for the documents that are stored in your Operator Document Stores.

When you display a document such as a Trend in Design mode, you can access the configuration features that are normally restricted for use by engineer level users. For more information on how to configure your document, please refer to the documentation that describes the configuration process for the type of item. For example, if you have displayed a Trend, refer to the ClearSCADA Guide to Trends for information on how to configure the Trend.

NOTE: If another user is editing the document at the same time as you, you will be prompted to choose between discarding the changes you made or keeping the changes you made and overwriting the changes made by the other user(s).


ViewX and WebX Clients Guide - Rename a Document in your Operator Document Store (Operator Document Stores)

Rename a Document in your Operator Document Store

You can rename any of the documents that are stored in your Operator Document Store(s). This is useful when a document has been provided with a misleading name or there is a mistake in the name.

To rename a document in your Operator Document Store:

  1. Log on to ViewX.
  2. Display your Operator Document Stores (see Access Your Operator Document Stores).
  3. Expand your Operator Document Stores until you locate the document that you want to rename.
  4. Right-click on the document, then select the Rename option from the context sensitive menu.
    The document is selected automatically, ready for you to define its name.
  5. Overwrite or amend the existing name as required, then press the Enter key or select another part of the interface to confirm your entry.


ViewX and WebX Clients Guide - Delete a Document in your Operator Document Store (Operator Document Stores)

Delete a Document in your Operator Document Store

You can delete any document or Group of documents stored in your Operator Document Store. This is useful when you have documents that are no longer required.

To delete a document from your Operator Document Store:

  1. Log on to ViewX.
  2. Display your Operator Document Stores (see Access Your Operator Document Stores).
  3. Expand your Operator Document Stores until you locate the document or Group that you want to delete.
  4. Either:
  • Select the document or Group in the tree-structure, then press the Delete key

Or:

  • Right-click on the document or Group, then select the Delete option from the context sensitive menu.

Or:

  • Select the document or Group in the tree-structure, then select the Edit menu, then select the Delete option.
    If you are deleting a single document, the document is deleted.

If you are deleting a Group, you are reminded that deleting the Group will also delete the documents in the Group—select Yes to delete the Group and its documents or select No to abort.


ViewX and WebX Clients Guide - Export a Document from your Operator Document Store (Operator Document Stores)

Export a Document from your Operator Document Store

You can export any document that is stored in your Operator Document Store or even the Operator Document Store itself. When you have exported a document or Operator Document Store, the export is saved as a file. This file can then be imported into another system (a document can be imported as a ‘normal’ database item in the Database Bar or can be imported as an operator document in another Operator Document Store).

To export a document from your Operator Document Store:

  1. Log on to ViewX.
  2. Display your Operator Document Stores (see Access Your Operator Document Stores).
  3. Expand your Operator Document Stores until you locate the document that you want to export.
  4. Right-click on the document in the tree-structure, then select the Export option from the context sensitive menu.
    The Export Item window is displayed.
  5. Use the Export Item window to:
  • Define the Name of the export file
  • Specify the Version of the export file. You need to choose the version of ClearSCADA that is running on the server (system) on which you want to import the export files.

(The window’s Save As type field is pre-set to Export.)

  6. Select the Save button to save the Operator Document Store or document as an export file and close the Export Item window.

You can now import the export file on another system as required.


ViewX and WebX Clients Guide - Import a Document into your Operator Document Store (Operator Document Stores)

Import a Document into your Operator Document Store

You can import any compatible document into any of your Operator Document Stores. This is useful when you need to transfer operator documents between systems or need to import operator documents that have been created by other users and saved as export files.

To import a document into your Operator Document Store:

  1. Log on to ViewX.
  2. Display your Operator Document Stores (see Access Your Operator Document Stores).
  3. Expand your Operator Document Stores until you locate the Group that you want to contain the imported document(s).
  4. Right-click on the Group in the tree-structure (or any of the documents that are stored in the Group), then select one of these options:
  • Import—Use this option to import a document. If the import file contains a document that has the same name as a document that already exists in your Operator Document Store, the import document will have its name changed automatically so that the existing document is not overwritten.
  • Import & Merge—Use this option to import a document. If the import file contains a document that has the same name as a document that already exists in your Operator Document Store, the imported document will overwrite your existing document.

The Import From window is displayed.

  5. In the Import Item window, locate the export file that you want to import, select it, then select the Open button.
    The selected export file is imported and the Import From window is closed.


ViewX and WebX Clients Guide - Save a Copy of a Document into an Operator Document Store (Operator Document Stores)

Save a Copy of a Document into an Operator Document Store

For information on using the Save in Operator Documents option, see Add a Copy of a Document to your Operator Document Store.


ViewX and WebX Clients Guide - Organize your Operator Document Stores (Operator Document Stores)

Organize your Operator Document Stores

You can create Group folders in your Operator Document Stores. The Group folders allow you to organize your Operator Document Stores so that your documents are stored in a hierarchy of suitably named groups.

To create a Group in an Operator Document Store:

  1. Log on to ViewX.
  2. Display your Operator Document Stores (see Access Your Operator Document Stores).
  3. Right-click on the Operator Document Store or Group to which you want to add a Group.
    A context sensitive menu is displayed.
  4. Select the New Group option.
    A new Group is added to the Operator Document Store. It is selected automatically, ready for you to define its name.
  5. Enter a suitable name for the Group then press the Enter key or select another part of the interface to confirm your entry.
  6. Move documents into the new Group by selecting them in the Operator Document Store tree-structure and dragging them into the Group. Similarly, you can move documents out of the Group using the same technique.
    Operator Documents organized into a hierarchy of Groups.

ATTENTION: Deleting a Group will delete the Group and the documents that are stored in the Group (see Delete a Document in your Operator Document Store).


ViewX and WebX Clients Guide - Send a Message to a User on another ViewX Client

Send a Message to a User on another ViewX Client

You can use the Notify User menu option to send a message or request to a user on another ViewX Client. This feature is useful, for example, if you want to ask another user to send a control to an item to which you do not have access or the relevant security permission.

To send a message to another user:

  1. Either:
  • Right-click on the relevant user account entry in the Database Bar, or on a Queries List such as the Users List (see Lists).

or:

  • Click on the user account entry on a Mimic (if a suitable Mimic exists on your system). The user account entry has to be configured to display an Object menu, or at least provide access to the Notify User option.

The user account’s Object Menu is displayed.

  2. Select the Notify User option.
    The Notify User window is displayed.
  3. In the Title field, enter a suitable title for your message. You can enter up to 256 alphanumeric characters, or leave the field empty if no title is required.
  4. In the Message field, enter the content of your message. Ensure the message is concise but clear. You can enter up to 256 alphanumeric characters. This field has to contain some content before the message can be sent to another user.
  5. Select the OK button to close the Notify User window and send the message to the user.
    The message appears in a window on the ViewX client onto which the recipient is logged. (If the intended recipient is not logged on to a ViewX client, the sender is notified when they attempt to send the message to that user.)

An entry is added to the Events List whenever a message is sent successfully. The entry includes the message’s content, sender and recipient.

NOTE: On some systems, Global scripts might be used to control how the messages are handled. For information, see User Messaging Functions in the ClearSCADA Guide to Scripting.


ViewX and WebX Clients Guide - Terminology

Terminology

This section explains the terms that you may come across in the ClearSCADA Guide to ViewX and WebX Clients and elsewhere in the ClearSCADA documentation suite.


ViewX and WebX Clients Guide - Client (Terminology)

Client

A computer that connects to, and displays information retrieved from, a Server.

Users typically operate ClearSCADA via ViewX Clients or WebX Clients.


ViewX and WebX Clients Guide - Database Item (Terminology)

Database Item

An item (or ‘object’) in the ClearSCADA Database, which contains configuration information.

You can use ViewX’s Database Bar to display a tree structure showing the database items that exist on your system.


ViewX and WebX Clients Guide - Driver (Terminology)

Driver

A driver provides additional support to enable ClearSCADA to communicate with other devices (such as Outstations and PLCs) using a particular communications protocol. Your ClearSCADA system might have a number of drivers installed. For more information, see Types of Driver in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - I/O (Terminology)

I/O

Input / Output.

ClearSCADA uses Points in the database to represent the I/O on site and any I/O that exists internally in the software.


ViewX and WebX Clients Guide - LAN (Terminology)

LAN

Local Area Network.


ViewX and WebX Clients Guide - ODBC (Terminology)

ODBC

Open Database Connectivity.

ODBC is an application programming interface that allows data to be transferred between ODBC-compliant applications. Depending on the configuration and system setup, a third-party ODBC client might be used to access the ClearSCADA database or, if ClearSCADA’s ODBC driver is installed, ClearSCADA might be used to interrogate the database of another ODBC-compliant application.


ViewX and WebX Clients Guide - OPC (Terminology)

OPC

OLE for Process Control. A set of standard specifications aimed at allowing communication between different SCADA systems (for more information, see http://www.opcfoundation.org/).

Depending on the configuration and system setup, a third-party OPC client might be used to access the ClearSCADA database or, if ClearSCADA’s OPC or OPC XML-DA driver is installed, ClearSCADA might be used to read or write to another application’s database, using OPC.

If your user account provides the necessary access, you can use ViewX’s OPC Data Bar or OPC Historic Data Bar to access the OPC properties of various items in the database (see Working with the OPC Data Bar in the ClearSCADA Guide to Core Configuration, and see Working with the OPC Historic Data Bar in the ClearSCADA Guide to Core Configuration).


ViewX and WebX Clients Guide - Outstation (Terminology)

Outstation

An enclosed unit that contains I/O cards, communications equipment and a power supply. The I/O cards contain the inputs and outputs (I/O) that correspond to the connections to Plant. ClearSCADA uses Points to represent the I/O in the database.

RTUs, PLCs and similar devices tend to be referred to as ‘outstations’ throughout much of the ClearSCADA documentation suite. For more information, see Outstations and Outstation Sets in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - Pick Action (Terminology)

Pick Action

Your user account will allow you to perform various actions on items in the database. You typically perform such actions by selecting options (or ‘pick actions’) from a context sensitive Object Menu.

The Mimics on your system might be configured to allow you to display context sensitive menus in order to select the pick actions you require. Where an area of a Mimic is configured to allow users to trigger just one specific pick action, that pick action might be configured to trigger immediately on selection, without a context sensitive menu being displayed. (For more information, see the ClearSCADA Guide to Mimics.)

Some pick actions on your system might be configured to trigger automatically on a scheduled basis, or in response to alarms being raised.


ViewX and WebX Clients Guide - Plant (Terminology)

Plant

A generic term to describe equipment such as sensors, gauges, and so on.

In ClearSCADA you use Database Items, such as Outstations and Points, to represent, monitor and/or control plant.


ViewX and WebX Clients Guide - PLC (Terminology)

PLC

Programmable Logic Controller.

RTUs, PLCs and similar devices tend to be referred to as ‘outstations’ throughout much of the ClearSCADA documentation suite. For more information, see Outstations and Outstation Sets in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - Point (Terminology)

Point

In the ClearSCADA database, points are used to represent the sensors, measuring instruments and control devices on your system. Points allow the corresponding Plant to be measured or controlled from the ClearSCADA Server. For further information, see Points and Pulse Actions in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - PSTN (Terminology)

PSTN

Public Switched Telephone Network.

For further information, see Systems with PSTN Communications in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - RTU (Terminology)

RTU

Remote Telemetry Unit.

RTUs, PLCs and similar devices tend to be referred to as ‘outstations’ throughout much of the ClearSCADA documentation suite. For more information, see Outstations and Outstation Sets in the ClearSCADA Guide to Drivers.


ViewX and WebX Clients Guide - SCADA (Terminology)

SCADA

Supervisory Control and Data Acquisition. ClearSCADA is a SCADA application, providing the means to retrieve data and control the Plant on your system (see What is ClearSCADA?).


ViewX and WebX Clients Guide - Server (Terminology)

Server

A computer that stores data and is capable of supplying the stored data to other computers (Clients). For further information, see ClearSCADA Server.


ViewX and WebX Clients Guide - SQL (Terminology)

SQL

Structured Query Language.

The ClearSCADA server uses SQL to query the database for current and historic data values. ClearSCADA uses an SQL query, for example, to obtain the data values that are displayed in Lists other than Alarms Lists.


ViewX and WebX Clients Guide - Toolbar (Terminology)

Toolbar

A row of buttons displayed below the ViewX client title bar (see Toolbars). Each button performs a specific action.


ViewX and WebX Clients Guide - WAN (Terminology)

WAN

Wide Area Network.


Core Configuration Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Core Configuration Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Core Configuration Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Core Configuration Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Core Configuration Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Core Configuration Guide - Document Scope (About the Guide)

Document Scope

This guide explains the various configuration practices and procedures with which you need to be familiar in order to configure the ClearSCADA database.

The guide also includes information about:

  • ClearSCADA’s system and state colors
  • Configuring non-driver-specific features, such as Schedules and Calendars.

For more information, see Introduction.

NOTE: For information relating to point configuration, see the ClearSCADA Guide to Core Point Configuration. For information about configuring features or points that are associated with a particular driver, see the relevant driver-specific guide.


Core Configuration Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for engineers who are responsible are configuring the ClearSCADA database.


Core Configuration Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Alarms

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Expressions

ClearSCADA Guide to Logic

ClearSCADA Guide to Trends

ClearSCADA Guide to Mimics

ClearSCADA Guide to Scripting

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Security

ClearSCADA Guide to the Database

ClearSCADA Guide to Drivers

ClearSCADA Guide to Lists

ClearSCADA Guide to ViewX and WebX Clients.


Core Configuration Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Core Configuration Guide - Introduction

Introduction

The ClearSCADA Guide to Core Configuration and associated core reference guides provide information about the configuration features that are not specific to a particular driver. Items that are not driver-specific are referred to as core database items, as they are part of the core ClearSCADA software. Other configuration features are driver-specific—they are only available if you have a specific driver installed, and are described in the relevant driver section.

The ClearSCADA Guide to Core Configuration is designed to be used in conjunction with other configuration documentation, for example, the ClearSCADA Guide to the Modbus Driver.

The core configuration topics that are covered in this guide include:

  • Topics associated with basic configuration practice and procedures, including:
  • Organizing and Configuring Your Database
  • Configuration Changes Auditing
  • Displaying an Editor
  • Working with the OPC Data Bar
  • Working with the OPC Historic Data Bar
  • Working with Forms
  • Groups
  • Group Templates and Group Instances
  • How to Restrict Alarm and Event Access to Specific Areas of Interest
  • Using the Add Action and Edit Method Windows
  • Specifying the Required Entry in a Date and Time Field
  • Using OPC Time Formats
  • Time Zone Support in ClearSCADA
  • Defining Identification Details
  • Using the User Methods Tab to Define Custom Actions
  • Defining a Default View
  • Defining an Item or Group’s Alarm Properties
  • Defining Severities
  • Defining the Format of Displayed Values
  • Requesting Confirmation of Action Requests
  • Converting a Database Item
  • Copying a Database Item
  • Renaming a Database Item
  • Deleting a Database Item
  • Displaying a Database Item’s References
  • Importing and Exporting Database Items
  • Checking for Invalid Configuration
  • Placing an Item In Service
  • Saving Configuration Changes
  • Downloading Configuration Changes.
  • Topics associated with defining the colors that are used in ClearSCADA:
  • System Colors
  • Defining a Custom State Color
  • Using the Color Window to Define a Color.
  • Configuration that is not driver-specific, including:
  • Stand-Alone Method Calls
  • Using Parameters to Store Static Data Values
  • Using Variables to Store Data Values
  • Configuring System Commands
  • Configuring Master Station Accumulators
  • Configuring Value Maps
  • Configuring Data Grids
  • Configuring Data Tables
  • Configuring Historic Calculations
  • Configuring Time Profiles
  • Configuring Forecasts
  • Using Schedules to Automate Regular Functions
  • Configuring Calendars
  • Setting up Operator Document Stores.


Core Configuration Guide - Terminology (Introduction)

Terminology

Throughout the documentation supplied with your ClearSCADA system, the term ‘database item’ is used to refer to any physical or internal object that you can include in your database, or any physical or internal object applicable to the context in which the term is mentioned. ‘Database items’ might include, for instance, outstations, outstation sets, communication channels, points, and timers.

The term ‘point’ is used to refer to any measuring instrument, sensor, or control device that is connected to an outstation, RTU, data logger, scanner or other such device.

The term ‘field’, when used in relation to Forms and tabs on Forms, is sometimes used as a general term to cover the various types of field that are used on Forms. This includes, for instance, check boxes, spin boxes, option buttons, combo boxes, and text entry fields. In the context of an actual field description or step-by-step procedure, the actual type of field is mentioned.


Core Configuration Guide - Organizing and Configuring Your Database

Organizing and Configuring Your Database

When first setting up or expanding an existing ClearSCADA system, you need to plan your requirements for the Database Structure and Database Security on your system. You should do this before you start any configuration within ClearSCADA. For a summary of the planning aspects that should consider, see Preparation.

Once the plan is in place, you can use various features within ClearSCADA to rapidly configure your database (see Add an Item to the Database).


Core Configuration Guide - Preparation (Organizing and Configuring Your Database)

Preparation

With ClearSCADA, you can:

  • Keep a detailed record of the property changes made on your system (see Configuration Changes Auditing).
  • Add and configure each item independently to other items on your system (for instance, you can add and configure one Alarm Redirection Action, and then add and configure another Alarm Redirection Action).
  • Use the Group Templates and Group Instances feature to reduce configuration effort. Consider whether to use this feature if the physical structure of your system can be split into ‘modules’. With such a structure, you can use Group Templates to produce the base configuration for a generic ‘module’. Within each Template, you can include items such as outstations, scanners, and points that have the base configuration for the items in each module. You can then use Group Instances to include the configuration that is specific to each ‘module’.

For more information, see Database Structure.

As part of the preparation before adding an item to the database, you need to consider:

  • ClearSCADA Naming Restrictions
  • Database Security
  • Time Zone Support in ClearSCADA
  • Colors used in ClearSCADA.

You might also want to consider using:

  • Alarm Redirection—Many items within the ClearSCADA database can raise alarms. You might want to redirect some of these alarms under particular circumstances. For instance, in order to automate a dial out to a PSTN outstation, or forward alarm announcements when a control center is unmanned. For further information, see Introduction to Alarm Redirection in the ClearSCADA Guide to Alarm Redirection.
  • Areas of Interest—You can restrict each user’s alarm and event access to just the alarms and events that are associated with specific area(s) of your system. Users are unaware of any alarms and events that are generated outside their allocated area(s) of interest. For more information, see Restrict Alarm and Event Access to Specific Areas of Interest.
  • Schedules—You can automate many activities that need to be undertaken on a regular basis, by associating those actions with Schedules. You can specify the times and regularity with which each Schedule triggers (see Using Schedules to Automate Regular Functions).

You also need to be familiar with the Basic Configuration Procedures and be logged onto the system as a user with the relevant permissions (see User Accounts in the ClearSCADA Guide to Security).

Many of the items that you configure in the database represent the plant, measuring instruments or control devices that are on your system. As such, much of the configuration of those database items needs to correspond to the settings that exist on, or that are supported by, those devices. In order to configure the database items successfully, you need to be aware of those settings.

Taking each of the above into consideration, should enable you to add and configure items rapidly and successfully in the ClearSCADA database (see Add an Item to the Database).


Core Configuration Guide - Database Structure (Organizing and Configuring Your Database)

Database Structure

You need to organize your database so that the tree-structure within the Database Bar is logical and user-friendly, and allows you and other users to locate items quickly. Typically, you should organize the database so that it reflects the physical structure of your system—for example, regions, control centers, outstations, and points.

To produce a multi-level tree structure that reflects the physical layout of your system, you need to organize your database into Groups. If your database structure is ‘modular’ and like-aspects of configuration are repeated throughout parts of your system, you should consider using one or more Group Templates to produce ‘model’ Group configuration. You then configure as many Group Instances as you require, to contain the groups of ‘live’ data. As each Instance inherits much of its configuration from a Group Template, this can considerably reduce configuration time. Within each Instance, ‘Instance-specific’ configuration is used to uniquely identify the ‘live’ data that is specific to that particular instance.

You can also use Abstract items within Group Templates to produce the base configuration for points or outstations, and then convert those Abstract items into specific point or outstation types within the Group Instances.

Example:

A ClearSCADA system might contain 50 outstations. Each outstation might monitor two analog values, have a digital input that monitors the open or closed state of a switch, and have a digital output that is used to control the state of that switch.

As much of the configuration for each outstation and its associated points is common to each outstation on the system, a Group Template can be configured to include the common configuration. Group Instances, which reference the Group Template, can then be configured to include both the common configuration (inherited from the Group Template) and the outstation- or point-specific configuration (such as an address or ID), that is unique to each Instance.

You can configure up to 12 levels of Groups, Group Templates, and Group Instances, and individual database items (such as points, outstations, and timers) within your database.

For further information, see, as appropriate:

  • Groups
  • Group Templates and Group Instances.

NOTE: We suggest that you place any User, User Group, and User Roster configuration in a separate ‘Users’ Group, off your system’s root directory. This will allow the user settings and permissions to be adjusted and updated when required, from the one location.


Core Configuration Guide - Database Security (Organizing and Configuring Your Database)

Database Security

At the planning stage, you need to consider database security. The ClearSCADA database can be ‘secured down’ so that users only have access to the features and areas of the database with which they need to work. ClearSCADA includes a variety of security features, including the need to log on to the system with a valid user name and password in order to gain access. You can also configure certain action requests so that users have to enter their logon password before ClearSCADA executes such requests (see Requesting Confirmation of Action Requests).

A User Account needs to have been allocated the Configure Database feature, in order to enable that user to configure items in the database (see Define the ViewX Configuration Settings for a User in the ClearSCADA Guide to Security).

Additionally, every item in the database is allocated a set of Permissions, which determine the level of security that is applied to that item. You can set permissions on a per Group or per item basis. For further information, see Allocating Security Permissions in the ClearSCADA Guide to Security.

You can also use the Area of Interest feature to restrict each user’s alarm and event access to only those alarms and events that are associated with particular area(s) of the system. Users are unaware of any alarms and events that are generated outside their allocated area(s) of interest. Area of Interest is an optional feature that is not enabled by default—for more information, see Restrict Alarm and Event Access to Specific Areas of Interest.


Core Configuration Guide - Colors used in ClearSCADA (Organizing and Configuring Your Database)

Colors used in ClearSCADA

ClearSCADA includes a series of default colors to denote different states, severities or system activities. Many of these colors can, if required, be changed so that they are more appropriate to your requirements. ClearSCADA includes color palettes for:

  • System Colors—Core and driver-specific colors that denote that an item is in a particular state, for example Overridden (see System Colors).
  • Alarm Severity Colors—Colors that indicate whether, for instance, an alarm has been acknowledged or cleared (see Alarm and Event Severities in the ClearSCADA Guide to Server Administration).
  • State Colors—A non-alarm state that needs to be brought to the attention of operators. For instance, the fact that a pump is running. For information, see Defining a Custom State Color.


Core Configuration Guide - Basic Configuration Procedures (Organizing and Configuring Your Database)

Basic Configuration Procedures

You can only configure items in the ClearSCADA database if your User Account is assigned the Configure Database feature and allocated the relevant security permissions (see Database Security).

You configure some types of database item by specifying properties on the relevant configuration Form (see Working with Forms). With other types of item, you configure the item using an Editor (see Displaying an Editor).

Sections within this guide explain the procedures for:

  • Adding an item to the database (see Add an Item to the Database)
  • Saving Configuration Changes
  • Copying a Database Item

On ClearSCADA systems that have multiple databases, you can use ClearSCADA’s Import and Export features to allow similar configurations to be duplicated between ClearSCADA databases that are not connected together (see Importing and Exporting Database Items).

  • Renaming a Database Item

You can include any alphanumeric characters in the name of an item in the ClearSCADA database. However, there are limitations to the overall length of the name (including the path to that name). There are also restrictions as to which non-alphanumeric Unicode characters you can include in a name. For further information, see Naming Restrictions.

  • Deleting a Database Item.

In order for outstations and their component parts (such as points) to communicate correctly with the ClearSCADA server, their database configuration has to be stored at the outstation. With some types of outstation, you can configure the data within ClearSCADA and then download that data to the outstation (see Downloading Configuration Changes). With outstations that do not support downloading, care needs to be taken to ensure that the same settings are configured in both the outstation and the ClearSCADA database.

WARNING

unexpected behavior of application

Do not make further configuration changes to an outstation or any of its dependants while a download is in progress to that outstation. Performing such changes may result in partially updated or corrupt configuration being downloaded to the outstation, or configuration changes not being flagged for download.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

Where a database item references another item (for instance, a point references the outstation on which it is located), you can display a list of those references (see Displaying a Database Item’s References). Be aware of these references should you move, copy, or delete an item in your database.

Further Information

Keep a detailed record of the property changes made on your system: see Configuration Changes Auditing.


Core Configuration Guide - Add an Item to the Database (Organizing and Configuring Your Database)

Add an Item to the Database

In order to create and configure an item in the database, you need to be logged on as a user that has the Configure Database feature enabled, and is allocated the relevant permissions (see User Accounts in the ClearSCADA Guide to Security). You also need to be aware of the Database Structure and Database Security requirements of your system, and have undertaken any necessary Preparation.

The primary means of accessing the database structure within ViewX is by using the Database Bar. This is one of the Explorer Bars that can be displayed in a pane to the left of the main ViewX work area (see Explorer Bars used in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).

To display the Database Bar if it is not visible, select the View menu, followed by the Explorer Bar option and then select the Database option.

To add an item to the database:

  1. On the Database Bar, right-click on the Group, or Group Template within which you want to add the item.
    A context-sensitive menu is displayed.
    Right-click on the Group or Group Template within which you want to add an item...
    ...select the New option...
    ...a context-sensitive menu is displayed. (The options vary, depending on the drivers on your system.)

  2. Select the New option.
    A further menu is displayed.

NOTE: To add a new Group Instance and associate that Instance with an existing Group Template, you select the New Instance option, rather than the New option. For more information, see Add a Group Instance.

  3. Select the menu option that is appropriate to the item that you want to create:

To add an item for a particular driver:

  1. Select the appropriate <Driver Name> option (for example, DNP3).
    A further context-sensitive menu is displayed.
  2. Select the type of item that you want to create (for example, a DNP3 Direct Channel).
    An item of the selected type is added to the ClearSCADA database. The entry is highlighted, ready for you to define its name.
  3. Give the item a suitable name (taking into account the ClearSCADA Naming Restrictions).

For information on the items that are supported by a particular driver and the order in which those items should be configured, see the driver-specific documentation.

To add a ‘core’ item:

  1. Select the appropriate menu option (for example, select ‘Alarm Redirection Action’ if you want to add a new redirection action to enable ClearSCADA to redirect alarms).
  2. In some cases, a further menu is displayed—select the appropriate option (for example, ‘E-Mail Action’ to add an e-mail redirection action).
    An item of the selected type is added to the ClearSCADA database. The entry is highlighted, ready for you to define its name.
  3. Give the item a suitable name (taking into account the ClearSCADA Naming Restrictions).

You can then configure the item in the database.

Some ClearSCADA database configuration is carried out using configuration Forms (see Working with Forms). A Form exists for every item in the database. This guide covers those aspects of Form-based configuration that are not specific to a particular driver, along with Basic Configuration Procedures. The ClearSCADA Guide to Point Configuration covers aspects of point configuration that are common to internal points and to points on many drivers.

Many items that you add to a ClearSCADA system will be driver-specific (they are only available if a specific driver, such as the DNP3 Driver, is installed). Refer to the relevant driver-specific guide for information on configuring the driver-specific items in your database, including the order in which you should configure the items in your database.

This Guide to Core Configuration covers configuration of many ‘core’ items, such as Master Station Accumulators, Value Maps, Data Grids, and Schedules—for more information, see Introduction.

You can also configure other ‘core’ items such as:

  • Trends—Plots of the values of, for example, points, over a specific time period. The data is displayed in the form of a time-based graph called a Trend. ClearSCADA supports various types of Trend (see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends).
  • Logic Programs—To define sequences, perform calculations, or determine the values of particular items in the database. ClearSCADA supports a variety of logic programs (see the ClearSCADA Guide to Logic).
  • Alarm Redirections—You can configure ClearSCADA to redirect alarms under particular circumstances. For instance, to forward alarm details to an on-call engineer’s pager when a control center is unmanned. For more information, see the ClearSCADA Guide to Alarm Redirection.
  • Mimics—Pictorial or textual representations of plant, regions, or other logical divisions (see the ClearSCADA Guide to Mimics).

As well as producing Mimics as a means of operator interaction with your system, you can also use Mimics as:

  • Default Views—Views that usually contain representations of the items within a Group (see Defining a Default View).
  • Help Views—Documents that provide Help about an item (see Defining Identification Details).
  • Alarm Views—Views that represent the alarm state for an item or Group, and provide access to alarm response actions and controls (see Defining an Item or Group’s Alarm Properties).


Core Configuration Guide - Configuration Changes Auditing

Configuration Changes Auditing

In ClearSCADA, the Event Journal (Events List) records configuration changes automatically.

Example:

A user named ‘Sysman1’ changes the value of a property on an Analog Point Form, then saves that configuration change. The saved change is recorded in the Event Journal (Events List):

(The Severity that is assigned to the configuration change is that specified on the user’s User Account Form (see Define the Severity of Events Associated with a User in the ClearSCADA Guide to Security).)

If ClearSCADA’s Configuration Changes Auditing feature is enabled on your system (the feature is disabled by default), ClearSCADA will also keep a separate detailed record of configuration changes. The changes that are recorded comprise changes to the values of properties (fields) in the database. Many of these properties appear as fields on configuration Forms. When enabled, the feature records each property change, along with the change in value and the ‘user’ responsible for that change. So, for example, you will be able ascertain whether a particular property change occurred due to an Import & Merge routine (which might have caused one property value to be replaced by another), or due to a user changing the value on an item’s Configuration Form.

The Configuration Changes Auditing feature is enabled or disabled on a per server basis (see Settings for Configuration Changes Auditing in the ClearSCADA Guide to Server Administration).

On systems on which the feature is enabled, you can use the Display Property Changes pick action to Display a List of Property Changes.


Core Configuration Guide - Display a List of Property Changes (Configuration Changes Auditing)

Display a List of Property Changes

If the Configuration Changes Auditing feature is enabled on your system, you can use the Display Property Changes pick action to display a Queries List showing details of the property changes that have been made on your system. You can display a List showing the property changes that have occurred on your system over a defined time-period, or you can display a List that is filtered to show the property changes that apply to a specific item or Group. In each case, you select the Display Property Changes pick action from the relevant context sensitive menu to display the List. For information on displaying the menu, see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients.

To display a List of configuration changes that have been made to a particular Group, including the items in that group and any subgroups, select that Group’s Display Property Changes pick action.

To display a List of configuration changes that have been made to an individual database item, select that item’s Display Property Changes pick action.

To display a List of configuration changes that have been made to an individual property (field) on a configuration Form, select that field’s Display Property Changes pick action on the configuration Form. (To do this, right-click on the field to display a context sensitive menu, then select the Display Property Changes option.)

As with other Lists, the Property Change History List consists of rows and columns. Each row represents an individual configuration property change entry, and each column contains information about a specific value for that configuration change.

The Property Change History List contains these columns:

  • Time—The date and time at which a property’s change in value was recorded. For example, the date and time at which a user saved the change made to a property on a configuration Form.
  • Object Name—The full name of the item to which the property change relates. The name includes the full path of the item in the database.
  • Field Name—The name of the property that has changed. This is the name that appears in the Name column on the relevant table in the database Schema. This name might differ slightly to the name shown on the configuration Form. (The name that appears on a Form is the property’s display name—the string that is displayed in the language that is associated with the logged on user’s specified Locale.)

You can ascertain a property’s Name by selecting the property on a Form, then looking at the name that is displayed in the Status Bar at the bottom of the ViewX window (as shown in the first example below).

  • Old Value—The previous value of the property.
  • New Value—The value to which the property has been changed.

The format used for both the Old Value and New Value varies, depending on the type of property. With many types of property (such as one that can be specified via a Text Entry Field or Browse Button), the values appear in the same format as that used on the configuration Form.

With a property that can be specified using a Combo Box, ClearSCADA stores each property value as a number in the database. For such a property, the Old Value and New Value columns show the number that represents the property’s value. Use the database Schema or the ClearSCADA Server Configuration Tool, as appropriate, to ascertain the value that the number represents (as shown in the second example below).

  • User—The name of the user that made the change. Depending how the change occurred, this might be the name of a logged on user, or one of ClearSCADA’s built-in internal ‘users’, such as ‘System’. For more information about each type of user, see Understand Events Lists in the ClearSCADA Guide to Lists.
  • Origin—The means by which the property’s value was changed. For example, ‘Configuration Form’ if a user changed a value on a Form.

The Origin (or ‘cause’) might be direct or indirect. For example, an indirect activity such as an object conversion (using the Convert To pick action), or an Import or Import & Merge routine, might result in configuration changes being recorded. Such configuration changes occur if the activity results in ClearSCADA assigning a value other than the default to any configuration property (as shown in the third example, below).

You specify which types of Origin are recorded in the auditing process, on a per server basis (see Settings for Configuration Changes Auditing in the ClearSCADA Guide to Server Administration).

As with other Queries Lists, you can perform a variety of activities on the Property Change History List, using options on the List’s context sensitive menu. For more information, see Display and Use Lists in the Guide to Lists.

Example 1:

A user assigns a ‘custom’ color to an analog point’s Full Scale Limit:

When the Color field is selected on the point’s Form, the name that is assigned to that particular property is displayed in the Status Bar:

When you select a field on a Form...
...the Status Bar displays the field’s name and type.

This is the Name that is assigned to that property in the database, as shown on the database Schema:

The property’s Name is shown in the relevant table in the database Schema.

The entry for the property change is displayed in the Property Change History List. The Field Name column shows the name that is assigned to that property in the database:

Example 2:

A user changes a point’s Confirm Disable/Enable property from ‘Always’ to ‘Always w/ Password’:

The property is displayed as a combo box on the point’s configuration Form. With such properties, ClearSCADA stores each property value as a number in the database.

As such, the property’s Old Value and New Value appear as numbers in the Property Change History List:

The value to which each number relates can be ascertained by looking at the property’s entry in the database Schema:

With a property represented by a combo box, look at the enumeration entries in the relevant database table’s Notes column. These show the property value that each number represents.

Further Information

Using the database Schema: see Working with the Database Schema in the ClearSCADA Guide to the Database.

Example 3:

A ClearSCADA system has a series of Group Instances that reference a particular Group Template. An engineer adds an Abstract PSTN outstation to the Group Template. ClearSCADA automatically replicates the addition of the PSTN outstation in each of the Group Instances that reference the Group Template.

In the Group Template, the engineer changes the value of the outstation’s Retries property to 3 from the default of 2. ClearSCADA automatically replicates the change in each of the Group Instances that reference the Group Template.

The Property Change History List is displayed. In the List, the Origin of the configuration change is shown as Configuration Form for the Group Template entry and Template Propagation for the Group Instance entries:

In the Group Template, the engineer converts the Abstract PSTN outstation to a driver-specific type of PSTN outstation. When ClearSCADA converts the outstation from one type to another, any properties that are supported by both types of outstation retain their existing settings. As such, the outstation’s Retries property retains its value of 3. As the Retries property is assigned a value other than the default, this is deemed to be a configuration change and is shown as such in the Property Change History List. In this case, the Origin of the configuration change is shown as Object Conversion:

The List also includes any other outstation properties that are assigned non-default values as a result of the outstation being converted from one type to another.

Further Information

Group Templates and Group Instances.

Abstract Item.

Converting a Database Item.

Specify Which Property Change Origins are Audited: see Settings for Configuration Changes Auditing in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Displaying an Editor

Displaying an Editor

With some types of database item—such as a Logic program, Mimic, Trend, or Calendar—you use an Editor to configure most of that item’s settings.

...Calendars...
Use ClearSCADA’s built-in Editors to configure a variety of items, including Logic programs...
...and Mimics.

To display an Editor in ViewX, either:

  1. Double-click on the item in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).
    The associated Editor is displayed.

or:

  1. Either:
  • Right-click on the item in the Database Bar.

or:

  • Right-click on the item in a Queries List.

or:

  • Select an animated representation of the item on a Mimic. (Provided that the animated representation is associated with the item’s Object menu and provides access to the relevant menu option.)

A context sensitive menu is displayed.

  2. Select the Edit option.
    The associated Editor is displayed.

For information on configuring an item using an Editor, see the relevant configuration section or guide. (For instance, for information on configuring a Mimic, see the ClearSCADA Guide to Mimics.)


Core Configuration Guide - Working with the OPC Data Bar

Working with the OPC Data Bar

The OPC standards are a series of standard specifications aimed at allowing interoperability between different SCADA systems. ClearSCADA uses these standards to allow transfer of data between the ClearSCADA server and third-party applications. To help facilitate this, ClearSCADA stores property values in the database in the form of OPC tags.

If your User Account provides access to this particular Explorer Bar, you can use the OPC Data Bar to access the OPC Data Access (OPC DA) properties (‘tags’) of various items in the database.

The OPC Data Bar displays the entries in a hierarchical tree structure.

At the top-most level is the System or Database icon. If a ViewX client provides access to Multiple Databases, ensure that you expand the branch of the System in which you are interested, in order to access the properties that apply to that particular database.

System or Database icon.

The next level of the tree structure comprises the following:

  • Root Group—Use this branch to access the OPC Data Access properties of items that are configured in the database (see Access Property Tags).
  • Search Keys—Use this branch to access the OPC Data Access properties of any ‘custom’ string fields that have been added to any of the database tables (see Access Search Key Tags).
  • Server Status—Use this branch to access to a selection of the OPC Data Access properties that relate to the server’s status (see Access Server Status Information).

NOTE: The Register Spaces branch is only supported by the server for specific applications.

You can use OPC Tags in expressions in various parts of ClearSCADA—see Welcome to the Guide to Expressions in the ClearSCADA Guide to Expressions. For further information on OPC Tags and for information on other ways of accessing such tags, see OPC Tags in the ClearSCADA Guide to Expressions.

Further Information

Working with the OPC Historic Data Bar.


Core Configuration Guide - Access Property Tags (Working with the OPC Data Bar)

Access Property Tags

You can use the Root Group branch of the OPC Data Bar to access the properties of any database item to which the ViewX client and your User Account has access. The name of each property is stored in the database as an OPC Tag.

To access such a property:

  1. Display the OPC Data Bar (see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Expand the Root Group branch of the system (database) for which you want to access a property.
    The uppermost entries within the branch correspond to the database setup (the entries mirror those of the Database Bar).
    The uppermost entries within the branch provide access to the Groups, Group Templates, Group Instances, and individual database items located within that branch.

    The lower entries within the branch provide access to OPC properties associated with the Root Group’s configuration fields, data fields, database aggregates (some of which appear as tabs on the Root Group’s configuration Form), and status attributes.
    ...and status attribute properties.
    The lower entries within the branch provide access to the Group’s database properties...

For instance, the properties within the $Config branch, off the Root Group’s GuestUser branch,...
...correspond to properties that you can configure on the Guest User tab of the Root Group’s configuration Form.

  3. Expand the tree structure further, as required, to access the OPC properties in which you are interested.

(If required, you can place the cursor over an entry in the OPC Data Bar, to display a ToolTip providing more information about that entry.)

The entries within each Group, Group Template, or Group Instance are organized in a similar way to those of the Root Group: the uppermost entries provide access to the database items and any Groups within that branch of the database; the lower entries provide access to the OPC properties associated with that particular Group, Group Template, or Group Instance.

  4. Either:
  1. Right-click on an item other than an OPC property to display a context sensitive menu, then select the Display Values menu option.
    A window is displayed, showing the current values of the OPC Data Access properties that are associated with that item.
    An Object Id of -1 indicates a reference field to which no database item has been assigned.

(Reference fields, such as ‘EventAreaOfInterest’ shown above, store the Object Id number of the target database item. The Object Id is the number that uniquely identifies an item in the database. An Object Id of 0 (zero) indicates the Root Group (or ‘World’ Area of Interest, if referring to an AOI reference field). An Object Id of -1 indicates a reference field to which no database item has been assigned. In this particular case, no Area of Interest has been assigned to events associated with the Guest User (as can also be seen by the blank ‘Area of Interest’ field on the ‘Guest User’ tab of the configuration Form shown in step 2).)

Or:

  1. Double-click on an OPC property to display a window providing information about that specific property.

(With a property that also appears as a field on a configuration Form, a Timestamp of 01/Jan/1601 typically indicates that the property’s setting has never been changed from the default. In the figure above, for example, the ‘AllowGroupAlarmOps’ property appears as an ‘Allow Group Alarm Operations’ check box on the Guest User tab of the Root Group’s configuration Form (as shown in the figure in step 2). The check box is blank (indicating that the feature is disabled, or false) by default. The Timestamp shown above indicates that the check box’s setting has never been changed from the default.)

Or:

  1. Right-click on an OPC property to display a context sensitive menu. The options vary, depending on the type of property, but may include:
  • Display Value—Displays a window providing information about that property (as shown above).
  • Display Trend—Displays the property’s value in the form of a current Trend.
  • Set Value—Displays a window enabling you to set the property’s value.
  5. If you want to use an OPC property elsewhere (for example, in a Logic program or on a Mimic), you can either:
  • Copy and paste the OPC Tag from the window that is displayed when you double-click on the property or select Display Value from the property’s context sensitive menu. For more information, see Use the Status Display Buttons in the ClearSCADA Guide to ViewX and WebX Clients.
  • Drag the required property (OPC Tag) from the OPC Data Bar onto a Mimic or other display. For more information, see Add Live Values to a Mimic in the ClearSCADA Guide to Mimics.

Further Information

For more information on any of the OPC properties that are available from the OPC Data Bar’s Root Group branch, see the database Schema.

Using the Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.

Trends: see the ClearSCADA Guide to Trends.

ClearSCADA supports several types of Trend. The type of Trend that you can display using the OPC Data Bar is a ‘standard’ Ad Hoc Trend (see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends).

Use the OPC Historic Data Bar to Access Historic Property Tags.


Core Configuration Guide - Access Search Key Tags (Working with the OPC Data Bar)

Access Search Key Tags

A Search Key is a ‘custom’ string field that has been added to a database table (see Add a New Extra Field in the ClearSCADA Guide to Server Administration).

If Search Keys exist on your system and are configured to be used as OPC Tags, you can use the Search Key branch of the OPC Data Bar to ascertain information about:

  • the Search Keys themselves
  • the database items on which the Search Keys have been assigned a value.

To access such information:

  1. Display the OPC Data Bar (see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Expand the Search Keys branch of the system (database) in which you are interested.
    The branch expands to list, in alphabetical order, the Search Keys that:
  • Have their Tag property enabled (see Modify an Existing Extra Field in the ClearSCADA Guide to Server Administration)
    A Search Key is only available from the OPC Data Bar’s Search Key branch if its Tag property is selected. (The property determines whether a Search Key can be used as an OPC Tag.)

  • Have been assigned a value on one or more of the configuration Forms on which the Search Key’s field is displayed.
  3. Expand the branch of the relevant Search Key.
    The tree expands to display entries for those database items on which the Search Key field has been assigned a value.

The entries are listed alphabetically by Search Key value.

Expand each Search Key entry to display those database items on which the Search Key field has been assigned a value.
The icons displayed within each Search Key branch indicate the type of database item with which that particular Search Key is located. (In this example, the ‘MapRef’ Search Key appears on Group Forms, and the ‘SiteName’ Search Key appears on Advanced Driver Outstation Forms.)

  4. You can either:
  1. Right-click on a database item that has been assigned a Search Key value.
    A context sensitive menu is displayed.
  2. Select the Display Values option to display a window providing the current values of the OPC Data Access properties associated with that item. (For an example of such a window, see Access Property Tags.)

Or:

  1. Expand the relevant database item’s entry, in order to access any of that item’s OPC properties. (If the Search Key is associated with a Group, only the properties associated with that Group are displayed. If you want to access the OPC properties of any database items in that Group, you need to expand that Group’s entry in the OPC Data Bar’s Root Group branch, rather than the Search Keys branch (see Access Property Tags).)
  5. As with OPC properties in the Root Group branch, you can either:
  • Double-click on an OPC property to display a window containing information about that property.

Or:

  • Right-click on an OPC property to display a context sensitive menu containing a combination of these options: Display Value, Display Trend, and Set Value. For more information on any of these options, see Access Property Tags.
  6. If you want to use an OPC Data Access property elsewhere (for example, in a Logic program or on a Mimic), you can either:
  • Copy and paste the OPC Tag from the window that is displayed when you double-click on the property or select Display Value from the property’s context sensitive menu. For more information, see Use the Status Display Buttons in the ClearSCADA Guide to ViewX and WebX Clients.
  • Drag the required property (OPC Tag) from the OPC Data Bar onto a Mimic or other display. For more information, see Add Live Values to a Mimic in the ClearSCADA Guide to Mimics.

Further Information

For more information on any of the OPC properties that are available from the OPC Data Bar’s Search Keys branch, see the database Schema.

Using the Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.


Core Configuration Guide - Access Server Status Information (Working with the OPC Data Bar)

Access Server Status Information

You can use the Server Status branch of the OPC Data Bar as an alternative means of accessing a selection of the properties that are available from the Server Status Tool. The Server Status categories that are available from the OPC Data Bar include:

  • MODULE—Equivalent to the Server Status Tool’s Modules category
  • LOG—Equivalent to the Server Status Tool’s Logging category
  • MEM—Equivalent to the Server Status Tool’s Memory Usage category
  • DBFILE—Equivalent to the Server Status Tool’s File Statistics category
  • HIS—Equivalent to the Server Status Tool’s Historian category

and the following categories, which relate to Main-Standby performance:

  • SBYCNT—Equivalent to the Server Status Tool’s Counters category
  • HISXFER—Equivalent to the Server Status Tool’s Historic Transfer category
  • ICMPPOL—Equivalent to the Server Status Tool’s ICMP Polls category
  • SBYLNK—Equivalent to the Server Status Tool’s Links (Standby) category
  • SBYPOL—Equivalent to the Server Status Tool’s Polls category.

To view information about server status properties in any of the above categories:

  1. Display the OPC Data Bar (see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Expand the Server Status branch of the system for which you want to view information.
    You can place the cursor over a category to display a ToolTip showing the category’s name.

  3. Expand the tree structure of the required category, including any subcategory within that category, to locate the property in which you are interested.
  4. Either:
  1. Double-click on the property to display a window providing information about that property.

Or:

  1. Right-click on the property.
    A context sensitive menu is displayed.
  2. Either:
  • Select the Display Value option to display a window providing information about that property.

Or:

  • Select the Display Trend option to display the property’s value in the form of a current Trend. (This option is only available for some properties.)

Locate the required server status property (in this example, the Event Journal’s ‘Total File’ property)...
...then select the Display Trend option (if available) to display the property’s value in the form of a current Trend...
...or the Display Value option to view a window providing status information about that property.

The property’s current value can also be accessed using the Server Status Tool:

The Event Journal’s ‘Total File’ property, along with its current value.

You can also use the Server Status branch of the OPC Data Bar to ascertain the name of a server status property, in order to use that property elsewhere (for example, in a Logic program or on a Mimic). The name of each property is stored in the database in the form of an OPC Tag.

If required, you can either:

  • Copy and paste the OPC Tag from the window that is displayed when you double-click on the property or select Display Value from the property’s context sensitive menu. For more information, see Use the Status Display Buttons in the ClearSCADA Guide to ViewX and WebX Clients.
  • Drag the required property (OPC Tag) from the OPC Data Bar onto a Mimic or other display. For more information, see Add Live Values to a Mimic in the ClearSCADA Guide to Mimics.

Further Information

Server Status Tool: see the ClearSCADA Guide to the Server Status Tool.

Trends: see the ClearSCADA Guide to Trends.

ClearSCADA supports several types of Trend. The type of Trend that you can display using the OPC Data Bar is a ‘standard’ Ad Hoc Trend (see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends).


Core Configuration Guide - Working with the OPC Historic Data Bar

Working with the OPC Historic Data Bar

If your User Account provides access to this particular Explorer Bar, you can use the OPC Historic Data Bar to access the OPC Historic Data Access (OPC HDA) properties (‘tags’) of various items in the database. The entries in the OPC Historic Data Bar are limited to those database items that support historic data and for which Historic is enabled. Depending on your database’s configuration, such items might include, for example, points, Master Station Accumulators, Forecasts, Time Profiles and/or any driver-specific database items that support and (if applicable) have Historic enabled.

In order to store data values historically, your system has to be enabled to store data historically (see Historic Configuration Settings in the ClearSCADA Guide to Server Administration). Additionally, Historic has to be enabled on those items for which historic data storage is optional, but required. For information on Historic properties associated with points and master station accumulators, see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration. The driver-specific guides explain any such properties that apply to driver-specific database items.

The OPC Historic Data Bar displays the entries in a hierarchical tree structure.

At the top-most level in the OPC Historic Data Bar’s tree structure is the System or Database icon. If a ViewX client provides access to Multiple Databases, ensure that you expand the branch of the System in which you are interested, in order to access the historic properties that apply to that particular database.

The next level of the tree structure comprises the following:

  • Root Group—Use this branch to access the OPC historic properties of items configured in the database (see Access Historic Property Tags).
  • Search Keys—Use this branch to access the OPC historic properties of any ‘custom’ string fields and the database items on which those fields are located (see Access Historic Search Key Tags).
    System or Database icon.
    The Root Group. Any items in the database that store data historically are located within this branch.
    The Search Keys branch contains any ‘custom’ string fields that are set up as OPC Tags and that are used on database items that store data historically.

You can use OPC Historic Tags in expressions in various parts of ClearSCADA—see Welcome to the Guide to Expressions in the ClearSCADA Guide to Expressions. For further information on OPC Historic Tags and for information on other ways of accessing such tags, see OPC Historic Tags in the ClearSCADA Guide to Expressions.

Further Information

Working with the OPC Data Bar.


Core Configuration Guide - Access Historic Property Tags (Working with the OPC Historic Data Bar)

Access Historic Property Tags

You can use the Root Group branch of the OPC Historic Data Bar to access the historic properties of any database item to which the ViewX client and your User Account has access. The name of each historic property is stored in the database as an OPC Historic Tag.

To access an item’s historic properties:

  1. Display the OPC Historic Data Bar (see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Expand the Root Group branch of the system (database) for which you want to access an OPC Historic Tag.

The Root Group’s tree structure corresponds to the way in which the database is structured. The tree structure is restricted to those items for which ClearSCADA is configured to store data historically, along with the Groups or Group Instances in which those items are located.

Example:

The tree structure only includes points and other database items for which ClearSCADA is configured to store data historically.
You can place the cursor over an entry to display a ToolTip that shows the item’s type.

  3. To display an item’s historic data in the form of a ‘standard’ Ad Hoc Trend, either:
  1. Double-click on the item’s entry in the OPC Historic Data Bar.

Or:

  1. Right-click on the item’s entry in the OPC Historic Data Bar.
    A context sensitive menu is displayed.
  2. Select the Display Trend option from the menu.

An Ad Hoc Trend of the item’s historic data is displayed.

Example:

For more information on working with Trends, see the ClearSCADA Guide to Trends.

  4. To use an OPC historic property elsewhere (for example, on a Mimic), you can either:
  • Drag an OPC historic property onto, for example, a cell in a Data Grid.

For more information, see Configuring Data Grids. For information on using a Data Grid to perform a calculation on a block of historic data, see Calculate a Value from a Block of Historic Data.

  • Use the OPC Historic Data Bar to ascertain the name of the database aggregate that ClearSCADA uses to store an item’s historic data, then enter that name into the required location.

The name of a historic aggregate might be required, for example, in an expression for a Mimic animation, or for use elsewhere in ClearSCADA. (Typically, you only need to include the name of a historic aggregate if the database item—such as a Forecast—has more than one historic aggregate). For further more information, see the ClearSCADA Guide to Expressions. In particular see Syntax of an OPC Historic Tag in the ClearSCADA Guide to Expressions.

The OCP Historic Data Bar includes a separate entry for each historic aggregate, if a database item has more than one historic aggregate.

A Forecast database item has 8 historic aggregates.

Further Information

Explorer Bars supported by ClearSCADA: see Explorer Bars used in ViewX in the ClearSCADA Guide to ViewX and WebX Clients.

Explorer Bar Structure: see Understanding the Explorer Bar Tree-Structure in the ClearSCADA Guide to ViewX and WebX Clients.

ClearSCADA supports several types of Trend. The type of Trend that you can display using the OPC Historic Data Bar is a ‘standard’ Ad Hoc Trend (see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends).

Other ways of displaying Trends: see Display a Trend in Run Mode in the ClearSCADA Guide to Trends.


Core Configuration Guide - Access Historic Search Key Tags (Working with the OPC Historic Data Bar)

Access Historic Search Key Tags

A Search Key is a ‘custom’ string field that has been added to a database table (see Add a New Extra Field in the ClearSCADA Guide to Server Administration).

If Search Keys exist on your system, providing that those Search Keys:

  • Are configured to be used as OPC Tags (see Modify an Existing Extra Field in the ClearSCADA Guide to Server Administration)
  • Are associated with database items for which ClearSCADA is configured to store data historically (see Working with the OPC Historic Data Bar)
  • Are assigned a value on those database items

you can use the Search Key branch of the OPC Historic Data Bar to:

  • Ascertain which Search Key values are configured on your system
  • Display a historic Trend for any of those values.

To perform either of the above:

  1. Display the OPC Historic Data Bar (see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Expand the Search Keys branch of the system (database) in which you are interested.
  3. Expand the branch of the relevant Search Key.
    You can only expand the branches of those Search Keys that are associated with database items for which ClearSCADA stores data historically.

    The tree expands to display the value that has been assigned to that Search Key on each of the database items for which ClearSCADA stores data historically.
  4. If required, you can display a historic Trend of any of those values by either:
  1. Double-clicking on the value.

Or:

  1. Right-clicking on the value to display a context sensitive menu.
  2. Selecting the Display Trend option.


Core Configuration Guide - Working with Forms

Working with Forms

Some ClearSCADA database configuration is carried out using configuration Forms. A Form exists for every item in the database. Each Form has a series of tabs that cover different aspects of the configuration for that item.

Each tab displays fields specific to a particular aspect of configuration for that item.
A Group Form has Identification, User Methods, Group, and Redirection tabs.

Some tabs, such as the Redirection tab, are common to multiple database items; other tabs are specific to the type of database item or the type of driver on which it is located.

This section explains:

  • How to Display a Form
  • Mandatory Configuration and Invalid Configuration Messages
  • Fields on Forms and how their appearance differs, depending on the way in which you need to enter the data.

For aspects of configuration that are common to many database items, see the relevant sections of the core configuration guides.

For aspects of configuration that are specific to a particular type of item or driver, see the relevant driver guide.

Further Information

Keep a detailed record of the property changes made on your system: see Configuration Changes Auditing.


Core Configuration Guide - Display a Form (Working with Forms)

Display a Form

To display a Form for a database item, either:

  1. Double-click on the item in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).
    The associated Form is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

or:

  1. Either:
  • Right-click on the item in the Database Bar.

or:

  • Right-click on the item in a Queries List.

or:

  • Select an animated representation of the item on a Mimic. (Provided that the animated representation is associated with the item’s Object menu and provides access to the relevant menu option).

A context sensitive menu is displayed.

  2. Select the Properties option.
    The associated Form is displayed.

Each Form has a series tabs that contain fields for particular aspects of the configuration (see Fields on Forms). Any messages relating to incomplete, incorrect, or conflicting configuration are displayed in a message area directly below the Form (see Mandatory Configuration and Invalid Configuration Messages).

Use the information within the core configuration guides and the appropriate driver-specific guide to help you configure the items in your database.


Core Configuration Guide - Mandatory Configuration and Invalid Configuration Messages (Working with Forms)

Mandatory Configuration and Invalid Configuration Messages

When you first create a new database item, messages relating to configuration that has to be specified are displayed in a message area directly below the Form.

A message area is displayed if mandatory information is incomplete, or there is invalid or conflicting configuration. (In this particular case, a channel’s Port needs specifying.)

During the configuration process, any incomplete, invalid or conflicting configuration is indicated in this message area, as the configuration is saved (see Saving Configuration Changes). (You need to save the configuration changes that you make, in order to store the details in the ClearSCADA database.)

The Database Bar also indicates whether a database item has any such configuration errors (see Checking for Invalid Configuration).

Ensure that any configuration errors are corrected and the changes saved in order for the item to have valid configuration.

ClearSCADA only deems an item to be functional (active) when it has valid configuration and has been placed In Service (see Placing an Item In Service). (With an item that is dependent on other items, those items also have to have valid configuration and be In Service.) When supported by the device, you also need to download the configuration to the outstation or PLC (see Downloading Configuration Changes).


Core Configuration Guide - Fields on Forms (Working with Forms)

Fields on Forms

You configure the details for each database item using a series of fields on the corresponding Form. The fields vary, depending on the way in which you need to enter the data. In some cases, the option that you select from a field may result in further fields being displayed, and becoming available for configuration on the Form.

The field, and field components you will come across include:

  • Text Entry Field
  • Combo Box
  • Spin Box
  • Check Box
  • Option Button
  • Browse Button
  • Custom Field.

A Grayed Out Field indicates that the field is not available for selection.


Core Configuration Guide - Text Entry Field (Working with Forms)

Text Entry Field

Text entry fields allow you to manually enter data using a keyboard.

Many text entry fields often come with a Browse Button, allowing you to choose an option from a list. Such fields are sometimes referred to as Reference fields.

If the Dictionary feature is used on your system, you may want to consider prefixing certain strings with @, in order to ‘translate’ those strings, so that they are replaced by other terms, when displayed on a List, Mimic or Trend, in ViewX. For more information on using the Dictionary feature, see Dictionary Settings in the ClearSCADA Guide to Server Administration.

Further Information

With text entry fields on some pick action windows, an on-screen keypad may be displayed to enable you to specify the field’s value on-screen, rather than by using a traditional keyboard. The keypad is only displayed on ViewX workstations on which the On-Screen Keyboard feature enabled. For more information, see Use the Numeric Touch Screen Keypad in the ClearSCADA Guide to ViewX and WebX Clients, and see Use the QWERTY Touch Screen Keypad in the ClearSCADA Guide to ViewX and WebX Clients.


Core Configuration Guide - Combo Box (Working with Forms)

Combo Box

To enter data using a combo box, you select the arrow to display a pop-up list of options, and select the option that you require. The highlighted entry is displayed in the field.

Select the arrow on a combo box...
...to display a list of options from which you highlight the one that you require.

Be aware that if the Dictionary feature is used on your system, some strings in combo box lists may be prefixed with @, to enable those strings to be ‘translated’, so that they are replaced by other terms, when displayed on a List, Mimic or Trend, in ViewX. For more information on using the Dictionary feature, see Dictionary Settings in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Spin Box (Working with Forms)

Spin Box

You can use the arrows on a spin box to increase or decrease the value in the associated field. Alternatively, you can manually overwrite the value.

Use the down arrow to decrease the value.
Use the up arrow to increase the value.


Core Configuration Guide - Check Box (Working with Forms)

Check Box

You enable a feature that is indicated by a check box by selecting the box so that it displays a check mark.

To disable the feature, select the check box so that it is clear.

Feature is disabled—the check box is clear.
Feature is enabled—the check box displays a check mark.

One of the most common check boxes is the In Service check box, which you use to specify whether an item is in service (functional, or active) or out of service (inactive). For more information, see Placing an Item In Service.

NOTE: The ‘Remove Explicit Palette on Descendants’ check box on the Color Palette, and the ‘Remove Explicit Permissions on Descendants’ check box on the Security window, work differently to most check boxes. With these two particular check boxes, if you select the check box, the function is only activated once, when you confirm the selection by using the window’s OK button. Unlike other check boxes, the function does not continue to remain enabled and therefore the check box will be clear the next time that the Color Palette or Security window is displayed.


Core Configuration Guide - Option Button (Working with Forms)

Option Button

Option buttons are not used on Forms, but do appear on the ClearSCADA Server Configuration Tool used by system administrators.

You enable a feature that is indicated by an option button by selecting the button so that it displays a marker.

To disable the feature, you select another option button. Option buttons are usually mutually exclusive—when one option is selected, the others are cleared.

Option is disabled—the button is clear.
Option is enabled—the button displays a marker.


Core Configuration Guide - Browse Button (Working with Forms)

Browse Button

Some text entry fields have a browse button attached. You can use the browse button to display a window, from which you can select the information that is required for that field.

For fields in which you are required to specify a method (action), select the browse button to display the Edit Method window. Use the window to Specify a Method and any method arguments that are to appear in the field.

For fields in which you are required to specify a time, select the browse button to display an Interval Window or Offset Window. Use the window to specify the time that is to appear in the field.

For fields in which you are required to specify the name of an item, select the browse button to display a Reference browse window. Select the item that you require from the Reference browse window, and then select the OK button to confirm the selection. Your choice is displayed in the field that is associated with the browse button.

Select a browse button...
... to display a Reference browse window...
... select an entry from the window...
... then confirm the selection with the OK button.

When an entry is displayed in the field, you can use the adjacent Go To link to display the Form or other ‘File Object’ for the item.

Where a Form is displayed, you can alter the configuration for that item.

Where another display is shown, for instance a Value Map, the display is depicted in ‘Run’ mode. In order to modify the display, you need to select the Design button [image] on the File toolbar, to put the display into ‘Design’ mode.


Core Configuration Guide - Grayed Out Field (Working with Forms)

Grayed Out Field

Fields are ‘grayed out’ and not available for selection when:

  • They are for information only. Either:
  • The data was configured on another Form
  • The data was configured when the item was created
  • If the Form is in a Group Instance, the data might be defined in the Group Template and be set up so that it cannot be altered on an individual basis. (For information on changing such configuration, see Define which Property Values Derive from a Group Template).
  • The feature with which the fields are associated is not enabled—if you require the feature, you will have to enable it elsewhere on the Form. The fields associated with that feature will then become available for use. When fields are ‘grayed out’ because a feature is not enabled, any configuration within them is ignored.
  • The feature is not applicable to that particular type of item or type of driver (see the driver-specific documentation for details).
    Fields available for selection.
    ‘Grayed out’ fields are not available for selection.

NOTE: In some cases, a feature is not grayed out when it does not apply to your configuration—see the relevant configuration section for details.


Core Configuration Guide - Custom Field (Working with Forms)

Custom Field

In addition to the standard fields that are displayed on Forms, you can, if required, add your own custom fields. Use these extra fields to define additional configuration settings that are specific to your system.

You should ensure that any custom fields are fully documented, and that the documentation is made available for use in addition to the documentation supplied with your system.

For further information on adding fields, see Extra Database Fields in the ClearSCADA Guide to Server Administration.

Custom configuration is retained whenever a system is upgraded to a later build.


Core Configuration Guide - Groups

Groups

The items in a ClearSCADA database are organized into groups. These groups appear as ‘folders’ in the Database Bar, rather like files in folders on a disk.

Each group can contain both database items and other groups, and you can organize your database into a hierarchy of up to 12 levels of groups and database items. This allows you to create complex hierarchies that reflect the design of your system. Typically, you use Groups to organize database items according to their geographical location, their type, or their purpose.

Groups can contain database items, including other Groups.

This section explains how to Use Groups to Organize your Database, including instructions on how to:

  • Add a Group
  • Configure a Group
  • Place Database Items in a Group.

Each ClearSCADA system includes a Root Group, for which you configure:

  • Properties that affect the system as a whole
  • The system-wide properties of the Guest User account (the default account that is used whenever a user accesses the system without logging on).

For more information, see Configure the Properties of the Root or System Group.

NOTE: This section describes ‘normal’ Groups. ClearSCADA also provides two other types of Groups referred to as Group Templates and Group Instances.


Core Configuration Guide - Use Groups to Organize your Database (Groups)

Use Groups to Organize your Database

Groups allow you to organize your database items into hierarchies so that the items can be easily located. If Groups are not used, the database items will each be located on the root of a system—this makes it difficult to locate specific items.

By using Groups, you can structure your database items into logical areas so that users can easily locate the items they need.

In addition to the ‘normal’ Groups, there are also Group Templates and Group Instances. Before you attempt to use Groups to organize your database, you should refer to the Group Templates and Group Instances section as you may be able to use these features to reduce the amount of configuration required.

To use Groups to organize your database:

  1. Add a Group.
  2. Optionally configure the Group properties if the defaults are unsuitable:
  1. Configure the Identification details (see Defining Identification Details).
  2. Configure any custom pick actions that are required for the Group (see Using the User Methods Tab to Define Custom Actions).
  3. Define a Default Mimic for the Group (see Defining a Default View).
  4. Configure the Alarm Redirections (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection). The Alarm redirections apply to alarms that are raised for items within the Group, and so can be used to provide an additional alarm redirection cascade to alarm redirections for individual items.
  5. Save the configuration (see Saving Configuration Changes).
  3. Place Database Items in a Group:

Either:

  • Add Items to a Group.

Or:

  • Move Items Between Groups.
  4. Repeat steps 1-3 inclusive for each required Group.


Core Configuration Guide - Add a Group (Groups)

Add a Group

You can use Groups to organize your database items into a logical hierarchy. The number of Groups you need to add will vary according to the requirements for your system.

We recommend that you store all of your database items in Groups or Group Instances (see Group Templates and Group Instances) as this improves the usability of the Database Bar—if the database items are ordered into logical Groups, users will be able to locate specific items much more easily.

You can include up to 12 levels of Groups and items within Groups on a system.

To add a Group folder:

  1. In the Database Bar, right-click on the System or Group folder to which you want to add the new Group.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Group option.
    A further menu is displayed.
  4. Select the Group option from the further menu.
    A Group is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Group (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.
  7. Repeat steps 1-6 inclusive for each required Group.

When you have added a Group, you can:

  • Configure the Group’s properties (see Configure a Group)
  • Add items to the Group, or move items into it (see Place Database Items in a Group).


Core Configuration Guide - Configure a Group (Groups)

Configure a Group

To configure a Group, you need to display its Form. The Group Form contains the fields that are required to configure the Group.

To display the Group Form:

  1. Right-click on the Group in the Database Bar.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the Properties option.
    The Group Form is displayed.
    Identification tab
    Redirection tab
    User Methods tab
    Group tab

You can use the Group Form to:

  1. Configure the Identification details (see Defining Identification Details).
  2. Optionally configure custom pick actions for the group (see Using the User Methods Tab to Define Custom Actions).
  3. Optionally define features associated with the group’s alarms (see Defining an Item or Group’s Alarm Properties).
  4. Define a Default View for the group (see Defining a Default View).
  5. Define whether confirmation is required when an operator attempts to disable or enable the group’s alarms (see Requesting Confirmation of Action Requests).
  6. Define any Alarm Redirections for the group (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).

Alarm redirections allow you, for instance, to redirect any alarms that are raised for items within the Group, to an engineer via e-mail. If you define Alarm Redirection on a Group-basis, you apply the settings to any alarms that are raised for items within that Group.

  7. Save the configuration (see Saving Configuration Changes).

Many of the features listed above are optional and do not affect the structure of the database or, with the possible exception of Alarm Redirection, the performance of the system.


Core Configuration Guide - Place Database Items in a Group (Groups)

Place Database Items in a Group

When you have added a Group, you need to either add items to the Group, or move existing items into it. This section explains how to:

  • Add Items to a Group.
  • Move Items Between Groups.

These principles also apply to Group Templates.

Add Items to a Group

You can add items to a Group or a Group Template.

To add a database item to a Group or Group Template:

  1. In the Database Bar, right-click on the Group or Group Template to which you want to add an item.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the relevant New option. For example, if you want to add a Mimic, select the New option, followed by the Mimic option. (Many menu options will provide access to further menus for specific types of item).
    The new item is added to the selected Group or Group Template. It is selected automatically, ready for you to configure.
    In this diagram, a new Trend has been added to a ‘TRENDS’ Group. The entry is selected, ready to be named.

  3. Enter a suitable name for the item (taking into account the ClearSCADA Naming Restrictions).
  4. Press the Enter key or select another part of the ViewX interface to confirm the name entry.

For more information on configuring the individual items, please refer to the relevant configuration section.

Move Items Between Groups

You can move existing items into a new Group or Group Template.

ATTENTION: If you move an item into a Group Template, it no longer remains ‘live’. However, ‘live’ versions of the item are added to each instance of that Template (see Group Templates and Group Instances).

ATTENTION: If you move an item out of a Group Template, the corresponding item is deleted from each Instance of that Template.

To move an item into a new Group or Group Template:

  1. Select the item in the Database Bar. Do not release the left-hand mouse button.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Drag the cursor so that it is positioned over the Group or Group Template to which you want to move the item.
    The cursor changes shape and the target Group or Group Template is highlighted.
  3. Release the left-hand mouse button.
    The item is moved into the target Group or Group Template.


Core Configuration Guide - Configure the Properties of the Root or System Group (Groups)

Configure the Properties of the Root or System Group

Each ClearSCADA system (database) is represented by a System or Root Group icon in the Database Bar’s tree-structure.

System or Root Group icon.

On ViewX clients that provide access to Multiple Databases, a separate System or Root Group is displayed for each database.

To configure the properties of the System or Root Group:

  1. Right-click on the system in the Database Bar.
    A context-sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option and then the Database option.

  2. Select the Properties option.
    The Root Group Form is displayed.
  3. Use the Identification tab to optionally Specify a Help View and whether to exclude the whole system from exclusive control (see Specify Whether to Exclude a Group or Database Item from Exclusive Control).
  4. Use the User Methods tab to configure any custom pick actions that are required for the system (see Using the User Methods Tab to Define Custom Actions).
  5. Use the Group tab to optionally Define an Alarm View and specify whether the server is to Request Confirmation Before Disabling or Enabling Alarms.

Also use the Group tab for optionally Defining a Default View.

  6. Use the Redirection tab to configure any alarm redirections for the system (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection). These redirections apply to any alarms that are raised on the system, and so can be used to provide an additional alarm redirection cascade to alarm redirections for individual groups or items.
  7. Use the Root Group tab to:
  • Specify the Global Operator Document Store for your System.
  • Specify the Default Area of Interest for your System.
  8. Use the Guest User tab to configure the properties of the Guest User account. This is the built-in user account that is used whenever a user accesses the system without logging on.

The properties on this tab apply to the built-in user account that is used when a user accesses ClearSCADA via ViewX or a third-party application, without logging onto the system.

The Areas of Interest section of the tab is only available for use if the Area of Interest feature is enabled on your system. If enabled, you can use each Area n field to Assign a Different Area of Interest to a User.

For information on configuring other properties on the Guest User tab, see Define the Global Settings for All Guest and Web User Accounts in the ClearSCADA Guide to Security.

NOTE: In addition to the system-wide Guest User properties that you configure on the Root Group, you also need to specify the ViewX properties of the Guest User (see Define the Client Specific Settings for the Guest User in the ClearSCADA Guide to Security).

  9. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Specify the Global Operator Document Store for your System (Groups)

Specify the Global Operator Document Store for your System

An Operator Document Store is a special type of group that allows operators that do not have the Configure permission to edit and configure documents such as Trends.

Use the Operator Document Store field on the Root Group tab of the System or Root Group to specify your system’s global Operator Document Store. The global Operator Document Store is shared by all users that have access to the Operator Document Stores feature.

To specify the global Operator Document Store, select the field’s browse button to display a Reference browse window. Select the required Operator Document Store from the window.

Further Information

Setting up Operator Document Stores.

Configure a User’s Personal Operator Document Store: see Define the Operational ViewX Settings for a User in the ClearSCADA Guide to Security.


Core Configuration Guide - Specify the Default Area of Interest for your System (Groups)

Specify the Default Area of Interest for your System

This section only applies if the Area of Interest feature is enabled on your system (see Restrict Alarm and Event Access to Specific Areas of Interest).

Use the Default Area of Interest field on the Root Group tab of the System or Root Group to specify the Area of Interest that ClearSCADA is to assign to any item that is added to the database.

By default, the ‘World’ Area of Interest is assigned as the Default Area of Interest. If you want to change this to another Area of Interest, select the field’s browse button to display a Reference browse window. Select the required Area of Interest from the window.

Further Information

Restrict Alarm and Event Access to Specific Areas of Interest.


Core Configuration Guide - Group Templates and Group Instances

Group Templates and Group Instances

ClearSCADA includes Group Template and Group Instance features that you can use to significantly reduce the amount of time and effort it takes to configure and maintain your system.

If your system requires multiple, similar configurations, you should consider using Group Templates and Group Instances instead of ‘normal’ Groups and database items (see Groups).

You use a Group Template [image] to create a ‘model’ Group configuration. The items in a Group Template are not ‘live’, there are merely used as a reference for items in Group Instances. Templates enable you to produce one set of configuration and replicate that configuration in as many Group Instances as required. Whenever you alter the configuration of an item in a Group Template, the same alteration is made to the corresponding items in each Group Instance that references that Template.

Group Instance s [image] are ‘live’ versions of a Group Template—they take most of their configuration from the corresponding items in the Group Template.

A Group Template contains ‘model’ configuration. It can contain any number of core, driver-specific or Abstract items.
Each Group Instance is a ‘live’ version of the Group Template. Each Instance contains the same database items as the Template, but they are ‘live’. The items take most of their configuration from the corresponding items in the Group Template. (Property Overrides are used to define which configuration properties are derived from the Template, and which are configured individually in each Group Instance.)

For more information on the components and features associated with Group Templates and Instances, see Understand Templates and Instances, and see Actions Associated with Group Templates and Group Instances.

For factors to consider when planning a Template/Instance ‘modular’ approach to your database, see Preparation.

For the procedure to follow when adding Group Templates and Group Instances to
a ClearSCADA system, see Setting Up Group Templates and Group Instances.


Core Configuration Guide - Understand Templates and Instances (Group Templates and Group Instances)

Understand Templates and Instances

This section provides an overview of the various components and features that are associated with Templates and Instances, including:

  • Group Template
  • Property Overrides
  • Group Instance
  • Abstract Item.


Core Configuration Guide - Group Template (Group Templates and Group Instances)

Group Template

Use a Group Template [image] to create a ‘model’ Group configuration.

The items in a Group Template are not ‘live’—instead, they provide the configuration ‘model’ for items in each of the Group Instances that reference the Group Template.

Within the Group Template, you include the database items that are common to the Group Instances that reference the Group Template. You also configure the properties that are common to those Group Instances. (To specify which properties are common and which properties are unique, you use the Property Overrides feature.)

As such, by using Group Templates, much of the configuration of like-modules is performed only once—in the Group Template. ClearSCADA then automatically replicates that configuration in each of the Group Instances that reference the Group Template. Similarly, any configuration changes made to a Group Template at a future date—for instance, the addition of a new point, or changes to the Template-derived configuration of an existing item—are automatically replicated in each of the Group Instances that reference the Group Template.

Group Templates can considerably reduce the amount of time and effort that it takes to configure and maintain a ClearSCADA system.

(To avoid the need to produce multiple similar Group Templates, you may want to consider including Abstract Items in your Group Template(s), in addition to ‘core’ or driver-specific items.)

You can add multiple Group Templates to a ClearSCADA system. You can also ‘nest’ Group Templates inside other Group Templates.

For an example demonstrating how a modular system might be configured using Templates and Instances, see Configure a Series of Group Templates and Group Instances.

Further Information

Preparation.

Limitations and Restrictions.

Add a Group Template.

Configure a Group Template.

Add Items to a Group Template.

Configure the Items in a Group Template.

Define which Property Values Derive from a Group Template.

Understanding the Property Overrides Window.


Core Configuration Guide - Property Overrides (Group Templates and Group Instances)

Property Overrides

You use the Property Overrides feature to define which property values in a Group Instance are derived from the Group Template, and which property values can be overridden locally, on a per Instance basis.

Property Overrides enable much of the configuration in a modular system to be performed just once—in the Group Template—with ClearSCADA automatically replicating that configuration in each of the Instances that reference the Template. (Similarly, if any of the inherited configuration needs modifying at a future date, the changes need be performed only once, in the Group Template, with the changes automatically being replicated in each Group Instance.)

You use the Property Overrides window to display the configurable properties of the Group Template and each of the database items in that Group Template (see Understanding the Property Overrides Window). You then specify which properties derive from the Template and which properties are configurable on a per Instance basis.

Some configuration properties are optional—they can be selected from a list, or be enabled or disabled. You need to ensure that the required optional features are specified on the configuration Forms of each item in a Group Template before specifying which properties are to be derived from that Template (see Configure the Items in a Group Template).

Certain configuration properties—such as an outstation address—need to be unique. By default, those properties that are deemed to be unique are specified as locally overridden—once you change the value of that property in an Instance, any changes that are then made to that property in the Template will not be inherited by the Instance. Properties that must be unique are fixed as locally overridden and cannot be changed from this setting.

In order for any other properties to be independently configurable within each Group Instance, you need to ensure that those particular properties are specified as locally overridden in the Property Overrides window. If you remove a property override (so that it is no longer locally configurable on a per Instance basis), all Instances of that property revert to the value that is specified in the Group Template.

For further information on using the Property Overrides feature and the Property Overrides window, see Define which Property Values Derive from a Group Template.

For examples demonstrating how Property Overrides might be used on a system, see Use Property Overrides to Optionally Assign PSTN Fallback to a Direct Outstation, and see Define which Connection Settings to use in the Instances of a Channel.

Further Information

Configure the Properties that are Unique to the Items in a Group Instance.


Core Configuration Guide - Group Instance (Group Templates and Group Instances)

Group Instance

A Group Instance [image] is a ‘live’ version of a Group Template—each Group Instance takes most of its configuration details from the corresponding items in the Group Template that it references.

For example, a point in a Group Instance will usually take its configuration details from a corresponding point in the Group Template. Most of the property values for that point will typically come from the Group Template—only those properties that are optional or unique to that particular point, will usually be assigned locally in the Group Instance.

In addition to ‘core’ and driver-specific items, you can optionally add Abstract Item(s) to a Group Template. All of the items that appear in the Group Template are replicated within each Group Instance. Within each Instance, you then ‘turn on’ those Abstract items that are required in that Instance, by converting the Abstract item(s) into the required type of point or outstation. (Any Abstract items that are surplus to requirements in a particular Group Instance are left unconverted and are effectively ignored by ClearSCADA.)

If need be, you can add items locally to a Group Instance. However, we do not recommend this approach—should the Group Instance’s configuration ever be changed to reference a different Group Template, any items that have been created locally in the Group Instance, will be deleted. (Instead of adding items locally, consider using Abstract Items, or assigning the Group Instance to a Group Template that better represents the configuration that is required.)

You can assign multiple Group Instances to a Group Template. You use the Property Overrides feature of the Group Template to specify which configuration properties are derived from the Group Template, and which properties can be overridden locally, from within each Group Instance.

You can use the Locate Template pick action to locate the corresponding Template version of a Group Instance, or the Locate in Template pick action to locate the corresponding Template version of an item in a Group Instance.

For an example demonstrating how a modular system might be configured using Templates and Instances, see Configure a Series of Group Templates and Group Instances.

Further Information

Add a Group Instance.

Configure a Group Instance.

Configure the Properties that are Unique to the Items in a Group Instance.

Optionally Add Items Directly into a Group Instance.

Associate an Unassigned Group Instance with a Group Template.


Core Configuration Guide - Abstract Item (Group Templates and Group Instances)

Abstract Item

You can add ‘core’ or driver-specific items to a Group Template—such items are then replicated in each Group Instance that references the Group Template.

To reduce the need to produce multiple similar Group Templates on a system, you might also want to consider using Abstract items. Abstract items are non-functioning items, which ClearSCADA ignores as they contain only the basic properties of a point or outstation. However, once you convert an Abstract item into a particular point or outstation type, ClearSCADA recognizes and acts on the configuration settings for that instance of the item.

You can add Abstract item(s) to a Group Template, then, within each Group Instance, convert the instances of those Abstract item(s) into the point or outstation types that you require.

You might decide to use Abstract items when, for example:

  • You have more than driver on your system—by using Abstract items, you can configure the ‘core’ properties of a variety of point or outstation types on any driver. Within each Group Instance, you convert the Abstract Items into the point or outstation types supported by the driver for which that particular Group Instance is being configured.

Example:

An Advanced Analog Point Abstract item is added to a Group Template. Within the Template, the Abstract item is used to configure the ‘core’ properties of any point that uses analog-type processing, on any type of Advanced Driver.

Within one Group Instance, configured for use with the DNP3 driver, the Advanced Analog Point Abstract entry is converted into the required point type, and the additional properties specific to that point and driver are configured on the Point Form for that Instance.

Within another Group Instance, configured for use with a different advanced driver, the Advanced Analog Point Abstract entry is converted into the required point type for that driver, and the additional properties specific to that point and driver type are configured on the Point Form for that Instance.

  • The point types vary between Groups on your system—as Abstract items contain only the basic properties for a point or outstation, you can use them as the basis for a wide variety of point or outstation types (see Types of Abstract Item).

Example:

An Advanced Analog Point Abstract item is added to a Group Template. Within the Template, the Abstract item is used to configure the ‘core’ properties of any point that uses analog-type processing, on any type of Advanced Driver.

Within each Group Instance, the Abstract item can be converted into any point type that uses analog-type processing. Points with this type of processing vary with each driver, but may include, for example, 2-limit analog, and 4-limit analog points. A comprehensive list of the points into which you may convert a particular type of Abstract item is given when you opt to convert that item.

  • You have a varying number of items within Group Instances on your system—by using Abstract items, you can configure the maximum number of items that you need within the Group Template, then in each Group Instance, you only convert the number of items that you require in that particular Group. ClearSCADA will ignore any items that remain as Abstract items.

Example:

Within the Group Template, eight Advanced Analog Point Abstract items are configured with the ‘core’ properties of each point that uses analog-type processing, on an Advanced Driver.

Within one instance, configured for use with the DNP3 driver, the eight Abstract items are converted into eight DNP3 Analog Input Points. The DNP3-specific features are configured on the individual Point Forms for each point within the Group Instance.

Within another Instance, configured for use with the DNP3 driver, five of the Abstract items are converted into DNP3 Analog Input points. As the other items remain Abstract items, they are ignored by ClearSCADA and effectively do not exist in that Group on the system.

For an example further demonstrating how Abstract Items might be used on a system, see Convert an Abstract Item into a Specific Type of Point.

Further Information

Add an Abstract Item to a Group Template.

Types of Abstract Item.

Convert an Abstract Item into a ‘Real’ Point or Outstation.


Core Configuration Guide - Preparation (Group Templates and Group Instances)

Preparation

If the physical structure of your system can be split into ‘modules’ and you intend using Group Templates and Group Instances to configure those modules, you will need to consider:

  • How many different ‘modules’ exist on your system—You will need to add one Group Template for each different ‘module’. (Remember that if ‘modules’ only differ slightly—say in the number or type(s) of point that each module contains—it may be possible to use Abstract Items to produce the ‘base’ configuration for those items. Using Abstract items can avoid the need to produce multiple Group Templates.) Ensure that you are aware of any Limitations and Restrictions.
  • The content of each of Group Template—You will need to decide on the number and type of ‘core’, driver-specific, and/or Abstract items that you need to include in each Group Template. Each of these items will be replicated in each Group Instance that references the Group Template.
  • The complexity and size of the Group Template and Group Instance configuration—If any of the Group Templates on your system are likely to be referenced by 100 or more Group Instances, consider enabling the server’s Template Transactions feature (see Template Transactions in the ClearSCADA Guide to Server Administration). This feature can reduce the amount of time for which access to the database is blocked while the server propagates any Group Template configuration changes to each of the Group Instances that reference that Group Template. (If fewer than 100 Group Instances reference each Group Template, the time for which the database is ‘locked’, if unnoticeable, only comprises a few seconds.)
  • Which Properties are to be Optional or Unique—You will need to decide which configuration properties are to be optional or unique to each database item in the Template. (You use the Property Overrides feature of the Group Template to specify which properties are derived from the Template and which can be overridden locally, on a per-item basis in each Group Instance.)
  • Naming Convention—Remember that the name that you give to an item in a Group Template is replicated in each Group Instance that references that Template. You cannot rename an item in a Group Instance directly—you can only rename an item in a Group Template. (The exception is an item that has been added locally to a Group Instance (not recommended).) You therefore need to decide on a suitable naming convention for the items that appear in your Templates and Instances (taking into account the ClearSCADA Naming Restrictions).


Core Configuration Guide - Limitations and Restrictions (Group Templates and Group Instances)

Limitations and Restrictions

You can include any item in a Group Template, except the following:

  • Another Group Template
  • An Operator Document Store
  • A Data Table
  • A User
  • A Script Library
  • A Function Block Library
  • A Structured Text Library.

If need be, you can Optionally Add Items Directly into a Group Instance. However, you need to be aware of the following:

  • Any item that you add locally to a Group Instance will be automatically deleted if the Instance’s configuration is later changed to reference a different Group Template.
  • You can add any item other than a Group Template locally to a Group Instance.
  • If you add a Group Instance to another Group Instance, each of those Instances has to reference a different Group Template (a Group Instance cannot reference the Group Template of any Group Instance in its parent chain).

ClearSCADA supports Incremental Import. If you use the Import or Import & Merge menu options to import configuration from one ClearSCADA database to another, be aware of the following:

  • The configuration of a Group Instance that is imported successfully into a database is compared to that of its Group Template (ClearSCADA automatically runs the Repair Instance method on each imported Group Instance). ClearSCADA checks whether any changes have been made to the Group Template between the Instance being exported and then imported. It then applies any changes that are found to the Group Instance.
  • If a Group Instance is imported into a database and that import would result in a situation in which the Group Instance would be invalid:
  • The imported Group Instance will be converted into a ‘normal’ Group
  • Any database items in the Instance that are not supported by normal Groups (such as Abstract Items) will be deleted.

Situations in which a Group Instance would be invalid include:

  • A Group Instance being imported into a database in which the Instance’s referenced Group Template does not exist
  • A Group Instance being imported into its own Group Template
  • A Group Instance being imported into another Group Instance, which itself references the same Group Template as the Group Instance that is being imported.

Should you make changes to a Group Template which has Group Instances that reference it, ClearSCADA will automatically propagate the changes to each of those Group Instances. With Group Templates that are referenced by fewer than 100 Group Instances, the time taken to propagate such changes should take only seconds, if noticeable at all. With large or complicated Group Template and Group Instance set-ups, there may be a noticeable period for which access to the database is prevented while the server propagates those changes. The time for which the database is ‘locked’ is reduced if the server’s Template Transactions feature is enabled (see Template Transactions in the ClearSCADA Guide to Server Administration). Should this feature be enabled, ClearSCADA will block attempts to make certain changes locally to a Group Instance while the server is in the process of propagating any Group Template configuration changes to that Group Instance. For a summary of the type of changes that ClearSCADA blocks until it has completed propagating Group Template changes to a Group Instance, see Configuration Changes and Structure Changes in the ClearSCADA Guide to Server Administration.

Further Information

Limitations if you Convert an Item in a Group Template (other than an Abstract Item).


Core Configuration Guide - Setting Up Group Templates and Group Instances (Group Templates and Group Instances)

Setting Up Group Templates and Group Instances

This section explains how to set up a Group Template and a Group Instance. You can use the principles of the following procedure to construct more complex Group Template and Group Instance set-ups that are more suited to your specific requirements.

To set up a Group Template and Group Instance:

  1. Ensure that you have carried out any necessary Preparation.
  2. Add a Group Template.
  3. Configure the Group Template (see Configure a Group Template).
  4. Add items to the Group Template.

You need to add database items that meet your requirements. Remember that these items do not actually represent ‘live’ data.

For further information, see Add Items to a Group Template and, if applicable, see Add an Abstract Item to a Group Template.

  5. Configure the items in the Group Template (see Configure the Items in a Group Template).
  6. Use the Property Overrides feature to define which properties can be overridden locally by the Group Instances (see Define which Property Values Derive from a Group Template).
  7. Set the required security for the Group Template and its content (the same security settings will apply to all Instances that reference the Template, unless you set security to be overridden locally by the Group Instances).
  8. Add a Group Instance.

Versions of the items that you have added and configured in the Group Template will be added automatically to the Group Instance. Each item in the Group Instance will have the same configuration as the corresponding item in the Group Template.

The database items in the Group Instance will be ‘live’ and will represent actual programs, or plant, and so on. (The exception to this is any Abstract Items that you will need to convert into specific types of point or outstation in order for them to become ‘live’.)

  9. Configure the Group Instance (see Configure a Group Instance).
  10. For each item within the Group Instance, configure those properties that can be overridden locally in the Group Instance—for example, any outstation or point addresses (see Configure the Properties that are Unique to the Items in a Group Instance).
  11. If applicable, convert into specific point or outstation types, any Abstract Items that are to be used in the Group Instance (see Convert an Abstract Item into a ‘Real’ Point or Outstation).

You will need to configure any type-specific properties in the converted item.

Where an Abstract item remains unconverted, it will effectively be ignored by ClearSCADA.

  12. Repeat steps 8 onwards for any further Group Instances that are to reference the same Group Template.

If required, you can make further configuration changes to a Group Template and items in that Group Template after Group Instances have been associated with that Group Template. ClearSCADA will propagate any such changes to each of the Group Instances that reference that Group Template. The time taken to do this, if noticeable, should only be seconds providing that fewer than 100 Group Instances reference the Group Template. With a larger number of Group Instances, access to the database might be prevented for a more noticeable amount of time. The time that the database is ‘locked’ is reduced if the server’s Template Transactions feature is enabled (see Template Transactions in the ClearSCADA Guide to Server Administration).

Further Information

Actions Associated with Group Templates and Group Instances.


Core Configuration Guide - Add a Group Template (Group Templates and Group Instances)

Add a Group Template

You need to add a Group Template to contain the ‘model’ configuration. This configuration data will be referred to by ‘live’ database items in Group Instances.

To add a Group Template:

  1. In the Database Bar, right-click on the group or system to which you want to add the Group Template.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Group option.
    A further menu is displayed.
  4. Select the Template option.
    A Group Template is added to the selected group or system, and appears as a Group Template folder in the Database Bar tree structure. The Template is selected automatically, ready for you to define its name.
  5. Enter a suitable name for the Group Template, taking into account the ClearSCADA Naming Restrictions. (The name can be unique to the Template—you name each of the Instances that reference the Template when you create those Instances.)
  6. Press the Enter key or select another part of the ViewX display to confirm the name entry.

Once you have added a Group Template, you can use the Group Template Form to configure the Template (see Configure a Group Template).

You can then add database items to the Group Template (see Add Items to a Group Template), and use the relevant Forms to configure those items.


Core Configuration Guide - Configure a Group Template (Group Templates and Group Instances)

Configure a Group Template

To configure a Group Template, you need to display its Form. The Group Template Form contains the fields that are required to configure a Group Template.

To display the Group Template Form and configure the properties on that Form:

  1. Right-click on the Group Template in the Database Bar.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the Properties option.
    The Group Template Form is displayed.
    Identification tab
    Group tab
    Redirection tab
    User Methods tab

  3. Use the Group Template Form to:
  1. Define the identification details (see Defining Identification Details).
  2. Associate any default views with the Group Template (see Defining an Item or Group’s Alarm Properties).

NOTE: The Alarm Redirection feature is not used on Group Templates—the items in the Template are not ‘live’ items and do not raise alarms. Similarly, the User Methods feature is not used on Group Templates. However, you can configure these features on items within a Group Template, so that the required functionality is made available to the corresponding items in each Instance of that Template.

  4. Save the configuration (see Saving Configuration Changes).

When you have added and configured the Group Template, you need to add database items to it (see Add Items to a Group Template). You should then configure the database items in the Group Template and specify any Property Overrides, before you Add a Group Instance.


Core Configuration Guide - Add Items to a Group Template (Group Templates and Group Instances)

Add Items to a Group Template

You add most items to a Group Template in the same way as you add items to a ‘normal’ Group (see Place Database Items in a Group).

Remember that the items in a Group Template do not actually represent ‘live’ data—they are the ‘model’ for the ‘live’ items in each Group Instance that references the Template.

When deciding what items to add to a Group Template, take into account any Limitations and Restrictions. Whatever database items you add to a Group Template are automatically replicated in each Instance that references the Template.

If the outstations or points are to vary in type or number in the Instances that reference a Group Template, consider adding Abstract Items to your Template (see Add an Abstract Item to a Group Template).

When assigning names to items in a Group Template, take into consideration the fact that those names will be inherited by each Instance that references the Template. (You cannot rename items within a Group Instance directly—the names are inherited from the Group Template that the Instance references.) If necessary, you can rename the items within a Group Template at a later stage—the same alteration will occur in each Instance that references the Template.

When you have added the required items to the Group Template, you will need to configure each of those items in the Template (see Configure the Items in a Group Template). The configuration that you specify automatically becomes replicated for the version of the item in each Group Instance that references the Template.

Use the Property Overrides feature to define which configuration properties can be overridden locally in each Group Instance, and which are derived from the Template (see Define which Property Values Derive from a Group Template).

To ‘activate’ an Abstract Item, you convert it to the required type of point or outstation, within a Group Instance (see Convert an Abstract Item into a ‘Real’ Point or Outstation).

For information on configuring database items, see the relevant configuration section.


Core Configuration Guide - Configure the Items in a Group Template (Group Templates and Group Instances)

Configure the Items in a Group Template

When you add items to a Group Template, you need to configure those items, as you would items in a ‘normal’ Group. You need to take into account that much of the configuration will be replicated automatically in the Group Instances that reference the Template.

Some features that you configure on Forms can be enabled or disabled (for example, the use of PSTN fallback on a direct outstation). When enabled, further fields may become available for use.

Some features that you configure on Forms are optional (for example, the type of connection that a channel uses). Optional features typically display a list of options—the option that you select often determines the fields that are displayed for the feature.

On the configuration Form of each item in a Group Template you need to:

  • Enable those features that are to be enabled in all (or many) of the Instances that reference the Template. Configure any of those feature’s properties that are to be inherited from the Template.
  • Define the default settings for any optional features. This will determine which fields are available for that feature in the Instances that reference the Template.

You can then Define which Property Values Derive from a Group Template and which properties can be specified locally in each Group Instance.

If you include any Abstract Items in your Group Template, you will only be able to configure the ‘base’ properties for those items in the Template. Once you have added Group Instances to your system, you can convert the Abstract Items into the required type of point or outstation, within each Instance (see Convert an Abstract Item into a ‘Real’ Point or Outstation).

For information on configuring database items, see the relevant configuration section.


Core Configuration Guide - Define which Property Values Derive from a Group Template (Group Templates and Group Instances)

Define which Property Values Derive from a Group Template

Configuration that does not vary in the Group Instances that reference a Group Template need be specified only once—in the Group Template. You use the Template’s Property Overrides feature to specify which configuration is derived automatically from the Group Template, and which configuration needs to be specified on a per Instance basis.

To use the Property Overrides feature to specify which property values derive from a Group Template:

  1. Configure the Items in a Group Template.

(The properties are that are included in the Property Overrides window will vary, depending on the items’ configuration.)

  2. Right-click on the relevant Group Template in the Database Bar.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  3. Select the Property Overrides option.
    The Property Overrides window is displayed. It contains a tree-structure that, at the top level, consists of the items in the Group Template, and any overrides for the Template itself (see Understanding the Property Overrides Window).

By default, most configuration properties are set as derived from the Template and are therefore not configurable on a per Instance basis. Only those properties that are deemed to be unique are, by default, set as being configurable locally in each Instance of a Template.

You need to use the Property Overrides window to alter any of the properties that need changing from their present configuration.

  4. Expand the branch of the item for which you want to change or check the configuration.
    The tree-structure expands to display the properties of the item you have selected.
  5. Select the properties that you want to be able to configure locally, on a per Instance basis.
    A check mark [image] is displayed next to each property that can be overridden (if a property is selected accidentally, de-select the property to remove the check mark).
    Select those properties that you want to be able to configure on a per item basis within each Group Instance.

NOTE: A ‘grayed out’ property box indicates a property that is fixed and cannot be changed for that particular type of feature. If a particular property cannot be set for overriding from a Group Instance, its property box is empty but ‘grayed out’. If a property must be unique, the property box will include a check mark and may also be ‘grayed out’ to indicate that the property must be configured on a per-Instance basis.
If the properties that you are looking for are not displayed, ensure that you have enabled the feature, or selected the required option on the relevant Form (see Configure the Items in a Group Template).

  6. Select the OK button.
    The Property Overrides window is closed.

You will now be able to configure the selected properties of the items, directly in each Group Instance that references the Template.

For examples that further demonstrate how the Property Overrides feature might be used on a ClearSCADA system, see Example Configuration.


Core Configuration Guide - Understanding the Property Overrides Window (Group Templates and Group Instances)

Understanding the Property Overrides Window

The Property Overrides window allows you to specify which property values are inherited from an item in a Group Template, and which properties are configurable locally, in each Group Instance that references the Template.

You use the Property Overrides pick action to display the Property Overrides window (see Define which Property Values Derive from a Group Template).

The window displays the configurable properties of the Group Template and the database items that have been added to that Group Template.

The Property Overrides window displays the configurable properties of a particular Group Template...
...along with a branch for each of the items that reside in that Group Template.

To access the properties for a particular item in a Template, you expand the tree structure for that item:

The Form for a direct channel has seven tabs...
The Property Overrides window contains a property check box for each of the seven tabs on the Channel Form...
...you then expand the branch of whichever tab you want to display the properties.

To display the properties of any optional features for an item, you need to have specified the required option on the configuration Form for that item, before displaying the Property Overrides window (see Configure the Items in a Group Template).

The check boxes in the Property Overrides window indicate either:

  • The root of a property branch ( [image] ).
  • A property that is derived from the Group Template ( [image] ) and is therefore not configurable from within any Instances of that Template.
  • A property that can be configured independently ( [image] ) in each Instance that references the Group Template. (By default, those properties that are deemed to be unique are selected as locally overridable, on a per Instance basis.)

If you later remove an override (by clearing a property’s check box), the Instances of that property revert to the value that is set in the Group Template.

  • A property that must be configured independently ( [image] ) in each Instance. As the property must be unique, the check box is ‘grayed out’ to indicate that its setting is fixed.

For examples demonstrating how properties might be configured on a Template and Instance basis, see Example Configuration.

In addition to a property check box for each field on an item’s Form, the Property Overrides window also displays check boxes for:

  • AccessControlList—Use this property check box to specify whether the security settings for an item are inherited from the Group Template, or are configurable on a per Instance basis.

When security is inherited from the Template (the default setting), the Security pick action is not available on any Instances of that item. (For more information on security, see Database Security.)

  • ColourPalette—Use this property check box to specify whether the Color Palette for an item is inherited from the Group Template, or is configurable on a per Instance basis.

When the Color Palette is inherited from the Template (the default setting), the Color Palette pick action is not available on any Instances of that item. (For information on using the Color Palette, see System Colors.)

  • DocumentContent—This property exists for any database item for which you can configure the content separately from the item’s Form. For instance, a Mimic, Trend, Schedule, or Logic Program for which you use an Editor to configure some of the content.

Use the DocumentContent property check box to specify whether the above content of these files is inherited from the Template (the default), or whether their configuration can be modified locally, on a per Instance basis.

When the file content is inherited from the Template, any changes that are made to the item’s content in the Template will automatically be replicated in the Instances of that item. Within the Instances themselves, you will only be able to display the item in ‘Run’ mode (the Edit pick action will not be available).

If the DocumentContent property is locally overridden, any further changes that are made to the item’s content in the Template, will not be replicated in the Instances. If you remove a DocumentContent override (by clearing a property’s check box), the Instances revert to using the document content that is specified in the Group Template.

  • Any custom field(s) that have been added to item(s) in the Template—Use the property check box to specify whether the value of each Custom Field is configurable on a per Instance basis, or is inherited from the Group Template.

Further Information

Define which Property Values Derive from a Group Template.

Configure the Properties that are Unique to the Items in a Group Instance.


Core Configuration Guide - Add a Group Instance (Group Templates and Group Instances)

Add a Group Instance

This section explains how to add a Group Instance. You typically only add Group Instances once the relevant Group Template(s) exist in the database (see Setting Up Group Templates and Group Instances).

To add a Group Instance and associate that Instance with a Template:

  1. In the Database Bar, right-click on the Group or System to which you want to add the Group Instance.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the New Instance option.
    A list of existing Group Templates is displayed.

(If any of your Group Templates are stored in Group directories off the root group, further level(s) of menu option are displayed—select the required directory name in order to display the list of Group Templates.)

  3. Select the Group Template with which the Instance is to be associated.
    A Group Instance is added to the selected group or system, and appears as a Group Instance folder in the Database Bar tree structure. The Instance is selected automatically, ready for you to define its name.
  4. Enter a suitable name for the Group Instance (taking into account the ClearSCADA Naming Restrictions).
  5. Press the Enter key or select another part of the ViewX display to confirm the name entry.

NOTE: If you want to add a Group Instance to your database, but the Group Template with which the Instance is to be associated is undecided, you can add an Instance by selecting the New option, followed by the Group option and then the Instance option. The Instance will have no database items associated with it until you assign it to a Group Template (see Associate an Unassigned Group Instance with a Group Template).

Once you have added a Group Instance, you can use the Group Instance Form to configure it (see Configure a Group Instance).

NOTE: If the Template Transactions feature is enabled on your system, attempts to make changes locally to a Group Instance will be blocked while ClearSCADA propagates any Group Template configuration changes to that Group Instance. For more information, Template Transactions in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Configure a Group Instance (Group Templates and Group Instances)

Configure a Group Instance

To configure a Group Instance, you need to display its Form. The Group Instance Form contains the fields that are required to configure a Group Instance.

To display the Group Instance Form:

  1. Right-click on the Group Instance in the Database Bar.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the Properties option.
    The Group Instance Form is displayed.
    Reference tab
    Identification tab
    User Methods tab
    Redirection tab
    Group tab

Use the Group Instance Form to:

  1. Define any identification details that are not inherited from the Group Template (see Defining Identification Details).
  2. Configure any custom pick actions that are required for the Group (see Using the User Methods Tab to Define Custom Actions).
  3. Define the alarm redirection details that are not inherited from the Group Template (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  4. Save the configuration (see Saving Configuration Changes).

NOTE: The Alarm, Default, and Help Views are inherited from the Group Template, unless their property overrides are enabled (see Define which Property Values Derive from a Group Template).
The association with a Group Template is made when a Group Instance is added to ClearSCADA. If necessary, this reference can be changed to associate the Group Instance with a different Group Template (see Associate an Unassigned Group Instance with a Group Template).

Once you have configured the Group Instance, you can Configure the Properties that are Unique to the Items in a Group Instance.


Core Configuration Guide - Configure the Properties that are Unique to the Items in a Group Instance (Group Templates and Group Instances)

Configure the Properties that are Unique to the Items in a Group Instance

When you associate a Group Instance with a Group Template, ClearSCADA adds a copy of the items in the Group Template to that Group Instance. The copy contains the same configuration as the items in the Group Template.

Unless a property is specified as being locally overridden (see Define which Property Values Derive from a Group Template), whenever any updates are made to that property in the Group Template, the same updates will occur in the Group Instance.

For any locally overridden properties, you need to specify the required values of those properties in each Group Instance. (Properties that are not configured as locally overridden are ‘grayed out’ and unavailable for selection on the item’s configuration Form, in the Group Instance.)

See a system administrator if any properties that need specifying locally in a Group Instance are ‘grayed out’ and unavailable for use.

If a local override is later removed (by clearing a property’s check box), the Instances of that property will revert to using the value that is set in the Group Template.

If a Group Instance contains any Abstract Items, you need to convert those items into the required type(s) of outstation or point, in order to ‘activate’ those items (see Convert an Abstract Item into a ‘Real’ Point or Outstation). You then need to configure the additional properties that become available for those items in each Group Instance. (If a particular Abstract item is not needed in a Group Instance, leave it as an Abstract item—it will be ignored by ClearSCADA.)

If required, you can also Optionally Add Items Directly into a Group Instance.

You can use the Locate Template pick action to locate the corresponding Template version of a Group Instance, or the Locate in Template pick action to locate the corresponding Template version of an item in a Group Instance.


Core Configuration Guide - Optionally Add Items Directly into a Group Instance (Group Templates and Group Instances)

Optionally Add Items Directly into a Group Instance

If required, you can add item(s) locally to a Group Instance.

ATTENTION: If you add an item locally to a Group Instance and later change that Instance’s configuration so that it references a different Group Template, the locally created item(s) will be deleted.

Before adding an item locally—especially if such items need adding to more than one Group Instance—first consider:

  • Adjusting the content of the referenced Group Template so that it includes the required item (see Add Items to a Group Template).
  • Adding Abstract Item(s) to the referenced Group Template (see Add an Abstract Item to a Group Template). You can convert Abstract items to different types of outstation or point, in different Group Instances, or leave them unconverted (and therefore unused) in those Instances in which they are not required.
  • Changing the Instance’s reference to that of a more suitable Group Template (see Convert a Group Instance to Reference a Different Group Template). Be aware that any local configuration will be lost on conversion to another Template.

If you decide to add an item locally to a Group Instance, you will need to take into account any Limitations and Restrictions. You will also need to configure that item’s properties locally in the Group Instance. (Refer to the appropriate item-specific configuration section for more information.)

An item that has been added locally to a Group Instance is identified by the absence of an arrow overlaying the icon in the Database Bar. The lack of an arrow indicates that the item is not Template-controlled, and that any changes to that item have to be made locally in the Group Instance.

An item that has been added locally to a Group Instance is identified by the absence of an arrow overlaying its icon in the Database Bar.
The icons of other items in a Group Instance are overlaid by an arrow...
...indicating that their configuration is at least partially inherited from the Group Template to which the Group Instance references.


Core Configuration Guide - Associate an Unassigned Group Instance with a Group Template (Group Templates and Group Instances)

Associate an Unassigned Group Instance with a Group Template

The association with a Group Template is typically made whenever a Group Instance is added to the ClearSCADA database (see Add a Group Instance). Using this association enables the Group Instance to contain a ‘live’ version of the database items within the Group Template. If you assigned a Template to your Group Instance when you added the Instance to the database, you can ignore this section.

However, you can also add a Group Instance to your system without initially assigning it to a Group Template (see Add a Group Instance).

To associate such a Group Instance with a Group Template:

  1. Configure a Group Instance.
  2. Select the Reference tab.
    Reference tab

  3. Select the browse button next to the Template field.
    A Reference browse window is displayed.
  4. Use the Reference browse window to locate the Group Template with which the Group Instance is to be associated.
  5. Select the required Group Template.
  6. Select the OK button.
    The Reference browse window is closed and the name of the selected Group Template is shown in the Template field.
  7. Save the configuration (see Saving Configuration Changes).
  8. Expand the Group Instance in the Database Bar.
    The Group Instance contains ‘live’ versions of the items in the Group Template.
    Group Template contains configuration ‘models’.
    Group Instance contains ‘live’ database items. The items take their configuration from the corresponding items in the Group Template.

NOTE: If necessary, you can change the Group Instance reference, so that a Group Instance becomes associated with a different Group Template. However, we do not recommend changing such a reference, as any configuration that is not duplicated in both Group Templates will be lost as soon as a Group Instance references a different Group Template—for further information, see Convert a Group Instance to Reference a Different Group Template.

If you display the Forms for items in a Group Instance, you will see that many of the configuration fields are ‘grayed out’—such configuration is defined in the Group Template and cannot be altered on an individual basis without using the Property Overrides feature (see Define which Property Values Derive from a Group Template).

Fields for items in Group Instances are ‘grayed out’ unless you can override the property locally in each Group Instance.


Core Configuration Guide - Add an Abstract Item to a Group Template (Group Templates and Group Instances)

Add an Abstract Item to a Group Template

To reduce the need for multiple similar Group Templates on your system, you can add Abstract point and outstation items to your Group Templates. The Abstract Items are ignored by the server, until you convert them into non-abstract point or outstation types, within the Group Instances.

To add an Abstract item to a Group Template:

  1. In the Database Bar, right-click on the Group Template to which you want to add an item.
    A context sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Abstract option.
    A further menu is displayed.

NOTE: Some drivers also support driver-specific Abstract items. To add a driver-specific Abstract item, select the <Driver Name> option (for example, DNP3), rather than the Abstract option.

  4. Select the relevant type of Abstract item (see Types of Abstract Item).
    An Abstract item is added to the selected Group Template. The Abstract item is selected automatically, ready for you to define its name.

Example:

An Abstract Advanced Digital Point is added to a Group Template

  5. Enter a suitable name for the Abstract item (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key, or select another part of the ViewX Interface to confirm the name entry.

Suitably configure the Abstract item within the Group Template, and specify any local overrides, as appropriate (see Configure the Items in a Group Template, and see Define which Property Values Derive from a Group Template).

Once you have added a Group Instance and associated it with your Group Template (see Add a Group Instance), you can convert the Abstract item into a specific type of point or outstation within that Group Instance (see Convert an Abstract Item into a ‘Real’ Point or Outstation).

For an example demonstrating how Abstract Items might be used on a system, see Convert an Abstract Item into a Specific Type of Point.

NOTE: If the Template Transactions feature is enabled on your system, attempts to add or convert an Abstract item will be blocked while ClearSCADA propagates any Group Template configuration changes to the Group Instance in which that item resides. For more information, see Template Transactions in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Types of Abstract Item (Group Templates and Group Instances)

Types of Abstract Item

The following table lists the types of Abstract Item that you can add to Group Templates, along with the type of item that you can convert them into within each Group Instance.

Refer to the driver-specific documentation for the types of outstation and point that are supported by the drivers on your system, before adding Abstract items to any Group Templates that you are configuring, to ensure that you select the most appropriate types. In addition to the items listed below, some drivers also support driver-specific Abstract items. For information on any Abstract items not listed below, see the relevant driver guide.
Abstract Item | Converts To:
Advanced Analog Point | Any point with analog-type processing on any advanced driver
Advanced Counter Point | Any counter point on any advanced driver
Advanced Digital Point | Any point with digital-type processing on any advanced driver
Advanced Point | Any point type on any advanced driver
Advanced Point (Current Data) | Any point type on any advanced driver for which the server can retrieve only current data
Advanced Point (Current and Logged Data) | Any point type on any advanced driver for which the server can retrieve both current and logged data
Advanced Point (Logged Data) | Any point type on any advanced driver for which the server can retrieve only logged data (time stamped data stored in the outstation)
Advanced Pulse Action | A pulse action on any advanced driver
Advanced String Point | A string point on any advanced driver
Outstation | Any type of direct or PSTN outstation
PSTN Outstation | Any type of PSTN-only outstation
Point | Any type of point, including internal points
Point Source | Scanner, ODBC Query, or Random Generator, and so on.
Simple Analog Point | Any internal or simple driver point with analog-type processing
Simple Counter Point | Any internal or simple driver counter point
Simple Digital Point | Any internal or simple driver point with digital-type processing
Simple Point | Any internal or simple driver point
Simple String Point | Any internal or simple driver string point
Simple Time Point | Any internal or simple driver time point

Further Information

Add an Abstract Item to a Group Template.

Convert an Abstract Item into a ‘Real’ Point or Outstation.


Core Configuration Guide - Convert an Abstract Item into a 'Real' Point or Outstation (Group Templates and Group Instances)

Convert an Abstract Item into a ‘Real’ Point or Outstation

You can add Abstract Items to Group Templates in order to reduce the need to configure multiple similar Templates on your system (see Add an Abstract Item to a Group Template).

The Abstract items contain only the basic properties for a point or outstation, and are ignored by ClearSCADA until you convert them into specific points or outstations.

You convert the Abstract items within each Group Instance, and then configure the additional properties that become available on the Form for each item.

To convert an Abstract item within a Group Instance:

  1. Right-click on the Abstract item in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Convert To option.
    A list of items is displayed. The list varies, depending on the type of Abstract item and the drivers on your system (see the example, below).
  3. Select the type of point or outstation that you require in your Group.
    The Abstract item is converted into the selected type of item, and becomes a ‘real’ point or outstation.
  4. Configure the additional properties that become available on the configuration Form for that item (see the relevant configuration section for details).
  5. Repeat the above steps for any other Abstract items that you want to convert in a Group Instance.

If a Group Instance contains more Abstract items than you require in that Group, only convert those Abstract items that are required.

Any items that remain as Abstract items are for the most part ignored by ClearSCADA and effectively do not exist in the database for that Group. However, you need to ensure that any Abstract items that might not be used within all Instances are not featured on any Mimics or Trends within the Group Template. (If required, you can specify that a Mimic’s or Trend’s DocumentContent property be locally overridden. You can then add the item to the Mimics or Trends in those Group Instances in which the item has been converted to a specific outstation or point type—for more information, see Understanding the Property Overrides Window.)

Further Information

Types of Abstract Item.

Example:

An Abstract Outstation in the Instance ‘Zone 1’...
...is selected for conversion into a specific type of outstation.
The actual conversion options vary, depending on the type of Abstract item and the drivers that are installed on the system.


Core Configuration Guide - Converting Groups and Group Instances (Group Templates and Group Instances)

Converting Groups and Group Instances

You can convert a Group into a Group Template, a Group Instance into a Group, or a Group Instance so that it references a different Group Template. This reduces the amount of configuration required to set up your system, as it allows you to alter existing items, rather than having to create new Groups or Group Templates. It also provides flexibility, as it allows you to incorporate changes to your original system plan.

This section explains how to:

  • Convert a Group into a Group Template
  • Convert a Group Instance into a Group
  • Convert a Group Instance to Reference a Different Group Template.

It also explains the restrictions that apply if you Convert an Item in a Group Template, and that item is not an Abstract Item.

NOTE: If the Template Transactions feature is enabled on your system, attempts to convert a Group Instance will be blocked while ClearSCADA propagates any Group Template configuration changes to that Group Instance. For more information, see Template Transactions in the ClearSCADA Guide to Server Administration.

Further Information

Convert an Abstract Item into a ‘Real’ Point or Outstation.


Core Configuration Guide - Convert a Group into a Group Template (Group Templates and Group Instances)

Convert a Group into a Group Template

You can convert a normal Group into a Group Template. This is especially useful when you have set up a Group and its items and have then realized that this information could be duplicated to produce other like areas of configuration on your system.

In order to convert a Group into a Group Template successfully, that Group must not contain any inward references from elsewhere in the system (as such references (‘links’) would become invalid and get broken when that Group is converted into a Group Template). If such links exist in the Group, ensure that they are suitably replaced before attempting the conversion (see Displaying a Database Item’s References). An attempt to convert a Group to a Group Template while that Group includes inward links will not complete—instead a diagnostic message will be displayed listing the reference(s) that need changing before the conversion can take place.

To convert a Group into a Group Template:

  1. In the Database Bar, right-click on the Group you want to convert.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the Convert To option.
    A further menu is displayed.
  3. Select the Group Template option.
    The Group is converted into a Group Template.

You can now configure the Group Template’s Property Overrides (see Define which Property Values Derive from a Group Template), and add Instances of the Group Template to your system (see Add a Group Instance).


Core Configuration Guide - Convert a Group Instance into a Group (Group Templates and Group Instances)

Convert a Group Instance into a Group

You can convert a Group Instance into a normal Group. This is useful if you no longer want a Group Instance to refer to a Group Template, but still require the configuration data in the Group Instance.

To convert a Group Instance into a normal Group:

  1. Ensure that the Group Instance does not contain any database items (such as Abstract Items) that are not supported by ‘normal’ Groups.

ATTENTION: Do not delete the Group Instance’s reference to its Group Template, as this will remove the items in the Group Instance.

  2. In the Database Bar, right-click on the Group Instance that you want to convert.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  3. Select the Convert To option.
    A further menu is displayed.
  4. Select the Group option.
    The Group Instance is converted into a Group. The properties of the items in the Group are now configurable locally, as they are no longer inherited from any Group Template.

If the conversion is attempted on a Group Instance that contains database items that are not supported by ‘normal’ Groups, a diagnostic message will be displayed:

Convert the unsupported item into a type of item that is supported by a normal Group, then repeat the above steps to convert the Group Instance. (You cannot delete an item in a Group Instance directly, unless the item has been added locally to the Group Instance.)

Further Information

Convert an Abstract Item into a ‘Real’ Point or Outstation.

For more information on the Convert Object window that lists any incomplete, conflicting, or invalid configuration, see Converting a Database Item.

For information on configuring items in a Group, see the relevant configuration section.


Core Configuration Guide - Convert a Group Instance to Reference a Different Group Template (Group Templates and Group Instances)

Convert a Group Instance to Reference a Different Group Template

You can convert an Instance of one Group Template so that it becomes an Instance of a different Group Template. This procedure should only be used in exceptional circumstances—before using this process, you need to be aware of the following:

  • Configuration that is not replicated in both Group Templates will be lost following the conversion process.
  • Identically named database items have to exist within both Templates in order for those items to be preserved in the Instance. Those items that are replicated in both Templates will take on the values specified in whichever Group Template the Instance references.
  • Any configuration that has been specified in the Instance, rather than in the Template, will be preserved only if the configuration properties are enabled for overriding in both Templates, and only if those items are identically named in both Templates.
  • Any items that have been added locally to the Instance (they did not exist in the Template to which the Instance referenced), will be lost following the conversion process.

To convert a Group Instance so that it references a different Group Template
(not recommended):

  1. In the Database Bar, right-click on the Group Instance that you want to convert.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the Convert To option.
    A further menu is displayed.
  3. Select the Instance Of option.
    A list of existing Group Templates is displayed.

(If any of your Group Templates are stored in Group directories off the root group, further level(s) of menu option are displayed—select the required directory name in order to display the list of Group Templates.)

  4. Select the Group Template that the Instance is to reference
    The Group Instance is converted to reference the selected Group Template. Any configuration that is not replicated both in name and type within both Templates will be lost. (For other restrictions, see above.)
  5. Expand the Group Instance in the Database Bar.
  6. Specify any Instance-specific configuration that is required for the database items within the Instance (refer to the appropriate configuration sections within the ClearSCADA documentation for information).


Core Configuration Guide - Convert an Item in a Group Template (Group Templates and Group Instances)

Convert an Item in a Group Template

Be aware that should you use the Convert To feature to convert a database item in a Group Template into a database item of another type, any ‘children’ that reference that item will remain unchanged, regardless of whether the equivalent conversion type exists for those items.

For example, if you convert a DNP3 outstation into a Kingfisher outstation in a Group Template, ClearSCADA converts that outstation in the Template and replicates the conversion in any Group Instances that reference the Template. Any DNP3 points that are associated with the DNP3 outstation remain unconverted in both the Template and its Instances. As such, any references from those points to the outstation are severed when the outstation is converted. (A Convert Object dialog box is displayed listing any configuration that becomes invalid as a result of the conversion process.)

In order to convert an item’s ‘children’ in a Group Template, use the Convert To feature to individually convert each item. You can then adjust each item’s ‘base’ configuration in the Template, set any Property Overrides as appropriate, and then configure any overridden properties locally, in each Instance that references the Template.

Consider using Abstract Items in a Group Template, if you need to convert items into different types in different Instances of that Template. (For more information, see Abstract Item.)

Further Information

Displaying a Database Item’s References.

Converting a Database Item.

Configure the Items in a Group Template.

Define which Property Values Derive from a Group Template.

Configure the Properties that are Unique to the Items in a Group Instance.


Core Configuration Guide - Example Configuration (Group Templates and Group Instances)

Example Configuration

This section includes a series of examples that demonstrate some of the features and functions associated with Templates and Instances. Use the examples as a guide when configuring the Templates and Instances on your system.

The examples in this section include:

  • Configure a Series of Group Templates and Group Instances
  • Use Property Overrides to Optionally Assign PSTN Fallback to a Direct Outstation
  • Define which Connection Settings to use in the Instances of a Channel
  • Convert an Abstract Item into a Specific Type of Point.

Further Information

Understand Templates and Instances.

Preparation.

Setting Up Group Templates and Group Instances.

Add a Group Template.

Add a Group Instance.

Add an Abstract Item to a Group Template.


Core Configuration Guide - Configure a Series of Group Templates and Group Instances (Group Templates and Group Instances)

Configure a Series of Group Templates and Group Instances

This example demonstrates how a modular system might be configured, using a series of Group Templates and Group Instances.

Example:

The regional organization of a particular system is very modular. The system comprises four regions, within each of which are a varying number of outstations and points. The type of data that is monitored or controlled in each outstation in a region is almost identical, with the exception that some outstations have an additional sensor to others.

A Group Template, ‘Regional Template’, is used to produce the ‘model’ basic configuration (channels and sets) for the four regions - Northern, Southern, Eastern, and Western.

A second Group Template, ‘Zone Template’, is used to produce the ‘model’ configuration for each of the areas of plant (outstation and points) that exist within the regions.

Both Group Templates are created in a TEMPLATES Group, off the root directory.

The ‘Regional’ Group Template contains the ‘model’ configuration for each region.
The ‘Zone’ Group Template contains the ‘model’ configuration for each area of plant within a region. In each Group Template, the names of the database items are left fairly general, as the names will be inherited by each Instance that references either of the Templates, and cannot be renamed in the Instances themselves.

The database items in each Template are suitably configured—most of the configuration in the Group Instances that are to reference these Templates is to be inherited directly from the Templates.

Sensor 5, in the Zone Template, is an Abstract Point. This is to allow for the fact that not all outstations have five sensors—the point will be ‘activated’ in those Instances that have five sensors, and left as an unused Abstract Item in the Instances that only have four sensors.

Each Template’s Property Overrides feature is used to specify which properties will be inherited from the items in the Template and which will need configuring on a per Instance basis. For example, all Instances of the Direct Channel use a Serial connection and are to inherit much of the configuration from the Channel in the ‘Regional’ Template (see Define which Connection Settings to use in the Instances of a Channel). Additionally, the Direct Outstation’s PSTN property is used to allow PSTN fallback to be enabled or disabled in each Instance of that outstation (see Use Property Overrides to Optionally Assign PSTN Fallback to a Direct Outstation).

The entries that represent the actual regions are added to the database. On this particular system, a ‘normal’ Group is added to represent each region. Into each Group is added:

  • A Group Instance that references the ‘Regional’ Template (representing the outstation and set configuration for the region)
  • Multiple Group Instances that references the ‘Zone’ Template (one Group Instance for each outstation, and associated points, that exists in the particular region).

The properties that are item-specific are configured within each Instance (for example, the telephone numbers of the PSTN channels, and the outstation and point addresses).

In those ‘Zone’ Group Instances that have five sensors, ‘Sensor 5’ is converted from an Abstract Item into the driver-specific Analog Input point that represents the fifth sensor (see Convert an Abstract Item into a Specific Type of Point). (In those Instances that only have four sensors, the Abstract Item is left unconverted and is ignored by ClearSCADA).

Each Instance of the ‘Regional’ Group Template contains a replica of the configuration in that Template.
Each Instance of the ‘Zone’ Group Template contains a replica of the configuration in that Template.
The ‘Northern Region’ Group contains one Instance of the ‘Regional’ Template and four Instances of the ‘Zone’ Template.
The ‘Southern Region’ Group contains one Instance of the ‘Regional’ Template and six Instances of the ‘Zone’ Template.


Core Configuration Guide - Use Property Overrides to Optionally Assign PSTN Fallback to a Direct Outstation (Group Templates and Group Instances)

Use Property Overrides to Optionally Assign PSTN Fallback to a Direct Outstation

This example shows how the Property Overrides feature can be used to allow PSTN Fallback to be enabled or disabled on an outstation, on a per Instance basis.

The example uses the ‘Zone’ Group Template mentioned in Configure a Series of Group Templates and Group Instances.

Example:

The direct outstation in a Group Template named ‘Zone Template’ is used as a ‘model’ for the Group Instances that reference that Template.

The Properties Overrides window is displayed for the Zone Template, and the outstation properties located.

By default, PSTN fallback is not enabled when a direct outstation is added to a ClearSCADA system. So, within the Property Overrides window, only the overall PSTN property is available for selection. (If PSTN was enabled for the outstation, individual PSTN properties would be available, in a branch off the main PSTN property.)

By default, a direct outstation in a Group Template has PSTN disabled...
...resulting in only the overall PSTN property being displayed in the Property Overrides window...
...and PSTN being unavailable for selection on the Outstation Form in any Instances of the Template.

The Property Overrides feature is to be used to allow PSTN Fallback to be optionally enabled or disabled, in each Instance that references the Template.

This can be done in one of two ways.

Either:

  • Enable PSTN fallback on the outstation in the Template, and then configure those PSTN properties that are to be inherited from the Template. Use the Property Overrides window to select the overall PSTN property and select any other PSTN properties that are to be specified locally, on a per Instance basis.

This will allow PSTN fallback to be enabled or disabled on a per Instance basis. For those Instances in which PSTN is enabled, many of the PSTN properties will be inherited from the Template. As such, minimal configuration is required on a per Instance level.

If a direct outstation in a Group Template has PSTN enabled...
...and the overall PSTN property is selected in the Property Overrides window, along with any other PSTN properties that are to be specified on a per Instance basis...
...engineers will be able to optionally enable PSTN on the Outstation Form in any Instances of the Template...
...with many of the PSTN properties inherited from the Template. (In this particular case, only the Telephone Number and Maximum Call Length need specifying on a per Instance basis—the other PSTN properties are inherited from the Template).

or:

  • Leave the PSTN feature disabled for the outstation in the Template. Select the overall PSTN property in the Properties Overrides window.

This will allow PSTN Fallback to be enabled or disabled on the Outstation Form in any Instances of the Template. However, for those Instances in which PSTN is enabled, any PSTN properties that are to differ from the default will need to be specified locally, on a per Instance basis.

If PSTN is disabled for a direct outstation in a Group Template...
...but the overall PSTN property for that outstation is selected in the Property Overrides window...
...engineers will be able to optionally enable PSTN on the Outstation Form in any Instances of the Template...
...but any PSTN properties that differ from the default will need specifying on a per Instance basis (as PSTN is not enabled for the outstation in the Template.).

(If all of the outstations are to use PSTN fallback and the option to disable PSTN is not required, enable and configure PSTN for the outstation in the Template, but ensure that the overall PSTN property is clear in the Property Overrides window. PSTN fallback will be enabled for the outstations in every Instance that references the Template, but there will be no ability to disable PSTN on a per Instance basis.)


Core Configuration Guide - Define which Connection Settings to use in the Instances of a Channel (Group Templates and Group Instances)

Define which Connection Settings to use in the Instances of a Channel

This example shows how to specify the type of connection that is to be used on the Instances of a direct channel. To specify the connection type, you need to select and configure the required connections settings on the Channel Form in the Group Template. You then use the Template’s Property Overrides feature to define which connection properties are to be inherited from the Template, and which are to be specified on a per Instance basis.

The example uses the ‘Regional’ Group Template mentioned in Configure a Series of Group Templates and Group Instances.

Example:

The direct channel in a Group Template named ‘Regional Template’ is used as a ‘model’ for the Group Instances that reference that Template.

Each Instance of the channel is to use a serial connection. Most of the property values for the connection are to be inherited from the direct channel in the Regional Template.

The Channel Form in the Template is used to specify a Serial connection type. The values of properties other than the Port number (which must be unique to each Instance of the channel) are suitably configured on the Form.

The Properties Overrides window is displayed for the Regional Template, and the channel properties located.

If a Serial Connection Type is specified for a direct channel in a Group Template...
...the Property Overrides window will display the serial-specific properties in a branch off the overall ConnectionPoint property (if another connection type, such as TCP/IP had been specified, the properties specific to that type of connection would be displayed).
The Instances of the direct channel will display the Serial connection fields...
...with various connection properties being inherited from the Template. (In this example, only the Port needs specifying in each Instance of the channel. As this particular property must be unique, its property box setting is fixed (as indicated by the check box being ‘grayed out’).)

(If the connection type needed to differ on some channels, you would select the overall ConnectionPoint property in the Property Overrides window. This would enable the Connection Type to be specified on a per Instance basis. To avoid configuring connection-specific properties in all Instances of the channel, you would use the Template’s Channel Form to specify and configure the connection-type that applied to the channels in most Instances.)

Further Information

Understanding the Property Overrides Window.

Define which Property Values Derive from a Group Template.

Configure the Properties that are Unique to the Items in a Group Instance.


Core Configuration Guide - Convert an Abstract Item into a Specific Type of Point (Group Templates and Group Instances)

Convert an Abstract Item into a Specific Type of Point

This example demonstrates how an Abstract Item might be used in a Group Template, to represent a point that only exists in some of the Group Instances that reference that Template.

The example uses the ‘Zone’ Group Template mentioned in Configure a Series of Group Templates and Group Instances.

Example:

A Group Template named ‘Zone Template’ is used as a ‘model’ for the Group Instances that reference that Template.

Analog Input points are used in the Group Template to represent sensors that exist in each of the Instances. Many of the Instances have four sensors, but some Instances contain five sensors.

To accommodate the fifth sensor, an Abstract Item is added to the Group Template:

Sensor 5 in the Zone Template is an Abstract Item.
It represents a sensor that only exists in some of the Instances that reference the Template.

In those Group Instances in which a fifth sensor is used, the Abstract item is converted into the required driver-specific Analog Input point type. The additional properties that are produced as a result of the conversion are then suitably configured in each of those Instances.

In the Group Instances that only have four sensors, the Abstract item is left unconverted. ClearSCADA ignores the unconverted item and those Group Instances are deemed to have only four sensors, rather than five.

The Instance ‘Zone 1’ has only four sensors, therefore Sensor 5 is left as an Abstract Item in that Instance.
The ‘Northern Region’ Group has four Instances of the ‘Zone’ Template—Zone 1 to Zone 4.
The Instances ‘Zone 2’ and ‘Zone 3’ both have five sensors. In these Instances, Sensor 5 is converted from an Abstract Item into the driver-specific Analog Input point that represents the fifth sensor.

An unconverted Abstract Item only contains basic configuration and is ignored by ClearSCADA.

Sensor 5 in the Instance ‘Zone 1’, within the ‘Northern Region’ Group, is an unconverted Abstract Item. As such, it only contains ‘base’ configuration and is effectively ignored by ClearSCADA.
Any entries in the message area on an Abstract Item’s Form can be ignored.

Once an Abstract Item is converted into a specific type of point or outstation, additional properties (and tabs) become available for use on the Form for that item, in the Instances in which it is converted:

Additional type-specific properties are available for configuration.
Sensor 5 in the Instance ‘Zone 2’, within the ‘Northern Region’ Group, has been converted from an Abstract Item into a specific type of Analog Input Point.
Its Form contains an additional tab, the properties of which need specifying in the Group Instance, if they are to differ from the default (their configuration is not inherited from the Group Template).
Any mandatory configuration that needs specifying in the Instance, is listed in the message area at the bottom of the Form.
Property values that are inherited from the Abstract Item in the Template are ‘grayed out’.


Core Configuration Guide - Actions Associated with Group Templates and Group Instances (Group Templates and Group Instances)

Actions Associated with Group Templates and Group Instances

In addition to the pick actions that are common to many database items (see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients), there are several pick actions that are specific to Group Templates and/or Group Instances. Use these pick actions when configuring and working with the Templates and Instances on your system. The pick actions (also known as context sensitive menu options) comprise:

  • Display Instances
  • Locate in Template
  • Locate Template
  • New Instance
  • Property Overrides
  • Repair Instance.


Core Configuration Guide - Display Instances (Group Templates and Group Instances)

Display Instances

Associated with: Group Templates

Security permission required to access this pick action: Read

Use the Display Instances pick action to display an Instances Queries List. The List shows the Group Instances that reference this particular Group Template.


Core Configuration Guide - Locate in Template (Group Templates and Group Instances)

Locate in Template

Associated with: Items in Group Instances

Security permission required to access this pick action: Read

Use the Locate in Template pick action to locate the database item from which this instance of the item inherits some or all of its configuration. ClearSCADA highlights the Group Template’s version of the item in the hierarchical ‘tree’ structure in the Database Bar.

Also see Locate Template.


Core Configuration Guide - Locate Template (Group Templates and Group Instances)

Locate Template

Associated with: Group Instances

Security permission required to access this pick action: Read

Use the Locate Template pick action to locate the Group Template with which a Group Instance is associated. ClearSCADA highlights the Group Template in the hierarchical ‘tree’ structure in the Database Bar.

Also see Locate in Template.


Core Configuration Guide - New Instance (Group Templates and Group Instances)

New Instance

Associated with: Groups, Group Instances, and Group Templates

Security permission required to access this pick action: Configure

Use the New Instance pick action to Add a Group Instance to your database.


Core Configuration Guide - Property Overrides (Group Templates and Group Instances)

Property Overrides

Associated with: Group Templates

Security permission required to access this pick action: Configure

Use the Property Overrides pick action to Define which Property Values Derive from a Group Template.


Core Configuration Guide - Repair Instance (Group Templates and Group Instances)

Repair Instance

Associated with: Group Instances

Security permission required to access this pick action: Configure

Select this pick action to:

  • Reset any non-overridden fields and aggregates back to their Group Template values. (An aggregate is an extension to the basic set of configuration features—for example, the ‘Historic’ aggregate supported by many types of point.)
  • Create Instances of any database items that currently exist in the Group Template, but not in the Group Instance.

A confirmation window is displayed when the Repair Instance pick action is selected, allowing you to confirm or abort the request.

When an Instance is repaired, any items that have been added directly to the Group Instance are retained, and any Abstract Items that have been converted to ‘real’ items retain their conversion.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Repair.


Core Configuration Guide - Restrict Alarm and Event Access to Specific Areas of Interest

Restrict Alarm and Event Access to Specific Areas of Interest

You can use ClearSCADA’s Area of Interest feature to limit the alarms and events that are displayed on a node (workstation). You use the feature to limit a user’s alarm and event access, so that they are only made aware of those alarms and events that are associated with the geographical or logical areas in which they are interested. As such, users are unaware of any alarms and events that are associated with items that occur outside of their ‘areas of interest’.

The Area of Interest feature is useful on systems on which users only need to be notified of alarms and events that occur on particular area(s) of the system. It does not restrict access to items in other areas of the system—it just limits the user’s alarm and event notification to those for specific area(s) of the system.

Areas of Interest are hierarchical—by defining different ‘levels’ of area on a system, you can restrict alarm and event notification by different amounts for different users.

Example:

A particular ClearSCADA system is configured to have this Areas of Interest hierarchy:

System administrators are assigned the World Area of Interest. This gives them access to all alarms and events on the system. (Always make sure at least one user, with permissions to configure other user accounts, has access to the World Area of Interest.)
Regional engineers are assigned the appropriate regional Area of Interest, such as Southern Region. This gives them access to the alarms and events in that region, and in any sub-divisions within that region.
System operators are assigned the appropriate sub-division Area of Interest, such as S3. This gives them access to the alarms and events in that particular sub-division only. They are unaware of any alarms and events that occur in any other sub-divisions or regions.

This section explains how to:

  • Enable the Area of Interest Feature in ClearSCADA
  • Display the Areas of Interest Bar
  • Add Further Areas of Interest to Your System
  • Assign a Different Area of Interest to an Item’s Alarms and Events
  • Restrict Alarm Redirection to Alarms that are Assigned a Specific Area of Interest
  • Assign a Different Area of Interest to a User
  • Rename an Area of Interest
  • Reorganize the Areas of Interest on your System
  • Delete an Area of Interest.


Core Configuration Guide - Enable the Area of Interest Feature in ClearSCADA (Restrict Alarm and Event Access to Specific Areas of Interest)

Enable the Area of Interest Feature in ClearSCADA

The Area of Interest feature is not enabled by default—if you want to use this feature on your system:

  1. Enable the Area of Interest feature on each server on your system (see Enable or Disable the Area of Interest Feature in the ClearSCADA Guide to Server Administration). (Once enabled, you will need to restart each server, in order to implement the feature.)
  2. For those engineer-level users that are to configure areas of interest on the system, ensure that their user accounts provide access to the Areas of Interest Bar (see Define Which Explorer Bars are Available to a User in the ClearSCADA Guide to Security).

The Areas of Interest Bar is an Explorer Bar (see Display the Areas of Interest Bar).

  3. A single World Area of Interest is automatically added when the Area of Interest feature is enabled. You can rename this Area of Interest if required (see Rename an Area of Interest).
  4. Add Further Areas of Interest to Your System, in order to restrict alarm and event access to specific areas of your system.
  5. By default, the ‘World’ Area of Interest is designated as your system’s Default Area of Interest. The Default Area of Interest is the Area of Interest that is assigned to any new items that are added to your database. If required, you can change the Default Area of Interest from the ‘World’ Area of Interest to another Area of Interest on your system (see Specify the Default Area of Interest for your System).

Any items that are added to the database are automatically assigned the current Default Area of Interest as their Area of Interest.

  6. By default, every alarm and event that can be generated on the system is assigned to the ‘World’ or Default Area of Interest.

Additional Area of Interest field(s) are included on the configuration Forms of those items with which an alarm or event can be associated. You can use these fields to Assign a Different Area of Interest to an Item’s Alarms and Events.

  7. By default, every alarm redirection on the system is assigned the ‘World’ or Default Area of Interest.

You can change an alarm redirection’s Area of Interest so that alarms are only redirected if they are assigned a more specific Area of Interest (see Restrict Alarm Redirection to Alarms that are Assigned a Specific Area of Interest).

  8. By default, each user account is allocated the ‘World’ or Default Area of Interest.

For those users that only require access to alarms and events that are associated with particular area(s) of the system, you can Assign a Different Area of Interest to a User.

(You can assign up to four Areas of Interest to each user.)

NOTE: If you are implementing the Area of Interest feature on an existing ClearSCADA system, consider using the Automation Interface to automate the setting up of each user’s and database item’s Area of Interest properties. The Automation Interface is a built-in interface that allows access to the properties and methods of every item in the database. (Refer to the Database Schema for the property naming conventions used with the Automation Interface.)

On systems on which the Area of Interest feature is enabled:

  • An additional Area of Interest column is added to:
  • The Alarm Banner
  • The Alarms List
  • The Events List.
  • Users are able to filter the Events List—and other lists of items with which alarms and events can be associated—by Area of Interest.

Users can only filter list entries by the Area(s) of Interest that are allocated to their user account, or by Area(s) of Interest that are contained within those allocated areas.

For more information on filtering Lists, see the ClearSCADA Guide to Lists.

  • An additional Areas of Interest section becomes available for use on the Alarms List’s Filter window, to enable filtering of the Alarms List by Area of Interest.

Users can only filter alarms by the Area(s) of Interest that are allocated to their user account, or by Area(s) of Interest that are contained within those allocated areas.

You can filter the Alarms List by the Area(s) of Interest to which you have access.

For more information on filtering the Alarms List, see the ClearSCADA Guide to Alarms.


Core Configuration Guide - Display the Areas of Interest Bar (Restrict Alarm and Event Access to Specific Areas of Interest)

Display the Areas of Interest Bar

The Areas of Interest Bar is an Explorer Bar.

You use the Areas of Interest Bar to:

  • Add Further Areas of Interest to Your System
  • Rename an Area of Interest
  • Reorganize the Areas of Interest on your System
  • Delete an Area of Interest.

You can only display the Areas of Interest Bar if:

  • The Area of Interest feature is enabled on your system (see Enable the Area of Interest Feature in ClearSCADA).
  • Your user account provides access to the Areas of Interest Bar (see Define Which Explorer Bars are Available to a User in the ClearSCADA Guide to Security).

To display the Areas of Interest Bar:

  1. Select the View menu.
    A context sensitive menu is displayed.
  2. Select the Explorer Bar option.
    A further context sensitive menu is displayed.
  3. Select the Areas of Interest option.
    The Areas of Interest Bar is displayed.

For other ways of displaying an Explorer Bar, see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients.


Core Configuration Guide - Add Further Areas of Interest to Your System (Restrict Alarm and Event Access to Specific Areas of Interest)

Add Further Areas of Interest to Your System

By default, when the Area of Interest feature is enabled on a ClearSCADA system, every alarm or event that can be generated on the system is assigned to the World Area of Interest.

To limit alarm and event access for particular areas of the system, you can add further Area of Interest level(s) to your system, and assign particular alarms and events to those Areas of Interest. You can only add further Areas of Interest if your user account provides access to the Areas of Interest Bar and you have been allocated the Configure Database permission.

To add an Area of Interest to your system:

  1. Display the Areas of Interest Bar
  2. Right-click on the entry to which you want to add a new Area of Interest. (For example, the World Area of Interest.)
    A context sensitive menu is displayed.
  3. Select the New Area of Interest option.
    A new Area of Interest is added to the Bar. The entry is highlighted, ready for you to define its name.
  4. Give the Area of Interest a suitable name, taking into account the ClearSCADA Naming Restrictions.
  5. Repeat steps 2 to 4 for any other Areas of Interest that you want to add to your system.

Be aware that Areas of Interest are hierarchical—you can configure multiple Area of Interest levels on your system. Users that are assigned a particular Area of Interest are automatically given access to any Areas of Interest that exist within that area.

Further Information

Specify the Default Area of Interest for your System.

Assign a Different Area of Interest to an Item’s Alarms and Events.

Restrict Alarm Redirection to Alarms that are Assigned a Specific Area of Interest

Assign a Different Area of Interest to a User.

Rename an Area of Interest.

Reorganize the Areas of Interest on your System.

Delete an Area of Interest.


Core Configuration Guide - Assign a Different Area of Interest to an Item's Alarms and Events (Restrict Alarm and Event Access to Specific Areas of Interest)

Assign a Different Area of Interest to an Item’s Alarms and Events

By default, when the Area of Interest feature is enabled on a ClearSCADA system, every alarm or event that can be generated on that system is assigned to the World Area of Interest.

To limit access to alarms and events for a particular database item, you can assign its alarms and events to a different Area of Interest.

ATTENTION: Ensure that the relevant users have access to the Areas of Interest that are assigned to a database item (see Assign a Different Area of Interest to a User).

To assign a different Area of Interest:

  1. Display the Form for the item (see Display a Form).
  2. Perform one of the following, as appropriate:
  • If assigning Areas of Interest to an item other than a Point, go to step 3.
  • If assigning Areas of Interest to a Point, go to step 4.
  3. On the <Item Type> tab (for instance, the Channel tab on a Channel Form), use the Area of Interest field to specify the Area of Interest that is to be associated with any alarms or events that are generated for that item.

Now go to step 6.

  4. On the <Point Type> tab on a Point Form:
  1. Use the Area of Interest field(s) within the Alarm Limits or States section of the tab to specify the Area of Interest for any alarms or events associated with the point’s value or state changes.
  2. On analog-type points, use the Area of Interest field within the No Change section of the tab to specify the Area of Interest for any alarms or events associated with the point’s value not changing over a defined time period.
  5. On the Control tab of an output point, use the Area of Interest field within the Actions section of the tab to specify the Area of Interest for any alarms or events associated with the point’s control actions.
  6. Save the configuration (see Saving Configuration Changes).
  7. Repeat the above steps for any other database items for which you want alarms and events allocated to a different Area of Interest to the one that is currently assigned. (Remember that you can only assign an Area of Interest to which you have access.)

Further Information

Specify the Default Area of Interest for your System.

Add Further Areas of Interest to Your System.

Restrict Alarm Redirection to Alarms that are Assigned a Specific Area of Interest.


Core Configuration Guide - Restrict Alarm Redirection to Alarms that are Assigned a Specific Area of Interest (Restrict Alarm and Event Access to Specific Areas of Interest)

Restrict Alarm Redirection to Alarms that are Assigned a Specific Area of Interest

You can use ClearSCADA’s Alarm Redirection feature to redirect any alarm on the system (see the ClearSCADA Guide to Alarm Redirection). If required, you can restrict any redirection action so that only those alarms that are assigned a particular Area of Interest are redirected.

By default, when the Area of Interest feature is enabled on a ClearSCADA system, every alarm redirection on that system is assigned the World or Default Area of Interest. To assign a different Area of Interest to an alarm redirection:

  1. Display the Form for the item (see Display a Form).
  2. On the Redirection tab, use the Area of Interest field to specify the area of interest that is to be associated with each Alarm Redirection. (Remember that you can only assign an Area of Interest to which you have access.)

The Area of Interest that you specify limits the redirection to only those alarms that are assigned that particular Area of Interest, or an area that resides within the specified Area of Interest. This Area of Interest can differ to that specified elsewhere on an item’s Form (see Assign a Different Area of Interest to an Item’s Alarms and Events).

  3. Repeat step 2 for any other alarm redirections for which you want to assign a particular Area of Interest.
  4. Save the configuration (see Saving Configuration Changes).

(Remember to assign appropriate Areas of Interest to any Alarm Redirections that exist on your system’s Root Group.)

Further Information

Specify the Default Area of Interest for your System.

Configuring Alarm Redirections: see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection.

Add Further Areas of Interest to Your System.


Core Configuration Guide - Assign a Different Area of Interest to a User (Restrict Alarm and Event Access to Specific Areas of Interest)

Assign a Different Area of Interest to a User

When the Area of Interest feature is enabled on a ClearSCADA system, each user is allocated access to the World Area of Interest, by default.

To restrict a user’s alarm and event access to just those area(s) of interest on the system, you need to allocate different Area(s) of Interest to that user’s account, in place of the World Area of Interest.

You can allocate up to four Areas of Interest to each user on a ClearSCADA system.

Be aware that if your system uses a hierarchical Area of Interest structure, in addition to the nominated Area(s) of Interest, users will also have access to alarms and events that are allocated to any further Areas of Interest that reside within those nominated areas.

ATTENTION: Always make sure that at least one high-level user on your system has access to the World Area of Interest and has permissions to configure other user accounts. Users can only allocate Areas of Interest to which they have access to themselves.

To assign an Area of Interest to a user:

  1. Display the user’s User Form (see Display the User Form in the ClearSCADA Guide to Security).
  2. Scroll to the Area of Interest section on the General tab.
  3. Select the browse button next to the Area 1 field.
    A Reference browse window is displayed.
  4. Select the required Area of Interest from the window.
  5. Repeat the above for any other Area n fields to which you want to allocate another Area of Interest.
  6. Save the configuration (see Saving Configuration Changes).

To restrict alarm and event access for the Guest User account—the default account that applies whenever a user accesses a ClearSCADA system without logging on—you specify the Area of Interest properties on the Guest User tab of your system’s Root Group Form (see Define the Global Settings for All Guest and Web User Accounts in the ClearSCADA Guide to Security).

A diagnostic message is displayed if an Area of Interest is specified for a user, and that Area of Interest is already contained within another Area of Interest allocated to the same user.


Core Configuration Guide - Rename an Area of Interest (Restrict Alarm and Event Access to Specific Areas of Interest)

Rename an Area of Interest

You can rename an Area of Interest using any of the methods that are available for renaming an item in the database—the only difference is that you rename the entry in the Area of Interest Bar, rather than in the Database Bar (see Renaming a Database Item).

When you rename an Area of Interest, ClearSCADA updates the references to that name automatically. (You may need to re-display any Forms and refresh any Lists that are open at the time, in order to update the entry.)

ATTENTION: If you rename the World Area of Interest, ensure that the new name indicates that this is the root Area of Interest to which alarms and events default, if they are not assigned a different Area of Interest.


Core Configuration Guide - Reorganize the Areas of Interest on your System (Restrict Alarm and Event Access to Specific Areas of Interest)

Reorganize the Areas of Interest on your System

You can reorganize the Areas of Interest on your system, however this procedure should be used with care. If you move an Area of Interest from one location to another:

  • The Area of Interest reference updates automatically to reflect the new location on:
  • Any alarms and events that are allocated to that Area of Interest.
  • Any user accounts that are allocated that Area of Interest.
  • Be aware that in a hierarchical Areas of Interest Structure, if an Area of Interest is moved from within one Area of Interest to another, some users may no longer have access to the alarms and events in the Area of Interest that has been moved.

Example:

On a particular ClearSCADA system, the Area of Interest S4 is moved out of the Southern Region Area of Interest, and into the Western Region Area of Interest:

Regional engineers that are assigned only the Southern Region Area of Interest no longer have access to alarms and events that are allocated to the S4 Area of Interest, as it now resides within a different Area of Interest.
System operators that are assigned the S4 Area of Interest are not affected by its relocation into the Western Region Area of Interest. They retain access to alarms and events in the S4 Area of Interest sub-division only.
Any regional engineers that are allocated both the Southern Region and Western Region Areas of Interest are not affected by the relocation, as they retain access to the alarms and events in the S4 Area of Interest sub-division.

To move an Area of Interest from one location to another:

  1. Select the entry in the Areas of Interest Bar. Do not release the left-hand mouse button.
  2. Drag the cursor so that it is positioned over the Area of Interest within which you want to move the selected entry.
    The target Area of Interest is highlighted.
  3. Release the left-hand mouse button.
    The entry is moved into the target Area of Interest.


Core Configuration Guide - Delete an Area of Interest (Restrict Alarm and Event Access to Specific Areas of Interest)

Delete an Area of Interest

You can use the Delete option to remove an Area of Interest that is no longer required on your system. Use the option with care if the Area of Interest is referenced by any users, events or alarms in the database.

If a referenced Area of Interest is removed from ClearSCADA:

  • The deleted Area of Interest will be removed from any user accounts that reference the area. If the deleted Area of Interest was the only Area of Interest allocated to a user, you will need to allocate another Area of Interest to that user.
  • Any alarms or events that were allocated the deleted Area of Interest will revert to using the ‘World’ Area of Interest. You may want to replace the ‘World’ reference with a different Area of Interest for each of the affected items (a list showing any referenced items is displayed when you select an Area of Interest for deletion).

You can delete an Area of Interest using any of the methods that are available for deleting an item in the database—the only difference is that you delete the entry from the Areas of Interest Bar, rather than the Database Bar (see Deleting a Database Item).

Example:

The Area of Interest S4 is to be deleted from a ClearSCADA system. It resides within another Area of Interest, Western Region.

A Confirm Deletion window is displayed when the Area of Interest S4 is selected for deletion. The window indicates that the Area of Interest is referenced by the User R. Johnson and an outstation.

If deletion is confirmed by selecting the Yes button, the outstation will revert to using the World Area of Interest, and the user’s S4 Area of Interest will be deleted. If this was the only Area of Interest allocated to that user, a diagnostic message will be displayed:

By double-clicking on the entry in the window, the User Form is displayed, allowing another Area of Interest to be specified for that user.


Core Configuration Guide - Using the Add Action and Edit Method Windows

Using the Add Action and Edit Method Windows

You use the Edit Method window, the Add Action window, or the Edit Action window to select a method (action) that ClearSCADA is to trigger automatically, and to specify the values of any arguments used by that method.

Although the name of each window varies, depending whether you access it via a Form or a Schedule, much of the functionality of each window is the same.

You typically:

  • Display the Edit Method Window from a Form
  • Display the Add Action Window or the Edit Action Window from a Schedule.


Core Configuration Guide - Display the Edit Method Window from a Form (Using the Add Action and Edit Method Windows)

Display the Edit Method Window from a Form

You typically display the Edit Method window by selecting the browse button for a Method field on a configuration Form:

Select the browse button for a Method field...
...to display the Edit Method window

Use the Edit Method window to Specify a Method (action) that ClearSCADA is to trigger automatically on the specified method object (database item).


Core Configuration Guide - Display the Add Action Window or the Edit Action Window from a Schedule (Using the Add Action and Edit Method Windows)

Display the Add Action Window or the Edit Action Window from a Schedule

You typically display the Add Action window when you Add an Action to a Schedule.

You typically display the Edit Action window when you Edit a Scheduled Action.

When you edit an action on a Schedule...
...the Edit Action window is displayed.

You can use either window to Specify a Method (action) that ClearSCADA is to trigger automatically on a scheduled basis.

You can additionally use the Edit Action window to change the database item on which ClearSCADA is to perform the action.


Core Configuration Guide - Specify a Method (Using the Add Action and Edit Method Windows)

Specify a Method

You can use the Edit Method window, the Add Action window, or the Edit Action window to specify a method (action) that ClearSCADA is to perform automatically. (You Display the Edit Method Window from a Form, and Display the Add Action Window or the Edit Action Window from a Schedule.)

To specify a method using any of the above windows:

  1. If the Object field is populated, ensure that the correct database item is specified, then proceed to step 2.

If the Object field on the window is blank:

  1. Select the Object field’s browse button.
    A Reference browse window is displayed.
  2. Use the Reference browse window to select the database item for which ClearSCADA is to trigger a method.
  2. Use the Aggregate combo box to specify the particular aggregate with which the method is associated. An aggregate is an ‘extension’ to a database item’s class—such as the Historic aggregate on points, or the PSTN aggregate on outstations that support such communications.

Optional aggregates are only available from the Aggregate combo box if they are enabled. (For instance, the UserMethods aggregate is only listed if the database item has that tab enabled (as would be the case if the item had one or more ‘custom’ methods (pick actions) assigned to it (see Using the User Methods Tab to Define Custom Actions).)

Not all database items have aggregates—the combo box is ‘grayed out’ and not available for use if no aggregates are enabled, or the item does not have any aggregates.

Specify (None) if the method applies to the item’s main class, rather than an extension of that class.

On this analog point, two aggregates are available. The Control aggregate is listed as the point is configured as an output point. The Historic aggregate is listed as historic is enabled on the point’s Historic tab. (If Historic was not enabled, that aggregate would not be included in this list.)

(For more information on database classes and aggregates, see Understanding the Database in the ClearSCADA Guide to the Database.)

  3. If the method is associated with alarms, use the Alarm combo box to specify the particular type of alarm with which the method is associated. Specify (None) if the method is not associated with an alarm, or applies to any of the alarms that are listed.

The Alarm combo box is ‘grayed out’ and unavailable for use if the item—or the particular Aggregate that is specified for that item—does not have the capability to generate any alarms.

On this direct channel, you can associate a method with two types of alarm. ClearSCADA generates the Channel alarm if it deems the channel to have failed. ClearSCADA generates the ChannelScanStatus alarm if the last scan of devices on the channel did not complete within the parameters specified for that scan. (The ChannelScanStatus alarm applies to direct channels on drivers that support scan duration parameters.) If the method is to be associated with only one of these alarms, select that particular alarm from the list. If the method applies to any of the alarms, select (None).

  4. Use the Method combo box to specify the method (action) that ClearSCADA is to trigger on the item shown in the Object field.

The list of available methods varies, depending on the database item and the Aggregate and Alarm options that you have specified.

You can move the cursor over a method to display the ToolTip for that method.

Position the cursor over a method in the list...
...to display a ToolTip summarizing that method’s functionality.

  5. If the selected method uses arguments to further define the action that is to be taken, these will be displayed in the Arguments list.

(If the selected method does not have any arguments, the Arguments list will be empty—please proceed to step 11.)

You need to specify the values of any arguments.

To assist, you can move the cursor over an argument in the list to display a ToolTip giving information on the value(s) that the argument supports.

Any arguments associated with a method are displayed in the Arguments list.
Position the cursor over an argument in the list...
...to display a ToolTip giving information on the values that the argument supports...

  6. If you are specifying the value of an argument that has a distinct set of values, you can right-click on the argument to display a context-sensitive menu and select the required value from the options that are displayed.
    The Action argument for a digital output’s Control method has a distinct set of values.
    Right-click on the Action argument to display a context-sensitive list, and choose the required value from the lower part of the list.

If you select a value using the context-sensitive menu, proceed to step 10.

If, instead of selecting a pre-defined value, you want to configure an expression using the Expression window, go to step 7.

  7. For arguments that do not have a distinct set of values or for which you want to configure an expression, either:
  1. Right-click on the argument in the Arguments list.
    A context-sensitive menu is displayed.
  2. Select the Edit option.

Or:

  1. Double-click on the argument in the Arguments list.

The Expression window is displayed.

  8. Use the Expression window to enter a suitable value for the argument.

Depending on the type of argument, the required value will typically be a numeric value, or a string. (A diagnostic message is displayed if an invalid expression is specified in the Expression window.)

If required, display the Database Schema, in order to obtain similar information to the ToolTips on the arguments that the method supports, and the range of values for those arguments (see Working with the Database Schema in the ClearSCADA Guide to the Database).

For information on using the Expression window, see Working with the Expression Window in the ClearSCADA Guide to Expressions. For information on the types of expression that you can specify, see Method Expressions in the ClearSCADA Guide to Expressions. If you are specifying the expression for a User Method, also see User Method Expressions in the ClearSCADA Guide to Expressions.

  9. Once you have entered the required argument value in the Expression window, select the window’s OK button.
    The Expression window is closed and the argument’s value is displayed in the Add Action, Edit Action or Edit Method window’s Arguments list.
  10. Repeat steps 5 to 9 for the other arguments in the Arguments list.
  11. Select the OK button on the Add Action, Edit Action, or Edit Method window.
    The window is closed and the method details are displayed on the Form or Schedule. Any arguments are shown in a comma-separated list, within parentheses, after the Method name.

For examples that demonstrate how to configure methods using the Add Action window, the Edit Method window, the Expression window and the Database Schema, see Example Configuration.

Further Information

Clear the Value of an Argument.

ClearSCADA can trigger methods under various circumstances. For further information on triggering methods, see:

Configure a Method Action to Trigger at Every Alarm State Change.

Define the Method Action Details in the ClearSCADA Guide to Alarm Redirection.

Stand-Alone Method Calls.

Using the User Methods Tab to Define Custom Actions.

To trigger actions automatically on a regular basis, see Using Schedules to Automate Regular Functions.


Core Configuration Guide - Clear the Value of an Argument (Using the Add Action and Edit Method Windows)

Clear the Value of an Argument

To clear the value that is specified for an argument in the Edit Method window, the Add Action window, or the Edit Action window:

  1. Either:
  1. Right-click on the argument in the Arguments list.
    A context-sensitive menu is displayed.
  2. Select the Clear option.
    The Value is cleared.
    Select the Clear option to clear a value from the Arguments list.

Or:

  1. Double-click on the argument in the Arguments list.
    The Expression window is displayed.
  2. Delete the expression from the Expression window.
  3. Select the OK button on the Expression window to confirm the deletion.
    The Expression window is closed and the argument’s value is cleared.


Core Configuration Guide - Example Configuration (Using the Add Action and Edit Method Windows)

Example Configuration

The examples in this section demonstrate how particular methods might be specified, using the Add Action or Edit Method windows, the Expression window, and the Database Schema.

The examples demonstrate how to:

  • Use the Edit Method Window to Specify the Switch Line Method
  • Use the Add Action Window to Specify the Tune Alarm Limits Method
  • Use the Add Action Window to Specify the One Shot Method.

Further Information

For examples that demonstrate how Methods might be configured on an item’s User Method tab, see Example Configuration.


Core Configuration Guide - Use the Edit Method Window to Specify the Switch Line Method (Using the Add Action and Edit Method Windows)

Use the Edit Method Window to Specify the Switch Line Method

This example demonstrates how to use the Edit Method window to specify the SwitchLine method on a configuration Form. The method has one argument, which has a distinct set of values.

Example:

The outstations on a particular ClearSCADA system use a dual channel setup.

Under certain circumstances, the ClearSCADA server is to automatically switch the outstations from one channel to another.

On the relevant configuration Form, the Edit Method window is used to specify the SwitchLine method, which will trigger the outstations to swap channels.

The SwitchLine method has one argument, named Type.

By right-clicking on the Type argument to display a context-sensitive list, it can be seen that the argument can have one of three possible values:

...which the context-sensitive list shows can have one of three possible values: Toggle Line, Primary, or Secondary.
The Edit Method window shows that the SwitchLine method...
...has one argument...

As the outstations are required to swap communications to the other channel, the Toggle Line value is selected.

This results in the following configuration in the Edit Method window:

and this configuration in the Method field on the configuration Form:

Further Information

Display the Edit Method Window from a Form.

Use the Edit Method Window to Specify a Method.


Core Configuration Guide - Use the Add Action Window to Specify the Tune Alarm Limits Method (Using the Add Action and Edit Method Windows)

Use the Add Action Window to Specify the Tune Alarm Limits Method

This example demonstrates how to use the Add Action window to specify the Tune Alarm Limits method (action) on a Schedule. The method has multiple arguments.

Example:

At specific times (triggered by a Schedule), ClearSCADA is to tune the limits of an analog point so that those limits have different values to those specified on the configuration Form for that analog point.

The Add Action window is used to add the required Tune Alarm Limits method (action) to the Schedule. The method has multiple arguments:

The ToolTip for each argument lists the type of value that needs specifying for that argument.

The Database Schema also includes the ToolTip information for each argument:

The Database Schema lists the arguments for the TuneLimits method and indicates the type of value that needs specifying for each of those arguments.

Both the ToolTips and Database Schema shows that for each limit:

  • The Boolean argument is used to specify whether the limit is to be tuned (1) or whether any existing tuning is to be removed (0).
  • The Float argument is used to specify the tuned value for the limit, as a floating-point number.

Each argument in the Arguments list is selected in turn and the Expression window used to specify the required Boolean or floating-point value.

For this particular analog point, this results in the following configuration in the Add Action window:

and this configuration on the Schedule:

Further Information

Tune Limits: see Define whether an Analog Point’s Limits can be Tuned in the ClearSCADA Guide to Core Point Configuration.

Using Schedules to Automate Regular Functions.

Add an Action to a Schedule.

Using the Add Action window to Specify a Method.

Using the Database Schema: see Working with the Database Schema in the ClearSCADA Guide to the Database.


Core Configuration Guide - Use the Add Action Window to Specify the One Shot Method (Using the Add Action and Edit Method Windows)

Use the Add Action Window to Specify the One Shot Method

This example demonstrates how to use the Add Action window to specify the One Shot method (action) on a Schedule. The method is associated with the PSTN aggregate.

Example:

At specific times (triggered by a Schedule), ClearSCADA is to send a One Shot request to a PSTN outstation, in order to retrieve the data from that outstation.

As the One Shot method is associated with an outstation’s PSTN aggregate, the PSTN Aggregate is specified in the Add Action window. This restricts the entries in the Method combo list to those methods (actions) that are associated with the PSTN aggregate.

The One Shot method is then selected from the Method combo box. The method does not have any arguments.

This results in the following configuration on the Schedule:

Further Information

Using Schedules to Automate Regular Functions.

Add an Action to a Schedule.

Using the Add Action window to Specify a Method.


Core Configuration Guide - Specifying the Required Entry in a Date and Time Field

Specifying the Required Entry in a Date and Time Field

While operating or configuring ClearSCADA, you may be required to specify a date and time in a field. Where applicable, ClearSCADA’s date and time fields support a Calendar window that you can use to specify the date element of such fields. This section explains how to specify the date and time elements of such fields.

Select the arrow on a date and time combo box...
... to display a Calendar window that you can use to specify the required date.

This section includes information on how to:

  • Manually Specify a Date
  • Specify a Date using the Calendar Window
  • Specify a Time.

NOTE: The format in which a date and time is displayed in a field varies, depending on the Date Format that is specified for the logged on user. For information on specifying a user’s Date Format, see Define the Regional Settings for a User in the ClearSCADA Guide to Security, and see Configuring the Guest and Web User Accounts in the ClearSCADA Guide to Security.


Core Configuration Guide - Manually Specify a Date (Specifying the Required Entry in a Date and Time Field)

Manually Specify a Date

You can manually specify a date by overtyping each element of the date, or you can Specify a Date using the Calendar Window.

To specify a date by overtyping the existing entry, select each element of the date (day, month, and year) in turn and overtype it with the required value.

To overtype the month, you need to specify the number of the month, rather than its name.

When overtyping the month, you need to specify the number of the month. So, for April, you would specify 4, for the fourth month of the year.

Further Information

Specify a Time.


Core Configuration Guide - Specify a Date using the Calendar Window (Specifying the Required Entry in a Date and Time Field)

Specify a Date using the Calendar Window

To specify the date element of a date and time field, you can either Manually Specify a Date, or display the Calendar window and use that window to specify the required date.

To specify the date using the Calendar window, select the date and time field’s arrow button to display the Calendar window.

Select the arrow on a date and time combo box...
... to display a Calendar window that you can use to specify the required date.

To specify a different year:

  1. Select the year at the top of the Calendar window.
    The year is highlighted and a spin box displayed.
  2. Either:
  • Use the spin box to change the year. (Use the Up arrow to increase, or the Down arrow to decrease, the year).

Or:

  • Overtype the year with the required value.

To specify a different month:

  1. Either:
  • Use the arrows at the top left or right of the Calendar window to change the month.
    Use the left-hand arrow to decrease the month...
    ... or the right-hand arrow to increase the month.

Or:

  • Select the presently displayed month to display a list of months, and then select the required entry from the list.
    Select the month...
    ...to display a pop-up list from which you can select the required entry.

To specify a different date:

  1. Either:
  • Select the required date on the Calendar.

Or:

  • If you want to specify today’s date, select the Today entry at the bottom of the Calendar.

The specified date is highlighted. (Today’s date is outlined (or both outlined and selected if it is the specified date).)

Further Information

Specify a Time.


Core Configuration Guide - Specify a Time (Specifying the Required Entry in a Date and Time Field)

Specify a Time

To specify the time element of a date and time field, you overtype the existing time with the time that you require.

To do this, select each time element in turn (hours, minutes, seconds, and then milliseconds) and overtype the time with the required value.

Select the hours element of a time and overtype it with the required value. Repeat the process for the minutes, seconds, and milliseconds elements of the time.

Further Information

Manually Specify a Date.

Specify a Date using the Calendar Window.


Core Configuration Guide - Using OPC Time Formats

Using OPC Time Formats

Use OPC time formats for entering dates and times in ClearSCADA. The formats are based on the standards that are defined by the OPC Foundation. The formats that you need to use vary, depending on the type of time or date. Within ClearSCADA you can enter and display these types of dates and times:

  • Intervals—For example, 15 minutes. To specify an interval, you enter the time in the OPC Time Format.
  • Relative Times—For example, yesterday at 06:00. To specify a relative time, you enter the time in the OPC Relative Time Format.
  • Absolute Times—For example, 15 June 2006 08:00:00. For absolute times, ClearSCADA uses the syntax that is defined by the user’s Date Format. For information on specifying a user’s Date Format, see Define the Regional Settings for a User in the ClearSCADA Guide to Security, and see Configuring the Guest and Web User Accounts in the ClearSCADA Guide to Security.

Point values that indicate times or dates on displays such as Mimics use the above Date Formats, unless you specify another format using the Text Format window. For further information, see as applicable:

  • Defining the Format of Displayed Values
  • Define How a Date and Time are Displayed
  • Define How a Time Period is Displayed.

Be aware that the Date Format on a recipient’s User Form defines the date and time format that ClearSCADA uses in any Alarm Redirection e-mail, pager, or SMS messages (see the ClearSCADA Guide to Alarm Redirection for further information).

The relevant sections in the ClearSCADA documentation indicate which format you should be using to specify a time or date.

Further Information

OPC Foundation Standards: See www.opcfoundation.org

Time Zone Support in ClearSCADA.


Core Configuration Guide - OPC Time Format (Using OPC Time Formats)

OPC Time Format

Enter periods of time in the OPC Time Format.

The OPC Time Format consists of a time value and a time unit. For instance, 10S is the OPC time format for ten seconds.

You use the OPC time format, for instance, to specify the maximum call length for a PSTN outstation.

If you are required to specify a time period, either:

  • Use the browse button next to the field to display an Interval window. You can then use the window to specify the required time period (see Interval Window).

or:

  • Enter the time period directly in the field (see Specify a Time Period in the OPC Time Format).


Core Configuration Guide - Interval Window (Using OPC Time Formats)

Interval Window

Use the Interval window to Specify a Time Period in the OPC Time Format. The window is displayed when you select the browse button next to a field in which you are required to specify a time period.

Select the browse button next to a field in which you are required to specify a time period...
...to display the Interval window. Use the fields in the window to specify the required time...
...and then select the OK button to confirm your selection and display the entry in the Form’s field.

To specify a time period using the Interval window:

  1. Select the browse button next to the field in which you are required to specify a time period.
    The Interval window is displayed.
  2. Select the check box for the required time unit (for instance, select the Minutes check box if you want to specify a time period in minutes).
  3. Use the adjacent combo box to specify whether you want to Add or Subtract the time period. (You may want to select the Subtract option if you are specifying a time period that comprises a combination of time units, in order to produce the time period that you require (see the example below).)
  4. Use the corresponding text entry field to specify the actual time value (for instance 2, for 2 Days, Hours, or Minutes, and so on.)

If the Interval window is accessed from a ViewX workstation on which the On-Screen Keyboard feature is enabled, a keypad is displayed on-screen whenever you select a time field.

Either enter the time value in the text entry field directly, or Use the Numeric Touch Screen Keypad to specify the required value.

Your ViewX workstation might be configured to display an on-screen keypad whenever a time field is selected. Designed for use with touch screen displays, you can use the on-screen keypad to enter the required value, instead of using a traditional keyboard.

  5. Repeat steps 2 to 4 for any other time units and values that are required to produce the overall time period.
    The resultant time period is shown in the display area at the bottom of the window. The period is updated as you use the above fields to produce the required interval.
  6. Select the OK button to close the Interval window and display the specified time period in the field on the configuration Form.

Years and Months are only supported in a few select places, each of which are not fixed periods—for example a Trend’s x-axis interval. Where Years and Months can be used, they are combined with an Offset. For instance, with an Offset of ‘Y’ (the beginning of this year), you can specify an Interval of ‘1Y’ (to give ‘this year’).

Fields for small time units, such as Milliseconds, are only included in the Interval window when such a time period might need specifying.

Example:

To use the Interval window to specify a time period of one hour and 30 minutes, you would specify the following:

On Forms, although the time period will initially be displayed in full in the field on the Form, once the Form is re-displayed, for numeric fields the time period will appear in short OPC Time Format:

For string fields, the time period will remain in exactly the format in which it was entered, including any blank spaces. (To ascertain whether a field is a numeric field or a string field, select the field and look at the field type that is displayed in the Status Bar at the bottom of the ViewX window.)

Further Information

To enter a time period directly in ClearSCADA, see Specify a Time Period in the OPC Time Format.


Core Configuration Guide - Specify a Time Period in the OPC Time Format (Using OPC Time Formats)

Specify a Time Period in the OPC Time Format

NOTE: Fields for which you are required to specify a time period have an adjacent browse button. You can use the browse button to display an Interval Window that you can use to specify the required time period.

To manually enter a time period in the OPC Time Format, you enter the time value as a numeral, followed by the time unit as either a single letter (short format) or as a word or partial word (long format).

So, to enter a time period that represents ten minutes, you specify either 10M (short OPC Time Format) or 10 Minutes (long OPC Time Format). You can also enter a combination of units to represent a time—for example, 2H 30M (short OPC Time Format) or 2 hours 30 minutes (long OPC Time Format). The format is case insensitive and spaces are optional.

On configuration Forms, the format in which a time period is displayed depends on whether the field is a string or numeric field. With numeric fields, ClearSCADA displays time periods in short OPC Time Format, regardless of whether the entry was specified using short or long OPC Time Format. With string fields, ClearSCADA displays time periods exactly as they are specified, including any character spaces.

The time units that ClearSCADA supports are:
Unit |  | Example (short format followed by long format)
Short Format | Long Format
S | Seconds | 5S 5 Seconds To enter a time in milliseconds, use a fraction, for example: 1.500S 1.500 Seconds
M | Minutes | 10M 10 Minutes
H | Hours | 1H 1 Hour
D | Days | 2D 2 Days
W | Weeks | 3W 3 Weeks
MO | Month | 2MO 2 Months
Y | Year | 3Y 3 Years

Example:

An engineer wants the x-axis of a digital point’s Trend to display time over a 30-minute interval. The engineer enters 30M in the Interval field, within the Trend section of the Digital Point Form. 30M is the short OPC Time Format for a 30-minute interval.

You can prefix a time value with + or -. Where a prefix is omitted, this equates to +.

You can specify an individual time value or combine several values to produce the time period that you require.

Example:

2H+30M is the same as 2H 30M.

2H-30M is equivalent to 1H 30M.

NOTE: In some instances, there is a limit to the minimum time that you can enter. For example, whole minutes rather than seconds. You will be prompted if you try to enter an unacceptable time for a particular item.
Be aware that Years and Months are only supported in a few select places, each of which are not fixed periods—for example a Trend’s x-axis interval. Where Years and Months are used, they are combined with an Offset. For instance, with an Offset of ‘Y’ (the beginning of this year), you can specify an Interval of ‘1Y’ (to give ‘this year’).


Core Configuration Guide - OPC Relative Time Format (Using OPC Time Formats)

OPC Relative Time Format

Enter a time value that is relative to the present time, by entering the value in the OPC Relative Time Format.

You use the OPC Relative Time Format, for instance, to enter Trend offsets.

If you are required to specify a relative time, either:

  • Use the browse button next to the field to display an Offset window. You can then use the window to specify the required relative time value (see Offset Window).

or:

  • Enter the relative time directly in the field (see Specify a Relative Time in the OPC Relative Time Format).

To specify a relative time that always refers to a time in the past, or that takes into account a particular time zone, see Specify a Relative Time that Always Refers to a Time in the Past.


Core Configuration Guide - Offset Window (Using OPC Time Formats)

Offset Window

You can use the Offset window to specify a relative time in OPC Relative Time Format. The window is displayed when you select the browse button next to a field in which you are required to specify a time that is relative to the present time.

Select the browse button next to a field in which you are required to specify a relative time...
...to display the Offset window. Use the fields in the window to specify the required relative time...
...Select the OK button to confirm your selection and display the entry in the Form’s field.
...The Preview field indicates to what the specified relative time currently equates...

To specify a relative time using the Offset window:

  1. Select the browse button next to the field in which you are required to specify a time that is relative to the present time.
    The Offset window is displayed.
  2. Use the From the start of the current combo box to specify the required time unit from which the time is to be relative (for instance, select the Hour option if want to specify a time that is relative to the start of the present hour).

Choose from Year, Month, Week, Day, Hour, Minute, or Second.

  3. Select the check box that represents the time unit by which the relative time is to be offset from the present time (for instance, select the Minutes check box to specify a time that is offset from the present time by one or more minutes).
  4. Use the adjacent combo box to specify whether you want to Add or Subtract the time value from the start of the time unit specified in step 2 (see the example below).
  5. Use the corresponding text entry field to specify the actual time value (for instance 2, for 2 Hours, or 2 Minutes, and so on.)

If the Offset window is accessed from a ViewX workstation on which the On-Screen Keyboard feature is enabled, a keypad is displayed on-screen whenever you select a time field.

Either enter the time value in the text entry field directly, or Use the Numeric Touch Screen Keypad to specify the required value.

Your ViewX workstation might be configured to display an on-screen keypad whenever a time field is selected. Designed for use with touch screen displays, you can use the on-screen keypad to enter the required value, instead of using a traditional keyboard.

  6. Repeat steps 3 to 5 for any other time units and values that are required to produce the required relative time.
    The resultant time is shown in the display area at the bottom of the window. The entry is updated as you use the above fields to produce the required time.
  7. Select the OK button to close the Offset window and display the specified relative time in the field on the configuration Form.

Example:

To use the Offset window to specify a time that represents 06:30:00.000 today, you would specify the following:

The specified relative time, in OPC Relative Time Format.
The Preview field indicates to what the specified relative time currently equates. (In this example, 6 hours and 30 minutes from the start of the present day.)

Once confirmed (by selecting the OK button on the Offset window), the resultant relative time entry is displayed in the field on the configuration Form:

Further Information

To enter a relative time directly in ClearSCADA, see Specify a Relative Time in the OPC Relative Time Format.


Core Configuration Guide - Specify a Relative Time in the OPC Relative Time Format (Using OPC Time Formats)

Specify a Relative Time in the OPC Relative Time Format

NOTE: Fields for which you are required to specify a relative time have an adjacent browse button. You can use the browse button to display an Offset Window that you can use to specify the required time.

To manually enter a relative time, you enter a time value in the OPC Relative Time Format, using the following syntax:

<base> [ ( + ¦ - ) <interval> ]

where:

  • <base> is a base time that is relative to ‘now’, the present time.

You can enter a base time in either short or long format—see the table below for the list of supported base times.

Example:

H
(The short OPC Relative Time Format for the start of the present hour.)

  • <interval> is an optional further offset that you can either add or subtract from the base time. You specify this offset in the OPC Time Format.

Example:

30M
(Half an hour.)

You can specify both the <base> and <interval> in either short or long format. The syntax is case insensitive and character spaces are optional.

(If required, you can use an extension to this syntax, to Specify a Relative Time that Always Refers to a Time in the Past, or that takes into account the relevant time zone.)

Example:

An engineer wants the x-axis of a digital point’s Trend to display time over an interval that starts 15 minutes before the beginning of the current minute.

The engineer enters M - 15M in the Offset field, within the Trend section of the Digital Point Form.

M - 15M is the short OPC Relative Time Format that corresponds to ‘15 minutes before the start of the present minute’ (as M - 15M = the start of the present minute minus 15 minutes).

(The long OPC Relative Time Format equivalent of M - 15M is Minute - 15 Minutes.)

The base times that ClearSCADA supports are:
Base Time |  | Description
Short Format | Long Format
S | Second | Beginning of the current second
M | Minute | Beginning of the current minute
H | Hour | Beginning of the current hour
D | Day | Beginning of the current day (starting from midnight)
W | Week | Beginning of the current week (starting from midnight on Sunday)
MO | Month | Beginning of the current month (starting from midnight on the first of the month)
Y | Year | Beginning of the current year (starting from midnight on the first of January)
NOW | NOW | ‘Now’ exactly (to the nearest 100 nanoseconds)

Examples:

D
is the short OPC Relative Time Format that represents 00:00am today (long format: Day)

D-1D
is the short OPC Relative Time Format for the start of the yesterday.(D is the start of today, and -1D moves that base time back by one day.)

D-2H
is the short OPC Relative Time Format for 10:00pm yesterday. (D is the start of today, and -2H moves that base time back by two hours.)

D+12H
is the short OPC Relative Time Format for midday today. (D is the start of today, and +12H adds 12 hours onto that base time.)

H+1H
is the short OPC Relative Time Format for the end of the present hour. (H is the start of the present hour, and +1H adds one hour onto that base time.)

H - 30M
is the short OPC Relative Time Format for the middle of the previous hour; where H indicates the start of the current hour, and 30M is the offset backwards in time from that hour. (Long format: Hour - 30 Minutes)

MO + 2W
represents the 14th day of this month (long format: Month + 2 Weeks)

D + 4H 30M
represents 04:30am today (long format: Day + 4 Hours 30 Minutes)

Specify a Relative Time that Always Refers to a Time in the Past

You can specify a relative time that always refers to a time in the past, and that optionally uses a particular time zone, with this syntax:

<base>[<time><time zone>] ( + ¦ - ) <interval>

where:

<time> is the time offset from the <base>

<time zone> is optional and indicates the time zone that applies to the entry. When specified, ClearSCADA uses that time zone when calculating the relative time

the square brackets [] surrounding the above entries specify that those entries should always refer to a time in the past, rather than a possible future time

<base> and the optional <interval> are as described earlier in this section.

Example:

D[05:00 Local]

(Specifies 05:00am today (or 05:00am yesterday, if the current time is 04:59am or earlier), in Local Time.)

The inclusion of the <time zone> element of the syntax is typically optional. If it is omitted from the syntax, ClearSCADA will apply whichever time zone is assigned to the property. (With fields on some configuration Forms, the time zone is specified in a nearby field, in which case the <time zone> element has to be omitted when using the above syntax.)

Example:

A Logic program includes this configuration:

This results in the Logic program triggering at 08:00am UTC each day.

(The time zone does not need specifying in this particular Interval Offset field, as it is specified in the adjacent Interval Offset Time Zone field.)

ClearSCADA supports these [<time> <time zone>] combinations:
Base Time (short format followed by long format) | Supported Combinations (shown in short format only) | Description
H Hour | H[MM] H[MM <Time Zone>] | MM indicates the minutes from the start of the current hour (or the previous hour, if that number of minutes has not yet been reached during the current hour).
D Day | D[HH:MM] D[HH:MM <Time Zone>] | HH indicates the hours, and MM the minutes from the start of the current day (or from the start of the previous day if that time has not yet been reached during the current day).
W Week | W[DD] W[DD <Time Zone>] W[DD:HH:MM] W[DD:HH:MM <Time Zone>] | DD indicates the day, HH the hours, and MM the minutes from the start of the current week (or from the start of the previous week, if that date and time has not yet been reached during the current week).
MO Month | MO[DD] MO[DD <Time Zone>] MO[DD:HH:MM] MO[DD:HH:MM <Time Zone>] | DD indicates the day, HH the hours, and MM the minutes from the start of the current month (or from the start of the previous month, if that date and time has not yet been reached during the current month).
Y Year | Y[MM] Y[MM <Time Zone>] Y[MM:DD] Y[MM:DD <Time Zone>] Y[MM:DD:HH:MM] Y[MM:DD:HH:MM <Time Zone>] | The first MM indicates the month, DD the day, HH the hour, and the second MM the minutes from the start of the current year (or the previous year, if that date and time has not yet been reached during the current year).

where <Time Zone> can be any one of these time zone units (alternatively, omit the units for ClearSCADA to use whichever time zone applies to the field):
Time Zone Unit | Description | Example
UTC | Coordinated Universal Time | Day[08:00 UTC] + 5 Seconds (Long OPC Relative Time Format for 08:00:05.000 UTC from the start of the current day.)
Local | Local Time, with adjustments made to account for Daylight Saving Time (DST). | H[15 Local] + 30S (Short OPC Relative Time Format for 15 minutes and 30 seconds past the current hour, local time. Adjustments are made for DST.)
LocalNoDST | Local Time (for instance, EST (Eastern Standard Time) if the local time zone is that for the East coast of America). No adjustments are made for Daylight Saving Time (DST). | Month[02:06:30 LocalNoDST] (Long OPC Relative Time Format for 06:30am on the 2nd day of the current month, local time. No adjustments are made for DST.)

In some cases, there is a limit to the minimum time that you can enter. For example, whole minutes rather than seconds. You will be prompted if you try to enter an unacceptable time for a particular item.

Further Information

Time Zone Support in ClearSCADA.


Core Configuration Guide - Time Zone Support in ClearSCADA

Time Zone Support in ClearSCADA

ClearSCADA can communicate with devices that run in Coordinated Universal Time (UTC) or Local Time.

Internally the ClearSCADA server processes and stores time values in Coordinated Universal Time (UTC). For any feature or function that runs in Local Time, ClearSCADA converts the time from UTC to Local Time as required.

Each ClearSCADA Server and ClearSCADA Client obtains its time locally from the PC on which it resides.

You can specify on a per user basis as to whether times on a ClearSCADA Client are displayed in Local Time or UTC.

Of the outstations, PLCs and other devices and applications with which ClearSCADA can interact, many of these run in UTC. However, some outstations and other devices only run in Local Time, while others support being run in either UTC or Local Time.

With any device or application that runs in Local Time, the relevant ClearSCADA driver automatically converts the times that it receives from that device or application to UTC, before passing the times onto ClearSCADA. Conversely, the driver converts any times sent from ClearSCADA to Local Time, before passing those times on to any device or application that runs in Local Time. For more information, see Outstations with Clocks that Run in Local Time with Daylight Saving Time.

With devices for which the time zone setting is optional, ClearSCADA provides options on the relevant configuration Form, to allow you to specify the required time zone.

(Some devices support fewer options than those shown above.)

In ClearSCADA, various features—such as Historic Views, Schedules, and Logic Programs—can run in Local Time or UTC as required. With such features, configuration options are provided to enable you to specify the required time zone setting. Each of these features obtains its time from the ClearSCADA server.

For further information on any device or application for which the time zone setting is optional, see the appropriate configuration section in the relevant core or driver guide.

Further Information

Specify whether times in ClearSCADA are displayed in UTC or Local Time:

  • for a named user: see Define the Regional Settings for a User in the ClearSCADA Guide to Security
  • for a guest user: see Define the Global Settings for All Guest and Web User Accounts in the ClearSCADA Guide to Security
  • on the clock that can optionally be displayed in the ViewX Status Bar: see Add a Clock to the Status Bar on a ViewX Client in the ClearSCADA Guide to Client Administration.

Local Time and The Affects of Daylight Saving Time Adjustments.

Script functions to convert time values from UTC to Local Time or vice versa: see LocalTimeToUTC, and see UTCToLocalTime in the ClearSCADA Guide to Scripting.

Logic functions to convert time values from UTC to Local Time or vice versa: see LOCAL_TO_UTC, and see UTC_TO_LOCAL in the ClearSCADA Guide to Logic.


Core Configuration Guide - Coordinated Universal Time (Time Zone Support in ClearSCADA)

Coordinated Universal Time

Coordinated Universal Time (UTC) is a universally recognized time standard that is based on International Atomic Time (TAI). With UTC, leap seconds are added at irregular intervals to maintain the time’s accuracy in relation to the Earth’s slowing rotation. UTC replaced Greenwich Mean Time (GMT) as the main reference time standard used by many regions worldwide in January 1972.

With UTC, there are no time adjustments in relation to Daylight Saving Time.

Local Time zones around the world can be expressed as positive or negative offsets from UTC.

The Network Time Protocol (NTP)—an Internet protocol used for synchronizing the system clocks on many computer systems—uses UTC to synchronize such clocks. The protocol synchronizes the clocks to the time of a ‘reference’ clock, such a known accurate atomic clock.

Internally the ClearSCADA server processes and stores time values in UTC. With any feature or function that runs in Local Time and with which ClearSCADA interacts, ClearSCADA converts the time from UTC to Local Time as required (see Time Zone Support in ClearSCADA).

Any log files generated by ClearSCADA show time values in UTC. The log file header indicates the Local Time zone that applied at the time that the log file was generated. The Local Time zone is shown as an offset from UTC, enabling you to ascertain when a particular activity occurred in either UTC or Local Time.

Example:

This log file shows that logging started at 00:27:46.646 UTC...
...and that the Local Time was 8 hours ahead of UTC...
...therefore these events, for which times are shown in UTC, occurred between 08:27:47.162 and 08:27:49.381 Local Time.
‘(Standard)’ indicates that Daylight Saving Time (DST) was not in force.

On some systems, ClearSCADA’s Automation Interface is used to enable external applications to query items in the ClearSCADA database. The Automation Interface provides time values in UTC. Should time values be required in Local Time, the external application or a third-party program will need to convert the time values from UTC to Local Time. For further information on the Automation Interface, see the Server Automation Technical Reference online Help.

With external applications that query items in the ClearSCADA database using ODBC, you can specify whether the third party ODBC Client converts the time values supplied by ClearSCADA from UTC to Local Time (see Configure a Third Party ODBC Client - System Connection in the ClearSCADA Guide to Client Administration).


Core Configuration Guide - Local Time (Time Zone Support in ClearSCADA)

Local Time

Local Time is the time local to the region of the world in which a user or device is located. Each Local Time zone around the world can be expressed as a positive or negative offset from Coordinated Universal Time (UTC).

Many countries that are not close to the equator adopt Daylight Saving Time for part of the year (see Daylight Saving Time). The Local Time for the rest of the year is known as Standard Time.

Although internally, the ClearSCADA server processes and stores time values in UTC, ClearSCADA can communicate with devices that run in UTC or Local Time. With each device that runs in Local Time, ClearSCADA converts the time from UTC to Local Time and vice versa as required (see Time Zone Support in ClearSCADA).


Core Configuration Guide - Daylight Saving Time (Time Zone Support in ClearSCADA)

Daylight Saving Time

With many countries that are not close to the equator, a time adjustment is made to the Local Time each spring and autumn, to adjust the time forward or backward, typically by one hour. This time adjustment is used to make the most of the smaller number of daylight hours over the winter period and to save artificial energy. This time adjustment is known as Daylight Saving Time (DST).

In the UK, for example, Greenwich Mean Time (GMT) is the Local Time between 01:00 on the last Sunday in October and 01:00 on the last Sunday in March. For the rest of the year, the Local Time is UTC+1 (known in the UK as ‘British Summer Time’ (BST)).

On the eastern coast of America, many of the US states observe Eastern Daylight Time (EDT) during the summer months and Eastern Standard Time (EST) during the winter months. With EDT, the Local Time is 4 hours behind UTC; with EST, the Local Time is 5 hours behind UTC (or UTC-4 and UTC-5 respectively). So, for example, an event that occurred at 10:07:49.000 EST would be logged internally in ClearSCADA as having occurred at 15:07:49.000 UTC.

For devices that run in Local Time and apply Daylight Saving Time adjustments, the most noticeable affect of the twice yearly time change is in the amount of data stored around the time that the clocks change (see The Affects of Daylight Saving Time Adjustments).

Be aware that not all devices that run in Local Time support time adjustments in relation to Daylight Saving Time (DST). The relevant configuration section mentions if any such limitations exist.


Core Configuration Guide - The Affects of Daylight Saving Time Adjustments (Time Zone Support in ClearSCADA)

The Affects of Daylight Saving Time Adjustments

This section applies to any device, feature or application that runs in Local Time with Daylight Saving Time.

The system clocks in most computer-based systems can adjust automatically when Daylight Saving Time (DST) starts and ends, based on their time zone settings.

This section explains the affects of Daylight Saving Time adjustments in ClearSCADA and the devices or applications with which it interacts. The section uses UK Daylight Saving Time adjustments as an example, but the affects are similar in any time zone in which Daylight Saving Time adjustments are made (although the difference between Local Time and UTC may be greater).

ClearSCADA stores time values internally in UTC. On any ClearSCADA Client running in Local Time, ClearSCADA converts such time values and displays them in Local Time. (A ClearSCADA Client displays times in Local Time when being used by a user whose User Account is configured to display times in Local Time.) The ClearSCADA Client obtains its time locally from the PC on which it resides, including whether Daylight Saving Time adjustments apply to that particular time zone.

In the UK the clocks jump forward by one hour in the spring (from 01:00 GMT to 02:00 BST on the last Sunday in March). This effectively ‘loses’ that hour and so results in a day that has only 23 hours.

The affects in ClearSCADA are as follows:

  • With data that is retrieved from outstations, PLCs and other devices that run in Local Time with Daylight Saving Time, no data is retrieved for the hour that is ‘lost’ when the clocks jump forward (as that hour never existed). With the data that ClearSCADA retrieves from the outstations and other devices outside of this hour, time values are converted to UTC for storage internally in the ClearSCADA database. For more information, see Outstations with Clocks that Run in Local Time with Daylight Saving Time.
  • With data that is retrieved from outstations, PLCs and other devices that run in either UTC or Local Time without Daylight Saving Time, data is retrieved as usual. No time adjustments are made for Daylight Saving Time. Time values are stored internally in the ClearSCADA database in UTC format. For any ClearSCADA Client running in Local Time, ClearSCADA converts the time values from UTC to Local Time for display on that Client.
  • When the clocks jump forward, the Events List on a ClearSCADA Client running in Local Time will include events up to 00:59:59.999, followed by events from 02:00.00.000 onwards.

If ClearSCADA logged events, for example, at 00:59:59.900 UTC and 01:00:00.100 UTC, these would appear to the user as being logged at 00:59:59.900 GMT and 02:00:00.100 BST.

The user would not see any events with time stamps between 01:00:00.000 to 01:59:59.999.

Conversely, in the UK the clocks jump backward by one hour in the autumn (from 02:00 BST to 01:00 GMT on the last Sunday in October). This effectively repeats that hour and so results in a day that has 25 hours.

The affects in ClearSCADA are as follows:

  • The Events List on a ClearSCADA Client running in Local Time will include events up to 01:59:59.999 before the time change, followed by events that occur from 01:00.00.000 onwards after the time change
    In the UK, clocks went back an hour at 02:00:00 BST on 25th October 2009. The Events List shows events that were recorded at 01:00:00.461 and 01:30:00.023 before the time change (the times for such events are in BST)...
    ...followed by events that were recorded at 01:00:00.444 and 02:00:00.395 after the time change. Although the time zone suffix is not shown, these events are in GMT.

The same Events List on a ClearSCADA Client running in UTC rather than Local Time:

With events that were recorded after the time change, the UTC times mirror the GMT times (as the GMT bias is UTC+0)...
... whereas with events that were recorded before the time change, the times differ by an hour (as BST is UTC+1).

  • With data that is retrieved from outstations, PLCs and other devices that run in either UTC or Local Time without Daylight Saving Time, data is retrieved as usual.

The data’s times values are stored internally in the ClearSCADA database in UTC format.

For any ClearSCADA Client running in Local Time, ClearSCADA converts the time values from UTC to Local Time for display on that Client.

ClearSCADA raises and clears alarms as usual, processing data against the UTC time stamps in the ClearSCADA database. On any ClearSCADA Client running in Local Time, this may result in an odd sequence of events around the time that the clocks jump backward: any alarm state that persists past the clock jump might appear as cleared before it was raised. For example, the Events List might show an alarm as being raised at 01:59:00.000 BST and then cleared at 01:11:00.000 GMT (but without the time zone suffix being displayed). (On a ClearSCADA Client running in UTC, the same alarm would be shown as being raised at 00:59:00.000 UTC and then cleared at 01:11:00.000 UTC, as BST is UTC+1, whereas GMT is UTC+0.)

  • With data that is retrieved from outstations, PLCs and other devices that run in Local Time with Daylight Saving Time, typically two sets of data is retrieved: one set of data for the time before the clocks jumped backward, and a second set of data for the time that was ‘repeated’ following the clock jump.

The way in which the apparent ‘duplication’ of data is handled varies per protocol. Care needs to be taken to ensure that no data is lost, due to the outstation or other device needing to store more records than usual for the period during which time is ‘repeated’.

With some protocols, the driver is able to retrieve all of an outstation’s data before changing the outstation’s clock and so is able to avoid such potential data loss.

Ideally, each outstation’s clock should be reset at exactly, or as close as possible to, the time when the actual time change occurs in that particular time zone. For example, at exactly 02:00:00.000, for the ‘repeated’ hour to run from 01:00:00.000 and 02:00:00.000.

If an outstation’s clock is reset at a later time, then the ‘repeated’ hour will run from the time that the reset occurred. So if a clock was reset at 02:15:00.000, for example, the ‘repeated’ hour would run between 01:15:00.000 and 02:15:00.000 for data retrieved from that particular outstation. For more information, see Outstations with Clocks that Run in Local Time with Daylight Saving Time.

Again, internally ClearSCADA stores the retrieved data’s time values in UTC format. The server raises and clears alarms by processing the data against the UTC time stamps in the ClearSCADA database.

An odd sequence of events might occur if an alarm was raised just before, and the alarm condition persisted until after, the clock was changed at an outstation. This is due to the fact that, during the hour that is ‘repeated’ when the clocks jump back, ClearSCADA deems any time stamped data that it receives from such an outstation to be in Daylight Saving Time.

Example:

An outstation raises an alarm on one of its points at 01:50:00.000 BST. Internally in ClearSCADA, the 01:50:00.000 BST alarm time is stored as 00:50:00.000 UTC (as BST = UTC+1).

The outstation’s clock is reset at 02:01:00.000 BST to 01:01:00.000 GMT.

The alarm clears in the outstation at 01:10:00.000 GMT.

During the hour that is ‘repeated’ when the clocks jump back, ClearSCADA continues to assume that any time stamped data that it receives from an outstation running in ‘Local Time with Daylight Saving Time’ is in Daylight Saving Time (BST in this example). Therefore, internally ClearSCADA stores the alarm clearance of 01:10:00.000 GMT as 00:10:00.000 UTC (as the time is assumed to be in BST rather than GMT and BST = UTC+1).

As the latter data is time stamped with an earlier time than the previously stored value for the point, ClearSCADA deems this to be ‘out of sequence’ data. The out of sequence events result in a non-clearing alarm until the outstation’s clock has gone past the time when the alarm was raised. Once this time has been reached, further point updates clear the alarm.

With any features, such as Schedules and Logic Programs, that are configured to run in Local Time with Daylight Saving Time, care needs to be taken to ensure that those features are not configured to trigger during the time that is ‘repeated’ or ‘lost’ when the clocks change. If the features are set to trigger during this time, this will result in the feature:

  • being triggered twice for each expected occurrence during the hour that is ‘repeated’ when the clocks jump backward
  • not being triggered at all during the hour that is ‘lost’ when clocks jump forward.

With Schedules and Logic Programs that run in Local Time with Daylight Saving Time and are configured to trigger on a daily basis at a time other than during the hour that is ‘lost’ or ‘repeated’, those features will trigger:

  • after a 25-hour period on the day on which clocks jump backward
  • after a 23-hour period on the day on which clocks jump forward.

Consider whether to associate a Schedule with a Calendar in order to trigger events as expected on the days on which the clocks change.

If any of the above scenarios are unacceptable on your system, but the devices or applications are required to run in Local Time, we suggest that those items are configured to run in Local Time without Daylight Saving Time. In countries in which Daylight Saving Time is implemented, this will result in the clocks being out by an hour for the period during which Daylight Saving Time is in force. However, there will be no apparent ‘gaps’ in data, or ‘duplicate’ data entries, for the time period that would have been ‘lost’ or ‘repeated’ had those items been configured to run in ‘Local Time with Daylight Saving Time’.


Core Configuration Guide - Outstations with Clocks that Run in Local Time with Daylight Saving Time (Time Zone Support in ClearSCADA)

Outstations with Clocks that Run in Local Time with Daylight Saving Time

Most types of outstation have only basic or no built-in time zone support. Most outstations typically runs a single clock.

We recommend that any outstations with which ClearSCADA is to interact run in Coordinated Universal Time (UTC) whenever possible. ClearSCADA stores time values internally in UTC and therefore any time stamped data retrieved from such outstations will be stored ‘as is’, without ClearSCADA needing to perform any time conversions. (If required, time values can be displayed in Local Time on a ClearSCADA Client. With each User that requires time values to be displayed in Local Time, ClearSCADA converts its UTC time values to Local Time for display on whichever ClearSCADA Client that user is using.)

If outstations need to run in Local Time, we recommend that they run in Local Time without Daylight Saving Time. The relevant driver will convert any local time values to UTC before passing the data onto the ClearSCADA server, and vice versa whenever ClearSCADA sends time values to the outstation.

Should outstations need to run in Local Time with Daylight Saving Time, the outstation’s clock has to be set correctly at the transition from Standard Time to Daylight Saving Time and vice versa.

Ideally, all logged (time stamped) data should be retrieved from the outstation before the outstation’s clock is set forward or backward.

Care needs to be taken to ensure that the clocks of PSTN and On Demand outstations are set in a timely manner, as close as possible to the time at which the actual transition occurs. When clocks jump forward, the outstations’ clocks need to be set within the time frame by which the clocks jump. So, in time zones in which the clocks jump forward by an hour, the outstations’ clocks need to be set to the new time within 1 hour of that transition actually occurring. Providing that this is done, the data will be recorded with the correct time stamps both before and after the transition. (Any data that is reported within the 1-hour time frame is deemed to be in Standard Time, rather than Daylight Saving Time, and is time stamped as such.)

If any PSTN or On Demand outstations on your system run in Local Time with Daylight Saving Time, consider whether to use Schedules to automatically contact those outstations and change their clocks at the relevant time. For more information, see Using Schedules to Automate Regular Functions.

For further information on the effects of clock changes in outstations that run in Local Time with Daylight Saving Time, see The Affects of Daylight Saving Time Adjustments.

Example:

A PSTN outstation is configured to run in Local Time with Daylight Saving Time.

The outstation is in a time zone in which clocks jump forward by an hour in the spring, from 01:00 GMT to 02:00 BST. (In other words, from Standard Time to Daylight Saving Time.)

On the morning of the transition, the outstation logs an event at 01:30:00.000 GMT. The outstation’s clock has not yet been set to BST. The event is stored in the database as 01:30:00.000 UTC. On any ClearSCADA clients on which users view time values in Local Time, the event is shown as having occurred at 02:30:00.000 BST.

If the outstation’s clock had been set to BST before the event occurred (say at 01:00:01.000), the same event would have been:

  • logged in the outstation at 02:30:00.000 BST
  • stored in the ClearSCADA database with a time stamp of 01:30:00.000 UTC
  • still be reported to the user as having been logged at 02:30:00.0000 BST.

Therefore, as long as the outstation’s clock is set forward correctly before 02:00:00.000 GMT, events that occur before and after the clock change will be reported and logged with the correct time stamp.

If for some reason the outstation’s clock was not updated until after 02:00:00.000 GMT, ClearSCADA would deem any time values for 02:00:00.000 onwards to be in BST rather than GMT. So if the outstation logged an event at 02:05:00.000 GMT, for example, ClearSCADA would process that data as having been logged at 02:05:00.000 BST (rather than GMT). Therefore in ClearSCADA the data would be logged with a time stamp of 01:05:00.000 UTC, and be shown on any ClearSCADA client on which users view time values in Local Time, as 02:05:00.000 BST.

If the outstation’s clock was only updated at, say, 02:30:00.000 GMT, any time stamps for 02:00:00.000 onwards would be presumed to be in BST rather than GMT. Additionally, when the outstation’s clock was adjusted forward by an hour at 02:30:00.000 GMT to 03:30:00.000 BST, a gap of one hour would appear in the data that ClearSCADA retrieves from the outstation. This is due to the 02:30:00.000 GMT clock change occurring half an hour later than the one-hour limit within which the clock’s time needed to have been set, in order for all of its time stamped data to be recorded correctly.


Core Configuration Guide - Defining Identification Details

Defining Identification Details

Each configuration Form contains an Identification tab. The tab has three fields:

Identification tab

  • Name—This field is for information only. It shows the name that has been defined for the item. You can only change the name by using the Rename action (see Renaming a Database Item)—you cannot use a Form to change the name of a database item.
  • Help View—Use this field to define a Help view for the selected database item. The Help View is optional and does not affect the performance of the selected database item. You can use a Help View to provide help information, such as instructions or procedures for using an item (see Specify a Help View).
  • Exclude From Exclusive Control—If the Exclusive Control feature is used on your system, use this check box to Specify Whether to Exclude a Group or Database Item from Exclusive Control.


Core Configuration Guide - Specify a Help View (Defining Identification Details)

Specify a Help View

You can associate each database item with a document that provides help about that item. For example, operating instructions for a piece of equipment. The document has to be a ‘File Object’ (you can view a list of existing File Objects on your system by selecting the File Objects entry on the Queries Bar).

Operators can access the Help View by selecting the Display Help View pick action, available (if a Help View is defined) from the context sensitive menu for the database item.

To specify a Help view:

  1. Display the Form for the database item that you want to configure (see Display a Form).
  2. Select the browse button next to the Help View field on the Identification tab.
    A Reference browse window is displayed.
    Reference browse window

  3. Use the Reference browse window to locate the File Object that you want to use as the Help View.
  4. Select the File Object.
  5. Select the OK button.
    The Reference browse window is closed, and the name of the selected File Object is shown in the Help View field.

NOTE: You can use the Go To hyperlink that is adjacent to the Help View field, to display the Form for the Help View.

  6. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Specify Whether to Exclude a Group or Database Item from Exclusive Control (Defining Identification Details)

Specify Whether to Exclude a Group or Database Item from Exclusive Control

The Exclusive Control feature allows a user to take control of an item or group of items in the database. When an item is under exclusive control, other users are unable to access certain, or all, features associated with that item. The feature is typically used to either allow maintenance engineers to work on part of a system, or to allow a regional control room to control specific areas of the system at specific times.

In order for the feature to be used, Exclusive Control needs to be enabled on the server(s) on a ClearSCADA system (see Exclusive Control Settings in the ClearSCADA Guide to Server Administration).

If the Exclusive Control feature is used on your system, there may be certain items or groups on your system that need to be excluded from any exclusive control activity, in order to allow users to access those parts of the system at all times. Use the Exclusive Control check box on each Group or item’s configuration Form to specify whether that group or item is to be excluded from exclusive control.

To exclude a Group or database item from exclusive control:

  1. Display the Form for the Group, or item (see Display a Form).
  2. On the Identification tab, select the Exclude From Exclusive Control check box.
  3. Save the configuration (see Saving Configuration Changes).
    The Group or item is excluded from exclusive control.

You can also use the above procedure to exclude a Group Template or Group Instance from exclusive control.

(For a database item, Group, Group Template, or Group Instance to be included in any relevant exclusive control activity, ensure that the Exclude From Exclusive Control check box is clear.)

Further Information

Using the Exclusive Control Feature: see Exclusive Control in the ClearSCADA Guide to Security.

Specifying which Permissions are only Available to a User with Exclusive Control: see Exclusive Control Settings in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Using the User Methods Tab to Define Custom Actions

Using the User Methods Tab to Define Custom Actions

You can associate up to five custom pick actions (‘methods’) with an item in a ClearSCADA database. This facility allows you to create custom actions to, for example, enable users to modify the properties of any custom database fields, or perform an action on all or some of the outstations in a set.

You use the User Methods tab on the relevant configuration Form to specify the database item with which an action is to be associated and the ‘method’ that ClearSCADA is to trigger on that item. You also use the tab to specify a custom title for the pick action (see Add a Custom Pick Action).

Once configured, the custom action is automatically appended to the list of ‘core’ and driver-specific pick actions for that item.

For a series of examples that demonstrate how custom actions might be used on a ClearSCADA system, see Example Configuration.


Core Configuration Guide - Add a Custom Pick Action (Using the User Methods Tab to Define Custom Actions)

Add a Custom Pick Action

To add a custom pick action to an item in the database:

  1. Display the Form for the database item for which you want to add a custom pick action (see Display a Form).
  2. Select the User Methods tab.
  3. Ensure that the Enabled check box is selected, so that the fields on the User Methods tab are available for use.
  4. Select the browse button adjacent to the first unused Object field.
    A Reference browse window is displayed.
    Use the browse button to locate the database item on which ClearSCADA is to perform the custom action.

  5. Use the Reference browse window to locate the database item for which ClearSCADA is to trigger the custom pick action.
  6. Select the browse button adjacent to the corresponding Method field.
    The Edit Method window is displayed.
    Select the Method (action) that ClearSCADA is to perform on the item.

  7. Use the Edit Method window to select the method that ClearSCADA is to trigger on that item and to specify the values of any arguments for that method (see Specify a Method).

The list of available methods varies, depending on the item that is specified in the window’s Object field and the entries in the Aggregate or Alarm fields.

For information on the type of expression that you can specify, see Method Expressions, and see User Method Expressions—both of these sections are in the ClearSCADA Guide to Expressions.

  8. Use the corresponding Title field on the configuration Form to specify the pick action name that is to appear whenever a pop-up context-sensitive menu is displayed for the item on which you are configuring the User Method details.

We advise that you use a naming convention that makes it clear when a pick action is a custom action, so that users are aware as to which actions can be further modified or updated, if necessary.

In the Title field, enter a suitable name for the custom action.

  9. Use the Permission combo box to specify the permission that a user has to be allocated in order to be able to execute the user method.

By default, the Permission field is set to Control, which requires a user have access to the control action(s) for that database item, in order to execute the user method.

For more information on the permissions that ClearSCADA supports, see Permissions for Database Items in the ClearSCADA Guide to Security.

  10. Repeat steps 4 to 9 for any other custom pick actions that you want to define on the same Form.
  11. Save the configuration (see Saving Configuration Changes).

For a series of examples that demonstrate how custom actions might be used on a ClearSCADA system, see Example Configuration.


Core Configuration Guide - Example Configuration (Using the User Methods Tab to Define Custom Actions)

Example Configuration

Use the examples in this section as an aid when configuring custom pick actions. The examples demonstrate how to produce:

  • Custom Actions used to Execute One Shot Calls on Multiple Outstations
  • A Custom Action used to Set the Value of a Test Point
  • A Custom Action used to Increment the Value of a Point.

Further Information

For an example that demonstrates using the TIME function in the expression for a User Method, see TIME in the ClearSCADA Guide to Expressions.

For an example that demonstrates using the USERNAME function in the expression for a User Method, see USERNAME in the ClearSCADA Guide to Expressions.


Core Configuration Guide - Custom Actions used to Execute One Shot Calls on Multiple Outstations (Using the User Methods Tab to Define Custom Actions)

Custom Actions used to Execute One Shot Calls on Multiple Outstations

This example demonstrates how custom pick actions can be used to perform actions such as triggering One Shot calls on groups of outstations. In this particular example, custom actions are configured to execute Structured Text Programs. For more information on working with Structured Text and other logic programs, see the ClearSCADA Guide to Logic.

Example:

A PSTN Outstation Set comprises 20 outstations. Two custom pick actions are required: one to trigger a One Shot call to the first ten outstations in the set, and another to trigger a One Shot call to the remaining outstations in the set.

Two Structured Text Programs are produced in the ClearSCADA database. Each is written to group ten of the outstations together and execute a One Shot call on those outstations.

The One Shot calls are to be triggered on a manual basis, and so the Structured Text Programs are not attached to a Schedule (which would trigger them on a regular basis), but are configured to be triggered manually via custom One Shot pick actions.

To trigger the One Shot calls manually, two custom pick actions are added to the User Methods tab of the PSTN Outstation Set with which the outstations are associated:

The Object field for each custom action is set to reference the appropriate Structured Text Program and the Method field is set to execute that Program:

The Object fields reference the Structured Text Programs that are used to group the outstations together.
The Method fields are used to trigger the respective Structured Text Programs.

An appropriate name is entered in the Title field, to indicate the custom actions’ functionality:

The Title fields are used to give the custom actions names that reflect their functionality.

The Permission required to execute each pick action is left at the default of Control.

The configuration is saved.

Whenever a user with the Control permission for that PSTN Outstation Set displays the context sensitive menu for the set, the two custom pick actions are displayed in the list of menu options:

The two custom pick action are displayed and available for use from the context-sensitive menu for the Outstation Set.


Core Configuration Guide - A Custom Action used to Set the Value of a Test Point (Using the User Methods Tab to Define Custom Actions)

A Custom Action used to Set the Value of a Test Point

This example demonstrates how a custom pick action might be configured to enable users to change the value of a Test point, which itself is used in a Logic program. The expression used for the pick action specifies a default value—the value that is used if no other value is specified for the point. This type of expression is only supported by User Methods (see Method Expressions in the ClearSCADA Guide to Expressions).

Example:

The fields on the User Methods tab of the Test Point’s Form are used to assign a custom pick action to that point:

The Method field is used to trigger an Override action. The first argument in square brackets specifies the label for field in the window that is displayed when the action is triggered (‘Required Value’). The second argument specifies the default value that is displayed in that window’s field. Should a different value not be specified when the action is triggered, the point’s value will be overridden with this default of 12.
The Title field is used to give the custom action a name that reflects its functionality. As with standard pick actions, an ellipsis (...) is appended to the entry to indicate that the action requires input from the user (via the window that is displayed when the action is triggered) before the action is executed.

The Permission required to execute the pick action is set to Override/Release.

The configuration is saved.

Whenever a user with the Override/Release permission for the Test Point displays the context sensitive menu for that point, the custom pick action is displayed on the list of menu options:

The custom pick action is displayed and available for use from the context-sensitive menu for the point. The pick action is assigned the Title that is specified on the User Methods tab.

When the pick action is selected, a custom pick action window is displayed:

The field’s label is assigned the first argument that is specified in the Method field for that action on the User Methods tab.
The field’s default value is the second argument that is specified in the Method field on the User Methods tab.

The user can either:

  • Select the OK button without entering a different value (in which case, the Test Point will be overridden with the default value of 12)
  • Overtype the default with a different value, then select OK
  • Specify a different value using the Numeric Touch Screen keypad. (The keypad is only displayed on ViewX workstations on which the On-Screen Keyboard feature is enabled.)


Core Configuration Guide - A Custom Action used to Increment the Value of a Point (Using the User Methods Tab to Define Custom Actions)

A Custom Action used to Increment the Value of a Point

This example demonstrates how a custom pick action might be configured and used to increment the value of one point so that its value is greater than that of another point.

The expression in the example uses .$ notation. You can use such notation instead of specifying the full name and path of the database item on which the custom action is configured (the ‘method source’). The notation is an extension of the Relative References that are supported by ClearSCADA. The leading dot(s) . refer to the Group in which the source item is located; the $ refers to the item itself. (The $ is only required if the item on which the custom action is configured is not itself a Group, Group Template, or Group Instance) .$ notation is substituted with the relevant information when the custom action is executed.

Example:

A custom action is required to enable the value of Test Point 3 to be incremented so that it is 1 greater than the value of Test Point 4.

The custom action is configured using the fields on the User Methods tab on Test Point 4’s configuration Form:

The custom action is configured on the User Methods tab of Test Point 4’s Form.
The Object field is used to specify Test Point 3 as the item on which the Method is to be performed.
The method expression used to increment the current value of Test Point 3, so that it is 1 greater than the current value of Test Point 4.
The title that is used for the custom action in any context-sensitive menus.

The Method field is used to assign this expression to the custom action:

CurrentValue( ".$.CurrentValue" + 1 )

where:

CurrentValue is the method name that defines the type of activity that is to be performed on the database item specified in the Object field. (In this particular example, the custom action is used to change Test Point 3’s current value.)

( ".$.CurrentValue" + 1 ) is the argument used for the above method. (In this case, the argument specifies that the value of the above method is to be set to Test Point 4’s current value plus one. (".$.CurrentValue" stipulates the current value of the custom action’s source—the database item on which the custom action is configured—which in this example is Test Point 4.))

The Permission required to execute the custom action is left at the default of Control.

The configuration is saved.

The Test points are used in a Logic program:

When required, users with the Control permission can trigger the custom action on Test Point 4...

A user right-clicks on Test Point 4...
...to display a context-sensitive menu, from which the custom action is selected...

... to increment Test Point 3’s value so that it is one greater then that of Test Point 4:

...to increment the value of Test Point 3 so that it is one greater than the value of Test Point 4.


Core Configuration Guide - Defining a Default View

Defining a Default View

You can use the Group tab to define a Default View for a Group, Group Template, or Group Instance. The Group tab is displayed on the Group Form, Group Template Form, and the Group Instance Form.

Default Views are ‘File Objects’, such as Mimics, that represent Groups of items. For example, if the items in a Group represent a pump, then the Default View for that Group could be a Mimic showing the pump. Unlike Alarm Views (see Defining an Item or Group’s Alarm Properties), operators can access Default Views at any time, using the Display Default View pick action.

Default Views are typically configured to represent the items in the Group, and provide access to alarm response actions and controls.
Default Views usually contain representations of the items within the selected Group.

NOTE: You can view a list of existing File Objects on your system by selecting the File Objects entry on the Queries Bar.

To define a Default View for a Group, Group Instance, or Group Template:

  1. Display the Form for the Group, Group Template, or Group Instance you want to configure. For more details, please refer to Groups or Group Templates and Group Instances.

NOTE: You can only define a Default View for a Group Instance if the Group Template’s DefaultViewId property override has been enabled.

  2. Select the Group tab.
  3. Select the browse button next to the Default View field.
    A Reference browse window is displayed.
  4. Use the Reference browse window to locate the File Object that is to be the Default View.
  5. Select the required File Object.
  6. Select the OK button.
    The Reference browse window is closed and the name of the File Object is shown in the Default View field.
  7. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Defining an Item or Group's Alarm Properties

Defining an Item or Group’s Alarm Properties

Use the fields on the Alarm tab (of an individual database item) or Group tab (of a Group, Group Template, or Group Instance) to define the general alarm-related properties for that item.

With a Group, Group Template, or Group Instance, use the Group tab to:

  • Define an Alarm View—a Mimic or Trend that users can view whenever an alarm is raised for any item in the Group (unless an item has its own Alarm View)
  • Request Confirmation Before Disabling or Enabling Alarms—optionally check whether a user genuinely wants to disable or enable alarms before executing the request.

(A further field on the tab is used for Defining a Default View.)

Any individual item that can have an alarm has an Alarm tab on its configuration Form. Use the Alarm tab to:

  • Define an Alarm View—a Mimic or Trend that users can view whenever an alarm is raised for the item (such a view takes precedence over any Group Alarm View)
  • Configure a Method Action to Trigger at Every Alarm State Change—trigger an action automatically whenever an alarm is raised for the item
  • Request Confirmation Before Disabling or Enabling Alarms—optionally check whether a user genuinely wants to disable or enable the item’s alarms before executing such a request
  • Specify an Alternative Alarm Source Name—optionally assign an ‘Alarm Source’ name to identify the source of an alarm, rather than the full path of the item with which the alarm is associated
  • Configure any Alarm Suppression Requirements—to help prevent the system from being ‘flooded’ with multiple alarms.


Core Configuration Guide - Define an Alarm View (Defining an Item or Group's Alarm Properties)

Define an Alarm View

You can associate any database item that can have an alarm with an Alarm View.

An Alarm View is a ‘File Object’, such as a Mimic or Trend, that is associated with an item’s alarm state. When the item enters an alarm state, the Display Alarm View pick action becomes available for that alarm (if an Alarm View has been defined for that item). You can use the Display Alarm View pick action to access the item’s Alarm View.

Although any File Object can be defined as the Alarm View for an item, Alarm Views are usually configured to represent the alarm state. For example, for a channel, a suitable Alarm View could be a Mimic that contains an animated representation of the state of the channel. Typically, the animation would involve changing or flashing colors.

If you want the items in a Group to have individual Alarm Views, define those views using the Alarm tab on the Form for each item.

If you want all or many of the items in a Group to have the same Alarm View, define a group Alarm View using the Group tab on the Form for the Group, Group Instance, or Group Template. The group Alarm View is used by those items in the Group that do not have an individual Alarm View defined. A group Alarm View would typically be configured to represent every item in the Group, and provide access to alarm response actions and controls.

When an alarm is raised for one of the items in a Group or Group Instance, the alarm is displayed in the Alarm Banner—operators can select the alarm from the banner, or from the Alarms List (on either ViewX or a WebX client), and use the Display Alarm View pick action to display the Alarm View for the item.

If the item does not have a defined Alarm View, the Alarm View for the Group, or Group Instance, is displayed instead.

If you configure a database item to use the alarm redirection e-mail feature (see E-mail/Voicemail Redirection in the ClearSCADA Guide to Alarm Redirection), a hyperlink to the Alarm View that you define for the item (or the Group, if the item does not have its own Alarm View) can also optionally be included in any alarm redirection e-mails. This means that when the database item enters an alarm state, an e-mail containing the Alarm View hyperlink is sent automatically.

To define an Alarm View:

  1. Display the Form for the item that you want to configure (see Display a Form).
  2. Select the appropriate tab:
  • To define an Alarm View for an individual database item, select the Alarm tab.
  • To define an Alarm View for a Group, Group Template, or Group Instance, select the Group tab.

NOTE: You can only change the Alarm View for a Group Instance if the Group Template’s AlarmViewId property override has been enabled. If the AlarmViewId property override has not been enabled, the Group Instance inherits the Alarm View from the Group Template.

  3. Select the browse button next to the Alarm View field.
    A Reference browse window is displayed.
    Reference browse window

  4. Use the Reference browse window to locate the File Object that is to be the Alarm View for the selected database item.
  5. Select the File Object.
  6. Select the OK button.
    The Reference browse window is closed, and the name of the selected File Object is shown in the Alarm View field.

NOTE: You can display the Form for selected Alarm View by selecting the Go To hyperlink that is adjacent to the browse button.

  7. Save the configuration (see Saving Configuration Changes).

NOTE: You can view a list of existing File Objects on your system by selecting the File Objects entry on the Queries Bar.


Core Configuration Guide - Configure a Method Action to Trigger at Every Alarm State Change (Defining an Item or Group's Alarm Properties)

Configure a Method Action to Trigger at Every Alarm State Change

When an item changes alarm state, you can immediately trigger an action known as a Method Action on any item in the database. For instance, you might want to temporarily increase the rate of data retrieval from a PSTN outstation should an alarm state-change occur on a point on that outstation, or you might want to execute some logic in the form of a Structure Text Program or Function Block Diagram. To configure such an action to trigger automatically and immediately whenever an item changes alarm state, use the Method Object and Method fields on the Alarm tab of the relevant configuration Form.

Once configured, the specified Method Action triggers immediately whenever an alarm state change occurs, regardless of:

  • The severity of the alarm
  • The time at which the alarm state change occurs
  • Whether alarms are disabled for the item for which you are configuring the Method Action.

NOTE: A Method Action that is configured on the Alarm tab of a Form cannot have a delay or an abort state associated with it. To apply a trigger delay, an abort state, or otherwise limit the conditions under which a Method Action triggers, you need to configure the Method Action using fields on the Redirection tab, rather than the Alarm tab of the Form (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection). (For information on Alarm Redirections in general, see Introduction to Alarm Redirection in the ClearSCADA Guide to Alarm Redirection.)

To configure a Method Action using the fields on the Alarm tab of a Form:

  1. Select the browse button next to the Method Object field.
    A Reference browse window is displayed.
  2. Use the Reference browse window to locate the name of the database item on which ClearSCADA should trigger the Method (action) when an alarm state changes.
  3. Select the required database item.
  4. Select the OK button.
    The Reference browse window is closed and the selected item name is shown in the Method Object field.
  5. Select the browse button next to the Method field.
    The Edit Method window is displayed.
  6. Use the Edit Method window to select the required method (action) and to specify the values of any arguments for that method. The list of possible methods varies depending on the database item and its configuration, along with the Aggregate and Alarm options that you specify (see Specify a Method). For information on the type of expression that you can specify, see Method Expressions in the ClearSCADA Guide to Expressions.
  7. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Request Confirmation Before Disabling or Enabling Alarms (Defining an Item or Group's Alarm Properties)

Request Confirmation Before Disabling or Enabling Alarms

Use the Confirm Alarm Disable/Enable field on the Alarm tab of a Form to specify whether operators need to confirm any manual request to disable or enable alarms for that item.

For a Group, Group Template, or Group Instance, use the Confirm Alarm Disable/Enable field on the Group tab of the Form to specify whether confirmation is required when a manual request is made to disable or enable alarms for the whole group, template, or instance.

You can also specify whether an operator needs to confirm their logon password before ClearSCADA carries out the request, and whether Notes regarding the item are automatically displayed when an Enable Alarms or Disable Alarms pick action is selected.

Use the Confirm Alarm Disable/Enable combo box to display a list of options and select the required option from the list. For information on what options are available, see Requesting Confirmation of Action Requests.


Core Configuration Guide - Specify an Alternative Alarm Source Name (Defining an Item or Group's Alarm Properties)

Specify an Alternative Alarm Source Name

When an alarm is displayed—for instance, in an Alarms List or the Alarm Banner—the source of that alarm is indicated in the Source column. By default, the Source is the full name of the database item with which the alarm is associated.

As an alternative to displaying an item’s full name in an alarm entry, ClearSCADA can display an Alarm Source name. This is particularly useful on complex ClearSCADA systems, in which database items might be stored within multi-level Groups, so resulting in long and complex full names. (An item’s full name includes its path, with the different levels denoted by dot separators (.).)

To specify an alternative name, enter a suitable name in the Alarm Source field on an item’s Alarm tab. The Alarm Source name has to be unique across the system and also has to differ from the full name of any item on the system. (Should the Alarm Source conflict with that of an existing database item, ClearSCADA will mark the configuration as invalid—see Mandatory Configuration and Invalid Configuration Messages.) Whenever a valid entry is configured in the Alarm Source field, ClearSCADA includes this name in any alarm entries, in preference to the item’s full name.

Example:

By default, ClearSCADA would display the alarm Source for the item below as ‘Simple Drivers.Modbus.Modbus Channel’.

However, as a name is specified in the item’s Alarm Source field, ClearSCADA displays that name as the Source of the entry in the Alarms List, instead of the item’s full name.

Whenever a name is specified in an item’s Alarm Source field...
...ClearSCADA displays that name as the Source of any alarm associated with that item.
(If an item’s Alarm Source field is empty, ClearSCADA displays the item’s full name as the Source of that item’s alarms.)

NOTE: If an item is configured to use an Alarm Source name, you can ascertain its full name by right-clicking on its entry in the Alarms List or Alarm Banner and selecting the View Status option to view its Status display. Within ViewX, you can also right-click on its entry in the Alarms List or Alarm Banner and select the Locate in Database Explorer option, in order to locate the item in the Database Bar.

Further Information

Alarms, Alarms Lists, and the Alarm Banner: see the ClearSCADA Guide to Alarms.

Status displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.


Core Configuration Guide - Configure any Alarm Suppression Requirements (Defining an Item or Group's Alarm Properties)

Configure any Alarm Suppression Requirements

In ClearSCADA, alarms can be suppressed such that when an alarm is raised on a ‘parent’ item, any alarms raised on items that reference that ‘parent’ item are suppressed.

The primary purpose of alarm suppression is to avoid ‘flooding’ the system with alarms that are a natural consequence of other alarms. When suppression is used, ClearSCADA only raises alarm(s) for the ‘parent’ item. Any changes in value or state that would usually result in alarms being raised for ‘child’ items are suppressed (omitted from any alarm displays) so as not to confuse operators by displaying other alarms that would otherwise be raised due to original ‘parent’ alarm being active. For more information, see The Affects of Alarm Suppression in ClearSCADA.

You configure any alarm suppression using the fields within the Consequential Alarms section of each database item’s Alarm tab. (The tab exists for any item for which alarms can be raised.)

To configure alarm suppression:

  1. Use the Type combo box to specify the suppression type. Choose from:
  • None—Alarm suppression is not used for alarms raised by this item. The rest of the fields in the Consequential Alarms section are ‘grayed out’ and unavailable for use.
  • Consequential—Alarms raised by this item are suppressed should they occur while the Parent Alarm Condition is active for the Parent Alarm Object. The Event Journal record that is generated to indicate that alarms are suppressed states that the reason is due to Consequential alarm suppression.
  • Maintenance—This is an alternative to the Consequential option. Select this option if alarms raised by this item are suppressed should they occur while the Parent Alarm Condition is active for the Parent Alarm Object. The Event Journal record that is generated to indicate that alarms are suppressed states that the reason is due to Maintenance mode.
  2. With an alarm suppression Type other than ‘None’, use the Parent Alarm Object field to specify the database item that is to suppress this item’s alarms. Any alarms are only suppressed if they are raised while the Parent Alarm Object’s alarm status matches the Parent Alarm Condition.

Select the browse button next to the field to display a Reference browse window. Select the required database item from the window.

  3. Use the Parent Alarm Condition field to specify the specific type of alarm that, when raised by the Parent Alarm Object, will suppress any new alarms that might otherwise be raised by this item.

Select the browse button next to the field to display a Reference browse window. Select the required type of alarm from the window. The list of alarms varies depending on the database item. So, for instance, several types of alarm might be associated with an outstation item, while other types of database item might only have a single alarm type.

  4. Save the configuration (see Saving Configuration Changes).

For an example that demonstrates how alarm suppression might be configured in ClearSCADA, see Example Configuration.


Core Configuration Guide - Example Configuration (Defining an Item or Group's Alarm Properties)

Example Configuration

This example demonstrates how ClearSCADA might be configured to suppress the alarms of three database items, depending on the alarm status of a fourth item. The example demonstrates the affects of alarm suppression on those database items.

Example:

A ClearSCADA database includes a ‘Mains Fail’ item, which indicates whether a particular area is experiencing a mains power outage. In addition, the database includes individual ‘Power Failure’ items for each outstation (RTU).

If the power to an individual outstation is lost, the relevant ‘Power Failure’ alarm is raised.

If the power outage applies to a whole area, that area’s ‘Mains Fail’ alarm is raised. Additionally, a ‘Power Failure’ alarm is raised on each outstation in that area. Without alarm suppression, this would result in operators being faced with a number of new alarms being raised, each as a consequence of the same power outage. Therefore, alarm suppression is used to:

  • Help ensure that the cause of the alarms is not masked by the appearance of numerous ‘Power Failure’ alarms (which might otherwise suggest that the power local to several outstations is down, rather than the power to the whole area)
  • Avoid the need to respond to and/or acknowledge numerous alarms that have each been raised as a consequence of the same incident (in this case, mains power outage).

The alarm suppression is used to suppress (omit from any alarm displays) any ‘child alarms’ (in this case, any outstation alarms, including ‘Power Failure’ alarms) that are raised once the mains power outage has been detected in the area in which the outstations are located. The suppression remains in force for as long as the mains power outage continues. The alarm suppression works by suppressing any new alarms on each outstation in that particular area, while that area’s ‘Mains Fail’ alarm is raised. (Alarms are not suppressed if the power outage is local to only one or some of the outstations in the area.)

To suppress the individual ‘Power Failure’ alarms, the ‘Mains Fail’ database item is assigned as each ‘Power Failure’ item’s Parent Alarm Object:

Should the ‘Mains Fail’ alarm become active, the individual ‘Power Failure’ alarms that are triggered as a result of the mains power outage are suppressed (not shown on any alarm displays).

The Suppressed Alarm Count for the ‘Mains Fail’ alarm indicates how many alarms are suppressed:

The Suppressed Alarm Count indicates how many child alarms the ‘Mains Fail’ alarm is suppressing.
Any child alarms that were in existence when the ‘Mains Fail’ alarm became active are not suppressed. (Only new child alarms are suppressed while the ‘Mains Fail’ alarm is active.).

The ‘Mains Fail’ item’s Suppressed Alarm Objects pick action is used to display a list of the child database items that might have suppressed alarms due to the ‘Mains Fail’ alarm being active:

Further Information

The Affects of Alarm Suppression in ClearSCADA.


Core Configuration Guide - The Affects of Alarm Suppression in ClearSCADA (Defining an Item or Group's Alarm Properties)

The Affects of Alarm Suppression in ClearSCADA

This section explains the affect that alarm suppression has on ClearSCADA.

In the bullet list below, parent alarm refers to an alarm that meets the Parent Alarm Condition criteria and is raised on the item that is configured as a Parent Alarm Object. Child alarm refers to an alarm that is raised on a database item on which the above Parent Alarm Object is specified. For more information, see Configure any Alarm Suppression Requirements.

When alarm suppression is configured:

  • Should the parent alarm go active:
  • ClearSCADA will suppress any new child alarms (see The Affects of Suppression on Alarm Displays)
  • An event will be logged for each suppressed alarm. The event record will indicate whether each alarm is suppressed due to Maintenance, or Consequential, alarm suppression
  • Each child item’s State Alarm status attribute will indicate whether its alarms are suppressed
  • Any existing ‘child’ alarms will remain active
  • The parent alarm’s Suppressed Alarm Count (displayed, for example, on Alarms Lists and the Alarm Banner) will indicate how many child alarms are suppressed
  • The parent item’s Suppressed Alarm Objects pick action will provide access to a list of the child database item(s) for which alarms might be suppressed due to the parent alarm being active.
  • Whenever the parent alarm ceases to become active:
  • ClearSCADA will automatically activate any existing suppressed child alarms (see The Affects of Suppression on Alarm Displays). The newly activated alarm entries will be time stamped with their occurrence time (or, on systems on which the Use Visible Time As Alarm Active Time feature is enabled, their unsuppressed time)
  • An event will be logged for each existing child alarm that is unsuppressed, indicating the time that the alarm became unsuppressed
  • Any Alarm Redirection activity that applies to the child alarms will come into affect (for instance, ClearSCADA will start any redirection timers).

The parent-child alarm relationship can be cascaded, so that a top level parent alarm will disable the alarms of its child items, and of the children of those child items, and so on.

For an example that demonstrates the affects of alarm suppression in ClearSCADA, see Example Configuration.

Further Information

Events logged due to Alarm Suppression: see Alarm-Related Entries in the Events List in the ClearSCADA Guide to Alarms.

Alarm Redirection: see the ClearSCADA Guide to Alarm Redirection.

Use Visible Time As Alarm Active Time: see Define whether the Visible Time is used as the Active Alarm Time in the ClearSCADA Guide to Server Administration.

The Affects of Suppression on Alarm Displays

The table below indicates how the alarm condition that triggers alarm suppression affects the entries in alarm displays, such as Alarms Lists and the Alarm Banner:
Parent Alarm Object | Entry in Alarm Displays | Child Objects | Alarm Status | Entries in Alarm Displays
No active alarms | --- | Any alarms | Unacknowledged Uncleared/ Acknowledged Uncleared/ Unacknowledged Cleared | VISIBLE
Alarm that triggers alarm suppression raised | VISIBLE | Existing alarms that were raised pre-suppression | Unacknowledged Uncleared/ Acknowledged Uncleared | VISIBLE
 |  | Alarms that cleared pre-suppression, which remain unacknowledged | Unacknowledged Cleared | VISIBLE
 |  | Existing alarms, raised pre-suppression, which have been acknowledged while suppression is in force | Acknowledged Uncleared | VISIBLE
 |  | Alarms raised while suppression is in force | Unacknowledged Uncleared | Suppressed (not shown)
 |  | Alarms raised while suppression is in force and which have cleared while suppressed (ClearSCADA automatically acknowledges any alarms that are raised then clear while still suppressed) | --- | ---
Alarm that triggers alarm suppression cleared | VISIBLE (Unacknowledged Cleared)/ --- (once acknowledged) | Any alarms, regardless of whether they were raised pre-, post-, or during suppression | Unacknowledged Uncleared/ Acknowledged Uncleared/ Unacknowledged Cleared | VISIBLE*
Different type of alarm raised** | VISIBLE | Any alarms, regardless of whether they were raised before or while the parent object’s alarm is active | Unacknowledged Uncleared/ Acknowledged Uncleared/ Unacknowledged Cleared | VISIBLE

* The date and time assigned to any alarms that were suppressed but become visible once suppression is no longer in force varies, depending whether the Use Visible Time As Alarm Active Time feature is enabled. If the feature is enabled, the alarm entries are time stamped with the date and time that they became visible post-suppression; if the feature is disabled (the default on most systems), the alarm entries retain their original time stamp (indicating the alarm’s original receipt time or occurrence time).

** Only some types of database item support more than one type of alarm.

Further Information

Alarm Status: see Alarm Status in the ClearSCADA Guide to Alarms.

Alarm Activity: see Activities that Occur when an Alarm is Raised in the ClearSCADA Guide to Alarms.

Use Visible Time as Alarm Active Time: see Define whether the Visible Time is used as the Active Alarm Time in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Stand-Alone Method Calls

Stand-Alone Method Calls

‘Stand-alone’ Method Calls are sometimes used to execute methods (actions) during testing or commissioning. On systems that are running the Pager driver, Method Calls can also be used to trigger actions remotely, by SMS (Short Message Service) text message.

Method Calls work in a similar way to other actions, except that their functionality is triggered by an ‘Execute’ command. Any arguments used for a Method Call are defined when the Method Call is configured, rather than at the time that the Method Call is triggered.

To create and configure a ‘stand-alone’ Method Call, you need to:

  1. Add a Method Call.
  2. Configure the Method Call’s Properties.
  3. Save the configuration (see Saving Configuration Changes).

ClearSCADA supports a wide variety of actions and methods.

By default, each database item is provided with a set of ‘core’ and, where applicable, driver-specific action(s) (methods)—see the ClearSCADA Guide to ViewX and WebX Clients and the relevant driver guides for further information.

To trigger an action immediately when an item changes alarm state, you need to configure a Method Action (see Configure a Method Action to Trigger at Every Alarm State Change).

To associate several ‘custom’ actions with a database item, see Using the User Methods Tab to Define Custom Actions.


Core Configuration Guide - Add a Method Call (Stand-Alone Method Calls)

Add a Method Call

To add a Method Call to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a Method Call.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Method Call option.
    A Method Call is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Method Call (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added a Method Call to the system, you can then Configure the Method Call’s Properties.


Core Configuration Guide - Configure the Method Call's Properties (Stand-Alone Method Calls)

Configure the Method Call’s Properties

You configure a Method Call by configuring the properties on the Method Call Form.

To configure the properties, you need to display the Method Call Form (see Display a Form).

The Method Call Form has these tabs:

  • Identification—Use to configure the Identification details (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the Method Call (see Using the User Methods Tab to Define Custom Actions).
  • Method Call—Use to specify the item on which ClearSCADA is to perform an action and the action that ClearSCADA is to use:
  • Method Object—Use to specify the database item on which ClearSCADA is to perform a Method Call.

Select the browse button to display a Reference browse window. Select the required database item from the window.

  • Method—Use to specify the Method (action) that ClearSCADA is to perform on the item that is specified in the Method Object field.

Select the browse button to display the Edit Method window.

Use the Edit Method window to select the method (action) that ClearSCADA is to trigger on the item and, if applicable, specify the values of any arguments that further define the action that is to be taken, or the value(s) that ClearSCADA is to use for the action.

For a list of the arguments that each Method uses and the format that those arguments take, refer to the Database Schema. For information on using the Database Schema, see the ClearSCADA Guide to the Database.

Depending on the type of method, you may also need to specify the particular aggregate and/or type of alarm with which the method is associated.

For information on using the Edit Method window, see Specify a Method.

For information on the type of expression you can specify, see Method Expressions in the ClearSCADA Guide to Expressions.

Once you have confirmed the settings by selecting the OK button on the Edit Method window, the window is closed and any arguments are displayed in parentheses next to the Method name on the Method Call Form.

Example:

The ‘Override’ Method for an analog point has one argument, which you use to specify the value to which ClearSCADA is to override the point.

As such, in the above example, this Override action will result in the point having a value of 22 while the override is in force.

  • Command Alias—Use to optionally define a shorter reference for a Method Call. A Command Alias can optionally be used to trigger a Method Call, instead of the full string that would otherwise be required to identify the method.

To define a Command Alias, specify a string of up to 32 characters in the Command Alias field. Ideally the name of the Command Alias should be indicative of the action that will be triggered when the Method Call is executed.

Each Command Alias:

  • Has to be unique on the system
  • Must not replicate the name of any method, action, or database item on the system (should this occur, the Method Call’s alias will take precedence)
  • Is case sensitive
  • Can contain any combination of alphanumeric characters, spaces, and text symbols supported by the GSM network, other than:

{}| ^ [] \ ~ € ‘’ “”

Example:

A particular Method Call includes this configuration:

A user triggers the Method Call remotely via SMS (Short Message Service) text message. To trigger the Method Call, they enter the Command Alias Switch1Off in the SMS text message. On receipt of the message, ClearSCADA overrides Switch 1 to state 0 (‘Power Off’).

To trigger a Method Call remotely via SMS, your system has to be running the Pager driver and be configured to process incoming SMS text messages. For more information, see the ClearSCADA Guide to the Pager Driver.


Core Configuration Guide - Defining Severities

Defining Severities

Alarms and events each have a severity level (sometimes called a priority) that indicates the importance of that alarm or event in relation to other alarms and events on the system. You specify the severity for each alarm or event by using the Severity field(s) on the relevant configuration Forms. For instance, to specify the severity of any alarms or events that are raised for a channel, you select the required severity from the Severity combo box on the relevant Channel Form.

A set of default severity levels is provided on each ClearSCADA system, but these can be replaced, adjusted, or further entries added, as appropriate to your system.

In some instances, the severity type (alarm or event) is fixed within ClearSCADA, in other cases, you can specify the severity type. This section explains how you:

  • Define the Severity Level when the Type is Fixed
  • Define the Severity Type.


Core Configuration Guide - Define the Severity Level when the Type is Fixed (Defining Severities)

Define the Severity Level when the Type is Fixed

Where the severity type (alarm or event) is fixed within ClearSCADA, a single Severity field is displayed on a Form. Use the Severity combo box to select the severity level that is appropriate to the events and/or alarms associated with that particular item.

(In some instances, separate Severity fields are available for specific alarms or events—see the relevant configuration documentation for details. With Alarm Redirections, two Severity combo boxes are displayed. Use the combo boxes to specify the lowest and highest severity levels that are to trigger an alarm redirection (see Define the Severity Range in the ClearSCADA Guide to Alarm Redirection).)

The default options are:

  • None
  • Low
  • Medium
  • High
  • Critical.

Where ‘None’ indicates that no alarms will be raised, and no events will be logged for an item. The other four options indicate rising levels of severity, with ‘Low’ being the lowest priority and ‘Critical’ being the highest priority.

The default Severity settings can be overwritten by a custom range of priorities. If the default settings have been replaced by a customized range—select the appropriate level of importance. (For information on changing the default settings, see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.)

In either case, a system administrator should define the meaning of each Severity—for instance, the level of importance, or urgency of action that is to be associated with each severity level on a system (see the example below).

NOTE: If the Dictionary feature is used on your system, Severity strings might be prefixed with @, in order for those strings to be replaced with other terms, when displayed in a List or on a Mimic, in ViewX. For more information, see Dictionary Settings in the ClearSCADA Guide to Server Administration.

Example:

A ClearSCADA system uses the default Severity settings. Users could consider the severities to have the following levels of importance and urgency:

  • None—No alarms or events are raised or logged for this item.
  • Low—A low level of importance, usually associated with states that indicate minor abnormal conditions that should not affect the running of the system or safety of staff. Operators should only acknowledge or resolve Low priority alarms and events once they have responded to other priorities of alarm and event.
  • Medium—A medium level of importance, usually associated with states that indicate that ClearSCADA has detected a significant problem. Typically, the problem that ClearSCADA has detected may affect the running of the system, but should not pose a danger to staff or equipment.
  • High—A high level of importance, usually associated with states that indicate that ClearSCADA has detected a major problem. High priority alarms and events typically require a fast user response. Operators should respond to High alarms and events before responding to Medium and Low alarms and events.
  • Critical—The highest level of importance, associated with states that indicate that ClearSCADA has detected a major problem or an emergency situation. Critical alarms and events typically require an immediate response, as they relate may relate to major problems or system events that affect the performance of the system or the safety of the staff.


Core Configuration Guide - Define the Severity Type (Defining Severities)

Define the Severity Type

In some instances, you can define whether ClearSCADA is to log an event or raise an alarm under specific circumstances. For example, you specify whether ClearSCADA is to trigger an alarm or event when a point enters a particular point state. (For more information on configuring point states and alarm limits, see the relevant ClearSCADA configuration documentation.)

You specify whether an alarm or event is to be triggered, by using the Severity fields on the appropriate Form. In this case, two Severity fields are displayed—one to define the type of activity that is to be triggered (for example, an event), and the other to define the priority for that activity.

Use the combo box on the first Severity field to display a list of severity types. Choose the option that you require:

  • None—ClearSCADA does not generate any type of alarm or event when the item enters the relevant state.
  • Event—ClearSCADA generates an event when the item enters the relevant state. Specify the priority of the event by selecting the required priority level from the adjacent combo box.
  • Alarm—ClearSCADA generates an alarm when the item enters the state. Specify the priority of the alarm by selecting the required priority level from the adjacent combo box. This option is not available for the Normal state of a point.
  • Fleeting—This option is only displayed when it is applicable, for example for digital point states. ClearSCADA generates a fleeting alarm when the item enters the relevant state. The fleeting alarm is deleted as soon as it is acknowledged by an engineer or operator. Specify the priority of the alarm by selecting the required priority level from the adjacent combo box.

The second Severity combo box does not display a ‘None’ option, as the box becomes ‘grayed out’ (unavailable) if ‘None’ is selected from the first Severity combo box.

The second combo box’s default options can be overwritten by a custom range of priorities. If the default settings in the second Severity combo box have been replaced by a customized range, select the appropriate level of importance. (For information on changing the default settings, see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.)

NOTE: If the Dictionary feature is used on your system, strings in the second Severity combo box may be prefixed with @, in order for those strings to be replaced with other terms, when displayed in a List or on a Mimic, in ViewX. For more information, see Dictionary Settings in the ClearSCADA Guide to Server Administration.

Example:

The diagrams in this example show how the Severity settings might be configured for a digital point.

For a digital point, use the first Severity combo box to define the activity that is triggered when the point goes into that state...

...then use the second Severity combo box to define the priority of the triggered activity. (In this case, when the point goes into State 0, ClearSCADA raises an alarm that has low priority.)


Core Configuration Guide - Defining the Format of Displayed Values

Defining the Format of Displayed Values

Point values are shown on a variety of displays within ClearSCADA. You can:

  • Define the Format of a Displayed Value
  • Define the Format of the Y-Axis on a Trend
  • Define the Format of a Value on a Mimic.

NOTE: Engineers with programming experience can also use the expression function FORMATVAL to define the format of a value in ClearSCADA (for example, in a Mimic animation). You can include any of the following syntax in the ‘Format String’ argument of the FORMATVAL function: Date and Time Syntax, Numeric Syntax, Text String Syntax, and Boolean Syntax. For more information on the FORMATVAL function, see the ClearSCADA Guide to Expressions.


Core Configuration Guide - Define the Format of a Displayed Value (Defining the Format of Displayed Values)

Define the Format of a Displayed Value

To adjust the appearance of a value on a display such as a Points List, Custom List, Report, or Status display, you define the value’s format using the Format field on the relevant Point Form. For example, you can alter the format of a value displayed in the Value column of a Points List, or the format of Current, Previous, and (where applicable) Logged, End of Period, and State Change values shown in a Status display.

To alter the format of the value, display the Point Form (see Display a Form) and change the format and units for the point value (for points with analog-type processing, see Define the Appearance of an Analog Point’s Values in the ClearSCADA Guide to Core Point Configuration; for points with digital-type processing, see Define the Format of a Digital Point’s Values in the ClearSCADA Guide to Core Point Configuration).

You use the Text Format window to define the value’s format. From within the window, you Choose a Format Category and configure the settings that you require.

Define the format of entries in the Value column of the Points List.

The columns for which you can format the value on, for example, Points Lists, Reports, and Status displays also include any prefix or suffix text, along with any units that are defined for the Point—if you specify more than one of these fields for a point, ensure that they do not duplicate like information.

Define the format of Current and Previous values (and, where applicable, logged, End of Period, and State Change values) in the Status display.


Core Configuration Guide - Define the Format of the Y-Axis on a Trend (Defining the Format of Displayed Values)

Define the Format of the Y-Axis on a Trend

ClearSCADA supports a variety of Trends (see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends).

You use the Text Format window to define the format of a Trend’s y-axis. Using the window, you can Choose a Format Category and configure the settings that you require.

Define the format of entries on the y-axis of a Trend.

To specify the default format of the y-axis on a Trend viewed using the Display Current Trend or Display Historic Trend context sensitive menu options, you use the Format settings on the relevant Point Form (see the ClearSCADA Guide to Core Point Configuration). If a such a Trend is on display while you update the format of the point’s values, re-display the Trend for those changes to be shown. This type of Trend is referred to as an Ad Hoc Trend.

To specify the default format of the y-axis on a pre-configured Trend (a Trend created using a Trend database item), you use the Format settings on the Edit Y Axis window. To apply the format to all new pre-configured Trends, you access the Edit Y Axis window from the ViewX menu bar’s Tools menu (see Define the Default Settings for New Trends in the ClearSCADA Guide to Trends). By default, the y-axis of a pre-configured Trend displays the range of values for the first item for which you add a trace.

With either type of Trend, you can also change the format of the y-axis when viewing the Trend in Edit mode (see Configure a Y-Axis in the ClearSCADA Guide to Trends). Such format changes are only temporary on an Ad Hoc Trend (they only apply while the Trend remains on display). With a pre-configured Trend, the changes only apply to the Trend on which they were implemented—save the configuration if you want to retain the changes and use them in place of the defaults on that particular Trend.


Core Configuration Guide - Define the Format of a Value on a Mimic (Defining the Format of Displayed Values)

Define the Format of a Value on a Mimic

If you insert a database value on a Mimic by using the Animation Wizard, or by dragging a database item onto a Mimic (see the ClearSCADA Guide to Mimics), its format is inherited from the relevant configuration for that item.

For instance, if you display the value of an analog point on a Mimic, you define the value’s format using the Format field on the Analog Point Form (see Define the Appearance of an Analog Point’s Values in the ClearSCADA Guide to Core Point Configuration).

Whenever the item’s configuration is updated, or the Mimic is re-displayed, ClearSCADA re-applies the configuration properties, such as the formatting, to the entry on the Mimic.

Define the format of values on Mimics

You can configure a value on a Mimic so that its format differs to that defined in the database for that item. For example, if a value inherits its format from a point, you might choose to remove the value’s Format animation, then configure independent format settings for that value (see the ClearSCADA Guide to Mimics). You use the Text Format window to define the new format for the value (see Choose a Format Category).

If you temporarily override a value’s format on a Mimic without removing its animated property, any format settings for that value on the Mimic are overridden by the format defined in the database as soon as you re-display the Mimic, or update the item’s configuration in any way.

ATTENTION: When adjusting the format of an existing point, and the value for that point is displayed on a Mimic, ensure that the value field on the Mimic is large enough to include any formatting changes. For example, the addition of postfix or prefix text.
If the additional information overflows the available area on the Mimic, you will have to adjust the area accordingly.


Core Configuration Guide - Choose a Format Category (Defining the Format of Displayed Values)

Choose a Format Category

The Text Format window displays a list of format categories. You can choose a suitable category to:

  • Apply Default Formatting to a Value
  • Define How a Numeric Value is Displayed
  • Define How a Date and Time are Displayed
  • Define How a Time Period is Displayed
  • Define How a Boolean Value is Displayed
  • Define a Custom Value Format.


Core Configuration Guide - Apply Default Formatting to a Value (Defining the Format of Displayed Values)

Apply Default Formatting to a Value

Use the General format category when a value requires no particular formatting other than the default. For instance, a whole number is automatically displayed without any decimal places. If this is acceptable, and no other specific formatting is required, then choose the General category.

The Sample area of the Text Format window displays an example of how the value will appear on Lists, Trends, and Mimics, and so on.


Core Configuration Guide - Define How a Numeric Value is Displayed (Defining the Format of Displayed Values)

Define How a Numeric Value is Displayed

Select the Number category when a numeric value requires a format other than the default. For instance, if you want an analog value to display a particular number of decimal places.

Define any formatting requirements using the fields that are available below the Sample area of the window. The example in the Sample area updates as you define the format, to show how the value will appear on Lists, Trends, and Mimics, and so on.

Use any combination of these fields to define the required format:

  • Decimal Places—Use the spin box to specify the number of places that are to be displayed after the value’s decimal point.

If the value supplied to ClearSCADA has more than the defined number of decimal places, values are rounded down (when the next figure is 4 or below), or up (when the next figure is 5 or above).

Example:

A point is configured to display only two decimal places. When its value is 1.234, ClearSCADA displays the value as 1.23. The value changes to 1.237, and ClearSCADA displays the new value as 1.24.

  • Trailing Zeros—If you want the displayed value to show a set number of digits after the decimal place, regardless of whether the value supplied to ClearSCADA uses that number of digits, use this spin box to define the number of zeros that should be displayed after the decimal point, if no other value is available.

The Trailing Zeros field works in conjunction with the Decimal Places field, such that you cannot define more trailing zeros than there are decimal places.

Example:

A point is configured to display three decimal places, but only two trailing zeros.

When the point’s value is 1.234, ClearSCADA displays the value as 1.234.
The value changes to 1, and ClearSCADA displays this new figure as 1.00.
The value changes to 1.2 and ClearSCADA displays the new figure as 1.20.

ClearSCADA ‘pads out’ the value to always show a minimum of two digits after the decimal point.

  • Prefix—Use the prefix field to enter any text that you want to display immediately in front of the point value. Insert a character space at the end if you want a space between the prefix text and the point value.

Prefix text appears wherever the value is displayed on Lists, Mimics, or Trends.

ATTENTION: When adding prefix text to an existing point, ensure that the value field on any existing Mimics is large enough to include the additional text.

NOTE: The columns for which you can format the value on, for example, Points Lists, Reports, and Status displays also include any prefix or suffix text, along with any units that are defined for the Point—if you specify more than one of these fields for a point, ensure that they do not duplicate like information.

  • Postfix—Use the postfix field to enter any text that you want to display immediately after the point value. Insert a character space if you want a space between the value and any postfix text.

Postfix text appears wherever the value is displayed on Lists, Mimics, or Trends.

ATTENTION: When adding postfix text to an existing point, ensure that the value field on any existing Mimics is large enough to include the additional text.

NOTE: The columns for which you can format the value on, for example, Points Lists, Reports, and Status displays also include any prefix or suffix text, along with any units that are defined for the Point—if you specify more than one of these fields for a point, ensure that they do not duplicate like information.

  • Use 1000 Separator—Select this check box if you want any values over 1000 for this point to display a comma to separate each thousand. Ensure the check box is clear if you do not want separators to be displayed for values of 1000 and above.

Example:

No separator is configured for a point, for which the value 2312 is displayed on a Mimic. When a separator is defined for the point, and the configuration change saved, the Mimic displays the value as 2,312.

  • Scientific—Select this check box if you want to display the point value in scientific format. Leave the check box clear for the value to be displayed in standard notation. This option is useful for displaying large values in a concise format.

Example:

A point displays its value using standard notation. The present point value is 123.457. The notation is altered to scientific and the configuration change saved. The same value is now displayed as 1.235E+02.


Core Configuration Guide - Define How a Date and Time are Displayed (Defining the Format of Displayed Values)

Define How a Date and Time are Displayed

NOTE: The Date/Time category does not apply to Trend y-axes.

Select the Data/Time category when a time period requires a format other than the default. For instance, if you want to display a date in a format other than that defined by the user regional settings, or the default user date settings. (For information on configuring a user’s regional date settings, see Define the Regional Settings for a User in the ClearSCADA Guide to Security).

Scroll down the Type field and select the required date or time format.

The example in the Sample area updates to show how the value will appear on Lists, Trends, and Mimics, and so on.

If you require a format that is not available from the Date/Time category, configure a suitable Custom option (see Define a Custom Value Format).


Core Configuration Guide - Define How a Time Period is Displayed (Defining the Format of Displayed Values)

Define How a Time Period is Displayed

Select the Interval category when a time period requires a format other than the default of raw seconds. For instance, if you want a time period to display in hours, minutes and seconds.

Select the required format from the list in the Type field.

The example in the Sample area updates to show how the value will appear on Lists, Trends, and Mimics, and so on.

There are no custom Interval formats.


Core Configuration Guide - Define How a Boolean Value is Displayed (Defining the Format of Displayed Values)

Define How a Boolean Value is Displayed

Select the Boolean category to use a format that is the Boolean (True or False) equivalent of a numeric value. For instance, if you want to display the value of a 1-bit digital point (0 or 1) as the text ‘F’ or ‘T’.

Any non-zero numeric value is treated as a Boolean ‘True’.

Select the required format from the list in the Type field.

The example in the Sample area updates to show how the value will appear on Lists, Trends, and Mimics, and so on.


Core Configuration Guide - Define a Custom Value Format (Defining the Format of Displayed Values)

Define a Custom Value Format

If you require a value format that is not available from the other categories, you can define a custom format. For example if you want a number that always appears as a fraction to display a leading zero before the decimal point. You can define custom number, date or time formats using the Custom category.

To define a custom format, either:

  1. Select the Custom category.
  2. Enter the required custom code in the Custom field (see Date and Time Syntax, Numeric Syntax, Text String Syntax, or Boolean Syntax as appropriate).

or:

  1. Select another category (such as Number, or Date/Time).
  2. Select a format from this category, which is similar to the custom entry you require.
  3. Select the Custom category.
    The Custom field displays the last ‘standard’ format that you selected prior to selecting the Custom category.
  4. Alter the existing code to your requirements (see Date and Time Syntax, Numeric Syntax, Text String Syntax, or Boolean Syntax as appropriate).

ATTENTION: Be aware that any custom format will automatically be lost should a standard format be selected at any time. If a standard format is accidentally selected in the Text Format window, select the Cancel button, to avoid losing the custom format. The Text Format window can then be re-displayed if the custom format requires further configuration.


Core Configuration Guide - Date and Time Syntax (Defining the Format of Displayed Values)

Date and Time Syntax

The syntax for date and time formats is given below. You can display many formats, such as days, months, and years, in full or in truncated form, depending on the number of times that you enter a particular code character—details are given below.
Code | Description | Appearance | Example
‘ | Insert a single quote at start and end of any string to indicate plain text. |  |
“ | Single quote, entered twice |  | ‘
a | AM/PM indicator | text | AM
d | Day in month (minimum number of digits displayed) | number | 9
dd | Day in month (two digits always displayed) | number | 09
D | Day in year (minimum number of digits displayed) | number | 5 (for fifth day in the year) 156 (for 156th day)
DDD | Day in year (three digits always displayed) | number | 005 (for fifth day in the year) 156 (for 156th day)
EEE | Day in week (first three characters displayed) | text | Wed (for ‘Wednesday’)
EEEE | Day in week (full text) | text | Wednesday
F | Day of week in month (minimum number of digits displayed) | number | 2 (for second week in the month)
FF | Day of week in month (two digits always displayed) | number | 02 (for second week in the month)
G | Era | text | AD
h | Hour in 12-hour clock (1 to 12) (minimum number of digits displayed) | number | 8 12
hh | Hour in 12-hour clock (1 to 12) (two digits always displayed) | number | 08 12
H | Hour in 24-hour clock (0 to 23) (minimum number of digits displayed) | number | 7 18
HH | Hour in 24-hour clock (0 to 23) (two digits always displayed) | number | 07 18
k | Hour in day (24-hour clock, 1 to 24) (minimum number of digits displayed) | number | 5 23
kk | Hour in day (24-hour clock, 1 to 24) (two digits always displayed) | number | 05 23
K | Hour in day (12-hour clock, 0 to 11) (minimum number of digits displayed) | number | 3 10
KK | Hour in day (12-hour clock, 0 to 11) (two digits always displayed) | number | 03 10
m | Minute in hour (minimum number of digits displayed) | number | 4 30
mm | Minute in hour (two digits always displayed) | number | 04 30
M | Month in year (minimum number of digits displayed) | number | 6 (for June)
MM | Month in year (two digits always displayed) | number | 06 (for June)
MMM | Month in year (truncated) | text | Aug (for ‘August’)
MMMM | Month in year (full text) | text | August
s | Second in minute (minimum number of digits displayed) | number | 5 24
s | Second in minute (two digits always displayed) | number | 05 24
S | Deciseconds (one digit displayed) | number | 0 3
SS | Centiseconds (two digits always displayed) | number | 01 32
SSS | Milliseconds (three digits always displayed) | number | 016 327
w | Week in year (minimum number of digits displayed) | number | 5 32
ww | Week in year (two digits always displayed) | number | 05 32
W | Week in month | number | 3
yy | Year (truncated to display last two digits only) | number | 03
yyyy | Year (all four digits) | number | 2003
z | Time zone | text | GMT+01:00

Examples:

The code d.M.yy displays a date in the form 14.2.03

The code dd.MM.yy displays a date in the form 14.02.03

(where entries are zero-padded if the figures are shorter than the specified amount of characters.)

The code EEE, MMM d, “yy displays a date in the form

Fri, Feb 14, ‘03

The code EEEE, MMMM d, yyyy displays a date in the form

Friday, February 14, 2003

The code ‘Today’’s date is: ‘EEEE, d MMMM displays

Today’s date is: Friday, 14 February


Core Configuration Guide - Numeric Syntax (Defining the Format of Displayed Values)

Numeric Syntax

The syntax for numeric values is given below.
Code | Description
. | Decimal point
, | Separator (for instance to separate 1000s)
‘ | Insert a single quote at start and end of any string to indicate plain text
% | Multiplies the value by 100 and displays it as a percentage
E | Use in scientific notation to separate the mantissa and the exponent (for example, #E+00)
# | A digit (omitted if zero)
0 | A digit (still displayed, even if the value is zero)

Examples:

Using the syntax #,### results in the value 1000000 being displayed as 1,000,000 (the separator automatically repeats for each occurrence of three digits—there is no need to include a further separator)

Using the Custom syntax 0E0 results in the value 900 being displayed as 9E2

A value formatted using a Number category format with two digits after the decimal place appears as .75

To display a leading zero before the decimal point, use the custom syntax 0.## (or 0.00 to always display two digits after the decimal place)

The value then appears as 0.75

Using the Custom syntax #% results in the value 0.75 being displayed as 75%

The Custom syntax ‘Weight: ‘ 0.## results in the value 0.75 being displayed as
Weight: 0.75.


Core Configuration Guide - Text String Syntax (Defining the Format of Displayed Values)

Text String Syntax

The syntax for text strings is given below:
Code | Description
> | Forces the whole string to appear in upper case
< | Forces the whole string to appear in lower case

Examples:

The syntax > is used to force the incoming string value ‘Xerox 123’ to be displayed within ClearSCADA as ‘XEROX 123’.

The syntax < is used to force the incoming string value ‘Printer TRAY 5’ to be displayed within ClearSCADA as ‘printer tray 5’.


Core Configuration Guide - Boolean Syntax (Defining the Format of Displayed Values)

Boolean Syntax

You typically assign a Boolean format by selecting the required entry from the Boolean Format category (see Define How a Boolean Value is Displayed). Alternatively, you can specify any of the following syntax.

As with any of the custom syntax listed in this section, you can also use Boolean syntax in the expression function FORMATVAL (see the ClearSCADA Guide to Expressions).

ClearSCADA supports this syntax for Boolean values:
Code | Example
t | t
T | F
tt | true
Tt | False
TT | TRUE


Core Configuration Guide - Requesting Confirmation of Action Requests

Requesting Confirmation of Action Requests

For several operator actions within ClearSCADA, you can specify whether an operator has to confirm an action that they have requested, before that action is carried out. This confirmation feature provides an additional checking mechanism for certain operator-driven actions, and helps to ensure that only genuinely requested actions are carried out on the system.

Additionally, you can also specify whether an operator has to confirm their logon password before an action is carried out. Use this option where additional security is required when controlling plant.

You can also specify whether the Notes window is displayed automatically when an action request is selected. Use this option when, for example, you want to display operating instructions for certain items of plant, or require operators to note down the reasons for performing certain actions.

Actions for which a combination of confirmation messages, notes and passwords can be requested include controls, overrides, and point initialization.

Use the relevant Confirm combo box on the appropriate configuration Form to specify what activities are to occur whenever an operator requests a particular action:

Choose the required option:

  • Always—A confirmation dialog box is always displayed when the pick action is selected (see Action Requests that Require Confirmation).
  • Always w/Password—A confirmation dialog box is always displayed when the pick action is selected. Once the request has been confirmed, the Confirm Password window is displayed, requiring confirmation of the user’s logon password before ClearSCADA performs the action request (see Action Requests that Require Password Confirmation).
  • Always w/Notes—A confirmation dialog box is always displayed when the pick action is selected. Once the request has been confirmed, the Notes window is displayed (see Action Requests that Display Notes).
  • Always w/Notes + Password—A confirmation dialog box is always displayed when the pick action is selected. Once the request has been confirmed, the Notes window is displayed, followed by the Confirm Password window (see Action Requests that Require Password Confirmation).
  • Per User—A confirmation dialog box is displayed when the pick action is selected and the Confirm Controls & Overrides option is set for the logged on user. Confirm Controls & Overrides is defined on a per user basis, using the User Form (see Creating a User Account in the ClearSCADA Guide to Security).

For the built-in Guest user account, you can define the Confirm setting on a per client basis. To define the Confirm setting for the Guest user on a specific client, you need to access the Options window (that can be selected from the Tools menu) on that client. For more information, see Define the Client Specific Settings for the Guest User in the ClearSCADA Guide to Security.

For the built-in Web user account, you can define the Confirm setting on a per server basis. To define the Confirm setting for the Web user on a specific server, you need to access the Form of the system (Root Group). For more information, see Define the Global Settings for All Guest and Web User Accounts in the ClearSCADA Guide to Security.

  • Per User w/Password—A confirmation dialog box is displayed when the pick action is selected and the Confirm Controls & Overrides option is set for the logged on user (see the ‘Per User’ option above for more details). Following this, the Confirm Password window is displayed, requiring confirmation of the user’s logon password before ClearSCADA performs the action request (see Action Requests that Require Password Confirmation).
  • Per User w/Notes—A confirmation dialog box is displayed when the pick action is selected and the Confirm Controls & Overrides option is set for the logged on user (see the ‘Per User’ option above for more details). Following this, the Notes window is displayed (see Action Requests that Display Notes).
  • Per User w/Notes +Password—A confirmation dialog box is displayed when the pick action is selected and the Confirm Controls & Overrides option is set for the logged on user (see the ‘Per User’ option above for more details). Following this, the Notes window is displayed, followed by the Confirm Password window (see Action Requests that Require Password Confirmation).
  • Never—A confirmation dialog box is not displayed when the pick action is selected.


Core Configuration Guide - Action Requests that Require Confirmation (Requesting Confirmation of Action Requests)

Action Requests that Require Confirmation

Where operator confirmation is specified, a confirmation dialog box is displayed whenever the action is selected.

Example:

The Override feature for a particular digital point, named ‘Switch 1’, is configured such that confirmation is always required whenever an operator requests the Override pick action.

An operator selects the Override pick action and specifies that the point is overridden to the state ‘Power Off’.

A confirmation dialog box is displayed as soon as the request is sent:

The server only activates the override request once the operator selects the ‘Yes’ button on the confirmation dialog box.

If the operator has selected the Override pick action unintentionally, the operator can cancel the Override request by selecting ‘No’ rather than ‘Yes’, on the confirmation dialog box.


Core Configuration Guide - Action Requests that Require Password Confirmation (Requesting Confirmation of Action Requests)

Action Requests that Require Password Confirmation

For action requests that require password confirmation, once the request has been selected and (if required) confirmed, the Confirm Password window is displayed, requiring confirmation of the user’s logon password before ClearSCADA performs the action request. This provides additional security when controlling vital items of plant.

If the user’s logon password is not entered correctly, the action request is aborted.

For action requests that are configured to display the Notes window (see Action Requests that Display Notes), Notes are displayed before the Confirm Password window is displayed.


Core Configuration Guide - Action Requests that Display Notes (Requesting Confirmation of Action Requests)

Action Requests that Display Notes

For action requests that are configured to display Notes, once the request has been selected and (if required) confirmed, the Notes window is displayed. The window allows, for example, operators to view instructions or information regarding the action request, or to enter their own information regarding the request.

In order for the Notes window to be displayed, the operator’s User Account has to be assigned both the Read and Edit Notes security permissions for the item on which the action is being performed.

The operator needs to select the OK button once the information has been read or inserted in the Notes window, whereupon ClearSCADA performs the request.

For more information on using the Notes window, see Notes in the ClearSCADA Guide to ViewX and WebX Clients.


Core Configuration Guide - Using Parameters to Store Static Data Values

Using Parameters to Store Static Data Values

ClearSCADA supports a series of Parameters that can be used to store static data values, such as a postal address, or map grid reference. Consider using Parameters if the data that you want ClearSCADA to store is:

  • Intended to remain static
  • Internal to ClearSCADA (it is not associated with plant)
  • Not directly associated with other items in the database (such as individual points, outstations, or scanners).

You can use Parameters, for example:

  • To display static data on Mimics, or in Reports.
  • To store static data used in Logic programs—for example, store the target value for an analog point.
  • As an alternative to ‘custom’ fields. (Unlike custom fields, when you add a new Parameter to ClearSCADA, you do not need to restart the server.)

Unlike Variables or Internal Points, users need the Configure permission, rather than the Control permission, to change a Parameter’s value. This provides additional security to help ensure that data that is intended to remain static is only changed by users with that permission.

This section:

  • Summarizes the different Types of Parameter that ClearSCADA supports.
  • Explains the circumstances that determine when you would use a Parameter rather than a Variable or other database item (see Parameters versus Points and Variables).

It also explains how to:

  • Add a Parameter
  • Configure a Parameter.

Also included is a series of examples that demonstrate how Parameters might be used on a ClearSCADA system (see Example Configuration).


Core Configuration Guide - Types of Parameter (Using Parameters to Store Static Data Values)

Types of Parameter

ClearSCADA supports these types of Parameter:

Type of Parameter

Description

Address

Use this type of Parameter to store a postal address of up to four lines, including the postal code.

Double

Use this type of Parameter to store a double-precision floating point number. The number is not expected to change once it has been configured in the database.

(ClearSCADA also supports Double and Constant Double Variables. The type of double that you add to ClearSCADA depends on the double’s intended functionality. (You might use a Constant Double Variable, rather than a Double Parameter, for instance, if you want to exclude such data from being exported to another ClearSCADA system.) For more information, see Parameters versus Points and Variables.)

Grid Reference

Use this type of Parameter to store an Ordnance Survey (OS) map grid reference.

Link

Use this type of Parameter to store a hyperlink to an item in the ClearSCADA database.

Consider using Link Parameters, for example, if the Mimics on your system are produced using a series of Group Templates, and you want users to be able to navigate between those Mimics (see Use Link Parameters to Enable the Instances of a Mimic to Reference Different Locations).

Parameter Table

Use this type of Parameter to store up to four text strings. The string content is expected not to change once it has been configured in the database.

String

Use this type of Parameter to store a single text string. The text string is expected not to change once it has been configured in the database.

(ClearSCADA also supports String Points and String Variables. The type of string that you add to ClearSCADA depends on the string’s intended functionality. For more information, see Parameters versus Points and Variables.)

In general, use Parameters as opposed to Variables if the data values that you want ClearSCADA to store are expected to remain static. For more information, see Parameters versus Points and Variables.

Further Information

Configure a Parameter.


Core Configuration Guide - Parameters versus Points and Variables (Using Parameters to Store Static Data Values)

Parameters versus Points and Variables

When configuring a ClearSCADA system, be aware that ClearSCADA can store some types of data as Point data, Variable data, or Parameter data. For example, ClearSCADA can store analog data in the form of an Analog Point, Double Variable, or a Double Parameter. The type of database item that you should use to store the data depends on how that data is intended to be used in ClearSCADA. (Point data, Variable data, and Parameter data can all be used in reports and be accessed by other applications that interrogate ClearSCADA.)

Be aware that you can also store ‘custom’ data in extra fields that you can add to configuration Forms, or otherwise to the database items on your system. For information on adding such ‘custom’ fields, see Extra Database Fields in the ClearSCADA Guide to Server Administration. Consider using custom fields if the data varies on a per item basis; consider using Parameters if the data is not database item-specific.

The rest of this section summarizes these three types of database item and their intended functionality in ClearSCADA:

  • Points
  • Variables
  • Parameters.


Core Configuration Guide - Points (Using Parameters to Store Static Data Values)

Points

Most drivers support a variety of Points. For each input or output value that is associated with plant, you need to create and configure a point of the appropriate type in the ClearSCADA database. For instance, if your ClearSCADA system communicates with outstations using the DNP3 protocol, you would add a DNP3 Point of the appropriate type to your system and associate that point with the input or output data on the relevant DNP3 outstation or other DNP3 device.

You can also add internal points to your system. Such points are not associated with plant, but instead only exist within the master station software. You can use internal points, for example, within Logic programs, or to simulate plant (see Internal Points in the ClearSCADA Guide to Core Point Configuration). Create and configure an internal point on your system if you require such values in the ClearSCADA database and you require any of the following:

  • Alarm and/or event functionality that is typically associated with points, including the ability to:
  • generate point alarms and events
  • redirect alarms
  • associate the point with an Alarm View
  • use alternative Alarm Source name for the point.
  • The ability to override the point’s value
  • The ability to format the point’s value for use in ClearSCADA displays (for instance, force an analog’s value to include a set number of decimal places, whenever that value is displayed in Lists and reports).

For more information on points, see the ClearSCADA Guide to Core Point Configuration.

For driver-specific information on points, see the relevant driver guides.


Core Configuration Guide - Variables (Using Parameters to Store Static Data Values)

Variables

You can use some types of Variable in a similar way to internal Points. Like internal points, Variables only exist within the master station software. You can use Variables in Logic programs, Value Maps, and so on. However, unlike internal points, Variables do not have the additional ‘overheads’ associated with points, such as the ability to generate events or alarms.

Create and configure a Variable on your system if you require:

  • a value that is not associated with plant
  • a value that does not need any of the ‘overheads’ associated with internal points (see the bullet list in the Points section, above)
  • a value that can be changed when required, including, if need be, on a scheduled basis. (Unlike Parameters, most Variables support the Set Value pick action and method, allowing the Variable’s value to be changed quite readily.)
  • a value that does not require exporting to, or importing from, another ClearSCADA database. (Unlike Parameters, Variables are stored as data, rather than configuration, and as such are not included in .sde export or import files.)

Consider using an Array Variable, rather than a single-value Variable, if a series of values are required.

For more information on Variables and Variable arrays, see Using Variables to Store Data Values.

A Variable’s value is expected to change. You can view the present values of the Variable(s) on your system using the Variables List. You can also view an individual Variable’s value and last update time on that Variable’s Status display...
...unlike a Parameter’s value, which is expected to remain static.


Core Configuration Guide - Parameters (Using Parameters to Store Static Data Values)

Parameters

Parameters are stored as configuration in the ClearSCADA database. Parameters are intended to store static values and can be used as an alternative to custom fields.

Create and configure a Parameter on your system if you require:

  • a value that is not associated with plant
  • a value that does not need any of the ‘overheads’ associated with internal points (see the bullet list in the Points section, above)
  • a value that is intended to remain static (for instance, a string that displays the name of a particular geographical location)
  • a value that can be imported from, or exported to, another ClearSCADA database. (Unlike Variables, Parameters are stored as configuration, and can therefore be exported or imported from one ClearSCADA database to another.)

If using String Parameters, consider using a Parameter Table, rather than a series of String Parameters, if a set of up to four String Parameters is required.

Further Information

Types of Parameter.

Add a Parameter.

Configure a Parameter.

Example Configuration.

Importing and Exporting Database Items.


Core Configuration Guide - Add a Parameter (Using Parameters to Store Static Data Values)

Add a Parameter

To add a Parameter to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a new Parameter.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Parameter option.
    A further menu is displayed.
  4. Select the required option from the list.
  5. A Parameter of the corresponding type is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  6. Enter a suitable name for the Parameter (taking into account the ClearSCADA Naming Restrictions).
  7. Press the Enter key or select another part of the ViewX interface to confirm the entry.

Once you have added a Parameter, you need to configure its properties (see Configure a Parameter).


Core Configuration Guide - Configure a Parameter (Using Parameters to Store Static Data Values)

Configure a Parameter

To configure a Parameter, you need to display the Parameter’s Form (see Display a Form).

Each Parameter Form has these tabs:

  • Identification—Use to optionally define a Help View and to indicate whether the Parameter is to be excluded from any Exclusive Control activity (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the Parameter (see Using the User Methods Tab to Define Custom Actions).

Each Form also has a <Parameter Type> tab that you use to configure the parameter(s) attributes. The tab varies, depending on the type of Parameter that you are configuring:

  • Use the Address tab to Specify a Postal Address
  • Use the Double tab to Specify a Double-Precision Floating Point Number
  • Use the Grid Reference tab to Specify an Ordnance Survey Grid Reference
  • Use the Link tab to Specify the Database Item that a Link Parameter is to Reference
  • Use the Parameter Table tab to Specify the String Parameters that a Parameter Table is to Store
  • Use the String tab to Specify a Single String Parameter.


Core Configuration Guide - Specify a Postal Address (Using Parameters to Store Static Data Values)

Specify a Postal Address

Use the Address tab on an Address Parameter’s Form to specify the postal address that the Parameter is to store.

The address can comprise up to four lines, including the Region (for instance, a county or state) and the Postal Code.

The Address 1, Address 2, and Region fields can each comprise up to 64 alphanumeric characters, including spaces.

The Postal Code can comprise up to 20 alphanumeric characters, including spaces.


Core Configuration Guide - Specify a Double-Precision Floating Point Number (Using Parameters to Store Static Data Values)

Specify a Double-Precision Floating Point Number

The Double Parameter Form includes a Double tab.

Use the Double field on the Double tab to specify the IEEE double-precision (64-bit) floating point number that the Parameter is to store.

You might, for example, use a Double Parameter to store the target value for one or more analog points, and include that target value in a series of Logic programs. Such configuration is particularly useful on systems in which Logic program(s) are included in Group Templates, and the target value differs in some Instances of those program(s).


Core Configuration Guide - Specify an Ordnance Survey Grid Reference (Using Parameters to Store Static Data Values)

Specify an Ordnance Survey Grid Reference

The Grid Reference Parameter Form includes a Grid Reference tab.

Use the Grid Reference fields on the tab to specify the Ordnance Survey® map grid reference. (The Ordnance Survey is Great Britain’s national mapping agency.)

Use the left-hand field to specify the Ordnance Survey (OS) sheet reference.

Use the center field to specify the Eastings (the distance east from the sheet reference’s origin, in kilometers).

Use the right-hand field to specify the Northings (the distance north from the sheet reference’s origin, in kilometers).

Example:

The Landranger series of maps are divided into 100km squares.

The OS Grid Reference for the town of Coventry, England is SP 335 785, where:

  • SP is the identifier of the 100km square that includes Coventry.
  • 335 is the Eastings (taken from the numbers that run from west to east across the map). In this example, the reference indicates that the center of Coventry is 33.5km east of the SP square’s origin.
  • 785 is the Northings (taken from the numbers that run from south to north up the side of the map). In this example, the reference indicates that the center of Coventry is 78.5km north of the SP square’s origin.


Core Configuration Guide - Specify the Database Item that a Link Parameter is to Reference (Using Parameters to Store Static Data Values)

Specify the Database Item that a Link Parameter is to Reference

Use the Link tab on a Link Parameter’s Form to specify the ClearSCADA database item that the Parameter is to reference.

To specify the item, select the browse button to the right of the Object field. A Reference browse window is displayed. Select the required database item from the window.

You can use a Link Parameter to reference any item in the database. For an example that demonstrates how you might use Link Parameters in ClearSCADA, see Use Link Parameters to Enable the Instances of a Mimic to Reference Different Locations.


Core Configuration Guide - Specify the String Parameters that a Parameter Table is to Store (Using Parameters to Store Static Data Values)

Specify the String Parameters that a Parameter Table is to Store

Use Parameter Tables to store up to four interconnected strings. To store only single strings, consider using String Parameters (see Specify a Single String Parameter).

This section describes the fields on the Parameter Table tab of the Parameter Table Form.

Use the four Parameter fields on the tab to specify up to four strings that the Parameter Table is to store.

In each field, you can specify an alphanumeric string of up to 128 characters, including spaces.

Example:

On a particular ClearSCADA system, Parameter Tables are used to store three strings. The strings specify a site name, an operator name, and a contact number.

The system is configured to display the parameters on the relevant Mimics and reports.


Core Configuration Guide - Specify a Single String Parameter (Using Parameters to Store Static Data Values)

Specify a Single String Parameter

Use String Parameters to store single strings. To store several interconnected strings, consider using Parameter Tables (see Specify the String Parameters that a Parameter Table is to Store).

This section explains the fields on the String tab of the String Parameter Form.

Use the String field on the tab to specify the text string that the Parameter is to store.

The string can comprise any combination of alphanumeric characters, up to a maximum length of 254 characters.

For an example that demonstrates how you might use a String Parameter in ClearSCADA, see Use String Parameters to Enable the Instances of a Mimic to Display Different Information.


Core Configuration Guide - Example Configuration (Using Parameters to Store Static Data Values)

Example Configuration

This section comprises examples that demonstrate how Parameters might be used on
a ClearSCADA system. The examples are by no means intended to be exhaustive—Parameters can be used in numerous ways in ClearSCADA.

This section contains these examples:

  • Use String Parameters to Enable the Instances of a Mimic to Display Different Information
  • Use Link Parameters to Enable the Instances of a Mimic to Reference Different Locations.


Core Configuration Guide - Use String Parameters to Enable the Instances of a Mimic to Display Different Information (Using Parameters to Store Static Data Values)

Use String Parameters to Enable the Instances of a Mimic to Display Different Information

This example demonstrates how you can use String Parameters on a Mimic that is in a Template, in order to allow each Instance of that Mimic to display different information.

Example:

The database on a particular ClearSCADA system has a ‘modular’ structure that has been configured using a series of Group Templates and Group Instances.

Each area of the system is defined as a different ‘zone’. A Group Template is used to define the ‘base’ content of a single zone—the configuration is then replicated in all of the Instances of that Template, with one Instance for each zone.

The Template includes a series of Mimics that provide various pictorial representations of the plant in a single zone. A heading is included on each Mimic, to identify the zone to which it relates. The heading is configured as a String Parameter. The same String Parameter is used on all of the Mimics in the Template. This enables users with the Configure permission to specify the zone name just once in each Instance, in order for all of the Mimics in that Instance to display that name.

In the Group Template, a ‘dummy’ string is specified in the String Parameter’s String field.

In the Template, a ‘dummy’ string is stored in the String Parameter. The string is worded such that it prompts users to replace its content with the relevant zone name, in each Instance of that Parameter.

The String Parameter is embedded on each of the Mimics in the Template:

The String Parameter is embedded on each Mimic in the Template, by dragging its Database Bar entry onto the Mimic...
...and specifying the String option on the pop-up menu that is displayed.
This results in each Mimic displaying the String that the String Parameter is configured to store.

The Properties feature is used to suitably configure the entry on each Mimic in the Template (color, font, and so on).

As no action is required when users select the string on the Instances of each Mimic, the Pick Action Wizard is used to set the action to None.

In this particular case, the String Parameter’s foreground and background colors are to remain static, and so the Animations window is used to remove any FillColour, and Blink animations.

By default, the text string that the String Parameter stores is inherited from the Group Template. In order for the string to be configurable on a per-Instance basis, the Group Template’s Property Overrides features is then used to select the String property of the String Parameter, so that it displays a check mark. This enables the property to be overridden locally, in each Instance.

In order to enable users with the Configure permission to specify a different text String in each Instance, the Group Template’s Property Overrides feature is used to mark the String Parameter’s String property as locally overridden.

In each Instance of the Template, engineers that have the Configure permission then replace the String Parameter’s ‘dummy’ String with the required entry. This is done once per Instance, via each Instance’s String Parameter Form. This results in all occurrences of that string being updated on all of the Mimics in that Instance.

Replacing the String content just once per Instance...
...results in all occurrences of that String being updated on all of the Mimics in that Instance.

Further Information

Group Templates and Group Instances.

Add a Parameter.

Specify a Single String Parameter.

Mimics, Mimic Properties, the Animations window, and the Pick Action Wizard: see the ClearSCADA Guide to Mimics.

Understanding the Property Overrides Window.


Core Configuration Guide - Use Link Parameters to Enable the Instances of a Mimic to Reference Different Locations (Using Parameters to Store Static Data Values)

Use Link Parameters to Enable the Instances of a Mimic to Reference Different Locations

This example demonstrates how you can use Link Parameters on a Mimic that is in a Template, in order to allow each Instance of that Mimic to reference different locations.

Example:

The database on a particular ClearSCADA system has a ‘modular’ structure that has been configured using a series of Group Templates and Group Instances.

Each area of the system is defined as a different ‘zone’. A Group Template is used to define the ‘base’ content of a single zone—the configuration is then replicated in all of the Instances of that Template, with one Instance for each zone.

The Group Template includes a Mimic that provides a pictorial overview of the plant in the zone. To aid navigation, hyperlinks are included on the Mimic, to enable users to access the overviews of the previous and next zones on the system. The hyperlinks are configured as Link Parameters. This enables much of the Mimic configuration of the hyperlinks to be specified only once, in the Group Template.

‘Buttons’ on the overview Mimic are used to link to the previous and next zones’ overview Mimics. Both of these buttons are configured using Link Parameters, as the location of the Mimic to which each button links varies on a per-Instance basis.
Other ‘buttons’ that link to detailed Mimics within the same zone do not need associating with Link Parameters, as the relative paths used by those buttons do not change on a per-Instance basis.

Two Link Parameters are added to the database—one to store the hyperlink for the previous zone’s overview, and another to store the hyperlink for the next zone’s overview.

In the Group Template, a ‘dummy’ location is specified in each Link Parameter’s Object field:

In this particular example, the ‘dummy’ location that is specified is a hyperlink to a Mimic. The Mimic informs engineers of the properties they need to configure in each Instance of the Group Template.

It is intended that engineers will replace the ‘dummy’ links with the actual links that are required, in each Instance of the Link Parameters, once configuration of the Mimic in the Template is complete (see toward the end of this example).

Each Link Parameter is embedded on the overview Mimic in the Group Template:

Each Link Parameter is added to the Mimic as a Hyperlink.

The Properties feature is used to suitably configure each entry on the Mimic (text, fill color, ToolTip, and so on). (The Properties window is displayed by double-clicking on each Link Parameter’s entry on the Mimic.)

The Animations feature is used to specify each Link Parameter’s Hyperlink property as the required PickParam entry:

Each Link Parameter’s Hyperlink property is specified as the PickParam expression. No other animations are used (any others that exist are removed).
(To display the Animations window, double-click on the item that you are configuring on a Mimic, and then select the Animations button from the Property window’s General tab.)

By default, the Object field on each Link Parameter Form’s Link tab is ‘grayed out’ and unavailable for configuration in each Instance of the Template. To enable the contents of this field to be configured on a per-Instance basis, the Template’s Property Overrides feature is used to select the Link tab’s ObjectID property as locally overridden. This is not done until each Link Parameter’s configuration and entry on the Group Template’s Mimic is complete, so that each Instance initially inherits the ‘dummy’ link that has been specified for the two Link Parameters.

In order to enable users with the Configure permission to specify a different hyperlink Object in each Instance...
...the ObjectID property of each Link Parameter is marked as locally overridden. This is done using the Group Template’s Property Overrides feature. The ObjectID property is selected so that it displays a check mark. This enables the property to be overridden in each Instance of the Template.

In each Instance of the Template, engineers that have the Configure permission then replace each Link Parameter’s ‘dummy’ hyperlink with the required entry. This automatically updates the hyperlinks on the overview Mimic in that Instance and so enables users to select the overview Mimics that are adjacent to that particular zone, using the ‘Previous Zone’ and ‘Next Zone’ buttons on that Mimic.

An example illustrating this is shown below. The engineers perform similar changes on all Instances of the Link Parameters, to ensure that the ‘Previous Zone’ and ‘Next Zone’ buttons link to the relevant adjacent overview Mimics in each Instance.

In the Instance that represents ‘Eastern Region - Zone 1’...
...the ‘Previous Zone’ button is to link to the overview Mimic for ‘Northern Region - Zone 4’.
To replace the ‘dummy’ link with the required link, an engineer specifies the required link in the Object field of the ‘Eastern Region - Zone 1’ Instance of the ‘Previous Zone’ Link Parameter.

Further Information

Group Templates and Group Instances.

Add a Parameter.

Specify the Database Item that a Link Parameter is to Reference.

Mimics, the Property Window, and Animations: see the ClearSCADA Guide to Mimics.

Understanding the Property Overrides Window.


Core Configuration Guide - Using Variables to Store Data Values

Using Variables to Store Data Values

ClearSCADA includes support for ‘global variables’—simple database items that can store single values, or ‘arrays’ of values. Variables are internal to ClearSCADA (they are not associated with plant) and can be used, for example, to hold the results of calculations in Logic programs. Variables do not trigger events or raise alarms.

You can set the value of a Variable manually via the Set Value or Set Element pick actions, automatically via the Value or SetElement methods, or via Logic.

You can display a list of Variables on your system at any time, using the Variables List. (For information on displaying and working with Lists, see the ClearSCADA Guide to Lists.)

This section summarizes the different Types of Variable that ClearSCADA supports. It also explains how to:

  • Add a Variable
  • Configure the Basic Properties of a Variable
  • Set the Value of a Variable.

Also included is a series of examples that demonstrate how Variables might be used on a ClearSCADA system (see Example Configuration).

NOTE: If the data that you want to store is intended to remain static, consider using Parameters as opposed to Variables. For more information, see Using Parameters to Store Static Data Values. Also see Parameters versus Points and Variables.


Core Configuration Guide - Types of Variable (Using Variables to Store Data Values)

Types of Variable

ClearSCADA supports these types of single-value Variable:
Type of Variable | Description
Boolean | Use this type of Variable to store a single TRUE/FALSE value.
Byte | Use this type of Variable to store a single 8-bit value.
Color | Use this type of Variable to store a color value.
Constant Double | Use this type of Variable to store an unchanging double-precision floating point value. This type of Variable differs from the other Variables supported by ClearSCADA in that the item has no Set Value pick action or Value method. The value is intended to remain constant and be used for test purposes only.
Double | Use this type of Variable to store a double-precision floating point value.
Float | Use this type of Variable to store an IEEE floating point value.
Long | Use this type of Variable to store a signed 4-byte (32-bit) whole number.
String | Use this type of Variable to store a single text string. (ClearSCADA also supports String Points and String Parameters. The type of string that you add to ClearSCADA is determined by that string’s intended functionality—see Parameters versus Points and Variables.)
Time | Use this type of Variable to store a single date and time value. (If used with Logic, a Time Variable can be used to store just a date, a time, or a date and time value.)
Unsigned Long | Use this type of Variable to store an unsigned 4-byte (32-bit) whole number.
Unsigned Word | Use this type of Variable to store a single unsigned 16-bit value.
Variant | Use this type of Variable to store a single value of any type.
Word | Use this type of Variable to store a single signed 16-bit value.

To set the value of any of the above Variables (other than a Constant Double), you can use the Value method, or set the value using Logic. With Variables other than a Constant Double or Variant, you can also set the value by using the Set Value pick action.

ClearSCADA also supports a series of Variable arrays. These types of Variable are intended to store a series of values, rather than a single value. To set the values in a Variable array, use the SetElement method, or set the values using Logic. With arrays other than a Variant Array, you can also set the values by using the Set Element pick action.

ClearSCADA supports these Variable arrays:
Type of Variable Array | Description
Boolean Array | Use this type of Variable array to store a series of TRUE/FALSE values.
Byte Array | Use this type of Variable array to store a series of 8-bit values.
Double Array | Use this type of Variable array to store a series of double-precision floating point values.
Float Array | Use this type of Variable array to store a series of IEEE floating point values.
Long Array | Use this type of Variable array to store a series of unsigned 4-byte (32-bit) whole numbers.
String Array | Use this type of Variable array to store a series of text strings. (If the text strings are to remain static, you might want to consider using Parameter Tables instead of String Arrays—see Types of Parameter.)
Time Array | Use this type of Variable array to store a series of date, time, or date and time values.
Unsigned Long Array | Use this type of Variable array to store a series of signed 4-byte (32-bit) whole numbers.
Unsigned Word Array | Use this type of Variable array to store a series of unsigned 16-bit values.
Variant Array | Use this type of Variable array to store a series of values of any type.
Word Array | Use this type of Variable array to store a series of signed 16-bit values.

To access the values of a Variable array via Logic, use the VECTOR keyword. (To access an Array Variable as an array, you need to use a Structured Text (ST) program.)

Example:

VAR
ITEMS AT %M<(Variable Array Name>) : VECTOR[0...9] OF REAL;
END_VAR

For more information on the VECTOR keyword, see Using Vectors to Access Direct Variables in the ClearSCADA Guide to Logic.


Core Configuration Guide - Add a Variable (Using Variables to Store Data Values)

Add a Variable

To add a Variable to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a Variable.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Variable option.
    A further menu is displayed.
  4. Select the type of Variable that you require (see Types of Variable).
  5. A Variable of the required type is added to the root of the System or to the selected Group (depending on your selection in Step 1), ready for you to enter its name.
  6. Enter a suitable name for the Variable (taking into account the ClearSCADA Naming Restrictions).
  7. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added a Variable, you can then:

  • Configure the Basic Properties of a Variable
  • Set the Value of a Variable.


Core Configuration Guide - Configure the Basic Properties of a Variable (Using Variables to Store Data Values)

Configure the Basic Properties of a Variable

To configure the basic properties of a Variable, display its configuration Form (see Display a Form). Most Variable Forms have only two tabs—configure the required properties on these tabs. The tabs comprise:

  • Identification—Use to optionally define a Help View and to indicate whether the Variable is to be excluded from any Exclusive Control (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the Variable (see Using the User Methods Tab to Define Custom Actions).

The Constant Double Variable has an additional tab:

  • Variable—Use the tab’s Value field to specify the value of the Constant Double Variable.

Further Information

Set the Value of a Variable, other than a Constant Double Variable.


Core Configuration Guide - Set the Value of a Variable (Using Variables to Store Data Values)

Set the Value of a Variable

To set the value of any of a single-value Variable (other than a Constant Double Variable), you can use the Value method, or set the value using Logic. With the exception of a Constant Double Variable or Variant Variable, you can also use the Set Value pick action. For information on using the Set Value pick action (which has the same arguments as the Value method), see Set Value.

To set the value of a Variable array, you use the Set Element pick action (other than with a Variant Array), SetElement method, or set the value using Logic. For information on using the Set Element pick action, see Set Element.

The value of a Constant Double Variable is, as its name implies, expected not to change once it has been configured. As such, you specify a Constant Double’s value using the Value field on the Constant Double Variable Form (see Configure the Basic Properties of a Variable).

A Variant Variable, or Variant Variable array can have a value, or series of values, of any type. The value(s) of this type of Variable or Variable array have to be set via Logic or the Automation Interface. For an example that demonstrates how a Variant Variable’s value might be set, see Using a Variant Variable to Store USINT Data in a Logic Program.


Core Configuration Guide - Set Value (Using Variables to Store Data Values)

Set Value

Associated with: Single-value Variables (other than Constant Double Variables)

You can use the Set Value pick action to set the value of a single-value Variable.

Select the Set Value pick action to display the Set Value window.

For most types of Variable, you use the Value field to enter or select the required Value for the Variable. If an on-screen keypad is displayed, you can Use the Numeric Touch Screen Keypad to specify the required value. (The keypad is only displayed on ViewX workstations on which the On-Screen Keyboard feature is enabled.)

With a Boolean Variable, a Value check box is displayed, rather than a Value field. Select the check box to set the value to True; ensure the check box is clear to set the value to False.

With a Time Variable, use the Value field to specify the required date and time. For more information, see Specifying the Required Entry in a Date and Time Field.

Once you have specified the required value, select the OK button to confirm the entry and set the Variable’s value.

The value remains changed until another Set Value action, or Value method, is executed successfully, or the Variable’s value is changed by other means, such as via a Logic program.

NOTE: With a Variant Variable, you set the value using the SetValue method or via Logic, rather than the Set Value pick action. This is because, as the name implies, the Variable can be any type of value and the type needs to be specified. For an example that demonstrates how a Variant Variable’s value might be set, see Using a Variant Variable to Store USINT Data in a Logic Program.


Core Configuration Guide - Set Element (Using Variables to Store Data Values)

Set Element

Associated with: Variable arrays

You can use the Set Element pick action to set the value of a specific element within a Variable array.

Select the Set Element pick action to display the Set Element window:

In the Element field, enter or select the required element in the array. (The first element in an array is 0, the next element is 1, and so on.)

In the Value field, enter or specify the required value for that element of the array.

With both of the above fields, if an on-screen keypad is displayed, you can Use the Numeric Touch Screen Keypad to specify the required value. (The keypad is only displayed on ViewX workstations on which the On-Screen Keyboard feature is enabled.)

With a Boolean Array, a Value check box is displayed, rather than a Value field. Select the check box to set the value of an element to True; ensure the check box is clear to set the value of the element to False.

With a Time Array, use the Value field to specify the required date and time. For more information, see Specifying the Required Entry in a Date and Time Field.

In each case, select the OK button to confirm the entries and set the value for the specified element of that Variable’s array.

The value of the element remains changed until another Set Element action, or SetElement method, is executed successfully on that element, or the element’s value is changed by other means, such as via a Logic program.

For an example that further demonstrates how to use the Set Element pick action, see Set the Values of the Elements in a Boolean Array.

NOTE: With a Variant Array, you set the value of an element in the array using the SetElement method or via Logic, rather than the Set Element pick action. This is because, as the name implies, the array can comprise a series of any type of value and the type needs specifying.


Core Configuration Guide - Example Configuration (Using Variables to Store Data Values)

Example Configuration

This section comprises several examples that demonstrate how Variables might be used on a ClearSCADA system. The examples are by no means intended to be exhaustive—Variables can be used in numerous ways in ClearSCADA.

This section contains these examples:

  • Use a Time Variable to Display the Present Time on a Mimic
  • Use Variables to Store Value Map Data
  • Set the Values of the Elements in a Boolean Array
  • Using a Variant Variable to Store USINT Data in a Logic Program.


Core Configuration Guide - Use a Time Variable to Display the Present Time on a Mimic (Using Variables to Store Data Values)

Use a Time Variable to Display the Present Time on a Mimic

This example demonstrates how a Time variable might be used to display the present time on a Mimic. A Function Block Diagram (FBD) is used to set the variable’s value.

Example:

The present date and time needs displaying in one corner of a Mimic.

A Time variable is added to the system. It is given the name ‘Now’.

A simple Function Block Diagram, named ‘Update’ is used to set the Time variable’s value:

The Time variable ‘Now’ is added to the Function Block Diagram’s Direct tab.
Within the Function Block Diagram, the Data and Time Function NOW...
...is used to set the value of the ‘Now’ Time variable to the present time.

The ‘Now’ Time variable is added to the relevant Mimic. The variable displays the present time and date, in the date format specified for the user that is logged on to that particular workstation.

Further Information

Working with Function Block Diagrams: see the ClearSCADA Guide to Logic.

Working with Mimics: see the ClearSCADA Guide to Mimics.


Core Configuration Guide - Use Variables to Store Value Map Data (Using Variables to Store Data Values)

Use Variables to Store Value Map Data

This example demonstrates how Variables might be used to store ‘point’ data in Value Maps. Value Maps are used by Slave drivers—drivers that enable ClearSCADA to act as a slave outstation, PLC, or other device. When ClearSCADA is configured as a slave, it reports any data changes to its SCADA ‘Master’ using the slave driver’s native protocol.

Example:

A particular ClearSCADA system is configured as a Modbus Slave.

Separate Value Maps are added to the database to represent each type of Modbus data (Input Register, Holding Register, Discrete, and Coil) that the slave (ClearSCADA) is to store.

As ClearSCADA is to act as a Modbus PLC and report any data changes back to its Master, ClearSCADA itself does not need to process any alarms or events for the data, nor store any values historically. Therefore Variables, rather than points, are used to store the ‘point’ data in the Value Maps.

Word Variables are used to represent the Input Register data. The Variables are attached to the WORD Value Maps that represent those registers.

Other Word Variables are used to represent Holding Register data and are attached to the WORD Value Maps that represent those registers.

Discretes and Coils are represented by Boolean Variables. These Variables are attached to the BIT Value Maps that represent either the Discrete or Coil data.

Boolean Variables represent the Discrete, and Coil Data. They are attached to the relevant BIT Value Maps.
BIT Value Maps are used to store the Discrete, and Coil Data.
WORD Value Maps are used to store the Input Register, and Holding Register data.
Word Variables represent the Input Register, and Holding Register Data. They are attached to the relevant WORD Value Maps.

Further Information

Configuring Value Maps.

Configuring ClearSCADA as a Modbus Slave: see the ClearSCADA Guide to the Modbus Slave Driver.


Core Configuration Guide - Set the Values of the Elements in a Boolean Array (Using Variables to Store Data Values)

Set the Values of the Elements in a Boolean Array

As with other Variable arrays, you can set the value of each element in a Boolean Array by using one of several means (see Set the Value of a Variable). This example demonstrates how the elements in a Boolean Array might be set using the Set Element pick action, and how operators might then ascertain the current values of those elements.

Example:

The Set Element pick action is used to set three elements in a Boolean Array.

As the first element (Element 0) is to be True, the Value check box in the Set Element window is selected:

The second element (Element 1) is also to be True, and the Set Element window is used to set that element accordingly.

The third element (Element 2) is to be False, so when setting this element, the Value check box is left clear:

Operators can ascertain the present values of each element by displaying, for example, the Variable’s Status display:

With a Variable array, the present value of each element is indicated by the Value attribute. The attribute displays each value in element order.

Or by displaying the Variables List:

Again, with a Variable array, the present value of each element is indicated in element order. (In this particular example, this shows that Elements 0 and 1 are True, and Element 3 is False.)

Or by looking at any Mimics that are configured to show the present values of the Boolean array.


Core Configuration Guide - Using a Variant Variable to Store USINT Data in a Logic Program (Using Variables to Store Data Values)

Using a Variant Variable to Store USINT Data in a Logic Program

This example demonstrates how a Variant Variable might be used to store USINT (Unsigned Short Integer) data in a Logic program.

Example:

A Variant Variable is used as an output in a Function Block Diagram. Its value is determined by the greatest of several inputs. Both the inputs and the Variant Variable have Unsigned Short Integer (USINT) values.

The Add Direct Variable window, which is displayed when the Variant Variable is added to the Function Block Diagram, is used to specify the Variable’s settings, including the fact that its value is USINT.

The Add Direct Variable window is used to specify the Variant Variable’s value Type (USINT in this example).

Once the Logic program’s configuration is complete, the program is saved.

When the Logic program executes, the Variant’s value is determined by whichever is the greatest of four inputs:

The MAX function is used to set the Variant Variable’s value. The value is the greatest of the MAX function’s inputs.

Further Information

Working with Logic Programs: see the ClearSCADA Guide to Logic.

The MAX function is one of several ‘Selection’ built-in functions that can be used in Logic programs: see Selection in the ClearSCADA Guide to Logic.


Core Configuration Guide - Configuring System Commands

Configuring System Commands

You can configure ClearSCADA to trigger a Windows® system command automatically, or on request. You might, for instance, use a System Command to automatically copy specific data to a third-party application, for use independent of ClearSCADA.

Any application that is triggered by such a command should require no additional user intervention and should run for only the briefest amount of time. (While a system command-triggered application is running, any other system commands are placed on hold until that application closes.)

ClearSCADA can trigger a system command under various circumstances—you need to Decide When ClearSCADA is to Execute a System Command, in order to determine the type of configuration that you need to undertake.

NOTE: In addition to the above, ClearSCADA is supplied with a built-in command line tool, to enable third-party applications to run ClearSCADA commands from the Windows® command prompt. For more information, see Server Command Line Tool in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Decide When ClearSCADA is to Execute a System Command (Configuring System Commands)

Decide When ClearSCADA is to Execute a System Command

ClearSCADA can trigger a system command under various circumstances. You need to decide when ClearSCADA is to execute each system command, in order to determine the type of configuration that you need to undertake:

  • If ClearSCADA is to trigger a system command automatically in response to a particular alarm situation, configure a System Command Action. A System Command Action is an alarm redirection action. For more information on configuring this type of action, see System Command Action in the ClearSCADA Guide to Alarm Redirection.
  • If a Logic program is to trigger a system command automatically, include the SYTEM function in the relevant Logic program. For more information, see Misc in the ClearSCADA Guide to Logic.
  • If ClearSCADA is to trigger a system command in response to a user request, either:
  • Associate the relevant object on a Mimic with a System Command pick action.

Configure a System Command pick action, rather than a System Command database item (see below), if you want to be able to:

  • Associate the pick action with any object on a Mimic, rather than specifically with a System Command object.
  • Specify the permission that users have to be allocated, in order for them to be able to trigger such a command. (With a system command that triggers a high-level operation, for instance, you might allocate the Mimic on which the pick action is located with the ‘System Admin’ permission. This would result in the System Command pick action only being made available to users that have been allocated the ‘System Admin’ permission for that Mimic.)

For information, see Creating a System Command Pick Action in the ClearSCADA Guide to Mimics.

  • Add a System Command item to the database, and then use that item’s Execute pick action to trigger the command.

Configure a System Command database item, rather than a System Command pick action, if users need to be able to execute the command from the Database Bar, or from a Queries List, in addition to any Mimic(s) on which the System Command database item is included. (Unlike the System Command pick action, the System Command database item’s Execute pick action is not restricted by permission.)

For more information on the System Command database item, see Add a System Command, and see Execute a System Command.

NOTE: In addition to the above, ClearSCADA is supplied with a built-in command line tool, to enable third-party applications to run ClearSCADA commands from the Windows® command prompt. For more information, see Server Command Line Tool in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Add a System Command (Configuring System Commands)

Add a System Command

This section only applies to System Commands that ClearSCADA is to execute on user request from the Database Bar, a Queries List, or any Mimic on which a System Command database item is included. (For more information on the circumstances under which ClearSCADA can execute a system command, see Decide When ClearSCADA is to Execute a System Command.)

To add a System Command item to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a System Command.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the System Command option.
    A System Command is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the System Command (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added a System Command to the system, you can then Configure the Properties on the System Command Form.


Core Configuration Guide - Configure the Properties on the System Command Form (Configuring System Commands)

Configure the Properties on the System Command Form

To define a System Command’s properties, you need to display the System Command Form (see Display a Form).

The System Command Form has these tabs:

  • Identification—Use to optionally define a Help View and to indicate whether the System Command is to be excluded from any Exclusive Control activity (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the System Command (see Using the User Methods Tab to Define Custom Actions).
  • System Command—Use to specify the required command line. Use the same syntax as a command line in Windows. For example, to run a particular application automatically, enter a command of the form:
<application>.exe

(where <application> is the name of the external application that is to run).

Be aware that any applications that are triggered by the System Command should require no user intervention and should run for only the briefest amount of time.

If appropriate, consider using a batch file to trigger multiple executes from a single System Command. For a System Command to trigger a batch file, specify the name of the batch file in the Command field.

Further Information

Execute a System Command.


Core Configuration Guide - Execute a System Command (Configuring System Commands)

Execute a System Command

To trigger a Windows® operating command using a System Command database item:

  1. Right-click on the relevant System Command entry on either:
  • The Database Bar
  • A Queries List
  • A Mimic.

A context sensitive menu is displayed.

  2. Select the Execute option.
    ClearSCADA triggers the specified command.


Core Configuration Guide - Configuring Master Station Accumulators

Configuring Master Station Accumulators

An Accumulator calculates or increments its value, depending on the state or value of another Accumulator or point (known as its ‘source’). For example, an Integrator Accumulator calculates the total value that its source reaches over a specified period.

ClearSCADA supports a variety of master station Accumulators—Accumulators that reside and act on values in the ClearSCADA database, rather than on values in an outstation. For further information, see Types of Master Station Accumulator.

This section explains:

  • The Types of Master Station Accumulator
  • How to Add and Configure an Accumulator
  • The Tabs on Accumulator Forms.

It also explains some of the pick actions and features that you might want to consider when Using Master Station Accumulators on a ClearSCADA System, and the Status Attributes Associated with Master Station Accumulators.

Example:

A Trend showing an Integrator Accumulator calculating the total value of an Analog point over an accumulation period.

In the Trend above, the Analog point trace is attached to the left y-axis and the Integrator Accumulator trace is attached to the right y-axis. The integration value is effectively the area under the Analog point’s trace (as the integral of a value is value x time).


Core Configuration Guide - Types of Master Station Accumulator (Configuring Master Station Accumulators)

Types of Master Station Accumulator

ClearSCADA supports these types of master station, or server-side, Accumulator:

  • Boolean Counter—A Boolean Counter calculates the number of times that its source changes from a False to True state, a True to False state, or both, over a specified period. The value of a Boolean Counter increments by one each time that a monitored state change occurs.
  • Delta—A ‘Delta’ is a small change between two successive sets of data. A Delta Accumulator calculates the sum of the differences in source value over a specified period. A Delta Accumulator is often used to accumulate another Accumulator’s data over a different calculation period (for instance, to integrate the data of an Accumulator that uses a one-hour End of Period reset, over a 24-hour period).
  • Integrator—An Integrator Accumulator calculates the total value of its source over a specified period (time x value).
  • Maximum—A Maximum Accumulator calculates the maximum value that its source reaches over a specified period.
  • Mean—A Mean Accumulator calculates the average value of its source over a specified period. You can specify whether the average value is calculated as an Arithmetic Mean, or a Time-Weighted Mean.
  • Minimum—A Minimum Accumulator calculates the minimum value that its source reaches over a specified period.
  • Rate of Change—A Rate of Change Accumulator calculates the rate at which its source value changes over a specified period. You can specify whether the rate of change compares the present source value against the previous source value, or uses Linear Regression to calculate the rate of change value. A negative Accumulator value indicates that the source’s value is falling, a positive Accumulator value indicates that the source’s value is rising.
  • Runtime—A Runtime Accumulator calculates the amount of time that its source is in a True or False state during a specified period.

NOTE: Some types of outstation and scanner support Accumulators that reside locally at the outstation or scanner. For information on configuring such Accumulators, see the driver-specific documentation.


Core Configuration Guide - Add and Configure an Accumulator (Configuring Master Station Accumulators)

Add and Configure an Accumulator

To add a master station Accumulator to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add an Accumulator.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Accumulator option.
    A further menu is displayed.
  4. Select the type of Accumulator that you require (see Types of Master Station Accumulator).
    An Accumulator of the required type is added to the root of the System or to the selected Group (depending on your selection in Step 1), ready for you to enter its name.
  5. Enter a suitable name for the Accumulator (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added an Accumulator, you can then define the Accumulator’s properties, using the fields on the Accumulator Form. To display the Form, see Display a Form. The Form has several tabs—use the fields on the tabs to configure the Accumulator (see Tabs on Accumulator Forms).


Core Configuration Guide - Using Master Station Accumulators on a ClearSCADA System (Configuring Master Station Accumulators)

Using Master Station Accumulators on a ClearSCADA System

Once configured, an Accumulator will automatically calculate its value using the state or value of its source, for the period specified in the End of Period Reset section of the Accumulator Form (see Specify the Period over which an Accumulator’s Value is Calculated).

If an Accumulator uses a Continuous reset method, you can optionally use the Accumulator’s Reset pick action to reset the Accumulator’s value to zero, independently of the configured End of Period settings.

Similarly, if an Accumulator uses a Continuous reset method, you can optionally use an Accumulator’s Initialize pick action to specify the starting value from which that Accumulator should calculate its value.

For more information on either pick action, see Actions Associated with Master Station Accumulators.

To reset or initialize an Accumulator’s value automatically in exceptional circumstances, consider using an Alarm Redirection Method Action (see Perform Action/Invoke Method Redirection in the ClearSCADA Guide to Alarm Redirection).

You can use Accumulators within Logic programs—for information on writing logic programs, see the ClearSCADA Guide to Logic.

You can view an Accumulator’s Status display whenever you need to ascertain information about the Accumulator’s status (see Status Attributes Associated with Master Station Accumulators).


Core Configuration Guide - Tabs on Accumulator Forms (Configuring Master Station Accumulators)

Tabs on Accumulator Forms

Each Accumulator Form has a combination of these tabs:

  • Identification—Use the fields on this tab to configure the Identification properties (see Defining Identification Details).
  • User Methods—Use the fields on this tab to define any custom pick actions (‘methods’) for an Accumulator (see Using the User Methods Tab to Define Custom Actions).
  • Historic—Use the fields on this tab to specify any historic storage settings for an Accumulator. The properties on this tab are identical to those on the Historic tab of points that support historic storage (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

Historic values provide a record of the Accumulator’s data and are of particular use when monitoring the value of an Accumulator over time. To store Accumulator values historically, your system has to be enabled to store data historically (see Historic Data Storage Settings in the ClearSCADA Guide to Server Administration).

If ClearSCADA is to store an Accumulator’s data historically and is to compress that historic data, be aware that ClearSCADA will not compress any Accumulator Updates to which Historic Data Compression Settings do not Apply.

  • Reset—Use the fields on this tab to:
  • Specify whether an Accumulator Continuously Sends Timed Reports and Resets its Value
  • Specify an Accumulator’s Source
  • Define the Appearance of an Accumulator’s Values
  • Specify the Frequency with which ClearSCADA Stores Timed Report Values
  • Specify the Period over which an Accumulator’s Value is Calculated
  • Specify the Data that ClearSCADA Stores for an Accumulator.
  • State—Applicable to Accumulators other than Integrator, Maximum, and Minimum. Use the fields on this tab to specify when an Accumulator value is to increment. The fields on the tab vary—depending on the type of Accumulator, you can use the fields to:
  • Define When the Value of a Boolean Counter is to Increment
  • Define When the Source of a Delta Accumulator has Reset
  • Define the Type of Calculation that a Mean Accumulator Uses
  • Specify when a Rate of Change Accumulator Value Increments
  • Specify when a Runtime Accumulator Value Increments.


Core Configuration Guide - Accumulator Updates to which Historic Data Compression Settings do not Apply (Configuring Master Station Accumulators)

Accumulator Updates to which Historic Data Compression Settings do not Apply

This section applies to Accumulators for which ClearSCADA is to store data historically, and for which ClearSCADA is to compress that historic data. Such settings are configured on the Accumulator Form’s Historic tab. The properties on the tab are identical to those on the Historic tab of many Point Forms (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

If you apply historic data Compression settings to an Accumulator, ClearSCADA compares the update that it last stored historically for the accumulator and the next update that is marked for compression. If any of the following attributes differ between the two accumulator values, ClearSCADA ignores any Compression settings and automatically stores the latest update historically:

  • State
  • Quality
  • The Reason for the point update (for example, Timed Report, or Current Update).

Additionally, ClearSCADA also stores any ‘out of sequence’ data historically. Out of sequence data comprises values that are time stamped with an earlier time to the previously stored value.

You can determine why ClearSCADA has stored an update historically, by looking at the Historic List for the accumulator. Each of the above attributes are displayed in separate columns on the List.

The entries in the State, Quality, and Reason columns indicate why ClearSCADA has stored an accumulator update historically, regardless of Compression settings.

For more information on Historic Lists, see the ClearSCADA Guide to Lists.

For more information on historic data Compression, see Historic Data Compression in the ClearSCADA Guide to Core Point Configuration.


Core Configuration Guide - Specify whether an Accumulator Continuously Sends Timed Reports and Resets its Value (Configuring Master Station Accumulators)

Specify whether an Accumulator Continuously Sends Timed Reports and Resets its Value

Use the Continuous check box at the top of the Reset tab to specify whether an Accumulator is to reset its value back to zero and send Timed Reports to ClearSCADA even if it has no new data to process:

Select the Continuous check box for an Accumulator to continuously send Timed Reports to ClearSCADA and then reset its Accumulator value even when that Accumulator has no new data to process. Use this option only if you require Accumulator data to be processed continually, regardless of whether the Accumulator has source data to process. Timed Report and End of Period values for those periods in which no source data is processed may be slightly inaccurate as the values for which no data exists are estimated (ClearSCADA does not wait for the next source value before calculating the values). With an Accumulator for which ClearSCADA continuously processes data, Initialize and Reset pick actions are provided to enable you to adjust the Accumulator’s value at any time (see Actions Associated with Master Station Accumulators).

Ensure that the Continuous check box is clear if an Accumulator is to send Timed Reports to ClearSCADA and then reset its Accumulator value only when that Accumulator has new data to process. This option is more accurate as ClearSCADA only calculates the Timed Report and End of Period Accumulator values for those periods in which no new data is processed once it receives the next source value.

Ensure that the check box is clear for Accumulators that are processing data from PSTN outstations or scanners.

Use the Continuous check box in conjunction with:

  • The fields within the Timed Report section of the Reset tab to Specify the Frequency with which ClearSCADA Stores Timed Report Values.
  • The fields within the End of Period Reset section of the Reset tab to Specify the Period over which an Accumulator’s Value is Calculated


Core Configuration Guide - Specify an Accumulator's Source (Configuring Master Station Accumulators)

Specify an Accumulator’s Source

Use the fields within the Source Object section of the Reset tab to specify the item that is to provide the source for an Accumulator and the type(s) of data that the Accumulator is to process from that source:

  • Object—Use to specify the point or Accumulator that this Accumulator is to use for its source value. The point or Accumulator can reside anywhere on the system. Select the browse button to display a Reference browse window and select the required entry from the window.
  • Current—Select this check box for the source item’s Current values to be taken into account when calculating the Accumulator’s value.

Clear the Current check box for such values not to be taken into account when calculating the Accumulator’s value.

  • Value Change—Select this check box for the source item’s Value Changes to be taken into account when calculating the Accumulator’s value.

Clear the Value Change check box for such values not to be taken into account when calculating the Accumulator’s value.

  • State Change—Select this check box for the source item’s State Change values to be taken into account when calculating the Accumulator’s value.

Clear the State Change check box for such values not to be taken into account when calculating the Accumulator’s value.

  • Timed Report—Select this check box for the source item’s Timed Report values to be taken into account when calculating the Accumulator’s value.

Clear the Timed Report check box for such values not to be taken into account when calculating the Accumulator’s value.

  • End of Period—Select this check box for the source item’s End of Period values to be taken into account when calculating the Accumulator’s value.

Clear the End of Period check box for such values not to be taken into account when calculating the Accumulator’s value.

  • End of Period Reset—Select this check box for the source item’s End of Period Reset values to be taken into account when calculating the Accumulator’s value.

Clear the End of Period Reset check box for such values not to be taken into account when calculating the Accumulator’s value.

  • Override—Select this check box for the source item’s Override values to be taken into account when calculating the Accumulator’s value.

Clear the Override check box for such values not to be taken into account when calculating the Accumulator’s value.

  • Release Override—Select this check box for the source item’s Release Override values to be taken into account when calculating the Accumulator’s value.

Clear the Release Override check box for such values not to be taken into account when calculating the Accumulator’s value.


Core Configuration Guide - Define the Appearance of an Accumulator's Values (Configuring Master Station Accumulators)

Define the Appearance of an Accumulator’s Values

Use the fields within the Formatting section of the Reset tab to define the appearance of an Accumulator’s values on other displays, such as Lists and Trends:

  • Units—Use this combo box to enter or select the appropriate measurement units for the Accumulator’s values. Either highlight the existing entry and overwrite it with a new type of measurement, or choose a measurement from the units list (displayed using the arrow button).

The list of measurements can be customized for your system (see Define Standard Descriptions for Measurement Units in the ClearSCADA Guide to Server Administration).

  • Format—Use this field to specify the format that the Accumulator’s values are to take on other displays. Select the browse button to display the Text Format window, from which you can choose or define the required type of formatting. For more information, see Choose a Format Category.


Core Configuration Guide - Specify the Frequency with which ClearSCADA Stores Timed Report Values (Configuring Master Station Accumulators)

Specify the Frequency with which ClearSCADA Stores Timed Report Values

ClearSCADA can log Accumulator data by Timed Report—it regularly stores Accumulator values in the database, regardless of whether those values have changed. Use the fields within the Timed Report section of the Reset tab to specify when ClearSCADA logs Accumulator values on a Timed Report basis. Use the Continuous check box at the top of the Reset tab to specify whether Timed Reports still occur when an Accumulator has no new data to process (see Specify whether an Accumulator Continuously Sends Timed Reports and Resets its Value).

  • Interval—Use this field to specify the frequency with which ClearSCADA is to logged timed reports for an Accumulator. Enter the frequency in the OPC Time Format, for instance, 15M for ClearSCADA to log timed report values at 15-minute intervals. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

Use this field in conjunction with the Offset field (see below) to specify when the timed reports are to occur.

  • Offset—Use this field to specify the synchronization offset—the amount of time that occurs before ClearSCADA logs the first timed report. Enter the frequency in the OPC Relative Time Format, for instance, H for the first timed report to occur at the start of the present hour, and thereafter at the intervals specified in the Interval field, above. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

To disable Timed Report logging, set the Interval to 0 (zero)—ClearSCADA will ignore any value specified in the Offset field (you can clear the Offset field if required).

  • Local Time—ClearSCADA can log timed report data on a Local or System time basis.

Select this check box for timed reports to be logged using Local Time, for example Eastern Standard Time (EST) if the local time zone is that for the East coast of America. Use the Daylight Saving Time check box (see below) to specify whether to take into account any daylight saving adjustments.

Ensure that the Local Time check box is clear for ClearSCADA to log timed reports using Coordinated Universal Time (UTC). This is the time that regulates the operation of your system. For more information, see Time Zone Support in ClearSCADA.

  • Daylight Saving Time—Applicable if the Local Time check box is selected (see above). Select this check box for ClearSCADA to automatically adjust the time to account for Daylight Saving Time (DST).

Ensure that the Daylight Saving Time check box is clear if ClearSCADA is not to make any DST time adjustments.

ATTENTION: Be aware that, depending on the driver on which an Accumulator’s source is located, there may be gaps in the data when the clocks are adjusted forwards, or missing data when times repeat after the clocks are adjusted back to account for DST. Ensure that the Daylight Saving Time check box is clear if such gaps are not acceptable on your system.

Example:

An Accumulator has this Timed Report configuration:

Interval: 5M
Offset: H
Local Time check box: Checked (End of Period resets are calculated using Local time)
Daylight Saving Time: Checked (ClearSCADA automatically adjusts the time to take into account any DST adjustments).

ClearSCADA logs the Accumulator value on the hour, and then at five-minute intervals throughout the day, taking account any DST adjustments.

If the Accumulator’s Continuous check box is not selected (see Specify whether an Accumulator Continuously Sends Timed Reports and Resets its Value), and there are no source values to process for part of the time, those Timed Reports will not occur until the next source value is processed, whereupon ClearSCADA will calculate the ‘missing’ Timed Reports and populate its historic database with those report values (time stamped with the times at which they would have occurred if data had been available for processing).


Core Configuration Guide - Specify the Period over which an Accumulator's Value is Calculated (Configuring Master Station Accumulators)

Specify the Period over which an Accumulator’s Value is Calculated

Use the fields within the End of Period Reset section of the Reset tab to specify the period over which an Accumulator’s value is calculated. Use the Continuous check box at the top of the Reset tab to specify whether End of Period Resets still occur when an Accumulator has no new data to process (see Specify whether an Accumulator Continuously Sends Timed Reports and Resets its Value)

  • Interval—Use this field to specify the duration over which an Accumulator’s value is calculated. Enter the duration in the OPC Time Format, for instance, 1H for ClearSCADA to calculate an Accumulator’s value over a one-hour period. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value. Once the period elapses, the Accumulator value is reset to zero, following which it increments once more until the next interval elapses.
  • Offset—Use this field to specify the start of the first calculation period. Enter the offset in the OPC Relative Time Format, for instance, D + 15M to start calculating the Accumulator’s value from 00:15hrs each day, and thereafter at the intervals specified in the Interval field, above. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

To disable End of Period resets, set the Interval to 0 (zero)—ClearSCADA will ignore any value specified in the Offset field (you can clear the Offset field if required).

  • Local Time—ClearSCADA can calculate the End of Period Reset time on a Local or System time basis.

Select this check box for ClearSCADA to calculate the End of Period Reset using Local Time, for example Eastern Standard Time (EST) if the local time zone is that for the East coast of America. Use the Daylight Saving Time check box (see below) to specify whether to take into account any daylight saving adjustments.

Ensure that the Local Time check box is clear for ClearSCADA to calculate the End of Period Reset using Coordinated Universal Time (UTC). This is the time that regulates the operation of your system. For more information, see Time Zone Support in ClearSCADA.

  • Daylight Saving Time—Applicable if the Local Time check box is selected (see above). Select this check box for ClearSCADA to automatically adjust the time to account for Daylight Saving Time (DST).

Ensure that the Daylight Saving Time check box is clear if ClearSCADA is not to make any DST time adjustments.

ATTENTION: Be aware that, depending on the driver on which an Accumulator’s source is located, there may be gaps in the data when the clocks are adjusted forwards, or missing data when times repeat after the clocks are adjusted back to account for DST. Ensure that the Daylight Saving Time check box is clear if such gaps are not acceptable on your system.

Example:

An Accumulator has this End of Period Reset configuration:

Interval: 1H
Offset: D
Local Time check box: Clear (End of Period resets are calculated using system time).

The Accumulator monitors its source value from 00:00hrs each day for a one-hour period. At the end of this period, the Accumulator value is reset to zero. The Accumulator then monitors its source value for another one-hour period, before the Accumulator value is again reset to zero. This activity is repeated throughout the day, with the last calculation period starting at 23:00hrs.


Core Configuration Guide - Specify the Data that ClearSCADA Stores for an Accumulator (Configuring Master Station Accumulators)

Specify the Data that ClearSCADA Stores for an Accumulator

Use the Historic Data Filter section of the Reset tab in conjunction with the Historic tab.

The Historic tab defines whether the server stores Accumulator values historically, and whether any unnecessary data is filtered out to reduce storage requirements (see Tabs on Accumulator Forms).

Use the fields within the Historic Data Filter section of the Reset tab to specify the type of Accumulator data that ClearSCADA is to store historically:

  • Current—Select this check box for the server to store an Accumulator’s current values historically.

Clear the check box if the server is not to store an Accumulator’s current values historically.

  • Timed Report—Select this check box for the server to store an Accumulator’s Timed Report values historically.

Clear the check box if the server is not to store an Accumulator’s Timed Report values historically.

  • End of Period—Select this check box for the server to store an Accumulator’s End of Period values historically.

Clear the check box if the server is not to store an Accumulator’s End of Period values historically.

If none of the check boxes is selected, regardless of whether historic is enabled on the Historic tab, ClearSCADA will not store retrieved Accumulator values historically.


Core Configuration Guide - Define When the Value of a Boolean Counter is to Increment (Configuring Master Station Accumulators)

Define When the Value of a Boolean Counter is to Increment

Use the check boxes on the State tab of the Boolean Counter Accumulator Form to specify which state changes are to increment the Accumulator value:

Select the False to True check box for the Accumulator value to increment when the state of its source point changes from False to True.

Select the True to False check box for the Accumulator value to increment when the state of its source point changes from True to False.

Select either, or both, check boxes, depending on requirements.

Example:

A Boolean Counter Accumulator monitors the value of a Digital point. The Accumulator is configured as ‘False to True’. As such, the value of the Accumulator increments each time that the Digital point travels from state 0 to state 1 (False to True). The Accumulator value increments by one on each occasion.

In the Trend above, the Boolean Counter Accumulator trace is attached to the left y-axis and the Digital point trace to the right y-axis. The Trend shows that when the Digital point changes state from 0 to 1 on eight occasions during the accumulation period, the Accumulator value reads 8.


Core Configuration Guide - Define When the Source of a Delta Accumulator has Reset (Configuring Master Station Accumulators)

Define When the Source of a Delta Accumulator has Reset

Use the Source Reset Type combo box on the State tab of the Delta Accumulator Form to specify how the Accumulator detects when its source value has reset:

The options are:

  • End of Period—The source value is configured to reset on an End of Period basis. Each Delta Accumulator value is calculated as the difference between the previous source value and the present source value. Any End of Period source values are ignored—the Accumulator continues to increment its value as if the source value has not reset to zero.
  • Zero Value—The source value is assumed to have reset whenever its value is zero. Each Delta Accumulator value is calculated as the difference between the previous source value and the present source value. Any source values that are zero are ignored—the Accumulator continues to increment its value as if the source value has not reset to zero.

Select this option:

  • If the source values are obtained from another device and zero source values are not logged with an End of Period reason in the ClearSCADA database
  • You want the Accumulator to calculate the difference between each non-zero source value.
  • Every Value—The source value resets whenever it changes value. Each Delta Accumulator value is the sum of the previous source value plus the present source value (rather than the difference between the two values).

Select this option for the Accumulator value to be a summation of the source values, including any source values that may be End of Period reset values (regardless of whether those values include an End of Period logging reason).

Example:

Three Delta Accumulators are used to calculate the differences in source value of a Runtime Accumulator. A Trend is used to monitor the Accumulator values.

In the Trend shown above, the Runtime source and two of the Delta Accumulator traces are attached to the left y-axis and the ‘Delta - Every Value’ Accumulator trace is attached to the right y-axis.

Each Delta Accumulator uses a different Reset type to evaluate the changes in source value. The ‘Every Value’ Delta Accumulator increments its value by the full new source value, whereas the ‘End of Period’ and ‘Zero Value’ Delta Accumulators increment their values by the difference between the present and previous source values.

The latter two Accumulators ignore any End of Period reset and zero source values respectively. This results in the ‘End of Period’ and ‘Zero Value’ Delta Accumulators producing identical traces in this example (as indicated by the ruler values on the Trend above). This is due to the End of Period and zero source values occurring at the same time as each other. (A Delta Accumulator with a ‘Zero Value’ Source Reset Type is typically only used if a source value resets to zero without supplying an ‘End of Period reason’ for the zero values in the ClearSCADA database.)


Core Configuration Guide - Define the Type of Calculation that a Mean Accumulator Uses (Configuring Master Station Accumulators)

Define the Type of Calculation that a Mean Accumulator Uses

Use the Arithmetic Mean check box on the State tab of the Mean Accumulator Form to specify the type of mean calculation that ClearSCADA is to use for the Accumulator value:

Select the Arithmetic Mean check box for ClearSCADA to use an arithmetic mean to calculate the Accumulator’s value. An arithmetic mean is the average of n values ((value1 + value2 +...valuen)/n).

Example:

A Mean Accumulator calculates the Arithmetic Mean value of an Analog point. The Analog point has the following values:

45.00, 46.56, 48.50, 50.65, 50.65, 34.46, 32.31

This results in an Accumulator value of 44.01 (the sum of the above Analog values, divided by the number of Analog values (7)).

Clear the Arithmetic Mean check box for ClearSCADA to use time-weighted mean. A time weighted mean takes into account the amount of time that the source remains at each value over the calculation period.

Example:

Two Mean Accumulators are used to calculate the average value of an Analog point. A Trend is used to monitor the Analog and Accumulator values.

The Accumulators use different types of mean calculation to evaluate the Analog point’s average value—one Accumulator calculates the Analog point’s Arithmetic Mean; the other Accumulator calculates the Analog point’s Time Weighted Mean.


Core Configuration Guide - Specify when a Rate of Change Accumulator Value Increments (Configuring Master Station Accumulators)

Specify when a Rate of Change Accumulator Value Increments

Use the Current value is instantaneous ROC check box on the State tab of the Rate of Change Accumulator Form to specify when the Rate of Change value increments:

Select the Current value is instantaneous ROC check box for ClearSCADA to calculate the Rate of Change between the present source value and the previous source value.

Example:

The ‘Current value is instantaneous ROC’ check box is selected for a Rate of Change Accumulator.

The Accumulator’s source changes in value from 14 to 24 over a five-second period. This produces an Accumulator value of 2.

(The value of the Accumulator is the difference between the present and previous source values (24 - 14), divided by the time (5)).

Clear the Current value is instantaneous ROC check box for ClearSCADA to calculate the Rate of Change using Linear Regression. Linear Regression uses a statistical calculation to produce a ‘best fit’ straight line to the rate of change source data. This provides an estimate of the rate of change over the calculation period, with ClearSCADA adjusting the resulting straight line as it processes new source data.

Example:

Two Rate of Change Accumulators are used to calculate the rate of change of an Analog point. A Trend is used to monitor the Analog and Accumulator values.

In the Trend shown above, the Analog point trace is attached to the left y-axis and the Rate of Change Accumulator traces to the right y-axis. The Accumulator values increase whenever the Analog value rises, and decrease whenever the Analog values falls, indicating the rate of change in the Analog point value.

The Accumulators use different types of calculation to evaluate the Analog point’s rate of change—one Accumulator calculates the difference between the previous and present Analog values and divides this by the time between the changes in value; the other Accumulator uses Linear Regression to evaluate the Analog point’s rate of change.


Core Configuration Guide - Specify when a Runtime Accumulator Value Increments (Configuring Master Station Accumulators)

Specify when a Runtime Accumulator Value Increments

Use the Log True check box on the State tab of the Runtime Accumulator Form to specify when the Runtime value increments:

Select the Log True check box for ClearSCADA to increment the Runtime value when the input value is True.

Clear the Log True check box for ClearSCADA to increment the Runtime value when the input value is False.

Example:

A Runtime Accumulator monitors the value of a Digital point. The Accumulator is configured as ‘Log True’. As such, the value of the Accumulator increments whenever the Digital point is True (state 1). The Accumulator value is calculated by taking into account the length of time that the Digital point remains True on each occasion.

In the Trend shown above, the Runtime Accumulator trace is attached to the left y-axis and the Digital point trace to the right y-axis. The value of the Runtime Accumulator increments whenever the Digital point is in State 1 (True). The Accumulator value indicates the amount of time that the Digital point is in the True state since the Accumulator last reset.


Core Configuration Guide - Actions Associated with Master Station Accumulators (Configuring Master Station Accumulators)

Actions Associated with Master Station Accumulators

In addition to the pick actions that are common to many database items (see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients), there are several pick actions that are specific to Master Station Accumulators. These pick actions (also known as context sensitive menu options) comprise:

  • Initialize
  • Reset.


Core Configuration Guide - Initialize (Configuring Master Station Accumulators)

Initialize

Associated with: Master Station Accumulators that use a Continuous reset method

Security permission required to access this pick action: Control

Use this pick action to specify the starting value from which the Accumulator should calculate its value.

Select the Initialize pick action to display the Initialize window.

Specify the required value in the Value field. If an on-screen keypad is displayed, you can Use the Numeric Touch Screen Keypad to specify the value. (The keypad is only displayed on ViewX workstations on which the On-Screen Keyboard feature is enabled.)

Further Information

Continuous reset method: see Specify whether an Accumulator Continuously Sends Timed Reports and Resets its Value.


Core Configuration Guide - Reset (Configuring Master Station Accumulators)

Reset

Associated with: Master Station Accumulators that use a Continuous reset method

Security permission required to access this pick action: Control

With an Accumulator that is configured to use a Continuous reset method, ClearSCADA automatically sets that Accumulator’s value back to zero at the end of each calculation period (see Specify the Period over which an Accumulator’s Value is Calculated).

If required, you can use the Reset pick action to reset an Accumulator’s value to zero, independently of the End of Period Reset settings configured for that Accumulator.

Further Information

Continuous reset method: see Specify whether an Accumulator Continuously Sends Timed Reports and Resets its Value.


Core Configuration Guide - Status Attributes Associated with Master Station Accumulators (Configuring Master Station Accumulators)

Status Attributes Associated with Master Station Accumulators

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

Use this section if you need information on the status of any Master Station Accumulators on your system.

Master Station Accumulators have many status attributes in common with points. For information on any status attributes that are not listed below, see Status Attributes Associated with Points in the ClearSCADA Guide to Drivers.

The subsections that follow explain those status attributes that are specific to Master Station Accumulators. The status attributes comprise:

  • Current Time
  • End of Interval
  • Interval
  • Overrun Count
  • Pre-Previous Update Quality
  • Pre-Previous Update Value
  • Pre-Previously Updated
  • Report Quality
  • Report Time
  • Report Value
  • Start of Interval.

Further Information

Working with Status displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.


Core Configuration Guide - Current Time (Configuring Master Station Accumulators)

Current Time

Associated with: Master Station Accumulators

This status attribute indicates the date and time that the Accumulator’s Current Value was last updated in the database.

Use the attribute in conjunction with the Current Quality attribute to ascertain the reliability of the Accumulator’s Current Value.


Core Configuration Guide - End of Interval (Configuring Master Station Accumulators)

End of Interval

Associated with: Master Station Accumulators on which the total is reset on an End of Period basis

This attribute displays the date and time at which the Accumulator’s current or latest End of Period Reset interval is due to end.

Use the attribute in conjunction with the Interval and Start of Interval status attributes.


Core Configuration Guide - Interval (Configuring Master Station Accumulators)

Interval

Associated with: Master Station Accumulators on which the total is reset on an End of Period basis

This status attribute indicates the interval at which the Accumulator’ is configured to reset. The interval is specified using the Interval field within the End of Period Reset section of the Accumulator Form (see Specify the Period over which an Accumulator’s Value is Calculated).

Use the attribute in conjunction with the Start of Interval and End of Interval status attributes.


Core Configuration Guide - Overrun Count (Configuring Master Station Accumulators)

Overrun Count

Associated with: Master Station Accumulators that use a Continuous reset method

This status attribute indicates whether ClearSCADA has omitted to process the Accumulator total within the configured End of Period Reset or Timed Report intervals. The Overrun Count is only likely to increment in exceptional circumstances—for example, if an extremely short Interval (such as 1 Second) is specified, but ClearSCADA was unable to process the Accumulator’s value at the required time due to the system being exceptionally busy.

An Overrun Count of 0 (zero) indicates that no counts have overrun since the Accumulator’s configuration was last saved.


Core Configuration Guide - Pre-Previous Update Quality (Configuring Master Station Accumulators)

Pre-Previous Update Quality

Associated with: Master Station Accumulators that are, or have been, In Service

This status attribute indicates the reliability of the Accumulator’s Pre-Previous Update Value —the total that the Accumulator reached before reaching its Previous Update Value.

For a comprehensive list of quality values, see Quality in the ClearSCADA Guide to Drivers.

Use the attribute in conjunction with the Pre-Previously Updated status attribute.


Core Configuration Guide - Pre-Previous Update Value (Configuring Master Station Accumulators)

Pre-Previous Update Value

Associated with: Master Station Accumulators that are, or have been, In Service

This status attribute indicates the total value that the Accumulator reached at its Pre-Previously Updated time—the last time that ClearSCADA processed the Accumulator’s total before the total that it processed at the Accumulator’s Previously Updated time.

Use the attribute in conjunction with the Pre-Previous Update Quality status attribute.


Core Configuration Guide - Pre-Previously Updated (Configuring Master Station Accumulators)

Pre-Previously Updated

Associated with: Master Station Accumulators that are, or have been, In Service

This status attribute indicates the date and time that ClearSCADA updated the Accumulator’s Pre-Previous Update Value —the last Accumulator total that ClearSCADA processed before it processed the Accumulator’s Previous Update Value.

Use the attribute in conjunction with the Pre-Previous Update Quality status attribute.


Core Configuration Guide - Report Quality (Configuring Master Station Accumulators)

Report Quality

Associated with: Master Station Accumulators for which ClearSCADA logs data on a Timed Report basis

This status attribute indicates the reliability of the Accumulator’s latest Report Value.

For a comprehensive list of quality values, see Quality in the ClearSCADA Guide to Drivers.

Use the attribute in conjunction with the Report Time status attribute.


Core Configuration Guide - Report Time (Configuring Master Station Accumulators)

Report Time

Associated with: Master Station Accumulators for which ClearSCADA logs data on a Timed Report basis

This status attribute indicates the date and time that ClearSCADA logged the Accumulator’s latest Report Value.

Use the attribute in conjunction with the Report Quality status attribute.


Core Configuration Guide - Report Value (Configuring Master Station Accumulators)

Report Value

Associated with: Master Station Accumulators for which ClearSCADA logs data on a Timed Report basis

This status attribute indicates the Accumulator total that ClearSCADA last logged on a Timed Report basis. Timed Report logging is configured using the Accumulator Form’s Timed Report properties (see Specify the Frequency with which ClearSCADA Stores Timed Report Values).

Use the attribute in conjunction with the Report Quality and Report Time status attributes.


Core Configuration Guide - Start of Interval (Configuring Master Station Accumulators)

Start of Interval

Associated with: Master Station Accumulators on which the total is reset on an End of Period basis

This attribute displays the date and time at which the Accumulator’s current or latest End of Period Reset interval started.

Use the attribute in conjunction with the Interval and End of Interval status attributes.


Core Configuration Guide - Configuring Value Maps

Configuring Value Maps

Value Maps are used with Slave drivers (drivers that provide data to another driver). Each Value Map, or Filtered Value Map (depending on the driver) is used by the Slave driver to map ClearSCADA database properties into a simple block of memory within the driver. The Slave driver can then use its native protocol to read the data from the Value Map or Filtered Value Map, and extract the value(s) that are required by its Master. The way in which the Slave driver accesses the data differs, depending on the protocol. For example, the Modbus Slave driver addresses registers by number.

A Value Map or Filtered Value Map can also perform extra processing on the values that it stores, such as scaling or type conversion. Filtered Value Maps can also store alarms and events in addition to ‘point’ values.

The values that are mapped by a Value Map or Filtered Value Map differ, depending on the application. Essentially, you can map any appropriate database value, such as the present state of a channel, or the result of a logic program, to a Value Map or Filtered Value Map. You can also map Variables, such as those representing internal values within the software, or Points that directly represent plant. (For more information on Points, see the ClearSCADA Guide to Core Point Configuration; for information on Variables, see Using Variables to Store Data Values.)

The type(s) of Value Map or Filtered Value Map that you can configure differs, depending on the type of driver. For further information, see Types of Value Map, and see the driver-specific documentation for information on the type(s) of Value Map or Filtered Value Map that are supported by the driver(s) on your system.

To create and configure a Value Map or Filtered Value Map, you need to:

  1. Add a New Value Map
  2. Edit a Value Map
  3. Specify the Map Size
  4. Specify the Number of Events that a Filtered Value Map can Store
    (this step applies to Filtered Value Maps only)
  5. Add an Entry to the Value Map
  6. Repeat step 5 for further variables, points, or other database values.
  7. Save the configuration (see Saving Configuration Changes).

To associate a Value Map or Filtered Value Map with a particular outstation, PLC or other Slave device, you need to specify the Value Map or Filtered Value Map on the relevant Outstation or Source Form (see the driver-specific documentation for further details).


Core Configuration Guide - Types of Value Map (Configuring Value Maps)

Types of Value Map

Refer to the driver-specific documentation for information on whether the driver for which you are mapping data supports Value Maps or Filtered Value Maps. Also refer to the driver-specific documentation for information on which Value Map(s) or Filtered Value Map(s) each driver supports.

The type of data that you can map to a Value Map or Filtered Value Map varies, depending on the application. Where supported by the application, you can map different data types to each Value Map or Filtered Value Map. For example, in addition to mapping single-bit values to a BIT Value Map, you might also choose to map 1-bit of a byte value to that BIT Value Map.

Each slave driver supports one or more of these types of Value Map and Filtered Value Map:
Type | Description
BIT Value Map | Maps single bit binary data.
BYTE Value Map | Maps 8-bit values.
DINT Value Map | Maps signed 32-bit values.
REAL Value Map | Maps IEEE floating point values.
UDINT Value Map | Maps unsigned 32-bit values.
WORD Value Map | Maps unsigned 16-bit values.
Filtered BIT Value Map | Maps single bit binary data.
Filtered BYTE Value Map | Maps 8-bit values.
Filtered DINT Value Map | Maps signed 32-bit values.
Filtered DOUBLE Value Map | Maps IEEE double-precision (64-bit) floating point values.
Filtered REAL Value Map | Maps IEEE floating point values.
Filtered String Value Map | Maps text string values.
Filtered UDINT Value Map | Maps counter-type point data.
Filtered WORD Value Map | Maps unsigned 16-bit values.

Example:

You might decide to:

Map a digital value into a BIT Value Map

Map an analog value into a WORD Value Map

Map a Variable into a WORD Value Map.

For information on adding any of the above to your ClearSCADA system, see Add a New Value Map.


Core Configuration Guide - Add a New Value Map (Configuring Value Maps)

Add a New Value Map

To add a new Value Map or Filtered Value Map to the ClearSCADA database:

  1. Within the Database Bar, right-click on the Group into which you want to place a Value Map or Filtered Value Map.
    A context-sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Value Map option.
    A further context sensitive menu is displayed.
  4. Select the required Value Map or Filtered Value Map option. Some drivers support more than one type of Value Map—for further information, see Types of Value Map and see the driver-specific documentation.
    The new Value Map or Filtered Value Map is added to the selected Group, and is selected automatically, ready for you to define its name.

You can then optionally configure the Value Map’s Identification properties (see Defining Identification Details), or Edit a Value Map.


Core Configuration Guide - Edit a Value Map (Configuring Value Maps)

Edit a Value Map

To edit a Value Map or Filtered Value Map, so that you can alter its configuration, and add or delete points and variables, either:

  1. Double-click on the Value Map or Filtered Value Map in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).
    The map is displayed in Edit mode.

NOTE: If the Database Bar is not displayed, you can access it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

or:

  1. Right-click on the Value Map or Filtered Value Map in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The map is displayed in Edit mode.

While editing a map, you can:

  • Specify the Map Size
  • Specify the Number of Events that a Filtered Value Map can Store (Filtered Value Maps only)
  • Add an Entry to the Value Map
  • Specify the Settings for a Mapped Item
  • Insert an Entry in between Populated Rows
  • Enable Mapping of Individual Bits within a Multi-bit Value Map
  • Delete an Entry from a Value Map.


Core Configuration Guide - Specify the Map Size (Configuring Value Maps)

Specify the Map Size

By default, a new Value Map or Filtered Value Map is given a size of zero. In order to add variables or points to a Value Map or Filtered Value Map, you need to specify a map size other than zero. Specify the size that you require, taking into account the number and type of values that you intend mapping to the Value Map. (Remember that some values may take up more than one row, for example a 32-bit analog will take up 2 consecutive rows of a WORD Value Map (as each row is 1 WORD, or 16 bits).)

ATTENTION: Extremely large Value Maps and Filtered Value Maps may adversely affect system performance. If large quantities of data need transferring, consider using multiple Slave devices. For more information, see Determining the Maximum Acceptable Size of a Value Map.

To specify a new map size:

  1. Display the Map for which you want to specify a new size, in Edit mode (see Edit a Value Map).
  2. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Map Size option.
    The Change Value Map Size window is displayed.
  4. Enter the new map size in the New field.
  5. Select the OK button to confirm the change.
    The Change Value Map Size window is closed, and the corresponding number of address entries appear on the Value Map or Filtered Value Map.


Core Configuration Guide - Determining the Maximum Acceptable Size of a Value Map (Configuring Value Maps)

Determining the Maximum Acceptable Size of a Value Map

Care should be taken when determining the number of entries that can be included in a Value Map. Very large Value Maps can have an adverse affect on system performance.

If large amounts of data need transferring between the Slave and its Master, consider using multiple Slave devices, to logically separate the data into smaller quantities. The Slaves can use the same or different channels, depending on system requirements.

When determining the maximum acceptable size of the Value Maps on your system, take into account the available system resources and the type of communications that are being used. Value Maps with 10,000 or more entries should be used sparingly.


Core Configuration Guide - Specify the Number of Events that a Filtered Value Map can Store (Configuring Value Maps)

Specify the Number of Events that a Filtered Value Map can Store

Filtered Value Maps can store events for the slave device. You can specify the number of events that a Filtered Value Map can store. The default is 50 events. The limit that you specify should take into account the number of events that you expect a Filtered Value Map to store before the driver reads and processes those events and transfers them to the appropriate master. Should the specified limit be exceeded, the oldest events exceeding this limit will be deleted.

To specify the maximum number of events that a Filtered Value Map can store:

  1. Display the Filtered Value Map for which you want to specify a new size, in Edit mode (see Edit a Value Map).
  2. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Max Events option.
    The Change Maximum Value Map Events window is displayed.
  4. Enter the required maximum number of events in the New field.
  5. Select the OK button to confirm the change.
    The Change Maximum Value Map Events window is closed.


Core Configuration Guide - Add an Entry to the Value Map (Configuring Value Maps)

Add an Entry to the Value Map

To add a variable, point, or other value to a Value Map or Filtered Value Map:

  1. Ensure that the variable or point, or other value exists in the ClearSCADA database.
  2. Display the Value Map or Filtered Value Map in Edit mode (see Edit a Value Map).
  3. Ensure that the map has at least one row that has an address, but is otherwise blank. (If no such rows are available, you may need to increase the map size (see Specify the Map Size).)
  4. To map a variable or point to a Value Map or Filtered Value Map:
  1. Display the Database Bar.
  2. Select the variable or point that you want to associate with the Value Map or Filtered Value Map—do not release the mouse button.
  3. Go to Step 6.
  5. To map any other value to a Value Map or Filtered Value Map (for example, the present channel state, or the outstation scanner status):
  1. Display the OPC Data Bar.
  2. Select the value that you want to associate with the Value Map or Filtered Value Map—do not release the mouse button.
  6. Drag the variable or point, or other value over to the next available map row that has an address, but is otherwise blank.
    Drag the required variable, point, or other value over to an available row in the Value Map or Filtered Value Map...

  7. Release the mouse button.
    If the type of variable, point, or other value is supported by this type of Value Map, the selected row is populated with information about the item.

If the variable, point, or other value is not supported by this type of Value Map, the cursor changes shape when you attempt to drag the item onto the Value Map.

NOTE: Depending on the type of value and type of map, more than one row may become populated by an individual value. For example, if you map a 32-bit analog point to a BYTE Value Map, the point will populate 4 consecutive rows (as each row is one BYTE (8 bits) and the analog value is 32 bits long). In such circumstances, you can only map the value if sufficient and consecutive unpopulated rows exist.

  8. Specify any further information about the data that the Value Map or Filtered Value Map needs to store or process for the variable, point, or value (see Specify the Settings for a Mapped Item).
  9. Repeat steps 3 to 7 for any other items that you want to map to the Value Map or Filtered Value Map.
  10. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Specify the Settings for a Mapped Item (Configuring Value Maps)

Specify the Settings for a Mapped Item

The type of information that you need to define for an entry on a Value Map and Filtered Value Map differs, depending on the type of value that it is to map. Some of the information is automatically inherited from each variable, point, or other value when you associate it with the Value Map, other information needs to be added manually to the map. The settings that have to be specified for a mapped item appear in rows under column headings that differ, depending on the type of Value Map.

This section describes:

  • Column Headings for a BIT Value Map
  • Column Headings for other Types of Value Map
  • Column Headings for a Filtered String Value Map
  • Column Headings for a Filtered BIT Value Map
  • Column Headings for other Types of Filtered Value Map.


Core Configuration Guide - Column Headings for a BIT Value Map (Configuring Value Maps)

Column Headings for a BIT Value Map

These column headings are displayed for a BIT Value Map:

  • Address—The unique identifier for the entry within the Value Map. The address is allocated automatically when you Specify the Map Size.
  • Object—The name of the item. This information is inherited from the variable, point, or other type of value when you associate it with the Value Map.
  • Bit Number—Use to specify an individual bit of a multi-bit value (for instance a single bit within a word or byte, or one bit of a multi-bit point).

Leave at the default of zero for mapping a value that only comprises one bit.

Example:

A 3-bit digital point is mapped to a BIT Value Map. In order to read the three bits of the digital value, three identical entries of the same digital are mapped to the Value Map. In order to map the three bits (0, 1, and 2), different bit numbers are allocated to each entry.

Three copies of the same 3-bit digital point are mapped onto a BIT Value Map...
... each entry is used to map a different bit of the 3-bit value. The bit is defined by the bit number that is allocated to each entry.


Core Configuration Guide - Column Headings for other Types of Value Map (Configuring Value Maps)

Column Headings for other Types of Value Map

These column headings are displayed for Value Maps other than BIT Value Maps:

  • Address—The unique identifier for the entry within the Value Map. The address is allocated automatically when you Specify the Map Size.
  • Object—The name of the item. This information is inherited from the variable, point, or other type of value when you associate it with the Value Map.
  • Data Type—The format of the data for the item. The type is inherited from the variable, point, or other value when you associate it with the Value Map.

A Data Type combo box is displayed whenever you select a populated row, allowing you to select another compatible data type if required.

Select a Data Type that:

  • Is suitable for the application for which it is being used
  • Helps ensure that values are converted to a type that supports the data source’s range.

Some precision is lost whenever a larger data type is converted to a smaller data type (for instance, if a WORD value is converted to a BYTE value). Only use such a conversion if this will not result in invalid readings being passed to a Slave’s Master (for example, if a point never rises above a particular value).

If a REAL (floating point) value is converted to any other data type, you should enable scaling (see below) to ensure that any value after the decimal place is not lost.

A BOOL (Boolean) data type will read False if the value is 0 to 1/2 scale, and True if the value over 1/2 scale. As such, if the full range of a BOOL is 0 to 100, the data will read False when the value is below 50, and True when the value is above 50.

Example:

A Modbus analog floating-point value defaults to REAL when mapped to a WORD Value Map.

Due to limited resources at the Modbus Slave, the analog value has to be mapped to an Input Register Map and be reported to the Modbus Master as a Word rather than a REAL Value.

In order to fulfill these requirements, the floating-point value is converted from a REAL to a WORD Data Type, resulting in it taking up only one row of the WORD Value Map (rather than 2 rows for a REAL value).

The value is suitably scaled (see below) for transfer to the Modbus Master.

  • Bit Number—Unused except where a row is converted into a multi-bit value block, in order to read individual bits within a value (see Enable Mapping of Individual Bits within a Multi-bit Value Map).

Where a multi-bit value block is used, specify which bit of a value is mapped to an individual entry in the Value Map. (A multi-bit value block is in effect a BIT Value Map embedded within another type of Value Map.)

  • Scaling—Use to specify whether any scaling is required when data is transmitted between the source (the point, variable, or other value) and the Value Map (a memory block within the Slave).

Choose from:

  • Raw—The value is transferred directly, with no scaling.
  • Scaled—The value is scaled, using the Source and Target ranges specified in the adjacent fields. It is advisable to scale a value if its Data Type is being converted from REAL (IEEE floating-point value) to another data type. Use the settings in the next four columns to specify the scaling that is required when the value is transmitted to the Value Map.
  • Source Full Scale—Used if the Scaling option is set to Scaled. This defaults to the full scale that has been specified for the point. Alter the scale if necessary.
  • Source Zero Scale—Used if the Scaling option is set to Scaled. This defaults to the zero scale that has been specified for the point. Alter the scale if necessary.
  • Target Full Scale—Used if the Scaling option is set to Scaled. Specify the value to which the variable, point, or other value’s full scale is to be scaled when it is read by the Value Map. An equivalent target scale is given by default, which can be altered if required. The default is the full range of the data type, or 100 for REAL types.
  • Target Zero Scale—Used if the Scaling option is set to Scaled. Specify the value to which the variable, point, or other value’s zero scale is to be scaled when it is read by the Value Map. An equivalent target scale is given by default, which can be altered if required.

Example:

A floating-point analog value has been configured to have its Data Type converted from REAL to WORD when mapped to a Value Map. To avoid the analog value being truncated when read by the driver, the value is scaled on the Value Map. The default settings are used, whereby the point’s 0 to 100 scale is converted to 0 to 65535 at the Slave.

At the Slave’s master, the point value is reverse-scaled, whereby the 0 to 65535 scale is converted to a scale of 0 to 100.


Core Configuration Guide - Column Headings for a Filtered String Value Map (Configuring Value Maps)

Column Headings for a Filtered String Value Map

These column headings are displayed for a Filtered String Value Map:

  • Address—The unique identifier for the entry within the Value Map. The address is allocated automatically when you Specify the Map Size.
  • Object—The name of the item. This information is inherited from the variable, point, or other type of value when you associate it with the Value Map.
  • Change Detection Type—Filtered Value Maps can store alarms and events for the slave device, to indicate string changes. Use this column to specify whether the Filtered String Value Map is to store any such alarms or events for each mapped value. Choose from:
  • None—The default option. The Filtered Value Map does not store any alarms or events that the source generates as a result of a change in string value.
  • Event on Change—The Filtered Value Map stores any events that the source generates as a result of the string changing value.
  • Alarm on Keyword—The Filtered Value Map generates an alarm whenever the string includes the trigger phrase specified in the Alarm Trigger Phrase column (see below).
  • Alarm Trigger Phrase—Only used when the Change Detection Type (see above) is set to Alarm on Keyword. Enter the phrase that may be included in the string that is retrieved for this entry. Whenever the string includes this phrase, the Filtered Value Map creates an alarm entry for this change.
  • Class—The type of data that the slave reports to its master has to be assigned a class. The class is used at the master to assess which type of data to retrieve from the slave. For example, on DNP3, Class 0 specifies static data (present values and states).

Each Class row within a Filtered Value map is automatically assigned as Class 0 when a variable, point, or other value is allocated to that row. Alter from the default if a different class is required.


Core Configuration Guide - Column Headings for a Filtered BIT Value Map (Configuring Value Maps)

Column Headings for a Filtered BIT Value Map

Filtered BIT Value Maps contain the same column headings as BIT Value Maps (see Column Headings for a BIT Value Map), plus these column headings:

  • Alarm or Event—Use to indicate whether the reason that a value has changed is due to an alarm or an event. When the Master requests any changes, the Slave reports this information as well as the value itself. Typically, select Alarm if the change is to be reported immediately, or Event if the change is just to be logged.

(To specify the maximum number of events that can be stored, see Specify the Number of Events that a Filtered Value Map can Store.)

  • Event Change Detection—Filtered Value Maps can store events for the slave device. Use this column to specify which type(s) of event a Filtered Value Map is to store for each value. Choose from:
  • Filtered Chronological Update—The default option. The Filtered Value Map generates and stores events whenever a source value changes, provided that:
  • The source value has changed state.

and:

  • The time stamp indicates that the value change is newer than the last update.
  • Generated on Update—The Filtered Value Map generates and stores events whenever a bit value changes state. This option will also generate events if the time stamp of the update is older than the previous update.

Select either this option, or the Filtered Chronological Update option, if the data sources do not have historic data, or you do not want to use the source’s historic data. The Filtered Value Map will generate events for the source value changes.

  • Reason for Logging—The Filtered Value Map stores those source events that fulfill the criteria specified in the Reason Mask column (see below), rather than events generated by the bit value changing state.

Select this option if the data sources do have historic data, and ClearSCADA is to use that historic data for the events.

  • Reason Mask—Only used when the Event Change Detection (see above) is set to Reason for Logging. A data source might store values historically for one of many reasons. Use the Reason Mask to specify which of those logged values a Filtered Value Map is to retrieve and store for an entry.The Reason Mask is a comma-separated list. By default, it lists each of the reason(s) for which the source might have stored a value historically. Use the list to specify which of those logged values the Filtered Value Map is to retrieve and store historically. The list varies, depending on the type of Filtered Value Map—delete any reasons that are not required.

The types of event that a Filtered Value Map might store include:

  • Value Change—The Filtered Value Map stores the event that the source logs whenever a change in value occurs.
  • State Change—The Filtered Value Map stores the event that the source logs whenever a change of state occurs.
  • Report—The Filtered Value Map stores the event that the source logs on timed report (background logging that occurs at regular intervals).
  • End of Period—The Filtered Value Map stores the event that the source logs as an End of Period value.
  • End of Period Reset—The Filtered Value Map stores the event that the source logs due to an End of Period reset.
  • Override—The Filtered Value Map stores the event that the source logs whenever an outstation override occurs.
  • Release—The Filtered Value Map stores the event that the source logs whenever an outstation override is released.

Example:

For a Filtered Value Map to store those events that a source generates whenever a value changes state, is overridden, or has an override removed, set the Event Change Detection to Reason for Logging and specify the following Reason Mask:

State Change, Override, Release

In addition to the above, add CDR to the comma-separated list if you want the Filtered Value Map to store current values historically.

  • Class—The type of data that the slave reports to its master has to be assigned a class. The class is used at the master to assess which type of data to retrieve from the slave. For example, on DNP3, Class 0 specifies static data (present values and states).

Each Class row within a Filtered Value map is automatically assigned as Class 0 when a variable, point, or other value is allocated to that row. Alter from the default if a different class is required.


Core Configuration Guide - Column Headings for other Types of Filtered Value Map (Configuring Value Maps)

Column Headings for other Types of Filtered Value Map

Filtered Value Maps other than Filtered BIT Value Maps and Filtered String Value Maps contain the same column headings as Value Maps (see Column Headings for other Types of Value Map), plus these additional column headings:

  • Event Change Detection—Filtered Value Maps can store events for the slave device. Use this column to specify which type(s) of event a Filtered Value Map is to store for each value. Choose from:
  • Filtered Chronological Update—The default option. The Filtered Value Map generates and stores events whenever a source value changes, provided that:
  • The source value either exceeds any of the thresholds specified in the Limit fields, or changes by the Sig Change Deadband or more.

and:

  • The time stamp indicates that the value change is newer than the last update.
  • Generated on Update—The Filtered Value Map generates and stores events whenever a source value exceeds any thresholds specified in the Limit fields, or changes by the Sig Change Deadband or more (see below). This option will also generate events if the time stamp of the update is older than the previous update.

Select either this option, or the Filtered Chronological Update option, if the data sources do not have historic data, or you do not want to use the source’s historic data. The Filtered Value Map will generate events for the source value changes.

  • Reason for Logging—The Filtered Value Map stores those source events that fulfill the criteria specified in the Reason Mask column (see below), rather than events generated by exceeding any thresholds specified in the Limit fields.

Select this option if the data sources do have historic data, and ClearSCADA is to use that historic data for the events.

The four deadband limits are used within each Filtered Value Map to indicate whether a change in value has caused a change in state—if so, this is stored as an alarm at the Value Map, and is reported to the Master as part of the ‘reasons for change’ for that value. You can specify four deadband limits:

  • Low Low Limit—Specify the limit below which the value is deemed to be in the Low Low state. If the value changes and crosses this or any of the other limit deadbands (see below), the occurrence is raised as an alarm, and the alarm is reported to the Master as part of the ‘reasons for change’ for that value.
  • Low Limit—Specify the limit below which the value is deemed to be in the Low state.
  • High Limit—Specify the limit above which the value is deemed to be in the High state.
  • High High Limit—Specify the limit above which the value is deemed to be in the High High state.

These column headings are also displayed for each Filtered Value Map:

  • Sig Change Deadband—If a value changes by this amount or more, it is deemed to have changed significantly. If the value changes significantly, but does not cross one of the four limit deadband (for example, High), the occurrence is logged as an event. This is reported to the Master as part of the ‘reasons for change’ when the Master requests data from the Slave.
  • Reason Mask—Only used when the Event Change Detection (see above) is set to Reason for Logging. A data source might store values historically for one of many reasons. Use the Reason Mask to specify which of those values a Filtered Value Map is to retrieve and store for an entry.The Reason Mask is a comma-separated list. By default, it lists each of the reason(s) for which the source might have stored a value historically. Use the list to specify which of those logged values the Filtered Value Map is to retrieve and store historically. The list varies, depending on the type of Filtered Value Map—delete any reasons that are not required.

The types of event that a Filtered Value Map might store include:

  • Value Change—The Filtered Value Map stores the event that the source logs whenever a change in value occurs.
  • State Change—The Filtered Value Map stores the event that the source logs whenever a change of state occurs.
  • Report—The Filtered Value Map stores the event that the source logs on timed report (background logging that occurs at regular intervals).
  • End of Period—The Filtered Value Map stores the event that the source logs as an End of Period value.
  • End of Period Reset—The Filtered Value Map stores the event that the source logs due to an End of Period reset.
  • Override—The Filtered Value Map stores the event that the source logs whenever an outstation override occurs.
  • Release—The Filtered Value Map stores the event that the source logs whenever an outstation override is released.

Example:

For a Filtered Value Map to store those events that a source generates whenever a value changes state, is overridden, or has an override removed, set the Event Change Detection to Reason for Logging and specify the following Reason Mask:

State Change, Override, Release

In addition to the above, add CDR to the comma-separated list if you want the Filtered Value Map to store current values historically.

  • Class—The type of data that the slave reports to its master has to be assigned a class. The class is used at the master to assess which type of data to retrieve from the slave. For example, on DNP3, Class 0 specifies static data (present values and states).

Each Class row within a Filtered Value map is automatically assigned as Class 0 when a variable, point, or other value is allocated to that row. Alter from the default if a different class is required.


Core Configuration Guide - Insert an Entry in between Populated Rows (Configuring Value Maps)

Insert an Entry in between Populated Rows

You can re-order a map so that one or more unused rows are made available within an already populated section of a map. This feature does not add any extra rows to the Value Map or Filtered Map, but merely re-orders to existing rows to insert the specified number of unused rows within rows that are already populated. The procedure works on the principle that the required number of unused rows exist at the end of the map, in the higher address range, and moves the specified number of these rows to the area that you indicate on the map.

To insert unused row(s) within a populated section of a map:

  1. Ensure that the required number of unused rows exist at the end of the map, in the highest address range. If they do not, add further rows to the map (see Specify the Map Size).
  2. Right-click on the populated row above which you want to make row(s) available for adding other variables or points.
    A context sensitive menu is displayed.
  3. Select the Insert Entries option.
    The Insert Entries window is displayed.
  4. Specify the numbers of rows that you want to make available for use.

If you specify a number that is greater than the number of unused rows at the bottom of the map, a diagnostic message is displayed:

Cancel the move if you do not want to lose any entries. If necessary, you can add further rows to the map (see Specify the Map Size).

  5. To proceed with you request to move the row(s), select the OK button.
    The Insert Entries window is closed, and the contents of the rows from the selected one downwards are moved down by the number of rows that you specified.

You can now Add an Entry to the Value Map at the location of the newly inserted unused row(s).

Example:

A Value Map has a size of 10, with variables allocated to addresses 0 to 3.

A 2-bit variable needs inserting into the map at addresses 0 to 1. As these addresses are already populated, the Insert Entries option is used to insert two unused rows above the top row.

This results in the populated rows from row 0 onwards being moved down two rows, so that rows 0 and 1 become available for use.

The Value Map retains its map size of 10, but the information that populated addresses 0 to 3, now populates addresses 2 to 5.


Core Configuration Guide - Enable Mapping of Individual Bits within a Multi-bit Value Map (Configuring Value Maps)

Enable Mapping of Individual Bits within a Multi-bit Value Map

With BYTE, DINT, UDINT, and WORD Value Maps and Filtered Value Maps, you can choose to map individual bits of a value, rather than the whole byte or word, and so on.

To map single bits of a value in one of the above map types:

  1. Right-click on an unused row in a BYTE, DINT, UDINT, or WORD Value Map or Filtered Value Map.
    A context-sensitive menu is displayed.
  2. Select the Convert to bit mapped value option.
    The row is converted to a multi-bit block. The number of rows in the block varies, depending on the type of map (8 for a BYTE, 16 for a WORD, and 32 for DINT and UDINT).
  3. Expand the block and populate the rows as required, to each map individual bits of a variable, point, or other value.

If you try to convert a populated row to a bit mapped value, a message is displayed, warning that the existing mapped reference will be lost.

Example:

To convert an unused row in a BYTE Value Map:

Right-click on an unused row and choose to convert the row to a bit mapped value block...
...then expand the newly formed block in order to display the new rows. Populate the rows as required.

To convert a multi-bit block back to a single row, in order to map a whole byte, DINT, UDINT, or Word:

  1. Right-click on the row labelled ‘Multi-bit’, at the top of the multi-bit block.
    A context sensitive menu is displayed.
  2. Select the Convert to word mapped value option.
    The multi-bit block converts to a single row.

If you try to convert a populated block back to a single row, a message is displayed, warning that the existing mapped reference(s) will be lost.


Core Configuration Guide - Delete an Entry from a Value Map (Configuring Value Maps)

Delete an Entry from a Value Map

To delete an entry from a Value Map or Filtered Value Map:

  1. Select the row so that it is highlighted.
  2. Either:
  1. Press the Delete key.

or:

  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Delete option.

The row becomes unpopulated.


Core Configuration Guide - Configuring Data Grids

Configuring Data Grids

The ClearSCADA database consists of a series of pre-configured tables. For example, basic information for each of the points in a ClearSCADA system is contained in the CDBPoint table. For information about the database table hierarchy, see Understanding the Database in the ClearSCADA Guide to the Database.

You can use Data Grids to add ‘custom’ tables to your database. Data Grids are not general purpose tables in which to store user data. Instead, Data Grids are used to collate, organize and summaries data from elsewhere in the database, in a tabular format that can be queried from, for example, a List or a Report. (If you require general purpose tables for storing data, consider using Data Tables (see Configuring Data Tables) as opposed to Data Grids.)

A Data Grid’s table consists of user-defined fields and a user-defined number of records. Each cell in the table contains an expression that calculates a value. The expression can simply map a value from an item in the database, be a simple literal (constant) value, or a more complex calculation.

You can then configure, for example, a Report, to access the Data Grid’s table, in order to display the results of each calculation.

Operators can display a Data Grid’s table as a List and navigate and sort the data in that List.

You can map values into a Data Grid, and optionally perform calculations on those data values...
...so that operators can, for example, view the resulting information in List format, or to use the information in a Report.

A Data Grid is a document (as is a Mimic, or a Trend) and as such is configuration, as opposed to data. Therefore, by changing the content of a Data Grid, you are re-configuring the system.

To create and configure a Data Grid, you need to:

  1. Add a Data Grid.
  2. Configure the Properties on the Data Grid Form.
  3. Edit a Data Grid.
  4. Specify the Data Grid Size.
  5. Add an Entry to a Data Grid.
  6. Repeat step 5 for any further entries in the Grid.
  7. Save the configuration (see Saving Configuration Changes).

You can then, if required, use the Data Grid’s table in a Report (see the ClearSCADA Guide to Crystal Reports).


Core Configuration Guide - Add a Data Grid (Configuring Data Grids)

Add a Data Grid

To add a Data Grid to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a Data Grid.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Data Grid option.
    A Data Grid is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Data Grid (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added a Data Grid to the system, you can then Configure the Properties on the Data Grid Form, or Edit a Data Grid and add entries to that Grid.


Core Configuration Guide - Configure the Properties on the Data Grid Form (Configuring Data Grids)

Configure the Properties on the Data Grid Form

To configure the properties on the Data Grid Form, you need to display the Form. For information, see Display a Form. You can also display the Data Grid Form from the Queries Bar. Right-click on the required Data Grid entry in the Queries Bar to display a context sensitive menu. Select the Properties option from the menu to display the Data Grid Form.

The Data Grid Form has these tabs:

  • Identification—Use to configure the Identification properties (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the Data Grid (see Using the User Methods Tab to Define Custom Actions).
  • Data Grid—Use to define the Table name and Title:
  • Table Name—Enter a unique name for the Data Grid table, as you want it to appear in the ClearSCADA database.

The name has to begin with an alphabetical character and contain only alphanumeric or underscore characters (see Naming Restrictions).

Ensure that the Table Name is not identical to that of any built-in table, other Data Grid table, or any other ‘custom’ tables, including Historic Views.

We advise that Table Names do not start with the letter ‘C’, to avoid confusion with built-in tables.

  • Title—Enter a unique title for the Data Grid. This is the title of the Data Grid when it is displayed in List format. The title can include character spaces.


Core Configuration Guide - Edit a Data Grid (Configuring Data Grids)

Edit a Data Grid

To edit a Data Grid, so that you can specify its size and configure the Grid cells, either:

  1. Double-click on the Data Grid in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).
    The Data Grid is displayed in Edit mode.

NOTE: If the Database Bar is not displayed, you can access it by selecting the View menu, followed by the Explorer Bar option and then the Database option.

or:

  1. Right-click on the Data Grid in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Data Grid is displayed in Edit mode.
    Field heading
    Row number
    Cell

or:

  1. Select the Queries button [image] from the Operate Toolbar.
    The Queries Bar is displayed.
  2. Right-click on the required Data Grid entry in the Queries Bar.
    A context sensitive menu is displayed.
  3. Select the Edit option.
    The Data Grid is displayed in Edit mode.

When editing a Data Grid, you can:

  • Specify the Data Grid Size
  • Add Fields to a Data Grid
  • Specify the Field Properties
  • Add an Entry to a Data Grid
  • Add Additional Rows to a Data Grid
  • Insert New Cells in Between Populated Cells
  • Clear the Contents from One or More Cells
  • Move the Contents from One or More Cells
  • Delete Cells from a Data Grid
  • Use Keyboard Shortcuts.


Core Configuration Guide - Specify the Data Grid Size (Configuring Data Grids)

Specify the Data Grid Size

By default, a new Data Grid has no rows or fields (columns). In order to add entries to a Data Grid, you need to specify at least one row and field (column) in the Data Grid.

To specify row(s) and field(s) in a Data Grid:

  1. Edit a Data Grid.
  2. Either:
  • Add Fields to a Data Grid
  • Add Additional Rows to a Data Grid.

You can also:

  • Insert New Cells in Between Populated Cells
  • Delete Cells from a Data Grid.


Core Configuration Guide - Add Fields to a Data Grid (Configuring Data Grids)

Add Fields to a Data Grid

You can add single or multiple fields to a Data Grid. The procedures below list the steps that you follow in order to insert a single field. To insert more than one field, either drag over a block of field headings or cells, or see Keyboard Shortcuts for other ways of making multiple selections. The number and location of the field headings or cells that you select determines the number and location of the fields that are inserted to the left of your selection.

Example:

If you select a block of four fields and choose to insert additional fields in that Data Grid, a block of four new fields will be inserted to the left of the selected block of fields.

If you select four fields in different parts of the Data Grid and choose to insert additional fields into that Grid, one additional field will be inserted to the left of each selected field.

To add a field (column) to a Data Grid, either:

  1. Right-click on a field heading to the right of where you want to insert a new field.
    A context sensitive menu is displayed.
  2. Select the Insert option.
    A new field is added to the left of the existing field.
    Select a field heading...
    ...to display a pop-up menu, from which you select the ‘Insert’ option.

Or:

  1. Select a cell or field heading to the right of where you want to insert a new field.
  2. Select the Insert menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Column option.
    A new field is added to the left of the existing field.

Or:

  1. Right-click on a cell to the right of where you want to insert an additional field.
    A context sensitive menu is displayed.
  2. Select the Insert option.
    The Insert window is displayed.
  3. Select the Entire column option button.
  4. Select the OK button.
    The Insert window is closed and a new field is inserted to the left of the specified column.

When you have added to required number of fields, you need to Specify the Field Properties for those fields.


Core Configuration Guide - Specify the Field Properties (Configuring Data Grids)

Specify the Field Properties

Once you Add Fields to a Data Grid, follow this procedure to specify the properties for that field:

  1. Right-click on the field heading in the Data Grid Editor.
    A context sensitive menu is displayed.
  2. Select the Properties option.
    The Field Properties window is displayed.
  3. Use the Field Properties Window to specify the field’s properties (such as the type of data that the field is to contain).
  4. Repeat steps 1 to 3 for any other fields for which you want to specify the properties.


Core Configuration Guide - Use the Field Properties Window (Configuring Data Grids)

Use the Field Properties Window

Use the Field Properties window to specify the properties for a field in a Data Grid. The Field Properties window contains these fields:

  • Name—Use to specify a unique name for the field. The name has to begin with an alphabetic character, and can thereafter contain a mix of alphanumeric and underscore characters, but no spaces.
  • Type—Use this combo box to specify the type of data that the field is to contain. The option that you select here affects the type of value that the field supports and the options that are available from the pop-up menu for the cells.

Where a field is to contain data that is mapped from other item(s) in the database (see Map a Property of an Item in the Database), you typically specify the same type of data as that which is being mapped.

When defining the expressions for the field’s cells, ensure that each expression calculates a value that is compatible with the type of field. (For information on entering more complex expressions, see Add an Entry to a Data Grid.)

Specify the required field Type from these options:

  • Byte—The field is to contain unsigned 8-bit values.
  • Word—The field is to contain signed 16-bit values.
  • Unsigned Word—The field is to contain unsigned 16-bit values.
  • Long—The field is to contain signed 32-bit values.
  • Unsigned Long—The field is to contain unsigned 32-bit values.
  • Float—The field is to contain IEEE single-precision floating point 32-bit values.
  • Double—The field is to contain IEEE double-precision floating point 64-bit values.

For more information on literal numeric values in expressions, see Number (Integer or Real) in the ClearSCADA Guide to Expressions.

  • Reference—The field is to contain references to items in the database. The items’ identifiers will form the cells’ values. Use the Table field to select the table that the field’s entries are to reference.

For information on entering an expression in a Reference field’s cell, see Specify a Constant Reference.

  • String—The field is to contain alphanumeric strings. Use the Size field (see below) to specify the maximum string length.

For information on literal String values in expressions, see String in the ClearSCADA Guide to Expressions.

If the Dictionary feature is used on your system, you can prefix strings in Data Grid cells, in order for those strings to be replaced with another term, when displayed in a List or on a Mimic, in ViewX. For more information, see Dictionary Settings in the ClearSCADA Guide to Server Administration. Ensure that you include the @ prefix within the String’s single quotes.

  • Boolean—The field is to contain Boolean (0 or 1) values and display those values as ‘True’ or ‘False’. For more information on Boolean values, see Boolean in the ClearSCADA Guide to Expressions.
  • Time—The field is to contain date or time values.

For information on literal date and time values in expressions, see Date and Time in the ClearSCADA Guide to Expressions.

  • Color—The field is to contain color values in RGB format. For example, RGB(255, 255, 128) for bright yellow. Only select this option if the client application that is to use the Grid’s data can decipher the data as color values.

For information on entering an expression in a Color field’s cell, see Specify a Constant Color Value.

  • Size—Only applies when the Type of field is specified as ‘String’. Use the spin box to specify the maximum acceptable string length for the field’s rows.

The client application that accesses the Grid’s table may use the size, for example, to truncate any strings that are longer than this size. There is no limit to the length of a string within a Data Grid.

  • Table—Only applies when the Type of field is specified as ‘Reference’. Use the combo box to specify the database table that the field’s rows are to reference. The choice restricts the browser so that it only displays items in the specified table.

The Table options vary, depending on the drivers that are installed on your system. For information on database tables and the database hierarchy, see Understanding the Database in the ClearSCADA Guide to the Database, and see Working with the Database Schema in the ClearSCADA Guide to the Database.


Core Configuration Guide - Add an Entry to a Data Grid (Configuring Data Grids)

Add an Entry to a Data Grid

Each cell in a Data Grid contains an expression that calculates its value. As such, the entries in a Data Grid are configuration, as opposed to data, even if the expression is just a literal (fixed) value.

Within each cell you can specify a simple expression that just maps a property of an item in the database, or just contains a constant. Alternatively, you can specify more complex expressions that make use of a range of operators and functions. For details about configuring such expressions, see Welcome to the Guide to Expressions in the ClearSCADA Guide to Expressions, and see Data Grid Expressions in the ClearSCADA Guide to Expressions.

When defining any type of expression in a Data Grid’s cell, ensure that the expression calculates a value that is compatible with the type of field to which the cell belongs (see Specify the Field Properties). (If an expression does not evaluate to the same type as the field, ClearSCADA will attempt to coerce the value to the correct type. For instance, it will convert the string ‘123’ to the number 123. If such a conversion is unsuccessful or not possible—for instance, it cannot convert the string ‘abc’ to a number—ClearSCADA will generate a diagnostic message when the table is queried.)

The Data Grid Editor contains features to allow you to build various expressions.

To include plain text in a Data Grid cell, enter the text in single quotes, for example ‘This is plain text’.

To view an expression if it overruns the visible area of a Data Grid cell, place the cursor over the cell—the full cell content is displayed in a ToolTip.

To replace the whole expression in a Data Grid cell, you can choose to:

  • Map a Property of an Item in the Database
  • Calculate a Value from a Block of Historic Data
  • Specify a Constant Reference
  • Specify a Constant Color Value.

To build up a more complex expression, you can:

  • Use an Expression to Define the Cell Content
  • Use a Flowchart to Build an Expression.


Core Configuration Guide - Map a Property of an Item in the Database (Configuring Data Grids)

Map a Property of an Item in the Database

To simply map a property of an item to a cell in a Data Grid, either:

  1. Select the OPC button [image] from the Operate Toolbar.
    The OPC Data Bar is displayed.
  2. Drag the required property from the OPC Data Bar into the relevant Data Grid cell.
    Drag the required value from the OPC Data Bar into the required Data Grid cell.

When you drag a property into a cell, the path to that property is relative to the Data Grid’s location. To specify an absolute path, hold down the SHIFT key while you drag the property into a cell.

Or:

  1. Right-click on the required cell in the Data Grid.
    A context sensitive menu is displayed.
  2. Select the Tag option.
    OPC ‘tags’ (database properties) are displayed in a Select Tag window.
  3. Select the required tag from the window and use the window to specify whether the path for that tag is relative or absolute. For more information, see Property Tags in the ClearSCADA Guide to Expressions.
  4. Select the OK button.
    The Select Tag window is closed. The specified tag is displayed in the Data Grid cell.

Or:

  1. Select the Database button [image] from the Operate Toolbar.
    The Database Bar is displayed.
  2. Perform one of the following:
  • For the path to the property to be relative to the Data Grid’s location, drag the required item from the Database Bar into the relevant Data Grid cell.
  • For the path to the property to be absolute, hold down the SHIFT key while you drag the property from the Database Bar into the required cell.

The expression uses the default property of the item (except if the field Type is set to ‘Reference’, in which case the item’s ID is used).

Example:

If you drag a point from the Database Bar into a Data Grid cell, the cell’s expression is the current value of the point.


Core Configuration Guide - Calculate a Value from a Block of Historic Data (Configuring Data Grids)

Calculate a Value from a Block of Historic Data

You can specify a block of historic data in the database and have ClearSCADA perform a calculation on that data. The result of the calculation can form the value of an expression in a Data Grid cell. In order to perform such a calculation:

  • The Field has to have a numeric Type (see Use the Field Properties Window)
  • ClearSCADA has to be configured to log values historically for the item for which you want to perform the calculation.

To use the result of such a calculation for an expression a cell in a Data Grid, either:

  1. Select the OPC Historic button [image] from the Operate Toolbar.
    The OPC Historic Data Bar is displayed.
  2. Perform one of the following:
  • For the path to the property to be relative to the Data Grid’s location, drag the required item from the OPC Historic Data Bar into the relevant Data Grid cell.
  • For the path to the property to be absolute, hold down the SHIFT key while you drag the property from the OPC Historic Bar into the required cell.

By default, the result of the expression is the average value of the selected item during the current hour.

Or:

  1. Right-click on the required cell in the Data Grid.
    A context sensitive menu is displayed.
  2. Select the Historic Tag option.
    Database items that have historic properties (historic ‘tags’) are displayed in a Select Historic Tag window.

  3. Select the required entry from the hierarchical tree structure and then use the fields in the window to specify:
  • Whether the path for the tag is to be relative or absolute
  • The calculation that ClearSCADA is to perform on the data
  • The block of historic data that ClearSCADA is to use for the calculation.

For more information on using the window, see OPC Historic Tags in the ClearSCADA Guide to Expressions.

  4. Select the OK button.
    The Select Historic Tag window is closed. The specified tag is displayed in the Data Grid cell.


Core Configuration Guide - Specify a Constant Reference (Configuring Data Grids)

Specify a Constant Reference

You can enter a simple expression in a Data Grid cell that contains just the reference to an item in the database.

To specify a reference ID, ensure that the field Type is set to ‘Reference’ (see Specify the Field Properties), then either:

  1. Select the Database button [image] from the Operate Toolbar.
    The Database Bar is displayed.
  2. Perform one of the following:
  • For the path to the property to be relative to the Data Grid’s location, drag the required item from the Database Bar into the relevant Data Grid cell.
  • For the path to the property to be absolute, hold down the SHIFT key while you drag the property from the Database Bar into the required cell.

The item’s ID forms the result of the expression.

Or:

  1. Right-click on the required cell in the Data Grid.
    A context sensitive menu is displayed.
  2. Select the Object option.
    The Select Object window is displayed.
  3. Use the window to:
  1. Select the item that the cell is to reference.
  2. Specify whether the path for the reference is to be relative or absolute.


Core Configuration Guide - Specify a Constant Color Value (Configuring Data Grids)

Specify a Constant Color Value

You can map a color to a cell if the field Type supports color values and the client application that is to use the Grid’s data can decipher the data as color values.

Be aware that the results of color expressions are displayed as raw integer values in Data Grid Lists.

To simply map a particular color value to a cell in a Data Grid:

  1. Ensure that the field Type is set to ‘Color’ (see Use the Field Properties Window).
  2. Right-click on the required cell in the Data Grid.
    A context sensitive menu is displayed.
  3. Select the Color option.
    The Color window is displayed.
  4. Use the Color window to select an existing basic or custom color, or to specify a new custom color (see Using the Color Window).
  5. Select the OK button on the Color window.
    The Color window is closed. The expression in the Data Grid cell uses the built-in RGB function to return the selected color.


Core Configuration Guide - Use an Expression to Define the Cell Content (Configuring Data Grids)

Use an Expression to Define the Cell Content

If you are experienced in writing expressions, you can specify an expression to define the content of a Data Grid cell. (For information on writing expressions, see Welcome to the Guide to Expressions in the ClearSCADA Guide to Expressions, and see Data Grid Expressions in the ClearSCADA Guide to Expressions.)

To specify an expression, either:

  1. Enter the expression manually within the required cell.

Or:

  1. Right-click on the required cell in the Data Grid.
    A context sensitive menu is displayed.
  2. Select the Properties option.
    The Expression window is displayed.
  3. Use the Expression field within the window to specify the required expression.

Example:

The expression can contain a combination of manually-typed and automatically entered code (see Working with the Expression Window in the ClearSCADA Guide to Expressions).

  4. Select the OK button on the Expression window.
    The Expression window is closed. The expression is displayed in the Data Grid cell.


Core Configuration Guide - Use a Flowchart to Build an Expression (Configuring Data Grids)

Use a Flowchart to Build an Expression

If you want to use an expression that comprises a series of Boolean comparisons, you can use the Flowchart Editor to graphically build that expression:

  1. Right-click on the required cell in the Data Grid.
    A context sensitive menu is displayed.
  2. Select the Flow Chart option.
    The Expression Flowchart window is displayed.

The Expression Flowchart window allows you to create IIF expressions in a diagram format.

  3. Build the required expression using the Flowchart window. (For more information on using the Expression Flowchart window, see Expression Flowchart in the ClearSCADA Guide to Expressions.)

Example:

Use the Expression Flowchart window to create an IIF expression in diagrammatic format...

  4. Select the OK button on the Expression Flowchart window.
    The window is closed and the expression entered in the Data Grid cell.

Example:

...the same IIF expression is displayed in textual format within the Data Grid cell.


Core Configuration Guide - Add Additional Rows to a Data Grid (Configuring Data Grids)

Add Additional Rows to a Data Grid

You can add single or multiple rows to a Data Grid. The procedures below list the steps that you follow in order to insert a single row. To insert more than one row, either drag over a block of rows, or see Keyboard Shortcuts for other ways of making multiple selections. The number and location of the rows that you select determines the number and location of the rows that are inserted immediately above your selection. (To add a row to a Data Grid that contains no rows, see Add Rows to an Empty Data Grid.)

Example:

If you select a block of four rows and choose to insert additional rows in that Data Grid, a block of four new rows will be inserted immediately above the selected block of rows.

However, if you select four rows in different parts of the Data Grid and choose to insert additional rows into that Grid, one additional row will be inserted immediately above each selected row.

To insert an additional row in a Data Grid, either:

  1. Right-click on the number of the row above which you want to insert an additional row.
    A context sensitive menu is displayed.
  2. Select the Insert option.
    A new row is inserted above the specified row.
    Select the number of the row above which you want to insert a new row...
    ...to display a pop-up menu, from which you select the ‘Insert’ option.

Or:

  1. Select the cell or row number above which you want to insert an additional row.
  2. Select the Insert menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Row option.
    A new row is inserted above the specified row.

Or:

  1. Right-click on the cell or row number above which you want to insert an additional row.
    A context sensitive menu is displayed.

NOTE: Do not select a field heading—the Insert option for a field heading inserts a new field (column) not a new row.

  2. Select the Insert option.
    The Insert window is displayed.
  3. Select the Entire row option button.
  4. Select the OK button.
    The Insert window is closed and a new row is inserted above the specified row. Any affected rows are renumbered accordingly.


Core Configuration Guide - Add Rows to an Empty Data Grid (Configuring Data Grids)

Add Rows to an Empty Data Grid

It is possible to delete all of the rows in a Data Grid, such that the Data Grid only contains field headings:

A Data Grid in which all rows have been deleted.

To add a row to such a Data Grid, either:

  1. Right-click on the blank heading cell to the left of the first field heading.
    A context-sensitive menu is displayed.
    Right-click on the empty heading cell...
    ...to display a context-sensitive menu.

  2. Select the Insert option.
    A row is inserted below the heading cells.

Or:

  1. Select the Insert menu from the ViewX menu bar.
    A context-sensitive menu is displayed.
  2. Select the Row option.
    A row is inserted below the heading cells.

To add further rows, either repeat the above procedure, or see Add Additional Rows to a Data Grid.


Core Configuration Guide - Insert New Cells in Between Populated Cells (Configuring Data Grids)

Insert New Cells in Between Populated Cells

You can add single or multiple cells to a Data Grid. The procedures below list the steps that you follow in order to insert a single cell. To insert more than one cell, either drag over a block of cells, or see Keyboard Shortcuts for other ways of making multiple selections. The number and location of the cells that you select determines the number and location of the cells that are inserted immediately above or to the left of your selection.

Example:

If you select a block of four cells and choose to insert additional cells to the left of those cells in the Data Grid, a block of four new cells will be inserted to the left of the selected block of cells.

However, if you select four cells in different parts of the Data Grid and choose to insert additional cells to the left of those cells, one additional cell will be inserted to the left of each selected cell.

ATTENTION: Be aware that the insertion of additional cells has the effect of moving existing cells to the right or further down from their present position in a Data Grid. You need to ensure that you make the necessary provisions to avoid losing the content of any cells that exist to the far-right or the last row in a Data Grid. Also be aware that causing an existing cell to move into a different field type may affect the resulting value of that cell.

You can use one of two procedures to add an individual cell to a populated Data Grid:

To insert a new cell and move existing cells to the right:

  1. Select the cell to the right of the point at which you want to insert an additional cell.
  2. Either:
  1. Select the Insert menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Cells option.
    The Insert window is displayed.

Or:

  1. Right-click on the cell.
    A context sensitive menu is displayed.
  2. Select the Insert option.
    The Insert window is displayed.
  3. Ensure that the Shift cells right option button is selected.
  4. Select the OK button.
    The Insert window is closed. A new cell is added at the specified location. Existing cells to the right of the new cell are shifted to the right to make way for the new cell.

To insert a new cell and move existing cells down:

  1. If the bottom-most cell in the column to which a new cell is being added is populated, ensure that you make the necessary provisions to avoid losing the content of that cell.
  2. Select the cell above which you want to insert an additional cell.
  3. Either:
  1. Select the Insert menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Cells option.
    The Insert window is displayed.

Or:

  1. Right-click on the cell.
    A context sensitive menu is displayed.
  2. Select the Insert option.
    The Insert window is displayed.
  3. Ensure that the Shift cells down option button is selected.
  4. Select the OK button.
    The Insert window is closed. A new cell is added at the specified location. Existing cells that appear below the new cell are shifted down to make way for the new cell.


Core Configuration Guide - Clear the Contents from One or More Cells (Configuring Data Grids)

Clear the Contents from One or More Cells

You can clear the content from one or more cells in a Data Grid so that the cells remain in the Grid but are devoid of content. To clear the content of more than one cell, either drag over a block of cells, fields, or rows, or see Keyboard Shortcuts for other ways of making multiple selections.

To clear the complete expression from one or more individual cells:

  1. For multiple cells, select the required cells (for a single cell, go straight to step 2).
  2. Right-click on the cell(s).
    A context sensitive menu is displayed.
  3. Select the Clear Contents option.
    The expressions are cleared from the selected cell(s).

To clear the complete expressions from whole fields or rows of cells:

  1. For multiple fields or rows, either:
  • Select the required field heading(s).
  • Select the required row number(s).

(For a single field or row, go straight to step 2.)

  2. Right-click on one of the selected fields or rows.
    A context sensitive menu is displayed.
  3. Select the Clear Contents option.
    The expressions are cleared from the selected fields or rows (depending on your selection in step 1).

To clear the part of an expression from a single cell:

  1. Highlight the obsolete content.
  2. Select the Delete key.
    The selected content is deleted.


Core Configuration Guide - Move the Contents from One or More Cells (Configuring Data Grids)

Move the Contents from One or More Cells

You can move the content from one or more cells and place that content into the same number of cells elsewhere on a Data Grid.

ATTENTION: Moving the content of a cell into an already populated cell will overwrite the present content of that cell with the selected content.

To move the content from one group of cells to another:

Either:

  1. Select the required cells (see Keyboard Shortcuts). (To select a complete row, select the row number; to select a complete field, select the field heading.)

Example:

The content of cells 1 to 7 is selected in the field ‘Col1’...

  2. Select the first cell in the highlighted group of cells and keep the mouse button pressed down.
  3. While keeping the mouse button pressed down, ‘drag’ the content of the selected cell to its new location.
  4. Release the mouse button.
    The content of the selected cell is moved to the new location. The content of the other selected cells moves to its new location, relative to the location that you selected.

Example:

...the content of cell 1 is then dragged over to its new location of row 1 in the ‘NewField’ field. When the mouse button is released, the content of cells 1 to 7 from the ‘Col1’ field is moved to cells 1 to 7 in the ‘NewField’ field.

Or:

  1. Select the content of one or more cells (see Keyboard Shortcuts).

Example:

The content of cells 1 to 2 is selected in the field ‘Col2’...

  2. Perform one of the following:
  • Press both the CTRL key and the X key.
  • Right-click on the cell to display a context sensitive menu and select the Cut option.
  • Select the Edit menu from the ViewX menu bar and then select the Cut option.

The content of the cells is removed from the Grid and placed in the clipboard.

  3. Move to the new location for the content of the top-left expression that is presently stored in the clipboard.
  4. Perform one of the following:
  • Press both the CTRL key and the V key.
  • Right-click on the cell to display a context sensitive menu and select the Paste option.
  • Select the Edit menu from the ViewX menu bar and then select the Paste option.

The content of the clipboard is pasted into the Data Grid cells, starting at the new location.

Example:

...the CTRL + X and CTRL + V key combinations are used to move the content of cells 1 and 2 from the ‘Col2’ field, into cells 8 and 9 in the ‘NewField’ field.


Core Configuration Guide - Delete Cells from a Data Grid (Configuring Data Grids)

Delete Cells from a Data Grid

You can delete from one or more cells from a Data Grid and move the remaining cells further to the left or further up the Grid to fill the void that is left by the deleted cells. To delete more than one cell, either drag over a block of obsolete cells, fields, or rows, or see Keyboard Shortcuts for other ways of making multiple selections.

ATTENTION: Be aware that moving remaining cells into fields of different types may affect the values of the expressions that those fields contain.

To delete one or more individual cells, either:

  1. For multiple cells, select the required cells (for a single cell, go straight to step 2).
  2. Right-click on the obsolete cell(s).
    A context sensitive menu is displayed.
  3. Select the Delete option.
    The Delete window is displayed.
  4. Choose how the removal of the obsolete cells is to affect the rest of the cells in the row or column (either Shift cells left or Shift cells up).
  5. Select the OK button.
    The selected cell is deleted. The remaining cells are adjusted as specified by the selected option button.

Or:

  1. Select the required cell(s).
  2. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Delete option.
    The selected cell(s) are deleted.

To delete whole fields or rows of cells:

  1. For multiple fields or rows, either:
  • Select the required field heading(s).
  • Select the required row number(s).

(For a single field or row, go straight to step 2.)

  2. Right-click on one of the selected fields or rows.
    A context sensitive menu is displayed.
  3. Select the Delete option.
    The selected fields or rows (depending on your selection in step 1) are deleted.


Core Configuration Guide - Keyboard Shortcuts (Configuring Data Grids)

Keyboard Shortcuts

There are several key-combinations that you can use when editing a Data Grid. This section summarizes the supported key strokes.

Key(s)

Action

Application

Displays a context sensitive menu, with menu options appropriate to the selected content, cell, field, or row.

Arrow keys

Moves to the next cell in the direction of the arrow (for example, the Up arrow moves to the cell immediately above the presently selected cell).

You can also use the SHIFT key in conjunction with the arrow keys to make multiple selections (see below).

CTRL

To select more than one field, row, or cell in different parts of a Data Grid, select the first field, row, or cell that you require and then hold down the CTRL key while you make further selections.

CTRL + A

Selects all of the cells in a table.

CTRL + C

Copies the content of the selected cells, fields or rows into the clipboard. (Use CTRL + V to paste the content elsewhere.)

CTRL + End

Moves to the bottom right (last) cell in a table.

Or: If editing a cell, moves the cursor to the end of the expression.

CTRL + Home

Moves to the top left (first) cell in a table.

Or: If editing a cell, moves the cursor to the start of the expression.

CTRL + P

Displays the Print window, enabling you to print the Data Grid.

CTRL + S

Saves the Data Grid configuration.

CTRL + V

Pastes the content of the clipboard into the Data Grid, starting at the presently selected location.

CTRL + X

Deletes the selected content and places it in the clipboard. (Use CTRL + V to paste the content elsewhere.)

You can also ‘drag’ the content of cells, fields or rows over to other cells, fields, or rows.

Be aware that if expressions are dragged over to field(s) that are of different type(s), this may affect the values of those expressions.

Delete

Deletes the selected field, row, or cell. Deletion is immediate if a field heading, or row number is selected. A Delete window is displayed if a cell is selected, allowing you to specify the item that you want to delete.

End

Moves to the right-most cell in the selected row.

Enter

Starts ‘in-place’ editing of the selected cell.

Or:

While editing a cell, select the Enter key to end the in-place editing.

(During ‘in-place’ editing, you can use the normal keyboard shortcuts, such as Home and End. Other keys, such as the Enter and ESC key have different functionality when used during in-place editing.)

ESC

While editing a cell, select the ESC key to discard any changes.

Home

Moves to the left-most cell in the selected row.

Page Down

Moves down one page, with the page size depending on the size of the window.

Page Up

Moves up one page, with the page size depending on the size of the window.

SHIFT

To select a block of fields, rows, or cells, select the first field, row or cell, and then hold down the SHIFT key while you select the last field, row or cell. All fields, rows and cells between the first and last selections are also selected.

SHIFT + Arrow keys

To select a block of fields, rows, or cells, you can use the SHIFT key along with any combination of Arrow keys to make your multiple selection. Select the first field, row, or cell that you require and then hold down the SHIFT key while using the Arrow keys that indicate the direction in which you want to make your selection.


Core Configuration Guide - Configuring Data Tables

Configuring Data Tables

The ClearSCADA database consists of a series of pre-configured tables. For example, basic information for every point in a ClearSCADA system is contained in the CDBPoint table.

You can use Data Tables to add ‘custom’ tables to your database. Data Tables are used purely for storing data (unlike Data Grids, which are ‘custom’ tables that you can use to perform calculations on data from elsewhere in the database).

You might want to use Data Tables, for example, to store the results of custom calculations that are running in Logic programs on your system, or to store the values that are returned by Mimic scripts. Data Tables are designed to be populated automatically using, for example, Logic or SQL.

Operators can display the data in a Data Table as a List, and navigate and sort the data in that List.

...then operators can view the resulting information in List format or, for example, in a Report.
You add a Data Table to ClearSCADA...
...then use the Table Editor to specify the fields that you want to include in that table. Use automation or Logic to populate the table...

Before you add a Data Table to ClearSCADA, carry out any necessary Preparation. Then to create, configure, and populate a Data Table, follow this procedure:

  1. Add a Data Table to the ClearSCADA database.
  2. Configure the Properties on the Data Table Form.
  3. Edit a Data Table.

While the table is displayed in Edit mode, you can perform activities such as:

  1. Add Fields to a Data Table.
  2. Specify the Field Properties.
  4. Save the configuration (see Saving Configuration Changes).
  5. Automatically Populate a Data Table.

Operators can then display the table’s data in List form (see Display the Data on a Data Grid or Data Table in List Format in the ClearSCADA Guide to Lists) or, if required, you can use the table’s data in a Report (see the ClearSCADA Guide to Crystal Reports).


Core Configuration Guide - Preparation (Configuring Data Tables)

Preparation

Before you add a Data Table to the ClearSCADA database, you should decide:

  • The data that the Data Table is to store.

For instance, is the Data Table to store the results of one or more Logic programs, or to store data directly from the ClearSCADA database, or an external database?

You need to decide which records the Data Table is to store, and what data it is to store for each of those records. You will need to add a separate field for each item of data that you want the Data Table to store. As such, you need to know the type of data that applies to each field (Byte, Float, String, and so on).

(Be aware that because of their nature, you cannot include Data Tables in Group Templates.)

  • The order of the fields in the Data Table.

You need to decide the order in which fields should be included in the Data Table, so that the fields appear in the expected order when operators view the data in List form.

You also need to decide whether the entries in any of those fields are to change appearance, depending on the item’s alarm state or overall status (see Specify the Field Properties).

  • Which fields to index.

You need to decide which fields an operator is likely to sort or search for data, and whether any of those fields should be indexed to speed such searches (see Specify the Field Properties).

  • Whether the colors used to display the records are dynamic.

You can configure certain types of field to perform specific functions, controlling either the background or foreground color of each record, or whether the records flash. Such attributes affect the appearance of the table’s data when that data is displayed as a List (see Specify the Field Properties).

  • Whether to retain the Table’s records in cache memory.

Particularly if a Data Table is to contain a large number of records, you need to decide whether the ClearSCADA server is to retain that Table’s records in its cache, or whether it is to load the records only when required (see Configure the Properties on the Data Table Form).

  • Which application is to automatically populate the Data Table.

Data Tables are designed to be populated automatically. You need to decide which application to use to automatically insert the required records into your Data Tables.

In order to configure the application successfully, you need the appropriate experience or knowledge of that application and how it interfaces with ClearSCADA (see Automatically Populate a Data Table).

If the application is to populate the Data Table with ClearSCADA data, you need to be familiar with the ClearSCADA database structure and naming conventions, in order to reference the relevant database table(s) and fields within those tables. For more information, see the ClearSCADA Guide to the Database.


Core Configuration Guide - Add a Data Table (Configuring Data Tables)

Add a Data Table

NOTE: We recommend that some basic Preparation is carried out, before adding a new Data Table to a ClearSCADA system.

To add a Data Table to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a Data Table.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Data Table option.
    A Data Table is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Data Table (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added a Data Table to the system, you can then Configure the Properties on the Data Table Form, or Edit a Data Table and add fields to that table.


Core Configuration Guide - Configure the Properties on the Data Table Form (Configuring Data Tables)

Configure the Properties on the Data Table Form

To define the properties on the Data Table Form, you need to display the Form (see Display a Form).

The Data Table Form comprises these tabs:

  • Identification—Use to optionally define a Help View and to indicate whether the Data Table is to be excluded from any Exclusive Control activity (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the Data Table (see Using the User Methods Tab to Define Custom Actions).
  • Data Table—Use to specify these properties:
  • Table Name—Enter a unique name for the Data Table, as you want it to appear in the ClearSCADA database. The name is used to identify the table when configuring, for example, the SQL or Logic that is to automatically populate the Table with data.

The Table Name has to begin with an alphabetical character and contain only alphanumeric or underscore characters (see Naming Restrictions). The maximum name length that you can specify is 23 characters.

We advise that Table Names do not start with the letter ‘C’, to avoid confusion with built-in tables.

Ensure that the Table Name is not identical to that of any built-in table, other Data Table, or any other ‘custom’ tables, including Data Grids, and Historic Views.

  • Title—Enter the title that is to be displayed in the header whenever operators display the Table’s data as a List. The Title can include character spaces.
  • Preload Table— A Data Table’s configuration is held in the server’s memory. Select the Preload Table check box for ClearSCADA to also load the Data Table’s records into memory on system start-up, and to retain those records in its memory.

Ensure that the check box is clear if the Data Table’s records are only to be loaded into the server’s memory when required. For instance, whenever the Data Table is queried, or its records are modified. If the Preload Table check box is clear, be aware that the Data Table’s records may get purged from memory when not in use. Should this occur, the records will be reloaded when the Table’s data is next required. This will result in additional loading on the server whenever a Data Table’s records are reloaded into memory (especially if that Data Table contains a large number of records).

To lock the Data Table’s records into the server’s memory, so that they are not purged, select the Preload Table check box.

The Data Files section of the ClearSCADA Server Configuration Tool is used to control the amount of memory that the server uses for Data Tables, and how often changes are flushed to disk.

Further Information

Edit a Data Table.


Core Configuration Guide - Edit a Data Table (Configuring Data Tables)

Edit a Data Table

To edit a Data Table, so that you can specify the fields that you want to include in the table:

  1. Double-click on the Data Table in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).
    The Data Table is displayed in Edit mode.

NOTE: If the Database Bar is not displayed, you can access it by selecting the View menu, followed by the Explorer Bar option and then the Database option.

or:

  1. Right-click on the Data Table in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Data Table is displayed in Edit mode.
    By default, a newly created Data Table is empty (it does not contain any fields).

When editing a Data Table, you can:

  • Add Fields to a Data Table
  • Edit an Existing Field
  • Specify the Field Properties
  • Delete a Field from a Data Table.

Further Information

Keyboard Shortcuts.

Configure the Properties on the Data Table Form.


Core Configuration Guide - Add Fields to a Data Table (Configuring Data Tables)

Add Fields to a Data Table

By default, a newly created Data Table does not contain any fields. You need to add a field for each item of data that you want your Data Table to store. You add a Data Table’s fields in the order in which you want the fields’ column headings to appear on the List display for that table. You then need to use automation or Logic to populate the Data Table with the records for that table.

To add a field to a Data Table:

  1. Display the Data Table in Edit mode (see Edit a Data Table).
  2. Either:
  1. Right-click on the Data Table.
    A context sensitive menu is displayed.
  2. Select the Add option.

Or:

  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Add Field option.

The Edit Field window is displayed.

  3. Use the window to Specify the Field Properties.

Ensure that you add the fields in the order in which the column headings are to appear when the table’s data is displayed as a List (with the exception of any ‘special’ fields, which are used to determines the records’ color or blink attributes).

  4. Repeat the above steps for any other fields that you want to add to your Data Table.

Further Information

Edit an Existing Field.

Delete a Field from a Data Table.

Keyboard Shortcuts.


Core Configuration Guide - Edit an Existing Field (Configuring Data Tables)

Edit an Existing Field

To edit a field on a Data Table:

  1. Display the Data Table in Edit mode (see Edit a Data Table).
  2. Either:
  1. Double-click on the field.

or:

  1. Right-click on the field.
    A context sensitive menu is displayed.
  2. Select the Properties option.

The Edit Field window is displayed.

  3. Use the window to Specify the Field Properties.

Further Information

Add Fields to a Data Table.

Delete a Field from a Data Table.


Core Configuration Guide - Specify the Field Properties (Configuring Data Tables)

Specify the Field Properties

For each item of data that a Data Table is to store, you need to include a field of the appropriate type in that Data Table (see Add Fields to a Data Table). You add the fields in the order in which the field’s column headings are to appear when the table’s data is displayed as a List.

When you add a field to a Data Table, or Edit an Existing Field, you use the Edit Field window to specify the field’s properties:

  • Name—Use to specify a unique name for the field. The name appears as a column heading when operators display the Data Table’s entries as a List.

The Name has to begin with an alphabetic character, and can thereafter contain a mix of alphanumeric characters and spaces.

  • Type—Use this combo box to specify the type of data that the field is to contain.

Specify the required field Type from these options:

  • Byte—The field is to contain unsigned 8-bit values.
  • Word—The field is to contain signed 16-bit values.
  • Unsigned Word—The field is to contain unsigned 16-bit values.
  • Long—The field is to contain signed 4-byte (32-bit) values.
  • Unsigned Long—The field is to contain unsigned 4-byte (32-bit) values.
  • Float—The field is to contain IEEE single-precision floating point values.
  • Double—The field is to contain double-precision floating point (64-bit) values.
  • String—The field is to contain alphanumeric strings. Use the Size field (see below) to specify the maximum string length.
  • Boolean—The field is to contain Boolean (0 or 1) values and display those values as ‘True’ or ‘False’.
  • Time—The field is to contain date or time values. When displayed as a List in ClearSCADA, the field’s values use the syntax that is defined by the user’s Date Format. When displayed in an external application, they use the Date and Time format specified by that application.
  • Color—The field is to contain color values in RGB format. For example, RGB(255, 255, 128) for bright yellow. Only select this option if the client application that is to use the Table’s data can decipher the data as color values.
  • Size—Only applies when the Type (see above) is specified as ‘String’. Use the spin box to specify the maximum acceptable string length of the field’s contents.

The client application that accesses the Data Table may use the size, for example, to truncate any strings that are longer than this size. There is no limit to the length of a string within a Data Table.

  • Attribute—You can optionally use certain types of field to control the color or blink attribute of each record (row) in a Data Table. The value that is assigned to such a field determines the color or blink status of that particular record. Foreground, Background, and Blink attribute-assigned fields do not appear as columns when the table’s data is displayed in List format.

If such attributes are used in a Data Table, ensure that only one field in the table is assigned to each Foreground, Background, or Blink attribute.

If no fields in a Data Table are used to determine the color or blink attribute of the records in that table, the records are displayed using the Windows’ color defaults (typically black text on a white background), whenever the table’s data is displayed as a List in ClearSCADA.

Use the Attribute combo box to specify whether the color or blink status of each record’s entries are to vary, depending on the value of this field, whenever the table’s data is displayed as a List.

  • None—The value of this field does not determine the color or blink status of the Data Table’s records.
  • Foreground—Only applies if the field’s Type is set to Color, Long, or Unsigned Long (see above). Select the Foreground option if the value of this field is to determine the foreground color that is used to display the records’ entries.
  • Background—Only applies if the field’s Type is set to Color, Long, or Unsigned Long (see above). Select the Background option if the value of this field is to determine the background color that is used to display the records’ entries.
  • Blink—Only applies if the field’s Type is set to Boolean (see above). Select the Blink option if the value of this field is to determine whether the foreground of the records’ entries flash. When displayed as a List, a record flashes when the value of this field is 1 (True), and does not flash when the value is 0 (False).
  • Indexed—You can use indexing in your Data Tables in order to speed the sorting and filtering of data in those tables. When indexing is used, only the indexes are searched or sorted, rather than the actual data records.

To index a field, ensure that the Indexed check box is selected. With Data Tables that are expected to contain numerous records, we suggest that you index each of the fields on which operators are likely to either sort or filter the data.

Leave the check box clear for those fields that are unlikely to be used for sorting or filtering the table’s data.


Core Configuration Guide - Delete a Field from a Data Table (Configuring Data Tables)

Delete a Field from a Data Table

You can delete single or multiple obsolete fields from a Data Table, while that table is displayed in Edit mode (see Edit a Data Table).

To delete field(s) from a Data Table:

  1. Select the required field(s) in the Data Table.
  2. Either:
  1. Press the Delete key.

or:

  1. Right-click on the obsolete field(s).
    A context sensitive menu is displayed.
  2. Select the Delete option.

or:

  1. Select the Edit menu.
  2. Select the Delete option.

or:

  1. Select the CTRL + X keys.
  3. Save the configuration (see Saving Configuration Changes).

Further Information

Keyboard Shortcuts.

Add Fields to a Data Table.


Core Configuration Guide - Keyboard Shortcuts (Configuring Data Tables)

Keyboard Shortcuts

There are several key-combinations that you can use when you Edit a Data Table. This section summarizes the supported key strokes.
Key(s) | Action
Application | Displays a context sensitive menu, with menu options appropriate to the selected field.
Arrow keys | Use the SHIFT key in conjunction with the up or down arrow keys to make multiple selections (see below).
CTRL | To select more than one field in different parts of a Data Table, select the first field that you require and then hold down the CTRL key while you make further selections.
CTRL + A | Selects all of the fields in a table.
CTRL + C | Copies the content of the selected fields into the clipboard. (Use CTRL + V to paste the content elsewhere.)
CTRL + S | Saves the Data Table configuration.
CTRL + V | Pastes the content of the clipboard into the Data Table, starting at the presently selected location.
CTRL + X | Deletes the selected field(s) and places them in the clipboard. (Use CTRL + V to paste the fields elsewhere.)
Delete | Deletes the selected field(s).
End | Highlights the last field in the Data Table.
Home | Highlights the first field in the Data Table.
Page Down | Moves down one page, with the page size depending on the size of the window.
Page Up | Moves up one page, with the page size depending on the size of the window.
SHIFT | To select a block of fields, select the first field that you require and then hold down the SHIFT key while you select the last required field. All fields between the first and last selections are also selected.
SHIFT + Arrow keys | To select a block of fields, you can use the SHIFT key along with the up or down arrow keys to make your multiple selection. Select the first field that you require and then hold down the SHIFT key while using the arrow keys that indicate the direction in which you want to make your selection.


Core Configuration Guide - Automatically Populate a Data Table (Configuring Data Tables)

Automatically Populate a Data Table

Data Tables are designed to be populated automatically.

Use whichever supported application is suitable for populating your Data Tables with the records that they are to store.

Your ClearSCADA system might, for example, include Data Tables that are configured to store the values of custom calculations that are running in Logic programs, or that store data values from third-party applications, with the Data Tables enabling operators to view the data from those applications, while logged on to ClearSCADA.

Be aware that if any of your Data Tables are to be populated with data from a third-party application, and that application is to transfer its data to ClearSCADA using Open DataBase Connectivity (ODBC) data transfer standards, your ClearSCADA system needs to be running the ClearSCADA ODBC driver. For information on transferring data to ClearSCADA using ODBC, see the ClearSCADA Guide to the ODBC Driver (as with other drivers in ClearSCADA, your system will require a license to run this driver).

Server Automation is a programming interface that enables external programs to interface with ClearSCADA. You can use Server Automation to automatically populate Data Tables with the records that they are to store. For further information on Server Automation, see the online Server Automation technical reference.

You can use Logic and/or SQL to automatically populate Data Tables with the records that they are to store. For an example that uses a Structured Text Logic program to call an SQL query in order to populate a Data Table, see Example Configuration. For further information on using Logic, see the ClearSCADA Guide to Logic. For information on the SQL commands that are supported by ClearSCADA, see the online SQL Technical Reference. (Remember that if you want to include SQL queries in a Logic program, that program has to be a Structured Text program.)


Core Configuration Guide - Example Configuration (Configuring Data Tables)

Example Configuration

This example demonstrates how you might use a Structured Text Logic program to automatically populate a Data Table with the relevant records. The Structured Text (ST) program calls an SQL query in order to populate the Data Table with the relevant data from the ClearSCADA database.

Example:

A Data Table, named ‘MyDataTable’, is to store values of the points that are located within an ‘Internal Points’ Group in the ClearSCADA database. For each point, the Data Table is to store these values: the point’s name, value, and the time that the point data was last updated.

The Data Table is to store data from points in the ‘Internal Points’ Group...
...to enable operators to view that data in, for example, List format.

The Data Table is suitably configured in ClearSCADA:

...then the required fields are added to the Data Table in Edit mode.
The required Data Table properties are specified on the Data Table Form...

A Structured Text Program is added to the ClearSCADA database. The ST program editor is used to specify the code for populating the Data Table with the relevant records. This particular ST program uses this code:

TYPE
(* The database object structure used to store the results of the result set *)
PtValues : DATABASE_OBJECT(CDBPoint)
Name: STRING;
CurrentValueFormatted: STRING;
CurrentTime: DATE_AND_TIME;
END_DATABASE_OBJECT;
END_TYPE
PROGRAM PopulateMyDataTable
VAR
(* SQL query to retrieve point values - this MUST include the ID column *)
Points AT %S(SELECT ID,Name,CurrentValueFormatted,CurrentTime FROM CDBPoint WHERE FullName LIKE 'Internal Points.%') :RESULTSET OF PtValues;
END_VAR
VAR
PtName : STRING;
PtVal : STRING;
PtTime : DATE_AND_TIME;
END_VAR
VAR
(* SQL to delete old values from the Data Table *)
Del AT %D(DELETE FROM MyDataTable );
(* SQL to insert current values into the Data Table *)
R1 AT %D(INSERT INTO MyDataTable VALUES ( ?, ?, ? ) ) WITH_PARAMS PtName, PtVal, PtTime;
END_VAR
(* Delete old values from the Data Table *)
Del.Execute();
(* Get the first record in the result set *)
Points.First();
(* While there is a valid record in the result set... *)
WHILE Points.Valid DO
(* ...transfer record from result set to INSERT query parameter variables... *)
PtName := Points.Value.Name;
PtVal := Points.Value.CurrentValueFormatted;
PtTime := Points.Value.CurrentTime;
(* ...then execute the INSERT query to insert that record's values into the Data Table *)
R1.Execute();
(* Get the next record from the result set *)
Points.Next();
END_WHILE;
END_PROGRAM

As can be seen from the above code:

  • A DATABASE_OBJECT structure is used to declare and access the direct variables that are used in the program.
  • The program uses an SQL query to retrieve the required point values from the database and store those values in a RESULTSET. (Remember that when using a DATABASE_OBJECT structure, the column names in the SQL must include the ID column first, followed by the member names from the DATABASE_OBJECT definition. (All DATABASE_OBJECT structures have an ID 'member’ that is implicit and is not included in the actual DATABASE_OBJECT definition.).)
  • The internal variables that are used to transfer the records from the RESULTSET into the Data Table are declared.
  • Whenever the ST program is executed, SQL first deletes the old values from the Data Table and then populates that table with the latest values from the relevant records. (The .First() and .Next() methods are used to cycle through the records in the RESULTSET, in order to populate the table.)

Further Information

Add a Data Table.

Configure the Properties on the Data Table Form.

Edit a Data Table.

Automatically Populate a Data Table.

Working with Logic Programs: See the ClearSCADA Guide to Logic.


Core Configuration Guide - Configuring Historic Calculations

Configuring Historic Calculations

You can use Historic Calculations to calculate historic data for a point or Forecast, based on the historic values of other points, Time Profiles, or Forecasts.

You specify an expression for each Historic Calculation. The expression instructs ClearSCADA as to the type of calculation that it is to perform on the historic data from one or more data sources (points, Time Profiles, or Forecasts). The results of the calculation form the historic data of the ‘target’ point or Forecast.

You specify the frequency with which ClearSCADA performs each calculation and the period for which the calculation is performed.

Use Historic Calculations to produce historic data for points or Forecasts for which historic data cannot be obtained directly, but can be calculated by using the historic data from other sources.

Example:

To assess the flood risk downstream in a river, use the known levels of the river tributaries upstream to calculate what height the river will reach downstream. Use Offsets to allow for the time it will take for the known tributary levels to reach downstream. Configure the Target Forecast so that it raises an alarm if the calculation indicates that the river will reach a critical level.

This section explains how to:

  • Add a Historic Calculation
  • Configure a Historic Calculation.

It also provides a detailed Example Configuration.


Core Configuration Guide - Add a Historic Calculation (Configuring Historic Calculations)

Add a Historic Calculation

To add a Historic Calculation to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a new Historic Calculation.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Historic Calculation option.
    A Historic Calculation is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Historic Calculation (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

Once you have added a Historic Calculation, you need to configure its properties (see Configure a Historic Calculation).


Core Configuration Guide - Configure a Historic Calculation (Configuring Historic Calculations)

Configure a Historic Calculation

To configure a Historic Calculation, you need to display the Historic Calculation Form (see Display a Form).

The Historic Calculation Form has these tabs:

  • Identification—Use to configure the Identification properties (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the Historic Calculation (see Using the User Methods Tab to Define Custom Actions).
  • Historic Calculation—Use to:
  • Specify the Target for the Historic Calculation Data
  • Specify the Expression for the Historic Calculation
  • Specify how Often Historic Data is Calculated
  • Specify the Period Over which Historic Data is Calculated.

For an example of how to use the fields on the Historic Calculation tab to configure a historic calculation, see Example Configuration.


Core Configuration Guide - Specify the Target for the Historic Calculation Data (Configuring Historic Calculations)

Specify the Target for the Historic Calculation Data

Use the Target field on the Historic Calculation tab to specify the Forecast or Internal point that is to use and store the Historic Calculation data.

Select the browse button to display a Reference browse window. Select the required point or Forecast from the window.

Ensure that any Internal Analog or Digital point has Historic enabled, in order to use that point as the Target point (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

If the Historic Calculation includes ‘future’ data, the Target has to be a Forecast. (By ‘future data’ we mean when the Window End field contains a time that is in the future.)


Core Configuration Guide - Specify the Expression for the Historic Calculation (Configuring Historic Calculations)

Specify the Expression for the Historic Calculation

Use the Expression field on the Historic Calculation tab to enter the syntax that defines the Historic Calculation expression.

You enter the expression syntax in the same way as for other Expression windows (see the ClearSCADA Guide to Expressions).

If the expression includes a comparison between the data values of two or more points, ensure that all of the source points have samples that occur within their respective sample windows. Also ensure that those samples occur within the overall calculation period (see Specify the Period Over which Historic Data is Calculated). (In effect, the Historic Calculation re-samples all of the historic data that is used in its expression, in order to produce historic data for the Target point.)

For an example of the type of syntax that can be used in the Expression field, see Example Configuration.

For further information on writing expressions, see the ClearSCADA Guide to Expressions.


Core Configuration Guide - Specify how Often Historic Data is Calculated (Configuring Historic Calculations)

Specify how Often Historic Data is Calculated

Use the Resample Interval field on the Historic Calculation tab to specify the frequency with which the historic data is calculated.

Enter the period in the OPC Time Format, for example 15M for ClearSCADA to calculate historic data at 15-minute intervals. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

For a further example of how to use the Resample Interval, see Example Configuration.


Core Configuration Guide - Specify the Period Over which Historic Data is Calculated (Configuring Historic Calculations)

Specify the Period Over which Historic Data is Calculated

Use the Window Start and Window End fields to specify the period for which ClearSCADA is to calculate historic data.

If the expression includes a comparison between the data values of two or more points, ensure that the calculation period is large enough to include the sample data from all of the source points. (In effect, the Historic Calculation re-samples all of the historic data that is used in its expression, in order to produce historic data for the Target point.)

  • Window Start—Use to specify the earliest time for which ClearSCADA is to calculate historic data. Enter the time in the OPC Relative Time Format. For example, M-1D, for ClearSCADA to calculate historic values for data starting one day before the beginning of the current minute. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

Whenever you run a Historic Calculation (using the Execute pick action), and the Target is a Forecast, ClearSCADA performs the calculation from the time specified in the Window Start field.

Whenever the Target is a point, ClearSCADA adjusts the start time for the calculation so that it runs from the last stored Target value or the specified Window Start time (whichever is the later).

  • Window End—Use to specify the latest time for which ClearSCADA is to calculate historic data. Enter the time in the OPC Relative Time Format. For example, M+2D, for ClearSCADA to continue calculating historic values until two days after the beginning of the current minute. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

If the Target is a point and the Window End field contains a time in the future, ClearSCADA will only perform a Historic Calculation on data that is time stamped up to ‘NOW’. ClearSCADA can only perform Historic Calculations on future data if the Target is a Forecast.

For a further example of how to use the above fields, see Example Configuration.


Core Configuration Guide - Example Configuration (Configuring Historic Calculations)

Example Configuration

This example demonstrates how a Historic Calculation can be used to provide a Target point with data from one of two points, depending on the values of those points. (In this particular example, when the source data values fall below a certain level, the Target point is provided with data from the source point that has the more accurate readings.)

Example:

The flow of gas in a pipe is measured by two signals—one with a range of 0-200 (source point ‘Pipe3 0-200’) and another that has a range of 0-20 (source point ‘Pipe3 0-20’). When the flow is less than 20, the 0-20 signal gives a more accurate reading than the 0-200 signal.

With the ClearSCADA system that monitors these readings, a Historic Calculation is to be carried out, such that the flow in the pipe is measured using data from the 0-200 signal when the gas flow is greater than or equal to 20, and using data from the 0-20 signal when the gas flow drops below 20.

An Internal Analog point, ‘Pipe3 Flow’, is to store the result of the Historic Calculation. The point is configured to have a range of 0 to 200, and has Historic enabled.

The Historic Calculation ‘Pipe3 Flow Calculation’ is configured to use ‘Pipe3 Flow’ as its Target point:

The Historic Calculation is to produce 3 days’ worth of historic data and is to calculate historic values at 15-minute intervals.

The Expression used for the Historic Calculation needs to take account of the value for the Analog point ‘Pipe3 0-200’ unless the value of the point drops to 20, whereupon it needs to take account of the value of the Analog point ‘Pipe3 0-20’. This can be calculated using an IIF statement.

The Select Historic Calculation Tag window is used to specify the blocks of historic data that ClearSCADA is to access for the Expression.

The browse button adjacent to the Expression field is used to display the Select Historic Calculation Tag window. The window is used to select the Analog point ‘Pipe3 0-200’. As the calculation is to provide historic data at 15-minute intervals, the Search Range is set to 15M. If no historic values are found within this period, a Max Search Range of 30M allows ClearSCADA to search back a further 15 minutes. The Offset is left at its default of 0—no allowance is needed to allow for any time difference between the source and resultant historic values.

A historic value found by searching back by up to 15 minutes will be deemed Good Quality...
An Offset of 0. This indicates that the resultant Historic Calculation values are to use the exact time stamps from this historic data. (They do not include any allowance for offsetting the resultant values.)
...if no historic values are found within the 15-minute period, ClearSCADA continues to search back in time. Historic values found between 15 and 30 minutes back will be deemed Uncertain Quality.
The point for which ClearSCADA is to access a block of historic data. (In this example, the Analog Input point ‘Pipe3 0-200’).
ClearSCADA is to use a relative path to the tag.
The path to the selected point.

The settings specified in the Select Historic Calculation Tag window result in the syntax

"..Eastern Group.PSTN.Pipe3 0-200:0:15M:30M"

being displayed in the Expression field on the Historic Calculation Form.

The Select Historic Calculation Tag window is used to specify similar settings for the Analog point ‘Pipe3 0-20’.

The full syntax used in the Expression field (entered by a mix of manual typing and by specifying settings using the Select Historic Calculation Tag window) is:

As the Historic Calculation is to produce 3 days’ worth of historic data, and calculate historic values at 15-minute intervals, the remaining fields on the Historic Calculation tab of the Historic Calculation Form are configured to have these settings:

This specifies that ClearSCADA is to calculate historic values at 15-minute intervals, starting three days before the beginning of the present minute, and finishing at the beginning of the present minute.

The Historic Calculation’s Execute pick action is used to produce historic values for the Target point ‘Pipe3 Flow’. This includes the following values:

Time

Value of Source Point ‘Pipe3 0-20’

Value of Source Point ‘Pipe3 0-200’

Value of
Target Point ‘Pipe3 Flow’

Comments

10:00

20.00

75

75.00

As the value of ‘Pipe3 0-200’ is over 20, its value is written to the Target point.

10:15

20.00

53

53.00

10:30

20.00

36

36.00

10:45

12.47

18

12.47

The value of ‘Pipe3 0-200’ drops below 20, so the value of ‘Pipe3 0-20’ is written to the Target point.

11:00

10.38

17

10.38

11:15

15.69

24

24.00

The value of ‘Pipe3 0-200’ rises above 20, so the value of ‘Pipe3 0-200’ is written to the Target point.

11:30

17.45

---

24.00

There is no value for ‘Pipe3 0-200’ at 11:30, therefore the previous value of 24.00 is written to the Target point. This is still within the 15-minute ‘Search Range’ so is deemed Good Quality.

11:45

19.99

26

26.00

12:00

---

20

18.34

The value of ‘Pipe3 0-200’ drops below 20, so the value of ‘Pipe3 0-20’ is written to the Target point. As no value exists for ‘Pipe3 0-20’ at 12:00, the previous value of 19.99 is written to the Target point.

12:15

---

16

18.34

There is no value for ‘Pipe3 0-20’ at 12:15 so ClearSCADA extends its search back. The last known value of 19.99 is written to the Target point. As this value is outside of the ‘Search Range’ but within the ‘Max Search Range’, the value of the Target point is deemed to be of Uncertain Quality.

12:30

---

19

---

The value of ‘Pipe3 0-200’ is still below 20, so ClearSCADA attempts to use the value of ‘Pipe3 0-20’ for the Target point. However, there has been no value for ‘Pipe3 0-20’ for longer than the ‘Max Search Range’. Therefore, ClearSCADA searches further back and uses the last known value of 19.99 for the Historic Calculation.

As this value is outside of the ‘Max Search Range’, it is deemed Bad Quality and therefore no Target value is stored for this time interval.

12:45

20.00

27

27.00

The value of ‘Pipe3 0-200’ rises above 20 and is written to the Target Point. The value is deemed Good Quality.


Core Configuration Guide - Configuring Time Profiles

Configuring Time Profiles

A Time Profile can be used for comparing a known set of values with other data. For instance, you might use a Time Profile with a Logic program, in order to compare actual data values with a set of pre-compiled data values (see Example Configuration). This can be useful for checking for unusual fluctuations in value. You can also use a Time Profile for providing a time varying control value, such as a Set Point. A Time Profile’s current value updates once a minute, at the beginning of each minute.

A Time Profile’s values are obtained from configuration, rather than directly from a ‘live’ source. Each Time Profile has either a one-day or one-week span—the change in value over that span is repeated on a daily or weekly basis, from midnight at the start of the span period. A Time Profile is configured by adding vectors to a graph—the vectors define the Profile’s value at different times of the day or week. You can generate a Time Profile’s vectors manually or automatically, and can optionally base the vectors on actual historic data taken from any historical source on your system.

Use a Time Profile to represent a value that fluctuates by known amounts at the same times each day or week.

With analog points on some drivers, you can optionally assign Time Profiles to the points’ alarm limits, to enable the limit values to change at different times of the day or week. This enables the level at which ClearSCADA generates alarms to vary during the course of each day, to take into account expected variations on site. The driver-specific documentation indicates whether a particular point type supports Time Profiles.

To create and configure a Time Profile, you need to:

  1. Add a Time Profile.
  2. Configure the Properties on the Time Profile Form.
  3. Edit a Time Profile.
  4. Save the configuration (see Saving Configuration Changes).

You can use a Time Profile’s Status display, or the Time Profiles List, to ascertain information about any of the Time Profiles on your system. For information on Lists, see the ClearSCADA Guide to Lists; for information on Status displays, see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Further Information

Using Logic: see the ClearSCADA Guide to Logic.

Assign Time Profiles to Analog Point Alarm Limits: see Specify any Alarm Limit Profiles in the ClearSCADA Guide to Core Point Configuration.

For an example that demonstrates how a Time Profile might be used in a Logic program, see Example Configuration.


Core Configuration Guide - Add a Time Profile (Configuring Time Profiles)

Add a Time Profile

To add a Time Profile to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a Time Profile.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Time Profile option.
    A list of the supported types of Time Profile is displayed.
  4. Select the option that indicates the type of values that the Time Profile is to contain. Choose from:
  • Double—The Time Profile is to contain a series of IEEE double-precision floating point 64-bit values.
  • Float—The Time Profile is to contain a series of IEEE single-precision floating point 32-bit values.
  • Long—The Time Profile is to contain a series of signed 32-bit values.
  • Unsigned Long—The Time Profile is to contain a series of unsigned 32-bit values.

A Time Profile of the specified type is added to the root of the System or to the selected Group (depending on your selection in step 1). The Time Profile is selected automatically, ready for you to enter its name.

  5. Enter a suitable name for the Time Profile (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added a Time Profile, you can Configure the Properties on the Time Profile Form and Edit a Time Profile.


Core Configuration Guide - Configure the Properties on the Time Profile Form (Configuring Time Profiles)

Configure the Properties on the Time Profile Form

To configure the Time Profile’s properties, you need to display the Time Profile Form (see Display a Form).

The Time Profile Form has several tabs.

Use the Identification tab to configure the Time Profile’s Identification properties (see Defining Identification Details).

Use the User Methods tab to define any custom pick actions (‘methods’) for the Profile (see Using the User Methods Tab to Define Custom Actions).

Use the Profile tab to:

  • Specify the Profile’s General Properties
  • Specify the Profile’s Range
  • Specify the Resolution used to Restrict the Positioning of the Profile’s Vectors.


Core Configuration Guide - Specify the Profile's General Properties (Configuring Time Profiles)

Specify the Profile’s General Properties

Use the fields at the top of the Profile tab to specify these properties:

  • Period—Use this combo box to specify the Time Profile’s span. Choose from:
  • Daily—The Time Profile has a one-day span. The change in value over the Profile’s span is repeated from midnight at the start of each day.
  • Weekly—The Time Profile has a one-week span, comprising seven sets of vectors—one set for each day of the week (see Edit a Time Profile). The change in value over the Profile’s span is repeated from midnight at the start of each week.

If you reduce a Time Profile’s span from Weekly to Daily, ClearSCADA will automatically delete the vectors for Monday to Saturday and assign Sunday’s vectors to the Daily profile.

If you change a Time Profile’s span from Daily to Weekly, ClearSCADA will automatically copy the existing vectors to each day of the week (so that all seven days have the same set of vectors).

  • Mode—Use this combo box to select the type of Profile that is required. Choose from:
  • Interpolated—ClearSCADA produces a smooth Profile, using the vectors provided and by interpolating (calculating) the values between those vectors.
  • Stepped—ClearSCADA produces a stepped Profile. The Profile only changes in value at each vector that has a different value to an adjacent vector. The value change is indicated by a vertical ‘step’ in the Profile.

Example:

These two Profiles contain the same vectors—the Mode on the first Profile is Stepped, while the Mode on the second Profile is Interpolated.

With a Weekly Profile, if one or more day’s entries have no vectors, ClearSCADA will interpolate or step between vectors on other days.

  • Time Zone—Use this combo box to specify the time zone that applies to the Time Profile’s values. Ensure that you specify the same time zone at that used by the driver or Logic program with which the Time Profile is to be associated.

Choose from:

  • Coordinated Universal Time (UTC)—The Time Profile runs in Coordinated Universal Time.
  • Local Time without Daylight Saving Time—The Time Profile runs in Local time, for instance EST (Eastern Standard Time) if the local time zone is that for the East coast of America. No adjustments are made for Daylight Saving Time (DST).
  • Local Time with Daylight Saving Time—The Time Profile runs in Daylight Saving Time, for instance EDT (Eastern Daylight Time).

For more information, see Time Zone Support in ClearSCADA.

  • Maximum Vectors—Use the spin box to specify the maximum number of vectors that can be included on the Profile. You can specify between 1 and 1440 vectors per Profile day.

If you use the Maximum Vectors field to reduce the maximum number of vectors on a Profile, ClearSCADA will automatically delete any excess vectors, so that the new maximum value is not exceeded.

If you Produce a Profile Based on Historic Data, ClearSCADA will truncate the data once the specified number of vectors is reached.

If the SetVectors method is used to Generate a Profile’s Data Programmatically, ensure that no more than the specified maximum number of vectors are passed in the arguments used to modify the vectors for each Profile day. (Any attempt to generate more than the specified maximum number of vectors will fail.)


Core Configuration Guide - Specify the Profile's Range (Configuring Time Profiles)

Specify the Profile’s Range

Use the Minimum and Maximum fields within the Range section of the Profile tab to specify the range of values that the Profile can display.

A Time Profile has a ‘normal’ scale if its Maximum value is greater than the Minimum value.

A Time Profile has an inverted scale if its Maximum value is less than the Minimum value. (A Time Profile that is used for alarm limits on analog point(s) that have inverted scales must itself have an inverted scale.)

  • Maximum—Enter the maximum value that the Profile can display.
  • Minimum—Enter the minimum value that the Profile can display.

If you reduce the range of an existing Time Profile, ClearSCADA will automatically move any out-of-bounds vectors to the new Minimum or Maximum value, as appropriate.

If you Produce a Profile Based on Historic Data and any of the values exceed the Profile’s Range, ClearSCADA will substitute any larger values with the Profile’s Maximum value, and any smaller values with the Profile’s Minimum value (or vice versa if the Profile has an inverted scale).

If the SetVectors method is used to Generate a Profile’s Data Programmatically and any of the values exceed the Profile’s Range, the method will fail.


Core Configuration Guide - Specify the Resolution used to Restrict the Positioning of the Profile's Vectors (Configuring Time Profiles)

Specify the Resolution used to Restrict the Positioning of the Profile’s Vectors

By default, you can place a vector at any location on the Profile graph. Use the fields within the Resolution section of the Profile tab to optionally restrict the manual positioning of vectors vertically and/or horizontally on the graph:

  • Time—Specify a value greater than 0 to restrict the positioning of vectors to times that are increments of this number of minutes.

Leave the Time at the default of 0 to allow vectors to be assigned to any time (horizontal position) on the Profile graph.

  • Value—Specify a value greater than 0 to restrict the positioning of vectors so that they can only be used to specify values that are increments of this number.

Leave the Value at the default of 0 to allow vectors to be placed at any vertical position on the Profile graph.

Example:

A Profile is configured with this Resolution:

Time: 10 Minutes
Value: 5

The Time resolution restricts the positioning of vectors in the x-axis direction to time values that are 10-minute multiples. As such, vectors can be added for the times 00:40, 02:00, and 05:30 as these are all multiples of 10 minutes, but not for times such as 01:42 or 04:53, which are not multiples of 10 minutes.

The Value resolution restricts the positioning of vectors in the y-axis direction to values that are multiples of 5. As such, vectors can be added to represent, for example, the values 5, 10 or 15 (provided that these values do not exceed the Profile’s Range), but not values such as 3 or 7, as these are not multiples of 5.

A Time Profile’s resolution is intended as an aid to help precise positioning of vectors when those vectors are being inserted or moved manually (see Edit a Time Profile). It has no effect on the positioning of vectors by any other means (such as by using Paste, the Import Historic Data option, or the SetVectors method).


Core Configuration Guide - Edit a Time Profile (Configuring Time Profiles)

Edit a Time Profile

ATTENTION: When a Time Profile is used for point alarm limits, modifying the Profile may invalidate the configuration of the point(s) that use the Profile. The configuration will become invalid if the changes result in a limit crossing other limit(s) on the same point. For more information, see Specify any Alarm Limit Profiles in the ClearSCADA Guide to Core Point Configuration.

To edit a Time Profile, so that you can configure the actual profile graph, either:

  1. Double-click on the Time Profile in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).
    The Time Profile is displayed in Edit mode.

NOTE: If the Database Bar is not displayed, you can access it by selecting the View menu, followed by the Explorer Bar option and then the Database option.

or:

  1. Right-click on the Time Profile in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Time Profile is displayed in Edit mode.
    A single tab is displayed on the Time Profile window for a Time Profile that has a Daily Period.
    A separate tab for each day of the week is displayed for a Time Profile that has a Weekly Period.

Use the Time Profile window to:

  • Display or Remove Grid Lines While Working with a Profile
  • Add a Vector
  • Move a Vector
  • View the Co-ordinates of a Vector
  • Delete a Vector
  • Use Copy and Paste to Copy a Profile’s Vectors
  • Remove a Profile’s Vectors
  • Use Undo and Redo.

To plot a Time Profile’s change in value, you can:

  • Manually add vectors to the Profile’s graph (see the references above)
  • Produce a Profile Based on Historic Data
  • Generate a Profile’s Data Programmatically.


Core Configuration Guide - Display or Remove Grid Lines While Working with a Profile (Configuring Time Profiles)

Display or Remove Grid Lines While Working with a Profile

Grid lines are displayed in the Time Profile window by default. The lines act as a guide when positioning Profile vectors. When displayed, one grid line is shown for each entry on the axes. As such, if you reduce the size of the Profile window that you are working with, this could result in fewer grid lines being displayed at that resolution.

You can display both horizontal and vertical grid lines in the window.

To display horizontal grid lines in the Profile window:

  1. Right-click on the vertical (value) axes.
    A context sensitive menu is displayed.
  2. Select the Grid Lines option.
    Horizontal grid lines are displayed on the Profile window.

To display vertical grid lines on the Profile window:

  1. Right-click on the horizontal (time) axes.
    A context sensitive menu is displayed.
  2. Select the Grid Lines option.
    Vertical grid lines are displayed on the Profile window.

To remove grid lines that are on display, repeat the above process so that the Grid Lines option no longer displays a check mark.


Core Configuration Guide - Add a Vector (Configuring Time Profiles)

Add a Vector

NOTE: If required, Specify the Resolution used to Restrict the Positioning of the Profile’s Vectors before adding vectors to a Time Profile.

To manually add a vector to a Time Profile:

  1. Select the required time and value in the Profile window.
    A vector is added at the selected position. The Status Bar displays the time and value of the vector (see View the Co-ordinates of a Vector).

As an alternative to manually adding vectors to a Time Profile, consider whether you want to:

  • Produce a Profile Based on Historic Data
  • Generate a Profile’s Data Programmatically.


Core Configuration Guide - Move a Vector (Configuring Time Profiles)

Move a Vector

NOTE: You cannot move a vector to a time period before the previous vector, or after the next vector.

To move a vector to the position you require:

  1. Select the vector that you want to move and keep the mouse button pressed.
  2. Drag the vector to the required position.

If the Time Profile’s Resolution properties have been used to restrict vector positioning, you will only be able to place the vector at a position that complies with those restrictions (see Specify the Resolution used to Restrict the Positioning of the Profile’s Vectors).

The Status Bar displays the time and value of the vector as you move the vector (see View the Co-ordinates of a Vector). The co-ordinates are restricted to those that comply with the Time Profile’s Resolution settings.


Core Configuration Guide - View the Co-ordinates of a Vector (Configuring Time Profiles)

View the Co-ordinates of a Vector

The co-ordinates of a Profile vector are displayed in the Status Bar at the bottom of the ViewX window as you add or move a vector, or use the cursor to hover over an existing vector.

If a Time Profile’s Resolution properties have been used to restrict vector positioning, the Status bar’s co-ordinates are restricted to those that comply with the Time Profile’s Resolution settings (see Specify the Resolution used to Restrict the Positioning of the Profile’s Vectors).

As you add or move a vector, or use the cursor to hover over a vector...
...the vector’s co-ordinates are displayed in the Status bar. (In this particular case, the co-ordinates indicate that the profile value changes to 40.41 at 6.00am.)


Core Configuration Guide - Delete a Vector (Configuring Time Profiles)

Delete a Vector

To delete a vector from a Time Profile:

  1. Right-click on the vector that is no longer required.
    The vector is removed and the Time Profile updated.


Core Configuration Guide - Use Copy and Paste to Copy a Profile's Vectors (Configuring Time Profiles)

Use Copy and Paste to Copy a Profile’s Vectors

You can use the Copy and Paste feature to copy all of a Time Profile’s vectors for a particular day into Windows’ temporary storage ‘clipboard’. You can then paste a copy of those vectors onto another Time Profile, or use them to form the Profile for another day on the same Time Profile. (A Time Profile that has a Weekly span has a separate tab for each day of the week; a Time Profile that has a Daily span has a single tab.)

You can copy and paste vectors between different types of Time Profile (for example, between a Float Time Profile and a Long Time Profile). If the Profile to which you are pasting the vectors has ‘less precise’ values, the vectors’ values will be rounded down. If any of the copied vectors exceed the new Profile’s Range, ClearSCADA will substitute those vectors’ values with the Profile’s Maximum or Minimum value, as applicable, when the Profile is saved.

To copy a Profile’s vectors to the clipboard:

  1. Display the required Time Profile(s) in Edit mode.
  2. If the Time Profile(s) have a Weekly span, select the required day of the week.
  3. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context-sensitive menu is displayed.
  2. Select the Copy option.

or:

  1. Press the CTRL and C keys simultaneously.

or:

  1. Select the Copy button [image] on the File Toolbar.

The selected Profile’s vectors are copied to the clipboard.

To paste a Profile’s vectors from the clipboard:

  1. Select the required day of the week onto which you want to paste the vectors.
  2. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context-sensitive menu is displayed.
  2. Select the Paste option.

or:

  1. Press the CTRL and V keys simultaneously.

or:

  1. Select the Paste button [image] on the File Toolbar.

The vectors are pasted into the Profile from the clipboard, replacing the existing vectors for the selected day of the week.

If a Time Profile’s configuration, as well as its vectors, is to form the basis for another Time Profile, use the Copy and Paste feature to make a copy of the whole Time Profile database item (see Use Copy and Paste to Copy a Database Item).


Core Configuration Guide - Remove a Profile's Vectors (Configuring Time Profiles)

Remove a Profile’s Vectors

To remove all of the vectors for a single day from a Time Profile and store a copy of those vectors in Window’s temporary storage ‘clipboard’:

  1. Display the required Time Profile(s) in Edit mode.
  2. If the Time Profile(s) have a Weekly span, select the day of the week for which the vectors are to be deleted.
  3. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context-sensitive menu is displayed.
  2. Select the Cut option.

or:

  1. Press both the CTRL key and the X key.

or:

  1. Select the Cut button [image] on the File Toolbar.

The vectors are removed from the selected day of the week. A copy of the vectors is placed in the clipboard.

  3. Paste a copy of the vectors onto another day of the week on the same or another Time Profile, as required (see Use Copy and Paste to Copy a Profile’s Vectors).

To delete the vectors for a single day from a Time Profile, but not store a copy of those vectors:

  1. Display the required Time Profile(s) in Edit mode.
  2. If the Time Profile(s) have a Weekly span, select the day of the week for which the vectors are to be deleted.
  3. Either:
  1. Press the Delete key.

or:

  1. Select the Edit menu from the ViewX menu bar.
    A context-sensitive menu is displayed.
  2. Select the Delete option.

The vectors are removed from the selected day of the week. The clipboard is not used during this function.

NOTE: If the vectors are deleted by accident, use the Undo feature to undo that deletion (see Use Undo and Redo).


Core Configuration Guide - Use Undo and Redo (Configuring Time Profiles)

Use Undo and Redo

To undo the last action that was performed when editing a Time Profile, either:

  1. Select the Undo button [image] on the File toolbar.

or:

  1. Select the Edit menu from the ViewX menu bar.
    A context-sensitive menu is displayed.
  2. Select the Undo option.

or:

  1. Press both the CTRL key and the Z key.

The last edit action is undone.

To reinstate an action that has been undone using any of the steps above, either:

  1. Select the Redo button [image] on the File toolbar.

or:

  1. Select the Edit menu from the ViewX menu bar.
    A context-sensitive menu is displayed.
  2. Select the Redo option.

or:

  1. Press both the CTRL key and the Y key.

The last action that was undone is reinstated.


Core Configuration Guide - Produce a Profile Based on Historic Data (Configuring Time Profiles)

Produce a Profile Based on Historic Data

You can produce a Time Profile that is based on actual data by temporarily importing historic data into the Time Profile window. You can then use the data to produce a profile:

  • Automatically, by getting ClearSCADA to insert vectors based on that data (see Use Gaussian Distribution Calculations to Produce a Profile from Historic Data).
  • Manually, by adding the vectors yourself, to produce a profile based on the historic data (see Manually Produce a Profile Based on Historic Data).

As an alternative to the above, you can write a program to Generate a Profile’s Data Programmatically.

Use Gaussian Distribution Calculations to Produce a Profile from Historic Data

ClearSCADA can use Gaussian Distribution calculations on samples of historic data to add vectors to a Time Profile and produce a profile based on that data.

You need to specify how closely the profile should relate to the historic data, and the sampling intervals for that data. ClearSCADA will then produce a profile, using one Gaussian Distribution calculation per historic data sample to define the vector positions of that profile.

To produce a profile automatically, and base that profile on historic data:

  1. Display the Time Profile in Edit mode.
  2. If the Time Profile has a Weekly span, select the day of the week for which ClearSCADA is to use Gaussian Distribution calculations.

(Each Import request imports historic data for a single day. With a Weekly Time Profile, you need to perform a separate Import request for each day of the week for which the profile is to be based on historic data.)

  3. Select the Edit menu from the main ViewX menu bar.
    A context sensitive menu is displayed.
  4. Select the Import Historic Data option.
    The Import Historic Data window is displayed.
  5. Select the Source browse button.
    A Reference browse window is displayed.
  6. Use the Reference browse window to select a Time Profile, Forecast, or point for which Historic is enabled. The item can reside anywhere on your system.
  7. Use the Date field to define the starting date from which you want to import the data.

With a Daily Time Profile Period, use the field to define the 24-hour period for which data is to be imported. The latest date you can specify is the current day.

With a Weekly Time Profile Period, use the field to define the starting date for which data is to be imported. ClearSCADA will use this Date to ascertain which data it needs to import for the day of the week that is selected on the Time Profile window. So, for instance, if data is to be imported for a Tuesday and the specified Date is for a Tuesday or earlier day of the week, ClearSCADA will import the data for the Tuesday in the week beginning with the specified Date. However, if the specified Date is for a Wednesday or later day of the week, ClearSCADA will import the data for the Tuesday in the week following the specified Date. The latest date you can specify is the start of the current week (Sunday being deemed the start of a week).

(For information on specifying a Time Profile’s Period, see Specify the Profile’s General Properties.)

  8. Ensure that the Generate Curve check box is selected.
    The other fields within the Distribution section become available for use.
  9. Use the Probability spin box to define the accuracy with which the calculations take into account the historic data distribution within each data sample. The higher the number, the closer the vectors follow the historic data.

You may, for example, want to use a lower Probability if the data includes occasional spurious values that fall outside the main distribution range for that data, so that the calculations tend not to take those spurious values into account.

  10. Use the Interval spin box to define the sampling interval for the historic data. ClearSCADA uses a Gaussian Distribution calculation on the historic data for each sample interval, and uses the calculation to assess the position of the resulting vector in the Editor window. The Interval is in minutes.
  11. Use the Confidence Limit option buttons to either:
  • Produce a series of vectors above the historic data distribution level, by selecting the Upper option button.
  • Produce a series of vectors below the historic data distribution level, by selecting the Lower option button.
  12. Select the OK button.
    The Import Historic Data window is closed. The historic data for the specified period is temporarily displayed in the Time Profile window, along with a profile based on that historic data.
  13. If the Time Profile has a Weekly span, repeat the above steps for any other day of the week for which the profile is to be based on historic data.

Example:

This example shows a profile that was generated automatically, based on historic data:

Imported historic data appears as green crosses in the Time Profile window. The data is only displayed temporarily. It is lost as soon as the window is closed.
ClearSCADA uses a series of Gaussian distribution calculations to determine the vector positions. The number of calculations depends on the interval specified. In this example, the interval is 30 minutes, so ClearSCADA adds one vector to the profile for each 30-minute interval. As the Confidence Limit is set to ‘Lower’, the vectors are added below the actual data. The probability—in this case 80%—determines how closely the profile follows the historic data.

NOTE: If historic data is erroneously imported to the wrong Time Profile, either close the Time Profile window without saving any changes, or use the Undo feature (see Use Undo and Redo).

Manually Produce a Profile Based on Historic Data

To produce a Time Profile manually and base that profile on actual historic data:

  1. Display the Time Profile in Edit mode.
  2. If the Time Profile has a Weekly span, select the day of the week for which ClearSCADA is to base the profile on historic data.

(Each Import request imports historic data for a single day. With a Weekly Time Profile, you need to perform a separate Import request for each day of the week for which the profile is to be based on historic data.)

  3. Select the Edit menu from the main ViewX menu bar.
    A context sensitive menu is displayed.
  4. Select the Import Historic Data option.
    The Import Historic Data window is displayed.
  5. Select the Source browse button.
    A Reference browse window is displayed.
  6. Use the Reference browse window to select a Time Profile, Forecast, or point for which Historic is enabled. The item can reside anywhere on your system.
  7. Use the Date field to define the starting date from which you want to import the data.

With a Daily Time Profile Period, use the field to define the 24-hour period for which data is to be imported. The latest date you can specify is the current day.

With a Weekly Time Profile Period, use the field to define the starting date for which data is to be imported. ClearSCADA will use this Date to ascertain which data it needs to import for the day of the week that is selected on the Time Profile window. So, for instance, if data is to be imported for a Tuesday and the specified Date is for a Tuesday or earlier day of the week, ClearSCADA will import the data for the Tuesday in the week beginning with the specified Date. However, if the specified Date is for a Wednesday or later day of the week, ClearSCADA will import the data for the Tuesday in the week following the specified Date. The latest date you can specify is the start of the current week (Sunday being deemed the start of a week).

(For information on specifying a Time Profile’s Period, see Specify the Profile’s General Properties.)

  8. Ensure that the Generate Curve check box is clear.
    The other fields within the Distribution section of the window are unavailable for use.
  9. Select the OK button.
    The Import Historic Data window is closed, and the historic data for the specified period is temporarily displayed in the Time Profile window.
  10. Manually add vectors to produce the profile that you require, using the historic data as a guide (see Add a Vector).
  11. If the Time Profile has a Weekly span, repeat the above steps for any other day of the week for which the profile is to be based on historic data.

The historic data indicators are only displayed temporarily, as a guide, while the window remains open.

If required, you can view different days on a Weekly Time Profile. ClearSCADA will display the indicators for the day for which historic data has been imported whenever you return to the tab for that day, providing the window remains open.

With any Time Profile, the indicators are lost as soon as the Time Profile window is closed.

Example:

This example shows temporarily imported data in a Time Profile window. The data can be used as a guide when manually adding vectors to produce a profile based on that historic data.

Imported historic data appears as green crosses in the Time Profile window. The data is only displayed temporarily. It is lost as soon as the window is closed.


Core Configuration Guide - Generate a Profile's Data Programmatically (Configuring Time Profiles)

Generate a Profile’s Data Programmatically

You can plot a Time Profile’s change in value by manually adding vectors to the Profile’s graph (see Edit a Time Profile), or you can:

  • Produce a Profile Based on Historic Data
  • Generate a Profile’s Data Programmatically.

Use the SetVectors method to modify a Profile’s vectors programmatically using a custom program, Logic, or script. The SetVectors method has these arguments:

  • Times (Word array)—The array of times to be used for the Profile’s vectors.

If the Profile Period is Daily, the times have to be in minutes from midnight at the start of the day. As such, the times have to be between 0 and 1439 minutes (the number of minutes in a day).

If the Profile Period is Weekly, the times have to be in minutes from midnight at the start of the week (Sunday). As such, the times have to be between 0 and 10079 minutes (the number of minutes in a week).

  • Values (Array of the appropriate type)—The array of values to be used for the Profile’s vectors. Ideally, the array should contain the type of value that corresponds to the Profile’s type (for instance floating point 32-bit values to modify a Float Time Profile’s vectors programmatically). However, if an array contains different type(s) of value, ClearSCADA will automatically convert those values to the correct type when the SetVectors method is executed.

To successfully modify a Profile’s vectors programmatically:

  • All Times have to be in sequential order, starting with the earliest time.
  • All Times have to be unique.
  • Both arrays have to contain the same number of entries.
  • All Values and Times have to be within the Profile’s Range (see Specify the Profile’s Range) and time Period (see Specify the Profile’s General Properties).

If any of the above are not adhered to, the method call will be unsuccessful and ClearSCADA will not modify the Profile’s vectors.

For an example that demonstrates how a Time Profile’s vectors might be generated programmatically, see Use a JScript Program to Modify a Time Profile’s Vectors Programmatically.

Further Information

Using ClearSCADA Script: see the ClearSCADA Guide to Scripting.

Use the Automation Interface: see the Server Automation Technical Reference online Help.


Core Configuration Guide - Example Configuration (Configuring Time Profiles)

Example Configuration

This section comprises several examples that demonstrate how Time Profiles might be configured or used on a ClearSCADA system. The section contains these examples:

  • Use a JScript Program to Modify a Time Profile’s Vectors Programmatically
  • Use Logic to Compare a Time Profile’s Value with the Readings from Plant.


Core Configuration Guide - Use a JScript Program to Modify a Time Profile's Vectors Programmatically (Configuring Time Profiles)

Use a JScript Program to Modify a Time Profile’s Vectors Programmatically

This example demonstrates how JScript might be used to generate a Time Profile’s vectors.

Example:

A Time Profile’s values are to be compared with the point data that is being retrieved from plant. The Time Profile’s values are to be generated programmatically.

A Double Time Profile named ‘My Time Profile’ is added to the database.

The Time Profile’s Period is specified as Daily.

A Microsoft® JScript program is used to generate a Time Profile’s vectors programmatically. This particular program uses constant values, but the values and times could equally be calculated according to a particular algorithm.

var Times = new Array(5);
Times[0] = 300;
Times[1] = 500;
Times[2] = 800;
Times[3] = 1000;
Times[4] = 1200;
var Values = new Array(5);
Values[0] = 10.0;
Values[1] = 25.0;
Values[2] = 50.0;
Values[3] = 30.0;
Values[4] = 20.0;
var Profile = Server.FindObject("My Time Profile");
Profile.Interface.SetVectors(Times, Values);

Further Information

Generate a Profile’s Data Programmatically.

Use the Automation Interface: see the Server Automation Technical Reference online Help.


Core Configuration Guide - Use Logic to Compare a Time Profile's Value with the Readings from Plant (Configuring Time Profiles)

Use Logic to Compare a Time Profile’s Value with the Readings from Plant

This example demonstrates how a Time Profile might be used in a Logic program, to provide a varying value against which data is compared. Be aware that a Time Profile’s current value is updated once, at the beginning of each minute. As such, each comparison is between the value of the Time Profile at the start of each minute and the value of the data against which the Profile’s value is being compared at that time.

Example:

A Time Profile is used to define the expected fluctuations in level each day.

The Time Profile is used in a Logic program, to compare the expected levels with the actual readings from plant, throughout the day.

In this particular example, the Logic uses the built-in GE (Greater Than or Equal To) function to compare the Time Profile’s value to the live data.

At 09:30, the Time Profile indicates that the expected level for that time of the day should be no greater than 40.
... as indicated by the GE function’s output being ‘True’.
The reading obtained from plant at the time is 25. This value is lower than the expected uppermost level for that time of day...

At 18:00, the Time Profile shows that the expected level has decreased. It should now be no greater than 30.
...as indicated by the GE function’s output being ‘False’.
The reading obtained from plant at the time is 32. This value is greater than the expected uppermost level for that time of day...

Further Information

Add a Time Profile.

Edit a Time Profile.

Working with Logic Programs: see the ClearSCADA Guide to Logic.

Built-in Logic Functions: see Built-in Functions, Function Blocks, and Conversions in the ClearSCADA Guide to Logic.

The GE function is one of several Comparison functions that can be used in Logic programs: see Comparison in the ClearSCADA Guide to Logic.


Core Configuration Guide - Configuring Forecasts

Configuring Forecasts

NOTE: Forecasts are a specialized area—if your system is not used for importing future (forecast) data, you can ignore this section of the guide.

Forecasts are predictions of future records of the values, at various times, of a measurable quantity, such as a river level. The time period that Forecasts cover may range, for example, from one day in the past to two days into the future, or from several months in the past to several months into the future.

When Forecasts are used on a ClearSCADA system, the Forecast data is typically imported at regular intervals using an executable client program, such as one written in Visual BasicTM, or Mimic script. The actual data import is usually an automated process.

This section explains how to:

  • Add a Forecast
  • Configure the Forecast Properties.

For information on importing Forecast data into ClearSCADA, see the documentation supplied with the Import utility that is used on your system. Also see Example Import Program.

For information on using Historic Calculations to produce Forecast data, see Configuring Historic Calculations.


Core Configuration Guide - Add a Forecast (Configuring Forecasts)

Add a Forecast

To add a Forecast to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a new Forecast.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Forecast option.
    A Forecast is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Forecast (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

Once you have added a Forecast, you need to Configure the Forecast Properties.


Core Configuration Guide - Configure the Forecast Properties (Configuring Forecasts)

Configure the Forecast Properties

To configure the Forecast properties, you need to display the Forecast Form (see Display a Form).

The Forecast Form has these tabs:

  • Identification—Use to configure the Identification properties (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the Forecast (see Using the User Methods Tab to Define Custom Actions).
  • Alarm—Use to define optional features associated with any Forecast alarms (see Defining an Item or Group’s Alarm Properties).
  • Redirection—Use to define any alarm redirections for the Forecast (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • Forecast—Use to:
  • Specify the Maximum Number of Forecasts Held
  • Specify the Time Interval Between Data Values
  • Configure the Limits for a Forecast
  • Define the Period of Forecast Data for which ClearSCADA can Generate Limit Alarms
  • Define the Time Period for which ClearSCADA Imports Forecast Values
  • Define the Appearance of a Forecast’s Values
  • Define the Trend Properties.

NOTE: If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed toward the top of the Forecast tab. Use the field to specify the area with which any Forecast alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events).
For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest.


Core Configuration Guide - Specify the Maximum Number of Forecasts Held (Configuring Forecasts)

Specify the Maximum Number of Forecasts Held

Use the Number of Forecasts combo box at the top of the Forecast tab to specify the number of Forecasts that a Forecast database item is to hold.

Each Forecast is a series of values that typically occur at the interval specified in the Value Interval field, below.

You can configure each Forecast database item to hold between 1 and 8 separate Forecasts. Once the specified limit is reached, ClearSCADA automatically deletes the oldest Forecast whenever a new Forecast is imported.


Core Configuration Guide - Specify the Time Interval Between Data Values (Configuring Forecasts)

Specify the Time Interval Between Data Values

Use the Value Interval field near the top of the Forecast tab to specify the frequency of the Forecast values that are to be imported into this Forecast object.

Enter the interval in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

‘Standard’ import utilities pass arrays of values to ClearSCADA, with each value being imported at the Value Interval apart from the next value. As such, there are no ‘gaps’ in the Forecast data.

‘Advanced’ import utilities pass arrays that include the value, time, and quality. As such, the Value Interval is ignored, as the values are imported at the interval at which they occur in the Forecast data.

NOTE: If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed just below the Value Interval field. Use the Area of Interest field to specify the area with which any Forecast alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events).
For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest.


Core Configuration Guide - Configure the Limits for a Forecast (Configuring Forecasts)

Configure the Limits for a Forecast

Use the fields within the Alarm Limits section of the Forecast tab to specify whether ClearSCADA is to raise any alarms as a result of Forecast values exceeding specified limits.

You can use these limits in conjunction with the fields in the Alarm Time Window to specify the period during which ClearSCADA is able to generate such alarms (see Define the Period of Forecast Data for which ClearSCADA can Generate Limit Alarms).

You can specify up to eight limits for which ClearSCADA is to raise alarms should any Forecast values exceed those limits.

Within the Alarm Limits section, each row represents a different limit (labelled 1 to 8). To use a limit, you select the Enabled check box for that limit. Once enabled, the rest of the fields in that row become available for use.

You do not need to set up the limits so that they form a particular order (for example, all High alarms together, followed by all Low alarms), as ClearSCADA organizes the limits internally, according to their configuration. However, we advise using ordering where possible, to allow the configuration to be readily assessed, should configuration changes be required in the future.

Use the fields to configure the limit settings:

  • Type—Use this combo box to specify whether the limit is a high or low limit:
  • High—The limit is a High limit. ClearSCADA raises an alarm if a Forecast value rises above this limit. Use the Limit field (below) to specify the actual value that have to be exceeded in order for ClearSCADA to raise the alarm.
  • Low—The limit is a Low limit. ClearSCADA raises an alarm if a Forecast value drops below this limit. Use the Limit field (below) to specify the actual value that has to be exceeded in order for ClearSCADA to raise the alarm.
  • Limit—Use to specify the Forecast value at which an alarm limit becomes active. ClearSCADA will raise an alarm if a Forecast value is greater than this limit (for a High-type limit) or less than this limit (for a Low-type limit).
  • Severity—Use this combo box to specify the level of importance associated with an alarm. A set of severity levels is provided for each ClearSCADA system (see Defining Severities). Choose the appropriate severity level from the list available on your system (the diagram below shows a default set of severity levels).
  • Description—Use this combo box to enter or select a suitable description for a limit. You can either highlight any existing description and replace it with a new one, or you can choose one of the available descriptions from the combo box list.

Each ClearSCADA system is supplied with a set of default descriptions for each limit, but these can be replaced by user-defined descriptions that are more specific to your system (see Define Descriptions for Numeric Point States in the ClearSCADA Guide to Server Administration).

If the Dictionary feature is used on your system, you can prefix strings in the Description field, in order for those strings to be replaced with another term, when displayed in a List or on a Mimic, in ViewX. For more information, see Dictionary Settings in the ClearSCADA Guide to Server Administration.

  • Color—By default, Forecast values are shown in black on displays such as Trends unless the value is in an alarm state (in which case it is displayed in the corresponding severity color).

Use the Color field if you want to associate the limit with a color other than the default color to indicate a ‘Normal’ state (black by default).

You can only associate a limit with a custom color if you have pre-configured custom colors available (see Defining a Custom State Color).

Use the Color field’s browse button to display a Reference browse window. Use the window to locate the required custom color.


Core Configuration Guide - Define the Period of Forecast Data for which ClearSCADA can Generate Limit Alarms (Configuring Forecasts)

Define the Period of Forecast Data for which ClearSCADA can Generate Limit Alarms

Use the fields within the Alarm Time Window section of the Forecast tab to specify the period of Forecast data for which ClearSCADA is able to generate any limit alarms that are defined in the Alarm Limits section of the tab (above).

  • Alarm Window Start Type—Use this combo box in conjunction with the Start Offset and Duration check boxes and fields to specify the period for which ClearSCADA is able to generate limit alarms. Choose from:
  • Forecast Start Time—ClearSCADA is able to generate limit alarms based on the start time of the Forecast data, taking into account any restrictions specified using the Start and/or Duration offsets.

If Start Offset is not enabled, but a Duration is specified, any alarm generation is restricted to the data that occurs from the start of the Forecast, for the period specified in the Duration field.

If a Start Offset is specified, but Duration is not enabled, alarm generation is restricted to the data that occurs from the start of the Forecast plus the Start Offset, up to the end of the Forecast. As such, the data at the start of the Forecast is ignored with regard to alarm generation.

If both a Start Offset and Duration are specified, any alarm generation is restricted to that Forecast data that occurs within the two offsets. ClearSCADA will not generate limit alarms for any Forecast data that occurs outside of these offsets.

  • Import Time—ClearSCADA is able to generate limit alarms based on the time that it imports the Forecast, taking into account any restrictions specified using the Start and/or Duration offsets.

If Start Offset is not enabled, but a Duration is specified, any alarm generation is restricted to the data that occurs from the time that the Forecast was imported into ClearSCADA, for the period specified in the Duration field.

If a Start Offset is specified, but Duration is not enabled, alarm generation is restricted to the data that occurs from the time that the Forecast was imported into ClearSCADA plus the Start Offset, up to the end of the Forecast. As such, any Forecast values that occur before the time that the Forecast was imported into ClearSCADA are ignored with regard to alarm generation (unless you specify a negative Start Offset).

If both a Start Offset and Duration are specified, any alarm generation is restricted to that Forecast data that occurs within the two offsets. ClearSCADA will not generate limit alarms for any Forecast data that occurs outside of these offsets.

No alarm filtering is applied if neither the Start Offset or Duration check boxes are selected.

  • Start Offset—Select this check box if the settings within this window are to determine the start of the period during which ClearSCADA can to generate an alarm if a Forecast value exceeds a limit.

Use the adjacent field to specify the time period following which ClearSCADA can to generate a limit alarm. Enter the time period in the OPC Time Format. You can enter a positive or negative value. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value. ClearSCADA only generates an alarm if a Forecast value exceeds an alarm limit during the time period after the Forecast Start, or Import Time, plus the time specified in this field.

Use in conjunction with the Duration check box and field (see below) if you want to further limit the period for which ClearSCADA can generate limit alarms.

Example:

A Forecast is imported, which has data that starts two days before the present day, comprising values that occur at 15-minute intervals.

The Forecast has this configuration:
Limit 1 enabled as a High Limit with a Limit of 100
Limit 2 enabled as a Low Limit with a Limit of 10

The Alarm Time Window section of the Forecast Form has these settings:
Alarm Window Start Type is set to ‘Forecast Start Time’
The Start Offset check box is enabled
The corresponding field is set to 30M (30 minutes).

The Limit settings indicate that the ‘normal’ range for the Forecast values is between 10 and 100.

If any Forecast values fall below 10 or rise above 100 in the block of data that is imported for the 30 minutes of the Forecast, ClearSCADA does not raise any limit alarms for that data. This is because the limits are exceeded before the start of the Alarm Time Window and are therefore ignored.

However, if any Forecast values fall below 10 or rise above 100 in the imported data that follows the first 30 minutes-worth of data, ClearSCADA raises a corresponding Low Limit or High Limit alarm.

Ensure that the Start Offset check box is clear if alarm generation is not to be determined using these Alarm Time Window settings.

  • Duration—Select this check box if the settings within this window are to limit the duration within which ClearSCADA can generate an alarm if a Forecast value exceeds a limit.

Use the adjacent field to specify the duration during which ClearSCADA is able to generate a limit alarm. Enter the duration in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value. ClearSCADA only generates an alarm if a Forecast value exceeds an alarm limit during the period following the Forecast Start, or Import Time, plus the time specified in the Start Offset field (above), if the exceeded limit occurs within the time period specified in this Duration field.

Example:

A Forecast is imported at midday each day, which has data that starts one day before the present day and finishes four days in the future. The data comprises values that occur at 15-minute intervals, starting from 00:00hrs each day.

The Forecast has this configuration:
Limit 1 enabled as a High Limit with a Limit of 100
Limit 2 enabled as a Low Limit with a Limit of 10

The Alarm Time Window section of the Forecast Form has these settings:
Alarm Window Start Type is set to ‘Import Time’
The Start Offset check box is enabled
The corresponding field is set to -1D (midday yesterday)
The Duration check box is enabled
The corresponding field is set to 3D (a three-day duration).

The Limit settings indicate that the ‘normal’ range for the Forecast values is between 10 and 100.

ClearSCADA ignores any alarm limits that are exceeded in the block of data that is imported for the 12 hours of the Forecast, as the limits are exceeded before the start of the Alarm Time Window (‘now’ - 1D, as specified by the Start settings above).

ClearSCADA also ignores any alarm limits that are exceeded in the block of data that is imported for the last 12 hours-worth of data, as the limits are exceeded after period during which ClearSCADA is configured to generate limit alarms (as specified by the Duration settings above - the Duration window starts after the first 12 hours-worth of data, and lasts for the next three days-worth of data, resulting in the last 12 hours-worth of data being outside of the Duration period).

If any Forecast values fall below 10 or rise above 100 in the block of data that follows the first 12 hours-worth of data, and occurs before the last 12 hours-worth of imported data, ClearSCADA raises a corresponding Low Limit or High Limit alarm.

Ensure that the Duration check box is clear if the duration for alarm generation is not to be determined using these Alarm Time Window Duration settings. In which case, ClearSCADA is able to raise limit alarms for any Forecast data that occurs after the Start Offset up to and including the final Forecast value.


Core Configuration Guide - Define the Time Period for which ClearSCADA Imports Forecast Values (Configuring Forecasts)

Define the Time Period for which ClearSCADA Imports Forecast Values

Use the fields within the Value Time Window section of the Forecast tab to specify the period for which ClearSCADA is to import Forecast values:

  • Start Offset—Select this check box if the settings within this window are to determine the start of the period for which ClearSCADA is to import Forecast values.

Use the adjacent field to specify the time period following which ClearSCADA is to import Forecast values. Enter the time period in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value. ClearSCADA only import a Forecast value if that value is time stamped with a time that occurs on or after the Forecast start plus the time specified in this field.

Example:

A Forecast is imported, which has data that starts two days before the present day, comprising values that occur at 15-minute intervals.

The Value Time Window section of the Forecast Form has these settings:
The Start Offset check box is enabled
The corresponding field is set to 30M (30 minutes).

This results in ClearSCADA only importing Forecast Values that occur on or after 30 minutes from the start of the Forecast. Values that occur earlier than 30 minutes from the start of the Forecast are ignored and not imported into ClearSCADA. (In this particular example, the first two Forecast values are ignored—the value at the very start of the Forecast, and the value that occurs 15 minutes into the Forecast.)

Ensure that the Start Offset check box is clear if ClearSCADA is to import values from the start of the Forecast.

  • Duration—Select this check box if the settings within this window are to limit the duration for which ClearSCADA imports Forecast values.

Use the adjacent field to specify the duration during which ClearSCADA is to import Forecast values. Enter the duration in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value. ClearSCADA only imports a Forecast value if that value is time stamped with a time that occurs during the period following the Forecast start plus the time specified in the Start Offset field (above), and on or before the time period specified in this Duration field.

Example:

A Forecast is imported, which has data that starts two days before the present day and finishes one day in the future, comprising values that occur at 15-minute intervals.

The Value Time Window section of the Forecast Form has these settings:
The Start Offset check box is enabled
The corresponding field is set to 30M (30 minutes)
The Duration check box is enabled
The corresponding field is set to 2D 22H.

ClearSCADA ignores any values that occur prior to 30 minutes from the start of the Forecast (as these exceed the Start Offset settings above). Such values are not imported into ClearSCADA.

ClearSCADA also ignores any values that occur within the last 1.5 hours of the Forecast (as these occur outside of the Duration period, specified above).

ClearSCADA only imports Forecast values that occur on or after 30 minutes into the Forecast start time and 1.5 hours before the end of the Forecast. (In this particular example, ClearSCADA does not import the first two Forecast values, or the last six Forecast values, as these occur outside the Value Time import period.)

Ensure that the Duration check box is clear if ClearSCADA is to import values up to the end of the Forecast.


Core Configuration Guide - Define the Appearance of a Forecast's Values (Configuring Forecasts)

Define the Appearance of a Forecast’s Values

Use the fields within the Formatting section of the Forecast tab to define the appearance of a Forecast’s values on other displays, such as Lists and Trends:

  • Units—Use the Units combo box to enter or select the appropriate measurement units for the Forecast values. Either highlight the existing entry and overwrite it with a new type of measurement, or choose a measurement from the units list (displayed using the arrow button).

The list of measurements can be customized for your system (see Define Standard Descriptions for Measurement Units in the ClearSCADA Guide to Server Administration).

  • Format—Use this field to specify the format that the Forecast values are to take on other displays. Select the browse button to display the Text Format window, from which you can choose or define the required type of formatting. For more information, see Choose a Format Category.


Core Configuration Guide - Define the Trend Properties (Configuring Forecasts)

Define the Trend Properties

You can display the trend, or movement, of a Forecast’s values in the form of a graph. The graph is referred to as a Trend.

Each Trend consists of an x-axis, a y-axis, and a trace. The x-axis displays a time interval, and the y-axis displays the measurement units. The Trace represents the Forecast values.

Y-Axis
Trace
X-Axis

Once Forecast data has been imported into a Forecast object, you can view the data as a Trend by using the Display <Trace Name> Trend pick action, available from the Forecast object. (The pick action only becomes available once data exists for a Forecast object.)

Use the fields within the Trend section of the Forecast tab to define the settings for when the data is displayed as a Trend:

  • Maximum—Use to specify the highest value to be shown on the y-axis.
  • Minimum—Use to specify the lowest value to be shown on the y-axis.
  • Logarithmic—Use this check box to define whether the y-axis is logarithmic or linear.

Select the Logarithmic check box if you want the y-axis to have a logarithmic scale.

Clear the Logarithmic check box if you want the y-axis to have a linear scale.

  • Offset—Specify the default start time for the x-axis, in relation to the present time.

Enter the offset in the OPC Relative Time Format. For example, H - 23H for the earliest time on the x-axis to be 23 hours before the beginning of the current hour. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

  • Interval—Specify the default time interval for the x-axis, starting from the time specified in the Offset field.

Enter the interval in the OPC Time Format, for example 1D for the x-axis to display a one-day period. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.


Core Configuration Guide - Example Import Program (Configuring Forecasts)

Example Import Program

This example demonstrates how Mimic script might be used to import Forecast data.

Example:

On a particular ClearSCADA system, Mimic script is used to import hard coded Forecast data for demonstration and test purposes. The script comprises:

option explicit
Sub GenerateForecast
Dim Frc
Dim FrcData(9)
Dim StartTime
Dim ForecastName
' Find the forecast in the database
Set Frc = Server.FindObject("Region 1 Forecasts.MyTestForecast")
if Frc is nothing then
MsgBox "Cannot find forecast object."
else
' Hard coded data for demonstration purposes
FrcData(0) = 30.4
FrcData(1) = 30.5
FrcData(2) = 30.6
FrcData(3) = 30.7
FrcData(4) = 30.75
FrcData(5) = 30.7
FrcData(6) = 30.65
FrcData(7) = 30.6
FrcData(8) = 30.55
FrcData(9) = 30.5
' Start time
StartTime = Now
' Forecast name
ForecastName = FormatDateTime( StartTime, vbLongDate ) + " "
ForecastName = ForecastName + FormatDateTime( StartTime, vbShortTime )
' Write the forecast
Frc.Interface.SetForecast ForecastName, StartTime, FrcData
end if
End Sub

The script is configured to run whenever a ‘Generate Forecast Data’ button is selected on the Mimic on which the script exists.

Further Information

Mimic Scripts: see Mimic Scripts in the ClearSCADA Guide to Scripting.


Core Configuration Guide - Using Schedules to Automate Regular Functions

Using Schedules to Automate Regular Functions

You can use Schedules to perform specific functions on your system at regular, specified times. For example:

  • Generate reports
  • Archive data
  • Run logic programs
  • Dial out to PSTN outstations.

You can choose the type of Schedule that you require in relation to the frequency of the events that you want to schedule on your system—Simple, Daily, Weekly, Monthly, or Yearly (see Types of Schedule Display).

Schedules allow you to automate regular functions, to alleviate the need for manual intervention each time such a function needs to be carried out (see Set up a Schedule).

Example:

The figure below shows a Schedule in which events are triggered at 04:05 and 16:05 on a daily basis (position the cursor over an event marker to check its trigger time, or select the View menu and choose the Schedule Times option).

The actions that the Schedule triggers at those times are a one shot call to an outstation (PSTN Ostn 2), and a dial out promotion to an outstation set (PSTN Set 2).

The promotion period, enclosed in parentheses, shows that the promotion is for a 15-minute interval over a one-hour period. The first 0 indicates that the server does not dial the outstations on the set as soon as the promotion period starts. The second 0 indicates the synchronization offset from the scheduled times (as this is zero, the server starts the promotion period at the event times specified on Schedule, rather than at an offset from those times).

Scheduled events are triggered infinitely at the times and regularity indicated on the Schedule Display (Daily, Weekly, Monthly, and Yearly Schedules), or on the Schedule Form (Simple Schedules). To halt a Schedule you need to take it out of service.


Core Configuration Guide - Types of Schedule Display (Using Schedules to Automate Regular Functions)

Types of Schedule Display

You can configure five different types of Schedule, as appropriate to your system requirements. The Schedule Display that operators can view to check for scheduled events, or that engineers can use to configure trigger times and scheduled actions, varies, depending on the Schedule type:

  • Simple Schedule
  • Daily Schedule
  • Weekly Schedule
  • Monthly Schedule
  • Yearly Schedule.

NOTE: The divisions on each Schedule Display (other than that for a Simple Schedule) adjust in relation to the size of the window—to display the greatest number of divisions, maximize your ViewX window and the size of the Schedule Display.


Core Configuration Guide - Simple Schedule (Using Schedules to Automate Regular Functions)

Simple Schedule

On a Simple Schedule, you specify the action(s) that are to trigger on Schedule execution. Unlike other types of Schedule, you do not add events to a Simple Schedule—any actions associated with a Simple Schedule execute at the offset and frequency that you specify, using fields on the Schedule Form (see Define when a Simple Schedule Executes).

As with other types of Schedule, you add the actions that are to trigger on a Schedule basis, to the Object area of the Schedule Display...
...but unlike other Schedules, you do not add events to a Simple Schedule Display—any associated actions trigger at the offset and frequency that you assign on the Schedule Form.

You need to configure a separate Simple Schedule for any action(s) that require triggering at different rates or offsets to other scheduled action(s).

Further Information

Set up a Schedule.


Core Configuration Guide - Daily Schedule (Using Schedules to Automate Regular Functions)

Daily Schedule

On a Daily Schedule, you can define processes to start from any minute within the 24-hour period on display.

You need to configure a separate Daily Schedule for any action(s) that require triggering at different times to other scheduled action(s).

When you are editing the Schedule Display, the time indicated by the position of the cursor is displayed in the format HH:MM (where HH = hours, MM = minutes), for example 08:53.

If required, you can associate a Calendar with a Daily Schedule. A Calendar allows you to specify different event times for specific dates in a year, such as company shutdown dates. When a Calendar is associated with a Schedule, six additional tabs are displayed on the Schedule—one for each of the day types that are assigned to the Calendar.

Further Information

Set up a Schedule.

Associate a Calendar with a Daily or Weekly Schedule.

Add an Event to a Schedule that is Associated with a Calendar.


Core Configuration Guide - Weekly Schedule (Using Schedules to Automate Regular Functions)

Weekly Schedule

The display for a Weekly Schedule looks similar to a Daily Schedule, with the addition of a tab for each day of the week.

Select the day that you require from the tabs at the top of the display, before adding any events to a Weekly Schedule.

When you are editing the Schedule Display, the time indicated by the position of the cursor is displayed in the format HH:MM (where HH = hours, MM = minutes), for example 09:43.

You can define processes to start from any minute within each 24-hour period that you display.

If required, you can associate a Calendar with a Weekly Schedule. A Calendar allows you to specify different event times for specific dates in a year, such as company shutdown dates. When a Calendar is associated with a Schedule, six additional tabs are displayed on the Schedule—one for each of the day types that are assigned to the Calendar.

You have to configure a separate Weekly Schedule for each action that you require triggering at a different time or on a different day or days to other scheduled action(s) (except where a Calendar fulfills such requirements).

Example:

A Weekly Schedule, Channel Stats 1, is configured to automatically reset the call statistics for a channel at 20:05 each Tuesday.

A separate Weekly Schedule is configured to automatically perform a One Shot call to each of three PSTN outstations at 21:15 each Thursday.

Because the actions require triggering on different days and at different times, separate Weekly Schedules are required.

If both types of action were to be carried out at the same time as each other, and on the same day(s), only one Weekly Schedule need be configured.

Further Information

Set up a Schedule.

Associate a Calendar with a Daily or Weekly Schedule.

Add an Event to a Schedule that is Associated with a Calendar.


Core Configuration Guide - Monthly Schedule (Using Schedules to Automate Regular Functions)

Monthly Schedule

On a Monthly Schedule, you can define processes to start from any 5-minute interval on any day of the month (for instance at 11:00, 11:05, 11:10, or 11:15).

You need to configure a separate Monthly Schedule for any action(s) that require triggering at different times to other scheduled action(s).

When you are editing the Schedule Display, the time indicated by the position of the cursor is displayed in the format D, HH:MM (where D = date, HH = hours, MM = minutes). For example, 12, 11:25 indicates 11:25am on the 12th day of the month.

You may find it easier to maximize the Schedule Display while adding processes, so that you can readily select the required times.

Be aware that if you add an event to the 31st day of a Monthly Schedule, any scheduled actions will only trigger on the 31st during those months that include 31 days. Similarly, any events assigned to the 30th or 31st day will not trigger during February, and those assigned to the 29th of the month will only trigger during February, when the year is a Leap year.

Further Information

Set up a Schedule.


Core Configuration Guide - Yearly Schedule (Using Schedules to Automate Regular Functions)

Yearly Schedule

The display for a Yearly Schedule looks similar to a Monthly Schedule, with the addition of a tab for each month of the year.

You can define processes to start from any 5-minute interval (for instance, 12:00, 12:05, 12:10, or 12:15) on any day of any month in the year.

Select the month that you require from the tabs at the top of the display, before adding any events to a Yearly Schedule.

You need to configure a separate Yearly Schedule for any action(s) that require triggering at different times or on different months to other scheduled action(s). For instance, if some actions need triggering during March, June, and September, and another set of actions need triggering during January, March, and July, you will need to configure two Yearly Schedules, one for each set of actions.

When you are editing the Schedule Display, the time indicated by the position of the cursor is displayed in the format D, HH:MM (where D = date, HH = hours, MM = minutes). For example, 4, 05:35 indicates 5:35am on the 4th day of the month that is on display.

You may find it easier to maximize the Schedule Display while adding processes, so that you can readily select the required times.

Further Information

Set up a Schedule.


Core Configuration Guide - Set up a Schedule (Using Schedules to Automate Regular Functions)

Set up a Schedule

To set up a Schedule and add an action to that Schedule, you need to:

  1. Add a Schedule.
  2. Display the Schedule Form.
  3. Define the Basic Schedule Properties.
  4. If required, Associate a Calendar with a Daily or Weekly Schedule.
  5. Define the frequency with which the Schedule is to trigger any action(s)—the procedure varies, depending on the type of Schedule:
  • If the Schedule is a Simple Schedule, you use the Schedule Form to Define when a Simple Schedule Executes.
  • If the Schedule is not a Simple Schedule, you Add an Event Directly to a Schedule.
  6. Add an Action to a Schedule.
  7. Save the configuration (see Saving Configuration Changes).

There are also other activities that you can undertake when configuring a Schedule.

For Schedules other than Simple Schedules, you can:

  • Check the Event Trigger Times
  • Move an Event
  • Delete an Event.

With any type of Schedule, you can:

  • Edit a Scheduled Action
  • Adjust the Order in which Actions are Triggered
  • Delete a Scheduled Action.

For a series of examples showing how Schedules can be used to trigger actions automatically on a ClearSCADA system, see Example Configuration.

NOTE: Do not confuse the Schedules with Alarm Redirection Schedules, which are used to redirect alarms at different times on different days. For information on Alarm Redirection Schedules and the Alarm Redirection Calendars on which they are used, see Configure an Alarm Redirection Calendar in the ClearSCADA Guide to Alarm Redirection.


Core Configuration Guide - Add a Schedule (Using Schedules to Automate Regular Functions)

Add a Schedule

To add a Schedule:

  1. In the Database Bar, right-click on the System or Group for which you want to add the new Schedule.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, followed by the Explorer Bar option, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Schedule option.
    A Schedule is added to the root of the System or to the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Schedule (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added a Schedule, you can configure its properties (see Display the Schedule Form).

ATTENTION: Ensure that you specify the type of schedule before adding any events to that schedule (see Define the Basic Schedule Properties). Changing the schedule type at a later stage (from Daily to Weekly, for instance) will result in deletion of any events associated with that schedule.


Core Configuration Guide - Display the Schedule Form (Using Schedules to Automate Regular Functions)

Display the Schedule Form

To configure a Schedule, you need to display its Form. The Form contains the fields required to configure a Schedule.

To display the Schedule Form:

  1. Right-click on the Schedule in the Database Bar.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the Properties option.
    The Schedule Form is displayed.
    Identification tab
    Schedule tab
    User Methods tab

You can use the Schedule Form to:

  1. Configure the Identification details (see Defining Identification Details).
  2. Configure any custom pick actions that are to be associated with the Schedule (see Using the User Methods Tab to Define Custom Actions).
  3. Define the type of Schedule, the time zone in which it operates and whether the schedule is in service (see Define the Basic Schedule Properties).
  4. Define when a Simple Schedule Executes.
  5. Optionally Associate a Calendar with a Daily or Weekly Schedule.
  6. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Define the Basic Schedule Properties (Using Schedules to Automate Regular Functions)

Define the Basic Schedule Properties

Use the fields at the top of the Schedule tab on the Schedule Form to define the type of Schedule you require, the time zone in which it operates and specify whether the Schedule is in service (‘active’).

To configure these properties:

  1. Display the Schedule Form.
  2. Select the Schedule tab.
  3. Define whether the Schedule is online and can be used by the server to carry out regular functions on the system.

Either:

  • Select the In Service check box to put the Schedule online. (For more information, see Placing an Item In Service.)
  • Clear the In Service check box if the Schedule is not to be used at this time.
  4. Use the Type combo box to select the type of Schedule that you require:
  • Simple—Select a Simple Schedule for processes that occur with a regularity that is easier to define using an Offset and Interval, rather than by inserting events onto another type of Schedule (see Simple Schedule).
  • Daily—Select a Daily Schedule for processes that occur at the same time every day. You can define processes to start from any minute within the 24-hour period on this type of Schedule (see Daily Schedule).
  • Weekly—Select a Weekly Schedule for processes that occur at different times each day, or only on certain days of the week. This option produces a display similar to the Daily Schedule, but with the addition of a separate tab for each day. You can define processes to start from any minute of any day on this type of Schedule (see Weekly Schedule).
  • Monthly—Select a Monthly Schedule for processes that occur at the same time each month, but for which a Weekly Schedule is not appropriate. You can configure processes to occur at any five-minute interval of any day on this type of Schedule (see Monthly Schedule).
  • Yearly—Select a Yearly Schedule for processes that occur infrequently throughout each year. This option produces a display similar to the Monthly Schedule, but with the addition of a separate tab for each month. You can configure processes to occur at any five-minute interval of any day in any month on this type of Schedule (see Yearly Schedule).
  5. Use the Time Zone combo box to specify the time zone that is used for Schedule execution.

Specify either:

  • Coordinated Universal Time (UTC), for the Schedule to execute in UTC.
  • Local Time without Daylight Saving Time, for the Schedule to execute in Local Time, for instance EST (Eastern Standard Time) if the local time zone is that for the East coast of America. No adjustments are made for any Daylight Saving Time (DST).

or:

  • Local Time with Daylight Saving Time, for the Schedule to execute in Local Time. ClearSCADA automatically adjusts the time to account for Daylight Saving Time (DST).

For more information, see Time Zone Support in ClearSCADA.

  6. Save the configuration (see Saving Configuration Changes).

If you have specified a Simple Schedule, you can now Define when a Simple Schedule Executes and then add action(s) to your Schedule (see Add an Action to a Schedule).

If you have specified a Daily or Weekly Schedule, you can optionally Associate a Calendar with a Daily or Weekly Schedule.

For a Schedule other than a Simple Schedule, you can now add events and actions to your Schedule (see Add an Event Directly to a Schedule, and see Add an Action to a Schedule).


Core Configuration Guide - Define when a Simple Schedule Executes (Using Schedules to Automate Regular Functions)

Define when a Simple Schedule Executes

Use the fields within the Simple section of the Schedule Form to specify when a Simple Schedule executes.

To specify when a Simple Schedule executes:

  1. Display the Schedule Form.
  2. Select the Schedule tab.
  3. Use the Offset field within the Simple section of the tab to specify the amount of time that occurs before Schedule execution starts.

Enter the synchronization offset in the OPC Relative Time Format, for instance H for the Schedule to first execute at the start of the present hour, and thereafter at the intervals specified in the Interval field, below. You can enter the offset directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required value. The minimum resolution that you can enter is 1M, for a one-minute offset.

  4. Use the Interval field within the Simple section of the tab to specify the frequency with which the Schedule executes.

Enter the frequency in the OPC Time Format, for instance 1H for the Schedule to execute at one-hourly intervals. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value. The minimum interval that you can specify is 1M (resulting in a schedule executing at one-minute intervals).

  5. Save the configuration (see Saving Configuration Changes).

For an example of how the Offset and Interval properties might be used to trigger actions on a regular basis, see A Simple Schedule used to Run a Pump.

You can now add the required action(s) to your Schedule (see Add an Action to a Schedule).


Core Configuration Guide - Associate a Calendar with a Daily or Weekly Schedule (Using Schedules to Automate Regular Functions)

Associate a Calendar with a Daily or Weekly Schedule

If you need to schedule events at different times on specific dates in the year—for instance during annual holidays or company shutdown periods—associate a Calendar with your Schedule. By associating a Calendar with a Schedule, you can specify different event times for up to six different ‘types’ of day, in addition to your usual Schedule.

You can associate a Calendar with a Daily Schedule or Weekly Schedule.

Calendars are an optional feature—you only need to create Calendar(s) on your system if automated actions differ on specific dates in the year and such actions cannot otherwise be specified on your Schedule(s).

To add a Calendar to your system and configure the required day types for that Calendar, see Configuring Calendars. (Do not confuse such Calendars with the Alarm Redirection Calendars that can be used to redirect alarms on a calendar basis. For information on Alarm Redirection Calendars, see Configure an Alarm Redirection Calendar in the ClearSCADA Guide to Alarm Redirection.)

Use the fields in the Daily/Weekly section of the Schedule Form to associate the Calendar with your Schedule.

To associate a Calendar with a Schedule:

  1. Display the Schedule Form.
  2. Select the Schedule tab.
  3. Select the browse button next to the Calendar field to display a reference browse window. Select the required Calendar from the window.
  4. Save the configuration (see Saving Configuration Changes).

You can now add event(s) and action(s) to your Schedule.

In addition to the tab(s) on which you assign your system’s ‘normal’ scheduled events, after attaching a Calendar, additional tabs are activated on the Schedule Editor. You use these tabs to specify the event times for the six additional day types that are assigned to the Calendar (see Add an Event to a Schedule that is Associated with a Calendar).

For an example of Calendar usage, see A Weekly Schedule and Calendar used to Generate a Series of Reports.


Core Configuration Guide - Display the Schedule in Edit Mode (Using Schedules to Automate Regular Functions)

Display the Schedule in Edit Mode

To add actions to a Schedule, or to add events (other than to a Simple Schedule), you need to display that Schedule in Edit mode.

To display a Schedule in Edit mode:

  1. Either:
  1. Double-click on the required Schedule entry in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).

or:

  1. Right-click on the Schedule in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Edit option.

The Schedule is displayed in Edit mode. The actual display varies, depending on the type of Schedule (see Types of Schedule Display).

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

Further Information

Add an Event Directly to a Schedule.

Add an Action to a Schedule.


Core Configuration Guide - Add an Event Directly to a Schedule (Using Schedules to Automate Regular Functions)

Add an Event Directly to a Schedule

This section applies to Schedules other than Simple Schedules.

After you Define the Basic Schedule Properties and, if required, Associate a Calendar with a Daily or Weekly Schedule, you can add the time(s) at which the scheduled events are to occur. For most types of Schedule, you do this by adding events to the Schedule Display. You can either add events directly to the Schedule Display (as per the procedure below), or add event(s) using the Add button on the Schedule Times window (see Add an Event using the Schedule Times Window). (With Simple Schedules, you do not add events to the Schedule Display—instead you use fields on the Schedule Form to Define when a Simple Schedule Executes.)

(Be aware that additional tabs are displayed on any Schedules that are associated with a Calendar (see Add an Event to a Schedule that is Associated with a Calendar).)

To add an event directly to a Schedule Display:

  1. Display the Schedule in Edit Mode.
  2. If you are adding an event to a Weekly or Yearly Schedule (or a Schedule that is associated with a Calendar), select the tab for the day or month for which you want to add the event.
  3. Move the cursor to the time at which you want the event to occur.
    The time that the cursor position indicates is shown on the display.
  4. To enter an event, double-click at the required point on the Schedule.
    An event indicator is placed on the Schedule Display.
    Double-click on the display to add an Event.

Be aware that if you add an event to the 31st day of a Monthly Schedule, any scheduled actions will only trigger on the 31st during those months that include 31 days. Similarly, any events assigned to the 30th or 31st day will not trigger during February, and those assigned to the 29th of the month will only trigger during February, when the year is a Leap year.

  5. Repeat steps 2 to 5 for each additional event that you want to add.
  6. Save the configuration (see Saving Configuration Changes).

If you haven’t done so already, you can now add the action(s) that ClearSCADA is to perform at the specified event times (see Add an Action to a Schedule).

In addition to adding events to a Schedule, you can also:

  • Check the Event Trigger Times
  • Move an Event
  • Delete an Event.

For examples that demonstrate events being used on Schedules, see Example Configuration.


Core Configuration Guide - Add an Event to a Schedule that is Associated with a Calendar (Using Schedules to Automate Regular Functions)

Add an Event to a Schedule that is Associated with a Calendar

When you Associate a Calendar with a Daily or Weekly Schedule, six additional tabs are activated on the corresponding Schedule Editor—one for each of the day types specified on the associated Calendar.

Add the required event times to each tab in turn, ensuring that you only add event times to the tabs inherited from the Calendar for events that are to occur at those times on those specific days (see Add an Event Directly to a Schedule). You use the Calendar Editor to specify when in a year those specific days occur (see Associate a Custom Day Type with a Calendar Date).

So, a Daily Schedule that is associated with a Calendar has a Normal tab, plus six additional tabs (the names of which are specified on the Calendar—see Rename a Day Type):

A Daily Schedule that is associated with a Calendar has a Normal tab. On this tab, you add the events that are to trigger on days that are not specified as ‘special’ days on the Calendar.
On the further six tabs (the names of which are inherited from the Calendar), you add the events that are to trigger on those specific days. (Use the Calendar Editor to specify when these days actually occur.)

A Weekly Schedule that is associated with a Calendar has the usual tabs for the seven days of the week, plus six additional tabs (with the tab names inherited from the day types specified on the Calendar):

A Weekly Schedule that is associated with a Calendar has a tab for each day of the week. On these tabs, you add the events that are to trigger on days that are not specified as ‘special’ days on the Calendar.
On the further six tabs (the names of which are inherited from the Calendar), you add the events that are to trigger on those specific days. (Use the Calendar Editor to specify when these days actually occur.)

If you haven’t done so already, once you have added the required events to your Schedule, you can add the actions that the server is to trigger at the specified times (see Add an Action to a Schedule).

For an example that further demonstrates Calendar usage, see A Weekly Schedule and Calendar used to Generate a Series of Reports.


Core Configuration Guide - Check the Event Trigger Times (Using Schedules to Automate Regular Functions)

Check the Event Trigger Times

This section applies to Schedules other than Simple Schedules.

To check the times at which each event on a Schedule triggers:

  1. Display the Schedule in Edit Mode or Display mode.
  2. Either:
  1. Position the cursor over a marker on the Schedule.
    The time that the event triggers is displayed next to the marker.

Example:

Moving the cursor over this marker on a Weekly Schedule...
...causes the event’s trigger time of 09:05 to be displayed.

Or:

  1. Display the Schedule Times Window.

The existing schedule execution times (the time(s) at which each event on the Schedule triggers) are displayed in a list in the window.

The Format in which Schedule Times are Displayed varies, depending on the type of Schedule.


Core Configuration Guide - Display the Schedule Times Window (Using Schedules to Automate Regular Functions)

Display the Schedule Times Window

This section applies to Schedules other than a Simple Schedules.

To display the Schedule Times window:

  1. Display the Schedule in Edit Mode or Display mode.
  2. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Schedule Times menu option.
    The Schedule Times window is displayed, listing the trigger times, days, or dates (as applicable) for the events that are configured on that Schedule.

The Format in which Schedule Times are Displayed varies, depending on the type of Schedule.

You can use the Schedule Times window to:

  • Check the Event Trigger Times
  • Add an Event using the Schedule Times Window

(Although you generally add events directly to a Schedule Display, rather than via the Schedule Times window—see Add an Event Directly to a Schedule.)

  • Move an Event
  • Delete an Event.


Core Configuration Guide - The Format in which Schedule Times are Displayed (Using Schedules to Automate Regular Functions)

The Format in which Schedule Times are Displayed

The format in which a schedule’s trigger times are displayed in the Schedule Times window varies, depending on the type of Schedule and whether that Schedule is associated with a Calendar.

The same format is also used in the Add Time and Edit Time windows that are displayed when you add or adjust an event time using the Schedule Times window (see Add an Event using the Schedule Times Window, and see Move an Event).

This section explains, via a series of examples, the formats in which event times are displayed.

Examples:

The Schedule Times window for a Weekly Schedule shows the days and times that event(s) trigger on a weekly basis. The example on the left shows events that trigger at 2:07pm on both Tuesday and Thursday each week. If a Weekly Schedule is associated with a Calendar (as per the example on the right), those events that are assigned to a particular Calendar day type are prefixed with the name of that day type.
The Schedule Times window for a Yearly Schedule shows the dates and times that event(s) trigger on a yearly basis. This example shows events that trigger shortly after midnight on the 11th of January and the 21st of June each year.
The Schedule Times window for a Daily Schedule shows the times that event(s) trigger on a daily basis. The example on the left shows two early morning events and two evening events. If a Daily Schedule is associated with a Calendar (as per the example on the right), each event is prefixed with ‘Normal’, or with the name of the Calendar day type to which the event is assigned.
The Schedule Times window for a Monthly Schedule shows the dates and times that event(s) trigger on a monthly basis. This example shows the times at which events trigger on the 12th, 18th, and 28th of each month.

Further Information

Display the Schedule Times Window.


Core Configuration Guide - Add an Event using the Schedule Times Window (Using Schedules to Automate Regular Functions)

Add an Event using the Schedule Times Window

This section applies to Schedules other than Simple Schedules.

You generally add event(s) to a Schedule by adding those events directly to the Schedule Display (see Add an Event Directly to a Schedule). However, you can also add events to a Schedule by using the Add button on the Schedule Times window.

To add an event to a Schedule by using the Schedule Times window:

  1. Display the Schedule Times Window.

(The Format in which Schedule Times are Displayed varies, depending on the type of Schedule.)

  2. Select the Add button.
    The Add Time window is displayed, with the first element of the time or date highlighted.
  3. If the entry includes a day, month, or Calendar day type, use the Up and Down arrow keys on your keyboard to cycle through the available options and select the required entry.
  4. Select the first time element (for instance the hour) and either overwrite the time with the required time, or use the field’s arrows to select the required time.
  5. Repeat step 4 for any other time element(s) (such as minutes).
  6. Select the OK button to add the new time to the Schedule Times window.
  7. Repeat steps 2 to 6 for any other times that you want to add to the window.
  8. Select the OK button on the Schedule Times window to add the event times to the Schedule.
  9. Save the changes that you have made to the Schedule (see Saving Configuration Changes).


Core Configuration Guide - Move an Event (Using Schedules to Automate Regular Functions)

Move an Event

This section applies to Schedules other than Simple Schedules.

To move an event to a new location on the same tab on a Schedule Display:

  1. Display the Schedule in Edit Mode.
  2. Select the event that you want to move—do not release the mouse button.
  3. Drag the event to its new location.
  4. Release the mouse button.
  5. Repeat steps 2 to 4 for any other events that you need to move.
  6. Save the configuration (see Saving Configuration Changes).

To move an event from one tab to another on a Schedule Display (for instance, from one day to another, or from one month to another):

  1. Delete the event from the tab on which it is no longer required (see Delete an Event).
  2. Select the tab on which you want to insert the event.
  3. Add the event at the required time and date (see Add an Event Directly to a Schedule).
  4. Repeat steps 1 to 3 for any other events that need moving to other tabs.
  5. Save the configuration (see Saving Configuration Changes).

To move an event by using the Schedule Times window:

  1. Display the Schedule Times Window.
  2. Select the event that you want to move.
  3. Select the Edit button.
    The Edit Time window is displayed, with the first element of the time or date highlighted.
  4. To change a day, month, or Calendar day type, use the Up and Down arrow keys on your keyboard to cycle through the available options and select the required entry.
  5. To change a time element (for instance the hour), select that element and then either either overwrite the time, or use the field’s arrows to select the required time.
  6. Select the OK button to update the entry in the Schedule Times window.
  7. Repeat steps 2 to 6 for any other times that you want to edit in the window.
  8. Select the OK button on the Schedule Times window to update the event times in the Schedule Display.
  9. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Delete an Event (Using Schedules to Automate Regular Functions)

Delete an Event

This section applies to Schedules other than Simple Schedules.

To delete an event from a Schedule:

  1. Display the Schedule in Edit Mode.
  2. Either:
  1. Double-click on the event that you want to remove.
    The event indicator is removed from the Schedule Display.
  2. Repeat step i for any other events that are now obsolete.

Or:

  1. Display the Schedule Times Window.
  2. Select the event that you want to remove.
  3. Select the Remove button.
    The entry is removed from the list in the Schedule Times window.
  4. Repeat steps ii to iii for any other events that are now obsolete.
  5. Select the OK button to remove the obsolete events from the Schedule Display.
  3. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Add an Action to a Schedule (Using Schedules to Automate Regular Functions)

Add an Action to a Schedule

With any type of Schedule, you need to specify the action(s) that ClearSCADA is to perform automatically at the scheduled time(s), and the database item(s) on which ClearSCADA is to perform those action(s). You do this using the Add Action window. The database items and actions that you specify are then displayed in the Object and Action areas at the bottom of the Schedule Editor.

The procedure that you use to assign the action trigger times differs, depending on the type of Schedule:

  • With a Schedule other than a Simple Schedule, you add event(s) to the Schedule Display (see Add an Event Directly to a Schedule) to specify when ClearSCADA is to perform the action(s) that you associate with that Schedule.
  • With a Simple Schedule, you use the Offset and Interval fields on the Schedule Form to specify when ClearSCADA is to perform the action(s) that you associate with the Schedule (see Define when a Simple Schedule Executes).

To specify the action(s) that ClearSCADA is to trigger automatically at the time(s) indicated on a Schedule, you can use either of these procedures:

  • Add an Action using the Database Bar
  • Add an Action using the Add Action Menu Option.


Core Configuration Guide - Add an Action using the Database Bar (Using Schedules to Automate Regular Functions)

Add an Action using the Database Bar

Follow this procedure if you want to use the Database Bar to specify an item, associate the item with a Schedule and specify the action that ClearSCADA is to perform on that item:

  1. Display the Schedule in Edit Mode.
  2. In the Database Bar, select the database item that you want to associate with the schedule—do not release the mouse button.
  3. Drag the item over to the Object area at the bottom of the Schedule Display.
    Drag the required database item over into the Schedule Display’s Object area...

  4. Release the mouse button.
    The Add Action window is displayed.
    ...the Add Action window is displayed, from which you specify the action that is be carried out at the scheduled time(s)...

  5. Use the Add Action window to:
  1. If applicable, specify the Aggregate with which the action is associated.
  2. If applicable, specify any particular Alarm with which the action is associated.
  3. Specify the Method (action) that ClearSCADA is to perform on the database item.
  4. If applicable, specify the values of any argument(s) that further define the action.

For more information using the window, see Specify a Method.

Once specified, the name of the database item, and the action that you have selected, are shown in the Object and Action areas at the bottom of the Schedule Display. The values of any arguments that apply to the action are displayed in a comma-separated list after the action name.

...details of the selected action, and the database item with which it is associated, are displayed in the Object and Action areas.

  6. Repeat steps 2 to 5 for any other actions that ClearSCADA is to perform at the same scheduled event times.

(With a Schedule on which you assign events to more than one tab, the actions that you specify on the Schedule Editor trigger automatically at each of the event times that you specify on each of those tabs.)

  7. Save the configuration (see Saving Configuration Changes).

If an action no longer needs triggering by a Schedule, you can delete that action (see Delete a Scheduled Action).

You can also:

  • Move the events associated with the action(s) (see Move an Event)
  • Check the Event Trigger Times
  • Delete obsolete events (see Delete an Event)
  • Further Edit a Scheduled Action
  • Adjust the Order in which Actions are Triggered.


Core Configuration Guide - Add an Action using the Add Action Menu Option (Using Schedules to Automate Regular Functions)

Add an Action using the Add Action Menu Option

Follow this procedure if you want to add an action to any type of Schedule by using the Schedule’s Add Action menu option:

  1. Display the Schedule in Edit Mode.
  2. Right-click on the Schedule Display’s Object area.
    A context sensitive menu is displayed.
    Select the Add Action menu option...

  3. Select the Add Action menu option.
    The Add Action window is displayed.
    ...to display the Add Action window.

  4. Use the Add Action window to:
  1. Specify the database item for which you want to schedule an action.
  2. If applicable, specify the Aggregate with which the action is associated.
  3. If applicable, specify any particular Alarm with which the action is associated.
  4. Specify the actual Method (action).
  5. If applicable, specify the values of any argument(s) that further define the action.

For more information on using the window, see Specify a Method.

The name of the database item, and the action that you have selected, are shown in the Object and Action areas at the bottom of the Schedule Display. The values of any arguments that apply to the action are displayed in a comma-separated list after the action name.

  5. Repeat steps 2 to 4 for any other actions that you want ClearSCADA to trigger at the same time, using the same Schedule.

(With a Schedule on which you assign events to more than one tab, the actions that you specify on the Schedule Editor trigger automatically at each of the event times that you specify on each of those tabs.)

  6. Save the configuration (see Saving Configuration Changes).

If an action no longer needs triggering by a Schedule, you can delete that action (see Delete a Scheduled Action).

You can also:

  • Move the events associated with the action(s) (see Move an Event)
  • Check the Event Trigger Times
  • Delete obsolete events (see Delete an Event)
  • Further Edit a Scheduled Action
  • Adjust the Order in which Actions are Triggered.


Core Configuration Guide - Edit a Scheduled Action (Using Schedules to Automate Regular Functions)

Edit a Scheduled Action

To edit an action that is assigned to a Schedule:

  1. Display the Schedule in Edit Mode.
  2. Either:
  1. Double-click on the action in the Action display area.

Or:

  1. Right-click on the action in the Action display area.
    A context-sensitive menu is displayed.
  2. Select the Edit option.

The Edit Action window is displayed.

  3. Use the Edit Action window to perform any of the following:
  • Specify a different database item.
  • Specify a different aggregate.
  • Specify a different alarm association.
  • Specify a different action.
  • Specify the values of any arguments that further define the action.

For more information on using the window, see Specify a Method.

  4. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Adjust the Order in which Actions are Triggered (Using Schedules to Automate Regular Functions)

Adjust the Order in which Actions are Triggered

The order in which actions are displayed on a Schedule defines the order in which ClearSCADA performs those actions at the scheduled trigger times.

In many cases, the trigger order is irrelevant and the actions trigger almost simultaneously. However, you might want to consider the order in which the actions are triggered, should some of those actions rely on the results of other actions, or have built-in delays or other functionality that affects the outcome of the other actions.

If need be, you can re-arrange the order in which ClearSCADA performs the actions that are assigned to a Schedule. To re-arrange the order:

  1. Display the Schedule in Edit Mode.
  2. Select the action is to appear in a different location in the Action area—do not release the mouse button.
  3. Drag the action to the required position in the list.
    You can drag an action...
    ...to a different position in the Action list.

  4. Repeat steps 2 and 3 for any other actions that are to be re-ordered.
  5. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Delete a Scheduled Action (Using Schedules to Automate Regular Functions)

Delete a Scheduled Action

If an action that is associated with a Schedule no longer needs to be triggered by that Schedule:

  1. Display the Schedule in Edit Mode.
  2. Either:
  1. Right-click on the action in the Object area of the Schedule Display.
    A context sensitive menu is displayed.
  2. Select the Delete option.

Or:

  1. Select the database item in the Object area of the Schedule Display.
  2. Select the Delete key.

Or:

  1. Select the database item in the Object area of the Schedule Display.
  2. Select the Edit menu from the ViewX menu bar.
  3. Select the Delete option.

The obsolete entry is removed from the Schedule Display.

  4. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Example Configuration (Using Schedules to Automate Regular Functions)

Example Configuration

This section includes several examples to further demonstrate how Schedules can be configured to trigger actions automatically on a ClearSCADA system.

The examples in this section include:

  • A Simple Schedule used to Run a Pump
  • A Daily Schedule used to Call PSTN Outstations Twice a Day.
  • A Weekly Schedule and Calendar used to Generate a Series of Reports.

Further Information

Use a Schedule to automatically archive data: see Setup Scheduled Archiving in the ClearSCADA Guide to Server Administration.

Use a Schedule to automatically trigger a report: see the ClearSCADA Guide to the Crystal Reports Driver.

Use the Add Action Window to Specify the Tune Alarm Limits Method.

NOTE: Do not confuse the above Schedules with Alarm Redirection Schedules, which are used to redirect alarms at different times on different days. For information on Alarm Redirection Schedules and the Alarm Redirection Calendars on which they are used, see Configure an Alarm Redirection Calendar in the ClearSCADA Guide to Alarm Redirection.


Core Configuration Guide - A Simple Schedule used to Run a Pump (Using Schedules to Automate Regular Functions)

A Simple Schedule used to Run a Pump

This example shows how a Schedule can be used to run a pump automatically on a regular basis. The pump is represented in ClearSCADA as a Pulse Action and is configured to run the pump for a specified time every time that the Schedule triggers.

Example:

A pump on a particular ClearSCADA system is to run at six-hourly intervals. The Pulse Action that represents the pump is attached to a Schedule, in order to run the pump automatically at the required intervals.

A Simple Schedule is to be used to run the pump.

The Schedule Form is used to specify the Schedule Type as Simple.

The Form’s Offset and Interval fields are used to specify that the Schedule is to trigger at 05:59 and thereafter at six-hourly intervals throughout the day:

The Schedule Type is specified as Simple.
The Offset field is used to specify that the Schedule first executes at 05:59.
The Interval field is used to specify that the Schedule thereafter executes at six-hourly intervals.

The pump is associated with the Schedule:

The database entry for the pump is dragged onto the Schedule Editor...
...and the Add Action window that is displayed, is used to specify the Control method. (Remember that actions that are associated with controls are on the Control aggregate.)

The Control method has an Action argument. The actual action is specified by right-clicking on the argument and selecting the required action from a context sensitive menu:

The actual Control action (Running) is selected from the context sensitive menu that is displayed when you right-click on the Action argument.

The scheduled action is displayed at the bottom of the Schedule Editor:

The configuration is saved and as a result, ClearSCADA runs the pump at 05:59, 11:59, 17:59 and 23:59 every day.

Further Information

Define the Basic Schedule Properties.

Define when a Simple Schedule Executes.

Add an Action to a Schedule.

Add Action Window: see Using the Add Action and Edit Method Windows.


Core Configuration Guide - A Daily Schedule used to Call PSTN Outstations Twice a Day (Using Schedules to Automate Regular Functions)

A Daily Schedule used to Call PSTN Outstations Twice a Day

This example shows how a Schedule can be used to send ‘One Shot’ calls to a series of PSTN outstations twice a day. The calls are used to retrieve data from the outstations (between ‘One Shots’, the outstations are configured to Dial In if an alarm is raised).

Example:

The PSTN outstations on a particular ClearSCADA system are to be contacted by the server twice a day, in order to update the ClearSCADA database with the latest data from those outstations.

A Daily Schedule is used to One Shot the outstations automatically.

The Schedule Form is used to specify the Schedule Type as Daily.

The Schedule Type is specified as Daily.

The required events are added to the Schedule Editor (in this case, the server is to call the outstations at 06:30 and 18:30 each day).

The Add Action window is then used to specify the One Shot method for the sets to which the outstations belong:

...and specify the One Shot method for that Set.
The Add Action window is used to specify the required PSTN Outstation Set...

In this particular example, the server is scheduled to One Shot the outstations on two sets at the same time and as such, two actions are specified—one for each outstation set.

Once specified, the selected sets and their respective actions are listed at the bottom of the Schedule Editor:

Events specify that the server is to trigger action(s) at 06:30 and 18:30 each day.
The items on which the server is to act are specified at the bottom of the display, along with the actions that the server is to perform on those items. (In this case, to send One Shot calls to the outstations on two PSTN outstation sets.)

The server is to call the outstations on a further two sets (for Zone C and Zone D) five minutes after the outstations in Zone A and Zone B. As the event times differ, a separate Daily Schedule is configured for Zone C and Zone D, with events at 06:35 and 18:35 respectively.

Further Information

Define the Basic Schedule Properties.

Add an Event Directly to a Schedule.

Add an Action to a Schedule.

Add Action window: see Using the Add Action and Edit Method Windows.


Core Configuration Guide - A Weekly Schedule and Calendar used to Generate a Series of Reports (Using Schedules to Automate Regular Functions)

A Weekly Schedule and Calendar used to Generate a Series of Reports

This example shows how a Schedule can be used to automatically generate a series of reports at the start of each week. The Schedule is associated with a Calendar, to allow report generation to be delayed for those weeks on which the Monday is a Public holiday.

Example:

A company requires that a series of area reports are generated prior to the weekly manager’s meeting. The meeting is usually held each Monday, apart from the weeks on which the Monday is a Public holiday. On such weeks, the manager’s meeting is held on the first working day following the Public holiday, and the report generation is delayed intentionally, to ensure that the reports contain the most up-to-date data.

A Weekly Schedule is used to generate the reports automatically. The Schedule is associated with a Calendar, to enable report generation to be suitably delayed on the weeks on which the Monday occurs on a Public holiday.

The Calendar is assigned suitable custom Day Types. The Day Types are used to indicate:

  • When Public holidays occur throughout the year
  • The weekday that immediately follows a Public holiday, if that Public holiday occurs on a Monday.
    ‘Public Holiday’ and ‘Post-Holiday’ Day Types are assigned to the Calendar...
    ...the Day Types are assigned to the relevant days on the Calendar.

The Calendar is associated with the Schedule that is to generate the reports:

The Schedule is configured as a Weekly Schedule (as it is being used for once-weekly report generation)...
...The Schedule is associated with the Calendar on which ‘Public Holiday’ and ‘Post-Holiday’ dates are specified.

The required report generation actions are added to the Schedule Editor.

The Monday tab is used to add the times at which the reports are to be generated on most Mondays in the year (the Mondays that are not Public holidays):

The event that is added to 08:00 hrs. on the Monday tab, specifies when ClearSCADA is to generate the reports on the Mondays that are not Public holidays.
The actions that are added to the Object area define the activities that ClearSCADA is to perform. ClearSCADA performs the actions at the event times specified on each tab, in the order that they are displayed on the tab.

In addition to a tab for each day of the week, the Schedule Editor also has tabs for each of the six Day Types that are assigned to the associated Calendar. These additional tabs are used to define the events that occur on those specific Day Types.

No events occur on Public Holiday days, therefore no events are assigned to that tab.

The Post-Holiday Report Generation tab is used to add the event times for report generation on those working days that occur immediately following a Public holiday:

An event is added to 08:30 hrs. on the Post-Holiday Report Generation tab. This event specifies when ClearSCADA is to generate the reports on those working days that occur immediately after Public holidays.

So, for most Mondays in the year, ClearSCADA generates the three area reports at 08:00hrs.

However, on those Mondays (such as 2nd January and 17th April) that are defined as Public Holidays, no reports are generated. Instead, on the dates that immediately follow those days (dates that are specified as ‘Post-Holiday Report Generation’ days), ClearSCADA generates the three area reports at 08:30hrs.

Further Information

Configuring Calendars.

Associate a Custom Day Type with a Calendar Date.

Define the Basic Schedule Properties.

Associate a Calendar with a Daily or Weekly Schedule.

Add an Event Directly to a Schedule.

Add an Action to a Schedule.


Core Configuration Guide - Configuring Calendars

Configuring Calendars

If different ClearSCADA functions are to occur automatically on specific dates each year—for instance during any company shutdown periods—consider using Calendars.

You can add Calendars to the ClearSCADA database and associate those Calendars with other ClearSCADA features, such as Schedules. You can then indicate specific dates, such as Public Holidays, on the Calendar and configure the associated features to perform the functions that are to occur on those dates.

You can specify up to six different Day Types—and therefore up to six automated ‘routines’—per Calendar.

NOTE: Do not confuse these ‘normal’ Calendars with Alarm Redirection Calendars that can be used to redirect alarms on a calendar basis. For information on Alarm Redirection Calendars, see the ClearSCADA Guide to Alarm Redirection.

This section explains how to:

  • Add a Calendar.
  • Display and Configure the Properties on the Calendar Form.
  • Display the Calendar Editor.
  • Use the Calendar Editor to:
  • Select a Calendar Year.
  • Rename a Day Type.
  • Associate a Custom Day Type with a Calendar Date.
  • Remove the Association with a Custom Day Type from a Calendar Date.

Further Information

Associate a Calendar with a Daily or Weekly Schedule.


Core Configuration Guide - Add a Calendar (Configuring Calendars)

Add a Calendar

To add a Calendar:

  1. Right-click on the System or Group to which you want to add the Calendar (this might be a separate Group for storing Calendars).
    A context-sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Calendar option.
    A Calendar is added to the system. It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Calendar (taking into account the ClearSCADA Naming Restrictions).
  6. Select another part of the interface or press the Enter key to confirm the entry.

When you have added a Calendar, you can:

  • Display and Configure the Properties on the Calendar Form
  • Display the Calendar Editor and associate one of up to six Day Types with any of the dates on the Calendar.

NOTE: Do not confuse ‘normal’ Calendars with Alarm Redirection Calendars that can be used to redirect alarms on a calendar basis. For information on Alarm Redirection Calendars, see the ClearSCADA Guide to Alarm Redirection.


Core Configuration Guide - Display and Configure the Properties on the Calendar Form (Configuring Calendars)

Display and Configure the Properties on the Calendar Form

Use the Calendar Form to configure the basic Calendar properties.

To display the Calendar Form and configure its properties:

  1. Right-click on the Calendar in the Database Bar.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the Properties option.
    The Calendar Form is displayed.
  3. Optionally use the Calendar Form for:
  1. Defining Identification Details.
  2. Configuring any custom pick actions that are to be associated with the Calendar (see Using the User Methods Tab to Define Custom Actions).
  3. Save the configuration (see Saving Configuration Changes).

NOTE: Do not confuse ‘normal’ Calendars with Alarm Redirection Calendars that can be used to redirect alarms on a calendar basis. For information on Alarm Redirection Calendars, see the ClearSCADA Guide to Alarm Redirection.


Core Configuration Guide - Display the Calendar Editor (Configuring Calendars)

Display the Calendar Editor

You use the Calendar Editor to select the Calendar year and allocate holidays or other special day types, as needed.

To display the Calendar Editor:

  1. Double-click on the item in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).
    The Calendar Editor is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

or:

  1. Either:
  • Right-click on the item in the Database Bar.

or:

  • Select the item on a List.

or:

  • Select an animated representation of the item on a Mimic. (Provided that the animated representation is associated with the item’s Pick Action Menu and provides access to the relevant menu option).

A context sensitive menu is displayed.

  2. Select the Edit option.
    The Calendar Editor is displayed.

You can use the Calendar Editor to:

  • Select a Calendar Year
  • Rename a Day Type
  • Associate a Custom Day Type with a Calendar Date
  • Remove the Association with a Custom Day Type from a Calendar Date.


Core Configuration Guide - Select a Calendar Year (Configuring Calendars)

Select a Calendar Year

To select a Calendar Year:

  1. Display the Calendar Editor.
  2. Use the Year spin box to select the required year.
    The Calendar displays the dates for the selected year.


Core Configuration Guide - Rename a Day Type (Configuring Calendars)

Rename a Day Type

Each Calendar is supplied with six default Day Types (Day Type A to Day Type F), that you can select from the Day Type combo box.

We advise that you rename the default Day Types to custom day types that are more applicable to your system.

You might want to rename any unused Day Types - for example, to include the text ‘UNUSED’ - in order to avoid those Day Types inadvertently being specified elsewhere in ClearSCADA (such as on a Schedule that might reference the Calendar).

To rename a Day Type:

  1. Display the Calendar Editor.
  2. Select the browse button adjacent to the Day Types field.
    The Day Types window is displayed.
  3. Select the Day Type that you want to rename.
    A selected day is highlighted...

  4. Select the entry again.
    ...A reselected day is made available for renaming

  5. Overtype the entry with a more relevant name. You can use any combination of alphanumeric characters. Keep the name concise but meaningful.
  6. Select the OK button to confirm the settings.
    The Day Types window is closed and the name of the Day Type is changed in the Calendar Day Type field.
  7. Save the configuration (see Saving Configuration Changes).

You can then Associate a Custom Day Type with a Calendar Date.

For an example demonstrating the use of custom Day Types, see A Weekly Schedule and Calendar used to Generate a Series of Reports.

NOTE: Do not confuse ‘normal’ Calendars with Alarm Redirection Calendars that can be used to redirect alarms on a calendar basis. For information on Alarm Redirection Calendars, see the ClearSCADA Guide to Alarm Redirection.


Core Configuration Guide - Associate a Custom Day Type with a Calendar Date (Configuring Calendars)

Associate a Custom Day Type with a Calendar Date

To indicate a specific date on a Calendar—for instance, to indicate that a day is a Public Holiday—you associate the date with a specific Day Type.

By default, each new Calendar is supplied with Day Types that are labelled Day Type A to Day Type B. Each Day Type is associated with a different color. You use the color to indicate the position of a Day Type on the Calendar.

We advise that you rename the default Day Types on each new Calendar so that the names correspond to the types of day that you want to indicate on the Calendar (see Rename a Day Type).

To associate a custom Day Type with a Calendar date:

  1. Use the Day Type combo box at the top of the Calendar Editor to select the required custom day.
  2. Select the date(s) that are to use that Day Type on the Calendar:
  • To select a single day, click on the day on the Calendar.
    The day becomes highlighted with the color that represents that Day Type.
  • To select a block of days, drag over the required days on the Calendar.
    The days become highlighted with the color that represents that Day Type.
  3. Repeat the steps above for any other dates that you want to associate with custom Day Types.
  4. Save the configuration (see Saving Configuration Changes).
    ...then select the date(s) that you want to associate with that custom Day Type.
    Select the required custom Day Type from the list...

You can then associate the Calendar with another ClearSCADA feature (such as a Schedule), to enable that feature to perform differently on the specified Calendar dates.

Further Information

Remove the Association with a Custom Day Type from a Calendar Date.

Associate a Calendar with a Daily or Weekly Schedule.


Core Configuration Guide - Remove the Association with a Custom Day Type from a Calendar Date (Configuring Calendars)

Remove the Association with a Custom Day Type from a Calendar Date

To remove the highlighting from a date on a Calendar and so remove that date’s association with a particular Day Type:

  1. Either:
  1. Right-click on a single highlighted date on the Calendar.
    The custom Day Type color is removed from the selected date.

or:

  1. Hold down the right-hand mouse button.
  2. Drag over the relevant block of dates on the Calendar.
    The custom Day Type color is removed from the selected dates.

or:

  1. Associate the date(s) with another custom Day Type color (see Associate a Custom Day Type with a Calendar Date).
  2. Repeat the above steps for any other dates that need changing.
  3. Save the configuration (see Saving Configuration Changes).


Core Configuration Guide - Setting up Operator Document Stores

Setting up Operator Document Stores

An Operator Document Store is a special type of Group that can be used by operator-level users to store documents, such as pre-configured Trends. Users that have access to Operator Document Store(s) can create and edit documents in the document stores, without their user accounts being allocated the ‘Configure Database’ feature. They can also use the Save In Operator Documents menu option to save a copy of any supported document, in any of the Operator Document Store(s) to which they have access, providing that they have Read access to that document. Operator-level users access the documents and the Operator Document Store(s) to which they have access, using the Operator Documents Bar —one of the ViewX Explorer Bars.

To set up an Operator Document Store, you need to:

  1. Add an Operator Document Store to the system.
  2. Optionally configure the Operator Document Store’s properties if the defaults are unsuitable (see Configure an Operator Document Store).
  3. Provide operator access to the document store (see Associate an Operator Document Store with a User or User Group).

Depending on the system set up, each operator can access up to six Operator Document Stores—a personal document store, up to four group document stores, and a global document store.


Core Configuration Guide - Add an Operator Document Store (Setting up Operator Document Stores)

Add an Operator Document Store

To add an Operator Document Store to your system:

  1. In the Database Bar, right-click on the System or Group folder to which you want to add an Operator Document Store.
    A context sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Group option.
    A further menu is displayed.
  4. Select the Operator Document Store option.
    An Operator Document Store is added to the root of the system, or to the selected Group (depending on your selection in step 1.) It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Operator Document Store (taking in to account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.
  7. Repeat the above steps for any other Operator Document Stores that you want to add to your system.

When you have added an Operator Document Store, you can:

  • Configure its properties (see Configure an Operator Document Store).
  • Provide operator access to the Operator Document Store (see Associate an Operator Document Store with a User or User Group).


Core Configuration Guide - Configure an Operator Document Store (Setting up Operator Document Stores)

Configure an Operator Document Store

To configure an Operator Document Store:

  1. Right-click on the Operator Document Store in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Properties option.
    The Operator Document Store Form is displayed.
  3. Use the Identification tab to configure the Identification properties (see Defining Identification Details).
  4. Use the User Methods tab to configure any custom pick actions that are required for the Operator Document Store (see Using the User Methods Tab to Define Custom Actions).
  5. Use the fields on the Group tab for Defining a Default View.

(The ‘Alarm View’ and ‘Confirm Alarm’ fields on the Group tab do not apply to Operator Document Stores, as the documents that you can store in them are not alarmable.)

  6. Save the configuration (see Saving Configuration Changes).

NOTE: The Alarm Redirection feature is not used on Operator Document Stores as the documents that you can store in Document Stores are not alarmable.


Core Configuration Guide - Associate an Operator Document Store with a User or User Group (Setting up Operator Document Stores)

Associate an Operator Document Store with a User or User Group

To allow operator(s) to access an Operator Document Store:

  1. Ensure that the operator(s) User Account provides access to the Operator Documents Bar (see Define Which Explorer Bars are Available to a User in the ClearSCADA Guide to Security).
  2. Do one of the following to provide the required access to the Operator Document Store:
  • Provide access on an individual User Account basis (see Define the Operational ViewX Settings for a User in the ClearSCADA Guide to Security).

or:

  • Provide access on a User Group basis (see Define the Operator Document Store for a User Group in the ClearSCADA Guide to Security).

(Remember that you can assign up to four User Groups to each User Account, and so provide user access to up to four group Document Stores.) For information on assigning a User Group to a User Account, see Associate a User with a User Group in the ClearSCADA Guide to Security.

or:

  • Provide global access by assigning the Operator Document Store as your system’s global document store (see Specify the Global Operator Document Store for your System).


Core Configuration Guide - System Colors

System Colors

Each ClearSCADA system is supplied with a set of default system colors. These colors comprise both ‘core system’ and driver-specific colors. Each color is used to indicate the state of an item in the database. The color is used on various ClearSCADA displays to indicate that the item is in a particular state.

Example:

A point is overridden by the ClearSCADA server. Blue is the default system color that is used to indicate that a value is overridden. The entry for the point on the Points List is displayed with a blue background color to indicate that the point is overridden.

The point state is also displayed on a Mimic. The state inherits its format from the point configuration in the database, and is displayed with a blue background, indicating that it is overridden.

Some colors take priority over other colors (see System Color Priorities). A lower-priority color will not be displayed until the higher-priority state is no longer in effect.

You can change a default system color by altering its color in the color palette. If you decide to do this, you should ensure that the new color is not identical to, or could be confused with, another color on your system.

This section provides an Alphabetical List of Core System Colors and explains how to:

  • Display The Color Palette Window
  • Use the Color Palette to Define a Custom System Color.

For information on driver-specific colors, see the appropriate driver-specific guide.

NOTE: Do not confuse System Colors with Alarm Severity colors (see Alarm and Event Severities in the ClearSCADA Guide to Server Administration) or State colors (see Defining a Custom State Color).


Core Configuration Guide - The Color Palette Window (System Colors)

The Color Palette Window

System colors are displayed in a Color Palette. To display a Color Palette window for a particular item or Group:

  1. In the Database Bar, right-click on the Group or item for which you want to view the system colors.
    A context sensitive menu is displayed.
  2. Select the Color Palette option.
    The Color Palette window is displayed, showing the suite of ‘core’ and driver-specific system colors for your system.
    By default, every item and Group (other than the Root Group) inherits its color palette from its ‘parent’—the Group in which that particular Group or item is located.

Core system colors are those that are available on most ClearSCADA systems. Driver-specific colors are those that are used only by specific drivers—the color and its associated state will only appear on the Color Palette if you have installed that driver.

For further information on core system colors, see Alphabetical List of Core System Colors. For information on driver-specific colors and states, see the relevant driver guide.

You can change a default system color by altering its color in the color palette. You can do this on a system-wide, per group, or individual item basis. If you decide to change a default system color, you should ensure that the new color is not identical to, or could be confused with, another color on your system.

For information on changing system colors, see Using the Color Window to Define a Color.


Core Configuration Guide - Use the Color Palette to Define a Custom System Color (System Colors)

Use the Color Palette to Define a Custom System Color

Follow this procedure if you want to replace a default system color with a custom color.

Ensure that the color you choose is not identical to, or could be confused with, another color on the system.

  1. To change a system color on a system-wide basis, right-click on the Root Group.

To change a system color on a particular part of the system, right-click on the relevant Group or database item.

A context sensitive menu is displayed.

  2. Select the Color Palette option.
    The Color Palette Window is displayed, showing the suite of ‘core’ and driver-specific system colors for your system.
  3. To change a system color on a Group or item other than the Root Group, clear the Inherit Palette from Parent check box.
    The selected Group or item will no longer inherit its color palette from its parent. (Its ‘parent’ is the Group in which the selected Group or item is located.) The colors in the color palette become available for selection.

(While the Inherit Palette from Parent check box is selected, you will not be able to change any of the colors on the selected item or Group’s color palette.)

  4. If you are changing a system color for a Group (including the Root Group), use the Remove Explicit Palette on Descendants check box to define whether the color change is also to apply to all of the items within that Group, regardless of whether the color palettes of any descendants have been individually customized.

Either:

  • Ensure that the check box is clear for the color to affect only the Group that you have selected, along with any descendants that have their Inherit Palette from Parent check box selected. Any descendants that do not have their Inherit Palette from Parent check box selected will retain their existing color palettes (whether or not those color palettes are customized or standard).
  • Select the Remove Explicit Palette on Descendants check box for the color change to affect all items in the Group, regardless of whether the color palettes of any descendants contain individually customized colors. The color palette for the Group will replace the individual color palettes of the descendants.

(This replacement is a ‘one-off’ activity—the descendants’ color palettes are updated just once, when you select the Color Palette window’s OK button. The replacement function does not continue to force the descendants to retain their parent’s color palette, therefore the check box will be clear the next time that the Color Palette window is displayed.)

  5. Click on the color that you want to change.
    A pop-up color palette is displayed.
  6. Either:
  1. Select a color from the palette.

Or:

  1. Select the ... option.
    The Color window is displayed.
  2. Use the Color window to define a color (see Using the Color Window).
  3. Select OK to close the Color window.
  7. Use the Flash check box adjacent to the color that you have changed to indicate whether the color should flash.

Either:

  • Select the check box for the color to flash.
  • Ensure that the check box is clear for the color to remain static.
  8. Select the OK button on the Color Palette window to confirm the color change.
  9. Repeat this procedure for any other system colors that you want to change.

Example:

In the Group below, the color palette of PSTN Ostn 2 is modified so that the palette is no longer inherited from its parent, and so that the status ‘Alarm Disabled’ uses a custom color.

All other items in the Group use ‘standard’ color palettes that contain standard rather than custom system colors. (By default, these palettes are all inherited from the parent Group, SCADAPack Modbus PSTN.)

The color palette of the Group, SCADAPack Modbus PSTN, is then modified so that the palette is no longer inherited from its parent, and so that the status ‘Master Station Override’ uses a custom color. The ‘Remove Explicit Palette on Descendants’ box is not checked.

The color palettes of all items within the Group inherit the new Group color palette, except PSTN Ostn 2, as this uses its own individually customized color palette.

The color palette of Analog Input Point 1 is then modified so that the palette is no longer inherited from the parent Group, SCADAPack Modbus PSTN, and so that the status ‘Control Disabled’ uses a custom color. The color palette for this point now contains two custom colors—’Control Disabled’, which was modified directly in the color palette for that point, and ‘Master Station Override’, which was inherited from the Group’s color palette, but now forms part of the customized color palette that is unique to Analog Input Point 1.

If the color palette for the Group, SCADAPack Modbus PSTN, is further modified, and the ‘Remove Explicit Palette on Descendants’ box checked, then all of the items within the Group would inherit the Group’s color palette, regardless of whether their own palettes were previously individually customized.

As such, both PSTN Ostn 2 and Analog Input Point 1 would inherit the Group color palette in place of their own customized color palettes. All other items in the Group would also inherit the Group color palette.


Core Configuration Guide - Alphabetical List of Core System Colors (System Colors)

Alphabetical List of Core System Colors

Core system colors are used to indicate the following states:

  • Alarm Disabled
  • Alarm Response
  • Bad Quality
  • Compilation Needed
  • Control Disabled
  • Debugging Program
  • Dial In Disabled
  • Download Configuration Required
  • Future Data
  • Logging
  • Master Station Override
  • Normal - Background
  • Normal - Foreground
  • Note
  • Outstation Connecting
  • Outstation Override
  • Outstation Request Pending
  • Parent Point Override
  • Point Action
  • Program Disabled
  • Source Refresh
  • Switching Disabled
  • Trend - Annotation
  • Trend - Bad Data
  • Trend - Inserted/Modified Data
  • Trend - Unvalidated Data
  • Trend - Validated/Good Data.

To ascertain which state, and therefore which system color, takes priority over another, see System Color Priorities.

NOTE: The default settings for the five Trend colors are set using the Trends tab on the Options window (selected via the Tools menu on the ViewX menu bar). For more information on using this window, see the ClearSCADA Guide to Trends.


Core Configuration Guide - Alarm Disabled (System Colors)

Alarm Disabled

Associated with: Any item that can raise an alarm

The Alarm Disabled state is indicated by an orange-red foreground color, by default.

The color indicates that alarms for an outstation or point are disabled. Alarms are disabled using the Disable Alarms pick action and enabled using the Enable Alarms pick action. For further information, see Disable Alarms and Enable Alarms in the ClearSCADA Guide to Alarms.


Core Configuration Guide - Alarm Response (System Colors)

Alarm Response

Associated with: Any item that can raise an alarm

The Alarm Response state is indicated by a light green background color, by default.

The color is used on the Alarms List and the Alarm Banner to indicate that a response exists for an alarm. A response indicates that a user is aware of an alarm situation, but has chosen not to acknowledge the alarm. For more information, see Respond to an Alarm in the ClearSCADA Guide to Alarms.


Core Configuration Guide - Bad Quality (System Colors)

Bad Quality

Associated with: Any database item

The Bad Quality state is indicated by a pink foreground color, by default.

The color indicates that the quality of the item’s data is suspect. This might be due, for example, to the item having invalid configuration, or being Out of Service.

Refer to the Quality column on the relevant List, or the Quality attribute on the item’s Status Display, for the reason for the data being suspect.


Core Configuration Guide - Compilation Needed (System Colors)

Compilation Needed

Associated with: Logic programs

The Compilation Needed state is indicated by a mid-gray background color, by default.

The color indicates that a program needs compiling.

For information on compiling a Logic program, refer to the relevant section below:

  • see Compiling a Function Block Diagram or Function Block Library in the ClearSCADA Guide to Logic
  • see Compiling a Ladder Diagram in the ClearSCADA Guide to Logic
  • see Compiling a Sequential Function Chart in the ClearSCADA Guide to Logic
  • see Compiling an ST Program or ST Library in the ClearSCADA Guide to Logic.


Core Configuration Guide - Control Disabled (System Colors)

Control Disabled

Associated with: Output and Pulse points

The Control Disabled state is indicated by an orange-red foreground color, by default.

The color indicates that controls are disabled for the output point. Controls are disabled using the Disable Controls pick action and enabled using the Enable Controls pick action.


Core Configuration Guide - Debugging Program (System Colors)

Debugging Program

Associated with: Logic programs

The Debugging Program state is indicated by a dark red foreground color, by default.

The color indicates that debugging is currently in progress.

For information on debugging a Logic program, refer to the relevant section below:

  • see Compiling a Function Block Diagram or Function Block Library in the ClearSCADA Guide to Logic
  • see Compiling a Ladder Diagram in the ClearSCADA Guide to Logic
  • see Compiling a Sequential Function Chart in the ClearSCADA Guide to Logic
  • see Debugging an ST Program or ST Library in the ClearSCADA Guide to Logic.


Core Configuration Guide - Dial In Disabled (System Colors)

Dial In Disabled

Associated with: Outstations that communicate via PSTN, including outstations with PSTN fallback

The Dial In Disabled state is indicated by a brown foreground color.

The color indicates that a PSTN outstation is prevented from dialing in to the server (calls from the server to the outstation are not stopped). Dial in is disabled using the Disable Dial In pick action and enabled using the Enable Dial In pick action.


Core Configuration Guide - Download Configuration Required (System Colors)

Download Configuration Required

Associated with: Outstations, etc., that support configuration download

The Download Configuration Required state is indicated by a mid-gray background color, by default.

The color indicates that an outstation has changed configuration that has not yet been downloaded from the ClearSCADA server.

For information on downloading configuration, see Downloading Configuration Changes.


Core Configuration Guide - Future Data (System Colors)

Future Data

Associated with: Points

The Future Data state is indicated by a green-blue foreground color, by default.

The color is used on the Historic List to indicate that the time stamp for the data is inaccurate in as much as the clock for the outstation, or PLC on which the point is located, had drifted forwards by more than the acceptable clock drift.

The Future Data setting is specified in the Points section of the ClearSCADA Server Configuration Tool (see Define the Maximum Outstation Clock Drift in the ClearSCADA Guide to Server Administration).


Core Configuration Guide - Logging (System Colors)

Logging

Associated with: Channels

The Logging state is indicated by a dark yellow background color, by default.

The color indicates that Communications, I/O, or Telnet logging is enabled for a channel. When this feature is enabled, the communications between the ClearSCADA server and the outstations that are using the channel are logged to a text file.

For information on Channel Communications logging and I/O logging, see Communications Logging in the ClearSCADA Guide to Server Administration. For information on Telnet logging, see Telnet Monitoring in the ClearSCADA Guide to Server Administration.


Core Configuration Guide - Master Station Override (System Colors)

Master Station Override

Associated with: Points

The Master Station Override state is indicated by a blue background color, by default.

The color indicates that the data for a point has been overridden at the master station.

Operators with the required permissions can override a point if the Override feature has been enabled on the configuration Form for that point.

Also see Outstation Override.


Core Configuration Guide - Normal - Background (System Colors)

Normal - Background

Associated with: Any database item

The Normal (Background) state is indicated by a white background color, by default.

The color indicates that the item is in its normal operating state or range and that the quality of the item’s data is good.

This is a low priority color over which other states take priority (see System Color Priorities).


Core Configuration Guide - Normal - Foreground (System Colors)

Normal - Foreground

Associated with: Any database item

The Normal (Foreground) state is indicated by a black foreground color, by default.

The color indicates that the item is in its normal operating state or range and that the quality of the item’s data is good.

This is a low priority color over which other states take priority (see System Color Priorities).


Core Configuration Guide - Note (System Colors)

Note

Associated with: Any database item

The Note state is indicated by a light green background color, by default.

The color indicates that Notes are available for an item. Notes can be attached to any item. They can be used, for example, to display operating instructions for certain items of plant.

For information on working with Notes, see Notes in the ClearSCADA Guide to ViewX and WebX Clients.


Core Configuration Guide - Outstation Connecting (System Colors)

Outstation Connecting

Associated with: Outstations and PLCs, etc.

The Outstation Connecting state is indicated by a flashing blue foreground color, by default.

The color indicates that the ClearSCADA server is establishing communications with the outstation or PLC. For example, the server is dialing or connecting to the outstation.


Core Configuration Guide - Outstation Override (System Colors)

Outstation Override

Associated with: Points

The Outstation Override state is indicated by a blue background color, by default.

The color indicates that the data for a point has been overridden at the outstation.

Operators with the required permissions can override a point if the Override feature has been enabled on the configuration Form for that point.

NOTE: Most outstations support Master Station Override, rather than Outstation Overrides.


Core Configuration Guide - Outstation Request Pending (System Colors)

Outstation Request Pending

Associated with: Outstations

The Outstation Request Pending state is indicated by a blue background color, by default.

The color indicates that a request to perform an action is in progress or pending on an outstation. For example, a call-back test might be being performed on a PSTN outstation.


Core Configuration Guide - Parent Point Override (System Colors)

Parent Point Override

Associated with: Derived points (points that are calculated from another point)

The Parent Point Override state is indicated by a blue background color, by default.

The color indicates that the data for the Parent point (the point from which this point is derived) has been overridden, therefore the value of this point has been calculated from an overridden value.


Core Configuration Guide - Point Action (System Colors)

Point Action

Associated with: Points on simple drivers, output points, and File Uploads

The Point Action state is indicated by a flashing blue foreground color, by default.

The color indicates that an action, for example a control, is currently in progress.


Core Configuration Guide - Program Disabled (System Colors)

Program Disabled

Associated with: Logic programs, including Function Block Diagrams, Ladder Logic Diagrams, and Structured Text programs

The Program Disabled state is indicated by an orange foreground color, by default.

The color indicates that execution of a program is presently disabled. Program execution is disabled using the Disable Execution pick action and enabled using the Enable Execution pick action.


Core Configuration Guide - Source Refresh (System Colors)

Source Refresh

Associated with: Simple driver point sources (for example, scanners)

The Source Refresh state is indicated by a flashing blue foreground color, by default.

The color indicates that a Refresh is in progress. A Refresh can be triggered automatically, or manually using the Refresh pick action. If necessary, an ongoing Refresh can be canceled by using the Cancel Refresh pick action.


Core Configuration Guide - Switching Disabled (System Colors)

Switching Disabled

Associated with: Shared or Switched sets, outstations on Shared or Switched sets

The Switching Disabled state is indicated by an orange foreground color, by default.

The color indicates that switching has been disabled for an outstation or set. Switching is disabled using the Disable Switching and enabled using Enable Switching pick action.


Core Configuration Guide - Trend - Annotation (System Colors)

Trend - Annotation

Associated with: Trends

The Annotation state is indicated by a light-blue marker on a Trend’s trace.

The color indicates that an annotated comment exists for that entry on the trace. The annotation might, for example, explain the reason for a particular value appearing on the trace (see Trend Annotations in the ClearSCADA Guide to Trends).

Place the cursor over the indicator to display a ToolTip showing the annotation, or view the annotation using an option on the context sensitive menu.


Core Configuration Guide - Trend - Bad Data (System Colors)

Trend - Bad Data

Associated with: Trends

The Bad Data state is indicated by a purple marker on a Trend’s trace.

The color indicates that the quality of the value may be bad (the value is unreliable and may be inaccurate).

The color is typically only used for data for which the source is from a non-ClearSCADA database, for example, another OPC database.


Core Configuration Guide - Trend - Inserted/Modified Data (System Colors)

Trend - Inserted/Modified Data

Associated with: Trends

The Insert/Modified Data state is indicated by a blue marker on a Trend’s trace.

The color indicates that the value has been modified or inserted by a user.

The color is typically only used for data for which the source is from a non-ClearSCADA database, for example, another OPC database.

For more information, see Insert a Value on a Historic Trend, and see Modify a Value on a Historic Trend in the ClearSCADA Guide to Trends.


Core Configuration Guide - Trend - Unvalidated Data (System Colors)

Trend - Unvalidated Data

Associated with: Trends

The Unvalidated Data state is indicated by a red marker on a Trend’s trace.

The color indicates that a trace value has not yet been checked and defined as being valid by an operator or engineer. The state only applies to systems on which manual Historic Validation is enabled (see Enable or Disable Manual Historic Data Validation in the ClearSCADA Guide to Server Administration).

The color is typically only used for data for which the source is from a non-ClearSCADA database, for example, another OPC database.

For further information, see Validate Historic Trend Data in the ClearSCADA Guide to Trends.


Core Configuration Guide - Trend - Validated/Good Data (System Colors)

Trend - Validated/Good Data

Associated with: Trends

The Validated/Good Data state is indicated by a light green marker on a Trend’s trace.

The color indicates that the value has been validated by an operator or engineer, or if manual Historic Validation is not enabled, that the value is reliably accurate.

The color is typically only used for data for which the source is from a non-ClearSCADA database, for example, another OPC database.

For information on validating historic data, see Enable or Disable Manual Historic Data Validation in the ClearSCADA Guide to Server Administration, and see Validate Historic Trend Data in the ClearSCADA Guide to Trends.


Core Configuration Guide - System Color Priorities (System Colors)

System Color Priorities

Each system color is assigned a level of importance, depending on the state that it represents. ClearSCADA uses the hierarchy to ascertain the color that it assigns to each database item.

Use the charts in this section to ascertain which core system colors take priority when an item is in a particular state. If more than one state applies simultaneously, the higher-priority color takes precedence until that state no longer applies. Be aware that in some cases, a driver-specific state and associated color may take priority over a core state—see the relevant driver guide for information on any driver-specific colors that may apply.

For more information about each core system color and the state it represents, see Alphabetical List of Core System Colors.

The charts in the rest of this section display the default system colors—you can change any of these colors using The Color Palette Window.

The charts show the:

  • Priority of Point Foreground Colors
  • Priority of Point Background Colors
  • Priority of Outstation Foreground Colors
  • Priority of Outstation Background Colors.


Core Configuration Guide - Priority of Point Foreground Colors (System Colors)

Priority of Point Foreground Colors

This chart indicates which point status takes precedence over another, and therefore which core system foreground color is assigned to a point at any particular time:

As such, if an output point:

  • Has valid configuration
  • Is In Service
  • Is not in alarm
  • Does not have its alarm functionality disabled
  • Does have its control functionality disabled (through use of the Disable Controls pick action)

the point’s foreground color will be an orange-red, by default, to indicate that controls are disabled on that point (unless a driver-specific state applies, which takes priority over the Control Disabled state).

Further Information

Alphabetical List of Core System Colors.

Alarm State Colors: see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.

Point State Colors: see Defining a Custom State Color.


Core Configuration Guide - Priority of Point Background Colors (System Colors)

Priority of Point Background Colors

This chart indicates which point status takes precedence over another, and therefore which core system background color is assigned to a point at any particular time (unless a driver-specific state and associated color takes precedence):

Further Information

Alphabetical List of Core System Colors.


Core Configuration Guide - Priority of Outstation Foreground Colors (System Colors)

Priority of Outstation Foreground Colors

This chart indicates which advanced driver outstation status takes precedence over another, and therefore which core system foreground color is assigned to an outstation at any particular time:

As such, if a PSTN outstation:

  • Has valid configuration
  • Is In Service
  • Is not in alarm
  • Does not have its alarm functionality disabled
  • Does have its Dial In capability disabled (through use of the Disable Dial In pick action)

the outstation’s foreground color will be brown, by default, to indicate that Dial In is disabled on that outstation (unless a driver-specific state applies, which takes priority over the Dial In Disabled state). However, should ClearSCADA dial out to the outstation, the outstation’s color will change to a flashing blue (the Outstation Connecting color) while ClearSCADA establishes communications with that outstation. Once communications is established, the color will revert to the Dial In Disabled color (unless a driver-specific state and color takes priority), while Dial In remains disabled.

Further Information

Alphabetical List of Core System Colors.


Core Configuration Guide - Priority of Outstation Background Colors (System Colors)

Priority of Outstation Background Colors

This chart indicates which advanced driver outstation status takes precedence over another, and therefore which core system background color is assigned to an outstation at any particular time (unless a driver-specific state and associated color takes precedence):

Further Information

Alphabetical List of Core System Colors.


Core Configuration Guide - Defining a Custom State Color

Defining a Custom State Color

Each state on a Point or Forecast is associated with a color. By default, such states are shown in black text (the Normal (Foreground) color from the Color Palette) on displays such as Lists, unless:

  • The point or Forecast is in an alarm state (in which case the entry is displayed in the corresponding severity color)
  • Another status, such as an Override, takes precedence over a non-alarm state (in which case the entry is displayed in the color that indicates that status).

In certain situations, you may want to associate a particular state with a specific color. For instance, you may want to associate the state ‘Pump Running’ with a color that does not in itself indicate an alarm state, but does bring to the attention of operators the fact that a pump is running (see Example Configuration).

For such a requirement, you need to create and configure a custom color, and associate that color with the Point state.

This section explains how to:

  • Add a Custom State Color
  • Configure a Custom State Color
  • Associate a Custom Color with a Point or Forecast State.

NOTE: Do not confuse Custom Colors with System Colors, which are used to indicate a particular status, such as ‘Control Disabled’. For information on System Colors, see System Colors, or the relevant driver guide.


Core Configuration Guide - Add a Custom State Color (Defining a Custom State Color)

Add a Custom State Color

To add a custom state color to the ClearSCADA database:

  1. In the Database Bar, right-click on the Group or System to which you want to add a Custom Color.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu followed by the Explorer Bar option, and then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Custom Color option.
    A Custom Color item is added to the selected Group or System (depending on your selection in step 1). The Custom Color is selected automatically, ready for you to define its name.
  5. Enter a suitable name for the Custom Color (taking into account the ClearSCADA Naming Restrictions).
  6. Press the Enter key or select another part of the ViewX display to confirm the name entry.

Once you have added a Custom Color, you can use the Custom Color Form to configure the color (see Configure a Custom State Color).

To use the Custom Color, you need to associate it with the Point or Forecast State(s) with which it is to be used (see Associate a Custom Color with a Point or Forecast State).


Core Configuration Guide - Configure a Custom State Color (Defining a Custom State Color)

Configure a Custom State Color

To configure the Custom Color properties, you need to display the Custom Color Form (see Display a Form).

The Custom Color Form has these tabs:

  • Identification—Use to configure the Identification properties (see Defining Identification Details).
  • User Methods—Use to define any custom pick actions (‘methods’) for the Custom Color (see Using the User Methods Tab to Define Custom Actions).
  • Color—Use to Specify a Color and Specify Whether a Color Flashes.


Core Configuration Guide - Specify a Color (Defining a Custom State Color)

Specify a Color

Use the Color field on the Color tab to specify the color that ClearSCADA is to use for this custom color.

Ensure that the color that you choose is not identical to, or could be confused with, another color on the system.

To specify a color:

  1. Select the Color field.
    A pop-up color palette is displayed.
  2. Either:
  1. Select an existing color from the palette.

Or:

  1. Select the ... option.
    The Color window is displayed.
  2. Use the color window to specify the required color (see Using the Color Window).
  3. Select OK to close the Color window and store the selection.


Core Configuration Guide - Specify Whether a Color Flashes (Defining a Custom State Color)

Specify Whether a Color Flashes

Use the Flash check box on the Color tab of the Custom Color Form to specify whether the custom color is to be static or flashing:

Select the Flash check box for the custom color to flash on any displays on which it is used.

Ensure that the Flash check box is clear for the custom color to be static on any displays on which it is used.


Core Configuration Guide - Associate a Custom Color with a Point or Forecast State (Defining a Custom State Color)

Associate a Custom Color with a Point or Forecast State

To associate a Custom Color with a Point or Forecast state:

  1. Display the Form for the Point or Forecast (see Display a Form).
  2. Select the tab on which the Point or Forecast States are displayed.
    Select the tab on which the Point or Forecast states are configured.

  3. Select the browse button adjacent to the Color field of the state for which you want to use a Custom Color.
    A Reference browse window is displayed.
  4. Locate the required Custom Color in the Reference browse window.
  5. Select the OK button.
    The Reference browse window is closed. The Custom Color name is displayed in the Color field.
  6. Save the configuration (see Saving Configuration Changes).

Whenever the Point or Forecast is in the state that is associated with the Custom Color, the entry will appear in the selected color, unless it is overridden by an alarm state or other status (see Example Configuration).

If the state’s Severity is set to ‘Alarm’, the color is also used to indicate that alarm limit in Trends—if no Custom Color is specified, the alarm limit is displayed in red, by default. (This default color is specified using the ClearSCADA Server Configuration Tool (see Points Settings in the ClearSCADA Guide to Server Administration).)

Points also contain properties, such as ‘CurrentStateColour’ that can be used in Mimic Animations to change color according to the point’s state. Such properties will use the Custom Color whenever the point is in the state for which the color is configured. (For information on using Animations, see the ClearSCADA Guide to Mimics.)


Core Configuration Guide - Example Configuration (Defining a Custom State Color)

Example Configuration

This example shows how a Custom Color might be used to indicate when a pump is running.

Example:

Operators on a ClearSCADA system need to be aware of when any pumps are running on the system. To bring such an occurrence to the attention of the operators, a Custom Color is configured and assigned to the ‘Pump Running’ state for each pump on the system.

The Custom Color is labelled ‘Pump Running’ and has this configuration (specified on the Custom Color Form):

The Custom Color is associated with the ‘Pump Running’ state of each pump by specifying the color for that State on the appropriate Point Forms:

The ‘Pump Running’ State...
...is assigned the ‘Pump Running’ color

Whenever a pump is in the ‘Pump Running’ state, providing no other status takes precedence, the pump details use the specified Custom Color:

On the Mimics on which the pumps are displayed, the pump symbols are animated to use each pump’s ‘CurrentStateColour’. So, whenever a pump is running, the relevant pump symbol displays the ‘Pump Running’ custom color:

The ‘Pump Running’ state is indicated by the pump displaying the ‘Pump Running’ color.


Core Configuration Guide - Using the Color Window to Define a Color

Using the Color Window to Define a Color

Each ClearSCADA system is supplied with sets of default colors. These sets include:

  • System Colors—Colors that are used to indicate the status of an item, such as ‘Outstation Override’ (see System Colors).
  • Alarm Colors—Colors that are used to indicate that an item is in a particular alarm state (for example, ‘Unacknowledged’) (see Edit a Severity Range in the ClearSCADA Guide to Server Administration).

You can use the default colors on your system or choose to replace any of the colors with custom colors. You can also use a custom color to indicate a particular Point or Forecast state, in place of the default ‘Normal’ state color (see Defining a Custom State Color).

If you decide to use a custom color, you will need to use the Color window to specify the color that you want to use. This section explains how to use the Color window (see Using the Color Window). For information on accessing the Color window, see the appropriate section listed above.

When you specify a custom color, ensure that the color that you choose is not identical to, or could be confused with, another color on the system.

Further Information

Change the Alarm Limits Color on Trends: see Define the Colors for Point Trend Graphs in the ClearSCADA Guide to Server Administration.

Change the Marker Colors on Trends: see the ClearSCADA Guide to Trends.

Using Color on Mimics (including animations, and changing the colors on custom menus): see the ClearSCADA Guide to Mimics.


Core Configuration Guide - Using the Color Window (Using the Color Window to Define a Color)

Using the Color Window

When you select the ... option on a pop-up color palette, the Color window is displayed (for information on accessing the color palette, see Using the Color Window to Define a Color, above).

To select a color from the Color window:

  1. Either:
  1. Select a color from the Basic Colors palette.

Or:

  1. Select a color from the Custom Colors palette.

Or:

  1. Specify a New Custom Color.
  2. Add the color to the Custom Colors palette.
  3. Select the new color from the Custom Colors palette.
  4. Select the OK button on the Color window.


Core Configuration Guide - Specify a New Custom Color (Using the Color Window to Define a Color)

Specify a New Custom Color

To define a new custom color:

  1. Select an unused color box from the Custom Colors palette.
  2. Perform one of the following:
  • Select the required range from the Color Box display and the required shade from the Shade bar.
  • Define the numeric values of the color in the Hue/Saturation/Luminescence boxes.
  • Define the numeric values of the color in the Red/Green/Blue boxes.
    Color Box display
    Shade bar
    Red/Green/Blue color intensity boxes
    Hue/Saturation/Luminescence boxes
    Field displaying chosen color

  3. Select the Add to Custom Colors button.
    The color is displayed at the selected location in the Custom Colors palette.
  4. Select the OK button on the Color window.

NOTE: You can also use the Color window to ascertain the RGB value of a particular color. The values shown in the Red, Green, and Blue color intensity boxes define a color’s RGB value. In the image shown above, the selected color has the RGB value RGB(255,150,150). You might need to specify an RGB value, for instance, if you use ClearSCADA’s proprietary specification language, TrendSpec, to define an ad hoc Trend’s colors.

To change an existing custom color:

  1. Select the color that you want to change from the Custom Colors palette.
  2. Follow Steps 2 to 3, above, as you would to define a new custom color.


Core Configuration Guide - Converting a Database Item

Converting a Database Item

The Convert To feature allows you to convert a database item into another item of a similar type—for example, to convert an internal digital point into a Modbus digital point. This feature is only available to specific types of database item, and is designed to provide:

  • An upgrade path when an outstation, PLC, or similar device has been replaced or upgraded with a different type of version of that device.
  • A method for changing the type of an item when a wrong type of item has been created by mistake.

You can also use the Convert To feature to reduce the amount of time and effort it takes to configure an item. For example, if you need to configure a new item to have a similar configuration as an existing item of a different type, you can copy the existing item, and then convert the copy into the required type. You can use the copy as the basis for the required configuration.

Be aware that when you convert some types of database item, that item’s ‘children’ may convert automatically into items of the equivalent type. For instance, if you convert a DNP3 outstation into a Kingfisher outstation, any DNP3 points that are associated with the DNP3 outstation are converted into their Kingfisher equivalent. Only those points for which an equivalent exists are converted—for points for which no equivalent exists, the point type remains unchanged and any references to the outstation are severed when the outstation is converted.

A dialog box is displayed if any mandatory information is incomplete or invalid, or if there is conflicting configuration following the conversion process. For information on checking for, and correcting, configuration errors, see Checking for Invalid Configuration.

Automatic conversion of ‘children’ only applies if items of the conversion equivalent exists and if the items are in an ordinary Group (rather than a Group Instance or Group Template).

For restrictions and limitations that apply when converting items in Templates and Instances, see Convert an Item in a Group Template.

NOTE: To produce a generic point or outstation type that you can readily convert into a specific point or outstation type, consider using an Abstract Item. You can configure Abstract item(s) within Group Templates, then convert them to specific items within each instance of that Template (see Convert an Abstract Item into a ‘Real’ Point or Outstation).

To convert a database item into a different type of database item:

ATTENTION: Converting an item may invalidate some or all of the references to that item (see Displaying a Database Item’s References).

  1. In the Database Bar, right-click on the item that you want to convert.
    A context sensitive menu is displayed. If the item can be converted into a different type of item, the Convert To option is available on the context sensitive menu.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

  2. Select the Convert To option.
    A further menu is displayed (with arrows to display further options, if applicable).
    The options vary, depending on the drivers that are installed on your system.

  3. Select the type of item into which you want to convert the selected item.

For example, if you right-clicked on an internal digital point in step 1, and you want to convert it into a Modbus digital point, select the option for the relevant type of digital point.
The selected item is converted into the type of item that you selected.

  4. A Convert Object dialog box is displayed listing any incomplete, conflicting, or invalid configuration that has occurred as a result of the conversion process.

As with other such dialog boxes (see Checking for Invalid Configuration), you can double-click on an entry in the list, in order to display the Form for the item and make the necessary correction.

Repeat the procedure for each of the entries in the dialog box.

  5. You will probably need to configure some other properties on the converted item’s Form (for instance properties that exist now that the item has been converted to a different type).

For more information, please refer to the relevant configuration section.

Further Information

Convert a Group into a Group Template.

Convert a Group Instance into a Group

Convert a Group Instance to Reference a Different Group Template

Restrictions that apply if you Convert an Item in a Group Template.


Core Configuration Guide - Copying a Database Item

Copying a Database Item

You can make a duplicate of an item or group of items. This can be useful for reducing the amount of configuration required—you can make copies of items that are similar, and then alter the configuration of the features that are unique. Copying duplicates the configuration of an item or group of items, it does not copy across any data associated with the item(s) that are being copied.

This section explains how to:

  • Use Copy and Paste to Copy a Database Item.
  • Use ‘Drag and Drop’ to Make a Copy of an Item.

If your system uses Areas of Interest (see Restrict Alarm and Event Access to Specific Areas of Interest), you can use the above procedures to copy an Area of Interest. To do so, you would Display the Areas of Interest Bar, rather than the Database Bar.

NOTE: To produce like groups of items, consider using a Group Template, and then creating Group Instances of that Template. Whenever you make configuration changes to any items within the Template, the same changes are replicated in each of the Instances of those items (see Group Templates and Group Instances).


Core Configuration Guide - Use Copy and Paste to Copy a Database Item (Copying a Database Item)

Use Copy and Paste to Copy a Database Item

The Copy and Paste feature uses Windows’ temporary storage ‘clipboard’ to store a copy of the item’s configuration.

When you copy an item to the clipboard, the item’s configuration is stored in the clipboard until it is replaced by other copied content (which may be from another application).

When you use the paste feature, you add the contents of the clipboard to a selected Group or Group Template. However, the contents of the clipboard are only added if they are compatible.

To use the copy and paste features to copy an item:

  1. Copy an Item onto the Clipboard.
  2. Paste an Item from the Clipboard into the Database.

You can also use the above procedures to copy items between ClearSCADA systems, if your workstation is connected to more than one system. To copy items between systems that are not connected, you need use the Import and Export features (see Importing and Exporting Database Items).


Core Configuration Guide - Copy an Item onto the Clipboard (Copying a Database Item)

Copy an Item onto the Clipboard

To make a copy of an item or whole Group of items and store the copy on the clipboard:

  1. In the Database Bar, select the database item that you want to copy.
  2. Either:
  1. Select the Edit menu from the ViewX menu bar.
  2. Select the Copy option.

or:

  1. Press the CTRL and C keys simultaneously.

or:

  1. Select the Copy button [image] on the File Toolbar.

A copy of the item is added to your computer’s clipboard. You can add the copy to your database by using the Paste feature (see Paste an Item from the Clipboard into the Database).

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

If an item that you are attempting to copy contains absolute references to another item, an Export Configuration dialog box is displayed listing those references. You can adjust the references in either the original configuration, or the copy that you make of the item (see Correcting Absolute References).


Core Configuration Guide - Paste an Item from the Clipboard into the Database (Copying a Database Item)

Paste an Item from the Clipboard into the Database

To paste an item into the database, you first need to have copied an item into the clipboard (see Copy an Item onto the Clipboard).

You can ‘paste’ an item or whole Group of items from the clipboard into the database. This means that you insert a copy of the item or Group into the ClearSCADA database. You can use the Rename feature to alter the name of the copy (see Renaming a Database Item).

To paste an item or Group from the clipboard into the database:

  1. In the Database Bar, select the System, Group, or Group Template that is to contain the pasted item.
  2. Either:
  1. Select the Edit menu from the ViewX menu bar.
  2. Select the Paste option.

or:

  1. Press the CTRL and V keys simultaneously.

or:

  1. Select the Paste button [image] on the File Toolbar.

The copied item is added to the selected System, Group, or Group Template.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

If an item that you have copied contains duplicated absolute references to another item, an Import Configuration dialog box is displayed listing those references. You can adjust the references by double-clicking on the entries in the dialog box (see Correcting Absolute References).


Core Configuration Guide - Use 'Drag and Drop' to Make a Copy of an Item (Copying a Database Item)

Use ‘Drag and Drop’ to Make a Copy of an Item

You can use the ‘drag and drop’ functionality to make a duplicate of an item. This method of copying database items is quicker to perform, and does not use the clipboard.

To use ‘drag and drop’ to copy and paste an item:

  1. In the Database Bar, select the individual database item or whole Group of items that you want to copy. Do not release the left-hand mouse button.
  2. Press the CTRL key. Do not release it.
  3. Drag the cursor to the System, Group, or Group Template that is to contain the copy of the item.
  4. Release the left-hand mouse button and the CTRL key.
    A copy of the selected item is added to the Database Bar tree-structure.

You can use the Rename feature to alter the name of the copy (see Renaming a Database Item).

If an item that you have copied contains duplicated absolute references to another item, an Import Configuration dialog box is displayed listing those references. You can adjust the references by double-clicking on the entries in the dialog box (see Correcting Absolute References).


Core Configuration Guide - Renaming a Database Item

Renaming a Database Item

You can use the Rename feature to change the name of a database item. This is especially useful for allocating a suitable name to a new item, or a copy of a database item.

You can rename a database item using one of two methods:

  • Rename an Item using the Rename Action
  • Rename an Item without using the Rename Action.

Both methods involve using the Database Bar. If the Database Bar is not displayed, you can access it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

If your system uses Areas of Interest (see Restrict Alarm and Event Access to Specific Areas of Interest), you can use the above procedures to Rename an Area of Interest. To do so, you would Display the Areas of Interest Bar, rather than the Database Bar.

To use the above procedures to rename a document in an Operator Document Store (see Setting up Operator Document Stores), you would display the Operator Documents Bar, rather than the Database Bar.

For information on renaming a link in a Favorites List, see Rename a Link or Folder in your Favorites List in the ClearSCADA Guide to ViewX and WebX Clients.


Core Configuration Guide - Rename an Item using the Rename Action (Renaming a Database Item)

Rename an Item using the Rename Action

To rename a database item using the Rename action:

  1. Either:
  • Right-click on the database item in the Database Bar.
    A context sensitive menu is displayed.

Or:

  1. Select the item in the Database Bar.
  2. Select the Edit menu from the ViewX menu bar.
    A further menu is displayed.
  2. Select the Rename option.
    The name of the database item is selected.
  3. Enter a new name to overwrite the existing name, or make amendments to the existing name. Remember to take into account any Naming Restrictions.
  4. Select another part of the ViewX display or press the Enter key to confirm the new name.


Core Configuration Guide - Rename an Item without using the Rename Action (Renaming a Database Item)

Rename an Item without using the Rename Action

To rename the database item directly from within the Database Bar without accessing the Rename action:

  1. Select the item in the Database Bar.
  2. Either:
  • Press the F2 function key on your keyboard.

Or:

  • Select the item for a second time and pause before releasing the mouse button.

The name of the item is highlighted and the cursor positioned, ready for you to change the item’s name.

  3. Enter a new name to overwrite the existing name, or make amendments to the existing name. Remember to take into account any Naming Restrictions.
  4. Select another part of the ViewX display or press the Enter key to confirm the new name.


Core Configuration Guide - Naming Restrictions (Renaming a Database Item)

Naming Restrictions

When naming or renaming an item in ClearSCADA, you need to take into account these restrictions:

  • You can include any alphanumeric character within a name.
  • You can include most non-alphanumeric Unicode symbols, such as ! * ( ) - _ , ~ `, in a name, with the exception of the following symbols, which cannot be included as they are reserved characters:
    < > # % \ “ ; : / ? . @ & = + $ { } | ^ [ ] ‘

(This restriction does not apply to Areas of Interest. The only symbol that must not be included in an Area of Interest name is a dot (.) separator.)

  • If you rename an item in a Template, that name will be replicated in each of the Instances of that Template. (You cannot rename an item in a Group Instance directly, you can only rename the Instance Group.)
  • The maximum length of a name is 63 characters. The overall full name of an item (as displayed in Queries Lists, and on the top banner of Forms, and so on) must not exceed 254 characters in total. This length includes the separation dots within the path name, and any blank spaces used within any part of the name.

Example:

An internal point is renamed Test Int Analog. The name uses 15 characters, including spaces.

The full name of the point, which is stored within the Northern Site Group in the database, is:
Northern Site.Internal Points.Test Int Analog
The full name of the point therefore uses 45 characters, including spaces and separation dots.

  • Each item has to have a unique name within its Group—a diagnostic message is displayed if there is an attempt to give an item a name that already exists within that Group.

With the exception of user names (see below), you can configure items in one group to use the same name as those in another group, as long as the path is unique for each of those items. (As the path includes the Group name, this allows ClearSCADA to differentiate between similarly named items in other groups.)

Example:

The group Engine 1 has a digital point Motor 1.

The group Engine 2 also has a digital point Motor 1.

Because the full path for each digital point includes the Group name (Engine 1, or Engine 2), the full name for each digital point is unique (Engine 1.Points.Motor 1, and Engine 2.Points.Motor 1).

  • Each user name has to be unique across the entire system (not just within the Group in which it is located).

Example:

Two engineers have the name John Jackson. To differentiate between their user names on the system, their initials are also used, resulting in two unique user names, John A Jackson, and John R Jackson.


Core Configuration Guide - Deleting a Database Item

Deleting a Database Item

You can use the Delete option to remove database items from the ClearSCADA database. This is useful for removing items that are no longer used.

Ensure that you select the correct unwanted item before choosing to delete it.

To delete a database item:

Either:

  1. Select the database item in the Database Bar.
  2. Press the Delete key.

Or:

  1. Right-click on the database item in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Delete option.

Or:

  1. Select the database item in the Database Bar.
  2. Select the Edit menu.
  3. Select the Delete option.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

(If your system uses Areas of Interest (see Restrict Alarm and Event Access to Specific Areas of Interest), you can use the above procedures to Delete an Area of Interest. To do so, Display the Areas of Interest Bar, rather than the Database Bar. For restrictions regarding deleting an Area of Interest, see Delete an Area of Interest.)

If you opt to delete a single item from the database, a confirmation dialog box is displayed:

Use the buttons on the dialog box to confirm whether you want to delete the item. If you select ‘Yes’ and the item is referenced by other items or has historic data online, a consequences dialog box is displayed (see below).

If you opt to delete an item from a Group Template, ClearSCADA will also delete all of the corresponding Instances of that item from the database.

If you opt to delete a Group, Group Template, or Group Instance, the dialog box indicates that ClearSCADA will also delete the items within that Group and its sub-Groups:

Use the buttons on the dialog box to confirm whether you want to delete the Group and its contents. If you select ‘Yes’ and any of the items are referenced by other items or have historic data online, a consequences dialog box is displayed (see below).

If the item, Group, or Group Instance that you are deleting:

  • Is referenced by other database items

or:

  • Comprises or contains point(s) or accumulator(s) for which historic data exists online

a consequences dialog box is displayed. The dialog box lists the consequences of proceeding with the deletion. It requires you to confirm whether you still want ClearSCADA to delete the item or Group.

The dialog box:

  • Lists any existing references to the item(s) that are about to be deleted. If you proceed with the deletion, those links that reference the deleted item(s) will be severed automatically—ensure that you update any necessary links for those items that remain in the database. For more information on database references, see Displaying a Database Item’s References.
  • Shows the number of historic records that exist online for any point(s) or accumulator(s) that are about to be deleted. If you proceed with the deletion, ClearSCADA will automatically delete the historic records from the database. If you need to retain a copy of the historic data, ensure that you archive, print, or copy the historic data to a file or another application before proceeding with the deletion.


Core Configuration Guide - Displaying a Database Item's References

Displaying a Database Item’s References

If your User Account is assigned the Configure Database feature, you can use the Display References option to display a list of the database items that refer to a selected database item. The list allows you to view those database items that will be affected by changes to the selected database item. The list shows, for example, the full name (including the database path) of:

  • Any database items that reference the selected item via a reference field on their configuration Form
    This Outstation field on a Point Form references the outstation on which the point is located.

  • Any Mimics on which the selected item is included, with the exception of:
  • Any indirect references to the selected item (via the use of Indirect Tags)
  • Any Mimic Scripts that reference the selected item.
  • Any Logic programs on which the selected item is included, with the exception of:
  • Any indirect references to the selected item (via the use of Indirect Tags)
  • Any Logic Programs that contain errors and do not compile.
  • Any Pre-Configured Trends on which the selected item is included
  • Any Schedules that are configured to trigger an action on the selected item
  • If the selected item is a Group Template, any Group Instances that reference that Group Template.

To access the references list for a database item:

  1. Display the item’s context sensitive Object Menu (for example, right-click on the item’s entry in the Database Bar).
  2. Select the Display References option.
    A References window is displayed. It contains a list of the items that refer to the selected database item.
    The References window lists the database items that refer to the selected item.

You can double-click on any entry in the References window to edit that item, for example, to change the configuration so that it references a different database item.

If you copy or export an item in the database that has absolute references (that is, references to a specific item in the database), an Import Configuration dialog box is displayed listing those references. You can adjust the references in either the original configuration, or the copy that you make of the item (see Correcting Absolute References).


Core Configuration Guide - Importing and Exporting Database Items

Importing and Exporting Database Items

You can use the Import and Export features to make a duplicate of a database item and insert the duplicate into another database. This is useful on multi-site systems, where those systems are not connected together, as it allows similar configurations to be duplicated between sites. (If your systems are connected together, you can simply copy and paste items between systems (see Copying a Database Item).)

You can import and export any database item.

When you import and export a Group, Group Template, or Group Instance:

  • You also import and export the items within the selected Group, Group Template, or Group Instance. For example, if you export a Group Template, you also export the database items within the Group Template.
  • If you intend importing Group Templates and Group Instances separately, you need to import the relevant Group Template before you import a Group Instance.

If you import a Group Instance before you have imported the Group Template, the Group Instance will lose its association with the Group Template.

You can export any part of the database configuration to an older version of ClearSCADA if required (useful if some servers are running older versions of ClearSCADA to other servers on multi-site systems). The ability to export to an older version of ClearSCADA only applies to database configuration, which is exported as an .sde export file, and not data or maintained objectIDs. When exporting to an older version of ClearSCADA, ensure that the correct older version is specified for the export file—you can only import an .sde file into a version of ClearSCADA that is identical to, or newer than the version of ClearSCADA specified for the .sde.

The following sections explain how to:

  • Export Database Items
  • Import Database Items
  • Import and Merge Database Items.

Further sections discuss Correcting Absolute References and provide summary information about ClearSCADA’s Incremental Import process.


Core Configuration Guide - Export Database Items (Importing and Exporting Database Items)

Export Database Items

NOTE: For information on exporting reports, see the ClearSCADA Guide to the Crystal Reports Driver.

You can make a copy of a database item and store it as an export file. The export file can then be imported into another database. This means that you can copy items between databases, which is useful for minimizing the amount of time and effort it takes to configure a system.

To export a database item:

  1. In the Database Bar, select the item that you want to export.

If you select a Group, Group Template, or Group Instance, the export file will contain a copy of the Group, Group Template, or Group Instance and the items within that group.

  2. Select the Edit menu from the ViewX menu bar.
  3. Select the Export option.
    The Export Item window is displayed (the layout of this window varies, depending on the operating system that you are running).
  4. Use the Export Item window to define the directory that will contain the export file.
  5. Enter a suitable name for the export file in the File name field.
  6. If the file is being exported so that it can be used in an older version of ClearSCADA, use the Save as version combo box to specify the required older ClearSCADA version. This saves the file in a format that can be read by the older database. (You can only import an .sde export file into a version of ClearSCADA that is identical to, or newer than the version of ClearSCADA specified for the .sde.)
  7. Select the Save button on the Export Item window.
    The Export Item window is closed and the selected item or group of items is saved as
    a ClearSCADA Export file. The export file can be imported into any ClearSCADA database (see Import Database Items).

If an item that you are attempting to export contains absolute references to another item, an Export Configuration dialog box is displayed listing those references (see Correcting Absolute References).


Core Configuration Guide - Import Database Items (Importing and Exporting Database Items)

Import Database Items

You can import configuration from a ClearSCADA export file. Export files contain copies of database items.

Importing database items can significantly reduce the amount of time required to set-up a system, as you can import similar configurations from other systems rather than configure new items in your database.

Use the Import command to:

  • Import files for which the content does not already exist in your database
  • Import files, without merging them with any like-content that already exists in your database.

To Import files for which similar content already exists in your database, and for which you want to update the content with the imported data, see Import and Merge Database Items.

To import a ClearSCADA export file:

  1. Select the System, Group, or Group Template that is to contain the imported database items.

If you are importing Group Template and Group Instances separately, remember to import the relevant Group Template before you import a Group Instance. If you import a Group Instance before you have imported the Group Template, the Group Instance will lose its association with the Group Template.

  2. Select the Edit menu from the ViewX menu bar.
  3. Select the Import option.
    The Import From window is displayed (the layout of this window varies, depending on the operating system that you are running).
  4. Use the Import From window to locate the ClearSCADA export file that you want to import into your database.
  5. Select the required ClearSCADA export file.

If you are importing an .sde file from a newer version of ClearSCADA, the .sde file needs to have been produced using the correct format (with the older version of ClearSCADA specified at the time of export)—see Export Database Items.

  6. Select the Open button on the Import From window.
    The Import From window is closed and the relevant data is imported. The imported data is stored at the location you selected in step 1.

ClearSCADA supports Incremental Import, whereby the import process comprises several phases, to minimize the import’s impact on system performance.

If an item that you have imported or copied contains duplicated absolute references to another item, an Import Configuration dialog box is displayed listing those references. You can adjust the references by double-clicking on the entry in the dialog box (see Correcting Absolute References).

If an identically named item is found to already exist in at the location into which you are importing configuration, the imported item is renamed to differentiate it from the existing item (typically, to ‘Copy of...’).

For the restrictions that apply should a Group Instance be imported, see Limitations and Restrictions.

If you want to replace existing configuration with imported configuration, you might want to consider using the Import & Merge feature (see Import and Merge Database Items).


Core Configuration Guide - Incremental Import (Importing and Exporting Database Items)

Incremental Import

ClearSCADA supports ‘incremental imports’, whereby the content of a ClearSCADA export file is imported into ClearSCADA in a series of phases. Importing configuration in this way enables the content of an export file to be imported into another ClearSCADA database with the minimum of impact on system performance while that import is in progress.

Two events are logged in the Event Journal for a successful import request:

  • Import Started—This entry is logged in the Event Journal at the start of the import process, to indicate the time and date that the import commenced.
  • Import Complete—This entry is logged in the Event Journal once all phases of the import are complete.

In addition to the above, ClearSCADA provides information on the progress of each phase of the import, while that phase is in progress.

At the start of the import process, all of the database items that are being added to the ClearSCADA database as a result of the import are created in the database.

Each newly created database item is available, for example, from the tree structure in the Database Bar.

Each item is initially marked as ‘Import in Progress’ and has invalid configuration until the import is complete. The second phase of the process imports the configuration for each item—this is usually the longest phase of the import process.

When this phase is complete, the imported items are initialized and then validated. The import is deemed complete at the end of the validation phase.

Should an Import or Import & Merge be aborted or fail part-way through, the items that were being imported will still be marked as ‘Import in Progress’ and be unusable. Should this situation occur, we suggest that all of these items are deleted from the database into which they were being imported, and the Import or Import & Merge request be repeated.

Further Information

Import Database Items.

Import and Merge Database Items.


Core Configuration Guide - Import and Merge Database Items (Importing and Exporting Database Items)

Import and Merge Database Items

You can import and merge configuration from a ClearSCADA export file. This function can be used, for example, to maintain a ‘template’ database. By using the Import and Merge feature, the ‘template’ database can be used to update several ‘live’ databases with recent configuration changes. This can significantly reduce the amount of time required to set up large systems, as you can import one set of configuration changes, rather than make the same changes more than once throughout the system.

The import and merge function carries out a standard database import (see Import Database Items). However, if an identically named item is found to already exist at the location at which the configuration is being imported:

  • If the existing item is the same item type as an imported item (for instance, a DNP3 Analog Input point, a Mimic, or a DNP3 Direct Channel), then the existing configuration for that item is overwritten by the imported configuration.
  • If ClearSCADA can convert the existing item to the same type as the imported item, ClearSCADA carries out that conversion. (For information on converting items from one type to another, see Converting a Database Item.)

Example:

A ClearSCADA export file contains the configuration for a Group named Area 2. The Group contains a Kingfisher Analog Input point named AI Point 2. The export file is imported and merged into another ClearSCADA database, also with a Group named Area 2. This Area 2 Group also contains a point named AI Point 2, however the point is an Internal Analog point.

During the Import and Merge process, the Internal Analog point is automatically converted into a Kingfisher Analog Input point. The conversion is listed in a dialog box. As further configuration of the point is now required, messages indicating any mandatory configuration requirements are also displayed:

  • If the existing item is not of the same type as the imported item and cannot be converted to the same type, the existing item is retained unchanged and the imported item is omitted from the import and merge process.

If an identically named item is not found to exist in the database into which the export file is being imported and merged, that part of the imported configuration is merely appended to the existing configuration.

Example:

A ClearSCADA export file contains the configuration for a Group named Area 3. The Group contains three DNP3 Analog Input points, named AI Point 1, AI Point 2, and AI Point 3. The export file is imported and merged into another ClearSCADA database, also with a Group named Area 3. This existing Group contains only two analog points, AI Point 1, and AI Point 2. During the Import and Merge process, the configuration of AI Point 1 and AI Point 2 is replaced by the configuration from the export file. In addition, the analog point AI Point 3 is added to the Area 3 Group.

To import and merge a ClearSCADA export file:

  1. Select the System, Group, or Group Template that is to contain the imported and merged database items.

If you are importing and merging Group Templates and Group Instances separately, remember to import and merge the relevant Group Template before you import and merge a Group Instance. If you import a Group Instance before you have imported the Group Template, the Group Instance will lose its association with the Group Template.

  2. Select the Edit menu from the ViewX menu bar.
    A drop-down menu is displayed.
  3. Select the Import & Merge option.
    The Import From window is displayed. The layout of the window varies, depending on the operating system that you are using.
  4. Use the Import From window to locate the ClearSCADA export (.sde) file that you want to import and merge with your database.
  5. Select the required ClearSCADA export file.

You can only import an .sde file into a version of ClearSCADA that is compatible with the version specified in the .sde file. If you want to import configuration from a newer version of ClearSCADA into an older version, you must select the appropriate version when you export the configuration—see Export Database Items.

  6. Select the Open button on the Import From window.
    The Import From window is closed and the relevant configuration is imported and merged. The configuration is merged with the existing configuration at the location you selected in Step 1.
  7. ClearSCADA supports Incremental Import, whereby the import process comprises several phases, to minimize the import’s impact on system performance. Once the import process is complete (as indicated by an ‘Import Complete’ entry in the Event Journal), ensure that any necessary configuration is carried out on those items that have been converted during the merge process. (An Import dialog will indicate which items have been converted, and list any mandatory configuration required.)

If an item that you have imported contains duplicated absolute references to another item, an Import Configuration dialog box is displayed listing those references. You can adjust the references by double-clicking on the entry in the dialog box (see Correcting Absolute References).

For the restrictions that apply should a Group Instance be imported, see Limitations and Restrictions.


Core Configuration Guide - Correcting Absolute References (Importing and Exporting Database Items)

Correcting Absolute References

If an item that you are attempting to export or copy contains absolute references to another item, an Export Configuration dialog box is displayed listing those references.

To correct or remove those references before making the export or copy, double-click on the entry within the dialog box—the item’s configuration Form is displayed, from within which you can adjust the reference.

Alternatively, you can change the references in the exported or copied version that you make (see below), and leave the original references unchanged.

If an item that you have imported or copied contains duplicated absolute references to another item, an Import Configuration dialog box is displayed listing those references.

The Import Configuration dialog box lists any duplicated absolute references, along with any other messages regarding configuration requirements.

You can adjust each reference by double-clicking on the entry in the dialog box—the item’s configuration Form is displayed, from within which you can make the necessary changes.


Core Configuration Guide - Checking for Invalid Configuration

Checking for Invalid Configuration

During your database’s configuration life cycle, you are likely to come across occurrences of incomplete, conflicting or invalid configuration. When an item is first added to the database, for example, certain properties are likely to need specifying. The item’s configuration will be marked as invalid until those properties have been specified and saved in the database.

When Importing and Exporting Database Items, an item that is in the process of being imported into one ClearSCADA database from another will initially have invalid configuration until the import is complete (see Incremental Import).

An item that has invalid configuration behaves as if it is out of service (see Placing an Item In Service).

If an item has invalid configuration, this is indicated by one or more messages being displayed in the message area at the bottom of that item’s configuration Form (see Mandatory Configuration and Invalid Configuration Messages).

Invalid configuration is also indicated in the Database Bar by a red cross appearing over the icon that represents the item:

An icon displays a red cross if it has invalid configuration (or, in the case of a Group, Group Template, or Group Instance, if item(s) within that group have invalid configuration).

The quality attribute of an item that has invalid configuration will indicate either Not Connected or Configuration Error, depending on the specific configuration error(s).

You can ascertain an item’s quality by viewing the item on, for example a List, Mimic, or Trend—an item that has invalid configuration, or data that is otherwise suspect (through the item being out of service, for instance) is indicated by its entry using the Bad Quality system color.

An entry is marked as suspect if, for instance, its configuration is invalid, or the item is not In Service.

To ascertain the reason for the color, you can either:

  • Look at the relevant entry in a List’s Quality column:
    The entry in the Quality column indicates why an item’s data is marked as suspect.

  • View the quality attribute in the item’s Status display:
    An item’s quality attribute indicates the reason for its data being suspect.

If configuration is invalid, display the item’s Form (see Display a Form) and correct the configuration as necessary.

ATTENTION: Some types of pick action require ClearSCADA to be in communication with an outstation in order to execute the pick action. If such a pick action is requested when ClearSCADA is not in communication with the outstation, ClearSCADA might queue that request until communications with the outstation is next established (see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations in the ClearSCADA Guide to Drivers). Be aware that any queued pick action requests that are associated with a database item will be deleted if that item’s configuration becomes invalid.

To display a list of configuration errors for the items in a Group:

  1. Right-click on the Group in the Database Bar.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

  2. Select the Display Errors option.
    A Configuration Errors dialog box is displayed listing any configuration errors that exist for items in the Group.
  3. Double-click on an entry on the list to display the Form for that item.
    The cursor is positioned at the relevant location on the Form, ready for you to correct the configuration.
  4. Amend the configuration as required.
  5. Save the changes (see Saving Configuration Changes).
  6. Repeat steps 3 to 5 for each entry in the Configuration Errors dialog box.

Further Information

Mandatory Configuration and Invalid Configuration Messages.

System Colors.

Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Lists: see the ClearSCADA Guide to Lists.


Core Configuration Guide - Placing an Item In Service

Placing an Item In Service

In order for most items to be active within the ClearSCADA system and for the ClearSCADA server to communicate with those items that have comms, you need to ensure that the item is In Service (active). You also need to ensure that the item has valid, saved, configuration (an item that has invalid configuration behaves as if it is out of service, with its Quality status attribute indicating the reason for that behavior—for more information, see Checking for Invalid Configuration.)

By default, most items are not In Service when they are first created.

Use the In Service check box on the item’s configuration Form to specify whether that item is In Service.

Select the check box for the item to be active (providing that the item has valid, saved, configuration).

Clear the check box for the item to be inactive (out of service). (Be aware that where a database item has dependants, if you take that item out of service, its dependants also become out of service. For instance, if you take an outstation out of service, its points, pulse actions and other dependants also become out of service.)

The Quality status attribute of an item that has valid configuration but is not in service indicates that the item is ‘Out of Service’.

An item’s quality attribute indicates if it has valid configuration but is out of service.

Some items, such as Internal Points and Forecasts, do not have an In Service check box, as they are deemed to be In Service once they have valid configuration.

Items that are in Group Templates and unconverted Abstract Items are always deemed out of service, as they are not ‘live’ (see Group Templates and Group Instances).

Further Information

Saving Configuration Changes.


Core Configuration Guide - Saving Configuration Changes

Saving Configuration Changes

Whenever you configure or edit a database item, you need to save the changes so that they are stored in the ClearSCADA database. With some types of database item on advanced drivers, you might also need to download the configuration to the outstation (see Downloading Configuration Changes).

ClearSCADA only deems an item to be active in the database if that item has valid saved configuration and is In Service. If the item depends on other items in the database (for instance, if the item is a point on an outstation), all of the items on which that item depends also need to have valid saved configuration and be In Service. For more information, see Placing an Item In Service and see Checking for Invalid Configuration.

To save an item’s configuration, you can use any of the following methods:

  • Select the Save button [image] on the File toolbar.

NOTE: If the File toolbar is not displayed, you can display it by selecting the View menu, then selecting the Toolbars option, followed by the File option.

Or:

  1. Select the File menu from the ViewX menu bar.
    A drop-down menu is displayed.
  2. Select the Save option.
    The configuration is saved.

Or:

  • Press the CTRL and S keys simultaneously.


Core Configuration Guide - Downloading Configuration Changes

Downloading Configuration Changes

In order for outstations or PLCs and their component parts—such as points—to communicate correctly with the ClearSCADA server, their database configuration has to be stored at the outstation. With devices with which ClearSCADA communicates using an advanced driver, you typically configure the properties of those items in the ClearSCADA database, and then write (download) the relevant properties to the outstation. (In those instances where advanced driver outstations do not support downloading, see the relevant driver-specific documentation.)

(Devices with which ClearSCADA communicates using simple drivers tend not to support downloading of configuration from a SCADA master. When configuring simple driver devices in ClearSCADA, ensure that the configuration in the ClearSCADA database replicates the settings that exist at the actual devices that those items represent.)

To download configuration to an advanced driver outstation, you use the Download Configuration pick action. The pick action is available if:

  • Supported by the type of outstation
  • The outstation has valid configuration
  • The outstation is In Service
  • Communications between ClearSCADA and the outstation is healthy
  • Your User Account is allocated the Configure security permission for the outstation (see Permissions for Database Items in the ClearSCADA Guide to Security).

Outstations on some advanced drivers have the ability to indicate that they have no configuration, or that their existing configuration is corrupt. On receipt of such an indication, ClearSCADA can automatically download the relevant configuration to the outstation.

Be aware that changing an item’s configuration in the ClearSCADA database does not automatically initiate a download—you need to trigger such a download using the Download Configuration pick action.

The Download Configuration Required system color indicates when configuration changes have been made in ClearSCADA, which have not yet been downloaded to the relevant outstation.

While a download is in progress, you must avoid making any configuration changes to that outstation or any of its dependants. Once the download is complete, you can make further changes to the configuration if required—such changes will be flagged needing to be downloaded to the outstation the next time that a Download Configuration request is made.

An entry is added to the Events List whenever a request is made to Download Configuration to an outstation. The entry will indicate the success, or otherwise, of the request.

The Download Configuration pick action can download, where supported by the driver or outstation type, database configuration for the following items:

  • The outstation
  • Any points that are associated with/reference the outstation
  • Any Pulse actions that are associated with/reference the outstation
  • Any other items that are associated with/reference the outstation and for which configuration requires downloading to the outstation (see the relevant driver-specific documentation for details of what items are supported by the outstations on your system).

To find out which database items are associated with an outstation, display the References for that outstation (see Displaying a Database Item’s References).

You should ensure that each of the associated database items have valid, saved configuration and are In Service (if they are to function online), before downloading the data to an outstation (see Checking for Invalid Configuration, and see Placing an Item In Service).

To download configuration to an outstation:

WARNING

unexpected behavior of application

Do not make further configuration changes to an outstation or any of its dependants while a download is in progress to that outstation. Performing such changes may result in partially updated or corrupt configuration being downloaded to the outstation, or configuration changes not being flagged for download.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

  1. In the Database Bar, right-click on the required outstation.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can display it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

  2. Select the Download Configuration... option.
    The Download Configuration dialog box is displayed.
  3. Use the Download combo box to choose whether to download:
  • All Configuration—The complete configuration for that outstation and its associated components, is downloaded.
  • Changed Configuration Only—Only those configuration changes made to the outstation or its components since the last download, are sent to the outstation. This option is only available when supported by the driver and when such an option is applicable.
  4. Select the OK button to confirm the request.
    The specified configuration is downloaded to the outstation.


Core Point Configuration Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Core Point Configuration Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Core Point Configuration Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Core Point Configuration Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Core Point Configuration Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Core Point Configuration Guide - Document Scope (About the Guide)

Document Scope

This guide explains:

  • The types of point and pulse action that are supported by ClearSCADA
  • How to add and configure points and pulse actions in the ClearSCADA database
  • The configuration properties that are common to many types of point.

For more information, see Introduction to Points.

NOTE: When configuring points or pulse actions associated with a particular driver, use this guide in conjunction with the relevant driver-specific guide.


Core Point Configuration Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for engineers who are responsible for configuring points or pulse actions in the ClearSCADA database.


Core Point Configuration Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Core Point Configuration Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Logic

ClearSCADA Guide to Trends

ClearSCADA Guide to Lists

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Security

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


Core Point Configuration Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Core Point Configuration Guide - Introduction to Points

Introduction to Points

The ClearSCADA system uses Points to represent the measuring instruments and control devices on your system. For each measuring instrument or control device on your system, you need to add and configure a corresponding Point of the appropriate type in the ClearSCADA database (see Types of Point used in ClearSCADA and see Configuring a Point). Points allow the corresponding plant to be measured or controlled from the ClearSCADA server.

Many drivers support both input points and output points. An input point receives its value from the corresponding measuring instrument on your system. The outstation, PLC, data logger, or other device to which the instrument is attached reports its value to the ClearSCADA server, which uses the input data to update the values in the ClearSCADA database.

An output point is used to control a device on your system. An operator or engineer sends a control from the ClearSCADA server to the outstation, PLC, or scanner. From there, the control is sent to the control device. A maintained control, sent via a digital output point, changes the state of plant until another control is sent to further alter the state. A pulsed control, sent via a pulse action, changes the state of plant for a defined period of time.

NOTE: Internal points differ from other points in that they do not physically exist on your system—they only exist within the master station software (see Internal Points).

This guide provides information on how to configure the analog point, digital point, counter point, string point, time point, and pulse action details on both simple and advanced drivers (see Types of Point used in ClearSCADA). It also includes sections on:

  • Defining Historic Details for a Point
  • Promoting Scanning of Outstations Associated with Controls
  • Multiple Point State Alarms.

Many points also have configuration that differs, depending on the type of driver. For information on such configuration, see the driver-specific documentation.

Some drivers support other types of point. Configuration of these points is covered in the driver-specific documentation. Many of these points have analog-, counter- or digital-type processing, and therefore many aspects of configuration explained in this guide also apply to these point types. The driver-specific documentation indicates when another point type has analog-, counter- or digital-type configuration.


Core Point Configuration Guide - Types of Point used in ClearSCADA (Introduction to Points)

Types of Point used in ClearSCADA

The type(s) of point that you configure in ClearSCADA varies, depending whether you want ClearSCADA to monitor a device using an input point, or control a device using an output point (for a maintained control) or pulse action (for a pulsed control).

The type of input or output point that you need to configure is determined by:

  • The type of data being used by the devices on your system—for this data, you configure a driver-specific point that represents the type of data used on those devices (for instance, analog, or digital). The type(s) of point that are supported by each driver differ, depending on the driver—see the driver-specific documentation for the type(s) of point that a particular driver supports. Use the driver-specific documentation alongside this ClearSCADA Guide to Core Point Configuration for detailed information on how to configure the points that you require.
  • The type of data that is to be stored or used internally at the server, for instance, to store results from Historic Calculations or Logic programs—for this data, you configure internal point(s) that represent the type of data you want to use (for instance, analog, or digital). Internal points differ from other points in that they do not physically exist on your system—they only exist within the master station software (see Internal Points).

This guide explains how to configure point properties that are common to internal points and to points on many drivers. Many points on drivers have additional properties that are specific to the driver or type of point—these properties are covered in the driver-specific documentation. To configure a point on a driver, we recommend that you refer initially to the driver-specific documentation, as this explains both the driver-specific point properties and refers back to this core guide for those properties that are common to points on many drivers.

This ClearSCADA Guide to Core Point Configuration explains how to configure properties for the following types of point:

  • Analog Point—A point used in ClearSCADA to represent data that can be in any of a range of values (see Defining Analog Point Details).
  • Digital Point—A point used in ClearSCADA to represent data that can be in any of a range of states. For instance, Open or Closed, On or Off (see Defining Digital Point Details).
  • Counter Point—A point used in ClearSCADA to accumulate values over time (see Defining Counter Point Details).
  • String Point—A point used in ClearSCADA to represent data that has a textual string value, rather than a numeric value (see Defining String Point Details).
  • Time Point—A point used in ClearSCADA to represent data that has a date/time value (see Defining Time Point Details).
  • Pulse Action—Used to send a control to a device for a defined period of time (see Defining Pulse Action Details).

Some drivers support other types of point. Configuration of these points is covered in the driver-specific documentation. Many of these points have analog-, counter- or digital-type processing, and therefore many aspects of configuration explained in this guide also apply to these point types. The driver-specific documentation indicates when another point type has analog-, counter- or digital-type configuration.

Points that derive their value from other points are called Derived Points.


Core Point Configuration Guide - Internal Points (Introduction to Points)

Internal Points

An Internal point is a point that only exists within the master station database—it does not physically exist on the system and is not associated with plant. ClearSCADA supports four types of Internal point:

  • Internal Analog point—A point that can be in one of a range of numeric values.
  • Internal Digital point—A 1-, 2-, or 3-bit point that can be in one of several fixed states.
  • Internal String point—A point that has a text string value, rather than a numeric value.
  • Internal Time point—A point that has a date/time value.

ClearSCADA can use Internal points to store data at the server—for instance, to store the resultant data from Historic Calculations, or to store calculation results or apply values to equations within Logic programs. You can also use Internal points to test Logic, simulate plant, or produce prototype designs.

Example:

You might write a Logic program that triggers a series of actions should a reservoir reach a particular level.

In order to test out the Logic and check that the necessary actions occur in the right order and have the desired effect, you might create Internal points on your system to simulate a reservoir reaching the crucial level.

By using such Internal points in the Logic program, you can test out the program without affecting the actual plant, and once satisfied that the Logic executes correctly, you can apply the program to the actual points that are associated with the reservoir.

NOTE: Within Logic programs it is often sufficient to use Variables rather than Internal points. However, Internal points have to be used if the Logic is to provide the additional processing that is associated with points, such as alarm features or historic storage of point values.

The Hand Control pick action enables users to manually set an Internal point’s value. This can be used, for instance, to manually set the value of an Internal point that is being used to simulate plant or test a Logic program. The Hand Control pick action should be disabled if an Internal point value is being set automatically, to stop users from manually hand controlling the point value.

Where a data access application or Logic program sets an Internal point’s value automatically, the application sets the point’s CurrentValue or CurrentState property directly. (The CurrentState property applies to Internal digital points.)

Whenever an Internal point’s CurrentValue or CurrentState property is set directly, ClearSCADA time stamps that value or state with a time of NOW and a Quality of Good, by default. If required, you can force ClearSCADA to time stamp the point value or state with a different time and quality by setting the Internal point’s PresetTimestamp and PresetQuality properties. When the Preset properties are set, ClearSCADA uses the values of those properties to update the point’s CurrentTimestamp and CurrentQuality properties, rather than the defaults of NOW and Good. ClearSCADA also applies the values of the Preset properties to any historic records that it generates.

For ClearSCADA to use the PresetTimestamp and PresetQuality properties when updating an Internal point’s value or state:

  • When using automation, write to the PresetQuality and PresetTimestamp properties before the point’s CurrentValue or CurrentState properties.
  • When using a Logic program, declare the PresetQuality and PresetTimestamp properties before the CurrentValue or CurrentState properties.

Example:

PROGRAM NewStructuredTextProgram
VAR
TS AT %M(.P.PresetTimestamp) : DATE_AND_TIME;
Q AT %M(.P.PresetQuality) : INT;
V AT %M(.P.CurrentValue) : LREAL;
END_VAR;
V := V + 5;
TS := DT#2010-03-02-12:40:00;
Q := 10;
END_PROGRAM

In each case, the PresetQuality and PresetTimestamp properties clear whenever the Internal point’s CurrentValue or CurrentState updates. As such, ClearSCADA will only use the Preset properties for the first point update, unless the Preset properties are written to again. If the Preset properties are not set when the point next updates, ClearSCADA will set the point’s CurrentTimestamp to the present time (rather than any offset that may be required) and the point’s CurrentQuality to Good.

You can specify whether ClearSCADA is to log an event each time that an Internal point’s value is set. Where a data access application or Logic program sets the point’s value, the Severity specified for that application is taken into account if the Log Hand Control Events check box is selected for a point.

Example:

If an Internal point’s Log Hand Control Events check box is selected, but the Severity for the Logic program that sets the point’s value is set to ‘None’, ClearSCADA will not log any events to indicate when the point’s value changes.

The Severity that is specified for the application that is setting an Internal point’s value affects whether the action is logged in the Event Journal, and the severity with which it is logged. (In this example, the Logic Program that sets an Internal point’s value has a Severity of ‘None’, so no events will be logged.)

ATTENTION: Ensure that an Internal point’s Log Hand Control Events check box is clear if an application sets the point’s value on a frequent basis. This is to help prevent the Event Journal from containing numerous events relating to the point’s value being set.

Further Information

Logic Programs: see the ClearSCADA Guide to Logic.

Using Variables: see Using Variables to Store Data Values in the ClearSCADA Guide to Core Configuration.

Historic Calculations: see Configuring Historic Calculations in the ClearSCADA Guide to Core Configuration.

Configuring Internal Analog Points: see Defining Analog Point Details.

Configuring Internal Digital Points: see Defining Digital Point Details.

Configuring Internal String Points: see Defining String Point Details.

Configuring Internal Time Points: see Defining Time Point Details.


Core Point Configuration Guide - Derived Points (Introduction to Points)

Derived Points

A derived point obtains its value from another point, by performing a calculation on the other point’s value. The point from which the derived point obtains its value is known as its parent point.

When configuring a derived point in ClearSCADA, some of the derived point’s configuration is typically inherited from its parent point. In order for the derived point to inherit such configuration, you need to use the relevant field to specify the name of that derived point’s parent point. The inherited configuration is displayed the next time that the configuration is saved.


Core Point Configuration Guide - Configuring a Point

Configuring a Point

For each measuring instrument or control device on your system, you need to create and configure a corresponding Point of the appropriate type within the ClearSCADA database (see Types of Point used in ClearSCADA). The point configuration allows the corresponding plant to be measured or controlled from the ClearSCADA server. It also allows you to define how that point data is displayed and used within ClearSCADA. For instance, whether the raw value is scaled for use within ClearSCADA, and whether ClearSCADA logs an event or raises an alarm if the point goes into a particular state.

To create and configure a point in the database, you need to be logged on via a User Account that has the Configure Database feature enabled, and has the relevant permissions (see Creating a User Account, in the ClearSCADA Guide to Security). You also need to have carried out any necessary Preparation, to enable you to configure the point(s) successfully in the database.

You configure each point by entering data into fields on a Point Form. The fields on the Form vary, depending on the type of point, and the driver with which it is associated.

Within ClearSCADA:

  • You can configure each point independently to other points on your system (for instance, create and configure one Modbus digital point, and then create and configure another Modbus digital point).
  • You can configure Internal Points that exist only within the master station software and can be used by ClearSCADA to store data at the server, for instance, for use within Logic programs. Such points are not associated with any physical devices on your system (see Internal Points).
  • If the physical structure of your system can be split into ‘modules’, you may want to consider using Group Templates to produce the base configuration for a generic ‘module’. Within the Templates, you can create driver-specific points, internal points and/or Abstract Points that have the base configuration for the points in each module.

You can then use Group Instances to include the configuration that is specific to each ‘module’ and convert the Abstract points into specific point types (for instance, an Abstract Simple Analog Point into a Modbus Analog Point).

Regardless of the type of point that you want to configure, you use the same basic procedure for creating and configuring the point (see Create and Configure a Point).

Further Information

Types of Point used in ClearSCADA.

Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration.

Abstract Item in the ClearSCADA Guide to Core Configuration.


Core Point Configuration Guide - Preparation (Configuring a Point)

Preparation

You typically add and configure points in ClearSCADA once the outstation, PLC, scanner, or other device on which the point is located, has been created and configured in the database. This is because the point configuration typically requires you to select the name of that item on the Point Form. For information on the order in which you should configure items in the ClearSCADA database, see the driver-specific documentation, and the ClearSCADA Guide to Advanced Drivers or the ClearSCADA Guide to Simple Drivers, as appropriate.

When you configure points in the database, many of the settings for those points need to correspond to the settings of the relevant measuring instruments or control devices on your system. Some settings are either fixed (incorporated into the design of the device), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the devices on your system before you can configure the database points successfully.

You also need to be aware of the importance of each control device and measuring instrument in relation to other items on your system, so that you can assign appropriate severity levels for any alarms and events that are raised or logged for those devices.

If using Group Templates, Instances, and Abstract points, you need to be aware of which of the above are common to many of the ‘modules’ on your system, and which are specific to individual modules so that you can configure the Abstract points accordingly.


Core Point Configuration Guide - Create and Configure a Point (Configuring a Point)

Create and Configure a Point

This section gives step-by-step procedures on how to:

  • Create a Point.
  • Configure a New or Existing Point.


Core Point Configuration Guide - Create a Point (Configuring a Point)

Create a Point

To create a point in the database, you need to be logged on via User Account that provides access to the relevant ViewX configuration features and has sufficient security permissions to create the required points (see Creating a User Account in the ClearSCADA Guide to Security).

To create a point in the ClearSCADA database:

  1. On the Database Bar, right-click on the Group, or Group Template within which you want to add a point.
    A context-sensitive menu is displayed.

(If the Database Bar is not displayed, select the View menu, and then select the Explorer Bar option, followed by the Database option.)

  2. Select the New option.
    A further menu is displayed.
    Right-click on the Group or Group Template within which you want to add a point...
    ...a context-sensitive menu is displayed. (The options on the menu vary, depending on the drivers on your system)
    ...select the New option...

  3. Select the menu option that is appropriate to the point you want to create:

To add a driver-specific point:

  1. Select the appropriate <Driver Name> option (for example, Modbus).
    A further context-sensitive menu is displayed.
  2. Select the type of point that you want to create (for example, Analog Point).

NOTE: With some drivers further sub-menu(s) are available. You might need to select the type of point you require from one of the sub-menus.

For information on the point types that are supported by particular drivers, see the driver-specific documentation.
A point of the selected type is added to the ClearSCADA database. The entry is highlighted, ready for you to define the point’s name.

  3. Give the point a suitable name (see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  4. Configure the point (see Configure a New or Existing Point).

To add an internal point (for example, for use in Logic programs):

  1. Select the Internal option.
    A further menu is displayed.
  2. Select the type of point that you want to create (for example, Analog Point).
    A point of the selected type is added to the ClearSCADA database. The entry is highlighted, ready for you to define the point’s name.
  3. Give the point a suitable name (see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  4. Configure the point (see Configure a New or Existing Point).

To add an abstract point:

(You can only create Abstract points within Group Templates. You cannot create Abstract points within Group Instances or ordinary Groups.)

  1. Select the Abstract option.
    A further menu is displayed.
  2. Select the type of point that you want to create:
  • For points on Simple drivers, select either ‘Point’ or one of the Simple point options (for example, Simple Analog Point).
  • For points on Advanced drivers, select either ‘Point’ or one of the Advanced point options (for example, Advanced Point (Current and Logged Data)).

For further information, see Types of Abstract Item in the ClearSCADA Guide to Core Configuration.

A point of the selected type is added to the ClearSCADA database. The entry is highlighted, ready for you to define the point’s name.

  3. Give the point a name that is not module-specific (also see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  4. Within the Template, configure the base (none module-specific) properties for the point (see Configure a New or Existing Point). Also ensure that appropriate configuration properties are enabled on the Point Forms, to allow module-specific properties to be configured within each Instance (see Define which Property Values Derive from a Group Template in the ClearSCADA Guide to Core Configuration).
  5. Within each Instance, configure the module-specific properties for the point (see Configure a New or Existing Point).


Core Point Configuration Guide - Configure a New or Existing Point (Configuring a Point)

Configure a New or Existing Point

To configure a point in the database, you need to be logged on as a user with the relevant privileges (see Creating a User Account in the ClearSCADA Guide to Security). You also need to ensure that any necessary Preparation has been undertaken.

You configure the properties of each point using the relevant Point Form. Each Form has several ‘tabs’ that you use to define different aspects of point configuration. As a minimum you have to define particular properties—such as the device with which the point is associated—in order to produce a functional point (see the relevant ‘Minimum Configuration’ section for details). In many cases, you only need to adjust some of the settings on the Form in order to achieve the required configuration.

If the Dictionary feature is used on your system, you can prefix the strings in some fields, in order for those strings to be replaced with other terms when displayed in a List or on a Mimic, in ViewX. For more information, see Dictionary Settings in the ClearSCADA Guide to Server Administration, and the field descriptions in the rest of this guide.

NOTE: If you are configuring an Abstract point, within the Template, you configure the base (none module-specific) properties for the point. Then within each Instance, you configure the module-specific properties for each point.

To configure a new or existing point:

  1. Double-click on the point entry in the Database Bar (if you are logged on via a User Account that has the Double Click Edits Documents feature enabled).
    The associated Form is displayed.
    Double-click on the point entry in the Database Bar...
    ...to display the Form for the point.

If your User Account does not have the Double Click Shows Properties feature enabled, double-clicking will display the Status display, rather than the Form for the item. In this case, you will need to use a context-sensitive menu to display the Form. For information on other ways to display a Form and on how to display the Database Bar, see Display a Form in the ClearSCADA Guide to Core Configuration.

  2. Define the Identification details (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  3. Define any User Methods that are required (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  4. Define the Alarm details (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  5. Define the Redirection details (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  6. Either:
  • Define the Analog Point details (see Defining Analog Point Details).

Or:

  • Define the Digital Point details (see Defining Digital Point Details).

Or:

  • Define the <Counter Type> Point details (see Defining Counter Point Details).

Or:

  • Define the String Point details (see Defining String Point Details).

Or:

  • Define the Time Point details (see Defining Time Point Details).

Or:

  • Define the details for a different point type (different drivers support different points—see the documentation for the relevant driver).
  7. If applicable, define the Historic details (see Defining Historic Details for a Point).
  8. Define the Driver specific details (please refer to the documentation for the relevant driver).
  9. Define the Control details of any Output points. See the section that is appropriate to the type of point that you are configuring:
  • Define the Control Settings for an Analog Output Point
  • Define the Control Settings for a Digital Output Point
  • Define the Control Settings for a String Point
  • Define the Control Settings for a Time Point
  • Defining Pulse Action Details.
  10. Define the Manual details of any Internal points. See the section that is appropriate to the type of Internal point that you are configuring:
  • Define the Manual Control Settings for an Internal Analog Point
  • Define the Manual Control Settings for an Internal Digital Point
  • Define the Manual Control Settings for an Internal String Point
  • Define the Manual Control Settings for an Internal Time Point.

For further information on configuring a driver-specific point, see the driver-specific documentation and the relevant point configuration section in this guide.

For further information on configuring an abstract or internal point, see the relevant configuration section within this guide.


Core Point Configuration Guide - Defining Analog Point Details

Defining Analog Point Details

Use Analog Points within the ClearSCADA database to represent measuring instruments or control devices that can be in any of a range of values. The raw input values received from the plant are scaled into engineering values or floating-point values, that the server can process. You then define the full range of values in which an analog point can reside, by using the Full Scale and Zero Scale limits on the Point Form. You use other state limits to represent the point when its value is within specific ranges. You can specify a suitable description for each of these states, and define whether an event is logged, or an alarm is raised upon entry into each state.

You configure each analog point on your system by using the fields on the appropriate Analog Point Form. Each Form has several tabs, which you use to define different aspects of the point configuration.

Use this section, along with the appropriate driver documentation, for information on configuring the analog points on your system.

This section explains how to configure analog point properties that are common to many analog points. Most of these properties are displayed on the Analog Point tab of the Analog Point Form (on some advanced drivers, these properties are displayed on a separate tab).

Analog Point tab

You can use the Analog Point tab to:

  • Configure the Limits for an Analog Point, including (if required):
  • Multiple Alarm Limits.
  • Use Hysteresis to Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm from clearing an alarm
  • Define how Over Range and Under Range Values are Processed
  • Define whether an Analog Point’s Limits can be Tuned
  • Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events. (Only applicable if the Area of Interest feature is enabled in ClearSCADA.)
  • Specify any Alarm Limit Profiles
  • Define the Appearance of an Analog Point’s Values
  • Define whether an Analog Point can be Overridden
  • Define the Criteria for a Significant Change in Value
  • Detect whether an Analog Point has Stopped Changing
  • Define an Analog Point’s Trend Settings.

Additionally, if the point is an analog output, you need to use the Control tab to:

  • Define the Analog Control Settings.

If the point in an internal analog point, you need to use the Manual tab to:

  • Define the Manual Control Settings for an Internal Analog Point.

(In addition to internal analog points, ClearSCADA also supports Variables. The type of database item that you add to ClearSCADA depends on that item’s intended functionality. For more information, see Variables in the ClearSCADA Guide to Core Configuration.)

In circumstances where the server uses separate alarm limits to the outstation, those limits are configured on the Master Station Alarm Limits tab of the Analog Point Form (see Master Station Alarm Limits).


Core Point Configuration Guide - Configure the Limits for an Analog Point (Defining Analog Point Details)

Configure the Limits for an Analog Point

You need to set the limits for each analog point so that when the value of the point drops below or rises above the normal range of values, a suitable alarm is raised or event is logged. The value of the point is retrieved from the outstation.

To configure the limits of an analog point, you need to access the Analog Point tab of the relevant type of Analog Point Form.

Columns for each configuration setting
Rows for each limit

The Alarm Limits section has a row of fields for each limit. The fields are arranged in columns, and are used for defining the configuration properties of each limit (see Procedure for Configuring an Analog Point’s Limits). The figure above shows the types of limit that are available for analog points on many drivers. Some analog points have different limits to those shown above (see Analog Points with Different Limits).

Zero Scale and Full Scale define the range of values (in engineering units) for a point. The values that you enter for these limits have to correspond with the raw scale of the point in the outstation. Most drivers use these values to scale the raw values that are reported by the outstation.

Example:

A raw scale of 0 to 4095 (12-bit) might be configured on the Point Form as:

Zero Scale = 0 (corresponding to the raw value 0)
Full Scale = 10 (corresponding to the raw value 4095).

Use the other Limit fields to define limits between the Zero Scale and Full Scale that indicate notable changes in operating condition of the plant. By default, the alarm limits are High High, High, Low, and Low Low for analog points on most drivers. You can specify whether a point passing one of these limits raises an event or an alarm. (With analog points on some drivers, you can optionally assign these limits to Time Profiles, to enable the limits’ values to change at different times of the day or week (see Specify any Alarm Limit Profiles).)

The Normal state defines the usual operating range for the plant. You can choose whether to log an event whenever the point to returns to this state. The Normal state operating range falls between those alarm limits that are immediately adjacent to the Normal state (typically the operating range that is between the High and Low alarm limits).

The range of limits forms a scale, as follows:

Example:

An analog point has this configuration:

Full Scale: 24 (Alarm)
High High: 22 (Alarm)
High: 20 (Event)
Normal
Low: 4 (Event)
Low Low: 2 (Alarm)
Zero Scale: 0 (Alarm).

The configuration indicates that the full operating range of the point is 0-24, but that the normal operating range is between 4 and 20.

From normal operating conditions, if the point value falls to 4 or below, an event is raised. If the value continues to drop to 2 or below, an alarm is raised. The existing alarm is replaced by another alarm should the point reach its lowest operating range of 0.

Similarly, from normal operating conditions, if the point value rises to 20 or above, an event is raised. If the value continues to rise to 22 or above, an alarm is raised. The existing alarm is replaced by another alarm if the point exceeds its maximum operating range of 24.

Alarms are cleared as the value returns to its normal operating range of between (but not including) 4 and 20. For instance, should the point value drop from 23 to below 22, the High-High alarm clears. If the value then drops below 20, the High alarm clears—the point has now returned to its normal operating range.


Core Point Configuration Guide - Analog Points with Different Limits (Defining Analog Point Details)

Analog Points with Different Limits

Some analog points have different types of alarm limit to those explained in this guide. The Procedure for Configuring an Analog Point’s Limits is very similar, regardless of the type of limit. The driver guides explain any limits that are driver-specific.

Analog points can also be configured to:

  • Have two sets of alarm limits (see Multiple Alarm Limits)
  • Use a separate set of limits at the server (see Master Station Alarm Limits)
  • Have Multiple Point State Alarms (in which case an additional Alarm column is displayed in the Alarm Limits section of the Point Form).


Core Point Configuration Guide - Procedure for Configuring an Analog Point's Limits (Defining Analog Point Details)

Procedure for Configuring an Analog Point’s Limits

To Configure the Limits for an Analog Point:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Analog Point tab.
    (If you are configuring the limits for another point that uses analog-type processing, select the appropriately named <Point Type> tab. If you are configuring separate server-based limits, select the Master Station Alarm Limits tab.)
  3. Highlight the relevant Limit field. For example, if you are configuring the Full Scale, select the Limit field for the Full Scale row.
  4. Enter the required value. When you enter the value, you need to consider the requirements at the site. For example, if the analog point represents a thermometer, the point limits need to correspond to low/normal/high temperatures for the specific area of plant.

NOTE: With analog points on some drivers, you can optionally assign each limit to a Time Profile, to enable the limit’s value to change at different times of the day or week (see Specify any Alarm Limit Profiles). Whenever a limit is assigned a Time Profile, the Limit field within the Alarm Limits section of the Analog Point tab is ‘grayed out’. You still use the rest of the fields within the Alarm Limits section to specify other properties for the limit (such as the Severity, Description, or Color).

  5. Use the left-hand Severity combo box next to the Limit field to define what happens when the analog point’s value exceeds the limit (or for a limit below the Normal state, drops below the limit):
    Use the left-hand Severity combo box to determine what happens when the point value exceeds the limit.

  • None—ClearSCADA does not generate an alarm or event.
  • Alarm—ClearSCADA generates an alarm. The alarm has the severity level that you select in step 6.
  • Event—ClearSCADA generates an event. The event has the severity level that you select in step 6.

If you selected the Alarm or Event options, proceed to step 6.

If you selected the None option, proceed to step 7.

  6. Use the right-hand Severity combo box next to the Limit field to define the level of importance associated with the event or alarm.
    Use the right-hand Severity combo box to define the importance of the alarm or event.

A set of severity levels are provided for each ClearSCADA system (see Defining Severities in the ClearSCADA Guide to Core Configuration). Choose the appropriate severity level from the list available on your system.

NOTE: If any of the analog points on your system have Multiple Point State Alarms configured, an additional Alarm column is displayed to the left of the Description combo box. For information on specifying multiple Alarm Conditions, see Multiple Point State Alarms.

  7. Use the Description combo box to enter or select a suitable description of the limit.

You can either highlight the existing description and replace it with a new one, or you can choose one of the available descriptions from the combo box list. There are default descriptions for each limit, but these can be replaced by user-defined descriptions that are more specific to the points on your system (see Define Descriptions for Numeric Point States in the ClearSCADA Guide to Server Administration).

Usually, the Description describes the state of the plant or conditions at the site. For example, with an analog point that represents a sensor at a reservoir, the description for a High-High limit might be ‘Flooding’. The description provides extra information to operators so that they have a better understanding of what the High-High limit represents.

If the Dictionary feature is used on your system, you can prefix the string in Description field, in order for that string to be replaced with another term, when displayed in a List or on a Mimic, in ViewX. For more information, see Dictionary Settings in the ClearSCADA Guide to Server Administration.

By default, point states are shown in black text on displays such as Lists, unless:

  • The point is in an alarm state (in which case the text is displayed in the corresponding severity color)
  • Another status, such as an Override, takes precedence over a non-alarm state (in which case the text is displayed in the color that indicates that status).

NOTE: You can change the color that your system uses for the ‘Normal’ state (black by default), using the Color Palette (see Use the Color Palette to Define a Custom System Color in the ClearSCADA Guide to Core Configuration).

If you want to associate a state with a custom color when neither of the above situations is in effect, proceed to step 8.

If you want the state to use the default color to indicate a ‘Normal’ state (black by default), proceed to step 10.

  8. You can only associate a limit with a custom color if you have pre-configured custom colors available (see Defining a Custom State Color in the ClearSCADA Guide to Core Configuration). To use the Color field to associate the limit with a custom color:
  1. Select the browse button next to the Color field for the limit you are configuring.
    A Reference browse window is displayed.
  2. Use the Reference browse window to locate the required custom color.
  3. Select the custom color.
  4. Select the OK button.
    The Reference browse window is closed and the name of the selected color is shown in the Color field. When the point enters this state, its value will be shown in the custom color.
  9. Repeat steps 3-8 inclusive for each limit.
  10. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

NOTE: If the Area of Interest feature is enabled on your system, also ensure that you Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events.


Core Point Configuration Guide - Multiple Alarm Limits (Defining Analog Point Details)

Multiple Alarm Limits

Normally, analog points have one set of alarm limits that you use to define which point values correspond to alarm conditions (see Configure the Limits for an Analog Point).

However, you can configure the points on your system so that they can use one of two sets of alarm limits. So, for example, points can have different sets of alarm limits, depending on seasonal variations.

Use two sets of alarm limits if there are known occasions when the points on your system require different limits.

Multiple alarm limits are not enabled by default—if you require the analog points on your system to have two sets of alarm limits, you have to enable this feature on each server on your system (see Set Up Multiple Alarm Limits in the ClearSCADA Guide to Server Administration).

Once configured, you can change which sets of alarms are in effect on a group by group basis (see Switch Between Multiple Alarm Limits in the ClearSCADA Guide to Server Administration).

NOTE: The limits on some analog points can optionally be assigned Time Profiles, to enable the limits’ values to alter in line with the Time Profiles’ change in value (see Specify any Alarm Limit Profiles). When a limit is assigned a Time Profile, ClearSCADA ignores the configuration in both sets of alarm limit fields for that particular limit (both limit fields in the Alarm Limits section of the tab are ‘grayed out’). You still use the rest of the fields within the Alarm Limits section to specify other properties for those limits (such as the Severity, Description, or Color).


Core Point Configuration Guide - Master Station Alarm Limits (Defining Analog Point Details)

Master Station Alarm Limits

Normally, analog points have one set of alarm limits that you use to define which point values or states correspond to alarm conditions (see Configure the Limits for an Analog Point). These ‘standard’ limits are configured on the Analog Point tab and are typically downloaded to the outstation (depending on the driver). The current state of the point is determined by the outstation, and, if the point is on a PSTN outstation, the limits are used to trigger the outstation to dial in to the server when an alarm situation occurs.

You can, however, configure the analog points on your system so that the ClearSCADA server uses a separate set of alarm limits to the outstation’s alarm limits. These alarm limits are known as Master Station Alarm Limits, and by default are not available.

To use master station alarm limits, you have to enable the Analog Point Alarm Limits feature on the Alarm Limits section of the ClearSCADA Server Configuration Tool (see Setup Master Station Analog Point Alarm Limits the ClearSCADA Guide to Server Administration).

Once enabled, an additional Master Station Alarm Limits tab becomes available on the Analog Point Forms on your system.

On this tab, you can define up to 18 alarm limits for the server to use instead of the limits on the Analog Point tab. Full Scale and Zero Scales limits are also displayed—these two limits are not configurable from this tab, but are displayed for reference only. The Full Scale and Zero Scale settings are the same as those defined on the Analog Point tab. Master Station Alarm limits are not downloaded to the outstation, but are used in place of the ‘standard’ alarm limits to raise and clear alarms at the server.

When Master Station Alarm Limits are used, the ‘Master Station’ state is displayed in the Alarm Banner, Alarms List, the Points List, and (if Historic is enabled for the point) the Historic List. You can also check the Current M/S State in the Status display, accessed via the View Status pick action.

Whenever Master Station states are included on a display, these will show the ‘standard’ states for those points for which Master Station Alarm Limits are not enabled.

Example:

In the Points List, the 'State' column shows the description of the current Master Station state of those points on which Master Station Alarm Limits are enabled.

The ‘State’ column shows the 'standard' state description for those points on which Master Station Alarm Limits are not enabled.

As the CDBPoint table includes separate fields for ‘standard’ and Master Station states when the Analog Point Alarm Limits feature is enabled on the Alarm Limits section of the ClearSCADA Server Configuration Tool, you can, for example, include either, or both, states in any Mimics or custom Lists.

The specific fields are:

  • CurrentMSStateDesc—The description of the current Master Station state.
  • CurrentStateDesc—The description of the current ‘standard’ state.
  • CurrentMSStateColour—The color associated with the current Master Station state.
  • CurrentStateColour—The color associated with the current ‘standard’ state.
  • CurrentMSStateBlink—Indicates whether the color associated with the current Master Station state is flashing.
  • CurrentStateBlink—Indicates whether the color associated with the current ‘standard’ state is flashing.

In each case, if Master Station Alarm Limits are not enabled on a particular point, the 'CurrentMS...' fields return the same values as the corresponding 'standard' fields.

For more information about any of the above fields, see the Database Schema.

Further Information

Procedure for Configuring Master Station Alarm Limits.


Core Point Configuration Guide - Procedure for Configuring Master Station Alarm Limits (Defining Analog Point Details)

Procedure for Configuring Master Station Alarm Limits

To configure master station alarm limits for an analog point:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Master Station Alarm Limits tab.
    (The tab is only available if the Analog Point Alarm Limits feature is enabled on the server (see Setup Master Station Analog Point Alarm Limits the ClearSCADA Guide to Server Administration).)
  3. Select the Enabled check box.
    Other fields on the tab become available for use.
  4. Use the Number of High Limits combo box to define how many of the alarm limits are above the normal state of the point.
    Alarms for each of these limits will be raised when the point value reaches or rises above the value that you enter in the corresponding Limit field.
  5. Use the Number of Low Limits combo box to define how many of the alarm limits are below the normal state of the point.
    Alarms for each of these limits will be raised when the point value reaches or drops below the value that you enter in the corresponding Limit field.

You can specify up to a total of 18 limits to be either High or Low limits. (Full Scale and Zero Scale limits are displayed for reference—the settings for these two limits are configured on the Analog Point tab.)

Example:

One analog point has 12 High Limits and 6 Low Limits.

Another analog point has 5 High Limits and 5 Low Limits, leaving the remaining 8 limits unused.

  6. Starting with Limit 1, configure each of the High limits that you are using for the point, entering the highest limit first, followed by decreasing High limits.

For information on configuring limits, see Configure the Limits for an Analog Point.

  7. Following immediately on from the last High limit, configure each of the Low limits that you are using for the point. Start with the Low limit that is nearest in value to the Normal state of the point (the Low limit that has the highest value), followed by decreasing Low limits.

Ensure that you enter the point limits consecutively, from the High limit with the highest value to the Low limit with the lowest value.

If you are not using all 18 limits, ensure that any limits that you leave unconfigured only appear after all of the High and Low limits that you are using for the point (see the example, below).

ClearSCADA deems the range of the Normal state to fall between the lowest value entered in any High Limit field, and the highest value entered in any Low Limit field.

  8. Define any Severity properties and the Description that you require for the Normal point state.
  9. Define any Hysteresis for the limits (see Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm).
  10. Define whether the Master Station Alarm Limits can be tuned (see Define whether an Analog Point’s Limits can be Tuned).
  11. If supported by the driver, used the Engineering Units Exceeded check box to Define how Over Range and Under Range Values are Processed.
  12. If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Master Station Alarm Limits tab. Use the field to specify the area with which any state-related master station alarms or events are to be associated (see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events).
  13. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Example:

An analog point has a full range of 0 to 100. Its value is normally expected to be in the region 15 to 75. The server is required to raise an alarm whenever the value rises above 75, 80, 85, 90, or 95, or the full range of 100. The server is also required to raise an alarm if the value drops below 15, 10, 5, or its lowest range of 0.

The Zero and Full Scale of 0 and 100 are configured on the Analog Point tab.

The Master Station Alarm Limits for the point are enabled and configured on the Master Station Alarm Limits tab as follows:

Number of High Limits = 5
Number of Low Limits = 3
Limit 1 = 95
Limit 2 = 90
Limit 3 = 85
Limit 4 = 80
Limit 5 = 75
Limit 6 = 15
Limit 7 = 10
Limit 8 = 5
Limit 9 to 18 are left unconfigured.

As the number of High limits is 5, the High limit closest to the point’s Normal state is Limit 5.

The Low limit closest to the point’s Normal state is configured as Limit 6 (the first limit following on from the five High limits).

The range for the Normal state of the point is therefore between the values of 75 and 15.

As the number of High limits is 5 and Low limits is 3, limits 9 onwards are deemed unused, and ClearSCADA ignores any settings within them.


Core Point Configuration Guide - Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm (Defining Analog Point Details)

Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm

The Hysteresis feature allows you to define the amount by which an analog point’s value has to decrease below a high limit, or increase above a low limit, for an alarm to be cleared. This helps to ensure that an analog point’s alarms are not continuously raised then cleared if its value fluctuates around an alarm limit.

The Hysteresis field is displayed within the Alarm Limits section, typically on the Analog Point tab of the Analog Point Form.

To define the Hysteresis amount:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Analog Point tab.
    (If you are configuring the hysteresis for another point that uses analog-type processing, select the appropriately named <Point Type> tab. If you are configuring a separate server-based hysteresis, select the Master Station Alarm Limits tab.)
  3. Enter the Hysteresis amount in the Hysteresis field.
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Example:

The High limit of an analog point is defined as 50.
The Hysteresis for the analog point is defined as 5.

The value of the analog point changes from 48 (Normal) to 51 (High). An alarm is raised.

The value of the analog point changes from 51(High) to 49 (Normal). Although the value has re-entered the Normal range of limits, the alarm is not cleared, as the point value has not decreased by the Hysteresis amount. The alarm will only clear when the point value changes to 45 or lower, as 50 - 5 (limit minus hysteresis) = 45.


Core Point Configuration Guide - Define how Over Range and Under Range Values are Processed (Defining Analog Point Details)

Define how Over Range and Under Range Values are Processed

If supported by the drivers on your system, you can use the Engineering Units Exceeded combo box to define how ClearSCADA processes an analog point’s value when the value is Over range (exceeds the Full Scale limit) or Under range (drops below the Zero Scale limit). For information on the limits, see Configure the Limits for an Analog Point.

Where supported, the Engineering Units Exceeded combo box is displayed on the Analog Point tab of the Analog Point Form.

The Engineering Units Exceeded feature provides flexibility, so that you can choose how to handle over range and under range values in the way that suits your needs. For example, you may need to force any Over range values to show the Full Scale value, so that the value is compatible with another application.

To define how the point value is processed when it exceeds the defined engineering units:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Analog Point tab.
    (If you are configuring this feature for another point that uses analog-type processing, select the appropriately named <Point Type> tab.)
  3. Use the Engineering Units Exceeded combo-box to choose:
  • Use Last Value—ClearSCADA uses the last point value that was between the Underrange and Overrange limits, and discards the reported value.
  • Use Limit Value—ClearSCADA uses the Full Scale value if the point value exceeds the Full Scale, and uses the Zero Scale value if the point value drops below the Zero Scale. In other words, it limits the values to Full Scale or Zero Scale respectively.
  • Use Reported Value—ClearSCADA uses the actual value, even if it is higher than the Full Scale or lower than the Zero Scale.
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define whether an Analog Point's Limits can be Tuned (Defining Analog Point Details)

Define whether an Analog Point’s Limits can be Tuned

Many analog points support limit tuning. When supported, you can use the Tune Limits check box to define whether operators can tune a point’s alarm limits.

Tuning allows operators whose User Accounts are allocated the Tune Limits permission (see Allocating Security Permissions in the ClearSCADA Guide to Security) to temporarily alter the point’s alarm limits, using the Tune Alarm Limits pick action. (Unless those limits are assigned Time Profiles—you cannot tune any limits that vary in value according to Time Profiles (see Specify any Alarm Limit Profiles).)

Use the feature to tune alarm limits during exceptional circumstances, for example, in bad weather conditions when a flood situation is known to exist—the alarm limits of a point can be tuned to help prevent unnecessary alarms being raised.

Example:

An error detected on some monitoring equipment is giving inaccurate readings for a particular analog point. As engineers are aware of the situation, there is no need to raise alarms, unless the point value changes unexpectedly or raises a genuine alarm.

To avoid unnecessary alarms being raised for the point, the alarm limits are tuned so that ClearSCADA ignores the inaccurate readings.

Once the equipment has been repaired, the tuning is revoked.

ATTENTION: With points on outstations that support configuration downloads, the action of tuning a point’s limits triggers ClearSCADA to download configuration to the outstation on which that point is located (see Downloading Configuration Changes in the ClearSCADA Guide to Core Configuration).

If you choose not to allow the Tune Limits feature to be used, the alarm limits configured on the Point Form remain in force.

To define whether a point’s limits can be tuned:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Analog Point tab.
    (If you are configuring this feature for another point that uses analog-type processing, select the appropriately named <Point Type> tab. If you are configuring separate server-based limit tuning, select the Master Station Alarm Limits tab.)
  3. Either:
  1. Clear the Tune Limits check box if users are not permitted to tune the point’s limits.
    The alarm limits configured on the Point Form will be used by ClearSCADA, and cannot be temporarily overridden.

Or:

  1. Select the Tune Limits check box to allow the analog point’s limits to be tuned.
  2. Ensure that the point’s Tune Limits security permission is suitably set (see Allocating Security Permissions in the ClearSCADA Guide to Security).

Users with the Tune Limits security permission will be able to use the Tune Alarm Limits pick action to temporarily alter the point’s alarm limits.

(If the analog points on your system use Master Station Alarm Limits, and tuning is enabled for those limits, use the Tune M/S Alarm Limits pick action to tune the ‘master station’ limits.)

  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Specify the Area of Interest Associated with a Point's State-Related Alarms and Events (Defining Analog Point Details)

Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events

If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed within the Alarm Limits section on the Analog Point tab.

An Area of Interest field is displayed if the Area of Interest feature is enabled on your system.

Use the Area of Interest field to specify the area with which any state-related point alarms or events are to be associated.

If a point value exceeds a limit that is configured to generate an event or alarm, that event or alarm will be associated with this Area of Interest. As such, only users that have access to this Area of Interest will be aware of the event or alarm.

For more information on configuring Areas of Interest, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

For information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

NOTE: If the Multiple Point State Alarms feature is used to assign multiple ‘Point State’ alarm conditions to an analog point, a separate Area of Interest section is displayed on the <Analog Point> tab. The section contains multiple Area of Interest fields—one for the ‘Normal’ state and one for each ‘Point State’ alarm condition (see Use Multiple Point State Alarms in Conjunction with Areas of Interest).


Core Point Configuration Guide - Specify any Alarm Limit Profiles (Defining Analog Point Details)

Specify any Alarm Limit Profiles

If supported by the drivers on your system, you can optionally configure any of an analog point’s limit values (typically High High, High, Low, and Low Low) to change at different times of the day or week.

To do this, you assign a Time Profile to the relevant limit(s), using fields within the Alarm Limit Profiles section of the Analog Point tab:

For each limit for which the value is to alter, select that limit’s browse button. A Reference browse window is displayed. Select the required Time Profile from the window. The specified Time Profile:

  • Must be of the appropriate type (for instance, a Double Time Profile, containing IEEE double-precision floating point 64-bit values)
  • Must not cross any of the point’s fixed limits
  • Must not cross over any other Time Profiles that are assigned to the point
  • Must use a compatible scale (for instance, an inverted scale if the point uses such a scale (a point that has an inverted scale has a Full Scale that is less than its Zero Scale)).

Be aware that editing a Time Profile that is already assigned to an analog point might invalidate one or more of the above rules.

You should also ensure that the Time Profile is configured to use a suitable Time Zone (for instance, ‘Local Time with Daylight Saving Time’, for a Time Profile that changes a point’s limits during working hours).

Diagnostic message(s) will indicate if a Time Profile’s configuration conflicts with the point’s configuration:

Invalid configuration messages will indicate if a Time Profile’s configuration conflicts with that of the point with which it is associated. (For instance, if the profile’s value exceeds that of another alarm limit.)

When a Time Profile is specified for a limit, the corresponding Limit field in the Alarm Limits section of the tab is ‘grayed out’ and unavailable for use. ClearSCADA ignores any configuration in this ‘grayed out’ field and instead uses the Time Profile to ascertain the limit’s value at any given time. You still use the Severity, Description, and Color fields adjacent to the ‘grayed out’ Limit field, to specify the rest of the limit’s properties (see Configure the Limits for an Analog Point).

The Limit field within the Alarm Limits section of the Analog Point tab is ‘grayed out’...
...if a Time Profile is assigned to that limit.

Whenever the point’s data is displayed as a Current Trend or Historic Trend, any Time Profiles that are assigned to the point are displayed on the Trend instead of the alarm limits that they replace.

Be aware that you cannot tune any limits that are assigned Time Profiles. (Such limits are not displayed in the Tune Alarm Limits window when the Tune Alarm Limits action is selected.)

For any limit(s) that are to remain fixed, ensure that the corresponding field(s) within the Alarm Limit Profiles section of the Analog Point tab are left blank. For such limits, ClearSCADA processes the point’s data using the values that are specified for those limits in the Alarm Limits section of the tab.

Example:

The High High limit of a particular analog point is assigned to a Daily Time Profile. The Time Profile’s value determines the value of that limit at any particular time throughout the day.

In this example, the High High limit is set to 95 until midday, whereupon the value rises. The Time Profile’s trace shows that the limit’s peak value of 98 occurs during 18:00 to 21:00, after which the value gradually falls back to 95.

Assign a limit to a Time Profile...
...to enable the limit’s value to alter in line with that Time Profile’s trace.

Further Information

Configuring Time Profiles in the ClearSCADA Guide to Core Configuration.

Produce a Profile Based on Historic Data in the ClearSCADA Guide to Core Configuration.


Core Point Configuration Guide - Define the Appearance of an Analog Point's Values (Defining Analog Point Details)

Define the Appearance of an Analog Point’s Values

You can use the Formatting section on an Analog Point Form to define the appearance of an analog point’s values. The Formatting section is displayed on the Analog Point tab.

The Units and Format that you configure will determine how the point’s value is shown on displays such as Lists, Mimics, Reports, and external applications. The format will help operators and other users to understand the significance of the point’s values.

To define the format of an analog point’s values:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Analog Point tab.
    (If you are configuring formatting for another point that uses analog-type processing, select the appropriately named <Point Type> tab.)
  3. Use the Units combo box to enter or select a type of measurement. The Units combo box is located in the Formatting section.

You can either highlight the existing entry and overwrite it with a new type of measurement, or you can choose a measurement from the units list (display the list using the arrow button).

The list of measurements can be customized for your system (see Define Standard Descriptions for Measurement Units in the ClearSCADA Guide to Server Administration).

  4. Select the browse button next to the Format field.
    The Text Format window is displayed.
  5. Use the Text Format window to choose and define the required type of formatting. For more information, see Choose a Format Category in the ClearSCADA Guide to Core Configuration.
  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define whether an Analog Point can be Overridden (Defining Analog Point Details)

Define whether an Analog Point can be Overridden

You can use the Analog Point Form to define whether a point’s value can be overridden. You can also define the range of valid override values.

The Override action allows users whose User Accounts are allocated the Override/Release security permission to define the value of that point. The override feature is useful when a known detected fault is resulting in an incorrect value being reported for a point—an operator can temporarily override the value back to a suitable value until the detected fault has been corrected. Overrides can also be used to simulate different plant states when testing the system.

Override enabled for point.
Override action for the point is available to operators.

However, you may require that a point value cannot be overridden. When the Override feature is disabled, ClearSCADA continues to use the point’s actual value—the value reported by the outstation, PLC, or other device on which the point is located—regardless of the state of that device.

To configure the override feature for an analog point:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Analog Point tab.
    (If you are configuring this feature for another point that uses analog-type processing, select the appropriately named <Point Type> tab.)
  3. Use the Enabled check box in the Override section to define whether the point can be overridden:

Either:

  • Select the Enabled check box in the Override section.
    The Maximum and Minimum fields become available. You need to use the Maximum and Minimum fields to define the override range (proceed to step 4).

Or:

  • Clear the Enabled check box.
    The Maximum and Minimum fields are grayed out. The point cannot be overridden (ignore step 4).
  4. Use the Maximum and Minimum fields to define the override range. The range defines the values that operators can enter to override the point—any value between and including the minimum amount and the maximum amount.
  1. In the Maximum field, enter the highest value that operators can use to override the point.
  2. In the Minimum field, enter the lowest value that operators can use to override the point.
  5. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator requests that a point is overridden (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

If you enable the Override feature, ensure that the point’s Override/Release security permission is suitably set (see Allocating Security Permissions in the ClearSCADA Guide to Security).


Core Point Configuration Guide - Define the Criteria for a Significant Change in Value (Defining Analog Point Details)

Define the Criteria for a Significant Change in Value

Use the Significant Change section on an Analog Point Form to define the amount by which a point’s engineering value has to change in order for the ClearSCADA server to update its database to include the changed value.

Use Significant Change to help prevent excessive database updates, by determining when a significant change in point value is included in the ClearSCADA database, and when an insignificant change in value can be discarded (the database retains the previously recorded value).

Example:

A point is scanned every 5 seconds and reports a value of 10. There is no need for the database to log the same value every 5 seconds. Significant Change is used to only log the value when it changes by more than 2 (Type = Absolute, Deadband = 2). The point’s value is only updated in the ClearSCADA database when it reaches or drops below 8, or when it reaches or rises above 12, and thereafter whenever the value changes by 2 or more.

To configure the significant change properties:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Analog Point tab, or <Driver Type> tab, as appropriate.
    (If you are configuring the properties for another point that uses analog-type processing, select the appropriately named <Point Type> tab.)
  3. Use the Type combo box to choose a type of Significant Change. Choose from None, Absolute, or Percentage of Span. The functionality of each option (especially ‘None’) differs, depending whether a point is on a simple or advanced driver.

To ascertain whether a driver is a simple or advanced driver, see Types of Driver in the ClearSCADA Guide to Drivers. Alternatively, check whether the guide for driver is located within the ‘Simple Drivers’ branch or the ‘Advanced Drivers’ branch of the online Help.

NOTE: Some drivers handle significant change in a different way to that described below, in particular the ‘None’ option. The driver-specific documentation explains any differences that apply to a particular driver.

For an analog point on a Simple Driver (such as Modbus, or OPC), choose from:

  • None—The server only updates the point value in the ClearSCADA database when one or more of the following occurs:
  • The point value changes by any amount
  • The Refresh action is triggered for the scanner on which the point resides
  • On system or driver start-up.
  • Absolute—The server only updates the point value in the ClearSCADA database when one or more of the following occurs:
  • The point’s engineering value changes by a defined amount. Define the amount by which the value has to change in the Deadband field.
  • The Refresh action is triggered for the scanner on which the point resides
  • On system or driver start-up.
  • Percentage of Span—The server only updates the point value in the ClearSCADA database when one or more of the following occurs:
  • The point’s engineering value changes by a defined percentage of its span. The span is the point range (Zero Scale to Full Scale). Define the percentage in the Deadband field.
  • The Refresh action is triggered for the scanner on which the point resides
  • On system or driver start-up.

For an analog point on an Advanced Driver (such as DNP3, or SCADAPack Modbus), choose from:

  • None—The server only updates the point value in the ClearSCADA database when one or more of the following occurs:
  • The point changes state
  • The point’s Scan Group interval expires
    (this applies to points on outstations that are using direct, rather than PSTN, communications to talk to the server)
  • On start-up of a call to an outstation
    (this only applies to points on PSTN outstations)
  • The Refresh action is triggered for the outstation on which the point resides
  • On system or driver start-up.
  • Absolute—In addition to the reasons listed in ‘None’ above, the point value will be updated in the ClearSCADA database if the point’s engineering value changes by a defined amount.

You define the amount by which the value has to change in the Deadband field.

  • Percentage of Span—In addition to the reasons listed in ‘None’ above, the point value will be updated in the ClearSCADA database if the point’s engineering value changes by a defined percentage of its span. The span is the point range (Zero Scale to Full Scale).

You define the percentage in the Deadband field.

  4. Enter the amount or percentage by which the point’s engineering value has to change for it to be deemed significant, within the Deadband field.
  5. Use the Log Event check box (advanced drivers only) to determine whether a change is logged in the Event Journal if it exceeds the deadband:
  • Select the check box for any significant changes in engineering point value to be logged in the Event Journal.

ATTENTION: Numerous messages may be logged in the Event Journal if Log Event is enabled for a point that frequently changes significantly in value.

  • Clear the check box for any significant changes in engineering point value to be updated in the database, but not be logged in the Event Journal.
  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration)


Core Point Configuration Guide - Detect whether an Analog Point has Stopped Changing (Defining Analog Point Details)

Detect whether an Analog Point has Stopped Changing

You can use the fields within the No Change section of the Analog Point tab to specify whether ClearSCADA should raise an alarm or log an event if a point’s value stops changing.

For instance, you might want ClearSCADA to raise an alarm if a particular point’s value doesn’t change by a specified minimum amount for a defined period of time.

For information on configuring the No Change properties and examples showing how these properties might be configured, see Detect Whether a Point Value has Stopped Changing.

ATTENTION: With many protocols, in order to use the No Change feature on points that are on PSTN outstations, you need to ensure that ClearSCADA is configured to raise Alarms From Logged Data Only, or Most Recent Logged Data. With these options the current value reported at the beginning of a call does not inadvertently generate a No Change alarm or event. (For more information, see the ClearSCADA Guide to Advanced Drivers.)


Core Point Configuration Guide - Define an Analog Point's Trend Settings (Defining Analog Point Details)

Define an Analog Point’s Trend Settings

You can display the trend, or movement, of an analog point’s value in the form of a graph. The graph is referred to as a Trend. Up to two types of Trend are available per point, depending on the point configuration (see Types of Trend).

This section gives an Overview of an Analog Point’s Trend and explains the Procedure for Configuring an Analog Point’s Trend Settings.


Core Point Configuration Guide - Types of Trend (Defining Analog Point Details)

Types of Trend

  • Current Trend—This Trend displays the current value of the point in a graph format. This type of Trend is available for each point.

Display a Current Trend by using the Display Current Trend pick action. The Trend displays the current value of the point at the instant that you display the Trend. As the Trend is by default ‘live’, ClearSCADA continues to update the point value, resulting in a ‘trace’ of point activity for the duration that the Trend remains on display.

  • Historic Trend—This Trend displays historically stored values for the point, in a graph format. This type of Trend is available for points that have Historic storage enabled (see Enable or Disable Historic Data Storage).

Display a Historic Trend by using the Display Historic Trend pick action. By default, this Trend displays a time scale from the present time backwards over a 24-hour period. The Trend displays data from the most recently logged value, backwards.

As the Trend is by default ‘live’, ClearSCADA continues to update the historic values as they are logged, resulting in an updating ‘trace’ of point activity for the duration that the Trend remains on display.

For more information on Trends, see the ClearSCADA Guide to Trends.


Core Point Configuration Guide - Overview of an Analog Point's Trend (Defining Analog Point Details)

Overview of an Analog Point’s Trend

X-Axis
Y-Axis
Trace

Each Trend consists of an x-axis, a y-axis, and a trace. The x-axis displays a time interval, and the y-axis displays the measurement units. The Trace represents the analog point’s current or historic values.

You need to define the values of the Trend’s y-axis, and determine whether it is logarithmic or linear so that a suitable range of units are shown. To do this, you need to use the fields in the Trend section of the Analog Point Form’s Analog Point tab (see Procedure for Configuring an Analog Point’s Trend Settings).

For Historic Trends, you also need to use the fields on the Analog Point Form’s Historic tab (see Define the Time Period Shown on Historic Trends and Lists).


Core Point Configuration Guide - Procedure for Configuring an Analog Point's Trend Settings (Defining Analog Point Details)

Procedure for Configuring an Analog Point’s Trend Settings

To configure an analog point’s Trend:

  1. Display the Form for the analog point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Analog Point tab.
    (If you are configuring Trend details for another point that uses analog-type processing, select the appropriately named <Point Type> tab.)
  3. Use the Trend section of the Form to define the range of the y-axis, and (for Current Trends only) the time interval of the x-axis:
  1. Enter the highest value to be shown on the y-axis in the Maximum field (within the Trend section).
  2. Enter the lowest value to be shown on the y-axis in the Minimum field (within the Trend section).
  3. Define whether the y-axis is logarithmic or linear:
  • Select the Logarithmic check box if you want the y-axis to have a logarithmic scale.
  • Clear the Logarithmic check box if you want the y-axis to have a linear scale.
  4. For Current Trends, follow the steps below to define the offset for, and the time interval of, the x-axis, along with the update rate for the Trend data.

For Historic Trends and Lists, define the time interval of the x-axis using the Trend/List fields on the Historic tab of the Point Form (see Define the Time Period Shown on Historic Trends and Lists).

The steps below do not apply to Historic Trends.

  5. In the Offset field, specify the default start time for the x-axis, in relation to the present time, for whenever you view the data as a Current Trend.

Enter the offset in the OPC Relative Time Format. For example, M - 10M for the earliest time on the x-axis to be ten minutes before the beginning of the current minute. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

  6. In the Interval field, specify the default time interval for the x-axis, starting from the time specified in the Offset field, for whenever you view the data as a Current Trend.

Enter the interval in the OPC Time Format, for example 15M for the x-axis to display a 15-minute period. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required offset.

  7. In the Update Rate field, specify the frequency with which the trace data on a Current Trend is updated.

Enter the frequency in the OPC Time Format, for example, 15S for the data to update at 15-second intervals. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required rate.

  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Maximum Y-Axis range
Minimum Y-Axis range
X-Axis offset
X-Axis interval

When a Current or Historic Trend is displayed for the point, the y-axis displays the range of values that remain within the Minimum value and Maximum value limits. It uses linear or logarithmic scaling in accordance with your selection for the Logarithmic check box.

When a Current Trend is displayed for the point, the Offset and Interval entries define the time period of the Trend, and the start time of the x-axis in relation to the present time.

Example:

The Interval of a Trend is set to 15M (15 minutes), and the Offset is M - 10M (10 minutes before the present minute). If the Trend is displayed and the present time is 12:00:05, the time period displayed by the x-axis would be 11:50:00 to 12:05:00, as the present time is rounded back to the beginning of the present minute.

Further Information

Overview of an Analog Point’s Trend.

For more information on Trends, see the ClearSCADA Guide to Trends.


Core Point Configuration Guide - Define the Control Settings for an Analog Output Point (Defining Analog Point Details)

Define the Control Settings for an Analog Output Point

Analog Outputs—also known as set points—control plant by sending it one of a range of values. You define the limits for those values using the fields on the Control tab of the Analog Output Point Form.

Several drivers support analog output points. This section covers configuration of the standard control properties on the Control tab of the Analog Output Point Form (see Define the Analog Control Settings). For fields not covered in this section, or in Promoting Scanning of Outstations Associated with Controls, see the driver-specific documentation.


Core Point Configuration Guide - Define the Analog Control Settings (Defining Analog Point Details)

Define the Analog Control Settings

Use the fields at the top of the Control tab to define the range of values that an operator can send to control the plant, and the severity of any events and alarms that are associated with the control action:

  1. Points on simple drivers that support controls, and output points on some advanced drivers, include an Enabled check box at the top of the Control tab. If a point is set up as an output point and is to be controlled by ClearSCADA, select the check box to enable the control feature for that point.
    Other fields on the Control tab become available for use.
    Go to step 2.

Clear the Enabled check box if the point is not to be used as an output point, or if the point is to be controlled by another application, rather than ClearSCADA.
The other fields on the Control tab will be ‘grayed out’ and unavailable for use.
Go to step 8.

  2. In the Maximum field specify the highest output value that can be sent to control the plant.
  3. In the Minimum field specify the lowest output value that can be sent to control the plant.

An operator, for example, would define the actual control value using the field in the Control window, displayed when the Control pick action is selected. The value has to fall within the limits specified above. The value is converted from an engineering value into a raw value when the server sends the control.

  4. Use the Severity combo box to define the severity of the event that is logged for each successful control action, and the severity of the alarm raised for an unsuccessful control action. For more information, see Defining Severities in the ClearSCADA Guide to Core Configuration.
  5. If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Control tab. Use the field to specify the Area of Interest with which any control-related events and alarms are associated.

For more information on configuring Areas of Interest, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

For information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  6. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator attempts to send a control (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  7. If available for points on your drivers, use the fields in the Promote section of the Control tab to define whether any outstations are scanned in preference to others following a control request (see Promoting Scanning of Outstations Associated with Controls).
  8. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define the Manual Control Settings for an Internal Analog Point (Defining Analog Point Details)

Define the Manual Control Settings for an Internal Analog Point

An Internal Analog Point is a point that only exists within the software—it does not physically exist on a system and is not associated with plant (see Internal Points).

To set the value of an Internal point, you ‘hand control’ the point value. Specify the hand control properties using the fields on the Manual tab of the Internal Analog Point Form.

  1. Either:
  • Select the Hand Control check box. Operators whose User Accounts are allocated the Control security permission for the point will be able to ‘hand control’ the point’s value, using the Hand Control pick action.

or:

  • Clear the Hand Control check box if the value of the Internal point is not to be controlled using the Hand Control pick action. Logic or a data access application can be used to set the point’s CurrentValue property directly (see Internal Points).
  2. In the Maximum field, specify the highest value that can be assigned to the Internal point.
  3. In the Minimum field, specify the lowest value that can be assigned to the Internal point.
  4. If the Hand Control check box is selected, use the Confirm combo box to specify whether a confirmation dialog box is displayed whenever an operator attempts to hand control the point (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  5. Either:
  • Select the Log Hand Control Events check box for ClearSCADA to log an event each time that the point’s value is set. This provides a historic record of when and by whom or what application the Internal point was hand controlled.

Be aware that if Logic or a data access application sets the point’s value, the severity with which that action is logged depends on the Severity that is specified for that application (see Internal Points).

or:

  • Clear the Log Hand Control Events check box if ClearSCADA is not to log any hand control events in the Event Journal.

ATTENTION: Clear the Log Hand Control Events check box if an application sets the point’s value on a frequent basis. This will help to prevent ClearSCADA from logging numerous events relating to the point’s value being set.

  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Defining Digital Point Details

Defining Digital Point Details

Use Digital Points within the ClearSCADA database to represent measuring instruments or control devices that can be in any of a set number of states (see Single and Multi-Bit Digital Points). For example, a digital point might represent a pump that is either running or stopped, or a pipe valve that is either open or closed. The raw digital value is received from the measuring instrument and processed to define the state of the digital point.

You configure each digital point on your system by using the fields on the appropriate Digital Point Form. Each Form has several tabs, which you use to define different aspects of the point configuration.

Use this section, along with the appropriate driver documentation, for information on configuring the digital points on your system.

This section explains how to configure digital point properties that are common to many digital points. Most of these properties are displayed on the Digital Point tab of the Digital Point Form.

Digital Point tab

Each Digital Point Form has a Digital Point tab that you can use to:

  • Define the Number of Bits for a Digital Point.
  • Define the Format of a Digital Point’s Values.
  • Define the Point States for a Digital Point.
  • Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events. (Only applicable if the Area of Interest feature is enabled in ClearSCADA.)
  • Define whether a Digital Point can be Overridden.
  • Define a Digital Point’s Trend Settings.

If the point is a digital output point, you need to use the Control tab to:

  • Define the Control Settings for a Digital Output Point.

If the point is an internal digital point, you need to use the Manual tab to:

  • Define the Manual Control Settings for an Internal Digital Point.

(In addition to internal digital points, ClearSCADA also supports Boolean Variables. The type of database item that you add to ClearSCADA depends on that item’s intended functionality. For more information, see Variables in the ClearSCADA Guide to Core Configuration.)


Core Point Configuration Guide - Single and Multi-Bit Digital Points (Defining Digital Point Details)

Single and Multi-Bit Digital Points

The number of bits that are allocated to a measuring instrument or control device in the outstation hardware determines the number of possible states for that point:
Number of bits allocated for the measuring instrument/ control device in the outstation | Number of possible states for the point representing the measuring instrument/ control device
1 | 2
2 | 3-4
3 | 5-8

Many drivers support 1-bit digital points, which can be in either of two states:
Bit Position | 0 | 1
State | 0 | 1

Some drivers also support 2- and 3-bit digital points.

A 2-bit digital point can be in one of four states:
Bit Position | 00 | 01 | 10 | 11
State | 0 | 1 | 2 | 3

A 3-bit digital point can be in one of eight states:
Bit Position | 000 | 001 | 010 | 011 | 100 | 101 | 110 | 111
State | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7

Example:

A digital input point represents a pump.

The data for the pump is stored in 2 consecutive bits of a digital input card in the outstation.

The digital point that represents the pump can have 4 possible states.
(Each bit allocated to the point can be on (1) or off (0)—as the point has 2 bits, the possible permutations are 0 0, 0 1, 1 0, or 1 1, and as such, four possible states.)

You need to Define the Number of Bits for a Digital Point on the Form for that point. The Number of Bits setting has to be consistent with the number of consecutive bits used in the outstation or PLC, to store the data for the measuring instrument or control device that the point represents.

You can then specify a suitable description for the state that is associated with each bit, and define whether an event is logged, or an alarm is raised upon entry into each state (see Define the Point States for a Digital Point).


Core Point Configuration Guide - Define the Number of Bits for a Digital Point (Defining Digital Point Details)

Define the Number of Bits for a Digital Point

To define the number of bits that are allocated to a digital point:

  1. Display the Digital Point Form for the digital point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Digital Point tab.
    (If you are configuring the number of bits for another point that uses digital-type processing, select the appropriately named <Point Type> tab.)
  3. Use the Number of Bits combo box to select the required number of bits (the number of consecutive bits that are used for the point in the outstation):
  • 1—For digital points that have 1 bit, and therefore can have 2 states.
  • 2—For digital points that have 2 bits, and therefore can have 3 to 4 states.
  • 3—For digital points that have 3 bits, and therefore can have 5 to 8 states.
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Single and Multi-Bit Digital Points.


Core Point Configuration Guide - Define the Format of a Digital Point's Values (Defining Digital Point Details)

Define the Format of a Digital Point’s Values

You can use the Format field on the Digital Point Form to define the appearance of a digital point’s values. The Format field is displayed on the Digital Point tab.

The format that you choose will determine how the digital point’s value is shown on other displays, such as Lists and Mimics.

To define the format of the digital point’s values:

  1. Display the Digital Point Form for the digital point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Digital Point tab.
    (If you are configuring the format for another point that uses digital-type processing, select the appropriately named <Point Type> tab.)
  3. Select the browse button next to the Format field.
    The Text Format window is displayed.
  4. Use the Text Format window to choose and define the required type of formatting (see Choose a Format Category in the ClearSCADA Guide to Core Configuration).
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define the Point States for a Digital Point (Defining Digital Point Details)

Define the Point States for a Digital Point

You need to define the states for each digital point so that ClearSCADA generates suitable alarms or events when the corresponding measuring instruments or control devices change state.

The number of states that are available for a point is determined by the number of bits that are allocated to that point (see Single and Multi-Bit Digital Points). Each point state corresponds to a condition of the measuring instrument or control device that the point represents. For example, a digital point that represents a valve might have one bit and two states—one state indicating that the valve is open, and the other indicating that the valve is closed.

The ‘severity’ of the digital point’s states defines what alarms or events are raised or logged when the point changes state.

To configure a digital point’s states, you need to access the Digital Point tab of the relevant Digital Point Form.

The tab includes a States section that contains the fields that you need to use to define each point state.

Each row of fields represents the properties for a single state. The state is indicated at the start of the row.
Each row contains Severity combo boxes, a Description field, Color field, and an Override check box.

For information on configuring the properties for each state, see Procedure for Configuring a Digital Point’s States.


Core Point Configuration Guide - Procedure for Configuring a Digital Point's States (Defining Digital Point Details)

Procedure for Configuring a Digital Point’s States

To Define the Point States for a Digital Point:

  1. Display the Digital Point Form for the digital point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Digital Point tab.
    (If you are configuring the states for another point that uses digital-type processing, select the appropriately named <Point Type> tab.)
  3. Scroll to the States section of the tab.
  4. Use the relevant Severity combo box to define what is generated when the point enters the selected state. (For example, to specify the severity associated with State 0, select the Severity combo box in row 0.)

Choose from None, Event, Alarm, or Fleeting.

For options other than None, define the severity of the event or alarm in the adjacent combo box (see step 5).

For further information on Severity options, see Defining Severities in the ClearSCADA Guide to Core Configuration.

  5. Use the combo box to the right of the Severity combo box to define the importance of the alarm, fleeting alarm, or event.
    Define the importance of the alarm, fleeting alarm, or event.

The figure above shows ClearSCADA’s default options—these will probably have been replaced by a customized range on your system—select the appropriate level of importance from the available options.

Further Information

Using Importance Levels: see Defining Severities in the ClearSCADA Guide to Core Configuration.

Configuring Custom Severity Levels: see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.

  6. Either:
  • Enter a description of the selected state in the Description field.

Or:

  • Choose a description from the Description combo box.
    (To adjust the entries in this list to more suitable ones for your system, see Define Descriptions for Numeric Point States in the ClearSCADA Guide to Server Administration.)

Ensure that you choose or define a suitable description for each point state, as these are shown on displays such as Mimics, allowing operators to understand the significance of each state. If you leave the description for a particular state at its default description, for example, State 1, ClearSCADA will display that description when the point is in that state, which will not be very indicative of the relevance of the state.

If the Dictionary feature is used on your system, you can prefix the string in Description field, in order for that string to be replaced with another term, when displayed in a List or on a Mimic, in ViewX. For more information, see Dictionary Settings in the ClearSCADA Guide to Server Administration.

By default, point states are shown in black text on displays, such as Lists, unless:

  • The point is in an alarm state (in which case the state is displayed in the corresponding severity color)
  • Another status, such as an Override, takes precedence over a non-alarm state (in which case the state is displayed in the color that indicates that status).

NOTE: You can change the color that your system uses for the ‘Normal’ state (black by default), using the Color Palette (see Use the Color Palette to Define a Custom System Color in the ClearSCADA Guide to Core Configuration).

If you want to associate the state with a custom color when neither of the above situations is in effect, proceed to step 7.

If you want the state to be associated with the default color to indicate a ‘Normal’ state (black text, by default), go straight to step 11.

  7. Select the browse button next to the Color field.
    A Reference browse window is displayed.
  8. Use the Reference browse window features to locate the custom color that you want to associate with the state.

You can only associate a limit with a custom color if you have pre-configured custom colors available (see Defining a Custom State Color in the ClearSCADA Guide to Core Configuration).

  9. Select the relevant custom color.
  10. Select the OK button.
    The Reference browse window is closed and the name of the custom color is displayed in the Color field. When the point enters the selected state, its state value will be shown in the custom color.

(If required, you can select the Go To hyperlink that is adjacent to the Color field to display the Color Form for the selected custom color.)

  11. Use the Override check box to determine whether the digital point can be overridden into the selected state.

The Override check boxes for each state are only available if the Override feature is enabled for the point (see Define whether a Digital Point can be Overridden).

Either:

  • Select the check box to allow operators to override the digital point into the selected state.
  • Clear the check box if operators are not permitted to override the digital point into the selected state.
  12. Repeat steps 3-11 for each digital point state.
  13. If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed in the States section of the tab. Use the field to Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events.
  14. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Specify the Area of Interest Associated with a Point's State-Related Alarms and Events (Defining Digital Point Details)

Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events

If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed within the States section on the Digital Point tab.

An Area of Interest field is displayed if the Area of Interest feature is enabled on your system.

Use the Area of Interest field to specify the area with which any state-related point alarms or events are to be associated.

Whenever a point enters a state that is configured to generate an event or alarm, that event or alarm will be associated with this Area of Interest. As such, only users that have access to this Area of Interest will be aware of the event or alarm.

For more information on configuring Areas of Interest, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.


Core Point Configuration Guide - Define whether a Digital Point can be Overridden (Defining Digital Point Details)

Define whether a Digital Point can be Overridden

You can use the Override check boxes on the Digital Point Form’s Digital Point tab to define whether a digital point can be overridden.

The Override feature allows operators whose User Accounts are allocated the Override/Release security permission to change (‘override’) the state of a digital point. When the state is overridden, its value replaces the state value of the selected point in the database, but does not affect the data in the outstation or PLC, or the corresponding measuring instrument or control device.

Typically, overrides are used when a known detected fault is resulting in an incorrect state being reported for a point. Overrides can also be used to simulate different plant states when testing the system.

To define whether a digital point can be overridden:

  1. Display the Digital Point Form for the digital point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Digital Point tab.
    (If you are configuring this feature for another point that uses digital-type processing, select the appropriately named <Point Type> tab.)
  3. Use the Override section of the tab to determine whether the point can be overridden:
  • Go to step 4 if you want to allow operators to be able to override a point.
  • Go straight to step 7 if operators are not to have the ability to override the point.

(On some drivers, additional fields are displayed within the Override section—see the driver-specific documentation for details.)

  4. Select the Override check box to allow the digital point to be overridden.
    The override check boxes for each state become available.
    Override enabled...
    ...Override check boxes for each state become available.

  5. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator requests that a point is overridden (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  6. Define the states to which operators can override the point—you have to select at least one point state (see Define the Point States for a Digital Point).
  7. Ensure that the Override/Release permission for the point is set to allow the required operators to perform an override (see Allocating Security Permissions in the ClearSCADA Guide to Security).

Now go to step 9.

  8. Ensure the Override check box is clear if operators are not permitted to override the digital point.
    ClearSCADA will use the point value reported by the outstation, PLC or other device on which the point is located, regardless of the state of that device.
    Override disabled

  9. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define a Digital Point's Trend Settings (Defining Digital Point Details)

Define a Digital Point’s Trend Settings

You can display the Trend, or movement, of a digital point’s value in the form of a graph. The graph is referred to as a Trend. Up to two types of Trend are available per point, depending on the point configuration (see Types of Trend).

This section gives an Overview of a Digital Point’s Trend and explains the Procedure for Configuring the Settings for a Digital Point’s Current Trend.


Core Point Configuration Guide - Overview of a Digital Point's Trend (Defining Digital Point Details)

Overview of a Digital Point’s Trend

X-Axis offset
Trace
X-Axis interval

Each Trend consists of an x-axis, a y-axis, and a trace. The x-axis displays a time interval, and the y-axis displays the point states. The Trace represents the digital point’s current or historic state.

You need to define the values of the Trend’s x-axis, to determine the time period over which the point’s states are shown, so that a suitable range of units are displayed.

To do this for a Current Trend, you need to use the fields in the Trend section of the Digital Point Form’s Digital Point tab (see Procedure for Configuring the Settings for a Digital Point’s Current Trend).

For a Historic Trend, you need to use the fields on the Digital Point Form’s Historic tab (see Define the Time Period Shown on Historic Trends and Lists).


Core Point Configuration Guide - Procedure for Configuring the Settings for a Digital Point's Current Trend (Defining Digital Point Details)

Procedure for Configuring the Settings for a Digital Point’s Current Trend

To define the time period shown on a digital point’s Current Trend:

  1. Display the Form for the digital point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Digital Point tab.
    (If you are configuring Trend details for another point that uses digital-type processing, select the appropriately named <Point Type> tab.)
  3. Use the Trend section of the tab to define the range of the x-axis:
  1. In the Offset field, specify the default start time for the x-axis, in relation to the present time, for whenever you view the data as a Current Trend.

Specify the offset in the OPC Relative Time Format. For example, M - 10M for the earliest time on the x-axis to be ten minutes before the beginning of the current minute. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

  2. In the Interval field, specify the default time interval for the x-axis, starting from the time specified in the Offset field, for whenever you view the data as a Current Trend.

Specify the interval in the OPC Time Format, for example 15M for the x-axis to display a 15-minute period. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required period.

  3. In the Update Rate field, specify the frequency with which the trace data on a Current Trend is updated.

Specify the frequency in the OPC Time Format, for example, 15S for the data to update at 15-second intervals. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required rate.

  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When a Current Trend is displayed for the point, the Offset and Interval settings define the time period of the Trend, and the start time of the x-axis in relation to the present time. The Update Rate specifies how often the Trend data is refreshed.

Example:

The Interval of a Trend is set to 15M (15 minutes), and the Offset is M - 10M (10 minutes before the present minute). If the Trend is displayed and the present time is 12:00:05, the time period displayed by the x-axis would be 11:50:00 to 12:05:00, as the present time is rounded back to the beginning of the present minute.

Further Information

Overview of a Digital Point’s Trend.

For more information on Trends, see the ClearSCADA Guide to Trends.


Core Point Configuration Guide - Define the Control Settings for a Digital Output Point (Defining Digital Point Details)

Define the Control Settings for a Digital Output Point

Digital output points can send one of up to two, four, or eight specified controls to a device, depending on the number of bits that the point contains (see Single and Multi-Bit Digital Points). 1-bit digital output points can have two control actions, 2-bit digital output points can have four control actions, and 3-bit digital output points can have eight control actions.

Each digital output takes the form of a maintained control. A maintained control upholds the new state of the point until it is altered by a further control.

Example:

A one-bit digital output sends a command to a point that is connected to a control device. The command instructs the device to carry out one of two control actions that it is configured to undertake. For instance, to open, or close a switch.

A number of drivers support digital output points.

This section covers configuration of standard Action fields on the Control tab of the Digital Output Point Form (see Specify Whether a Digital Point can be Controlled, and see Define the Output Actions). For fields not covered in this section, or in Promoting Scanning of Outstations Associated with Controls, see the driver-specific documentation.

NOTE: A number of drivers also support pulsed controls. A pulsed control changes the state of a point for a defined period of time. You configure pulsed controls using the appropriate Pulse Action Form (see Defining Pulse Action Details).


Core Point Configuration Guide - Specify Whether a Digital Point can be Controlled (Defining Digital Point Details)

Specify Whether a Digital Point can be Controlled

Digital points on simple drivers that support controls, and output points on some advanced drivers, include an Enabled check box at the top of the Control tab. If a point is set up as an output point and is to be controlled by ClearSCADA, select the check box to enable the control feature for that point.
Other fields on the Control tab become available for use.

Ensure that the Enabled check box is clear if the point is not to be used as an output point, or if the point is to be controlled by another application, rather than ClearSCADA.
The other fields on the Control tab will be ‘grayed out’ and unavailable for use.


Core Point Configuration Guide - Define the Output Actions (Defining Digital Point Details)

Define the Output Actions

Use the fields within the Actions section of the Control tab to define the actions that a digital output point can undertake. The number of available control actions depends on the number of bits used by the point:

NOTE: An additional Enabled check box is displayed at the top of the tab for points on Simple drivers (see the ClearSCADA Guide to Simple Drivers). Select this Enabled check box if the point is to be used as an output point—the fields shown below will become available for use.

  1. For each available action either:
  • Select the Enabled check box to allow users with the Control permission to issue the corresponding control action.
  • Clear the Enabled check box to prevent controls from being issued for the action.
    Any Severity or Description settings for that action are ignored.
  2. Use the Severity combo box to define the severity of the event that is logged for each successful control action, and the severity of the alarm raised due to an unsuccessful control action. (For more information, see Defining Severities in the ClearSCADA Guide to Core Configuration.)
  3. In the Description field enter a text description for each enabled control action, or use the combo box to select one of the pre-defined descriptions. (To add a pre-defined description, see Define Descriptions for Control Actions in the ClearSCADA Guide to Server Administration.)
  4. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator attempts to send a control (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  5. If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Control tab. Use the field to specify the Area of Interest with which any control-related events and alarms are associated.

For more information on configuring Areas of Interest, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

For information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  6. If available for points on your drivers, use the fields in the Promote section of the Control tab to define whether any outstations are scanned in preference to others following a control request (see Promoting Scanning of Outstations Associated with Controls).
  7. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define the Manual Control Settings for an Internal Digital Point (Defining Digital Point Details)

Define the Manual Control Settings for an Internal Digital Point

An Internal Digital Point is a point that only exists within the master station software—it does not physically exist on a system and is not associated with plant (see Internal Points).

To set the value of an internal digital point, you ‘hand control’ the point value. Specify the hand control properties using the fields on the Manual tab of the Internal Digital Point Form:

  1. Either:
  • Clear the Hand Control check box if the value of the Internal point is not to be controlled using the Hand Control pick action. Logic or a data access application can be used to set the point’s CurrentValue property directly (see Internal Points).

or:

  • Select the Hand Control check box to enable operators that have the Control permission to ‘hand control’ the value of the point, using the Hand Control pick action.
  2. In the States section of the tab, for each available state either:
  • Select the check box to allow that state to be hand controlled, either manually using the Hand Control pick action (if enabled, above), or automatically using Logic or a data access application.

or:

  • Clear the check box if a state is not to be hand controlled.

(The number of states that are available for selection depends on the number of bits that are specified for the point (see Single and Multi-Bit Digital Points).)

  3. If the Hand Control check box is selected, use the Confirm combo box to specify whether a confirmation dialog box is displayed whenever an operator attempts to hand control the point (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  4. Either:
  • Select the Log Hand Control Events check box for ClearSCADA to log an event each time that the point’s value is set. This provides a historic record of when and by whom or what application the Internal point was hand controlled.

Be aware that if Logic or a data access application sets the point’s value, the severity with which that action is logged depends on the Severity that is specified for that application (see Internal Points).

or:

  • Clear the Log Hand Control Events check box if ClearSCADA is not to log any hand control events in the Event Journal.

ATTENTION: Clear an Internal point’s Log Hand Control Events check box if an application sets the point’s value on a frequent basis. This will help to prevent ClearSCADA from logging numerous events relating to the point’s value being set.

  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Defining Counter Point Details

Defining Counter Point Details

A Counter-type Point is a point that accumulates a value over time. For example, a counter-type point might monitor the number of rotations of a turbine over a 24-hour period. A number of drivers support counter-type points, although the name given to this type of point differs, depending on the driver (see the driver-specific documentation for details).

As with many other types of point, you specify the states in which the point can reside. You can also define a suitable description for each of these states, and define whether an event is logged, or an alarm is raised upon entry into each state.

You configure each counter-type point on your system by using the fields on the appropriate Point Form. Each Form has several tabs, which you use to define different aspects of the point configuration.

Use this section, along with the appropriate driver documentation, for information on configuring the counter-type points on your system.

This section explains how to configure counter point properties that are common to many counter-type points. Most of these properties are displayed on the <Point Type> tab of the Point Form (the name of this tab varies with the type of counter point—see the driver-specific documentation for details).

The <Point Type> tab name varies, depending on the type of counter point.

On a counter-type point, you can use the <Point Type> tab to:

  • Define Whether an Initialization Request Requires Confirmation
  • Configure the Limits for a Counter-Type Point, including (if required):
  • Multiple Alarm Limits.
  • Define Whether a Counter-Type Point’s Limits can be Tuned
  • Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events. (Only applicable if the Area of Interest feature is enabled in ClearSCADA.)
  • Define the Appearance of a Counter-Type Point’s Values
  • Define Whether a Counter-Type Point can be Overridden
  • Detect whether a Counter-Type Point has Stopped Changing
  • Define a Counter-Type Point’s Trend Settings.

Other fields on the tab vary, depending on the driver. They typically include field(s) to define the period over which the counter point accumulates its value, and a multiplier field so that the count can be scaled into a more useful figure for use in ClearSCADA. For example, one count might represent 0.5mm of rain, or 1kWh of electricity. For further information, see the driver-specific documentation.


Core Point Configuration Guide - Define Whether an Initialization Request Requires Confirmation (Defining Counter Point Details)

Define Whether an Initialization Request Requires Confirmation

Many counter-type points support initialization, whereby an operator can initialize the point back to a particular value by using the Initialize pick action.

The Confirm Initialize combo box is displayed on the Point Form for counter-type points that support Initialization. (On some drivers, the name of this combo-box varies—see the driver-specific documentation for details.)

Use the Confirm Initialize combo box to define whether a confirmation dialog box is displayed whenever an operator requests that a point is initialized (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Configure the Limits for a Counter-Type Point (Defining Counter Point Details)

Configure the Limits for a Counter-Type Point

You need to set the limits for each counter-type point so that when the value of the point rises above the normal range of values, a suitable alarm is raised or event is logged. On many drivers, the driver calculates the value of the counter point from the data that it retrieves from the outstation. This data often comprises an indication that another counter-type event (‘tick’) has occurred. From this information, the driver calculates the running total, or value, of the counter-type point.

To configure the limits of a counter-type point, you need to access the <Point Type> tab of the relevant type of Counter Point Form.

Columns for each configuration property
Rows for each limit

The Alarm Limits section has a row of fields for each limit. The fields are arranged in columns, and are used for defining the configuration properties of each limit. The figure above shows the types of limit that are available for counter-type points on many drivers. Some counter-type points have different limits to those shown above (see Counter-Type Points with Different Limits).

Use the Alarm Limits to define limits that indicate notable changes in operating condition of the plant. By default, many counter-type alarm limits are High-High and High. You can specify whether a point rising past these limits logs an event or raises an alarm.

The Normal state defines the usual operating range for the plant. You can choose whether to log an event whenever the point returns to this state. The Normal state operating range is between zero and the High alarm limit.

The range of limits forms a scale.

Where the counter-type point has only High and High-High limits, the range of limits form a scale, as follows:

Example:

A counter point is used to monitor the amount of electricity that is used each day. An event is logged if power consumption rises to 15kWh/day, and an alarm is raised if power consumption is deemed too high (18kWh/day or more).

The counter point has two alarm limits and has been configured to have these properties:

High-High: 18 kWh (Alarm)
High: 15 kWh (Event)
Normal

The value of the counter point is calculated over a one-day period.

When the value of the counter point is below 15 kWh, it is deemed to be in its usual operating state.

From normal operating conditions, if the point rises to 15 kWh or above, an event is logged to indicate that the point value has risen to the High state.

If the point value continues to rise, and reaches 18 kWh or above, an alarm is raised, to indicate that the point value has risen to the High-High state.

If the point value then drops below 18 kWh, the High-High alarm is cleared. This situation occurs if the point value is in the High-High state when an End of Period (EOP) Reset occurs, or the point is Initialized.

In this particular example, an End of Period Reset occurs automatically at the end of each day. When a Reset occurs, the driver updates the End of Period value with the total counter value for the day that is just ending, then resets the current value of the point back to zero, ready to accumulate the value for the day that is just starting.

Further Information

Procedure for Configuring a Counter-Type Point’s Limits.


Core Point Configuration Guide - Counter-Type Points with Different Limits (Defining Counter Point Details)

Counter-Type Points with Different Limits

Some counter-type points have different types of alarm limit to those explained in this guide. The Procedure for Configuring a Counter-Type Point’s Limits is very similar, regardless of the type of limit. The driver guides explain any limits that are driver-specific.

Counter-type points can also be configured to have:

  • Two sets of alarm limits (see Multiple Alarm Limits)
  • Multiple Point State Alarms (in which case an additional Alarm column is displayed in the Alarm Limits section of the Point Form).


Core Point Configuration Guide - Procedure for Configuring a Counter-Type Point's Limits (Defining Counter Point Details)

Procedure for Configuring a Counter-Type Point’s Limits

To Configure the Limits for a Counter-Type Point:

  1. Display the Form for the counter-type point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the <Point Type> tab (for example, select the Counter Point tab for a DNP3 counter point).
  3. Highlight the relevant Limit field. For example, if you are configuring the High-High limit, select the Limit field for the High-High row.
  4. Enter the required value. When you enter the value, you need to consider the requirements at the site—for example, the point limits need to correspond to normal/high/high-high operating conditions for the specific area of plant.
  5. Use the left-hand Severity combo box next to the Limit field to define what happens when the counter-type point’s value exceeds the limit:
    Use the left-hand Severity combo box to determine what happens when the point value exceeds the limit.

  • None—ClearSCADA does not generate an alarm or event.
  • Alarm—ClearSCADA generates an alarm. The alarm has the severity level that you select in step 6.
  • Event—ClearSCADA generates an event. The event has the severity level that you select in step 6.

If you selected the Alarm or Event options, proceed to step 6.

If you selected the None option, proceed to step 7.

  6. Use the right-hand Severity combo box next to the Limit field to define the level of importance associated with the event or alarm.
    Use the right-hand Severity combo box to define the importance of the alarm or event.

A set of severity levels are provided for each ClearSCADA system (see Defining Severities in the ClearSCADA Guide to Core Configuration). Choose the appropriate severity level from the list available on your system.

NOTE: If any of the counter-type points on your system have Multiple Point State Alarms configured, an additional Alarm column is displayed to the left of the Description combo box. For information on specifying multiple Alarm Conditions, see Multiple Point State Alarms.

  7. Use the Description combo box to enter or select a suitable description of the limit.

You can either highlight the existing description and replace it with a new one, or you can choose one of the available descriptions from the combo box list. There are default descriptions for each limit, but these can be replaced by user-defined descriptions that are more specific to the points on your system (see Define Descriptions for Numeric Point States in the ClearSCADA Guide to Server Administration).

Usually, the Description describes the state of the plant or conditions at the site. For example, for a counter point that monitors power consumption over a week, the description for a High-High limit could be ‘Excessive Demand’. The description provides extra information to operators so that they have a better understanding of what the High-High limit represents.

If the Dictionary feature is used on your system, you can prefix the string in Description field, in order for that string to be replaced with another term, when displayed in a List or on a Mimic, in ViewX. For more information, see Dictionary Settings in the ClearSCADA Guide to Server Administration.

By default, point states are shown in black text on displays such as Lists, unless:

  • The point is in an alarm state (in which case the text is displayed in the corresponding severity color)
  • Another status, such as an Override, takes precedence over a non-alarm state (in which case the text is displayed in the color that indicates that status).

NOTE: You can change the color that your system uses for the ‘Normal’ state (black by default), using the Color Palette (see Use the Color Palette to Define a Custom System Color in the ClearSCADA Guide to Core Configuration).

If you want to associate a state with a custom color when neither of the above situations is in effect, proceed to step 8.

If you want the state to use the default color to indicate a ‘Normal’ state (black by default), proceed to step 10.

  8. Use the Color field to associate the limit with a custom color:
  1. Select the browse button next to the Color field for the limit you are configuring.
    A Reference browse window is displayed.
  2. Use the Reference browse window to locate the required custom color.

You can only associate a limit with a custom color if you have pre-configured custom colors available (see Defining a Custom State Color in the ClearSCADA Guide to Core Configuration).

  3. Select the custom color.
  4. Select the OK button.
    The Reference browse window is closed and the name of the selected color is shown in the Color field. When the point enters this state, its value will be shown in the custom color.
  9. Repeat steps 3-8 inclusive for each limit.
  10. If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed in the Alarm Limits section of the tab. Use the field to Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events.
  11. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Multiple Alarm Limits (Defining Counter Point Details)

Multiple Alarm Limits

Normally, counter-type points have one set of alarm limits that you use to define which point values correspond to alarm conditions (see Configure the Limits for a Counter-Type Point).

However, you can configure the points on your system so that they can use one of two sets of alarm limits. So, for example, points can have different sets of alarm limits, depending on seasonal variations.

Use two sets of alarm limits if there are known occasions when the points on your system require different limits.

Multiple alarm limits are not enabled by default—if you require the counter-type points on your system to have two sets of alarm limits, you have to enable this feature on each server on your system (see Set Up Multiple Alarm Limits in the ClearSCADA Guide to Server Administration).

Once configured, you can change which sets of alarms are in effect on a group by group basis (see Switch Between Multiple Alarm Limits in the ClearSCADA Guide to Server Administration).


Core Point Configuration Guide - Define Whether a Counter-Type Point's Limits can be Tuned (Defining Counter Point Details)

Define Whether a Counter-Type Point’s Limits can be Tuned

Many counter points support limit tuning. When supported, you can use the Tune Limits check box to define whether operators can tune a point’s alarm limits.

Tuning allows operators whose User Accounts are allocated the Tune Limits permission (see Allocating Security Permissions in the ClearSCADA Guide to Security) to temporarily alter the point’s alarm limits, using the Tune Alarm Limits pick action.

Use the feature to tune alarm limits during exceptional circumstances, for example, in bad weather conditions when a flood situation is known to exist—the alarm limits of a point can be tuned to help prevent unnecessary alarms being raised.

Example:

An error detected on some monitoring equipment is giving inaccurate readings for a particular counter-type point. As engineers are aware of the situation, there is no need to raise alarms, unless the point value changes unexpectedly or raises a genuine alarm.

To avoid unnecessary alarms being raised for the point, the alarm limits are tuned so that ClearSCADA ignores the inaccurate readings.

Once the equipment has been repaired, the tuning is removed.

ATTENTION: With points on outstations that support configuration downloads, the action of tuning a point’s limits triggers ClearSCADA to download configuration to the outstation on which that point is located (see Downloading Configuration Changes in the ClearSCADA Guide to Core Configuration).

If you choose not to allow the Tune Limits feature to be used, the alarm limits configured on the Point Form remain in force.

To define whether a point’s limits can be tuned:

  1. Display the Form for the counter-type point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the <Point Type> tab (for example, select the Counter Point tab for a DNP3 counter point).
  3. Either:
  • Select the Tune Limits check box to allow the point’s limits to be tuned.
    Users with the Tune Limits permission will be able to use the Tune Alarm Limits pick action to temporarily alter the point’s alarm limits.
  • Clear the Tune Limits check box if users are not permitted to tune the point’s limits.
    The alarm limits configured on the Point Form will be used by ClearSCADA, and cannot be temporarily overridden.
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Specify the Area of Interest Associated with a Point's State-Related Alarms and Events (Defining Counter Point Details)

Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events

If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed within the Alarm Limits section on the <Point Type> tab.

An Area of Interest field is displayed if the Area of Interest feature is enabled on your system.

Use the Area of Interest field to specify the area with which any state-related point alarms or events are to be associated.

If a point value exceeds a limit that is configured to generate an event or alarm, that event or alarm will be associated with this Area of Interest. As such, only users that have access to this Area of Interest will be aware of the event or alarm.

For more information on configuring Areas of Interest, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

NOTE: If the Multiple Point State Alarms feature is used to assign multiple ‘Point State’ alarm conditions to a counter-type point, a separate Area of Interest section is displayed on the <Point Type> tab. The section contains multiple Area of Interest fields—one for the ‘Normal’ state and one for each ‘Point State’ alarm condition (see Use Multiple Point State Alarms in Conjunction with Areas of Interest).


Core Point Configuration Guide - Define the Appearance of a Counter-Type Point's Values (Defining Counter Point Details)

Define the Appearance of a Counter-Type Point’s Values

You can use the Formatting section of counter-type Point Forms to define the appearance of a counter point’s values. The Formatting section is displayed on the <Point Type> tab.

The Units and Format that you choose will determine how the point’s value is shown on displays such as Lists, Mimics, Reports, and external applications. The format will help operators and other users to understand the significance of the point’s values.

To define the format of a counter-type point’s values:

  1. Display the Form for the counter-type point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the <Point Type> tab (for example, select the Counter Point tab for a DNP3 Counter point).
  3. Use the Units combo box to enter or select a type of measurement. The Units combo box is located in the Formatting section.

You can either highlight the existing entry and overwrite it with a new type of measurement, or you can choose a measurement from the units list (display the list using the arrow button).

The list of measurements can be customized for your system (see Define Standard Descriptions for Measurement Units in the ClearSCADA Guide to Server Administration).

  4. Select the browse button next to the Format field.
    The Text Format window is displayed.
  5. Use the Text Format window to choose and define the required type of formatting. For more information, see Choose a Format Category in the ClearSCADA Guide to Core Configuration.
  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define Whether a Counter-Type Point can be Overridden (Defining Counter Point Details)

Define Whether a Counter-Type Point can be Overridden

You can use the Point Form for a counter-type point to define whether the point’s value can be overridden. You can also define the range of valid override values.

The Override pick action allows users whose User Accounts are allocated the Override/Release permission for a point to define the value of that point. The override feature is useful when a known detected fault is resulting in an incorrect value being reported for a point—an operator can temporarily override the value back to a suitable value until the detected fault has been corrected. Overrides can also be used to simulate different plant states when testing the system.

However, you may require that a point value cannot be overridden. When the Override feature is disabled, ClearSCADA continues to use the point’s actual value—the value reported by the outstation, PLC, or other device on which the point is located—regardless of the state of that device.

To configure the override feature for a counter-type point:

  1. Display the Form for the counter point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the <Point Type> tab (for example, the Counter tab for a DNP3 Counter point).
  3. Use the Enabled check box in the Override section to define whether the point can be overridden:

Either:

  • Select the Enabled check box in the Override section to enable the Override feature.
    The Maximum and Minimum fields become available. Use the fields to define the override range (proceed to step 4).

Or:

  • Clear the Enabled check box to disable the Override feature.
    The Maximum and Minimum fields are grayed out. The point cannot be overridden (ignore step 4).
  4. Use the Maximum and Minimum fields to define the override range. The range defines the values that operators can enter to override the point—any value between and including the minimum amount and the maximum amount.
  1. In the Maximum field, enter the highest value that operators can use to override the point.
  2. In the Minimum field, enter the lowest value that operators can use to override the point.
  5. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator requests that a point is overridden (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

If you enable the Override feature, ensure that the point’s Override/Release security permission is suitably set (see Allocating Security Permissions in the ClearSCADA Guide to Security).


Core Point Configuration Guide - Detect whether a Counter-Type Point has Stopped Changing (Defining Counter Point Details)

Detect whether a Counter-Type Point has Stopped Changing

You can use the fields in the No Change section on a counter-type Point Form to specify whether ClearSCADA should raise an alarm or log an event if a point’s value stops changing.

For instance, you might want ClearSCADA to raise an alarm if a particular point’s value doesn’t change by a specified minimum amount for a defined period of time.

For information on configuring the No Change properties and examples showing how these properties might be configured, see Detect Whether a Point Value has Stopped Changing.

ATTENTION: With many protocols, in order to use the No Change feature on points that are on PSTN outstations, you need to ensure that ClearSCADA is configured to raise Alarms From Logged Data Only, or Most Recent Logged Data. With these options the current value reported at the beginning of a call does not inadvertently generate a No Change alarm or event. (For more information, see the ClearSCADA Guide to Advanced Drivers.)


Core Point Configuration Guide - Define a Counter-Type Point's Trend Settings (Defining Counter Point Details)

Define a Counter-Type Point’s Trend Settings

You can display the trend, or movement, of a counter-type point’s value in the form of a graph. The graph is referred to as a Trend. Up to two types of Trend are available per point, depending on the point configuration (see Types of Trend).

This section gives an Overview of a Counter-Type Point’s Trend and explains the Procedure for Configuring a Counter-Type Point’s Trend Settings.


Core Point Configuration Guide - Overview of a Counter-Type Point's Trend (Defining Counter Point Details)

Overview of a Counter-Type Point’s Trend
Trace
Y-Axis
X-Axis

Each Trend consists of an x-axis, a y-axis, and a trace. The x-axis displays a time interval, and the y-axis displays the measurement units. The Trace represents the counter point’s current or historic values.

You need to define the values of the Trend’s y-axis, and the default time period that is to be displayed for the Trend, so that a suitable range of units are shown. To do this, you need to use the fields in the Trend section of the counter-type Point Form’s <Point Type> tab (see Procedure for Configuring a Counter-Type Point’s Trend Settings).

For Historic Trends, you also need to use the fields on the counter-type Point Form’s Historic tab (see Define the Time Period Shown on Historic Trends and Lists).


Core Point Configuration Guide - Procedure for Configuring a Counter-Type Point's Trend Settings (Defining Counter Point Details)

Procedure for Configuring a Counter-Type Point’s Trend Settings

To configure a counter-type point’s Trend:

  1. Display the Form for the counter-type point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the <Point Type> tab (for example, select the Counter Point tab for a DNP3 counter point).
  3. Use the Trend section of the Form to define the range of the y-axis, and (for Current Trends only) the time interval of the x-axis:

NOTE: Trend properties vary for some counter-type points—see the driver-specific documentation for details.

  1. Enter the highest value to be shown on the y-axis in the Maximum field (within the Trend section).
  2. Enter the lowest value to be shown on the y-axis in the Minimum field (within the Trend section).
  3. For Current Trends, follow the steps below to define the offset for, and the time interval of, the x-axis, along with the update rate for the Trend data.

For Historic Trends and Lists, define the time interval of the x-axis using the Trend/List fields on the Historic tab of the Point Form (see Define the Time Period Shown on Historic Trends and Lists).

The steps below do not apply to Historic Trends.

  4. In the Offset field, specify the default start time for the x-axis, in relation to the present time, for whenever you view the data as a Current Trend.

Specify the offset in the OPC Relative Time Format. For example, M - 10M for the earliest time on the x-axis to be ten minutes before the beginning of the current minute. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

  5. In the Interval field, specify the default time interval for the x-axis, starting from the time specified in the Offset field, for whenever you view the data as a Current Trend.

Specify the interval in the OPC Time Format, for example 15M for the x-axis to display a 15-minute period. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required period.

  6. In the Update Rate field, specify the frequency with which the trace data on a Current Trend is updated.

Specify the frequency in the OPC Time Format, for example, 15S for the data to update at 15-second intervals. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required rate.

  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

X-Axis Interval
Maximum Y-Axis Range
X-Axis Offset
Minimum
Y-Axis Range

When a Current or Historic Trend is displayed for the point, the y-axis displays the range of values that remain within the Minimum value and Maximum value limits.

When a Current Trend is displayed, the Offset and Interval entries define the time period of the Trend, and the start time of the x-axis in relation to the present time.

Example:

The Interval of a Trend is set to 15M (15 minutes), and the Offset is M - 10M (10 minutes before the present minute).

If the Trend is displayed and the present time is 11:42:05, the time period displayed by the x-axis would be 11:32:00 to 11:47:00, as the present time is rounded back to the beginning of the present minute.

Further Information

Overview of a Counter-Type Point’s Trend.

For more information on Trends, see the ClearSCADA Guide to Trends.


Core Point Configuration Guide - Defining String Point Details

Defining String Point Details

Use a String Point within the ClearSCADA database to represent an internal point, or to retrieve or set the value of a property on another device or application, when that property has a textual string value, rather than a numeric value. For instance, to retrieve information on the present status of a printer that is attached to the system.

Configure each string point on your system by using the fields on the String Point Form. The Form has several tabs, which you use to define different aspects of point configuration. This section explains how to configure point properties that are common to many string points. You configure most of these properties on the String Point, and Control tabs of the appropriate String Point Form.

Use this section, along with the appropriate driver documentation, for information on configuring the string points on your system.

Use the fields on the String Point tab to:

  • Specify the Format Settings
  • Configure Override Settings.

If the point is a control device, use the fields on the Control tab to:

  • Define the Control Settings for a String Point.

If the point is an Internal point, use the Manual tab to:

  • Define the Manual Control Settings for an Internal String Point.

(In addition to internal string points, ClearSCADA also supports String Parameters and String Variables. The type of string that you add to ClearSCADA depends on the string’s intended functionality. For more information, see Parameters versus Points and Variables in the ClearSCADA Guide to Core Configuration.)


Core Point Configuration Guide - Format Settings (Defining String Point Details)

Format Settings

Use the Format field on the String Point tab to specify the format in which the point’s value appears in displays such as Lists.

Use the browse button next to the field to display the Text Format window and select the required format. For further information, see Defining the Format of Displayed Values in the ClearSCADA Guide to Core Configuration.


Core Point Configuration Guide - Configure Override Settings (Defining String Point Details)

Configure Override Settings

Use the fields within the Override section of the String Point tab to define whether the value of the point can be overridden.

The Override feature allows operators whose User Accounts are allocated the Override/Release permission to change (‘override’) the value of the point. An overridden point value replaces the value of the selected point in the ClearSCADA database. Typically, overrides are used when a known detected fault is resulting in an incorrect value being reported for a point.

To define whether a string point can be overridden:

  1. Use the Enabled check box to define whether the point can be overridden:

Either:

  1. Select the check box to allow the point to be overridden.
  2. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator requests that a point is overridden (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

or:

  1. Clear the check box if operators are not to have the ability to override the point.


Core Point Configuration Guide - Define the Control Settings for a String Point (Defining String Point Details)

Define the Control Settings for a String Point

Several drivers support string output points—points that are used to set text string values on other applications or devices. (The actual value is defined using the Control pick action, at the time that the control is requested.)

This section covers configuration of the standard control properties on the Control tab of the String Point Form. For fields not covered in this section, see the driver-specific documentation.

Use the fields on the Control tab to define whether the point is an output point and if so, the properties that are associated with any controls:

If the point is not an output point (it is only being used to retrieve string values):

  1. Clear the Enabled check box.
    The other fields on the Control tab will be ‘grayed out’ and unavailable for use.

If the point is an output point (a point that is being used to set string values):

  1. Select the Enabled check box.
    The other fields on the tab become available for use.
  2. Use the Severity combo box to define the severity of the event that is logged for each successful control action, and the severity of the alarm raised due to an unsuccessful control action. For more information, see Defining Severities in the ClearSCADA Guide to Core Configuration.
  3. If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Control tab. Use the field to specify the Area of Interest with which any control-related events and alarms are associated.

For more information on configuring Areas of Interest, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  4. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator attempts to send a control (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define the Manual Control Settings for an Internal String Point (Defining String Point Details)

Define the Manual Control Settings for an Internal String Point

Internal String Points are points that only exist within the master station software (see Internal Points).

To set the value of an Internal string point, you ‘hand control’ the point value. Specify the hand control properties using the fields on the Manual tab of the String Point Form:

  1. Either:
  • Select the Hand Control check box to enable operators whose User Accounts are allocated the Control permission to ‘hand control’ the value of the point, using the Hand Control pick action.

or:

  • Clear the Hand Control check box if the value of the Internal point is not to be controlled using the Hand Control pick action.

Logic or a data access application can be used to set the point’s CurrentValue property directly (see Internal Points).

  2. If the Hand Control check box is selected, use the Confirm combo box to specify whether a confirmation dialog box is displayed whenever an operator attempts to hand control the point (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  3. Either:
  • Select the Log Hand Control Events check box for ClearSCADA to log an event each time that the point’s value is set. This provides a historic record of when and by whom or what application the Internal point was hand controlled.

Be aware that if Logic or a data access application sets the point’s value, the severity with which that action is logged depends on the Severity that is specified for that application (see Internal Points).

or:

  • Clear the Log Hand Control Events check box if ClearSCADA is not to log any hand control events in the Event Journal.

ATTENTION: Clear an internal point’s Log Hand Control Events check box if an application sets the point’s value on a frequent basis. This will help to prevent ClearSCADA from logging numerous events relating to the point’s value being set.

  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Defining Time Point Details

Defining Time Point Details

Use a Time Point within the ClearSCADA database to represent an internal point, or to retrieve or set the value of a property on another device or application, when that property has a date/time value.

Configure each time point on your system by using the fields on the Time Point Form. The Form has several tabs, which you use to define different aspects of point configuration. This section explains how to configure point properties that are common to many time points. You configure most of these properties on the Time Point, and Control tabs of the Time Point Form.

Use this section, along with the appropriate driver documentation, for information on configuring the time points on your system.

Use the fields on the Time Point tab to:

  • Specify the Format Settings
  • Configure Override Settings.

If the point is a control device, use the fields on the Control tab to:

  • Define the Control Settings for a Time Point.

If the point is an Internal point, use the Manual tab to:

  • Define the Manual Control Settings for an Internal Time Point.

(In addition to internal time points, ClearSCADA also supports Time Variables. The type of database item that you add to ClearSCADA depends on that item’s intended functionality. For more information, see Variables in the ClearSCADA Guide to Core Configuration.)


Core Point Configuration Guide - Format Settings (Defining Time Point Details)

Format Settings

Use the Format field on the Time Point tab to specify the format in which the point’s value appears in displays such as Lists.

Use the browse button next to the field to display the Text Format window and select the required format. For further information, see Defining the Format of Displayed Values in the ClearSCADA Guide to Core Configuration.


Core Point Configuration Guide - Configure Override Settings (Defining Time Point Details)

Configure Override Settings

Use the fields within the Override section of the Time Point tab to define whether the value of the point can be overridden.

The Override feature allows operators whose User Accounts are allocated the Override/Release permission to change (‘override’) the value of the point. An overridden point value replaces the value of the selected point in the ClearSCADA database. Typically, overrides are used when a known detected fault is resulting in an incorrect value being reported for a point.

To define whether a time point can be overridden:

  1. Use the Enabled check box to define whether the point can be overridden:

Either:

  1. Select the check box to allow the point to be overridden.
  2. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator requests that a point is overridden (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

or:

  1. Clear the check box if operators are not to have the ability to override the point.


Core Point Configuration Guide - Define the Control Settings for a Time Point (Defining Time Point Details)

Define the Control Settings for a Time Point

Several drivers support Time Output Points—points that set time/date values on other applications or devices. (The actual value is defined using the Control pick action, at the time that the control is requested.)

This section covers configuration of the standard control properties on the Control tab of the Time Point Form. For fields not covered in this section, see the driver-specific documentation.

Use the fields on the Control tab to define whether the point is an output point and if so, the properties that are associated with any controls:

If the point is not an output point (it is only being used to retrieve time/date values):

  1. Clear the Enabled check box.
    The other fields on the Control tab will be ‘grayed out’ and unavailable for use.

If the point is an output point (a point that is being used to set time/date values):

  1. Select the Enabled check box.
    The other fields on the tab become available for use.
  2. Use the Severity combo box to define the severity of the event that is logged for each successful control action, and the severity of the alarm raised due to an unsuccessful control action.

For more information, see Defining Severities in the ClearSCADA Guide to Core Configuration.

  3. If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Control tab. Use the field to specify the Area of Interest with which any control-related events and alarms are associated.

For more information on configuring Areas of Interest, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  4. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator attempts to send a control (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration.)


Core Point Configuration Guide - Define the Manual Control Settings for an Internal Time Point (Defining Time Point Details)

Define the Manual Control Settings for an Internal Time Point

Internal Time Points are points that only exist within the master station software (see Internal Points).

To set the value of an internal time point, you ‘hand control’ the point value. Specify the hand control properties using the fields on the Manual tab of the Time Point Form:

  1. Either:
  • Select the Hand Control check box to enable operators that have the Control permission to ‘hand control’ the value of the point, using the Hand Control pick action.

or:

  • Clear the Hand Control check box if the value of the Internal point is not to be controlled using the Hand Control pick action.

Logic or a data access application can be used to set the point’s CurrentValue property directly (see Internal Points).

  2. If the Hand Control check box is selected, use the Confirm combo box to specify whether a confirmation dialog box is displayed whenever an operator attempts to hand control the point (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  3. Either:
  • Select the Log Hand Control Events check box for ClearSCADA to log an event each time that the point’s value is set. This provides a historic record of when and by whom or what application the Internal point was hand controlled.

Be aware that if Logic or a data access application sets the point’s value, the severity with which that action is logged depends on the Severity that is specified for that application (see Internal Points).

or:

  • Clear the Log Hand Control Events check box if ClearSCADA is not to log any hand controlled events in the Event Journal.

ATTENTION: Clear an internal point’s Log Hand Control Events check box if an application sets the point’s value on a frequent basis. This will help to prevent ClearSCADA from logging numerous events relating to the point’s value being set.

  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Defining Pulse Action Details

Defining Pulse Action Details

Pulse Actions are used to send a control to a device for a defined period of time, for example to start a motor. A pulse is a pulsed (rather than a maintained) digital output control.

Some drivers support pulse actions that have a single configurable control action. Outstations on some drivers support pulse actions that have two or three configurable control actions.

Example:

A one-action Pulse control sends an electrical pulse to a point that is connected to a control device. The pulse instructs a pump to start running.

You configure each pulse action on your system by using the fields on the appropriate Pulse Action Form. Each Form has several tabs, which you use to define different aspects of the pulse action configuration.

Use this section, along with the appropriate driver documentation, for information on configuring the pulse actions on your system.

This section covers configuration of standard fields on the Pulse Action tab of the Pulse Action Form (see Define the Actions that a Pulse Undertakes).

For fields not covered in this section, or in Promoting Scanning of Outstations Associated with Controls, see the driver-specific documentation.

NOTE: To display pulse action details in List format from the Queries Bar, filter the constraints on the Pulse Actions List.


Core Point Configuration Guide - Define the Actions that a Pulse Undertakes (Defining Pulse Action Details)

Define the Actions that a Pulse Undertakes

Use the fields within the Actions section of the Pulse Action tab to define the action(s) that can be undertaken by a pulse action point.

For each available action:

  1. Use the Severity combo box to define the severity of the event that is logged for a successful control action, and the severity of alarm raised due to an unsuccessful control action. (For more information, see Defining Severities in the ClearSCADA Guide to Core Configuration.)
  2. In the Description field, either enter a text description for each action, or use the combo box to select one of the pre-defined actions. (To add a pre-defined description to a server on your system, see Define Descriptions for Control Actions in the ClearSCADA Guide to Server Administration.)
  3. Use the Confirm combo box to define whether a confirmation dialog box is displayed whenever an operator attempts to send a control (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  4. If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Pulse Action tab. Use the field to specify the Area of Interest with which any pulse-related events and alarms are associated.

For more information on configuring Areas of Interest, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  5. If available for pulse actions on your drivers, use the fields in the Promote section of the tab to define whether any outstations are scanned in preference to others following a control request (see Promoting Scanning of Outstations Associated with Controls).
  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Detect Whether a Point Value has Stopped Changing

Detect Whether a Point Value has Stopped Changing

The No Change feature detailed in this section applies to analog and counter points and to points (other than Derived Points) that have analog- or counter-type processing.

You can use the fields within the No Change section on an Analog or Counter Point Form to specify whether ClearSCADA should raise an alarm or log an event if a point’s value stops changing.

For instance, you might want ClearSCADA to raise an alarm if a particular point’s value doesn’t change by a specified minimum amount for a defined period of time.

You can use the No Change feature to indirectly detect that an instrument has failed, by detecting that the instrument’s value is no longer changing. (Measurement of real physical processes often includes a small degree of random variation on the signal that is being measured. Some instruments indicate failure by ‘flat-lining’—producing a fixed unchanging signal without this random variation. The No Change feature can be used to check that a random variation in signal is no longer occurring.)

Example:

An incremental sensor is attached to a mechanical float.

A mechanical obstruction causes the instrument to fail.

When the instrument fails, the same reading is reported to ClearSCADA without any variation in value.

The No Change feature is used to detect whether changes in value have stopped occurring and to raise an alarm should this happen.

Once you Understand How the No Change Feature Works, use the fields within the No Change section of the Point Form to Configure the No Change Properties for an Analog or Counter Point.

For further examples that demonstrate how the No Change feature can be used, see Example Configuration.

ATTENTION: With many protocols, in order to use the No Change feature on points that are on PSTN outstations, you need to ensure that ClearSCADA is configured to raise Alarms From Logged Data Only, or Most Recent Logged Data. With these options the current value reported at the beginning of a call does not inadvertently generate a No Change alarm or event. (For more information, see the ClearSCADA Guide to Advanced Drivers.)

NOTE: The No Change feature is used to detect whether a point’s value has stopped changing but is still being updated, rather than whether a point has stopped updating.
To check whether a point has stopped updating, look at the ‘Last Updated’ status attribute on the point’s Status display. To ascertain whether more than one point has stopped updating, either display a Points List and sort or filter the List by ‘Last Updated’ time, or create a suitable report.


Core Point Configuration Guide - Understand How the No Change Feature Works (Detect Whether a Point Value has Stopped Changing)

Understand How the No Change Feature Works

The No Change feature works by checking whether a value has changed by more than a specified Deadband, within a specified time Interval.

If the value changes sufficiently within the Interval, ClearSCADA restarts its No Change checking process, from the instance at which it deems the point’s value to have changed sufficiently:

If a point value differs from the original value by more than the Deadband, ClearSCADA restarts its No Change checking process, from this instant on, and does not generate a No Change alarm or event.

If the point’s value does not change sufficiently throughout the Interval, when ClearSCADA processes the next point value, it will generate a No Change alarm or event for the point. ClearSCADA will also restart its No Change checking process, using the new point value and its update time as the basis. (Any No Change alarm will remain in force until ClearSCADA next detects that the point’s value has changed sufficiently, whereupon it will clear the alarm.)

If the values that ClearSCADA processes for the point do not differ from the original value by more than the Deadband, ClearSCADA generates a No Change alarm or event. It generates the alarm or event when it processes the next point value after the Interval has elapsed.


Core Point Configuration Guide - Configure the No Change Properties for an Analog or Counter Point (Detect Whether a Point Value has Stopped Changing)

Configure the No Change Properties for an Analog or Counter Point

To specify whether ClearSCADA is to raise an alarm or log an event in response to a point’s value not changing:

  1. Display the Form for the analog or counter point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the <Point Type> tab (for example, select the Analog Point tab for an analog point)
  3. Scroll to the No Change section of the tab.
  4. Use the Type combo box to specify whether ClearSCADA is to raise an alarm or log an event should the point’s value stop changing.

Choose from:

  • None—ClearSCADA does not raise an alarm or log an event if the point’s value stops changing.

The rest of the fields in the No Change section are ‘grayed out’ and unavailable for use. Proceed to step 10.

  • Absolute—ClearSCADA raises an alarm or logs an event if the point’s value does not change by more than the amount specified in the Deadband field.
  • Percentage of Span—Applies to analog-type points only. ClearSCADA raises an alarm or logs an event if the point’s value does not change by more than a defined percentage of its span. The span is the point range (Zero Scale to Full Scale). Specify the percentage in the Deadband field (see below).
  5. In the Deadband field, enter the amount or percentage by which the point has to change. If the point’s value does not change by more than the Deadband by the time that ClearSCADA processes the next point value after the Interval has elapsed, ClearSCADA raises an alarm or logs an event.

Specify zero for ClearSCADA to detect any change in value.

  6. In the Interval field, specify the time period against which ClearSCADA compares the difference in time stamps of the point values that it uses in its No Change checking process.

Enter the time in the OPC Time Format, for instance 1H for a one-hour period. You can enter the value directly in the Interval field, or use the Interval Window (accessed via the field’s browse button) to specify the required time period.

Whenever ClearSCADA processes a new point value, it compares the time that has elapsed between the new value and the point value against which it is performing its No Change checking. If this time is greater than the time specified in the Interval field, it raises an alarm or logs an event.

ClearSCADA restarts its No Change checking process whenever the difference in the two point values exceeds the Deadband amount or percentage.

  7. Use the left-hand Severity combo box to specify whether ClearSCADA is to generate an Alarm or Event if it deems that the point’s value has not changed.
  8. Use the right-hand Severity combo box to specify the severity level of the alarm or event that ClearSCADA is to generate (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  9. If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed within the No Change section of the tab.

Use the field to specify the Area of Interest with which any ‘No Change’ events or alarms are associated. For more information, see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

  10. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Understand How the No Change Feature Works.

Example Configuration.


Core Point Configuration Guide - Example Configuration (Detect Whether a Point Value has Stopped Changing)

Example Configuration

This section comprises several examples that demonstrate how the No Change feature might be used on a ClearSCADA system. The examples comprise:

  • No Change in Absolute Value
  • No Change in Span.


Core Point Configuration Guide - No Change in Absolute Value (Detect Whether a Point Value has Stopped Changing)

No Change in Absolute Value

This example demonstrates how the No Change feature can be used to check whether a counter point has changed by a specific amount during any 30-minute period.

Example:

A counter point is configured with these No Change properties:

Type: Absolute
Deadband: 5
Interval: 30M
Severity: Alarm, Low priority.

ClearSCADA will only deem the point value to have changed if its value changes by more than 5, over a 30-minute Interval.

Whenever the value does change by more than 5, ClearSCADA restarts its No Change checking process for the point.

If the point value does not change by more than 5 for over 30-minutes, ClearSCADA will raise a low priority alarm to indicate that the point has not changed sufficiently. ClearSCADA will also restart its No Change checking process for the point.

In this example, the counter’s value changes as follows:
Time | Value | Comments
09:05:00 | 24 | ClearSCADA starts its No Change checking process. It uses this time for the start of the Interval, and compares future values against this value to see whether they change by more than the Deadband of 5.
09:10:00 | 25 |
09:15:00 | 27 |
09:20:00 | 30 | As the value has changed by 6 (which is more than the Deadband) in the previous 15 minutes, ClearSCADA re-starts its checking process. It uses the new time and value as the basis against which to perform those checks.
09:25:00 | 30 |
09:30:00 | 30 |
09:35:00 | 30 |
09:40:00 | 31 |
09:45:00 | 32 |
09:50:00 | 32 |
09:55:00 | 33 | As the value has only changed by 3 in the last 35 minutes (and as such, has remained within the Deadband for longer than the specified Interval), ClearSCADA raises a No Change alarm. It also re-starts its checking process, using the new time and value as the basis against which to perform those checks.
10:00:00 | 36 |
10:05:00 | 40 | As the value has changed by more than the Deadband of 5 in the last 10 minutes, ClearSCADA clears the No Change alarm and re-starts its checking process. It uses this time and value as the basis against which to perform its checks.
... |  |

Further Information

Configure the No Change Properties for an Analog or Counter Point.


Core Point Configuration Guide - No Change in Span (Detect Whether a Point Value has Stopped Changing)

No Change in Span

This example demonstrates how the No Change feature can be used to check whether an analog point has changed by a specific percentage of its overall point range during any one-hour period.

Example 2 - No Change in Span:

An analog point has configuration that includes these Limits:
Full Scale: 80
Zero Scale: 0

and these No Change properties:
Type: Percentage of Span
Deadband: 10
Interval: 1H
Severity: Alarm, Medium priority.

The No Change Deadband is 10% of the full point range of 0 to 80. Therefore, ClearSCADA will only deem the point value to have changed if its value changes by more than 8, over a one-hour Interval.

Whenever the value does change by more than 8, ClearSCADA restarts its No Change checking process for the point.

If the point value does not change by more than 8 for over an hour, ClearSCADA will raise a medium priority alarm to indicate that the point has not changed sufficiently. ClearSCADA will also restart its No Change checking process for the point.

In this example, the analog’s value changes as follows:
Time | Value | Comments
09:00:00 | 54.0 | ClearSCADA starts its No Change checking process. It uses this time for the start of the Interval, and compares future values against this value to see whether they change by more than the 10% Deadband of 8.
09:12:04 | 53.2 |
09:27:13 | 55.1 |
09:46:23 | 57.3 |
10:02:00 | 58.0 | As the value has only changed by 4 in the last 62 minutes (and as such, has remained within the Deadband for longer than the specified Interval), ClearSCADA raises a No Change alarm. It also re-starts its checking process, using the new time and value as the basis against which to perform those checks.
10:21:48 | 56.1 |
10:37:12 | 52.9 |
10:45:00 | 49.0 | As the value has changed by more than the Deadband value of 8 in the last 43 minutes, ClearSCADA clears the No Change alarm and re-starts its checking process. It uses this time and value as the basis against which to perform its checks.
... |  |

Further Information

Configure the No Change Properties for an Analog or Counter Point.


Core Point Configuration Guide - Defining Historic Details for a Point

Defining Historic Details for a Point

This section explains how to configure the Historic details for a point. It describes the Historic features that are common to points that can store historic data.

You can use the Historic tab of the Point Configuration Forms to define the Historic storage features of an individual point.

Historic tab

When Historic is enabled, the point’s values are stored in the database as historic values. The historic values provide a record of the point’s data, and are of particular use when monitoring the value of a point over time, or, for example, when trying to establish the origin of a detected fault relating to a point.

Points other than string points, time points, and pulse actions support historic storage.

To enable your system to store point data historically, and to define how long that data is retained, see Historic Data Storage Settings in the ClearSCADA Guide to Server Administration.

Additionally, you need to enable and configure the Historic feature for each point for which you require values to be stored historically.

To enable a point to store values historically:

  1. Display the relevant Point Form.
  2. Select the Historic tab.
  3. Enable Historic (see Enable or Disable Historic Data Storage).
  4. Define any Historic Data Compression.
  5. Define the Time Period Shown on Historic Trends and Lists.

If a point’s data is not to be stored historically:

  • Disable Historic (see Enable or Disable Historic Data Storage).


Core Point Configuration Guide - Enable or Disable Historic Data Storage (Defining Historic Details for a Point)

Enable or Disable Historic Data Storage

If you want ClearSCADA to keep a historical record of a point’s values, you need to enable the Historic feature for that point. Points do not have the Historic feature enabled by default.

You can use the Enabled check box on the Historic tab of a Point Form to define whether the Historic feature is active.

ATTENTION: Your system specification determines the amount of historic data that can be stored. If you use the Historic feature on too many points, the performance of the system will be affected. (To set the historic storage specifications for your system, see Historic Data Storage Settings in the ClearSCADA Guide to Server Administration.)

To enable or disable the historic feature:

  1. Display the Form for the point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Historic tab on the Point Form.
  3. Either:
  • Select the Enabled check box.
    Point values will be stored historically in accordance with the other properties on the Historic tab.
    Select the Enabled check box on the Point Form (a Digital Point Form is shown).

Or:

  • Clear the Enabled check box.
    The other fields on the Historic tab become unavailable.

The ClearSCADA database will only store point values that meet specific criteria, such as End of Period values, in addition to current point values.

If you enable the historic feature, you need to define any Historic Data Compression and Define the Time Period Shown on Historic Trends and Lists.

ATTENTION: With points on some drivers, ‘Historic Data Filter’ properties are used to define the type of reported point data that ClearSCADA is to store historically for those points. With such points, reported point values are only stored historically if historic is enabled on the point’s Historic tab, and at least one option is selected within the Historic Data Filter section of the Point Form. The driver-specific guides provide details about any points that have Historic Data Filter properties.

If you disable the historic feature, you need to save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration). Any existing online historic data for the point will be deleted.


Core Point Configuration Guide - Historic Data Compression (Defining Historic Details for a Point)

Historic Data Compression

You can use the Compression section of a Point Form’s Historic tab to define the criteria for historic processing and storage.

You can use compression to:

  • Reduce storage requirements for historic data
  • Reduce the amount of historic data that ClearSCADA needs to process. (Excessive historic updates might effect system performance.)

Compression works by filtering out unnecessary data, such as small changes, or values that are reported in quick succession. You can choose to compress just the current values for a point and retain all other values in full, or compress all point values (see Apply Historic Data Compression Settings).

If you need to retain every point value historically, you need to:

  • Disable Historic Data Compression.

A comprehensive point history is often required by reporting applications.

Compression is generally used with points that are on simple drivers rather than advanced drivers. Outstations on many advanced drivers have the ability to filter historic data before passing it to the server and therefore additional Compression filtering is often not required for those points.

Scanners on simple drivers typically support current data only. Outstations on advanced drivers typically store time stamped (logged) data, in addition to processing current data. (Current data is the present state or value of a point at the instance that the ClearSCADA server requests current data from the outstation or scanner.)

To store point data historically in ClearSCADA, you enable historic storage on that Point Form’s Historic tab. If Logged Data is enabled for that point, ClearSCADA typically stores only logged (rather than current) values historically for the point. If Logged Data is not enabled (or supported) for that point, ClearSCADA will store only current point values historically. Some points on advanced drivers also have Historic Data Filters that you can use to further limit the data that ClearSCADA stores historically.

Refer to the relevant driver documentation for further information on the data that can be logged or retrieved for each point type, and any filtering that each outstation or scanner can undertake on that data.

If you choose to use Compression (see Apply Historic Data Compression Settings) to limit the number of values that ClearSCADA stores historically, ClearSCADA only applies the compression if certain attributes remain unchanged between point updates (see Point Updates to which Compression Settings do not Apply). When ClearSCADA does apply the compression to point data, it stores only those updates that meet the pre-defined and user-defined compression criteria—values that do not meet the criteria are excluded from historic storage.

Be aware that when point values are compressed, ClearSCADA retains the last point value that it did not store historically due to that compression. It does this in case the next value that it is to store historically does not meet the compression criteria. If the next value does not meet that criteria, ClearSCADA then stores both values historically. This helps to ensure that the values that ClearSCADA stores historically for a point provide an accurate representation of that point’s movements.

Example:

ClearSCADA is to compress the data that it is to store historically for a point.

Significant changes in point value are excluded from compression and stored historically. Additionally, ClearSCADA also stores the last point value that it processes prior to each significant change in point value. (This also applies to any other changes that are excluded from compression—ClearSCADA stores those point values historically, and also stores the value that it processes prior to each of those values.)

(If ClearSCADA were to only store significant changes in point value historically, whenever such values were, for example, displayed as a historic Trend, the interpolation in the trend between the stored values might not accurately reflect the known values of the point, and therefore might be misleading.)

When ClearSCADA compresses historic data, in addition to storing values that have changed significantly...
...it also stores the last value that it processed prior to each significant change...
...in order to produce an accurate representation of the point’s movements (as shown by this trace).
If ClearSCADA were to store only values that have changed significantly...
...the trace of such records would produce an inaccurate representation of the point’s movements.


Core Point Configuration Guide - Point Updates to which Compression Settings do not Apply (Defining Historic Details for a Point)

Point Updates to which Compression Settings do not Apply

If you Apply Historic Data Compression Settings to a point, ClearSCADA compares the update that it last stored historically for the point and the next update that is marked for compression. If any of the following point attributes differ between the two values, ClearSCADA ignores any Compression settings and automatically stores the latest update historically:

  • State
  • Quality
  • The Reason for the point update (for example, Timed Report, or Current Update)

ClearSCADA typically stores point updates that change due to an Override or Release Override pick action, as the reason for these updates typically differs from the reason for the previously stored value.

  • Status
  • M/S State (only applies to analog points that are on systems on which Master Station Alarm Limits are enabled).

Additionally, ClearSCADA also stores any ‘out of sequence’ data historically. Out of sequence data comprises values that are time stamped with an earlier time to the previously stored value.

You can determine why ClearSCADA has stored an update historically, by looking at the Historic List for the point. Each of the above attributes are displayed in separate columns on the List. (If Master Station Alarm Limits are enabled and used for the analog points on your system, the ‘State’ column on the Historic List displays the Master Station State, rather than the ‘standard’ point State.)

The entries in the Time, State, Quality, Reason, and Status columns indicate why ClearSCADA has stored a point update historically, regardless of Compression settings.

For further information on Historic Lists, see Historic Lists in the ClearSCADA Guide to Lists.


Core Point Configuration Guide - Apply Historic Data Compression Settings (Defining Historic Details for a Point)

Apply Historic Data Compression Settings

You can use the Compression section of a Point Form’s Historic tab to define the criteria for historic processing and storage.

You can use compression to:

  • Reduce storage requirements for historic data
  • Reduce the amount of historic data that ClearSCADA needs to process. (Excessive historic updates might effect system performance.)

If you enable compression, you can specify which point values can be omitted from historic storage, so that only some values are retained historically. (If you need to retain every point value historically, either for use in ViewX or for use by another application, you should Disable Historic Data Compression.)

Typically, use compression if a point’s data is only retained historically to provide an overview of the values, for example, an overview of the point’s values over a week.

You typically only use compression with points that are on simple drivers—outstations on advanced drivers generally have the ability to filter historic data before passing that data on to the ClearSCADA server (see Historic Data Compression).

To enable and configure the compression properties for a point:

  1. Display the Point Form for the point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Historic tab.
  3. Ensure that Historic is enabled (see Enable or Disable Historic Data Storage).

ATTENTION: With points on some drivers, ‘Historic Data Filter’ properties are used to define the type of reported point data that ClearSCADA is to store historically for those points. With such points, reported point values are only stored historically if historic is enabled on the point’s Historic tab, and at least one option other than ‘None’ is selected within the Historic Data Filter section of the Point Form. The driver-specific guides provide details about any points that have Historic Data Filter properties.

  4. Select the required option from the Apply To combo box within the Compression section. Choose from:
  • All Data—ClearSCADA compresses all of the data that it stores historically for this point, with the exception of any Point Updates to which Compression Settings do not Apply.
  • Current Data Only—ClearSCADA only compresses the current data that it stores historically for this point. (Be aware that on points on which Logged Data storage is enabled, ClearSCADA typically stores only logged data historically—see the driver documentation for more details.)

ClearSCADA does not compress any other data that it stores historically for the point. Nor does it compress any Point Updates to which Compression Settings do not Apply.

Compression features are available when the Apply To field is set to an option other than ‘No Data’.

  5. Use the Significant Change combo box to choose a type of significant change. If a value is deemed to have changed significantly, ClearSCADA will store that value historically. Significant Change compression only applies to the type of point data that is specified in the Apply To field (see above):
  • Absolute—The value of the point has to change by a defined amount for it to be stored historically.

You define the amount by which the value has to change in the field that is next to the Significant Change combo box.

  • Percentage of Span—The value of the point has to change by a defined percentage of the span if it is to be stored historically. The span is the point range (Zero Scale to Full Scale).

You define the percentage in the field that is next to the Significant Change combo box.

  • Percentage of Value—The value of the point has to change by a defined percentage of the last stored value if it is to be stored historically.

You define the percentage in the blank field that is next to the Significant Change combo box.

  6. Enter the value or percentage in the field next to the Significant Change combo box.
    Enter the value or percentage in the field.

  7. Use the Minimum Interval field to define the minimum amount of time between the values that ClearSCADA is to store historically and compress for this point.

The interval applies only to values that are of the type listed in the Apply To field (see above). ClearSCADA stores all occurrences of other types of point value historically, regardless of frequency.

  8. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Example:

An analog point has the following configuration:

Range: Zero Scale 0, Full Scale 80.
Apply To: All Data
Significant Change: Percentage of Span, with a deadband of 10%.
Minimum Interval: 15 seconds.

At 05:09:30 the point has a value of 41 that is stored historically.

At 05:10:08 the point has a value of 50. The value has increased by more than 10% of the point’s range, and has been reported more than 15 seconds after the previous historic value. As the new value meets the compression criteria for the point, it is stored historically.

At 05:10:10, the value of the point changes to 60. This new value is not stored historically the increase in value of 5 is not equal to, or greater than 10% of the range (10% of the range is 8, as the range is 0-80).

At 05:10:11, the value of the point changes to 63. The value is not stored historically as although the point value has changed by more than 10% of the span, the Minimum Interval time has not elapsed.

At 05:10:27, the point value changes to 62. The value is stored historically as it meets the compression criteria for the point. The increase in value is greater than 10% of the span (the increase since the last logged value is 12), and the Minimum Interval time has elapsed (there is more than 15 seconds between the last logged value - 05:10:08 - and the current value - 05:10:27).


Core Point Configuration Guide - Disable Historic Data Compression (Defining Historic Details for a Point)

Disable Historic Data Compression

You might decide not apply historic data compression to a point:

  • If historic storage space is not a concern
  • The source of the historic data is controlled (for example, the point is polled at a slow rate, or the updates are from logged data in an outstation)
  • You need to retain every value for a particular point.

Typically, you do not apply compression if the historic updates for the point are not excessive and:

  • A point’s historic data is used by reporting or analysis applications

Or:

  • You need an exact record of the point’s values.

(Apply Historic Data Compression Settings if a point’s historic values are only used to provide an overview of the data; you want to reduce storage requirements for historic data; or excessive historic updates are effecting system performance.)

To disable the compression feature for a point:

  1. Display the Point Form for the point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Historic tab.
  3. Set the Apply To field in the Compression section of the Point Form to ‘No Data’.

    The Significant Change and Minimum Interval features are unavailable.
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Core Point Configuration Guide - Define the Time Period Shown on Historic Trends and Lists (Defining Historic Details for a Point)

Define the Time Period Shown on Historic Trends and Lists

The historic values of a point can be displayed on a Trend (by selecting the Display Historic Trend pick action), or on a Historic List (by selecting the Display Historic List pick action).

Use the properties within the Trend/List section of the Point Form’s Historic tab to define which time period of data is included on Historic Trends and Lists by default. Also use the section to specify any processing that ClearSCADA is to undertake when presenting the data as a Historic Trend.

To define the above properties for a point:

  1. Display the Point Form for the point that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Historic tab.
  3. Ensure that Historic is enabled (see Enable or Disable Historic Data Storage).

ATTENTION: With points on some drivers, ‘Historic Data Filter’ properties are used to define the type of reported point data that ClearSCADA is to store historically for those points. With such points, reported point values are only stored historically if historic is enabled on the point’s Historic tab, and at least one option other than ‘None’ is selected within the Historic Data Filter section of the Point Form. The driver-specific guides provide details about any points that have Historic Data Filter properties.

  4. Specify the start time of the Historic Trend/List in the Offset field.

Specify the time in the OPC Relative Time Format. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

The Historic Trend or Historic List will only show historic values that were logged after the start time defined by the Offset.

  5. Specify the amount of time shown on the Historic Trend/List in the Interval field.

Specify the time in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required period.

For the Historic Trend, the Interval is the amount of time shown on the X-Axis.

For the Historic List, the Interval is the amount of time shown on the List. For example, an Interval of 1H means that the List only displays one hour’s worth of historic data.

Example:

For this example, we will assume the current time is 11:30.

A point is configured with these settings:

Offset: H-23H
Interval: 1D

The Display Historic Trend option is used to display the Historic Trend for the point.

The Historic Trend displays the historic values of the point between 12:00 yesterday and 12:00 today. As now is 11:30, the x-axis interval begins at 12:00 yesterday, as the offset and interval settings result in the latest time shown on the axis being rounded forward to the nearest hour.

  6. Select the Relative to Latest check box if the x-axis of a Historic Trend is to be relative to the latest data that is used in the Trend.

Clear the Relative to Latest check box if the x-axis is to be relative to the current time.

  7. Select the Use Raw Data check box if the trace on a Historic Trend is to display raw input data for the point. Raw data comprises the actual data values, as reported or read from the device that the point represents.

Clear the Use Raw Data check box if the trace is to display processed point data. This is the default for historic Trends. Processed data comprises the result of calculations on the raw data, either to produce interpolated data (to obtain readings between the raw values), or to calculate the average of a number of raw data values.

Processed data offers maximum flexibility for the Trend. For example, when displaying a large time scale, such as a year, each screen pixel might represent several raw data values. With a processed Trend, ClearSCADA calculates the average value of those raw values and displays a processed or summary value for each pixel.

When zooming in to display a very small time scale on a Trend, such as 60 seconds, only a few raw data values might be visible at such a scale. With a trace that uses processed data, ClearSCADA will linearly interpolate between the raw values, to produce a trace that includes both interpolated (calculated) values as well as the actual values that were reported or read from plant.

  8. Use the Stepped Mode check box to specify whether Trends and data calculations linearly interpolate (calculate) between the actual data values.

Leave the check box clear (the default for analog- and counter-type points) for the data to be linearly interpolated.

With interpolated data, ClearSCADA linearly calculates the values between the actual recorded data.

Select the check box (the default for digital-type points) for the data to be stepped.

With stepped data, ClearSCADA assumes each value remains unchanged until the next recorded value.

  9. Use the Total Multiplier field to specify the amount by which ClearSCADA is to multiply the results of time integrated calculations, such as Total and Time Average. (Total and Time Average calculations integrate the sample data over time. They can be used, for instance, to convert flow rates into total delivered quantities.)

The Total Multiplier can be used to correct the scale of totalized values, should those values be calculated from raw data values that represent quantity transferred within a time unit.

Use a Total Multiplier of 1 if the time base is in seconds.

Example:

On a particular ClearSCADA system, an analog point is used to measure dosing rate in liters per minute. A Total Multiplier of 0.0166666 (1 divided by 60) is used to scale the result of the Total and Time Average calculations to liters.

  10. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

NOTE: To define the time period that is shown on a current Trend, see Define an Analog Point’s Trend Settings, or see Define a Digital Point’s Trend Settings, as applicable.


Core Point Configuration Guide - Promoting Scanning of Outstations Associated with Controls

Promoting Scanning of Outstations Associated with Controls

This section applies to Pulse, Output and Computed points that are on outstations other than PSTN-only or exception outstations.

On some drivers you can promote the scanning of outstations that are associated with a control request. To do this, you use the Promote section on a Point’s Form to specify those outstation(s) that provide feedback on the success (or otherwise) of a control request. You also specify the duration for which ClearSCADA is to promote the scanning of those outstations. Whenever ClearSCADA sends a control request to that particular point, it gives those outstations scanning priority for the specified duration. This scanning ‘promotion’ enables the driver to retrieve the outstations’ data at a more frequent rate, allowing the data on, for example, Lists and Mimics, to be updated sooner. The primary purpose of this feature is to provide control feedback for operators.

Use the fields within the Promote section of the Control tab (Point Form), or the Pulse Action tab (Pulse Action Form), to specify whether any outstations are promoted following a control action request:

  1. Either:
  • Select the Enabled check box if any outstations are to be scanned more frequently than other outstations following a control request.
    The other fields within the Promote section become available for use.
  • Clear the Enabled check box if outstations are not to be given any scanning preference following a control request. Proceed to Step 4.
    The other fields within the Promote section become unavailable for use.
  2. Use the Outstations fields to promote up to five outstations that provide feedback on the success of a control request for the point. For each outstation that is to be promoted, use the browse button to display a Reference browse window, and select the outstation that you require.

You can choose any outstation on your system that supports promotion. This may include a simple driver point source (scanner), if that source supports fast rate scanning.

Additionally, for a point on an advanced driver:

  3. Use the Duration field to specify the amount of time for which the outstation(s) are to remain promoted, following a control request. After this period, the outstations are scanned in turn and are no longer scanned in preference to others.
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Define the Control Settings for an Analog Output Point.

Define the Control Settings for a Digital Output Point.

Define the Actions that a Pulse Undertakes.


Core Point Configuration Guide - Multiple Point State Alarms

Multiple Point State Alarms

Many point types, such as analog and counter-type points, can support Multiple Point State Alarms. The Multiple Point State Alarms feature allows each type of point to have a user-defined number of ‘Point State’ Alarm Conditions, and to associate each state of a point with one of these conditions.

When the Multiple Point State Alarms feature is not used (the default on many systems), each point has a single ‘Point State’ Alarm Condition, which is active when the value of the point is outside of the Normal operating range for that point. For instance, once an analog point value rises above the High limit, or falls below the Low limit, the ‘Point State’ Alarm Condition for that point becomes active.

When the Multiple Point State Alarms feature is used for a particular point type, every point of that type will include all of the configured Alarm Conditions. This is regardless of a point’s specific configuration, within which only some of the Alarm Conditions might be used (any Alarm Conditions that are not used on a particular point will remain inactive).

So, for instance, the High state of an analog point might be associated with Alarm Condition ‘A’, and the High High state of the same point with Alarm Condition ‘B’. (The names of multiple ‘Point State’ Alarm Conditions are user configurable.) Under certain circumstances, multiple ‘Point State’ Alarm Conditions might be active simultaneously for a point. For instance, when the analog point mentioned above is in the High High state, both Alarm Condition ‘A’ and Alarm Condition ‘B’ are active. (If a further Alarm Condition, ‘C’, is configured, but is not used on this particular analog point, then Alarm Condition ‘C’ will remain inactive on that point.)

By default, the Multiple Point State Alarms feature is not enabled on a ClearSCADA system. To set up Multiple Point State Alarms for a particular type of point, use the Point State Alarms section of the ClearSCADA Server Configuration Tool (see Point State Alarms in the ClearSCADA Guide to Server Administration). Once enabled for a particular point type, an additional Alarm column is displayed within the Alarm Limits section of the Point Form for that type of point (see the example below). Use the Alarm field that corresponds to each limit to specify the particular ‘Point State’ Alarm Condition that is to be associated with that limit. (You can specify different combinations of Alarm Conditions for each point.)

Be aware that additional fields are displayed on the Point Form if you Use Multiple Point State Alarms in Conjunction with Areas of Interest.

Example:

Three ‘Point State’ Alarm Conditions are configured for the analog points on the DNP3 driver (the point type CDNP3AnalogIn). The Alarm Conditions are labelled A, B, and C.

As a result, an extra Alarm column is displayed within the Alarm Limits section of the Point Form for each DNP3 analog input point.

The Alarm combo box for each limit is used to select the required Alarm Condition for that limit. So, for the DNP3 analog input point shown below, the Full Scale, Zero Scale, and Invalid states are designated as level ‘A’ alarms; the High High and Low Low states as level ‘B’ alarms; and the High and Low states as level ‘C’ alarms.

An extra Alarm column and corresponding fields are displayed when Multiple ‘Point State’ Alarm Conditions are enabled for a point type. The name of each Alarm Condition is user configurable (A, B, and C in this example).

Each limit is associated with a separate ‘Point State’ Alarm Condition. As such, when the value of the point rises past the High limit, the ‘Point State C’ Alarm Condition becomes active.

If the value of the point continues to rise past the High High limit, the ‘Point State C’ Alarm Condition remains active; additionally, the ‘Point State B’ Alarm Condition becomes active, and so both Alarm Conditions are now active.

The present status of each Alarm Condition is listed in the Status display for the point:

When Multiple ‘Point State’ Alarm Conditions are enabled for a point, the present status of each Alarm Condition appears as a separate entry in the Status display for that point. The name of each Alarm Condition is user configurable (A, B, and C in this example).


Core Point Configuration Guide - Use Multiple Point State Alarms in Conjunction with Areas of Interest (Multiple Point State Alarms)

Use Multiple Point State Alarms in Conjunction with Areas of Interest

ClearSCADA’s Area of Interest feature enables users’ alarm and event access to be limited, so that each user is only made aware of those alarms and events that are of interest to them. By default, the Area of Interest feature is not enabled on a ClearSCADA system.

If this feature is enabled on your system, for any point types that have Multiple Point State Alarms, an Area of Interest field will be displayed on the corresponding Point Form, for each separate Alarm Condition. You use the ‘Normal’ Area of Interest field to specify the Area of Interest that is associated with any events that are logged whenever a point enters its ‘Normal’ operating range. Use the other Area of Interest fields to specify the Area of Interest that is associated with each Alarm Condition. (The name of each field corresponds to the name of the Alarm Condition.)

So, when used in conjunction with the Multiple State Alarms feature, you can use the Area of Interest feature to filter the alarms and events that are seen by each user on a per-limit basis (rather than on a per-item basis, which you can do through standard ClearSCADA security).

Example:

The Area of Interest feature is enabled on a particular ClearSCADA system. The Area of Interest hierarchy is arranged as follows:

Central control engineers are allocated the Area of Interest that is associated with their particular Control Center. This gives them access to the alarms and events for that center, along with those that are generated for the regions and specific areas overseen by that center.
Regional engineers are allocated the Area of Interest that is associated with their particular region. This gives them access to the alarms and events for that region, along with those that are generated for the specific areas within that region.
Operators are allocated the Area of Interest that is associated with their particular area (for instance, S3). This gives them access to the alarms and events for that area. They are unaware of any alarms or events that occur in any other areas or regions.

The Area of Interest feature is used in conjunction with the Multiple Point State Alarms feature to report point state alarms to a wider group of users, the further from ‘normal’ each point’s state becomes.

The system communicates with several DNP3 outstations.

Three ‘Point State’ Alarm Conditions are configured for the analog points on the DNP3 driver (the point type CDNP3AnalogIn). The Alarm Conditions are labelled Center, Region, and Area.

Within the Alarm Limits section of the Point Form for each DNP3 analog point, the Alarm combo box is used to select the required Alarm Condition for each limit:

An Area of Interest field is displayed on the DNP3 Analog Point Form for each of the defined ‘Point State’ Alarm Conditions. The fields are used to associate each Alarm Condition with an Area of Interest:

In this particular example:

  • Alarms that are assigned the ‘Area’ Alarm Condition are allocated the ‘S3’ Area of Interest—this Area of Interest includes any events and alarms to which S3 operators have access. (In this example, S3 operators are also given access to any events that are logged while the point is in its ‘Normal’ operating range.)
  • Alarms that are assigned the ‘Region’ Alarm Condition are allocated the ‘Southern Region’ Area of Interest—this Area of Interest includes any alarms or events to which both S1 operators and Southern regional engineers have access.
  • Alarms that are assigned the ‘Center’ Alarm Condition are allocated the ‘Control Center 2’ Area of Interest—this Area of Interest includes any alarms or events to which S1 operators, Southern regional engineers, and Control Center 2 engineers have access.

As such, different levels of user are notified, depending on Area of Interest associated with each alarm or event.

Further Information

The Area of Interest Feature: see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.


Alarms Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Alarms Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Alarms Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Alarms Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Alarms Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Alarms Guide - Document Scope (About the Guide)

Document Scope

This guide describes ClearSCADA’s alarm handling capabilities. It explains the various displays from which you can access alarms and the activities that can be performed on those alarms.

The guide also summarizes the various alarm-related aspects of system configuration and explains how to:

  • Set up your system’s alarm preferences
  • Specify default alarm filtering
  • Add additional data columns to Alarms Lists and the Alarm Banner.

For more information, see Welcome to the Guide to Alarms.

NOTE: For information on alarm redirection, see the ClearSCADA Guide to Alarm Redirection.


Alarms Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for any user that works with alarms or needs to configure alarm settings.


Alarms Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Alarms Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Lists

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Mimics

ClearSCADA Guide to Logic

ClearSCADA Guide to Scripting

ClearSCADA Guide to Security

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


Alarms Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Alarms Guide - Welcome to the Guide to Alarms

Welcome to the Guide to Alarms

Welcome to the ClearSCADA Guide to Alarms. This guide:

  • Explains what comprises an alarm (see Understand Alarms)
  • Explains the various ways in which ClearSCADA raises your awareness of alarms on your system, including:
  • Activities that Occur when an Alarm is Raised
  • The Alarm Banner
  • Alarms Lists
  • Understand the Information that is Displayed on an Alarms List or Alarm Banner
  • Alarms on Other Displays.
  • Summarizes the types of action that can be performed on alarms (see Perform an Action on an Alarm).
  • Explains the other activities you can perform when using Alarms Lists and the ViewX Alarm Banner:
  • Adjust the Columns on an Alarms List or the Alarm Banner
  • Use the Filter Window to Filter Alarm Entries
  • Sort the Entries in an Alarms List or the Alarm Banner.

For engineers that are configuring ClearSCADA, this guide also summarizes the various Alarm-Related Aspects of System Configuration, including how to:

  • Specify a Default Alarm Filter
  • Set up the Alarms, Alarms Lists, and Alarm Banner Preferences
  • Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client
  • Configure Additional Alarm Columns.


Alarms Guide - Understand Alarms

Understand Alarms

An alarm is an indication of an abnormal condition detected by the ClearSCADA system. For instance, items in your database may be configured to operate within certain limits, and if an item returns values that are outside those limits, an alarm might be raised. When an alarm is raised, its occurrence is indicated in several ways, including those shown below (see Activities that Occur when an Alarm is Raised).

Alarms are shown on the Alarms List and can also be shown on other Lists. Typically, Mimics are configured to contain animated representations of alarms so that you can view and manage alarms from a Mimic.
The Alarm Bell button indicates the number of alarms on your system.
Alarms are added to the Alarm Banner. This is the primary display for alarms on a ViewX client.

When an alarm is raised, you should take the appropriate action (see Perform an Action on an Alarm). Typically, you should acknowledge the alarm and then ensure that the abnormal condition that caused the alarm is rectified (if possible). Once ClearSCADA detects that the alarm condition is no longer present, it will clear the alarm.

Your user account settings, security permissions and so on, may restrict the alarms to which you have access. This is to help ensure that you are only made aware of alarms that might be of interest to you.

The rest of this section includes information on:

  • Activities that Occur when an Alarm is Raised
  • Alarm Severity, Status, and Category.

For further information on alarms, see the other sections in the rest of this guide.


Alarms Guide - Activities that Occur when an Alarm is Raised (Understand Alarms)

Activities that Occur when an Alarm is Raised

When an abnormal condition is detected, ClearSCADA typically raises an alarm. In ViewX, when an alarm is raised:

  • An entry is usually added to the Alarm Banner and Alarms Lists. The entry indicates, alongside other things, the Alarm Severity, Status, and Category.

(The exceptions to this are if an alarm is suppressed by another active alarm, or alarms are disabled for the item. A suppressed or disabled alarm will not appear in Alarms Lists or the Alarm Banner. For more information on alarm suppression, see Configure any Alarm Suppression Requirements in the ClearSCADA Guide to Core Configuration. For more information on disabled alarms, see Disable Alarms and Enable Alarms.)

  • If the alarm is not suppressed or disabled, the alarm count increments on the Alarm Bell Button. The color of the button also changes, to indicate the presence of unacknowledged alarm(s). The color change also occurs whenever an alarm is suppressed.
  • If configured to do so, the audible bell sounds (see Audible Alarms), providing that the alarm is not disabled or suppressed. This helps to ensure that you are made aware of the alarm as soon as possible.
  • An entry is logged in the Event Journal (also referred to as the Events List) (see Events in the ClearSCADA Guide to ViewX and WebX Clients).

In the case of suppressed alarms, the type of alarm suppression is indicated.

A further entry is logged in the Event Journal should such a suppressed alarm become unsuppressed, or a disabled alarm become enabled. The unsuppressed or enabled alarm also appears in Alarms Lists and the Alarm Banner. In each case, the Alarms List and Alarm Banner entry is time stamped with the original alarm receipt or occurrence time (or, on systems on which the Use Visible Time As Alarm Active Time feature is enabled, the time that the alarm became unsuppressed or enabled).

For further information on Events List entries, see Alarm-Related Entries in the Events List.

For information on the Use Visible Time As Alarm Active Time feature, see Define whether the Visible Time is used as the Active Alarm Time in the ClearSCADA Guide to Server Administration.

  • The item’s change in Alarm State is indicated on displays such as:
  • The item’s Status display (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients)
  • Any Mimics that are configured to depict the item and its alarm state (see Alarms on Mimics)
  • Any other displays that include the item.
  • If the Alarm Redirection feature is used, additional activities might occur. For instance, the alarm might be forwarded automatically to an on-call engineer's pager. Any automatic redirection might occur as soon as the alarm is raised, or after a pre-configured amount of time—for example, should the alarm not be acknowledged within a certain time period. Additional entries are logged in the Events List whenever an alarm is redirected (see Alarm-Related Entries in the Events List).

When an alarm is raised, decide what action you need to take to have the cause of the alarm investigated and the abnormal condition rectified (see Perform an Action on an Alarm). If configured for the item or the Group in which it is located, you can also use the Display Alarm View option to display the ‘file object’ that is associated with the item’s alarm state.


Alarms Guide - Alarm Severity, Status, and Category (Understand Alarms)

Alarm Severity, Status, and Category

Each alarm has an:

  • Alarm Severity level that indicates the importance of the alarm.
  • Alarm Status that indicates whether the alarm has been acknowledged and whether the alarm conditions are still in effect.
  • Alarm Category that indicates the type of alarm.

You need to understand the different values of each of the alarm properties listed above, especially the severity and status, as these provide important information that you can use to determine what you need to do about the alarm (see Perform an Action on an Alarm).


Alarms Guide - Alarm Severity (Understand Alarms)

Alarm Severity

Each alarm has a severity level that defines the importance of the alarm. You can use the severity level to help you determine the order in which you should investigate raised alarms.

The range of possible severities is configurable on a per system basis. Additionally, your User Account may be configured to provide access only to those alarms that have specific severity levels. This helps to ensure that you are only made aware of alarms in which you are interested.

The default alarm severities are:

When deciding which alarms to investigate first, you need to take into account both the severity and Alarm Status.

For example, an alarm with Low severity can be more important than an alarm with High severity if the Low severity alarm is unacknowledged and uncleared, and the High alarm has been acknowledged or cleared. (An acknowledged alarm typically indicates that someone is aware of the alarm’s existence and its cause is under investigation. A cleared alarm means that the abnormal condition that caused the alarm is no longer apparent.)

Further Information

Perform an Action on an Alarm.

The severity of individual alarms is configured on a per item/per alarm basis (see the relevant configuration section).

System-wide severity settings: see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.


Alarms Guide - Alarm Status (Understand Alarms)

Alarm Status

Each alarm has a status that indicates whether the abnormal condition that triggered the alarm is still in effect and whether the alarm has been acknowledged by a user. The possible alarm statuses are:

  • Unacknowledged Uncleared—The condition that triggered the alarm still exists. The alarm entry has not been acknowledged.

Unacknowledged Uncleared alarms are deemed to be the most important alarms as no users have responded to them.

When a Unacknowledged Uncleared alarm occurs, you need to decide whether to acknowledge that alarm, attach an Alarm Response message to the alarm without acknowledging the alarm, or inform others of the alarm’s occurrence (see Perform an Action on an Alarm).

  • Acknowledged Uncleared—The condition that triggered the alarm still exists. The alarm entry has been acknowledged, indicating that a user is aware of the alarm. This status typically indicates that the abnormal condition is either being investigated, is scheduled for investigation, or is a known detected fault.

To aid others when acknowledging alarms, you can optionally choose to enter a comment about the acknowledged alarm (see Acknowledge an Alarm with Comment).

Should an alarm be acknowledged unintentionally, you may be able to unacknowledge the alarm (see Unacknowledge an Alarm).

  • Unacknowledged Cleared—The condition that triggered the alarm no longer exists, therefore ClearSCADA has cleared that particular item’s alarm flag. The entry that indicates that the alarm has cleared has not been acknowledged.

Once an alarm is both acknowledged and cleared, it is automatically deleted from the Alarms Lists and Alarm Banner.

You can view an alarm’s status on a variety of displays including the Alarm Banner and Alarms Lists. Each item’s Status display shows the alarm status of the most important alarm that is raised for the item—the alarm with the highest severity (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients).

Color is also used to indicate the alarm status. The default color scheme for alarms is:

  • Red (Flashing)—Unacknowledged Uncleared alarm.
  • Green (Flashing)—Unacknowledged Cleared alarm.
  • Brown—Acknowledged Uncleared alarm.

(Your system may be configured to use a different color scheme.)

The alarm colors are used on the Alarm Banner, Alarms Lists, and Queries Lists (see Lists in the ClearSCADA Guide to ViewX and WebX Clients) and can also be used to indicate alarms on animated Mimics (see Mimics in the ClearSCADA Guide to ViewX and WebX Clients).

Further Information

Status attributes that represent an alarm status display one of a series of Standard Alarm States.

Understanding Alarm Conditions: see Understanding Alarm Conditions and Subconditions in the ClearSCADA Guide to Alarm Redirection.

Configure the Alarm Colors: see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.


Alarms Guide - Alarm Category (Understand Alarms)

Alarm Category

Each alarm has a Category that indicates the type of alarm. You can filter Alarms Lists or the Alarm Banner so that they only display alarms of a specific category. For example, so that they only display ‘Channel Status’ alarms.

The alarm categories include:

  • Archive Volume—Alarms that have been raised in relation to the archive volume (the media to which data is being archived). For example, the archive volume being full.
  • Archiving—Alarms that have been raised to indicate problems that have been detected with data archiving.
  • Callback—Alarms that have been raised due to an outstation or similar device not reporting back within the callback time.

When you perform a Callback action on an outstation, the outstation should report to the ClearSCADA server within a pre-defined time, referred to as the callback time. If the outstation does not report within this time, an alarm is raised.

  • Channel Status—Alarms that have been raised to indicate problems that have been detected with the availability of a communications channel. For example, channels on which communications has been interrupted unexpectedly.
  • Control Status—Alarms that have been raised due to controls being unsuccessful. For example, controls that were unsuccessful due to communications being interrupted between the ClearSCADA server and the outstation to which the server was attempting to send the control requests.
  • Dial In Overactive—Alarms that have been raised due to PSTN outstations dialing in more often than expected.
  • File Upload Status—Alarms that have been raised to indicate errors detected with file upload activity, such as outstation data not uploading successfully into ClearSCADA.
  • Forecast—Alarms that have been raised to indicate that a Forecast database item has a value that exceeds one of its alarm limits.
  • Interface Alarm—Alarms that have been raised by an external application, using the SetInterfaceAlarm method. The SetInterfaceAlarm method is purely for use with the Automation Interface.
  • Outstation Comms—Alarms that have been raised due to an outstation or similar device being unable to communicate with the ClearSCADA server.
  • Outstation Error—Alarms that have been raised due to general errors being detected on an outstation or similar device. This category is for outstation alarms that are not included in any of the other outstation categories.
  • Outstation Hardware—Alarms that have been raised to indicate that component errors, such as the battery being low, have been detected in an outstation. This category is limited to those outstations that can provide data about their hardware, such as Kingfisher outstations.
  • Point Error—Alarms that have been raised due to miscellaneous errors being detected on points.
  • Point No Change—Alarms that have been raised due to a point’s value not having changed by a specified amount for a defined period of time. Such alarms only apply to points that are configured to use the No Change feature.
  • Point State—Alarms that have been raised due to a point’s value changing and causing the point to change state. For example, a point state alarm is raised when an analog point’s value rises above one of its alarm limit thresholds (defined in its configuration).
  • Scanner Status—Alarms that have been raised to indicate problems that have been detected with a scanner or point source (simple drivers). For example, a scanner being offline.
  • Scheduled Dial In—Alarms that have been raised to indicate unexpected scheduled dial ins, or scheduled dial ins that did not occur when expected.
  • Server Status—Alarms that have been raised to indicate problems detected with a server or channel (simple drivers).
  • System Alarm—Generic alarms that relate to system-wide problems that have been detected. For example, licenses expiring.
  • Unknown Dial In—Alarms that have been raised due to an unknown PSTN outstation dialing-in to ClearSCADA.

There may also be further categories relating to specific drivers—for information on any alarm categories not listed above, see the Driver Reference Suite.


Alarms Guide - Alarm Banner

Alarm Banner

The Alarm Banner is the primary alarm display on a ViewX Client. The Alarm Banner is displayed at the bottom of the ViewX window by default and comprises the Alarm Bell Button and the Alarm Banner List.

Alarm Bell Button
Alarm Banner List

The Alarm Banner List provides information about alarms in the same manner as the Alarms Lists. The Alarm Banner List displays alarm information using a series of columns (see Understand the Information that is Displayed on an Alarms List or Alarm Banner). Your user account settings, security permissions and so on, may restrict the alarm entries to which you have access. This is to help ensure that you are only made aware of alarms that might be of interest to you.

By default, the entries in the Alarm Banner List are ordered by State, Severity, and then Time. This results in the most recently raised Unacknowledged Uncleared alarms of the highest severity appearing at the top of the Alarm Banner. This is followed by any Unacknowledged Uncleared alarms of the next highest severity, again in chronological order. Following on from Unacknowledged Uncleared alarms are any Unacknowledged Cleared alarms in severity and then time order, and then finally any Acknowledged Uncleared alarms in severity and then time order. The alarm entries are also colored to indicate their Alarm Status.

If you select (highlight) an alarm in the Alarm Banner, ClearSCADA will attempt to retain the selected alarm’s position relative to the Alarm Banner’s visible display area, regardless of other alarm activity. As such, if you select a visible alarm in an Alarm Banner that is only large enough to show a few alarms at once, the selected alarm will remain on display regardless of the number of other alarms that are raised or cleared while that alarm remains selected.

As with Alarms Lists, you can right-click on an entry in the Alarm Banner List to display a context sensitive menu.

Generic Alarm Banner options.
Alarm-specific options.

You can select an option from the menu to:

  • Perform an Action on an Alarm
  • Locate the database item with which the alarm is associated, or view other displays associated with that item (see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients)
  • Perform various Alarms Banner actions. For information, see:
  • Use the Filter Window to Filter Alarm Entries. (The Filter option is only available from the Alarm Banner if the Can Filter Alarm Banner feature is enabled on your User Account.)
  • Reset the Filters on an Alarms List or the Alarm Banner
  • Sort the Entries in an Alarms List or the Alarm Banner. (This option is only available if Alarm Banner sorting is enabled on a ViewX client.)
  • Reset the Sort Order on an Alarms List or the Alarm Banner
  • Adjust the Columns on an Alarms List or the Alarm Banner.

If Alarm Banner scripts are used on your system, additional ‘custom’ options may be available from the Alarm Banner’s context sensitive menu. See a system administrator for the documentation associated with such custom actions.

If your User Account is configured to allow you to select multiple alarms and you display the context sensitive menu while more than one alarm is selected, a subset of menu options is shown.

Further Information

Move the Alarm Banner.

Audible Alarms.

Remove the Alarm Banner.

Display the Alarm Banner.

Use Alarm Banner scripts to optionally add ‘custom’ actions to the Alarm Banner’s context sensitive menu: see Alarm Banner Scripts in the ClearSCADA Guide to Scripting.

Display a full screen Alarm Banner on a multi-head ViewX client: see Configure a Head to Show a Full Screen Alarm Banner in the ClearSCADA Guide to Client Administration.


Alarms Guide - Audible Alarms (Alarm Banner)

Audible Alarms

If the Alarm Bell is enabled, your system repeats an audible sound whenever a new alarm is raised. The sound ceases whenever you select the Alarm Bell Button to acknowledge that you are aware of the new alarm.

The audible alarm bell is designed to distract you from any other tasks so that the alarm becomes the focus of your attention. In some circumstances, the alarm bell sound can be an inappropriate distraction—for example, if the new alarms have Low priority and their immediate investigation is less urgent than the task you are performing. For this reason, your User Account may be configured to allow you to disable the audible alarm bell.

To disable the audible alarm:

  1. Right-click on the Alarm Bell Button.
    A context sensitive menu is displayed.
  2. Select the Disable Bell option.
    The audible alarm bell is de-activated—there is no sound when an alarm is raised.

To restore the alarm bell sound, repeat this procedure but select the Enable Bell option (which replaces the Disable Bell option).

NOTE: The audible bell does not sound for alarms that are omitted from alarm displays due to an item’s alarm feature being disabled or suppressed. For more information on either of these features, see Disable Alarms and Enable Alarms, and see Alarm Suppression.


Alarms Guide - Alarm Bell Button (Alarm Banner)

Alarm Bell Button

The Alarm Bell button is displayed on the left-hand side of the Alarm Banner and indicates the number of alarms to which you have access on your system.

The number of unacknowledged alarms.
The number of alarms.

Whenever a new alarm is raised, the Alarm Bell Button is colored red. This color provides a visual indication that a new unacknowledged alarm exists. The Alarm Bell Button is also colored red if a new alarm is suppressed by another alarm being active (see Alarm Suppression).

If configured to do so, an audible alarm bell will sound whenever a new alarm is raised, unless that alarm is suppressed (see Audible Alarms). (If alarms are disabled for an item that has gone into an alarm state, this has no effect on the Alarm Bell Button.)

Select the Alarm Bell Button once you have checked the new alarm—the button’s color will change to gray and any audible bell sound will cease until another unacknowledged alarm is raised.

The bottom number on the Alarm Bell Button shows the total number of unsuppressed alarms that currently exist in your area of the system. (The area to which your User Account provides access (taking into account any additional filtering you may have requested (see below)).)

The top number is the number of unacknowledged unsuppressed alarms that currently exist in your area of the system.

(Neither alarm count increments if an alarm is raised but suppressed. However, the count does increment should an existing suppressed alarm become unsuppressed.)

If you use the Filter window to filter the entries that appear in the Alarm Banner (see Use the Filter Window to Filter Alarm Entries):

  • The Alarm Bell Button displays an ‘F’ while such a filter is in place.
  • The number of alarms and unacknowledged alarms takes into account the filter criteria.
    An ‘F’ indicates that additional filtering is in place. The numbers indicate the number of alarms and unacknowledged alarms that meet the filter criteria.

Select the Reset Filter option from the Alarm Banner’s context sensitive menu to remove any filters that you have applied.


Alarms Guide - Move the Alarm Banner (Alarm Banner)

Move the Alarm Banner

If your User Account has the Can Move Banner feature enabled, you can choose whether to move the Alarm Banner to either the top or bottom of the ViewX window.

To move the Alarm Banner:

  1. Right-click on the Alarm Bell Button.
    A context sensitive menu is displayed.
  2. Select the Move To Top option.
    The alarm banner will now display at the top of the ViewX window.

If required, you can move the Alarm Banner to the bottom of the ViewX window by repeating this procedure and selecting the Move To Bottom option instead of the Move To Top option.

Further Information

Alarm Bell Button.

Audible Alarms.

Remove the Alarm Banner.

Display the Alarm Banner.


Alarms Guide - Remove the Alarm Banner (Alarm Banner)

Remove the Alarm Banner

The Alarm Banner is displayed on most ViewX clients by default. Although we do not recommend it (as you may not become aware of new alarms on the system), you can remove the Alarm Banner so that it is not on display.

You can only remove the Alarm Banner if your User Account is assigned the Can Remove Banner privilege.

To remove the Alarm Banner:

  1. Either:
  1. Select the Alarm Banner’s Close button.
    Close button.

or:

  1. Select the View menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Alarm Banner option so that the entry is no longer prefixed by a check mark.

or:

  1. Right-click on the toolbar, menu, or status bar area.
    A context sensitive menu is displayed.
  2. Select the Alarm Banner option so that the entry is no longer prefixed by a check mark.

The Alarm Banner is removed.

Further Information

Move the Alarm Banner.

Display the Alarm Banner.


Alarms Guide - Display the Alarm Banner (Alarm Banner)

Display the Alarm Banner

If your User Account enables you to View Alarms, and you want to view the Alarm Banner, but it is not on display:

  1. Either:
  1. Select the View menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Alarm Banner option so that the entry is prefixed by a check mark.
    Check marks indicate which components (such as the Alarm Banner) are on display.

or:

  1. Right-click on the toolbar, menu, or status bar area.
    A context sensitive menu is displayed.
  2. Select the Alarm Banner option so that the entry is prefixed by a check mark.

or:

  1. Press the CTRL and B keys simultaneously.

The Alarm Banner is displayed.

Further Information

Move the Alarm Banner.

Remove the Alarm Banner.


Alarms Guide - Alarms Lists

Alarms Lists

When an alarm is raised in ClearSCADA, an entry is usually added to the Alarms Lists and the Alarm Banner (the exceptions to this are if the alarm is suppressed by another alarm, or the alarm is disabled). The alarm’s occurrence may also be indicated on other displays, such as Mimics and Trends, and by an audible bell (see Activities that Occur when an Alarm is Raised).

Your user account settings, security permissions and so on, may restrict the alarms to which you have access. This is to help ensure that you are only made aware of alarms that might be of interest to you.

When an alarm is raised, you should take the appropriate action (see Perform an Action on an Alarm). Typically, you should acknowledge the alarm and then ensure that the abnormal condition that caused the alarm is rectified (if possible). Once ClearSCADA detects that the alarm condition is no longer present, it will clear the alarm.

This section is specific to Alarms Lists. You can display an Alarms List on a ViewX or WebX Client. You can view a general list of alarms, or view a list of the alarms that are associated with an individual item or group. (The latter type of Alarms List contains the same type of information as the former, but pre-filters the entries to include only those alarms that apply to the selected item or group.)

As with other alarm displays, Alarms Lists provide information about each alarm, and use color to indicate alarm status (see Alarm Status).

The data in Alarms Lists updates in real time.

If you select (highlight) an alarm on an Alarms List, ClearSCADA will attempt to retain that selected alarm’s position relative to the Alarms List’s visible display area, regardless of other alarm activity. As such, if you select a visible alarm on an Alarms List that only has a small display area, that selected alarm will remain on display, regardless of the number of other alarms that are raised or cleared while that alarm remains selected.

The rest of this section explains how to:

  • Display a Client-Wide Alarms List
  • Display the Alarms List for an Item or Group.

As with other Lists and the Alarm Banner, you can right-click on an entry on an Alarms List to display a context sensitive menu. (On a ViewX client, your User Account may be configured to allow you to select multiple entries.)

Alarm-specific options.
Generic Alarms List options.

Select an option from the menu to:

  • Perform an Action on an Alarm
  • Locate the database item on which the alarm is associated, or view other displays associated with that item (see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients)
  • Perform various Alarms List actions. For information, see:
  • Use the Filter Window to Filter Alarm Entries
  • Reset the Filters on an Alarms List or the Alarm Banner
  • Sort the Entries in an Alarms List or the Alarm Banner
  • Reset the Sort Order on an Alarms List or the Alarm Banner
  • Adjust the Columns on an Alarms List or the Alarm Banner.

Further Information

For information on alarms in general, including alarm severity, status, and category, see Understand Alarms.

How to interpret the information that the Alarms Lists provide: see Understand the Information that is Displayed on an Alarms List or Alarm Banner.

Various properties affect the way in which alarm information is presented on a ClearSCADA system. Many of these properties can be configured by system administrators and high-level engineers. For information, see Alarm-Related Aspects of System Configuration.

Display a full screen Alarms List in ViewX: see Use a ViewX Command to Display a Full Screen Alarms List in the ClearSCADA Guide to Client Administration.


Alarms Guide - Display a Client-Wide Alarms List (Alarms Lists)

Display a Client-Wide Alarms List

You can display an Alarms List that includes alarms:

  • On the ClearSCADA databases to which a particular ViewX or WebX client is connected

and:

  • To which your User Account has access.

This client-wide Alarms List displays similar information to the Alarm Banner (see Alarm Banner).

To display such a list of alarms on a ViewX client, either:

  1. Select the Alarms button [image] on the Operate Toolbar.

Or:

  1. Select the View menu from the ViewX menu bar.
    A drop-down menu is displayed.
  2. Select the Alarms option.

Or:

  1. Press the F9 function key.

An Alarms List is displayed.

The Alarms List shows the alarms that are raised on the system(s) to which a particular client is connected. It also includes any alarms have cleared but have not yet been acknowledged (see Alarm Severity, Status, and Category). The List only includes alarms for the areas of the system to which you have access (providing those alarms are not suppressed).

If required, you can filter the Alarms List so that it only displays a subset of these alarms (see Display the Alarms List for an Item or Group, or see Use the Filter Window to Filter Alarm Entries).

You can also display an Alarms List on a WebX client (see View and Action Alarms on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients).

Further Information

Display the Alarms List for an Item or Group.

Each User Account can be assigned a Default Alarm Filter. This can be used to pre-filter the alarm entries, so that only those alarms that are of interest to the individual user are included on Alarms Lists and the Alarm Banner (see Specify a Default Alarm Filter). Such default filtering is applied in addition to any other settings that may restrict the alarms to which a user has access (see Alarm-Related Aspects of System Configuration).


Alarms Guide - Display the Alarms List for an Item or Group (Alarms Lists)

Display the Alarms List for an Item or Group

You can display an Alarms List that is pre-filtered automatically to show only those alarms for a specific item or Group. You can display such an Alarms List from:

  • The Database Bar (see Display a List from the Database Bar in the ClearSCADA Guide to Lists)
  • From another display, such as a Mimic or another List (see Display a List from another Display in the ClearSCADA Guide to Lists).

In either case, use the Display Alarms menu option or pick action to display the required Alarms List. The List will be filtered automatically so that it only shows those alarms for the selected item or group, and for which your User Account has access. If you select a Group folder, the Alarms List also shows the alarms for the items within that folder and its subfolders.

Be aware that a Default Alarm Filter can be assigned to your User Account, so that only alarms in which you are interested are included in any Alarms List. When used, ClearSCADA automatically applies the default filter in addition to any other settings that may restrict the alarms to which you have access (see Alarm-Related Aspects of System Configuration).


Alarms Guide - Alarms on Other Displays

Alarms on Other Displays

In addition to Alarms Lists and the Alarm Banner, various other displays in ClearSCADA also indicate whether an item is in alarm. Such displays include Mimics, Status displays, Queries Lists, and Events Lists. The rest of this section contains information about:

  • Alarms on Mimics
  • Alarm-Related Entries in the Events List.

NOTE: A Mimic or other display might indicate that an item is in alarm, without such an alarm appearing in the Alarms List or Alarm Banner. This occurs if access to that particular alarm be restricted by, for example, alarm suppression or alarm redirection (see Restrict Alarm Access). Such restrictions allow you to be aware of the alarm situation, but not perform an action on that particular alarm. You can typically only Perform an Action on an Alarm if that alarm appears in an Alarms List or the Alarm Banner.

Further Information

Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Queries Lists: see Queries Lists in the ClearSCADA Guide to Lists.


Alarms Guide - Alarms on Mimics (Alarms on Other Displays)

Alarms on Mimics

Mimics often contain animated items that indicate when an alarm is raised. Typically, this involves an item changing color. It may also include some other type of animation, such as movement or a change in size. Mimic animations are designed to attract your attention so that you are aware of any alarms and can evaluate the situation quickly.

Example:

A Mimic may be configured to display alarms, for example the buttons with red text in the Mimic shown below.

Mimics can contain embedded Alarms Lists and/or hyperlinks to Alarms Lists.

Embedded Alarms List

With an embedded Alarms List, you select an entry in the List to display the context sensitive menu for that particular alarm. Use the menu’s options as you would those on any Alarms Lists. You can also filter and sort the entries in an embedded Alarms List—for more information, see Use the Filter Window to Filter Alarm Entries, and see Sort the Entries in an Alarms List or the Alarm Banner.

Some Mimics might be configured as Alarm Views. Such views can be used as an aid when alarms occur. Use the Display Alarm View option to access to such a view.

Further Information

Displaying Mimics that are Stored in the Database in the ClearSCADA Guide to Mimics.

View a Mimic on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.

Working with Mimics: see Operating a Mimic in the ClearSCADA Guide to Mimics.

Mimics and Alarms Lists:

  • see Embed an Alarms List on a Mimic in the ClearSCADA Guide to Mimics.
  • see Filter an Embedded Alarms List in the ClearSCADA Guide to Mimics.
  • see Creating a Hyperlink to an Alarms List in the ClearSCADA Guide to Mimics.


Alarms Guide - Alarm-Related Entries in the Events List (Alarms on Other Displays)

Alarm-Related Entries in the Events List

Events Lists provide an audit trail of activity on your system. Events that are recorded in an Events List include those that relate to alarm activity. Alarm-related entries are displayed using the appropriate Severity color (see The Color of Entries in a List other than the Alarms List in the ClearSCADA Guide to Lists). In each case, the entry’s Source indicates the Group, Group Instance, or item with which the event is associated.

Alarm-related activities that are recorded in the Event Journal (Events List) include:

  • Alarm raised—Logged to indicate the occurrence of an unacknowledged uncleared alarm. Along with other information, the entry indicates the cause of the alarm and the item with which the alarm is associated (see Understand Events Lists in the ClearSCADA Guide to Lists).

The entry is appended with the text (Suppressed Consequential) or (Suppressed Maintenance) should the alarm be suppressed due to the existence of another active alarm. Suppressed alarms are not shown in Alarms Lists or the Alarm Banner, but do appear on other displays (see Alarm Suppression).

  • Alarm <original alarm message> unsuppressed—Logged due to a suppressed alarm becoming unsuppressed. An alarm becomes unsuppressed should the abnormal condition that caused the alarm still exist, but the ‘parent’ alarm that caused the suppression clears.
  • Alarm <original alarm message> redirected to <name of redirection action>—Logged due to an alarm being redirected using an Alarm Redirection Action (see the ClearSCADA Guide to Alarm Redirection).
  • Alarm <original alarm message> priority changed from <old severity level> to <new severity level>—Logged due to an alarm being redirected using a Change Priority alarm redirection action (see Change Priority Action in the ClearSCADA Guide to Alarm Redirection).
  • Alarm <original alarm message>, responsibility assigned to <User, User Group, or ViewX workstation>—Logged to indicate the name of the User, User Group, or ViewX workstation(s) with the ability to acknowledge this particular alarm. This type of entry indicates that either:
  • The alarm has been redirected using a Set Responsibility Action alarm redirection action (see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection)

or:

  • The ability to acknowledge the alarm has been restricted by either the SetAlarmResponsibleUser, or SetAlarmResponsibleWorkstation methods. Both of these methods are associated with the CAlarmObject and CGroup database tables. For more information, see the database Schema.
  • Alarm redirections matching group <redirection group> canceled—Logged due to the CancelRedirections method being used to cancel any alarm redirections that are associated with a particular Redirection Group. In addition to this entry, entries are also logged for each individual Alarm Redirection Action that was canceled due to the CancelRedirections method being triggered. For more information, see CancelRedirections and RestartRedirections Methods in the ClearSCADA Guide to Alarm Redirection.
  • Alarm <original alarm message>, alarm redirection <name of redirection action> canceled—Logged due to the CancelRedirections method being used to cancel alarm redirections. One event message is logged per canceled Alarm Redirection Action.
  • Alarm redirections matching group <redirection group> restarted—Logged due to the RestartRedirections method being used to restart any previously canceled alarm redirections that are associated with a particular Redirection Group. In addition to this entry, entries are also logged for each individual Alarm Redirection Action that was restarted due to the RestartRedirections method being triggered. For more information, see CancelRedirections and RestartRedirections Methods in the ClearSCADA Guide to Alarm Redirection.
  • Alarm <original alarm message>, alarm redirection <name of redirection action> restarted—Logged due to the RestartRedirections method being used to restart previously canceled alarm redirections. One event message is logged per restarted Alarm Redirection Action.
  • Alarm <original alarm message>, responsibility assignment removed—Logged due to either:
  • A Set Responsibility Action alarm redirection being revoked. This will typically be due to a further Set Responsibility Action being triggered, to remove the restriction set by a previous Set Responsibility Action.

or:

  • The ClearAlarmResponsibility method being used to remove the restriction on which User, User Group, or ViewX workstation(s) had the ability to acknowledge the original alarm. The ClearAlarmResponsibility method is associated with the CAlarmObject and CGroup database tables. For more information, see the database Schema.
  • Alarm <original alarm message> acknowledged—Logged due to an existing alarm being acknowledged. The User column indicates the user that acknowledged the alarm. This might be a user that is logged onto the system, or a built-in internal ‘user’, such as a Logic program (see Understand Events Lists in the ClearSCADA Guide to Lists).

The entry is appended with a comment if it was logged due to an Acknowledge with Comment action.

  • Alarm <original alarm message> unacknowledged—Logged due to a previously acknowledged alarm being unacknowledged. The User column indicates the user that unacknowledged the alarm.

The entry is appended with a comment if it was logged due to an Unacknowledge with Comment action.

  • Alarms disabled—Logged due to the Disable Alarms action being used to disable (hide) alarms on a particular item or group of items.
  • Alarms enabled—Logged due to the Enable Alarms action being used to enable (register) alarms on a particular item or group of items.
  • Alarm <original alarm message> removed—Logged due to an acknowledged alarm being removed. The User column indicates the user that removed the alarm.

The entry is appended with a comment if it was logged due to a Remove with Comment action.

  • Alarm cleared—Logged due to an existing uncleared alarm clearing. An alarm clears once the abnormal condition that raised the alarm no longer exists.

The entry is appended with the text (Suppressed Consequential) or (Suppressed Maintenance) if the alarm cleared while it was suppressed (see Alarm Suppression).

Further Information

Alarm Redirections and Redirection Actions: see the ClearSCADA Guide to Alarm Redirection.

Events and Events Lists: see the ClearSCADA Guide to Lists.


Alarms Guide - Perform an Action on an Alarm

Perform an Action on an Alarm

When an alarm is raised on your system, you need to decide what to do about it. This can involve using ViewX to change the alarm’s status, as well as taking action to investigate the cause of the alarm, for example contacting an engineer to check the piece of equipment that is registering the alarm.

To action an alarm:

  1. Perform one of the following:
  • Right-click on the alarm in the Alarm Banner. (The Alarm Banner can only be displayed on a ViewX Client.)
  • Right-click on the alarm on an Alarms List (see Alarms Lists).
  • On an appropriate Queries List, right-click on the item for which the alarm has been raised. For example, if the alarm is associated with a point, right-click on the point on the relevant Points List, or Objects List (see Queries Lists in the ClearSCADA Guide to Lists).
  • On a Mimic, either:
  • Click on the representation of the item for which the alarm has been raised (see Alarms on Mimics). (This option only applies if the item on the Mimic is configured to display an Object menu.)
  • Click on the relevant entry on a List embedded on the Mimic.
  • In the Database Bar, right-click on the item for which the alarm has been raised. (The Database Bar can only be displayed on a ViewX Client.)

A context sensitive menu is displayed. The menu includes any alarm actions to which you have access.

  2. Select the action you want to perform on the alarm.

The actions that are available vary depending, for example, on your User Account permissions and the alarm’s state. Access to the Acknowledge and Acknowledge with Comment actions might be further restricted for alarms on some database items (see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection).)

Typical actions include:

  • Acknowledge or Acknowledge Alarms—Acknowledge an Alarm.
  • Acknowledge With Comment—Acknowledge an alarm and associate it with a brief text description (see Acknowledge an Alarm with Comment).
  • Disable Alarms—Withhold alarms for an item. You may want to disable alarms when a device that has been detected as faulty is causing nuisance alarms, or a device has been decommissioned (see Disable Alarms and Enable Alarms).
  • Enable Alarms—Allow alarms to be raised for an item (see Disable Alarms and Enable Alarms).
  • Response or Alarm Response—Record a response to an alarm without acknowledging it (see Respond to an Alarm).
  • Remove or Remove Alarms—Remove an alarm from the display (see Remove an Alarm).
  • Remove With Comment—Remove an alarm and associate the activity with a brief text description (see Remove an Alarm with Comment).
  • Unacknowledge or Unacknowledge Alarms—Unacknowledge a previously acknowledged alarm (see Unacknowledge an Alarm).
  • Unacknowledge With Comment—Unacknowledge a previously acknowledged alarm and associated the activity with a brief text description (see Unacknowledge an Alarm with Comment).

Additional ‘custom’ actions may be available from the Alarm Banner’s context sensitive menu if:

  • Alarm Banner scripts are used on your system. See a system administrator for the documentation associated with such custom actions. For information on Alarm Banner scripts, see the ClearSCADA Guide to Scripting.
  • Alarm Redirection is used to allow specific alarms to be redirected manually. For more information, see Redirect an Alarm.


Alarms Guide - Acknowledge an Alarm (Perform an Action on an Alarm)

Acknowledge an Alarm

NOTE: Your ClearSCADA system may be configured to use a different background color to indicate which alarms you can acknowledge on Alarms Lists and the Alarm Banner (see Define the Background Colors for a Severity in the ClearSCADA Guide to Server Administration).

When an alarm is raised, you should typically acknowledge it so that other users do not attempt to investigate the same alarm condition. You acknowledge an alarm using the Acknowledge or Acknowledge Alarms options. (A further option, Acknowledge with Comment can also be used—see Acknowledge an Alarm with Comment.)

Your User Account may be configured to allow you to Select Multiple Alarms. If so, you will be able to acknowledge more than one alarm at a time by holding down the CTRL button while you select each alarm.

When you acknowledge an alarm:

  • The alarm’s color in the Alarms List changes and is no longer listed at the top of the Alarms Lists—unacknowledged alarms are listed above acknowledged alarms irrespective of the severity level.
  • Any entry is added to the Events List (see Alarm-Related Entries in the Events List).
  • The item’s Alarm Status changes from Unacknowledged Uncleared to Acknowledged Uncleared, as shown here in the item’s Status display.
  • The number of unacknowledged alarms decreases by one on the Alarm Bell Button.
    Number of unacknowledged alarms
    Number of alarms

An Acknowledged Uncleared alarm indicates that the alarm condition still exists in your system—you should investigate its cause.

If you usually have access to the Acknowledge or Acknowledge Alarms options, but those options are not available, the ability to acknowledge alarms might be restricted to a particular User, User Group, or ViewX workstation. Use the View Status option to view the Status display for the item and ascertain whether such a restriction is in force. For further information, see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection, and see Standard Alarm States in the ClearSCADA Guide to ViewX and WebX Clients.


Alarms Guide - Acknowledge an Alarm with Comment (Perform an Action on an Alarm)

Acknowledge an Alarm with Comment

If you select the Acknowledge with Comment option, a window opens for you to enter a comment.

If a set of standard Alarm Acknowledgment comments are configured on your system, you can either overtype the existing entry with your own comment, or select a suitable standard comment from a pop-up list.

The comment is a brief message that can be viewed by any user who has access to the point’s Status display, where the comment is displayed as part of the State Alarm attribute (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients).

Other changes to how the alarm is displayed are the same as for Acknowledge an Alarm.

Your User Account may be configured to allow you to Select Multiple Alarms. If so, you will be able to acknowledge more than one alarm at a time by holding down the CTRL button while you select each alarm.

If you usually have access to the Acknowledge with Comment option, but that option is not available, the ability to acknowledge alarms might be restricted to a particular User, User Group, or ViewX workstation. Use the View Status option to view the Status display for the item and ascertain whether such a restriction is in force. For further information, see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection, and see Standard Alarm States in the ClearSCADA Guide to ViewX and WebX Clients.

To acknowledge an alarm without entering a comment, select the Acknowledge or Acknowledge Alarms option, rather than the Acknowledge with Comment option (see Acknowledge an Alarm).


Alarms Guide - Disable Alarms and Enable Alarms (Perform an Action on an Alarm)

Disable Alarms and Enable Alarms

Depending on the system configuration, it may be possible to disable (withhold) or enable (allow) alarms for an item. You may want to disable alarms, for example, when a device that has been reported as faulty is causing nuisance alarms, or a device has been decommissioned.

The Disable Alarms action is designed to allow you to withhold alarms for a specific database item or group of items. On systems on which the disabling of alarms is allowed, the Disable Alarms option can be selected from the context sensitive menu for a database item (see Perform an Action on an Alarm). The option can also be triggered by a Schedule or ‘called’ by a Logic program.

If an alarm condition occurs while alarms are disabled for an item, the alarm is withheld, but only until the item’s alarms are enabled again. When the item’s alarms are set to enabled, the withheld alarms are shown.

Depending on the configuration of the server, the Disable Alarms action will:

  • Disable alarms for the selected item until the Enable Alarms action is selected, triggered or called.
  • Disable alarms for the selected item for a time period defined in the server configuration.

When the time period expires, the alarms are enabled again automatically. The alarms can also be enabled again by a user selecting the Enable Alarms action.

The time period only applies to the Disable Alarms action when selected from the pick action menu by a user. The time period is not implemented when the Disable Alarms action is triggered by a Schedule or called by a Logic program; instead the alarms are disabled indefinitely (until they are enabled via the Schedule triggering the Enable Alarms action, or the Logic program calling the Enable Alarms method).

  • Disable alarms for the selected item for a user-defined period of time.

You are prompted to enter a suitable time period (which has to be within the limits defined in the server configuration) and when this time period expires, the alarms are enabled again automatically. The alarms can also be enabled again by a user selecting the Enable Alarms action.

Enter the required duration in the OPC Time Format, for example 1D (for one day).

The time period only applies to the Disable Alarms action when selected from a context sensitive menu by a user. The time period is not implemented when the Disable Alarms action is triggered by a Schedule or called by a Logic program; instead the alarms are disabled indefinitely (until they are enabled via the Schedule triggering the Enable Alarms action or the Logic program calling the Enable Alarms method).

By default, database items are set to have their alarms enabled. This means that the internal ‘flags’ for the item’s alarms are each set to enabled. There are three flags:

  • User
  • Schedules
  • Logic Programs.

When any of the flags is set to disabled, the alarms for the selected item are disabled. They remain disabled until each of the three flags are set to enabled. The Status Displays for each item that can have alarms indicate whether the flags are enabled or disabled and also provides information about when the alarms will become automatically enabled (where appropriate).

While an item has its alarms disabled, that item’s entry on displays such as Queries Lists will be assigned the Alarm Disabled system color (unless another status takes precedence). Should an item that has its alarms disabled go into a state that is configured as an alarm state:

  • No alarm entries will be added to Alarms Lists or the Alarm Banner for that item while its alarms remain disabled
  • No alarm redirection activity (if configured for the item) will be triggered (as no alarm was generated)
  • The item’s change in state will be logged in the Event Journal (Events List), but will not appear as an alarm-related entry (as no alarm was generated)
  • The item’s Status display will indicate that the item’s alarm functionality remains disabled, while other attributes, such as the State Alarm attribute that applies to many types of item, indicate a ‘Disabled Active’ state.

You can use the Enable Alarms action to allow alarms to be raised for a database item that currently has its alarms disabled. The Enable Alarms action will only enable the alarms for a database item if both of the other flags are also set to enabled. So, if you select the Enable Alarms action, it will only enable the alarms for the selected item if the Schedules disable alarm flag and Logic disable alarm flag are both set to enabled. Similarly, if a Schedule triggers the Enable Alarms action, it will only enable the alarms for the relevant item if the item’s User disable alarm flag and Logic disable alarm flag are set to enabled. A Logic program that calls the Enable Alarms method will only be able to enable the alarms for a database item if the item’s User disable alarm flag and Schedule disable alarm flag are both set to enabled.

If other disable alarm flags are set to disabled when the Enable Alarms action is selected, triggered or called, it will seem to have no effect. However, the Enable Alarms action will change the status of the relevant disable alarm flag. For example, if alarms have been disabled for a point by a user selecting the Disable Alarms action, a Schedule will not be able to set the point to have its alarms enabled. Instead, when the Schedule triggers the Enable Alarms action, it sets the Schedule disable alarm flag to enabled.

If each of the three disable alarm flags become enabled on an item after one or more of those flags has been disabled, an Alarms enabled entry will be logged in the Event Journal (Events List). If the item is currently in a state that is configured as an alarm state:

  • Alarm entries will be added to the Alarms List and Alarm Banner. The entries will be time stamped with the alarm’s original occurrence time (or, on systems on which the Use Visible Time As Alarm Active Time feature is enabled, the time that alarms were re-enabled on the item)
  • The item’s Status display will indicate that alarms are enabled on the item and will include a summary of the item’s alarm status
  • The timer will start for any alarm redirections that are configured on the item
  • If configured to do so, the item will be displayed in the appropriate alarm severity colors on displays such as Mimics.

Example:

A new point is created. By default, its three disable alarm flags (User, Schedule and Logic) are each set to enabled, so the point can have alarms.

A user selects the Disable Alarms action for a point. This sets the User flag to disabled and so withholds alarms for the point.

A Schedule triggers the Enable Alarms action for the point. As the User flag is set to disabled, the point cannot have its alarms enabled (the Enable Alarms action will only enable alarms when triggered by a Schedule if the point’s User disable alarm flag and Logic disable alarm flags are both set to enabled).

A Logic program calls the Disable Alarms method for the point. The point is already disabled, so the Logic program appears to have no effect. However, by the Logic program calling the Disable Alarms method for the point, it has set the point’s Logic disable alarm flag to disabled.

So the point now has its User disable alarm flag set to disabled, its Schedule disable alarm flag set to enabled, and its Logic disable alarm flag set to disabled.

The user selects the Enable Alarms action for the point. This appears to have no effect as the point’s alarms remain disabled (as the Logic program has disabled them). However, by selecting the Enable Alarms action, the user has set the point’s User disable alarm flag to enabled. The point now has its User and Schedule disable alarm flags set to enabled and only its Logic disable alarm flag set to disabled.

The Logic program calls the Enable Alarms method for the point. As the User and Schedule disable alarm flags are both set to enabled, the Logic Program is able to set the point to have alarms again. (The Logic program sets the Logic disable alarms flag to enabled, resulting in all three flags being enabled. Only when all three disable alarm flags are enabled can alarms be raised for an item).

Further Information

Logic Programs: see the ClearSCADA Guide to Logic.

Schedules: see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration.

Alarms Settings at the Server: see Define the Disable Alarms Settings in the ClearSCADA Guide to Server Administration.

Use Visible Time As Alarm Active Time: see Define whether the Visible Time is used as the Active Alarm Time in the ClearSCADA Guide to Server Administration.


Alarms Guide - Redirect an Alarm (Perform an Action on an Alarm)

Redirect an Alarm

ClearSCADA supports Alarm Redirection, whereby alarms can be redirected automatically or manually whenever those alarms fulfill certain redirection criteria. Alarm redirection can be configured on a per item or per group basis (see Introduction to Alarm Redirection in the ClearSCADA Guide to Alarm Redirection).

Should alarm redirection be used to allow you to manually redirect an alarm, that item or group’s context sensitive menu will include one or more ‘custom’ redirection options, in addition to the usual alarm options.

Select the required ‘custom’ option to redirect the alarm. Depending on the configuration, you may be prompted to enter a comment providing further information about the redirected alarm.

The ClearSCADA Guide to Alarm Redirection includes several examples that demonstrate how alarm redirection might be used to allow specific alarms to be redirected manually:

  • see Use Alarm Redirection to Enable Operators to Manually Redirect Alarms in the ClearSCADA Guide to Alarm Redirection
  • see Allow an Operator to Enter a Comment when Manually Redirecting an Alarm in the ClearSCADA Guide to Alarm Redirection.


Alarms Guide - Respond to an Alarm (Perform an Action on an Alarm)

Respond to an Alarm

You can use the Response or Alarm Response options to record a response to an alarm without acknowledging it.

When you select either option, the Alarm Response window is displayed. Enter a suitable response comment in the field, then select the OK button.

(If a set of standard comments are configured on your system, you can either overtype the existing entry with your own comment, or select a suitable ‘standard’ comment from a pop-up list.)

By default, the entry in the Alarms List changes its background color to indicate that a text response for the alarm is available for viewing. The color used is that which is assigned as the Alarm Response color for your system (see Define the Background Colors for a Severity in the ClearSCADA Guide to Server Administration).

A response record, including the alarm response comment, is added to the Events List (see Events in the ClearSCADA Guide to ViewX and WebX Clients).


Alarms Guide - Remove an Alarm (Perform an Action on an Alarm)

Remove an Alarm

You can use the Remove or Remove Alarms options to remove an acknowledged alarm. (A further option, Remove with Comment can also be used—see Remove an Alarm with Comment.)

WARNING

lack of alarm notification

Use the Remove and Remove Alarms options with care. Removing an alarm using either of these options will stop the alarm displaying on the system. Before using either option, we strongly recommend that you perform a risk analysis to ensure that the removal of existing alarms will not pose a danger to people or equipment.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

When the Remove or Remove Alarms option is selected, ClearSCADA removes the alarm from the Alarm Banner and Alarms Lists. Additionally, the alarm flag is cleared from other displays, such as Mimics (see Alarms on Mimics).

Removing the alarm creates a record in the Events List (see Events in the ClearSCADA Guide to ViewX and WebX Clients).

A new alarm will be raised if the condition that caused the removed alarm clears, but later recurs. For example, if the level in a water tank drops below the level that caused a removed alarm, but then fills to reach that level again, another alarm will be raised.


Alarms Guide - Remove an Alarm with Comment (Perform an Action on an Alarm)

Remove an Alarm with Comment

You can use the Remove with Comment option to remove an existing alarm and enter a brief message as to why the alarm is being removed.

WARNING

lack of alarm notification

Use the Remove with Comment option with care. Removing an alarm using this option will stop the alarm displaying on the system. Before using the option, we strongly recommend that you perform a risk analysis to ensure that the removal of existing alarms will not pose a danger to people or equipment.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

When you select the Remove with Comment option, the Removal Comment window is displayed. Enter your comment in the window.

The comment can be viewed by any user who has access to the Events List (see Events in the ClearSCADA Guide to ViewX and WebX Clients). The comment forms part of the record that is added to the Events List when the alarm is removed.

As with the Remove option (see Remove an Alarm), the alarm is removed from the Alarm Banner, Alarms List and other displays, such as Mimics.

A new alarm will be raised if the condition that caused the removed alarm clears, but later recurs.

To remove an alarm without entering a comment, select the Remove or Remove Alarms option, rather than the Remove with Comment option (see Remove an Alarm).


Alarms Guide - Unacknowledge an Alarm (Perform an Action on an Alarm)

Unacknowledge an Alarm

NOTE: The ability to Unacknowledge Alarms is disabled on most systems by default. (Its permission is typically denied on a per server basis.)

Depending on the system configuration, it may be possible to unacknowledge alarm(s) that have been acknowledged, but for which the abnormal condition still exists (that is, alarms that are in the Acknowledged Uncleared state). You unacknowledge alarms using the Unacknowledge or Unacknowledge Alarms options. (A further option, Unacknowledge with Comment can also be used—see Unacknowledge an Alarm with Comment.)

When you unacknowledge an alarm:

  • The item’s Alarm Status changes from Acknowledged Uncleared to Unacknowledged Uncleared.
  • An entry is logged in the Event Journal, stating when the alarm was unacknowledged and by whom (the User that was logged on to the workstation at the time)
  • The position and color of the alarm in Alarms Lists and the Alarm Banner changes—the alarm appears alongside other Unacknowledged Uncleared alarms, and uses the color assigned to that Alarm Status.
  • The number of unacknowledged alarms increments by one on the Alarm Bell Button.


Alarms Guide - Unacknowledge an Alarm with Comment (Perform an Action on an Alarm)

Unacknowledge an Alarm with Comment

NOTE: The ability to Unacknowledge Alarms is disabled on most systems by default. (Its permission is typically denied on a per server basis.)

If available on your system, use the Unacknowledge with Comment option to:

  • unacknowledge an alarm that has been acknowledged but is still in existence

and:

  • log a comment indicating why the alarm has been unacknowledged.

When you select the Unacknowledge with Comment option, a window is displayed. Enter your comment in the window, then select the OK button to unacknowledge the alarm. Your comment is included in the message that is logged in the Event Journal, indicating when and why the alarm has been unacknowledged (see Unacknowledge an Alarm).

To unacknowledge an alarm without entering a comment, select the Unacknowledge or Unacknowledge Alarms option, rather than the Unacknowledge with Comment option (see Unacknowledge an Alarm).


Alarms Guide - Alarms List and Alarm Banner Columns

Alarms List and Alarm Banner Columns

Alarms Lists and the Alarm Banner display alarm information in a series of columns (see Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns).

If required, you can adjust the order or widths of these columns (see Change the Order of Columns on an Alarms List or the Alarm Banner Directly, and see Change the Size of Columns on an Alarms List or the Alarm Banner Directly).

You can also Configure Additional Alarm Columns.


Alarms Guide - Understand the Information that is Displayed on an Alarms List or Alarm Banner (Alarms List and Alarm Banner Columns)

Understand the Information that is Displayed on an Alarms List or Alarm Banner

Each row in an Alarms List or the Alarm Banner contains the record for an individual alarm. The information for each alarm is displayed using a series of columns. By default, these columns include:

  • Severity—The importance of the alarm (see Alarm Severity).
  • Time—Alarms have both an occurrence time and a receipt time. The former is the time that the alarm occurred, and the latter is the time that ClearSCADA received notification of the alarm. This field displays the alarm’s occurrence time (if known), otherwise it displays the receipt time. On systems on which the Use Visible Time As Alarm Active Time feature is enabled, the occurrence time is the time that the alarm occurred or the time that the alarm was last unsuppressed or enabled, whichever is the later (see Define whether the Visible Time is used as the Active Alarm Time in the ClearSCADA Guide to Server Administration).

(Should ClearSCADA not know the occurrence time when it processes an alarm, it will use that alarm’s receipt time. However, should ClearSCADA become aware of the occurrence time at a later stage, it will update the alarm’s time accordingly. (For instance, if ClearSCADA dials out to a PSTN outstation and retrieves the current data for a point that is in alarm, it will raise an alarm with the receipt time—the time that it processed the data. If it then retrieves logged data for that point, in which it retrieves the state change that triggered that alarm, the server will update the alarm data with the occurrence time—the time that the point changed state.))

  • Source—The full name and path of the item with which the alarm is associated, or the item’s ‘Alarm Source’ name. (The ‘Alarm Source’ name is displayed if the item has been configured to have an alternative Alarm Source name—see Specify an Alternative Alarm Source Name in the ClearSCADA Guide to Core Configuration).

Outstations on some advanced drivers support the ability to send text messages to ClearSCADA, which the server reports using text alarms. Additionally, occurrences such as an unknown outstation dialing in to the server, or a server license expiring, will also generate a text alarm. Unlike other alarms, the source of a text alarm will not be an item in the database.

  • Message—A short description about the abnormal condition that caused the alarm to be raised.
  • Category—The type of alarm (see Alarm Category).
  • System—The name of the ClearSCADA database on which the alarm has been raised. This column is only included on the client-wide Alarms List (see Display a Client-Wide Alarms List) and Alarm Banner if your ViewX Client is configured to access Multiple Databases.
  • Area of Interest—Only displayed if the Area of Interest feature is enabled on your system. The column indicates the Area of Interest with which the alarm is associated. Additionally, the entries in the Alarms List are restricted to include only alarms that are associated with the Area(s) of Interest to which your User Account has access. For more information, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.
  • Suppressed Alarm Count—Applies to alarms that are configured as the ‘Parent Alarm Condition’ for other database items. When active, the ‘parent’ alarm suppresses any new alarms on the other database items. The Suppressed Alarm Count value indicates the number of other alarms that are currently suppressed (omitted from alarm displays) as a result of this ‘parent’ alarm being active. For more information, see Configure any Alarm Suppression Requirements in the ClearSCADA Guide to Core Configuration.

Other columns may be displayed if the Alarms Lists and Alarm Banner on your system have been configured to include additional columns (see Configure Additional Alarm Columns).


Alarms Guide - Adjust the Columns on an Alarms List or the Alarm Banner (Alarms List and Alarm Banner Columns)

Adjust the Columns on an Alarms List or the Alarm Banner

Alarms Lists and the Alarm Banner display these columns by default:
Order and Names of Columns | Width of Alarm Banner Column on a ViewX Client | Width of Alarms List Column on a ViewX Client | Width of Alarms List Column on a WebX Client
Severity | 82 | 80 | 75
Time | 282 | 160 | 150
Source | 301 | 312 | 350
Message | 444 | 275 | 450
Category | 200 | 183 | 100
System | 200 | 200 | ---
Area of Interest | 200 | 198 | 200
Suppressed Alarm Count | 200 | 200 | 200

The Area of Interest column is only displayed if the Area of Interest feature is enabled on your system (see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration).

The System column is only displayed on a ViewX client that is configured to access Multiple Databases.

You can use the Alarm Columns window to adjust the columns that are displayed on an Alarms List or the Alarm Banner (see Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns). You can use the window to:

  • Change the column order
  • Resize a column
  • Hide a column.

If the Allow Column Resizing check box is selected on the Alarm Banner tab of the Options window (see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client), you can also:

  • Change the Order of Columns on an Alarms List or the Alarm Banner Directly.
  • Change the Size of Columns on an Alarms List or the Alarm Banner Directly.

Users with the required permission can add additional columns to the Alarms Lists and Alarm Banner, if required (see Configure Additional Alarm Columns).


Alarms Guide - Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns (Alarms List and Alarm Banner Columns)

Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns

If required, you can change the order of, or resize, any of the columns on the Alarms Lists or the Alarm Banner. Any changes that you make are on a per-client basis and affect either the Alarms Lists, or the Alarm Banner (depending from which of these two items you opt to make the changes). For example, if you change the order of the columns on the Alarm Banner on a ViewX client, those changes will only affect the Alarm Banner on that particular client. Similarly, if you resize a column on an Alarms List on a WebX client, those changes will only apply to the Alarms Lists that are displayed on that particular WebX client.

To make any of the above changes:

  1. On the relevant client, right-click on whichever Alarms display you want to make the changes (either an Alarms List, or the Alarm Banner).
    A context sensitive menu is displayed.
  2. Select the Columns option.
    The Alarm Columns window is displayed.
    The ‘Area of Interest’ column is only included if the Areas of Interest feature is enabled on your system.
    Columns are listed in the order in which they are displayed on the Alarms List, or Alarm Banner.

The window lists the columns that are included on the Alarms List or Alarm Banner. The entries are listed in the order in which the columns are displayed (the list also includes any columns that are hidden due to their size being set to 0).

Severity, Time, Source, Message, and Category columns are included by default (along with the ‘Area of Interest’ column, if the Area of Interest feature is enabled on your system). It is also possible to add additional columns to the Alarms Lists and Alarm Banner—if such columns have been added to the alarm displays on your system, these will also be listed in the Alarm Columns window.

  3. To change the order of any of the columns:
  1. Select the column that you want to move.
  2. Either:
  • Select the Move Up button to move the column further up the list.

Or:

  • Select the Move Down button to move the column further down the list.
  3. Repeat the above steps for any other columns for which you want to change the order.
  4. To resize a column:
  1. Select the column that you want to resize.
    Its present width is displayed in the Width of selected column field.
  2. Specify the required width in the Width of selected column field.

To hide an existing column, so that it is not displayed, specify a width of 0 (zero).

To display a presently hidden column, set its width to a non-zero value.

  3. Repeat the above steps for any other columns that you want to resize.
  5. Select the OK button to confirm the changes and close the Alarm Columns window.
    The changes are applied to the Alarms List or Alarms Banner, as applicable.

Further Information

Configure Additional Alarm Columns.

Change the Order of Columns on an Alarms List or the Alarm Banner Directly.

Change the Size of Columns on an Alarms List or the Alarm Banner Directly.


Alarms Guide - Change the Order of Columns on an Alarms List or the Alarm Banner Directly (Alarms List and Alarm Banner Columns)

Change the Order of Columns on an Alarms List or the Alarm Banner Directly

You can use the Alarm Columns window to change the order in which the columns display on an Alarms List or Alarm Banner (see Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns).

If the Allow Column Resizing check box is selected on the Alarm Banner tab of the Options window (see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client), you can also change the column order on the Alarm Banner directly.

With either procedure, any changes in column order are head-specific—that is, they only apply to the Alarms Lists or the Alarm Banner on the individual head of the particular client (ViewX or WebX) on which those changes are made.

To change the order of columns on an Alarms List or the Alarm Banner directly:

  1. Select the header of the column that is to be moved to a different position on the List—do not release the mouse button.
  2. ‘Drag’ the column header to its required location. (For instance, if you want the ‘Time’ column to appear to the left of the ‘Severity’ column, drag the ‘Time’ column onto the ‘Severity’ column.)
  3. Release the mouse button.
    The selected column is moved to the specified position on the Alarms List or Alarm Banner.

If you want to hide any columns so that they are no longer displayed, use the Alarm Columns Window (see Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns).


Alarms Guide - Change the Size of Columns on an Alarms List or the Alarm Banner Directly (Alarms List and Alarm Banner Columns)

Change the Size of Columns on an Alarms List or the Alarm Banner Directly

You can use the Alarm Columns window to change the width of the columns on an Alarms List or Alarm Banner (see Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns).

If the Allow Column Resizing check box is selected on the Alarm Banner tab of the Options window (see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client), you can also change the size of columns on the Alarm Banner directly.

With either procedure, any changes in column size are head-specific—that is, they only apply to the Alarms Lists or the Alarm Banner on the individual head of the particular client (ViewX or WebX) on which those changes are made.

To change the width of columns on an Alarms List or the Alarm Banner directly:

  1. On the header cells, place the cursor over the line that indicates the end of the column that you want to resize.
    The cursor changes shape.
  2. Hold down the mouse button while dragging the header line horizontally.
    The column resizes in line with the cursor position.
  3. Release the mouse button once the column reaches the required width.


Alarms Guide - Specify a Default Alarm Filter

Specify a Default Alarm Filter

This section is for system administrators and high-level engineers who are defining Default Alarm Filters.

The entries on Alarms Lists and the Alarm Banner can be pre-filtered automatically on a per user basis, so that the displays only include those alarms in which a particular user is interested. The user themselves can then further filter the Alarms Lists and/or Alarm Banner whenever required, using the Filter window (see Use the Filter Window to Filter Alarm Entries).

The Default Alarm Filter is specified using the Alarm Filter String field on each User Form (see Define the Default Alarm Filter Settings for a User in the ClearSCADA Guide to Security). With the ViewX Guest User account, you specify the Alarm Filter String on each system’s Root Group Form (see Define the Global Settings for All Guest and Web User Accounts in the ClearSCADA Guide to Security).

Leave the Alarm Filter String field empty for the Alarms Lists and Alarm Banner to include alarms to which:

  • The current user has access
  • The ViewX or WebX client is connected

and, in the case of Alarms Lists that are displayed for a particular item or Group:

  • That apply to the selected item, Group, or Group Instance.

The alarm displays will include any alarms that meet the following criteria:

  • Alarms that are associated with database items to which the user is assigned the View Alarms security permission—This permission is required in addition to the User Account being assigned the View Alarms feature. For more information, see Define the Operational ViewX Settings for a User in the ClearSCADA Guide to Security, and see Permissions for Database Items in the ClearSCADA Guide to Security.
  • Alarms raised within Area(s) of Interest to which the user has access—This restriction only applies if the Area of Interest feature is enabled on your system. For more information, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.
  • Alarms that are not under the Exclusive Control of another user—This restriction only applies if the Exclusive Control feature is enabled on your system. For more information, see Exclusive Control in the ClearSCADA Guide to Security.
  • Alarms that are not disabled (see Disable Alarms and Enable Alarms).
  • Alarms that are not suppressed by another active alarm (see Alarm Suppression).

Optionally use the Alarm Filter String field to further restrict the alarms that are included on Alarms Lists and the Alarm Banner. When a default filter is specified, ClearSCADA takes into account the above restrictions, plus the filters that are specified in the Alarm Filter String field. Whenever the user logs on to a ViewX or WebX client, the alarm displays on that client only include those alarms that fulfill all of the alarm criteria, including that specified in the Alarm Filter String field.

You specify an Alarm Filter String using specific syntax (see Alarm Filter String Syntax).

Should a user use the Filter window to further filter the Alarms List or Alarm Banner, they can later use the Reset Filter menu option to reset the filters back to the default. If the user’s Alarm Filter String field is used to restrict the alarms that are displayed, the default takes the content of this field into account. If the user’s Alarm Filter String field is blank, the display will revert to including those alarms to which the user and the ViewX or WebX client has access.

If a user’s Alarm Filter String field is used to restrict the alarms that are displayed, that user can still view alarms that are excluded from alarm displays due to that Alarm Filter String. To do this, they can use the Filter window to include any alarms to which their account and the ViewX or WebX client has access. Again, the Reset Filter menu option can later be used to remove the filtering that they have applied and revert to the default specified by the Alarm Filter String (plus the other criteria listed above).

Further Information

Use the Filter Window to Filter Alarm Entries.

Specify a Default Alarm Filter for an Alarms List embedded on a Mimic: see Filter an Embedded Alarms List in the ClearSCADA Guide to Mimics.


Alarms Guide - Alarm Filter String Syntax (Specify a Default Alarm Filter)

Alarm Filter String Syntax

You can use the User Form’s Alarm Filter String property to pre-filter alarms to those of potential interest to a particular user (see Specify a Default Alarm Filter). You can use the property to pre-filter alarms by the same attributes as those that can be specified using the Filter window (see Use the Filter Window to Filter Alarm Entries).

If your system comprises multiple ClearSCADA databases, be aware that any filters you specify using the Alarm Filter String only apply to the particular ClearSCADA database on which a User Account is located. For each user that has access to Multiple Databases, a separate User Account has to exist on each ClearSCADA database to which that user has access. For such users, you need to specify an Alarm Filter String for each of those User Accounts. Depending on the attribute(s) by which alarms are being filtered, the filter string might need to differ on each of those User Accounts (for example, if alarms on one ClearSCADA database are to be filtered by a Source or AOI (Area of Interest) that exists on one ClearSCADA database, but not on another).

You specify a user’s Alarm Filter String using specific syntax. The attributes by which you can filter alarms are listed in the table below. Several restrictions apply to the syntax used to specify any of those attributes:

  • Specify each required attribute using the format <Filter Attribute>="<filter value>"
  • To specify multiple filter attributes, include an ampersand (&) between each filter attribute
  • Do not include any character spaces in the filter string (other than spaces that are included in the names of any AOI, Categories, or Source values by which alarms are being filtered)
  • Do not include any carriage returns in the filter string
  • Any part of the filter string used to specify the name of a database item, or a database path, is case sensitive. The rest of the filter string is case insensitive
  • The filter string can support a maximum of four MinSeverity and MaxSeverity ranges
  • The filter string can only support up to one AlarmState attribute and value
  • With the Source attribute, you can optionally include Filter Wildcards to define the filter values.

The attributes by which you can filter alarms using the Alarm Filter String are as follows:

Filter Attribute

Value Type

Comments

AlarmState

String

Use to filter alarms by alarm state. This is equivalent to using the State combo box on the Filter window.

The states by which you can filter alarms are:

Acknowledged, Cleared, Unacknowledged, Uncleared, and UnacknowledgedUncleared. You can only specify up to one AlarmState clause and value per alarm filter string. Whenever the AlarmState attribute is omitted from an alarm filter string, ClearSCADA includes each alarm that meets all of the other filter criteria, regardless of alarm state.

Example:

AlarmState="Acknowledged"

(Resulting in alarms being filtered to those that have been acknowledged, but for which the condition that caused the alarm still exists.)

AOI

String

Use to filter alarms by Area of Interest. This is equivalent to using the Area of Interest section on the Filter window.

This attribute only applies if the Area of Interest feature is enabled on your system (see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration).

On systems on which multiple Area of Interest levels exist, use a dot separator (.) to indicate each hierarchical level.

You can specify single or multiple Areas of Interest. Include a separate AOI clause for each Area of Interest that you want to specify.

Example:

AOI="South-West.SW2"&AOI="North-East.NE1"

(Resulting in ClearSCADA filtering alarms to those that are assigned the SW2 Area of Interest (which is itself within the South-West Area of Interest), or the NE1 Area of Interest (which is within a North-East Area of Interest).)

Assigned

Boolean

Use to filter alarms to those that are assigned to the current user or ViewX workstation. This is equivalent to using the Only Show Alarms Assigned to Current User check box on the Filter window.

When TRUE, alarms are restricted to those that are assigned to the current user or ViewX workstation. When this attribute is omitted from the Alarm Filter String, ClearSCADA assumes the attribute to be FALSE.

Example:

Assigned="True"

Categories

String

Use to filter alarms by alarm category (or type of alarm). This is equivalent to using the Categories section on the Filter window.

You can specify single or multiple categories. To specify multiple categories use either of these methods:

  • Use a semi-colon (;) to separate each additional category in a single Categories clause. Ensure no spaces are included either side of the semi-colon. Only include spaces where they exist in the category name.
  • Specify each filter value as a separate Categories clause, in the same way as you would other alarm filter attributes.

You can ascertain the category names that exist on your system from, for example, the Category column on an Alarms List or the Alarm Banner, or from the Filter window.

Example:

Categories="Point Error;Point No Change;Point State"

or:

Categories="Point Error"&Categories="Point No Change"&Categories="Point State"

(Either string results in ClearSCADA filtering the alarms to those point alarms that are associated with any of the above categories.)

MinSeverity

Integer

Use to specify the minimum priority of the alarms that are to be included in alarm displays. This is equivalent to using the Minimum combo boxes on the Filter window.

With the Filter window, you specify the priority by selecting the severity Description that is assigned to that level of alarm. With the Alarm Filter String, you specify the Priority level. You can ascertain the Priority level that applies to each severity Description on your system by looking at the Severities section of the ClearSCADA Server Configuration Tool.

You can use the Alarm Filter String to specify up to four minimum severities. Include a separate MinSeverity clause for each priority range to which you want to restrict the alarm entries. With multiple MinSeverity clauses, follow each clause with a MaxSeverity clause (see below).

With a single MinSeverity clause, inclusion of a MaxSeverity clause is optional. (If it is excluded from the Alarm Filter String, ClearSCADA assumes the MaxSeverity attribute’s value to be that of the maximum priority level configured on your system.)

For an example that demonstrates the syntax used for defining the MinSeverity attribute, see the MaxSeverity entry below.

MaxSeverity

Integer

Use to specify the maximum priority of the alarms that are to be included in alarm displays. This is equivalent to using the Maximum combo boxes on the Filter window.

As with the MinSeverity attribute (see above), when including this attribute in the Alarm Filter String, you use it to specify the Priority level. You can ascertain the Priority levels on your system by looking at the Severities section of the ClearSCADA Server Configuration Tool.

You can use the Alarm Filter String to specify up to four maximum severities. Include a separate MaxSeverity clause for each priority range to which you want to restrict the alarm entries. With multiple MaxSeverity clauses, precede each clause with a MinSeverity clause (see below).

With a single MaxSeverity clause, inclusion of a MinSeverity clause is optional. (If it is excluded from the Alarm Filter String, ClearSCADA assumes the MinSeverity attribute’s value to be that of the minimum priority level configured on your system.)

Example:

MinSeverity="1"&MaxSeverity="334"&MinSeverity="667"&MaxSeverity="1000"

(Resulting in ClearSCADA filtering alarms to those that have a severity within the range 1 and 334, or 667 and 1000 inclusive.)

Source

String

Use to filter alarms by alarm source (the Group(s), Group Instance(s), or individual item(s) with which the alarms are associated). This is equivalent to using the Sources section on the Filter window.

Each source needs to include the full path within the specific ClearSCADA database. Use a dot separator (.) to indicate each hierarchical level within the database. With the Source attribute, you can optionally include Filter Wildcards to define the values by which ClearSCADA is to filter the alarms.

You can specify single or multiple sources. Include a separate Source clause for each source that you want to specify.

Example:

Source="Northern Region.Zone 1"

(Resulting in ClearSCADA filtering the alarms to those for database items within the group ‘Zone 1’. The ‘Zone 1’ group is located within the ‘Northern Region’ group.)

Examples:

The Alarm Filter String on a particular User Account is configured as:

AlarmState="UnacknowledgedUncleared"&Categories="Point Error;Point State;Outstation Error;Channel Status"&MinSeverity="667"&MaxSeverity="1000"

This results in ClearSCADA filtering the alarms to those that fulfill all of the following filter criteria:

  • Alarms that are both Unacknowledged and Uncleared
  • Alarms that are assigned one of these alarm categories: Point Error, Point State, Outstation Error, or Channel Status
  • Alarms that have a severity of between 667 and 1000 inclusive. (The range for High and Critical priority alarms, by default.)

whenever that particular user logs on to a ViewX or WebX client.

The Alarm Filter String on another User Account is configured as:

Source="Zone #.*"&Categories="Point State"&Categories="Channel Status"

This results in ClearSCADA filtering the alarms to those for items:

  • In the database groups ‘Zone 1’ to ‘Zone 9’
  • That are assigned one of these alarm categories: Point State, or Channel Status.

(For information on the filter wildcards that are supported by the Source filter attribute, see Filter Wildcards.)

Should the syntax that is specified in the Alarm Filter String be invalid, ClearSCADA will display one or more diagnostic messages in a message area at the bottom of the User Form. The message area is displayed once an attempt is made to save any invalid configuration (see Mandatory Configuration and Invalid Configuration Messages in the ClearSCADA Guide to Core Configuration).

If the syntax is valid but includes non-existent value(s) (such as a non-existent database item or path), a diagnostic message will be displayed when ClearSCADA attempts to apply the default filter.

As with any User Account settings, if changes are made to a user’s default Alarm Filter String while that user is logged on, the changes will only take effect the next time that user logs onto the system.


Alarms Guide - Use the Filter Window to Filter Alarm Entries

Use the Filter Window to Filter Alarm Entries

Alarm displays only include those alarms to which a user and ViewX or WebX client have access. Additionally, a Default Alarm Filter can optionally be specified on a per user basis. Such a Default Alarm Filter can be used to further restrict the entries that are included in Alarms Lists and the Alarm Banner, to just those alarms that are of interest to that particular user. A system administrator or high-level engineer typically configures any such Default Alarm Filter whenever a new User Account is added to ClearSCADA, by specifying an Alarm Filter String for that user (see Specify a Default Alarm Filter).

If required, you can use the Filter window to temporarily filter the entries further, so that only a subset of alarm entries is included in the Alarms List or Alarm Banner. For example, you might want to temporarily filter an Alarms List so that it only provides information on alarms that have High severity. If your User Account allows you to filter entries in the Alarm Banner, ClearSCADA might be configured to automatically disregard any such filtering as soon as your User Account’s Banner Filter Timeout period is exceeded.

If your User Account is assigned a Default Alarm Filter, you can also use the Filter window to temporarily adjust the default filters, so that the alarm displays include further alarms to which your User Account and ViewX or WebX client have access.

To use the Filter window to temporarily filter the entries in an Alarms List or the Alarm Banner:

  1. Display the Filter window.

To display the Filter window for the Alarm Banner on a ViewX client:

  1. Right-click on the Alarm Banner.
    A context sensitive menu is displayed.
  2. Select the Filter option.
    (This option is only available if the ability to filter Alarm Banner entries is enabled on your User Account.)

To display the Filter window for a currently open Alarms List:

On a ViewX client, either:

  1. Right-click on the Alarms List.
    A context sensitive menu is displayed.
  2. Select the Filter option.

Or:

  1. Select the Items menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Filter option.

Or:

  1. Press the F7 function key.

The Filter window is displayed.

On a WebX client:

  1. Right-click on the Alarms List.
    A context sensitive menu is displayed.
  2. Select the Filter option.

The Filter window is displayed.

Use the Sources section to filter the alarms to those that are associated with specific Groups, or database items.
Use the Areas of Interest section to filter the alarms by Area of Interest.
Use the Severities section to filter the alarms by severity range.
Use the Categories section to define which categories of alarm are shown. (The categories vary, depending on the drivers that are installed on your system.)
Use the State combo box to filter the alarms by alarm state.
Only applies to the Alarm Banner or the client-wide Alarms List on ViewX clients that can access multiple ClearSCADA databases. Use the Filter for combo box to specify the ClearSCADA database on which you want to filter the alarms.
Only applies if the Set Responsibility Action is used. Use the check box to display the alarms to which the current user or ViewX workstation is assigned responsibility.

  2. Use the Filter window to perform any combination of the following:
  • Specify the ClearSCADA Database for which you want to Filter Alarms (ViewX clients that are configured to access multiple ClearSCADA databases only)
  • Filter Alarms to Show Only Those that are Assigned to the Current User or ViewX Workstation
  • Filter Alarms by Alarm Source
  • Filter Alarms by Area of Interest
  • Filter Alarms by Alarm Severity
  • Filter Alarms by Alarm Category
  • Filter Alarms by Alarm State.

Further Information

Reset the Filters on an Alarms List or the Alarm Banner.

Specify a Default Alarm Filter for an Alarms List embedded on a Mimic: see Filter an Embedded Alarms List in the ClearSCADA Guide to Mimics.


Alarms Guide - Specify the ClearSCADA Database for which you want to Filter Alarms (Use the Filter Window to Filter Alarm Entries)

Specify the ClearSCADA Database for which you want to Filter Alarms

A ViewX client can be configured to access a single or multiple ClearSCADA databases (see Working with Single and Multiple Databases in the ClearSCADA Guide to Client Administration).

When you use the Filter window to filter the entries on the Alarm Banner or on the client-wide Alarms List on a ViewX client that accesses Multiple Databases, an additional Filter for field is displayed at the top of the Filter window. Use the field to specify the ClearSCADA system (database) on which you want to filter the alarms.

The filter criteria has to be specified separately on each ClearSCADA database, as the options from which you can choose to filter the alarms differ per database. For instance, the Sources (database items) on one ClearSCADA database will differ to those on other ClearSCADA database(s) to which a ViewX Client has access. Similarly, the Areas of Interest typically differ, as may the Categories (if different drivers run on each system), and so on.

To specify the ClearSCADA system (database) to which the filter criteria is to apply:

  1. Display the Filter Window (see Use the Filter Window to Filter Alarm Entries).
  2. Select the arrow on the Filter for combo box. (The combo box is only displayed on ViewX clients that access multiple ClearSCADA databases.)
    A list is displayed showing the ClearSCADA databases to which the ViewX client is connected.
  3. Select the required ClearSCADA system (database) from the list.

The Filter window refreshes to display the existing filter criteria and filter options for the specified system. (For instance, the Categories list refreshes to display the alarm categories that apply to that particular system. (The list of categories differs, depending on the drivers that are installed on that system.))

  4. Use the Filter Window to specify the required filters for the alarms on that system. For further information, see these sections:
  • Filter Alarms to Show Only Those that are Assigned to the Current User or ViewX Workstation
  • Filter Alarms by Alarm Source
  • Filter Alarms by Area of Interest
  • Filter Alarms by Alarm Severity
  • Filter Alarms by Alarm Category
  • Filter Alarms by Alarm State.
  5. Repeat steps 3 and 4 for any other ClearSCADA systems for which you want to filter alarms.
  6. Select the OK button.
    The Filter window is closed and the alarm display is filtered accordingly. The List or Banner only shows those alarms that meet the filter criteria for the ClearSCADA system with which they are associated.


Alarms Guide - Filter Alarms to Show Only Those that are Assigned to the Current User or ViewX Workstation (Use the Filter Window to Filter Alarm Entries)

Filter Alarms to Show Only Those that are Assigned to the Current User or ViewX Workstation

ClearSCADA can be configured to redirect specific alarms in such a way that only a particular User, User Group, or one or more ViewX Workstations are assigned the ability to acknowledge those alarms (see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection).

You can filter an Alarms List or Alarm Banner to show only those redirected alarms that you or your workstation are assigned the ability to acknowledge.

To filter alarms in this way:

  1. Display the Filter Window (see Use the Filter Window to Filter Alarm Entries).
  2. On a ViewX Client that can access multiple ClearSCADA databases, Specify the ClearSCADA Database for which you want to Filter Alarms.
  3. Select the Only Show Alarms Assigned to Current User check box.
  4. If required, Use the Filter Window to Filter Alarm Entries by other types of filter.
  5. Select the OK button.
    The Filter window is closed and the Alarms List or Alarm Banner is filtered. It only shows the alarms that meet the filter criteria.


Alarms Guide - Filter Alarms by Alarm Source (Use the Filter Window to Filter Alarm Entries)

Filter Alarms by Alarm Source

You can use the Filter window to optionally filter alarms by Source.

To filter alarms by Source:

  1. Display the Filter Window (see Use the Filter Window to Filter Alarm Entries).
  2. On a ViewX Client that can access multiple ClearSCADA databases, Specify the ClearSCADA Database for which you want to Filter Alarms.
  3. Select the Add button in the Sources section.
    The Add Source window is displayed.
  4. Use the browse button to display a Reference browse window.
  5. Use the window to locate and select the required source (either a Group, Group Instance, or an individual item).
  6. Select the OK button to close the window.
    The specified source is displayed in the Add Source window.
  7. If required, you can specify one or more sources by including various Filter Wildcards in the Source field (see below). (Wildcard characters allow a single character to match any of one or more unspecified characters.)
  8. Once you have selected or specified the required source(s), select the OK button to confirm the choice and close the window.
    The specified source(s) are added to the Sources list in the Filter window.
  9. Repeat steps 2 to 8 for any other sources by which you want to filter the Alarms List or Alarm Banner.
  10. If required, Use the Filter Window to Filter Alarm Entries by other types of filter.
  11. Select the OK button.
    The Filter window is closed and the Alarms List or Alarm Banner is filtered. It only shows the alarms that meet the filter criteria. (Remember that should any of the items that are in alarm be configured to use an Alarm Source name, that name will be shown in the alarm display’s Source column in place of the item’s full name. As such, the Alarms List or Alarm Banner may appear to include other alarms in addition to those specified in the Filter window’s Sources field, due to those Alarm Source names being shown. (With an item that has an Alarm Source name, ClearSCADA filters that item’s alarms by both Source and Alarm Source name.) For more information on Alarm Source names, see Specify an Alternative Alarm Source Name in the ClearSCADA Guide to Core Configuration.)

To edit an existing Source filter:

  1. Select the relevant entry in the Sources list.
  2. Select the Edit button.
    The Edit Source window is displayed.
  3. Do either or both of the following:
  1. Select the browse button to display a Reference browse window and select the required source from that window.
  2. Use one or more Filter Wildcards to specify the source that you require.
  4. Select the OK button to confirm the choice and close the window.
    The edited source is updated in the Sources list in the Filter window.

To remove an existing Source filter:

  1. Select the relevant entry in the Sources list.
  2. Select the Remove button.
    The selected source is removed from the list of Sources.


Alarms Guide - Filter Wildcards (Use the Filter Window to Filter Alarm Entries)

Filter Wildcards

When filtering an Alarms List or Alarm Banner by Source, you can include wildcard characters in the filter criteria. Wildcard characters allow a single character to match any of one or more unspecified characters. The Sources filter on the Alarms List or Alarm Banner’s Filter window supports these wildcard characters:

  • ? (question mark) matches a single character.

Example:

N? Region.Water Level
will match Sources such as NE Region.Water Level and NW Region.Water Level

  • * (asterisk) matches any number of characters.

Example:

*Pager*
will match any Sources that include the string ‘Pager’.

  • # (hash) matches any single digit (0 to 9).

Example:

Zone #.Sensor #
will match Sources such as Zone 1.Sensor 2, Zone 1. Sensor 3, and Zone 2.Sensor 4.

  • [] a case insensitive comma-separated list, enclosed in square brackets. A Source is included if it includes any one of the characters, digits, or strings that are included in this list.

Examples:

[a,b,c]*
will match any Sources that start with the letters a, A, b, B, c, or C.

[a-f]*
will match any Sources that start with a letter in the range a to f inclusive (either upper or lower case)

[A-F,M-P,S,T]*
will match any Sources that start with a letter in the ranges A to F, or M to P, or either of the letters S or T (either upper or lower case).

  • [!] a case insensitive comma-separated list, enclosed in square brackets, with the first entry prefixed with an exclamation mark. A Source is excluded if it includes any one of the characters, digits, or strings that are included in this list.

Example:

[!a,b,c]*
will exclude any Sources that start with the letters a, A, b, B, c, or C.

Further Information

Filter Alarms by Alarm Source using the Filter window.

Pre-filter alarms by Alarm Source using the Alarm Filter String: see Specify a Default Alarm Filter.

(The filter wildcards that are supported by Lists other than the Alarms List differ to the above—for information, see Filter Wildcards in the ClearSCADA Guide to Lists.)


Alarms Guide - Filter Alarms by Area of Interest (Use the Filter Window to Filter Alarm Entries)

Filter Alarms by Area of Interest

You can optionally filter alarms by Areas of Interest. This filter only applies if the Area of Interest feature is enabled on your system (see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration).

To filter alarms by Area of Interest:

  1. Display the Filter Window (see Use the Filter Window to Filter Alarm Entries).
  2. On a ViewX Client that can access multiple ClearSCADA databases, Specify the ClearSCADA Database for which you want to Filter Alarms.
  3. Select the Add button in the Areas of Interest section.
    A Reference browse window is displayed.
    The window displays the Areas of Interest to which you have access.

  4. Select the required Area of Interest from the window.
  5. Select the OK button to confirm the choice and close the window.
    The specified Area of Interest is added to the Areas of Interest list in the Filter window.
  6. Repeat steps 2 to 5 for any other Areas of Interest by which you want to filter the Alarms List or Alarm Banner.
  7. If required, Use the Filter Window to Filter Alarm Entries by other types of filter.
  8. Select the OK button.
    The Filter window is closed and the alarm display is filtered. It only shows the alarms that meet the filter criteria.

To edit an existing Area of Interest filter:

  1. Select the relevant entry in the Areas of Interest list.
  2. Select the Edit button.
    A Reference browse window is displayed.
  3. Select the required Area of Interest from the window.
  4. Select the OK button to confirm the choice and close the window.
    The edited Area of Interest is updated in the Filter window’s Areas of Interest list.

To remove an existing Area of Interest filter:

  1. Select the relevant entry in the Areas of Interest list.
  2. Select the Remove button.
    The selected entry is removed from the Areas of Interest list.


Alarms Guide - Filter Alarms by Alarm Severity (Use the Filter Window to Filter Alarm Entries)

Filter Alarms by Alarm Severity

You can optionally filter the alarms in an Alarms List or the Alarm Banner by Severity.

To filter alarms by Severity:

  1. Display the Filter Window (see Use the Filter Window to Filter Alarm Entries).
  2. On a ViewX Client that can access multiple ClearSCADA databases, Specify the ClearSCADA Database for which you want to Filter Alarms.
  3. In the Severities section of the Filter window:
  1. Use the Minimum combo box to specify the minimum priority of alarms that are to be included in the List or Banner.

For example, if you select Medium, the Alarms List or Alarm Banner omits any alarms that have Low priority.

  2. Use the Maximum combo box to set the maximum priority of alarms that are to be included in the List or Banner.

For example, if you select Medium, the Alarms List or Alarm Banner omits any alarms that have High or Critical priority.

  3. Optionally use the Enabled check box(es) and adjacent Minimum and Maximum combo boxes to specify further alarm range(s) for inclusion in the List or Banner.
    The range of possible severities is configurable on a per system basis.

  4. If required, Use the Filter Window to Filter Alarm Entries by other types of filter.
  5. Select the OK button.
    The Filter window is closed and the alarm display is filtered. It only shows the alarms that meet the filter criteria.

Further Information

The Severities that apply to your database are configured using the ClearSCADA Server Configuration Tool: see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.


Alarms Guide - Filter Alarms by Alarm Category (Use the Filter Window to Filter Alarm Entries)

Filter Alarms by Alarm Category

You can optionally filter the alarms in an Alarms List or the Alarm Banner by Category.

To filter alarms by Category:

  1. Display the Filter Window (see Use the Filter Window to Filter Alarm Entries).
  2. On a ViewX Client that can access multiple ClearSCADA databases, Specify the ClearSCADA Database for which you want to Filter Alarms.
  3. On a ViewX client, use the check boxes in the Categories section of the Filter window to specify the categories of alarm that are to be included in the List or Banner:
  1. Select the check boxes of those categories that are to be included in the List or Banner.
  2. Clear the check boxes of any categories that are not to be included in the List or Banner.
    The entries in the Categories list vary, depending on the drivers that are installed on your system.

On a WebX client, select those categories that are to be included in the List or Banner. Alarms with categories that are highlighted will be included in the alarm displays.

To select multiple categories, hold down the SHIFT or CTRL keys while selecting the entries you require.

For more information on alarm categories, see Alarm Category.

  4. If required, Use the Filter Window to Filter Alarm Entries by other types of filter.
  5. Select the OK button.
    The Filter window is closed and the alarm display is filtered. It only shows the alarms that meet the filter criteria.


Alarms Guide - Filter Alarms by Alarm State (Use the Filter Window to Filter Alarm Entries)

Filter Alarms by Alarm State

You can optionally filter the alarms in an Alarms List or the Alarm Banner by State.

To filter alarms by State:

  1. Display the Filter Window (see Use the Filter Window to Filter Alarm Entries).
  2. On a ViewX Client that can access multiple ClearSCADA databases, Specify the ClearSCADA Database for which you want to Filter Alarms.
  3. To filter the List or Banner to show only alarms that are in a specific state (such as), select the required option from the State combo box at the bottom of the Filter window.

For example, select ‘Unacknowledged Uncleared’ for the List or Banner to only display alarms that have not been acknowledged and for which the condition that triggered the alarm still exists.

  4. If required, Use the Filter Window to Filter Alarm Entries by other types of filter.
  5. Select the OK button.
    The Filter window is closed and the alarm display is filtered. It only shows the alarms that meet the filter criteria.


Alarms Guide - Reset the Filters on an Alarms List or the Alarm Banner (Use the Filter Window to Filter Alarm Entries)

Reset the Filters on an Alarms List or the Alarm Banner

You can use the Reset Filter option to set an Alarms List or the Alarm Banner to disregard any filtering that you have applied using the Filter window. This returns the List or Banner’s filtering to its original state—the List or Banner is reset to show the same type of alarm data as when it was first displayed. This may include each of the alarms to which your User Account and ViewX or WebX client have access. However, if your User Account is configured to use a default Alarm Filter String, the original filter state of the Alarms List or Alarm Banner will also take into account any filter restrictions specified by that Alarm Filter String. A system administrator or high-level engineer typically configures any such default filters when a User Account is added to ClearSCADA (see Specify a Default Alarm Filter).

If your User Account allows you to filter entries in the Alarm Banner, ClearSCADA might be configured to automatically disregard any such filtering as soon as your User Account’s Banner Filter Timeout period is exceeded. Once this period is exceeded, ClearSCADA will return the Alarm Banner’s filtering to its original state.

To manually reset the filters on an Alarms List or the Alarm Banner:

  1. Right-click on the List or Banner.
    A context sensitive menu is displayed.
  2. Select the Reset Filter option.

The filtering for the Alarms List or Alarm Banner is reset—any additional filtering is removed and the original filtering reinstated.

With an Alarms List, you can also reset the filters using the following procedure:

  1. Select the Items menu from the ViewX menu bar.
    A further menu is displayed.
  2. Select the Reset Filter option.
    The filtering for the Alarms List is reset—any additional filtering is removed and the original filtering reinstated.

Further Information

Use the Filter Window to Filter Alarm Entries.


Alarms Guide - Sort the Entries in an Alarms List or the Alarm Banner

Sort the Entries in an Alarms List or the Alarm Banner

The order in which alarms are displayed on Alarms Lists and the Alarm Banner is determined by the alarm Sort Order.

On many ClearSCADA systems, the default Sort Order is State, Severity, Time. With such a Sort Order, the most recent Unacknowledged Uncleared alarm of the highest severity appears at the top of the List or Banner, followed by other Unacknowledged Uncleared alarms in descending severity and then time order. This is followed by the most recent Unacknowledged Cleared alarm of the highest severity, followed by any other Unacknowledged Cleared alarms, then finally the most recent Acknowledged Uncleared alarm of the highest severity, followed by any other Acknowledged Uncleared alarms.

If required, you can temporarily change the sort order from the default, so that the alarm information easier to view and interpret. You change the sort order on Alarms Lists and the Alarm Banner in the same way as other Lists in ClearSCADA (see Sort a List in the ClearSCADA Guide to Lists). You can only sort the order of entries in the Alarm Banner if the Banner is configured to Allow Sorting (see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client).

You can Reset the Sort Order on an Alarms List or the Alarm Banner back to the default, while that List or Banner remains on display. Should you close and then re-display an Alarms List or the Alarm Banner, the sort order will also revert to the default.

Further Information

Specify the default alarm entry sort order: see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client.


Alarms Guide - Reset the Sort Order on an Alarms List or the Alarm Banner (Sort the Entries in an Alarms List or the Alarm Banner)

Reset the Sort Order on an Alarms List or the Alarm Banner

The order in which alarms are displayed on Alarms Lists and the Alarm Banner is determined by the alarm Sort Order. On many ClearSCADA systems, the default Sort Order is State, Severity, Time.

If required, you can temporarily sort an Alarms List or the Alarm Banner to display the information in a different order from this default (see Sort a List in the ClearSCADA Guide to Lists). (You can only sort the order of entries in the Alarm Banner if the Banner is configured to Allow Sorting (see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client).)

To revert the sort order on an Alarms List back to its default, either:

  1. Select the Items menu from the ViewX menu bar.
    A further menu is displayed.
  2. Select the Default Sorting option.

Or:

  1. Right-click on the List.
    A context sensitive menu is displayed.
  2. Select the Default Sorting option.

The Sort order is reset to its original state—any additional sorting is removed and the default sorting reinstated.

To revert the sort order on the Alarm Banner back to its default:

  1. Right-click on the Alarm Banner.
    A context sensitive menu is displayed.
  2. Select the Default Sorting option.
    The Sort order is reset to its original state—any additional sorting is removed and the default sorting reinstated.

The sort order on either alarm display automatically reverts to the default should that List or Banner be closed and then re-displayed.


Alarms Guide - Alarm-Related Aspects of System Configuration

Alarm-Related Aspects of System Configuration

This section is for system administrators and engineers that are tasked with configuring ClearSCADA. The section summarizes the various alarm-related aspects of system configuration.

Any system-wide alarm configuration should be undertaken when a ClearSCADA system is installed. Client-specific configuration should be performed on existing clients as part of the system setup, and on new clients as they are added to the system. User-specific configuration should also be performed as part of the system setup, or as new User Accounts are added to the system.

ClearSCADA has sophisticated alarm handling capabilities.

The sections in the rest of this guide summaries the various alarm-related aspects of system configuration. The sections explain how to:

  • Set up the Alarms, Alarms Lists, and Alarm Banner Preferences—This section comprises a summary of the various system-wide, client- and user-specific settings that you might want to change from the defaults.

(For information on configuring the fonts and header colors on Alarms Lists and the Alarm Banner, see Specify the Preferred List Options on a ViewX Client in the ClearSCADA Guide to Lists.)

  • Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client—including the fonts and the default Sort Order of entries in Alarms Lists and the Alarm Banner.
  • Configure Additional Alarm Columns—how to add extra columns of information to Alarms Lists and the Alarm Banner.

The rest of this section summarizes other alarm-related configuration of which you need to be aware when setting up a ClearSCADA system:

  • Alarm Redirection
  • Alarm Severity
  • Alarm Suppression
  • Alarm Views
  • The various means by which you can Restrict Alarm Access.

Further Information

Optionally Specify a Default Alarm Filter per User Account.


Alarms Guide - Alarm Redirection (Alarm-Related Aspects of System Configuration)

Alarm Redirection

ClearSCADA supports Alarm Redirection, whereby specific alarms can be redirected manually and/or automatically. So, for instance, if a control center is unmanned when a high-priority alarm is raised, alarm redirection could be configured to forward that alarm automatically to an on-call engineer’s pager.

Each ClearSCADA system is supplied with a variety of Alarm Redirection Actions that enable you to specify the type of redirection that is required (see Introduction to Alarm Redirection in the ClearSCADA Guide to Alarm Redirection).

Each database item for which alarms can be redirected has a Redirection tab on its configuration Form, allowing you to specify up to 15 alarm redirections for that particular item. Further alarm redirections can be applied on a Group-wide basis.

For further information, see the ClearSCADA Guide to Alarm Redirection.


Alarms Guide - Alarm Severity (Alarm-Related Aspects of System Configuration)

Alarm Severity

Every database item for which alarms can be raised includes one or more Severity fields on its configuration Form. Use the Severity field(s) to specify the importance of the alarms and/or events that are associated with the item.

For information on Severity fields, see Defining Severities in the ClearSCADA Guide to Core Configuration. See the relevant configuration section for information on the severity settings that apply to specific types of database item.

(With a change in point state, you can also specify whether such a change is to raise or clear an alarm, or merely be logged as an Event. For more information, see the relevant point configuration section in the ClearSCADA Guide to Core Point Configuration, or the relevant driver guide.)


Alarms Guide - Alarm Suppression (Alarm-Related Aspects of System Configuration)

Alarm Suppression

ClearSCADA has the ability to suppress alarms on specific database items, depending whether a particular alarm is active on a ‘parent’ item. You can use this function to help prevent an important alarm being ‘masked’ by the occurrence of numerous other alarms, which themselves are raised as a result of the initial alarm becoming active.

When an alarm is suppressed, it is omitted from Alarms Lists and the Alarm Banner, but its alarm state is apparent on other displays. Users cannot acknowledge alarms that are suppressed and any alarm redirections remain inactive for the period that the alarms remain suppressed.

Further Information

Configure Alarm Suppression: see Configure any Alarm Suppression Requirements in the ClearSCADA Guide to Core Configuration.

Working with Alarm Suppression:

  • see The Affects of Alarm Suppression in ClearSCADA in the ClearSCADA Guide to Core Configuration.
  • see Alarm Redirection and Suppressed Alarms in the ClearSCADA Guide to Alarm Redirection.


Alarms Guide - Alarm Views (Alarm-Related Aspects of System Configuration)

Alarm Views

Each database item that can generate alarms can be configured to have an Alarm View. An Alarm View is a ‘file object’, such as a Mimic, that can be used as an aid when an alarm is raised. You can configure Alarm Views on a per item or per Group basis (see Define an Alarm View in the ClearSCADA Guide to Core Configuration).

Alarm views are displayed using the Display Alarm View pick action.


Alarms Guide - Restrict Alarm Access (Alarm-Related Aspects of System Configuration)

Restrict Alarm Access

Access to alarms or alarm-related actions can be restricted:

  • By security permission—see Allocating Security Permissions in the ClearSCADA Guide to Security
  • By Area of Interest—see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration
  • By disabling alarms on either a per item, or per Group basis—see Disable Alarms and Enable Alarms
  • By Alarm Suppression
  • By using the Set Responsibility Action Alarm Redirection action to restrict the ability to acknowledge a particular alarm to that of particular User, User Group, or specific ViewX workstation(s)
  • When under Exclusive Control—see Exclusive Control in the ClearSCADA Guide to Security.

In addition to the above, a Default Alarm Filter can be used to present a subset of alarms to a user (see Specify a Default Alarm Filter). If required, the user can change this initial filter to display further alarms to which they have access.


Alarms Guide - Set up the Alarms, Alarms Lists, and Alarm Banner Preferences

Set up the Alarms, Alarms Lists, and Alarm Banner Preferences

This section is for system administrators and high-level engineers who are setting up the preferences for Alarms, Alarms Lists, and the Alarm Banner on either a system-wide, client-specific, or user-specific basis (see Set up the List Preferences in the ClearSCADA Guide to Lists).

ClearSCADA is supplied with a set of predefined defaults for Alarms, Alarms Lists, and the Alarm Banner. These affect, for example, the system colors that are used to indicate that an item is in alarm. If required, these options can be changed from the defaults. Some of these options affect alarms on a system-wide basis, whereas other options can be specified on a per-client (workstation) basis, or on a per-user basis.

This section summarizes the properties you might want to consider when setting up:

  • System-Wide Alarm and Alarms List Preferences
  • Client-Specific Alarms List and Alarm Banner Preferences
  • User-Specific Alarm-Related Preferences.

In addition to the above, a system administrator also needs to allocate the required Security Permissions to each User Account, User Group, and item in the database. This includes the permissions that determine whether alarms can be acknowledged, removed, and/or disabled. For further information, see Allocating Security Permissions in the ClearSCADA Guide to Security.

Further Information

Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client.

Configure Additional Alarm Columns.

Display a full screen Alarm Banner on a multi-head ViewX client: see Configure a Head to Show a Full Screen Alarm Banner in the ClearSCADA Guide to Client Administration.

Display a full screen Alarms List in ViewX: see Use a ViewX Command to Display a Full Screen Alarms List in the ClearSCADA Guide to Client Administration.


Alarms Guide - System-Wide Alarm and Alarms List Preferences (Set up the Alarms, Alarms Lists, and Alarm Banner Preferences)

System-Wide Alarm and Alarms List Preferences

This section summarizes those Alarm and Alarms List options that a system administrator can configure on a system-wide basis. Such options, if required to differ from the defaults, should be specified on each server when a ClearSCADA system is first installed. The options are specified using the ClearSCADA Server Configuration Tool.

You can use the ClearSCADA Server Configuration Tool to:

  • Specify the Alarms Settings, including:
  • Whether alarms are actually enabled on your system
  • Whether the ‘Area of Interest’ feature is enabled on your system. (For more information on this feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.)
  • Whether an alarm’s ‘visible’ time is used as its alarm active time in Alarms Lists and the Alarm Banner. (For more information, see Understand the Information that is Displayed on an Alarms List or Alarm Banner.)
  • Whether any ‘standard comments’ are available to users that can redirect or acknowledge alarms and associate such actions with a comment.

For more information, see Alarms Settings in the ClearSCADA Guide to Server Administration.

  • Specify whether the Exclusive Control feature is enabled on your system, and if so, whether a person who has exclusive control can, for example, remove, acknowledge, and/or disable alarms (see Exclusive Control Settings in the ClearSCADA Guide to Server Administration).
  • Specify any system-wide, ViewX user, WebX user, or standard pick action menu Permission Restrictions, including whether all users are denied the permission to Acknowledge Alarms, or Remove Alarms. For more information, see Define whether any Permissions are Restricted in the ClearSCADA Guide to Security.
  • Specify the WebX settings, including the order in which columns are sorted on the Alarms List whenever it is viewed from a WebX client (see WebX Settings in the ClearSCADA Guide to Server Administration).
  • Specify whether points have two sets of Alarm Limits, and whether analog points can have separate master station alarm limits (see Alarm Limits in the ClearSCADA Guide to Server Administration). For more information on using this feature, see the relevant Multiple Alarm Limits section within the ClearSCADA Guide to Core Point Configuration.
  • Specify whether any point types have additional Point State Alarms. For information on configuring additional alarm states, see Point State Alarms in the ClearSCADA Guide to Server Administration. For more information on using this feature, see Multiple Point State Alarms in the ClearSCADA Guide to Core Point Configuration.
  • Specify the alarm and event Severities settings, including:
  • The colors used to indicate, for example, unacknowledged alarms on the Alarms List.
  • The Alarms List and Alarm Banner background colors (such as the background color used for any alarms that a user can acknowledge)
  • Which user-initiated alarm actions (such as ‘Remove Alarm’ and ‘Unacknowledge Alarm’) are allowed on the system.

For more information, see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.

To access a ClearSCADA system, users typically log on via a User Account. Anyone who accesses the system without logging on, is logged on automatically via the Guest or Web User accounts.

Use the Root or System Group Form to define the system-wide settings for the Guest User, including:

  • Whether the Allow Group Alarm Operations feature is made available to the Guest User.
  • The Default Alarm Filter that defines the alarms to which the Guest User has access.
  • If the Area of Interest feature is used on your system, any Area of Interest Filters. This can also affect which alarms are visible to the Guest User.

For information on configuring any of the above, see Define the Global Settings for All Guest and Web User Accounts in the ClearSCADA Guide to Security.

If required, the ability to acknowledge specific alarms can optionally be restricted to a particular User, User Group, or ViewX workstation. Such a restriction is configured on a per-item or per-Group basis. For information, see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection.

You can optionally use Alarm Banner scripts to add ‘custom’ actions to the Alarm Banner’s context sensitive menu (see Alarm Banner Scripts in the ClearSCADA Guide to Scripting).


Alarms Guide - Client-Specific Alarms List and Alarm Banner Preferences (Set up the Alarms, Alarms Lists, and Alarm Banner Preferences)

Client-Specific Alarms List and Alarm Banner Preferences

This section summarizes those Alarms List and Alarm Banner options that a system administrator can configure on a per client basis. Such options, if required to differ from the defaults, should be specified on existing ClearSCADA Clients (workstations) when a ClearSCADA system is first installed, and then on new clients whenever they are added to the system. On each ViewX Client, you specify the options using the Options window (available from the ViewX Tools menu).

You can use the Options window to specify:

  • The Alarm Banner settings that are to apply to that particular client (see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client).
  • The format in which Lists are to be displayed on that particular client (see Specify the Preferred List Options on a ViewX Client in the ClearSCADA Guide to Lists).

For anyone that accesses the system without logging on via a User Account, use the Options window to define the client-specific Features that are available to the Guest User, including:

  • Operational features, such as whether the Guest User actually has access to the Alarms List and Alarm Banner on that particular client.
  • The Alarm Banner/List settings, including whether the Guest User can perform actions on multiple alarms on that particular client.

For information on configuring either of the above, see Define the Client Specific Settings for the Guest User in the ClearSCADA Guide to Security.

In addition to the above, whenever a ViewX client is added to the system, a system administrator has to specify the connection between that client and the system. This is done using the Client Configuration window. The window is also used to specify:

  • The Workstation Name that applies to that particular ViewX workstation (client). The name identifies the client whenever alarm redirection is used to restrict the ability to acknowledge alarms to that particular workstation (see Define the Workstation Name for the ViewX Client in the ClearSCADA Guide to Client Administration).

For information on using alarm redirection to restrict the ability to acknowledge alarms, see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection.


Alarms Guide - User-Specific Alarm-Related Preferences (Set up the Alarms, Alarms Lists, and Alarm Banner Preferences)

User-Specific Alarm-Related Preferences

This section summarizes the alarm-related options that a system administrator can configure on a per-user basis. The options apply to users that log onto the system using a User Account.

The options for each individual User Account, if they are to differ from the defaults, should be specified once that User Account has been added to the system.

For a user that logs onto the system using an individual User Account, use that user’s User Form to:

  • Specify whether the Allow Group Alarm Operations feature is made available to that user.
  • If the Area of Interest feature is used on your system, specify any Area of Interest Filters associated with the user. This can affect which alarms and events are visible to the user. (For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.)
  • Specify the Default Alarm Filter that defines the alarms to which the user has access.
  • For users that are accessing the system via a ViewX client (as opposed to WebX):
  • Specify Operational features, including whether the user actually has access to the Alarms List and Alarm Banner.
  • Specify the user’s Alarm Banner/List settings, including whether that user can perform actions on multiple alarms or filter entries in the Alarm Banner (including whether such filtering is disregarded whenever a defined timeout period is exceeded).

For information on configuring any of the above, see Creating a User Account in the ClearSCADA Guide to Security. Also see Specify a Default Alarm Filter.


Alarms Guide - Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client

Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client

ClearSCADA is supplied with a set of predefined defaults that affect the appearance of the Alarm Banner and Alarms Lists on ViewX Clients (workstations). These defaults determine, for example, the fonts, the sort order, and the default bell sound.

If required, a system administrator or high-level engineer can change these properties from the defaults, on a per-client basis.

To change the default properties of the Alarm Banner and the Alarms Lists on a ViewX client:

  1. Log on via a User Account that has the Configure Options feature enabled.
  2. Select the Tools menu.
    A further menu is displayed.
  3. Select Options.
    The Options window is displayed.
  4. Select the Alarm Banner tab.
    The properties on the Alarm Banner tab...
    ...determine many of the settings used for the Alarm Banner and Alarm Bell (along with some settings for the Alarms Lists).

  5. Use the fields on the tab to determine the Alarms List, Alarm Banner and Alarm Bell settings:
  • Use the fields within the Alarm Banner section of the tab to Specify the Properties of the Font used for the Alarm Banner.
  • Use the fields within the Alarm Bell section to Specify the Properties of the Font used for the Alarm Bell.
  • Use the Sort Order combo box to specify the order in which alarms are sorted on Alarms Lists and the Alarm Banner.

The default sort order is State, Severity, Time. This results in the most recently raised Unacknowledged Uncleared alarms of the highest severity appearing at the top of the Alarm Banner. This is followed by any Unacknowledged Uncleared alarms of the next highest severity, again in chronological order. Following on from the Unacknowledged Uncleared alarms are any Unacknowledged Cleared alarms in severity and then time order, and then finally any Acknowledged Uncleared alarms in severity and then time order. (For more information on alarm states and severity, see Alarm Severity, Status, and Category.)

(Should you opt to change the Sort Order, you may have to close and then re-display any currently open Alarms Lists for the change to come into effect.)

  • Use the Flashing Column combo box to specify which column(s) on the Alarms Lists and the Alarm Banner are to flash should an alarm be in one of the alarm states that is configured to flash. The default is for All columns to flash, but you can specify an single named column, or choose None if none of the columns are to flash.

(Flashing alarm states include Unacknowledged Uncleared, and Unacknowledged Cleared by default—for information on configuring alarm severity colors and flash states, see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.)

  • Select the Allow Column Resizing check box if users are to be able to resize the columns on the Alarm Banner. If this check box is selected, users can resize the Alarm Banner’s columns by using the cursor to drag the lines that separate the Alarm Banner’s Headers (see Change the Size of Columns on an Alarms List or the Alarm Banner Directly).

Ensure that the check box is clear (the default) if users are not to be able to resize the Alarm Banner’s columns directly on this particular ViewX client. (Users will still be able to resize the columns by using the Alarm Columns window (see Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns).)

  • Select the Allow Sorting check box if users are to be able to manually change the order in which alarms are displayed in the Alarm Banner. If this check box is selected, users can select a column heading to sort the alarms in chronological or alphabetical order by the values in that column. Selecting a column heading sorts the alarms in ascending order; re-selecting the column heading sorts the alarms in descending order. Additionally, when a user right-clicks on any entry in the Alarm Banner, the context sensitive menu that is displayed will include the additional options Sort and Default Sorting. Similarly, if a user selects one of the Alarm Banner’s Headers, the context sensitive menu will include additional options such as Sort Ascending, Sort Descending, Sort, and Default Sorting. These options can be used to sort the entries in the Alarm Banner in the same way as the same entries on an Alarms List—for information, see Sort the Entries in an Alarms List or the Alarm Banner.

Ensure that the check box is clear (the default) if users are not to be able to manually sort the order in which alarms are displayed in the Alarm Banner on this particular ViewX client.

  • Select the Scroll to top on acknowledge, remove or manual redirect check box for ClearSCADA to automatically scroll to the top of the Alarm Banner whenever a user acknowledges, removes, or manually redirects an alarm. With an alarm that is manually redirected, ClearSCADA only scrolls to the top of the Alarm Banner automatically if the Redirection Action’s Deselect Alarm After Manual Redirection Action feature is enabled (see Configure the Properties on the Action Tab in the ClearSCADA Guide to Alarm Redirection).

Ensure that the Scroll to top on acknowledge, remove or manual redirect check box is clear if ClearSCADA is not to automatically scroll to the top of the Alarm Banner. Whenever a user acknowledges an uncleared alarm, the Alarm Banner continues to display that alarm entry and, if applicable, scrolls to the alarm’s new position in the Alarm Banner List. Whenever a user acknowledges an unacknowledged cleared alarm, ClearSCADA removes the cleared entry and continues to display that part of the Alarm Banner List.

  • Use the Include Simple Events in Status Bar check box to specify which type(s) of event are displayed in the Status Bar (see Specify Whether Simple Events are Displayed in the Status Bar in the ClearSCADA Guide to Lists).
  • If required, you can associate a WAV sound file with the alarms on a ViewX client. The sound file will be used instead of the default alarm bell sound whenever an alarm is raised. To use such a file, use the browse button adjacent to the Default Bell Sound field to display the Select Sound window. Select the required WAV file from the window.

(You can use the ClearSCADA Server Configuration Tool to associate a WAV sound file with any of the severity ranges on the ViewX clients on your system—see Associate a WAV Sound File with a Severity Range in the ClearSCADA Guide to Server Administration.)

  • On multi-headed ViewX clients, use the Sound Bell on Head combo box to specify the head(s) (monitors) on which any audible alarm bell is to sound. Leave at the default of 1 on single-headed clients. Only the head that sounds the bell can silence it.
  6. Select the OK button to confirm the changes and close the Options window.
  7. Repeat the above steps for any other ViewX clients on which the properties are to differ from the defaults.

Further Information

Specify the Colors used in List and Alarm Banner Headers in the ClearSCADA Guide to Lists.

Other Properties that Affect an Alarms List or Alarm Banner’s Format.

Display a full screen Alarm Banner on a multi-head ViewX client: see Configure a Head to Show a Full Screen Alarm Banner in the ClearSCADA Guide to Client Administration.

Display a full screen Alarms List in ViewX: see Use a ViewX Command to Display a Full Screen Alarms List in the ClearSCADA Guide to Client Administration.

Use Alarm Banner scripts to add ‘custom’ actions to the Alarm Banner’s context sensitive menu: see Alarm Banner Scripts in the ClearSCADA Guide to Scripting.


Alarms Guide - Specify the Properties of the Font used for the Alarm Banner (Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client)

Specify the Properties of the Font used for the Alarm Banner

Use the Alarm Banner section on the Option window’s Alarm Banner tab to specify the properties of the font used in the Alarm Banner’s headers and rows:

Use the fields within the Alarm Banner section of the Alarm Banner tab...
...to specify the properties of the font that is used for the Alarm Banner.

  • Font—Use the combo box to display a list of the fonts that are available to this particular client. Select the required font from the list.
  • Height—Use the spin box to specify the required font height. The default is 10 points.
  • Bold—Select this check box for the text in the Alarm Banner’s headers and rows to be bold. Clear the check box for the text’s weight to be regular.
  • Italic—Select this check box for the text in the Alarm Banner’s headers and rows to be italic. Clear the check box for the text’s angle to be regular.
  • Custom Background Color—Use this check box to determine the background color of alarms on both the Alarm Banner and Alarms Lists. The color applies to alarm entries other than any alarms to which the ClearSCADA Server Configuration Tool’s Background Colors apply (see Define the Background Colors for a Severity in the ClearSCADA Guide to Server Administration.)

Clear the check box for ClearSCADA to use the Windows® default for the background color on Alarms Lists and the Alarm Banner. (The default is the color that is specified for 3D Objects on the Windows® Display applet, accessed via the Control Panel.)

Select the Custom Background Color check box for the adjacent color button to be used to determine the background color. Click on the color if you want to change it from the default. A pop-up color window is displayed. Either select a color from the window, or select the ... option and create a custom color (see Using the Color Window in the ClearSCADA Guide to Core Configuration).

Once you have confirmed the settings by selecting the Option window’s OK button, the changes come into effect immediately.


Alarms Guide - Specify the Properties of the Font used for the Alarm Bell (Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client)

Specify the Properties of the Font used for the Alarm Bell

Use the Alarm Bell section on the Option window’s Alarm Banner tab to specify the properties of the font that is used for the Alarm Bell:

Use the fields within the Alarm Bell section of the Alarm Banner tab...
...to specify the properties of the font that is used for the Alarm Bell.

  • Font—Use the combo box to display a list of the fonts that are available to this particular client. Select the required font from the list.
  • Height—Use the spin box to specify the required font height. The default is 20 points.
  • Bold—Select this check box for the Alarm Bell’s text to be bold. Clear the check box for the text’s weight to be regular.
  • Italic—Select this check box for the Alarm Bell’s text to be italic. Clear the check box for the text’s angle to be regular.

Once you have confirmed the settings by selecting the Option window’s OK button, the changes come into effect immediately.

Further Information

For information on using the Alarm Bell, see Alarm Banner.

The audible alarm can be disabled on a per user basis (see Define the Alarm Banner and Alarm List Settings for a User in the ClearSCADA Guide to Security).


Alarms Guide - Other Properties that Affect an Alarms List or Alarm Banner's Format (Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client)

Other Properties that Affect an Alarms List or Alarm Banner’s Format

This section summarizes other properties that affect the format of an Alarms List or the Alarm Banner. References are provided to the sections that explain such properties in more detail.

This section contains information on:

  • The Background Color used on Alarms Lists and the Alarm Banner
  • The Foreground Color of Entries in Alarms Lists or the Alarm Banner.


Alarms Guide - The Background Color used on Alarms Lists and the Alarm Banner (Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client)

The Background Color used on Alarms Lists and the Alarm Banner

The background color used on Alarms Lists and the Alarm Banner is inherited from the Windows® system palette by default. If required, a system administrator or high-level engineer can specify a different color.

The background color that ClearSCADA uses for Alarms Lists and the Alarm Banner can be changed from the default.

On a ViewX client, a custom background color can be specified on the Alarm Banner tab of the Options window (see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client).

For WebX clients, the preferred background color is specified in the WebX section of the ClearSCADA Server Configuration Tool (see Define the Alarms List Order and Background Settings in the ClearSCADA Guide to Server Administration).

Additionally, a series of alarm entry Background Colors can be specified using the ClearSCADA Server Configuration Tool. The colors can optionally be used to highlight individual alarm entries in Alarms Lists and the Alarm Banner when those alarms:

  • Are selected in the List or Banner
  • Are associated with an Alarm Response (see Respond to an Alarm)
  • Can be acknowledged.

For more information, see Define the Background Colors for a Severity in the ClearSCADA Guide to Server Administration.

Further Information

The Foreground Color of Entries in Alarms Lists or the Alarm Banner.


Alarms Guide - The Foreground Color of Entries in Alarms Lists or the Alarm Banner (Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client)

The Foreground Color of Entries in Alarms Lists or the Alarm Banner

The foreground color that ClearSCADA uses for displaying an entry in an Alarms List or the Alarm Banner is determined by that entry’s state.

An item’s Severity determines its color in an Alarms List and the Alarm Banner.

Further Information

Severity Colors: see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.

The Background Color used on Alarms Lists and the Alarm Banner.

The Color of Entries in a List other than the Alarms List in the ClearSCADA Guide to Lists.


Alarms Guide - Configure Additional Alarm Columns

Configure Additional Alarm Columns

This section is for system administrators and high-level engineers.

If required, you can add extra columns to the Alarms Lists and Alarm Banner. This is useful when additional information such as point states and data from custom fields is needed in the alarm displays.

Any extra columns you create will be shown in the Alarms Lists and in the Alarm Banner. (If you add or remove extra alarm columns while an Alarms List is on display, you may need to close and then re-open the List to show the column changes.)

To configure extra alarm columns:

  1. Display the Extra Alarm Columns Window
  2. Use the Extra Alarm Columns window to:
  • Add an Extra Alarm Column
  • Edit an Extra Alarm Column
  • Change the Default Order of Extra Alarm Columns
  • Remove an Extra Alarm Column.


Alarms Guide - Display the Extra Alarm Columns Window (Configure Additional Alarm Columns)

Display the Extra Alarm Columns Window

You can use the Extra Alarm Columns window to add, edit, and remove extra alarm columns. You can only access the Extra Alarm Columns window if you log on via a User account that has the Configure permission for the system item.

To display the Extra Alarm Columns window:

  1. Log on to ViewX via a User account that has the Configure permission for the system item and has the Configure Database option enabled in the User account’s configuration.
  2. In the Database Bar, right-click on the system item (Root Group), then select the Alarm Columns option from the context sensitive menu.
    The Extra Alarm Columns window is displayed. The window header indicates the ClearSCADA system to which the alarm columns apply.

You can use the Extra Alarm Columns window to:

  • Add an Extra Alarm Column
  • Edit an Extra Alarm Column
  • Change the Default Order of Extra Alarm Columns
  • Remove an Extra Alarm Column.


Alarms Guide - Add an Extra Alarm Column (Configure Additional Alarm Columns)

Add an Extra Alarm Column

You can add new columns to the Alarms Lists and Alarm Banner displays. This is useful when additional information is required, for example, if data from custom fields needs to be included in the alarm information.

To add a new column to the Alarms Lists and Alarm Banner:

  1. Display the Extra Alarm Columns Window.
  2. Select the Add button to display the Configure Alarm Column window.
  3. In the Name field, enter a name for the new column. The name that you enter will be shown at the top of the column on the Alarms Lists and Alarm Banner.
  4. The entries in the Categories list represent different types of alarm. Entries other than text alarm entries, relate to tables in the database. The entries in the list vary, depending on the drivers that are installed on your system. (For information on the ‘core’ categories, see Alarm Category; for any driver-specific alarm categories, see the relevant driver guide.)

For each category in the list:

  1. Select the category, so that its attributes are shown in the Attributes list.
  2. Select the attribute that represents the data that you want to be shown when an alarm of the chosen category is raised. (For any category for which a relevant attribute does not exist, select the <None> attribute.) Each attribute typically corresponds to a field in the database.

Example:

If you have created a new column that is to show receipt time of each alarm, you could select each category in turn and specify the ReceiptTime attribute for each category. This would set the new column to display the receipt time of every type of alarm that is raised. (If the Alarms Lists and Alarm Banner are not to display the receipt time for certain types of alarm, you could assign the <None> attribute to those particular alarm categories.)

  3. Repeat steps i and ii for the other categories in the list.

(By default, ClearSCADA assigns the <None> attribute to any categories that you do not select, so that the new column does not display a value for those type(s) of alarm.)

  5. Select the OK button to confirm your selection and close the Configure Alarm Column window.
    The name of the new column and its associated categories and attributes are displayed in the Extra Alarm Columns window.
  6. Repeat steps 2 to 5 for any other columns that you want to add to the Alarms Lists and Alarm Banner.
  7. Once you have added the extra column(s), select the OK button on the Extra Alarm Columns window.
    The changes are saved and the window is closed. The extra column(s) are added to the Alarm Banner, and will be included on Alarms Lists whenever they are displayed.

Example:

The figure below shows an Alarms List with an extra column named ‘Current Channel’. The column displays the CurrentChannelName (the name of the channel that is currently being used) for alarms that have been raised due to an Outstation Comms, Outstation Error, or Outstation Hardware error.

For alarms that are raised due to an Outstation Comms, Outstation Error, or Outstation Hardware alarm, the extra column (named ‘Current Channel’) displays the channel that is currently being used for that outstation.
For other categories of alarm, no value is displayed in the extra column.

If required, you can Change the Default Order of Extra Alarm Columns. You can also Adjust the Columns on an Alarms List or the Alarm Banner so that, for example, columns, including those that appear on the Alarm Banner or in the Alarms List by default, are displayed in a different order, or have a different width.


Alarms Guide - Edit an Extra Alarm Column (Configure Additional Alarm Columns)

Edit an Extra Alarm Column

You can change the configuration of any of the extra columns on an alarm display at any time.

To change the configuration of an extra column on an alarm display:

  1. Display the Extra Alarm Columns Window.
  2. Select the name of the column that you want to change.
  3. Select the Edit button to display the Configure Alarm Column window.
  4. Use the Configure Alarm Column window to alter the configuration of the extra column as required. The Configure Alarm Column window works in the same way as described in Add an Extra Alarm Column.
  5. Select the OK button to confirm your selections and close the Extra Alarm Columns window.


Alarms Guide - Change the Default Order of Extra Alarm Columns (Configure Additional Alarm Columns)

Change the Default Order of Extra Alarm Columns

You can use the Extra Alarm Columns window to alter the default order in which the extra alarm columns appear on the Alarms Lists and Alarm Banner. This is useful when you need to rearrange the columns so that related information is displayed side-by-side. The Extra Alarm Columns window settings only apply the default order of any extra columns that have been added to the Alarms Lists and Alarm Banner.

To change the order of the extra columns on the alarm displays:

  1. Display the Extra Alarm Columns Window.
  2. Select the name of the column that you want to change.
  3. Select the Move Up button to move the column up in the list or select the Move Down button to move the extra column down in the list.

The extra column at the top of the list on the Extra Columns for System window is the first extra column to be shown after the default columns on the Alarms Lists and Alarm Banner. The second extra column in the list is shown to the right of the first extra column, the third extra column is shown to the right of the second extra column and so on.

  4. Select the OK button to confirm your selections and close the Extra Alarm Columns window.

You can re-organize the columns on an individual client by dragging and dropping the columns in the Alarms Lists or Alarm Banner as required (see Adjust the Columns on an Alarms List or the Alarm Banner).

For information on changing the default width, or display order of an alarm column on a client, see Use the Alarm Columns Window to Change the Alarms List or Alarm Banner Columns.


Alarms Guide - Remove an Extra Alarm Column (Configure Additional Alarm Columns)

Remove an Extra Alarm Column

You can use the Extra Alarm Columns window to remove any of the extra alarm columns from the Alarms Lists and Alarm Banner.

To remove an extra column:

  1. Display the Extra Alarm Columns Window.
  2. Select the name of the column that you want to remove.
  3. Select the Remove button to delete the extra alarm column.
  4. Select the OK button to confirm your selection(s) and close the Extra Alarm Columns window.


Alarm Redirection Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Alarm Redirection Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Alarm Redirection Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Alarm Redirection Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Alarm Redirection Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Alarm Redirection Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to use ClearSCADA’s alarm redirection feature. The feature can be used to:

  • Redirect alarms to engineers that are not manning a ClearSCADA workstation
  • Trigger a pick action (method) in response to a particular alarm situation
  • Change an alarm’s severity level
  • Restrict the ability to acknowledge particular alarms
  • Trigger an operating system command in response to a particular alarm situation.

For more information, see Introduction to Alarm Redirection.


Alarm Redirection Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for users who need to perform any of the following tasks:

  • Determine a system’s alarm redirection requirements
  • Configure a Redirection Action, Action Roster, User Roster, or Alarm Redirection Calendar
  • Configure a database item’s Redirection properties
  • Manually redirect alarms
  • Respond to redirected alarms
  • Troubleshoot a system’s alarm redirection settings.


Alarm Redirection Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Alarm Redirection Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Alarms

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Logic

ClearSCADA Guide to Mimics

ClearSCADA Guide to Scripting

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Security

ClearSCADA Guide to the Pager Driver.


Alarm Redirection Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Alarm Redirection Guide - Introduction to Alarm Redirection

Introduction to Alarm Redirection

Alarm Redirection enables alarms to be redirected to engineers that are not manning a ClearSCADA workstation—for example, engineers that are on site. It also allows other actions, such as performing a one-shot call on an outstation, to be undertaken automatically when particular alarm situations occur.

The alarm redirection feature allows ClearSCADA to redirect an item’s alarms:

  • As an e-mail or voice message
  • As a pager or SMS (mobile telephone) text message
  • To perform an action on an item (known as invoking a method)
  • To alter the alarm’s severity
  • To restrict the ability to acknowledge an alarm
  • To execute a Windows® system command (for instance, to run an external application)
  • On a roster basis
  • On a calendar basis.

Alarm redirection is available for database items that can have alarms, including, for example, points, outstations, and channels. Each item can have up to 15 alarm redirections. However, if the item is in a Group, further alarm redirections can be applied on a group-wide basis, as the Group can also have alarm redirections.

Alarm redirections can be cascaded—if the alarm is redirected, and has not been dealt with within a defined time, the alarm can be redirected again, using a different redirection action.

For more information, see Understand Alarm Redirection.

This guide explains the considerations and Preparation that is required before configuring alarm redirections on a system. It also explains Setting up Alarm Redirections on a ClearSCADA System and includes detailed sections on how to:

  • Choose a Type of Alarm Redirection
  • Configure a User Roster
  • Configure a Redirection Action
  • Configure an Action Roster
  • Configure an Alarm Redirection Calendar
  • Configure Alarm Redirections for an Item or Group.

It also explains the Trip Sequences Supported by Redirection Actions and Troubleshooting Redirection Action Trip Sequences.

NOTE: ClearSCADA can be configured to trigger a particular Method Action immediately, whenever an alarm state change occurs, regardless of the alarm priority or when the alarm changes state. If this is required, consider whether to configure a Method on the Alarm tab of a Form (see Configure a Method Action to Trigger at Every Alarm State Change in the ClearSCADA Guide to Core Configuration).


Alarm Redirection Guide - Understand Alarm Redirection (Introduction to Alarm Redirection)

Understand Alarm Redirection

If required on your system, you can configure ClearSCADA to redirect alarms for:

  • A system (database) including the Groups, sub-Groups and items in that database
  • A Group (including the items within that Group and any sub-Groups)
  • An individual database item.

For each of the above, you can configure up to 15 alarm redirections, each of which can be configured to trigger automatically, manually, or both. In each case, you configure the alarm redirections on the Redirection tab of the appropriate configuration Form. You specify the alarm redirections in the order in which ClearSCADA is to check them: from the top row downwards. For each alarm redirection that is required, you specify the conditions under which ClearSCADA is to redirect the alarm, the action that is to be performed, or the Action Roster or redirection Calendar that is to come into force.

When an alarm occurs, ClearSCADA checks the trigger type of the action, action roster, or alarm redirection calendar at the top of the Redirection tab downwards, on the affected system, Group, or individual item.

For each alarm redirection that is to trigger automatically:

  • If the alarm condition does not meet any of the trigger states or other redirection criteria, ClearSCADA does not redirect the alarm.
  • If the alarm condition does meet one or more trigger states and other redirection criteria, ClearSCADA waits for any delay time to expire. If the alarm condition remains unchanged when the delay expires, ClearSCADA redirects the alarm, as per the action/action roster/alarm redirection calendar specified for that redirection.

For each alarm redirection that is to be triggered manually:

  • If the alarm condition does not meet any of the trigger states or other redirection criteria, no redirection takes place.
  • If the alarm condition does meet one or more trigger states and other redirection criteria, custom menu option(s) become available to enable users to manually trigger those redirection(s).

For each alarm redirection that can be triggered both manually and automatically:

  • If the alarm condition does not meet all of the redirection criteria, no redirection occurs.
  • If the alarm condition meets the redirection criteria:
  • Custom menu option(s) become available to enable users to trigger the relevant redirection(s).

Additionally:

  • Once any delay time expires, if the alarm condition remains unchanged, ClearSCADA redirects the alarm automatically.

NOTE: There are certain Circumstances in which Alarm Redirections do not Trigger.

Further Information

Preparation.

Setting up Alarm Redirections on a ClearSCADA System.

Choose a Type of Alarm Redirection.


Alarm Redirection Guide - Preparation (Introduction to Alarm Redirection)

Preparation

If alarms are to be redirected on your system, you will need to consider:

  • Under what circumstances are the alarms to be redirected?

For example:

  • Is ClearSCADA to redirect alarms automatically, or are operators and engineers to be given the option to redirect alarms if they deem this necessary? For more information, see Define the Trigger Type.
  • Are the alarms only to be redirected if they are in a particular state, such as Unacknowledged? For more information, see Define the Trigger State.
  • Are alarms to be redirected every time, or only on specific occasions, such as when control rooms are unmanned, or during company shutdown periods?

You can specify the time window during which redirection(s) take place (see Define When the Redirection Action is Active).

You can also redirect alarms on a Alarm Redirection Calendar or Action Roster basis.

  • If the Area of Interest feature is enabled on your system, are only those alarms that are associated with specific Area(s) of Interest to be redirected?

You can specify an Area of Interest for each redirection—see Specify the Area of Interest for which Alarms are Redirected.

  • For alarms that are to be redirected automatically:
  • Are the alarms only to be redirected if they remain in a particular state for a set amount of time?

You can specify a Delay for each redirection—see Define a Delay.

  • Are there circumstances for which ClearSCADA is to abort a redirection? For instance, if an alarm is acknowledged within the Delay time.

You can specify an Abort State for each redirection—see Define the Abort State.

  • How are alarms to be redirected? For instance, in a pager or e-mail message, or to trigger ClearSCADA to perform a particular action. For more information, see Choose a Type of Alarm Redirection.

If alarms are to be redirected in a pager or e-mail message:

  • Are the messages to be sent to individual Users, User Groups, or nominated individuals on User Rosters? (For information on User Rosters, see Configure a User Roster.)
  • Is sending of messages to be inhibited under particular circumstances? For instance, when the intended recipient is logged on to ClearSCADA. (For more information, see Define the E-Mail Action Details, or see Define the Pager Action Details.)
  • Are alarms to be redirected on a per system, per Group, or per item basis?

You can associate up to 15 alarm redirections with each item for which ClearSCADA can generate an alarm. You can also associate up to 15 alarm redirections with each Group, including your system’s Root Group. For more information, see Configure Alarm Redirections for an Item or Group.

For information on accessing the Root Group, see Configure the Properties of the Root or System Group in the ClearSCADA Guide to Core Configuration.

NOTE: ClearSCADA also supports alarm suppression, whereby alarms raised on certain items are omitted from alarm displays while a specific alarm on another item is active. For more information, see Alarm Suppression in the ClearSCADA Guide to Alarms.


Alarm Redirection Guide - Setting up Alarm Redirections on a ClearSCADA System (Introduction to Alarm Redirection)

Setting up Alarm Redirections on a ClearSCADA System

To set up alarm redirections on your system:

  1. Carry out any necessary Preparation.
  2. If alarms are to be redirected to a nominated individual on a User Roster, configure the required User Roster(s) (see Configure a User Roster).
  3. Configure the required redirection Actions (see Configure a Redirection Action).
  4. If alarms are to be redirected on an Action Roster basis, configure the required Action Roster(s) (see Configure a User Roster).
  5. If alarms are to be redirection on a Calendar basis, configure the required Calendar(s) (see Configure an Alarm Redirection Calendar).

NOTE: Do not confuse Alarm Redirection Calendars with ‘normal’ Calendars. ‘Normal’ Calendars are used alongside other ClearSCADA features, such as Schedules, to indicate functions that are to occur on specific dates in the year.
For information on ‘normal’ Calendars, see Configuring Calendars in the ClearSCADA Guide to Core Configuration.

  6. Configure the alarm redirection(s) that ClearSCADA is to trigger:
  • On a system-wide basis (see Configure the Properties of the Root or System Group in the ClearSCADA Guide to Core Configuration).
  • On a per Group basis.
  • On an individual item basis.

For more information, see Configure Alarm Redirections for an Item or Group.

This guide includes various examples that demonstrate how alarm redirections might be configured and used on a ClearSCADA system. You can use the examples as an aid when configuring alarm redirections on your system. For more information, see:

  • Example Configuration (a series of examples covering various aspects of alarm redirection configuration)
  • Example of Action Roster Configuration
  • Examples of Calendar Configuration.


Alarm Redirection Guide - Ascertain Which Alarm Redirections are Pending or in Progress (Introduction to Alarm Redirection)

Ascertain Which Alarm Redirections are Pending or in Progress

You can use the Alarm Redirections section of the ClearSCADA Server Status Tool to ascertain which alarm redirections are pending or in progress on your ClearSCADA system (see Alarm Redirections in the ClearSCADA Guide to the Server Status Tool).

The section shows those alarm redirections that are to be triggered automatically (see Define the Trigger Type). Manual alarm redirections are executed as soon as they are requested, and therefore do not appear in this section.


Alarm Redirection Guide - Ascertain Which Alarms have been Redirected (Introduction to Alarm Redirection)

Ascertain Which Alarms have been Redirected

Use the Events Lists to ascertain which alarms have been redirected. An entry is logged, for example, whenever:

  • An alarm is redirected
  • Alarm redirections are canceled or restarted
  • The responsibility for acknowledging a redirected alarm is assigned to a particular User, User Group, or ViewX workstation
  • Any responsibility assignment is removed.

For more information, see Alarm-Related Entries in the Events List in the ClearSCADA Guide to Alarms.


Alarm Redirection Guide - Choose a Type of Alarm Redirection

Choose a Type of Alarm Redirection

There are five types of alarm redirection. Choose the type of redirection suitable for the your system and the item that you are configuring:

  • E-mail/Voicemail Redirection
  • Pager/SMS Redirection
  • Perform Action/Invoke Method Redirection
  • Change Priority Action
  • Set Responsibility Action
  • System Command Action.

You can also configure any of the above redirections to run on a roster basis, with different redirections triggering in a different order on different days (see Action Roster), or on a calendar basis, allowing you to readily set up redirections for different types of day (non-working, public holiday, and so on) (see Alarm Redirection Calendar).


Alarm Redirection Guide - E-mail/Voicemail Redirection (Choose a Type of Alarm Redirection)

E-mail/Voicemail Redirection

An E-mail Action forwards the alarm details in an e-mail. You can use this type of redirection to automatically contact the relevant person wherever they are able to pick up their e-mail messages.

You need to configure a separate E-mail Action for each different e-mail message that you want sent. Each e-mail message can be in plain text, or HyperText Markup Language (HTML) format, depending on the format that is supported by each recipient’s e-mail client.

In order to acknowledge an alarm by replying to the e-mail, the recipient needs to have Web access and have the security permissions needed to acknowledge the alarm. If required, you can specify an Acknowledgment Keyword for inclusion in the subject line of the reply to the e-mail, in order for ClearSCADA to acknowledge the alarm.

If an Alarm View has been configured for the item that has triggered the redirection action, you can optionally include a hyperlink to that Alarm View in the e-mail. The recipient needs to have Web access to allow them to select the hyperlink and display the Alarm View in a Web browser. They can then use the Alarm View to manage the alarm and operate the system.

You can use an E-Mail Action to redirect alarms to an individual User, to every user in a User Group, or to the nominated individual on a User Roster.

You can also use an E-Mail Action for Voicemail Redirection.

For more information, see Define the E-Mail Action Details.


Alarm Redirection Guide - Voicemail Redirection (Choose a Type of Alarm Redirection)

Voicemail Redirection

You can configure ClearSCADA to send alarm redirection e-mails to Third Party telephony software. The telephony software can then process the e-mails, and relay the alarm information to engineers as automated telephone calls. Depending on the type of telephony software being used, engineers may be able to respond to the alarms by using the telephone keypad.

NOTE: To use Voicemail redirection, your system needs to have appropriate telephony hardware and software installed.

Typically, Voicemail Redirection is set up so that an E-mail Action sends an e-mail to the telephony software e-mail address when a relevant alarm occurs. The telephony software constantly monitors for incoming e-mails and so is able to process the e-mail quickly. After processing the e-mail, the telephony software telephones the recipient user, and when the call is answered, it relays the alarm details using a text-to-speech system.

When the recipient user receives the telephone call, they will be presented with the alarm information, and may be able to respond to the alarm using the telephone keypad. This is dependent on the configuration of the telephony software. Typically, a user will receive a call that describes the alarm message and then gives the user a series of options, for example, ‘Press 1 to acknowledge the alarm’. When the user responds to the alarm, they may be required to enter information such as the alarm reference number, User ID and PIN. The alarm reference number is the alarm cookie which is included in the alarm message that ClearSCADA sends to the telephony system (in the redirection e-mail). The User ID and PIN are defined in the Voicemail settings on the recipient’s User Form.

After the recipient has responded to the call, the telephony software sends a message to ClearSCADA. If the message contains an appropriate response and has the required authentication details (User ID, PIN etc.), ClearSCADA applies to the response to the alarm.

When using E-mail Actions for voicemail redirection, you need to:

  • Set the e-mail to be in a format that is supported by the telephony software. Many telephony applications have specific requirements for the format of incoming messages. For more information, please refer to the telephony software manufacturers’ documentation, and then configure your redirection e-mails to use the appropriate format.
  • Configure the recipients’ User accounts so that appropriate voicemail settings are in place. For more information:
  • see Configure a Redirection Action,
  • see Define the E-Mail Action Details,
  • see Configure a User Roster (if User Rosters are used on your system).

NOTE: You should set ClearSCADA to use an e-mail format that is supported by your telephony software (some telephony applications may only support the Plain Text format). To set the format of e-mails sent by ClearSCADA, you need to configure the E-Mail Contact settings for the recipient User accounts (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security).


Alarm Redirection Guide - Pager/SMS Redirection (Choose a Type of Alarm Redirection)

Pager/SMS Redirection

A Pager Action forwards the alarm details as a text message to a pager or mobile phone. This allows the relevant person to be notified of an alarm even when they are away from the control room or their workstation. The user to whom a pager or mobile phone message is sent needs to have the required privileges in ViewX to be able to acknowledge the alarm to which that message relates.

You need to configure a separate Pager Action for each different pager message that you want sent. You also need to ensure that the engineer’s user account has the relevant pager contact details configured. You can use a Pager Action to redirect alarms to an individual User, to every user in a User Group, or to the nominated individual from a User Roster.

For further information, see Configure a Redirection Action, see Define the Pager Action Details, and if applicable, see Configure a User Roster.


Alarm Redirection Guide - Perform Action/Invoke Method Redirection (Choose a Type of Alarm Redirection)

Perform Action/Invoke Method Redirection

A Method Action allows ClearSCADA to automatically perform an action on an item in the database. For instance, to automatically send a control to switch on a pump, or to close a breaker.

You need to configure a separate Method Action for each different action that you want to occur. You also need to specify the individual database item on which the action is to be carried out.

For further information, see Configure a Redirection Action, and see Define the Method Action Details.

NOTE: ClearSCADA can be configured to trigger a particular Method Action immediately, whenever an alarm state change occurs, regardless of the alarm priority or when the alarm changes state. If this is required, consider whether to configure a Method on the Alarm tab of a Form (see Configure a Method Action to Trigger at Every Alarm State Change in the ClearSCADA Guide to Core Configuration).


Alarm Redirection Guide - Change Priority Action (Choose a Type of Alarm Redirection)

Change Priority Action

A Change Priority Action alters the severity level of the alarm. This type of redirection is useful when operators have not acknowledged an alarm within a suitable period of time. The redirection can be used to raise the severity of the alarm and bring it to the operators’ attention.

You can also optionally use a Change Priority Action to re-evaluate every one of an alarm’s automatic redirections, canceling those that do not pass the new (changed severity) redirection criteria, and triggering those that do pass the new redirection criteria.

You need to configure a separate Change Priority Action for each change in severity level that you require.

For further information, see Configure a Redirection Action, and see Define the Change Priority Action Details.


Alarm Redirection Guide - Set Responsibility Action (Choose a Type of Alarm Redirection)

Set Responsibility Action

Any user on a ClearSCADA system has access to alarms, providing that:

  • Their User Account is configured to enable them to View Alarms.
  • They are allocated the View Alarms security permission for the database items to which they require such access.
  • If the Area of Interest feature is enabled on the system, they are allocated the relevant Area(s) of Interest to enable them to access the alarms in which they are interested.

If a user is also allocated the Acknowledge Alarms security permission for the database items that are in alarm, this permission usually enables them to acknowledge those alarms.

If required, you can use Set Responsibility Action(s) to restrict the ability to acknowledge specific alarms to a particular User, User Group, or ViewX workstation. This inhibits the Acknowledge Alarms security permission on any alarms that have been redirected using the Set Responsibility Action(s), so restricting access to the Acknowledge Alarms and Acknowledge with Comment pick actions. Any user that does not meet the responsibility criteria can see the alarms, so is aware of their existence, but cannot acknowledge them.

For further information, see Configure a Redirection Action, and see Define the Set Responsibility Action Details. For an example that demonstrates how such a redirection action might be used, see Use a Set Responsibility Action to Restrict the Ability to Acknowledge Alarms.

NOTE: ClearSCADA provides several methods—ClearAlarmResponsibility, SetAlarmResponsibleUser, and SetAlarmResponsibleWorkstation—that you can use to set or clear the restriction placed on acknowledging alarms. The methods are associated with the CAlarmObject and CGroup database tables. For more information on each method, see the database Schema.


Alarm Redirection Guide - System Command Action (Choose a Type of Alarm Redirection)

System Command Action

A System Command Action enables ClearSCADA to automatically trigger an operating system command in response to a particular alarm situation. This can be used, for instance, to trigger an external application to record the alarms on your system. The application that the command runs needs to be fully automated, so that it runs up, performs its required activity, and then automatically closes again in the briefest period of time (certainly well under a second). While such a system command-triggered application is running, any other system commands are placed on hold.

You need to configure a separate System Command Action for each different executable that ClearSCADA is to run in response to an alarm situation (or, if appropriate, use a batch file to trigger multiple executes from a single System Command Action).

For further information, see Configure a Redirection Action, and see Define the System Command Action Details.

NOTE: ClearSCADA can also execute system commands from Logic programs, and from pick action menus on Mimics. For information, see the ClearSCADA Guide to Logic, and the ClearSCADA Guide to Mimics, respectively.


Alarm Redirection Guide - Action Roster (Choose a Type of Alarm Redirection)

Action Roster

An alarm redirection Action Roster allows you to configure a series of redirection actions that can trigger in a different order on different days, depending on your systems’ requirements.

Action Rosters are particularly useful if you require redirection actions to trigger only on certain days of the week, or during holiday periods, and so on.

If you use an Action Roster, you also need to configure the redirection actions that you want to use on the roster, or ensure that they exist on your system. You can attach any type of redirection action to an Action Roster.

For further information, see Configure an Action Roster.


Alarm Redirection Guide - Alarm Redirection Calendar (Choose a Type of Alarm Redirection)

Alarm Redirection Calendar

An alarm redirection Calendar allows you to schedule sets of alarm redirections to run at different times during different days. You can specify different alarm redirection schedules for different days of the week. You can also specify different schedules for different types of day (for instance, Public holidays, or Company Shutdown periods).

Alarm redirection Calendars are particularly useful if you want to run standard schedules for most of the year and override specific days, such as Public holidays, with different alarm redirection schedules.

If you use an alarm redirection Calendar, you also need to configure the redirection actions or rosters that you want to use on the calendar, or ensure that they exist on your system. You can attach any type of redirection action to an alarm redirection Calendar.

For further information, see Configure an Alarm Redirection Calendar.

NOTE: Do not confuse Alarm Redirection Calendars with ‘normal’ Calendars. ‘Normal’ Calendars are used alongside other ClearSCADA features, such as Schedules, to indicate functions that are to occur on specific dates in the year.
For information on ‘normal’ Calendars, see Configuring Calendars in the ClearSCADA Guide to Core Configuration.


Alarm Redirection Guide - Configure a User Roster

Configure a User Roster

You can use a User Roster to redirect alarms to a different User or User Group, depending which User or User Group is deemed to be the ‘Duty User’ when an alarm redirection is triggered.

You can specify up to 16 different Users or User Groups per User Roster. You can redirect alarms to a User Roster’s ‘Duty User’ via E-Mail, Voicemail, Pager, or SMS.

WARNING

misdirected alarm notifications

If ClearSCADA is to redirect alarm messages to the users in a User Roster, those users must be able to receive messages via the same E-Mail or Pager Contact number. Ensure that each user account associated with the User Roster is configured to receive messages via the E-Mail or Pager Contact number (1, 2, 3, or 4) specified on the Redirection Action’s Form.

For information on configuring user contact details, see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

In order to redirect alarms to the ‘Duty User’ on a User Roster, you need to:

  1. Add a User Roster.
  2. Configure the User Roster Properties.
  3. Assign a User Roster to an E-Mail Action or Pager Action.
  4. Assign that E-Mail Action or Pager Action as a Redirection Action for the database item(s) or group(s) for which you want to redirect alarms (see Configure Alarm Redirections for an Item or Group).
  5. Specify the Duty User from a list of Users or User Groups on the User Roster.

For an example of how a User Roster might be used to redirect alarms, see Use a User Roster to Redirect Alarms ‘Out of Hours’ to an On-Duty Engineer.

NOTE: As an alternative to redirecting alarms on a User Roster basis, you might want to consider redirecting alarms on a Calendar basis (see Configure an Alarm Redirection Calendar).


Alarm Redirection Guide - Add a User Roster (Configure a User Roster)

Add a User Roster

To add a User Roster:

  1. Right-click on the System or Group to which you want to add the roster (this might be a separate group for storing redirection actions, or for storing user details).
    A context sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the User Roster option.
    A User Roster is added to the system. It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the User Roster (see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  6. Select another part of the interface or press the ENTER key to confirm the entry.

When you have added a User Roster, you need to Configure the User Roster Properties.


Alarm Redirection Guide - Configure the User Roster Properties (Configure a User Roster)

Configure the User Roster Properties

You need to use the User Roster Form to configure the properties of a User Roster. To configure the properties:

  1. Display the User Roster Form (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Use the Identification tab to configure the Identification properties (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  3. Use the User Methods tab to define any custom pick actions (‘methods’) for the User Roster (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  4. Use the User fields on the User Roster tab to specify the Users or User Groups to which you want to redirect alarms.

You can specify up to 16 Users or User Groups per User Roster. Alarms will be directed to whichever User or User Group is set as the ‘Duty User’ at the time that an alarm redirection is triggered (see Specify the Duty User).

Use the browse button next to each User field to display a Reference browse window. Select the required User or User Group from the window.

  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Alarm Redirection Guide - Assign a User Roster to an E-Mail Action or Pager Action (Configure a User Roster)

Assign a User Roster to an E-Mail Action or Pager Action

In order to redirect alarms on a User Roster basis, you need to assign that User Roster to an E-Mail or Pager Redirection Action. See, as applicable:

  • Configure a Redirection Action
  • Define the E-Mail Action Details
  • Define the Pager Action Details).

You then need to:

  1. Assign that E-Mail Action or Pager Action as a Redirection Action for the database item(s) or group(s) for which you want to redirect alarms (see Configure Alarm Redirections for an Item or Group).
  2. Specify the Duty User from a list of Users or User Groups on the User Roster.


Alarm Redirection Guide - Specify the Duty User (Configure a User Roster)

Specify the Duty User

You use a User Roster to redirect alarms to whichever User or User Group is deemed to be the ‘Duty User’ at that time.

You specify the Duty User by using the Set Duty User pick action that is associated with the User Roster.

Select the Set Duty User pick action to display the Set Duty User window. Use the Duty User combo box to display the list of Users and User Groups that are assigned to that User Roster.

Select the User or User Group that is presently ‘on duty’.

Use the combo box to select the User or User Group that is presently ‘on duty’.

Whenever ClearSCADA redirects an alarm using a User Roster, it sends the alarm to the User or User Group that is specified as the Duty User at that time.

NOTE: You can set the Duty User manually or automatically—to set the Duty User automatically, associate the User Roster with a Schedule (see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration).

For an example showing how the Set Duty User pick action can be used to select an on-call engineer, see Use a User Roster to Redirect Alarms ‘Out of Hours’ to an On-Duty Engineer.


Alarm Redirection Guide - Configure a Redirection Action

Configure a Redirection Action

You need to configure a separate redirection action for each different redirection that you require, for example, a separate E-mail action for each different e-mail message that needs sending.

To add and configure a redirection action:

  1. Add a Redirection Action.
  2. Display the Action Form.
  3. Configure the Properties on the Action Tab.
  4. Define the properties specific to the type of redirection that you are configuring, either:
  • Define the E-Mail Action Details
  • Define the Pager Action Details
  • Define the Method Action Details
  • Define the Change Priority Action Details
  • Define the Set Responsibility Action Details
  • Define the System Command Action Details.
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

If you are using the redirection actions in an Action Roster or an alarm redirection Calendar, you need to configure that roster (see Configure an Action Roster) or calendar (see Configure an Alarm Redirection Calendar).

You can then attach the Redirection Action, Action Roster or alarm redirection Calendar to a database item to redirect the alarms for that item (see Configure Alarm Redirections for an Item or Group).

NOTE: ClearSCADA also supports alarm suppression, whereby alarms raised on certain items are omitted from alarm displays while a specific alarm on another item is active. For more information, see Alarm Suppression in the ClearSCADA Guide to Alarms.


Alarm Redirection Guide - Add a Redirection Action (Configure a Redirection Action)

Add a Redirection Action

Before you can redirect an item’s alarms, you need to add and configure an appropriate redirection action (see Choose a Type of Alarm Redirection).

Consider whether you want to create a separate Group for storing the redirection actions that your system requires, so that you can quickly locate them should you need to change or configure further redirection actions at any time (see Add a Group in the ClearSCADA Guide to Core Configuration).

To add a redirection action:

  1. Right-click on the System or Group to which you want to add the E-mail Action (this might be a redirection actions group).
    A context sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Alarm Redirection Action option.
    A further menu is displayed.
  4. Select the appropriate option (for instance, Change Priority Action).
    A new redirection action of that type is added to the system. It is selected automatically, ready for you to enter its name.

NOTE: Two further options, Action Roster, and Calendar, are also available, allowing you to redirection alarms on a roster or calendar basis. For further information, see Action Roster and see Alarm Redirection Calendar.

  5. Enter a suitable name for the action (see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  6. Select another part of the interface or press the ENTER key to confirm the entry.

When you have added a redirection action, you need to configure it using the Action Form (see Display the Action Form).

NOTE: If a user is to manually redirect an alarm, they need to have Read access to the redirection action, action roster, or alarm redirection calendar that is used to redirect the alarm (see Select the Action to be Taken).


Alarm Redirection Guide - Display the Action Form (Configure a Redirection Action)

Display the Action Form

You need to use the Action Form to configure the properties of each redirection action. To display the Action Form:

  1. Right-click on the redirection action in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Properties option.
    The Action Form for the selected redirection action is displayed.
    Identification tab
    User Methods tab
    Action tab
    <Action Type> tab

Each Action Form has four tabs:

  • Identification—Use to define the Identification properties (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for a Redirection Action (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Action—Use to specify an Action’s basic properties and optionally associate the redirection Action with a Redirection Group. For more information, see Configure the Properties on the Action Tab.
  • <Action Type> Action—The name and fields on this tab vary, depending on the type of redirection action. Use the tab to either:
  • Define the E-Mail Action Details
  • Define the Pager Action Details
  • Define the Method Action Details
  • Define the Change Priority Action Details
  • Define the Set Responsibility Action Details
  • Define the System Command Action Details.


Alarm Redirection Guide - Define the E-Mail Action Details (Configure a Redirection Action)

Define the E-Mail Action Details

For E-mail/Voicemail Redirection use an E-Mail Action.

To successfully redirect an alarm by forwarding the details in an e-mail:

  • The servers on your system have to be configured to send e-mail messages (see E-Mail Settings in the ClearSCADA Guide to Server Administration).
  • The users to which you want to send e-mails must have:
  • Valid e-mail accounts (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security)
  • Web access if they are to acknowledge alarms via e-mail and/or access the item’s Alarm View from a hyperlink embedded in the e-mail (see Define whether a User can Access the System via ViewX, WebX or Phone in the ClearSCADA Guide to Security).
  • The security permissions needed to acknowledge the alarms (see Allocating Security Permissions in the ClearSCADA Guide to Security).
  • If e-mails are to be sent to multiple users:
  • Suitable User Groups and/or User Rosters have to exist in the database (see User Groups in the ClearSCADA Guide to Security, and see Configure a User Roster in this guide)
  • Each user has to be a member of the relevant User Group (see Associate a User with a User Group in the ClearSCADA Guide to Security).
  • Each user in a User Group and/or User Roster has to be configured to receive the e-mails via the same E-Mail Contact number (either 1, 2, 3, or 4) (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security).
  • If users are to acknowledge alarms by entering an Acknowledgment Keyword in the subject line of the reply to the e-mail, that Acknowledgment Keyword has to be specified on your system’s servers (see E-Mail Settings in the ClearSCADA Guide to Server Administration).

Use the E-Mail Action Form’s E-Mail Action tab to define:

  • Whether the e-mail should only be sent to recipients that are logged on to the ClearSCADA system
  • The recipient(s) of the e-mail
  • The contact account to which to send the e-mail
  • The importance of the e-mail
  • The e-mail’s subject
  • The e-mail’s content.

Configure each E-mail Action so that the correct engineer receives the e-mail, and the e-mail contains the relevant information. Each e-mail is customized for the individual recipient. This includes the overall format of the e-mail, which can be sent in either:

  • Plain text format (see Plain Text Format E-Mails)
  • HyperText Markup Language (HTML) format (see HTML Format E-Mails).

You specify the required e-mail format on each user’s User Account Form (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security). Other properties—such as a User Account’s Locale and Date Format—further determine how an e-mail is customized for an individual recipient.

To define an E-mail Action’s message:

  1. Display the Action Form for the E-mail Action that you want to configure.
  2. Select the E-Mail Action tab.
  3. Use the Inhibit Action combo box to define under what circumstances ClearSCADA should be inhibited from sending the e-mail:
  • Never—Send the e-mail to each of the users listed in the To field, regardless of whether those users are logged on to the system.
  • If actioned users are logged on—Send the e-mail to those users listed in the To field, who are not logged on to the system.
  • If actioned users are logged on from a WebX client—Send the e-mail to those users listed in the To field, who are not logged on to the system from a WebX client.
  • If actioned users are logged on from a ViewX client—Send the e-mail to those users listed in the To field, who are not logged on to the system from ViewX.
  4. Use the Retries field to specify the maximum number of times that ClearSCADA will attempt to re-send an e-mail if the initial attempt is unsuccessful. Use this field in conjunction with the Retry Interval field (see below).
  5. Use the Retry Interval field to specify the duration between attempts to re-send an e-mail. Specify the required interval in the OPC Time Format, for example 30S for a 30-second interval.

You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required interval.

  6. Select the browse button adjacent to the To field.
    A Reference browse window is displayed.
  7. Use the Reference browse window to locate the user name of the required recipient user.
  8. Select the required User name, User Group, or User Roster. (For further information, see User Accounts in the ClearSCADA Guide to Security; see User Groups in the ClearSCADA Guide to Security; or see Configure a User Roster.)

NOTE: Only users with an e-mail address are valid (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security).

  9. Select the OK button.
    The Reference browse window is closed and the selected user name is shown in the To field.
  10. Use the E-Mail Contact combo box to specify to which e-mail contact account the message is to be sent. (Each user can be allocated up to four e-mail addresses through which they can be contacted. Each address is allocated to a separate E-Mail Contact Account—see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security.)

    WARNING

    misdirected alarm notifications

    When configuring ClearSCADA to redirect alarms to a User Group or User Roster, ensure that each user account in that User Group or User Roster is configured to receive messages via the specified E-Mail Contact number (1, 2, 3, or 4).

    Failure to follow these instructions can result in death, serious injury, or equipment damage.
  11. Use the Importance combo box to define the priority of the e-mail. When the recipient receives the e-mail, it will display its importance—the recipient can use the importance to determine which e-mails take priority.

Choose from High, Normal, and Low.

  12. Use the Alarm View check box to specify whether the e-mail is to include a hyperlink to the relevant Alarm View (if such a view exists for the item that is in alarm).

Select the Alarm View check box to include a hyperlink. The format of the hyperlink varies, depending whether the e-mail is in Plain Text or HTML format (see Plain Text Format E-Mails, and see HTML Format E-Mails). For an example of each type of hyperlink, see Send an E-Mail in Different Formats to Different Users. In order to access the Alarm View using the hyperlink and display that view in a Web browser, the intended recipient(s) need to have Web access (see Define whether a User can Access the System via ViewX, WebX or Phone in the ClearSCADA Guide to Security).

Clear the check box if no hyperlink is required. This option might be preferable, for example, for security purposes, or if the language used on your system includes characters that are not supported by hyperlinks in Plain Text e-mails (see Plain Text Format E-Mails).

  13. Enter the title of the e-mail in the Subject field. The title can contain both plain text and trip sequences (see Trip Sequences Supported by Redirection Actions).

Regardless of the E-Mail’s format, the Subject is sent as 7-bit US-ASCII, a character set to which limitations apply (see Plain Text Format E-Mails).

  14. Select the Message field.
  15. Enter the e-mail message. This can include trip sequences (see Trip Sequences Supported by Redirection Actions).

If the e-mail is being sent to telephony software, also see E-mail/Voicemail Redirection.

If any of the recipients can receive HTML format e-mails, you can include HTML tags and character entities (such as &lt;) in the e-mail message. Any tags and character entities have to conform to the HTML 4.0 Transitional standard (see HTML Format E-Mails).

NOTE: If the Send Using Plain Text Only feature is activated on the recipient’s user account, the recipient will only be sent e-mails in plain text format (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security).

  16. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have configured the required E-Mail Actions, you can proceed to Configure Alarm Redirections for an Item or Group.


Alarm Redirection Guide - Plain Text Format E-Mails (Configure a Redirection Action)

Plain Text Format E-Mails

This section summarizes the structure and limitations that apply to an e-mail that is transmitted in Plain Text format.

Plain Text format e-mails have very little formatting - they only contain alpha-numeric characters, punctuation, tabs and spacing. While this means that they may be less visually appealing when viewed via an e-mail client, the lack of formatting makes them more appropriate for use with other types of external application.

Typically, you only need to set ClearSCADA to transmit e-mails in Plain Text format if you need alarms to be redirected in e-mails to Third-Party applications. For example, the Plain Text format is often required when redirecting alarm e-mails to Third-Party telephony software.However, if the Third-Party application supports HTML e-mail, you may prefer to use the HTML format.

To set ClearSCADA to transmit e-mails in Plain Text format, you need to configure the User account of the recipient (which may be a system user or a Third Party application). In the User configuration, you need to specify that the User can only receive e-mails in the Plain Text format (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security). When this is in place, ClearSCADA will use the Plain Text format for any e-mails that it sends to that user.

The Subject and Message of a Plain Text e-mail can contain characters from the 7-bit US-ASCII character set. This character set was developed to support the American English language and so only supports a limited range of other characters—for example, the accented characters and ligatures (joined characters) used in many European languages are not supported. HTML coding, if present, will be removed, but some tags, such as &lt; are converted to their textual equivalent (for example, >). Any characters that cannot be represented are replaced by a question mark symbol (?).

If the 7-bit US-ASCII character set proves too limiting for the language used by the users on your system, we recommend that your system is configured to send only HTML Format E-Mails. HTML format e-mails are sent as multi-part e-mails, allowing the recipient to receive the e-mail in either HTML format, or plain text format, depending on the format supported by their e-mail client. The plain text version of an HTML format e-mail is sent using the less restrictive UTF-8 character set, which supports characters that are not supported by the more limiting 7-bit US-ASCII character set. (Many of the characters in alphabets such as Bulgarian and Russian, cannot be represented by the 7-bit US-ASCII character set.)

For an example that demonstrates how an e-mail’s layout differs when sent to users that can receive e-mails in HTML or plain text format, see Send an E-Mail in Different Formats to Different Users.


Alarm Redirection Guide - HTML Format E-Mails (Configure a Redirection Action)

HTML Format E-Mails

This section summarizes the structure of an e-mail that is transmitted in HTML format.

HTML e-mails use HyperText Markup Language (HTML) tags to apply formatting to the content. For example, HTML can be used to apply different font sizes and styles to specific parts of the Message. E-mails that use the HTML format are often visually engaging and have improved readability when compared to plain text e-mails.

Typically, the improved readability of HTML e-mails means that they are used wherever possible, especially when the recipient is an operator or engineer. However, if you want alarm e-mails to be redirected to a Third Party application, you should determine whether the Third Party application supports HTML e-mail:

  • If the Third Party application supports HTML e-mail, you can use HTML format e-mails for alarm redirections to the application.
  • If the Third Party application does not support HTML e-mail, you will need to use Plain Text format e-mails (see Plain Text Format E-Mails).

You will also need to use Plain Text format e-mails if your e-mail application does not support HTML e-mails (many modern e-mail applications have HTML support as standard).

To set ClearSCADA to transmit e-mails in HTML format, you need to configure the User account of the recipient. In the User configuration, you need to specify that the User can receive e-mails in the HTML format (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security). When this is in place, ClearSCADA will use the HTML format for any e-mails that it sends to that user.

The Subject of a HyperText Markup Language (HTML) format e-mail can only contain characters from the 7-bit US-ASCII character set. This character set supports a limited range of symbols, and any characters that cannot be represented in HTML are replaced by a question mark symbol (?). For more information on this character set, see Plain Text Format E-Mails.

The Message of an HTML format e-mail is inserted between the e-mail’s <body> and </body> HTML tags automatically. It can contain characters from the UTF-8 character set or HTML tags and character entities. Any tags and character entities in the message need to conform to the HTML 4.0 Transitional standard, for example, they should:

  • Use the <p> and </p> tags to start and end each paragraph
  • Use the <br> line break tag to force content to start on a new line.

Do not include any reserved characters in the Message content—instead, specify the relevant character entities for such characters. For instance, specify the character entity &lt; instead of a left angle bracket (<). The character entity is replaced by the corresponding character when the e-mail is rendered in the e-mail client.

If an HTML format e-mail is configured to include an Alarm View hyperlink:

  • The hyperlink will only be included if an Alarm View exists for the item that is in alarm. For information on configuring Alarm Views, see Define an Alarm View in the ClearSCADA Guide to Core Configuration.
  • The hyperlink will display the full path to the Alarm View item in the database.

You can send an alarm redirection e-mail to multiple recipients, some of whom might use e-mail clients that can receive HTML format e-mails, while others might only be able to receive plain text e-mails. HTML format e-mails are sent as multi-part e-mails: the first part contains a plain text version of the e-mail; the second part contains the HTML version of the e-mail.

For an example that demonstrates how an e-mail’s layout differs when sent to users that can receive e-mails in HTML or plain text format, see Send an E-Mail in Different Formats to Different Users.

Further Information

Supported character entities: see http://www.w3.org/TR/html4/sgml/entities.html

Supported HTML tags: see http://www.w3.org/TR/1998/REC-html40-19980424/


Alarm Redirection Guide - Define the Pager Action Details (Configure a Redirection Action)

Define the Pager Action Details

You can redirect alarms so that they are sent as text messages to the pager or mobile phone of an engineer, or group of engineers (see Pager/SMS Redirection). To do this you use a Pager Action.

To successfully redirect an alarm in a text message:

  • The intended recipient(s) must have:
  • Valid Pager Accounts (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security).
  • The security permissions required to acknowledge the alarm (see Allocating Security Permissions in the ClearSCADA Guide to Security).

To send the same text message to multiple users:

  • Suitable User Groups and/or User Rosters have to exist in the database (see User Groups in the ClearSCADA Guide to Security, and see Configure a User Roster in this guide)
  • Each user has to be a member of the relevant User Group (see Associate a User with a User Group in the ClearSCADA Guide to Security).
  • Each user in a User Group and/or User Roster has to be configured to receive the e-mails via the same Pager Contact number (either 1, 2, 3, or 4) (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security).

You can use the Pager Action Form’s Pager Action tab to define:

  • Whether the pager message should only be sent to recipients that are logged onto the ClearSCADA system
  • The recipient(s) of the message
  • The contact account to which to send the message
  • The message content
  • Any audible indication that a message has been delivered.

Configure each Pager Action so that the correct engineer receives the pager message, and the message contains the relevant information.

To define a Pager Action’s details:

  1. Display the Action Form for the Pager Action that you want to configure.
  2. Select the Pager Action tab.
  3. Use the Inhibit Action combo box to define under what circumstances ClearSCADA should be inhibited from sending the pager message:
  • Never—Send the message to each of the users listed in the To field, regardless of whether those users are logged on to the system.
  • If actioned users are logged on—Send the message to those users listed in the To field, who are not logged on to the system.
  • If actioned users are logged on from a WebX client—Send the message to those users listed in the To field, who are not logged on to the system from a WebX client.
  • If actioned users are logged on from a ViewX client—Send the message to those users listed in the To field, who are not logged on to the system from ViewX.
  4. Select the browse button adjacent to the To field.
    A Reference browse window is displayed.
  5. Use the Reference browse window to locate the user name of the required recipient user.
  6. Select the required User name, User Group, or User Roster. (For further information, see User Accounts in the ClearSCADA Guide to Security; see User Groups in the ClearSCADA Guide to Security; or see Configure a User Roster.)

NOTE: Only users for which Pager Account details have been configured are valid (see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security).

  7. Select the OK button.
    The Reference browse window is closed and the selected user name is shown in the To field.
  8. Use the Pager Contact combo box to specify to which pager contact account the message is to be sent. (Each user can be allocated up to four pager IDs and services through which they can be contacted. Each ID and service is allocated to a separate Pager Contact Account—see Creating a User Account in the ClearSCADA Guide to Security).

    WARNING

    misdirected alarm notifications

    When configuring ClearSCADA to redirect alarms to a User Group or User Roster, ensure that each user account in that User Group or User Roster is configured to receive messages via the specified Pager Contact number (1, 2, 3, or 4).

    Failure to follow these instructions can result in death, serious injury, or equipment damage.
  9. Select the Pager Message field.
  10. Enter the pager message. This can include both plain text and trip characters (see Trip Sequences Supported by Redirection Actions).

The maximum message length is defined using a field on the Form for the Pager Service used by the recipient of the message. Should a pager message exceed this limit, the message is either de-vowelled or truncated, as defined on that Form (see the ClearSCADA Guide to the Pager Driver).

  11. For Multitone Pager Services, enter the Beep Code for the required audible signal that indicates to the recipient that a message has arrived.

Refer to the documentation supplied with your Pager system for details of the Beep Codes that apply.

  12. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have configured the required Pager Actions, you can proceed to Configure Alarm Redirections for an Item or Group.

If your ClearSCADA system is running the Pager driver and is configured to send and receive SMS messages, ClearSCADA can be configured to enable users to trigger actions remotely via SMS. So, for instance, on receipt of an SMS alarm message generated using a Pager redirection action, a user might opt to trigger an action remotely to correct the cause of the alarm. For more information, see the ClearSCADA Guide to the Pager Driver.


Alarm Redirection Guide - Define the Method Action Details (Configure a Redirection Action)

Define the Method Action Details

You can use the Method Action Form’s Method Action tab to define:

  • The database item on which the server is to act
  • The action that the server undertakes on that item.

(For more information, see Perform Action/Invoke Method Redirection.)

To define the Method Action’s properties:

  1. Display the Action Form for the Method Action that you want to configure.
  2. Select the Method Action tab.
  3. Select the browse button next to the Method Object field.
    A Reference browse window is displayed.
  4. Use the Reference browse window to locate the name of the database item for which ClearSCADA should trigger an action when the alarm is redirected.
  5. Select the required database item.
  6. Select the OK button.
    The Reference browse window is closed and the selected item name is shown in the Method Object field.

NOTE: You can display the Form for the item by selecting the Go To hyperlink that is adjacent to the browse button.

NOTE: ClearSCADA can be configured to trigger a particular Method Action immediately, whenever an alarm state change occurs, regardless of the alarm priority or when the alarm changes state. If this is required, consider whether to configure a Method on the Alarm tab of a Form (see Configure a Method Action to Trigger at Every Alarm State Change in the ClearSCADA Guide to Core Configuration).

  7. Select the browse button next to the Method field.
    The Edit Method window is displayed.
  8. Use the Edit Method window to select the method (action) that ClearSCADA is to trigger on the item and, if applicable, specify the values of any arguments that further define the action that is to be taken, or the value(s) that ClearSCADA is to use for the action. If a method includes String arguments, you can optionally include trip sequences in such arguments, alongside or instead of plain text. As with any string, you need to enclose the whole string, including any trip sequences, in single quotation marks. (For an example that demonstrates this, see Include a Trip Sequence in a Method Action’s Arguments.)

Depending on the method, you may also need to specify a particular aggregate and/or the type of alarm with which the method is associated—for information on using the Edit Method window, see Specify a Method in the ClearSCADA Guide to Core Configuration.

  9. Once you have specified the required method and the values of any arguments, select the OK button to confirm the settings and close the Edit Method window.
  10. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have configured the required Method Actions, you can proceed to Configure Alarm Redirections for an Item or Group.


Alarm Redirection Guide - Define the Change Priority Action Details (Configure a Redirection Action)

Define the Change Priority Action Details

You can use the Change Priority Action Form’s Change Priority Action tab to alter the severity level of the alarm.

To define the new priority of the alarm:

  1. Display the Action Form for the Change Priority Action that you want to configure.
  2. Select the Change Priority Action tab.
  3. Use the Type combo box to define whether you want to set the alarm to a particular priority, or whether you want to increase or decrease the priority level.

Choose from:

  • Set—Select this option if you want to choose a particular priority for the alarm. Use this setting in conjunction with the New Priority field to specify the alarm priority (now go to Step 4).
  • Increase—Select this option if you want to raise the alarm priority by a particular number of levels. Use this setting in conjunction with the Levels field to specify by what amount you want to raise the priority (now go to Step 5).
  • Decrease—Select this option if you want to lower the alarm priority by a particular number of levels. Use this setting in conjunction with the Levels field to specify by what amount you want to lower the priority (now go to Step 5).
  4. If you have chosen ‘Set’ from the Type field, use the New Priority combo box to select the required alarm priority.

A set of priority levels is provided for each ClearSCADA system (see Defining Severities in the ClearSCADA Guide to Core Configuration). The default priority levels are shown above—these can be overridden with custom priority levels (see Alarm and Event Severities in the ClearSCADA Guide to Server Administration). Choose the appropriate priority level from the list available on your system.

Now go to Step 6.

NOTE: Choose the ‘None’ option if you want the redirection action to clear the alarm.

  5. If you have chosen to Increase or Decrease the alarm level using the Type field, use the Levels field to specify by how many priority levels the alarm priority is to change when it is redirected.

Example:

An alarm is priority 3. If the alarm has not been acknowledged after 10 minutes, it is redirected, and its priority is increased by 2, resulting in a priority 1 alarm.

  6. You can optionally use a Change Priority Action to re-evaluate each of the redirection actions that apply to, and are configured to trigger automatically for, a particular alarm.

Select the Reevaluate automatic redirections on alarm check box if ClearSCADA is to re-evaluate each of the redirections that are set to trigger automatically for the alarm, whenever this Change Priority Action is triggered. Following the re-evaluation, ClearSCADA will trigger each of the automatic redirections that now pass the redirection criteria, and cancel each of the automatic redirections that do not pass the redirection criteria (taking the redirection settings on the relevant database item’s Redirection tab into account). Any redirection actions that were triggered before the alarm changed severity, will be re-triggered if they pass the redirection criteria.

Example:

A Change Priority Action raises the severity of an alarm from Medium to High.

As the action’s Reevaluate automatic redirections on alarm check box is selected, ClearSCADA re-evaluates each of the automatic redirections for the alarm. (The redirection actions are listed on the relevant database item’s Redirection tab.)

Any redirections to which the new severity applies, and which meet the other redirection criteria, are triggered after their specified Delay times.

Any redirections to which the new severity or other redirection criteria do not apply are canceled.

(Any redirection actions that have a Trigger Type of Manual are ignored during the re-evaluation process—users can still trigger these manually if the redirection criteria still applies to those actions, and the users have the required permissions to trigger such redirection actions.)

For another example that further demonstrates the re-evaluate process, see Use a Change Priority Action to Re-evaluate other Redirection Actions.

Clear the Reevaluate automatic redirections on alarm check box if ClearSCADA is not to attempt to perform any other redirections as a result of this Change Priority Action being triggered.

  7. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have configured the required Change Priority Actions, you can proceed to Configure Alarm Redirections for an Item or Group.


Alarm Redirection Guide - Define the Set Responsibility Action Details (Configure a Redirection Action)

Define the Set Responsibility Action Details

Use the Set Responsibility Action Form’s Set Responsibility Action tab to specify whether the ability to acknowledge alarms is to be restricted once the alarms have been redirected using this redirection action:

  1. Display the Action Form for the Set Responsibility Action that you want to configure.
  2. Select the Set Responsibility Action tab.
  3. Use the Type combo box to define whether the ability to acknowledge redirected alarms is to be restricted.

Choose from:

  • Clear Responsibility—The ability to acknowledge alarms is not to be restricted to a particular User, User Group, or ViewX workstation. Any user that has access to the alarms and is allocated the Acknowledge Alarms security permission for the item(s) that are in alarm can acknowledge the redirected alarms.

This option can be used to clear an existing restriction on acknowledging alarms, so that any user with the relevant alarm access and security permissions can acknowledge the alarms.

Now go to step 6.

  • Set Responsible User—The ability to acknowledge the redirected alarms is restricted to a particular User or User Group. Go to step 4.
  • Set Responsible Workstation—The ability to acknowledge the redirected alarms is restricted to a particular ViewX workstation.

When this type of redirection is in force, the alarm(s) to which the redirection action applies cannot be acknowledged from a WebX client, nor a ViewX client that is running an older version of ClearSCADA (one that does not support Set Responsibility functionality).

Now go to step 5.

  4. If you have chosen ‘Set Responsible User’ from the Type field, select the browse button next to the User field to display a Reference browse window.
    A list of Users and/or User Groups is displayed.

Select the required User or User Group from the list. Ensure that the specified User(s) have access to any redirected alarms and are allocated the Acknowledge Alarms security permission for the item(s) that might generate an alarm.

ATTENTION: If the Area of Interest feature is enabled on your system, ensure that the specified User(s) are allocated the Area of Interest that allows them to access any redirected alarms (see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration).

For information on Users, see User Accounts in the ClearSCADA Guide to Security; for information on User Groups, see User Groups in the ClearSCADA Guide to Security.

Now go to step 6.

  5. If you have chosen ‘Set Responsible Workstation’ from the Type field, use the Workstation field to specify the name of the ViewX workstation on which alarms can be acknowledged. The ViewX workstation has to be running a suitable version of ClearSCADA (one that supports Set Responsibility functionality).

If required, you can specify the names of multiple workstations, although only one will be assigned alarm responsibility. Enter the workstation names as a comma-separated list, in the order in which you would like ClearSCADA to check the workstations. Each ViewX workstation has to be running a suitable version of ClearSCADA (one that supports Set Responsibility functionality). ClearSCADA will assign responsibility to the first workstation that is found to be connected to the system.

To ascertain the name that is assigned to a particular ViewX client, look at the Workstation Name that is assigned to that client on the Client Configuration window (see Define the Workstation Name for the ViewX Client in the ClearSCADA Guide to Client Administration). The name is machine-specific, therefore alarms can be acknowledged from any head on a multi-headed workstation.

  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have configured the required Set Responsibility Actions, you can proceed to Configure Alarm Redirections for an Item or Group.

If the ability to acknowledge alarms is restricted to a particular User, User Group, or Workstation, other users who can view the redirected alarms will not have access to the Acknowledge or Acknowledge with Comment actions for those alarms.

To ascertain which User, User Group, or Workstation has responsibility for acknowledging the alarms via the Acknowledge or Acknowledge with Comment actions, either:

  • View the entries in the Events List. (ClearSCADA logs separate entries for each alarm, alarm redirection, and the name of any user, user group, or workstation that is assigned responsibility for acknowledging a redirected alarm.)

or:

  • Use the View Status action to view the Status display of the item that is in alarm.

For an example that shows the type of information that is included in the above displays and demonstrates how this type of redirection action might be used, see Use a Set Responsibility Action to Restrict the Ability to Acknowledge Alarms.

Your system may be configured to use a different background color to indicate whether you can acknowledge an alarm. If so, any unacknowledged alarms (including redirected alarms) that you can acknowledge will have a different background color on alarm displays. For more information, see The Background Color used on Alarms Lists and the Alarm Banner in the ClearSCADA Guide to Alarms.

NOTE: ClearSCADA provides several methods—ClearAlarmResponsibility, SetAlarmResponsibleUser, and SetAlarmResponsibleWorkstation—that you can use to set or clear the restriction placed on acknowledging alarms. The methods are associated with the CAlarmObject and CGroup database tables. For more information on each method, see the database Schema.


Alarm Redirection Guide - Define the System Command Action Details (Configure a Redirection Action)

Define the System Command Action Details

Use the System Command Action Form’s System Command Action tab to specify the Windows® system command that ClearSCADA is to trigger.

To specify the required system command:

  1. Display the Action Form for the System Command Action that you want to configure.
  2. Select the System Command Action tab.
  3. Use the Command field to enter the required command line. Use the same syntax as a command line in Windows. For example, to run a particular application automatically, enter a command of the form:
<application>.exe

(where <application> is the name of the external application that is to run).

Be aware that any applications that are triggered by the System Command Action should require no user intervention and should run for only the briefest amount of time. While a system command-triggered application is running, any other system commands are placed on hold until that application closes.

If appropriate, consider using a batch file to trigger multiple executes from a single System Command Action. For the Action to trigger a batch file, specify the name of the batch file in the Command field.

  4. If supported by the application(s) that the system command is to trigger, you can optionally append the command line with a text string that provides further details about the alarm. The string can contain both plain text and trip characters (see Trip Sequences Supported by Redirection Actions).

To enter such a string, leave at least one character space after the system command, then specify the required text string in the format expected by the application that the command line is to trigger. For example, use single or double quotation marks to specify any strings, if this is the format that the application requires.

  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have configured the required System Command Actions, you can proceed to Configure Alarm Redirections for an Item or Group.


Alarm Redirection Guide - Configure the Properties on the Action Tab

Configure the Properties on the Action Tab

The configuration Form for each redirection Action, Action Roster, and alarm redirection Calendar has an Action tab that you use to specify the basic action properties.

To specify the properties:

  1. Display the configuration Form for the Action, Action Roster, or alarm redirection Calendar that you want to configure. For more information, see the relevant section below:
  • Display the Action Form
  • Display and Configure Properties on the Action Roster Form
  • Display and Configure Properties on the Calendar Form.
  2. Select the Action tab.
  3. Use the In Service check box to specify whether the Redirection Action, Action Roster, or alarm redirection Calendar is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  4. Use the Severity combo box to choose the level of importance of any events that ClearSCADA generates in response to the Redirection Action, Roster, or Calendar’s activity (see Defining Severities in the ClearSCADA Guide to Core Configuration).

With an E-Mail or Pager redirection Action, for example, ClearSCADA generates events if attempts to send an e-mail or pager message are unsuccessful.

Use the Severity combo box to specify the priority level, and so the importance, of such events.

  5. Redirection Actions can be configured to trigger manually or automatically (see Define the Trigger Type). Use the Manual Redirection Description field to enter a concise, but clear description as to the redirection that occurs should a user trigger this redirection Action, Roster, or Calendar manually.

For those database items for which the redirection Action, Roster, or Calendar is set to trigger manually, the description that you enter in this field appears in the list of manual redirection destinations for that item. The list is displayed when a user right-clicks on the database entry in the Alarms List or Alarm Banner.

(If no Manual Redirection Description is configured for an action, Roster, or Calendar that is set to trigger manually, the entry in the manual redirection destinations list will default to Redirect to <Action Name>, where <Action Name> is the full name of the redirection Action, Roster, or Calendar.)

For an example that demonstrates how to configure alarms so that they can be redirected on a manual basis, see Use Alarm Redirection to Enable Operators to Manually Redirect Alarms.

  6. For those database items for which the redirection Action, Roster, or Calendar is set to trigger manually, use the Manual Redirections Require Comment check box to specify whether operators can enter a comment when manually redirecting an alarm. You might want to use this feature, for instance, to enable operators to enter comments that inform others as to why they manually redirect any alarms.

Select the Manual Redirections Require Comment check box if operators are to be able to enter a comment. When an operator opts to manually redirect an alarm, Roster, or Calendar, a Redirection Comment window is displayed. The operator can use the window to enter a plain text comment relating to the manual redirection, or leave the field blank if no comment is required. (On systems on which a ‘standard’ set of Alarm Acknowledgment and Manual Redirection Comments are configured, the operator can select one of the ‘standard’ comments, or enter their own comment.) When the window’s OK button is selected, ClearSCADA redirects the alarm. The comment is logged in the Event Journal, as part of the event message regarding the manual redirection. For an example that demonstrates the comment feature, see Allow an Operator to Enter a Comment when Manually Redirecting an Alarm. To optionally include the comment with an E-Mail, Pager, or System Command Action’s redirection details, include the %K trip character in the relevant field on that Action Form’s <Action Type> tab. (For more information on trip characters, see Trip Sequences Supported by Redirection Actions.)

Clear the Manual Redirections Require Comment check box if operators are not required to enter a comment when manually redirecting an alarm.

NOTE: To allow users to enter comments when manually triggering alarm redirections on a per roster, or per calendar basis, select the Manual Redirections Require Comment check box on the Action Roster, or Calendar Form respectively.

  7. Use the Deselect Alarm After Manual Redirection Action check box to specify whether the alarm remains selected. This setting only applies to those database items for which the redirection Action, Roster, or Calendar is set to trigger manually.

To trigger a redirection Action, Roster or Calendar manually, you need to access the context sensitive menu for the alarm associated with the redirection. This means that in the Alarm Banner or Alarms List, the alarm is selected.

If you select the Deselect Alarm After Manual Redirection Action check box, the alarm becomes deselected as soon as the redirection has been manually triggered.

If you clear the Deselect Alarm After Manual Redirection Action check box, the alarm remains selected as soon as the redirection has been manually triggered.

  8. Optionally Associate a Redirection Action, Roster, or Calendar with a Redirection Group.

Further Information

For information on configuring the other properties on a redirection Action, Roster, or Calendar’s Form, see the relevant section below:

  • Configure a Redirection Action
  • Configure an Action Roster
  • Configure an Alarm Redirection Calendar.

Configure a ‘standard’ set of Alarm Acknowledgment and Manual Redirection Comments: see Define Standard Alarm Acknowledgment Comments in the ClearSCADA Guide to Server Administration.


Alarm Redirection Guide - Associate a Redirection Action, Roster, or Calendar with a Redirection Group (Configure the Properties on the Action Tab)

Associate a Redirection Action, Roster, or Calendar with a Redirection Group

You can optionally associate each redirection Action, Roster, or Calendar with a Redirection Group. This is a logical grouping that you can use to separate your redirection Actions, depending on your system requirements. The grouping is used for canceling and restarting alarm redirections in specific circumstances (see CancelRedirections and RestartRedirections Methods).

Should any alarm redirections need to be canceled, the CancelRedirections method can be used to selectively cancel only those redirection Actions, Rosters, and/or Calendars that are assigned to a particular Redirection Group (and for which a sufficient Delay is configured). Once the cancellation no longer needs to apply, the RestartRedirections method can be used to selectively restart only those canceled alarm redirections that are associated with the relevant Redirection Group(s).

Use the Redirection Group field on the Action tab of each Action, Action Roster, or alarm redirection Calendar Form to specify the logical group with which that particular redirection Action, Roster, or Calendar is associated.

The Redirection Group field is case sensitive and can comprise up to 128 characters, including character spaces. You can include any alphanumeric characters except for the following:

*, ?, #, [ ]

For an example that demonstrates the use of the CancelRedirections and RestartRedirections methods in conjunction with the Redirection Group property, see Cancel the Redirection Actions that are Associated with a Particular Redirection Group.

For information on the other fields on the Action tab, see Configure the Properties on the Action Tab.


Alarm Redirection Guide - Trip Sequences Supported by Redirection Actions

Trip Sequences Supported by Redirection Actions

Trip sequences comprise special characters and references to alarm or database attributes that are replaced by specific values when an e-mail or pager message is sent. To enter a trip sequence, you enter a % immediately before and after the trip code. For example, type %OAlarmDesc% for an e-mail to display a description of the alarm (the alarm state). (For a message to display the % percentage character, enter %%.)

If you are using an E-mail Action to send an e-mail to telephony software, also see E-mail/Voicemail Redirection.

If the Trip sequence syntax is incorrect, or references an item that cannot be found, ClearSCADA replaces the sequence with a diagnostic message when it redirects the alarm. For further information, see Troubleshooting Redirection Action Trip Sequences.

E-mail, Pager, and System Command Actions, and Method Actions that include string arguments, support a combination of the following trip sequences:

Trip
Code

Description

Example

%A

Use this trip code to include any relevant alarm attribute information in an e-mail or pager message, or append the information to a System Command Action’s command line.

Use the syntax %A<attribute>%, where <attribute> can be any one of the alarm attributes listed in the next table.

ClearSCADA formats any date and time trip sequences using the recipients date format.

(see separate table)

%K

Only applies to manually redirected Actions (see Configure the Properties on the Action Tab), Action Rosters, and alarm redirection Calendars, where such manual redirections require a comment.

Use the %K trip character to include the manual redirection comment in the redirection message. (As this is a trip character, as opposed to a trip sequence, you only enter % before the code—do not enter another % after the code.)

The %K content will be blank if no comment is entered by the user that manually redirects the alarm.

For an example that demonstrates using this trip character in an alarm redirection e-mail message, see Allow an Operator to Enter a Comment when Manually Redirecting an Alarm.

Displays the redirection comment that was entered when the alarm was manually redirected. For example,

Known event - maintenance engineer notified

%N

The name of the computer that was main when ClearSCADA redirected the alarm.

(As this is a trip character, as opposed to a trip sequence, you only enter % before the code—do not enter another % after the code.)

WEST17

%O

Any field from the source object’s table.

For fields that are in an object’s main table, use the syntax %O<field>%, where <field> is the name of the field.

For fields that are in an aggregate table off an object’s main table, use the syntax %O<aggregate>.<field>%, where <aggregate> is the name of the aggregate field and <field> is the name of the field in that aggregate.

Use the syntax %O<reference>.<field>% to display the value of a field on an item that is associated with the item that is raising the alarm. For instance, you can display the name of the outstation that is associated with the point for which ClearSCADA is redirecting an alarm. There is no limit to the number of references that you can follow in this way.

You can display a list of the available fields and references by using the OPC Data bar or the database Schema.

%OAlarmDesc%

displays the alarm description,
for example,
Acknowledged Uncleared

%OOutstationId.Name%

displays the name of the outstation associated with the point for which ClearSCADA is redirecting an alarm

%r

(Note that the ‘r’ trip character is lower case, where as many other trip characters are upper case.)

Any field from the alarm redirection action itself.

For fields that are in a redirection action’s table, use the syntax %r<field>%, where <field> is the name of the field.

Use the syntax %r<reference>.<field>% to display the value of a field on an item that is associated with the redirection action. For instance, you can display the recipient of an e-mail redirection action. There is no limit to the number of references that you can follow in this way.

You can display a list of the available fields and references by using the OPC Data bar or the database Schema.

%rName%

displays the name of the redirection action,
for example,
E-Mail Alarm Details

%rUserId.Name%

displays the name of the recipient of the redirected alarm

%U

Any field from the CDBUser table for the recipient. This trip character is typically used for personalizing a message.

For fields that are in an object’s main table, use the syntax %U<field>%, where <field> is the name of the field.

For fields that are in an aggregate table off an object’s main table, use the syntax %U<aggregate>.<field>%, where <aggregate> is the name of the aggregate field and <field> is the name of the field in that aggregate.

Use the syntax %U<reference>.<field>% to display the value of a field on an item that is associated with the recipient of the redirected alarm. For instance, you can display the name of the recipient’s Help View, listing instructions on how to deal with any redirected alarms. There is no limit to the number of references that you can follow in this way.

You can display a list of the available fields and references by using the OPC Data bar or the database Schema.

%UName%

displays the name of the user,
for example,
John

%UHelpViewId.Name%

displays the name of the Help View that is associated with the recipient of the redirected alarm

The trip sequences that you can use with the %A alarm attribute trip code are:
Syntax | Description | Example
%ASeverity% | The severity of the alarm (supersedes %E). | Low
%ASource% | The source of the alarm (supersedes %S). | Western Site. Point AIP3
%AMessage% | The alarm message (supersedes %M). | State changed to High, value is 80.00
%ACookie% | An alarm cookie (identifier) that uniquely identifies the alarm. This is used to acknowledge an alarm by voice interface, using telephony software (supersedes %I). | 8637
%ACategory% | The alarm category (supersedes %C). | Point State
%AAckComment% | Any comment entered when the alarm was acknowledged. | Known Event - Engineer Called
%AAckUsername% | The user that acknowledged the alarm. | RJohnson
%AAckDate% | The date that the alarm was acknowledged. | 01/Apr/2005
%AAckTime% | The time that the alarm was acknowledged. | 11:22:25.888
%AAckDateTime% | The date and time that the alarm was acknowledged. | 01/Apr/2005 11:22:25.888
%AResponse% | Any response entered in relation to the alarm. | Severe conditions - Checking Alarm Cause
%AResponseUsername% | The user that entered the response. | ARichards
%AResponseDate% | The date that the response was entered. | 01/Apr/2005
%AResponseTime% | The time that the response was entered. | 11:56:07.882
%AResponseDateTime% | The date and time that the response was entered. | 01/Apr/2005 11:56:07.882
%ACondName% | The ‘condition’ with which the alarm is associated. For example, the state of a particular type of point. For further information, see Understanding Alarm Conditions and Subconditions. | DNP3AnalogInState1 (indicating that the alarm is associated with the state of a DNP3 analog input point)
%ACondActiveDate% | The date on which the alarm condition became active. | 01/Apr/2005
%ACondActiveTime% | The time at which the alarm condition became active. | 11:22:09.755
%ACondActiveDateTime% | The time and date at which the alarm condition became active. | 01/Apr/2005 11:22:09.755
%ASubCondName% | The name of the active ‘subcondition’ with which the alarm is associated. For example, a particular point state. For further information, see Understanding Alarm Conditions and Subconditions. | HighHigh
%ASubCondActiveDate% | The date on which the alarm subcondition became active (supersedes %D). | 01/Apr/2005
%ASubCondActiveTime% | The time at which the alarm subcondition became active (supersedes %T). | 11:22:09.755
%ASubCondActiveDateTime% | The time and date at which the alarm subcondition became active. | 01/Apr/2005 11:22:09.755
%ASubCondDef% | The definition of the alarm subcondition (the status change that triggered the alarm). | Current State = 1
%ASubCondDesc% | The description of the alarm subcondition. | Pump Running
%AInactiveDate% | The date that the alarm cleared. | 01/Apr/2005
%AInactiveTime% | The time at which the alarm cleared. | 11:22:01.473
%AInactiveDateTime% | The date and time at which the alarm cleared. | 01/Apr/2005 11:22:01.473
%AReceiptDate% | The date that the server received the alarm notification. | 01/Apr/2005
%AReceiptTime% | The time that the server received the alarm notification. | 11:22:09.755
%AReceiptDateTime% | The date and time that the server received the alarm notification. | 01/Apr/2005 11:22:09.755

Any date and time trip sequences are formatted using the recipient’s Date Format (specified on the recipient’s User Form—see Creating a User Account in the ClearSCADA Guide to Security).

Examples:

Alarm at %ASource%
results in a message in the form
Alarm at Northern Site.Pump3

The alarm “%AMessage%” occurred on %ASubCondActiveDate% at %ASubCondActiveTime%
results in a message where the trip characters are replaced by the actual alarm message text, followed by the date and time of the alarm, in the form
The alarm “Communications State - Disconnected” occurred on 12-FEB-2003 at 13:48:15

Alarm message for %UName%...
results in a message of the form
Alarm message for John...

Alarm associated with %ASource%, on %OOutstationId.Name%
results in a message that includes the name of the outstation on which a point is located, in the form
Alarm associated with Western Site. Pump 5, on NW3

Alarm raised on %OName% (Location: %OOutstationId.SetId.Name%)
results in a message of the form
Alarm raised on Pump 7 (Location: Central Region)
(where ‘Central Region’ is the set with which the point ‘Pump 7’ is associated)

Alarm raised on %OName%. (If an alarm situation cannot be resolved, see the %UUserGroup1Id.HelpViewId.Name% Mimic for a list of engineer telephone and pager numbers.)
results in a message of the form
Alarm raised on Pump 7. (If an alarm situation cannot be resolved, see the Contact Numbers Mimic for a list of engineer telephone and pager numbers.)
(where ‘Contact Numbers’ is the Help View for the User Group associated with the recipient of the alarm message.)

These superseded trip codes are retained for backwards compatibility with earlier ClearSCADA systems. To enter one of these superseded trip codes, you entered a % immediately in front of the trip character. Do not use these trip codes for new Alarm Redirections—use the appropriate %A<attribute>% or %O<field>% syntax instead.

Trip
Code

Description

Example

%C

The category of the alarm.

(Now superseded by %ACategory% (see above).)

Point State

%D

The date of the alarm.

(Now superseded by %ASubCondActiveDate% (see above).)

18-MAR-2003

%E

A description of the severity of the alarm.

(Now superseded by %ASeverity% (see above).)

High

%I

An alarm cookie (identifier) that uniquely identifies the alarm. This is used to acknowledge an alarm by voice interface, using telephony software.

(Now superseded by %ACookie% (see above).)

8637

%M

The alarm message.

(Now superseded by %AMessage% (see above).)

Communications State - Disconnected

%R

A description of the item that is in alarm.

This trip character can only be used if:

  • A custom description field is configured for the database items on your system

and:

  • That custom field is configured as the first Search Key field in the Metadata window (see Extra Database Fields in the ClearSCADA Guide to Server Administration).

(Now superseded by %O<field>% (see above).)

(Do not confuse %R with %r, which has different functionality (see above).)

Change in River Level

%S

The source of the alarm.

(Now superseded by %ASource% (see above).)

Western Site. Outstation F3

%T

The time of the alarm.

(Now superseded by %ASubCondActiveTime% (see above).)

10:32:15

%V

The value of the point that is in alarm (this is only available for alarms on points, and includes any point formatting and units).

(Now superseded by %OCurrentValueFormatted% (see above).)

95.6


Alarm Redirection Guide - Understanding Alarm Conditions and Subconditions (Trip Sequences Supported by Redirection Actions)

Understanding Alarm Conditions and Subconditions

For database items that can raise alarms, every situation or ‘condition’ that can raise an alarm (such as a change in point state, or an outstation losing communications) is associated with an Alarm Condition. An alarm condition identifies the particular abnormal occurrence that has triggered the alarm (for instance, a ‘Point State’ condition indicates that a change in point state has caused an alarm to be raised). An alarm condition becomes active when the item enters a state for which an Alarm Severity is configured. An alarm condition becomes inactive once the item is no longer in a state for which an Alarm Severity is configured and the alarm that has cleared as a result of this change has been acknowledged. The ‘normal’ state of an item is deemed as inactive with respect to alarm conditions and alarm subconditions.

Example:

A point has states High, Normal, and Low, where High and Low are configured as alarm states. Whenever the point value rises above the High limit, the point changes to the High state and the point's 'Point State' alarm condition becomes active. Whenever the point value falls below the High limit, the point changes to the Normal state and the alarm condition becomes inactive.

Similarly, if the point value falls below the Low limit, the point changes to the Low state and the point's 'Point State' alarm condition becomes active. Whenever the point value rises above the Low limit, the point changes to the Normal state and the alarm condition becomes inactive.

You can use one of the %ACond...% trip sequences to include details about the alarm’s alarm condition in an E-Mail or Pager action. For example, you might use the %ACondActiveTime% trip sequence to indicate the time that the alarm condition occurred.

Each alarm condition comprises at least one Alarm Subcondition. A subcondition is a particular class of alarm condition. The active subcondition provides an indication of the cause or ‘state’ of the alarm (such as an analog point’s value exceeding the High limit). Some alarm conditions comprise multiple alarm subconditions, with each subcondition representing one of the alarm’s possible states. An alarm condition can only have one active subcondition at any time.

Example:

A point has states High High, High, and Normal, where High High and High are configured as alarm states. The point’s ‘Point State’ alarm condition is active whenever the point value is above the High limit, and inactive when below the High limit. Additionally, the High and High High states each have their own alarm subcondition (there is no active subcondition when the point is in the Normal state).

So, whenever the point is in the High state, both the ‘Point State’ alarm condition and the High state’s alarm subcondition are active. If the point value then rises above the High High limit, the alarm condition remains active. Additionally, the active subcondition changes from the High state’s subcondition to the High High state’s subcondition.

You can use one of the %ASubCond...% trip sequences to include details about an alarm’s active subcondition. In the above example, for instance, you might use %ASubCondActiveTime% trip sequence to indicate when the point went into the presently active alarm state (the High High state).

NOTE: When the Multiple Point State Alarms feature is being used (see Multiple Point State Alarms in the ClearSCADA Guide to Core Point Configuration), each point will have several 'Point State' alarm conditions, each with the same subconditions. The mapping between the point's states and the alarm conditions is then configurable on a point-by-point basis, so several conditions may be active at any given time.


Alarm Redirection Guide - Troubleshooting Redirection Action Trip Sequences (Trip Sequences Supported by Redirection Actions)

Troubleshooting Redirection Action Trip Sequences

Should ClearSCADA be unable to evaluate any trip sequence that is specified for an E-Mail, Method, Pager, or System Command redirection, it will replace that sequence with a diagnostic message.

Use the table below to determine the cause of any unevaluated trip sequences.

Diagnostic Message

Description

#ERROR NO TERMINATING%#

The trip sequence does not contain a terminating % character—see Trip Sequences Supported by Redirection Actions for the syntax that is required.

To display a % character in a redirection message, specify %%.

#NO REFERENCE#

The referenced field is null (the field does not reference another item and is blank on the associated configuration Form).

For example, the trip sequence %OHelpViewId.Name% for an item that does not have a Help View configured.

#GET REFERENCE FAILED#

ClearSCADA was not able to read the value of the referenced field.

You are unlikely to see this diagnostic message.

#NOT REFERENCE#

The trip syntax incorrectly references a field that is not a reference field.

For example, %OCurrentState.Name%, where 'CurrentState' is a byte field, not a reference field. Refer to the Database Schema for a comprehensive list of the reference fields and aggregates that exist for each type of database item.

#AGGREGATE DISABLED#

The trip sequence references a database aggregate that is presently disabled, therefore ClearSCADA cannot display the referenced information.

#REFERENCE NOT FOUND#

The trip sequence contains a reference that is not a field or aggregate.

For example, %Onnnn.Name%, where there is neither a field or aggregate named ‘nnnn’.

#VALUE ERROR#

ClearSCADA was not able to read the value of the referenced field, or was not able to format the value into the message.

You are unlikely to see this diagnostic message.

#FIELD NOT FOUND#

The trip syntax references a field that does not exist.

Refer to the Database Schema for a comprehensive list of the fields that exist for each type of database item. Also check that the field name has not been misspelt and that the syntax is complete (see Trip Sequences Supported by Redirection Actions).

#OBJECT NOT FOUND#

ClearSCADA is unable to locate the item or the user that is associated with the alarm.

You are unlikely to see this diagnostic message.


Alarm Redirection Guide - Configure an Action Roster

Configure an Action Roster

Configure an Action Roster if you require different redirection actions to trigger in a different order on different days. For instance, to coincide with particular shift patterns, or holiday periods.

To add and configure an Action Roster:

  1. Add an Action Roster.
  2. Display and Configure Properties on the Action Roster Form.
  3. Add Redirection Actions to the Action Roster.
  4. Define the Priority of Each Action on the Roster.
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

You can then attach the Action Roster to a database item to redirect the alarms for that item (see Configure Alarm Redirections for an Item or Group).

For an example of how an Action Roster can be used, see Example of Action Roster Configuration.

NOTE: As an alternative to Action Rosters, you might want to consider using alarm Redirection Calendars (see Alarm Redirection Calendar).


Alarm Redirection Guide - Add an Action Roster (Configure an Action Roster)

Add an Action Roster

Before you can redirect an item’s alarms on a roster basis, you need to add and configure an Action Roster.

To add an Action Roster:

  1. Right-click on the System or Group to which you want to add the roster (this might be a separate Group for storing redirection actions).
    A context sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Alarm Redirection Action option.
    A further menu is displayed.
  4. Select the Action Roster option.
    An Action Roster is added to the system. It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Action Roster (see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  6. Select another part of the interface or press the ENTER key to confirm the entry.

When you have added an Action Roster, you need to Display and Configure Properties on the Action Roster Form.


Alarm Redirection Guide - Display and Configure Properties on the Action Roster Form (Configure an Action Roster)

Display and Configure Properties on the Action Roster Form

You need to use the Action Roster Form to configure the properties of a roster. To display and configure the properties on the Form:

  1. Right-click on the Action Roster in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Properties option.
    The Action Roster Form is displayed.
  3. Use the Identification tab to define the Identification properties (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  4. Use the User Methods tab to define any custom pick actions (‘methods’) for the Action Roster (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  5. Configure the Properties on the Action Tab.
  6. On the Action Roster tab:
  1. Use the Cutover time spin box to define the start of the day. This defines when the roster for one day finishes and the roster for the next day starts.

Example:

The Cutover time is 06:00. The roster for each day runs from 06:00 to 06:00, the time that the night shift finishes and the day shift starts. So at 06:00 on 2nd April, the roster starts for that day. The roster remains in force until 06:00 on 3rd April, when the roster for the 3rd April starts.

  2. Use the Action delay field to specify the time that ClearSCADA waits before triggering the next redirection action in the roster (the first redirection action executes immediately). Enter the time in the OPC Time Format, for example 5S for five seconds. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required delay.

Redirection actions are triggered in order of priority, with the highest priority (for example, Priority 1) being triggered immediately. For the next highest priority level, ClearSCADA waits for the time specified in the Action delay field before triggering the redirection action(s) that have that priority. It then waits the same amount of time again before triggering the redirection action(s) with the next priority, and so on until each of the redirection actions for that day’s roster have been triggered. (Redirection actions with Priority 0 are not executed.)

For an example of how the Action Delay can be used, see Example of Action Roster Configuration.

  3. Use the Local Time check box to specify whether the time used for the roster is Local Time (check box selected), or UTC (Coordinated Universal Time)/GMT (check box clear).

For more information on Time Zone settings, see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.

  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have configured the properties on the Alarm Roster Form, you can Add Redirection Actions to the Action Roster.


Alarm Redirection Guide - Add Redirection Actions to the Action Roster (Configure an Action Roster)

Add Redirection Actions to the Action Roster

Once you have an Action Roster on your system (see Display and Configure Properties on the Action Roster Form), you can add redirection actions to that roster.

By default, each Action Roster can have up to 10 redirection actions associated with it. However, you can adjust the maximum number of redirection actions on an individual roster basis (see Define a Different Action Roster Size).

NOTE: Ensure that the redirection action(s) that you want to add to the roster exist on your system, or configure new redirection action(s) if required (see Configure a Redirection Action).

To edit the roster and add a redirection action:

  1. Right-click on the Action Roster in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Action Roster is displayed.
  3. In the Database Bar, select the redirection action that you want to add to the roster—do not release the mouse button.
  4. Drag the redirection action over to the next available Action field on the roster.
    ...over into an available Action field on the Action Roster...
    Drag the required Redirection Action...

  5. Release the mouse button.
    The redirection action is displayed on the roster. The date entries on the Roster calendar for that action are populated with the default priority of zero.
    ... the Redirection Action is added to the Action Roster and the date entries for that action are populated with the default priority of zero (indicating that ClearSCADA is not to execute the redirection action).

  6. Repeat Steps 3 to 5 for any other redirection actions that you want to add to the Action Roster.

When you have added the required redirection action(s) to the Action Roster, you need to Define the Priority of Each Action on the Roster.


Alarm Redirection Guide - Define the Priority of Each Action on the Roster (Configure an Action Roster)

Define the Priority of Each Action on the Roster

After you Add Redirection Actions to the Action Roster, you need to define the priority of those action(s).

By default, when you add a redirection action to a roster, the date fields on the roster calendar for that action are populated with the default priority of zero. Priority 0 informs ClearSCADA not to trigger the redirection action.

For any action that ClearSCADA is to trigger, you need to define a priority other than zero.

Actions are triggered on the roster in priority order, with the highest priority (for example, Priority 1) triggering immediately. Once those action(s) have triggered, ClearSCADA takes into account the Action Delay time specified on the Action Roster Form (see Display and Configure Properties on the Action Roster Form), and only triggers the actions with the next priority once the delay time has elapsed.

To change the priority of an alarm redirection on a roster:

  1. Select the tab that corresponds to the month for which you want to change the alarm redirection priority.
  2. In the row corresponding to the alarm redirection for which you want to change the priority, select the required date so that it is highlighted. (Use the horizontal scroll bar if necessary.)
  3. Press the ENTER key on the keyboard.
    The priority entry for that date is selected ready for changing.
  4. Enter the priority that you require (1 being the highest, 0 for any redirection action that ClearSCADA is not to trigger).
  5. Repeat the procedure for any other redirection actions on the roster.
  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).
    Select the month you require...
    ... followed by the date...
    ... press the ENTER key on the keyboard to select the entry, and then enter the required priority.

For an example of how priorities can be used to trigger actions in a particular order, see Example of Action Roster Configuration.

When you have defined the priority of each action on the roster, you can proceed to Configure Alarm Redirections for an Item or Group.


Alarm Redirection Guide - Define a Different Action Roster Size (Configure an Action Roster)

Define a Different Action Roster Size

By default, each Action Roster has an Index that allows up to 10 redirection actions to be attached to the roster. However, you can change the size of each roster on an individual basis to hold anywhere between one and 100 redirection actions.

To adjust the size of a roster:

  1. Either:
  • Double-click on the Action Roster in the Database Bar.

Or:

  1. Right-click on the Action Roster in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Edit option.

The Action Roster is displayed.

  2. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Map Size option.
    The Change Roster Size window is displayed, showing the maximum number of redirection actions that can presently be attached to the roster.
  4. In the New field, specify the maximum number of redirection actions that you want to be able to attach to the roster (a value between 1 and 100).
  5. Select the OK button to confirm the change.
    The Change Roster Size window is closed, and the Action Roster resized accordingly.

If you attempt to resize an Action Roster already populated with redirection actions, and you enter a roster size smaller then the number of actions that exists on the roster, a message is displayed:

If you select the OK button, any redirection actions located at Index entries above the newly set roster size will be lost. Select the Cancel button if you want to retain the redirection actions or set a different roster size.


Alarm Redirection Guide - Example of Action Roster Configuration (Configure an Action Roster)

Example of Action Roster Configuration

This example shows example configuration for an Action Roster that has four redirection actions, and shows the order in which those actions are executed when the roster is triggered.

Example:

An Action Roster is configured with these settings:

Four redirection actions are attached to the roster:

The roster is attached to an analog point.

At 06:35 on the 4th of May, the Action Roster is triggered by the analog point going into an alarm state.

As the time is after 05:59, the roster for the 4th of May becomes active (before 06:00, the roster for the 3rd of May would still have been in force, as the Cutover time is configured as 06:00).

ClearSCADA immediately triggers the redirection action that is configured as Priority 1. For the 4th of May, this is the action configured at Index 0.

After 10 seconds (the Action delay time), as the analog point is still in alarm, ClearSCADA triggers both redirection actions that are configured as Priority 2. For the 4th of May, these are the actions configured at Index 1 and Index 3.

Finally, after another 10 seconds, as the analog point is still in alarm, ClearSCADA triggers the redirection action that is configured as Priority 3 (at Index 2).

Should the Action Roster have been triggered at 06:35 on the 5th of May, ClearSCADA would have triggered the redirection actions in a different order—still in order of priority (1, 2, and then 3), but in this case, the redirection action at Index 2 would have been triggered immediately, followed 10 seconds later by the actions at Index 0 and Index 3, then after a further 10 seconds by the action at Index 1.


Alarm Redirection Guide - Configure an Alarm Redirection Calendar

Configure an Alarm Redirection Calendar

NOTE: Do not confuse Alarm Redirection Calendars with ‘normal’ Calendars. ‘Normal’ Calendars are used alongside other ClearSCADA features, such as Schedules, to indicate functions that are to occur on specific dates in the year. For information on ‘normal’ Calendars, see Configuring Calendars in the ClearSCADA Guide to Core Configuration.

Configure an alarm redirection Calendar if you want to schedule sets of alarm redirections to trigger at different times on different days, or to only trigger on specific types of day (for example, during Company Shutdown periods, Public holidays, or at weekends.).

With a Calendar, you configure alarm redirection schedules for each day of the week and any custom Day Types using the Edit Day Schedule window...
...Monday to Sunday schedules are allocated automatically to those days on the Calendar. However, you can also override any date with a custom Day Type...
...the alarm redirection lists that you schedule for each day, correspond to the alarm redirections that you configure on the corresponding tabs of the Calendar Form.

Before you add and configure Calendar(s) on your system, you need to plan your Calendar requirements. For instance:

  • How many different sets of alarm redirections do you require? For example, are different alarm redirections required on Public Holidays to other non-working times?

You can specify one set of alarm redirections that are deemed to run during non-working times, and any of seven sets of alarm redirections to run individually during different working times.

You can allocate different combinations of alarm redirection sets to each day of the week. You can also configure up to six additional Day Types for other occasions, such as Public holidays or Company Shutdown periods. You can allocate any combination of the eight alarm redirection sets to each day type.

  • Do alarm redirections need to change part-way through a day? If so, at what times? How many of the eight sets of alarm redirections need to run individually for each day type?

Each Calendar day runs from 00:00 to 00:00. Any time between midnight and the first time that you schedule for a day is deemed to be Non-Working. ClearSCADA can run any of the eight alarm redirection sets individually at different times or in a different order for each Day Type.

  • Do many of the Calendars on your system use the same schedules for individual days of the week? If so, ensure that default schedules have been set up for those days.

Default schedules can be set on a per server basis, using the Alarm Action Calendar section of the ClearSCADA Server Configuration Tool (see Alarm Action Calendar Settings in the ClearSCADA Guide to Server Administration). The defaults will appear as the default schedule settings for each day of the week, on every new Calendar that is added to your system.

For examples of how an alarm redirection Calendar can be used, see Examples of Calendar Configuration.

To add and configure a Calendar:

  1. Add a Calendar
  2. Display the Calendar Editor
  3. Select a Calendar Year
  4. Define the Alarm Redirection Schedule for a Day
  5. Rename a Custom Day Type
  6. Associate a Custom Day Type with a Calendar Date
  7. Display and Configure Properties on the Calendar Form
  8. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

You can then attach the Calendar to a database item to redirect the alarms for that item (see Configure Alarm Redirections for an Item or Group).


Alarm Redirection Guide - Add a Calendar (Configure an Alarm Redirection Calendar)

Add a Calendar

NOTE: Do not confuse Alarm Redirection Calendars with ‘normal’ Calendars. ‘Normal’ Calendars are used alongside other ClearSCADA features, such as Schedules, to indicate functions that are to occur on specific dates in the year.
For information on ‘normal’ Calendars, see Configuring Calendars in the ClearSCADA Guide to Core Configuration.

Before you can redirect an item’s alarms on a calendar basis, you need to add and configure an alarm redirection Calendar.

NOTE: If many of the Calendars on your system are to use the same schedule times for the individual days of the week, you can set up default schedule times for those days. The default times can be set on a per server basis, using the Alarm Action Calendar section of the ClearSCADA Server Configuration Tool (see Alarm Action Calendar Settings in the ClearSCADA Guide to Server Administration). The defaults apply to each new Calendar that is added to your system.

To add a Calendar:

  1. Right-click on the System or Group to which you want to add the calendar (this might be a separate Group for storing redirection actions).
    A context sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Alarm Redirection Action option.
    A further menu is displayed.
  4. Select the Calendar option.
    A Calendar is added to the system. It is selected automatically, ready for you to enter its name.
  5. Enter a suitable name for the Calendar (see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  6. Select another part of the interface or press the ENTER key to confirm the entry.

When you have added a Calendar, you can Display the Calendar Editor and specify the redirection schedules that are required.


Alarm Redirection Guide - Display the Calendar Editor (Configure an Alarm Redirection Calendar)

Display the Calendar Editor

You use the Calendar Editor to select the year(s) for which you want to configure alarm redirection schedules, allocate ‘standard’ schedules to each day of the week or allocate specific schedules to specific days.

To display the Calendar Editor:

  1. If you are logged on as an engineer-type user who is configured to edit documents by default, double-click on the required Calendar entry in the Database Bar.
    (For information, see Creating a User Account in the ClearSCADA Guide to Security.)
    The Calendar Editor is displayed.

NOTE: If the Database Bar is not displayed, you can access it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

or:

  1. Either:
  • Right-click on the item in the Database Bar.

or:

  • Select the item on a List.

or:

  • Select an animated representation of the item on a Mimic. (The animated representation has to be associated with the item’s Pick Action Menu).

A context sensitive menu is displayed.

  2. Select the Edit option.
    The associated Calendar Editor is displayed.

You can use the Calendar Editor to:

  • Select a Calendar Year
  • Define the Alarm Redirection Schedule for a Day
  • Associate a Custom Day Type with a Calendar Date.

NOTE: Do not confuse Alarm Redirection Calendars with ‘normal’ Calendars. ‘Normal’ Calendars are used alongside other ClearSCADA features, such as Schedules, to indicate functions that are to occur on specific dates in the year.
For information on ‘normal’ Calendars, see Configuring Calendars in the ClearSCADA Guide to Core Configuration.


Alarm Redirection Guide - Select a Calendar Year (Configure an Alarm Redirection Calendar)

Select a Calendar Year

To select a Calendar year:

  1. Display the Calendar Editor.
  2. Use the Year spin box to select the required year.


Alarm Redirection Guide - Define the Alarm Redirection Schedule for a Day (Configure an Alarm Redirection Calendar)

Define the Alarm Redirection Schedule for a Day

In order to associate Working and Non-Working sets of alarm redirections with specific time periods on specific days, you need to associate those sets of redirections with Day Types. You can associate Working or Non-Working Redirections with individual days of the week (Sunday, Monday, and so on) or with other Day Types that you can customize to your system’s requirements. (Custom Day Types are labelled Day Type 1 to Day Type 6, by default—to rename a customer Day Type, see Rename a Custom Day Type.)

NOTE: If many of the Calendars on your system are to use the same schedule times for the individual days of the week, you can set up default schedule times for those days. The default times can be set on a per server basis, using the Alarm Action Calendar section of the ClearSCADA Server Configuration Tool (see Alarm Action Calendar Settings in the ClearSCADA Guide to Server Administration). The defaults apply to each new Calendar that is added to your system.

In order to define the schedule for a Day Type, you need to:

  1. Display the Calendar Editor.
  2. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Day Schedules option.
    The Edit Day Schedule window is displayed.
  4. Select the day for which you want to define a schedule (for example, Monday).

Each day runs from 00:00 to 00:00 the next day. By default, a day is deemed to be Non-Working unless configured otherwise.

  5. Select the New button.
    The Day Entry window is displayed.

Use the window to define the schedules that you require for the day, specifically the starting time(s) for individual sets of alarm redirections.

By default the time from 00:00 to the first time that you enter on a schedule is deemed to be Non-Working, and corresponds to the set of alarm redirections that you configure on the Non-Working Time Redirections tab of the Calendar Form (see Define a Set of Alarm Redirection Actions).

  6. To enter a schedule time, select the hours part of the Time entry and either use the spin box to select the required time, or overtype the entry. Ensure that you use 24-hour clock settings.
  7. Select the minutes part of the Time entry and either use the spin box to select the required time, or overtype the entry.
  8. Use the Redirection List combo box to specify the name of the alarm redirection list that is to come into effect at the Time that you have just specified.

Each Redirection List option links to the set of alarm redirections that are configured on a particular tab of the corresponding Calendar Form. For instance, the Non-Working option corresponds to alarm redirections that are configured on the Non-Working Time Redirections tab, and the Working 1 option corresponds to alarm redirections that are configured on the Working 1 Redirections tab.

Select the option that corresponds to the required set of alarm redirections for the time that you have specified.

  9. Repeat Steps 5 to 8 for any further alarm redirection schedules that you want to include for the same day. You can add numerous schedule entries for each Day Type.
  10. Repeat Steps 4 to 9 for any other days for which you want to configure schedule entries.
  11. Select the OK button to confirm the settings.
    The Edit Day Schedule window is closed.
  12. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).
    The schedule details become associated with the Calendar Day Types

Each day of the week automatically becomes associated with the schedule configured for its Day Type—for instance, every Monday becomes associated with the schedule that is set for the Monday Day Type. If no schedule is configured for a particular Day Type, by default it is deemed to use the Non-Working Alarm Redirections List (and therefore uses the set of alarm redirections configured on the Non-Working Time Redirections tab of the Calendar Form (see Define a Set of Alarm Redirection Actions)).

To replace the schedule for a particular day with another schedule—for example, replace the schedule for a particular Monday with a Public Holiday schedule, you need to override that particular day with a custom Day Type in the Calendar Editor (see Associate a Custom Day Type with a Calendar Date).

To define the sets of alarm redirections that relate to the redirection lists that you have scheduled for each day, specify the redirections on the corresponding Redirection tabs of the Calendar Form (see Define a Set of Alarm Redirection Actions).

For examples of how alarm redirection schedules and custom Day Types can be used, see Examples of Calendar Configuration.


Alarm Redirection Guide - Rename a Custom Day Type (Configure an Alarm Redirection Calendar)

Rename a Custom Day Type

If you want a calendar to run a different schedule on a specific type of day, such as a Public Holiday or during a period of Company Shutdown, you can configure a custom Day Type. By default, custom Day Types are labelled Day Type 1 to Day Type 6, but you can rename these Day Types to give them more meaningful names.

To rename a custom Day Type so that its name reflects the type of day that it is to represent:

  1. Display the Calendar Editor.
  2. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Day Schedules option.
    The Edit Day Schedule window is displayed.
  4. Select the relevant Day Type 1 to Day Type 6 entry.
    A selected entry is highlighted...

  5. Select the entry again.
    ...A reselected entry is made available for renaming.

  6. Overtype the entry with a new name. You can use any combination of alphanumeric characters. The name can be up to a maximum of 31 characters long.
  7. Configure the schedule for that day type (see Define the Alarm Redirection Schedule for a Day).
  8. Select the OK button to confirm the settings.
    The Edit Day Schedule window is closed and the name of the Day Type is changed in the Calendar Day Type Selector field.
  9. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

You can then Associate a Custom Day Type with a Calendar Date.

NOTE: You may want to rename any unused custom Day Types to include the text ‘UNUSED’ and so avoid inadvertently adding any unconfigured custom Day Types to a Calendar.

For examples on using custom Day Types, see Examples of Calendar Configuration.


Alarm Redirection Guide - Associate a Custom Day Type with a Calendar Date (Configure an Alarm Redirection Calendar)

Associate a Custom Day Type with a Calendar Date

By default, ClearSCADA automatically associates each day of the week with an alarm redirection schedule for that Day Type—for instance, every Monday is associated with a schedule for the Monday Day Type. You configure the alarm redirection schedule for each day of the week using the Edit Day Schedule window (see Define the Alarm Redirection Schedule for a Day) and the corresponding Redirections tabs on the Calendar Form (see Define a Set of Alarm Redirection Actions).

If you want to override a specific day with a custom schedule—for instance, one for a Public Holiday—you can associate a custom Day Type with that day on the calendar.

By default, custom Day Types are labelled Day Type 1 to Day Type 6. They are each associated with a different color. You use the color to indicate the position of a custom Day Type on the Calendar.

Custom Day Types are labelled Day Type 1 to Day Type 6 by default.

To use a custom Day Type:

  1. Give each custom Day Type a name that indicates its usage (see Rename a Custom Day Type).
  2. Define the schedule that is to be associated with that Day Type (see Define the Alarm Redirection Schedule for a Day).
  3. Select the required custom Day Type from the field at the top of the Calendar Editor. (The names of the Day Types reflect the names that have been allocated to them in the Edit Day Schedule window.)
  4. Select the date(s) that are to use that Day Type on the Calendar:
  • To select a single day, click on the day on the Calendar.
    The day becomes highlighted with the color that represents that Day Type.
  • To select a block of days, drag over the required days on the Calendar.
    The days become highlighted with the color that represents that Day Type.
  5. Repeat the steps above for any other dates that you want to associate with custom Day Types.
  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).
    The dates that have been allocated custom Day Types will run the corresponding alarm redirection schedules that are associated with those custom Day Types. As such, a Monday that has been allocated a ‘Public Holiday’ custom Day Type, will run the ‘Public Holiday’ schedule, rather than the Monday schedule.

Select the required Custom Day Type from the list...
...then select the date(s) that you want to associate with that custom Day Type.

To define the alarm redirections that are to run during a custom Day Type, see Define the Alarm Redirection Schedule for a Day, and see Define a Set of Alarm Redirection Actions.

To remove an association with a particular custom Day Type, either:

  1. Hold down the right-hand mouse button.
  2. Select or drag over the date(s) on the Calendar.
    The custom Day Type color will be deleted for the selected date(s).
  3. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).
    The changed date will use the schedule that is allocated to that day of the week.

or:

  1. Allocate another custom Day Type color to that date.
  2. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).
    The changed date will use the schedule that is allocated to the custom Day Type with which it is now associated.

For more information on using custom Day Types, see Examples of Calendar Configuration.


Alarm Redirection Guide - Display and Configure Properties on the Calendar Form (Configure an Alarm Redirection Calendar)

Display and Configure Properties on the Calendar Form

NOTE: Do not confuse Alarm Redirection Calendars with ‘normal’ Calendars. ‘Normal’ Calendars are used alongside other ClearSCADA features, such as Schedules, to indicate functions that are to occur on specific dates in the year.
For information on ‘normal’ Calendars, see Configuring Calendars in the ClearSCADA Guide to Core Configuration.

You need to use the Calendar Form to configure the basic calendar properties and the required sets of alarm redirections. For instance, you might want to configure one set of redirection actions for when a control center is manned, and another set of redirection actions for when the control center is unmanned.

To display and configure the properties on the Calendar Form:

  1. Right-click on the Calendar in the Database Bar.
    A context-sensitive menu is displayed.
  2. Select the Properties option.
    The Calendar Form is displayed.
  3. Use the Identification tab to define the Identification properties (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  4. Use the User Methods tab to define any custom pick actions (‘methods’) that are to be associated with the Calendar (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  5. Configure the Properties on the Action Tab.
  6. Use the Calendar tab to define the time settings for the Calendar:
  • Select the Local Time check box to use the Local Time zone, for instance British Summer Time (BST).
  • Clear the Local Time check box to use UTC (Coordinated Universal Time).

For more information on Time Zone settings, see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.

  7. Use the Non-Working Time Redirections tab to define the set of alarm redirections that are to be used during any non-working times on the Calendar (see Define a Set of Alarm Redirection Actions).
  8. Use the Working 1 Redirections to Working 7 Redirections tabs to allocate appropriate sets of alarm redirections for the various working times on the Calendar (see Define a Set of Alarm Redirection Actions). For example, you might want to configure one set of alarm redirections for a Day Shift and another set of alarm redirections for a Night Shift.

For any sets of redirections that are not required, ensure that the Enabled check boxes on those tabs are clear (disabled).

  9. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Alarm Redirection Guide - Define a Set of Alarm Redirection Actions (Configure an Alarm Redirection Calendar)

Define a Set of Alarm Redirection Actions

You use the fields on the Non-Working Time Redirections tab and the seven Working Redirections tabs on the Calendar Form to configure sets of alarm redirections. You can configure up to 10 alarm redirections or alarm redirection rosters per Redirections tab.

Each alarm redirection set corresponds to a specific Redirections List that you can allocate to specific days or dates on a Calendar. For instance, you use the Non-Working Redirections List in the Edit Day Schedule window to schedule the times from which ClearSCADA runs the set of alarm redirections that are configured on the Non-Working Time Redirections tab of the Calendar Form. Similarly, you use the Working 1 Redirections List to schedule the times from which ClearSCADA runs the set of alarm redirections that are configured on the Working 1 Redirections tab, and so on.

For more information, see Define the Alarm Redirection Schedule for a Day, and see Examples of Calendar Configuration.

To configure an alarm redirection entry on any of the Redirections tabs on the Calendar Form:

NOTE: You need to have configured the required Redirection Actions (see Configure a Redirection Action) and Action Rosters (see Configure an Action Roster) before you can select the actions and action rosters for alarm redirection.

  1. Select the Enabled check box to indicate that a redirection action is in use.
    Other fields in the row become available for use.

(Clear the Enabled check box for any rows that you do not want to use.)

  2. Use the Action field to specify the Action or Action Roster that is to be performed when this set of Redirection Actions is scheduled to run.

Use the browse button adjacent to the Action field to display a Reference browse window and select the required action or action roster from the window.

  3. Use the Low Severity and High Severity combo boxes to define the severity range within which alarms are redirected. Any alarms that occur outside of the specified severity range are not redirected.

For more information on using severity ranges to redirect alarms, see Define the Severity Range.

  4. Use the Delay field to suspend the alarm redirection for a specified amount of time. Enter the time in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required delay.
    The alarm is not redirected until the Delay time expires. If the alarm changes to the Abort State (see below) within the Delay time, the alarm is not redirected.

To redirect an alarm as soon as it is raised, you should set the Delay to 0, and the Abort State to ‘Never’.

For more information on using the Delay feature, see Define a Delay.

  5. Use the Abort State field to specify the alarm state that causes the alarm redirection to be canceled. Use this property in conjunction with the Delay time (see above) to specify the circumstances under which redirection is canceled. For example, if the alarm is acknowledged within the Delay time.

For more information on aborting redirections, and the Abort States that you can select, see Define the Abort State.

  6. Repeat the steps above for any other alarm redirections that you want to configure.
  7. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Alarm Redirection Guide - Examples of Calendar Configuration (Configure an Alarm Redirection Calendar)

Examples of Calendar Configuration

This section includes several examples of Calendar configuration. The examples can be used as an aid when configuring alarm redirection Calendars on a ClearSCADA system.

The section includes these examples:

  • A Calendar for a Five Day Working Week
  • A Calendar for a Control Room that has Three Working Shift Patterns.


Alarm Redirection Guide - A Calendar for a Five Day Working Week (Configure an Alarm Redirection Calendar)

A Calendar for a Five Day Working Week

This example demonstrates the configuration of a simple Alarm Action Calendar on
a ClearSCADA system. The Calendar in this example is for a control room that has a five-day working week. Alarms are redirected to the on-call engineer out of hours and during Public holidays.

Example:

A control room has a 5-day working week. It is manned during the following hours:

Monday to Thursday 08:30 to 16:30
Friday08:30 to 15:30

Out of hours and during Public Holidays, alarms are redirected to the on-call engineer.

The Monday to Thursday Day Types are set to correspond to the working times above, so are configured as follows:
08:30Working 1 Redirection List
16:30Non-Working Redirection List
(By default, the period from midnight to the first entry of 08:30 is deemed Non-Working, and therefore does not need to be set manually.)

Similarly, the Friday Day Type is configured to have these times:
08:30Working 1 Redirection List
15:30Non Working Redirection List
(Again, by default, the period from midnight to the first entry of 08:30 is deemed Non-Working, and therefore does not need to be set manually.)

On the Calendar Form, suitable alarm redirections are set on the Working 1 Redirections tab to redirect alarms for when engineers are manning the control room (during normal working hours, Monday to Friday). The Non-Working Time Redirections tab of the Calendar Form is used to redirect alarms to the on-call engineer for when intervention is required out of hours.

For Public Holidays, Day Type 1 is renamed to Public Holiday. It is not given any schedule settings, as by default every Day Type is deemed to run the Non-Working Redirection List, unless configured otherwise. (If different alarm redirections were required to those for other out of hours times, the Public Holiday Day Type could have been allocated the Working 2 Redirections List, and appropriate redirections set on the Working 2 Redirections tab of the Calendar Form.)

Similarly, Saturday and Sunday are not allocated any schedule times as these, by default, already run the Non-Working Redirections List for the whole day.

For clarity, Day Types 2 to 6 are renamed to include the text ‘Unused’, so that engineers do not inadvertently add these unconfigured Day Types to the Calendar.

Finally, Public Holiday dates are added to the Calendar Editor. The Public Holidays override the usual settings for the days to which they are allocated. So, if a Public Holiday occurs on a Monday, ClearSCADA redirects alarms according to the Public Holiday Day Type Schedule, rather than the Monday Day Type Schedule.

For May 2004, the Calendar shows the following:

The 3rd and 31st are Public Holidays, so are highlighted in dark blue, the Public Holiday Day Type.
Others days are automatically allocated their corresponding Day Type Schedules (Monday to Sunday), and are not highlighted.

Further Information

Configure an Alarm Redirection Calendar.

Define the Alarm Redirection Schedule for a Day.

Define a Set of Alarm Redirection Actions.

Rename a Custom Day Type.

Associate a Custom Day Type with a Calendar Date.


Alarm Redirection Guide - A Calendar for a Control Room that has Three Working Shift Patterns (Configure an Alarm Redirection Calendar)

A Calendar for a Control Room that has Three Working Shift Patterns

This example demonstrates the configuration of a more complex Alarm Action Calendar on a ClearSCADA system. The Calendar in this example is for a control room that has three working shift patterns that change on a weekly basis, with alternate work patterns for Sundays and Public holiday periods.

For an example that demonstrates how to configure a simpler alarm redirection Calendar, see A Calendar for a Five Day Working Week.

Example:

A control room has a six-day working week, with three 8-hour shifts per day. The shifts run from 00:00 to 08:00, 08:00 to 16:00, and 16:00 to 00:00 on Monday to Saturday each week.

The shifts rotate on a weekly basis, such that engineers that worked the 00:00 to 08:00 shift one week, work the 08:00 to 16:00 shift the following week, followed by the 16:00 to 00:00 shift the third week.

During Sundays, the office is unmanned, however engineers in another office are contactable during the hours of 12:00 to 16:00.

During Public Holiday periods, the office is unmanned and alarms are redirected to the on-call engineer. On-call engineers operate on a 12-hour shift during Public Holidays, with shifts running from 00:00 to 11:59 and 12:00 to 23:59.

As the six-day shifts rotate on a weekly basis, the Monday to Saturday Day Schedules are unused. Instead, three of the additional Day Types, Day Type 1 to Day Type 3, are renamed and configured as follows:

Day Type 1 is renamed to Shift Pattern 1 and is given these settings:
00:00Working 1 Redirection List
08:00Working 2 Redirection List
16:00Working 3 Redirection List

Day Type 2 is renamed to Shift Pattern 2 and is given these settings:
00:00Working 3 Redirection List
08:00Working 1 Redirection List
16:00Working 2 Redirection List

Day Type 3 is renamed to Shift Pattern 3 and is given these settings:
00:00Working 2 Redirection List
08:00Working 3 Redirection List
16:00Working 1 Redirection List

On the Calendar Form, suitable alarm redirections are set on the Working 1 Redirections tab to redirect alarms for when engineers are working the 00:00 to 08:00 shift of Shift Pattern 1. The same redirections are used for the second shift of Shift Pattern 2 and the third shift of Shift Pattern 3.

Similarly, alarm redirections are set on the Working 2 Redirections tab of the Calendar Form for when engineers are working the 08:00 to 16:00 shift of Shift Pattern 1, the third shift of Shift Pattern 2, and the first shift of Shift Pattern 3.

Alarm redirections set on the Working 3 Redirections tab of the Calendar Form are configured for engineers working the 16:00 to 00:00 shift of Shift Pattern 1, the first shift of Shift Pattern 2, and the second shift of Shift Pattern 3.

The Sunday Day Schedule is configured as follows:

By default, the period from midnight to the first entry of 12:00 is deemed Non-Working, and therefore does not need to be set manually.

On the Calendar Form, suitable alarm redirections are set on the Working 4 Redirections tab to redirect alarms to the engineers in the neighboring office between 12:00 and 16:00 each Sunday. For other hours each Sunday, alarm redirections are set on the Non-Working Time Redirections tab of the Calendar Form.

Day Type 4 is renamed to Public Holiday and is configured with these settings:
00:00Working 5 Redirection List
12:00Working 6 Redirection List.

On the Calendar Form, suitable alarm redirections are set on the Working 5 Redirections tab for the on-call engineer that is working the 00:00 to 12:00 Public Holiday shift. Similarly, alarm redirections are set on the Working 6 Redirections tab for the on-call engineer that is working the 12:00 to 00:00 Public Holiday shift.

For clarity, Day Type 5 and Day Type 6 are renamed to include the text ‘Unused’, so that engineers do not inadvertently add these unconfigured Day Types to the Calendar.

Shift Patterns 1 to 3 are added to the Calendar Editor, followed by Public Holidays (which override the Shift Patterns for those days). The Calendar automatically picks up the Sunday Day Type and allocates its settings to every Sunday in the year, so Sundays do not need highlighting on the chart, unless they are a Public Holiday.

So for May 2004, the Calendar shows the following, with Shift Patterns rotating on a weekly basis:

The 3rd and 31st are Public Holidays, so are highlighted in red, the Public Holiday Day Type.
Sundays are automatically designated the Sunday Day Type, and are not highlighted.
Shift Pattern 1 is indicated by the dark blue highlight.
Shift Pattern 2 is indicated by the light green highlight.
Shift Pattern 3 is indicated by the light blue highlight.

Further Information

Configure an Alarm Redirection Calendar.

Rename a Custom Day Type.

Define the Alarm Redirection Schedule for a Day.

Define a Set of Alarm Redirection Actions.

Associate a Custom Day Type with a Calendar Date.


Alarm Redirection Guide - Configure Alarm Redirections for an Item or Group

Configure Alarm Redirections for an Item or Group

You need to configure the Alarm Redirection properties of every database item or Group (including the Root Group) that is to have its alarms automatically redirected in some form. Any database item that has alarms can have those alarms redirected.

NOTE: You need to configure the individual Redirection Actions that are needed on your system before you can configure the properties on the Redirection tab for an item (see Configure a Redirection Action). If the Redirection Actions are to trigger on a roster basis, you also need to have configured the Action Roster(s) that you require (see Configure an Action Roster). Similarly, if Redirection Actions are to trigger on a calendar basis, you need to have configured the alarm redirection Calendar(s) that you require (see Configure an Alarm Redirection Calendar).

You can use the Redirection tab that is available on the Forms for many types of database item to configure up to 15 alarm redirections.

Redirection tab

The alarm redirections allow ClearSCADA to redirect an item’s alarms:

  • As an e-mail message
  • As a pager message or mobile telephone (SMS) message
  • To perform an action (known as invoking a method)
  • To alter alarm severity
  • To restrict the ability to acknowledge an alarm
  • To execute a system command
  • On a roster basis
  • On a calendar basis.

For example, e-mails can be sent to another User, User Group, or User Roster when alarms are raised for a selected database item. This allows users (typically engineers) to receive alarm data when they are not working on a ClearSCADA workstation (client), such as when they are on site (see Use a User Roster to Redirect Alarms ‘Out of Hours’ to an On-Duty Engineer).

If you configure redirections to run on a roster or calendar basis, you can configure different redirections to trigger in a different order on different days, depending on the requirements of your system (see Example of Action Roster Configuration, and see Examples of Calendar Configuration).

NOTE: ClearSCADA can be configured to trigger a particular Method Action immediately, whenever an alarm state change occurs, regardless of the alarm priority or when the alarm changes state. If this is required, consider whether to configure a Method on the Alarm tab of a Form (see Configure a Method Action to Trigger at Every Alarm State Change in the ClearSCADA Guide to Core Configuration).

To configure alarm redirections for a database item:

  1. Display the Form for the item that you want to configure (see Display a Form in the ClearSCADA Guide to Core Configuration).
  2. Select the Redirection tab.
  3. Enable or Disable Alarm Redirections for a Database Item.
  4. Define the Trigger Type.
  5. Define the Trigger State.
  6. Select the Action to be Taken.
  7. Define the Severity Range.
  8. If the Area of Interest feature is enabled on your system, Specify the Area of Interest for which Alarms are Redirected.
  9. If an alarm redirection is to be triggered manually:
  1. Define When the Redirection Action is Active.
  10. If an alarm redirection is to trigger automatically, or both manually and automatically:
  1. If the alarm redirection applies to, or can apply to, alarms on Point(s), Specify the Direction of Travel that Denotes Whether a Point Alarm is Redirected.
  2. Define a Delay.
  3. Define the Abort State.
  4. Define When the Redirection Action is Active.
  11. Repeat the above steps from step 4 onwards for each alarm redirection.
  12. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

You can define up to 15 redirection actions/action rosters/alarm redirection calendars for each database item. You can also define up to 15 redirection actions/action rosters/alarm redirection calendars for each Group. Group redirection actions, action rosters, and alarm redirection calendars apply to every item in the Group. Root Group redirection actions, action rosters, and alarm redirection calendars apply to every item on that ClearSCADA system. (On systems with multiple databases, you need to configure the required alarm redirections for each Root Group.)

For each alarm redirection, you specify whether the redirection is to trigger automatically and/or manually. When an alarm occurs, ClearSCADA checks the trigger type of each action, action roster, or alarm redirection calendar in order, from the top entry on the Redirection tab downwards. If the alarm condition meets the redirection criteria, ClearSCADA either redirects the alarm, and/or makes menu option(s) available, to enable users to redirect the alarm manually. For more information, see Understand Alarm Redirection, and see Circumstances in which Alarm Redirections do not Trigger.

This guide includes various examples that demonstrate how alarm redirections might be configured and used on a ClearSCADA system. If you are unsure about the effects of the alarm redirection configuration, see:

  • Example Configuration (a series of examples covering various aspects of alarm redirection configuration)
  • Example of Action Roster Configuration
  • Examples of Calendar Configuration.

If you are configuring a database item that is already configured to make use of the alarm redirections feature, you can choose to disable the alarm redirections. This is useful when the database item has been demoted so that it is no longer critical to the system. For instructions on disabling alarm redirections, see Enable or Disable Alarm Redirections for a Database Item.

NOTE: ClearSCADA can be configured to trigger a particular Method Action immediately, whenever an alarm state change occurs, regardless of the alarm priority or when the alarm changes state. If this is required, consider whether to configure a Method on the Alarm tab of a Form (see Configure a Method Action to Trigger at Every Alarm State Change in the ClearSCADA Guide to Core Configuration).

You can use the Alarm Redirections section of the ClearSCADA Server Status Tool to ascertain which alarm redirections are pending or in progress on your ClearSCADA system (see Alarm Redirections in the ClearSCADA Guide to the Server Status Tool). The section shows those alarm redirections that are to be triggered automatically (see Define the Trigger Type). Manual alarm redirections are executed as soon as they are requested, and therefore do not appear in the section.


Alarm Redirection Guide - Enable or Disable Alarm Redirections for a Database Item (Configure Alarm Redirections for an Item or Group)

Enable or Disable Alarm Redirections for a Database Item

To allow the alarms of a selected database item to be redirected, you need to select the Enabled check box on that item’s Redirection tab. The Redirection tab is available on the configuration Form of most types of database item.

If required, you can disable the alarm redirections feature on a database item that was previously configured to use alarm redirections. You should only disable the alarm redirections of a database item if you are certain that its alarms no longer need to be redirected. (Be aware that you can use the CancelRedirections method to cancel specific alarm redirections—see CancelRedirections and RestartRedirections Methods.)

For any database item for which alarms are not to be redirected, clear the Enabled check box on the Redirection tab.

To enable or disable alarm redirections for a database item:

  1. Display the Form for the database item that you want to configure (for more information, please refer to the relevant configuration section).
  2. Select the Redirection tab.
    The Redirection tab is displayed.
    Redirection tab

  3. Either:
  • Select the Enabled check box to allow alarm redirections to occur.
    The Trigger Type combo boxes become available for selection.
    When the check box is selected (a check mark is displayed), the Trigger Type combo boxes become available.

Or:

  • Clear the Enabled check box.
    The alarm redirection fields are ‘grayed out’ and are unavailable for selection. The item’s alarms will not be redirected.
    When the check box is clear, the Trigger Type combo boxes are unavailable.

When you have enabled the alarm redirection feature, you need to start the configuration of the first alarm redirection—proceed to Define the Trigger Type.


Alarm Redirection Guide - Define the Trigger Type (Configure Alarm Redirections for an Item or Group)

Define the Trigger Type

Use the Trigger Type combo box on the Redirection tab to define how an alarm redirection is triggered whenever an alarm occurs.

Choose from:

  • None—The action is unused. The other fields in the row are ‘grayed out’ and unavailable for use.
  • Auto—ClearSCADA triggers the redirection automatically. The redirection triggers whenever an alarm state that meets the redirection criteria still exists once the specified Delay time (see Define a Delay) has expired.

If need be, you can cancel and later restart any automatic redirections that are waiting to trigger following a Delay—see CancelRedirections and RestartRedirections Methods.

  • Manual—Users with the required permissions can redirect the alarm manually. Specify this option, for example, if alarms are to be redirected only in exceptional circumstances.

In order for a user to be able to redirect an alarm manually:

  • The user needs to have the relevant permissions (including the Manual Redirection permission) to allow them to manually redirect alarms associated with the relevant database item(s).
  • The user needs to have Read access to the redirection action, action roster, or alarm redirection calendar that is specified in the redirection’s Action field (see Select the Action to be Taken).
  • If the Area of Interest feature is enabled on the system, the user needs to have access to the Area of Interest that is associated with the items’ alarms. (This Area of Interest may differ from the Area of Interest to which the alarms are to be redirected.) The Area of Interest is typically specified on the <Item Type> tab on the configuration Form of each database item—see the relevant configuration section for details.

To redirect an alarm manually, the user right-clicks on the alarm entry in the Alarms List or Alarm Banner and selects the appropriate custom redirection option. The text that is displayed for the menu option is defined in the Manual Redirection Description field, on the Form of the redirection action, roster, or calendar that is to be triggered. (You specify the redirection action, roster, or calendar that is to trigger, using the Action field on the Redirection tab—see Select the Action to be Taken.)

(If no Manual Redirection Description is configured for a redirection action, roster, or calendar that is set to trigger manually, the entry in the manual redirection destinations list will default to Redirect to <Action Name>, where <Action Name> is the full name of the redirection action, roster, or calendar.)

For examples that demonstrate how to configure alarms for manual redirection, see Use Alarm Redirection to Enable Operators to Manually Redirect Alarms, and see Allow an Operator to Enter a Comment when Manually Redirecting an Alarm.

  • Both—ClearSCADA is to trigger the redirection automatically. Additionally, users with the required permissions can redirect the alarm manually.

Specify this option, for example, if ClearSCADA is to redirect an alarm only if it remains in the Trigger State for quite some time—by also giving users the option to redirect the alarm manually, they can trigger the redirection before the specified Delay has expired, if this is deemed necessary.

As with the Manual Trigger Type (see above), users with the required permissions and access can redirect alarms manually, by selecting the required custom redirection option from the Alarms List or Alarm Banner.

For an alarm redirection with a Trigger Type other than ‘None’, you now need to Define the Trigger State.

Further Information

Security Permissions: see Allocating Security Permissions in the ClearSCADA Guide to Security.

Areas of Interest: see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

The Area of Interest Associated with an Item’s Alarms: see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration.

Specifying the Manual Redirection Description: see Configure the Properties on the Action Tab.

In some situations, you might want to consider alarm suppression as an alternative to alarm redirection. ClearSCADA is able to suppress alarms on certain database items while a specific alarm is active on another database item—see Alarm Suppression in the ClearSCADA Guide to Alarms. When an alarm is suppressed, it is omitted from alarm displays.


Alarm Redirection Guide - Define the Trigger State (Configure Alarm Redirections for an Item or Group)

Define the Trigger State

The Trigger State applies to redirection actions that are to trigger automatically, manually, or both manually and automatically (see Define the Trigger Type).

The Trigger State is the alarm state that causes an alarm to be redirected. For example, if the Trigger State is set to Unacknowledged Uncleared, each new Unacknowledged Uncleared alarm for the selected database item will be redirected.

To define a Trigger State:

  1. Ensure that the Enabled check box is selected so that the item’s alarms can be redirected (see Enable or Disable Alarm Redirections for a Database Item).
  2. Select the required Trigger State from one of the 15 Trigger State combo boxes.

We recommend that you use the top Trigger State combo-box for the first alarm redirection, and use the lower combo boxes for subsequent alarm redirections.

The Trigger States are:

  • Unacknowledged Uncleared—The redirection action, roster, or calendar triggers when a new alarm is raised.
  • Unacknowledged Cleared—The redirection action, roster, or calendar triggers whenever an alarm has cleared but the original alarm occurrence has not been acknowledged.
  • Acknowledged Uncleared—The redirection action, roster, or calendar triggers when an alarm is acknowledged but the alarm occurrence has not cleared.
  • Acknowledged Cleared—The redirection action, roster, or calendar triggers whenever a cleared alarm is acknowledged or an acknowledged alarm clears.
  • Acknowledged—The redirection action, roster, or calendar triggers whenever an alarm is acknowledged, whether or not the alarm state still exists.
  • Unacknowledged—The redirection action, roster, or calendar triggers whenever an alarm remains unacknowledged, whether or not the alarm state still exists.
  • Cleared—The redirection action, roster, or calendar triggers whenever an alarm clears, whether or not an operator has acknowledged the alarm.
  • Uncleared—The redirection action, roster, or calendar triggers if the item remains in an alarm state, regardless of whether an operator has acknowledged the alarm.
  • Always—The redirection action, roster, or calendar triggers whenever an alarm changes state.

For more information about the various alarm states, see Alarm Status in the ClearSCADA Guide to Alarms.

When you have selected a Trigger State for an alarm redirection, you need to Select the Action to be Taken.

NOTE: ClearSCADA can be configured to trigger a particular Method Action immediately, whenever an alarm state change occurs, regardless of the alarm priority or when the alarm changes state. If this is required, consider whether to configure a Method on the Alarm tab of a Form (see Configure a Method Action to Trigger at Every Alarm State Change in the ClearSCADA Guide to Core Configuration). Configuring a Method Action this way allows the Method to be triggered even when, for example, alarms are disabled for the item.


Alarm Redirection Guide - Select the Action to be Taken (Configure Alarm Redirections for an Item or Group)

Select the Action to be Taken

NOTE: You need to have configured the required Redirection Actions (see Configure a Redirection Action), Action Rosters (see Configure an Action Roster) and alarm redirection Calendars (see Configure an Alarm Redirection Calendar) before you can select the actions, action rosters, and Calendars for alarm redirection.

Each alarm redirection triggers an action (see Choose a Type of Alarm Redirection), an action roster (see Action Roster), or an alarm redirection calendar (see Alarm Redirection Calendar). The entry that is specified in the Action field on the Redirection tab, determines what happens when an alarm meets the redirection criteria and is redirected.

To define the action to be taken:

  1. Select the browse button next to the Action field for the alarm redirection that you want to configure.
    A Reference browse window is displayed.
    Reference browse window overlays Form

  2. Use the browse window to locate the Action that is to be performed, or the Action Roster, or alarm redirection Calendar that is come into force when the selected database item has an alarm that meets the redirection criteria.

For example, if you want an E-mail to be sent, select the relevant E-mail Action; if you want a series of actions to trigger on a roster or calendar basis, select the relevant Action Roster, or alarm redirection Calendar.

If the alarm redirection is set to trigger on a Manual basis (see Define the Trigger Type), only a user with Read access to the redirection action, action roster, or alarm redirection calendar that is specified in this Action field will be able to manually redirect an alarm. (Remember that the activity that you specify in the Action field will only come into effect when such a user manually triggers the redirection.)

  3. Select the OK button.
    The browse window is closed and the name of the Action, Action Roster or alarm redirection Calendar is shown in the Action field.

NOTE: You can select the Go To hyperlink next to the browse button to display the Form for the Action, Action Roster or alarm redirection Calendar.

Select the Go To hyperlink...
...to display the Action Form.

NOTE: As with other items in the database, each redirection Action, Action Roster, and alarm redirection Calendar can be made inactive as well as active. If ClearSCADA does not redirect alarms as expected, ensure that the specified Action, Roster, or Calendar is In Service. You can check this by using the Go To hyperlink to display the item’s Form, selecting the Action tab and ensuring that the In Service check box is selected.

When you have selected an Action, Action Roster or alarm redirection Calendar, you need to Define the Severity Range.


Alarm Redirection Guide - Define the Severity Range (Configure Alarm Redirections for an Item or Group)

Define the Severity Range

The Severity range allows you to redirect alarms according to their severity. For example, you can choose to only redirect alarms that have Critical priority (for more information on Alarm priorities, please see Defining Severities in the ClearSCADA Guide to Core Configuration).

To redirect alarms according to their severity, you need to define a severity range. You define the start of the severity range in the Low Severity combo box, and the end of the range in the High Severity combo box. Only those alarms that have severity levels within or including the defined range are redirected.

A set of severity levels is provided for each ClearSCADA system. By default they are Critical, High, Medium, and Low. These severity levels can be overridden with custom priority levels (see Alarm and Event Severities in the ClearSCADA Guide to Server Administration). Use the appropriate priority levels from the list available on your system.

Examples:

Using the default severity levels, you might configure the range so that it is Low-Critical. This is the default range, and it begins at Low priority and ends at Critical priority, with Medium and High priorities in between. Every alarm falls within this range, therefore every alarm is redirected.

If you configure the range so that it is Low-High, then alarms with Low, Medium or High priority are redirected. (Critical priority alarms are not in the defined range so are not redirected).

To define the priority range for an alarm redirection, after you Select the Action to be Taken:

  1. Use the Low Severity combo box to define the start of the priority range.
  2. Use the High Severity combo box to define the end of the priority range.

NOTE: The severity level options on your system may vary from those shown in the diagrams above, as severity levels can be overridden with custom levels. Choose the appropriate levels from the list available on your system.

When you have defined the priority range of the alarm redirection:

  • For an alarm redirection with a Trigger Type of Auto or Both, you need to Specify the Direction of Travel that Denotes Whether a Point Alarm is Redirected.
  • For an alarm redirection with a Manual Trigger Type, you need to Define When the Redirection Action is Active.

Additionally, if your system has the Area of Interest feature enabled, you need to Specify the Area of Interest for which Alarms are Redirected.


Alarm Redirection Guide - Specify the Area of Interest for which Alarms are Redirected (Configure Alarm Redirections for an Item or Group)

Specify the Area of Interest for which Alarms are Redirected

If the Area of Interest feature is enabled on your system, an Area of Interest field is available for each alarm redirection on the Redirection tab.

If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed for each alarm redirection.

Each alarm on the system is associated with an Area of Interest (the World Area of Interest, by default).

For each alarm redirection, use the Area of Interest field to specify the Area of Interest with which an alarm has to be associated, in order for that alarm to be redirected. Alarms are only redirected if they are associated with the specified Area of Interest, or an area that is contained within that Area of Interest.

You can only assign Area(s) of Interest to which your User Account has access.

For an example that covers redirection of alarms that have a specific Area of Interest, see Use an E-Mail Action to Enable an Engineer to Acknowledge Alarms Remotely.

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

For an alarm redirection with a Trigger Type of Auto or Both, you now need to Specify the Direction of Travel that Denotes Whether a Point Alarm is Redirected.

For an alarm redirection with a Manual Trigger Type, you now need to Define When the Redirection Action is Active.


Alarm Redirection Guide - Specify the Direction of Travel that Denotes Whether a Point Alarm is Redirected (Configure Alarm Redirections for an Item or Group)

Specify the Direction of Travel that Denotes Whether a Point Alarm is Redirected

The Direction field only applies to:

  • Redirection actions that are to trigger automatically, or both manually and automatically (see Define the Trigger Type).
  • Alarm redirections that apply to points, such as Analog or Counter points, that can be in one of a range of values and point states.

Use the Direction field to specify whether an alarm is to be redirected only if the point’s value is deemed to be traveling in a particular direction.

Choose from:

  • Either—Providing the alarm fulfills the other redirection criteria, the alarm is redirected regardless of the ‘direction’ in which the point value is traveling.
  • Toward Normal—The alarm is only redirected if the alarm fulfills the other redirection criteria and the point value is traveling toward the Normal State (for example, away from Zero Scale or Full Scale).
  • Away From Normal—The alarm is only redirected if the alarm fulfills the other redirection criteria and the point value is traveling away from the Normal State (for example, toward Zero Scale or Full Scale).

Once you have defined the direction to which the alarm redirection applies, you need to Define a Delay.


Alarm Redirection Guide - Define a Delay (Configure Alarm Redirections for an Item or Group)

Define a Delay

The Delay feature only applies to redirection actions that are to trigger automatically, or both manually and automatically (see Define the Trigger Type).

The Delay feature allows you to suspend an alarm redirection for a defined amount of time. It allows you to stop alarms from being redirected when the selected database item’s alarm state value is fleeting between alarm states.

You can also use the Delay feature to create a cascade of alarm redirections. For example, you can redirect an alarm to an engineer, and if the alarm is not acknowledged or cleared within the delay time, the alarm can be redirected to another User account or User Group. This can be repeated so that an alarm could be redirected several times. This is referred to as a cascade.

When a selected item has an alarm that is in the Trigger State (see Define the Trigger State), the Delay timer begins. The alarm is not redirected until the Delay time period expires. (If required, you can cancel and then later restart any alarm redirections for which the Delay period has not yet expired—see CancelRedirections and RestartRedirections Methods.)

If the alarm changes from the Trigger State to the Abort State (see Define the Abort State) within the Delay time, the alarm is not redirected.

To define the Delay, after you Define the Severity Range:

  1. Enter the Delay amount and its time units in the Delay field. Specify the time in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required delay.

Example:

1H 30M gives a delay of 1 hour 30 minutes.

To redirect an alarm as soon as it is raised, you should set the Delay to 0, and the Abort State to ‘Never’ (see Define the Abort State).

If you want to stop alarms being redirected when a value is fleeting into and out of an alarm limit, you should set the Delay to a short amount of time, such as 30S (30 seconds). You will need to set an appropriate Abort State, so that the alarm redirection is canceled if the alarm is cleared, acknowledged, or both during the Delay.

For cascaded alarm redirections, you should allocate enough time for someone to respond to the alarm. For example, you could allocate 2H (2 hours) for an engineer to repair an inoperative instrument. You could also set the Abort State so that the alarm redirection is canceled if the engineer acknowledges the alarm.

For an example of how the Delay and Abort State can be used to create a small cascade, see Use Alarm Redirection to Send Alarm Details in an E-Mail.


Alarm Redirection Guide - Define the Abort State (Configure Alarm Redirections for an Item or Group)

Define the Abort State

The Abort State only applies to redirection actions that are to trigger automatically, or both manually and automatically (see Define the Trigger Type).

The Abort State is the alarm state that causes the alarm redirection to be canceled. It is used in conjunction with the Delay time (see Define a Delay). If the alarm changes to the Abort State within the Delay time, the alarm redirection is canceled.

You can use the Abort State with the Delay to cancel an alarm redirection when:

  • An item is fleeting in and out of alarm
  • The alarm has been acknowledged and/or cleared within the Delay time.

Example:

A point is configured to have its Unacknowledged Uncleared alarms redirected after 10 minutes. The alarm redirection has an Abort State of Cleared.

An alarm is raised for the point. The 10 minute Delay time starts.

During the 10 minute Delay time, an engineer resolves the situation that caused the alarm, and so the alarm changes state to Unacknowledged Cleared. As the alarm changed to one of the Cleared alarm states within the 10 minute delay, the alarm redirection is canceled.

For further examples that indicate how you might use the Abort State, see Example Configuration.

To set the Abort State, after you Define the Severity Range, and, if required, Define a Delay:

  1. Use the Abort State combo box to select one of these Abort States:
  • Never—The alarm redirection is not canceled. The alarm is redirected when the Delay time expires. This option is not valid if a Delay of other than zero is used.
  • Unacknowledged Uncleared—The alarm redirection is canceled if the alarm changes state to Unacknowledged Uncleared.
  • Unacknowledged Cleared—The alarm redirection is canceled if the alarm changes state to Unacknowledged Cleared.
  • Acknowledged Uncleared—The alarm redirection is canceled if the alarm changes state to Acknowledged Uncleared.
  • Acknowledged Cleared—The alarm redirection is canceled if the alarm changes state to Acknowledged Cleared.
  • Acknowledged—The alarm redirection is canceled if the alarm changes state to Acknowledged Uncleared, or Acknowledged Cleared (that is, someone acknowledges the alarm).
  • Unacknowledged—The alarm redirection is canceled if the alarm changes state to Unacknowledged Uncleared, or Unacknowledged Cleared.
  • Cleared—The alarm redirection is canceled if the alarm changes state to Unacknowledged Cleared, or Acknowledged Cleared.
  • Uncleared—The alarm redirection is canceled if the alarm changes state to Unacknowledged Uncleared, or Acknowledged Uncleared.
  • Always—The alarm redirection is canceled if an alarm changes from the Trigger State to another state, within the Delay time.
  2. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have defined the Abort State of the alarm redirection action, action roster or alarm redirection calendar, you need to Define When the Redirection Action is Active.

Further Information

Circumstances in which Alarm Redirections do not Trigger.


Alarm Redirection Guide - Define When the Redirection Action is Active (Configure Alarm Redirections for an Item or Group)

Define When the Redirection Action is Active

Use the Active From and Active To fields to define the time period during which the alarm redirection is active—you need to specify this for each alarm redirection that needs configuring. If the alarm redirection is always active, set both fields to the default of 00:00.

Example:

If an alarm redirection only needs to occur when a control room is unmanned, and that control room is manned between 8.00am and 6.00pm, set the Active From field to 18:00 and the Active To field to 08:00.

To specify different hour and minute entries for the Active From or the Active To fields:

  1. Select the hours entry so that it is highlighted.
  2. Either:
  • Select the upper arrow of the spin box to increase the hour by one each time that you select it.

Example:

If the time is 00:00, select the upper arrow to change the time to 01:00, then 02:00, and so on.

  • Select the lower arrow of the spin box to decrease the hour by one, each time that you select it.

Example:

If the time is 00:00, select the lower arrow to change the time to 23:00, then 22:00, and so on.

  • Overtype the entry with the required time.
  3. Select the minutes entry so that it is highlighted.
  4. Either:
  • Select the upper arrow of the spin box to increase the minutes by one each time that you select it.

Example:

If the time is 00:00, select the upper arrow to change the time to 00:01, then 00:02, and so on.

  • Select the lower arrow of the spin box to decrease the minutes by one, each time that you select it.

Example:

If the time is 00:00, select the lower arrow to change the time to 00:59, then 00:58, and so on.

  • Overtype the entry with the required time.

Repeat the various alarm redirection configuration procedures until you have configured each of the alarm redirections that is required on the item or Group (see Configure Alarm Redirections for an Item or Group).


Alarm Redirection Guide - Circumstances in which Alarm Redirections do not Trigger

Circumstances in which Alarm Redirections do not Trigger

Alarm redirections can be triggered automatically, manually, or both (see Understand Alarm Redirection). However, ClearSCADA will not trigger alarm redirections on any:

  • Alarms that do not meet all of the redirection criteria (the criteria is configured on the Redirection tab of the relevant configuration Forms—see Configure Alarm Redirections for an Item or Group)
  • Alarms that are disabled (see Disable Alarms and Enable Alarms in the ClearSCADA Guide to Alarms)
  • Alarms that are suppressed (see Alarm Redirection and Suppressed Alarms)
  • Items or Groups for which the CancelRedirections method is used to abort alarm redirections (see CancelRedirections and RestartRedirections Methods)
  • Items or Groups on which specified redirection Action, Action Roster, and alarm redirection Calendar is inactive. (As with most database items, a redirection Action, Action Roster, and alarm redirection Calendar needs to be In Service in order to be active on the system.)
  • Lone server systems on which the server is shut down while alarm redirections are in progress. On lone server systems, any pending alarm redirections will be lost and the intended recipients will not be notified. (On multi-server systems, the alarm redirections will still be sent to the recipients, but from the Standby server that goes Main.)


Alarm Redirection Guide - Alarm Redirection and Suppressed Alarms (Circumstances in which Alarm Redirections do not Trigger)

Alarm Redirection and Suppressed Alarms

Alarm redirections do not trigger for any item for which alarms are suppressed. An alarm can be suppressed (omitted from any alarm displays) due to an alarm being raised on ‘parent’ item.

Should the parent alarm clear, any alarms that were suppressed because of that alarm become unsuppressed if they still exist. Once an alarm becomes unsuppressed, it appears on any alarm displays and ClearSCADA triggers any associated alarm redirections in the usual way.

Further Information

Alarm Suppression: see Alarm Suppression in the ClearSCADA Guide to Alarms.

Configure any Alarm Suppression Requirements in the ClearSCADA Guide to Core Configuration.


Alarm Redirection Guide - CancelRedirections and RestartRedirections Methods (Circumstances in which Alarm Redirections do not Trigger)

CancelRedirections and RestartRedirections Methods

ClearSCADA provides two methods, CancelRedirections and RestartRedirections, that can be used to cancel and restart any alarm redirection(s) that:

  • Apply to a particular database item, Group, Group Instance, or Redirection Group
  • Are triggered to occur after a Delay that is long enough to allow for the above methods to be executed.

CancelRedirections and RestartRedirections are methods rather than pick actions and therefore are not available from any context-sensitive menu. The methods are intended to be used, for example, in Script or Logic programs.

Example:

On a particular ClearSCADA system, the CancelRedirections method is used to cancel the alarm redirections that are associated with an ‘Operator Redirections’ Redirection Group whenever system maintenance is being performed.

During that time, any ‘genuine’ alarms (ones that are not generated as a result of system maintenance) are manually assigned to a particular user or workstation, using the SetAlarmResponsibleUser or SetAlarmResponsibleWorkstation methods.

Once system maintenance is complete, the RestartRedirections method is used to re-enable the alarm redirections.

If required, standard OPC wildcards can be used with the CancelRedirections and RestartRedirections methods, in order to cancel or restart redirection actions that are associated with multiple Redirection Groups.

Example:

The points on a particular area of the system are assigned redirections that are associated with Redirection Groups ‘Group 1’, ‘Group 2’, or ‘Group 3’.

The CancelRedirections method is configured to cancel alarm redirections that are associated with ‘Group ?’. The question mark (?) is the OPC wildcard that matches a single character. In this particular case, triggering the one CancelRedirections method results in ClearSCADA canceling alarm redirections that are associated with any of the three Redirection Groups ‘Group 1’, ‘Group 2’, and ‘Group 3’.

Further Information

For more information on methods, including the above methods and the ClearAlarmResponsibility method, see the database Schema. (Each of the alarm redirection methods is associated with the CAlarmObject, and the CGroup database tables.)

For an example that further demonstrates the use of the CancelRedirections and RestartRedirections methods, see Cancel the Redirection Actions that are Associated with a Particular Redirection Group.

Associate a Redirection Action, Roster, or Calendar with a Redirection Group.

ClearSCADA’s Script feature: see the ClearSCADA Guide to Scripting.

Logic programs: see the ClearSCADA Guide to Logic.

Supported OPC wildcards: see Filter Wildcards in the ClearSCADA Guide to Alarms.


Alarm Redirection Guide - Example Configuration

Example Configuration

This section includes a series of examples to show how database items might be configured to use the alarm redirection feature. Use the examples as an aid when configuring alarm redirections on your system.

The section includes these examples:

  • Use an E-Mail Action to Enable an Engineer to Acknowledge Alarms Remotely
  • Use Alarm Redirection to Send Alarm Details in an E-Mail
  • Send an E-Mail in Different Formats to Different Users
  • Use Alarm Redirection to Change the Alarm Priority
  • Use a Change Priority Action to Re-evaluate other Redirection Actions
  • Use a Set Responsibility Action to Restrict the Ability to Acknowledge Alarms
  • Use Alarm Redirection to Enable Operators to Manually Redirect Alarms
  • Allow an Operator to Enter a Comment when Manually Redirecting an Alarm
  • Cancel the Redirection Actions that are Associated with a Particular Redirection Group
  • Include a Trip Sequence in a Method Action’s Arguments
  • Use a User Roster to Redirect Alarms ‘Out of Hours’ to an On-Duty Engineer.

Further Information

Example of Action Roster Configuration.

Examples of Calendar Configuration.


Alarm Redirection Guide - Use an E-Mail Action to Enable an Engineer to Acknowledge Alarms Remotely (Example Configuration)

Use an E-Mail Action to Enable an Engineer to Acknowledge Alarms Remotely

This example demonstrates how an E-Mail Action might be used to enable an engineer to acknowledge alarms remotely, via e-mail.

Example:

On a particular ClearSCADA system, alarm redirection is used to enable engineers to acknowledge alarms via e-mail.

In order to be able to acknowledge alarms via e-mail:

  • The engineers need to have their User Accounts configured to allow them to access ClearSCADA via the web:
    In order for a user to acknowledge alarms via e-mail, their User Account has to allow Web access to ClearSCADA.

  • The engineers need to have the required permissions to allow them to acknowledge alarms on the database item(s) for which ClearSCADA is to trigger alarm redirections.
  • If the Area of Interest feature is enabled on the system, the engineers also need to have access to the Area of Interest that is associated with the redirected alarms.
    If the Area of Interest feature is used on the system, the engineers that are to acknowledge redirected alarms must have access to the Area of Interest to which the alarms are redirected.

An E-Mail Action is configured to redirect alarms to a group of engineers:

An E-Mail Action is configured to redirect alarms to a group of engineers, via e-mail.

The engineers’ User Accounts are each associated with the specified User Group:

The relevant engineers’ User Accounts are associated with the User Group to which ClearSCADA is to redirect alarms.

The E-Mail Action is configured as the redirection Action on the Forms of those database items for which alarms are to be redirected via e-mail:

The E-Mail Action is configured as the redirection Action on the relevant configuration Forms.

An engineer receives an Alarm Redirection e-mail.

To acknowledge the alarm remotely, the engineer replies to the e-mail. (If the system is configured to use an e-mail Acknowledgment Keyword, the engineer has to enter the keyword in the subject line of the reply.)

When the server receives the e-mail (and that e-mail includes the appropriate Acknowledgment Keyword, if required), ClearSCADA checks whether the alarm is still in existence. If the alarm still exists and has not already been acknowledged, ClearSCADA updates the alarm status to acknowledged by the user to which it sent the Alarm Redirection e-mail. The status change is logged with a comment indicating that the alarm was acknowledged by e-mail.

The comment is included in the Event Journal:

The fact that an alarm has been acknowledged by e-mail is indicated on various displays, including the Events List...

and can be viewed on the relevant Status Display:

...and the relevant database item’s Status Display.

Further Information

Configure User Accounts: see User Accounts in the ClearSCADA Guide to Security.

Configure User Groups: see User Groups in the ClearSCADA Guide to Security.

Assign Permissions: see Allocating Security Permissions in the ClearSCADA Guide to Security.

Areas of Interest: see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

Configure a Redirection Action.

Define the E-Mail Action Details.

Acknowledgment Keyword: see E-Mail Settings in the ClearSCADA Guide to Server Administration.

Configure Alarm Redirections for an Item or Group.

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

For more detailed examples of how to configure alarm redirection to send alarm details in an e-mail, see Use Alarm Redirection to Send Alarm Details in an E-Mail, and see Send an E-Mail in Different Formats to Different Users.


Alarm Redirection Guide - Use Alarm Redirection to Send Alarm Details in an E-Mail (Example Configuration)

Use Alarm Redirection to Send Alarm Details in an E-Mail

This example demonstrates how alarm redirections might be cascaded on a ClearSCADA system.

Two alarm redirections on a channel are configured to send alarm details in an e-mail. The first alarm redirection sends the e-mail to an engineer. If the engineer does not acknowledge the alarm within 10 minutes, a second alarm redirection is used to redirect the alarm to the engineer’s manager.

Example:

A channel is configured to provide a connection between the ClearSCADA server and a PLC. The channel is configured so that if communications via the channel is interrupted, a High priority alarm is raised. An Alarm Redirection is used to redirect the High priority alarm to an engineer. The first Alarm Redirection for the channel is configured as:

  • Trigger Type: Auto
  • Trigger State: Unacknowledged Uncleared
  • Action: ‘Communications Interruption’ E-mail (this is an e-mail to an engineer).
  • Low Severity: High
  • High Severity: High
  • Direction: Either (This setting is ignored by ClearSCADA, as the redirection is not for a point)
  • Delay: 0
  • Abort State: Never
  • Active From: 00:00
  • Active To: 00:00

With this configuration, as soon as an Unacknowledged Uncleared alarm with High priority is raised for the channel, ClearSCADA redirects the alarm by sending details of the alarm in the ‘Communications Interruption’ e-mail. The configuration of the ‘Communications Interruption’ E-mail Action determines which engineer receives the e-mail.

If the engineer does not acknowledge the alarm within 10 minutes, a second Alarm Redirection is used to redirect the alarm to the engineer’s manager. The second Alarm Redirection for the channel is configured as:

  • Trigger Type: Auto
  • Trigger State: Unacknowledged Uncleared
  • Action: ‘Communications Interruption - Unacknowledged’ E-mail (an e-mail to the engineer’s manager)
  • Low Severity: High
  • High Severity: High
  • Direction: Either (This setting is ignored by ClearSCADA, as the redirection is not for a point)
  • Delay: 10M
  • Abort State: Acknowledged
  • Active From: 00:00
  • Active To: 00:00

With this alarm redirection, when the channel has an Unacknowledged Uncleared alarm with High priority, a 10 minute timer begins. If the engineer does not acknowledge the alarm during the 10 minute delay, the alarm is redirected—the ‘Communications Interruption - Unacknowledged’ e-mail is sent to the engineer’s manager. If the engineer does acknowledge the alarm within the 10 minute delay, the alarm changes to an Acknowledged state, and the alarm redirection to the manager is canceled.


Alarm Redirection Guide - Send an E-Mail in Different Formats to Different Users (Example Configuration)

Send an E-Mail in Different Formats to Different Users

This example demonstrates how the format of an e-mail sent using an E-Mail Action varies when some recipients receive e-mails in HTML format, while others receive plain text e-mails.

Example:

A series of points are configured so that when any of those points has an unacknowledged alarm, details about the alarm are automatically forwarded in an e-mail.

Whenever an unacknowledged uncleared alarm occurs, ClearSCADA automatically forwards the alarm details using the redirection action ‘E-Mail Action B’.
When the ‘E-Mail Action B’ redirection action is triggered, ClearSCADA e-mails each of the users in the User Group ‘System Engineers’. ClearSCADA uses the engineers’ ‘E-Mail Contact 1’ e-mail addresses to send the e-mails.
Both the e-mail’s Subject and Message include trip sequences. The Message also includes HTML tags to control the format of the e-mail whenever it is sent to a user that can receive HTML format e-mails.

The User Account of each user that is in the User Group ‘System Engineers’ is configured to be associated with that User Group. (Each User Account can be associated with up to four User Groups.)

The User Groups with which an individual user is associated are specified on the General tab of their User Account Form.

Of the users that are in the User Group ‘System Engineers’, some use e-mail clients that are able to receive e-mails in HTML format. Their User Accounts are configured to allow HTML format e-mails:

The user ‘Sysman1’ can receive HTML format e-mails via the e-mail address Sysman1@mye-mailaddress.co.uk.

Other users in the ‘System Engineers’ User Group use e-mail clients that are only able to receive plain text e-mails. Their User Accounts are configured to receive such e-mails:

The user ‘Sysman2’ can only receive plain text e-mails via the e-mail address Sysman2@anothere-mailaddress.co.uk.

‘E-Mail Action B’ is configured to append an Alarm View hyperlink to each e-mail that is sent using that redirection action:

When the Alarm View check box is selected, ClearSCADA includes a hyperlink in a redirection e-mail whenever an Alarm View exists for the item that is in alarm.

By using an Account that has Web access and the relevant security permissions, a user will be able to select the e-mail’s Alarm View hyperlink and display the relevant Alarm View in a Web browser. They can then use the Alarm View to monitor the alarm situation and perform the relevant actions on the item(s) that are in alarm.

For a user to be able to display an Alarm View in a Web browser, their User Account has to have Web access.

When one of the points goes into alarm, ClearSCADA automatically forwards the alarm details using the redirection action ‘E-Mail Action B’:

The Event Journal (Events List) records when an alarm is generated...
...along with any alarm redirection activity that is triggered as a result of that alarm.

In the ‘System Engineers’ User Group, those users that can receive HTML format e-mails receive the alarm details in a fully formatted HTML e-mail.

The formatting takes into account any HTML tags and character entities that are included in ‘E-Mail Action B’s Message field:

In an HTML format e-mail, the HTML tags that are included in the E-Mail Action’s Message area control the format of any HTML e-mails that are sent using that redirection action. (In this particular example, HTML tags control the paragraph and line breaks, and define which text appears in a bold font or italics.)

Those users that can only receive plain text e-mails receive the alarm details in that format (any formatting specified using HTML tags is ignored):

Blank lines in an E-Mail Action’s Message area are used to separate the content that is displayed in plain text e-mails.

With both e-mail formats, when ClearSCADA sends the e-mail it:

  • Replaces any trip sequences in the E-Mail Action’s Subject and Message fields with the relevant alarm details
  • Appends an Alarm View hyperlink to the end of the e-mail. The recipient can select the hyperlink to display the Alarm View in a Web browser, then use the view to ascertain the alarm situation and perform any necessary actions.

Further Information

Configure User Accounts: see User Accounts in the ClearSCADA Guide to Security.

Configure User Groups: see User Groups in the ClearSCADA Guide to Security.

Configure a Redirection Action.

Define the E-Mail Action Details.

Configure Alarm Redirections for an Item or Group.

Alarm and Alarm Redirection Event Messages: see Alarm-Related Entries in the Events List in the ClearSCADA Guide to Alarms.


Alarm Redirection Guide - Use Alarm Redirection to Change the Alarm Priority (Example Configuration)

Use Alarm Redirection to Change the Alarm Priority

This example demonstrates how an alarm redirection might be configured to raise the priority of an alarm, if that alarm remains in an Unacknowledged Uncleared state for more than five minutes.

Example:

A sensor monitors the water level in a river. An analog point represents the sensor in the ClearSCADA database. The point is configured to trigger a Medium priority alarm should the river level rise above a particular amount.

An Alarm Redirection is associated with the point—the Alarm Redirection raises the priority of the alarm to High should the alarm remain in an Unacknowledged Uncleared state for more than five minutes.

The Alarm Redirection for the point has this configuration:

  • Trigger Type: Auto
  • Trigger State: Unacknowledged Uncleared
  • Action: 'Raise to High' (a Change Priority Redirection Action)
  • Low Severity: Medium
  • High Severity: Medium
  • Direction: Away From Normal
  • Delay: 5M
  • Abort State: Always
  • Active From: 00:00
  • Active To: 00:00

The 'Raise to High' Redirection Action is configured to set the priority to High should an alarm be redirected.

An Unacknowledged Uncleared alarm with a Medium priority is raised for the point.

If the point’s value is traveling toward the Normal State (indicating that the river level is dropping), the alarm is not redirected.

However, if the point’s value is traveling away from the Normal State, as soon as the alarm is raised, a five-minute timer begins.

If the alarm clears or is acknowledged within five minutes, the alarm redirection is canceled.

If the alarm does not change state within the five-minute delay, its priority is raised from Medium to High.

Further Information

Configure Alarm Redirections for an Item or Group.

Define the Change Priority Action Details.

For a further example that demonstrates how a Change Priority Action might be used, see Use a Change Priority Action to Re-evaluate other Redirection Actions.


Alarm Redirection Guide - Use a Change Priority Action to Re-evaluate other Redirection Actions (Example Configuration)

Use a Change Priority Action to Re-evaluate other Redirection Actions

This example demonstrates how a Change Priority Action might be used to re-evaluate each of the redirection actions that apply to, and are configured to trigger automatically for, a particular alarm.

Example:

A Change Priority Action is to be used to re-evaluate each of the automatic redirection actions that apply to an alarm. To enable this, the Reevaluate automatic redirections on alarm check box is selected on the Change Priority Action’s Form:

The Reevaluate automatic redirections in alarm check box is selected, as the Change Priority Action is being used to re-evaluate any automatic redirection actions for the alarm.
The Change Priority Action is configured to increase the priority (severity) of an alarm by one severity level.

The Change Priority Action is specified as one of the redirection actions on the Redirection tab of a database item’s Form:

A Medium severity alarm is raised for the database item.

After 2 minutes, the alarm is still in force and has not been acknowledged—ClearSCADA redirects the alarm via E-Mail Action 1 (the first redirection action specified on the Redirection tab).

After a further 3 minutes (a total of 5 minutes since the alarm was raised), the alarm has not cleared—ClearSCADA redirects the alarm as per the Change Priority Action. The action raises the alarm’s severity by one level, to High. It also causes ClearSCADA to re-evaluate each of the automatic redirections that are configured for the alarm. For those redirections for which the Trigger Type is set to Auto or Both:

  • ClearSCADA cancels any redirections that do not meet the redirection criteria.
  • For those redirections that do meet the redirection criteria, ClearSCADA redirects the alarm as per the settings on the Redirection tab.

For this particular database item, this results in:

  • E-Mail Action 1 being canceled (as the alarm’s High severity is outside of this redirection’s severity range).
  • Change Priority Action 1 being ignored this time round (as the alarm’s High severity is also outside of this redirection’s severity range).
  • Method Action 2 being triggered two minutes after the alarm’s priority is raised to High, if the alarm is not acknowledged within this redirection’s 2-minute Delay time.
  • The On-Call Pager action being triggered eight minutes later (a total of 10 minutes since the alarm’s severity was raised to High), if the alarm does not clear during this redirection’s 10-minute Delay time.

Pager Action 2 is ignored, as its Trigger Type is Manual.

Further Information

Define the Change Priority Action Details.

Configure Alarm Redirections for an Item or Group.

For a further example that demonstrates how a Change Priority Action might be used, see Use Alarm Redirection to Change the Alarm Priority.


Alarm Redirection Guide - Use a Set Responsibility Action to Restrict the Ability to Acknowledge Alarms (Example Configuration)

Use a Set Responsibility Action to Restrict the Ability to Acknowledge Alarms

This example demonstrates how Set Responsibility Actions might be used to restrict the ability to acknowledge alarms, and clear that restriction under specific circumstances.

Example:

A point on a particular ClearSCADA system is configured to use alarm redirection, such that:

  • The ability to acknowledge an alarm is restricted while the alarm condition exists, to those users that are in the User Group ‘Duty Engineers’
  • The above restriction is removed if the alarm condition clears, so that any user with the appropriate permissions and access to the alarm can acknowledge the cleared alarm.

Two Set Responsibility Actions are configured—one for each of the above requirements:

A Set Responsibility Action entitled ‘User Group’ is used to restrict the ability to acknowledge alarms to those users that are in a ‘Duty Engineers’ User Group.
Another Set Responsibility Action (entitled ‘Clear’) is used to clear any existing restrictions, so that any user with the appropriate permissions can acknowledge alarms.

The required alarm restrictions are specified on the Redirection tab on the point’s configuration Form:

The ‘User Group’ Set Responsibility Action is used to restrict the ability to acknowledge Unacknowledged Uncleared alarms...
...whereas the ‘Clear’ Set Responsibility Action is used to remove the restriction for any Cleared alarms (alarms for which the alarm condition no longer exists).

The configuration is saved.

When the point goes into alarm, most users can see the alarm, but cannot acknowledge it:

Users that are not in the ‘Duty Engineers’ User Group cannot acknowledge any alarms that are raised for the point, while the alarm condition exists.

(On a system that is configured to use a different background color to indicate whether an alarm can be acknowledged, any unacknowledged alarms that users do have the ability to acknowledge will have a different background color on alarm displays. For more information, see The Background Color used on Alarms Lists and the Alarm Banner in the ClearSCADA Guide to Alarms.)

The users that are allocated responsibility for acknowledging the alarm can be ascertained by looking at the Events List:

Entries logged in the Events List indicate that the alarm has been redirected, and list the User Group that is assigned responsibility for acknowledging the alarm. (In this case, any users that are in the ‘Duty Engineers’ User Group.)

Or by viewing the point’s Status display while the point remains in alarm:

The View Status pick action can be used to view the point’s Status display and ascertain which users have responsibility for acknowledging the alarm.

Should the alarm condition clear before a Duty Engineer acknowledges the alarm, the restriction is removed and any user that is allocated the Acknowledge Alarms security permission for the point can acknowledge the cleared alarm:

If the alarm clears before a Duty Engineer has acknowledged it, the point’s second redirection action comes into effect. This clears the previous restriction, enabling any user with the Acknowledge Alarms permission for the point, to acknowledge the cleared alarm.

Further Information

Configure a Redirection Action.

Define the Set Responsibility Action Details.

Configure Alarm Redirections for an Item or Group.


Alarm Redirection Guide - Use Alarm Redirection to Enable Operators to Manually Redirect Alarms (Example Configuration)

Use Alarm Redirection to Enable Operators to Manually Redirect Alarms

This example demonstrates how you might configure a database item to allow operators to redirect alarms if they consider it necessary.

Example:

Operators on a ClearSCADA system are to be able to decide whether to redirect any alarms that occur on the system. To enable them to make informed decisions as to which redirection action, if any, to take, suitable Manual Redirection Descriptions are configured for each redirection Action.

A suitable description is entered in the Manual Redirection Description field on each Action Form (this diagram shows the Form for an E-Mail Action).

On the Redirection tab of the configuration Forms of those database items that are to optionally have their alarms redirected, the redirection Action(s) are configured to be triggered manually:

The Trigger Type is set to Manual, to allow operators to decide whether to redirect any alarms.
The Trigger State fields are set to ‘Always’ to allow the operators to trigger the redirection actions manually, regardless of alarm state.
The required redirection Actions are specified in the Action fields. (Action fields can also be used to redirect alarms on an Action Roster, or Calendar basis.) (The Direction, Delay, and Abort State fields (not shown above) are ‘grayed out’, for manually triggered redirection actions.)

Whenever ClearSCADA generates an alarm for the item, the operator can decide whether to redirect the alarm.

To manually redirect the alarm, the operator right-clicks on the alarm in the Alarm Banner (or on the Alarms List) to display a context-sensitive menu. At the bottom of the menu is the list of Manual Redirection Descriptions for each of the redirection Actions that are configured for the item. The operator selects the appropriate manual redirection option, to trigger ClearSCADA to redirect the alarm accordingly.

...the Manual Redirection Description for each associated redirection Action (or Action Roster or alarm redirection Calendar) is displayed in a list at the bottom of the context-sensitive menu. The operator selects the required redirection option, and ClearSCADA redirects the alarm accordingly.
When an operator right-clicks on an alarm for that database item in the Alarm Banner...

NOTE: If no Manual Redirection Description is configured for an Action, Action Roster, or Calendar that is set to trigger manually, the entry in the manual redirection destinations list will default to Redirect to <Action Name>, where <Action Name> is the full name of the alarm redirection Action, Action Roster, or Calendar.

Further Information

Configure a Redirection Action.

Configure Alarm Redirections for an Item or Group.

Define the Trigger Type.

Select the Action to be Taken.


Alarm Redirection Guide - Allow an Operator to Enter a Comment when Manually Redirecting an Alarm (Example Configuration)

Allow an Operator to Enter a Comment when Manually Redirecting an Alarm

This example demonstrates how to enable users to enter a comment when manually redirecting an alarm. It also demonstrates how an operator might use the Comment feature to provide further information on the alarm that is being manually redirected.

The Comment feature can be enabled to allow users to enter comments whenever alarms are manually redirected on a per redirection Action, Action Roster, or Calendar basis.

Example:

Operators on a ClearSCADA system are to be able to decide whether to redirect any alarms that occur on the system. To enable them to make informed decisions as to which redirection action, if any, to take, suitable Manual Redirection Descriptions are configured for each redirection Action.

Additionally, operators are required to enter a comment providing further details about each alarm that they manually redirect. To enable the operators to enter such a comment, the Manual Redirections Require Comment check box is selected on each redirection Action’s Action tab.

A description is entered in the Manual Redirection Description field, to inform the operator as to the type of redirection action they can select.
The Manual Redirections Require Comment check box is selected on each Action Form, to enable users to enter a comment whenever they manually redirect an alarm.

The operator’s comment is to be included in the E-Mail Message that is used to manually redirect the alarms. Therefore, the %K trip character is included in the Message field on that Action Form’s E-Mail Action tab. (The %K trip character is automatically replaced by the operator’s comment when the e-mail is sent.)

The %K trip character is used to include the operator’s comment in the E-Mail that will be sent whenever an alarm is manually redirected via this redirection Action.

On the Redirection tab of the configuration Forms of those database items that are to optionally have their alarms redirected, the redirection Action(s) are configured to be triggered manually. (For an example that demonstrates this, see Use Alarm Redirection to Enable Operators to Manually Redirect Alarms.)

Whenever ClearSCADA generates an alarm for the item, the operator can decide whether to redirect the alarm.

To manually redirect the alarm, the operator right-clicks on the alarm in the Alarms List (or on the Alarm Banner). A context sensitive menu is displayed. The manual redirection options are included on the menu—the operator selects the appropriate redirection option.

The operator selects the appropriate manual redirection option.

A Redirection Comment window is displayed, into which the operator enters a suitable comment:

(On some systems, a set of ‘standard’ Alarm Acknowledgment and Manual Redirection Comments may be configured using the Alarms section of the ClearSCADA Server Configuration Tool. If such a set of comments exists, a combo box is displayed in place of the above field. The user can either choose a ‘standard’ comment from the list, or enter their own comment.)

The operator selects the OK button to close the window and redirect the alarm.

The comment is included as part of the entry’s message in the Events List:

The entry in the Events List shows that the alarm was manually redirected....
....and includes the operator’s comment.

The E-Mail message that is sent as a result of the manual redirection also includes the operator’s comment (the comment replaces the %K trip character is included on the E-Mail Action tab’s Message field):

Further Information

Configure a Redirection Action.

Trip Sequences Supported by Redirection Actions.

Configure Alarm Redirections for an Item or Group.

Configure a ‘Standard’ Alarm Redirection Comment: see Define Standard Alarm Acknowledgment Comments in the ClearSCADA Guide to Server Administration.

For an example that further demonstrates how you might configure an E-Mail Action’s message content, see Send an E-Mail in Different Formats to Different Users.


Alarm Redirection Guide - Cancel the Redirection Actions that are Associated with a Particular Redirection Group (Example Configuration)

Cancel the Redirection Actions that are Associated with a Particular Redirection Group

This example demonstrates how:

  • The CancelRedirections method might be used to temporarily cancel a series of alarm redirections
  • The RestartRedirections method might be used to reinstate those redirections, once the cancellation is no longer required.

Example:

Alarms on a particular ClearSCADA system are redirected initially to the operators manning the workstations in various Area Control rooms. The redirection Actions are each associated with an ‘Operators’ Redirection Group.

If the redirected alarms are not acknowledged, or do not clear, within 20 minutes, they are redirected again, to the engineers manning the support center. The support redirection Actions are each associated with a ‘Support’ Redirection Group.

The Redirection Group field on each redirection Action Form is used to specify whether a redirection Action is associated with the ‘Operators’ or ‘Support’ Redirection Group.

‘Custom’ pick actions are added to the system, using the User Methods tab on the relevant configuration Forms. These are used to trigger the CancelRedirections and RestartRedirections methods, respectively—each method is configured to cancel or restart every pending redirection in the ‘Operators’ Redirection Group in a particular area of the system.

The Group or Group Instance for which redirections are to be canceled or restarted.
The Redirection Group for which redirection Actions are to be canceled or restarted.
The custom pick action name that indicates the type of action that will be triggered.

A Mimic is configured to allow high-level engineers to access the ‘custom’ pick actions from a single display.

(As an alternative to using User Methods, Mimic scripts could be used to enable high-level engineers to trigger the CancelRedirections and RestartRedirections methods.)

If a major problem occurs, a high-level engineer triggers the CancelRedirections method in the affected area(s). This cancels every pending redirection that would otherwise redirect alarms to the Area Control room operators (any redirection Actions that are associated with the ‘Operators’ Redirection Group). Events are logged in the Event Journal indicating which alarm redirections have been canceled. The cancellation helps to prevent the operators from receiving numerous alarms, rather than just the crucial ones.

While the redirections are canceled, the crucial alarms are assigned to specific users, or manually redirected to the support center staff (as only the redirection actions associated with the ‘Operators’ Redirection Group are canceled—any ‘Support’ redirection Actions are unaffected by the cancellation).

Once the cause of the problem has been rectified, the RestartRedirections method is triggered in each affected area, to re-enable the ‘Operators’ alarm redirections in those areas.

Events are added to the Event Journal indicating which alarm redirections have been restarted.

The restarted redirections are deemed to be newly generated redirections.

For those alarms for which the redirection criteria still applies, the Delay timer begins as soon as the redirections are restarted. As with any redirection, once the Delay time expires, ClearSCADA redirects those alarms for which the redirection criteria still applies.

Further Information

Configure a Redirection Action.

User Methods: see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration.

Mimics: see the ClearSCADA Guide to Mimics.

Mimic Scripts: see the ClearSCADA Guide to Scripting.

The types of event that are logged when alarm redirections are canceled or restarted: see Alarm-Related Entries in the Events List in the ClearSCADA Guide to Alarms.


Alarm Redirection Guide - Include a Trip Sequence in a Method Action's Arguments (Example Configuration)

Include a Trip Sequence in a Method Action’s Arguments

You can use Method Actions to automatically perform actions on items in the database in response to alarm situations (see Perform Action/Invoke Method Redirection).

If the method that is specified for a Method Action includes string argument(s), you can optionally include any of the Trip Sequences Supported by Redirection Actions in those arguments. This example demonstrates how a trip sequence might be used in such an argument. (Trip sequences only apply to Method Actions—methods that are triggered by alarm redirection. Trip sequences do not apply to methods that are not directly associated with alarm redirection (such as stand-alone Method Calls, or User Methods).)

Example:

A Method Action on a particular ClearSCADA system is used to trigger the ‘Acknowledge with Comment’ method on a digital point. The ‘Acknowledge with Comment’ method has a single string argument. The trip code %O is used to specify the scanner with which the point is associated, and to include that information in the comment that is logged when the point’s alarm is acknowledged.

Browse button used to display the Edit Method window.
The method (action) that ClearSCADA is to perform on the Method Object.
The ‘Acknowledge with Comment’ method has a single string argument.
As with any string, the argument’s content is enclosed in single quotation marks. The %O trip character is used to reference the scanner with which the Method Object (a digital point) is associated. This trip sequence will be replaced with the scanner name when any of the point’s alarms are acknowledged using this Method Action.
The database item on which this Method Action is to act.

The Method Action is referenced on the Redirection tab of each database item that is to trigger this particular redirection action.

Whenever the Method Action is triggered, any alarms that are in existence for the Method Object are acknowledged. The record that is logged in the Event Journal in relation to the alarm acknowledgment is appended with the Comment that is defined by the Comment argument. Within the comment itself, the %OScannerId.Name% trip sequence is replaced by the scanner’s name.

The Comment is include in the Message column for the event that is logged as a result of the alarm being acknowledged.
The User and Category columns indicate that the event is an Action that was triggered by a Method Call (in this particular case, a Method Action).

Further Information

Configure a Redirection Action.

Define the Method Action Details.

Configure Alarm Redirections for an Item or Group.


Alarm Redirection Guide - Use a User Roster to Redirect Alarms 'Out of Hours' to an On-Duty Engineer (Example Configuration)

Use a User Roster to Redirect Alarms ‘Out of Hours’ to an On-Duty Engineer

This example demonstrates how a User Roster might be used to redirect alarms ‘out of hours’ to whichever engineer is ‘on duty’ at the time.

Example:

A company employs three on-call engineers to respond to any alarms that are raised ‘out of hours’. The on-call engineers work on a roster basis, with only one of the engineers being on-call at a time.

Alarms that are raised at the control room during working hours are redirected out of hours to the pager of whichever on-call engineer is on duty. The engineer then assesses the situation and takes the appropriate action.

A User Roster is used to redirect alarms ‘out of hours’. The user accounts of the three on-call engineers are referenced from the User Roster:

The three on-call engineers are associated with a User Roster by specifying their details on the Roster’s User Roster tab.

The User Roster is associated with a Pager Action (named ‘On-Call Pager’).

The message that the Pager Action is to send to the pager of the on-call engineer is specified in the Pager Message field on the Pager Action Form:

Alarm Associated with %ASource%, on %OOutstationId.Name%

The message includes trip codes that are replaced by specific alarm content whenever ClearSCADA sends a pager message using that Pager Action:

On this particular system, the account to which the pager message is sent is Pager Contact 2.
On the User Form for each on-call engineer, the engineer’s Pager ID and Pager Service details are specified in the corresponding Pager Contact 2 fields.
Whenever ClearSCADA redirects an alarm using the Pager Action, the server uses the Pager Contact 2 settings to contact whichever engineer on the User Roster is specified as ‘On Duty’ at that time.
The Pager Message on the Pager Action Form include trip codes.

On the Form for each Group of database items for which alarms are to be redirected, the Action field on the Redirection tab is used to specify the On-Call Pager Action as the required redirection action:

The Pager Action ‘On-Call Pager’ is specified in the Action field on the Redirection tab of the Form for each Group of database items for which alarms are to be redirected ‘out of hours’...

As the on-call engineers are only on duty ‘out of hours’ (in this case, between 18:00hrs and 08:00hrs, when the control room is unmanned), this time period is specified using the Active From and Active To fields on the Form for each Group of database items:

The Active From and Active To fields on the Redirection tab of the Group Form are used to indicate when the on-call engineers are on duty.

At the end of each working day, the Control Room Manager selects the User Roster’s Set Duty User pick action to specify which of the on-call engineers is on duty that night.

The Control Room Manager uses the Set Duty User pick action to specify which of the engineers on the User Roster is on duty each night.

If any alarms are raised overnight, ClearSCADA redirects those alarms to the Duty User’s pager.

Further Information

Configure a User Roster.

Configure the User Roster Properties.

Define the Pager Action Details.

Trip Sequences Supported by Redirection Actions.

Specify a user’s pager contact details: see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security.

Configure Alarm Redirections for an Item or Group.

Specify the Duty User.

NOTE: If your ClearSCADA system is running the Pager driver and is configured to send and receive SMS messages, ClearSCADA can be configured to enable users to trigger actions remotely via SMS. So, for instance, on receipt of an SMS alarm message generated using a Pager redirection action, a user might opt to trigger an action remotely to correct the cause of the alarm. For more information, see the ClearSCADA Guide to the Pager Driver.


Lists Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Lists Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Lists Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Lists Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Lists Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Lists Guide - Document Scope (About the Guide)

Document Scope

This guide explains the types of List that are provided with ClearSCADA, and includes information about:

  • Accessing and using the features associated with those Lists
  • Setting up the preferences for the Lists.

The guide also explains how to create ‘custom’ Lists.

For more information, see Welcome to the ClearSCADA Guide to Lists.

NOTE: For information on Alarms Lists, see the ClearSCADA Guide to Alarms.


Lists Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for:

  • Operators and engineers that need to use Lists
  • System administrators that need to set up the Lists’ preferences or create ‘custom’ Lists.


Lists Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Lists Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Alarms

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Logic

ClearSCADA Guide to Mimics

ClearSCADA Guide to Trends

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Security

ClearSCADA Guide to the Database.


Lists Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Lists Guide - Welcome to the ClearSCADA Guide to Lists

Welcome to the ClearSCADA Guide to Lists

Welcome to the ClearSCADA Guide to Lists. This guide provides reference information about the various aspects of List operation and configuration.

ClearSCADA is capable of displaying a wide range of information in List form, for example:

  • Alarms (see Alarms Lists in the ClearSCADA Guide to Alarms)
  • Events (see Events Lists)
  • Database Items (see Queries Lists)
  • Historic Values (see Historic Lists)
  • Configuration Changes (see Configuration Changes Auditing in the ClearSCADA Guide to Core Configuration).

For information on working with Lists, see the following sections in addition to the references above:

  • Understand List Displays
  • Display and Use Lists.

System administrators or high-level engineers that are setting up the system should see the following section:

  • Set up the List Preferences.

In addition to the above, be aware that engineers with the relevant permissions can also optionally configure Custom Lists. Like a standard Queries List, a Custom List uses an SQL query to determine the information that is included in the List. Custom Lists are useful if you want to display information that is not available in any of the standard Queries Lists, or if you regularly want to display a List that is filtered and/or sorted differently.

If you need to use ClearSCADA to query a Third Party ODBC database such as an SQL Server database, please refer to Querying Third Party ODBC Databases.


Lists Guide - Understand List Displays (Welcome to the ClearSCADA Guide to Lists)

Understand List Displays

Each List contains rows and columns of data. Each row represents an individual record—a single database item, event, historic record, or alarm—depending on the type of List. Each column represents the data that is associated with a particular record—for example, the Name column displays a record’s Name value, and the Type column displays a record’s Type value (the type of database item to which the record relates).

Columns display the data associated with a particular record.
Each row represents an individual record (a single item, event, or alarm depending on the type of List).

For information on the data that a particular column contains, position the cursor over the column heading. This displays a ToolTip that describes that column’s content.

With standard (as opposed to custom) Lists, you can access a pick action menu for each item by right-clicking on the row for the relevant item. The pick action menu provides access to display options and/or controls, depending on the configuration of the item and your user permissions. You can use these options to access other displays, and perform actions on the system in the same way as you would use context sensitive menus on other ViewX and WebX displays. Pick action menus are also available for items in custom Lists, providing that the Id or RecordId fields have been included in the SQL Query for the List (see Custom Lists).

NOTE: The values in Alarms Lists continuously update in real time. The rows in Queries Lists also update automatically. However, you may need to Refresh the Data on a List other than an Alarms List, to ensure that the List continues to include all of the relevant entries while it remains on display.

Further Information

Display and Use Lists.

Understand Alarms Lists: see Understand the Information that is Displayed on an Alarms List or Alarm Banner in the ClearSCADA Guide to Alarms.

Understand Events Lists.

Understand Historic Lists.


Lists Guide - Set up the List Preferences (Welcome to the ClearSCADA Guide to Lists)

Set up the List Preferences

ClearSCADA is supplied with a set of defaults, which determine the way in which the system functions, and the way in which data is processed and displayed. This includes various settings that affect Lists. If required, many of these settings can be changed from the defaults.

This section is for system administrators and high-level engineers who need to change any of the List defaults on either a system-wide, client-specific, or user-specific basis.

Ideally, if any of the options are to differ from the defaults, a system administrator should specify:

  • System-wide preferences when ClearSCADA is first installed (including any system-wide settings for the Guest User)
  • Client-specific preferences on existing clients (workstations) when ClearSCADA is first installed, and on new clients as they are added to the system (including any client-specific settings for the Guest User)
  • User-specific preferences for each individual User Account at the time that the account is added to the system.

In addition to the above, a system administrator also needs to allocate the required Security Permissions to each User Account, User Group, and item in the database. This includes the permissions that, for example, determine whether alarms can be acknowledged, removed, and/or disabled, and whether certain actions can be performed on an item in the database. For further information, see Allocating Security Permissions in the ClearSCADA Guide to Security.

System administrators need only change any of the List settings if they are required to differ from the default settings that are supplied with the ClearSCADA system. The following sections in this guide list the options you might want to consider should you need to:

  • Set up Events List Preferences
  • Set up Queries List Preferences
  • Set up Historic List Preferences
  • Specify the Preferred List Options on a ViewX Client.

In addition to the above, be aware that you can optionally configure Custom Lists. Like a standard Queries List, a Custom List uses an SQL query to determine the information that is included in the List. Custom Lists are useful if you want to display information that is not available in any of the standard Queries Lists, or if you regularly want to display a List that is filtered and/or sorted differently.

Further Information

Set up the Alarms, Alarms Lists, and Alarm Banner Preferences in the ClearSCADA Guide to Alarms.

Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client in the ClearSCADA Guide to Alarms.

Configure Additional Alarm Columns in the ClearSCADA Guide to Alarms.

Define the Property Change History List Preferences (see Settings for Configuration Changes Auditing in the ClearSCADA Guide to Server Administration).


Lists Guide - Display and Use Lists

Display and Use Lists

In ClearSCADA, you can display a wide variety of information in List form. Lists present the information for each entry as a row of text (see Understand List Displays). The colors in which the entries are displayed further indicate their state or status (see The Color of Entries in a List other than the Alarms List).

This section is for operators and other users who want to display these Lists and restrict the information that the Lists display, to just those entries that are of interest.

This section explains those aspects of List operation that are common to many types of List. The information in this section explains how to:

  • Display a List
  • Display and Use a List’s Context Sensitive Menu
  • Sort a List
  • Filter a List.

For Lists such as Events Lists, Queries Lists, and Historic Lists, it also explains how to:

  • Quick Filter a List other than an Alarms List
  • Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List
  • Reset the Filters and Sort Order on a List other than an Alarms List
  • Refresh the Data on a List other than an Alarms List.

Some aspects of List operation vary, depending on the type of List. Such activities are documented in the relevant List-specific sections within this guide. References are included from within this section if applicable.

Further Information

Alarms Lists (see Alarms Lists in the ClearSCADA Guide to Alarms).

Events Lists.

Queries Lists.

Historic Lists.

Property Change History Lists (see Display a List of Property Changes in the ClearSCADA Guide to Core Configuration).


Lists Guide - Display a List (Display and Use Lists)

Display a List

There are various ways of displaying a List. This section explains how to:

  • Display a List from the Database Bar
  • Display a List from another Display.

You can also:

  • Display a Client-Wide Alarms List in the ClearSCADA Guide to Alarms
  • Display a General List of Events
  • Display a Queries List from the Queries Bar
  • Display the Data on a Data Grid or Data Table in List Format.

For further information on displaying Lists on a WebX client:

  • see View and Action Alarms on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients
  • see View and Action Events on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients
  • see View and Action Lists on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.

Many Lists display instantaneously. For those Lists for which a large number of records need to be retrieved, ClearSCADA provides a progress report while that data retrieval is ongoing. This report is updated in real time and indicates the number of records that have been retrieved so far. The report is replaced by the List entries as soon as the relevant records have been retrieved. You can continue to perform other activities in ClearSCADA while such data retrieval is ongoing. To cancel a request to display a List containing a large number of records, close the progress report window.


Lists Guide - Display a List from the Database Bar (Display and Use Lists)

Display a List from the Database Bar

You can display various types of List from the Database Bar, including:

  • Various pre-filtered Queries Lists—For example, you can display a list of the points that are associated with a particular outstation or scanner, by following the procedure below and selecting the Display Points option in step 4.
  • The Alarms List—You can display an Alarms List that either:
  • Includes alarms for each of the ClearSCADA systems to which a ViewX client is connected (or the single ClearSCADA system to which a WebX Client is connected)

Or:

  • Includes only those alarms that are associated with a specific system, Group, Group Instance, or database item.

To display an Alarms List, follow the steps below, then select the Display Alarms option in step 4.

  • The Events List—You can display the Events List for a single ClearSCADA system, or you can display a pre-filtered Events List, which shows only those events that are associated with a specific Group, Group Instance, Group Template, or database item. To display an Events List, follow the steps below, then select the Display Events option in step 4.
  • A Historic List—You can display a Historic List for any point or master station accumulator that has Historic enabled. To display a Historic List, follow the steps below, then select the Display Historic List option in step 4.
  • If your system includes Data Grids or Data Tables, you can display the data for either of these items in List format. To display such a List, follow the steps below to locate the relevant Data Grid or Data Table. At step 4, select the Display option. You can Sort, Filter, and Quick Filter either List in the same way as other Queries Lists.

To display a List from the Database Bar:

  1. Display the Database Bar (see Explorer Bars used in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Expand the Database hierarchy if required.
  3. Right-click on the item for which you want to display a List. (For example, the outstation for which you want to display a List of points, alarms, or events.)
    A context sensitive menu is displayed.
  4. Select the relevant menu option. (For example, the Display Points option.)
    The specified List is displayed. The List is pre-filtered so that it only includes the relevant records. (For instance, it only includes the points that are associated with the selected outstation.)

Examples:

To display a List of the database items that are in a particular Group, or Group Instance, select the Display Objects menu option.

Right-click on a Group in the Database Bar and select the Display Objects option...
... to display the Queries List of the items in that Group.

To display a List of the outstations that are associated with a particular Outstation Set, select the Display Outstations menu option.

To display a List of the Instances that reference a particular Group Template, select the Display Instances menu option.

You can also display a pre-filtered List by selecting the relevant menu option on another List, or on a Mimic (see Display a List from another Display).


Lists Guide - Display a List from another Display (Display and Use Lists)

Display a List from another Display

You can Display a List from the Database Bar, or you can display a List from various other displays, including:

  • Another related List.

Example:

By right-clicking on a scanner on the Point Sources Queries List and selecting the Display Points menu option, an operator is able to display a List of the points that are associated with that scanner.

The Point Sources Queries List (available from the Queries Bar) display a list of the scanners and slave outstations on the system.
Right-click on a scanner to display a pop-up menu...
...and select the Display Points option...
...to display a list of the points associated with that scanner.

  • Any Mimic that is configured to enable access to the required type of List.

If an item on a Mimic is configured to display an Object Menu, by default that Object Menu includes a link to any relevant List (for more information, see Pick Action Animations for Mimic Objects in the ClearSCADA Guide to Mimics.)

Example:

The outstation entry on a Mimic is configured to display an Object Menu. An operator clicks on the outstation name to display a menu, then selects the Display Points option to display a List of the points associated that outstation.

On a Mimic, select an object or text string that is configured to display an Object menu...
...then select the relevant menu option (in this case, Display Points)...
...to display the Queries List of items that are associated with the selected object.

If a Mimic includes an embedded ‘custom’ List, display that Mimic to view the List.


Lists Guide - Display and Use a List's Context Sensitive Menu (Display and Use Lists)

Display and Use a List’s Context Sensitive Menu

You can perform a variety of activities on a List or on any of the entries on that List. Right-click on an entry on a List to display a context sensitive menu. The options on the menu vary, depending on your security permissions, the entry that you have selected, and the type of List.

In each case, the context sensitive menu’s options enable you to perform activities specific to the entry you have selected, or in relation to the List itself.

The context sensitive menu on Events Lists might include these options:

Event-specific option.
Generic Events List options.

For information on any of the above menu options, see Events Lists.

The context sensitive menu options on Historic Lists are similar to those on Events Lists (see Work with a Historic List).

The context sensitive menu for entries on Queries Lists varies, depending on the type of item, its state and configuration:

Generic Queries List options.
Object menu options.

For information on Object menu options, see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on the generic Queries List options, see Display and Use Lists.

For information on the type of context sensitive menu options that are available on Alarms Lists, see Alarms Lists in the ClearSCADA Guide to Alarms.


Lists Guide - Sort a List (Display and Use Lists)

Sort a List

You can sort Lists to change the order in which their entries are displayed and grouped to make their contents easier to view and interpret.

To sort a List by one column:

  1. Display the required List (see Display a List).
  2. Either:
  1. Click on a column header once to sort the List by that column in ascending order.
  2. Click on the same column again, without clicking on any other column, to sort the List by that column in descending order.

Or:

  1. Right-click on a column header.
    A context sensitive menu is displayed.
  2. Either:
  • Select the Sort Ascending option.
    The List is sorted in ascending order by that column.

Or:

  • Select the Sort Descending option.
    The List is sorted in descending order by that column.

To sort a List by multiple columns:

  1. Display the required List (see Display a List).
  2. On a ViewX client, either:
  1. Select the Items menu from the ViewX menu bar.
    A further menu is displayed.
  2. Select the Sort option.

Or:

  1. Right-click on the List.
    A context sensitive menu is displayed.
  2. Select the Sort option.

Or:

  • Press the F8 function key.

The Sort Order window is displayed.

On a WebX client:

  1. Right-click on the List.
    A context sensitive menu is displayed.
  2. Select the Sort option.

The Sort Order window is displayed.

  3. Click on the Add button.
    The Add Column window is displayed.
  4. Use the Column combo box to select the column on which you want to sort the List. (The combo box lists the columns that are on display on the List, other than those that are already being used to sort the List.)
  5. Use the Direction combo box to specify the direction in which you want to sort that column—either Ascending or Descending.
  6. Select the OK button.
    The Add Column window is closed and the new sort criteria is displayed in the Sort Order window.
  7. If required, select the Move Up or Move Down buttons to change the order in which the columns are sorted.
  8. To change the sort order of an existing Sort criteria, select the required entry, then select the Descending button—the sort direction will toggle between Descending and Ascending.
  9. To remove any obsolete Sort criteria, select the obsolete entry, and then select the Remove button.
  10. Repeat the above steps for any further Sort criteria that are required.
  11. Select the OK button.
    The Add Column window is closed and the List is refreshed to display the entries in the specified Sort order.

With Lists other than Alarms Lists, you can also specify the sort order by directly modifying the SQL query’s ORDER BY clause (see Ascertain which SQL Query is Presently used by a List).

Further Information

Reset the Sort Order on an Alarms List or the Alarm Banner in the ClearSCADA Guide to Alarms.

Reset the Filters and Sort Order on a List other than an Alarms List.


Lists Guide - Filter a List (Display and Use Lists)

Filter a List

You can filter a List so that it only shows specific information. For example, you might filter an Events List or Queries List to include only those entries that have specific values, or that are associated with particular area(s) of the system.

With an Alarms List or the Alarm Banner, you filter the entries in the List or Banner by using a Filter window—for information, see Use the Filter Window to Filter Alarm Entries in the ClearSCADA Guide to Alarms.

With other types of List, including Events Lists, Queries Lists, and Historic Lists, you can either Quick Filter the entries in the List, or use the Filter Columns window to specify which entries are displayed in the List. To filter a List using the Filter Columns window, follow the procedure below. For information on Quick Filtering a List, see Quick Filter a List other than an Alarms List.

To filter a List, other than an Alarms List, using the Filter window or Filter Columns window:

  1. Display the required List (see Display a List).
    (When you display a Queries List from the Queries Bar, the Filter Columns window is displayed automatically—proceed to step 3. For other Lists, proceed to step 2.)
  2. On a ViewX client, either:
  1. Select the Items menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Filter option.

Or:

  1. Right-click on the List.
    A context sensitive menu is displayed.
  2. Select the Filter option.

Or:

  1. Press the F7 function key.

The Filter window, or the Filter Columns window is displayed (depending on the type of List).

On a WebX client:

  1. Right-click on the List.
    A context sensitive menu is displayed.
  2. Select the Filter option.

The Filter window, or the Filter Columns window is displayed (depending on the type of List).

  3. Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List.

Further Information

Reset the Filters and Sort Order on a List other than an Alarms List.

Use the Filter Window to Filter Alarm Entries in the ClearSCADA Guide to Alarms.


Lists Guide - Quick Filter a List other than an Alarms List (Display and Use Lists)

Quick Filter a List other than an Alarms List

ClearSCADA includes a Quick Filter feature that allows you to filter various types of List, including an Events List, Queries List, or a Historic List, with a single command. You can use the Quick Filter feature to filter a List according to any of the values shown on the List. For example, if you are viewing a Points List, you can use the Quick Filter feature to filter the Points List so that it only shows those points that have Good quality data.

To use the Quick Filter feature:

  1. Display the required List (see Display a List).
  2. In the relevant column, right-click on the particular value that is to be the filter criteria for the List. When the Quick Filter is applied, the List will only display those entries that have the selected value for the corresponding property.
    A context sensitive menu is displayed.
  3. Select the Quick Filter option.
    The List is filtered so that it only shows those items that have the selected value for the selected property. (The List will only show those items that are relevant to the List, so if you use the Quick Filter on, for example, the Outstations List, the List will only show Outstations that meet the selected filter criteria).

Example:

The Points Queries List is displayed.

In the Quality column, an operator right-clicks on a point that has a Quality of ‘Uncertain’.

The Quick Filter option is selected from the pop-up menu.

The Queries List is automatically filtered to include only those points that have a Quality value of ‘Uncertain’.

To cancel the Quick Filter so that the List reverts to its default settings, right-click on any entry in the List and select the Reset Query option (see Reset the Filters and Sort Order on a List other than an Alarms List).


Lists Guide - Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List (Display and Use Lists)

Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List

With various types of List, including an Events List, Queries List, or Historic List, you can either Quick Filter the entries in the List, or use the Filter Columns window to filter the entries to those that are of interest (see Filter a List).

With the latter method, you can use the Filter Columns window to:

  • Add a Filter to a List
  • Change the Filters on a List
  • Use SQL to Create a Filter for a List other than an Alarms List.


Lists Guide - Add a Filter to a List (Display and Use Lists)

Add a Filter to a List

To filter the entries in a List you can either:

  • Use the Quick Filter feature to filter a List according to a particular value that is shown in the List (see Quick Filter a List other than an Alarms List)
  • Use the Filter Columns window to add a filter to a List. By filtering a List in this way, you can create complex filter criteria to restrict the entries that are included in the List.

To use the Filter Columns window to add a filter to a List such as an Events List, Queries List, or Historic List:

  1. Display the Filter Columns Window (see Filter a List).
  2. Select the Add button.
    The Add Filter window is displayed.
    Database field to which the filter applies.
    The filter condition (options vary, depending on the type of database field).
    The filter value.

  3. Use the first combo box to select the database field to which you want to apply a filter. For a brief description of a particular database field, position the cursor over the highlighted field name to display a ToolTip. The ToolTip provides a description of the field.

Database fields that are commonly filtered on Queries Lists include:

  • Alarm State (AlarmState)—Can be filtered so that it only shows, for example, the items that are in alarm, or for which alarms are disabled.
  • Name—Can be filtered so that it only shows, for example, items that have a specific name, or that include a particular string within their name.
  • Quality (CurrentQualityDesc)—Can be filtered so that it only shows items with a certain quality status, for example, items with Bad Quality.
  • Overridden—Can be filtered so that it only shows those points that either are overridden, or are not overridden.

For information on the fields that apply to Events Lists, see Fields by Which you can Filter an Events List.

  4. Select the filter condition from the second combo box (see Filter Condition Types).
  5. Select the value you want to set for the filter in the third field. (Depending on your choice in step 4, this field may comprise a combo box, include a browse button, or be a text entry field).

(To specify more than one value in this field, select the >> button next to the second combo box. This is only available for certain combinations of database field type and filter condition. When selected, the Add Filter window expands, enabling you to specify a series of filter values in the third field (see Specify a Series of Filter Values).)

When you filter a List, the value(s) entered in this filter value field are compared against the value of the corresponding field of each record in the ClearSCADA database. If the values match (or the value in the ClearSCADA database is between the minimum and maximum values when a Between filter is used), the corresponding record in the ClearSCADA database is returned and is included in the List. (If the filter condition is an exclusive condition that matches the value of a record in the database, that record is NOT included in the List.)

Values can be:

  • Numeric—Useful for searching Historic Lists for particular point values.
  • String—Useful for searching for a database item (or group of items).
  • Date/Time—Can be an absolute time, or a relative time (see Time Formats for Filters).
  • Boolean—Either True or False.
  • Reference—Useful for searching for the name or ID of an item in the database.

Depending on the database field that you select in the first combo box, you may need to type in the value yourself. For more information on entering filter criteria, see:

  • Filter Condition Types
  • Filter Wildcards.
  6. If you have specified a database field that represents a time, further field(s) will be displayed. If you have specified a Relative Time or Specific Time option in step 6, use these fields to specify the time, or time period, by which the List is to be filtered (see Time Formats for Filters).

(If you specified another option in step 6, these fields will contain predefined base time, or time units, and will be ‘grayed out’.)

If you specify a database field that represents a time...
...additional filter value field(s) are displayed, allowing you to specify the time, or time period, by which that field is to be filtered.

ATTENTION: Always include a Time filter with Events Lists and Historic Lists, to restrict the amount of data from which ClearSCADA needs to extract the List’s entries.

  7. Select the OK button.
    The Add Filter window is closed and the new filter criteria is displayed in the Filter Columns window.
  8. Repeat the above steps to add any further filters to the List.

(Multiple filters are combined using the logical AND operator. To combine multiple filters using the logical OR operator, select the Advanced button on the Filter Columns window and directly edit the SQL WHERE clause. For more information, see Use SQL to Create a Filter for a List other than an Alarms List.)

  9. Select the OK button.
    The Filter Columns window is closed. The List is refreshed to show only those records (if any) that meet the filter criteria you have specified.


Lists Guide - Specify a Series of Filter Values (Display and Use Lists)

Specify a Series of Filter Values

Depending on the type of field and the filter condition, it may be possible to specify more than one filter value. In such a situation, the filter values are combined using the logical OR. For example, ‘filter value A’ OR ‘filter value B’ OR ‘filter value C’.

You can specify more than one filter value when:

  • The database field to which you are applying the filter is either a numeric, string, or reference field.

and:

  • You specify a filter condition (see Filter Condition Types) other than: Is Greater Than, Is Greater Than or Equal To, Is Less Than, Is Less Than or Equal To, Is Between, Is Not Between, Is in Group, Is in Area.

With such filter criteria, you can expand the Add Filter window to enable you to specify more than one filter value.

With certain types of database field and filter condition, you can select the >> button...
...to expand the Add Filter window, and enable you to specify a series of values in the third filter field.

To specify a series of filter values:

  1. Select the >> button next to the filter condition field on the Add Filter window.
    The Add Filter window expands to display further fields and buttons.

(The Add Filter window is displayed when you select the Add button on the Filter Columns window. For information on displaying the Filter Columns window, see Filter a List. For more information on using the Add Filter window, see Add a Filter to a List.)

  2. Use the text entry field or combo box below the >> button to define the first value (in the same way as you would define the value if you were only defining one filter value).
  3. Select the Add button.
    The defined filter value is added to the filter values list that is displayed below the Add button.
  4. Repeat steps 2 and 3 for any other values that you want to add to the filter values list.
  5. Once you have specified the values that you require, select the OK button.
    The Add Filter window is closed and the specified filter is added to the list on the Filter Columns window.
  6. Use the Filter Columns window to add further filters as required (see Add a Filter to a List).
  7. Select the OK button on the Filter Columns window.
    The Filter Columns window is closed. The List is refreshed to show only those records (if any) that meet the filter criteria you have specified.

Example:

If you choose to filter the entries in an Events List by the Alarm State field, and select the Is Equal To filter condition, you can add multiple alarm states to that field’s filter values list.

If you add the Cleared, Raised, and Response alarm states to the list, then select the OK button, the Events List will be filtered to show only those events that are associated with alarms being raised or cleared, along with events for any users responding to alarms.

The filter values that appear in this field are combined using the logical OR. (In this case, entries only appear in the Events List if they are associated with either the Cleared, Raised, OR Response Alarm States.)

You can delete a filter value from the filter values list at any time by selecting the filter value and then selecting the Remove button.

You can use the Update button to update or replace any of the filter values that are included in the filter values list. Select the value that you want to update, so that it is highlighted in the list, enter the new value in the filter value field, and then select the Update button. The highlighted entry in the filter values list is updated with the new value.

Further Information

Filter Condition Types.

For more information on the alarm states mentioned in the above example, see Perform an Action on an Alarm in the ClearSCADA Guide to Alarms.


Lists Guide - Change the Filters on a List (Display and Use Lists)

Change the Filters on a List

You can alter a filter that has been applied to a List so that different filter criteria are applied. To change the filter on a List such as an Events List, Queries List, or Historic List, you can either:

  1. Use the Quick Filter feature to apply a quick filter in addition to the existing filter(s) (see Quick Filter a List other than an Alarms List).

Or:

  1. Edit an existing filter:
  1. Display the Filter Columns Window (see Filter a List).
  2. Select the filter that you want to change.
  3. Select the Edit button.
    The Edit Filter window is displayed.
  4. Use the Edit Filter window to adjust the filter settings as required. The filter settings work in exactly the same way as the Add Filter window except that you cannot change the field to which the filter criteria applies (see Add a Filter to a List).

If required, you can alter the filter by directly modifying the SQL query, to change the WHERE clause (see Use SQL to Create a Filter for a List other than an Alarms List).

  5. Select the OK button to confirm the changes and close the Edit Filter window.
  6. Repeat the above steps for any other filters that you want to change.
  7. Select the OK button to confirm your selection and close the Filter Columns window.
    The revised filter(s) are applied to the List.

Or:

  1. Remove an existing filter:
  1. Display the Filter Columns Window (see Filter a List).
  2. Select the filter that you want to remove.
  3. Select the Remove button.
    The filter is removed from the filter list.
  4. Repeat the above steps for any other filters that you want to remove.
  5. Select the OK button to confirm the deletion(s) and close the Filter Columns window.
    The remaining filter(s) are applied to the List.

You can also:

  • Reset the Filters and Sort Order on a List other than an Alarms List
  • Use SQL to Create a Filter for a List other than an Alarms List.


Lists Guide - Filter Condition Types (Display and Use Lists)

Filter Condition Types

When you display a List such as an Events List, Queries List, or Historic List, you can filter the List so that it only shows entries that match specified criteria (see Add a Filter to a List). This is useful as it allows you to control what information is shown on a List so that the data is relevant to your current requirements.

When you are configuring a filter for a List, you need to choose a type of filter condition. The filter condition restricts the entries that are included in the List—the List only shows those items, Events, or alarms that match the defined criteria.

The filter conditions that are available for selection vary according to the type of database field (string, time, numeric, and so on) to which you are applying the filter. Depending on the type of field, you can choose from the following filter conditions:

  • Is Equal To—Restricts the List to entries for which the field’s value matches the filter value exactly.

Select the Is Equal To filter condition, and then enter the value that has to be matched (or use the browse button to select an appropriate item). For example, if you use the Is Equal To filter condition with the Source field, and specify the filter value ‘AI1’, the List will only display those items/events/alarms that have ‘AI1’ as their Source value.

  • Is Not Equal To—Restricts the List to entries for which the field’s value does not match the filter value exactly.

Select the Is Not Equal To filter condition, and then enter the value that is to be excluded from the List (or use the browse button to select an appropriate item). For example, if you use the Is Not Equal To filter condition with the Source field, and specify the filter value ‘AI1’, the List will display those items/events/alarms that do not have ‘AI1’ as their Source value.

  • Begins With—Restricts the List to entries for which the first characters of the field’s value match the characters that are specified as the filter value. For example, if you filter a List by the Name field and specify ‘Ana’ as the Begins With characters, the List will only display those items that have a Name that begins with ‘Ana’.
  • Does Not Begin With—Restricts the List to entries for which the first characters of the field’s value do not match the characters that are specified as the filter value. For example, if you select the Name field and specify ‘Ana’ as the Does Not Begin With characters, the List will only display those items that have a Name that does not begin with ‘Ana’.
  • Ends With—Restricts the List to entries for which the last characters of the field’s value match the characters that are specified as the filter value. For example, if you filter a List by the Name field and specify ‘int’ as the Ends With characters, the List will only display those items that have a Name that ends with ‘int’.
  • Does Not End With—Restricts the List to entries for which the last characters of the field’s value do not match the characters that are specified as the filter value. For example, if you filter a List by the Name field and specify ‘int’ as the Does Not End With characters, the List will only display those items that have a Name that does not end with ‘int’.
  • Contains—Restricts the List to entries for which the field’s value includes the string that is specified as the filter value. For example, if you use the Contains filter condition with the Name field and specify the filter value ‘ana’, the List will only display those items that include the string ‘ana’ in their name. So, for instance, a Points List filtered in this way will show the points named ‘analog input 1’, ‘analog input 2’ and ‘analog input 3’ as they contain the string ‘ana’, but will not show the points named ‘digital output 1’, ‘digital output 2’ and ‘monitor point’, as their names do not contain the string ‘ana’.
  • Does Not Contain—Restricts the List to entries for which the field’s value does not include the string that are specified as the filter value. For example, if you use the Does Not Contain filter condition with the Name field and specify the filter value ‘ana’, the List will only display those items that do not include the string ‘ana’ in their name. So, for instance, a Points List filtered in this way will show the points named ‘digital output 1’, ‘digital output 2’ and ‘monitor point’, but will not display points named ‘analog input 1’, ‘analog input 2’ (as these latter points contain ‘ana’ in their name).
  • Is Like—Restricts the List to entries for which the field’s value is similar to the specified filter value. Only those records that contain the defined and non-defined characters that are specified as the filter value are included in the List. Represent the non-defined characters using Filter Wildcards. For example, if you filter a List by Parent (ParentGroupName) field, using the Is Like filter condition, and specify the following filter value:
Nort% Region

the List will display those items for which the parent group’s name includes the strings ‘Nort’ and ‘Region’, with any other characters in between (as the % wildcard represents 0 or more unspecified characters). So, for instance, a List would include items in the Groups ‘North Region’ and ‘North-West Region’, but would not include items in Groups such as ‘South Region’ or ‘South East Region’.

If the wildcard was an underscore (to represent a single character):

Nort_ Region

the above List would include items in the Group ‘North Region’, but not items in the Group ‘North-West Region’ (as the latter Group name includes more than one character between the ‘Nort’ and ‘Region’ strings).

  • Is Not Like—Restricts the List to entries for which the field’s value is not similar to the specified filter value. Any records that contain the defined and non-defined characters that are specified as the filter value are not included in the List. Represent the non-defined characters using Filter Wildcards. For example, if you filter a List by Parent (ParentGroupName) field, using the Is Not Like filter condition and the following filter value:
Nort% Region

the List will display those items for which the parent group’s name does not include the strings ‘Nort’ and ‘Region’, with any other characters in between (as the % wildcard represents 0 or more unspecified characters). So, for instance, a List would include items in the Groups ‘South Region’ and ‘South East Region’, but would not include items in Groups such as ‘North Region’ or ‘North-West Region’.

If the wildcard was an underscore (to represent a single character):

Nort_ Region

the above List would include items in the Group ‘North-West Region’, but not items in the Group ‘North Region’.

  • Is Greater Than—Restricts the List to entries for which the field’s value is greater than the specified filter value. For example, if you filter a List by the Number of Updates field, using the Is Greater Than filter condition, and specify a filter value of 50, the List will only display those items that have been updated 51 times or more.

If you use the Is Greater Than filter condition with a field that represents a time, (such as Previously Updated), use the filter value field on the Add Filter window, or Edit Filter window, to specify the required time base:

If you select one of the predefined options, the relevant time identifier is displayed automatically in the next text entry field:

Select the Relative Time or Specific Time option, if you want to specify a different time to those on offer (see Time Formats for Filters).

  • Is Greater Than or Equal To—Restricts the List to entries for which the field’s value is greater than or equal to the specified filter value. For example, if you filter a List by the Number of Updates field, using the Is Greater Than or Equal To filter condition, and specify a filter value of 50, the List will only display those items that have been updated 50 times or more.
  • Is Less Than—Restricts the List to entries for which the field’s value is less than the specified filter value. For example, if you filter a List by the Number of Updates field, using the Is Less Than filter condition, and specify a filter value of 50, the List will only display those items that have been updated 49 times or less.

If you use the Is Less Than filter condition with a field that represents a time (such as Previously Updated), use the filter value field on the Add Filter window, or Edit Filter window, to specify the required time base. If you select one of the predefined options, the relevant time identifier is displayed automatically in the next text entry field. Select the Relative Time or Specific Time option, if you want to specify a different time to those on offer (see Time Formats for Filters).

  • Is Less Than or Equal To—Restricts the List to entries for which the field’s value is less than or equal to the specified filter value. For example, if you filter a List by the Number of Updates field, using the Is Less Than or Equal To filter condition, and specify a filter value of 50, the List will only display those items that have been updated 50 times or less.
  • Is Between—Restricts the List to entries for which the field’s value is between two specified values or times. Its value has to be more than or equal to the lowest value that is specified, and less than or equal to the highest value that is specified.

When you specify the Is Between filter condition, you have to enter at least one of the filter values for the filter to work (we recommend that you enter a low value and a high value). Enter the low value in the upper filter value field and enter the highest value in the lower filter value field. For example, if you filter a List by Value (CurrentValueAsReal) field, using the Is Between filter condition, and specify 30 as the lowest value and 45 as the highest value, the List will only display those items that have a current value that is between 30 and 45.

If you use the Is Between filter condition with a field that represents a time (such as Last Updated), use the filter value field on the Add Filter window, or Edit Filter window, to specify the required interval:

...used in conjunction with the Is Between filter condition (to filter the entries to those records that occurred during a particular time period)...
With a database field that represents a time...
...use the filter value field to specify the required time interval. (The options vary, depending on the database field.)

If you select one of the predefined options, the relevant time identifiers are displayed automatically in the two text entry fields:

To specify a different time to those on offer, select the Relative Times or Specific Times option (see Time Formats for Filters).

  • Is Not Between—Restricts the List to entries for which the field’s value is not be between the two specified filter values or times. In other words, if its value is not more than or equal to the lowest value that is specified, or less than or equal to the highest value that is specified.

When you specify the Is Not Between filter condition, you have to enter at least one of the filter values for the filter to work (we recommend that you enter a low value and a high value). Enter the low value in the upper filter value field and enter the highest value in the lower filter value field. For example, if you filter a List by Value (CurrentValueAsReal) field, using the Is Not Between filter condition, and specify 30 as the lowest value and 45 as the highest value, the List will only display those items that have a current value that is below 30 and above 45. (The List will not include those items that have a value between 30 and 45).

If you use the Is Not Between filter condition with a field that represents a time (such as Last Updated), use the filter value field on the Add Filter window, or Edit Filter window, to specify the exclusion interval. If you choose a predefined option, the relevant time identifiers will be displayed in separate text fields below this field. To specify a different time to those on offer, select the Relative Times or Specific Times option (see Time Formats for Filters).

  • Is In Area—This filter condition is only available when filtering Events Lists. It allows you to filter an Events List by Area of Interest. When you select the Is in Area filter condition, you can use the browse button on the filter value field to select the Area of Interest that is to be used as the filter criteria—the Events List will only show those events that are associated with the specified Area of Interest.
  • Is In Group—This filter condition is only available when filtering Events Lists. It allows you to filter an Events List by Group. When you select the Is in Group filter condition, you can use the browse button on the filter value field to select the Group that is to be used as the filter criteria—the Events List will only show those events that are associated with the specified Group.


Lists Guide - Filter Wildcards (Display and Use Lists)

Filter Wildcards

When the Is Like or Is Not Like Filter Condition Types are used to filter a List such as an Events List, Queries List, or Historic List, you can include wildcard characters in the filter criteria. Wildcard characters allow a single filter value to match multiple ClearSCADA database values. There are two wildcard characters:

  • _ (underscore) matches any single character.

For example CA_ will match CAT, CAN, CAB, but will not match CATCH, CALL or CA.

  • % (percent) matches any number of characters.

For example CA% will match CAT, CAN. CAB, CATCH, CALL or CA.

To include a wildcard character in a search without causing the wildcard to match other characters, enter a backslash (\) before the wildcard character. For example PUMP\_1 will only match PUMP_1, and will not match PUMP11, or PUMPA1.

Further Information

Add a Filter to a List.

(The filter wildcards that are supported by Alarms Lists and Alarm Banner differ to the above—for information, see Filter Wildcards in the ClearSCADA Guide to Alarms.)


Lists Guide - Time Formats for Filters (Display and Use Lists)

Time Formats for Filters

If you filter a List by a database field that represents a time, you are offered a predefined choice of base times, or time intervals (see Filter Condition Types) in the Add Filter window or Edit Filter window. If you want to specify a different base time, or time interval to those on offer, select the Relative Time, Relative Times, Specific Time, or Specific Times option.

Whether you select a predefined option, or opt to enter your own time criteria, ClearSCADA is capable of interpreting two time formats when filtering a List:

  • Specific Time, using the syntax that is defined by the user’s Date Format. For example, yyyy-MM-dd HH:mm:ss.SSS.
  • Relative Time in the OPC Relative Time Format.

Specific Time

If you select the Add Filter window or Edit Filter window’s Specific Time or Specific Times option, specify the time that you require by overtyping the displayed entry. Alternatively, use the Calendar window to specify the date, and then overtype the time element (see Specifying the Required Entry in a Date and Time Field in the ClearSCADA Guide to Core Configuration).

Specific time(s) are displayed in the syntax defined by the user’s Date Format. To specify the required time(s), overtype the entries, or use the Calendar window to specify the date, then overtype the time element.

Relative Time

If you select the Add Filter window or Edit Filter window’s Relative Time or Relative Times option, specify the time value that you require by overtyping the displayed entry. You need to specify the time in the OPC Relative Time Format.

With a Relative Time, you need to enter the required time value in the OPC Relative Time Format.

Relative times are times that are relative to the present time. You can specify a single time unit, or for more complex expressions, a time unit followed by an offset. You can specify the time value in either short or long OPC Relative Time Format.

Examples:

D
(for the start of the current day)

D-2H
(for 10pm yesterday (2 hours before the start of the current day)

H+1H
(The end of the current hour).

Hour-30Minutes
(30 minutes before the start of the present hour).

For more information, see Specify a Relative Time in the OPC Relative Time Format in the ClearSCADA Guide to Core Configuration.

For information on time formats in general, see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.

Further Information

Display the Add Filter window: see Add a Filter to a List.


Lists Guide - Use SQL to Create a Filter for a List other than an Alarms List (Display and Use Lists)

Use SQL to Create a Filter for a List other than an Alarms List

When displaying a List such as an Events List, Queries List, or Historic List, you can use the Filter Columns window to apply the filter criteria (see Filter a List). When using the Filter Columns window, you can choose to apply the filter settings by using the various combo boxes and fields, or you can select the Advanced button. This button provides access to the SQL text entry field, enabling you to define the filter criteria as an SQL query WHERE Clause. (To revert back to using simple filters, select the Simple button on the Filter Columns window.)

Example:

The Display Points option is used to display a Queries List of the points that are associated with a particular outstation. The Filter option is used to display the Filter Columns window. A further filter is added to restrict the List to only those points that contain the word ‘Sensor’ within their name.

The Filter Columns window indicates the filters that are being used for the List:

The Filter Columns window lists the filters that are being used to restrict the List’s content.

The Advanced button is selected on the Filter Columns window. This displays the WHERE Clause—the part of the SQL query that is being used for the above filters:

The WHERE Clause for the above filters.

By defining the filter using SQL, you can create more complex filter criteria. To do this, you need a good understanding of the SQL language.

Example:

With the above List, the WHERE Clause is expanded to enable the List to contain points that include either ‘Sensor’ or ‘Switch’ in their names:

( "SourceName" = 'Eastern Region.Zone 1.Direct Outstation' ) AND (( "Name" LIKE '%Sensor%' ) OR ( "Name" LIKE '%Switch%' ) )

Be aware that if a List is filtered using a complex WHERE Clause, only the OK and Cancel buttons remain available for use on the Filter Columns window.

When the WHERE Clause used to filter a List is complex...
...only the OK and Cancel buttons on the Filter Columns window remain available for use.

To further adjust the filter, specify the required WHERE Clause in the Filter Columns window, or right-click on the List and use the Reset Query option to reset the filter back to the default (see Reset the Filters and Sort Order on a List other than an Alarms List).

Be aware that you can also temporarily control exactly which columns are included in a List, along with the List’s sort order, and the filter criteria, by displaying the SQL query for the whole List (rather than just the SQL for the filters)—for more information, see Ascertain which SQL Query is Presently used by a List. You need a good understanding of the SQL language in order to specify the required SQL query successfully.

Be aware that there are several database fields that perform special functions in ClearSCADA—these fields are not displayed as columns in the List, but do affect the appearance and functionality of the List. For more information, see Fields that Perform Special Functions.

Further Information

Using SQL to Customize Lists.


Lists Guide - Reset the Filters and Sort Order on a List other than an Alarms List (Display and Use Lists)

Reset the Filters and Sort Order on a List other than an Alarms List

You can use the Reset Query option to set a List, such as an Events List, Queries List, or Historic List to disregard any filtering and sorting that you have applied. This returns the List to its original state—the List will be reset so that it shows the same data as when it was first displayed.

When you first display such a List, ClearSCADA stores the SQL query that specifies which data is shown in the List. As you apply filters and sorting, the SQL Query for the List is altered, but the original SQL Query remains stored in the List document. When you select the Reset Query option, it sets the List to disregard the SQL Query that is currently in place and reinstate the original SQL Query.

To reset a List that is on display:

  1. On a ViewX client, either:
  1. Select the Items menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Reset Query option.

Or:

  1. Right-click on the List.
    A context sensitive menu is displayed.
  2. Select the Reset Query option.

The SQL Query for the List is reset—any additional filtering and sorting for the List is removed and the List reverts to its original state.

On a WebX client:

  1. Right-click on the List.
    A context sensitive menu is displayed.
  2. Select the Reset Query option.

The SQL Query for the List is reset—any additional filtering and sorting for the List is removed and the List reverts to its original state.

Further Information

Sort a List.

Filter a List.

Reset the Filters on an Alarms List or the Alarm Banner in the ClearSCADA Guide to Alarms.


Lists Guide - Refresh the Data on a List other than an Alarms List (Display and Use Lists)

Refresh the Data on a List other than an Alarms List

The data in Alarms Lists updates in real time.

Data in other Lists is queried via SQL. The rows in Queries Lists such as the Points List are continuously updated, however, should you, for example, add a new point to the database while the Points List remains on display, the new point would only be included in that List once you ‘refresh’ the List. (Assuming that any filters that are in force do not exclude the new point from the List.)

Similarly, while the Events List is on display, the entries in that List are only further updated when you ‘refresh’ that List. (Events are not ‘live’—they are occurrences that have already happened on the system. Each new event is a new entry in the Events List.)

‘Custom’ Lists with complex queries that include, for example, summary functions (SUM) and/or GROUP BY clauses, only update when a Refresh is issued. A Refresh is required if there is no one-to-one correlation between the entries on a List and the Ids or RecordIds that would otherwise identify the records in the ClearSCADA database.

To ‘refresh’ a List with the latest data:

  1. Right-click on the List.
    A context sensitive menu is displayed.
  2. Select the Refresh Query option.

Alternatively, on a ViewX client, you can either:

  1. Select the Items menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Refresh option.

or:

  1. Press the F5 function key on the keyboard.

(Closing and then redisplaying a List also refreshes the data on that List.)


Lists Guide - Events Lists

Events Lists

ClearSCADA logs each activity that occurs on your system, creating an audit trail for system operation and reporting. Events are the records of the activities that have occurred on your system. ClearSCADA logs events, for example, for each user interaction with the system, and for automatic system occurrences such as alarms, point updates, scheduled archiving, and so on. ClearSCADA logs the events in the Event Journal. You can view these occurrences by displaying an Events List. You can view a general list of events that have occurred on the system over a particular time period, or view a list of the events that are associated with an individual item or group. (The latter version of the Events List contains the same type of information as the former, but further filters the entries to include only those records that apply to the selected item or group.)

You can use either Events List to view the events and determine what has happened on your system. This is especially useful when attempting to diagnose reported faults or to determine what tasks other users have performed.

This section explains how to:

  • Display a General List of Events
  • Display the Events List for an Item or Group.

Refer to the following sections for details on how to use the Events List’s features and interpret the information that the Events Lists provide:

  • Understand Events Lists
  • Display and Use a List’s Context Sensitive Menu
  • Display Events for the Previous or Next Time Interval
  • Display Events for a Particular Time Interval
  • Sort an Events List
  • Filter a List
  • Fields by Which you can Filter an Events List
  • Reset the Filters and Sort Order on a List other than an Alarms List
  • Insert a Comment for an Event.

Various properties affect the way in which event information is presented on a ClearSCADA system. Many of these properties can be configured by system administrators and high-level engineers. Such configuration is explained in the following sections within this guide:

  • Set up Events List Preferences
  • Specify the Preferred List Options on a ViewX Client.


Lists Guide - Display a General List of Events (Events Lists)

Display a General List of Events

You can display a list of events that have occurred on a single ClearSCADA system (database). The List is pre-filtered by time—the period for which events are initially shown is defined by your User Account (or the Guest User Account if you are not logged on to ClearSCADA).

Any events that relate to alarms are displayed in the same color scheme as used on the Alarms List (see The Color of Entries in a List other than the Alarms List).

Be aware that your user account settings, security permissions and so on, may restrict the events to which you have access. This is to help ensure that you are only made aware of events that might be of interest to you.

To display a general list of events on a ViewX client, either:

  1. Select the Events button [image] on the Operate Toolbar.

Or:

  1. Select the View menu from the ViewX menu bar.
    A drop-down menu is displayed.
  2. Select the Events option.

Or:

  1. Press the F10 function key.

An Events List is displayed. The List shows event messages that have been logged on your system within a specified time period (the Event List Range specified on your User Account (or the Guest User Account if you are not logged onto ClearSCADA)).

If the Events List is not displayed and a Historic Cache message is shown, there are too many events for the query to process. To avoid this, you may need to further filter the Events List (see Filter a List). (If the filter does not resolve the situation, contact a high-level user as the amount of memory available may be inadequate, or the configuration of database items may mean that events are being logged more often than are actually required.)

You can refresh the Events List by selecting Refresh from the Items menu or by pressing F5 (see Refresh the Data on a List other than an Alarms List).

On a ViewX client that has access to multiple ClearSCADA databases, the above procedures each display the general Events List for the default ClearSCADA database. To display the Events List for a particular ClearSCADA database to which a ViewX client has access:

  1. Display the Database Bar (see Explorer Bars used in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Right-click on the relevant system entry.
    A context sensitive menu is displayed.
  3. Select the Display Events option.
    The list of events for that ClearSCADA system is displayed.

You can also display a general list of events for the ClearSCADA database to which a WebX client is connected (see View and Action Events on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients).


Lists Guide - Display the Events List for an Item or Group (Events Lists)

Display the Events List for an Item or Group

You can display an Events List that is filtered automatically to show the Events for a specific item or group. You can display such an Events List from:

  • The Database Bar (see Display a List from the Database Bar)
  • From another display, such as a Mimic or another List (see Display a List from another Display).

In either case, use the Display Events menu option or pick action to display the required Events List. The List will be filtered automatically to include only those events for the selected item or group.

If you select a Group folder, the Events List also shows the events for the items in that folder and its subfolders.

The Events List is pre-filtered by time—the period for which events are initially shown is defined by the Event List Range specified your User Account (or the Guest User Account if you are not logged onto the system).

Your user account settings, security permissions and so on, may further restrict the events to which you have access. This is to help ensure that you are only made aware of events that might be of interest to you.


Lists Guide - Understand Events Lists (Events Lists)

Understand Events Lists

The Events List displays a row of values for each event that occurs in your ClearSCADA system, and uses columns to separate and categorize the values. The column headings indicate what the values in each column represent. The columns that are displayed on your Events List can be configured by a system administrator (see Events List Settings in the ClearSCADA Guide to Server Administration).

The default column headings for the Events List are:

  • Severity—Events have a severity level that indicates the importance of the event. Severity for events works in exactly the same way as Severity for alarms and has the same range of severity levels (see Alarm Severity in the ClearSCADA Guide to Alarms).
  • Time—The date and time at which the event was recorded. Events have both an ‘occurrence time’ and a ‘received time’. Whenever the ClearSCADA server provides the time stamp, these times are one and the same. Whenever ClearSCADA receives a time stamped event from an outstation, the Time column displays that record’s ‘occurrence time’ (the time stamp provided by the outstation or scanner).

Events that are generated at the master station (ClearSCADA) are time stamped by the server. If an event occurs at the outstation, the time stamp of that event depends on the driver. With some drivers, the outstation time stamps the data and then passes that data to ClearSCADA. With other drivers, the time stamp might be generated by the outstation or the server, depending how the data was reported. Outstations on some drivers do not support time stamping of data, and therefore the server time stamps that data when it receives it from the outstation.

  • Source—The name of the item with which the event is associated. The Source is not always the name of an item in the ClearSCADA database. For items that are in the ClearSCADA database, the FullName of the item is displayed.
  • Message—A short text description of the system occurrence that caused the event to be generated.
  • User—The identity of the user that caused the event to be generated. Users include:
  • <User Name>—The name of a user that is logged on to ClearSCADA and whose activity caused an event to be generated. <User Name> generated activities might include, for example, logging on and off ClearSCADA, modifying an item’s configuration, or sending controls to plant.
  • Guest—This is a built-in user account. Events are assigned to the Guest user should someone perform activities on a ViewX Client without being logged onto ClearSCADA via that client. Guest user access is typically restricted to help prevent unauthorized interaction with the system.
  • Web—This is a built-in user account. Events are assigned to the Web user should someone perform activities on a WebX Client without being logged onto ClearSCADA via that client. Web user access is typically restricted to help prevent unauthorized interaction with the system.
  • <Super User Name>—If enabled on your system, the Super User Account provides access to all ClearSCADA features. The account is typically used to log on to ClearSCADA should incorrect configuration result in some features being denied by the other users on your system (for example, through the security features being configured incorrectly).

For more information on any of the above users, see User Accounts in the ClearSCADA Guide to Security.

ClearSCADA also includes several built-in internal ‘users’:

  • Driver—Events generated due to driver-instigated activities, such as configuration upload.
  • Logic—Events generated due to a Logic program’s activity. For instance, an activity such as a One Shot call being triggered by a Logic program. For information on Logic programs, see the ClearSCADA Guide to Logic.
  • Method Call—Events generated due to actions being triggered by Method Calls (see Stand-Alone Method Calls in the ClearSCADA Guide to Core Configuration).
  • Schedule—Events generated due to actions being triggered by a Schedule (see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration).
  • System—Events that are not generated by another type of user. Alarm-related events, for example, such as those logged to indicate an alarm being cleared or raised, are assigned to the System user.

If the event was not caused by ‘user’ interaction, there will be no entry in this column.

  • Category—Each event has a category that indicates the type of event. This allows you to filter the Events List so that it only displays events of a specific category, such as outstation communications events (see Add a Filter to a List).

The event categories include:

  • Action—The event was logged due to an action being performed. An action can be triggered manually by an operator, or automatically—for instance, by a Method Call, Logic, or a Schedule.
  • Alarm Analysis—The event was logged due to the permitted time for either receiving, responding to, or clearing an alarm being exceeded. Alarm Analysis periods can optionally be configured for Severity ranges (see Add a Severity Range in the ClearSCADA Guide to Server Administration).
  • Alarm Redirection—The event was logged due to an alarm being redirected (as part of the Alarm Redirection feature that allows, for example, alarms to be sent to pagers).
  • Archive Volume—The event was logged due to a detected problem associated with either deleting, duplicating, or recreating an archive volume (the media to which data is being archived). For example, the archive volume being full.
  • Archiving—The event was logged due to data being archived, for instance onto hard disk, CD, DVD, or compact flash. Archiving provides the ability to store historic and/or event data offline. For more information on archiving, see Archiving in the ClearSCADA Guide to Server Administration.
  • Callback—The event was generated due to a successful callback, an unsuccessful callback, or an unexpected callback. (The callback feature allows you to send a message to an outstation to instruct it to dial in. The outstation should then report its data within a specific amount of time).
  • Channel Status—The event is associated with a communications channel’s status. For example, an event is logged if channel communications is interrupted unexpectedly (an alarm is also raised).
  • Comment—The event was logged due to a comment being created (see Insert a Comment for an Event).
  • Configuration—The event was logged due to configuration changes being made (for example, a new item being created, the configuration of an existing item being modified, an item being renamed or deleted from the database).

If you have the Configuration Changes feature enabled on your system, you can keep a detailed record of any configuration changes. You can use the Property Change History List to view a summary of the configuration changes on your system (see Display a List of Property Changes in the ClearSCADA Guide to Core Configuration).

  • Control Status—The event was logged due to both successful and unsuccessful control activity. For example, a control request, or execution.
  • Database Server—This category is used for miscellaneous events associated with server activity. For example, an event logged due to unexpected activity occurring while receiving a request from a ViewX or WebX client.
  • Dial In Overactive—The event has been logged due to a PSTN outstation dialing in more often than expected.
  • File Upload Status—The event is associated with file upload activity, for example, outstation data being uploaded to ClearSCADA. Where supported by a driver, if the system set-up does not allow ClearSCADA to communicate with one or more outstations, file uploading can be used to upload the data from those outstations to ClearSCADA.
  • Forecast—The event is associated with a Forecast item. For example, an event is logged if an alarm is raised due to a Forecast from an external application having values that are outside the alarm limits for the Forecast item in ClearSCADA.
  • Historic—The event was logged due to an operation associated with historic data (for example, historic data being inserted, or modified).
  • Interface Alarm—The event was logged due to an external application raising an alarm using the SetInterfaceAlarm method. The SetInterfaceAlarm method is purely for use with the Automation Interface. For more information, see the database Schema.
  • Interface Event—The event was generated by an external application, using the SetInterfaceEvent method. The SetInterfaceEvent method is purely for use with the Automation Interface. For more information, see the database Schema.
  • Outstation Comms—The event was logged due to a change in outstation communications status (for example, due to an incoming call).
  • Outstation Error—The event was generated when a general outstation error was detected (an outstation error that is not included in the Outstation Hardware or Outstation Comms categories).
  • Outstation Hardware—The event is associated with the status of the outstation’s hardware.
  • Outstation Status—The event is associated with the status of an outstation. For example, an event can be logged when an outstation is reset, or when an outstation requests configuration.
  • Pager Comms—The event is associated with the communications status of a pager service. For example, an event is logged when there is an attempt to connect with a pager.
  • Point Error—The event has been logged due to a miscellaneous error associated with a point being detected.
  • Point No Change—The event has been logged due to a point’s value not having changed by a specified amount for a defined period of time. Such events can only be logged for points that are configured to use the No Change feature.
  • Point Significant Change—The event is associated with a significant change in the value of a point. This type of event can only be logged for points that are configured to use the Significant Change feature.
  • Point State—The event has been logged due to a point changing state. The point states are those that are defined in the configuration of each point.
  • Point Status—The event is associated with the status of a point. These are miscellaneous events that are not covered by Point State.
  • Scanner Status—The event is associated with a scanner or a point source (simple drivers). For example, an event is logged when an alarm is raised due to a scanner error being detected.
  • Scheduled Dial In—The event has been logged due to a successful scheduled dial in, an unsuccessful scheduled dial in, or an unexpected scheduled dial in.
  • Server Status—The event is associated with the status of a server or channel (simple drivers). For example, an event is logged when there is a switch from one channel to another.
  • Set Status—The event is associated with the status of an outstation set. For example, an event is logged if the outstation set switches from one communications channel to another (switches lines).
  • System—The event has been logged due to an occurrence that affects the entire system, such as the server being stopped and restarted. The System category is also used for miscellaneous events that are not suited to the other categories.
  • System Alarm—The event has been logged due to a system-wide problem being detected, such as licenses expiring.
  • Text Message—The event has been logged due to a ClearSCADA Server receiving a text message from an outstation or another ClearSCADA server.
  • Unknown Dial In—The event has been logged due to an unknown PSTN outstation dialing-in to ClearSCADA.

Other columns that may be included in the Events List are:

  • Area of Interest—This column is only available if the Area of Interest feature is enabled on your system. The column lists the Area of Interest with which the event is associated. Only alarm-related events have an Area of Interest; the entry is blank for other types of event. Additionally, the Events List is restricted so that it only includes events that have either no Area of Interest, or an Area of Interest to which the logged on user has access. For more information, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.
  • Alarm State—The event has been logged due to a change in the item’s alarm state. For example, an alarm being raised, cleared, acknowledged, or disabled.
  • User Location—The IP Address or computer name of the client computer which generated the event.
  • Deleted—Indicates if the item associated with the event has been deleted from the database.
  • Source—The item ID of the item in the database that is associated with the event.
  • Named Region—The name of the Historic Region that contains the event (where applicable). Historic Regions are sections of historic data that remain online—the events within them are not deleted.

This information is especially useful when filtering an Events List. For example, if your system has a Historic Region for a time period in which a specific event occurred, such as a power outage, you can filter the Events List by the relevant Historic Region. You can then use the filtered Events List to examine what happened on your system during the power outage.

  • Receipt Time—The time at which the event was received at the ClearSCADA server. The time includes the date on which the event was received.

Further Information

Events logged due to alarms or alarm redirections: see Alarm-Related Entries in the Events List in the ClearSCADA Guide to Alarms.


Lists Guide - Display Events for the Previous or Next Time Interval (Events Lists)

Display Events for the Previous or Next Time Interval

When you Display a General List of Events, or Display the Events List for an Item or Group, the List initially shows events for the interval that is defined by your User Account’s Event List Range (or the Event List Range of the Guest User Account, if you are not logged onto ClearSCADA).

To display the events for the previous, or next interval, either:

  1. Select the Previous [image] or Next [image] button on the Navigate Toolbar.

Or:

  1. Right-click on the Events List.
    A context sensitive menu is displayed.
  2. Select the Previous Interval option, or the Next Interval option, as required.

The Events List is refreshed to show the events for the previous, or next, time interval. (For instance, if the List shows events for a 24-hour period, the entries are displayed for the previous 24-hour period, or the next 24-hour period.)

You can also Display Events for a Particular Time Interval.


Lists Guide - Display Events for a Particular Time Interval (Events Lists)

Display Events for a Particular Time Interval

When you Display a General List of Events, or Display the Events List for an Item or Group, the List initially shows events for the interval that is defined by your User Account’s Event List Range (or the Event List Range of the Guest User Account, if you are not logged onto ClearSCADA). If required, you can Display Events for the Previous or Next Time Interval, or specify a different time period.

To display the events for a particular time period:

  1. Right-click on the Events List.
    A context sensitive menu is displayed.
  2. Select the Go To option.
    The Go To Time window is displayed.
  3. Use the combo box at the top of the window to select either:
  • A predefined time period (such as ‘Previous Hour’).
  • The Relative Time option, if you want to specify a time relative to the present time. Go to step 5.
  • The Specific Time option, if you want to specify a specific date and time for which the Events List is to display events. Go to step 6.
  4. If you have specified a predefined time period in step 3, the Start and End fields will be populated automatically with the relevant time values and will be ‘grayed out’. Go to step 7.
  5. If you specified the Relative Time option in step 3, use the Start and End fields specify the required time interval for which the List is to display events. The interval has to be relative to the present time, and you have to specify the time in the OPC Relative Time Format. You can specify a single time unit, or a time unit followed by an offset in either field. You can specify the time value in either short or long OPC Relative Time Format. Once you have specified the required time interval, go to step 7.

Example:

Start: H - 3H
End: 2H
(To display two-hours’ worth of events, for an interval starting three hours ago.)

  6. If you specified the Specific Time option in step 3, use the Start and End fields to specify the specific time period for which the List is to display events.

Either overtype the existing entries with the required dates and times, or use the Calendar window to specify each date and then overtype the time elements (see Specifying the Required Entry in a Date and Time Field in the ClearSCADA Guide to Core Configuration).

The entry in each field is displayed using the syntax that is defined by the user’s Date Format. For example, dd-MMM-yyyy HH:mm:ss.SSS.

  7. Select the OK button to confirm the settings.
    The Go To Time window is closed and the Events List is filtered to show only those events that occurred during the specified time period.


Lists Guide - Sort an Events List (Events Lists)

Sort an Events List

The Events List displays Events in time order by default—the latest logged events are shown at the top of the Events List and the oldest logged events are shown at the bottom. You can use the Sort feature to determine the order in which events display in the Events List (see Sort a List).


Lists Guide - Fields by Which you can Filter an Events List (Events Lists)

Fields by Which you can Filter an Events List

When you use the Add Filter window to filter an Events List, you use the top combo box on the window to specify the database field to which you want to apply a filter (see Add a Filter to a List).

You can filter an Events List by various database fields, including:

  • Area of Interest—Only displayed if the Area of Interest feature is enabled on your system. Use this field to filter the Events List to those events that are associated with specific Area(s) of Interest. When using the Reference browse window to specify an Area of Interest, you will be offered those Area(s) of Interest to which your User Account has access. For more information, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.
  • Alarm State—Use to filter the Events List according to alarm state. Each event that is associated with an alarm has an alarm state, which indicates the particular activity that is associated with that alarm. For example, you can filter the Events List so that it only shows alarms being Acknowledged, or leave the filter values field blank to include or exclude those events that are associated with alarms.
  • Alarm Suppression Type—Use to filter the Events List to show or exclude events that relate to alarms being suppressed or unsuppressed. When filtering by this field, the filter value combo box offers four options:
  • <Blank>—Use to apply the filter to events that are not alarm-related (that is, events with which alarm suppression cannot be associated).
  • Consequential—Use to apply the filter to alarm-related events that are associated with the ‘Consequential’ type of alarm suppression.
  • Maintenance—Use to apply the filter to alarm-related events that are associated with the ‘Maintenance’ type of alarm suppression.
  • None—Use to apply the filter to alarm-related events that have no associated alarm suppression.

For further information on alarm suppression, see Alarm Suppression in the ClearSCADA Guide to Alarms.

  • Category—Use to filter the Events List according to its category values. Each event has a category value that describes the type of system occurrence that caused the event to be logged. For example, if a user performs an Override control, an event is logged with the Action category (as the event was caused by a user performing an action).
  • Comment Number—You can add comments to events in the Events List. Comments are useful for indicating, for example, that an event was logged due to an unusual occurrence (see Insert a Comment for an Event). Use the Comment Number field to filter the Events List to either include or exclude those events that are comments. Events that are comments have a Comment Number of 1; other events have a Comment Number of 0.
  • Deleted—Use to filter the Events List to those events that are associated with database items that have been deleted since the event was logged.
  • File Id—Event Journal messages are stored in a series of files. Each file has a unique File Id. Use the File Id field for diagnostic purposes, to filter the Events List to those events that are stored in particular Event Journal file(s). The File Id is a string value.
  • File Offset—Event Journal messages are stored in a series of files, with each message being assigned a unique offset in each file. Use the File Offset field for diagnostic purposes, to filter the Events List to those events that are stored in a particular location within specific Event Journal file(s). The File Offset is a whole number.
  • Message (Message)—Use to filter the Events List according to its message values. Each event has a message value that describes what happened to cause the event to be logged. For example, if a user performs an Override action on a point, the message indicates that an Override action was performed and the value of the override. The Message is a string value.
  • Message (MessageLong)—Use as an alternative to the Message (Message) field, to filter the Events List according to its message values, should the relevant messages be over 254 characters long. ClearSCADA stores event messages up to 254 characters long as text fields and messages over 254 characters as memo fields. Be aware that some third-party applications provide only limited searching of memo fields.
  • Named Region—Use to filter the Events List to those events that are stored in specific Historic Regions. Historic Regions are used to retain specific periods of historic data on the system. Normally, historic data is deleted after a certain amount of time; the data recorded during the time specified for a Historic Region is not deleted (see Historic Regions in the ClearSCADA Guide to Server Configuration).
  • Raw Encoded Message—ClearSCADA stores event messages internally in raw encoded format. Each message is decoded for display in the Events List. The Raw Encoded Message field can be used for diagnostic purposes. For instance, to ascertain which events contain particular messages elements, or how message elements conveying variable data are passed between server and client.
  • Receipt Time—Use to filter the Events List to those events that were received by the server at a specific time or within a defined time range.
  • Severity (Severity)—This field is only retained for backwards compatibility, and is an alias for the SeverityValue field. We suggest you filter events by Severity (SeverityValue) rather than by this field.
  • Severity (SeverityDesc)—Use to filter the Events List according to severity description. Each event has a severity description that indicates the importance of the event. The default descriptions are Critical, High, Medium, and Low, where, for example, an event with a Low severity would not be as important as an event with a severity description of High or Critical. The default severity descriptions and levels may have been replaced by a custom range of severities on your system.
  • Severity (SeverityValue)—Use to filter the Events List according to the severity of the events. Each event has a severity value that indicates the importance of the event. Use this field to filter the Events List to those events that have a specific severity value, or have a severity value within a defined range. The default ranges are Low 1-333, Medium 334-666, High 667-999, and Critical 1000. Unlike the Severity (SeverityDesc) field, you use the Severity (SeverityValue) field to filter events by severity number, rather than severity description. Be aware that the number ranges and corresponding severity descriptions on your system may differ from those above.
  • Source (Id)—Each item in the database has a unique ID number that is used internally to identify that item. Use the Source (Id) field to filter the Events List to those events that are associated with a source that has a particular ID number. When you select this field, use the browse button adjacent to the filter value field to select the name of the database item for which you want to filter the events. Alternatively, use the >> button adjacent to the filter condition field, and specify more than one source.

Although the name of each database item is displayed in the simplified form of the filter, the SQL behind the filter filters the List by Id rather than by source name (as can be seen by selecting the Advanced button on the Filter Columns window, to view the WHERE Clause that is used for the filter).

  • Source (Source)—Use to filter the Events List according to event source. Each event is associated with a specific ‘source’, which is typically an item in the database. This item is the source of the event. As with the Source (Id) field, you use the browse button adjacent to the filter value field to select the name of the database item for which you want to filter the events, or use the >> button adjacent to the filter condition field to expand the window and specify more than one source.
  • Time (RecordTime)—Use this field in the same way as the Time (Time) field, including by third-party applications. Select this field if you want to filter the Events List to those events that occurred at a specific time, or within a specific time range. The RecordTime is the time that an event occurred, as opposed to the ‘receipt time’, which is the time at which the server received the data that caused the event. (For instance, this is the time that a pump started, as opposed to the time that the server dialled the outstation and retrieved the state of the pump (which might be hours later).)

Events Lists are filtered by time. Each List initially displays events for the interval that is defined by your User Account’s Event List Range (or the Event List Range of the Guest User Account, if you are not logged onto ClearSCADA). You can use the Go To menu option to Display Events for a Particular Time Interval, or the Previous or Next buttons or options to Display Events for the Previous or Next Time Interval, as an alternative to filtering by Time (RecordTime).

  • Time (Time)—This field is only retained for backwards compatibility, and is an alias for the RecordTime field. We suggest you filter events by Time (RecordTime) rather than by this field. (‘Time’ is a reserved word in SQL and as such cannot be used by some third-party applications.)
  • User—Use to filter the Events List according to the users that caused the events to be logged. Each event can be associated with a specific user, for example, if a user performs an action, an event is logged and the user for that event is the user that performed the action. Many events that are generated due to system activity, such as point state changes, do not have a user value as they are normal system events. However, some system events, such as the server starting, have a user value of System. Typically, you would use this database field to filter the Events List so that it shows events that were caused by users performing actions or altering the configuration of database items.
  • User Location (ClientAddress)—Use to filter the Events List to those events that were logged as a result of the actions of a user who was logged on to a specified client. When using this field, you need to specify the IP address of the client you require. Specify the IP address as a 32-bit integer.

This field is primarily for use by applications that are searching the Event Journal for specific events. (It is more efficient than searching by ClientAddressDesc).

  • User Location (ClientAddressDesc)—Use to filter the Events List to those events that were logged as a result of the actions of a user who was logged on to a specified client. When using this field, you need to specify the IP address of the client you require. Specify the IP address in standard dot-decimal notation, for example, 10.1.5.30.
  • User Location (ClientName)—Use to filter the Events List to those events that were logged as a result of the actions of a user who was logged on to a specified client. When using this field, you need to specify the name of the client you require.

Other fields perform special functions and are not used for filtering. These include:

  • Foreground—This field controls the color in which an entry’s text appears in the Events List. The color indicates, for example, whether an event is associated with alarm activity (see The Color of Entries in a List other than the Alarms List).
  • Record ID—This field enables ClearSCADA to retrieve ‘dynasets’ of data. Retrieving dynasets of data minimizes the loading on both the server and client, particularly when requesting large quantities of data.
  • Sequence Number—This field is used to sort events that have the same time stamp into the correct order. The Sequence Number is included in the Events List’s ORDER BY clause (as can be ascertained by using the Sort option to display the Sort Order window).

Further Information

Filter a List.


Lists Guide - Insert a Comment for an Event (Events Lists)

Insert a Comment for an Event

You can add comment to an Event in the Events List. This is useful for indicating that an event was logged due to an unusual occurrence. For example, if a new piece of equipment is used and that equipment proves to be faulty, ClearSCADA would typically raise an alarm and log an event to indicate that it has detected a problem. You could then use the alarm’s Acknowledge with Comment feature to acknowledge the alarm and add a comment to state that the cause of the alarm is under investigation (see Acknowledge an Alarm with Comment in the ClearSCADA Guide to Alarms). Then, when the detected problem has been identified as being the faulty equipment, you could use the event’s Insert Comment feature to add a comment to state the event was logged due to faulty equipment.

Other users who view the events for that time period will be able to see that the event was due to an isolated detected fault. They will see that it is not a recurring problem related to the setup of the system.

To insert a comment for an event:

  1. Either Display a General List of Events, or Display the Events List for an Item or Group.
  2. Right-click on the relevant event in the Events List.
    A context sensitive menu is displayed.
  3. Select the Insert Comment option.
    The Insert Comment window is displayed.
  4. Enter a suitable comment.
  5. Select the OK button.
    The Insert Comment window is closed and a new event is created in the Events List, with the comment displayed in the Message column.


Lists Guide - Queries Lists

Queries Lists

Queries Lists are Lists of database values. You can display many Queries Lists in ClearSCADA, and use those Lists to monitor, control and compare various aspects of your system.

When you display a Queries List, ClearSCADA uses SQL to query the database and retrieve the data that you require. The entries in the List are then displayed in colors that define their state and status (see The Color of Entries in a List other than the Alarms List).

Each Queries List comprises a row of values for each database item that is included in the List. The values are displayed using a series of columns. The column headings indicate what the values in each column represent. The columns that are included in a Queries List vary, depending on the type of List. For more information on a particular column, move the cursor over the column heading to display a ToolTip about that column.

As with other Lists, you can right-click on an entry in a Queries List to display a context sensitive menu. Many of the options are identical to those that are available from the Object menu for the item (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients). Be aware that some Queries List menu options vary, depending on the type of item, your user account security permissions, and the configuration specified for that item.

This section explains how to:

  • Display a Queries List

Refer to the following sections for details on how to use the Queries Lists’ features and interpret the information that the Lists provide:

  • Display and Use a List’s Context Sensitive Menu
  • Sort a List
  • Filter a List
  • Quick Filter a List other than an Alarms List
  • Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List
  • Reset the Filters and Sort Order on a List other than an Alarms List
  • Refresh the Data on a List other than an Alarms List.

Various properties affect the way in which query information is presented on a ClearSCADA system. Many of these properties can be configured by system administrators and high-level engineers. Such configuration is explained in the following sections within this guide:

  • Set up Queries List Preferences
  • Specify the Preferred List Options on a ViewX Client.

Some drivers support additional driver-specific Lists. Such Lists are summarized in the relevant driver guides. Unless stated otherwise, you can navigate, Sort, Filter, Quick Filter, and Refresh the data on these Lists in the same way as other Queries Lists.


Lists Guide - Display a Queries List (Queries Lists)

Display a Queries List

There are several ways of displaying a Queries List in ClearSCADA.

On a ViewX client, you can display a Queries List from:

  • The Queries Bar (see Display a Queries List from the Queries Bar)
  • The Database Bar (see Display a List from the Database Bar)
  • Another display, such as another List or a Mimic (see Display a List from another Display).

You can also display a Queries List on a WebX client (see View and Action Lists on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients).

If Data Tables or Data Grids exist on your system, you can Display the Data on a Data Grid or Data Table in List Format

While a Queries List is on display, you can perform any of the following to change how the information is displayed on that List:

  • Sort a List
  • Filter a List
  • Quick Filter a List other than an Alarms List
  • Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List
  • Reset the Filters and Sort Order on a List other than an Alarms List
  • Refresh the Data on a List other than an Alarms List.


Lists Guide - Display a Queries List from the Queries Bar (Queries Lists)

Display a Queries List from the Queries Bar

To display a Queries List from the Queries Bar:

  1. Display the Queries Bar (see Explorer Bars used in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Expand the Queries branch if required.
    The tree structure expands to show the available Queries Lists. The entries vary, depending on the drivers that are installed on your system (some drivers support driver-specific Queries Lists, which are included if those drivers are installed).

(To display a Data Grid’s data in List format, expand the Data Grids branch of the Queries Bar.)

  3. Either:
  1. Double-click on the type of Queries List that you want to display.

or:

  1. Right-click on the required type of Queries List.
    A context sensitive menu is displayed.
  2. Select the List option from the menu.

or:

  1. Select the required type of Queries List.
    A context sensitive menu is displayed.
  2. Press the ENTER key on the keypad.

The Filter Columns window is displayed.

  4. Use the Filter Columns window to apply any filter settings as required (see Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List).
  5. Select the OK button on the Filter Columns window to apply any filter(s) and display the List.
    Choose the List you want to display from the Queries Bar...
    ...the selected Queries List will be displayed in ViewX’s document display area.
    ...specify any filters that you require...

To display a List from the Queries Bar without first displaying the Filter Columns window, at step 3 above, either:

  1. Hold down the CTRL key and double-click on the required type of Queries List.

or:

  1. Select the entry for the Queries List that you want to display.
  2. Press the CTRL and ENTER keys simultaneously.

The relevant Queries List is displayed. The List shows all of the items of the selected database type to which you have access. For instance, if you select the Points entry, the List will include every point to which the currently logged on User Account provides access.

(If you select the Objects entry, the resultant List will include all of the database items—points, outstations, channels, Mimics, Groups, Logic Programs, and so on—to which you have access on your system.)


Lists Guide - Display the Data on a Data Grid or Data Table in List Format (Queries Lists)

Display the Data on a Data Grid or Data Table in List Format

If Data Tables or Data Grids exist on your system, you can display their data in List format.

Display such a List on a ViewX client, from either:

  • The Database Bar (see Display a List from the Database Bar)
  • Another display, such as another List or a Mimic (see Display a List from another Display).

You can also display a Data Grid’s List from:

  • The Queries Bar (see Display a Queries List from the Queries Bar).

To display a Data Table or Data Grid List on a WebX client, either:

  1. Display the Objects List (see View and Action Lists on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Apply an appropriate filter to the List (for instance, filter the List to display only database items of Type Data Grid or Data Table). (For more information, see Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List.)
  3. Right-click on the appropriate Data Grid or Data Table entry in the resultant Objects List.
    A context sensitive menu is displayed.
  4. Select the Display option to display the List for that Data Grid or Data Table.

Or:

  1. Display a Mimic on which the relevant Data Table or Data Grid is included (see View a Mimic on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Click on the Data Table or Data Grid.
    If the item is configured to display an Object menu, a context sensitive menu is displayed.
  3. Select the Display option.
    The Data Table or Data Grid List is displayed.

Or:

  1. Embed the Data Grid or Data Table’s List on a Mimic (see Adding Objects to a Mimic in the ClearSCADA Guide to Mimics, and see Example Configuration).
  2. Display the Mimic in order to view the embedded List.

You can change how the information on a Data Table or Data Grid List is displayed, in the same way as you can on other Queries Lists (see Display a Queries List).


Lists Guide - Historic Lists

Historic Lists

ClearSCADA can be configured to store data historically for:

  • Many types of Point
  • Master station Accumulators.

In order for ClearSCADA to store a point’s or accumulator’s data historically, the Historic feature has to be enabled on that point’s or accumulator’s configuration Form. For information on configuring Historic storage for a point, see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration. For information on configuration Historic storage for an accumulator, see Tabs on Accumulator Forms in the ClearSCADA Guide to Core Configuration.

For points and accumulators for which ClearSCADA does store data historically, you can display that data as a Historic List, or a Historic Trend. (For information on Historic Trends, see the ClearSCADA Guide to Trends.)

This section explains how to:

  • Display a Historic List

It also explains how to use the Historic List’s features and interpret the information that a Historic List provides:

  • Work with a Historic List
  • Understand Historic Lists.

Various properties affect the way in which historic information is stored or presented on a ClearSCADA system. Many of these properties can be configured by system administrators and high-level engineers. Such configuration is explained in the following sections within this guide:

  • Set up Historic List Preferences
  • Specify the Preferred List Options on a ViewX Client.


Lists Guide - Display a Historic List (Historic Lists)

Display a Historic List

There are several ways of displaying a Historic List in ClearSCADA.

On a ViewX client, you can display a Historic List from:

  • The Database Bar (see Display a List from the Database Bar).
  • From another display, such as a Mimic or another List (see Display a List from another Display).

In either case, use the Display Historic List menu option or pick action to display the required List. The List will be filtered automatically so that it only shows the historic data for the selected point or accumulator. By default, the entries in the List will be restricted to those values that ClearSCADA has stored as historic data within the last 24 hours (although this default period can be changed on a per-point, and per-accumulator basis).

To display a Historic List on a WebX client, either:

  1. Display an appropriately filtered Points List, or Accumulator List (see View and Action Lists on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Right-click on the Point or Accumulator for which you want to display a Historic List.
    A context sensitive menu is displayed.
  3. Select the Display Historic List option.
    The Historic List is displayed.

Or:

  1. Display a Mimic on which the relevant Point or Accumulator is included (see View a Mimic on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients).
  2. Click on the Point or Accumulator.
    If the item is configured to display an Object menu, a context sensitive menu is displayed.
  3. Select the Display Historic List option.
    The Historic List is displayed.

Or:

  1. Display a Mimic on which the Historic List has been embedded.

NOTE: On a Hot-Standby system, it is possible for a ClearSCADA client to connect to a Standby server rather than the Main server. ClearSCADA allows a client to connect to a Standby server once the server has synchronized its current data with that of the Main server. This is to allow users to access ClearSCADA as soon as possible during the synchronization process. On a client that is connected to a Standby server, if an attempt is made to view a Historic List while that server is still synchronizing its historic database with the Main server, the List’s background will show a series of question marks (?). Data will be displayed once the synchronization process is complete (this may take some time on systems that have a large amount of historic data).

Further Information

Work with a Historic List.

Understand Historic Lists.


Lists Guide - Work with a Historic List (Historic Lists)

Work with a Historic List

A Historic List is in effect a Queries List that displays values that ClearSCADA has stored historically for a point or accumulator.

You can perform the same actions on a Historic List that you can on any Queries List, in order to change how the information is displayed on that List. As with any Queries List, you right-click on an entry on a Historic List in order to display a context sensitive menu. You then select the menu option that you require:

  • Use the Sort option to Sort a List.
  • Use the Filter option to Filter a List.

(You can Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List or Historic List. You have to include a Time filter on a Historic List.)

  • Use the Quick Filter option to filter the List according to any of the values shown on the List (see Quick Filter a List other than an Alarms List).
  • Use the Reset Query option to reset any filtering or sorting back to the default (see Reset the Filters and Sort Order on a List other than an Alarms List).
  • Use the Previous Interval and Next Interval options to display the historic values for the previous or next time intervals respectively. These options work in the same way as the options on an Events List (see Display Events for the Previous or Next Time Interval).

Only those historic values that were logged within a specific time period are initially included on a Historic List. This time period is specified in the Trend/List section on the point or accumulator’s Historic tab. (For information on configuring this time period for a point, see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration. For information on configuring this time period for an accumulator, see Tabs on Accumulator Forms in the ClearSCADA Guide to Core Configuration.)

  • Use the Go To option to display the historic values for a specific time interval. This option works in the same way as the Go To option on an Events List (see Display Events for a Particular Time Interval).
  • Use the Refresh Query option to refresh the data in the List (see Refresh the Data on a List other than an Alarms List).

Further Information

Display a Historic List.

Understand Historic Lists.


Lists Guide - Understand Historic Lists (Historic Lists)

Understand Historic Lists

You can Display a Historic List for an individual point that has Historic Logging enabled, or for an individual master station accumulator.

Each Historic List comprises a series of rows and columns, and contains the data that is stored historically in the ClearSCADA database for that particular point or accumulator. Each row comprises the data for an individual historic record. The column headings indicate what the data in each column represents.

Be aware that ClearSCADA supports historic data compression, whereby unnecessary data can be filtered out so that only those entries that are of interest are stored historically. Compression is mainly used to reduce storage requirements for historic data, and is typically used with points on simple drivers rather than advanced drivers. For more information on compressing point data, see Historic Data Compression in the ClearSCADA Guide to Core Point Configuration. For information on compressing accumulator data, see Tabs on Accumulator Forms in the ClearSCADA Guide to Core Configuration. There are some updates to which compression settings do not apply—ClearSCADA logs such updates historically regardless of any compression settings (see Point Updates to which Compression Settings do not Apply in the ClearSCADA Guide to Core Point Configuration; and see Accumulator Updates to which Historic Data Compression Settings do not Apply in the ClearSCADA Guide to Core Configuration). You can determine why ClearSCADA has stored an update historically by looking at the Historic List for the point or accumulator.

The column headings for a Historic List are:

  • Time—The date and time at which the data was recorded.

There are many factors that affect the time stamp of a record, primarily the driver. With some drivers, the outstation time stamps the data and then passes that data to ClearSCADA. With other drivers, the time stamp might be generated by the outstation or the server, depending how the data was reported. Outstations on some drivers do not support time stamping of data, and therefore the server time stamps that data when it receives it from the outstation. Historic records that are logged due to actions such as Override and Release Override are time stamped by the server.

  • Value—The recorded value of the point or accumulator.
  • State—The recorded state of the point or accumulator.
  • Quality—A description of the quality of the data. This indicates the reliability of the data. Descriptions within this column might include:
  • Good—The quality of the data that has been logged is good.
  • Local Override—The data that has been logged is for a value that has been locally overridden at the ClearSCADA server. (Some drivers also support overriding of point values at the outstation.)
  • High : Engineering Units Exceeded—The data has been logged while an analog point was over range (the value exceeded the point’s Full Scale limit).
  • Low : Engineering Units Exceeded—The data has been logged while an analog point was under range (the value was below the point’s Zero Scale limit).

(Most drivers only map to a subset of OPC qualities, depending on what information they are capable of reporting. The reason for a historic record having a particular quality is typically down to the individual driver and how it maps the information available to it onto the standard OPC Qualities.)

  • Reason—The reason why the data is being stored (‘logged’) historically. Possible reasons for logging include:
  • Current Data—The data has been logged due to a request for the point or accumulator’s current data.
  • Value Change—The data has been logged due to a significant change in point or accumulator value. (Typically due to a change in value exceeding a Significant Change deadband, although some drivers interpret value changes differently.)
  • State Change—The data has been logged due to a change in point state.
  • Timed Report—Only applies if timed reporting (‘background Logging’) is supported by, and configured for, the point or accumulator. The data has been logged due to the timed report interval expiring.
  • End of Period—Only applies if End of Period reporting is supported by, and configured for, the point or accumulator. The data has been logged due to the End of Period report interval expiring.
  • End of Period Reset—Only applies if resetting of values at an End of Period interval is supported by, and configured for, the point or accumulator. The data has been logged due to an End of Period reset.
  • Override—The data has been logged due to the point’s value being overridden.
  • Release Override—The data has been logged due to an existing Override being released.
  • Modified/Inserted—The data was either inserted or modified.

The Insert/Modify Data option can be used to insert or modify a point or accumulator value on a Historic Trend. This is useful if data was not recorded for some reason, or a value that has been recorded historically is inaccurate (for instance, due to an instrument fault). For more information, see Insert a Value on a Historic Trend in the ClearSCADA Guide to Trends, and see Modify a Value on a Historic Trend in the ClearSCADA Guide to Trends.

  • Status—A description of the status of the data, as a comma- separated list. Applies to Historic Point Lists only. A Status entry might indicate, for instance, that:
  • The point was overridden at the master station (ClearSCADA server). (Advanced drivers only.)
  • The time that the data was recorded was in the future. (Advanced drivers only.) Such a status indicates that the data is from a device that has different time settings to the server. For example, an outstation that has not had its clock set correctly, or that has a clock which is fast. For more information, see Define the Maximum Outstation Clock Drift in the ClearSCADA Guide to Server Administration.

A driver-specific status description might be displayed for points on some drivers.


Lists Guide - Set up Events List Preferences

Set up Events List Preferences

This section is for system administrators and high-level engineers who are setting up the preferences for Events Lists on either a system-wide, client-specific, or user-specific basis (see Set up the List Preferences).

ClearSCADA is supplied with a set of predefined defaults for the Event Journal and Events Lists. These affect, for example, the columns that are included on an Events List. If required, these options can be changed from the defaults. Some of these options affect Events Lists on a system-wide basis, whereas other options can be specified on a per-client (workstation) basis, or on a per-user basis.

(ClearSCADA logs events in the Event Journal. You can view these events by displaying the Events Lists.)

This section summarizes the properties you might want to consider when setting up:

  • System-Wide Events List and Event Journal Preferences
  • Client-Specific Events List Preferences
  • User-Specific Events List Preferences.

In addition to the above, be aware that you can configure Historic Regions to stop events that have been logged within a specific time period from being deleted from the system. Such events are retained online and can be displayed on Events Lists. You configure Historic Regions using the ClearSCADA Server Configuration Tool (see Historic Regions in the ClearSCADA Guide to Server Administration).


Lists Guide - System-Wide Events List and Event Journal Preferences (Set up Events List Preferences)

System-Wide Events List and Event Journal Preferences

This section summarizes those Events List or Event Journal options that a system administrator can configure on a system-wide basis. Some of the options are specific to Events Lists, whereas others affect the Event Journal. Some options affect other areas of ClearSCADA in addition to Events Lists or the Event Journal. Such options, if required to differ from the defaults, should be specified on each server when a ClearSCADA system is first installed. The options are specified using the ClearSCADA Server Configuration Tool.

You can use the ClearSCADA Server Configuration Tool to:

  • Specify the Alarms section settings, including:
  • Whether events are actually logged on your system. (When enabled (the default), ClearSCADA logs events in the Event Journal. Any of these events can be viewed in list format, by displaying an Events List.)
  • Whether the ‘Area of Interest’ feature is enabled on your system. (For more information on this feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.)

For more information, see Alarms Settings in the ClearSCADA Guide to Server Administration.

  • Specify the Events List columns that are included in the Events Lists on your system, and the number of Events List columns that remain at a fixed size (see Events Display Settings for the Event Journal (Events List) in the ClearSCADA Guide to Server Administration).
  • Specify the Location of the database files, including the Event Journal (see Locations of the Database Folders in the ClearSCADA Guide to Server Administration).
  • Specify the Historic Configuration settings, including the amount of time for which Event Journal messages are kept online (see Historic Configuration Settings in the ClearSCADA Guide to Server Administration).

To access a ClearSCADA system, users typically log on via a User Account. Anyone who accesses the system without logging on, is logged on automatically via the Guest or Web User accounts.

Use the Root or System Group Form to define the system-wide settings for the Guest User, including:

  • The default Event List Range.
  • If the Area of Interest feature is used on your system, any Area of Interest Filters. (This can affect which events are visible to the Guest User.)

For information on configuring either of the above, see Define the Global Settings for All Guest and Web User Accounts in the ClearSCADA Guide to Security.


Lists Guide - Client-Specific Events List Preferences (Set up Events List Preferences)

Client-Specific Events List Preferences

This section summarizes those Events List options that a system administrator can configure on a per client basis. Such options, if required to differ from the defaults, should be specified on existing clients (workstations) when a ClearSCADA system is first installed, and then on new clients whenever they are added to the system. On each client, you specify the options using the Options window (available from the ViewX Tools menu).

You can use the Options window to specify:

  • The format in which Lists are to be displayed on that particular client (see Specify the Preferred List Options on a ViewX Client).

For anyone that accesses the system without logging on via a User Account, use the Options window to define the client-specific Features that are available to the Guest User, including:

  • Operational features, such as whether the Guest User actually has access to Events Lists on that particular client (see Define the Client Specific Settings for the Guest User in the ClearSCADA Guide to Security).


Lists Guide - User-Specific Events List Preferences (Set up Events List Preferences)

User-Specific Events List Preferences

This section summarizes those Events List options that a system administrator can configure on a per-user basis. The options apply to users that log onto the system using a User Account.

The options for each individual User Account, if they are to differ from the defaults, should be specified once that User Account has been added to the system.

For a user that logs onto the system using an individual User Account, use that user’s User Form to:

  • Specify the default Event List Range. This defines the time period for which events are initially displayed on the Events List.
  • If the Area of Interest feature is used on your system, specify any Area of Interest Filters associated with the user. This can affect which events are visible to the user.
  • For users that are accessing the system via a ViewX client (as opposed to WebX), you can specify Operational features, including whether the user actually has access to Events Lists.

For information on configuring any of the above, see Creating a User Account in the ClearSCADA Guide to Security.


Lists Guide - Set up Queries List Preferences

Set up Queries List Preferences

This section is for system administrators and high-level engineers who are setting up the preferences for Queries Lists on either a system-wide, client-specific, or user-specific basis (see Set up the List Preferences).

ClearSCADA is supplied with a set of predefined defaults for Queries Lists. These affect, for example, the List header colors. If required, these options can be changed from the defaults. Some of these options affect Queries Lists on a system-wide basis, whereas other options can be specified on a per-client (workstation) basis, or on a per-user basis.

This section summarizes the properties you might want to consider when setting up:

  • System-Wide Queries List Preferences
  • Client-Specific Queries List Preferences
  • User-Specific Queries List Preferences.


Lists Guide - System-Wide Queries List Preferences (Set up Queries List Preferences)

System-Wide Queries List Preferences

To access a ClearSCADA system, users typically log on via a User Account. Anyone who accesses the system without logging on, is logged on automatically via the Guest or Web User accounts.

Use the Root or System Group Form to define the system-wide settings for the Guest User, including:

  • The Regional Settings, that define, for instance, the format in which dates and times are displayed on Lists. For more information, see Define the Global Settings for All Guest and Web User Accounts in the ClearSCADA Guide to Security.


Lists Guide - Client-Specific Queries List Preferences (Set up Queries List Preferences)

Client-Specific Queries List Preferences

This section summarizes those Queries List options that a system administrator can configure on a per client basis. Such options, if required to differ from the defaults, should be specified on existing clients (workstations) when a ClearSCADA system is first installed, and then on new clients whenever they are added to the system. On each client, you specify the options using the Options window (available from the ViewX Tools menu).

You can use the Options window to specify:

  • The format in which Lists are to be displayed on that particular client (see Specify the Preferred List Options on a ViewX Client).

For anyone that accesses the system without logging on via a User Account, use the Options window to define the client-specific Features that are available to the Guest User, including:

  • To which Explorer Bars the Guest User has access on that particular client. This includes whether or not they can access the Queries Bar from which Queries Lists can be displayed. For more information, see Define the Client Specific Settings for the Guest User in the ClearSCADA Guide to Security).


Lists Guide - User-Specific Queries List Preferences (Set up Queries List Preferences)

User-Specific Queries List Preferences

This section summarizes those Queries List options that a system administrator can configure on a per-user basis. The options apply to users that log onto the system using a User Account.

The options for each individual User Account, if they are to differ from the defaults, should be specified once that User Account has been added to the system.

For a user that logs onto the system using an individual User Account, use that user’s User Form to specify:

  • The Regional Settings, including the format in which dates and times are displayed on Lists.
  • The Explorer Bars to which the user has access. This includes whether or not they can access the Queries Bar from which Queries Lists can be displayed.

For more information on either of the above, see Creating a User Account in the ClearSCADA Guide to Security.


Lists Guide - Set up Historic List Preferences

Set up Historic List Preferences

This section is for system administrators and high-level engineers who are setting up the preferences for Historic Lists on either a system-wide, or client-specific basis (see Set up the List Preferences).

ClearSCADA is supplied with a set of predefined defaults for Lists. These affect, for example, the List header colors. If required, these options can be changed from the defaults. Some of these options affect Lists on a system-wide basis, whereas other options can be specified on a per-client (workstation) basis.

This section summarizes the properties you might want to consider when setting up:

  • System-Wide Historic List Preferences
  • Client-Specific Historic List Preferences
  • User-Specific Historic List Preferences.

Remember that ClearSCADA will only store point or accumulator data historically if the Historic feature is enabled on that point’s or accumulator’s configuration Form. For information on configuring Historic storage for a point, see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration. For information on configuration Historic storage for an accumulator, see Tabs on Accumulator Forms in the ClearSCADA Guide to Core Configuration.

In addition to the above, be aware that you can configure Historic Regions to stop historic data that has been logged within a specific time period from being deleted from the system. Such data is retained online and can be displayed on Historic Lists. You configure Historic Regions using the ClearSCADA Server Configuration Tool (see Historic Regions in the ClearSCADA Guide to Server Administration).


Lists Guide - System-Wide Historic List Preferences (Set up Historic List Preferences)

System-Wide Historic List Preferences

This section summarizes those options that affect Historic Lists on a system-wide basis. Such options, if required to differ from the defaults, should be specified on each server when a ClearSCADA system is first installed. The options are specified using the ClearSCADA Server Configuration Tool.

You can use the ClearSCADA Server Configuration Tool to specify:

  • The Historic Data settings, including the duration for which historic data is retained online, and the maximum number of records that can be returned in a historic query (see Historic Data Storage Settings in the ClearSCADA Guide to Server Administration).
  • The Location at which ClearSCADA stores historic data (see Locations of the Database Folders in the ClearSCADA Guide to Server Administration).


Lists Guide - Client-Specific Historic List Preferences (Set up Historic List Preferences)

Client-Specific Historic List Preferences

This section summarizes those options that affect Historic Lists on a per client basis. Such options, if required to differ from the defaults, should be specified on existing clients (workstations) when a ClearSCADA system is first installed, and then on new clients whenever they are added to the system. On each client, you specify the options using the Options window (available from the ViewX Tools menu).

You can use the Options window to specify:

  • The format in which Lists are to be displayed on that particular client (see Specify the Preferred List Options on a ViewX Client).

For anyone that accesses the system without logging on via a User Account, use the Options window to define the client-specific Guest User settings including:

  • The Date Format that defines how dates and times are displayed on any Lists that the Guest User accesses. For more information, see Define the Client Specific Settings for the Guest User in the ClearSCADA Guide to Security).


Lists Guide - User-Specific Historic List Preferences (Set up Historic List Preferences)

User-Specific Historic List Preferences

This section summarizes those options that affect Historic Lists on a per-user basis. The options apply to users that log onto the system using a User Account.

The options for each individual User Account, if they are to differ from the defaults, should be specified once that User Account has been added to the system.

For a user that logs onto the system using an individual User Account, use that user’s User Form to specify:

  • The Regional Settings, including the format in which dates and times are displayed on Lists (see Creating a User Account in the ClearSCADA Guide to Security).


Lists Guide - Specify the Preferred List Options on a ViewX Client

Specify the Preferred List Options on a ViewX Client

ClearSCADA is supplied with a set of predefined defaults that affect the appearance of Lists and the Alarm Banner on ViewX clients (workstations). These defaults determine the fonts, header colors, and any grid lines that ClearSCADA uses when displaying the Alarm Banner or any type of List on a ViewX client. Such Lists include Alarms Lists, Events Lists, Queries Lists (such as the Points List), Historic Lists, and any custom Lists.

If required, a system administrator or high-level engineer can change these properties from the defaults, on a per-client basis.

To change the default properties of Lists and the Alarm Banner on a ViewX client:

  1. Log on via a User Account that has the Configure Options feature enabled.
  2. Select the Tools menu.
    A further menu is displayed.
  3. Select Options.
    The Options window is displayed.
  4. Select the Lists tab.
    The properties on the Lists tab...
    ...determine the fonts, List header colors, and the properties of any grid lines used in Lists and the Alarm Banner.

  5. Use the relevant sections on the Lists tab to:
  • Specify the Properties of the Font used in List Rows
  • Specify the Properties of the Font used in List Headers
  • Specify the Colors used in List and Alarm Banner Headers
  • Specify the Properties of any Grid Lines.
  6. Select the OK button to confirm the changes and close the Options window.
  7. Repeat the above steps for any other ViewX clients on which the properties are to differ from the defaults.

Further Information

Other Properties that Affect a List’s Format.

Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client in the ClearSCADA Guide to Alarms.


Lists Guide - Specify the Properties of the Font used in List Rows (Specify the Preferred List Options on a ViewX Client)

Specify the Properties of the Font used in List Rows

This section only applies to Lists—for information on changing the font properties of the Alarm Banner, see Specify the Properties of the Font used for the Alarm Banner in the ClearSCADA Guide to Alarms.

Use the Row Font section on the Option window’s Lists tab to specify the properties of the font used in List rows:

  • Font—Use the combo box to display a list of the fonts that are available to this particular client. Select the required font from the list.
  • Height—Use the spin box to specify the required font height. The default is 8 points.
  • Bold—Select this check box for the text in the List’s rows to be bold. Clear the check box for the text’s weight to be regular.
  • Italic—Select this check box for the text in the List’s rows to be italic. Clear the check box for the text’s angle to be regular.

Once you have confirmed the settings, you will need to close and re-open any Lists that are presently on display, in order for the changes to take effect on those Lists.


Lists Guide - Specify the Properties of the Font used in List Headers (Specify the Preferred List Options on a ViewX Client)

Specify the Properties of the Font used in List Headers

This section only applies to Lists—for information on changing the font properties of the Alarm Banner, see Specify the Properties of the Font used for the Alarm Banner in the ClearSCADA Guide to Alarms.

Use the Header Font section of the Option window’s Lists tab to specify the properties of the font used in List headers:

  • Font—Use the combo box to display a list of the fonts that are available to this particular client. Select the required font from the list.
  • Height—Use the spin box to specify the required font height. The default is 8 points.
  • Bold—Select this check box for the text in the List’s headers to be bold. Clear the check box for the text’s weight to be regular.
  • Italic—Select this check box for the text in the List’s headers to be italic. Clear the check box for the text’s angle to be regular.

Once you have confirmed the settings, you will need to close and re-open any Lists that are presently on display, in order for the changes to take effect on those Lists.


Lists Guide - Specify the Colors used in List and Alarm Banner Headers (Specify the Preferred List Options on a ViewX Client)

Specify the Colors used in List and Alarm Banner Headers

Use the Header Colors section on the Option window’s Lists tab to specify the colors used in the header cells of Lists and the Alarm Banner:

  • Text—Use to specify the color of the text that is displayed in the header cells (column headings).
  • Face—Use to specify the background color of the header cells.
  • Highlight—Use to specify the color of the highlight line that is displayed to the top and left of each header cell.
  • Shadow—Use to specify the color of the shadow line that is displayed below and to the right of each header cell.
  • Dark Shadow—Use to specify the color of the dark shadow line that is displayed below and to the right of each List’s header cell.

(The Alarm Banner’s header cells only include a Dark Shadow if the Alarm Banner is set to Allow Sorting (see Specify the Preferred Alarm Banner and Alarms List Options on a ViewX Client in the ClearSCADA Guide to Alarms).)

To change any of the above:

  1. Click on the color that you want to change.
    A pop-up color window is displayed.
  2. Either:
  1. Select a color from the palette.

Or:

  1. Select the ... option.
    The Color window is displayed.
  2. Use the Color window to define a color (see Using the Color Window in the ClearSCADA Guide to Core Configuration).
  3. Select OK to close the Color window.
  3. Repeat the above steps for any other color that you want to change.
  4. Select the OK button at the bottom of the window to confirm the changes and close the Options window.

Example:

A ViewX client with this Header Color configuration:

Will result in List header cells that have these couloirs

Text color
Highlight color
Face color
Shadow color
Dark Shadow color


Lists Guide - Specify the Properties of any Grid Lines (Specify the Preferred List Options on a ViewX Client)

Specify the Properties of any Grid Lines

This section applies to Lists other than Alarms Lists.

Use the Grid Lines section on the Option window’s Lists tab to specify these properties:

  • Size—Use to specify the line thickness of grid lines used to separate cells on Lists other than Alarms Lists. The default is 1.

If required, either specify a different line thickness, or specify 0 for grid lines to be excluded from any Lists that are displayed on that particular ViewX client.

  • Color—Use to specify the color of the grid lines that separate the cells in Lists other than Alarms Lists.

Click on the color if you want to change it. A pop-up color window is displayed. Either select a color from the window, or select the ... option and create a custom color (see Using the Color Window in the ClearSCADA Guide to Core Configuration).

Example:

On a particular ViewX client, grid lines are configured as cyan:

Changing the Grid Lines’ Color in the Options window...
...alters the color of the grid lines in Lists, such as the Events List.


Lists Guide - Other Properties that Affect a List's Format (Specify the Preferred List Options on a ViewX Client)

Other Properties that Affect a List’s Format

This section summarizes other properties that affect a List’s format, and provides references to the sections that explain such properties in more detail. This section contains information on The Color of Entries in a List other than the Alarms List.


Lists Guide - The Color of Entries in a List other than the Alarms List (Specify the Preferred List Options on a ViewX Client)

The Color of Entries in a List other than the Alarms List

The color that ClearSCADA uses for displaying an entry in a List is determined by that entry’s state and, in the case of a Queries List, any actions that are being performed on, or associated with, the item. The exception to this is any ‘custom’ Lists (see Custom Lists) or high-level ‘standard’ Lists that have not been configured to use the relevant database table’s Foreground, Background, and Blink fields to control each List entry’s color (for example, PSTN Call Statistics Lists do not use these fields).

Any entry in an Events List that relates to an alarm is displayed using the appropriate Severity color. Otherwise, the entry is displayed using the ‘Normal’ System color.
Any item in a Queries List that in is an alarm state is displayed using the corresponding Severity color. Otherwise, the entry is displayed using the System color that indicates its present status. In the case of Points and Forecasts, if no other status takes precedence, the entry is displayed using the appropriate State color.

Further Information

Severity Colors: see Alarm and Event Severities in the ClearSCADA Guide to Server Administration.

System Colors: see System Colors in the ClearSCADA Guide to Core Configuration.

Point and Forecast State Colors: see Defining a Custom State Color in the ClearSCADA Guide to Core Configuration.

It is possible to ‘customize’ Lists so that only the entries in certain column(s) change color (see Lists in Which only the Entries in Particular Columns Change Color).

Colors used in Alarms Lists: see Other Properties that Affect an Alarms List or Alarm Banner’s Format in the ClearSCADA Guide to Alarms.


Lists Guide - Specify Whether Simple Events are Displayed in the Status Bar

Specify Whether Simple Events are Displayed in the Status Bar

‘Tracking’ events—events that track activities that affect the system—are displayed in the status bar as they occur, in addition to being logged in the Event Journal. ‘Tracking’ events include, for example, events that are generated by user interaction with the system, such as changing an item’s configuration, or hand controlling a point. External interactions with the system are also categorized as ‘tracking’ events, as are redirection activities.

‘Tracking’ type events are displayed in the status bar. (This particular event indicates that a scanner’s configuration has been changed.)

‘Condition’ events—events that are associated with alarms—are not displayed in the status bar.

By default, ‘simple’ events—events that do not fall into the ‘tracking’ or ‘condition’ event categories (such as point state change events) are excluded from the status bar. This is to reduce loading on the server (the server only sends such events to a client should an Events List in which such events are included be displayed on that client).

Although we do not recommend it, you can select the Include Simple Events in Status Bar check box on the Alarm Banner tab of the Options window, to include such events in the status bar. (To access the Options window, you need to be logged onto ViewX via a User Account that has the Configure Options feature enabled. Display the Options window by selecting the Tools menu, followed by Options.)

Be aware that by selecting the Include Simple Events in Status Bar check box, the loading on the server will increase, as each event that is generated (other than a ‘condition’ event) will get sent to the client, in order to appear in the status bar’s message area.

On systems on which a large number of events are generated, this could result in substantial loading on the server.

ATTENTION: On systems that have a large number of ViewX clients, selecting this check box on each client may result in the system being temporarily un-responsive should many thousands of events be generated.


Lists Guide - Custom Lists

Custom Lists

ClearSCADA provides access to many types of List (see Welcome to the ClearSCADA Guide to Lists). Each List is automatically filtered so that it only includes the alarms, events, historic records, or items that are relevant to the specific area of the database from which the List is displayed. If some of the Lists on your system regularly require further filtering in order to restrict their content to those entries that are of interest, consider whether to ‘customize’ those Lists. By ‘customizing’ Lists, you can provide access to such Lists without the need for further filtering each time that the List is displayed.

You can create ‘custom’ Lists in ClearSCADA by:

  • Embedding Lists in Mimics—You can embed a Queries List in a Mimic, and then use an SQL query to define the content of that List. For instance, you can specify which database table ClearSCADA is to query, which fields you want the List to include, and the order in which the data is to be displayed in columns on that List.

Consider embedding Lists in Mimics if more than one user frequently needs to access information in List format, and such access would otherwise require much manual filtering of a List.

For further information, see Using SQL to Customize Lists. For examples that demonstrate how you might create ‘custom’ Lists, including by embedding Lists in Mimics, see Example Configuration.

  • Using Favorites—If only one user needs to access a List that requires several filters to restrict its content, and that user’s User Account provides access to the Favorites Bar, they can filter the List as required and then add it to their list of Favorites. Whenever they display the List from the Favorites Bar, it will be filtered automatically.

Consider using Favorites as an alternative to other means of ‘customizing’ Lists, if only one user needs access to such Lists. For more information on using Favorites, see Favorites Bar in the ClearSCADA Guide to ViewX and WebX Clients.

  • Adding custom pick actions to provide access to specific Lists—A system administrator can add extra Table Queries to the server, in order to provide access to Queries Lists that provide specific information. Each ‘custom’ List that is added to the system in this way is associated with a particular database table. As such, a custom pick action is associated with each item in that database table. Whenever a menu associated with that item is displayed, the custom pick action is included. The pick action provides access to the ‘custom’ List. As with Queries Lists that you embed on Mimics, you can use an SQL query to define the content of each List.

Consider adding extra Table Queries if you want to provide access to specific information in List format, and you want every item associated with a particular database table to provide access to such a List. For more information, see Extra Table Queries in the ClearSCADA Guide to Server Administration, and see Using SQL to Customize Lists. For an example that demonstrates Table Queries, see A Custom Pick Action to Display a List of Out of Service Points.

Be aware that you will need to restart the server for any extra Table Queries to come into effect.

You can also temporarily customize a List that is not embedded in a Mimic, by altering the SQL query that is being used to display that List. However, be aware that any changes to the SQL query are lost as soon as the List is closed.


Lists Guide - Using SQL to Customize Lists (Custom Lists)

Using SQL to Customize Lists

In ClearSCADA, the entries in Lists other than Alarms Lists comprise those records that are the result of an SQL query.

SQL is a standardized language used for requesting data from databases. An SQL query can filter, sort, and group data from any table in the database. An SQL query minimizes the loading of any request for data by only retrieving those records that are of interest, rather than all of the records in the database.

In order to customize Lists successfully, you need to:

  • Carry out the necessary Preparation.
  • Be able to Ascertain which SQL Query is Presently used by a List.
  • Understand the SQL Query Structure.
  • Be aware of Fields that Perform Special Functions.

For examples that demonstrate how to customize Lists using an SQL query, see Example Configuration.


Lists Guide - Preparation (Custom Lists)

Preparation

ATTENTION: Any SQL queries for ‘custom’ Lists should be written by engineers who have the appropriate experience and knowledge of the SQL language. Running a badly designed SQL query can have an adverse affect on the system. All queries should include suitable restrictions to limit the number of records that are retrieved from the database. An SQL query that queries vast amounts of data will affect the performance of the server while that query executes.

In order to reference the relevant database tables and include the required data in any custom Lists:

  • You need to be familiar with the ClearSCADA database structure and naming conventions. This information is covered in detail in the ClearSCADA Guide to the Database.
  • You should have the appropriate experience and knowledge of the SQL language. Some basic information is included in this section. Also see the SQL Technical Reference online Help.

In order to embed Lists successfully in Mimics, in addition to the above, you also need to be familiar with the principles of Mimic configuration in ClearSCADA. This is covered in detail in the ClearSCADA Guide to Mimics. In particular:

  • see Embed a Queries List on a Mimic
  • see Embed an Alarms List on a Mimic
  • see Editing an Embedded Query List
  • see Editing an Embedded Alarms List.

(Each of the above are references to sections in the ClearSCADA Guide to Mimics.)

In order to add extra Table Queries successfully in ClearSCADA, in addition to the bullet points listed at the start of this section, you need to be familiar with the syntax that ClearSCADA supports for Table Queries (see Extra Table Queries in the ClearSCADA Guide to Server Administration).


Lists Guide - Ascertain which SQL Query is Presently used by a List (Custom Lists)

Ascertain which SQL Query is Presently used by a List

An SQL query is used to define the entries in Lists other than Alarms Lists. To display the SQL query that is presently used by a List:

  1. Display the List in ViewX (see Display a List).
  2. Select the View menu.
    A drop-down menu is displayed.
  3. Select the SQL option.
    The SQL query that is used for that particular query is displayed in an SQL window.

(To display the SQL query that is presently used by a List that is embedded on a Mimic, ensure that the Mimic is being displayed in Design mode (see Displaying a Mimic in the ClearSCADA Guide to Mimics). Double-click on the List to display the Embedded List Properties window, then select the Query tab to view the SQL query that is being used for that List.)

Example:

The Display Points pick action is used to display a List of the points that are associated with a particular DNP3 outstation.

The SQL window is displayed in order to ascertain the SQL query that is being used to display the entries in that particular List.

The SQL window shows that the SQL query returns a series of fields (listed below the SELECT clause) from the ClearSCADA Point Table CDBPoint. The SQL retrieves only those records that pertain to the database item ‘Direct Outstation 1’ within the ‘DNP3 Direct’ Group, which is itself in the ‘DNP3 Group’ (as defined by the WHERE clause). Finally, the returned data is displayed in ascending order (ASC), by full name.

(The Id, Foreground, Blink, and Background fields are ‘special’ fields that are not presented as columns in the List.)

The WHERE Clause is the SQL that is used for the List’s filters—this can also be determined by right-clicking on the List and selecting the Filter option to display the Filter Columns window:

The List’s Filter Columns window displays the simplified version of the filter that is defined by the WHERE Clause.

(You can select the Advanced button on the Filter Columns window to show the actual WHERE Clause, and edit that clause if required (see Use SQL to Create a Filter for a List other than an Alarms List).)

The ORDER BY Clause is the SQL that is used to determine the List’s sort order—this can also be determined by right-clicking on the List and selecting the Sort option to display the Sort Order window:

The List’s Sort Order window displays the simplified version of the sorting that is defined by the ORDER BY Clause.

Be aware that if you change the SQL on a List that is not embedded in a Mimic, any changes will be lost as soon as that List is closed.

Further Information

SQL Query Structure.

Fields that Perform Special Functions.


Lists Guide - SQL Query Structure (Custom Lists)

SQL Query Structure

ATTENTION: Any SQL queries for ‘custom’ Lists should be written by engineers who have the appropriate experience and knowledge of the SQL language. Running a badly designed SQL query can have an adverse affect on the system. All queries should include suitable restrictions to limit the number of records that are retrieved from the database. An SQL query that queries vast amounts of data will affect the performance of the server while that query executes.

In order to retrieve data from the ClearSCADA database and display that data in a List, you use an SQL SELECT query.

The basic format that such a query takes is as follows:

SELECT
<field>, <field>, <field>
FROM
<database table>
WHERE
<field> = 'Value'
ORDER BY
<field>

For a brief overview of each SQL clause, see the following sections:

  • SELECT Clause
  • FROM Clause
  • WHERE Clause
  • ORDER BY Clause.

Be aware that you may also want to consider including other clauses, such as the GROUP BY clause, and the HAVING clause in your SQL query. For information on these clauses, and for more detailed information on SQL, see the SQL Technical Reference online Help.

NOTE: ‘Custom’ Lists with complex queries that include, for example, summary functions (SUM) and/or GROUP BY clauses, only update when a Refresh is issued (see Refresh the Data on a List other than an Alarms List). A Refresh is required if there is no one-to-one correlation between the entries on a List and the Ids or RecordIds that would otherwise identify the records in the ClearSCADA database.


Lists Guide - SELECT Clause (Custom Lists)

SELECT Clause

In its simplest form, the SELECT clause takes the form of a comma-separated list of the fields that you want to retrieve from the database. The fields that you specify in this clause have to exist in the table that you specify in the FROM clause (which defines the database table from which you want to retrieve the data).

Most of the retrieved fields are presented as columns in the resultant List. However, some database fields have a special role (see Fields that Perform Special Functions), and as such are not actually displayed as columns in the resulting List. You need to be aware of which ‘special’ fields you need to include in the comma-separated list, in order to obtain the List results and functionality that you require.

Specify the fields in the SELECT clause in the order in which you want those fields to be displayed as columns in the resultant List. (The exceptions to this are the ‘special’ fields which are not displayed as columns in the resultant List, and any fields that you prefix with an underscore (see below).)

In the SELECT clause, include the fields that you want to use in the SQL query’s ORDER BY (and GROUP BY) clauses.

If you need to include a field in the SELECT clause, but do not want that field to be displayed in the resultant List, assign an alias to that field and prefix the alias with an underscore (_). The syntax for this is:

<field> AS "_<alias>"

(with the field’s alias enclosed in double straight quotation marks)

Example:

"CurrentQualityDesc" AS "_CurrentQualityDesc"

To retain a column as a ‘fixed’ column, so that it remains on view whenever the horizontal scroll bar is used on a List, assign an alias to the field that represents that column, and prefix the alias with a tilde (~). The syntax for this is:

<field> AS "~<alias>"

(with the field’s alias enclosed in double straight quotation marks)

Example:

The ‘Name’ column on a List is to remain on view whenever a user scrolls across the List data.

The ‘Name’ column is displayed by specifying the FullName database field. (‘Name’ is the field’s display name—the string that is displayed in the language that is associated with the logged on user’s specified Locale.)

To ensure that the column remains on view, the SELECT clause includes this syntax:

"FullName" AS "~FullName"

To right-align a column’s content, assign an alias to the field that represents that column, and prefix the alias with the ‘greater than’ sign (>). The syntax for this is:

<field> AS "><alias>"

(with the field’s alias enclosed in double straight quotation marks)

Example:

The entries in the ‘Value’ column on a Points List are to be right-aligned.

The ‘Value’ column is displayed by specifying the CurrentValueFormatted database field. (‘Value’ is the field’s display name—the string that is displayed in the language that is associated with the logged on user’s specified Locale.)

To right-align the ‘Value’ column’s content, the SELECT clause includes this syntax:

"CurrentValueFormatted" AS ">CurrentValueFormatted"

By default, column headings are displayed as a single line. For column headings to span multiple lines in a List, assign an alias to the field that represents a column, and insert \n within the alias, at each point at which the heading is to continue onto a separate line.

Example:

The heading for the ‘Number of Updates’ column on a Points List is to span multiple lines.

The ‘Number of Updates’ column is displayed by specifying the ProcessCount database field. (‘Number of Updates’ is the field’s display name—the string that is displayed in the language that is associated with the logged on user’s specified Locale.)

For the heading to span a second line, the SELECT clause includes this syntax:

"CProcessCount" AS "Numberof\nUpdates"

This results in the text ‘Number of’ appearing on one line, with ‘Updates’ appearing on the line below.

You can also use the SELECT Clause to assign color properties to specific fields. This enables you to:

  • Control the number of columns in which entries change color
  • Specify the color attributes that determine the color of those entries.

For more information, see Lists in Which only the Entries in Particular Columns Change Color.

Whenever you assign as alias to a field, you have to specify that alias, rather than the field name, in any WHERE, ORDER BY, or GROUP BY clauses.

For further information on the SELECT clause, and for more detailed information on SQL in general, see the SQL Technical Reference online Help.


Lists Guide - FROM Clause (Custom Lists)

FROM Clause

Use the FROM clause to specify the database table(s) from which you want your List to display data. You can use the FROM clause in its simplest form to query a single database table (as in the example below), or you can use the clause to perform more complex actions, such as joining two or more database tables.

Example:

To display data from the database points table, you might specify:

FROM
CDBPOINT

(To restrict the List to only those points that belong to a particular group, or that are of a particular point type, use the WHERE Clause to restrict the data that is retrieved from the table.)

For further information on the FROM clause, and for more detailed information on SQL in general, see the SQL Technical Reference online Help.

For a list of the ‘standard’ database tables on your system, expand the Tables entry (or, if applicable, the Data Grids entry) on the Queries Bar in ViewX. Alternatively, use the Database Schema. The Schema also includes information on historic pseudo tables and user defined tables. Such tables include:

  • CDBEventJournal—The Event Journal.
  • CDBHistoric—Point and Accumulator historic data.
  • CForecastHistoric—Forecast historic data.
  • Data Grid tables—(These are user defined tables (see Configuring Data Grids in the ClearSCADA Guide to Core Configuration).)
  • Data Table tables—(These are user defined tables (see Configuring Data Tables in the ClearSCADA Guide to Core Configuration).)
  • Historic Views—(These are user defined tables (see Historic Views in the ClearSCADA Guide to Server Administration).)

For information on database tables in general, see the ClearSCADA Guide to the Database.

For information on using the database Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.


Lists Guide - WHERE Clause (Custom Lists)

WHERE Clause

Use the WHERE clause to further restrict the number of records that are retrieved from the database to only those that are of interest. The clause typically takes the form of one or more ‘conditions’. Only those records that meet one or more of the conditions are retrieved from the specified database table.

Examples:

A List that displays only those points that are associated with a particular outstation, might use this type of syntax within its SELECT query:

FROM
CDBPOINT
WHERE
"SourceName" = 'My Group.My Outstation'

A List that displays only those database items that are associated with a particular group, might use this type of syntax within its SELECT query:

FROM
CDBOBJECT
WHERE
"~FullName" LIKE 'My Group.%'

(The % is a ‘wildcard’ used to denote a variable number of characters. (The wildcard to denote a single unknown character is an underscore (_).)

When querying the CDBEventJournal, CDBHistoric or CForecastHistoric tables, you must specify a time constraint, to restrict the entries in the List to those that occurred within a particular time period. Such a List might include this type of syntax within its SELECT query:

FROM
CDBEVENTJOURNAL
WHERE
"~RecordTime" BETWEEN { OPC 'H-23H' } AND { OPC 'H+1H' }

Additionally, when querying the CDBHistoric or CForecastHistoric tables, you must constrain the List to those records that are associated with an individual database item (either a particular point, accumulator, or forecast).

Whenever an alias is assigned to a field (see SELECT Clause), remember to specify that alias, rather than the field name, in the WHERE clause.

For more information on SQL Conditions, see the SQL Technical Reference online Help.


Lists Guide - ORDER BY Clause (Custom Lists)

ORDER BY Clause

Use the ORDER BY clause to specify the order in which the records appear in a List.

Example:

"~FullName" ASC

(For a List in which the records are displayed in ascending order, by FullName. (The ASC and DESC keywords are optional—if neither is included, ASC is assumed.))

To sort the data by multiple fields, specify a comma-separated list:

Example:

"~RecordTime" DESC, "SeqNo" DESC

(For an Events List in which the records are displayed in descending order by both record time and the sequence in which events that have the same time stamp occurred.)

Whenever an alias is assigned to a field (see SELECT Clause), remember to specify that alias, rather than the field name, in the ORDER BY clause.

For more information on the ORDER BY clause, see the SQL Technical Reference online Help. Also see the above documentation for information on the GROUP BY clause—a clause that you might want to consider using for producing complex Lists.


Lists Guide - Fields that Perform Special Functions (Custom Lists)

Fields that Perform Special Functions

Some database fields perform particular functions in ClearSCADA. Whenever these functions are required, the particular fields associated with those functions have to be included in the SELECT clause’s comma-separated list of fields. Unlike other database fields, these ‘special’ fields are not displayed as columns in the resultant List.

The ‘special’ fields are:

  • Id
  • RecordId
  • Foreground
  • Background
  • Blink
  • SeqNo
  • CommentNo.


Lists Guide - Id (Custom Lists)

Id

Associated with: Tables other than the Event Journal (CDBEventJournal), Data Grids, and Data Tables

We recommend that Id is always included in a List’s SELECT Clause (other than when querying CDBEventJournal (whereupon you would specify RecordId instead), a Data Grid, or a Data Table).

The Id field enables SQL to retrieve dynasets of data. As such, typically only a subset of the data that is requested for a List is retrieved at any one time, rather than all of the specified data. This minimizes the loading on both the server and client, particularly when requesting large quantities of data. When a List is displayed, for those entries that are presently visible on a client, data is retrieved for all of the fields specified by that List’s SELECT clause. For the remaining entries in the List, only the Id of every required entry is retrieved from the database. Whenever the vertical scroll bar is used to display further List entries, the additional fields of data for those entries is retrieved from the database.

The Id field also enables pick action(s) to be associated with List entries.


Lists Guide - RecordId (Custom Lists)

RecordId

Associated with: The Event Journal table (CDBEventJournal), CDBHistoric, CForecastHistoric, and Historic View tables

The RecordId is a unique number that is used to identify a historic record.

When querying any of the above tables in order to produce a List, always include the RecordId field in that List’s SELECT Clause.

The RecordId field enables SQL to retrieve dynasets of historic data. As such, typically only a subset of the data (including each required entry’s RecordId) is retrieved from the database, rather than all of the data that is specified by the List’s SELECT query. (For more information on dynasets, see Id.)


Lists Guide - Foreground (Custom Lists)

Foreground

Associated with: Tables other than Historic Views or Historic Forecasts; optional for Data Tables

Include the Foreground field in a List’s SELECT Clause if you want each record’s foreground color to change depending on the item’s status. Standard Queries Lists, Historic Lists, and Events Lists include the Foreground field by default (see The Color of Entries in a List other than the Alarms List).

If the Foreground field is not included in the SELECT Clause, the workstation’s Windows® settings determine the foreground color of the List’s entries (typically black text).

(To ascertain whether Foreground is used in a particular Data Table, look at the Attributes of the fields in that table (see Specify the Field Properties in the ClearSCADA Guide to Core Configuration.)

You can also assign Foreground color aliases to other fields, in order to produce Lists in Which only the Entries in Particular Columns Change Color.

Also see Blink, and see Background.


Lists Guide - Background (Custom Lists)

Background

Associated with: Tables, including CDBHistoric (but not Data Grid tables, the Event Journal (CDBEventJournal), or other Historic Pseudo tables); optional for Data Tables

Include the Background field in a List’s SELECT Clause if you want each record’s background color to change depending on the item’s status. Standard Queries Lists, Historic Lists, and Events Lists include the Background field by default (see The Color of Entries in a List other than the Alarms List).

If the Background field is not included in the SELECT Clause, the workstation’s Windows® settings determine the background color of the List’s entries (typically white).

(To ascertain whether Background is used in a particular Data Table, look at the Attributes of the fields in that table (see Specify the Field Properties in the ClearSCADA Guide to Core Configuration.)

You can also assign Background color aliases to other fields, in order to produce Lists in Which only the Entries in Particular Columns Change Color.

Also see Foreground.


Lists Guide - Blink (Custom Lists)

Blink

Associated with: Tables, including CDBHistoric (but not Data Grid tables, the Event Journal (CDBEventJournal), or other Historic Pseudo tables); optional for Data Tables

Some system colors and alarm severity colors are configured to flash. Include the Blink field, along with the Foreground field in a List’s SELECT Clause if you want a record’s foreground to flash whenever that entry is displayed using a flashing system or alarm color. Standard Queries Lists, and Historic Lists include the Blink field by default (see The Color of Entries in a List other than the Alarms List).

If the Foreground field is included without the Blink field, none of the List’s entries will flash when a flashing system or alarm color is in force. Instead, the entries will display the ‘base’ color that indicates such a status, without using the flashing element of that color.

The Blink field has no effect if it is included in the SELECT Clause without the Foreground field.

(To ascertain whether Blink is used in a particular Data Table, look at the Attributes of the fields in that table (see Specify the Field Properties in the ClearSCADA Guide to Core Configuration.)

If required, you can assign a Blink alias to one or more fields, in order for only the entries in certain columns to flash (see Lists in Which only the Entries in Particular Columns Change Color).


Lists Guide - SeqNo (Custom Lists)

SeqNo

Associated with: The Event Journal table (CDBEventJournal)

ClearSCADA is supplied with various ‘standard’ Events Lists—the Events List for a particular system, and the Events Lists for an individual Group or database item. Each of these Lists query the Event Journal table. Users can insert a comment for any event in any of these Events Lists—for example, in order to indicate the unusual occurrence that resulted in a particular event being logged.

With a ‘custom’ Events List, include both the SeqNo and CommentNo fields in the SELECT Clause if you want users to be able to add such comments to any entries in that List. (For information on inserting comments, see Insert a Comment for an Event.)

The SeqNo indicates the position of an event in the Events List. (The first event to be logged on a system is number 1, the second event is number 2, and so on.) Include this field in the ORDER BY Clause so that when two or more events occur at the same time, they are shown in the correct order in the List


Lists Guide - CommentNo (Custom Lists)

CommentNo

Associated with: The Event Journal table (CDBEventJournal)

ClearSCADA is supplied with various ‘standard’ Events Lists—the Events List for a particular system, and the Events Lists for an individual Group or database item. Each of these Lists query the Event Journal table. Users can insert a comment for any event in any of these Events Lists, in order, for example, to indicate the unusual occurrence that resulted in a particular event being logged.

With a ‘custom’ Events List, include both the SeqNo and CommentNo fields in the SELECT Clause if you want users to be able to add such comments to any entries in that List. (For information on inserting comments, see Insert a Comment for an Event.)

The CommentNo indicates the position of a comment in the sequence of comments that have been inserted for an event on an Events List.


Lists Guide - Example Configuration (Custom Lists)

Example Configuration

Use the examples in this section as an aid when creating your own ‘custom’ Lists. The examples demonstrate how to produce:

  • A List of Points that have Invalid Configuration
  • A List that Contains Information that is Relevant to a Particular Group Instance
  • A Custom Pick Action to Display a List of Out of Service Points
  • Lists in Which only the Entries in Particular Columns Change Color.

ATTENTION: Any SQL queries for ‘custom’ Lists should be written by engineers who have the appropriate experience and knowledge of the SQL language. Running a badly designed SQL query can have an adverse affect on the system. All queries should include suitable restrictions to limit the number of records that are retrieved from the database. An SQL query that queries vast amounts of data will affect the performance of the server while that query executes.


Lists Guide - A List of Points that have Invalid Configuration (Custom Lists)

A List of Points that have Invalid Configuration

This example demonstrates how you might embed a List on a Mimic, in order to display a pre-filtered List of points that have invalid configuration. By producing such a List, engineers are able to access the information when required, without needing to manually filter the Points List each time they need access to such information.

(If an individual user needs regular access to a filtered List and their User Account gives them access to the Favorites Bar, they can add the filtered List to their list of Favorites—this will enable them to view the List with the filters already in place. For more information, see Favorites Bar in the ClearSCADA Guide to ViewX and WebX Clients.)

Example:

A particular ClearSCADA system is being restructured and expanded over a period of months. A series of pre-filtered ‘custom’ Lists are produced, to enable engineers to quickly display any database items that have invalid configuration. The Lists are embedded in Mimics within a suitably named Group in the database.

To produce a pre-filtered List of points that have invalid configuration, the Queries Bar is first used to display the Points List with the required filters in place. The SQL query for this List is then used as the basis for the embedded List. The embedded version of the List will enable engineers to display the information they require, without necessarily needing to filter the data on that List. (The embedded List will automatically be pre-filtered to show only points that have invalid configuration.)

To filter the Points List to show only those points that have invalid configuration, an engineer double-clicks on the Points entry on the Queries Bar. The Filter Columns window is displayed. The Add button is selected to display the Add Filter window.

The window is used to filter the List so that it only displays points that do not have valid configuration:

The OK button is used to confirm the filter settings and to add the filter to the Filter Columns window. Any other filters are added as required, then the OK button is selected on the Filter Columns window to confirm the filters and display the List.

While the List is on display, the View menu is selected, followed by the SQL option. This displays the SQL window, which shows the SQL query that is being used for the List:

The highlighted query is copied to the clipboard (using the key combinations CTRL + C).

The Mimic on which the List is to be embedded is displayed in Design mode. The Embedded List button on the Mimic Editing toolbar is used to insert an embedded List onto the Mimic. The Embedded List Properties window is displayed automatically. The copied SQL code is pasted into the window’s Query tab (using the key combinations CTRL + V to paste the copied code from the clipboard). Any further adjustments of the SQL code are performed as required.

The Embedded List Properties window is closed to confirm the settings and update the embedded List’s configuration. The Mimic on which the List is embedded is saved.

Users are then able to display the Mimic with the embedded List whenever they need to ascertain whether any points have invalid configuration. The List includes, for instance, any points that contain a Configuration Error, or are Not Connected.

(With any point that contains configuration error(s), any user that is logged onto ClearSCADA with a User Account that has the Configure Database feature enabled is able to click on the entry in the embedded List, to display a context sensitive menu. By selecting the Properties option, they are able to display the configuration Form for the point—the invalid or conflicting configuration is summarized in the message area at the bottom of the Form. They can then correct the configuration as required.)

Further Information

Display a Queries List from the Queries Bar.

Use the Filter Columns Window to Filter the Entries in a List other than an Alarms List.

Embed a List on a Mimic: see Embed a Queries List on a Mimic in the ClearSCADA Guide to Mimics.

Use the Embedded List Properties window: see Editing an Embedded Query List in the ClearSCADA Guide to Mimics.

Invalid Configuration: see Checking for Invalid Configuration in the ClearSCADA Guide to Core Configuration.


Lists Guide - A List that Contains Information that is Relevant to a Particular Group Instance (Custom Lists)

A List that Contains Information that is Relevant to a Particular Group Instance

This example demonstrates how you might embed a List on a Mimic that is in a Group Template, in order that in each Instance of that Template, the Instance of the embedded List displays the entries that are relevant to that Instance.

ATTENTION: Be aware that the contents of a List embedded on a Mimic that is in a Group Template will always be empty (as that List is not ‘live’—only the Instances of the embedded List are ‘live’ and include any content). In order to configure and test out such an embedded List, we recommend that you initially include the Mimic in a ‘normal’ Group, while you ascertain the List’s content. Once the SQL query for that embedded List (and any other embedded Lists) is complete, you can convert the Group into a Group Template.

Example:

A particular ClearSCADA system comprises several ‘zones’ and has been configured using a series of Group Templates and Group Instances.

A Group Template ‘Zone Template’ is used to produce the ‘model’ configuration for each of the areas of plant (outstation and points) that exist in each zone. The Template contains an outstation called ‘Direct Outstation’, and the points that are associated with that outstation.

The Group Template also includes an overview Mimic that is to display a summary of the plant status for a single zone. The information, a summary of the points that are associated with the ‘Direct Outstation’ in a single zone, is to be displayed in List format.

The overview Mimic is displayed. The Embedded List button on the Mimic Editing toolbar is used to insert an embedded List onto the Mimic. The Embedded List Properties window is displayed automatically. The SQL query for the List’s content needs specifying in the window’s Query tab.

As a time saving exercise, to avoid typing in the complete SQL query manually, the SQL query for an existing List is used as a basis. To ascertain the SQL query that is presently used on a similar List, the Database Bar is used to locate an outstation elsewhere on the system. The Points List for the outstation is displayed by right-clicking on the outstation, and then selecting the Display Points option. While the List is on display, the View menu is selected, followed by the SQL option—this displays the SQL window, which shows the SQL query that is used for the List:

The SQL query shows that:

  • The SELECT Clause forces the FullName column to remain in view on the List, regardless of whether any horizontal scroll bar is used to navigate the List’s entries.
  • The CDBPOINT table is the database table that is being queried for point data (as specified by the FROM Clause).
  • The WHERE Clause is restricting the records to those of the outstation, in a particular location on the system.
  • The ORDER BY Clause is used to display the List’s records in ascending order by FullName.

The SQL query is copied and pasted into the Query tab on the embedded List’s Embedded List Properties window.

The SQL for the SELECT Clause is modified to include the fields that are required for the embedded List. (The ‘special’ fields Id, Foreground, and Background are retained so that the List entries are displayed using the appropriate system colors.)

The SQL for the WHERE Clause is modified so that the embedded List only includes data for the points on the relevant outstation. As the List is embedded on a Mimic that is in a Group Template, the WHERE Clause in each Instance of the List needs to limit the List’s entries to only those points that are relevant to that particular Instance. To enable this, the SQL query is animated.

To animate the SQL query, the engineer right-clicks on the Query tab and selects the Generate Animation option.

To animate the SQL query for a List that is embedded on a Mimic...
...then right-click on the SQL query to display a pop-up menu, and select the Generate Animation menu option...
...display the SQL query for that List...

The Generate Animation option animates the embedded List’s SQL query.

In order to specify the required animation, the Embedded List Properties window is closed, and the Animations window opened. The Animations window includes an entry for the animated SQL query:

The Animations window includes the expression for the animated SQL query. (The window is displayed by right-clicking on the embedded List to display a context-sensitive menu, and selecting the Animations option.)

The SQL expression is edited so that the embedded List displays only those points that are associated with the direct outstation in any one Instance of embedded List.

In this particular case, the SQL for the WHERE Clause is changed to:

WHERE "SourceName" = ''' + ".Direct Outstation.FullName" + '''

The Embedded List Properties window is used to configure any other List properties that are to differ from the defaults (for example, the List’s header colors). (The settings that are specified here override the defaults that the List inherited from elsewhere in ClearSCADA.)

The Mimic configuration is saved.

As the List is embedded on a Mimic that is in a Template, no entries are displayed in the Template version of the embedded List. Therefore, an Instance of the embedded List is displayed, to verify that it includes the relevant records.

An Instance of the embedded List is displayed, to verify that it contains only the points that relate to that particular Instance.

(Remember that if any Instances of a Mimic are on display while the Template version of that Mimic is modified, the Mimic Instances will need redisplaying in order to reflect those changes.)

(Also remember that once the SQL query for an embedded List has been animated, any changes to that SQL query have to be performed by editing the query’s expression in the Animations window, rather than the SQL query on the Query tab of the Embedded List Properties window.)

Further Information

Group Templates and Group Instances: see Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration.

Ascertain which SQL Query is Presently used by a List.

SQL Query Structure.

Embed a List on a Mimic: see Embed a Queries List on a Mimic in the ClearSCADA Guide to Mimics.

Use the Embedded List Properties window: see Editing an Embedded Query List in the ClearSCADA Guide to Mimics.

Generate Animation menu option: see Query Tab (Embedded Query List), and see Sql, both in the ClearSCADA Guide to Mimics.

Using the Animations window: see Animations in the ClearSCADA Guide to Mimics.


Lists Guide - A Custom Pick Action to Display a List of Out of Service Points (Custom Lists)

A Custom Pick Action to Display a List of Out of Service Points

This example demonstrates how an extra Table Query might be added to a ClearSCADA system, in order to enable users to display Lists of Out of Service points in a Group.

For further information on creating extra Table Queries, see Extra Table Queries in the ClearSCADA Guide to Server Administration.

Example:

The engineers on a particular ClearSCADA system need ready access to lists of Out of Service points. Ideally, the entries in each List should be restricted to the points that are associated with the particular database Group from which the List is displayed.

The ClearSCADA Server Configuration Tool is used to add an extra Table Query to the database:

The Extra Table Queries section of the ClearSCADA Server Configuration Tool is used to add a new Table Query.
The Query is associated with the CGroup database table.
It is configured to display the custom pick action ‘Display Out of Service Points’ whenever the menu for a group item is displayed in ClearSCADA.
The Table Query’s Title includes the $ trip character. In this particular case, this is used to ensure that the name in the List’s title bar indicates the particular group with which the Out of Service points are associated.
In the Query field, SQL is used to specify the List’s content.

The SQL for the Table Query is as follows:

SELECT
"FullName" AS "~FullName", "Id", "Foreground", "Blink", "Background",
"CurrentTime", "SourceName", "Source", "TypeDesc"
FROM
CDBPoint
WHERE
("CurrentQuality" = 28) AND
("~FullName" LIKE CASE WHEN
$Id$=0 THEN '%'
ELSE '$FullName$.%' END)
ORDER BY
"~FullName" ASC

As with any Queries List, the SELECT Clause lists the data fields that are to be retrieved from the database. These include several Fields that Perform Special Functions, which won’t themselves be displayed as columns in the resulting List.

The FROM Clause defines the database table from which the data is to be retrieved. As the Lists are to display points, the clause specifies the overall points table CDBPoint.

The WHERE Clause is used to restrict the List’s content to the relevant points. In this particular case, the CurrentQuality attribute is used to restrict the List’s entries to those points that are out of service. (28 is the CurrentQuality value that corresponds to the CurrentQualityDesc (current quality description) ‘Out of Service’). Using the current quality value in the WHERE Clause is more efficient that specifying the current quality description, and is also language independent. (To ascertain the CurrentQuality value for ‘Out of Service’ you could, for instance, right-click on an Out of Service point in the OPC Data Bar, then select the Display Values option to display the OPC values for that point. The CurrentQuality value is displayed above the corresponding CurrentQualityDesc string.)

Additionally, the CASE scalar function is used in the WHERE Clause to further restrict the entries to those points that either belong to the Root Group (whenever the List is displayed from the root itself—as specified by $Id$=0), or from a specific Group whenever the List is displayed from another Group. (Again, querying by Root Group ID is more efficient than querying by Root Group name.)

The ORDER BY Clause specifies that the order in which the List’s entries are displayed is initially by ascending FullName order.

The ClearSCADA server is restarted to add the additional Table Query to the database.

Whenever an engineer right-clicks on a Group (including the Root Group) in the Database Bar, the context sensitive menu now includes the custom option ‘Display Out of Service Points’. When this option is selected, a list of Out of Service points for that Group is displayed.

The context sensitive menu for each Group includes the custom option ‘Display Out of Service Points’.
Selecting the menu option displays the List of Out of Service points for the Group.

The custom menu option is also available from any other displays, such as Mimics or other Lists, from which users can display a context sensitive menu for a Group item.

Users can Filter, Sort, Quick Filter, and perform other actions from the List in the same way as other Queries Lists.

Further Information

SQL Query Structure.


Lists Guide - Lists in Which only the Entries in Particular Columns Change Color (Custom Lists)

Lists in Which only the Entries in Particular Columns Change Color

With most Lists, the color that ClearSCADA uses for displaying each entry in the List is determined by that entry’s state and, in the case of a Queries List, any actions that are being performed on, or are associated with, the item (see The Color of Entries in a List other than the Alarms List).

With such a List, the Foreground, Background, and Blink fields are used to control the color of the entries in the List. These fields are ‘special’ fields that are not displayed as separate columns in the List (see Fields that Perform Special Functions). By including these fields in the SQL for a List, this enables the whole row for each record to change color according to that item’s state, or the activity associated with that item.

If required, you can ‘customize’ a List, so that the entries in an individual column change color according to a particular expression. To do this, you include a special attribute column in the List’s SELECT Clause, to control the color of the entries in the next column that is listed in that clause. You assign the special attribute column an alias that either comprises, or commences with, Foreground, Background, or Blink. The syntax for this is:

<expression> AS "{<alias>}", "<field>"

where:

  • <expression> is the expression that evaluates either:
  • To an integer that is interpreted as a color (if the alias is, or begins with, either Foreground or Background)

Or:

  • To a Boolean (if the alias is, or begins with, Blink).
  • <alias> specifies which color attribute the above expression determines for the entries in the next column that is specified in the SELECT Clause. Specify Foreground, Background, or Blink, as appropriate. Where more that one column is assigned a color alias, specify an alias that begins with one of these three strings.
  • <field> is the field that represents the column that is being assigned the above alias.

NOTE: You can only assign one column per List to a particular alias. As such, if more than one column is to change foreground color, for example, the Foreground alias has to be suffixed with different letter(s) or number(s) for each column that requires such an alias. For example, {Foreground1} for the first column that is to have such an alias, and {Foreground2} for the second column that is to have a Foreground alias.

If the SQL for a List does not include the Foreground, Background, and Blink fields as separate fields in the SELECT Clause, only the entries in those column(s) that are assigned a color alias will have their color determined by a color property in the SQL. The workstation’s Windows® settings will determine the foreground and background colors of entries in those columns that are not assigned a color alias.

If the SQL does include the Foreground, Background, and Blink fields as separate fields in the SELECT Clause:

  • The color expression that is assigned to any column that uses a color alias will determine the color of the entries in that particular column.
  • The entries in those columns that are not assigned a color alias will be determined by the Foreground, Background, and Blink fields, as per most Lists.

The examples below demonstrate how color aliases can be used to control the color or blink element of entries in specific column(s) in a List.

Example 1:

The states of certain digital points on a particular ClearSCADA system are assigned Custom colors. A custom List is produced, based on the Points List. The List queries the Points table CDBPoint. Rather than include the Foreground, Background, and Blink fields in the SQL, it has been decided to limit the colors of the entries. The foreground color of the entries in the ‘State’ and ‘Last Updated’ columns will be determined by each point’s state color; the color of the entries in other columns will use the Windows® defaults.

The SQL query shows that ‘State’ and ‘Last Updated’ are the display names of the CurrentStateDesc and CurrentTime fields, respectively. (A display name is the string that is displayed in the language that is associated with the logged on user’s specified Locale.)

The database schema is used to look up the CDBPoint table. This indicates that a point’s State Color is determined by its CurrentStateColour field.

To enable the entries in the two columns to be displayed using the appropriate state color, the SELECT Clause is modified to include this syntax:

"CurrentStateColour" AS "{Foreground1}", "CurrentStateDesc", "CurrentStateColour" AS "{Foreground2}", "CurrentTime"

(As more than one column is assigned a Foreground color alias, a digit is appended to each ‘Foreground’ entry, to ensure that each alias is unique.)

Example 2:

A custom List is produced, based on the Objects List for a particular Group, ‘Eastern Region’. The List queries the table CDBOBJECT. The List is to show which of the items in the Group do not have valid configuration.

The Foreground, Background, and Blink fields are omitted from the List.

The database schema shows that the CDBOBJECT table includes a ConfigValid field. This field is included in the SQL for the List. The List’s SELECT Clause is modified to include this syntax:

"FullName" AS "~FullName", "Id", "TypeDesc",
CASE "ConfigValid" WHEN TRUE THEN FALSE ELSE TRUE END AS "{Blink}",
CASE "ConfigValid" WHEN TRUE THEN 51200 ELSE 255 END AS "{Foreground}",
CASE "ConfigValid" WHEN TRUE THEN 'Yes' ELSE 'NO' END AS "ConfigValid"

This results in a List in which the ConfigValid entry displays:

  • A green ‘Yes’ for those items in the Group that have valid configuration
  • A flashing red ‘NO’ for those items that have invalid configuration.

Further Information

Custom Colors: see Defining a Custom State Color in the ClearSCADA Guide to Core Configuration.

Using the Database Schema: see Working with the Database Schema in the ClearSCADA Guide to the Database.

Display a Queries List from the Queries Bar.

Ascertain which SQL Query is Presently used by a List.

SQL Query Structure.


Lists Guide - Querying Third Party ODBC Databases

Querying Third Party ODBC Databases

You can use ClearSCADA to query any ODBC database. This is useful as it allows ClearSCADA users to view data stored in other ODBC database systems. For example, if you have an SQL Server database, you can use Queries Lists to view the SQL Server’s data in ClearSCADA.

To query a third party database from ClearSCADA, you need to:

  1. Use Windows to configure your operating system to recognize the external database. To do this, you need to use the Data Sources settings that are available via the Control Panel. When configuring the Data Sources settings, you can define various settings for accessing the external table, including passwords and a name for the external table. For more information, please refer to the Microsoft documentation for using the Data Sources tool.
  2. Use the ClearSCADA Server Configuration Tool’s Linked ODBC Tables settings to create a link between ClearSCADA and each individual table that you want to query (see SQL Query Configuration Settings in the ClearSCADA Guide to Server Administration). As long as ClearSCADA has a valid link to your Third Party ODBC database table, it can query the table in the same way as any table in the ClearSCADA database.
  3. In ViewX, log on and display any Queries List (see Display and Use Lists).
  4. With the Queries List on display, select the View menu, then the SQL option to display the Queries List’s current SQL.
  5. Delete the current SQL and replace it with an SQL statement that instructs ClearSCADA to query your Third Party ODBC database. There is no special syntax required to query your Third Party ODBC table, you should just construct an SQL statement in the same way as you would for any ClearSCADA database table.
  6. Select the OK button to confirm your entry.
  7. If the settings for the System DSN and Linked Database Tables are correct, and the SQL Query you entered is valid, the Queries List that you displayed in step 3 will now show the results of a query on the Third Party ODBC database table.

You can also use embedded Lists on Mimics to query Third Party ODBC database tables. As long as ClearSCADA has a link to the table that is to be queried, the SQL of the embedded List can be configured to query a Third Party ODBC table. This works in the same way as querying a ClearSCADA database table (see Editing an Embedded Query Listin the ClearSCADA Guide to Mimics).

With Mimics, you can also create a hyperlink to a List, with the configuration of the hyperlink’s SQL statement being used to query a Third Party ODBC table. For such a hyperlink to work, ClearSCADA has to have a link to the table being queried, and the SQL has to reference the Third Party ODBC table in the same way that it would reference a ClearSCADA database table (see Creating a Hyperlink to a List in the ClearSCADA Guide to Mimics).

If you want to show the results of a Third Party ODBC database table query to WebX users, embedded Lists and hyperlinks are especially useful. WebX users cannot alter the SQL of a List, but they can display Mimics that are pre-configured to query a Third Party ODBC database table.

Example: Querying a Third Party ODBC Database Table in ViewX

A common requirement is for users to be able to query a third party database and combine the result set with data that exists in the ClearSCADA database. In this example, we are going to use the Metadata feature to show how this requirement can be achieved.

Let’s say we have a third party ODBC database, in this case, an SQL Server database. The database contains a table named ‘ASSETINFO_PUMPS’ which is used to store information about the pumps used on part of a system including Pump_Reference, Serial Number, Purchase Date and Warranty.

In ClearSCADA, each pump is represented by two database points (one to power the pump on, and one to power it off). The various values of the points can be viewed on the Points List which works by querying the CDBPoint table in the ClearSCADA database.

For the purpose of this example, we are going to assume that a user wants to perform a query that returns the information in the ‘ASSETINFO_PUMPS’ table in the SQL Server database and combines it with the Points List data for the corresponding points in ClearSCADA.

To achieve this, the CDBPoint table in ClearSCADA has to be joined with the ‘ASSETINFO_PUMPS’ table in the SQL Server database, and a Join requires the two tables to have a matching column that can be used as a reference.

As the CDBPoint table does not contain the same fields as the ‘ASSETINFO_PUMPS’ table, there is no common column to use for the join. To work around this, a custom field (metadata field) is added to the database. The metadata field is added to all Point Forms by entering the following information in the configuration for a new metadata field:

Fields:

  • Field Name—Pump Reference
  • Section—Configuration
  • Show on Form—Checked
  • Table—CDBPoint
  • Row—1
  • Column—2
  • List Priority—None
  • Type—String
  • Size—30
  • Permission—Configure
  • Target Type—CDBObject (grayed out)
  • View Info Dialog Title—Pump_Reference

Labels:

  • Label—Pump_Reference
  • Table—CDBPoint
  • Row—1
  • Column—1

This adds a Pump_Reference field to the Point tab on Point Forms.

Each point is then configured so that its entry for the Pump_Reference field corresponds to the Pump_Reference number of the pump that the point represents. For example, if a digital input point represents a pump that has the reference number SA-REG1-PUMP1, the point will have SA-REG1-PUMP1 as its entry for the Pump_Reference field on the Point Form.

On the ClearSCADA Server, a System DSN is configured (via Windows Control Panel) so that the server’s operating system can detect the SQL Server. For the purpose of this example, the System DSN that is created is named SQLSERVERDB.

Next, the ClearSCADA server itself has to be configured so that it can connect to the ASSETINFO_PUMPS table in the SQL Server database.

Using the ClearSCADA Server Configuration Tool, the user configures a Linked ODBC Table for each table in the SQL Server database that is to be queried by ClearSCADA. In this case, ClearSCADA only needs to query one table in the SQL Server database (the ASSETINFO_PUMPS table), so a link is configured with the following settings:

  • Table Name—ASSETINFO_PUMPS
  • Connection String—DSN=SQLSERVERDB
  • User Name—Null (Not Specified)
  • Password—(Not Specified)
  • Source Catalog—Master
  • Source Schema—dbo
  • Source Table—ASSETINFO_PUMPS

In this example the DSN system name is SQLSERVERDB and the SQL ‘source catalog’ has the default name of ‘Master’. The Table Name and Source Table settings have to match the name of the table that ClearSCADA needs to query.

The settings are applied to the ClearSCADA server configuration.

In ViewX, the user displays any of ClearSCADA’s built-in Queries Lists, for example, the Points List. The user chooses to display the List with no filters applied.

With the List on display, the user selects the View menu, then the SQL option to display the SQL window which shows the SQL query that is used to return the List’s current result set.

The current SQL is deleted and replaced with the following:

SELECT

"FullName" AS "~FullName", "CurrentValueFormatted", "CurrentStateDesc", "CurrentQualityDesc", "Manufacturer", "Serial_Number", "Purchase_Date", "Warranty"

FROM

CDBPOINT JOIN ASSETINFO_PUMPS USING ( PUMP_REFERENCE )

This SQL Query uses the Pump Reference property that is found in both the CDBPoint table (as it was added using the Metadata feature) and the ASSETINFO_PUMPS table, to join the two tables. This allows ClearSCADA to display a single result set that is taken from both of the tables. In this case, the SQL has been defined so that ClearSCADA displays a List that contains the Name, Value, State, Quality, Manufacturer, Serial_Number, Purchase_Date, and Warranty columns (selected columns taken from both the CDBPoint table and the ASSETINFO_PUMPS table).


Mimics Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Mimics Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Mimics Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Mimics Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Mimics Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Mimics Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure and operate ClearSCADA’s interactive graphical displays (Mimics).

For details on the subjects covered in this Guide, see Welcome to the Mimics Guide.


Mimics Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for system operators who use Mimics to interact with the system and also for those engineers who are responsible for the configuration and management of Mimics.


Mimics Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Mimics Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Expressions

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Database

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Security

ClearSCADA Guide to Lists

ClearSCADA Guide to Trends

ClearSCADA Guide to Client Administration.


Mimics Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Mimics Guide - Welcome to the Mimics Guide

Welcome to the Mimics Guide

Welcome to the ClearSCADA Guide to Mimics. This guide provides reference information about the various aspects of Mimic configuration and operation.

The guide consists of the following sections:

  • Displaying a Mimic
  • Operating a Mimic
  • Creating a New Mimic
  • File Based Mimics
  • Designing a Mimic
  • Adding Objects to a Mimic
  • Importing a DXF File
  • Importing an SVG File
  • Importing a Windows Metafile
  • Editing Objects on a Mimic
  • Views
  • Layers
  • Local Variables (Registry Key Settings)
  • Associating Mimic Objects with Pick Actions
  • Hyperlinks
  • Animations
  • Mimic Parameters
  • Troubleshooting - Mimics.


Mimics Guide - Displaying a Mimic

Displaying a Mimic

There are two types of Mimic that you can display in ViewX:

  • Mimics that are stored in the database
  • File Based Mimics

In WebX, you can only display Mimics that are stored in the database.

There are various techniques you can use to display a Mimic, some of which are only available if your User account is configured to have certain features enabled or has specific security permissions. In the following sections, we describe the various ways in which you can display a Mimic, explain the difference between the two Mimic modes (Run Mode and Design Mode), and also provide an overview of the Mimic interface:

  • Displaying Mimics that are Stored in the Database
  • Displaying File Based Mimics
  • Run Mode and Design Mode
  • The Mimic Display.


Mimics Guide - Displaying Mimics that are Stored in the Database (Displaying a Mimic)

Displaying Mimics that are Stored in the Database

Mimics can be stored in the ClearSCADA database or saved as a file to an external source. Usually, Mimics are stored in the ClearSCADA database as they contain hyperlinks and ‘live’ data that need to be continuously updated. However, it is possible to save a Mimic as an external file which can then be stored externally and opened in ClearSCADA when required (see Displaying File Based Mimics).

In the following sections, we explain the various ways you can display a Mimic that is stored in the ClearSCADA database:

  • Use the Database Bar to Display a Mimic
  • Use an SQL Queries List to Display a Mimic
  • Use a Mimic to Display another Mimic
  • Use the Navigation Features to Display a Mimic
  • Use the Favorites Feature to Display a Mimic
  • Use a Go To link on a Form to Display a Mimic
  • Use an Alarms List or Alarm Banner to Display a Mimic
  • Use the WebX Database Page to Display a Mimic.

When you display a Mimic, it is shown in Run Mode or Design Mode, depending on the technique you used to display the Mimic, the permissions allocated to your User account, and the configuration of your User account. If you have the Configure permission for the Mimic, you can switch between Run Mode and Design Mode as required (see Run Mode and Design Mode).

Further Information

The Mimic Display.


Mimics Guide - Use the Database Bar to Display a Mimic (Displaying a Mimic)

Use the Database Bar to Display a Mimic

You can use the Database Bar in ViewX to access Mimics and their various display options (see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).

There are several ways of displaying a Mimic from the Database Bar:

  • Double-click on the Mimic that you want to display (if your User account has the Configure permission for the Mimic and has the Double Click Edits Documents feature enabled, the Mimic will display in Design Mode; if Double Click Edits Documents is disabled or you do not have the Configure permission, the Mimic is displayed in Run Mode).

For more information on permissions, see Permissions for Database Items in the ClearSCADA Guide to Security. For details on the Double Click Edits Documents feature, see Define the General ViewX Settings for a User in the ClearSCADA Guide to Security.

  • Right-click on the Mimic that you want to display, then select the Display option to display a Mimic in Run Mode. Alternatively, select the Edit option to display a Mimic in Design Mode (see Run Mode and Design Mode). The Edit option is only available if you have the Configure permission.
  • Right-click on a Group, Group Template or Group Instance that contains the default view Mimic you want to display, then select the Display Default View option. You can only display a Mimic in this way if the Group, Group Template or Group Instance has been configured to have a Default View.
  • Right-click on a database item for which an alarm has been raised, then select the Display Alarm View option. This will display the Mimic that has been defined as the Alarm View for the database item. You can only display a Mimic in this way if the selected database item has an active alarm and has been configured to have a Alarm View.
  • Right-click on a database item for which a Help View Mimic has been defined, then select the Display Help View option. This will display the Mimic that has been defined as the Help View for the database item. You can only display a Mimic in this way if the selected database item has been configured to have a Help View.
  • Right-click on a database item then select the Display <Extra Link Field> option, where <Extra Link Field> is the name of a metadata field (custom field) that has been configured to provide access to a Mimic. Selecting a metadata field of this type will only display the Mimic that is associated with the metadata field.
  • If a database item references a Mimic, you can use the Show References action for the item to gain access to the Mimic. From the item’s context sensitive menu, select the Show References option to display the References window which lists the items that the selected item references. You can double-click on any Mimic in the list of references to display the Mimic.

Further Information

Database Bar: see Explorer Bars used in ViewX in the ClearSCADA Guide to ViewX and WebX Clients.

The Mimic Display


Mimics Guide - Use an SQL Queries List to Display a Mimic (Displaying a Mimic)

Use an SQL Queries List to Display a Mimic

You can use an SQL Queries List in ViewX or WebX to display a Mimic—simply display a List that contains the Mimic you want to display, then select the Mimic to display its context sensitive menu. From the context sensitive menu, you can select the Display, Display Default View, Display Alarm View, Display Help View, Display <Extra Link Field>, Edit or Show References option as required. These options work in the same way as described in Use the Database Bar to Display a Mimic.

Alternatively, you can select a hyperlink to the Mimic from an appropriate column in an SQL List. The columns that contain hyperlinks are:

  • AlarmViewLink—provides a hyperlink to the Mimic that is configured as the item’s Alarm View
  • HelpViewLink—provides a hyperlink to the Mimic that is configured as the item’s Help View
  • DefaultViewLink—provides a hyperlink to the Mimic that is configured as the item’s Default View
  • ObjectLink—provides a hyperlink that displays the Mimic that is named in the ObjectLink column.

Further Information

WebX: see WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.

Lists: see Welcome to the ClearSCADA Guide to Lists in the ClearSCADA Guide to Lists.

Lists in WebX: see View and Action Lists on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


Mimics Guide - Use a Mimic to Display another Mimic (Displaying a Mimic)

Use a Mimic to Display another Mimic

Mimics can be configured so that they contain:

  • Objects that provide access to the context sensitive menu of any item, including other Mimics
  • Hyperlinks to other displays, including other Mimics.

If you display a Mimic that contains a hyperlink to another Mimic or provides access to a Mimic’s context sensitive menu, you can use that Mimic to display other Mimics:

Either:

  • Select a hyperlink pick action that is configured to link to the Mimic you want to display.

Or:

  • Select a pick action that is configured to provide access to an item’s context sensitive menu (object menu), then select Display Default View , Display Alarm View, Display Help View, or Display <Extra Link Field> as required. These options work in the same way as when accessed via the Database Bar (see Use the Database Bar to Display a Mimic).

Or:

  • Select a pick action that is configured to provide access to the Mimic’s context sensitive menu (object menu), then select Display or Edit as required. These options work in the same way as when accessed via the Database Bar (see Use the Database Bar to Display a Mimic)

When you use a Mimic to display another Mimic, the ‘target’ Mimic (the Mimic that is displayed when you select the hyperlink or action) can be shown in place of the original Mimic, in a new window, or in an inset window. You can use the navigation features of ViewX or the web browser used by WebX to move between the Mimics as required (see Use the Navigation Features to Display a Mimic).

Further Information

The Mimic Display

Hyperlinks.


Mimics Guide - Use the Navigation Features to Display a Mimic (Displaying a Mimic)

Use the Navigation Features to Display a Mimic

In ViewX, you can use the navigation features to move between a sequence of displays, including Mimics. So if there are Mimics in the sequence of displays that you have viewed, you can use the Back and Next options to display the Mimics as required. ViewX also has a Home option that, when selected, displays the Mimic that has been configured as the Home Page Mimic for the User account that is currently logged on.

If a Home Page Mimic has not been defined for the Guest User account or your User account, the Home toolbar button is grayed out and cannot be selected.

The web browser used by WebX also has Back and Next buttons that you can use to move between a sequence of displays, and the WebX interface has a Home button that, when selected, displays the Home Page Mimic for your User account. If you have not logged on, selecting the Home button will either display the Home Page Mimic for the Guest User account or will display the default Mimic for the system, depending on whether the Guest User has a Home Page Mimic configured). It is also possible to configure the web browser’s own Home button to display a Mimic by entering the http:/address of a Mimic in the web browser’s Home Page configuration settings.

To use the Navigation features to display a Mimic (ViewX and WebX):

  • Use the Back button/option to display a Mimic that was the previous ClearSCADA document on display (in a ‘chain’ of displays, where you have navigated away from the Mimic to another display).
  • Use the Forward button/option to display a Mimic that is the next ClearSCADA document on display (in a ‘chain’ of displays, where you have navigated away from the Mimic to another display).
  • Use the Home button/option to display a Mimic that is configured as the home page for your user account/the Guest user account or the default Mimic for your system. For more information, see Define the Client Specific Settings for the Guest User in the ClearSCADA Guide to Security and also see Define the Homepage Settings for a User in the ClearSCADA Guide to Security.

NOTE: If you access ViewX via a User account that does not have a Home Page Mimic defined in its configuration, the Home button is unavailable. In WebX, logging on via a User account that has no defined Home Page Mimic will cause the browser to display the default Mimic for the system.

Further Information

Navigating Between Mimics.

The Mimic Display


Mimics Guide - Use the Favorites Feature to Display a Mimic (Displaying a Mimic)

Use the Favorites Feature to Display a Mimic

If you have added the Mimic you want to display to your list of Favorites, you can access the Mimic by selecting the link to the Mimic from your Favorites folder. For more information, see Favorites Bar in the ClearSCADA Guide to ViewX and WebX Clients.

Further Information

The Mimic Display


Mimics Guide - Use a Go To link on a Form to Display a Mimic (Displaying a Mimic)

Use a Go To link on a Form to Display a Mimic

If you are logged on via a User account that can access configuration Forms for database items, you can use a Go To link to display a Mimic. This is only applicable when the Mimic you want to display has been associated with an item via a configuration field. For example, if the Mimic has been set as the Help View for database point, you can display the Mimic by selecting the Go To link next to the Help View field on the point’s Form.


Mimics Guide - Use an Alarms List or Alarm Banner to Display a Mimic (Displaying a Mimic)

Use an Alarms List or Alarm Banner to Display a Mimic

If an alarm is raised for a database item, and that item is configured to have an Alarm View or Help View, you can use the Display Alarm View and Display Help View actions to display a Mimic. Simply right-click on the relevant alarm in the Alarms List or Alarm Banner, then select:

  • Display Help View to display the Mimic that is configured as the Help View Mimic
  • Display Alarm View to display the Mimic that is configured as the Alarm View Mimic for the item in alarm.

NOTE: The Alarm Banner is only available in ViewX.

Further Information

Alarm Banner: see Alarm Banner in the ClearSCADA Guide to Alarms.

Alarms List: see Alarms Lists in the ClearSCADA Guide to Alarms.

The Mimic Display


Mimics Guide - Use the WebX Database Page to Display a Mimic (Displaying a Mimic)

Use the WebX Database Page to Display a Mimic

You can use the Database pages of the WebX interface to access hyperlinks that allow you to display Mimics. To do this, browse the database pages until you locate a Mimic item of interest, and then select the hyperlink to the Mimic item. This will cause the Mimic to be displayed in the WebX interface.

You can also select the Display Default View hyperlink to display the Mimic that has been configured as the Default View Mimic for a Group, Group Template or Group Instance.

Further Information

Mimics in WebX: see View a Mimic on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.

The Mimic Display


Mimics Guide - Displaying File Based Mimics (Displaying a Mimic)

Displaying File Based Mimics

Mimics can be saved as files that are not stored in the database, for example, a Mimic can be stored as a file on a memory stick. To open a Mimic that is not stored in the database, select the File menu in ViewX then select the Open option and browse to the Mimic you want to open. File based Mimics cannot be opened in WebX.

For more information, see File Based Mimics.


Mimics Guide - Run Mode and Design Mode (Displaying a Mimic)

Run Mode and Design Mode

In ViewX, you can display Mimics in two modes:

  • Run Mode:

When a Mimic is displayed in Run Mode, its operational features are active. For example, hyperlinks can be selected and will cause other displays to be shown, and animated values will update in real-time. Run Mode is usually the active mode for Mimics in control rooms etc., where they are used by operator level users to interact with the system.

The Mimic configuration-related features are unavailable when a Mimic is displayed in Run Mode. You cannot configure any Mimic objects when a Mimic is in Run mode, even if your User account has the Configure permission.

  • Design Mode:

When a Mimic is displayed in Design Mode, its configuration features are active. For example, if you select a hyperlink, you access the configuration settings for the hyperlink rather than trigger the hyperlink to show the target display.

You can only access Design Mode if your User account has the Configure permission for the Mimic. When a Mimic is in Design mode, you can add objects, edit objects, rearrange objects, add views and layers etc. You can also create scripts and animations and associate Mimic objects with pick actions.

Typically, operator level users have accounts that restrict their access to configuration features, so they will only use Mimics in Run Mode. Engineers often have the Configure permission and so can access both Run Mode and Design Mode.

If you are configuring a Mimic and need to test whether pick actions, animations etc. work, you will need to switch the Mimic from Design Mode into Run Mode. This is because pick action menus and animations are only active in Run Mode. To switch between the two modes:

  • Select the Design button on the File toolbar.

The Design button toggles between Run Mode and Design Mode (when it appears to be pressed down, the Mimic is in Design Mode).You can also select/deselect the Design option on the View menu.

NOTE: In WebX, you can only display Mimics in Run Mode. To configure a Mimic, you have to use a ViewX client.

Further Information

The Mimic Display


Mimics Guide - The Mimic Display (Displaying a Mimic)

The Mimic Display

When you display a Mimic, the Mimic is shown in the Document Display Area. If the Mimic is a new Mimic, it will be blank (in Design Mode, it may show rows and columns of dots - this is the Grid which is used for aligning Mimic objects and can be enabled or disabled as required). If you display a Mimic that has already been configured, it may contain graphical and text elements as well as selectable areas that provide functionality, such as hyperlinks and pick action menus.

Depending on the configuration of the Mimic, the permissions allocated to your user account, and the mode in which the Mimic is displayed, you may be able to:

  • Access pick action menus and context sensitive menus for Mimic objects by selecting or right-clicking on a Mimic object. The pick action menus provide access to operational features in Run Mode and configuration options in Design Mode.
  • Select Mimic objects that have been configured to act as hyperlinks to other displays
  • Use the Mimic Menu Options to access design and operational features for Mimic objects and the Mimic itself.
  • Use the Mimic Editing Toolbar and Alignment Toolbar to access Mimic design features.


Mimics Guide - Mimic Context Sensitive Menus (Displaying a Mimic)

Mimic Context Sensitive Menus

Mimics can contain a variety of context sensitive menus and selectable areas that acts as hyperlinks or actions. For example, during the configuration of a Mimic, you could use the context sensitive menu for a Mimic object to create a hyperlink pick action for the object. Then, with the Mimic displayed in Run Mode, you could select that object to trigger the hyperlink (this would cause another display to be shown).

When you display a Mimic in Design Mode, you can access a variety of features for individual objects by right-clicking on an object. This displays a context-sensitive menu that provides access to various configuration features for that object, including animations.

When you display a Mimic in Run Mode, you can access context sensitive menus by selecting any object that is configured to provide a context sensitive menu. You can determine which objects have context sensitive menus by looking closely at the cursor:

  • When you position the cursor over a Mimic object that provides access to a context sensitive menu or acts as a trigger for a method, hyperlink etc., the cursor changes from an arrow to a hand with a pointing finger.
  • When a Mimic object does not provide access to a context sensitive menu and does not act as a trigger, the cursor is shown as an arrow.

For information on the options that are displayed in the context sensitive menus, please refer to:

  • Designing a Mimic
  • Layers
  • Mimic Parameters
  • Animations
  • Views
  • Hyperlinks
  • Operating a Mimic.

Further Information

Run Mode and Design Mode.


Mimics Guide - Mimic Menu Options (Displaying a Mimic)

Mimic Menu Options

When you display a Mimic, you may have access to menus and menu that provide design and operation options. The menus and options you can use will vary according to the permissions of your user account and whether the Mimic is displayed in Design or Run mode.

The following list describes those menus and menu options that you can use specifically when designing and operating Mimics:

  • File
  • Save as File—Use to save a Mimic as a file rather than as a database item (see File Based Mimics).
  • Edit
  • Layers—Use to display the Layers window which you can use to create, delete, edit and re-order layers on your Mimic. This option is only available in Design mode. For more information, see Layers.
  • Views—Use to add, edit and remove Mimic views. This option is only available in Design mode. For more information, see Views.
  • Animations—Use to add, edit and remove Mimic animations. This option is only available in Design mode. For more information, see Animations.
  • Parameters—Use to add, edit and remove Mimic parameters. This option is only available in Design mode. For more information, see Mimic Parameters.
  • Import DXF File—Use to import a DXF file into a Mimic. This option is only available in Design mode. For more information, see Importing a DXF File.
  • Edit Script—Use to access the script for a Mimic. This option is only available in Design mode when the Mimic is configured to have scripting enabled. For more information, see Mimic Scripts in the ClearSCADA Guide to Scripting.
  • Debug Mode—Use to run the debugger on a Mimic script to test the validity of the script. For more information, see Mimic Scripts in the ClearSCADA Guide to Scripting.
  • View
  • Design—Use to toggle between Design Mode and Run Mode. For more information, see Run Mode and Design Mode.
  • Display Ruler—Use to toggle the ruler. The ruler is only available in Design mode. For more information, see Using the Mimic Ruler.
  • Show Pick Actions—Use to toggle the highlight that shows which Mimic objects are configured to provide access to a pick action. This sub-menu is only available in Run Mode and has a None option for turning the highlight off and an Active option for turning the highlight on.
  • Mimic Diagnostics—Use to display the Mimic Details dialog box which contains a list of the Mimic’s contents. You can copy individual items in the list to your PC’s clipboard by using the Copy option, or copy every item by selecting Copy All. For more information, see Displaying Mimic Diagnostics.
  • Mimic Navigator—Use to display the Mimic Navigator which helps you to locate any invalid expressions or animations on a Mimic. For more information, see Using the Mimic Navigator to Locate Invalid Animations and Pick Actions.
  • Tools
  • If you select Options to display the Options window, you will see that there is a Mimics tab that allows you to define General Mimic settings, Update Rates, and Custom Menu settings (see Using the Options Window to Define Settings that apply to All Mimics).
  • Insert—Use the options in the Insert menu to add new objects to a Mimic. You can choose from Line, Rectangle, Ellipse, Polygon, Pipe, Text, Image, Remote Image, Button, Pie Chart, Mimic, Trend, X-Y Plot, List, Alarm List, Windows Metafile, and SVG File. For more information, see Adding Objects to a Mimic.
  • Arrange—Use to reorder the objects on your Mimic, make and break groups of objects, combine and split polylines, reshape segments, rotate and flip objects, and change the alignment of objects. For more information, see Mimic Editing Features.

Of course, there are also common menus such as Window and Help and the menus also contain other options which are applicable to many types of ClearSCADA display. For more information, please refer to the documentation for the type of display you are using.


Mimics Guide - Mimic Editing Toolbar (Displaying a Mimic)

Mimic Editing Toolbar

ClearSCADA includes a Mimic Editing toolbar that you can use to quickly access Mimic configuration features. You can toggle the Mimic Editing toolbar on and off via the View>Toolbars menu.

The Mimic Editing toolbar allows you to add objects to a Mimic, display different layers and access the Layers window which you can use to configure the Mimic’s layers.

The buttons on the Mimic Editing toolbar are (from left to right):

  • Insert Line—Adds a line to the Mimic (see Add Shapes to a Mimic)
  • Insert Rectangle—Adds a rectangle to the Mimic (see Add Shapes to a Mimic)
  • Insert Ellipse—Adds an ellipse to the Mimic (see Add Shapes to a Mimic)
  • Insert Polygon—Adds a polygon to the Mimic (see Add Shapes to a Mimic)
  • Insert Pipe—Adds a pipe to the Mimic (see Add Shapes to a Mimic)
  • Insert Text—Adds a text box to the Mimic (see Add Text to a Mimic)
  • Insert Image—Adds an image file to the Mimic (see Embed an Image on a Mimic)
  • Insert Remote Image—Adds an image file that is hosted externally to the Mimic (see Add Remote Images to a Mimic)
  • Insert Button—Adds a button to the Mimic (see Add a Button to a Mimic)
  • Insert Pie Chart—Adds a pie chart to the Mimic (see Add a Pie Chart to a Mimic)
  • Insert Mimic—Embeds a Mimic on the Mimic (see Embed a Mimic on a Mimic)
  • Insert Trend—Embeds a pre-configured Trend on the Mimic (see Embed a Pre-Configured Trend on a Mimic)
  • Insert X-Y Plot—Embeds an X-Y Plot on the Mimic (see Embed an X-Y Plot on a Mimic)
  • Insert List—Embeds a List on the Mimic (see Embed a Queries List on a Mimic)
  • Insert Alarms List—Embeds an Alarms List on the Mimic (see Embed an Alarms List on a Mimic)
  • Active Layer—Use to navigate between the Mimic’s layers. The layer that you select is the active layer i.e. is the layer currently on display (see Layers).
  • Layers—Use to display the Layers window which you can use to add, edit and remove the Mimic’s layers (see Layers).

Further Information

Alignment Toolbar


Mimics Guide - Alignment Toolbar (Displaying a Mimic)

Alignment Toolbar

ClearSCADA includes an Alignment toolbar that you can use to quickly access Mimic arrangement features. You can toggle the Alignment toolbar on and off via the View>Toolbars menu.

The Alignment toolbar allows you to control how Mimic objects are placed on the Mimic background. You can also use it to Group and Un-Group Mimic objects.

Certain buttons on the Alignment toolbar are only available when a minimum of two or three Mimic objects are displayed or currently selected. The Alignment buttons are (in order from left to right):

  • Group—Only available when two or more Mimic objects are selected, the Group button groups the selected objects so that they become 1 single group object. (see Making a Group of Mimic Objects)
  • UnGroup—Only available when a Group object is selected, the UnGroup button breaks a group so that its objects become individual objects again (see Making a Group of Mimic Objects).
  • Bring to Front—Only available when two or more Mimic objects are shown on the Mimic, the Bring to Front button moves the currently selected object(s) in front of the other objects on the Mimic. For more information, see Changing the Order of Mimic Objects.
  • Send to Back—Only available when two or more Mimic objects are shown on the Mimic, the Send to Back button moves the currently selected object(s) behind the other objects on the Mimic. For more information, see Changing the Order of Mimic Objects.
  • Bring Forward—Only available when two or more Mimic objects are shown on the Mimic, the Bring Forward button moves the currently selected object(s) in front of one other layer of objects on the Mimic. For more information, see Changing the Order of Mimic Objects.
  • Send Backward—Only available when two or more Mimic objects are shown on the Mimic, the Bring Forward button moves the currently selected object(s) behind one other layer of objects on the Mimic. For more information, see Changing the Order of Mimic Objects.
  • Left Align—Only available when two or more Mimic objects are selected on the Mimic, the Left Align button moves the currently selected object(s) so that they are aligned with the left-hand side of the left-most selected object. For more information, see Changing the Order of Mimic Objects.
  • Center Horizontally—Only available when two or more Mimic objects are selected on the Mimic, the Center Horizontally button moves the currently selected object(s) so that they are aligned with the horizontal center of the background. For more information, see Changing the Order of Mimic Objects.
  • Right Align—Only available when two or more Mimic objects are selected on the Mimic, the Right Align button moves the currently selected object(s) so that they are aligned with the right-hand side of the right-most selected object. For more information, see Changing the Order of Mimic Objects.
  • Top Align—Only available when two or more Mimic objects are selected on the Mimic, the Top Align button moves the currently selected object(s) so that they are aligned with the uppermost side of the uppermost selected object. For more information, see Changing the Order of Mimic Objects.
  • Center Vertically—Only available when two or more Mimic objects are selected on the Mimic, the Center Vertically button moves the currently selected object(s) so that they are aligned with the vertical center of the Mimic background. For more information, see Changing the Order of Mimic Objects.
  • Bottom Align—Only available when two or more Mimic objects are selected on the Mimic, the Bottom Align button moves the currently selected object(s) so that they are aligned with the bottom edge of the selected object that is nearest the bottom of the Mimic. For more information, see Changing the Order of Mimic Objects.
  • Space Horizontal—Only available when three or more Mimic objects are selected on the Mimic, the Space Horizontal button moves the currently selected object(s) so that they are evenly spaced horizontally across the Mimic. For more information, see Changing the Order of Mimic Objects.
  • Space Vertical—Only available when three or more Mimic objects are selected on the Mimic, the Space Horizontal button moves the currently selected object(s) so that they are evenly spaced vertically across the Mimic. For more information, see Changing the Order of Mimic Objects.
  • Grid—Use to toggle the Grid on and off (see Define the Grid Settings for a Mimic).
  • Ruler—Use to toggle the Ruler on and off (see Using the Mimic Ruler).

Further Information

Mimic Editing Toolbar


Mimics Guide - Operating a Mimic

Operating a Mimic

This section describes the basic navigation and operation features for Mimics, which include:

  • Magnifying a Mimic (Zooming)
  • Moving the Mimic within the Display (Panning)
  • Locking a Mimic
  • Using the Navigator on a Mimic
  • Navigating Between Mimics
  • Switching Between Layers on a Mimic
  • Switching Between Views on a Mimic
  • Controlling Items via a Mimic
  • Using Embedded Objects on Mimics.

Operator level users will need to have a good knowledge of the navigation and operation features so that they can perform their duties. Engineer level users will also need an understanding of the navigation and operation features so that they can test the Mimics that they have configured. Some features, such as the magnification tools can be used during Mimic configuration.

NOTE: For information on common displays such as menus, toolbars, and the Explorer Bar, please refer to the ClearSCADA Guide to ViewX and WebX.


Mimics Guide - Magnifying a Mimic (Zooming) (Operating a Mimic)

Magnifying a Mimic (Zooming)

You can use the Zoom tools to magnify a Mimic. This is useful for viewing details in close up and for revealing layers.

Some Mimics have layers that are only visible at certain levels of magnification. Typically, the more magnification that is applied to a Mimic with layers, the more details are revealed (as layers containing more details are made visible).

There are several magnification tools available:

  • Zoom
  • Zoom In and Zoom Out
  • Zoom Box.

If you have a mouse that has a wheel, you can use the wheel to change the level of magnification. Roll the wheel forward to zoom in and roll it backwards to zoom out.

NOTE: The various magnification tools only have the described effect if the Mimic is configured to allow magnification. Mimics can have their Zooming features enabled and disabled via the Mimic Properties window (see Define the Magnification Settings for a Mimic).


Mimics Guide - Zoom (Operating a Mimic)

Zoom

In ViewX, you can use the Zoom combo box to display a Mimic at default levels of magnification or to define a custom magnification level. The Zoom combo box is shown on the Navigate toolbar.

In WebX, the Zoom feature is made available via the context sensitive menu that is displayed when you right-click on the background of a Mimic.

When you select the Zoom combo box, a list of default magnification levels is shown. You can choose any of the magnification levels or you can highlight the entry in the combo box and overwrite it by typing a new value.

Overwriting the Zoom value is useful when you need to set the Mimic to a specific level of magnification. For example, if a Mimic has a layer that is configured to be only visible when the Mimic is shown at 30-50% magnification, you can overwrite the Zoom value to any value in this range.

As well as the default levels of magnification, the Zoom combo box also provides 3 magnification options:

  • Size to Picture—Magnifies the Mimic so that it makes maximum use of the ViewX Document Display Area. The aspect ratio maintains the dimensions of the Mimic and determines the amount of border that is shown.
  • Size to Content—Magnifies the Mimic so that the content of the Mimic makes maximum use of the ViewX Document Display Area.
  • Size to Selection—Magnifies the Mimic so that the Mimic display is zoomed in on the Mimic object you have selected.

The Zoom combo box is the magnification tool that provides you with the greatest amount of control—you can specify the exact amount of magnification required.


Mimics Guide - Zoom In and Zoom Out (Operating a Mimic)

Zoom In and Zoom Out

Both ViewX and WebX have Zoom In and Zoom Out features. In ViewX, Zoom In and Zoom Out can be performed via the Zoom In button and a Zoom Out button on the Navigate toolbar:

Zoom In
Zoom Out
Zoom Out

In WebX, the Zoom In and Zoom Out features are available via the context sensitive menu that is displayed when you right-click on the background of a Mimic.

You can use the Zoom In tool to increase the magnification of your Mimic. The Zoom In tool is useful for magnifying complex areas of a Mimic that may not be clearly visible when the Mimic is displayed at its default magnification. It can also be used to display different layers (Mimics can contain layers of information, with certain layers only visible when the Mimic is shown in a specified range of magnification).

If you select the Zoom In tool, the magnification level is increased.

The Zoom Out tool has the opposite effect to the Zoom In tool—it reduces the level of magnification. The Zoom Out tool is useful for reducing the magnification of a Mimic so that you can see more of the Mimic, although it may make it more difficult to view complex areas or small text.


Mimics Guide - Zoom Box (Operating a Mimic)

Zoom Box

You can use the Zoom Box tool to magnify a Mimic. The main advantage of the Zoom Box over the other Zoom tools is that it allows you to specify which part of a Mimic is to be shown at an increased level of magnification.

To use the Zoom Box:

  1. Activate the Zoom Box tool:

In ViewX, select the Zoom Box button on the Navigate toolbar.

In WebX, right-click on the background of the Mimic to display a context sensitive menu, then select the Zoom Box option.

  2. Draw a selection box over the area that you want to magnify.
    The area will be magnified when you release the left-hand mouse button.
  3. Repeat this procedure as required.


Mimics Guide - Moving the Mimic within the Display (Panning) (Operating a Mimic)

Moving the Mimic within the Display (Panning)

You can use the Pan tool to move a Mimic within the ViewX Document Display Area or WebX Document Display Area. This is useful when you want to look at another part of a Mimic without changing the level of magnification.

To pan a Mimic:

  1. Activate the Pan tool:

In ViewX, select the Pan button on the Navigate toolbar.

In WebX, right-click on the background of the Mimic to display a context sensitive menu, then select the Pan option.

  2. Select any area on the Mimic and keep the left-hand mouse button pressed down.
  3. Move the cursor to move the Mimic within the ViewX Document Display Area.
  4. Release the left-hand mouse button when the required part of the Mimic is shown.

NOTE: You can also use the Navigator tool to move the Mimic within the ViewX Document Display Area (see Using the Navigator on a Mimic).


Mimics Guide - Locking a Mimic (Operating a Mimic)

Locking a Mimic

You can use the Lock tool to determine whether a Mimic retains its original dimensions - which correspond to A4 paper (landscape) - when you resize the ViewX/Webx window. This feature is useful for setting a Mimic so that it is shown in its entirety.

When you activate the Lock tool, the Mimic makes maximum use of the ViewX or WebX Document Display Area. This means that the level of magnification is changed automatically so that the entire Mimic is visible.

When you de-activate the Lock tool, ViewX or WebX disregards the Mimic' s original dimensions. The Mimic remains at its defined magnification and size—parts of the Mimic may be out of view when you resize the ViewX/WebX window (although you will be able to scroll to any area of the Mimic).

To use the Lock tool:

  • In ViewX, select the Lock button [image] on the Navigate bar.
  • In WebX, right-click on the background of the Mimic to display a context sensitive menu, then select the Zoom Lock option.


Mimics Guide - Using the Navigator on a Mimic (Operating a Mimic)

Using the Navigator on a Mimic

The Navigator Window is an overlaid window that provides an overview of the Mimic on display. You can use it to view and magnify a specific section of a Mimic.

When you use the Navigator Window to magnify a Mimic, a Navigation Box is shown in the Navigator Window. The Navigation Box allows you to see how the magnified section of the Mimic relates to the entire Mimic. It also allows you to access other parts of the Mimic without changing the level of magnification.

To use the Navigator window:

  1. Select the Navigator button on the Navigate toolbar.
    The Navigator window is displayed.
  2. In the Navigator window, drag the Navigator Box over the area of the Mimic that you want to view.
    The relevant part of the Mimic is shown in the ViewX Document Display Area.
    The Navigator window overlays the Mimic display. It contains a Navigator Box that you can use to select the part of the Mimic that you want to view.

  3. Use the Zoom In and Zoom Out tools (or the mouse wheel if available) to increase or decrease the level of magnification. When you change the level of magnification, you will see that the Navigator Box becomes smaller (when you zoom in) or larger (when you zoom out).

NOTE: Embedded objects such as lists are not shown in the Navigator window.

For more information on the Zoom In and Zoom Out tools, see Zoom In and Zoom Out.


Mimics Guide - Navigating Between Mimics (Operating a Mimic)

Navigating Between Mimics

Hyperlinks are links from one display to another, for example, a link from a Mimic to a Trend. They work in the same way as hyperlinks on web pages and are useful navigation tools—they allow you to access a variety of related displays from a single Mimic. The 'target' display (the display that is shown when the hyperlink is selected) can be displayed in place of the current Mimic or can be displayed in a new window, or another application, depending on the configuration of the hyperlink (see Hyperlinks).

By using hyperlinks, you can ' chain' Mimics—this means that a Mimic has a hyperlink to another Mimic. For example, an overview Mimic could represent a geographical region, and could contain hyperlinks to other Mimics that represent each site in that region. Similarly, the site Mimics could have hyperlinks to Mimics that represent the plant etc.

When you have used a hyperlink, you can use the Back button on the Operate toolbar (ViewX) or web browser (WebX) to step back in the sequence so that the previous display is shown. After you have used the Back button, you can use the Forward button to step forward in the sequence so that the next display in the sequence is shown.

Back
Forward

Example:

An operator begins by viewing the default Mimic for a Group. In this instance, the default Mimic is the 'Area 2 Monitoring Station' Mimic (1). The operator selects a link (in this case, a button is configured to act as a hyperlink) to the 'Site Overview' Mimic (2). The operator selects the Back button to return to the 'Area 2 Monitoring Station Mimic' (1).

The operator selects the Forward button to proceed to the 'Site Overview' Mimic (2). On the 'Site Overview' Mimic, the operator selects the Site Alarms button which links to the 'Alarms' Mimic (3). Then the operator selects the Staff button on the 'Alarms' Mimic to link to the 'Staff' Mimic (4). On the 'Staff' Mimic, the operator selects the Back button and is returned to the 'Alarms' Mimic (3). From the 'Alarms' Mimic, the operator can select the Back button again to return to the 'Site Overview' Mimic or select the Forward button to proceed to the 'Staff' Mimic.


Mimics Guide - Switching Between Layers on a Mimic (Operating a Mimic)

Switching Between Layers on a Mimic

Some Mimics are configured to have layers. Each layer contains different objects and the layer may only be visible at certain levels of magnification.

If a layer is set to be Operator Controlled, operators can switch from one layer to another in Run mode. This allows operator levels to view each layer separately. If a layer is not Operator Controlled, operators may only be able to view the various layers by zooming in or out on the Mimic.

To switch between layers on a Mimic that is displayed in Run Mode:

  1. Right-click on the Mimic.
    A context sensitive menu is displayed. It contains an option for each layer. The layers that are currently on display are prefixed by a check mark.
  2. Select the option for the layer that you want to show or hide. If the layer was previously on display, its check mark will be removed when you select it and the layer will be hidden; if the layer was not on display, a check mark will be added to the option and the layer will be shown on the Mimic.

NOTE: The layer names are defined during the configuration of the layers on the Mimic.

For more information on layers, see Layers.


Mimics Guide - Switching Between Views on a Mimic (Operating a Mimic)

Switching Between Views on a Mimic

If a Mimic has been configured to have Views, you can use the Views combo box to switch from one view to another. Each View shows a selected part of a Mimic at a specific level of magnification.

Users that have the Configure permission can magnify a specific part of a Mimic and save that display as a View. For example, an engineer could zoom in on a Mimic that contains a pump object so that the pump object fills the Mimic display. The engineer could then store the magnified view of the pump object as a View.

Views provide fast access to specific parts of a Mimic. They are particularly useful on large, complex Mimics, as instead of having to Zoom and Pan the Mimic to find the part you want to view, you can select the stored view from the Views combo box.

To switch between Views on a Mimic:

  1. Either:
  • Select the Views combo box on the Navigate bar (ViewX).

Or:

  • Right-click on the background of the Mimic to display a context sensitive menu, then select the Views option to display a further list (WebX).
  2. Select the required View from the list. (The name of each View is defined by the user that configured the Mimic).
    The Mimic is magnified and panned automatically to show the selected view.

For more information on Mimic Views, see Views.


Mimics Guide - Controlling Items via a Mimic (Operating a Mimic)

Controlling Items via a Mimic

Typically, Mimics are designed to allow operators to perform their duties via the Mimic displays. The Mimics often contain objects that are associated with pick action menus—when you select these objects, a menu is displayed. The menu contains the options that allow you to interact with the system, such as Override and the various alarm controls

Pick action menu is made available by selecting a pre-configured object on a Mimic. In this case, the embedded list provides access to a pick action menu.

Mimic objects can also be configured to perform a method when they are selected. This means that when you select the object, a specific action takes place. For example, a Mimic object could be configured to write a value to the database when you select it.

To access a pick action menu on a Mimic, simply select an object that has been configured to provide access to a pick action menu. Usually, Mimics are designed in such a way that it is clear which objects provide access to controls. For example, if a button is configured to write a value to the database, the text on the button should indicate its purpose.

NOTE: The availability of pick actions on a Mimic is dependent on the configuration of the Mimic.


Mimics Guide - Using Embedded Objects on Mimics (Operating a Mimic)

Using Embedded Objects on Mimics

Mimics can contain embedded objects such as Trends, Lists, and other Mimics. Each embedded object provides access to the same features as the original version.

Example:

A Mimic named 'River Level and Flow' contains several control buttons. When selected, these buttons allow the user to override points.

The 'River Level and Flow' Mimic is embedded on another Mimic named 'Overview'. Users can select the control buttons on the embedded version of the 'River Level and Flow' Mimic in the same way as if the users had selected the buttons on the original 'River Level and Flow' Mimic.

Selecting a button on the embedded 'River Level and Flow' allows the user to override a point in the same way as if the button was selected on the actual 'River Level and Flow' Mimic.


Mimics Guide - Creating a New Mimic

Creating a New Mimic

To create a new Mimic that is stored in the database, you need to create a new Mimic database item. You can only create a new Mimic database item if your User account has the Configure permission for the Group that is to contain the Mimic.

To create a new Mimic database item:

  1. In the Database Bar, right-click on the Group, Group Template, or system that is to contain the new Mimic.
    A context sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Mimic option.
    A new Mimic database item is added to the Database Bar. It is selected automatically, ready for you to define its name.
  4. Type a suitable name then press the Enter key to confirm (or select another part of the ViewX interface).
    Mimic database items are represented by this icon.

When you have created a new Mimic database item, you can configure the Mimic. To configure the Mimic, you need to display it in Design mode (see Displaying a Mimic). Once the Mimic is displayed in Design mode, you can add objects to it (see Adding Objects to a Mimic) and edit them.

We recommend that you refer to Designing a Mimic before starting your Mimic configuration.

NOTE: You can also create new Mimics that are not part of the database (see File Based Mimics).

You can also define the Mimic properties (see Configuring the Mimic Properties)


Mimics Guide - File Based Mimics

File Based Mimics

You can create Mimics that are not stored as part of the database. Instead, they are stored as files on your network or on removable media such as CD-R.

File based Mimics are useful for engineers that need to experiment with Mimic configuration. As file based Mimics have no effect on the database, users can alter settings knowing that their actions will not have an adverse effect on the system.

There are 2 ways to create a file based Mimic:

  1. Log on via an account that has the Configure Local Files permission (on the User Form) and has the Configure permission for the Group that contains the Mimic.
  2. Select the New button on the File toolbar (or select the File menu then the New option, then the Mimic option on the New File window)

Or:

  1. Log on via an account that has the Configure Local Files permission (on the User Form) and has the Configure permission for the Group that contains the Mimic.
  2. Open a Mimic in Design mode (see Displaying a Mimic)
  3. Select the File menu, then select the Save As File button.
  4. Choose an appropriate location and enter a suitable name for the Mimic file.
  5. Select the OK button to confirm.
    A copy of the Mimic in the database is saved as a file at the specified location.

To open a file based Mimic:

  1. Select the Open button on the File toolbar or select the File menu, then the Open option.
  2. Browse to the Mimic file.
  3. Select the Mimic file and then select the OK button.

You can edit file based Mimics in exactly the same way as Mimics that are stored in the database. The only difference is that any references to items in the database have to use absolute paths. You need to remember this if you enter references manually.


Mimics Guide - Designing a Mimic

Designing a Mimic

To configure a Mimic, you have to log on via a User account that has the Configure permission for the Group that is to contain (or already contains), the Mimic. To save the Mimic to the database, your User account also needs to have the Configure Document and Configure Database permissions (defined in the User account configuration). To save the Mimic as a file, your User account has to have the Configure Local Files permission (also defined in the User account configuration).

When you have logged on via a suitable account, you can display a Mimic in Design mode and begin configuring it by adding objects and editing them. Before you create a Mimic, you should familiarize yourself with the following sections:

  • Design Considerations
  • Using the Symbol Library
  • Mimic Editing Features
  • Keyboard Shortcuts.

These sections will help you to design user-friendly Mimics and work efficiently. By using features such as the Symbol Library, you can significantly reduce the amount of time and effort required to create a practical and visually appealing Mimic.

When you are ready to begin the configuration of your Mimic, we recommend you begin by Configuring the Mimic Properties.


Mimics Guide - Design Considerations (Designing a Mimic)

Design Considerations

We recommend that each Mimic you design is:

  • Easy to understand—Information should be clear, easy to read, and structured in a logical way. Users should be able to easily understand the purpose of the Mimic and be able to obtain the information they require.
  • Easy to interact with—Operators will be able to function more quickly and efficiently if the interactive parts of each Mimic (controls, navigation features etc.) are clearly labelled.
  • Aesthetically pleasing—the Mimic should not be cluttered with too much information and should use a color scheme that is complimentary to the information and objects being displayed.
  • Designed to be efficient—Mimics with excessive amounts of the following objects can cause slow performance:
  • Transparent or semi-transparent objects
  • Polylines (in particular, where lots of separate lines are used where a single segmented line or curved line could be used to create the same effect)
  • Objects with gradient shading
  • Embedded objects, especially Mimics
  • Objects with the Fast Update feature enabled (the Fast Update feature should be used sparingly).
  • Designed to make use of the default Mimic Properties—If you need to create multiple Mimics that require objects with the same settings, you will be able to save time and effort by using the Mimic Properties settings. The Mimic Properties settings allow you to define default settings for a single Mimic that you are configuring, or for every Mimic that you configure on your client.

The default settings can reduce your workload, especially if you need to configure several Mimics to contain objects that have the same attributes. For example, if you are configuring 6 Mimics and each of these Mimics needs text boxes that use the same coloring, font, size etc., it is quicker to define the text box settings once as default settings than to configure them individually. Once you have defined the required settings as the default settings, every text box that you add will already have the required settings in place (as it will have the default settings automatically).

For more information on applying default settings to a single Mimic or every new Mimic that you configure on your client, see Configuring the Mimic Properties.

  • Designed to make use of Group Templates and Group Instances—If you need to create multiple Mimics that contain the same type of information, you may benefit from using the Group Template and Group Instances features. By using Group Templates and Group Instances, you may be able to significantly reduce the amount of time it takes to configure and maintain the Mimics.

When you create a Mimic in a Group Template, copies of that Mimic are automatically added to the Group Instances that are 'children' of the Group Template. The Mimics in the Group Instances are exactly the same as the Mimic in the Group Template, and any changes you make to the Mimic in the Group Template are inherited by the Mimics in the Group Instances. By default, you cannot edit any of the features of the Mimics in the Group Instances. However, by using parameter items and the Property Override features, you can configure a Mimic in a Group Template so that some of its properties can be edited in the Group Instance versions.

Parameter items allow you to store values (strings, links, doubles etc.) that can be used as the source of an animation on a Mimic. This means that you can create animations on a Mimic in a Group Template that obtain their source values from the parameter items that are stored in the Group Template. The Group Instances that are associated with the Group Template automatically contain copies of the parameter items. By using the Property Override feature on the parameter items in the Group Template, you can allow the values of the parameter items to be reconfigured within each Group Instance. You can then change the source values within each Group Instance as required. The Mimics in the Group Instances will retain the overall look of the Mimic in the Group Template, but can have different values as the source of the animations as required. This reduces the amount of time and effort required to configure Mimics, as you can design one 'master' Mimic that is used throughout the system. You can then change the values of the parameters in the Group Instances so that each Group Instance version of the Mimic displays different information.

Example:

A Group Template is created along with two Group Instances named 'West' and 'East' respectively. The 'West' and 'East' Group Instances are associated with the Group Template and so inherit their configuration and items from the Group Template.

A Mimic is configured in a Group Template. The Mimic contains a text box that displays the name of a site: 'Main Site'. The text box is animated by a parameter item that stores the text string 'Main Site'. By default, the Group Instance versions of the Mimic also display 'Main Site' in the text box.

The Property Override feature of the Group Template item is used to enable overrides on the string property of the parameter item. This means that users can configure a new string for the Group Instance versions of the parameter item.

In the 'West' Group Instance, a user accesses the Form for the parameter item and changes the String value from 'Main Site' to 'Western Site'. The Mimic in the 'West' Group Instance changes—its text box now displays 'Western Site'. The Mimic in the 'East' Group Instance and in the Group Template both still display 'Main Site'.

In the 'East' Group Instance, the string value of the parameter item is reconfigured to be 'Eastern Site'. The Mimic in the 'East' Group Instance changes to display 'Eastern Site'. The Mimic in the Group Template still displays 'Main Site' and the Mimic in the 'West' Group Instance still displays 'Western Site'.

A tank symbol is added to the Mimic in the Group Template. As the Group Instances are still associated with the Group Template, the tank is also added to the Mimics in the Group Instances. Only those properties that can be overridden for each Group Instance item can be different on the Group Instance versions of the Mimic (in this case, the string values of the parameters can be different).

NOTE: Do not confuse parameter database items with Mimic parameters. Mimic parameters are used with embedded Mimics and allow you to create embedded Mimics that vary according to the values associated with its parameters. Parameter database items simply store values that can be used to animate Mimic properties.

By taking these factors into account before you begin to design your Mimic, you can go on to create a Mimic that runs efficiently, and provides the functionality you require.

You should also consider:

  • Using the symbol Mimics from the symbol library to reduce the amount of time it takes to create visually appealing Mimic objects (see Using the Symbol Library).
  • How users will access the Mimic. A Mimic can be associated with a Default View, Alarm View, or Help View as well as being available as a database item and the ‘target’ display of hyperlinks.

For more information, please refer to the following sections:

  • Default View: see Defining a Default View in the ClearSCADA Guide to Core Configuration
  • Alarm View: see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration
  • Help View: see Specify a Help View in the ClearSCADA Guide to Core Configuration
  • Hyperlinks.

When you have considered your design and are ready to begin the Mimic configuration, you will need to add objects to your Mimic (see Adding Objects to a Mimic), and you will need to edit them (see Mimic Editing Features).

Further Information

For more information on Group Templates, Group Instances, and Property Overrides, see Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration.


Mimics Guide - Using the Symbol Library (Designing a Mimic)

Using the Symbol Library

ClearSCADA comes complete with a symbol library that contains a variety of pre-configured Mimic objects such as maps, pumps, valves, etc. You can use the symbol Mimics in your own Mimic designs.

A selection of the symbol Mimics that are available in the Symbol Library.

You can:

  • Embed a Mimic from the symbol library onto your Mimic
  • Copy the objects on a symbol library Mimic and paste them onto your own Mimic. This is useful if you only want to use part of a symbol Mimic or you want to make alterations to the object(s) on the symbol Mimic.

By using the symbol library, you can significantly reduce the amount of time it takes to configure your Mimics. You can use the symbol library Mimics to represent common system objects such as pumps, valves, pylons etc.

The symbol library Mimics also illustrate some of the effects that can be achieved with the various Mimic editing tools.

The latest version of the symbol library is included on your ClearSCADA installation CD (you can import the library file into your database by using the Import option that is available when you right-click on a system in the Database Bar in ViewX).


Mimics Guide - Mimic Editing Features (Designing a Mimic)

Mimic Editing Features

When you have added objects to a Mimic, you will need to edit them so that they are the appropriate size and color and use suitable fonts, animations, pick actions etc.

To alter the color and configuration of a Mimic object, you need to access its Properties settings. To do this, you need to display the object's Properties window. You can also use the Properties window to set up animations and pick actions. For more information, refer to the Editing section that applies to the object you want to configure. For example, if you want to change the color of a pipe, refer to the Editing a Pipe section.

Each Mimic object also has an editing pick menu. You can access the editing pick menu by right-clicking on the required object (in Design mode).

Each Mimic object has an editing pick menu that you can use to access editing features.

The editing pick menu has the following options which you can use during the design of your Mimic:

  • Cut—Use to remove the object from the Mimic and place in the clipboard storage area of your PC.
  • Copy—Use to make a duplicate of the selected object. The duplicate is placed in the clipboard storage area of your PC and replaces any data that is in the clipboard.
  • Paste—Use to add the contents of your PC's clipboard storage area to the Mimic.
  • Paste Special—Use to add the contents of your PC's clipboard storage area to the Mimic. This option differs to the standard Paste option as it allows you to select which format is used for the information being 'pasted' onto a Mimic. The Paste Special option is only available when the clipboard area contains data in multiple formats, for example, if you use the Copy Shortcut feature, this copies a hyperlink to the clipboard area. You can then use the Paste Special option to paste the hyperlink onto a Mimic as an actual hyperlink or as plain text.
  • Delete—Use to remove the selected object from the Mimic. The deleted object is not stored on your PC's clipboard area.
  • Bring to Front—Use to move a Mimic object to the front (see Changing the Order of Mimic Objects).
  • Send to Back—Use to move a Mimic object to the back (see Changing the Order of Mimic Objects).
  • Bring Forward—Use to move a Mimic object forwards (see Changing the Order of Mimic Objects).
  • Send Backward—Use to move a Mimic object backwards (see Changing the Order of Mimic Objects).
  • Flip—Use to flip a Mimic object so that it becomes a mirror image of its original self (see Flipping a Mimic Object).
  • Rotate—Use to change the angle of a Mimic object (see Rotating a Mimic Object).
  • Animations—Use to access the Animations window for the selected Mimic object (see Using the Animations Window).
  • Pick Action Wizard—Use to access the Pick Action Wizard for the selected Mimic object (see Associating Mimic Objects with Pick Actions).
  • Advanced Pick Menu—Use to access the Pick Menu window (see Custom Pick Action Menus)
  • Define Path—Use to start the path definition process. After selecting this option, you can define the path for a position animation (see Position Animations)
  • Edit Points—Use to change the shape of a Mimic object (see Changing the Shape of an Object).
  • Convert to Pipe—Use to convert the selected shape or line into a pipe object.
  • Convert to Polyline—Use to convert the selected pipe object into a shape or line.
  • Simplify—Use to simplify a Mimic object so that it contains fewer lines. This is designed for use with the Import DXF File feature (see Importing a DXF File).
  • Properties—Use to access the Properties window for the selected Mimic object. For more information, please refer to the section that describes editing the type of object. For example, if you want to use the Properties window for a pipe object, see Editing a Pipe.

There are also useful Mimic editing features available via the main menu options at the top of the display. Of particular use on Mimics are:

  • Edit > Layers—Displays the Layers window (see Layers)
  • Edit > Views—Displays the Views window (see Views)
  • Edit > Animations—Displays the Animations window for the currently selected object (see Animations)
  • Edit > Parameters—Displays the Mimic Parameters window (see Mimic Parameters)
  • Edit > Import DXF File—Allows you to import a DXF file (see Importing a DXF File)
  • View > Design—Allows you to toggle between Run mode and Design mode.
  • View > Mimic Diagnostics—Displays the Mimic Details window. This option is only available when a Mimic object is currently selected and it provides a list of detailed information about that object, including the total number of its layers, pick actions etc.
  • View > Mimic Navigator—Displays the Mimic Navigator window. This option is only available when a Mimic object is currently selected and it allows you to check for invalid configuration on a Mimic (see Using the Mimic Navigator to Locate Invalid Animations and Pick Actions). You can also use this feature to switch easily between objects on a Mimic - simply double click on the object you want to select in the Mimic Navigator, then close the Properties window that is displayed to select the object.
  • Insert > Line—Allows you to insert a line (see Add Shapes to a Mimic)
  • Insert > Rectangle—Allows you to insert a rectangle (see Add Shapes to a Mimic)
  • Insert > Ellipse—Allows you to insert an ellipse (see Add Shapes to a Mimic)
  • Insert > Polygon—Allows you to insert a polygon (see Add Shapes to a Mimic)
  • Insert > Pipe—Allows you to insert a pipe (see Add Shapes to a Mimic)
  • Insert > Text—Allows you to insert text (see Add Text to a Mimic)
  • Insert > Image—Allows you to insert an image (see Embed an Image on a Mimic)
  • Insert > Remote Image—Allows you to insert an image that is stored on a web server (see Add Remote Images to a Mimic)
  • Insert > Button—Allows you to insert a button (see Add a Button to a Mimic)
  • Insert > Pie Chart—Allows you to insert a pie chart (see Add a Pie Chart to a Mimic)
  • Insert > Mimic—Allows you to insert an embedded Mimic (see Embed a Mimic on a Mimic)
  • Insert > Trend—Allows you to insert an embedded pre-configured Trend (see Embed a Pre-Configured Trend on a Mimic)
  • Insert > X-Y Plot—Allows you to insert an embedded X-Y Plot (see Embed an X-Y Plot on a Mimic)
  • Insert > Alarm List—Allows you to insert an embedded Alarms List (see Embed an Alarms List on a Mimic)
  • Insert > Windows Meta File—Allows you to import a Windows meta file (see Importing a Windows Metafile)
  • Insert > SVG File—Allows you to import an SVG file (see Importing an SVG File)
  • Arrange > Bring to Front—Use to bring an object to the front of a layer (see Changing the Order of Mimic Objects)
  • Arrange > Send to Back—Use to send an object to the back of a layer (see Changing the Order of Mimic Objects).
  • Arrange > Bring Forward—Use to bring an object forward one position on a layer (see Changing the Order of Mimic Objects).
  • Arrange > Send Backward—Use to send an object back one position on a layer (see Changing the Order of Mimic Objects).
  • Arrange > Make Group—Use to group multiple selected objects (see Making a Group of Mimic Objects)
  • Arrange > Break Group—Use to ungroup a selected group of objects (see Making a Group of Mimic Objects).
  • Arrange > Combine Polylines—Use to merge multiple selected shapes into a single shape (see Creating a New Shape by Combining Mimic Objects).
  • Arrange > Split Polyline—Use to separate a combined shape into separate shapes (see Creating a New Shape by Combining Mimic Objects).
  • Arrange > Align—Use to position objects on a layer. You can choose from Left (aligns the left-hand edges of the selected objects), Center Horizontally (aligns the center of each of the selected objects along the horizontal axis), Right (aligns the right-hand side of the selected objects), Top (aligns the top edge of the selected objects), Center Vertically (aligns the center of each of the selected objects along the vertical axis), Bottom (aligns the bottom edge of the selected objects).
  • Arrange > Space Evenly—Distributes the selected objects so that they have an equal amount of space between them. The arrangement can be applied along the Horizontal axis or Vertical axis.
  • Arrange > Flip—Allows you to flip an object (see Flipping a Mimic Object)
  • Arrange > Rotate—Allows you to rotate an object (see Rotating a Mimic Object)
  • Arrange >Segment—Allows you to split, curve, open, close and detach a segment (see Changing the Shape of an Object)
  • Arrange >Simplify Polylines—Use to simplify a Mimic object so that it contains fewer lines. This is designed for use with the Import DXF File feature (see Importing a DXF File).


Mimics Guide - Changing the Order of Mimic Objects (Designing a Mimic)

Changing the Order of Mimic Objects

When objects on a Mimic overlap, they are in an order. For example, if a square is placed over a circle, the circle is regarded as being behind the square. The square is regarded as being in front of the circle.

Square is in front of the circle. The circle is behind the square.

If a triangle is added to the Mimic, it is positioned in front of the square by default.

By using the Bring to Front, Send to Back, Bring Forward, and Send Backward features, you can change the order of the objects on your Mimic. For example, by using the Bring Forward option on the Mimic shown above, you could move the circle in front of the square.

To use the order features:

  1. Display the relevant Mimic in Design mode.
  2. Right-click on the Mimic object that you want to move.
    A context sensitive menu is displayed.
  3. Select the required option:
  • Bring to Front—Moves the object in front of other objects.
  • Send to Back—Moves the object behind other objects.
  • Bring Forward—Moves the object one place forward in the order.
  • Send Backward—Moves the object one place backward in the order.

NOTE: Alternatively, you can also use the ordering options on the Alignment Bar or on the Arrange menu.


Mimics Guide - Flipping a Mimic Object (Designing a Mimic)

Flipping a Mimic Object

You can flip a Mimic object so that it appears as a mirror image of its original shape. This is useful for converting left-facing objects into right-facing objects and vise-versa. For example, you can use the flip tool to change corner pieces like this:

The original right-facing corner pipe is flipped horizontally so that it becomes a left-facing corner pipe.

NOTE: The Flip feature is only available for Pipes, Lines, and Shapes.

To flip an object:

  1. Display the relevant Mimic in Design mode.
  2. Right-click on the Mimic object that you want to flip.
    A context sensitive menu is displayed.
  3. Select the Flip option, then choose from:
  • Horizontal—Flips the object from left to right or vise-versa.
  • Vertical—Flips the object from top to bottom or vise-versa.

NOTE: You can also access the Flip options via the Arrange menu.


Mimics Guide - Rotating a Mimic Object (Designing a Mimic)

Rotating a Mimic Object

You can use the Rotate feature to rotate a Mimic object so that it is displayed at a different angle.

The pipe on the right is a copy of the pipe on the left. The copy has been rotated by 45°.

NOTE: The Rotate feature is only available for Pipes, Lines, and Shapes.

To rotate a Mimic object:

  1. Display the relevant Mimic in Design mode.
  2. Right-click on the Mimic object that you want to rotate.
    A context sensitive menu is displayed.
  3. Select the Rotate option, then choose from:
  • Free—The object is selected for rotation. You control the amount of rotation by holding down the left-hand mouse button and using the mouse to move the cursor. Release the left-hand mouse button when the Mimic object is shown at the required angle.
  • 180—Rotates the object by 180°.
  • +90—Rotates the object 90° clockwise.
  • +60—Rotates the object 60° clockwise.
  • +45—Rotates the object 45° clockwise.
  • +30—Rotates the object 30° clockwise.
  • -30—Rotates the object 30° anti-clockwise.
  • -45—Rotates the object 45° anti-clockwise.
  • -60—Rotates the object 60° anti-clockwise.
  • -90—Rotates the object 90° anti-clockwise.

NOTE: You can also access the Rotate options via the Arrange menu.

For information on setting up a rotation animation, see Rotation Animations.


Mimics Guide - Changing the Shape of an Object (Designing a Mimic)

Changing the Shape of an Object

You can use the Edit Points feature to reshape a line, shape, or pipe on a Mimic. This is useful when you need to create a curved edge.

Each shape (including lines) consists of an uninterrupted line that forms a ' loop'. For example, a rectangle forms a ' loop' by joining 4 drawing points (corners) and a line forms a ' loop' by joining two points twice. The 'loop' is referred to as a figure.

A rectangle forms a figure by connecting 4 drawing points
A line forms a figure by connecting one drawing point (the start of the line) to a target point (the end of the line), and then connecting the target point to the point at the start of the line (the second line is open so is not drawn).

By using the Edit Points feature and then making use of the segment tools, you can move part of a figure. This allows you to manipulate shapes so that they can form irregular shapes or can have curved lines. For example, you can curve two ends of a rectangle so that it looks like a cylinder.

To change the shape of a line, shape, or pipe:

  1. Display the relevant Mimic in Design mode.
  2. Right-click on the Mimic object that you want to alter.
    A context sensitive menu is displayed.
  3. Select the Edit Points option.
    The handles for the object are shown and the segment options become available.
    Handles

If you want to reshape the object but have no need for curved lines, proceed to step 4.

If you want to reshape the object so that it has one or more curved lines, proceed to step 6.

If you want to reshape the object so that a segment is opened, closed, or removed, proceed to step 10.

  4. Select a handle and drag it to a new position.
  5. Repeat step 4 for the other handles until the Mimic object has the required shape.

NOTE: If you need to divide a line, right-click on it and select the Split Segment option. An additional handle is added to the line.

If you need to open, close, or delete any of the segments, proceed to step 9, otherwise proceed to step 12.

  6. Right-click on the line that you want to curve. You can select any line between 2 handles. This means that you can select parts of a line if the line has several handles.
    A context sensitive menu is displayed.
  7. Select one of the following options:
  • Curve Segment (1 Handle)—Adds 1 handle to the line. When you drag the handle, the line will curve with the handle being the center of the arc.
    Drag the additional handle to create a curve. The additional handle is the center of the arc.

  • Curve Segment (2 Handles)—Adds 2 handles to the line. The line can have 2 curves, one for each handle. When you drag either handle, the line curves with the selected handle being the center of one arc.
    There can be 2 curves—drag either handle to create a curve.

  8. Drag the handle(s) to create the required curves. If you need to open, close, or delete any of the segments proceed to step 9, otherwise proceed to step 12.
  9. Select the segment that you want to open, close, or remove. The handles for the segment become black when it is selected.
  10. Right-click on the segment to display a context sensitive menu.
  11. Choose the appropriate option:
  • Open Segment—Use this option to open the segment so that there is no line between its handles.
    The segment has its line removed.

  • Close Segment—Use this option to restore a line to an open segment.
  • Delete Segment—Use this option to remove a segment. This will cause the object to be reshaped as the handles either side of the deleted segment will connect to complete the 'loop' for the line, pipe, or shape.
    The segment is deleted and the handles either side of the segment connect to complete the 'loop' for the line, pipe, or shape.

NOTE: You can straighten any curved segment by right-clicking on the segment and selecting the Straighten Segment option from the context sensitive menu.

  12. Right-click on the object and select the Select Object(s) option to return to the object selection mode (i.e. turn Edit Points off).

NOTE: The segment options are also available from the Arrange menu.


Mimics Guide - Making a Group of Mimic Objects (Designing a Mimic)

Making a Group of Mimic Objects

You can group Mimic objects together. This is useful when you have several Mimic objects that form a larger object, for example, you could have several separate Mimic objects that represent the various parts of a pump. By grouping the objects, you can move and resize them as a single object rather than as individual objects.

To group Mimic objects:

  1. Select an object that is to be in the group.
  2. Press the Shift key and keep it held down.
  3. Select the other Mimic objects that are to be in the group in turn, keeping the Shift key pressed down.
  4. When you have selected the Mimic objects, press the right-hand mouse button to display a context sensitive menu.
  5. Select the Make Group option to group the Mimic objects.

Alternatively, you can draw a selection rectangle over the Mimic objects that are to be in the group (first, check that there are no drawing tools selected, and then draw the selection rectangle by pressing the left-hand mouse button down and dragging the cursor over the Mimic objects). When you have drawn the selection rectangle, the Mimic objects in the rectangle are selected. Press the right-hand mouse button, then select the Make Group option from the context sensitive menu.

If you want to take Mimic objects out of a group, right-click on the group and select the Break Group option. This cancels the last group formation.


Mimics Guide - Creating a New Shape by Combining Mimic Objects (Designing a Mimic)

Creating a New Shape by Combining Mimic Objects

You can create a new shape on a Mimic by combining the polylines of multiple Mimic objects. For example, you can create a new shape by combining the polylines of a rectangle and a circle. The new shape can then be edited in the same way as any other Mimic object.

There are 2 methods that control how a combined polygon is filled:

  • Even-Odd—The operating system determines whether each pixel of the shape should be 'filled' or 'open'. To do this, it counts the number of lines between each pixel and the edge of the Mimic. If the number is even, the pixel is included in the shape and is 'filled'; if the number is odd, the pixel is excluded from the shape and is 'open'.

Example:

Two rectangles are set to overlap.

The Fill Mode is set to Even-Odd and the rectangles are combined by using the Combine Polylines action. The rectangles are combined to create the following shape:

The space where the rectangles overlapped is 'open' (not filled). To determine this, the operating system counted the number of lines crossed when drawing a 'ray' from each pixel to the edge of the Mimic. As the 'rays' for each pixel in the overlapping area cross an even number of lines, the area is 'open'.

The operating system determines how many lines are crossed when drawing a 'ray' from each pixel to the edge of the Mimic. In this case, the 'ray' crosses 2 lines, so the number of lines crossed is even. The pixel is 'open' and is excluded from the shape.
Crosses first line
Crosses second line

The areas that do not overlap are included in the shape. The operating system determines this in the same way, by counting the number of lines crossed when drawing a 'ray' from each pixel to the edge of the Mimic. As the number is odd, the pixels are included in the shape.

The operating system determines how many lines are crossed when drawing a 'ray' from each pixel to the edge of the Mimic. In this case, the 'ray' crosses 1 line, so the number of lines crossed is odd. The pixel is 'open' and is excluded from the shape.
Crosses 1 line before reaching the edge of the Mimic

  • Non-Zero—The operating system determines whether each pixel of the shape should be 'filled' or 'open'. To do this, it draws a 'ray' from each pixel to the edge of the Mimic. Each time the 'ray' crosses the line of a shape, it adds or subtracts one from a total:
  • If the 'ray' crosses the line of a shape that was drawn in a clockwise direction, 1 is added to the total.
  • If the 'ray' crosses the line of a shape that was drawn in an anti-clockwise direction, 1 is deducted from the total.

If the final total is zero, the pixel is not included in the shape. If the final total is any number other than zero, the pixel is included in the shape.

Example:

Two rectangles are set to overlap.

The Fill Mode is set to Non-Zero and the rectangles are combined by using the Combine Polylines action. The rectangles are combined to create the following shape:

The space where the rectangles overlapped is 'filled'. To determine this, the operating system counted the number of lines crossed when drawing a 'ray' from each pixel to the edge of the Mimic. Each time the 'ray' crossed a line that was drawn in a clockwise direction, the operating system added 1 to the total. Each time the 'ray' crossed a line that was drawn in an anti-clockwise direction, the operating system deducted 1 from the total.

As the total number for the pixels in the overlapping area was not zero, the pixels are included in the shape.

From this pixel, the 'ray' crosses 2 lines that were drawn in a clockwise direction. This means the total is 2, and so not zero. As the total for the pixel is not zero, it is included as part of the shape.
The angle brackets indicate the direction in which the shapes were drawn.

NOTE: Shapes in ClearSCADA are usually drawn in a clockwise direction. However, you can use the Line tool and the Polygon tool to draw shapes in an anti-clockwise direction if required.

The Fill Mode is mainly used when combining shapes and is also used internally when importing Third Party graphics such as SVG files. However, the same methodology is used when determining the fill for a complex polyline that you have drawn manually—the areas between the lines will be 'filled' or left 'open' according to the Fill Mode setting and the number of lines that are crossed by the 'ray'.

To define the fill mode and combine multiple objects on a Mimic:

  1. Display the relevant Mimic in Design mode (see Displaying a Mimic).
  2. Select the objects that you want to combine by either:
  • Holding down a Ctrl key and left-clicking on each shape

Or:

  • Positioning the cursor on an empty area of the Mimic, then with the left-hand mouse button pressed down, drag the cursor so that it draws a selection box over the objects you want to select. Release the mouse button to select the objects in the selection box.
    Multiple shapes selected simultaneously

  3. Right-click to display a context sensitive menu, then select the Combine Polylines option.
    The shapes are combined into a single shape. By default, the shape uses the Even-Odd Fill Mode.
  4. Right-click to display a context sensitive menu, then select the Properties option to display the Multiple Selection Properties window.
  5. On the General tab of the Multiple Selection Properties window, use the Fill Mode combo box to select Even-Odd or Non-Zero as required.
  6. Close the Multiple Selection Properties window.
  7. Select the objects to be included in the shape again (see step 2).

NOTE: When you combine shapes, the resulting shape will use the Fill properties of the uppermost object in the selection (the object that is 'top' in the z order i.e. is layered above the other objects or was created before the other objects).


Mimics Guide - Using the Mimic Ruler (Designing a Mimic)

Using the Mimic Ruler

You can use the Mimic ruler when designing Mimics. The ruler shows horizontal and vertical measurements and makes it easier for you to size and position Mimic objects.

Use the Mimic ruler when sizing and positioning Mimic objects.

To toggle the Mimic ruler on and off:

Either:

  • Select the Ruler button on the Alignment Bar (toolbar)

Or:

  • Select the View menu, then select the Display Ruler option.


Mimics Guide - Keyboard Shortcuts (Designing a Mimic)

Keyboard Shortcuts

You can use the following keyboard shortcuts when designing a Mimic:

  • Alt—Hold an Alt key when moving, resizing, or adding an object to disable the snap to grid feature. (Design mode).
  • Alt+Double-click—Select the next object in order.
  • Shift:
  • Hold a Shift key when adding an object to force a 1:1 size ratio.
  • Hold a Shift key when adding a straight line to force an angle of 15°.
  • Hold a Shift key when resizing to maintain the current aspect ratio.
  • Ctrl—Hold a Ctrl key when you need to select multiple objects. Keep the Ctrl key pressed down as you select the objects in turn.
  • Ctrl+G—Toggle the grid on and off.
  • Ctrl+M—Make Group.
  • Ctrl+B—Break Group.
  • Ctrl+R—Toggle Run/Design Mode.
  • Ctrl+Up—Bring Forward.
  • Ctrl+Down—Send Backward.
  • Ctrl+Shift+Up—Bring to Front.
  • Ctrl+Shift+Down—Send to Back.
  • Ctrl+L—Next Layer.
  • Ctrl+Shift+L—Previous Layer.

NOTE: The standard Windows keyboard shortcuts such as Ctrl+C for copy are also available.


Mimics Guide - Configuring the Mimic Properties

Configuring the Mimic Properties

Before you begin adding and configuring individual Mimic objects, you should make use of the settings on the Options window and also those on the Mimic Properties window. These two windows allow you to define default settings that apply to either:

  • Every Mimic that is displayed on your client

Or:

  • Every New Mimic that is configured on your client

Or:

  • The Mimic on which you are working.

By defining appropriate default settings, you can significantly reduce the amount of time and effort required to configure your Mimics, especially if you are configuring multiple Mimics that need to have objects with similar or identical properties. For example, let us assume that you are going to create and configure 4 Mimics, and each of these Mimics needs to have text boxes that use the same font styles and colors etc. Rather than configure each Mimic’s text boxes individually, you can define the text box settings in the default settings. Then every text box that you add will have the required settings already in place (as the new text boxes will use the default settings automatically).

In the following sections, we explain how to use the Options window and Mimic Properties window to apply settings that can affect one or more Mimics:

  • Using the Options Window to Define Settings that apply to All Mimics
  • Define whether Flash Effects are Active in all Windows
  • Define the Update Rates for a Mimic
  • Enable or Disable Anti-Aliasing on your ClearSCADA Client
  • Enable or Disable WYSIWYG Printing for Mimics
  • Enable or Disable Custom Menus for a Mimic
  • Defining the Default Mimic Properties for New Mimics
  • Defining the Default Mimic Properties for a Specific Mimic
  • Mimic Properties Window
  • Define the Background Color for a Mimic
  • Add, Edit, Reorder and Remove Layers on a Mimic
  • Add, Edit, and Remove Views on a Mimic
  • Smooth Mimic Graphics with the Anti-Aliasing Feature
  • Set the Size and Orientation of a Mimic
  • Define the Magnification Settings for a Mimic
  • Define the Grid Settings for a Mimic
  • Define the Script Settings for a Mimic
  • Define the Polyline Line Settings for a Mimic
  • Define the Polyline Fill Settings for a Mimic
  • Define the Text Pen Settings for a Mimic
  • Define the Text Fill Settings for a Mimic
  • Define the Text Font Settings for a Mimic
  • Define the Button Pen Settings for a Mimic
  • Define the Button Fill Settings for a Mimic
  • Define the Button Font Settings for a Mimic
  • Define the Pipe Fill Settings for a Mimic.


Mimics Guide - Using the Options Window to Define Settings that apply to All Mimics (Configuring the Mimic Properties)

Using the Options Window to Define Settings that apply to All Mimics

You can use the Options window’s Mimics tab to define settings that apply to:

  • New Mimics when edited for the first time on your client PC
  • Existing Mimics that you display on your client PC (the settings may not apply when the same Mimics are displayed on other client PCs).

To display the Options window, select the Tools menu, then choose the Options option. When the Options window is displayed, select the Mimics tab.

The settings that you apply for Mimics via the Options window are specific to your client PC, and they allow you to define:

  • The default settings that are in place whenever you first edit a new Mimic on your client. By defining the default settings, you can reduce the amount of time and effort required when configuring Mimics that have common features, such as the same orientation, size, lettering styles etc.

To define the default settings for new Mimics, you need to use the Mimic Properties window. You can display it by selecting the Edit button in the General section on the Option window’s Mimics tab.

For more information on the default settings for new Mimics, see Mimic Properties Window.

  • Whether Mimics displayed on your client PC only flash when they are the active window (i.e. are the currently selected display). For more information on the Only Flash If Active setting, see Define whether Flash Effects are Active in all Windows.
  • Whether Mimics displayed on your client PC use anti-aliasing to smooth the edges of Mimic objects (especially noticeable on curved lines and curved shapes). For more information on the Enable Anti-Aliasing setting, see Smooth Mimic Graphics with the Anti-Aliasing Feature.
  • Whether Mimics use WYSIWYG (What You See Is What You Get) printing. For more information on the WYSIWYG Printing setting, see Enable or Disable WYSIWYG Printing for Mimics
  • How frequently Mimics displayed on your client PC are updated. For more information on the Update Rates settings, see Define the Update Rates for a Mimic.
  • The appearance of context-sensitive menus for Mimics on your client PC. You can choose to use Custom Menus or leave the default Windows-style context sensitive menus in place (see Enable or Disable Custom Menus for a Mimic).

The settings you apply via the Options window’s Mimics tab apply to those Mimics that are displayed or created on your client PC only. When the same Mimics are displayed on other client PCs, different settings may be applied (depending on the Options settings on the other clients).

You should also be aware that when you select the Edit button on the Mimics tab, the Mimic Properties window that is displayed is not the same as the Mimic Properties window that is available for individual Mimics. Although the Mimic Properties windows contain the same settings, there is a difference:

  • The Mimic Properties window displayed via the Options window has settings that apply to every new Mimic on your client PC
  • The Mimic Properties window that is displayed when you select the Properties option for a Mimic has settings that only apply to that specific Mimic.


Mimics Guide - Define whether Flash Effects are Active in all Windows (Configuring the Mimic Properties)

Define whether Flash Effects are Active in all Windows

Flashing effects can be useful to attract users’ interest, but if they are used too frequently, they become less effective. This is especially true when multiple Mimics (with flashing features) are displayed simultaneously, as:

  • A high number of flashing effects can mean that they no longer serve their purpose - the flashing objects no longer stand out and so may not attract users’ attention.
  • Users may become distracted or irritated by a high number of flashing effects. An excessive number of Mimics with flashing objects can also affect system performance.

To help you use flashing effects appropriately, ClearSCADA includes a Only Flash If Active setting. When enabled, this sets flashing effects so that they are only active if they are in the currently selected window. So if a user has 4 Mimics on display and they have flashing features, the flashing effects will only be visible on the currently selected Mimic (the 'active' Mimic).

To enable or disable the Only Flash If Active setting on your client PC, you need to use the Options window:

  1. Select the Tools menu, then select the Options option to display the Options window.

NOTE: You can only display the Options window if your user account has the Configure Options permission.

  2. Select the Mimics tab.
  3. Define the flash setting:
  • Select the Only Flash if Active check box to restrict flash effects so that they are only applied on the currently selected window.
  • Clear the Only Flash if Active check box to allow the flash effects to be applied on every Mimic on display, irrespective of the currently selected window.
  4. Select the OK button to confirm your changes and close the Options window.

Further Information

FlashAlpha

FlashColour

FlashMode

FlashOffset.


Mimics Guide - Define the Update Rates for a Mimic (Configuring the Mimic Properties)

Define the Update Rates for a Mimic

If you display a Mimic that contains dynamic data, your client has to request updates for the dynamic data from the server. The amount of time between requests varies according to:

  • The configuration of the expression for each dynamic Mimic object. The expression is configured to be associated with the Normal update group or the Fast update group. If it is associated with the Fast update group, your client will request updates for the expression more frequently than it will request updates those expressions associated with the Normal update group.
  • The configuration of the Update Rates on the Options window on your client. The Fast setting defines how regularly the client requests updates for those expressions that are associated with the Fast update group. Similarly, the Normal setting defines how regularly the client requests updates for those expressions that are associated with the Normal update group.

Example:

Let’s say that you have a Mimic that contains some expressions that have fast updates enabled and some expressions that use normal updates. The Fast setting for your client PC is set to 0.5 seconds and the Normal setting is 1.0 seconds.

When you first open the Mimic, your client informs the server that it has some tags that should be updated at a maximum of once every half second, and some tags that should be updated at a maximum of once every second. The server then monitors the tags and updates them but only if the source of the tag’s value has changed since the last update.

The data source for one of the ‘fast’ expressions is changing value every quarter of a second. The server monitors this and updates the expression as fast as it can - every 0.5 seconds. The server cannot update the tag every time the source value changes as the source value is changing every 0.25 seconds and the fastest that the server can update the Mimic is every 0.5 seconds.

The data source for one of the ‘normal’ expressions is changing value every hour. This means that on the Mimic, the tag for the expression will also change once per hour even though the Normal update setting is 1 second. This is because the server only updates the Mimic when the source values change, and the update rates define the maximum speeds at which the Mimic can be updated.

You can use the Options window to define the update rate for the Fast and Normal update groups. The settings you define will apply to the Mimics that are displayed on your client PC.

To define the Update Rates:

  1. Select the Tools menu then select the Options option to display the Options window.

NOTE: You can only display the Options window if your user account has the Configure Options permission.

  2. Select the Mimics tab.
  3. Use the Update Rates settings to define the maximum rates at which the server can update the values on a Mimic shown on your client PC:
  • Use the Fast spin box to define the maximum rate at which the server can update those expressions that have Fast Updates enabled. The default setting is 0.5 seconds and the Fast update rate should be around twice as frequent as the Normal update setting.
  • Use the Normal spin box to define the maximum rate at which the server can update those expressions that have Fast Updates disabled. The Normal update group should be updated at a slower rate than the Fast update group, usually around half as often. By default, the Normal update group is updated every second.

Please be aware that changing the update rates may affect the performance of your system.

  4. Select the OK button to apply the changes and close the Options window.

NOTE: The Fast and Normal update rates that you define will only apply to the dynamic data on Mimics that are displayed on your client PC. When the same Mimics are displayed on other clients, they will use the update rates that are defined on those clients’ Options windows.


Mimics Guide - Enable or Disable Anti-Aliasing on your ClearSCADA Client (Configuring the Mimic Properties)

Enable or Disable Anti-Aliasing on your ClearSCADA Client

You can use the Options window to Enable Anti-Aliasing for the Mimics that are displayed on your client (you can also disable Anti-Aliasing). The Anti-Aliasing feature improves the appearance of curved lines and edges on your Mimics by smoothing the lines, but can affect your computer’s performance.

For more information, see Smooth Mimic Graphics with the Anti-Aliasing Feature.


Mimics Guide - Enable or Disable WYSIWYG Printing for Mimics (Configuring the Mimic Properties)

Enable or Disable WYSIWYG Printing for Mimics

You can use the WYSIWYG Printing setting on the Options window to control whether print-outs of Mimics include embedded Lists and embedded Alarms Lists. While you may have a use for print-outs that show a ‘snapshot’ of an embedded List or embedded Alarms List, you need to be aware that enabling WYSIWYG Printing will affect the resolution of Mimic print-outs.

By default, the WYSIWYG Printing (What You See Is What You Get) setting is disabled. This means that if you print a Mimic that contains an embedded List, the embedded List will not be included on the print-out; a blank space will appear instead. The reason for this is that an embedded list often contains more entries than can be shown on screen, and so you need to use the list’s scroll bars to access the entries. Obviously, you cannot scroll a print-out, and so the embedded list is not shown. By excluding embedded lists from print-outs, ClearSCADA can print higher resolution versions of the Mimic.

However, you may decide that you want your print-outs to include embedded Lists, even if they only show those entries that are visible on screen at the time of printing (a ‘snapshot’). To do this, you need to enable (select) the WYSIWYG Printing setting.

With the WYSIWYG Printing setting enabled, Mimic print-outs will include a ‘snapshot’ of embedded Lists or embedded Alarms Lists (where applicable). But you need to be aware that the WYSIWYG Printing setting applies to every Mimic. So if you enable WYSIWYG Printing, it means that a lower resolution will also be used for print-outs of Mimics that contain no embedded Lists or Alarms Lists.

To enable or disable the WYSIWYG Printing setting:

  1. Select the Tools menu then select the Options option to display the Options window.

NOTE: You can only display the Options window if your user account has the Configure Options permission.

  2. Select the Mimics tab.
  3. Use the WYSIWYG Printing check box to enable or disable the setting:
  • Select the WYSIWYG Printing check box to enable WYSIWYG Printing. When you print a Mimic, a lower resolution will be used. If the Mimic contains embedded Lists or embedded Alarms Lists, a ‘snapshot’ of those embedded Lists will be included in the print-out. As the print-out is in a lower resolution, the edges will appear less sharp, particularly on lettering and shapes.
  • Clear the WYSIWYG Printing check box to disable WYSIWYG Printing. When you print a Mimic, a higher resolution is used and any embedded Lists or Alarms Lists are excluded from the print-out. This means that the edges of shapes and text will appear sharp, but there will be empty spaces in place of any embedded Lists/embedded Alarms Lists.
  4. Select the OK button to apply the changes and close the Options window.


Mimics Guide - Enable or Disable Custom Menus for a Mimic (Configuring the Mimic Properties)

Enable or Disable Custom Menus for a Mimic

ClearSCADA allows you to create a customized appearance for:

  • Custom menus (that you create on Mimics)
  • ClearSCADA Object Menu pick actions (pick actions that you configure to associate a Mimic object with the context sensitive menu of a database item).

The custom design that you define is used instead of the standard, Windows-style appearance.

Custom pick action menu

Typically, the Custom Menus feature is used in organizations that prefer to apply custom styles that match their corporate branding wherever possible.

To create your own custom menu design, you need to use the Custom Menus settings on the Options window. The design you implement in the Custom Menus settings will apply to the custom menus and custom pick action menus of the Mimics displayed on your client PC. The settings will not apply to the Mimics when they are displayed on other clients (unless the other clients have the same Custom Menus settings as your client).

To define the Custom Menus settings:

  1. Select the Tools menu, then select the Options option to display the Options window.
  2. Select the Mimics tab.
  3. Use the Enable Custom Menus check box to define whether the custom menus use the alternate style of menus:
  • Select the Enable Custom Menus option to apply the different menu style to custom menus. The alternate menu style will only be applied to custom menus on Mimics that are displayed on your client. When the same Mimics are displayed on other clients, the Custom Menu settings of the other clients will apply.
  • Clear the Enable Custom Menus check box to set those Mimics that contain custom menus to use standard Windows-style menus when displayed on your client PC.
  4. Use the Enable Custom Pick Menus check box to define whether ClearSCADA Object Menus on Mimics use the alternate style of menus:
  • Select the Enable Custom Pick Menus option to apply the different menu style to ClearSCADA Object Menus on Mimics (ClearSCADA Object Menus that are associated with the pick action for a Mimic object). The alternate menu style will only be applied to ClearSCADA Object Menus on Mimics that are displayed on your client. When the same Mimics are displayed on other clients, the Custom Menu settings of the other clients will apply.
  • Clear the Enable Custom Menus check box to set the Mimics’ ClearSCADA Object Menus use standard Windows-style menus when displayed on your client PC.
  5. Use the Font combo box to select the style of lettering that will be used on the custom menus and ClearSCADA Object Menus.
  6. Use the Height spin-box to define the size of the lettering on the custom menus and ClearSCADA Object Menus. The measurements are in points.
  7. Use the Bold check box to define whether the text on the custom menus and custom ClearSCADA Object Menus is emboldened. Select the check box to embolden the text or clear it to use standard text.
  8. Use the Italic check box to define whether the text on the custom menus and ClearSCADA Object Menus is italicized. Select the check box to italicize the text or clear it to use standard text.
  9. Use the Text color button to define the color of the text on the custom menus and ClearSCADA Object Menus. You can choose a color from the palette or create a custom color. For more information, see Using the Color Window.
  10. Use the Selected Text color button to define the color of selected text on the custom menus and ClearSCADA Object Menus. This is the color that the text will become when an option or menu is selected. For more information, see Using the Color Window.
  11. Use the Menu color button to define the color of the menu background on the custom menus and ClearSCADA Object Menus. This is the color that is shown behind the text on a custom menu or custom pick action menu. For more information, see Using the Color Window.
  12. Use the Selected Menu color button to define the color of the menu background on the custom menus and ClearSCADA Object Menus. This is the color that is shown behind the text on a custom menu or custom pick action menu when the menu or option is selected. For more information, see Using the Color Window.

Further Information

Associating Mimic Objects with Pick Actions

Custom Pick Action Menus.


Mimics Guide - Defining the Default Mimic Properties for New Mimics (Configuring the Mimic Properties)

Defining the Default Mimic Properties for New Mimics

You can use the Mimic Properties window to define the default settings for new Mimics (Mimics that have yet to be configured). The settings you define will apply to every new Mimic that you configure on your client PC. New Mimics that are configured on other client PCs may use different default settings, and if you create a new Mimic but it is edited for the first time on another client, the default settings of the other client are applied.

To define the default settings for new Mimics, you need to display the Mimic Properties window via the Options window:

  1. Select the Tools menu, then select the Options option to display the Options window.
  2. Select the Mimics tab, then select the Edit button in the General section.
    The Mimic Properties window is displayed.

NOTE: If you want to define the default settings for every new Mimic, you have to display the Mimic Properties window by using the Edit button on the Mimics tab of the Options window. If you display the Mimic Properties window by selecting the Properties option for an individual Mimic, the settings on the Mimic Properties window only apply to that specific Mimic. Some Mimic options can only be configured on a per-Mimic basis, including the Layers, Views, and Script settings.

  3. Use the Mimic Properties window to define the settings that will apply to every Mimic that is configured for the first time on your client PC. For more information on the settings on the Mimic Properties window, see Mimic Properties Window.

NOTE: You can only define the default settings if your user account has the Configure Options permission. This permission is usually allocated to high level users such as engineers.


Mimics Guide - Defining the Default Mimic Properties for a Specific Mimic (Configuring the Mimic Properties)

Defining the Default Mimic Properties for a Specific Mimic

You can use the Mimic Properties window to define the default settings for a Mimic, including the default styles and colors of Mimic objects. By defining the default settings for a Mimic, you can reduce the amount of time and effort required to configure a Mimic. For example, let’s assume that your Mimic needs to contain 6 text boxes that have the same style, color and size of font. Rather than configure each text box separately, you can define the settings you require as the default settings for text boxes. Then, when you add a text box, it will already have the default settings in place. So you can simply add the 6 text boxed and define the text for each box—the color, style and font defined in the Mimic’s default properties will automatically be in place (and you can still reconfigure the settings for each text box individually if required).

To define the default settings for a specific Mimic, you need to display the Mimic Properties window by selecting the Mimic’s Properties pick action:

  1. Display the Mimic for which you want to define the Mimic Properties. You need to display the Mimic in Design Mode (see Displaying a Mimic).
  2. Right-click on the background of the Mimic to display a context-sensitive menu.
  3. Select the Properties option to display the Mimic Properties window.

As an alternative to steps 2 and 3, you can double-click on the background of the Mimic to display the Mimic Properties window (but the Mimic has to be in Design Mode).

NOTE: If you want to define the default settings for a selected Mimic, you have to display the Mimic Properties window by using the Properties action on the background’s context sensitive menu. If you display the Mimic Properties window by selecting the Edit button on the Options window’s Mimics tab, the settings on the Mimic Properties window will apply to every new Mimic on your client.

  4. Use the Mimic Properties window to define the settings that will only apply to the Mimic that you are currently configuring. For more information on the settings on the Mimic Properties window, see Mimic Properties Window.


Mimics Guide - Mimic Properties Window (Configuring the Mimic Properties)

Mimic Properties Window

You can use the Mimic Properties window to define the default settings for:

  • Any selected Mimic. The default settings you put in place for the Mimic will be applied whenever the Mimic is displayed, irrespective of which client PC is used.
  • New Mimics that are being edited for the very first time. The default settings for new Mimics are client-specific, so they only apply if your client PC is being used to configure a Mimic that has not been configured before.

The method you use to access the Mimic Properties window determines whether the changes you make apply to all Mimics displayed on your client or just those of a specific Mimic:

  • If you display the Mimic Properties window by selecting the Edit button on the Mimics tab of the Options window, the settings will apply to each Mimic that you display on your client PC. The settings are client-specific and so will not apply when the same Mimics are displayed on other client PCs. For more information, see Defining the Default Mimic Properties for New Mimics.
  • If you display the Mimic Properties window by double-clicking on the background of a Mimic or right-clicking on the background and selecting Properties from the context-sensitive menu, the settings will apply to the selected Mimic only. The settings will be applied every time the Mimic is displayed, irrespective of the PC on which it is being displayed. For more information, see Defining the Default Mimic Properties for a Specific Mimic.

The Mimic Properties window consists of several tabs, each containing a variety of settings. You can use the tabs as follows:

  • Mimic—Use the settings on this tab to:
  • Define the Background Color for a Mimic
  • Add, Edit, Reorder and Remove Layers on a Mimic
  • Add, Edit, and Remove Views on a Mimic
  • Smooth Mimic Graphics with the Anti-Aliasing Feature
  • Set the Size and Orientation of a Mimic
  • Define the Magnification Settings for a Mimic
  • Define the Grid Settings for a Mimic
  • Define the Script Settings for a Mimic.
  • Polyline Line—Use the settings on this tab to Define the Polyline Line Settings for a Mimic.
  • Polyline Fill—Use the settings on this tab to Define the Polyline Fill Settings for a Mimic
  • Text Pen—Use the settings on this tab to Define the Text Pen Settings for a Mimic
  • Text Fill—Use the settings on this tab to Define the Text Fill Settings for a Mimic
  • Text Font—Use the settings on this tab to Define the Text Font Settings for a Mimic
  • Button Pen—Use the settings on this tab to Define the Button Pen Settings for a Mimic
  • Button Fill—Use the settings on this tab to Define the Button Fill Settings for a Mimic
  • Button Font—Use the settings on this tab to Define the Button Font Settings for a Mimic
  • Pipe Fill—Use the settings on this tab to Define the Pipe Fill Settings for a Mimic.


Mimics Guide - Define the Background Color for a Mimic (Configuring the Mimic Properties)

Define the Background Color for a Mimic

You can use the Background setting on the Mimic Properties window to define the default background color for a Mimic. Depending on the method you use to display the Mimic Properties window, the color you choose will be the background color for a specific Mimic or for new Mimics being configured on your client PC.

To choose the required background color, select the Background color button to display a color palette.

You can choose a color from the palette or you can use the ... option to create a custom color (see Using the Color Window).

Further Information

Defining the Default Mimic Properties for New Mimics

Defining the Default Mimic Properties for a Specific Mimic.


Mimics Guide - Add, Edit, Reorder and Remove Layers on a Mimic (Configuring the Mimic Properties)

Add, Edit, Reorder and Remove Layers on a Mimic

You can use the Layers button on the Mimic Properties window to access the Layers window for a Mimic. The Layers button is only available when you display the Mimic Properties window by double-clicking on the background of a Mimic or right-clicking on the background and selecting the Properties option from the context sensitive menu.

You can use the Layers window to add, remove, and organize the layers on the current Mimic. For more information on the Layers window, see Layers.

Further Information

Defining the Default Mimic Properties for a Specific Mimic.


Mimics Guide - Add, Edit, and Remove Views on a Mimic (Configuring the Mimic Properties)

Add, Edit, and Remove Views on a Mimic

You can use the Views button on the Mimic Properties window to access the Views window for a Mimic. The Views button is only available when you display the Mimic Properties window by double-clicking on the background of a Mimic or right-clicking on the background and selecting the Properties option from the context sensitive menu. For more information on the Views window, see Views.

Further Information

Defining the Default Mimic Properties for a Specific Mimic.


Mimics Guide - Smooth Mimic Graphics with the Anti-Aliasing Feature (Configuring the Mimic Properties)

Smooth Mimic Graphics with the Anti-Aliasing Feature

ClearSCADA includes an Anti-Aliasing feature which allows the edges on certain Mimic objects to be 'smoothed' so that lines appear less jagged. The 'smoothing' effect of the Anti-Aliasing feature is especially noticeable on curved edges, such as the edges of circles and ellipses.

The Anti-Aliasing feature smooths out the edges of the Mimic objects.
If the Anti-Aliasing feature disabled, the edges of the Mimic objects can appear jagged.

While the Anti-Aliasing feature does improve the appearance of curved lines on Mimics, it is performed by the client PC and so places a demand on the client PC’s processors. For this reason, we recommend that you have the Anti-Aliasing feature disabled on slow PCs.

In this section, we explain how to:

  • Enable or Disable Anti-Aliasing for your Client PC
  • Enable or Disable Anti-Aliasing for New Mimics on your Client PC
  • Enable or Disable Anti-Aliasing for a Specific Mimic.

Enable or Disable Anti-Aliasing for your Client PC

You can use the Enable Anti-Aliasing check box (on the Mimics tab of the Options window) to define whether your client PC is able to use the Anti-Aliasing feature on Mimics. If the Enable Anti-Aliasing check box is selected, your client PC can support Anti-Aliasing and so any Mimics that have Anti-Aliasing enabled will have objects with ‘smoothed’ edges. If the Enable Anti-Aliasing check box is clear, your client PC will not be able to use Anti-Aliasing, even if you use it to display Mimics that have Anti-Aliasing enabled.

Anti-Aliasing is performed by your client PC and requires an adequately powered graphics card. If your client PC’s graphics card is insufficient, the anti-aliasing feature can cause slower performance. For this reason, we recommend that the Enable Anti-Aliasing feature is only enabled on client PCs that have adequately powered graphics cards. If your Mimics refresh at a very slow rate or are very complex with a high number of objects and curved shapes and lines, we recommend that you disable the anti-aliasing feature.

If you wish to use Anti-Aliasing but are experiencing slower performance, you should consider upgrading the graphics card in your PC (or upgrade your laptop) and the processors in your PC. Computers using minimum or low specification processors may exhibit slow Mimic refresh rates even when an adequately powered graphics card is in use. Typically, you would only experience slow Mimic refresh rates on lower specification, budget PCs.

To enable or disable Anti-Aliasing for every Mimic that is to be displayed on your client PC:

  1. Select the Tools menu, then the Options option to display the Options window.
  2. Select the Mimics tab.
  3. Either:
  • Select the Enable Anti-Aliasing check box to activate the Anti-Aliasing feature on your client PC. Your client PC will now apply Anti-Aliasing to any Mimics that are configured to use Anti-Aliasing.

Or:

  • Clear the Enable Anti-Aliasing check box to disable the Anti-Aliasing feature on your client PC. Any Mimics that you display on your client PC will not use Anti-Aliasing, even if they are configured to have Anti-Aliasing enabled.
  4. Select the OK button to confirm your selection and close the Options window.

NOTE: You can only access the Options window if your user account has the Configure Options permission.

Further Information

Enable or Disable Anti-Aliasing for New Mimics on your Client PC

Enable or Disable Anti-Aliasing for a Specific Mimic.

Enable or Disable Anti-Aliasing for New Mimics on your Client PC

You can use the Mimic Properties window to enable or disable the Anti-Aliasing feature on new Mimics by default. To do this, you have to display the Mimic Properties window by accessing it via the Options window.

When you have displayed the Mimic Properties window by using the Edit button on the Options window, you can enable or disable the Anti-Alias feature for new Mimics that are displayed on your client PC. However, the Anti-Alias setting you put in place only applies to new Mimics that are displayed on your client PC and are being configured for the first time. New Mimics that are being displayed and configured on other client PCs are unaffected by your selections.

For the Anti-Aliasing feature to be applied to new Mimics, it has to be enabled for Mimics (see below) and also enabled on your client PC (see Enable or Disable Anti-Aliasing for your Client PC).

To enable or disable Anti-Aliasing for new Mimics, you have to access the Mimic Properties window via the Options window:

  1. Select the Tools menu, then select the Options option to display the Options window.

NOTE: To access the Options window, your user account has to have the Configure Options permission.

  2. Select the Mimics tab.
  3. On the Mimics tab, select the Edit button in the General section.
    The Mimic Properties window is displayed.
  4. On the Mimic tab of the Mimic Properties window, use the Anti-Alias check box to define whether Anti-Aliasing is enabled or disabled on any new Mimics displayed on your client PC:
  • Select the check box to enable the Anti-Aliasing feature by default on new Mimics (on your client PC only)
  • Clear the check box to disable the Anti-Aliasing feature by default on new Mimics (on your client PC only).
  5. Close the Mimic Properties window.
  6. Select the OK button to confirm your selection and close the Options window.

NOTE: If you access the Mimic Properties window by using the Properties option for a Mimic, the changes you make will only apply to that specific Mimic. You have to access the Mimic Properties window via the Options window to apply settings that are applied to each new Mimic by default.

Further Information

Enable or Disable Anti-Aliasing for your Client PC

Enable or Disable Anti-Aliasing for a Specific Mimic.

Enable or Disable Anti-Aliasing for a Specific Mimic

You can use the Mimic Properties window to enable or disable the Anti-Aliasing feature on an individual Mimic. To do this, you have to display the Mimic Properties window by accessing it via the Properties option for the background of the Mimic.

When you have displayed the Mimic Properties window by using the Properties option, you can enable or disable the Anti-Alias feature for the Mimic you are configuring. The setting that you put in place will only apply to the Mimic you are configuring and will apply every time the Mimic is displayed. However, if you enable the Anti-Aliasing feature for a Mimic, it will only be used if that Mimic is displayed on a client PC that is configured to use Anti-Aliasing (see Enable or Disable Anti-Aliasing for your Client PC). If the client PC is not configured to use Anti-Aliasing, the Anti-Aliasing feature will not be applied irrespective of the Mimic’s configuration settings.

To enable or disable Anti-Aliasing for an individual Mimic, you have to access the Mimic Properties window via the background of the Mimic:

  1. Display the Mimic in Design Mode (see Displaying a Mimic).
  2. On the background of the Mimic, right-click to display a context sensitive menu, then select the Properties option. Alternatively, you can double-click on the background of the Mimic.
    The Mimic Properties window is displayed. The settings on the Mimic Properties window only apply to the Mimic that you are currently configuring.
  3. On the Mimic tab of the Mimic Properties window, use the Anti-Alias check box to define whether Anti-Aliasing is enabled or disabled on the Mimic:
  • Select the check box to enable the Anti-Aliasing feature for the Mimic
  • Clear the check box to disable the Anti-Aliasing feature for the Mimic.
  4. Close the Mimic Properties window.

NOTE: If you access the Mimic Properties window by using the Edit option on the Options window, the changes you make will apply to new Mimics on your client PC, not just the Mimic you have on display.

Further Information

Enable or Disable Anti-Aliasing for your Client PC

Enable or Disable Anti-Aliasing for New Mimics on your Client PC.


Mimics Guide - Set the Size and Orientation of a Mimic (Configuring the Mimic Properties)

Set the Size and Orientation of a Mimic

You can use the Mimic Properties window to change the size and orientation of a Mimic so that it has different dimensions. For example, you can set a Mimic to be the same size as A5 paper and to have landscape orientation. This is useful when you need to print out Mimics on different paper sizes.

Depending on the method you use to display the Mimic Properties window, the size and orientation settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the size settings as follows:

  • Size—Choose one of the Mimic sizes:
  • Custom—Use to set the Mimic size to your specific requirements. When you select the Custom option, you can define the required size in the Width and Height fields.
  • Standard—Sets the Mimic to the standard size of 27.20 x 18.50 cm. This is an A4 page with margins.
  • A0-B10—Sets the Mimic to a standard paper size. The options correspond to paper sizes. When you select a size, the measurements for the size are shown in the Width and Height fields. For example, if you select A5, the Width field shows 21.00 and the Height field shows 14.80.
  • Landscape—Select this option button to set the Mimic to have a landscape orientation (the top and bottom of the Mimic are the longest sides).
  • Portrait—Select this option button to set the Mimic to have a portrait orientation (the left and right edges of the Mimic are the longest sides).


Mimics Guide - Define the Magnification Settings for a Mimic (Configuring the Mimic Properties)

Define the Magnification Settings for a Mimic

You can use the Mimic Properties window to define whether a Mimic can have its level of magnification altered in Run Mode and also the range of magnification permitted. This is useful when you need to restrict access to certain levels of magnification or wish to disable magnification in Run Mode to simplify the level of user interaction with a Mimic.

Depending on the method you use to display the Mimic Properties window, the Zooming settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the magnification settings as follows:

  • Zooming—Use the Zooming settings to define whether the Mimic can be magnified, and if so, what limits are in place:
  • Enabled—Use this check box to define whether the Mimic can be magnified in Run mode (via the Zoom tools on the Navigate toolbar). Select the check box to allow the Mimic to be magnified or clear it to disable the magnification features for the Mimic (in Run Mode).
  • Min—Use the Min percentage spin-box to define the lowest level of magnification that can be applied to the Mimic. In Run Mode, the Mimic will not be allowed to be shown at a smaller size than the Min size.
  • Max—Use the Max percentage spin-box to define the highest level of magnification that can be applied to the Mimic. In Run Mode, the Mimic will not be allowed to be shown at a larger size than the Max size.

Further Information

Magnifying a Mimic (Zooming)

Displaying a Mimic

Run Mode and Design Mode.


Mimics Guide - Define the Grid Settings for a Mimic (Configuring the Mimic Properties)

Define the Grid Settings for a Mimic

You can use the Mimic Properties window to define whether a Mimic has its Grid enabled or disabled. When the Grid feature is enabled, all objects on a Mimic are aligned with a grid line automatically. This alignment is referred to as an object being 'snapped to grid'.

The Grid is useful for aligning objects on a Mimic.

Depending on the method you use to display the Mimic Properties window, the Grid settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Grid settings as follows:

  • Enabled—Use to enable or disable the Grid feature for the selected Mimic/new Mimics on your client PC. Select the Enabled check box to set the Grid to be on display (though not necessarily visible, see below); clear the check box to disable the Grid.
  • Visible—Use to define whether the grid can be seen. If you select the Visible check box, the grid dots will be visible to users; if you clear the check box, the grid dots will not be shown but the grid will still be in place and objects will still align to it.
  • Width—Use to increase or decrease the amount of space between each column of grid dots.
  • Height—Use to increase or decrease the amount of space between each row of grid dots.

NOTE: You can also toggle the grid on and off by using the Grid toolbar button (see Alignment Toolbar).


Mimics Guide - Define the Script Settings for a Mimic (Configuring the Mimic Properties)

Define the Script Settings for a Mimic

You can use the Mimic Properties window to enable client-side scripting for a Mimic and also to access the Script Editor which you can use to create a Mimic script. The Mimic Properties script settings are:

  • Enabled—Select the Enabled check box to toggle the scripting feature on and off for the Mimic. By default, the Enabled check box is clear (scripting is off).
  • Edit—When you select the Enabled check box, the Edit button becomes available. When you select the Edit button, the Script Editor is displayed. You can use the Script Editor to create a script for the Mimic (see Display the Script Editor for a Mimic in the ClearSCADA Guide to Scripting).

The Script settings on the Mimic Properties window are only available on a per-Mimic basis (you have to access the Mimic Properties window by double-clicking on the background of a displayed Mimic or by right-clicking on the background and selecting the Properties option from the context sensitive menu).

For more information, please see Mimic Scripts in the ClearSCADA Guide to Scripting.


Mimics Guide - Define the Polyline Line Settings for a Mimic (Configuring the Mimic Properties)

Define the Polyline Line Settings for a Mimic

You can use the Polyline Line tab of the Mimic Properties window to define the default settings for lines that are drawn on Mimics. This is useful when you know that many different lines of the same type and style need to be added to a Mimic. Rather than configure each line separately, you can define the default settings for lines—then every line that is added will already have the default settings in place. You can make further adjustments to each line by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Polyline Line settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Polyline Line settings as required. The various PolyLine Line settings work in the same way as the similarly named settings on the Line tab of the Polyline Properties window (see Editing a Line).

Further Information

Define the Pipe Fill Settings for a Mimic.


Mimics Guide - Define the Polyline Fill Settings for a Mimic (Configuring the Mimic Properties)

Define the Polyline Fill Settings for a Mimic

You can use the Polyline Fill tab of the Mimic Properties window to define the default settings for the fill area of shapes that are drawn on Mimics (the fill area is the area within the edges of the shape). This is useful when you know that many different shapes, with the same types of fill, need to be added to a Mimic. Rather than configure the fill area for each shape separately, you can define the default settings for the fill area of every shape. After doing this, each shape that you add will already have the default settings in place. You can make further adjustments to each shape by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Polyline Fill settings you define will be applied to:

  • new Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Polyline Fill settings as required. The various PolyLine Fill settings work in the same way as the similarly named settings on the Fill tab of the Polyline Properties window (see Editing a Shape).

Further Information

Define the Pipe Fill Settings for a Mimic.


Mimics Guide - Define the Text Pen Settings for a Mimic (Configuring the Mimic Properties)

Define the Text Pen Settings for a Mimic

You can use the Text Pen tab of the Mimic Properties window to define the default settings for the text that you add to text boxes on Mimics. This is useful when you know that you need to add multiple text boxes to a Mimic, each containing text of the same type, color and with the same flashing effects. Rather than configure the pen settings for each text box separately, you can define the default pen settings for text boxes. After doing this, each text box that you add will already have the default settings in place. You can make further adjustments to each text box by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Text Pen settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Text Pen settings as required. The various Text Pen settings work in the same way as the similarly named settings on the Pen tab of the Text Properties window (see Editing a Text Box).

Further Information

Define the Text Fill Settings for a Mimic

Define the Text Font Settings for a Mimic.


Mimics Guide - Define the Text Fill Settings for a Mimic (Configuring the Mimic Properties)

Define the Text Fill Settings for a Mimic

You can use the Text Fill tab of the Mimic Properties window to define the default settings for the background of text boxes that you add to Mimics. This is useful when you know that you need to add multiple text boxes to a Mimic, each with the same color or style of background. Rather than configure the fill settings for each text box separately, you can define the default fill settings for text boxes. After doing this, each text box that you add will already have the default fill settings in place. You can make further adjustments to each text box by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Text Fill settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Text Fill settings as required. The various Text Fill settings work in the same way as the similarly named settings on the Fill tab of the Text Properties window (see Editing a Text Box).

Further Information

Define the Text Pen Settings for a Mimic

Define the Text Font Settings for a Mimic.


Mimics Guide - Define the Text Font Settings for a Mimic (Configuring the Mimic Properties)

Define the Text Font Settings for a Mimic

You can use the Text Font tab of the Mimic Properties window to define the default settings for the style, size and orientation of the lettering in text boxes that you add to Mimics. This is useful when you know that you need to add multiple text boxes to a Mimic, each with the same style of lettering. Rather than configure the font settings for each text box separately, you can define the default font settings for text boxes. After doing this, each text box that you add will already have the default font settings in place. You can make further adjustments to each text box by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Text Font settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Text Font settings as required. The various Text Font settings work in the same way as the similarly named settings on the Font tab of the Text Properties window (see Editing a Text Box).

Further Information

Define the Text Pen Settings for a Mimic

Define the Text Fill Settings for a Mimic.


Mimics Guide - Define the Button Pen Settings for a Mimic (Configuring the Mimic Properties)

Define the Button Pen Settings for a Mimic

You can use the Button Pen tab of the Mimic Properties window to define the default settings for the text that you add to buttons on Mimics. This is useful when you know that you need to add multiple buttons to a Mimic, each containing text of the same type, color and with the same flashing effects. Rather than configure the pen settings for each button separately, you can define the default pen settings for buttons. After doing this, each button that you add will already have the default settings in place. You can make further adjustments to each button by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Button Pen settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Button Pen settings as required. The various Button Pen settings work in the same way as the similarly named settings on the Pen tab of the Button Properties window (see Editing a Button).

Further Information

Define the Button Fill Settings for a Mimic

Define the Button Font Settings for a Mimic.


Mimics Guide - Define the Button Fill Settings for a Mimic (Configuring the Mimic Properties)

Define the Button Fill Settings for a Mimic

You can use the Button Fill tab of the Mimic Properties window to define the default settings for the background of buttons that you add to Mimics. This is useful when you know that you need to add multiple buttons to a Mimic, each with the same color or style of background. Rather than configure the fill settings for each button separately, you can define the default fill settings for buttons. After doing this, each button that you add will already have the default fill settings in place. You can make further adjustments to each button by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Button Fill settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Button Fill settings as required. The various Button Fill settings work in the same way as the similarly named settings on the Fill tab of the Button Properties window (see Editing a Button).

Further Information

Define the Button Pen Settings for a Mimic

Define the Button Font Settings for a Mimic.


Mimics Guide - Define the Button Font Settings for a Mimic (Configuring the Mimic Properties)

Define the Button Font Settings for a Mimic

You can use the Text Font tab of the Mimic Properties window to define the default settings for the style, size and orientation of the lettering in buttons that you add to Mimics. This is useful when you know that you need to add multiple buttons to a Mimic, each with the same style of lettering. Rather than configure the font settings for each button separately, you can define the default font settings for buttons. After doing this, each button that you add will already have the default font settings in place. You can make further adjustments to each button by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Button Font settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Button Font settings as required. The various Button Font settings work in the same way as the similarly named settings on the Font tab of the Button Properties window (see Editing a Button).

Further Information

Define the Button Pen Settings for a Mimic

Define the Button Fill Settings for a Mimic.


Mimics Guide - Define the Pipe Fill Settings for a Mimic (Configuring the Mimic Properties)

Define the Pipe Fill Settings for a Mimic

You can use the Pipe Fill tab of the Mimic Properties window to define the default settings for the background of pipes that you add to Mimics. This is useful when you know that you need to add multiple pipes to a Mimic, each with the same color or style of background. Rather than configure the fill settings for each pipe separately, you can define the default fill settings for pipes. After doing this, each pipe that you add will already have the default fill settings in place. You can make further adjustments to each pipe by configuring its own settings separately if required.

Depending on the method you use to display the Mimic Properties window, the Pipe Fill settings you define will be applied to:

  • New Mimics on your client PC (access the Mimic Properties window via the Edit button on the Mimics tab of the Options window—see Defining the Default Mimic Properties for New Mimics).
  • A specific Mimic (access the Mimic Properties window by selecting the Properties option for the background of a Mimic or by double-clicking on the background of a Mimic—see Defining the Default Mimic Properties for a Specific Mimic).

When you have displayed the Mimic Properties window using the appropriate method for your needs, define the Pipe Fill settings as required. The various Pipe Fill settings work in the same way as the similarly named settings on the Fill tab of the Pipe Properties window (see Editing a Pipe).


Mimics Guide - Adding Objects to a Mimic

Adding Objects to a Mimic

You can add a variety of objects to your Mimics, including shapes, comments, and dynamic values (referred to as animations). In this section, we explain how to:

  • Add Shapes to a Mimic
  • Add Text to a Mimic
  • Embed a Mimic on a Mimic
  • Embed a Pre-Configured Trend on a Mimic
  • Embed an X-Y Plot on a Mimic
  • Embed a Queries List on a Mimic
  • Embed an Alarms List on a Mimic
  • Embed an Image on a Mimic
  • Add Remote Images to a Mimic
  • Add a Button to a Mimic
  • Add a Pie Chart to a Mimic
  • Add a Pipe to a Mimic
  • Add Live Values to a Mimic
  • Add Pick Action Menus to a Mimic.

For information on adding dynamic values (values that update according to the values that are stored in the database), please refer to the Animations section (see Animations).

You can also add imported images to a Mimic:

  • Importing a DXF File
  • Importing an SVG File
  • Importing a Windows Metafile.


Mimics Guide - Add Shapes to a Mimic (Adding Objects to a Mimic)

Add Shapes to a Mimic

You can add a variety of shapes to your Mimics. The shapes can be common shapes such as lines, squares, and rectangles, or you can create polygons. You can also use the Curve tools to bend lines so that shapes become irregular (see Changing the Shape of an Object).

You can set each shape to have set colors and shading. You can also use Animations and Pick Actions to associate a shape with dynamic values and context sensitive menus respectively (see Animations).

To add a shape to a Mimic:

  1. On the Mimic Editor toolbar, select the required shape button.
    Line
    Rectangle
    Ellipse
    Polygon

    When you position the cursor on the Mimic, it will appear as a cross hair. This indicates that a shape tool is selected.

NOTE: You can also use the Line, Rectangle, Ellipse, and Polygon options on the Insert menu.

  2. Draw the required shape:
  • For lines, rectangles, and ellipses, simply press the left-hand mouse button to define the start of the shape, then keep the left hand mouse button pressed and move the cursor to the end of the shape. When you release the left-hand mouse button, the shape is drawn.
  • For polygons, press the left-hand mouse button once then move the cursor to the next corner or angle of the polygon. At the corner, press the left-hand mouse button again, then move the cursor to the next corner. Repeat this procedure until you have drawn the required polygon, then double-click to confirm the entry.

When you have drawn a shape, you can re-position it by selecting it and dragging it to a new location.

You can edit a shape by double-clicking on it to display its Properties window. You can use the Properties window to define the appearance of the shape. (see Editing Objects on a Mimic).

You can also access editing features by right-clicking on the shape to display a context sensitive menu (see Mimic Editing Features).


Mimics Guide - Add Text to a Mimic (Adding Objects to a Mimic)

Add Text to a Mimic

You can add text boxes to your Mimics. The text boxes are rectangular and contain a string of characters that you define. You can set the text box to be transparent so that only the text is visible, or you can set it to have a color. Similarly, you can alter the appearance of the text. You can also animate text boxes (see Animations).

To add text to a Mimic:

  1. On the Mimic Editor toolbar, select the Text button.

    When you position the cursor on the Mimic, it will appear as a cross hair. This indicates that the Text tool is selected.

NOTE: You can also use the Text option on the Insert menu.

  2. Draw a text box by pressing the left-hand mouse button and keeping it pressed down while you drag the cursor.
  3. Release the left-hand mouse button to complete the drawing of the text box and display the Text Properties window.
  4. Use the Text Properties window to define the settings for the text box.

Each tab provides the following settings:

  • General—Use to access the Animations and Pick Action settings, define the ToolTip, enable or disable Visibility, and define Dynamic Positions.
  • Text—Use to define the text that is shown in the text box.
  • Pen—Use to define the color and shading settings of the text.
  • Fill—Use to define the color and shading settings of the text box.
  • Font—Use to define the style and size of the text.

You can find more detailed information about the Text properties window in Editing a Text Box.

  5. Close the Text Properties window.

You can reposition the text box by dragging it, or you can double-click on it to edit it (see Editing a Text Box).

You can also access editing features by right-clicking on the text box to display a context sensitive menu (see Mimic Editing Features).


Mimics Guide - Embed a Mimic on a Mimic (Adding Objects to a Mimic)

Embed a Mimic on a Mimic

You can embed Mimics on other Mimics. This means that you can create a Mimic display that contains other Mimic displays.

Embedded Mimics are especially useful on Mimics that provide an overview—you can create a Mimic that contains status information etc. and also contains a visual representation in the form of an embedded Mimic. The overview Mimic can also contain links to the Mimic that is embedded.

Embedded Mimics are particularly useful on Mimics that provide an overview of a specific part of the system. For example, this Mimic contains an overview of status information, buttons that link to related displays, and a visual overview in the form on an embedded Mimic.
Embedded Mimic

Each Mimic can contain a maximum of 6 levels of embedded Mimic. For example, if a Mimic named 'Tanks' contains an embedded Mimic named 'Water Tanks', and the 'Water Tanks' Mimic contains an embedded Mimic named 'Main Tank', then the 'Tanks' Mimic is 3 levels deep:

'Tanks' Mimic contains an embedded version of the 'Water Tanks' Mimic which...
...itself contains an embedded Mimic named 'Main Tank'.
So, the 'Main Tank' Mimic is embedded on the 'Water Tanks' Mimic which is embedded on the 'Tanks' Mimic. This means the 'Tanks' Mimic contains 3 levels of embedded Mimics.

The limitation of six levels is designed to help prevent embedded Mimics from causing an infinite loop where Mimics are constantly reloaded.

If you exceed the permitted depth of levels, a level limit icon [image] is displayed in place of those embedded Mimics that are too deep (embedded deeper than six levels).

To add an embedded Mimic to a Mimic:

  1. Display the Mimic that is to contain the embedded Mimic. You need to display the Mimic in Design mode.
  2. Select the Embed Mimic button on the Mimic Editing toolbar.

NOTE: You can also use the Mimic option on the Insert menu.

  3. Draw the outline of the embedded Mimic by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the embedded Mimic.
  4. Release the left-hand mouse button to display a browse window.
  5. Use the browse window to locate the Mimic that you want to embed.
  6. Select the Mimic that is to be embedded, then select the OK button to confirm.
    The browse window is closed and the Mimic is embedded.

Alternatively:

  1. Display a Mimic in Design mode.
  2. In the Database Bar, select the Mimic that you want to embed and drag it onto the Mimic that you have already displayed in Design mode.
    A context sensitive menu is displayed.
  3. Select the Embedded Mimic option to embed the Mimic.

You can resize the embedded Mimic by selecting it and dragging its sides. Similarly, you can reposition it by selecting it and dragging it to a new position.

You can edit the embedded Mimic by double-clicking on it (see Editing an Embedded Mimic).

You can also access editing features by right-clicking on the embedded Mimic to display a context sensitive menu (see Mimic Editing Features).


Mimics Guide - Embed a Pre-Configured Trend on a Mimic (Adding Objects to a Mimic)

Embed a Pre-Configured Trend on a Mimic

You can embed pre-configured Trends on your Mimics. Embedded pre-configured Trends update in the same way as Trends that are stored as database items and provide similar advantages to embedded Mimics:

  • They allow you to display Trend data on a Mimic, which is especially useful on 'overview' Mimics.
  • You can embed multiple pre-configured Trends on a single Mimic. This is useful for comparing Trend data while also displaying other dynamic data such as states and values.
    Embedded pre-configured Trend

To embed a pre-configured Trend on a Mimic:

  1. Display the Mimic that is to contain the embedded Trend. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Embed Trend button on the Mimic Editing toolbar.

NOTE: You can also use the Trend option on the Insert menu.

  3. Draw the outline of the embedded Trend by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the embedded Trend.
  4. Release the left-hand mouse button to display a browse window.
  5. Use the browse window to locate the pre-configured Trend that you want to embed.
  6. Select the Trend that is to be embedded, then select the OK button to confirm.
    The browse window is closed and the Trend is embedded.

Alternatively:

  1. Display a Mimic in Design mode (see Displaying a Mimic).
  2. In the Database Bar, select the pre-configured Trend that you want to embed and drag it onto the Mimic.
    A context sensitive menu is displayed.
  3. Select the Embedded Trend option to embed the Trend on the Mimic.

You can resize the embedded Trend by selecting it and dragging its sides. Similarly, you can reposition it by selecting it and dragging it to a new position.

You can edit the embedded Trend by double-clicking on it (see Editing an Embedded Trend). You can also access editing features by right-clicking on the embedded Trend to display a context sensitive menu (see Mimic Editing Features).


Mimics Guide - Embed an X-Y Plot on a Mimic (Adding Objects to a Mimic)

Embed an X-Y Plot on a Mimic

You can embed X-Y Plots on your Mimics. Embedded X-Y Plots update in the same way as X-Y Plots that are stored as database items and provide similar advantages to embedded Mimics:

  • They allow you to display X-Y Plot data on a Mimic, which is especially useful on 'overview' Mimics.
  • You can embed multiple X-Y Plots on a single Mimic. This is useful for comparing X-Y Plot data while also displaying other dynamic data such as states and values.
    Embedded X-Y Plot

To embed an X-Y Plot on a Mimic:

  1. Display the Mimic that is to contain the embedded X-Y Plot. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Embed X-Y Plot button on the Mimic Editing toolbar.

NOTE: You can also use the X-Y Plot option on the Insert menu.

  3. Draw the outline of the embedded X-Y Plot by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the embedded X-Y Plot.
  4. Release the left-hand mouse button to display a browse window.
  5. Use the browse window to locate the X-Y Plot that you want to embed.
  6. Select the X-Y Plot that is to be embedded, then select the OK button to confirm.
    The browse window is closed and the X-Y Plot is embedded.

Alternatively:

  1. Display a Mimic in Design mode (see Displaying a Mimic).
  2. In the Database Bar, select the X-Y Plot that you want to embed and drag it onto the Mimic.
    A context sensitive menu is displayed.
  3. Select the Embedded X-Y Plot option to embed the X-Y Plot on the Mimic.

You can resize the embedded X-Y Plot by selecting it and dragging its sides. Similarly, you can reposition it by selecting it and dragging it to a new position.

You can edit the embedded X-Y Plot by double-clicking on it (see Editing an Embedded X-Y Plot). You can also access editing features by right-clicking on the embedded X-Y Plot to display a context sensitive menu (see Mimic Editing Features).


Mimics Guide - Embed a Queries List on a Mimic (Adding Objects to a Mimic)

Embed a Queries List on a Mimic

You can embed Queries Lists on your Mimics. Embedded Lists provide similar advantages to embedded Graphs:

  • They allow you to display List data on a Mimic, which is especially useful on 'overview' Mimics.
  • You can embed multiple Lists on a single Mimic. This is useful for comparing List entries from different Lists while also displaying other dynamic data such as states and values.

To embed a List on a Mimic:

  1. Display the List that you want to embed on a Mimic. You can display an unfiltered List or a filtered List (as you can embed both).

NOTE: To display a List, select the Queries button in the Operate toolbar, then locate the required List in the Queries tree-structure and double-click on it. Use the Filter Columns window to define any filters, then select the OK button to display the List.

  2. Select the View menu, then the SQL option to display the SQL code that provides the List.
  3. Select the entire SQL code, and copy it.

NOTE: To copy the code, highlight it, then press the right-hand mouse button to display a context sensitive menu. Select the Copy option from the menu to copy the SQL code to your computer's clipboard area. Alternatively, you can highlight the code and then press Ctrl and C simultaneously.

  4. Close the SQL window by selecting the OK button.
  5. Close the List.
  6. Display the Mimic that you want to contain the embedded List. You have to display the Mimic in Design mode.
  7. Select the Embed List button on the Mimic Editing toolbar.

NOTE: You can also use the List option on the Insert menu.

  8. Draw the outline of the embedded List by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the embedded List.
  9. Release the left-hand mouse button to display the Embedded List Properties window.
  10. Use the Embedded List Properties window to define the data that is shown on the list and its appearance:
  1. Paste the SQL code onto the Query tab. To do this, right-click in the text area on the Query tab and select the Paste option from the context sensitive menu. Alternatively, you can press Ctrl and V simultaneously.
  2. Remove the following character from the SQL code:

You have to remove each instance of this character, otherwise the List will not display correctly.

  3. Examine the SQL Query for the embedded Queries List. If you want the List to provide access to the context sensitive menus for the items in the List, include the Id field in the Query. If the Id field is excluded, the list will not provide access to the context sensitive menus.
  4. Use the General tab to:
  • Access the Animations for the embedded List.
  • Access the Pick Action Wizard for the embedded List.
  • Define the System settings for the embedded List.
  • Define the Dynamic Positions settings for the embedded List.
  • Define the colors for the embedded List.
  • Define the grid size for the embedded List.
  5. Use the List Font tab to define the size and style of the lettering used for the list entries.
  6. Use the Header Font tab to define the size and style of the lettering used for the column headings.

For more information on these settings, see Editing an Embedded Query List.

  11. Close the Embedded List Properties window.
    The embedded List is shown on the Mimic. It displays list entries that comply with the criteria you defined on the Query tab and has the display settings, animations, pick actions etc., that you defined on the General, List Font, and Header Font tabs.

Alternatively, you can:

  1. Display a Mimic in Design mode.
  2. Select the Embedded List button on the Mimic Editing toolbar.
  3. Draw the rectangle for the Embedded List.
  4. When the Embedded List Properties window is displayed, enter the required SQL code in the Query tab and use the other tabs to define the required settings.
  5. Close the Embedded List Properties window.

This method should only be used by engineers and operators with a good knowledge of SQL coding.

NOTE: The Embedded List option is also available via the Insert menu.

When you have added an embedded List to a Mimic, you can resize it by selecting it and then dragging its sides. Similarly, you can reposition it by selecting it and dragging it to a new position.

You can edit the embedded List by double-clicking on it (see Editing an Embedded Trend). You can also access editing features by right-clicking on the embedded List to display a context sensitive menu (see Mimic Editing Features).


Mimics Guide - Embed an Alarms List on a Mimic (Adding Objects to a Mimic)

Embed an Alarms List on a Mimic

You can embed an Alarms List on a Mimic. This is useful when you need a Mimic to provide alarm information as well as other information and links to other displays.

This Mimic contains an embedded Mimic as well as an embedded Alarms List.
Embedded Alarms List
Embedded Mimic

To embed an Alarms List on a Mimic:

  1. Display a Mimic in Design mode.
  2. Select the Embed Alarms List button on the Mimic Editing toolbar.

NOTE: You can also use the Alarm List option on the Insert menu.

  3. Draw the outline of the embedded Alarms List by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the embedded Alarms List.
  4. Release the left-hand mouse button to embed the Alarms List. The Alarms List contains a list of the alarms on the system.

NOTE: Users can apply sorting to the embedded Alarms List by viewing the Mimic in Run mode and using the Sort feature on the embedded Alarms List.

Further Information

Filtering an Embedded Alarms List: see Filter an Embedded Alarms List.

Filtering an Alarms List: see Use the Filter Window to Filter Alarm Entries in the ClearSCADA Guide to Alarms.


Mimics Guide - Embed an Image on a Mimic (Adding Objects to a Mimic)

Embed an Image on a Mimic

You can add images to your Mimics. This is useful for including company logos and other graphic files to your Mimic displays. As with other Mimic objects, you can resize and position embedded images and also edit their properties so that they are associated with pick action menus, animations etc.

Embedded Queries List
Embedded Image
Embedded Image

ClearSCADA supports the following image file formats:

  • BMP
  • JPEG
  • EMF
  • WMF
  • PNG
  • ICO

To embed an image on a Mimic:

  1. On the Mimic Editor toolbar, select the Embed Image button.

    A browse window is displayed.

NOTE: You can also use the Image option on the Insert menu.

  2. Use the browse window to locate the image file that you want to embed on the Mimic.
  3. Select the image file, then select the OK button to confirm.
    The browse window is closed and the cursor changes shape to indicate that the image tool is selected.
  4. Draw the outline of the embedded image by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the embedded image.
  5. Release the left-hand mouse button to embed the image.

When you have embedded the image, you can re-position it by selecting it and dragging it to a new location.

You can define the animations, pick actions etc. for the image by double-clicking on it to display its Properties window. For information on the image's property settings see Editing an Embedded Image.


Mimics Guide - Add Remote Images to a Mimic (Adding Objects to a Mimic)

Add Remote Images to a Mimic

Mimics can contain remote images—images that are stored on a web server. By using the remote image feature, you can add images from web cams and similar devices by storing the images on a web server and then referencing the images on your Mimic by using http.

Remote Images are useful for:

  • Web cams—Mimics can contain web cam images that can be updated at a specified rate. This means that you can present ' live' images such as security images from a webcam on a Mimic.
  • Managing pictures that are shown on web interfaces and Mimics at the same time. For example, if a company logo is displayed on a web page and on a Mimic, the logo can be stored on the web server. This means that if the logo is changed on the web server, it is automatically changed on the Mimic and on the web page—the pictures on the web server are not stored as part of the Mimic.

The Remote Image feature supports:

  • Bitmap (.bmp)
  • JPEG (.jpg or .jpeg)
  • Portable Network Graphics (.png) images.

If you have updating images that need to be added to a Mimic, for example, images from a web cam, you have to host the images on a web server before you can add them using the Remote Images feature.

NOTE: ClearSCADA uses the proxy server settings that are defined in Internet Explorer.

To add a remote image to a Mimic:

  1. On the Mimic Editor toolbar, select the Embed Remote Image button.

NOTE: You can also use the Remote Image option on the Insert menu.

  2. Draw the outline of the embedded image by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the embedded image.
  3. Release the left-hand mouse button to display the Remote Image Properties window.
  4. In the Source field, enter the address of the remote image file. For this example, we are going to use the WebX logo that is stored on your WebX server (but you could use any image that is available on the Internet, your network etc.):
http://localhost:81/file/images/logo.jpg

(Replace localhost:81 with the address of your WebX server if necessary).

For information on the other Remote Image Properties window settings, see Editing an Embedded Remote Image.

  5. Close the Remote Image Properties window.
    The remote image is displayed on the Mimic. If the remote image is not shown, re-display the Remote Image Properties window by double-clicking on the embedded image box and check that the Source entry is correct. If the entry is correct, you may need to check the Internet connections on the client PC.
    Remote Image (logo is stored on the WebX server)

When you have embedded the image, you can re-position it by selecting it and dragging it to a new location.

You can define the animations, pick actions etc. for the image by double-clicking on it to display its Properties window. For information on the image's property settings see Editing an Embedded Remote Image.


Mimics Guide - Add a Button to a Mimic (Adding Objects to a Mimic)

Add a Button to a Mimic

You can add buttons to your Mimics. The buttons are rectangles that have a 3D appearance and can be animated so that when selected, they appear to be pressed down. By using the Animations feature, you can set a button to instigate a system action. For example, you can configure a button on a Mimic that, when selected, appears to be pressed down and causes a point to be overridden.

The buttons are designed to provide obvious interactive features on your Mimics.

On this Mimic, the buttons are used to control a point. The point sends a signal to a pump that either empties the tank, empties the tank until it is at 50% volume, fills the tank, or fills the tank until it is at 50% volume. The signal that is sent to the pump is dependent on which button is selected.

To add a button to a Mimic:

  1. Display a Mimic in Design Mode.
  2. Select the Add Button button on the Mimic Editing toolbar.

NOTE: Alternatively, you can select the Insert menu, then select the Button option.

  3. Draw the outline of the button by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the button.
  4. Release the left-hand mouse button to add the button.

When you have added the button, you can re-position it by selecting it and dragging it to a new location.

You can define the animations, pick actions etc. for the button by double-clicking on it to display its Properties window. For information on the button's property settings see Editing a Button.


Mimics Guide - Add a Pie Chart to a Mimic (Adding Objects to a Mimic)

Add a Pie Chart to a Mimic

You can add pie charts to your Mimics. Pie charts are useful for displaying statistical information such as percentages.

Pie Chart

To add a pie chart to a Mimic:

  1. Display a Mimic in Design mode.
  2. Select the Add Pie Chart button on the Mimic Editing toolbar.

NOTE: Alternatively, you can select the Insert menu, then select the Pie Chart option.

  3. Draw the outline of the pie chart by pressing the left-hand mouse button, and moving the cursor while keeping the left-hand mouse button pressed. The rectangle that is drawn is the space that will be occupied by the pie chart.
  4. Release the left-hand mouse button to add the pie chart. When you first add a pie chart, it is entirely black. This is because it is not associated with any values.

To associate the pie chart with values and define its settings, see Editing a Pie Chart.

When you have added the pie chart, you can re-position it by selecting it and dragging it to a new location.


Mimics Guide - Add a Pipe to a Mimic (Adding Objects to a Mimic)

Add a Pipe to a Mimic

You can use the Pipe drawing tool to create pipelines on your Mimics. The pipelines are rectangular shapes that are pre-formatted to use pipe gradient shading which creates the illusion of a cylindrical shape.

On this Mimic, pipes have been drawn either side of a pump drawing. The pipes have been edited so that they are a suitable width and color.

To add a pipe drawing to a Mimic:

  1. Display a Mimic in Design mode.
  2. Select the Add Pipe button on the Mimic Editing toolbar.

NOTE: Alternatively, you can select the Insert menu, then select the Pipe option.

  3. Draw the pipeline in the same way that you would draw a polygon (i.e. left-click on a position, then move the cursor to a new position, then left-click again). Each time you press the left-hand mouse button, you define a new corner for the pipe. To complete the pipe drawing, double-click the left hand mouse button.

When you have double-clicked to define the end of the pipe drawing, the pipe is selected as a single object on the Mimic. It is gray with black and white shading by default. You can alter its settings via the Pipe Properties window (see Editing a Pipe).


Mimics Guide - Add Live Values to a Mimic (Adding Objects to a Mimic)

Add Live Values to a Mimic

You can add ‘live’ values for any database item to a Mimic by either:

  • Dragging the required item from the Database Bar onto the Mimic to display a context sensitive menu (see Database Bar in the ClearSCADA Guide to ViewX and WebX Clients).
    You can choose from any of the selection of ‘live’ values that are shown on the context sensitive menu, for example, for a database point, there are many current values that you can add, including Alarm State, State, Last Updated time, Quality and a variety of options for Value. You can also choose to add the Previous Value, Previous State, Previous Updated time or Previous Quality.

For more information on the possible options that can be shown on the context sensitive menu, see Drag and Drop Menu Options for Values on Mimics.

  • Displaying the OPC Data Bar, expanding the OPC property tags for the required item, then dragging the OPC tag you want to display onto the Mimic (see Working with the OPC Data Bar in the ClearSCADA Guide to Core Configuration).
  • Displaying the OPC Historic Data Bar, expanding the hierarchy of items with historic data, then dragging the item you want to display onto the Mimic. This will show ‘live’ historic data on the Mimic (the calculated Average value for the last hour). For more information on the OPC Historic Data Bar, see Working with the OPC Historic Data Bar in the ClearSCADA Guide to Core Configuration.
  • Creating an animation that references the database item and property that you want to display on the Mimic (see Animations).
  • Displaying the Queries Bar and dragging an SQL List, Data Grid, or Table onto the Mimic. This adds an embedded version of the selected SQL List to the Mimic. For more information on the Queries Bar, see Queries Bar in the ClearSCADA Guide to ViewX and WebX Clients.

For example, if you wanted to display the ‘live’ CurrentQualityDesc value of a point, you could display the OPC Data Bar, expand the property tags for the point, then select CurrentQualityDesc. With the property selected, you would then drag it onto the Mimic. ClearSCADA creates a text box containing the ‘live’ CurrentQualityDesc value of the point and displays it on the Mimic.

Drag an OPC Tag onto a Mimic and the latest value for that tag is shown in a text box. You can edit the text box as required.

When you have added a ‘live’ value to a Mimic, the value will update whenever the value changes in the database.

The text boxes, shapes, Lists, etc., that are added to the Mimic when you drag and drop have animations in place. You can edit these animations to suit your own requirements as needed (see Animations).


Mimics Guide - Drag and Drop Menu Options for Values on Mimics (Adding Objects to a Mimic)

Drag and Drop Menu Options for Values on Mimics

When you drag and drop a database item from the Database Bar onto a Mimic, a context sensitive menu is displayed. The options on the context sensitive menu vary according to the type of item you have selected.

The following list describes the possible menu options, but please be aware that some of the options are only available for certain items. For example, the Vertical Bar option is only available for analog points.

  • Name—Adds a text box that is animated to show the name of the item (see Text Box Animations).
  • Full Name—Adds a text box that is animated to show the full name (including any parent Groups) of the item (see Text Box Animations).
  • Hyperlink—Adds a text box that is animated so that it works as a hyperlink to the default display of the item (see Animating an Object to act as a Hyperlink).
  • Help View—Adds a text box that is animated so that is works as a hyperlink to the defined Help View of the item (see Animating an Object to act as a Hyperlink).
  • Alarm View—Adds a text box that is animated so that is works as a hyperlink to the defined Alarm View of the item (see Animating an Object to act as a Hyperlink).
  • Alarm State—Adds a text box that is animated so that it displays the current alarm state of the item (see Text Box Animations).
  • Value
  • Value—Adds a text box that is animated so that it displays the current value of the item (see Text Box Animations).
  • Formatted Value—Adds a text box that is animated so that it displays the current formatted value of the item (see Text Box Animations).
  • Vertical Bar—Adds a vertical bar that ‘fills’ according to the current value of the item (see Fill Animations).
  • Up—The proportion of the bar that is ‘filled’ represents the current value of the item. The minimum possible value corresponds to the bottom of the bar and the maximum possible value corresponds to the top of the bar.
    The ‘fill’ rises toward the top of the bar when the item’s value increases and drops toward the bottom of the bar when the value decreases.

  • Center—The proportion of the bar that is ‘filled’ represents the current value of the item. The minimum possible value corresponds to the center of the bar and the maximum possible value corresponds to the top and bottom of the bar. So when the value is low, the ‘fill’ is close to the center, and when the value is high, the ‘fill’ expands from the center to reach closer to the top and bottom of the bar.
    The ‘fill’ expands from the center toward the top and bottom of the bar when the item’s value increases. It contracts toward the center of the bar when the value decreases.

  • Down—The proportion of the bar that is ‘filled’ represents the current value of the item. The minimum possible value corresponds to the top of the bar and the maximum possible value corresponds to the bottom of the bar.
  • Horizontal Bar—Adds a vertical bar that ‘fills’ according to the current value of the item (see Fill Animations).
  • Left—The proportion of the bar that is ‘filled’ represents the current value of the item. The minimum possible value corresponds to the left of the bar and the maximum possible value corresponds to the right of the bar.
    The ‘fill’ expands from the left toward the right of the bar when the item’s value increases. It contracts toward the left of the bar when the value decreases.

  • Center—The proportion of the bar that is ‘filled’ represents the current value of the item. The minimum possible value corresponds to the center of the bar and the maximum possible value corresponds to the left and right of the bar. So when the value is low, the ‘fill’ is close to the center, and when the value is high, the ‘fill’ expands from the center to reach closer to the left and right of the bar.
    The ‘fill’ expands from the center toward the left and right of the bar when the item’s value increases. It contracts toward the center of the bar when the value decreases.

  • Right—The proportion of the bar that is ‘filled’ represents the current value of the item. The minimum possible value corresponds to the right of the bar and the maximum possible value corresponds to the left of the bar.
  • Sized Box—Adds an animated sized box to the Mimic (see Size Animations). The outline of the box represents the maximum value and an inner ‘fill’ represents the current value of the item. So when the item has a low value, the ‘fill’ is small and in the center of the box, and when the item’s value is high, the ‘fill’ is large and expands closer to the boundaries of the box.
    When the item’s value is low or decreases, the ‘fill’ shrinks toward the center...
    ...when the item’s value increases, the ‘fill’ expands toward the outer limits of the box.

  • Default View—Adds a text box that is animated so that is works as a hyperlink to the defined Default View of the item (see Animating an Object to act as a Hyperlink).
  • Embedded Mimic—Adds an embedded version of the selected Mimic onto the currently displayed Mimic (see Embed a Mimic on a Mimic).
  • Embedded Trend—Adds an embedded version of the selected Trend onto the Mimic (see Embed a Pre-Configured Trend on a Mimic).
  • Embedded X-Y Plot—Adds an embedded version of the selected X-Y Plot to the Mimic (see Embed an X-Y Plot on a Mimic).
  • Current Value—Adds a text box that is animated so that it displays the current value of the item (see Text Box Animations).
  • Quality—Adds a text box that is animated so that it displays the current quality of the item (see Text Box Animations).
  • Last Updated—Adds a text box that is animated so that it displays the time stamp of the most recent update to the item’s value (see Text Box Animations).
  • State—Adds a text box that is animated so that it displays the current state of the item (see Text Box Animations).
  • Previous Value—Adds a text box that is animated so that it displays the previous current value of the item (see Text Box Animations).
  • Previous Quality—Adds a text box that is animated so that it displays the previous quality of the item (see Text Box Animations).
  • Previous Updated—Adds a text box that is animated so that it displays the previous last updated time stamp of the item (see Text Box Animations).
  • Previous State—Adds a text box that is animated so that it displays the previous current state of the item (see Text Box Animations).
  • Color—Adds a rectangle that is animated so that its fill and line color represent the state of the item. The rectangle is also animated to flash (see FillColour).
  • Last Executed—Available for use with Schedules, this option adds a text box to the Mimic. The text box is animated so that it displays the time stamp for the previous execution of the schedule (see Text Box Animations)
  • Next Execute—Available for use with Schedules, this option adds a text box to the Mimic. The text box is animated so that it displays the time stamp for the next execution of the schedule (see Text Box Animations)
  • Duty User—Available for use with User Rosters, this option adds a text box to the Mimic. The text box is animated so that it displays the name of the User or User Group that is currently designated as the Duty User (see Text Box Animations)
  • List—Available for use with Data Grids, this option adds an embedded version of the selected Data Grid to the Mimic. The Data Grid is displayed as an SQL List.
  • Sinewave—Available only for Random Generators, you can use this option to add a text box that is animated with the Value, a vertical bar, a horizontal bar, or a sized box. In each case, the text or ‘fill’ represents the sinewave value of the random generator item you have selected.

In other respects, the Value, Vertical, Horizontal and Sized Box options work in the same way as the similarly named options from the Value sub-menu (see Value, above).

  • Sawtooth—Available only for Random Generators, you can use this option to add a text box that is animated with the value, a vertical bar, a horizontal bar, or a sized box. In each case, the text or ‘fill’ represents the sawtooth value of the random generator item you have selected.

In other respects, the Value, Vertical, Horizontal and Sized Box options work in the same way as the similarly named options from the Value sub-menu (see Value, above).

  • Random—Available only for Random Generators, you can use this option to add a text box that is animated with the value, a vertical bar, a horizontal bar, or a sized box. In each case, the text or ‘fill’ represents the random value of the random generator item you have selected.

In other respects, the Value, Vertical, Horizontal and Sized Box options work in the same way as the similarly named options from the Value sub-menu (see Value, above).

  • Walk—Available only for Random Generators, you can use this option to add a text box that is animated with the value, a vertical bar, a horizontal bar, or a sized box. In each case, the text or ‘fill’ represents the walk value of the random generator item you have selected.

In other respects, the Value, Vertical, Horizontal and Sized Box options work in the same way as the similarly named options from the Value sub-menu (see Value, above).

Further Information

Alarm Views: see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration.

Help Views: see Specify a Help View in the ClearSCADA Guide to Core Configuration.

Alarm States: see Alarm Severity, Status, and Category in the ClearSCADA Guide to Alarms.

Default Views: see Defining a Default View in the ClearSCADA Guide to Core Configuration.

Schedules: see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration.

Duty User: see Specify the Duty User in the ClearSCADA Guide to Alarm Redirection.

Data Grids: see Configuring Data Grids in the ClearSCADA Guide to Core Configuration.


Mimics Guide - Add Pick Action Menus to a Mimic (Adding Objects to a Mimic)

Add Pick Action Menus to a Mimic

You can setup pick action menus for any object on a Mimic. The pick action menus can be used to provide access to the options for a database item, act as a hyperlink, write a value to a registry, run a script etc.

For more information, see Associating Mimic Objects with Pick Actions.


Mimics Guide - Importing a DXF File

Importing a DXF File

You can import DXF files into your Mimics. This is useful as it allows you to use DXF files from other systems as objects on your Mimics.

Mimic showing imported DXF file.

To import a DXF file:

  1. Display the Mimic that is to contain the DXF file. You have to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Edit menu.
  3. Select the Import DXF File option.
  4. Use the browse window to locate the DXF file, select the file, then select the OK button.
    The Import DXF window is displayed.
  5. Use the settings to define which parts of the DXF file are to be imported:
  1. In the Layers list, select the check boxes for the layers that are to be imported. Clear the check boxes for those layers that are not required.
  2. Select a layer (it is highlighted when it is selected).
  3. Use the Details section’s Color button to set the color for the objects on the selected layer (see Using the Color Window).
  4. Use the Details section’s Import To combo box to define which Mimic layer will contain the selected DXF layer.
  5. Use the Offset settings to define the position of the DXF layer on the Mimic. Use the Left percentage spin-box to set the position from the left-hand side of the Mimic and the Top percentage spin box to set the position from the top side of the Mimic.
  6. Use the Scale settings to define the size of the DXF layer on the Mimic. Use the Width and Height percentage spin-boxes to set the size as required. Use the Preserve Aspect Ratio check box to define whether the DXF layer retains its original dimensions—select the check box to retain the dimensions so that the DXF layer objects keep the same proportions as the original DXF layer or clear it to allow the proportions to be changed.
  7. Repeat steps ii - vi inclusive for each layer.
  6. Select the OK button to import the DXF file.

When the DXF file is imported, ClearSCADA converts the objects in the DXF file into ViewX Mimic objects—it does not retain any reference to the DXF file. The imported DXF objects become standard Mimic objects and can be configured and animated in the same way as lines, shapes, pipes etc.

DXF files often contain many separate segments. Some of the segments may be redundant in ClearSCADA and may affect performance as ViewX needs to draw each segment in turn. To resolve this, we suggest that you:

  1. Select an imported DXF file.
  2. Press the right-hand mouse button to display a context sensitive menu.
  3. Select the Simplify option.
    ViewX removes any redundant segments—the shape of the objects will not change, but there will be less segments. This reduces the amount of processing required.

You can use the Mimic Diagnostics window to see how many segments have been removed (see Displaying Mimic Diagnostics).


Mimics Guide - Importing an SVG File

Importing an SVG File

You can import SVG version 1.1. files into your Mimics. This is useful as it allows you to use graphics that were created in other packages and saved as SVG to be used on Mimics.

ClearSCADA supports SVG version 1.1. and many of its features, including:

  • Concepts—SVG files are written in XML and can make use of effects, fonts and animations. These concepts are supported by ClearSCADA.
  • Rendering Model—ClearSCADA supports the 'painters model' and rendering methods used by SVG.
  • Basic Data Types and Interfaces—ClearSCADA supports the common data types for SVG properties and colors.
  • Document Structure—ClearSCADA supports the various elements of SVG document structure.
  • Coordinate Systems, Transformations and Units—ClearSCADA supports the coordinate systems used by SVG for the canvas size and positioning.
  • Paths—ClearSCADA supports the path lines that are used in SVG files to create the outlines of objects.
  • Basic Shapes—ClearSCADA supports the basic drawing shapes of SVG, including lines, circles, ellipses and rectangles.
  • Text—ClearSCADA supports the SVG specification for the use of text on graphics.
  • Painting: Filling, Stroking and Marker Symbols—ClearSCADA supports the SVG specification for the method of filling shapes (painting the interior of a shape) and stroking shapes (painting the outline of a shape). It also supports the SVG specification for marker symbols (arrow heads and polymarkers).
  • Color—ClearSCADA supports the SVG specification for color properties and definitions.
  • Gradients and Patterns—ClearSCADA supports the SVG specification for color shading and patterns.
  • Fonts—ClearSCADA supports the SVG specification for lettering styles.

Some SVG concepts cannot be converted for use with Mimics. Those SVG specifications that are unsuitable for use in ClearSCADA include: Styling; Clipping, Masking and Compositing; Filter Effects; Interactivity; Linking; Scripting; Animation; and Metadata. If an imported SVG graphic contains features that are not supported by ClearSCADA, a message box is displayed, describing which features could not be imported.

When you import an SVG file, the various shapes of the SVG graphic are converted into a group of Mimic objects that you can edit as required. You can also break the group so that the objects are individual objects that you can edit (see Editing Objects on a Mimic).

Mimic showing imported SVG file.

To import an SVG file:

  1. Display the Mimic that is to contain the SVG file. You have to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Insert menu.
  3. Select the SVG File option.
    A browse window is displayed.
  4. Use the browse window to locate the SVG file, select the file, then select the OK button.
  5. On the Mimic, position the cursor, keep the left-hand mouse button pressed down, then drag the cursor over the area that is to contain the SVG file. This 'draws' a box. The SVG file will be sized and proportioned to fill the box that you draw.
  6. Release the left-hand mouse button to insert the SVG file.

NOTE: When you insert the SVG file, a message may be displayed. The message provides details about any parts of the SVG graphic that are not supported by ClearSCADA.

You can edit the imported SVG graphics as required. By default, the individual graphics are grouped. You can edit the group (see Editing a Group of Mimic Objects) or can break the group and then edit the objects individually.

Further Information

The SVG Specification: see The World Wide Web Consortium web site at
http://www.w3.org/TR/SVG/.


Mimics Guide - Importing a Windows Metafile

Importing a Windows Metafile

You can import Windows metafiles into your Mimics. This is useful as it allows you to use graphics that were created in other packages and saved as .wmf to be used on Mimics.

When you import a Windows metafile, the various shapes of the graphic are converted into a group of Mimic objects that you can edit as required. You can also break the group so that the objects are individual objects that you can edit (see Editing Objects on a Mimic).

Mimic showing imported Windows metafile.

To import a Windows metafile:

  1. Display the Mimic that is to contain the Windows metafile. You have to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Insert menu.
  3. Select the Windows Metafile option.
    A browse window is displayed.
  4. Use the browse window to locate the Windows Metafile, select the file, then select the OK button.
  5. On the Mimic, position the cursor, keep the left-hand mouse button pressed down, then drag the cursor over the area that is to contain the Windows metafile. This 'draws' a box. The Windows metafile will be sized and proportioned to fill the box that you draw.
  6. Release the left-hand mouse button to insert the Windows metafile.

NOTE: When you insert the Windows metafile, a message may be displayed. The message provides details about any parts of the Windows metafile graphic that are not supported by ViewX.

You can edit the imported Windows metafile graphics as required. By default, the individual graphics are grouped. You can edit the group (see Editing a Group of Mimic Objects) or can break the group and then edit the objects individually.


Mimics Guide - Editing Objects on a Mimic

Editing Objects on a Mimic

When you have added an object to a Mimic, you need to access its Properties window so that you can edit its settings. Each object's settings allow you to alter the appearance and functionality of each Mimic object.

This section explains:

  • Editing a Line
  • Editing a Shape
  • Editing an Embedded Mimic
  • Editing an Embedded Trend
  • Editing an Embedded X-Y Plot
  • Editing an Embedded Query List
  • Editing an Embedded Alarms List
  • Editing an Embedded Image
  • Editing an Embedded Remote Image
  • Editing a Button
  • Editing a Pie Chart
  • Editing a Pipe
  • Editing a Text Box
  • Editing a Group of Mimic Objects.

It also explains how to use the Color window to define custom colors (see Using the Color Window).


Mimics Guide - Editing a Line (Editing Objects on a Mimic)

Editing a Line

When you have added a line to a Mimic, you can access its Properties window to edit its settings. The line's Properties window is called the Polyline Properties window.

To display the Polyline Properties window for a line, either:

  • Double-click on the line (with the Mimic displayed in Design mode).

or:

  • Right-click on the line and select Properties from the context sensitive menu.

The Polyline Properties window has three tabs which contain the settings that allow you to:

  • Define whether the line is visible (see General Tab)
  • Define a ToolTip for the line (see General Tab)
  • Access the Animations settings for the line (see General Tab)
  • Access the Pick Action Wizard for the line (see General Tab)
  • Define which area of the line provides access to a pick action menu (see General Tab)
  • Define which areas of the line are filled (see Creating a New Shape by Combining Mimic Objects)
  • Experiment with the line's rotation settings (see General Tab)
  • Experiment with the line's sizing settings (see General Tab)
  • Experiment with the line's position settings (see General Tab)
  • Define the appearance of the outline of the line (see Line Tab)
  • Define the appearance of the inside (the 'fill') of the line (see Fill Tab).

When you have edited the line, you can close the Polyline Properties window.

NOTE: Remember that you will need to save the Mimic to store the changes you have made. You can save the Mimic by selecting the Save button on the Operate toolbar or by selecting the File menu, then the Save option.


Mimics Guide - Editing a Shape (Editing Objects on a Mimic)

Editing a Shape

When you have added a shape to a Mimic, you can access its Properties window to edit its settings. The shape's Properties window is called the Polyline Properties window.

To display the Polyline Properties window for a shape, either:

  • Double-click on the shape (with the Mimic displayed in Design mode).

or:

  • Right-click on the shape and select Properties from the context sensitive menu.

The Polyline Properties window has three tabs which contain the settings that allow you to:

  • Define whether the shape is visible (see General Tab)
  • Define a ToolTip for the shape (see General Tab)
  • Access the Animations settings for the shape (see General Tab)
  • Access the Pick Action Wizard for the shape (see General Tab)
  • Define which area of the shape provides access to a pick action menu (see General Tab)
  • Define which areas of the shape are filled (see Creating a New Shape by Combining Mimic Objects)
  • Experiment with the shape's rotation settings (see General Tab)
  • Experiment with the shape's sizing settings (see General Tab)
  • Experiment with the shape's position settings (see General Tab)
  • Define the appearance of the outline of the shape (see Line Tab)
  • Define the appearance of the inside (the 'fill') of the shape (see Fill Tab).

When you have edited the shape, you can close the Polyline Properties window.

NOTE: Remember that you will need to save the Mimic to store the changes you have made. You can save the Mimic by selecting the Save button on the Operate toolbar or by selecting the File menu, then the Save option.


Mimics Guide - Editing an Embedded Mimic (Editing Objects on a Mimic)

Editing an Embedded Mimic

When you have added an embedded Mimic to a Mimic, you can access its Embedded Mimic Properties window to edit its settings.

To display the Embedded Mimic Properties window, either:

  • Double-click on the embedded Mimic (with the Mimic displayed in Design mode).

or:

  • Right-click on the embedded Mimic and select Properties from the context sensitive menu.

The Embedded Mimic Properties window has only one tab—the General tab. The tab contains Name, Visible, Animations, Pick Actions, ToolTip, and Dynamic Position settings that work in the same way as on other General tabs (see General Tab). However, the General tab on the Embedded Mimic Properties window also contains some settings that are specific to embedded Mimics:

  • Maintain Aspect Ratio
  • Shared with Other Embedded Mimics
  • System
  • Mimic
  • Relative.


Mimics Guide - Maintain Aspect Ratio (Editing Objects on a Mimic)

Maintain Aspect Ratio

Embedded Mimics have a Maintain Aspect Ratio setting that you can use to define whether the embedded Mimic retains its original proportions when it is resized. The Maintain Aspect Ratio setting is shown on the General tab of the Mimic Properties window (for embedded Mimics).

If you select the Maintain Aspect Ratio check box, the embedded Mimic will retain its original proportions. This means that when you resize the embedded Mimic, its width and height will maintain their relationship, for example, if you reduce the height, the width will also reduce automatically.

If you clear the Maintain Aspect Ratio check box, you can adjust the height and width of the embedded Mimic to any size. Changing the height will not affect the width and changing the width will not affect the height. This can result in distorted embedded Mimics, as the embedded Mimic can be stretched to the selected height or width.

The embedded Mimic is resized so that it is smaller. As the Maintain Aspect Ratio check box is selected, the smaller version has the same proportions as the original.
The embedded Mimic is resized so that it is smaller. As the Maintain Aspect Ratio check box is clear, the smaller version does not retain its original dimensions and so can be 'stretched'. In this case, the height of the embedded Mimic has been reduced, but the width has not been altered.

Further Information

Editing an Embedded Mimic


Mimics Guide - Shared with Other Embedded Mimics (Editing Objects on a Mimic)

Shared with Other Embedded Mimics

Each embedded Mimic has a Shared with Other Embedded Mimics setting that defines how ViewX loads the embedded Mimic into memory:

  • If Shared with Other Embedded Mimics is enabled (selected), ViewX loads a single version of the embedded Mimic into memory. This version is then used as the ‘definition’ (source) for every instance of that embedded Mimic on the Mimic.
    This Mimic has three instances of the same embedded Mimic. The embedded Mimic represents a pump. Only one copy of the definition for the embedded Mimic is loaded into memory—the three instances of the embedded Mimic use the same definition. This reduces the amount of memory used by the Mimic.

  • If Shared with Other Embedded Mimics is disabled (cleared), ViewX loads a separate ‘definition’ of each embedded Mimic into memory. This means that every embedded Mimic is unique and is not affected by changes to other instances of the same embedded Mimic.

For example, let’s say you have a Mimic that contains six embedded instances of a ‘Pump’ Mimic, and these embedded Mimics are only used as graphical aids (they have no animations). If the Shared with Other Embedded Mimics setting is enabled, it means ClearSCADA can load 1 ‘definition’ of the ‘Pump’ Mimic into memory and then use that single ‘definition’ for the six of the embedded Mimics. This reduces the amount of memory required and so makes performance more efficient. However, if the Shared with Other Embedded Mimics feature is disabled, ClearSCADA has to load six ‘definitions’ of the ‘Pump’ Mimic into memory - one for each embedded instance of the ‘Pump’ Mimic. This requires extra memory and so is less efficient.

By default, embedded Mimics have Shared with Other Embedded Mimics enabled (selected). This is because of the performance benefits gained by sharing, and also because many Mimics are not affected by sharing a single Mimic loaded into memory.

However, there are certain types of embedded Mimic that require the Shared with other Embedded Mimics setting to be disabled. This is because certain features, such as button animations, require an individual ‘definition’ of an embedded Mimic to be loaded into memory (for each instance of that embedded Mimic). Disabling the Shared with other Embedded Mimics setting unnecessarily can cause slow performance, so you should take great care when configuring this feature.

We recommend that you only disable the Shared with other Embedded Mimics setting if your embedded Mimic:

  • Uses Hover animations

Embedded Mimics that use hover animations need to be loaded individually, which means the Shared with Other Embedded Mimics needs to be disabled. The reason for this is that if a Mimic contains multiple instances of an embedded Mimic that uses Hover animations, the embedded Mimics need to have individual ‘definitions’ in memory. If they were to share the same ‘definition’, activating the Hover animation on one of the embedded Mimics would also cause the Hover animation to become active on the other instances of that embedded Mimic.

By disabling the Shared with Other Embedded Mimics setting, you ensure that ViewX loads separate ‘definitions’ of the embedded Mimic into memory. This allows the Hover animations of the embedded Mimics to work individually (activating the Hover animation on one instance of the embedded Mimic will have no affect of the Hover animation of another instance of the embedded Mimic).

  • Contains button objects that have animations

Embedded Mimics that have buttons with animations need to be loaded individually, which means the Shared with Other Embedded Mimics setting needs to be disabled. The reason for this is similar to the situation with embedded Mimics that use Hover animations (described above); if the embedded Mimics are shared, the animation on one instance of the embedded Mimic applies to each instance of the embedded Mimic. By disabling the Shared with Other Embedded Mimics setting, you set ViewX to load separate ‘definitions’ of the embedded Mimic into memory. This means you can use the buttons on each instance of the embedded Mimic individually.

For example, let’s say a Mimic is configured to represent a power switch and LED light. The Mimic is named ‘Power LED’ and is configured so that it has animations—when the buttons are pressed, they change appearance, the color of the ‘Power LED’ changes and a value is written to a point. This ‘Power LED’ Mimic is then embedded twice onto another Mimic (named ‘Controls’). Both of the embedded ‘Power LED’ Mimics are configured to have the Shared with Other Embedded Mimics setting disabled. This sets ViewX to load 2 ‘definitions’ of the ‘Power LED’ Mimic into memory when the ‘Controls’ Mimic is displayed.

As the embedded ‘Power LED’ Mimics do not share the same ‘definition’ in memory, selecting an animated button on one of the embedded Mimics has no effect on the other embedded ‘Power LED’ Mimic. So the animated buttons can be selected independently on each embedded Mimic
.

If the Shared with Other Embedded Mimics setting had been enabled, only one ‘definition’ of the embedded ‘Power LED’ Mimic would be loaded into memory. This would mean that if you selected ‘Power LED’ button on one of the embedded Mimics, the ‘Power LED’ button on the other embedded Mimic would also be selected.

  • Uses indirect tags that reference parameters.
    If the Mimic you are embedding uses indirect tags that reference parameters, you should disable the Shared with Other Embedded Mimics feature. This will help to prevent slow performance, which can occur when the underlying list of OPC tags are frequently changing.

Mimics are redrawn whenever there is a change to a value, including the value of a Mimic parameter. For this reason, it is vital that the Shared with Other Embedded Mimics setting is disabled for embedded Mimics that use indirect tags that reference Mimic parameters. This is because each instance of the embedded Mimic can be set to have a different source item for the Mimic parameter, and so if the ‘definition’ is shared, ViewX will have to continuously redraw the Mimic as it animates each embedded Mimic.

For example, let’s say a Mimic named ‘Overview’ contains two instances of an embedded Mimic named ‘Valve Display’. The ‘Valve Display’ Mimic is configured to show the current value of [Parameter A] and, when embedded, has its Shared with Other Embedded Mimics setting enabled.

On the ‘Overview’ Mimic, the first instance of the embedded ‘Valve Display’ has its [Parameter A] associated with a database point named ‘1AC’. The second instance of the embedded Mimic has its [Parameter A] associated with a database point named ‘Control C1’.

When ViewX draws the ‘Overview’ Mimic, it has to draw both of the embedded Mimics.

ViewX draws the first instance of the embedded Mimic and creates a new OPC Tag for the ‘definition’ of the embedded Mimic. The new OPC tag is added to the OPC Group list of tags for the ‘Overview’ Mimic and contains the reference for the value of [Parameter A], in this case, ["1AC"+ '.'CurrentValue'].

When ViewX draws the second instance of the embedded Mimic, a different reference has to be used for the value of [Parameter A] because the second embedded Mimic is associated with the ‘Control C1’ point. This means ViewX overwrites the OPC Tag for the ‘definition’ in memory - the OPC Tag now has ["Control C1"+ '.'CurrentValue'] instead of ["1AC"+ '.'CurrentValue']. As the parameter value has changed, ViewX has to redraw the Mimic, and so rewrites the parameter as ["1AC"+ '.'CurrentValue'] and then has to overwrite it with ["Control C1"+ '.'CurrentValue'] again. This continues for as long as the ‘Overview’ Mimic is displayed and can cause slow performance.

If the embedded ‘Valve Display’ Mimics have their Shared with Embedded Mimics settings disabled, the performance is unaffected. This is because if the embedded Mimics have individual ‘definitions’ loaded into memory, ViewX will create a new OPC Tag for each ‘definition’ rather than create, and continuously overwrite, a single OPC Tag for a shared ‘definition’.

NOTE: For maximum Mimic performance, you should configure the Embedded Mimic Cache Size setting so that it is large enough to store the embedded Mimics on a Mimic. For more information, see Define the Size of the Embedded Mimic Cache in the ClearSCADA Guide to Client Administration.

To change the Shared with Other Embedded Mimics setting, display the Embedded Mimic Properties window (see Editing an Embedded Mimic), then:

  • Select the Shared with Other Embedded Mimics check box to set the embedded Mimics to share a single ‘definition’. Only one ‘definition’ of the embedded Mimic will be stored in memory. This is the default setting and should be used on all embedded Mimics except those that use:
  • button animations
  • hover animations
  • tags that reference Mimic parameters.
  • Clear the Shared with Other Embedded Mimics check box to set the embedded Mimics to use individual ‘definitions’. A separate ‘definition’ will be loaded into memory for each individual instance of an embedded Mimic. For best Mimic performance, you should only clear the Shared with Other Embedded Mimics check box for embedded Mimics that use:
  • button animations
  • hover animations
  • tags that reference Mimic parameters.

ATTENTION: If your embedded Mimics have no button animations, hover animations or tags that reference Mimic parameters, you should select the Shared with Other Embedded Mimics check box. Disabling the Shared with Other Embedded Mimics feature for such embedded Mimics could cause slow performance.

NOTE: The Share with other embedded Mimics setting only affects ViewX memory usage—it does not affect the storage of Mimics in the server.


Mimics Guide - System (Editing Objects on a Mimic)

System

Each embedded Mimic has a System setting that you can use to specify which system contains the original version of the embedded Mimic. (The system on which the embedded Mimic is stored as a 'normal' Mimic.)

Typically, you will use the System combo box to select the same system that contains the Mimic you are configuring. However, you may need to change the System setting if you are editing a Mimic that has been copied from one system to another.

For example, a Mimic named 'Overview' is created on System A. The Mimic contains an embedded version of a Mimic named 'Pipeline' and the 'Pipeline' Mimic is also stored on System A.

The 'Overview' Mimic is copied and pasted into a folder on System B. Rather than have the Mimic on System B referring to the 'Pipeline' Mimic on System A, you can change the System setting so it refers to a local Mimic. On the 'Overview' Mimic on System B, the System setting for the embedded Mimic is changed from System A to System B. This means that the 'Overview' Mimic on System B refers to a local version of the 'Pipeline' Mimic i.e. a 'Pipeline' Mimic on System B.

To change the System setting, display the Embedded Mimic Properties window (see Editing an Embedded Mimic), then select the required system name in the System combo box.


Mimics Guide - Mimic (Editing Objects on a Mimic)

Mimic

Each embedded Mimic has an Embedded Mimic Properties window that includes a Mimic setting. The Mimic setting is ‘grayed out’ and shows the name of the embedded Mimic that you are currently editing.


Mimics Guide - Relative (Editing Objects on a Mimic)

Relative

Each embedded Mimic has a Relative setting that you can use to define whether an embedded Mimic uses relative or absolute references. This only applies when the embedded Mimic is stored on a different system to the Mimic that you are currently editing.

If you clear the Relative check box, the embedded Mimic will use an absolute reference. This means that:

  • The embedded Mimic has to be in the defined location
  • The Mimic that contains the embedded Mimic cannot be moved (without breaking the link to the embedded Mimic)
  • Copies of the Mimic will also contain the absolute reference and so has to be in the same location as the original Mimic.

If you select the Relative check box, the embedded Mimic will use a relative reference. This means that the link to the embedded Mimic will work as long as the Mimic and the embedded Mimic maintain their locations in relation to each other. They can be moved onto other systems, copied etc., and the link to the embedded Mimic will remain intact.


Mimics Guide - Editing an Embedded Trend (Editing Objects on a Mimic)

Editing an Embedded Trend

When you have embedded a pre-configured Trend onto a Mimic, you can access its Embedded Trend Properties window to edit its settings.

To display the Embedded Trend Properties window, either:

  • Double-click on the embedded pre-configured Trend (with the Mimic displayed in Design mode).

or:

  • Right-click on the embedded pre-configured Trend and select Properties from the context sensitive menu.

The Embedded Trend Properties window has these tabs:

  • General Tab (Embedded Trend)
  • Main Font Tab (Embedded Trend)
  • Title Font Tab (Embedded Trend)
  • Label Font Tab (Embedded Trend).


Mimics Guide - General Tab (Embedded Trend) (Editing Objects on a Mimic)

General Tab (Embedded Trend)

The General tab contains Name, Visible, Animations, Pick Actions, ToolTip, and Dynamic Position settings that work in the same way as on other General tabs (see General Tab). However, the General tab on the Embedded Trend Properties window also contains some settings that are specific to embedded pre-configured Trends:

  • System—Use the System combo box to specify which system contains the original version of the embedded pre-configured Trend i.e. the system on which the embedded Trend is stored as a 'normal' pre-configured Trend.

Typically, you will use the System combo box to select the same system that contains the Mimic you are configuring. However, you may need to change the System setting if you are editing a Mimic that has been copied from one system to another.

For example, a Mimic named 'Overview' is created on System A. The Mimic contains an embedded version of a Trend named 'Pressure' and the 'Pressure' Trend is also stored on System A.

The 'Overview' Mimic is copied and pasted into a folder on System B. Rather than have the Mimic on System B referring to the 'Pressure' Trend on System A, you can change the System setting so it refers to a local Trend. On the 'Overview' Mimic on System B, the System setting for the embedded Trend is changed from System A to System B. This means that the 'Overview' Mimic on System B refers to a local version of the 'Pressure' Trend i.e. a 'Pressure' Trend on System B.

  • Mimic—This field is read only (grayed out) and shows the name of the pre-configured Trend that is embedded.
  • Relative—You can use this check box to define whether an embedded Trend uses relative or absolute references. This only applies when the embedded Trend is stored on a different system to the Mimic that you are currently editing.

If you clear the Relative check box, the embedded Trend will use an absolute reference. This means that:

  • The embedded Trend has to be in the defined location
  • The Mimic that contains the embedded Trend cannot be moved (without breaking the link to the embedded Trend)
  • Copies of the Mimic will also contain the absolute reference and so has to be in the same location as the original Mimic.

If you select the Relative check box, the embedded Trend will use a relative reference. This means that the link to the embedded Trend will work as long as the Mimic and the embedded Trend maintain their locations in relation to each other. As long as their relative locations remain the same, the Mimic and Trend can be moved onto other systems, copied etc., and the link to the embedded Trend will remain intact.

  • Background—Use the Background color button to set the color of the background of the embedded pre-configured Trend. The background is gray by default, but you can change it to any of the system colors or to a custom color.
    Trend with default gray background
    Trend with light blue background

When you select the Background color button, a color palette is displayed.

Select the ... option to access the Color window.
If you want to use a default system color, select the required color from the palette.

You can select any of the colors on the palette, or select the ... option to access the Color window. The colors on the palette are the system colors, and the Color window allows you to create a custom color (see Using the Color Window).

  • Transparency—Use the Transparency spin-box to define the transparency of the color. You can set the color to have a minimum 0% transparency (solid) up to a maximum transparency of 100% transparency (invisible).
  • Show Title—Select the check box to display the title on the embedded pre-configured Trend or clear it to hide the title.
  • Show X-Axis—Select the check box to display the X-Axis on the embedded pre-configured Trend or clear it to hide the X-Axis.
  • Show Y-Axis—Select the check box to display the Y-Axis on the embedded pre-configured Trend or clear it to hide the Y-Axis.
  • Show Key—Select the check box to display the key on the embedded pre-configured Trend or clear it to hide the key.


Mimics Guide - Main Font Tab (Embedded Trend) (Editing Objects on a Mimic)

Main Font Tab (Embedded Trend)

You can use the Main Font tab to define the appearance of the text used on the limits, X-Axis, and Y-Axis.

The Main Font tab contains Family, Height, and Style settings. These are common text settings and are explained in the Font Tab section.


Mimics Guide - Title Font Tab (Embedded Trend) (Editing Objects on a Mimic)

Title Font Tab (Embedded Trend)

You can use the Title Font tab to define the appearance of the text on the Title of the pre-configured Trend.

The Title Font tab contains Family, Height, and Style settings. These are common text settings and are explained in the Font Tab section.


Mimics Guide - Label Font Tab (Embedded Trend) (Editing Objects on a Mimic)

Label Font Tab (Embedded Trend)

You can use the Label Font tab to define the appearance of the text on the Y-Axis label.

The Label Font tab contains Family, Height, and Style settings. These are common text settings and are explained in the Font Tab section.


Mimics Guide - Editing an Embedded X-Y Plot (Editing Objects on a Mimic)

Editing an Embedded X-Y Plot

When you have added an embedded X-Y Plot to a Mimic, you can access its Embedded X-Y Plot Properties window to edit its settings.

To display the Embedded X-Y Plot Properties window, either:

  • Double-click on the embedded X-Y Plot (with the Mimic displayed in Design mode).

or:

  • Right-click on the embedded X-Y Plot and select Properties from the context sensitive menu.

The Embedded X-Y Plot Properties window has four tabs:

  • General Tab (Embedded Trend)
  • Main Font Tab (Embedded Trend)
  • Title Font Tab (Embedded Trend)
  • Label Font Tab (Embedded Trend).


Mimics Guide - General Tab (Embedded X-Y Plot) (Editing Objects on a Mimic)

General Tab (Embedded X-Y Plot)

The General tab contains Name, Visible, Animations, Pick Actions, ToolTip, and Dynamic Position settings that work in the same way as on other General tabs (see General Tab). However, the General tab on the Embedded X-Y Plot Properties window also contains some settings that are specific to embedded X-Y Plots:

  • System—Use the System combo box to specify which system contains the original version of the embedded X-Y Plot i.e. the system on which the embedded X-Y Plot is stored as a 'normal' X-Y Plot.

Typically, you will use the System combo box to select the same system that contains the Mimic you are configuring. However, you may need to change the System setting if you are editing a Mimic that has been copied from one system to another.

For example, a Mimic named 'Overview' is created on System A. The Mimic contains an embedded version of a X-Y Plot named 'Pressure' and the 'Pressure' X-Y Plot is also stored on System A.

The 'Overview' Mimic is copied and pasted into a folder on System B. Rather than have the Mimic on System B referring to the 'Pressure' X-Y Plot on System A, you can change the System setting so it refers to a local X-Y Plot. On the 'Overview' Mimic on System B, the System setting for the embedded X-Y Plot is changed from System A to System B. This means that the 'Overview' Mimic on System B refers to a local version of the 'Pressure' X-Y Plot i.e. a 'Pressure' X-Y Plot on System B.

  • Mimic—This field is read only (grayed out) and shows the name of the X-Y Plot that is embedded.
  • Relative—You can use this check box to define whether an embedded X-Y Plot uses relative or absolute references. This only applies when the embedded X-Y Plot is stored on a different system to the Mimic that you are currently editing.

If you clear the Relative check box, the embedded X-Y Plot will use an absolute reference. This means that:

  • The embedded TX-Y Plot has to be in the defined location
  • The Mimic that contains the embedded X-Y Plot cannot be moved (without breaking the link to the embedded X-Y Plot)
  • Copies of the Mimic will also contain the absolute reference and so has to be in the same location as the original Mimic.

If you select the Relative check box, the embedded X-Y Plot will use a relative reference. This means that the link to the embedded X-Y Plot will work as long as the Mimic and the embedded X-Y Plot maintain their locations in relation to each other. As long as their relative locations remain the same, the Mimic and TX-Y Plot can be moved onto other systems, copied etc., and the link to the embedded X-Y Plot will remain intact.

  • Background—Use the Background color button to set the color of the background of the embedded X-Y Plot. The background is gray by default, but you can change it to any of the system colors or to a custom color.

When you select the Background color button, a color palette is displayed.

Select the ... option to access the Color window.
If you want to use a default system color, select the required color from the palette.

You can select any of the colors on the palette, or select the ... option to access the Color window. The colors on the palette are the system colors, and the Color window allows you to create a custom color (see Using the Color Window).

  • Transparency—Use the Transparency spin-box to define the transparency of the color. You can set the color to have a minimum 0% transparency (solid) up to a maximum transparency of 100% transparency (invisible).


Mimics Guide - Main Font Tab (Embedded X-Y Plot) (Editing Objects on a Mimic)

Main Font Tab (Embedded X-Y Plot)

You can use the Main Font tab to define the appearance of the text used on the limits, X-Axis, and Y-Axis.

The Main Font tab contains Family, Height, and Style settings. These are common text settings and are explained in the Font Tab section.


Mimics Guide - Title Font Tab (Embedded X-Y Plot) (Editing Objects on a Mimic)

Title Font Tab (Embedded X-Y Plot)

You can use the Title Font tab to define the appearance of the text on the Title of the Trend.

The Title Font tab contains Family, Height, and Style settings. These are common text settings and are explained in the Font Tab section.


Mimics Guide - Label Font Tab (Embedded X-Y Plot) (Editing Objects on a Mimic)

Label Font Tab (Embedded X-Y Plot)

You can use the Label Font tab to define the appearance of the text on the Y-Axis label.

The Label Font tab contains Family, Height, and Style settings. These are common text settings and are explained in the Font Tab section.


Mimics Guide - Editing an Embedded Query List (Editing Objects on a Mimic)

Editing an Embedded Query List

When you have added an embedded list to a Mimic, you can access its Embedded List Properties window to edit its settings.

To display the Embedded List Properties window, either:

  • Double-click on the embedded list (with the Mimic displayed in Design mode).

or:

  • Right-click on the embedded list and select Properties from the context sensitive menu.

The Embedded List Properties window contains four tabs:

  • General Tab (Embedded Query List)
  • Query Tab (Embedded Query List)
  • List Font Tab (Embedded Query List)
  • Header Font Tab (Embedded Query List).


Mimics Guide - General Tab (Embedded Query List) (Editing Objects on a Mimic)

General Tab (Embedded Query List)

The General tab for embedded lists contains several settings that are common to General tabs, including Name, Visible, Animations, Pick Action, ToolTip, and the Dynamic Position settings. For more information on these common settings, see General Tab.

The General tab for embedded lists also contains the following settings which you can use to define the appearance of the embedded list and to choose the database to which the list's query applies:

  • System—Use the System combo box to specify the database (system) to which the SQL query in the embedded List is applied. This allows embedded Lists on one system to display information taken from the database of another system.

Example:

A company has a ClearSCADA system that contains two databases. One database is called 'North' and the other is called 'South'. The 'North' database contains a Mimic that has an embedded List. The embedded List is set up to display the points on a system. By default, the embedded List displays the points on the 'North' system as this is the system that contains the Mimic. However, by using the System setting for the embedded List, an engineer can set the embedded List to display the points that are in the 'South' database. To do this, the engineer accesses the Properties window for the embedded List and changes the System setting from North to South.

Similarly, on the South system, a Mimic can be setup to contain an embedded List that shows the points on the North system. Again, an engineer has to access the Properties window for the embedded List and change the System setting, only this time the setting has to be changed from South to North.

  • Foreground—Use the Foreground color button to set the color of the text in the entries on the list.
    Foreground color is set to red. Foreground is not included in the SELECT part of the SQL Query for the list, so the text for the list entries is red.

As with other color buttons, you can choose a color from the palette, or use the ... option to create a custom color on the Color window (see Using the Color Window).

NOTE: The Foreground color only takes effect if the Foreground is not included in the SELECT part of the SQL Query for the list.

  • Background—Use the Background color button to set the color of the background of the list. The background color is shown in each row in the list and also at the extremities of the list.
    Background color is set to red.

As with other color buttons, you can choose a color from the palette, or use the ... option to create a custom color on the Color window (see Using the Color Window).

NOTE: The background color only affects the background color of the list’s cells if Background is excluded from the SELECT part of the SQL Query for the list. If the Background is included in the SELECT part of the SQL Query, the background color will only affect the background of the table, not the individual cells.

The background color is set to red. As the SQL Query for the list includes Background in its SELECT definition, the background color is not applied to the background of the list entries. Only the background of the table is set to red.

  • Header Text—Use the Header Text color button to set the color of the text in the column headings on the list.
    Header Text set to red

As with other color buttons, you can choose a color from the palette, or use the ... option to create a custom color on the Color window (see Using the Color Window).

  • Header Face—Use the Header Face color button to set the color of the column heading cells on the list.
    Header face set to red

As with other color buttons, you can choose a color from the palette, or use the ... option to create a custom color on the Color window (see Using the Color Window).

  • Header Shadow—Use the Header Shadow color button to set the color of the shadow line in the header cells on the list. The shadow line is a thin line that is shown on the bottom and the right-hand edge of each header cell.
    Header shadow set to red

As with other color buttons, you can choose a color from the palette, or use the ... option to create a custom color on the Color window (see Using the Color Window).

  • Header Highlight—Use the Header Highlight color button to set the color of the highlight line in the header cells on the list. The highlight line is a thin line that is shown on the top and left-hand edges of each header cell.
    Header highlight set to red

As with other color buttons, you can choose a color from the palette, or use the ... option to create a custom color on the Color window (see Using the Color Window).

  • Header Dark Shadow—Use the Header Dark Shadow color button to set the color of the dark shadow line in the header cells on the list. The dark shadow line is a thin line that is shown around the bottom, left, and right edges of the header cells.
    Header dark shadow is set to red

As with other color buttons, you can choose a color from the palette, or use the ... option to create a custom color on the Color window (see Using the Color Window).

  • Grid Color—Use the Grid Color color button to set the color of the lines that form the cells.
    Grid color is set to red

As with other color buttons, you can choose a color from the palette, or use the ... option to create a custom color on the Color window (see Using the Color Window).

  • Grid Size—Use the Grid Size spin-box to define the size of the grid lines that form the cells. You can increase or decrease the size as required.


Mimics Guide - Query Tab (Embedded Query List) (Editing Objects on a Mimic)

Query Tab (Embedded Query List)

Use the Query tab to alter the SQL code for the embedded List. You can add or remove code in the same way as you would use a text editing program such as Notepad.

A common use of the Query tab is to paste an SQL query that has been copied from a List (you can copy the SQL code for a List by displaying the List, selecting the SQL option on the View menu, highlighting the SQL code, then right-clicking and selecting the Copy option). To paste the code onto the Query tab, you need to copy the SQL code as described, then right-click on the Query tab and select the Paste option from the context sensitive menu.

If you right-click in the text entry area on the Query tab, a context sensitive menu is displayed containing the Generate Animation option. If you select this option, the SQL string that you have entered on the Query tab is copied and converted into the correct syntax for an animation of the Sql animation property. You can then amend the SQL animation via the Animations window as required (see Embedded Query List Animations).

For more information, see the SQL Technical Reference on-line Help.


Mimics Guide - List Font Tab (Embedded Query List) (Editing Objects on a Mimic)

List Font Tab (Embedded Query List)

Use the List Font tab to define the appearance of the text on the embedded list's list entries. The settings work in the same way as the similarly named settings on the Font Tab for text boxes etc.


Mimics Guide - Header Font Tab (Embedded Query List) (Editing Objects on a Mimic)

Header Font Tab (Embedded Query List)

Use the Header Font tab to define the appearance of the text on the embedded list's column headings. The settings work in the same way as the similarly named settings on the Font Tab for text boxes etc.


Mimics Guide - Editing an Embedded Alarms List (Editing Objects on a Mimic)

Editing an Embedded Alarms List

When you have added an embedded Alarms List to a Mimic, you can access its Embedded Alarm List Properties window to edit its settings.

To display the Embedded Alarm List Properties window, either:

  • Double-click on the embedded Alarms List (with the Mimic displayed in Design mode)

or:

  • Right-click on the embedded Alarms List and select Properties from the context sensitive menu.

The Embedded Alarm List Properties window has three tabs: General, List Font, and Header Font. These tabs work in the same way as the General, List Font, and Header Font tabs on the Embedded List Properties window, except that they apply to the various parts of the Alarms list (see Editing an Embedded Query List).

However, there is one exception—the General tab for an embedded Alarms List has a Filter button that you can use to Filter an Embedded Alarms List.


Mimics Guide - Filter an Embedded Alarms List (Editing Objects on a Mimic)

Filter an Embedded Alarms List

You can apply a filter to an embedded Alarms List so that the Alarms List only includes information that meets specific criteria. To filter an embedded Alarms List, you need to:

  1. In Design Mode, right-click on the embedded Alarm List to display a context sensitive menu.
  2. Select the Properties option to display the Embedded Alarm List Properties window.
  3. Select the Filter button.
    The Edit Embedded Alarm List String dialog box is displayed.

At this stage, you have a choice. You can either:

  • Define an Alarm Filter String for an Embedded Alarms List Manually.

Or:

  • Use the Filter Window to Create an Alarm Filter String for an Embedded Alarms List. When you use the Filter window, ClearSCADA converts your selections into an appropriate string, which it then uses to apply the filter settings.

Before you make your choice, you need to understand how the Alarm Filter String is used (see Understanding How ClearSCADA Applies Alarm Filters to Embedded Alarms Lists).

  4. Use the Alarm Filter String field or Filter window to define the required filter string (see Define an Alarm Filter String for an Embedded Alarms List Manually or Use the Filter Window to Create an Alarm Filter String for an Embedded Alarms List, depending on how you want to define the string).
  5. Select the OK button to apply the filter setting and close the filter configuration windows (Edit Embedded Alarm List Filter String dialog box and Filter window).
    The embedded Alarms List is now set to use the filter settings you defined every time it is displayed. Users with appropriate permissions will be able to alter the filter settings as required, but every time the embedded Alarms List is re-displayed, the filter settings you defined will be in place.

Further Information

Understanding How ClearSCADA Applies Alarm Filters to Embedded Alarms Lists

Define an Alarm Filter String for an Embedded Alarms List Manually

Use the Filter Window to Create an Alarm Filter String for an Embedded Alarms List


Mimics Guide - Understanding How ClearSCADA Applies Alarm Filters to Embedded Alarms Lists (Editing Objects on a Mimic)

Understanding How ClearSCADA Applies Alarm Filters to Embedded Alarms Lists

Whether you define the Alarm Filter String manually, or allow ClearSCADA to create the string based on your selections on the Filter window, you need to understand how ClearSCADA applies alarm filter strings. In this section, we explain how the alarm filter strings of User accounts and Alarms Lists are used and describe how ClearSCADA determines which filter settings take precedence.

Once you understand how ClearSCADA uses Alarm Filter Strings, you will be able to create your own alarm filters without experiencing unexpected results.

In ClearSCADA, both User accounts and Alarms Lists (including embedded Alarms Lists) have Alarm Filter String settings. These settings define the filter settings that are applied to an Alarms List when it is first displayed.

A User account’s Alarm Filter String is defined on the User Form and it is applied automatically whenever that user accesses an Alarms List. However, ClearSCADA only applies the clauses if they do not conflict with the clauses in the list’s own Alarm Filter String.

Alarms Lists also have an Alarm Filter String that is applied whenever the lists are displayed. Any settings that are explicitly defined in the filter string for an Alarms List take precedence over the settings defined in any User alarm filter string.

When an embedded Alarms List is displayed, ClearSCADA merges the filter string defined for the Alarms List with the filter string defined for the current user’s User account. It then applies the resulting string to the embedded Alarms List.

If the filter string for the User account does not conflict with the filter string for the embedded Alarms List, ClearSCADA can merge the strings and apply both filters simultaneously. However, if there is a conflict, ClearSCADA will use the filter values in the embedded Alarms List’s filter string in preference to those defined for the User account’s filter string (on a clause-by-clause basis). This means that the embedded Alarms List’s filter string takes precedence over a User account’s alarm filter string.

NOTE: ClearSCADA can only use a clause in preference to another clause. So a blank clause (representing a default filter value) cannot be used in preference to a defined filter. For example, a blank Minimum Severity setting in an embedded Alarms List’s filter string cannot be used in preference to MinSeverity=200 in a User account’s filter string.

However, there is one situation in which the User filter string takes precedence over the embedded Alarm’s List’s filter setting—when the default filter values are in place but not specified in the string for the Alarms List. For more information on this special case, see Making an Embedded Alarms List’s Default Filter Settings Take Precedence.

Now that you have an appreciation of how ClearSCADA uses the Alarm Filter String settings, you can make an informed decision:

If you want to apply a filter that differs from the default filter values, you can choose to:

  • Enter the alarm filter string manually (see Define an Alarm Filter String for an Embedded Alarms List Manually). You will need an understanding of the required syntax: see Alarm Filter String Syntax in the ClearSCADA Guide to Alarms.

or

  • Use the Filter window to choose the filter settings. ClearSCADA will then generate the appropriate filter string for you (see Use the Filter Window to Create an Alarm Filter String for an Embedded Alarms List).

If you want to use the default filter values for the embedded Alarms List and are willing to let User account filter strings take precedence:

  • Leave the Alarm Filter String for the List blank (see Define an Alarm Filter String for an Embedded Alarms List Manually).

or:

  • If the default filter settings are not currently in place, you can use the Filter window to reset the various options to their default value (see Use the Filter Window to Create an Alarm Filter String for an Embedded Alarms List).

If you want to use the default filter values for the embedded Alarms List and you want these default values to take precedence over any User account filter strings:

  • see Making an Embedded Alarms List’s Default Filter Settings Take Precedence.


Mimics Guide - Define an Alarm Filter String for an Embedded Alarms List Manually (Editing Objects on a Mimic)

Define an Alarm Filter String for an Embedded Alarms List Manually

You can define an alarm filter by entering the expression for the alarm filter string manually. The clauses you can use to define the string are:

MinSeverity="<Lower Severity Limit>"
MaxSeverity="<Upper Severity Limit>"
AlarmState="<Every Alarm State or a Specific State>"
Assigned="<True or False>"
Source="<Data Source>"
AOI="<Name of Area of Interest>"
Categories="<Name of one or more Categories>

Do not include the angle brackets < >.

For example, the following string filters an alarms list so that when it is first displayed, it only shows outstation communications alarms that are in the unacknowledged state, assigned to the current user, in a Group named 'CM' or one of its children, and in an Area of Interest named 'AFKI':

AOI="AFKI"&Source="CM.*"&Categories="Outstation Comms"&AlarmState="Unacknowledged"&Assigned="TRUE"

When you define an alarm filter string manually, you may need to define values for some of the clauses in your string. If you do not include certain clauses in your string, ClearSCADA will use the default values for those clauses.
Clause | Value used by ClearSCADA for clause if clause is not included in filter string
MinSeverity | Low
MaxSeverity | Critical
AlarmState | All States
Assigned | FALSE
Source | All Sources
AOI | All Areas of Interest
Categories | All Categories

NOTE: Blank clauses in an Alarms List filter string cannot take precedence over defined clauses in the User account filter string. For more information, see Making an Embedded Alarms List’s Default Filter Settings Take Precedence.

To define the filter string for an embedded Alarms List manually:

  1. Display the Embedded Alarm List String dialog box (see Filter an Embedded Alarms List)
  2. On the Edit Embedded Alarm List String dialog box, enter the string for your filter in the Alarm Filter String text entry field. For more information on constructing an alarm filter string, see Alarm Filter String Syntax in the ClearSCADA Guide to Alarms.
  3. When you have entered an appropriate string for the filter you require, select the OK button to confirm. This closes the Edit Embedded Alarm List String dialog box.
  4. Close the Edit Embedded List Properties window.
    The filter you have defined is applied to the list. You have now filtered the embedded Alarms List.

Further Information

Understanding How ClearSCADA Applies Alarm Filters to Embedded Alarms Lists

Use the Filter Window to Create an Alarm Filter String for an Embedded Alarms List


Mimics Guide - Use the Filter Window to Create an Alarm Filter String for an Embedded Alarms List (Editing Objects on a Mimic)

Use the Filter Window to Create an Alarm Filter String for an Embedded Alarms List

To define an alarm filter for an embedded Alarms List, you can either enter the alarm filter string manually or you can use the various settings on the Filter window. If you use the Filter window settings, you simply choose the filter options you want to apply and then ClearSCADA constructs the corresponding filter string for you. This is useful if you are unfamiliar with expressions and the syntax required for defining filters.

To use the Filter window to create an alarm filter string for an embedded Alarms List:

  1. Display the Embedded Alarm List String dialog box (see Filter an Embedded Alarms List)
  2. On the Edit Embedded Alarm List String dialog box, select the ... browse button to display the Filter window.
  3. Use the Filter window settings to create the filter criteria for your embedded Alarms List. These settings work in the same way as the alarm filter settings for an Alarms List, see Use the Filter Window to Filter Alarm Entries in the ClearSCADA Guide to Alarms.
  4. Select the OK button to confirm your choices and close the Filter window.
    ClearSCADA creates a string that represents the choices you have made. The string is added to the Edit Embedded Alarm List dialog box automatically.
  5. Close the Edit Embedded List Properties window.
    The filter you have defined is applied to the list. You have now filtered the embedded Alarms List.

Further Information

Understanding How ClearSCADA Applies Alarm Filters to Embedded Alarms Lists

Making an Embedded Alarms List’s Default Filter Settings Take Precedence

Making an Embedded Alarms List’s Default Filter Settings Take Precedence

You need to define the alarm filter manually if:

  • You want to use the default settings for an embedded Alarms List’s filter

and

  • You want the default settings to take precedence over any defined User filter strings.

This is because the default settings have no need for ClearSCADA to generate a string. So when ClearSCADA merges the embedded Alarms List’s filter with that of a User account, the User account filter string is used. This is because the User account’s filter string has defined clauses whereas the embedded Alarms List’s filter is blank.
Embedded Alarms List Filter String | User Account Filter String | Result
String created manually by user | Blank | ClearSCADA applies embedded Alarms List’s filter string
String created manually by user, every clause included | String created manually by user | ClearSCADA merges the two filter strings and applies the resulting filter. If there is a conflict between the two filters, the embedded Alarms List’s filter takes precedence
String created manually by user, some clauses omitted | String created manually by user | ClearSCADA merges the two filter strings and applies the resulting filter. If there is a conflict between the two filters, the clauses that are explicitly defined in the embedded Alarms List’s filter string take precedence. However, any clauses that are left out of the embedded Alarms List’s filter cannot take precedence.
Blank | Blank | ClearSCADA displays an unfiltered embedded Alarms List (no filter is applied).
String created manually by user, some clauses omitted | Blank | The clauses which are specified in the embedded Alarms List’s filter string are applied. The default values for the clauses that are not specified in the filter string are also applied.
Blank | String created manually by user | The User account filter string is applied.

To configure the embedded Alarms List’s filter so that its default filter values take precedence over any User account filter strings:

  1. Display the Embedded Alarm List String dialog box (see Filter an Embedded Alarms List)
  2. On the Edit Embedded Alarm List String dialog box, select the ...browse button to display the Filter window.
  3. Using the Filter window’s settings:
  • Select the Only Show Alarms Assigned to Current User check box
  • Add a Source
  • Add an Area of Interest (if this feature is enabled on your system)
  • Change the Minimum Severity setting
  • Change the Maximum Severity setting
  • Clear at least 1 Category.
  • Select any State (i.e. select any option other than All States).

The reason for changing the settings from the default settings is that it forces ClearSCADA to generate a string automatically. You can then edit the string so that the default settings are used in the string, and so, as a result will take precedence over the clauses in any User account filter strings.

  4. Select the OK button to confirm your selections.
    This closes the Filter window. As you have defined a filter, ClearSCADA generates the corresponding string automatically and it is shown in the Edit Embedded Alarm List dialog box.
  5. Edit the string so that the default filter values are applied. Your string should appear like this:
AOI="World"&Source="*"&MinSeverity="1"&MaxSeverity="1000"&Categories="Alarm Inhibit;Archive Volume;Archiving;Authentication;Callback;Channel Status;Control Status;Dial In Overactive;EFM Alarm;File Upload Status;Forecast;Interface Alarm;Off Scan;Outstation Comms;Outstation Error;Outstation Hardware;Pager Comms;Point Error;Point No Change;Point State;Scanner Status;Scheduled Dial In;Server Status;SMS PagerService;SNMP Configuration Error;System Alarm"&AlarmState="All"&Assigned="FALSE"

NOTE: To apply the default settings, you will need to adjust the values for several clauses: the value for the categories clause needs to include every category that is available on your system; the value for the AOI clause needs to be World (which includes every Area of Interest); the value for the MinSeverity should be 1 and the MaxSeverity should be 1000.

  6. Select the OK button to confirm your string and close the Edit Embedded Alarm List String dialog box.
    The default filter values are applied to the embedded Alarms List and will be applied whenever the embedded Alarms List is displayed.

Further Information

Alarm Filter Syntax: see Alarm Filter String Syntax in the ClearSCADA Guide to Alarms.


Mimics Guide - Editing an Embedded Image (Editing Objects on a Mimic)

Editing an Embedded Image

When you have added an embedded image to a Mimic, you can access its Image Properties window to edit its settings.

To display the Image Properties window, either:

  • Double-click on the image (with the Mimic displayed in Design mode)

or:

  • Right-click on the embedded image and select Properties from the context sensitive menu.

The Image Properties window contains a single tab—General.

The General tab contains Name, Visible, Animations, Pick Action, ToolTip, and Dynamic Position settings that work in the same way as on other General tabs (see General Tab). However, the General tab on the Image Properties window also contains Alignment settings:

  • Center—Select this option button to position the embedded image so that it is in the middle of the image frame (the frame that you drew when you added the image).
  • Stretch—Select this option button to resize the embedded image so that it fills the image frame.
  • Tile—Select this option button to repeat the embedded image in the image frame until the image frame is full.


Mimics Guide - Editing an Embedded Remote Image (Editing Objects on a Mimic)

Editing an Embedded Remote Image

When you have added a remote image to a Mimic, you can access its Remote Image Properties window to edit its settings.

To display the Remote Image Properties window, either:

  • Double-click on the image (with the Mimic displayed in Design mode)

or:

  • Right-click on the remote image and select Properties from the context sensitive menu

The Remote Image Properties window has a General tab. The General tab contains Name, Visible, Animations, Pick Action, ToolTip, and Dynamic Position settings that work in the same way as on other General tabs (see General Tab). The General tab on the Remote Image Properties window also contains these settings:

  • Alignment—The Alignment settings of Center, Stretch, and Tile work in the same way as the alignment settings for embedded images (see Editing an Embedded Image), except that they apply to the remote image.
  • Source—Use to define the location of the image. This can be the complete path name of an image file that is available on your network or the address of an image file on the Internet (or your Intranet). For example, to insert the Earth image from the www.pdimages.com web site, you would enter:
http://www.pdimages.com/BX0097.JPG

  • Refresh—Use to set your client PC to request the image at a defined interval. The Refresh numbers represent seconds, so if you set the Refresh spin-box to 5, your client PC will request the image every 5 seconds. Although the image on the Mimic will update at the defined Refresh rate, the picture may change less frequently as the refresh time of the web server controls how often the image changes.


Mimics Guide - Editing a Button (Editing Objects on a Mimic)

Editing a Button

When you have added a button to a Mimic, you can access its Button Properties window to edit its settings.

To display the Button Properties window, either:

  • Double-click on the button (with the Mimic displayed in Design mode)

or:

  • Right-click on the button and select Properties from the context sensitive menu

The Button Properties window has four tabs:

  • General—The General tab contains some common settings for General tabs, including Name, Visible, Animations, Pick Action, ToolTip, and the Dynamic Position settings. For more information on these settings, see General Tab.

The General tab on the Button Properties window also contains these settings:

  • Style—Use the Style combo box to define whether the button is:
  • Normal—The button will appear to be pressed down when it is selected (the button will only appear to be pressed down when the Mimic is in Run mode).

When a normal button is pressed, it executes any animations or pick actions associated with the button once per selection. For example, if a button is configured to change the state of a digital point, pressing the button so that it is pressed down then deselected 3 times will change the state of the point 3 times. Holding the button down will only change the point state 1 time.

  • Latch—The button will only appear to be pressed down when its Latched animations property has a value that is true.

Typically, the Latch style is used with a button that is animated to perform an action when selected. For example, a button can be configured to change the value of a digital point to True when it is pressed. The state of the digital point can also be associated with the button's Latched property so that when the button is pressed, the digital point's value changes to True and the Latched property changes to True. So, when the button is selected, there is a short pause as the values and states are processed and changed, then the button appears to be pressed down.

For more information, see Latched.

  • Latch w/feedback—The Latch w/feedback style works in the same way as the Latch style except that there is no delay when the button is selected—the button appears to be pressed down when it is selected and when its Latched property has a True value.

For more information, see Latched.

  • Repeat—The button appears as a ‘normal’ button, but when held in the pressed down position, it continues to execute any associated pick actions or animations. For example, you can configure a repeat button so that, when selected, it executes a Logic program. If you keep the repeat button pressed down for 30 seconds, the associated Logic program will execute 30 times (once per second by default).

The Repeat button is designed to be used with pick action animations, where a method is called repeatedly for as long as the button is pressed down. For more information on the Repeat feature and an example of how it can be used, see Using Repeat Buttons to Write to a Point.

  • Repeat Interval—Only available when the Repeat option is selected for the Style setting. The Repeat Interval allows you to define how often the repeat occurs. By default, the Repeat Interval is 1.0 seconds which means that if the button is held in a pressed down position, the action for the button will repeat once per second (for as long as the button is pressed down). You can change the amount of time between each repeat as required.
  • Text—Enter the text that will be shown on the face of the button. By default, the Text entry is 'Button'.

The Text entry will be overridden by any animations that use the Text animation property of the button. For more information,see Animations.

  • Pen—Use the Pen tab to define the color and shading settings for the text that is shown on the button. The Pen tab settings work in the same way as the settings on other Pen tabs (see Pen Tab).
  • Fill—Use the Fill tab to define the color and shading settings for the background of the button. The Fill tab settings work in the same way as the settings on other Fill tabs (see Fill Tab).
  • Font—Use the Font tab settings to define the style, size, and positioning of the text that is shown on the button. The Font tab settings work in the same way as the settings on other Font tabs (see Font Tab).


Mimics Guide - Editing a Pie Chart (Editing Objects on a Mimic)

Editing a Pie Chart

When you have added a pie chart to a Mimic, you can access its Pie Chart Properties window to edit its settings.

To display the Pie Chart Properties window, either:

  • Double-click on the pie chart (with the Mimic displayed in Design mode)

or:

  • Right-click on the pie chart and select Properties from the context sensitive menu.

The Pie Chart Properties window contains two tabs:

  • General—The General tab contains some common settings for General tabs, including Name, Visible, Animations, Pick Action, ToolTip, and the Dynamic Position settings. For more information on these settings, see General Tab.

The General tab on the Pie Chart Properties window also contains these settings:

  • Key Position—Use the Key Position setting to define the location of the key in relation to the pie chart. Choose from:
  • None—There is no key for the pie chart.
  • Left—The key is shown to the left of the pie chart.
  • Right—The key is shown to the right of the pie chart.
  • Key Style—Use the Key Style settings to define what information is shown in the key. You can choose from:
  • Label Only—The key will only contain the label for each slice. The value and percentage are not shown.
  • Value Only—The key will only contain the value for each slice. The label and percentage are not shown.
  • Percentage Only—The key will only contain the percentage for each slice. The label and value are not shown.
  • Label and Value—The key will contain the label and value for each slice. The percentage is not shown.
  • Label and Percentage—The key will contain the label and percentage for each slice. The value is not shown.
  • Value and Percentage—The key will contain the value and percentage for each slice. The label is not shown.
  • Label, Value, and Percentage—The key will contain the label, value, and percentage for each slice.
    This key is shown to the right of the pie chart, and shows the Label, Value, and Percentage for each slice.

NOTE: You will only be able to see the effects of the Key Position and Key Style settings if there are pie chart animations in place. The pie chart needs to have animations for one or more slices, with animations for the Value, Color, and Label properties. For more information, see Animations.

  • Font—Use the Font tab settings to define the style, size, and positioning of the text that is shown in the key for the pie chart. The Font tab settings work in the same way as the settings on other Font tabs (see Font Tab).

NOTE: To remove a slice from a pie chart, you should set the value of the animation for the slice to 0 before you clear it (remove the slice). If you do not set the slice animation to 0, the pie chart will continue to show the slice, even after you have cleared the animation for the slice. This is because the pie chart will maintain the previous value of the slice.


Mimics Guide - Editing a Pipe (Editing Objects on a Mimic)

Editing a Pipe

When you have added a pipe object to a Mimic, you can access its Pipe Properties window to edit its settings.

To display the Pipe Properties window, either:

  • Double-click on the pipe (with the Mimic displayed in Design mode)

or:

  • Right-click on the pipe and select Properties from the context sensitive menu.

The Pipe Properties window contains two tabs:

  • General—The General tab contains some common settings for General tabs, including Name, Visible, Animations, Pick Action, ToolTip, and the Dynamic Position settings. For more information on these settings, see General Tab.
  • Fill—Use the Fill tab to define the color and shading settings for the background of the pipe. The Fill tab settings work in the same way as the settings on other Fill tabs (see Fill Tab).


Mimics Guide - Editing a Text Box (Editing Objects on a Mimic)

Editing a Text Box

When you have added a text box to a Mimic, you can access its Text Properties window to edit its settings.

To display the Text Properties window, either:

  • Double-click on the text box (with the Mimic displayed in Design mode)

or:

  • Right-click on the text box and select Properties from the context sensitive menu.

The Text Properties window has five tabs:

  • General—The General tab contains some common settings for General tabs, including Name, Visible, Animations, Pick Action, ToolTip, and the Dynamic Position settings. For more information on these settings, see General Tab.
  • Text—Use the Text tab to define the text that is to be shown in the text box. Simply type the required text into the text entry area.
  • Pen—Use the Pen tab to define the color and shading settings for the text that is shown in the text box. The Pen tab settings work in the same way as the settings on other Pen tabs (see Pen Tab).
  • Fill—Use the Fill tab to define the color and shading settings for the background of the text box. The Fill tab settings work in the same way as the settings on other Fill tabs (see Fill Tab).
  • Font—Use the Font tab settings to define the style, size, and positioning of the text that is shown in the text box. The Font tab settings work in the same way as the settings on other Font tabs (see Font Tab).


Mimics Guide - Editing a Group of Mimic Objects (Editing Objects on a Mimic)

Editing a Group of Mimic Objects

When you group a selection of objects on a Mimic, their individual configuration settings grouped on to a single Properties window. You can access the Properties window for a group of objects by:

  • Double-clicking on the group of objects (with the Mimic displayed in Design mode)

or:

  • Right-clicking on the group of objects and selecting Properties from the context sensitive menu.

The tabs on the Group Properties window vary according to the types of objects in the group. For information on each of the tabs, please refer to the section that describes the relevant type of Mimic object. For example, if you have a group that contains a pie chart, the Group Properties window will have a Pie Chart Font tab—for information on the settings on the Pie Chart Font tab, refer to the Font tab in the Editing a Pie Chart section.


Mimics Guide - Common Editing Settings for Mimic Objects (Editing Objects on a Mimic)

Common Editing Settings for Mimic Objects

This section explains the common properties settings for Mimics. The settings on the following tabs are available for a variety of Mimic objects:

  • General Tab
  • Fill Tab
  • Line Tab
  • Pen Tab
  • Font Tab.


Mimics Guide - General Tab (Editing Objects on a Mimic)

General Tab

Each Mimic object has a General tab on its Properties window.

The General tab contains some settings that are object specific - for example, the General tab for a button contains a Button section - and several common settings including:

  • Name—The Name field shows the name of the currently selected Mimic object. The name is a reference, such as P_21, that is used internally by ClearSCADA. To change the name, select the browse button next to the name field to display a pop-up window, then enter the new name in the New field.
  • Visible—Use the Visible check box to define whether the selected Mimic object can be seen on the Mimic. If you select the check box, the Mimic object can be seen; if you clear the Mimic check box, the Mimic object will not be shown on the Mimic.
  • Animations—Use the Animations button to access the Animations window. You need to use the Animations window to associate values in the database with properties of Mimic objects. For information on the Animations feature, see Animations.
  • Pick Action—Use the Pick Action button to access the Pick Action Wizard. You can use the Pick Action Wizard to associate the selected Mimic object with a pick action menu or individual pick action. For more information on the Pick Action Wizard, see Associating Mimic Objects with Pick Actions.
  • ToolTip—Each object on a Mimic can have a ToolTip (a brief description that is displayed in a box when the cursor is positioned over the Mimic object in Run Mode). ToolTips are useful for labelling objects on a Mimic.
    In Run mode, the ToolTip is displayed whenever you position the cursor over the Mimic object.

Use the ToolTip field to define the text that is shown on the ToolTip for the selected Mimic object. Simply enter the required text in the ToolTip field.

  • Polyline—Use the following settings to define the pick action settings for polylines:
  • Use Line Extents—Use this setting to control when a pick action menu is displayed for the object:
  • If you select the Use Line Extents check box, any pick action menu that you associate with the object will only be displayed when a user selects the outline of the object. The pick action menu will not be displayed when a user selects another part of the object, such as the inside of a rectangle.
  • If you clear the Use Line Extents check box, the pick action menu will be displayed when a user selects the outline or the inner part of the object.

The Use Line Extents feature is particularly useful with pipes and shapes that have no fill.

With the Use Line Extents check box clear, the pick action menu is displayed whenever a user selects the outline of the object or its interior, even if its Fill is set to None.
With the Use Line Extents check box selected, the pick action menu is only displayed when a user selects the outline of the object.

  • Rotation—You can use the Rotation settings to define the pivot point of the object and the angle of rotation. This is useful for testing the rotation of an object before setting up a rotation animation. For example, if you are unsure about the exact angle which the object needs to be rotated by, you can experiment with the Rotation settings before making a decision. Once you know the correct angle, you can define it in an Animation (see Animations).

You can use these settings to examine the effects of a rotation:

  • Pivot—Use the Pivot combo box to choose the anchor point for the rotation. The object will rotate from the selected side, corner, or center.
    Polygon is rotated from the Top Left corner with an Angle of 20°.

  • Angle—Use the Angle field to enter the angle of rotation. You can enter positive or negative values.

NOTE: When you have set the Pivot and Angle, close the Properties window and then switch the Mimic from Design mode into Run mode. The rotation only takes effect when the Mimic is displayed in Run mode.

  • Dynamic Sizing—You can use the Dynamic Sizing settings to define the type of resizing that will be applied to an object and the minimum size, maximum size, and current size of an object. This is useful for experimenting with sizes before using Animations to associate the size of an object with values in the database (see Animations).

You can use these settings to view the effects of a size alteration:

  • Direction—Use the Direction combo boxes to select the direction of resizing, for example, you can set an animated rectangle to have its fill start from the center and increase to the edges when a point’s value increases.

There are two Direction combo boxes, one for horizontal directions and one for vertical. The options that are available are: Left to Right, Right to Left, Center Horizontal (start from the center expaning left and right), Top to Bottom, Bottom to Top, Center Vertical (start from the center expanding up and down).

  • Min—Use the Min field to define the value that corresponds to the object's smallest size. Simply enter the required amount.
  • Max—Use the Max field to define the value that corresponds to the object's largest size. Enter the required amount.
  • Value—Use the Value field to define the object's current value. This sets the object to be a specific size in relation to the Min and Max limits you have defined. For example, if you enter a Value of 50 and the Min is 0 and the Max is 100, the object will be half of its maximum size (50 is midway in the range 0-100).

Enter the required amount.

The polygon is resized in a Left to Right direction and has a Value of 50. The width of the shape is 50% its maximum width as 50 is halfway between the specified 0 Min and 100 Max range.
The polygon is shown at full size. This is the size of the polygon when it has a Value of 100 and its Min setting is 0 and Max setting is 100.

  • Dynamic Position—You can use the Dynamic Position settings to define the positioning of an object. This is useful for experimenting with positioning before using Animations to associate the position of an object with values in the database (see Animations).

Positioning animations set an object to move along a defined path. The position of the object on the path varies according to values in the database. For example, a Mimic object could move between the top corners of a Mimic depending on the value of a point.

To see the effect of dynamic positioning, you need to define these settings:

  • Anchor—The Anchor setting allows you to specify which part of the Mimic object will be anchored to the path line. The 'anchored' part of the object stays in contact with the path line. For example, if the Anchor is set to Top, the object will move along the path line—the top of the object will remain on the pathline with the rest of the object being positioned underneath.
    Path line
    The top of the shape stays in contact with the path line as the Anchor position is set to Top.

  • Min—Use the Min field to define the value that corresponds to the start of the path line. Simply enter the required amount.
  • Max—Use the Max field to define the value that corresponds to the end of the path line. Enter the required amount.
  • Value—Use the Value field to define the object's current value. This sets the object to be at a specific location on the path line. The current position of the object is defined by its Value and is in relation to the Min and Max limits you have defined. For example, if you enter a Value of 50 and the Min is 0 and the Max is 100, the object will be half way along the path line (50 is midway in the range 0-100).

Enter the required amount.

Min value defines the start of the path line.
Max value defines the end of the path line.
Value defines the current position of the object on the path line in relation to the Min and Max values.


Mimics Guide - Fill Tab (Editing Objects on a Mimic)

Fill Tab

The Fill tab contains the settings for fill colors. These are the colors that are shown within an object's boundaries. For example, the following shape has its fill color settings set to be a solid red:

If you look closely, you will see that the outline of the shape is black. This is because the outline color is defined on the Line tab—the Fill tab settings only apply to the inner part of an object.

NOTE: For text boxes and buttons, the Fill tab settings apply to the background of the text box or button, not the text itself. The color of the text is defined on the Pen tab.

The Fill tab settings that are available vary according to the type of Mimic object you are editing. The possible Fill tab settings include:

  • Width—Use the Width spin-box to define the thickness of a line. This setting applies to pipe objects. When you increase the spin-box amount, the pipe becomes thicker; when you decrease the amount in the spin-box, the pipe becomes thinner.
  • Type—Use to choose the type of shading to be applied. There are several shading options, and the type of shading you choose will affect which settings are available in the Colors and Fill sections.

The types include:

  • None—No fill color is applied. This means that the object will appear to have a transparent fill. For example, a text box with its Type set to None will only have its outline and text visible.
  • Solid—The fill color is a single color with no shading effects.
  • Hatch—The fill color is a hatch pattern. The pattern consists of two colors that you can select in the Colors section. You can also change the style of hatch pattern by using the Pattern combo box in the Fill section.
  • Linear Gradient—The Linear Gradient option applies a two-color shading effect. One side of the fill is one color and the opposite side is the other color. The colors blend into each other in the middle of the fill, creating a 'bleed' effect.
    On this shape, the Linear Gradient option is used to create a 'bleed' effect—one side is dark blue and the other is white. Dark blue 'bleeds' into white from left to right.

You can define the two colors by using the Start and End buttons in the Colors section (see Using the Color Window).

You can change the position of the two colors by altering the Angle setting in the Fill section (see Fill Tab).

  • Pipe Gradient—The Pipe Gradient option applies a 3D shading effect that makes the fill appear cylindrical. This feature was specifically designed to be used as the shading effect on pipe drawings and is the shading effect you can see on any pipes that you draw using the Add Pipe tool.
    An ellipse and a pipe with Pipe Gradient shading.

As with the Linear Gradient option, the Pipe Gradient feature has two colors.

The Line color is the color of the highlight bar that is inside the fill. This bar acts as the reflection of the light source. You can move the position of the line by dragging it in the preview panel at the top-right of the Properties window.

You can also define its position by changing the Position setting, and change its direction by using the Direction setting. Both settings are in the Fill section (see Fill Tab).

The Bounds color is the color of the fill. You can change the Bounds and Line colors by using the color buttons in the Colors section (see Using the Color Window).

Radial Gradient—The Radial Gradient option applies an 'spherical' shading effect. Like the other Gradient types of shading, the Radial Gradient uses two colors—a Point color and a Bounds color.

This ellipse has a green Bounds color and a white Point color. The Point color can be positioned anywhere within the shape and creates a spherical shading effect.

The Point color is the color of the highlight within the fill and it acts as the reflection of a light source. You can move the position of the point by selecting it and then dragging it in the preview panel at the top right of the Properties window. You can also define its position by changing the X Position and Y Position settings in the Fill section (see Fill Tab).

The Bounds color is the color of the fill. You can change the Bounds and Point colors by using the color buttons in the Colors section (see Using the Color Window).

  • Flash—You can use the Flash section to apply a flashing effect to the Fill color.

The Flash section contains these settings:

  • Blink—Defines whether the flash effect is enabled.

If the Blink check box is selected, the fill area will flash on and off.

If the Blink check box is clear, the fill area will not flash on and off.

  • Mode—Use the Mode setting to define the speed of the flash effect and how many flash colors are used. The available modes are:
  • On/Off (Normal)—The fill color flashes on and off (visible then invisible) at the normal rate which is 1 second on, 1 second off.
  • On/Off (Fast)—The fill color flashes on and off at a faster than normal rate (half a second on, half a second off).
  • On/Off (Briefly On)—The fill color flashes on for half a second and off for 1 and a half seconds.
  • On/Off (Briefly Off)—The fill color flashes on for 1 and a half seconds and off for half a second.
  • Two Color (Normal)—The fill color flashes from one color to another color every second. You can select the two Flash colors by using the Flash buttons in the Colors section (see Using the Color Window).
  • Two Color (Fast)—The fill color flashes from one color to another color every half-second. You can select the two Flash colors by using the Flash buttons in the Colors section (see Using the Color Window).
  • Four Color—The fill flashes from one color to the next color (in a four-color sequence) every half second. This feature is useful for creating the illusion of movement. For example, if you choose a Linear Gradient type of shading and select four shades of blue as the Start, End, and Flash (x2) colors, you can create a flash effect that looks like flowing water.

The Start color flashes between the selected start color and the shades between it and the selected start Flash color. Similarly, the End color, flashes between the selected End color and the shades between the selected end Flash color.

For example, if the Start color is red and the Flash color is white, the fill will flash:

1. Red

2. Red-White

3. White-Red

4. White

You can define the Flash colors by using the Flash buttons in the Colors section (see Using the Color Window).

  • Offset—The flash Offset defines the sequence for color flashing effects.

Each set of flashing colors has a sequence. The sequence begins with the Start color and ends with the Flash color, with any other colors occurring in between. For example, for four color flashing, the sequence is:

1. Start color

2. Start color with some end color

3. Flash color with some start color

4. Flash color

Start Color is first (when Offset is 0)
Flash Color is last (when Offset is 0)
Colors between Start color and Flash color are mixtures of the two colors.
1
2
3
4

So, if the Start color is red and the Flash color is white, the sequence for a four-color flash is:

1. Red

2. Red with some white

3. White with some red

4. Red

By using the Offset setting, you can define where the Start color comes in the flashing sequence.

  • Select 0 to set the Start color to be the first color in a flashing sequence.
  • Select 1 to set the Start color to be the second color in a flashing sequence.
  • Select 2 to set the Start color to be the third color in a flashing sequence.
  • Select 3 to set the Start color to be the fourth color in a flashing sequence.

NOTE: For single color flashing effects, the Offset setting defines whether the flashing sequence begins with the Start color in view (on) or invisible (off).

  • Colors—You can use the Colors section to define the colors and shading:
  • Fill—The Fill color button is only available when you choose a Solid or Hatch type of shading. It defines the background color of the object, so if you have selected Solid the object will be the Fill color and if you selected Hatch, the object will have a pattern over the top of the Fill color.

To change the Fill color, you need to select the Fill color button. To do this, simply select the color shown next to the Fill field name.

When you select the color button, a color palette is displayed. You can set the color button to any of the colors on the palette, or you can select the ... option to create a custom color on the Color window (see Using the Color Window).

  • Hatch—Use the Hatch color button to define the color of the hatch pattern. This option is only available when you select a Hatch type of shading. You will also need to use the Fill color button to define the background color for the hatch pattern.
    Fill color is yellow
    (the background color)
    Hatch color is green
    (the pattern color)

As with the Fill color button (see above), when you select the Hatch color button you can choose a color from the palette or use the ... option to create a custom color (see Using the Color Window).

  • Start and End—The Start and End color buttons are only available when you choose a Linear Gradient type of shading.

The Start color is the color at one side of the object and the End color is the color at the opposite side of the object. The colors blend into each other in the middle of the object.

Start color is red
End color is yellow

As with the Fill color button (see above), when you select the Start or End color buttons, you can choose a color from the palette or use the ... option to create a custom color (see Using the Color Window).

  • Line and Bounds—The Line and Bounds settings are available when you set the shading type to Pipe Gradient.
  • Use the Line color button to define the color for the highlight that is shown within the fill area of the object.
  • Use the Bounds color button to define the color of the background of the fill area of the object.
    This rectangle has a Line color of yellow and a Bounds color of black.

As with the other color buttons, when you select the Line or Bounds color buttons, you can choose a color from the palette or use the ... option to create a custom color (see Using the Color Window).

  • Point and Bounds—The Point and Bounds color settings are available when you select the Radial Gradient type of shading.
  • Use the Point color button to define the color for the highlight that is shown within the fill area of the object.
  • Use the Bounds color button to define the color of the background of the fill area of the object.
    This rectangle has a Point color of white and a Bounds color of green.

  • Flash—Use the Flash color button(s) to define the alternate color when the flash effect is enabled (see the Flash settings, earlier in this section).

For single color effects, there is one Flash color button. The color will flash between the Fill color and the Flash color you select (the flash sequence may include shades between the two colors, depending on the type of flash you have set).

For multiple color effects, such as Linear Gradient shading, there is a Flash color button for each color in the effect. So for Linear Gradient shading, there is a Flash color for the Start color and a Flash color for the End color. One side of the object will alternate between the Start color and its Flash color and the other side of the object will alternate between the End color and its Flash color.

As with the other color buttons, when you select the Flash color button(s), you can choose a color from the palette or use the ... option to create a custom color (see Using the Color Window).

  • Center and Edge—The Center and Edge color buttons are only available for Pipe objects. They work in exactly the same way as the Line and Bounds color buttons for Pipe Gradient shading (described earlier in this section). Center works in the same way as Line and Edge works in the same way as Bounds.
  • % (Transparency)—The percentage spin-boxes next to each color button allow you to define the transparency of the color. You can set each color to have a minimum 0% transparency (solid) up to a maximum transparency of 100% transparency (invisible).
  • Fill—Use the following settings to define the color and shading:
  • Pattern—Use the Pattern combo box to choose the style of hatch for the object (the Pattern setting is only available if you have selected the Hatch type of shading). There are over 50 different styles available.

When you make a selection, you can see a preview of the style in the preview panel at the top right of the Properties window.

  • Angle—The Angle spin-box is only available when you select the Linear Gradient style of shading. You can use it to alter the position of the Start and End colors. For example, if you set the Angle to 45°, the Start color begins at the top left-hand side of the object and the End color is at the bottom-right hand corner of the object.
    Start color begins on the top-left hand side when the Angle is 45°
    End color begins on the bottom-right hand side when the Angle is 45°

  • Direction, Position, and Indent—These settings are only available when you set the style of shading to Pipe Gradient.

Use the Direction combo box to choose the direction of the pipe shading. There are several directions available, including the standard Horizontal and Vertical as well as shading for corners.

The flange shading styles allow you to create cylindrical shading effects that are wide at one end and narrow at the other.

An ellipse with Flange Down shading.

You can use the Position spin box to alter the location of the Line color. Simply increase or decrease the percentage as required. For vertical shading, the left hand side of the object begins at 0% and the right-hand side is 100%. For horizontal shading, the top of the object is 0% and the bottom is 100%

Alternatively, you can select the Line color in the preview panel and drag it to the required position.

When you select a Flange direction, an additional spin-box is displayed—Indent. Use the Indent spin-box to define the position of the bottom points of the flange shading. Decreasing the percentage will make the bottom of the flange shading wider (and so it will fill up more of the shape), whereas increasing the percentage will cause the bottom of the flanges to become smaller and more pointed.

When you make a selection, you can see a preview of the style in the preview panel at the top right of the Properties window.

  • X Position and Y Position—The X Position and Y Position spin-boxes are available for the Radial Gradient shading effects and some Pipe Gradient shading effects. You can use these spin-boxes to define the vertical and horizontal position of the Line or Point color (as appropriate).
  • The X Position represents the horizontal position. It begins at 0% on the left-hand side and goes to 100% on the right-hand side.
  • The Y Position represents the vertical position. It begins at 0% at the top side and ends at 100% at the bottom side.
    The X Position sets the horizontal position of the Line or Point and the Y Position sets the vertical position.

Simply increase or decrease the percentages to change the position of the Line or Point color as required. Alternatively, you can select the Line or Point in the preview panel and drag it to the required location (the X and Y Positions will be altered automatically).

When you make a selection, you can see a preview of the style in the preview panel at the top right of the Properties window.


Mimics Guide - Line Tab (Editing Objects on a Mimic)

Line Tab

The Line tab contains the settings you need to define the appearance of lines and outlines (the lines around shapes).

  • Type—You can choose between two types of line:
  • None—The outline of the selected object on the Mimic is not shown.
  • Solid—The outline of selected object on the Mimic is a visible line of a single color.
  • Flash—The Flash section contains a Blink check box, a Mode combo box, and an Offset combo box. These settings work in exactly the same way as the Flash settings on the Fill tab (see Fill Tab), except that they apply to the outline of an object rather than its fill.
  • Colors—Use the Colors section to define the color of the outline or line.
  • Line—Use the Line color button to define the color of the line or outline. As with other color buttons, when you select the color button, a color palette is displayed. You can choose a color from the palette, or you can select the ... option to create a custom color (see Using the Color Window).
  • % (Transparency)—Use the percentage spin-box next to the Line color button to define the transparency of the color. You can set the color to have a minimum 0% transparency (solid) up to a maximum transparency of 100% transparency (invisible).
  • Line—Use the settings in the Line section to define the appearance of the line:
  • Width—Use the Width spin-box to increase or decrease the thickness of the line or outline. The width is measured in points (the same measurement is used for font sizes when adding text).
  • Style—Use the three Style combo boxes to choose the type of line or outline. The left-hand combo box allows you to choose from a variety of single and double line styles, and the middle combo box allows you to choose continuous or dashed style lines. If you select a dashed line, you can use the third combo box to choose the types of dashes (squared, rounded, or mitred).
  • Joins—Use the Joins combo box to define the appearance of corners (joins) on the outline. You can choose from:
  • Mitred—The joins are pointed.
  • Rounded—The joins are curved.
  • Bevelled—The joins are angled.
  • Mitre Limit—Use to define the limit for mitred joins. The limit is measured in points.

Acute angled Mitred joins can extend beyond the normal boundaries of a line or shape. This can make certain shapes and lines seem inappropriately sized, especially when the line width is set to be thick. By defining a mitre limit, you can restrict the mitred joins so that they can only extend so far. At the position where the mitred join reaches the limit, ClearSCADA will set the join to be bevelled.

The mitred joins extend beyond the boundaries of the shape and have no Mitre Limit set.
The mitred joins have a Mitre Limit of 2.00 pt and so the extensions are bevelled at 2.00 pt outside the shape's normal boundary.

  • Arrowheads—Use the Arrowheads section to define the appearance of each end of a line:
  • Start—The Start of the line is the left-hand end or top end of the line. Choose the required style of arrowhead from the Start combo box list, and the size of arrowhead from the combo box that is shown to the right of the Start combo box.
  • End—The End of the line is the right-hand end or bottom end of the line. Choose the required style of arrowhead from the End combo box list, and the size of arrowhead from the combo box that is shown to the right of the End combo box.
    Define the style of arrowhead for the start of the line with this combo box.
    Define the size of the arrowhead for the start of the line with this combo box.
    Use this combo box to set the style of arrowhead for the end of the line.
    Use this combo box to set the size of the arrowhead for the end of the line.


Mimics Guide - Pen Tab (Editing Objects on a Mimic)

Pen Tab

The Pen tab is available on Properties windows that relate to objects with text, such as text boxes and buttons. It contains the settings that allow you to define the shading and colors of the text.

The Pen tab contains these settings:

  • Type—You can choose between six types of shading:
  • None
  • Solid
  • Hatch
  • Linear Gradient
  • Pipe Gradient
  • Radial Gradient

These shading types work in exactly the same way as the shading types for the Fill (see Fill Tab) except that they apply to the text.

  • Flash—The Flash section contains a Blink check box, a Mode combo box, and an Offset combo box. These settings work in exactly the same way as the Flash settings on the Fill tab (see Fill Tab), except that they apply to the text in a text box or on a button rather than the fill.
  • Colors—Use the color buttons in the Colors section to define the colors that are to be used for the shading. The color buttons work in the same way as the color buttons on the Fill tab (see Fill Tab), except that they apply to the shading for the text rather than the fill.
  • % Transparency—Use the percentage spin-box(es) next to the color buttons to define the transparency of the color(s). You can set the color to have a minimum 0% transparency (solid) up to a maximum transparency of 100% transparency (invisible).


Mimics Guide - Font Tab (Editing Objects on a Mimic)

Font Tab

The Font tab is available for Mimic objects that have text settings, including text boxes and embedded Graphs (there are three Font tabs on embedded Graphs—Main Font, Title Font, and Label Font).

You can use the Font tab settings to define the appearance of text.

Each Font tab contains these settings:

  • Family—Use the Family combo box to choose the style of font. There are many font styles available. To preview your choice of font, use the Family combo box to select the required font, then move the Properties window so that you can see the text on the Mimic. The text will be shown in the font you have chosen.
  • Height—Use the Height spin-box to set the size of the text. Simply increase the number to make the text bigger or decrease the number to reduce the text size. The text size is measured in points.
  • Orientation—This field is only available for text boxes and it allows you to change the direction of the text. You can set the text to be:
  • Left to Right—The text will start at the left-hand side of the text box and will flow to the right-hand side.
  • Top to Bottom—The text will start at the top of the text box and will flow downwards to the bottom.
  • Bottom to Top—The text will start at the bottom of the text box and will flow upwards to the top.
    Left to right orientation
    Top to Bottom orientation
    Bottom to Top orientation

  • Format—Allows you to define the format for the text. This is especially useful for controlling the display of dates, times, values etc.

When you select the Format button, the Text Format window is displayed.

You can use the Text Format window to define the format for the following categories of text:

  • Number—Allows you to define the number of decimal places, trailing zeros, etc.
  • Date/Time—Allows you to define the format of date and time entries.
  • Interval—Use to define the format of time periods.
  • Boolean—Use to define the format of Boolean (0 or 1/True or False) values.
  • Custom—Use to define a custom format i.e. a format that is different to any of the default categories.

To alter the settings for a category, select a category in the left-hand field, then use the settings that are shown on the right-hand side of the window to define the required format. For detailed information on defining Text Formats, see see Defining the Format of Displayed Values in the ClearSCADA Core Configuration Guide.

  • Style—Use to define whether any special characteristics are applied to the text. Typically, the characteristics are used to create emphasis.

You can choose from:

  • Bold—Select the check box to embolden the text (make it darker and slightly larger) or clear it to use normal text.
  • Italic—Select the check box to italicize the text (make the text thinner and lean to one side) or clear it to use normal text.
  • Underline—Select the check box to apply a line under the text or clear it to use normal text.
  • Strikeout—Select the check box to apply a line through the middle of the text or clear it to use normal text.
  • Alignment—Use the option buttons to define the location of the text within the text box (this section only applies to text boxes). You can choose from:
  • Left Center Right—The option buttons on this row apply to the vertical position of the text. If you select Left, the text is positioned on the left of the text box. Selecting Center places the text in the middle, and selecting Right places the text on the right-hand side of the text box.
  • Top Center Bottom—The option buttons on this row apply to the horizontal position of the text. If you select Top, the text is positioned near the top edge of the text box. Selecting Center places the text in the middle, and selecting Bottom places the text near the bottom edge of the text box.

You can select one option from each row.


Mimics Guide - Using the Color Window (Editing Objects on a Mimic)

Using the Color Window

The Color window is displayed whenever you choose the custom option (...) on a color button's palette. You can use the Color window to add a custom color to the color palette.

Basic Colors
Color Panel
Shade Bar
Custom Colors
Color Preview
Hue, Sat, Lum, Red, Green, and Blue settings

To create a custom color:

  1. Select a blank check box in the Custom Colors section (bottom left-hand side of the window). If there are no blank check boxes, you will have to overwrite an existing custom color—select the check box for the color you want to replace.
  2. In the Basic Colors section, select the color that is closest to the color that you want to create. For example, if you want to create a light shade of brown, select a basic brown color.

When you select a basic color, its values are shown in the Hue, Sat, Lum, Red, Green, and Blue fields. The cursor on the color panel is positioned on the selected color automatically, and the shade bar shows different shades of the selected color.

  3. Adjust the color by:
  • Entering new values in the Hue, Sat, and Lum fields or the Red, Green, and Blue fields. These fields define the hue, saturation, luminescence, and the amount of red, green, and blue in the color respectively.
  • Selecting a different color in the Color Panel
  • Moving the arrow next to the Shade Bar to select a lighter or darker shade of the selected color.

You can see the color you have created in the Color Preview box.

  4. When you have created the required color, select the Add to Custom Colors button. The custom color is added to the Custom Colors section.
  5. Select the check box for the custom color that you want to use.
  6. Select the OK button to confirm you selection and close the Color window. The custom color will now be used as the color for the relevant color button.
    This pipe uses custom colors for its shading—the Center color is a pale yellow and the Edge color is a light brown.


Mimics Guide - Views

Views

Views are specific areas of a Mimic that are shown at a defined level of magnification. They are used to provide easy access to specific parts of a Mimic. For example, you can create a View that shows a magnified top left-hand corner of a Mimic.

The main advantage of using Views is that operators and engineers can gain fast access to specific parts of a Mimic by selecting a View from a list. Hyperlinks can also be associated with a specific View so that ' chained' Mimics can link to specific areas on other Mimics. For example, a Mimic containing an overview of a site could contain a hyperlink to a View of a particular part of plant on another Mimic.

This View shows an overview of the entire Mimic
This View shows a magnified part of the Mimic, in this case, a close-up of a valve.

This section explains:

  • Creating a View
  • Editing a View
  • Removing a View.

For information on accessing different Views, see Switching Between Views on a Mimic.


Mimics Guide - Creating a View (Views)

Creating a View

To create a View:

  1. Display the Mimic that contains the area to be included in the View. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Use the magnification tools to zoom in on the area that is to be shown in the View (see Magnifying a Mimic (Zooming)).
  3. Select the Edit menu.
  4. Select the Views option to display the Views window.
  5. Select the Add button to add a new View to the list. The View is selected automatically, ready for you to define its name. The View already has the X, Y, W, and H settings (X and Y co-ordinates for the section of the Mimic and width and height settings for the size of the View) for the area of the Mimic that you magnified in step 2.
  6. Enter a suitable name for the View, then press the Enter key or select another part of the interface to confirm the selection.
  7. Select the Close button.
  8. Repeat this procedure for each View that you require.

You can change the View settings by using the Edit feature (see Editing a View).

NOTE: Only users with the Configure permission can create Views.


Mimics Guide - Editing a View (Views)

Editing a View

To change the positioning or magnification of an existing View:

  1. Display the Mimic that contains the View you want to edit. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Edit menu.
  3. Select the Views option to display the Views window.
  4. Select the View you want to edit from the Views list, then select the Properties button.
    The Edit View window is displayed.
  5. Overwrite the Name entry as required.
  6. Change the positioning of the View by altering the co-ordinates in the X and Y fields. X is the positioning from left to right and Y is the positioning from top to bottom.
  7. Change the level of magnification by altering the W and H settings. W is the width setting and H is the Height setting. Increasing the numbers reduces the level of magnification; reducing the numbers increases the level of magnification.
  8. Select the OK button to confirm the settings and close the Edit View window.

Alternatively, you may find it easier to create a new View with the required settings then remove the existing View (see Removing a View).

NOTE: Only users with the Configure permission can edit Views.


Mimics Guide - Removing a View (Views)

Removing a View

To remove a View that is no longer required:

  1. Display the Mimic that contains View that you want to remove. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Edit menu.
  3. Select the Views option to display the Views window.
  4. Select the View you want to edit from the Views list, then select the Remove button.

NOTE: Only users with the Configure permission can remove Views.


Mimics Guide - Setting a View as the Default View (Views)

Setting a View as the Default View

When a Mimic is displayed in Run mode, it is displayed at the level of magnification that is defined for the default View. If there is no default View in place, the Mimic is displayed at full size.

You can use the Edit View window to specify which of the Mimic's Views is to be used as the default View. (This is optional—you can leave the Mimic to be displayed at full size if you wish).

To define a View as the Default View:

  1. Display the Mimic that contains the View you want to set as the default View. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Edit menu.
  3. Select the Views option to display the Views window.
  4. In the list on the Views window, select the View that is to be the default View.
  5. Select the Set Default button.
    The selected View is now the default View. When the Mimic is displayed in Run mode, it will be shown at the level of magnification defined for the default View. This is also true if the Mimic is displayed as the result of a hyperlink (unless the configuration of the hyperlink defines that a different View is shown instead of the default View).

To return the Mimic to having no default View:

  1. Display the Mimic that contains the View you want to cancel as the default View. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Edit menu.
  3. Select the Views option to display the Views window.
  4. In the list on the Views window, select the View that is the current default View.
  5. Select the Clear Default button.
    The Mimic is reset to have no default View. You can leave the Mimic without a default View or use the Set Default button to apply the default View status to another View as required.

Further Information

Creating a Hyperlink to a Mimic Shown at a Specific Level of Magnification.


Mimics Guide - Layers

Layers

You can divide a Mimic into several layers, with each layer containing different objects. This is useful when you need to hide or show groups of Mimic objects at specific levels of magnification.

The layers feature is often used on Mimics that represent maps, where the default layer shows little geographical detail, but further Layers show place names and location details, such as sites and equipment. By using layers, you can control the visibility (and availability) of objects on the Mimic.

Layer 1 shows little detail.
Layer 2 shows more detail.
Layer 3 shows much more detail.

You can set each layer to be visible or hidden when the Mimic is displayed at a specified level of magnification (or within a specified range of magnification). For example, an overview Mimic could show the basic overview of a site at the default level of magnification, but layers containing additional information about specific plant could be made visible when a user 'Zooms In' on the Mimic.

The visibility of layers can also be controlled by animation expressions. This means that you can animate a layer so that it is only visible when a value in the registry changes.

This section explains how to configure layers for your Mimics. It explains how to:

  • Display the Layers Window
  • Add a Layer
  • Edit the Layer Settings
  • Remove a Layer
  • Order the Layers.

For information on navigating between the layers in Run mode, see Operating a Mimic.


Mimics Guide - Display the Layers Window (Layers)

Display the Layers Window

To add, remove, or reorder the layers for a Mimic, you need to access the Layers window.

To access the Layers window:

  1. Display the Mimic you want to edit in Design mode.
  2. Either:
  • Select the Layers button on the Mimic Editing toolbar

Or:

  • Select the Edit menu, then select the Layers option.

Or:

  • Access the Mimic Properties window, then select the Layers button on the Mimic tab.

The Layers window contains a list of the layers that are already set up for the Mimic (if any). Information about the layers is shown in the following categories:

  • Name—The name that has been defined for the layer.
  • Enabled—Indicates whether the layer is active or inactive. Only active layers are visible on a Mimic. (Yes means active; No means inactive).
  • Operator Enabled—Indicates whether a context sensitive menu that can be used to turn layers on/off is made available in Run Mode. (Yes means there is a context sensitive menu; No means there is no context sensitive menu).
  • Fixed—Indicates whether the layer can be magnified. The Fixed feature is designed for use with layers that contain objects that need to be visible at the defined level of magnification, for example, a menu banner or a company logo.

When the Fixed feature is enabled (indicated by Yes), the layer cannot be magnified, although other layers may be magnified. When the Fixed feature is disabled (indicated by No), the layer can be magnified as required.

  • Visibility—Shows the range of magnification in which the layer is visible. For example, if a layer has Visibility of 120%-200% it will only be visible when the Mimic is magnified between 120% and 200%. When the Mimic is shown at less than 120% or more than 200%, the layer will not be shown.

The Layers window also contains the following buttons:

  • Add—Use to Add a Layer
  • Edit—Use to Edit the Layer Settings
  • Remove—Use to Remove a Layer
  • Set Default—Use to set the selected layer to be the layer that is shown when the Mimic is first displayed.
  • Move Up—Use to Order the Layers
  • Move Down—Use to Order the Layers
  • Close—Use to close the Layers window.


Mimics Guide - Add a Layer (Layers)

Add a Layer

To create a Layer:

  1. Display the Layers window (see Display the Layers Window).
  2. Select the Add button.
    A new layer is added to the list. It is selected automatically, ready for you to define its name.
  3. Type a suitable name for the layer, then press the enter key or select another part of the interface to confirm the entry.

The new layer has the default layer settings. You can change these settings as required (see Edit the Layer Settings).


Mimics Guide - Edit the Layer Settings (Layers)

Edit the Layer Settings

You can edit the settings for any layer that is listed on the Layers window.

To edit the settings for a layer:

  1. Display the Layers window (see Display the Layers Window).
  2. Select the layer that you want to edit by clicking on it in the list of layers.
  3. Select the Edit button to display the Layer Properties window.
  4. Use the Layer Properties window to edit the layer:
  • Use the Name field to alter or overwrite the existing name. Select the field and type in the required alterations.
  • Use the Enabled check box to define whether the layer is active (visible on the Mimic) or inactive (invisible on the Mimic). Select the check box to activate the layer or clear the check box to deactivate it.
  • Use the Operator Controlled check box to define whether the layer can be turned on or off by operators.

If you select this check box, operators will be able to access a context sensitive menu on the Mimic that allows them to turn the layer on and off.

If you clear the check box, operators will not be able to control whether the layer is displayed.

  • Use the Fixed Layer check box to define whether the layer can be magnified. The Fixed Layer feature is designed for use with layers that contain objects that need to be visible at the defined level of magnification, for example, a menu banner or a company logo.

When the Fixed Layer check box is selected, the layer cannot be magnified. When the Fixed Layer check box is clear, the layer can be magnified as required.

  • Use the Visibility settings to define the range of magnification at which the layer is visible. You can also use the Expression setting to associate the layer's visibility with a value in the database or registry.
  • Between %—Use the 2 spin boxes to set the range of magnification in which the layer can be seen. For example, if you set the left-hand side spin-box to 50% and the right-hand side spin-box to 90% the layer will only be shown when the Mimic is displayed at 50% magnification or above up to 90% magnification.

The layer visibility settings are particularly useful on Mimics that use layers to contain different levels of detail. For example, a Mimic could be set up to have layers that show a geographical location and detailed information about a site. At the lowest level of magnification, the layer with the least amount of information is shown, such as an overview of an area. As the user zooms in on the area, less of the area is shown but more details are revealed such as buildings etc.

  • Expression—You can use the Expression field to enter a ViewX expression that associates the visibility of the layer with a value. For example, you can set a layer to be visible only when a selected point is in a defined state.

Type in an expression or use the browse button to select a Tag.

The Expression feature is normally used when setting up Local Variables (Registry Key Settings).

  5. Select the OK button to confirm the settings and close the Layer Properties window.


Mimics Guide - Remove a Layer (Layers)

Remove a Layer

To delete any unwanted or unused layers:

  1. Display the Layers window (see Display the Layers Window).
  2. Select the layer that you want to remove by clicking on it in the list of layers.
  3. Select the Remove button.


Mimics Guide - Order the Layers (Layers)

Order the Layers

You can use the Layers window to change the order of the layers on your Mimic. This is useful when the order of layers has not been configured in order, or when you need a layer to be visible but it is obscured by another layer.

If your Mimic has multiple layers, they are listed on the Layers window. The list indicates the order of the layers—the layer are ordered top to bottom, with the bottom layer being the lowest layer (the other layers are placed on top of the bottom layer in order, with no layers being placed on the top layer).

Layer at the top of the list is placed above the other layers
Layer at the bottom of the list is placed below the other layers.
Layers are listed in descending order. For example, the Ops Sites layer is beneath the Navigator, Key Site, and Rainfall Sites layers but above the Title bar, Rivers, Catchment, Map, and New Layer layers.

NOTE: Pick action menus are selectable between layers. For example, if a layer named Map has a text box with a pick action menu, and another layer is positioned over the Map layer, operators will still be able to access the pick action menu by selecting the area that covers the text box. However, the pick action menu on the Map layer is unavailable if the area that covers the text box has its own pick action menu.

To change the order of layers on a Mimic:

  1. Display the Layers window (see Display the Layers Window).
  2. Select the layer that you want to move in the layers order.
  3. Select one of the following buttons:
  • Move Up—To move the layer up one position in the layer order.
  • Move Down—To move the layer down one position in the layer order.


Mimics Guide - Local Variables (Registry Key Settings)

Local Variables (Registry Key Settings)

Local Variables are registry settings that allow Mimic display features to be altered without affecting the display on other PCs. For example, an operator can choose to hide a specific part of a Mimic—the Mimic object is only hidden on that operator's PC. Other PCs that are displaying the same Mimic are not affected by the operator's action.

In this section, we explain two common uses for local variables and registry settings:

  • To allow operators to display different layers at the click of a button (see Using Registry Settings to Control the Visibility of Layers on a Mimic)
  • To allow operators to apply different filters to an embedded list at the click of a button (see Using Registry Settings to Apply different Filters to an Embedded List).

These are just two possible uses for registry settings. Users with in-depth experience and knowledge of ViewX expressions will be able to use registry settings for many other purposes.

For more information, see Welcome to the Guide to Expressions in the ClearSCADA Guide to Expressions.


Mimics Guide - Using Registry Settings to Control the Visibility of Layers on a Mimic (Local Variables (Registry Key Settings))

Using Registry Settings to Control the Visibility of Layers on a Mimic

One of the common uses for registry settings is to control the visibility of layers on a Mimic. This is particularly useful on Mimics that contain maps, where each layer has a different level of detail. For example, the top layer could provide a simple overview of an area, whereas lower layers could reveal geographical features such as rivers, roads, sites etc.

By using a registry pick action, you can create a Mimic that has a selectable button (or another type of object) that toggles a layer's visibility on and off. The toggle is only applied to the local machine, so that other users viewing the same Mimic are not shown the layer changes.

Selecting the 'Show Rivers' object writes a value to a registry key. If the value in the registry key is 0, the layer containing the rivers is visible; if the value in the registry key is 1, the layer containing the rivers is invisible.

Another use of registry settings is to switch between filter settings for an embedded list, so when the registry setting is true one set of filters is applied, and when the registry setting is false another set of filters are applied (the filters need to be defined in animations for the embedded list, and the animations also need to use an IF statement to reference the registry settings).

Usually, the format for the registry expression is:

REGISTRY ('<registry setting name>', 0) = 1

Where <registry setting name> is the name you allocate to the registry setting (do not enter the angle brackets < >). This means that the registry setting is true when it has a value of 0 and false when it has a value of 1. You can reference the registry setting name in your expressions, for example, you can set a layer to be visible when the registry setting is 0 and invisible when the registry setting is 1.

To set up a local variable that allows a layer's visibility to be toggled on and off at the click of a button:

  1. Display the Layer Properties window (see Edit the Layer Settings) for the layer that you want to set up to use the local variable.
  2. In the Expression field, enter the expression that defines the behavior that you require. The expression should take the format:
REGISTRY ('<registry key name>', 0) = 1

For example:

REGISTRY ('ShowLayer', 0) = 1

  3. Select the OK button to confirm the layer configuration.

Now that you have defined the registry setting, you need to create a selectable object that, when selected, will change the registry setting (and therefore will toggle the layer's visibility).

  4. Add a Mimic object that will act as a display button. When selected, the object will toggle the layer's visibility on and off. You can use any type of shape, line, or button for the object. The object you create needs to be visible on each of the layers—we recommend that you create a separate layer for the object and set that layer to be the top layer.
  5. Edit the object so that it has a suitable appearance. For more information, see the section on editing the object, for example, see Editing a Button.
  6. On the General tab of the object's Properties window, select the Animations button.
    The Animations window is displayed.

If you are using a latched button to set the registry value, proceed to step 17.

If you are using an unlatched button or another type of object such as a line or shape to set the registry value, proceed to step 7.

  7. Double-click on the PickParam property to display the Expression window. The Pick Param property associates an animation with the pick action feature of an object.
  8. Enter the following expression:
'<registry key name>( ' + IIF( REGISTRY( '<registry key name', 0 ) = 0, '1', '0' ) + ')'

Where <registry key name> is the name of the registry to which a value is written when the button or object is selected. The registry key name has to be identical to the name of the registry key that you specified in the configuration for the layer. Do not enter the angle brackets < >.

For example:

'ShowLayer( ' + IIF( REGISTRY( 'ShowLayer', 0 ) = 0, '1', '0' ) + ')'

The expression instructs the system to write a 0 value to the registry when the existing registry setting is 1, and to write a 1 value to the registry when the existing setting is 0. This means that the button or object will toggle the layer visibility on and off when selected.

  9. Select the OK button to confirm the expression.
  10. On the Animations window, double-click on the PickType property to display its Expression window.
  11. Enter the number 8 as the expression. This informs the system that the object's pick action feature is to be used as a registry pick action (8 represents the registry type of pick action. For more information, see Pick Action Animations for Mimic Objects).
  12. Select the OK button to confirm the expression. Proceed to step 29.

NOTE: As an alternative to steps 10 to 12 inclusive, you can select the Pick Action button on the General tab of the object's Properties window. This displays the Pick Action Configuration Wizard—you will need to select the Registry option on the Pick Action Configuration Wizard then proceed through the various stages of the pick action configuration. You only need to set the object to have a Registry pick action as the other settings are provided as part of the expression for the PickParam animation.

  13. Double-click on the Latched property to display the Expression window. The Latched property represents the button when it is pressed down.
  14. Enter the following expression:
REGISTRY ('<registry key name>', 0) = 1

Where <registry key name> is the name you are using for the registry to which a value will be written. Do not enter the angle brackets. This expression is identical to the expression that you used for the layer.

  15. Select the OK button to confirm the expression.
  16. Close the Animations window.
  17. Access the Button Properties window for the latched button (see Editing a Button).
  18. On the General tab, select the Pick Action button to display the Pick Action Wizard.
  19. Select the Registry option button to set the button to write a value to the registry when selected.
  20. Select the Next button to proceed to the next step (Registry Configuration Button Down).
  21. In the top field, enter the name of the registry key to which a value is written when the button is pressed down. The registry key name has to match the name of the registry key that you defined in the expressions for the layer and the Latched animation property.
  22. Set the Key Type combo box to Number if the value that is written is a number, or set it to String if the value contains letters.
  23. In the Value field, enter the value that is written to the registry when the button is pressed down.
  24. Select the Next button to proceed to the next step (Registry Configuration Button Up.
  25. Repeat steps 21-23 inclusive, only this time the settings that you define will apply to the button when it is up i.e. not pressed down.
  26. Select the Next button to proceed to the next step.
  27. Enter a Pick Action Comment if required, then select the Next button.
  28. Select the Finish button to end the pick action configuration.
  29. View the Mimic in Run Mode and select the Mimic object (button, line, shape etc.) to switch the relevant layer's visibility on and off. If the layer does not toggle between being visible and invisible, trace your steps through this section and check that you have followed each step correctly.


Mimics Guide - Using Registry Settings to Apply different Filters to an Embedded List (Local Variables (Registry Key Settings))

Using Registry Settings to Apply different Filters to an Embedded List

You can use registry settings to apply different filters to an embedded list on a Mimic.

By using a registry pick action, you can create a Mimic that has a selectable button (or another type of object) that toggles between 2 sets of filters. The toggle is only applied to the local machine, so that other users viewing the same Mimic are not shown the filter changes.

Selecting this button writes a value to the registry key. The value that is written defines which database class the embedded list should use in its filter, in this case, it uses the CRealFLOModbusOS class, so that the embedded list shows the RealFLO PSTN outstations only.
Selecting this button writes a value to the registry key. The value that is written defines which database class the embedded list should use in its filter, in this case, it uses the CGenericModbusOS class, so that the embedded list shows the SCADAPack Modbus direct outstations only.

To set up a local variable that allows different filters to be applied to an embedded list at the click of a button:

  1. Embed a List on the Mimic (see Embed a Queries List on a Mimic).
  2. Animate the Sql property of the embedded list:
  1. Display the Embedded List Properties window (see Editing an Embedded Query List).
  2. Select the General tab.
  3. Select the Animations button to display the Animations window.
  4. Select the Sql property.
  5. Select the Edit button to display the Expression window.
  6. Enter an expression that defines the query that will be applied and define the registry name and value. The format is:

'SELECT Id, <field>, <field> FROM' + REGISTRY("<registry key name>", "<database class>")

Where SELECT defines the start of the query, <field> is the name of a field that is to be included in the query (and returned by the list). Each field has to be separated by a comma. FROM instructs the query to retrieve the defined fields from a specific part of the database. + REGISTRY instructs the system to apply the query to the database class that is named in the registry (the value in the registry will be the name of a database class). <registry key name> is the name you allocate to the registry key that will contain the value that is used to identify the database class and <database class> is the name of the database class that is used if there is no value in the registry key. In each case, do not enter the angle brackets < >.

For example:

'SELECT Id, FullName FROM ' + REGISTRY( "outstation", "CGenericModbusOS" )

Where 'SELECT Id, FullName FROM' defines the types of values that are being requested in the query ) Id and FullName. + REGISTRY ("outstation", "CGenericModbusOS") instructs the embedded list to use the value in the "outstation" registry key to identify the database class to which the query is applied. If there is no value in the registry key, it will use the default registry key setting of 'CGenericModbusOS'.

  3. Select the OK button to confirm the expression entry and close the Expression window.
  4. Close the Animations window.

Now that you have defined the registry setting and filter, you need to create a selectable object that, when selected, will change the registry setting (and therefore will cause the embedded list to use a different filter).

  5. Add a Mimic object that will act as a display button. When the object is selected, a different filter will be applied to the embedded list. You can use any type of shape, line, or button.
  6. Edit the object so that it has a suitable appearance. For more information, refer to the Edit section for the relevant type of object, for example, if you are editing a button refer to Editing a Button.
  7. On the General tab of the object's Properties window, select the Pick Action button. This displays the Pick Action Configuration Wizard.
  8. On the first 'page' of the Wizard, select the Registry option button. This instructs the system that the object's pick action menu is to write a value to the registry.
  9. Select the Next button to proceed to the next 'page' of the Pick Action Configuration Wizard.
  10. In the top field, enter the name of the registry key to which a value is written when the object is selected. The registry key name has to match the name of the registry key that you defined in the expression for the embedded list's Sql animation.
  11. Set the Key Type combo box to String. The String setting is required as the value that is written to the registry key when the Mimic object is selected contains text (the value defines a class in the database).
  12. In the Value field, enter the value that is written to the registry when the mimic object is selected. The value needs to be the name of a database class—the name that you enter is the class to which the SQL query for the embedded list will be applied. The name has to be identical to the class name. You can see the available classes by using the ClearSCADA Database Schema (see Welcome to the Guide to the Database in the ClearSCADA Database Guide).
  13. Select the Next button to proceed to the next step.
  14. Enter a Pick Action Comment if required, then select the Next button.
  15. Select the Finish button to end the pick action configuration.
  16. View the Mimic in Run Mode and select the Mimic object (button, line, shape etc.). You will see that when you select the button, a different filter is applied to the embedded list.

You can use the principles you have used in this procedure to create more selectable objects that apply different filters to the embedded list as required.


Mimics Guide - Associating Mimic Objects with Pick Actions

Associating Mimic Objects with Pick Actions

You can associate any object on a Mimic with a pick action menu (a context sensitive menu that provides access to specific options).

Pick action menu is shown when a suitable Mimic object is selected. You can configure any Mimic object to provide access to a pick action menu.

There are several types of pick action menu available, including:

  • Object Menu—Associate a Mimic object with the pick action menu of an object in the database, for example, associate a button with the pick action menu of a database point. (see Creating an Object Menu Pick Action).
  • Hyperlink—Associate a Mimic object with another display. When the Mimic object is selected, another display is shown. For more information, see Hyperlinks.
  • Method—Associate a Mimic object with a specific pick action. When the Mimic object is selected, a specific method is performed. For example, if you associate a shape with the Override action, the Override method will be applied when a user selects the shape. You can choose to set the method to apply a specific value, or you can leave the choice of value up to the user. (see Creating a Method Pick Action).
  • Script—Associate a Mimic object with a script. When the Mimic object is selected, a script is executed (see Associate a Mimic Script with a Script Pick Action in the ClearSCADA Guide to Scripting).
  • Registry—Associate a Mimic object with a registry setting. When the Mimic object is selected, a value is written to the registry. The value in the registry can be used as a condition for other settings, for example, the visibility of a layer can be dependent on the value in the registry (see Creating a Registry Pick Action).
  • ViewX Command—Associate a Mimic object with a ViewX command (a ViewX command is the equivalent of a ViewX menu or toolbar option). When the Mimic object is selected, the relevant ViewX command is performed. (see Creating a ViewX Command Pick Action).
  • System Command—Associate a Mimic object with a system command (a system command is a Windows command, such as running another program). When the Mimic object is selected, the relevant system command is performed. (see Creating a System Command Pick Action).
  • Menu—Associate a Mimic object with a custom pick action menu. When the Mimic object is selected, a custom pick action menu is displayed. You can name and configure the menus and menu options as required. (see Creating a Menu Pick Action).

You can set up any of these pick action menus. ClearSCADA includes a Pick Action Configuration Wizard which you can use to configure pick actions. The Pick Action Configuration Wizard is a special display that contains a series of pages, each with specific settings. It is specially designed to guide you through each step of the pick action configuration process.

To learn how to display the Pick Action Configuration Wizard, see Accessing the Pick Action Configuration Wizard.

To remove a pick action association that has already been configured, see Removing or Disabling a Pick Action Association.

NOTE: You can also use the Animations window to set up pick action menus (see Using the Animations Window to Set Up Pick Actions).

Further Information

Example Configuration: Pick Actions.


Mimics Guide - Accessing the Pick Action Configuration Wizard (Associating Mimic Objects with Pick Actions)

Accessing the Pick Action Configuration Wizard

The Pick Action Configuration Wizard is a special display that provides a simple step-by-step procedure for creating pick actions. Each page of the Wizard contains options and settings that you have to use to define the type and functionality of your pick action menus.

To access the Pick Action Wizard, you can either:

  • Right-click on the object for which you want to set up a pick action, and select the Pick Action Wizard option from the context sensitive menu.

Or:

  • Double-click on an object to display its Properties window, then select the Pick Action button on the General tab.
    Use these buttons to choose the type of pick action.
    Use these buttons to step through the 'pages' of the pick action configuration.
    Select the Disabled check box to deactivate a pick action but leave its configuration in place; clear it to make a pick action active again.

You can use the Pick Action Configuration Wizard for:

  • Creating an Object Menu Pick Action
  • Creating a Hyperlink Pick Action (see Hyperlinks)
  • Creating a Method Pick Action
  • Associating a Script with a Pick Action (see Associate a Mimic Script with a Script Pick Action in the ClearSCADA Guide to Scripting)
  • Creating a Registry Pick Action
  • Creating a ViewX Command Pick Action
  • Creating a System Command Pick Action
  • Creating a Menu Pick Action

You can also use the Pick Action Configuration Wizard to create Custom Pick Action Menus


Mimics Guide - Creating an Object Menu Pick Action (Associating Mimic Objects with Pick Actions)

Creating an Object Menu Pick Action

You can use the Pick Action Configuration Wizard to associate an Object Menu pick action with a Mimic object. Object Menu pick actions are useful for providing access to a database item's pick actions via a Mimic.

To associate a Mimic object with an Object Menu pick action:

  1. Display the Pick Action Wizard (see Accessing the Pick Action Configuration Wizard).
  2. Select the Object Menu option.
  3. Use the Disabled check box to define whether the pick action you are setting up is enabled or disabled.

If you select the check box, the pick action will be disabled—it will not be available to users. This setting is designed for use with animations. By animating the PickDisabled property of an object, you can make the availability of a pick action menu dependent on a condition. For example, you could set the pick action to disabled on the Pick Action Wizard and then use an animation to associate the Mimic object's PickDisabled property with a digital point. The state of the digital point will affect whether the pick action menu is enabled or disabled.

If you clear the check box, the pick action menu is available for selection. This is the default setting.

  4. Select the Next button.
  5. Use the browse button feature of the text entry field to associate the Mimic object with the pick action menu of a database item.

Alternatively, you can enter the location of the database item.

  6. Use the Relative check box to define whether the Mimic object uses an absolute or a relative reference to the database item.

Select the Relative check box to use a relative reference; clear it to use an absolute reference.

  7. In the Options section, select the check boxes for those menu options that you want to be displayed on the Mimic object's pick action menu. Clear the check boxes of those options that you want to exclude from the pick action menu.
  8. Select the Next button.
  9. Enter a comment in the Pick Action Comment field (if required). The comment is shown in the status bar when a user positions the cursor over the Mimic object. If you do not enter a comment, a default comment is shown in the status bar instead.
  10. Select the Next button.
  11. Select the Finish button.

The Mimic object is now associated with the pick action menu of the selected database item. The pick action menu for the Mimic object will contain the options that you specified on the Object Menu Options window.

You can test the pick action menu by displaying the Mimic in Run mode and selecting the Mimic object (pick action menus are only available in Run mode).


Mimics Guide - Creating a Method Pick Action (Associating Mimic Objects with Pick Actions)

Creating a Method Pick Action

You can use the Pick Action Configuration Wizard to associate a Mimic object with a method. When the pick action is selected, a method is performed. Where applicable, you can choose to specify the value that is written by the method. Alternatively, you can choose to set up the method pick action so that the user that selects the pick action has the choice to enter a value.

In this Mimic, an object with a method pick action has been selected. The user now has the option to enter an override value.

NOTE: For information on associating Button objects with method pick actions, see Pick Action Animations for Mimic Objects.

To associate a Mimic object with a method pick action:

  1. Display the Pick Action Wizard (see Accessing the Pick Action Configuration Wizard).
  2. Select the Method option.
  3. Use the Disabled check box to define whether the pick action you are setting up is enabled or disabled.

If you select the check box, the pick action will be disabled—it will not be available to users. This setting is designed for use with animations. By animating the PickDisabled property of an object, you can make the availability of a pick action dependent on a condition. For example, you could set the pick action to disabled on the Pick Action Wizard and then use an animation to associate the Mimic object's PickDisabled property with a digital point. The state of the digital point will affect whether the hyperlink is enabled or disabled.

If you clear the check box, the hyperlink pick action is available for selection. This is the default setting.

  4. Select the Next button.
  5. Use the browse button for the top field to select the database item that provides the method that you want to be associated with the pick action. For example, if you want the pick action to write an Override value to a point, use the browse button to select the point.
  6. Use the Relative check box to define whether the Mimic object uses an absolute or a relative reference to the database item.

Select the Relative check box to use a relative reference; clear it to use an absolute reference.

  7. Use the Aggregate combo box to select the aggregate that provides the required method. If the method is not provided by an aggregate, select the (None) option.

Each database item is stored in a class in the database. The class includes the fields, methods etc., that are available for items in that class. Some classes have aggregates —extensions to the class. Each aggregate has its own name, fields and methods that are used to store data. If the item you selected in step 5 is stored in a class that has an aggregate, you can use any of the methods for the class or the methods for the aggregate. If you are configuring a pick action to use an aggregate method, select the relevant aggregate from the Aggregate combo box.

Some aggregates also have their own alarm conditions which you can select (if required) in the Alarm combo box.

For more information on aggregates and to learn how to view them in the database schema, (see Working with the Database Schema in the ClearSCADA Guide to the Database).

  8. Use the Alarm combo box to select the alarm condition for the method. This is useful as it allows you to configure pick actions for methods that are only available for specific alarm conditions (alarm conditions are similar to aggregates in the database as they also provide additional fields and methods).

The alarm conditions are either specific alarm conditions for the database item you selected in step 5 or are alarm conditions for the aggregate you selected in step 7.

NOTE: If the method is not provided by a specific alarm condition, select the (None) option.

For more information on the alarm conditions that are available for the database item or an aggregate, please refer to the Database Schema (see Working with the Database Schema in the ClearSCADA Guide to the Database).

  9. Use the Method combo box to select the method that will be performed when the pick action is selected. The list of methods that is available is dependent on your selection in the Alarm and Aggregate combo boxes. The available methods are either:
  • Methods for the database item you selected in step 5
  • Methods for the aggregate you selected in step 7
  • Methods for the alarm condition you selected in step 8.
  10. Select the Next button.

If you selected a method that has arguments (requires a value), the Arguments 'page' is displayed. Proceed to step 11.

if you selected a method that does not have arguments, the Pick Action Comment 'page' is displayed. Proceed to step 13.

  11. Use the Arguments 'page' to configure the expressions for the arguments:

The Arguments 'page' lists the available arguments. The name of the argument is shown in the Name column, the required data type is shown in the Type column, and the expression for the argument is shown in the Value column.

  1. Right-click on the argument that you want to configure.
    A context sensitive menu is displayed.
  2. Select the required option:
  • Edit—Displays the Expressions window that you can use to configure an expression for the argument. Proceed to step iii.
  • <Pre-Defined Argument>—Depending on the type of method you have selected, there may be additional argument options that correspond to the arguments that are configured for the database item. For example, the pick action is associated with a digital point and you select the Override method, the context menu has options for each of the digital point's states (State 0, State 1, State 2 etc.) If you select any of these options, the value for the argument will be set to match the corresponding value in the database item's configuration. So, if you selected State 1 for a digital point, the method would use State 1 for the point as its value.

If you select a <Pre-Defined Argument> option, the selected argument is shown in the Value column of the Parameters 'page'. Proceed to step 12.

  3. Use the Expressions window to create an expression that defines the argument value. For more information, see Using the Expression Editors in the ClearSCADA Guide to Expressions.
  4. Select the OK button to confirm the expression and close the Expression window.
  5. Repeat steps i-v for each argument as required. When you have defined the required arguments, proceed to step 12.

NOTE: To remove the expression for an argument, right-click on the argument in the list on the Arguments 'page' then select the Clear option.

  12. Select the Next button.
  13. Enter a comment in the Pick Action Comment field (if required). The comment is shown in the status bar when a user positions the cursor over the Mimic object. If you do not enter a comment, a default comment is shown in the status bar instead.
  14. Select the Next button.
  15. Select the Finish button.

The Mimic object is now associated with a method pick action. You can test the method pick action by displaying the Mimic in Run mode and selecting the object that is associated with the method pick action (pick actions are only available in Run mode). If you configured a pick action method that is specific to an alarm condition, the method will only be triggered if the relevant database item has an alarm that matches the selected condition. The database item does not have to be in that alarm state; it just needs to have that alarm condition.


Mimics Guide - Creating a Registry Pick Action (Associating Mimic Objects with Pick Actions)

Creating a Registry Pick Action

You can use the Pick Action Configuration Wizard to associate a Mimic object with a registry pick action. When the pick action is selected, a value is written to the registry. This value can be used in animations as part of a condition in an expression.

For example, a common use of the registry pick action is to write a value to the registry that is used to determine whether a layer is visible.

You can find more detailed information on using the registry pick action feature for controlling the visibility of layers and applying different filters to an embedded SQL list in Local Variables (Registry Key Settings).

NOTE: The registry values are stored in the
HKEY_CURRENT_USER\Software\Schneider Electric\ClearSCADA\ViewX\Mimics key in the registry on your client PC.

To set up a registry pick action:

  1. Display the Pick Action Wizard (see Accessing the Pick Action Configuration Wizard).
  2. Select the Registry option.
  3. Use the Disabled check box to define whether the pick action you are setting up is enabled or disabled.

If you select the check box, the pick action will be disabled—it will not be available to users. This setting is designed for use with animations. By animating the PickDisabled property of an object, you can make the availability of a pick action dependent on a condition. For example, you could set the pick action to disabled on the Pick Action Wizard and then use an animation to associate the Mimic object's PickDisabled property with a digital point. The state of the digital point will affect whether the hyperlink is enabled or disabled.

If you clear the check box, the hyperlink pick action is available for selection. This is the default setting.

  4. Select the Next button.
  5. Enter the name of the registry in the Name field. If this registry does not already exist, the selection of the pick action will cause the system to create the registry. The registry will have the value that you define in step 7 as its default value.

NOTE: You cannot include brackets ( ) in the Name.

Typically, engineers configure the animations for a registry pick action before they setup the pick action. If the name of the registry and the default value has already been specified in the animations, the settings on the pick action wizard will not be used to create a new registry (unless they specify a different registry name).

  6. Use the Type combo box to define the type of value that will be written by the pick action. The value can be:
  • Number—The value consists only of numerical characters.
  • String—The value contains letters.
  7. In the Value field, enter the Value that is written to the registry when the pick action is selected. This is the value that will be used as the default value for the registry if the registry does not already exist.

The value will be overridden by any values that are specified as part of a registry animation (see Local Variables (Registry Key Settings)).

  8. Select the Next button.
  9. Enter a comment in the Pick Action Comment field (if required). The comment is shown in the status bar when a user positions the cursor over the Mimic object. If you do not enter a comment, a default comment is shown in the status bar instead.
  10. Select the Next button.
  11. Select the Finish button.

The Mimic object is now associated with a registry pick action. You can test the registry pick action by displaying the Mimic in Run mode and selecting the object that is associated with the registry pick action (pick actions are only available in Run mode). When the pick action is selected, the relevant value is written to the registry. By using the registry in animation expressions, you can apply local changes to a Mimic (see Local Variables (Registry Key Settings)).


Mimics Guide - Creating a ViewX Command Pick Action (Associating Mimic Objects with Pick Actions)

Creating a ViewX Command Pick Action

You can associate a Mimic object with a ViewX Command pick action (a ViewX command is the equivalent of a ViewX menu or toolbar option). When the Mimic object is selected, the relevant ViewX command is performed. For example, you can use the ViewX command pick action menu to associate a button on a Mimic with the Print command. This means that you can have fully operational command buttons on your Mimics.

To set up a ViewX Command pick action:

  1. Display the Pick Action Wizard (see Accessing the Pick Action Configuration Wizard).
  2. Select the ViewX Command option.
  3. Use the Disabled check box to define whether the pick action you are setting up is enabled or disabled.

If you select the check box, the pick action will be disabled—it will not be available to users. This setting is designed for use with animations. By animating the PickDisabled property of an object, you can make the availability of a pick action dependent on a condition. For example, you could set the pick action to disabled on the Pick Action Wizard and then use an animation to associate the Mimic object's PickDisabled property with a digital point. The state of the digital point will affect whether the hyperlink is enabled or disabled.

If you clear the check box, the hyperlink pick action is available for selection. This is the default setting.

  4. Select the Next button.
  5. Select the required command from the Command combo box. The commands correspond to options in the menus and buttons on the various toolbars. For example, if you select the Zoom In command, the pick action will provide the same functionality as the Zoom In button on the Navigate toolbar.
  6. Select the Next button.
  7. Enter a comment in the Pick Action Comment field (if required). The comment is shown in the status bar when a user positions the cursor over the Mimic object. If you do not enter a comment, a default comment is shown in the status bar instead.
  8. Select the Next button.
  9. Select the Finish button.

The Mimic object is now associated with a ViewX command pick action. You can test the ViewX command pick action by displaying the Mimic in Run mode and selecting the object that is associated with the ViewX command pick action (pick actions are only available in Run mode). When the pick action is selected, the relevant command is performed. For example, if you set the command to Print, selecting the pick action will display the Print window (you can use the Print window to define the print settings and start the printing process).


Mimics Guide - Creating a System Command Pick Action (Associating Mimic Objects with Pick Actions)

Creating a System Command Pick Action

You can associate a Mimic object with a system command (a system command is a Windows command, such as running another program). When the Mimic object is selected, the relevant system command is performed. For example, you can set up a system command pick action so that a Third Party program runs when the pick action is selected.

To set up a system command pick action:

  1. Display the Pick Action Wizard (see Accessing the Pick Action Configuration Wizard).
  2. Select the System Command option.
  3. Use the Disabled check box to define whether the pick action you are setting up is enabled or disabled.

If you select the check box, the pick action will be disabled—it will not be available to users. This setting is designed for use with animations. By animating the PickDisabled property of an object, you can make the availability of a pick action dependent on a condition. For example, you could set the pick action to disabled on the Pick Action Wizard and then use an animation to associate the Mimic object's PickDisabled property with a digital point. The state of the digital point will affect whether the hyperlink is enabled or disabled.

If you clear the check box, the hyperlink pick action is available for selection.

  4. Select the Next button.
  5. Enter the command line in the Command field. The command line entry should use the same syntax as a command line in Windows.
  6. Use the Permission combo box to select the permission that is associated with the system command pick action. Only users that have the specified permission for the host Mimic (the Mimic that contains the pick action) will be able to select the pick action. For more information on permissions, see Allocating Security Permissions in the ClearSCADA Guide to Security.
  7. Select the Next button.
  8. Enter a comment in the Pick Action Comment field (if required). The comment is shown in the status bar when a user positions the cursor over the Mimic object. If you do not enter a comment, a default comment is shown in the status bar instead.
  9. Select the Next button.
  10. Select the Finish button.

The Mimic object is now associated with a system command pick action. You can test the system command pick action by displaying the Mimic in Run mode and selecting the object that is associated with the system command pick action (pick actions are only available in Run mode). When the pick action is selected, the relevant command is performed.


Mimics Guide - Creating a Menu Pick Action (Associating Mimic Objects with Pick Actions)

Creating a Menu Pick Action

You can create custom pick action menus that contain a variety of options. The custom pick action menu feature allows you to create menus that are suited to your system and use appropriate terminology.

To create a custom pick action menu:

  1. Display the Pick Action Wizard (see Accessing the Pick Action Configuration Wizard).
  2. Select the Menu option.
  3. Use the Disabled check box to define whether the pick action you are setting up is enabled or disabled.

If you select the check box, the pick action will be disabled—it will not be available to users. This setting is designed for use with animations. By animating the PickDisabled property of an object, you can make the availability of a pick action dependent on a condition. For example, you could set the pick action to disabled on the Pick Action Wizard and then use an animation to associate the Mimic object's PickDisabled property with a digital point. The state of the digital point will affect whether the hyperlink is enabled or disabled.

If you clear the check box, the hyperlink pick action is available for selection. This is the default setting.

  4. Select the Next button to display the Pick Menu window.

NOTE: Alternatively, you can access the Pick Menu window by right-clicking on the relevant Mimic item and then selecting the Advanced Pick Menu option from the context sensitive list.

  5. Use the Pick Menu window to create new pick action menu options and sub-options (see Using the Pick Menu Window)
  6. Use the Test button to see how the custom pick action menu will be displayed when selected on the Mimic.(see Test Custom Pick Action Menus)
  7. Select the OK button to confirm your custom menu settings and close the Pick Menu window.

Further Information

Associating a Custom Menu Pick Action with a Mimic Parameter.

Example Configuration: Pick Actions.

Using Custom Menu Options on a Symbol to Write Values to a Point.


Mimics Guide - Custom Pick Action Menus (Associating Mimic Objects with Pick Actions)

Custom Pick Action Menus

You can use the Pick Action Wizard to create custom pick action menus. For more information, see Creating a Menu Pick Action.


Mimics Guide - Using the Pick Menu Window (Associating Mimic Objects with Pick Actions)

Using the Pick Menu Window

You can use the Pick Menu window to create new custom pick menus and pick menu options.

The Pick Menu window is displayed when you select the Menu option on the first page of the Pick Action Wizard and press the Next button (see Creating a Menu Pick Action). You can also access the Pick Menu window by right-clicking on a Mimic object and selecting the Advanced Pick Menu option.

You can use the Pick Menu window to:

  • Add a Custom Pick Action Menu
  • Add a Custom Pick Action
  • Add a Separator
  • Edit a Pick Action Menu Option
  • Remove a Custom Pick Action or Custom Pick Action Menu
  • Change the Order of Custom Pick Actions, Menus, and Separator Lines
  • Add Comments for Custom Pick Actions and Menus
  • Enable and Disable a Custom Pick Action Menu
  • Test Custom Pick Action Menus.


Mimics Guide - Add a Custom Pick Action Menu (Associating Mimic Objects with Pick Actions)

Add a Custom Pick Action Menu

To add a custom pick action menu:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. Select the Add Menu button.
    A new menu is added to the pick action menu tree structure. It is selected automatically, ready for you to define its name.
  3. Enter a suitable name, then press the Enter key or select another part of the interface to confirm the name entry.

When you have added a menu, you can add pick actions to the menu (see Add a Custom Pick Action) and move the menu in the pick action menu tree structure (see Change the Order of Custom Pick Actions, Menus, and Separator Lines).


Mimics Guide - Add a Custom Pick Action (Associating Mimic Objects with Pick Actions)

Add a Custom Pick Action

To add a custom pick action to a custom pick action menu:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. In the pick action menu tree structure, select the custom menu to which you want to add a custom pick action.
  3. Select the Add Action button.
    The Pick Action Configuration window is displayed.

The Pick Action Configuration window has an extra setting when displayed for custom menu pick actions—the Animate Parameter check box. For more information on this setting, see Associating a Custom Pick Action with a Mimic Parameter.

  4. Use the first page of the Pick Action Configuration window to choose the type of pick action that you want to add. The types are:
  • Object Menu—The custom pick action provides access to the pick action options for an object in the database. If you have selected this option and have not enabled the Animate Parameter check box, proceed to step 5.
  • Hyperlink—The custom pick action acts as a hyperlink to another display. If you have selected this option and have not enabled the Animate Parameter check box, proceed to step 6.
  • Method—The custom pick action instigates a method action when selected. If you have selected this option and have not enabled the Animate Parameter check box, proceed to step 7.
  • Script—The custom pick action executes a script when selected. If you have selected this option and have not enabled the Animate Parameter check box, proceed to step 8.
  • Registry—The custom pick action writes a value to the registry when selected. If you have selected this option and have not enabled the Animate Parameter check box, proceed to step 9.
  • ViewX Command—The custom pick action performs the same function as a specific toolbar button or menu option when selected. If you have selected this option and have not enabled the Animate Parameter check box, proceed to step 10.
  • System Command—The custom pick action instigates a system command when selected. If you have selected this option and have not enabled the Animate Parameter check box, proceed to step 11.

NOTE: If you select the Animate Parameter check box, you allow the custom action to be associated with a Mimic parameter instead of a specific database object. If you want to associate a custom action with a Mimic parameter, see Associating a Custom Pick Action with a Mimic Parameter. If you do not intend to associate the custom action with a Mimic parameter, clear the Animate Parameter check box.

  5. Define the settings for the Object pick action menu:
  • Use the browse button feature of the Object field to choose a database item. The database item that you choose is the database item that provides the pick action menu that is associated with the custom pick action.
  • Use the Options section to choose the options that are to be included (select to include; clear to exclude).
  • Use the Relative check box to define whether the custom pick action uses an absolute or relative reference to link to the selected database item. If the check box is selected, the custom pick action uses a relative reference.

Proceed to step 12.

  6. Define the settings for the target display:
  • Use the URL field's browse button to select the target display.
  • Use the Mode combo box to define where the target display is shown
  • Use the spin boxes to define the positioning and sizing of the target display (where appropriate).
  • Use the Relative check box to define whether the custom pick action uses an absolute or relative reference to link to the selected display. If the check box is selected, the custom pick action uses a relative reference.

These settings work in the same way as the corresponding settings on the Pick Action Configuration Wizard for hyperlinks (see Using the Pick Action Wizard to Create a Hyperlink).

Proceed to step 12.

  7. Define the settings for the method:
  1. Use the Object field's browse button to select the database item that provides the method that you want to be associated with the pick action. For example, if you want the pick action to write an Override value to a point, use the browse button to select the point.
  2. Use the Method combo box to choose the type of method that is performed when the custom pick action is selected.
  3. Use the Relative check box to define whether the custom pick action uses an absolute or relative reference to link to the selected method. If the check box is selected, the custom pick action uses a relative reference.
  4. Select the Next button to display the next page of the Pick Action Wizard.
  5. Double-click on the parameter that you want to define.
    The Expression window is displayed.
  6. Use the Expression window to define the setting for the parameter. For more information, see Using the Expression Editors in the ClearSCADA Guide to Expressions.
  7. Select the OK button to confirm your selection and close the Expression window.
  8. Repeat steps v to vii inclusive for each parameter.

These settings work in the same way as the corresponding settings on the Pick Action Configuration Wizard for methods (see Creating a Method Pick Action).

  8. Use the Script field's browse button feature to select a preconfigured function or enter any valid script in the field. The selected function or defined script will be executed when the custom pick action is selected. For more information, see Associate a Mimic Script with a Script Pick Action in the ClearSCADA Guide to Scripting.

Proceed to step 12.

  9. Define the settings for the registry pick action:
  • Use the Name field to enter the name of the registry key.
  • Use the Type combo box to choose the type of registry value.
  • Use the Value field to define the value that is written to the registry.

These settings work in the same way as the corresponding settings on the Pick Action Configuration Wizard for registry key pick actions (see Creating a Registry Pick Action).

Proceed to step 12.

  10. Use the Command combo box to select the type of ViewX command that will be performed when the custom pick action is selected. Each command corresponds to a toolbar option or menu option. For more information, see Creating a ViewX Command Pick Action.

Proceed to step 12.

  11. Define a system command for the custom pick action:
  • Use the Command browse button to select an application to run when the custom pick action is selected. Alternatively, enter a system command in the field.
  • Use the Permission combo box to choose the permission that controls whether a user can use the pick action to perform a system command. Only users that have the selected permission for the host Mimic (the Mimic that provides access to the custom pick action) can select the custom pick action.

For more information, see Creating a System Command Pick Action.

Proceed to step 12.

  12. Enter an expression to define the availability of the pick action in the expression field, or leave the field empty to set the pick action to be available. If you choose to enter an expression, the value of the expression has to be convertible to a Boolean value (as the action will be available when the expression is true and unavailable when it is false). If a custom action is unavailable, it does not appear on the custom menu.

For more information on the syntax for expressions, see Understanding the Basics of Expressions in the ClearSCADA Guide to Expressions.

  13. Select the Next button to confirm.
  14. Select the Finish button to confirm your choices and close the Pick Action Configuration window.
    The custom pick action is added to the custom pick action menu structure.

You can change its position if required—see Change the Order of Custom Pick Actions, Menus, and Separator Lines.

Further Information

Associating a Custom Menu Pick Action with a Mimic Parameter.

Example Configuration: Pick Actions.

Using Custom Menu Options on a Symbol to Write Values to a Point.


Mimics Guide - Add a Separator (Associating Mimic Objects with Pick Actions)

Add a Separator

You can use the Add Separator feature of the Pick Menu window to add a separator line to your custom pick action menu. By using separators, you can divide your custom pick action menus into sections, for example:

Separator lines can be used to divide a pick action menu into sections.

To add a separator line:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. In the pick action menu tree structure, select the custom pick action that will be positioned above the separator line.
  3. Select the Add Separator button.
    A new separator line is added to the custom pick action menu.

You can use the Move Up and Move Down buttons to move the position of the line as required (see Change the Order of Custom Pick Actions, Menus, and Separator Lines).


Mimics Guide - Edit a Pick Action Menu Option (Associating Mimic Objects with Pick Actions)

Edit a Pick Action Menu Option

You can change the settings for any of the custom pick action menu options. To make alterations, you need to display the Edit Action window.

To display the Edit Action window:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. Double-click on the pick action that you want to edit. Alternatively, select the pick action and then select the Edit button.
    The Pick Action Configuration window is displayed.
  3. Use the Pick Action Configuration window to alter the configuration of the custom pick action (see Add a Custom Pick Action).


Mimics Guide - Remove a Custom Pick Action or Custom Pick Action Menu (Associating Mimic Objects with Pick Actions)

Remove a Custom Pick Action or Custom Pick Action Menu

You can remove a custom pick action or custom pick action menu as required:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. Select the pick action or pick action menu that you want to remove, then select the Remove button.
    The action or action menu is removed.


Mimics Guide - Change the Order of Custom Pick Actions, Menus, and Separator Lines (Associating Mimic Objects with Pick Actions)

Change the Order of Custom Pick Actions, Menus, and Separator Lines

You can change the order of pick actions, pick action menus, and separator lines. To do this, you need to use the Move Up and Move Down buttons on the Pick Menu window.

To change the order of custom pick actions, custom pick action menus, and separator lines:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. Select the pick action, menu, or separator line that you want to move.
  3. Either:
  • Select the Move Up button to move the action, menu, or line toward the top of the hierarchy.
  • Select the Move Down button to move the action, menu, or line toward the bottom of the hierarchy.
  4. Repeat step 3 as required.


Mimics Guide - Add Comments for Custom Pick Actions and Menus (Associating Mimic Objects with Pick Actions)

Add Comments for Custom Pick Actions and Menus

You can add a comment for your custom pick action menu. The comment will be displayed in the status bar when the cursor is positioned over the pick action menu in Run mode.

To add a comment:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. Select the required action or menu.
  3. Enter the required comment in the Comment field.
  4. Select the OK button to confirm.

The Comment field works in the same way as the PickComment field on the Pick Action Configuration Wizard. For more information, see the relevant Pick Action Configuration Wizard section, for example, refer to Hyperlinks for information on the pick comment for a hyperlink pick action.


Mimics Guide - Enable and Disable a Custom Pick Action Menu (Associating Mimic Objects with Pick Actions)

Enable and Disable a Custom Pick Action Menu

You can use the Pick Menu window to enable and disable a custom pick action menu. Typically, you would not use the Disabled check box on the Pick Menu window as you would use an animation to control whether the pick action menu is available. However, you can make a custom pick action menu inaccessible if required:

To enable or disable a custom pick action menu:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. Either:
  • Select the Disabled check box to make the custom pick action menu unavailable.
  • Clear the Disabled check box to enable the pick action menu so that users can access its options.
  3. Select the OK button to confirm.


Mimics Guide - Test Custom Pick Action Menus (Associating Mimic Objects with Pick Actions)

Test Custom Pick Action Menus

When you are creating custom menus, you can use the Test button on the Pick Menu window to see how the pick action menu will appear when selected on a Mimic. When you select the Test button, the custom pick action menu is displayed.

NOTE: The Test feature is only designed to show a preview of your custom menu—the options on the custom menu will not have any affect on the system.

To test a custom pick action menu:

  1. Display the Pick Menu window (see Using the Pick Menu Window).
  2. Create the custom pick action menu by adding pick action menus, pick actions, and separator lines as required.
  3. Select the Test button.
    The pick action menu is displayed. It shows the various branches that you have created as part of the menu's hierarchy.


Mimics Guide - Associating a Custom Menu Pick Action with a Mimic Parameter (Associating Mimic Objects with Pick Actions)

Associating a Custom Menu Pick Action with a Mimic Parameter

When you create a custom menu that contains pick actions, each action is associated with a parameter. The parameter defines the database item, script, registry etc. to which the action relates. For example, if a custom menu has a hyperlink action, that action can have a parameter that specifies the location of the ‘target’ display. However, there is a limitation with this as the parameter for the action is 'fixed' i.e. it can only reference a specific database item, location, registry, script etc.

By using the Animate Parameter setting, you can set the parameter of a pick action to reference a Mimic parameter instead of a 'fixed' value. For example, instead of a hyperlink action referencing the Form of a specific database item, it can reference a Mimic parameter. The Mimic parameter can then be associated with the Form of any database item. The value that is used as the source of the Mimic parameter will be the value that is used as the value for the pick action’s parameter.

NOTE: Take care not to confuse Mimic parameters with pick action parameters. A Mimic parameter is a custom property that can be animated when the Mimic is embedded, whereas a pick action parameter is the entry that associates a custom action with a database item, location, script, registry, etc. So a Mimic parameter can be used as the value for the parameter of a pick action.

A common use of the Animate Parameter feature is to allow a Mimic that contains a custom menu to be embedded on other Mimics, with each embedded Mimic having pick actions that are associated with different database items. For a detailed example, see Using Custom Menu Options on a Symbol to Write Values to a Point.

To configure a custom action so that it is associated with a Mimic parameter instead of a specific database item:

  1. Create a parameter for the Mimic that contains (or is to contain) the custom pick action menu (see Adding a Mimic Parameter).
  2. Display the Pick Menu window (see Using the Pick Menu Window)
  3. Either create a new action or edit an existing action (see Add a Custom Pick Action or see Edit a Pick Action Menu Option).
    The Pick Action Wizard is displayed.
  4. On the first page of the Pick Action Wizard, select the button for the type of action you want to create and then select the Animate Parameter check box. The options for the types of action are the same as those that are available when creating a custom action that is associated with a specific database item (see Add a Custom Pick Action).
  5. Select the Next button to display an expression entry page.
  6. On the expression entry page, define the expression for the custom action. The expression has to be valid for the type of custom action you have selected and if it references a parameter, the parameter has to be available on the Mimic.

For more information on the syntax for expressions, see Understanding the Basics of Expressions in the ClearSCADA Guide to Expressions.

  7. Select the Next button.
  8. On the second expression entry page, enter an expression to define the availability of the pick action. If you leave the field empty, the pick action is made available by default. If you choose to enter an expression, the value of the expression has to be convertible to a Boolean value (as the action will be available when the expression is true and unavailable when it is false). If a custom action is unavailable, it does not appear on the custom menu.

For more information on the syntax for expressions, see Understanding the Basics of Expressions in the ClearSCADA Guide to Expressions.

  9. Select the Next button.
  10. Select the Finish button to complete the custom action configuration.
  11. Repeat as required for other custom actions.

Further Information

Example Configuration: Pick Actions

Custom Pick Action Menus

Mimic Parameters

Understanding the Basics of Expressions in the ClearSCADA Guide to Expressions.


Mimics Guide - Using the Animations Window to Set Up Pick Actions (Associating Mimic Objects with Pick Actions)

Using the Animations Window to Set Up Pick Actions

You can use the Animations window to set up pick actions. This is useful when you need the availability of a pick action to be dependant on a condition. For example, you can use an animation expression to set a pick action menu to only be available when a point is in a specific state.

There are several animation properties that relate to pick actions, including:

  • PickComment—Use to animate the comment for a pick action.
  • PickDisabled—Use to enable and disable a pick action with an animation.
  • PickParam—Use to animate the features of the pick action menu.
  • PickType—Use to set the type of pick action menu (ClearSCADA Object, Hyperlink, Registry, etc.).

For more information on setting up the pick action animations, see Animations.


Mimics Guide - Removing or Disabling a Pick Action Association (Associating Mimic Objects with Pick Actions)

Removing or Disabling a Pick Action Association

You can use the Pick Action Wizard to delete a pick action association so that a Mimic object no longer provides access to pick action functionality. For example, if a Mimic object provides access to an Object Menu, you can remove or disable the pick action configuration so that selecting the Mimic object has no effect.

When canceling a pick action association, you have 2 options:

  • You can remove the pick action association completely, so that the configuration for the pick action is removed and the Mimic object is not associated with the pick action in any way.
  • You can disable the pick action association so that the pick action configuration remains intact, but is disabled. This means that the Mimic object will not 'trigger' the pick action when selected. However, if the pick action is disabled, it can later be restored by clearing the Disabled check box—the pick action will not need to be reconfigured.

To remove or disable a pick action association:

  1. Display the Pick Action Wizard for the Mimic object that you wish to disassociate from the pick action (see Accessing the Pick Action Configuration Wizard).
  2. On the first 'page' of the Wizard, either:
  • Select the None option to remove the pick action configuration. You should select this option if you want to cancel the pick action association permanently.

Or:

  • Select the Disabled check box to leave the pick action configuration in place, but set it to be disabled so that selecting the Mimic object has no effect. You should use this option if you only need to temporarily cancel the pick action association.
  3. Select the Next button to proceed to the next 'page' of the Pick Action Wizard.
  4. Repeat step 3 as required until you reach the final 'page' of the Pick Action Wizard.
  5. Select the Finish button to confirm your selections and close the Pick Action Wizard.


Mimics Guide - Example Configuration: Pick Actions (Associating Mimic Objects with Pick Actions)

Example Configuration: Pick Actions

The following examples demonstrate some of the many ways in which you can use pick actions with Mimic objects:

  • Associating a Mimic Object with a Point’s Pick Action Menu
  • Associating a Mimic Object with the Alarms On Sytstem Command
  • Using Repeat Buttons to Write to a Point
  • Using Custom Menu Options on a Symbol to Write Values to a Point.


Mimics Guide - Associating a Mimic Object with a Point's Pick Action Menu (Associating Mimic Objects with Pick Actions)

Associating a Mimic Object with a Point’s Pick Action Menu

In this example, a Mimic object is associated with the default pick action menu for a database point. This allows the Mimic object to provide access to the point’s pick action menu when the object is selected (in Run Mode).

Example:

An engineer configures a Mimic so that it contains a representation of a valve. The valve object is grouped so that it is a single selectable object.

The engineer selects the valve object so that it is highlighted. Next, the engineer uses the Database Bar to locate the point that is to be associated with the valve object. The engineer drags the point from the Database Bar onto the valve object. This displays a context sensitive menu, from which the engineer selects the Paste Object Menu option.

The Mimic is displayed in Run Mode and the engineer selects the valve database item; the pick action menu for the point that is associated with the valve object is displayed.

By default, each of the pick action menu’s options are shown. The engineer decides that only a small selection of the options should be available for this Mimic, and so the Mimic is displayed in Design Mode again. The engineer right-clicks on the valve object and selects the Pick Action Wizard option from the menu. This displays the Pick Action Wizard.

The engineer selects the Next button to proceed to the second page of the wizard. There, the options list shows the pick actions that can be included on the pick action menu.

The engineer clears the check boxes for those options that should not be included in the pick action menu, then selects the Next buttons to proceed through the pages of the wizard. Finally, the engineer selects the Finish button to confirm the changes and close the wizard.

The engineer displays the Mimic in Run Mode and selects the valve object. The pick action menu for the point is displayed again, only this time, it only contains those options that were chosen by the engineer (the options that remained selected).


Mimics Guide - Associating a Mimic Object with the Alarms On Sytstem Command (Associating Mimic Objects with Pick Actions)

Associating a Mimic Object with the Alarms On Sytstem Command

In this example, a simple text box is configured to work as a ViewX Command pick action. The text box, when selected in Run Mode, will trigger the Alarms on System ViewX command (which causes the Alarms List to be displayed with no filters in place).

Example:

An engineer adds a new text box to a Mimic and configures the text box so that it contains the text ‘Display System Alarms’ in white, shown on a red background.

The engineer right-clicks on the text box to display a context sensitive menu, then selects the Pick Action Wizard option. On the Pick Action Wizard, the engineer selects ViewX Command as the type of pick action, then selects Next. On the second page of the wizard, the engineer selects Alarms on System as the ViewX command that will be executed when the text box is selected, then selects Next followed by Finish to complete the configuration.

The Mimic is displayed in Run Mode and the engineer selects the Display System Alarms text box—the Alarms List is displayed and it has no filters, so shows all system alarms (to which the logged on user has access).

Further Information

Creating a ViewX Command Pick Action


Mimics Guide - Using Repeat Buttons to Write to a Point (Associating Mimic Objects with Pick Actions)

Using Repeat Buttons to Write to a Point

The Repeat button feature is designed to allow users to perform an action repeatedly by holding down a button. When the button is pressed down, the action that is associated with the button is performed every second. As soon as the button is released, the action stops being performed. This is useful if you need users to send controls that change values in set increments.

NOTE: To configure a button to use Repeat mode, see Editing a Button.

You can configure a pick action animation for a repeat button in the same way as you would configure a pick action animation for any other Mimic object (see Associating Mimic Objects with Pick Actions). The only difference with a repeat button is that any action that is associated with the button is repeated (every second by default) for as long as the button is pressed down.

The following example shows how repeat buttons can be used to change the value of a point by set increments:

Example:

A Mimic contains a graphical representation of a weir that is used in the water industry. The weir is animated so that it is raised or lowered, depending on the value of an analog point (named ‘MDN River Level’).

The Mimic also contains 2 buttons, both of which are set to Repeat mode. One button is named ‘Raise Weir’ and the other is named ‘Lower Weir’.

When the ‘Lower Weir’ button is held down, 10 is deducted from the current value of the ‘MDN River Level’ point’s current value every second. This change in value is reflected in the position of the weir in the graphic.

When the ‘Raise Weir’ button is held down, 10 is added to the current value of the ‘MDN River Level’ point’s current value every second. This change in value is also reflected in the position of the weir in the graphic.

The configuration for the various Mimic objects and animations is as follows:

‘Weir’ Mimic object:

The ‘Weir’ Mimic object has a Dynamic Path animation that sets the moving part to move along a straight, downwards line:

The animations for the Dynamic Path are:

  • Pos Anchor: 0. This sets the anchor point of the moving part to be the center.
  • PosMax: 100. This sets the last position on the path to correspond to a value of 100.
  • PosMin: 0. This sets the first position on the path to correspond to a value of 0.
  • PosVal: ".MDN River Level.CurrentValue". This associates the position of the moving part with the current value of the ‘MDN River Level’ point.

‘Raise Weir’ button:

The ‘Raise Weir’ button is configured so that it is in Repeat mode. The Pick Action Wizard is used to associate the button with a database item, in this case, the ‘MDN River Level’ point. The settings that are put in place are:

  • Type: Method
  • Object: SCX:////CPointAlgManual/.MDN River Level
  • Method: Hand Control
  • Argument: ".MDN River Level.CurrentValue" -10

These settings mean that when the ‘Raise Weir’ button is held down, the value of the ‘MDN River Level’ point will decrease by 10 (every second by default). This will cause the moving part of the ‘weir’ object to move upwards as it has a dynamic path animation that is associated with the current value of the ‘MDN River Level’ point.

‘Lower Weir’ button:

The ‘Lower’ Weir button has the same configuration as the ‘Raise Weir’ button except that it uses the following argument:

  • Argument: ".MDN River Level.CurrentValue" +10

This means that when the ‘Lower Weir’ button is pressed, the value of the ‘MDN River Level’ point increases by 10 (every second by default). This will cause the moving part of the ‘weir’ object to move downwards.

Further Information

Pick Action Animations for Mimic Objects

Associating Mimic Objects with Pick Actions.

Editing a Button


Mimics Guide - Using Custom Menu Options on a Symbol to Write Values to a Point (Associating Mimic Objects with Pick Actions)

Using Custom Menu Options on a Symbol to Write Values to a Point

In this example, a Mimic is configured to contain custom menu options. The Mimic is designed to be used as a ‘Symbol’ Mimic; it will be embedded on many other Mimics. The custom menu options will be used to write values to a point that is associated with the Mimic, but each embedded version of the Mimic will need to be associated with a different point. To achieve this, Mimic parameters and pick action expressions that reference the parameters are used.

Example:

A Mimic called ‘Pump’ is configured so that it contains a visual representation of a pump. This pump is controlled via an analog point named ‘Pump Controls’.

The ‘pump’ graphic is configured to have a custom menu. The user right-clicks on the ‘pump’ graphic and selects the Advanced Pick Menu option. Then, on the Pick Menu window, the user selects Add Menu and names the new menu ‘Pump Power’. Within this menu, the user creates 4 new actions named ‘Increase Power 10’, ‘Max Power’, ‘Decrease Power 10’ and ‘Minimum Power’. The pick actions for these actions are configured as follows:

‘Increase Power 10’:

Type: Method

Object: SCX:////CPointAlgManual/.Pump Controls

Method: Hand Control

Expression: ".Pump Controls" +10

‘Max Power’:

Type: Method

Object: SCX:////CPointAlgManual/.Pump Controls

Method: Hand Control

Expression: ".Pump Controls" 90

‘Decrease Power 10’:

Type: Method

Object: SCX:////CPointAlgManual/.Pump Controls

Method: Hand Control

Expression: ".Pump Controls" -10

‘Min Power’:

Type: Method

Object: SCX:////CPointAlgManual/.Pump Controls

Method: Hand Control

Expression: ".Pump Controls" 5

For the 4 custom menu options, the Animate Parameter setting is cleared

This means that each custom action can only be associated with the properties of a specific database item (in this case, the ‘Pump Controls’ point). As the ‘Pump’ Mimic is designed to be used as a symbol Mimic (a generic representation of a pump that can be embedded on many Mimics), only being able to link the Mimic with one specific point means it has limited use. So the ‘Pump’ Mimic is reconfigured so that it can be associated with any database point.

An engineer uses the Parameters window (accessed via the Edit menu’s Parameters option) to add the following Mimic parameters:

Name: Point

Group: Yes (selected)

Name: CurrentValue

Parent: Point

Name: FullScale

Parent: Point

Name: ObjectLink

Parent: Point

Name: ZeroScale

Parent: Point

These parameters will allow the ‘Pump’ Mimic to be associated with the CurrentValue, FullScale, and ZeroScale properties of a point (the ObjectLink is required to link the pick action menu of any point to the ‘Pump’ Mimic). The parameters require the same name as the database item properties with which they will be used.

The engineer then reconfigures the 4 custom menu options so that they have the Animate Parameter setting selected (enabled). This allows each custom menu to use a parameter as an animation property.

When the Animate Parameter setting is enabled and the Next button is selected, the engineer is prompted to enter an expression. The engineer enters the following expressions for the custom menu options:

‘Increase Power 10’:

"Parameter:Point.ObjectLink"+'?CurrentValue&value="' +STR("Parameter:Point.CurrentValue"+10) +'"'

The expression links the custom menu with the ObjectLink and CurrentValue parameters and is set to convert the current value of a point to a string. It then adds 10 to the value before writing it back to the parameter source (which will be a point).

‘Decrease Power 10’:

"Parameter:Point.ObjectLink"+'?CurrentValue&value="' +STR("Parameter:Point.CurrentValue"-10) +'"'

The expression links the custom menu with the ObjectLink and CurrentValue parameters and is set to convert the current value of a point to a string. It then subtracts 10 from the value before writing it back to the parameter source (which will be a point).

‘Max Power’:

"Parameter:Point.ObjectLink"+'?CurrentValue&value="' +STR("Parameter:Point.FullScale") +'"'

The expression links the custom menu with the ObjectLink and CurrentValue parameters and is set to convert the current value of a point to a string. It then sets the value to the same value as the FullScale of the parameter source (which will be a point).

‘Min Power’:

"Parameter:Point.ObjectLink"+'?CurrentValue&value="' +STR("Parameter:Point.ZeroScale") +'"'

The expression links the custom menu with the ObjectLink and CurrentValue parameters and is set to convert the current value of a point to a string. It then sets the value to the same value as the ZeroScale of the parameter source (which will be a point).

The engineer saves the ‘Pump’ Mimic and creates a new, blank Mimic. Next, the engineer adds an embedded version of the ‘Pump’ Mimic to the new Mimic. The embedded ‘Pump’ Mimic has the custom menu options of Increase Power 10, Decrease Power 10, Max Power and Min Power, but they are not associated with any database item.

To associate the custom menus with a point, the engineer selects the embedded ‘Pump’ Mimic so that it is highlighted. They then drag the required point from the Database Bar onto the ‘Pump’ Mimic, and a context sensitive menu is displayed.The engineer selects the Point option (which corresponds to the name of the parent group of parameters) and then selects the Configure All option. This associates the custom menu options on the embedded ‘Pump’ Mimic with the point’s FullScale, ZeroScale, CurrentValue and ObjectLink properties. When a user selects the options on the custom menu, they will increase or decrease the point’s value accordingly.

The engineer embeds the ‘Pump’ Mimic on other Mimics and associates the custom menus with a variety of other points. The embedded ‘Pump’ Mimics can be associated with any points as the custom menu pick actions have the Animate Parameter setting enabled.

Further Information

Pick Action Animations for Mimic Objects

Associating Mimic Objects with Pick Actions

Custom Pick Action Menus


Mimics Guide - Hyperlinks

Hyperlinks

Hyperlinks are special parts of a display that, when selected, cause another display to be shown. For example, a shape on a Mimic can be configured to act as a hyperlink to another Mimic. The Mimic that is to be displayed when the hyperlink is selected is referred to as the 'target'. When the shape is selected, the 'target' Mimic is displayed (either in place of the Mimic, or in a new window depending on the configuration of the hyperlink).

...causes another Mimic to be displayed.
Selecting a hyperlink on one Mimic...

In the following sections, we explain the concept of hyperlinks and 'chained' displays and describe how to create and use your own hyperlinks:

  • Understanding Hyperlinks and 'Chained' Displays
  • Using Drag and Drop to Create a Hyperlink
  • Using the Pick Action Wizard to Create a Hyperlink
  • Using Animations to Create a Hyperlink
  • Creating a Hyperlink to Another Mimic
  • Creating a Hyperlink to a Form
  • Creating a Hyperlink to a List
  • Creating a Hyperlink to an Alarms List
  • Creating a Hyperlink to a Trend or X-Y Plot
  • Creating a Hyperlink to a Logic Program
  • Creating a Hyperlink to a Schedule
  • Creating a Hyperlink that Displays in an Inset Window
  • Creating a Hyperlink to a File
  • Creating a Hyperlink to a Web Page
  • Creating a Hyperlink to a Crystal Report
  • Creating a Hyperlink to a ViewX ‘Document’ on Another ViewX Head
  • Animating a Symbol Object to Hyperlink to Another Display
  • Hyperlinks that Define Values for Mimic Parameters on a Target Mimic
  • Locating the Absolute Address of a Display.


Mimics Guide - Understanding Hyperlinks and 'Chained' Displays (Hyperlinks)

Understanding Hyperlinks and 'Chained' Displays

Hyperlinks are selectable areas of a Mimic that, when selected, cause other displays to be shown. Any object on a Mimic can be configured to act as a hyperlink.

When you display a Mimic, you can discover which parts of the Mimic are configured to act as hyperlinks by moving the cursor over the Mimic objects. When the cursor is positioned over a hyperlink object, the shape of the cursor changes from an arrow to a pointing finger.

When you select a hyperlink, the 'target' display is shown in place of the 'source' Mimic. The 'target' display is the display that is shown when the hyperlink is selected, and the 'source' Mimic is the Mimic that contains the hyperlink object. The 'target' display for a hyperlink is defined in the hyperlink configuration.

NOTE: If you are working on a WebX client, you can select hyperlinks to Mimics on other systems. However, the target Mimic will only be displayed if the appropriate server configuration for the system is in place (defined in the Server Configuration Tool’s WebX settings). The WebX settings allow ClearSCADA to determine which system contains the Mimic that is the target for the hyperlink. For more information, see Cross Database Hyperlinks for WebX Clients.

The 'target' display can be shown in:

  • the same window as the 'source' Mimic (it replaces the 'source' Mimic). This can be resized as required.
  • a new top-level window that is sized by the operating system.

NOTE: The new window will replace the current window if the User configuration is set to only support Single Document Interface only. The Single Document Interface setting is defined on the User Form (see User Accounts).

  • a new window with user defined proportions and a user defined anchor position. This type of window is referred to as an inset window and its proportions and position are defined in the hyperlink configuration.

Inset windows are 'children' of the 'parent' Mimic (the Mimic that contains the hyperlink that opens the inset window). They are displayed on top of the 'parent' Mimic and are closed if the 'parent' Mimic is closed.

When 'target' displays are set to be displayed in the same window as the 'source' Mimic, a navigation 'chain' can be formed. A 'chain' is a sequence of displays and can contain an unlimited number of displays.

As the window can only show one of the displays in the chain at once, you can use the navigation tools to move through the sequence of 'chained' displays. The Back and Forward tools allow you to move to the previous display and next display in a sequence respectively.

Example:

A Mimic named 'Pipe Line Overview' is displayed. It contains a hyperlink to a 'Water Tank' Mimic. When the user selects the hyperlink, the first link in the 'chain' is formed:

'Pipe Line Overview' - chained to - 'Water Tank'.

The Back button becomes available on the Operate toolbar

In this sequence, the 'Pipe Line Overview' Mimic is the first display that is viewed, and the 'Water Tank' Mimic is the second display that is viewed. When the 'Water Tank' Mimic is displayed via the hyperlink, the Back button becomes available. The user selects the Back button, and the window shows the previous display in the 'chain' (the 'Pipeline Overview' Mimic) in place of the current display (the 'Water Tank' Mimic).

When the 'Pipe Line Overview' Mimic is re-displayed, the Forward button becomes available. The user selects the Forward button and the window shows the next display in the 'chain' (the 'Water Tank' Mimic).

The Forward button becomes available on the Operate toolbar

The 'Water Tank' Mimic contains a hyperlink to a point's configuration Form. The user selects the hyperlink to the Form, and the Form is displayed in place of the 'Water Tank' Mimic. This creates a second link in the 'chain':

'Pipe Line Overview' - chained to - 'Water Tank' - chained to - 'Point Form'.

The user selects the Back button to return to the 'Water Tank' Mimic, then selects the Back button again to return to the 'Pipeline Overview' Mimic.

NOTE: The Back and Forward tools are available from the Operate toolbar.

Further Information

Configuring a Hyperlink on a Mimic.


Mimics Guide - Configuring a Hyperlink on a Mimic (Hyperlinks)

Configuring a Hyperlink on a Mimic

You can configure any Mimic object to act as a hyperlink 'trigger'—when the object is selected, ClearSCADA will show the 'target' display. Depending on the configuration of the hyperlink, the 'target' display will be shown in place of the Mimic or will be shown in a new window.

As with other aspects of Mimic configuration, you need to configure hyperlinks with the Mimic in Design mode (see Displaying a Mimic). When you have displayed a Mimic in Design mode, you need to select the object that is to act as the hyperlink 'trigger'. If the Mimic is empty, you will need to add an object of the required type (see Adding Objects to a Mimic).

When you have selected the 'trigger' object, you need to choose which method you are going to use to configure the hyperlink. There are three different ways to configure a hyperlink:

  • Using Drag and Drop to Create a Hyperlink
  • Using the Pick Action Wizard to Create a Hyperlink
  • Using Animations to Create a Hyperlink.

No matter which method you choose, when you configure the hyperlink, you will need to specify:

  • The location of the display that is to be shown when the hyperlink is selected (the 'target' display). The 'target' display can be another Mimic, a configuration Form, a List, a Trend, an X-Y Plot, or any other type of ClearSCADA display. The 'target' display can also be a Third Party Application display, such as a Microsoft Word document or could even be a web page.
  • How the 'target' display will be shown. You can set the 'target' display to be shown in place of the Mimic that contains the hyperlink (the 'source' Mimic) or in a new window.

You can also define a comment for the hyperlink. The comment can provide a brief description of the hyperlink so that users can understand its purpose. Typically, the comment provides an indication of what is shown when the hyperlink is selected.

For more information on configuring hyperlinks, see:

  • Creating a Hyperlink to Another Mimic
  • Creating a Hyperlink to a Form
  • Creating a Hyperlink to a List
  • Creating a Hyperlink to a Trend or X-Y Plot
  • Creating a Hyperlink to a Logic Program
  • Creating a Hyperlink to a Schedule
  • Creating a Hyperlink that Displays in an Inset Window
  • Creating a Hyperlink to a File
  • Creating a Hyperlink to a Web Page
  • Creating a Hyperlink to a Crystal Report
  • Cross Database Hyperlinks for WebX Clients
  • Animating a Symbol Object to Hyperlink to Another Display
  • Hyperlinks that Define Values for Mimic Parameters on a Target Mimic.


Mimics Guide - Using Drag and Drop to Create a Hyperlink (Hyperlinks)

Using Drag and Drop to Create a Hyperlink

You can use Windows' Drag and Drop functionality to add a new hyperlink to a Mimic. Creating a hyperlink in this way adds a new text box to the Mimic—the text box is automatically configured to hyperlink to another display.

You can use drag and drop to automatically configure a hyperlink for an existing Mimic object or a new text box:

  • Use Drag and Drop to Create a New Text Box Hyperlink
  • Use Drag and Drop to Create a Hyperlink for an Existing Mimic Object.

Use Drag and Drop to Create a New Text Box Hyperlink

To use drag and drop functionality to create a hyperlink in a new text box:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Either:
  1. In ViewX, use the Database Bar to locate the item that is the 'target' of the hyperlink. The 'target' display will be:
  • The graphical display for any item that is configured graphically, such as Pre-Configured Trends, X-Y Plots, Schedules, Mimics, Function Block Diagrams etc.
  • The configuration Form for any database item that is not configured graphically, for example, database points, channels, outstations etc.
  2. Select the item and keep the left-hand mouse button pressed down. Proceed to step 3.

Or:

  1. Use Windows Explorer to locate the file that is the 'target' display.
  2. Size the Windows Explorer window and the ViewX window so that you can drag the file icon from the Windows Explorer window onto the Mimic.
  3. Select the icon for the file. Keep the left-hand mouse button pressed down. Proceed to step 3.

Or:

  1. Use a web browser such as Internet Explorer to display the web page that is to be the 'target' display.
  2. Size the browser window and the ViewX window so that you can drag the file icon from the Address field on the browser onto the Mimic.
  3. Select the icon for the web page (in the browser's Address field). Keep the left-hand mouse button pressed down. Proceed to step 3.
  3. Drag the item onto the Mimic's design area, then release the left-hand mouse button.
    A context sensitive menu is displayed.
  4. Select the Hyperlink option.
    A new text box is added to the Mimic. It is automatically configured to act as a hyperlink to the display you selected in step 2.

You can alter the text in the text box and change its appearance in the same way as you would edit any other text box (see Editing a Text Box). You can also edit the animations that are in place for the hyperlink (see Text Box Animations). If you want to change the ToolTip for the hyperlink or set the 'target' display to be shown in a new window, use the Pick Action Configuration Wizard (see Using the Pick Action Wizard to Create a Hyperlink).

When the Mimic is displayed in Run mode, users will be able to select the hyperlink text box—when it is selected, the relevant 'target' display will be shown.

Use Drag and Drop to Create a Hyperlink for an Existing Mimic Object

To use drag and drop functionality to create a hyperlink for an object on a Mimic:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the Mimic object that is to act as the 'trigger' object for the hyperlink.
  3. Either:
  1. In ViewX, use the Database Bar to locate the item that is the 'target' of the hyperlink. The 'target' display will be:
  • The graphical display for any item that is configured graphically, such as Pre-Configured Trends, X-Y Plots, Schedules, Mimics, Function Block Diagrams etc.
  • The configuration Form for any database item that is not configured graphically, for example, database points, channels, outstations etc.
  2. Select the item and keep the left-hand mouse button pressed down. Proceed to step 3.

Or:

  1. Use Windows Explorer to locate the file that is the 'target' display.
  2. Size the Windows Explorer window and the ViewX window so that you can drag the file icon from the Windows Explorer window onto the Mimic.
  3. Select the icon for the file. Keep the left-hand mouse button pressed down. Proceed to step 3.

Or:

  1. Use a web browser such as Internet Explorer to display the web page that is to be the 'target' display.
  2. Size the browser window and the ViewX window so that you can drag the file icon from the Address field on the browser onto the Mimic.
  3. Select the icon for the web page (in the browser's Address field). Keep the left-hand mouse button pressed down. Proceed to step 3.
  4. Drag the item onto the Mimic's design area, then release the left-hand mouse button.
    A context sensitive menu is displayed.
  5. Select the Paste Hyperlink option.
    The selected Mimic object is configured to have a hyperlink to the display for the item you selected in step 3.
    Drag the 'target' display icon onto the selected Mimic object, then select the Paste Hyperlink option.

You can alter the settings for the object as required (see Editing Objects on a Mimic). You can also edit the animations that are in place for the hyperlink (see Animations). If you want to change the comment for the hyperlink or set the 'target' display to be shown in a new window, use the Pick Action Configuration Wizard (see Using the Pick Action Wizard to Create a Hyperlink).

When the Mimic is displayed in Run mode, users will be able to select the hyperlink text box—when it is selected, the relevant 'target' display will be shown.


Mimics Guide - Using the Pick Action Wizard to Create a Hyperlink (Hyperlinks)

Using the Pick Action Wizard to Create a Hyperlink

You can use the Pick Action Wizard to create a hyperlink. The Pick Action Wizard provides step-by-step instructions for creating a hyperlink.

The Pick Action Wizard provides a step-by-step configuration tool for hyperlinks (and other types of pick action).

To use the Pick Action Wizard to create a hyperlink:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Right-click on the Mimic object that is to act as the 'trigger' for the hyperlink. If the Mimic does not yet contain the object that you want to use as the 'trigger', you will need to create the object (see Adding Objects to a Mimic) and then right-click on it.
    A context sensitive menu is displayed.
  3. Select the Pick Action Wizard option to run the Pick Action Wizard.
  4. On the first 'page' of the Wizard, select the Hyperlink option, then select the Next button to proceed to the second 'page'.
  5. On the second 'page' use the URL field to select the 'target' display (the display that will be shown when the 'trigger' Mimic object is selected in Run mode. You can either enter the address of the display manually or you can use the browse button to locate the display.

If you are using the browse button, a context sensitive menu provides these options:

  • Link to Object—Select this option if you want to link to any ViewX display (Mimic, Trend, X-Y Plot, Schedule, Form etc.). When you select Link to Object, the Select Object browse window is displayed—use it to locate and select the object to which you want to link. If you select a database item that has a graphical display, the hyperlink will display the graphical interface; if you select a database item that does not have a graphical display, the hyperlink will display the Form for the item.

If you want to link to the Form of a database item that has a graphical display, you need to select the item on the Select Object browse window, select the OK button, and then edit the entry in the URL field on the Pick Action Wizard. When editing the entry, you need to remove the class of the item. For example, a hyperlink to a Mimic named 'Change Password' could be:

SCX:////CMimic/..Change Password

To change the hyperlink so that the Mimic's Form is the target, you need to remove the CMimic part of the entry:

SCX://///..Change Password

To remove the class of an item, you simply need to delete the class name which is usually C<type of database item>, for example, CGraph, CMimic, CXYPlot etc. If required, you can use the Database Schema to determine the class of a database item (see Working with the Database Schema in the ClearSCADA Guide to the Database).

If you select the Link to Object option, the Relative check box becomes available. Proceed to step 6.

  • Link to File—Select this option if you want to link to an external file such as a Microsoft Word document. When you select Link to File, a Link to File browse window is displayed. Use the Link to File browse window to locate the file to which you want to link, select the file, then select the Open button to confirm your choice.
    The address of the file is added to the URL field automatically. Proceed to step 7.
  • Link to Web Page—Select this option if you want to link to an Internet or Intranet page. When you select Link to Web Page, a browser runs. Use the browser to navigate to the required web page, then close the browser window. The address of the web page is automatically added to the URL field on the Pick Action Wizard.

If you know the address of the web page to which you want to link, it is quicker to enter the address in the URL field manually than to use the Link to Web Page option. The Link to Web Page option is useful when you are unsure of the address of the required page.

When you have selected the required web page, proceed to step 7.

NOTE: Clear the URL field so that it is empty before you select the Link to Web Page option.

  6. Use the Relative check box to define whether the hyperlink uses a relative or absolute reference. If you select the check box, the hyperlink uses a relative reference. This means that as long as the hierarchy between the Mimic that contains the 'trigger' object and the 'target' database item remains the same, the hyperlink will work. This means that the Mimic and the 'target' database item can be moved—as long as the hierarchy between the Mimic and the 'target' database item remain the same, the hyperlink will work.

If you clear the Relative check box, the hyperlink will use an absolute reference. This means that the hyperlink will only work if the Mimic that contains the 'trigger' object and the 'target' database item remain in exactly the same location. If the Mimic is moved or the 'target' database item is moved, the hyperlink will be broken.

NOTE: The Relative option is only applicable to links to items in the ClearSCADA database.

  7. Use the Mode combo box and Inset Position settings to define the type, size and location of the 'target' display:
  • Mode—Choose the required mode of navigation:
  • Navigate—The 'target' display will be shown in place of the 'source' Mimic (the Mimic that contains the 'trigger' object). The display window will remain at its current size. Proceed to step 8.
  • Navigate & Resize—The 'target' display will be shown in place of the 'source' Mimic (the Mimic that contains the 'trigger' object). The display window will be resized according to the dimensions you specify in the width and height spin-boxes.

Use the Height spin-box to define the vertical dimensions of the resized display window, and then use the Width spin-box to define the horizontal dimensions. When you have defined the dimensions, proceed to step 8.

  • Open in New Window—The 'target' display will be shown in a new window that overlays the window that contains the 'source' Mimic. The new window is sized automatically by the operating system. Proceed to step 8.
  • Open as Inset—The 'target' display will be shown in a new window that overlays the window that contains the 'source' Mimic. You can specify the size and location of the window.

Use the Left and Top spin-boxes to define the position of the new window. 0% is the top left-hand corner of the 'source' Mimic window. So, when you increase the percentages, the new window will be positioned further down/right accordingly. Use the Width and Height spin-boxes to change the horizontal and vertical dimensions of the window accordingly. Proceed to step 8.

  • Open as Inset (Relative)—The 'target' display is shown in a new window. The position of the window is relative to the position of the cursor when the 'trigger' object was selected.

The Open as Inset (Relative) option works in the same way as the Open as Inset option except that the cursor position defines 0% instead of the top left-hand corner of the 'source' Mimic. For example, if you set the inset window to be 50% of the 'source' Mimic's width and height and to have Left and Top settings of 10%, the 'target' Mimic will be displayed at 10% across and 10% down from the cursor position at the time the hyperlink was selected.

Proceed to step 8.

NOTE: Setting the Width or Height to 0% instructs the inset window to use the maintain the aspect ratio of the 'source' Mimic. For example, if you set the Height to 0% and the Width to 50%, the 'target' Mimic will retain the proportions of the 'source' Mimic (the 'target' Mimic will be half as wide and the height will be calculated so that the 'target' Mimic maintains the same proportions as the 'source' Mimic).

  8. Select the Next button to proceed to the third 'page' of the Pick Action Configuration Wizard.
  9. In the Pick Action Comment field, enter the text that will be displayed in the comment for the 'trigger' object. When a user positions the cursor over the 'trigger' object, a comment will be displayed in the status bar showing the text that you enter. For this reason, we recommend that you enter a brief description of the 'target' display or some indication as to which display the hyperlink targets.

NOTE: You can leave the description field blank if you wish. If you do not enter a description, a default description will be used instead.

  10. Select the Next button to proceed to the final 'page' of the Pick Action Configuration Wizard.
  11. If you are satisfied with the hyperlink configuration settings you have defined, select the Finish button to close the Pick Action Wizard and put the hyperlink configuration into effect.
    The Hyperlink configuration is complete.

When the Mimic is displayed in Run mode, users will be able to select the 'trigger' object on the Mimic—when it is selected, the relevant 'target' display will be shown.


Mimics Guide - Using Animations to Create a Hyperlink (Hyperlinks)

Using Animations to Create a Hyperlink

You can use the Animations window to create hyperlinks or adjust the existing hyperlink configuration to meet your needs. For example, if you have used drag and drop functionality to create a hyperlink, you can use the Animations window to alter the configuration of the drag and drop hyperlink so that it meets your requirements.

To use the Animations window to create hyperlinks, you need to have an understanding of Mimic Animations (see Animations).

To use the Animations window to create a hyperlink:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Right-click on the Mimic object that you want to animate (the object that is to act as the 'trigger'). If the Mimic does not yet contain the object that you want to use as the 'trigger', you will need to create the object (see Adding Objects to a Mimic) and then right-click on it.
    A context sensitive menu is displayed.
  3. Select the Animations option to display the Animations window. You can also display the Animations window by double-clicking on an object and then selecting the Animations button on the General tab.
  4. Select the PickParam property (this is the Mimic object property that determines which display the hyperlink 'targets').
  5. Select the Edit button.
    The Expression window is displayed.
  6. In the Expression field, enter the expression that will be used to access the target display.
  • For ViewX displays on the same system, you need to use the format:
'SCX:////<Class>/<Path>'

For example, 'SCX:////CMimic/Overview Mimic'. Do not enter the angle brackets < >.

NOTE: If the Relative check box is selected, you can use relative links to the 'target' display (see Relative References in the ClearSCADA Guide to Expressions).

  • For ViewX displays on a different system, you need to use the format:
'SCX:///<System Name>/<Class>/<Path>'

For example, 'SCX:///Main/CMimic/Overview Mimic'. Do not enter the angle brackets < >, and take care to use an absolute reference as links between systems can only use absolute references (see Absolute References in the ClearSCADA Guide to Expressions).

  • For web pages, you need to use the format:
'http://web site address'

For example, 'http://www.google.com'

NOTE: If you want to link to the Form of an item that has a graphical display, such as a Mimic, you have to edit the PickParam value so that the class part of the address is removed. For more information on classes, see Class Information in the ClearSCADA Guide to the Database.

  7. Select the OK button to confirm the expression and close the Expression window.
  8. Select the PickType property on the Animations window. The PickType property defines the type of pick action that is to be associated with the selected object. As you are creating a hyperlink, you need to set this property to a specific type of Hyperlink.
  9. Select the Edit button to display the Expression window.
  10. Enter the number that corresponds to the type of hyperlink you want to use:
  • 3—The target display is shown in the Mimic window in place of the Mimic.
  • 4—The target display is shown in a new inset window. The inset window will use the default size and position settings. You cannot use Animations to change the position and size of the window (to do this, you need to use the Pick Action Wizard).
  • 10—The target display is shown in a new top-level window.

NOTE: If the target display is a web page, the web page will be displayed in a browser, such as Internet Explorer.

  11. Select the OK button to close the Expression window and confirm your selection.
  12. Select the PickComment animation property. This property represents the information that is shown in the Status bar when the cursor is positioned over the 'trigger' object.
  13. Select the Edit button to display the Expression window.
  14. In the Expression field, enter the required text for the Status bar description. The text has to be enclosed in single quotes as it is a string value.
  15. Select the OK button to close the Expression window and confirm your entry.
  16. Close the Animations window.
  17. Save the Mimic.
    When you display the Mimic in Run Mode, positioning the cursor over the 'trigger' object will cause the defined text to be displayed in the Status bar and the ToolTip description in the ToolTip comment. When you select the 'trigger' object, the 'target' display will be shown (in a new window, inset window, or in place of the Mimic, depending on which number you entered as the expression for the PickType property).

NOTE: Steps 9-17 inclusive are optional.


Mimics Guide - Creating a Hyperlink to Another Mimic (Hyperlinks)

Creating a Hyperlink to Another Mimic

Any object on a Mimic can act as a 'trigger' for a hyperlink to another Mimic—when the object is selected, another Mimic is shown. The 'target' Mimic is the Mimic that is shown when the hyperlink is selected and it can be set to be displayed in the existing window or in a new window.

To create a hyperlink from one Mimic to another Mimic:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Use one of the following methods to configure the hyperlink:

Drag and Drop:

  1. In the Database Bar, select the 'target' Mimic's icon, then drag it onto the Mimic display.
    When you release the mouse button, a context sensitive menu is displayed.
  2. Select the Hyperlink option to add a text box to the Mimic.
    The text box is automatically configured to act as a 'trigger'—when it is selected, the 'target' Mimic will be displayed.

You can edit the text box in the same way as any other text box (see Editing a Text Box).

For more information, see Using Drag and Drop to Create a Hyperlink.

Pick Action Wizard:

  1. Right-click on the Mimic object that is to act as the 'trigger' for the hyperlink. If the Mimic does not yet contain the object that is to act as the 'trigger', you should add the object then right-click on it (see Adding Objects to a Mimic).
    When you right-click on the Mimic object, a context sensitive menu is displayed.
  2. Select the Pick Action Wizard option to run the Pick Action Wizard.
  3. Use the various 'pages' of the Pick Action Wizard to set the type of pick action to Hyperlink, define the URL of the 'target' Mimic, define where the 'target' Mimic will be displayed, and define a ToolTip for the 'trigger' object.

For more information, see Using the Pick Action Wizard to Create a Hyperlink.

Animations:

  1. Right-click on the Mimic object that is to act as the 'trigger' for the hyperlink. If the Mimic does not yet contain the object that is to act as the 'trigger', you should add the object then right-click on it (see Adding Objects to a Mimic). When you right-click on the Mimic object, a context sensitive menu is displayed.
  2. Select the Animations option to display the Animations window.
  3. Use the Animations window to define animations for these properties:
  • PickParam—Use an expression to define the location of the 'target' Mimic.
  • PickType—Enter 3, 4, 10, or 11 depending on the type of hyperlink you want to create.
  • PickComment—Enter a string that will be shown in the Status Bar when the cursor is positioned over the 'trigger' object. This is optional.
  • ToolTip—Enter a string that will be shown in the ToolTip comment when the cursor is positioned over the 'trigger' object. This is optional.
  4. Select the OK button to confirm the animations and close the Animations window.

For more information, see Using Animations to Create a Hyperlink.

  3. When you have configured the hyperlink, save the Mimic.

The hyperlink will be available when the Mimic is displayed in Run Mode. When the 'trigger' object is selected, the 'target' Mimic will be shown in the relevant window (defined by the type of hyperlink).

The procedure above explains how to create a hyperlink that displays the 'target' Mimic at its default size. You can link to a Mimic shown at it’s default size or to any of the Mimic's configured views. For more information, refer to Creating a Hyperlink to a Mimic Shown at a Specific Level of Magnification.

Further Information

To create a hyperlink to the configuration Form for a Mimic, see Creating a Hyperlink to a Form.

To create a hyperlink to a Mimic that is displayed in another ViewX session (i.e. on another head), see Creating a Hyperlink to a ViewX ‘Document’ on Another ViewX Head.


Mimics Guide - Creating a Hyperlink to a Mimic Shown at a Specific Level of Magnification (Hyperlinks)

Creating a Hyperlink to a Mimic Shown at a Specific Level of Magnification

You can create a hyperlink to a Mimic view (a specific area of a Mimic shown at a defined level of magnification). This is useful when you need to provide hyperlink to information shown on a specific part of a Mimic rather than the entire Mimic.

To create a hyperlink to a Mimic View:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Use one of the following methods to configure the hyperlink:

Drag and Drop:

  1. In the Database Bar, select the 'target' Mimic's icon, then drag it onto the Mimic display.
    When you release the mouse button, a context sensitive menu is displayed.
  2. Select the Hyperlink option to add a text box to the Mimic.
    The text box is automatically configured to act as a 'trigger'—when it is selected, the 'target' Mimic will be displayed.
  3. Right-click on the 'trigger' text box that you created in step ii.
    A context sensitive menu is displayed.
  4. Select the Animations option to display the Animations window.
  5. On the Animations window, select the PickParam property, then select the Edit button to display the Expression window.
  6. On the Expression window, add the following to the expression:
+'#View="<ViewName>"'

Where <ViewName> is the name of the Mimic View to which you want to link. Do not enter the angle brackets < >.

For example, if you want to link to the 'Pump62' View on a Mimic named 'PipeLine Overview' you would change the expression from:

".Pipeline Overview.ObjectLink"

to:

".Pipeline Overview.ObjectLink"+'#View="Pump62"'

  7. Select the OK button to confirm your entry and close the Expression window.
  8. Select the Close button to confirm your alterations and close the Animations window.
  9. Edit the text box as required (see Editing a Text Box), then proceed to step 3.

Pick Action Wizard:

  1. Right-click on the Mimic object that is to act as the 'trigger' for the hyperlink. If the Mimic does not yet contain the object that is to act as the 'trigger', you should add the object then right-click on it (see Adding Objects to a Mimic).
    When you right-click on the Mimic object, a context sensitive menu is displayed.
  2. Select the Pick Action Wizard option to run the Pick Action Wizard.
  3. Use the first 'page' of the Pick Action Wizard to set the type of pick action to Hyperlink, then select the Next button.
  4. Define the URL of the 'target' Mimic (for more information, see Using the Pick Action Wizard to Create a Hyperlink).
  5. When you have defined the URL, add the following to the end of the URL address:
#View="<ViewName>"

Where <ViewName> is the name of the Mimic View to which you want to link. Do not enter the angle brackets < >.

For example, if you want to link to the 'Pump62' View on a Mimic named 'PipeLine Overview' you would change the URL from:

SCX:////CMimic/.Pipeline Overview

to:

SCX:////CMimic/.Pipeline Overview#View="Pump62"

  6. Define the Mode and Inset Position as required (for more information, see Using the Pick Action Wizard to Create a Hyperlink).
  7. Select the Next button.
  8. Define the ToolTip comment as required (for more information, see Using the Pick Action Wizard to Create a Hyperlink).
  9. Select the Next button.
  10. Select the Finish button to confirm the configuration and close the Pick Action Wizard. Proceed to step 3.

Animations:

  1. Right-click on the Mimic object that is to act as the 'trigger' for the hyperlink. If the Mimic does not yet contain the object that is to act as the 'trigger', you should add the object then right-click on it (see Adding Objects to a Mimic). When you right-click on the Mimic object, a context sensitive menu is displayed.
  2. Select the Animations option to display the Animations window.
  3. On the Animations window, select the PickParam property, then select the Edit button to display the Expression window.
  4. On the Expression window, add the following to the expression:
+'#View="<ViewName>"'

Where <ViewName> is the name of the Mimic View to which you want to link. Do not enter the angle brackets < >.

For example, if you want to link to the 'Pump62' View on a Mimic named 'PipeLine Overview' you would change the expression from:

".Pipeline Overview.ObjectLink"

to:

".Pipeline Overview.ObjectLink"+'#View="Pump62"'

  5. Select the OK button to confirm your entry and close the Expression window.
  6. Select the Close button to confirm your alterations and close the Animations window. Proceed to step 3.
  3. Save the Mimic.

The hyperlink will be available when the Mimic is displayed in Run Mode. When the 'trigger' object is selected, the 'target' Mimic View will be shown in the relevant window (defined by the type of hyperlink).

When the hyperlink 'trigger' is selected...
...the 'target' Mimic View is displayed.


Mimics Guide - Creating a Hyperlink to a Form (Hyperlinks)

Creating a Hyperlink to a Form

You can create a hyperlink to the configuration Form of any database item, including those items that have graphical displays such as Mimics and Trends.

Select the 'trigger' object on a Mimic to...
...hyperlink to a configuration Form.

To create a hyperlink to a Form:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Either:
  • Use the drag and drop functionality to drag the 'target' database item from the Database Bar onto the Mimic. This will create a text box that is automatically configured to hyperlink to the database item's Form (unless the item has a graphical display, in which case you will need to use the Pick Action Wizard or Animations feature to alter the 'target' address - see the Note below).

For more information, see Using Drag and Drop to Create a Hyperlink.

  • Use the Pick Action Wizard to create a Hyperlink pick action that has its URL set to the database item associated with the Form.

For more information, see Using the Pick Action Wizard to Create a Hyperlink.

  • Use the Animations feature to set the value of the PickParam to the address of the database item associated with the Form.

For more information, see Using Animations to Create a Hyperlink.

NOTE: To hyperlink to the Form of an item that has a graphical display, such as a Mimic or Trend, you have to remove the class part of the address from the URL on the Pick Action Wizard or the PickParam value on the Animations window.

  3. Save the Mimic.


Mimics Guide - Creating a Hyperlink to a List (Hyperlinks)

Creating a Hyperlink to a List

You can create hyperlinks to Queries Lists. This is useful when a Mimic needs to provide access to a specific list of information, for example, a List of points that relate to the data shown on the Mimic.

To create a hyperlink to a List:

  1. Use the Queries Bar to display the List to which you want to link (for more information, see the ClearSCADA Guide to Lists).
  2. Apply any filtering and sorting that is required (for more information, see the ClearSCADA Guide to Lists)
  3. Select the Edit menu, then select the Copy Shortcut option. This copes a shortcut to the List to your PC's clipboard storage area.
  4. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  5. Right-click on the Mimic and select the Paste option from the context sensitive menu. Alternatively, select the Edit menu and then select the Paste option.
    A text box is added to the Mimic. It is automatically configured to act as a hyperlink to the List you displayed in step 1.

If you want to use the text box as the hyperlink 'trigger', simply edit the text box as required (see Editing a Text Box), then proceed to step 6.

If you want to use a different type of Mimic object as the 'trigger:

  1. Right-click on the text box and select the Pick Action Wizard option from the context sensitive menu.
    The Pick Action Configuration Wizard is displayed.
  2. Select the Next button to access the second 'page' of the Pick Action Wizard.
  3. Highlight the entry in the URL field. You need to highlight the entire entry. (The URL entry contains a link to the List in the correct format and also includes the SQL Query that defines the criteria for the information that is shown on the List).

The entry in the URL field uses the following syntax:

SCX:///<system>/List/Title="<title>"&InitialSQL="<SQL>"

Where:

  • <system> is the name of your system (the angle brackets are not included). It can be omitted when relative links are being used.
  • <title> is the title of the List (the angle brackets are not included). The title is optional., but we recommend that you define a suitable title otherwise the default title of 'Query' will be used.

If the SQL contains quotes ("), you need to insert additional quotes so that the sequence uses two quotes (""), for example, InitialSQL="SELECT ""FullName"" FROM CDBObject".

  4. Right-click to display a context sensitive menu, then select the Copy option. This copies the URL to your computer's clipboard storage area.
  5. Close the Pick Action Wizard.
  6. Right-click on the Mimic object that is to act as the 'trigger' for the hyperlink. If the Mimic does not yet contain the object that is to act as the 'trigger', you should add the object then right-click on it (see Adding Objects to a Mimic). When you right-click on the Mimic object, a context sensitive menu is displayed.
  7. Select the Pick Action Wizard option to run the Pick Action Configuration Wizard.
  8. On the first 'page' of the Wizard, select the Hyperlink option, then select the Next button.
  9. On the second 'page' of the Wizard, right-click in the URL field and then select the Paste option from the context sensitive menu.
    The address for the List that you displayed in step 2 is added to the URL field. It contains the SQL Query that specifies what information is displayed on the List.
  10. Define the Mode and Inset Position as required (for more information, see Using the Pick Action Wizard to Create a Hyperlink).
  11. Select the Next button.
  12. Define the ToolTip comment as required (for more information, see Using the Pick Action Wizard to Create a Hyperlink).
  13. Select the Next button.
  14. Select the Finish button to confirm the configuration and close the Pick Action Wizard. Proceed to step 6.
  6. Save the Mimic.

When the Mimic is displayed in Run mode, the text box or other type of Mimic object that you configured will act as a 'trigger' for the hyperlink—when it is selected, the List is displayed.

Select the 'trigger' object on a Mimic to...
...hyperlink to a List.

NOTE: Alternatively, you can use the Animations window to configure a hyperlink to a List. To do this, you would need to paste the URL from the text box that was created in step 5 into the expression for the PickParam animation property. You would also need to edit the expression so that it formed a string of the correct format. Using the Pick Action Wizard is the recommended method for creating hyperlinks to Lists as it is quicker and easier to configure.


Mimics Guide - Creating a Hyperlink to an Alarms List (Hyperlinks)

Creating a Hyperlink to an Alarms List

You can create hyperlinks to an Alarms List. This is useful when a Mimic needs to provide access to alarm data for multiple items.

To create a hyperlink to an Alarms List:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Right-click on the Mimic object that you want to animate (the object that is to act as the 'trigger'). If the Mimic does not yet contain the object that you wish to use as the 'trigger', you will need to create the object (see Adding Objects to a Mimic) and then right-click on it.
    A context sensitive menu is displayed.
  3. Either:
  • Select the Pick Action Wizard option to run the Pick Action Wizard.

Or:

  • Select the Animations option to display the Animations window.
  4. Use the Pick Action Wizard or Animations window to configure the hyperlink to the Alarms List:

Pick Action Wizard:

Set the pick action to work as a Hyperlink, then on the second 'page' enter the syntax for the Alarms List in the URL field. When you have entered the URL, proceed through the steps of the Pick Action Wizard in the same way as for other types of hyperlink (see Using the Pick Action Wizard to Create a Hyperlink).

The syntax you need to use is:

SCX:///<system>/AlarmList/<filter1>="<value1>"&<filter2>="<value2>"

Where:

  • <system> is the name of your system. This can be omitted for relative links as required. Do not enter the angle brackets <>. If you want to include multiple systems, use the * character instead of the system name.

If you use the * character to include multiple systems, you have to qualify each option with the system name as each system has its own filter. For example, System1.Area="Group 1"&System2.Area="Group 2".

  • <filter1> is the name of the first filter condition that you want to apply. You can use any of the following filter conditions: AlarmState, AOI, Assigned, Categories, MaxSeverity, MinSeverity, and Source. For more information on these conditions, see Alarm Filter String Syntax in the ClearSCADA Guide to Alarms.
  • <value1>—Represents the criteria that has to be met for the first filter condition. The value has to be enclosed in double quotation marks " ". Do not enter the angle brackets < >.
  • &—Use the ampersand character (&) to add another filter condition.
  • <filter2>—Represents the second filter. Do not enter the angle brackets < >.
  • <value2>—Represents the value for the second filter. The value has to be enclosed in double quotation marks " ". Do not enter the angle brackets < >.

NOTE: You can add extra filters and values by using the ampersand character &. For example, <filter 3>="<value3>"&<filter4>="<value4>" and so on.

Example:

The following entry filters the Alarms List so that it only shows alarms for a point named 'AI1' that is stored in a Group named 'Main Site' on a System named 'CentralPipeline'. The Alarms List only includes alarms that are within the severity range 200-800 (the meaning of these values is defined in the server configuration - see Alarm and Event Severities in the ClearSCADA Guide to Server Administration).

SCX:///CentralPipeline/AlarmList/Area="Main Site"&Source="AI1"&MinSeverity="200"&MaxSeverity="800"

Animations:

  1. On the Animations window, select the PickType property, then select the Edit button to display the Expression window.
  2. Enter the number for the required type of hyperlink (3, 4, 10, or 11). For more information, see Using Animations to Create a Hyperlink.
  3. Select the OK button to confirm your entry and close the Expression window.
  4. On the Animations window, select the PickParam property, then select the Edit button to display the Expression window.
  5. On the Expression window, define the filter for the Alarms List using the following syntax:
'SCX:///<system>/AlarmList/<filter1>="<value1>"&<filter2>="<value2>"'

The syntax for the PickParam animation is exactly the same as the syntax required when using the Pick Action Wizard (see the description earlier in this section), except that the entry has to be enclosed in single quotation marks ' ' as it is an expression.

  6. Select the OK button to confirm your entry and close the Expression window.
  7. Close the Animations window.
  5. Save the Mimic.

When the Mimic is displayed in Run mode, selecting the 'trigger' object will activate the hyperlink and display the Alarms List. The Alarms List will use the filter conditions that are defined in the URL field (on the Pick Action Wizard) or PickParam animation for the 'trigger' object.

Further Information

Default Alarm Filters: see Specify a Default Alarm Filter in the ClearSCADA Guide to Alarms.


Mimics Guide - Creating a Hyperlink to a Trend or X-Y Plot (Hyperlinks)

Creating a Hyperlink to a Trend or X-Y Plot

You can create hyperlinks to Trends and X-Y Plots. This is useful when a Mimic needs to provide access to information that is shown on a graph (where an embedded Trend or X-Y plot is inappropriate).

The method(s) that you can use to create hyperlinks to Trends partially depends on the type of Trend. For information on the types of Trend that ClearSCADA supports, see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends.

To create a hyperlink to a pre-configured Trend or an X-Y Plot:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Either:
  • Use the drag and drop functionality to drag a Pre-Configured Trend or X-Y Plot from the Database bar onto the Mimic, then select the Hyperlink option (see Using Drag and Drop to Create a Hyperlink).

Or:

  • Use the Pick Action Wizard to create a hyperlink to a Pre-Configured Trend or X-Y Plot (set the pick action to Hyperlink and use the Link to Object option to select the required Trend or X-Y Plot). For more information, see Using the Pick Action Wizard to Create a Hyperlink.

Or:

  • Use the Animations feature to create a hyperlink (set the PickParam value to the address of a Pre-Configured Trend or X-Y Plot and set the PickType to 3, 4, 10, or 11 depending on the type of hyperlink you require). For more information, see Using Animations to Create a Hyperlink.
  3. Save the Mimic.

To create a hyperlink to a ‘standard’ ad hoc Trend:

  1. Use the point or master station accumulator’s Display Current Trend or Display Historic Trend pick action to display the required ad hoc Trend (see Display an Ad Hoc Trend in Run Mode in the ClearSCADA Guide to Trends).
  2. Select the Edit menu from in the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Copy Shortcut option.
  4. Display the Mimic that is to contain the hyperlink to the ad hoc Trend. You need to display the Mimic in Design mode (see Displaying a Mimic).
  5. Either:
  • Paste the contents of the clipboard onto the Mimic.
    A text box is added to the Mimic. It is automatically configured to act as a hyperlink to the ad hoc Trend.

or:

  • Use the Pick Action Wizard to create a hyperlink to the ad hoc Trend (set the pick action to Hyperlink and paste the contents of the clipboard into the URL field). For more information, see Using the Pick Action Wizard to Create a Hyperlink.
  6. Save the Mimic.

With a ‘custom’ ad hoc Trend, you produce the Trend’s definition using ClearSCADA’s proprietary specification language, TrendSpec (see Using TrendSpec to Produce Ad Hoc Trends in the ClearSCADA Guide to Trends).

To create a hyperlink to a ‘custom’ ad hoc Trend:

  1. Display the Mimic that is to contain the hyperlink to the ad hoc Trend. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Either:
  1. Use the Pick Action Wizard to create a hyperlink to the ad hoc Trend (set the pick action to Hyperlink and paste the TrendSpec definition into the URL field). You need to include the SCX:////Trend/ prefix before the start of the definition in the URL field. For an example that demonstrates the type of content that might be included in an URL field, see Use TrendSpec to Define an Ad Hoc Trend’s Colors in the ClearSCADA Guide to Trends.

or:

  1. Include the TrendSpec definition as a script subroutine on a Mimic that has the Script feature enabled.
  2. Use the Pick Action Wizard to create a hyperlink to run the script (set the pick action to Script and specify the name of the Script subroutine in the Function field).

For information on writing Mimic scripts, see Mimic Scripts in the ClearSCADA Guide to Scripting. For examples of TrendSpec definitions, including definitions used in Mimic scripts, see Example Configuration in the ClearSCADA Guide to Trends.

  3. Save the Mimic.

When the Mimic is displayed in Run Mode, selecting the 'trigger' object will cause the 'target' Trend or X-Y Plot to be displayed in a new window or in place of the currently displayed Mimic (depending on the type of hyperlink you have configured).

Select the 'trigger' object on a Mimic to...
...hyperlink to an X-Y Plot (or Trend as required).

NOTE: If you want to link to the Form of a Pre-Configured Trend or X-Y Plot instead of the graphical display, see Creating a Hyperlink to a Form.


Mimics Guide - Creating a Hyperlink to a Logic Program (Hyperlinks)

Creating a Hyperlink to a Logic Program

You can create hyperlinks to Logic programs such as ST Programs and Function Block Diagrams. This is useful on Mimics that show information that is related to the calculations and functionality that is provided by Logic programs.

To create a hyperlink to a Logic program:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Either:
  • Use the drag and drop functionality to drag the Logic program from the Database bar onto the Mimic, then select the Hyperlink option (see Using Drag and Drop to Create a Hyperlink).

Or:

  • Use the Pick Action Wizard to create a hyperlink to the Logic program (set the pick action to Hyperlink and use the Link to Object option to select the required Logic program). For more information, see Using the Pick Action Wizard to Create a Hyperlink.

Or:

  • Use the Animations feature to create a hyperlink (set the PickParam value to the address of the Logic program and set the PickType to 3, 4, 10, or 11 depending on the type of hyperlink you require). For more information, see Using Animations to Create a Hyperlink.
  3. Save the Mimic.

When the Mimic is displayed in Run Mode, selecting the 'trigger' object will cause the 'target' Logic program to be displayed in a new window or in place of the currently displayed Mimic (depending on the type of hyperlink you have configured).

NOTE: If you want to link to the Form of a Logic program instead of the graphical display, see Creating a Hyperlink to a Form.


Mimics Guide - Creating a Hyperlink to a Schedule (Hyperlinks)

Creating a Hyperlink to a Schedule

You can create hyperlinks to a schedules as required. When the hyperlink is selected, the graphical display for the schedule is displayed. (You can also create hyperlinks to the Forms for schedules, see Creating a Hyperlink to a Form).

To create a hyperlink to a schedule:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Either:
  • Use the drag and drop functionality to drag the Schedule item from the Database bar onto the Mimic, then select the Hyperlink option (see Using Drag and Drop to Create a Hyperlink).

Or:

  • Use the Pick Action Wizard to create a hyperlink to the Schedule (set the pick action to Hyperlink and use the Link to Object option to select the required Schedule). For more information, see Using the Pick Action Wizard to Create a Hyperlink.

Or:

  • Use the Animations feature to create a hyperlink (set the PickParam value to the address of the Schedule and set the PickType to 3, 4, 10, or 11 depending on the type of hyperlink you require). For more information, see Using Animations to Create a Hyperlink.
  3. Save the Mimic.

When the Mimic is displayed in Run Mode, selecting the 'trigger' object will cause the 'target' Schedule to be displayed in a new window or in place of the currently displayed Mimic (depending on the type of hyperlink you have configured).

Select the 'trigger' object on a Mimic to...
...hyperlink to a schedule.

NOTE: If you want to link to the Form of a Schedule instead of the graphical display, see Creating a Hyperlink to a Form.


Mimics Guide - Creating a Hyperlink that Displays in an Inset Window (Hyperlinks)

Creating a Hyperlink that Displays in an Inset Window

You can configure a hyperlink so that it causes the 'target' display to be shown in a new window rather than in place of the 'source' Mimic. If the new window is repositioned or resized, it is referred to as an inset window.

You can create a hyperlink that displays the 'target' in a new window by using the Pick Action Wizard (see Using the Pick Action Wizard to Create a Hyperlink) or Animations (see Using Animations to Create a Hyperlink). However, you can only alter the size and position of the inset window by using the Pick Action Wizard.


Mimics Guide - Creating a Hyperlink to a File (Hyperlinks)

Creating a Hyperlink to a File

You can create hyperlinks to Third Party files, such as Microsoft Word documents, Microsoft Excel Spreadsheets etc. This is useful when you need a Mimic to provide access to additional information that is stored outside your ClearSCADA system, for example, you could have a hyperlink to policy documents.

To create a hyperlink to a file:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Use the Pick Action Wizard to create a hyperlink to the file (set the pick action to Hyperlink and use the Link to File option to select the required file). For more information, see Using the Pick Action Wizard to Create a Hyperlink.
  3. Save the Mimic.

When the Mimic is displayed in Run Mode, selecting the 'trigger' object will cause the 'target' file to be displayed. The 'target' file will run in a new window (the application associated with the file will run, for example, for a Word document, Microsoft Word will run and display the 'target' file).


Mimics Guide - Creating a Hyperlink to a Web Page (Hyperlinks)

Creating a Hyperlink to a Web Page

You can create hyperlinks to web pages. This is useful when you need a Mimic to provide access to information that is stored on a company Intranet or on the Internet.

To create a hyperlink to a web page:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Either:
  • Display the required web page in a web browser application such as Microsoft Internet Explorer, then drag the icon next to the Address of the web page from the browser window onto the Mimic. This creates a text box that is configured to act as a hyperlink to the web page. You can edit the text box as required (see Editing a Text Box).

Or:

  • Use the Pick Action Wizard to create a hyperlink to the web page (set the pick action to Hyperlink, then select the Link to Web Page option and use the browser window to display the required web page). For more information, see Using the Pick Action Wizard to Create a Hyperlink.
  3. Save the Mimic.

When the Mimic is displayed in Run Mode, selecting the 'trigger' object will cause the 'target' web page to be displayed. The 'target' web page will run in a new browser window.

Select the 'trigger' object on the Mimic...
...to display the 'target' web page in a Third Party browser window.


Mimics Guide - Creating a Hyperlink to a Crystal Report (Hyperlinks)

Creating a Hyperlink to a Crystal Report

You can create hyperlinks to Crystal Reports. This is useful when you need a Mimic to provide access to information that is stored in a report, such as statistics.

To create a hyperlink to a Crystal Report:

  1. Display the Mimic that is to contain the new hyperlink. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Use the Pick Action Wizard to create a hyperlink to the Crystal Report:
  1. Set the pick action to Hyperlink then select the Next button.
  2. In the URL field, select the browse button then select the Link to Object option.
  3. Use the browser window to select the required Crystal Report item.
  4. Adjust the entry in the URL field as follows:

For the latest report, add the following to the end of the URL entry:

?latest

For a report generated on a specific date, add the following to the end of the URL entry:

?file=<date> <time>

Where:

<date> is the date on which the report was generated and has to use the following format:

dd/MM/yyyy

<time> is the time at which the report was generated. The <time> has to be in Universal Co-ordinated Time (UTC) and has to use the following syntax:

HH/mm/ss.SSS

Do not enter the angle brackets < >. You need to use the forward slash character instead of the colon character when separating the time elements.

NOTE: The time and date hyperlink can only be used if the Crystal Report has Historic enabled in its configuration. If Historic is not enabled, the Mimic can only contain a hyperlink to the latest report.

Example:

If the Crystal Report item was named 'Electricity Usage' and the latest report was required, the URL would be set to:

SCX:////CCrystalReport/Electricity Usage?latest

This would create a hyperlink to the most recently generated report for the 'Electricity Usage' Crystal Report.

If the user required a report that was generated at 10:16:35 on November 1st 2006, the URL would be set to:

SCX:////CCrystalReport/Electricity Usage?file=01/11/2006 10/16/35

  5. Proceed through the remaining steps of the Pick Action Wizard (see Using the Pick Action Wizard to Create a Hyperlink).
  3. Save the Mimic.

NOTE: You can also configure a hyperlink to a Crystal Report by using the animations feature (see Using Animations to Create a Hyperlink). To do this, simply enter the URL as described in step iv as the value for the 'trigger' object's PickParam property and set the PickType to 3, 4, 10, or 11 as required.

Further Information

Time Zone Settings: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Mimics Guide - Creating a Hyperlink to a ViewX 'Document' on Another ViewX Head (Hyperlinks)

Creating a Hyperlink to a ViewX ‘Document’ on Another ViewX Head

You can configure a Mimic so that it has hyperlinks that, when selected, cause a display to be shown on a specified head. This type of hyperlink can be useful on multi-head clients (where a client PC has been configured to use more than 1 monitor), as you can select a hyperlink on a Mimic shown on one monitor and the target display is shown in a ViewX session running on a different monitor.

You can use a hyperlink to display any of the following ViewX displays on another head:

  • Mimics
  • Lists
  • Forms
  • Alarm Lists
  • Trends
  • X-Y Plots
  • Logic Programs
  • Schedules
  • Reports
  • Time Profiles
  • Script Libraries
  • Calendars
  • Value Maps
  • Alarm Action Rosters
  • Alarm Action Calendars
  • Data Grids
  • Data Tables
  • Crystal Reports.

NOTE: Some Drivers also have driver-specific ‘documents’ that can be used as ‘target’ displays for hyperlinks.

To create a hyperlink that causes a display to be shown on another head, you need to configure a Script pick action that uses Execute Code Fragment mode. As part of the configuration for the pick action, you will need to define code that instructs ViewX to display a specified display on a specified head. The following procedure explains how to create such a hyperlink:

  1. Log on to ViewX via a User account that has the Configure permission for the Mimic that is to contain the hyperlink. We will refer to this Mimic as the ‘Source’ Mimic.

NOTE: You can use a single head client to create a hyperlink to a display on another head, but to test your hyperlink works as expected, you will need to use a multi-head client.

  2. Display the Mimic in Design Mode (see Displaying a Mimic)
  3. Either add a new Mimic object and select it or select an existing Mimic object. The object you select will contain the hyperlink (when you select it in Run Mode, it will cause the ‘target’ display to appear on another head).
  4. Right-click on the selected Mimic object, then select the Pick Action Wizard option to display the Pick Action Wizard.
  5. On the first page of the Pick Action Wizard, select Script, then select Next.
  6. On the second page of the Pick Action Wizard, set the Mode to Execute Code Fragment, then enter the following code in the Code field:
App.OpenWindowOnHead n,"<Absolute reference to target display>"

Where:

  • n is the number of the head (monitor) on which you want the target display to be shown.
  • <Absolute reference to target display> is an absolute reference to the ViewX ‘document’ that is to be the ‘target’ display. The absolute reference has to include the system name and should not include the angled brackets < >.

For more information on finding out the absolute reference for a display, Locating the Absolute Address of a Display.

  7. Use the Permission setting to define the security permission required to select the pick action that you are configuring.
  8. Select the Next button.
  9. Enter a Pick Action Comment if required
  10. Select the Next button, then select the Finish button.
    The Pick Action Wizard is closed.

When you display the Mimic in Run Mode, you will be able to select the Mimic object to trigger the pick action. If configured correctly, this will cause the target display to be shown in another instance of ViewX on the specified head. If the specified head is not already displaying an instance of ViewX, a new instance of ViewX will run automatically.

NOTE: The client heads are displayed in the last known position of the heads, for example, if head 2 was last displayed shown at 50% size in the top right of a second monitor, that is where any target displays for head 2 will be shown. If ViewX has not been displayed on the heads before, ViewX will attempt to calculate the position of the ViewX instances by using the head information in the operating system. If the positioning is incorrect, you can correct it by moving the displays to the required position and then closing them. The next time they are displayed, they will be shown in the position you selected.

Example:

A ViewX client is set up to have 2 heads, each running a ViewX session. In Windows, the heads are recognized as Head 1 and Head 2 (for this example, we will assume Head 1 is the left-hand side monitor).

A user logs on and displays a Mimic named ‘ControlA1’ on Head 1. The user configures the ‘ControlA1’ Mimic so that is has a hyperlink that, when selected in Run Mode, will cause a Mimic named ‘Sector8C’ to be displayed on Head 2. The ‘Sector8C’ Mimic is stored on a system called ‘MAIN’ and in a Group named ‘Power Switches’.

To configure the hyperlink, the user selects a suitable object on the ‘ControlA1’ Mimic and displays the Pick Action Wizard for that object. They then configure a Script pick action that is set to Execute Partial Code. They define the code as:

App.OpenWindowOnHead 2,"SCX:///MAIN/CMimic/Power Switches.Sector8C"

The App.OpenWindowOnHead 2 part of the code instructs ClearSCADA to display the defined target display in a ViewX session on Head 2. If Head 2 is not already running a session of ViewX, a new session will be started when the hyperlink is selected.

The comma separates the function command from the definition of the target display. The code enclosed in double quotes " " defines the target display and is an absolute reference that includes the system name and database class (in this case MAIN and CMimic respectively).

The user completes the pick action configuration and then displays the ‘ControlA1’ Mimic in Run Mode. They select the object with the pick action, which causes the ‘Sector8C’ Mimic to be displayed on Head 2 (the right-hand side monitor).


Mimics Guide - Cross Database Hyperlinks for WebX Clients (Hyperlinks)

Cross Database Hyperlinks for WebX Clients

If you are working on a WebX client, you can display Mimics that contain hyperlinks to displays on multiple systems. For example, you may display a Mimic that contains one hyperlink to an item that is stored on the system on which you are working and another hyperlink to an item that is stored on a different system.

However, if a Mimic contains hyperlinks to displays on another system, the hyperlinks will only work if the appropriate Cross Database Hyperlinks settings are in place. The Cross Database Hyperlinks settings allow you to specify the node name and port numbers of the server that contains the 'target' display. With the correct settings in place, the ClearSCADA server can use the information contained in the hyperlink to determine which server contains the 'target' display.

To configure the Cross Database Hyperlinks settings, you need to use the Server Configuration Tool. The appropriate settings have to be in place on the server to which the WebX client(s) connect. There is no special configuration required for the hyperlinks themselves (they are configured in the same way as a hyperlink to a display that is stored on the local system).

For more information on configuring the Cross Database Hyperlinks settings, see Define the Cross-Database Hyperlinks Settings in the ClearSCADA Guide to Server Administration.


Mimics Guide - Animating a Symbol Object to Hyperlink to Another Display (Hyperlinks)

Animating a Symbol Object to Hyperlink to Another Display

You can use parameters to animate a symbol object so that it acts as a hyperlink to another display. The value of the parameter defines the location of the display that is to be shown when the object is selected (the 'target' display).

To configure a Symbol object to act as a hyperlink, you need to edit the expression for the symbol object's PickParam animation so that it is:

"Parameter:<Parameter Name>"

Where:

  • <Parameter Name> matches the name of a parameter that you have created for the Mimic. The value of the named parameter defines the location of the 'target' display.

To animate a symbol object to act as a hyperlink:

  1. Configure a group parameter (select the Edit menu, then Parameters, then Add, then define the name of the parameter and select the Group check box). The name of the group parameter will be an option that you can use to select the required expression so it is better to define a suitable name.
  2. Configure a child parameter named ObjectLink. The ObjectLink parameter has to be a child of the group parameter that you created in the previous step. It also has to be named ObjectLink as this is the property that links the pick action menu of an item to the symbol.
  3. Double click on the symbol object to display its Polyline Properties window.
  4. On the General tab, select the Animations button to display the Animations window.
  5. Select the PickParam property on the Animations window.
  6. Select the Edit button to display the Expression window.
  7. Select the browse button to display a context sensitive menu.
  8. Select the option that is named the same as the group parameter you created in step 1.
    A further menu is displayed.
  9. Select the ObjectLink option.
    The correct expression is shown in the Expression field.

This links the symbol object with the ObjectLink property of any item that is associated with the symbol. Each database item has an ObjectLink property that contains a location address (in the ClearSCADA format). So, when you embed the symbol on a Mimic, you can drag any database item from the Database Bar onto the symbol and associate its ObjectLink property with the symbol object's ObjectLink parameter.

  10. Select the OK button to confirm the expression and close the Expression window.
  11. Select the PickType property.
  12. Select the Edit button to display the Expression window.
  13. Enter the number for the required PickType. For a hyperlink, the number is 3, 4, 10, or 11 depending on the type of hyperlink you require. The types of hyperlink are explained in Using Animations to Create a Hyperlink.
  14. Select the OK button to confirm the expression and close the Expression window.
  15. Close the Animations window.

The symbol object is now configured to act as a hyperlink. It will link to any display that is associated with the named parameter (see Animating Mimic Parameters on an Embedded Mimic).


Mimics Guide - Hyperlinks that Define Values for Mimic Parameters on a Target Mimic (Hyperlinks)

Hyperlinks that Define Values for Mimic Parameters on a Target Mimic

You can create a hyperlink that links to another Mimic and also defines a value for one of the target Mimic's parameters. This is useful when you want to manipulate the target Mimic and link to it with a single command. For example, you can create a hyperlink from one Mimic to another Mimic that contains an Alarms List. The target Mimic has parameters that define the filter criteria for the embedded Alarms List (the filter changes according to the value of the Mimic parameter). When the hyperlink is selected on the source Mimic, not only is the target Mimic displayed, but also a parameter value is defined for the target Mimic's parameters. So by selecting the hyperlink, a user can access the embedded Alarms List on the target Mimic and also apply a specific filter (the filter is defined by the parameter value that is included in the hyperlink).

When creating a hyperlink that defines a value for a Mimic parameter on another Mimic, check that the parameters on the target Mimic are configured correctly (see Mimic Parameters). You should also check that the hyperlink pick action uses this format:

SCX:////<System>/<Class>/<Location of Target Mimic>#<Mimic Parameter Name>= "<Mimic Parameter Value>"

Where:

<System> is the name of the system that contains the target Mimic. The system part of the entry can be left blank if the target Mimic is on the same system as the Mimic that contains the hyperlink.

<Class> is the database class that stores the target Mimic. Mimics are stored in the CMimic class, so the class will be CMimic for hyperlinks to other Mimics.

<Location of Target Mimic> is the location of the target Mimic in the database structure. This is the full address of the Mimic and includes Groups etc. However, you can also set the location to use a relative reference by altering the location manually: replace each level of Group with a period. For more information, see Relative References in the ClearSCADA Guide to Expressions.

# indicates that the remainder of the hypertext string defines parameter settings. The part of the string that defines the parameter settings is called a fragment and is sometimes referred to as the location. To avoid confusion with the location of the target Mimic, we will refer to the second part of the string as the fragment.

<Mimic Parameter Name> is the name of the parameter on the Target Mimic that is to have a value defined for it by the hyperlink. When the hyperlink is selected, the target Mimic will be displayed and a specific value will be defined for the selected parameter on the target Mimic. The name of the Mimic parameter you define in the link has to match the name of the required parameter on the target Mimic exactly.

= indicates that the remainder of the hypertext string defines the value for the parameter setting.

"<Mimic Parameter Value>" defines the value that is to be used as the value for the selected Mimic parameter. The value has to be enclosed in double quotes as the value is a string. If more than one parameter is required, use an ampersand & after each parameter, with each parameter in double quotation marks. For example, #Group= "PLCs" & PointName= "Analog Point 1" would set a value of PLCs for the Group parameter and a value of Analog Point 1 for the PointName parameter.

Do not include the angle brackets < > for any part of the hyperlink definition.

Example:

In this example, we have 2 Mimics that are both stored in a Group named 'Outstations'. One of the Mimics is named 'Overview' and the other Mimic is named 'Outstation Alarms'.

The 'Outstations' Group also contains 2 sub-Groups, one named 'Outstation 1 Points' and the other named 'Outstation 2 Points'. Both of these sub-Groups contain 2 points. Each point has one uncleared unacknowledged alarm raised.

Each of these points has an unacknowledged uncleared alarm.

The 'Overview' Mimic is configured to have three buttons:

The 'Outstation Alarms' Mimic is configured to have a title text box and an embedded Alarms List:

The Following Parameters are configured for the 'Outstation Alarms' Mimic (via the Edit>Parameters menu option):

  • Parameter Name: Group
  • Parent: None
  • Hint: None
  • Default Value: Outstations
  • Parameter Name: Title
  • Parent: None
  • Hint: None
  • Default Value: Outstation Alarms

The Title parameter is associated with the title text box on the Mimic by dragging the Title parameter from the Parameters window onto the text box, then selecting the Text option. This automatically sets the text box to use any value that is defined for the Title parameter as the text to be shown in the text box.

The Group parameter is associated with the embedded Alarms List by configuring an animation for the Alarms List's Filter property. The Filter property is animated with the following expression:

'Source='"+"Parameter:Group"+'.*"'

The + is preceded by a single quote and then a double quote and the * is followed by a double quote and then a single quote. The * is a wildcard character that represents any characters (1 or more).

This Filter animation sets the Filter property of the Alarms List to use any value that is defined for the Group parameter as the source for the filter. So, if the Group parameter had a value of 'SiteA', the Alarms List would be filtered to only show those alarms that are for database items with a Source of 'SiteA' i.e. alarms for items within the 'SiteA' Group.

On the 'Overview' Mimic, the Show Alarms button is configured to have the following pick action settings (via the Pick Action Wizard):

  • Type: Hyperlink
  • URL: SCX:////CMimic/.Outstation Alarms
  • Type of Reference: Relative
  • Mode: Open as Inset

This sets the Outstation Alarms Mimic to be displayed when the Show Alarms button is selected in Design mode.

The Show OS 1 Alarms button has the following pick action configuration:

  • Type: Hyperlink
  • URL: SCX:////CMimic/.Outstation Alarms#Group="Outstation 1 Points"&Title="Outstation 1 Alarms"
  • Type of Reference: Relative
  • Mode: Open as Inset

The URL entry sets the button to hyperlink to the Outstation Alarms Mimic and sets two values: Outstation 1 Points is the value that is set for the Group parameter and Outstation 1 Alarms is the value that is set for the Title parameter. So, when a user selects the Show OS 1 Alarms button, the Outstation Alarms Mimic will be displayed in an inset window. It will display 'Outstation 1 Alarms' in its text box (as that is the value defined for the Title parameter which is used to animate the Text value of the text box) and its embedded Alarms List will only display those alarms for points in the Outstation 1 Points Group (as Outstation 1 Points is the value defined for the Group parameter which is used to animate the Filter property of the embedded Alarms List).

The Show OS 2 Alarms button works in a similar way to the Show OS 1 Alarms button and has similar configuration. The only difference is that the Show OS 2 Alarms button's hyperlink sets the inset Outstation Alarms Mimic to display Outstation 2 Alarms in the text box and to only show the alarms for points in the Outstation 2 Points Group in the embedded Alarms List. To achieve this, the following configuration is defined for the Show OS 2 Alarms button's hyperlink pick action:

  • Type: Hyperlink
  • URL: SCX:////CMimic/.Outstation Alarms#Group="Outstation 2 Points"&Title="Outstation 2 Alarms"
  • Type of Reference: Relative
  • Mode: Open as Inset

So, when the Outstation Alarms Mimic is displayed as a Mimic in its own right, it displays an embedded Alarms List that contains the alarms for points within the Outstations Group. Its text box displays the Default Parameter value for the Title parameter, which is Outstation Alarms. When the Outstation Alarms Mimic is displayed as a result of selecting the Show OS 1 Alarms button or Show OS 2 Alarms button, the Outstation Alarms Mimic is shown as an inset and is filtered to only show the alarms for points in the Outstation 1 Points or Outstation 2 Points Group respectively. Its text box is also configured to show Outstation 1 Alarms or Outstation 2 Alarms.


Mimics Guide - Locating the Absolute Address of a Display (Hyperlinks)

Locating the Absolute Address of a Display

When you are configuring hyperlinks, you may need to enter the absolute address of a display as the Target. For example, if you are setting up a hyperlink on a multi-head system, where the target display is to be shown on a different head, you will need to define the absolute address of the target display.

For target displays other than Lists and Alarms Lists, you can determine the absolute reference by following these steps:

  1. Drag the document item from the Database Bar onto a Mimic (displayed in Design Mode).
  2. When the context sensitive menu appears, select Hyperlink to create a hyperlink to the document item.
  3. Right-click on the hyperlink and select the Pick Action Wizard option to display the Pick Action Wizard.
  4. Select Next to proceed to the second page of the Wizard. There you will see the absolute reference to the document (although it may not contain the System name) in the URL field.
  5. Copy the URL entry to the clipboard, then paste it into the Code field when you are configuring your pick action.

NOTE: If the system name is not included in the URL, you will need to add the system name before the last / after the ClearSCADA: part of the link. For example, if the URL is SCX:////CProfile/New Double and your system is called MAIN, you would need to change the entry to: SCX:///Main/CProfile/NewDouble.

With Lists and Alarms Lists, you need to use a different technique to obtain the absolute address:

  1. In ViewX, display the List to which you want to link, applying any filters as required (see Display and Use Lists in the ClearSCADA Guide to Lists).
  2. With the List on display, select the Edit menu, then select the Copy Shortcut option.
  3. Run a text editor program such as Notepad and paste the entry into a new document. If you do not have a text editor program, you can paste the absolute link into the Notes for the List item (see Notes in the ClearSCADA Guide to ViewX and WebX Clients).
  4. Look at the absolute reference and check that it complies with the following syntaxes:

For Queries Lists:

SCX:///<System>/List/Title="<Name of List>"&InitialSQL="<SQL for List> FROM <Database Class>".

Where:

  • <System> is the name of the system that contains the List.
  • <Name of List> is the name of the List in ViewX, for example, Objects. The angled brackets should not be included.
  • <SQL for List> is the SQL filter applied to the list and consists of SELECT followed by the defined filter criteria.
  • <Database Class> is the table in the database that stores the information for the List, for example, for the Objects List, the database class is CDBOBJECT.

For Alarms Lists:

SCX:///<System>/AlarmList/<Filter1>="<Value1>"&<Filter2>"<Value2>"

Where:

  • <System> is the name of the system on which the alarms have been raised. If you want the Alarms List to show the alarms on all of your systems, use the asterisk * character instead of <System>. Do not include the angled brackets for <System> or *.
  • <Filter1> is the name of the first filter condition that you want to apply. Do not include the angle brackets < >.
  • <Value1> is the criteria that has to be met for <Filter1>. Do not include the angle brackets < >.
  • <Filter2> is the name of the first second condition that you want to apply. Do not include the angle brackets < >.
  • <Value2> is the criteria that has to be met for <Filter2>. Do not include the angle brackets < >.

There can be additional filters and values (<Filter3>, <Filter4> etc.) as required. For more information on the filter conditions that can be used, see Creating a Hyperlink to an Alarms List.

  5. Copy the reference to the clipboard, then paste it into the Code field when you are configuring your pick action.


Mimics Guide - Animations

Animations

Each Mimic object has properties that you can associate with values in the database. For example, you can associate the size of a Mimic object with the value of an analog point so that the Mimic object is larger when the point has a high value.

Associating the property of a Mimic object with the property of an item in the database is referred to as animating an object.

The properties of an object on a Mimic...
...are animated so that they are associated with the values of objects in the database.

You can also use an animation to associate a Mimic object property with a specific value. For example, you can associate the FillColour property of a text box with an RGB value so that the FillColour is set to a specific color.

By configuring animations, you can allow Mimics to:

  • Change in appearance according to values in the database. You can set Mimic objects to change size and color, rotate, become invisible, and move to a new location according to the values of objects in the database.
  • Show values that are stored in the database
  • Provide access to pick actions.

By using the animations feature, you can create Mimics that provide the information and interactivity required by operators.

In this section, we explain:

  • Displaying the Animations Window
  • Using the Animations Window
  • Shape Animations
  • Text Box Animations
  • Line Animations
  • Button Animations
  • Embedded Mimic Animations
  • Embedded Query List Animations
  • Embedded Alarms List Animations
  • Embedded Trend Animations
  • Embedded X-Y Plot Animations
  • Image and Remote Image Animations
  • Pie Chart Animations
  • Pipe Animations
  • Fill Animations
  • Pen Animations
  • Font Animations
  • Pick Action Animations for Mimic Objects
  • Pick Action Animations for Symbols
  • PickComment Animations
  • PickDisabled Animations
  • Rotation Animations
  • Position Animations
  • Size Animations
  • ToolTipText Animations
  • Visibility Animations
  • Animations for Historic Data
  • Alarm Conditions in Expressions.


Mimics Guide - Displaying the Animations Window (Animations)

Displaying the Animations Window

To access the animation properties for an object, you need to display its Animations window. The Animations window contains a list of the animation properties that are available for the selected Mimic object and shows any expressions that are in place.

To display the Animations window:

  1. Display the Mimic object's Properties window by double-clicking on the Mimic object (with the Mimic in Design mode).
  2. Select the General tab.
  3. Select the Animations button.

Alternatively, right-click on the Mimic object and select the Animations option from the context sensitive menu.

For information on the Animations window settings, see Using the Animations Window.


Mimics Guide - Using the Animations Window (Animations)

Using the Animations Window

When you have displayed the Animations window, you can use it to view, edit, remove, and create animations. Each animation either defines a value for a particular setting or associates an animation property with one of the properties of a database item.

The animation properties are listed in the main display. They are listed in a tree-structure, with sets of related animation properties being grouped in branches. You can expand any branch by selecting the + icon.

The following information is provided (where applicable):

  • Property—The name of the animation property (see Understanding the Animation Properties).
  • Expression—Shows the ViewX expression (if any) that is in place. The ViewX expression defines the relationship or value for the animation property.
  • Hover—Indicates whether the Hover feature is enabled for the expression for the animation property. For more information on the Hover feature, see Working with the Expression Window in the ClearSCADA Guide to Expressions.
  • Fast Updates—Indicates whether the expression for the animation property is set to be updated using the Fast update rate or the slower, Normal update rate. For more information on Fast Updates and Normal Updates, see Define the Update Rates for a Mimic.
  • Status—Shows the status of the animation. The status indicates whether the animation is working correctly. If the animation is correctly configured, the Status will show OK. If the animation is incorrect, the status indicates that there is an error. For example, if you have entered an incorrect expression, the status entry is Invalid.

The Animations window also has these buttons:

  • Edit—Use to access the Expression window. You need to use the Expression window to enter ViewX expressions and associate an animation property with a database item property (see Using the Expression Window).
  • Flowchart—Use to access the Flowchart window. You can use the Flowchart window to create complex IIF statements—the Flowchart window allows you to create a condition tree that is easier to understand than an expression containing multiple IIF statements (see Using the Flowchart Window).
  • Clear—Use to remove the expression for the selected animation property.
  • Refresh—Use to update the Animations window so that it shows the latest status settings etc.
  • Close—Use to exit the Animations window.

For information on the animation properties, see Understanding the Animation Properties.


Mimics Guide - Understanding the Animation Properties (Animations)

Understanding the Animation Properties

The animation properties that are shown in the Animations window vary according to the type of object you are trying to configure. If you are trying to configure an animation for a Mimic object and need more information about a particular animation property, please refer to the relevant section:

  • Shape Animations
  • Text Box Animations
  • Line Animations
  • Button Animations
  • Embedded Mimic Animations
  • Embedded Query List Animations
  • Embedded Alarms List Animations
  • Embedded Trend Animations
  • Embedded X-Y Plot Animations
  • Image and Remote Image Animations
  • Pie Chart Animations
  • Pipe Animations
  • Fill Animations
  • Pen Animations
  • Font Animations
  • Pick Action Animations for Mimic Objects
  • Pick Action Animations for Symbols
  • PickComment Animations
  • PickDisabled Animations
  • Rotation Animations
  • Position Animations
  • Size Animations
  • ToolTipText Animations
  • Visibility Animations
  • Animations for Historic Data

For information on the various features of the Animations window, see Using the Animations Window.


Mimics Guide - Using the Expression Window (Animations)

Using the Expression Window

You can use the Expression window to define a specific value for an animation property. You can also use it to enter a ViewX expression that defines a relationship between the animation property and a value in the database. For example, you can associate an animation property with the state of a digital point—the state of the digital point will affect the value for the animation property.

There are examples for the various animation properties in the animations sections. For example, for information on the Text Box animations and suitable entries, refer to Text Box Animations. A list of the animation sections is included at the start of the Animations section (see Animations).

To display the Expression window for an animation property, select an animation property on the Animations window and then select the Edit button. Alternatively, you can double-click on the required animation property on the Animation window.

The Expression window has 3 check boxes, and an expression text entry field that has a browse button feature:

  • Relative—Use this check box to define whether the expression uses relative or absolute references. Select the Relative check box to use relative references or clear it to use absolute references.
  • Hover—Use the Hover check box to define whether the Mimic object needs to be selected or highlighted to instigate the animation:
  • If you select the Hover check box, the animation will occur when the cursor is positioned over the Mimic object in Run mode.
  • If you clear the Hover check box, the animation will occur when the Mimic object is selected in Run mode.
  • Fast Updates—Use this check box to determine whether the expression is included in the client PC's fast updates group. The fast updates group is a set of values for which the client requests more frequent updates. The server sends updates for the fast update group values more frequently that it sends updates for other values.

The frequency of requests is defined via the Options window (see Define the Update Rates for a Mimic).

  • If you select the check box, the animation is included in the fast updates group.
  • If you clear the check box, the animation is included in the normal update group.

NOTE: Fast updates can place extra demand on the system's resources and should be used sparingly.

  • Expression—In the Expression field, you can:
  • Enter the ViewX expression that defines the value or relationship for the animation. The expression has to be a valid ViewX expression.
  • Use the browse button feature to associate the animation property with:
  • OPC Tag—Associate the animation property with a specific property tag for an object in the database. For example, you can associate the Value animation property with the CurrentValue tag of a database point.
  • OPC Historic Tag—Associate the animation property with a historic tag. For more information on historic animations, see Animations for Historic Data.
  • Color—Associate the animation property with a color from the palette or create a custom color (see Using the Color Window). The color setting is only appropriate for animation properties that require a color definition such as FillColour.

Select the OK button to confirm your selections and close the Expression window.

Further Information

Expressions: see Understanding the Basics of Expressions in the ClearSCADA Guide to Expressions.


Mimics Guide - Using the Flowchart Window (Animations)

Using the Flowchart Window

The Expression Flowchart window allows you to create IIF expressions in a diagram format. This makes it easier to create complicated IIF expressions as you can easily visualize what happens with each condition.

NOTE: For information on IIF expressions, see IIF in the ClearSCADA Guide to Expressions.

Each flowchart consists of branches and leaves. Branches contain IIF expressions, and the result of these expressions is True or False. There are 2 leaves for each branch. Each leaf represents a True result or False result.

When the system processes the flowchart, it begins with the first branch (the top-left branch) and proceeds through the flowchart until it reaches a leaf. The value in the leaf is used as the value for the animation property.

For example, the following flowchart is used with the FillColour animation property of a polygon.

Branch
Leaves

The branch IIF expression defines that the value of a digital point's alarm state has to be 4 (the point has to have an unacknowledged uncleared alarm).

The True leaf sets the color to be red and the False leaf sets the color to be green. This means that if the digital point has an uncleared alarm, the FillColour animation will have RGB (0,255, 0) as its value (Green) and if the digital point does not have an uncleared alarm, the FillColour animation will have RGB(255, 0, 0) as its value (red).

When you display a new Flowchart window, the flowchart contains a single condition, referred to as a branch.

Branch

You can edit the branch so that it contains an IIF expression. Once the branch has an expression, it is provided with 2 'leaves'. One leaf is the result if the branch IIF expression is True and the other is the result if the expression is False.

Condition branches can be chained together to form a complex series of conditions and results.

To create a flowchart, right-click on a branch or leaf to display a context sensitive menu. You can then use the options on the context-sensitive menu to create the flowchart:

  • Insert—Inserts a new condition branch.
  • Swap Branches—Swaps the True and False leaves of a condition branch. The expressions for the True leaf become the expressions for the False leaf and vice versa.
  • Edit—Displays the Expression window for a branch or leaf. Use the Expression window to define the IIF expression for a branch or the value for a leaf. For more information on the Expression window, see Using the Expression Window.

NOTE: There are also the standard Cut, Copy, Paste, and Delete options.

When you have created a suitable flowchart, you can choose to add it to the Fast Updates group by selecting the Fast Updates check box. The Fast Updates check box works in the same way as the Fast Updates check box that is shown on the Expression window (see Using the Expression Window).

To confirm your selections and close the Flowchart window, select the OK button.


Mimics Guide - Shape Animations (Animations)

Shape Animations

Each shape (rectangle, polygon, and ellipse) has the following properties which you can animate as required:

  • Fill—see Fill Animations.
  • FillMode—see FillMode Animations.
  • Line—see Line Animations.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring a shape on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a shape on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring a shape on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a shape on a Symbol Mimic.
  • PivotType—see Rotation Animations.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • Rotation—see Rotation Animations.
  • SizeDir—see Size Animations.
  • SizeMax—see Size Animations.
  • SizeMin—see Size Animations.
  • SizeVal—see Size Animations.
  • TooltipText—see ToolTipText Animations.
  • Visible—see Visibility Animations.


Mimics Guide - Text Box Animations (Animations)

Text Box Animations

Each text box has the following properties which you can animate as required:

  • Fill—see Fill Animations.
  • Font—see Font Animations.
  • Format—see Format.
  • Pen—see Pen Animations.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring a shape on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a shape on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring a text box on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a text on a Symbol Mimic.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • Text—see Text.
  • TooltipText—see ToolTipText Animations.
  • Value—see Value and see Animating Textboxes to show Values.
  • Visible—see Visibility Animations.


Mimics Guide - Format (Animations)

Format

The Format property represents the formatting settings for values that are shown in the text box. You can animate the Format property by associating it with the Format property of a database item or by entering a string that specifies the format rules (see Defining the Format of Displayed Values in the ClearSCADA Guide to Core Configuration).

The Format animations only have an effect on the text box when its Value property is animated to show a numerical value. For more information, see Animating Textboxes to show Values.


Mimics Guide - Text (Animations)

Text

The Text property represents a string or value that is not affected by the Format animations or settings. By animating the Text property, you can set the text box to display a defined string or value, or you can associate it with the value of any property in the database, for example, the CurrentStateDesc of a point.

For more information, see Animating Textboxes to show Values.


Mimics Guide - Value (Animations)

Value

The Value property represents a string or value that is affected by the Format animations or settings. By animating the Value property, you can set the text box to display a defined string or value, or you can associate it with the value of any property in the database, for example, the CurrentStateDesc of a point.

For more information, see Animating Textboxes to show Values.


Mimics Guide - Animating Textboxes to show Values (Animations)

Animating Textboxes to show Values

You can animate the Format, Text, and Value properties to allow a text box to display values or text strings. The three properties have different purposes:

  • Format—The Format property represents the type of formatting that is applied to any value that is shown in the text box. This only has an effect when the text box's Value property is animated.

The Format property is not usually animated (the format is set on the Text Properties window instead). Typically, if the Format property is animated, it is associated with the Format property of a point so that the text box uses the same formatting as has been defined in the point's configuration. To do this, you would use the browse feature of the Expression window to associate the Format property of the text box with the Format property of the point.

You can also enter a string to animate the Format property. The string has to include the format rules and use the relevant syntax. For example, for the Format to be animated to show a numeric value to 3 decimal places, the string has to include:

#.000

For information about the syntax for format definitions see FORMATVAL in the ClearSCADA Guide to Expressions.

  • Text—The Text property represents a string. By animating this property, you can set the text box to display a defined string or value, or you can associate it with the value of any property in the database, for example, the CurrentStateDesc of a point.

If you enter a text string in the expression for the Text property, the text string has to be enclosed in single quotes. For example, if you enter 'State Display' as the expression, the text box will display:

State Display

If you enter a number, there is no need to enclose it in single quotes ' '.

If you use the Expression window to associate the Text property with the property of a database item, the value that is shown in the text box will not use any formatting settings. Typically, you would associate the Text property with a text value such as a point's CurrentStateDesc so the formatting would not be irrelevant (text does not use formatting). However, for numerical values, you may need formatting such as a specific number of decimal places. If formatting is required, you should you should animate the Value property instead of the Text property.

  • Value—The Value property represents a numerical value or a text string that uses formatting settings. By animating this property, you can set the text box to display a defined string of characters or the value of any property in the database. The Formatting settings are defined for the value in the Point configuration or are set as an animation (see Format).

If you enter a string in the expression for the Value property, the text string has to be enclosed in single quotes. This works in the same way as strings that are used when animating for the Text property.

If you enter a numerical value, the number does not have to be enclosed by single quotes.

If you use the Expression window to associate the Value property with the property of a database item, the text box will display the text string or numerical value for the selected property and will apply any formatting settings, for example, a specific number of decimal places. If there are no formatting settings specified, the default settings are applied (2 decimal places, no leading zeros etc.).

NOTE: If a text box is used to present a value from the database, such as the value of a point, you need to size the text box appropriately. The text box needs to be large enough to display the entire value, including any prefixes or postfixes. If the text box is too small, parts of the value may not be visible.

To see how the Format, Text, and Value animations work:

  1. Create a text box on a Mimic.
  2. Access the animations window for the text box.
  3. Enter the following expression for the Format property:
'#.000'

This expression specifies that any animated value that is shown in the text box uses three decimal places.

  4. Animate the Text property so that it is associated with the CurrentValue property of an internal analog point.
  5. Close the animations window and display the Mimic in Run Mode.
  6. In the Database Bar, right-click on the analog point that is used to animate the Text property, then select the Hand Control option.
    The Hand Control window is displayed.
  7. Hand Control the point value so that it is 5.65890068

On the Mimic, the text box shows 5.65890068, as the text box has its Text property animated to show the value of the point. The Text property does not use the formatting settings (as defined in the expression for the Format property) and so shows the hand controlled value in full.

  8. Display the Mimic in Design Mode.
  9. Access the Animations window for the text box.
  10. Select the Text property.
  11. Select the Clear button to remove the Text animation.
  12. Animate the Value property so that it is associated with the CurrentValue property of the internal analog point that was previously associated with the Text property.
  13. Close the Animations window and display the Mimic in Run Mode.

The text box displays 5.659 as the 3 decimal places formatting that is defined by the Format animation is applied to the Value animation.

The text box has its Text property animated, so the Format animation has no effect.
The text box has its Value property animated, so the Format animation is applied to the value shown in the text box.


Mimics Guide - Line Animations (Animations)

Line Animations

Line animations can be used on line objects and on the outline of shapes. Each line/outline has the following properties which you can animate as required:

  • Fill—see Fill Animations.
  • FillMode—see FillMode Animations.
  • Line—The Line group of properties includes:
  • Alpha.
  • Blink.
  • Colour.
  • DashCap.
  • DashStyle.
  • EndCap.
  • EndCapSize.
  • FlashAlpha.
  • FlashColour.
  • FlashMode.
  • FlashOffset.
  • JoinStyle.
  • MitreLimit
  • LineStyle.
  • StartCap.
  • StartCapSize.
  • Type.
  • Width.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring a line on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a line on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring a line on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a line on a Symbol Mimic.
  • PivotType—see Position Animations.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • Rotation—see Rotation Animations.
  • SizeDir—see Size Animations.
  • SizeMax—see Size Animations.
  • SizeMin—see Size Animations.
  • SizeVal—see Size Animations.
  • TooltipText—see ToolTipText Animations.
  • Visible—see Visibility Animations.


Mimics Guide - Alpha (Animations)

Alpha

The Alpha property represents the amount of transparency that is applied to the line/outline.

The Alpha property works in the same way as the FillAlpha property except that it animates the line/outline rather than the fill color. For more information, refer to the Fill Animations section (see FillAlpha).


Mimics Guide - Blink (Animations)

Blink

The Blink property is used to define whether the flash feature is on or off for the line/outline.

The Blink property for lines works in exactly the same way as the Blink property in the Fill group except that it applies to the line/outline. For more information, refer to the Fill Animations section (see Blink).


Mimics Guide - Colour (Animations)

Colour

The Colour property is used to define the color of the line/outline.

You can animate the Colour property in the same way as the FillColour property—the only difference is that the Colour property applies to the outline instead of the fill. For more information, refer to the Fill Animations section (see FillColour).


Mimics Guide - DashCap (Animations)

DashCap

The DashCap property defines the appearance of the dashes when the line/outline is dashed (broken lines).

Typically, you would set the DashCap by defining the appearance of the dashes on the Line tab of the Polyline Properties window or the Text Properties window. However, you could use an expression to define the DashCap or to animate the DashCap according to the value or state of a database item. For example, you could animate the Dashcap so that when a digital point is in state 0 the dashes have round ends and when the point is in state 1 the dashes have pointed ends. The expression for this is:

IIF("<path and name of point>.CurrentState" = 0, 2, 3)

Where <path and name of point> is the location and name of the database point (do not enter the angle brackets < > ). CurrentState is the point property that affects the dashes. 0, 2, 3 means that when the point is in state 0 the end of the dashes use style 2, and when the point is in any other state the end of the dashes use style 3.

The dashes in this outline are animated to use round dash ends
The dashes in this outline are animated to use pointed dash ends

The numbers for each style are:
Number for Expression | Dash Style
0 | Flat
2 | Rounded
3 | Pointed

NOTE: The end dash style is only visible when the Width of the line is set to 3 pt or above (either set on the Line tab or animated via the Width property).


Mimics Guide - DashStyle (Animations)

DashStyle

The DashStyle property defines the type of dashed lines that are used for a dashed line/outline.

Typically, you would set the DashStyle by defining the appearance of the dashes on the Line tab of the Polyline Properties window or the Text Properties window. However, you could use an expression to define the DashStyle or to animate the DashStyle according to the value or state of a database item.

Each DashStyle has a number that you can enter in an expression:
Number for Expression | Style
0 | Solid line
1 | Dashed line
2 | Dotted line
3 | Dash-Dot line
4 | Dash-Dot-Dot line

For example, you could animate the DashStyle so that it changes when a point has an unacknowledged uncleared alarm. The expression for this is:

LOOKUP( "<Path and name of point>.AlarmState" + 1, 0, 0, 0, 0, 4)

Where <path and name of point> is the location and name of the database point (do not enter the angle brackets < > ). AlarmState is the point property that affects the dashes and the numerical values are:

  • +1 is needed as LOOKUP is 1 based (starts from 1) whereas the point's alarm states are 0 based (start from 0).
  • The first 0 is the DashStyle that will be applied when the point is in has no alarms (is in a normal state). DashStyle 0 is a Solid line.
  • The second 0 is the Type that will be applied when the point has its alarms disabled. DashStyle 0 is a Solid line.
  • The third 0 is the Type that will be applied when the point has an Acknowledged Uncleared alarm. DashStyle 0 is a Solid line.
  • The fourth 0 is the DashStyle that will be applied when the point has an Unacknowledged Cleared alarm. DashStyle 0 is a Solid line.
  • The 4 is the DashStyle that will be applied when the point has an Unacknowledged Uncleared alarm. DashStyle 4 is Dash-Dot-Dot.

This means that the outline will be a solid line unless the point has an unacknowledged uncleared alarm.

Solid line outline when the point does not have an uncleared unacknowledged alarm
Dashed line outline when the point does has an uncleared unacknowledged alarm


Mimics Guide - EndCap (Animations)

EndCap

The EndCap property defines the appearance of the end of a line. As with properties such as the DashCap and DashStyle, you would typically set the value for the EndCap on the Polyline Properties window or the Text Properties window. However, you can animate the property to use a specific style (by entering the relevant number as the expression) or to use a different style depending on the value or state of an item in the database.

The numbers for the expression are as follows:
Expression Number | Style
0 | None
1 | Flat Arrow
2 | Open Arrow
3 | Pointed Arrow
4 | Diamond
5 | Circle

You could use these to animate a line so that one of its ends changes style according to the value or state of a database item. For example, you could animate the EndCap and Colour properties to change a line from a green circle ended line to a red arrow ended line according to the alarm state of a 1 bit digital point. This could be useful for changing the appearance of a 'callout' line when an alarm is raised for a point.

Line changes arrow style and color when an alarm is raised for the relevant point.

To achieve the effect shown above, the following expressions are used:

For the Colour property:

IIF( "<.1 Bit Digital>.AlarmState" = 4, RGB( 255, 0, 0 ), RGB( 0, 255, 0 ) )

Where <.1 Bit Digital> is the path and name of a 1 bit digital point (do not enter the angle brackets < > ). AlarmState is the point property that affects the color for the line. The remaining part of the expression defines that when the point is in alarm state 4 (has an unacknowledged uncleared alarm), the line is red and when the point has an alarm state other than 4, the line is green.

For the EndCap property:

IIF( "<.1 Bit Digital>.AlarmState" = 4, 1, 5 )

Again, <.1 Bit Digital> is the path and name of a 1 bit digital point and you should not include the angle brackets < >. The AlarmState is the point property that affects the style of the line. The remaining part of the expression defines that when the point has an AlarmState of 4 (unacknowledged alarm), the line will use EndCap 1 (arrow tip) and when the AlarmState is not 4, the line will use EndCap 5 (round tip).

The text that changes from 'Power On' to 'Power Failure' is an animated text box that animates the Value property to show the CurrentStateDesc property of the point.


Mimics Guide - EndCapSize (Animations)

EndCapSize

The EndCapSize property defines the size of the end tip of a line (the EndCap). As with the EndCap property, typically you would set the EndCapSize on the Polyline Properties window or the Text Properties window and would not animate it. However, you can animate the EndCapSize if required. You can animate it so that it is a certain size by entering the relevant number for its expression or you can animate it so that the end tip changes size according to the value or state of an item in the database.

The numbers for the available sizes are:
Number for Expression | Style (width x height)
0 | Small x Small
1 | Medium x Small
2 | Large x Small
3 | Small x Medium
4 | Medium x Medium
5 | Large x Medium
6 | Small x Large
7 | Medium x Large
8 | Large x Large

For example, you could animate a line with an arrow tip so that the arrow tip increases in size when an alarm is raised for a point. To do this, you would enter the following expression for the EndCapSize property:

LOOKUP( "<DigitalPoint 2>.AlarmState" + 1, 0, 0, 3, 5, 8)

Where <DigitalPoint 2> is the location and name of the 2 bit digital point (do not enter the angle brackets < > ), the AlarmState is the point property that animates the EndCapSize property of the Mimic object and the numerical values are:

  • +1 is needed as LOOKUP is 1 based (starts from 1) whereas the point's alarm states are 0 based (start from 0).
  • The first 0 is the EndCapSize that is applied when the point has an alarm state of 0 (no alarms raised). The 0 EndCapSize is small x small.
  • The second 0 is the EndCapSize that is applied when the point has an alarm state of 1 (alarms disabled). The 0 EndCapSize is small x small.
  • The 3 is the EndCapSize that is applied when the point has an alarm state of 2 (acknowledged uncleared alarm). The 3 EndCapSize is small x medium.
  • The 5 is the EndCapSize that is applied when the point has an alarm state of 3 (unacknowledged cleared alarm). The 5 EndCapSize is large x medium.
  • The 8 is the EndCapSize that is applied when the point has an alarm state of 4 (unacknowledged uncleared alarm). The 8 EndCapSize is large x large.


Mimics Guide - FlashAlpha (Animations)

FlashAlpha

The FlashAlpha property defines the amount of transparency for the flash color that is used in a flash effect for the outline or line. This works in exactly the same way as the FlashFillAlpha property in the Fill group of properties except that it applies to the line instead. For more information, refer to FlashFillAlpha.


Mimics Guide - FlashColour (Animations)

FlashColour

The FlashColour property defines the alternative color for the line when the flash effect is in use. The FlashColour works in exactly the same way as the FlashFillColour except that it applies to the line/outline instead of the fill color.


Mimics Guide - FlashMode (Animations)

FlashMode

The FlashMode property defines the type of flash effect that is applied to the outline. The FlashMode property in the Line group works in exactly the same way as the Flash Mode property in the Fill group except that it applies to the line/outline instead of the fill color.


Mimics Guide - FlashOffset (Animations)

FlashOffset

The FlashOffset works in exactly the same way as the FlashOffset property in the Fill group except that it applies to the flash sequence for the line/outline rather than the fill. Typically, you would set the flash offset on the Polyline Properties window (it is not designed to be used as an animation).


Mimics Guide - JoinStyle (Animations)

JoinStyle

The JoinStyle property defines the appearance of corners on a shape. As with the other Line properties, you would usually set the JoinStyle on the Line tab of the Polyline Properties window or Text Properties window but you can also animate it if required.

You can animate the JoinStyle so that it is a specific type or so that it changes according to the value or state of an item in the database. The numbers you need for the expressions are:
Number for Expression | Style
0 | Mitre (corners meet in a point)
1 | Bevel (corners are angled to form a curve)
3 | Round (corners are rounded to form a curve)

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 1, 3 )

This means that when the point named '1 Bit Digital' has an alarm state of 4 (an unacknowledged alarm), the join style is Bevel. When the point has any other alarm state, the join style is round.


Mimics Guide - MitreLimit (Animations)

MitreLimit

The MitreLimit property defines the maximum limit for the mitre tip of a line that has its Joins set to Mitred. If the mitred join exceeds the defined limit, the join is bevelled at the limit.

Typically you would set the MitreLimit on the Polyline Properties window and would not animate it. However, you can animate the MitreLimit if required. You can animate the limit so that it is a certain number by entering the relevant number for its expression. Alternatively, you can animate it so that the limit changes size according to the value or state of an item in the database.

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 13.50, 10.00 )

This means that when the point named '1 Bit Digital' has an alarm state of 4 (an unacknowledged alarm), the Mitre Limit is 13.50 pt. When the point has any other alarm state, the Mitre Limit is 10.00 pt.


Mimics Guide - LineStyle (Animations)

LineStyle

The LineStyle property defines the type of line that is used as the outline of a shape or a line. As with the other Line properties, you would usually set the LineStyle on the Line tab of the Polyline Properties window, but you can also animate it if required.

You can animate the LineStyle so that it is a specific type or animate it so that it changes according to the value or state of an item in the database. The numbers you need for the expressions are:
Number for Expression | Style
0 | Solid
1 | Thin/Thin
2 | Thin/Thick
3 | Thin/Thick
4 | Thin/Thick/Thin

For example:

IIF( ".1 Bit Digital.CurrentState" = 1, 4, 1 )

This expression means that when the point named '1 Bit Digital' is in state 1, the line style is Thin/Thick/Thin (LineStyle 4) and when the point is in any other state the line style is Thin/Thin (LineStyle 1).


Mimics Guide - StartCap (Animations)

StartCap

The StartCap property is exactly the same as the EndCap property except that it applies to the opposite end of the line (the 'start' of the line).


Mimics Guide - StartCapSize (Animations)

StartCapSize

The StartCapSize property is exactly the same as the EndCapSize property except that it applies to the opposite end of the line (the 'start' of the line).


Mimics Guide - Type (Animations)

Type

The Type property defines whether the line/outline is visible. Typically, you would set the Type on the Polyline Properties window and would not animate it. However, you can animate the Type property if required.

You can animate the Type so that it is a specific type or so that it changes according to the value or state of an item in the database. There are only two types of outline, so the numbers you need for the expressions are:
Number for Expression | Style
0 | None
1 | Solid

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 1, 0 )

This expression means that if the point named '1 Bit Digital' has an alarm state of 4 (i.e. has an unacknowledged uncleared alarm), the type of line is solid (Type 1). If the point has any other alarm state, the line is not shown (the Type is 0 - None).


Mimics Guide - Width (Animations)

Width

The Width property defines the thickness of the line/outline. As with the other Line properties, you would usually set the Width on the Line tab of the Polyline Properties window but you can also animate it if required.

You can enter an expression to animate the Width so that it defines a specific thickness or so that it changes thickness according to the value or state of an item in the database.

For the expression, you should enter the size of the line you require (the number you enter is recognized as being a point size). For example:

IIF( ".1 Bit Digital.CurrentState" = 1, 10, 5 )

This expression means that when the point named '1 Bit Digital' has a current state of 1, the line is 10 pt thick, and when the point is in state 0 the line is 5 pt thick.


Mimics Guide - Button Animations (Animations)

Button Animations

Each button object has the following properties that you can animate as required:

  • Fill—see Fill Animations.
  • Font—see Font Animations.
  • Latched—see Latched.
  • Pen—see Pen Animations.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring a button on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a button on a Symbol Mimic.
  • PickParamAlt—see PickParamAlt.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring a button on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a button on a Symbol Mimic.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • Style—see Style.
  • Text—see Text.
  • TooltipText—see ToolTipText Animations.
  • Visible—see Visibility Animations.


Mimics Guide - Latched (Animations)

Latched

You can animate the Latched property to define whether a latched button appears to be pressed. The Latched property only has an effect when the button is set to be a latched button (either by having the Style set to Latch on the Button Properties window or by having the Style property animated to be 1).

The expression for the Latched property needs to equal TRUE for the button to appear to be pressed down, and it has to equal FALSE for it to be raised.

Raised latched button
Pressed down latched button

You can enter True or False as the expression, or you can use a more complex expression that returns a True or False answer. For example, if a button is to appear pressed down only when a specific 1 bit digital point is in state 1, you would need to enter the following as the expression for the Latched property of the Mimic object:

"<path and name of point>.CurrentState" = 1

Where <path and name of point> is the location and name of the point in the database. Do not enter the angle brackets < >.

CurrentState is the name of the point property that is used to animate the Mimic object's Latched property.

The final part of the expression defines that if the CurrentState value of the point is 1, then the result of the expression is TRUE and so the button appears to be pressed down. If the CurrentState is not 1, the result of the expression is FALSE and the button appears to be raised.


Mimics Guide - PickParamAlt (Animations)

PickParamAlt

The PickParamAlt animation property can only be used when the button style is Latched. It allows a pick action menu (or specific pick action) to be associated with the button when it appears to be pressed down. The PickParam property allows a pick action menu to be associated with a the button when it appears to be raised.

The PickParamAlt property can be animated in exactly the same way as the PickParam property—the only difference is that the action or menu that you associate with the PickParamAlt property will only be applied or made available when the button appears to be pressed down. The action or menu that is used to animate the PickParam property, if any, will apply when the button appears to be raised.

Example:

A latched button is used to Hand Control a digital point named 'Button States'. When the button is pressed, the point is hand controlled to be in State 1 and when the button is selected again (raised), the point is hand controlled to be in State 0. To achieve this, the following animations are setup:

The Latched property is animated by the CurrentState of the digital point so that it appears pressed down or raised according to the current state of the point. The following expression is used:

".Button States.CurrentState"

The PickParam property is animated so that when the button is raised (not pressed down), the digital point is hand controlled to State 0. The expression for the PickParam property is:

".Button States.ObjectLink" + '?CurrentState&Value="1"'

The ".Button States.ObjectLink" part of the expression associates the raised button with the pick action menu for the 'Button States' digital point, and the '?CurrentState&Value="1"' part of the expression associates the raised button with the Hand Control action (CurrentState) which sets the value of the digital point to State 1.

The PickParamAlt property is animated so that when the button is pressed down, the digital point is hand controlled to State 1. The expression for the PickParamAlt property is:

".Button States.ObjectLink" + '?CurrentState&Value="0"'

The ".Button States.ObjectLink" part of the expression associates the pressed down button with the pick action menu for the 'Button States' digital point, and the '?CurrentState&Value="1"' part of the expression associates the pressed down button with the Hand Control action (CurrentState) which sets the value of the digital point to State 0.

The Text property has the following expression:

".Button States.CurrentStateDesc"

This associates the current state description of the 'Button States' point with the text that is shown on the button. This means that when the button is pressed down, the text will show 'State 1' and the 'Button States' digital point is hand controlled to be in State 1. When the button is reselected so that it becomes raised, the button text changes to 'State 0' and the 'Button States' digital point is hand controlled to be in State 0.

The effect of the PickParam and PickParamAlt animations can also be achieved by using the Pick Action Wizard for the button.

After selecting Method as the type of pick action, you can use the next two 'pages' of the Wizard to setup the action that is performed and the value that is set when the button is up (raised) or down (pressed down).

Use Method combo box to choose the type of action
Use the argument values to define expressions for the actions to be performed when the button is raised or pressed down.


Mimics Guide - Style (Animations)

Style

The Style property defines whether the button is a normal button (only appears to be pressed when it is selected, and then returns to its raised position) or is a latched button (appears pressed in when selected and does not return to its raised position automatically). Typically, you would set the Style on the Button Properties window and would not animate it. However, you can animate the Style property if required.

You can animate the Style so that it is a specific type or so that it changes according to the value or state of an item in the database. There are only two types of style, so the numbers you need for the expressions are:
Number for Expression | Style
0 | Normal button
1 | Latched button

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 1, 0 )

This expression means that if the point named '1 Bit Digital' has an alarm state of 4 (i.e. has an unacknowledged uncleared alarm), the style is latched (Style 1). If the point has any other alarm state, the style is normal (the Style is 0 - Normal).


Mimics Guide - Text (Animations)

Text

The Text property represents a string or value that is shown on the button. By animating the Text property, you can set the button to display a defined string or value, or you can associate it with the value of any property in the database, for example, the CurrentStateDesc of a point.

Animating the Text property on a button is similar to animating the Text property on a text box. For more information, see Animating Textboxes to show Values.


Mimics Guide - Embedded Mimic Animations (Animations)

Embedded Mimic Animations

Each embedded Mimic has the following properties that you can animate as required:

  • MaintainAspectRatio—see MaintainAspectRatio.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring an embedded Mimic on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an embedded Mimic on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring an embedded Mimic on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an embedded Mimic on a Symbol Mimic.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • Shared—The shared animation property corresponds to the Shared with other embedded Mimics setting on the Embedded Mimic Properties window. Although it is possible to animate the Shared property (it can be True or False), it is not designed for use as an animation.
  • TooltipText—see ToolTipText Animations.
  • Visible—see Visibility Animations.


Mimics Guide - MaintainAspectRatio (Animations)

MaintainAspectRatio

The MaintainAspectRatio property represents a True/False setting that determines whether the embedded Mimic maintains its aspect ratio when it is resized. This property is not designed for use as an animation.


Mimics Guide - Embedded Query List Animations (Animations)

Embedded Query List Animations

You can animate the properties of an embedded List on a Mimic. Although embedded Lists have unique properties, some of the properties are similar to those of other objects and can be used for similar types of animation.

You can animate the following properties for an embedded List:

  • BackColour—see BackColour.
  • Font—see Font Animations.
  • GridColour—see GridColour.
  • GridSize—see GridSize.
  • HeaderDkShadowColour—see HeaderDkShadowColour.
  • HeaderFaceColour—see HeaderFaceColour.
  • HeaderFont—see HeaderFont.
  • HeaderHighlightColour—see HeaderHighlightColour.
  • HeaderShadowColour—see HeaderShadowColour.
  • HeaderTextColour—see HeaderTextColour.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring an embedded List on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an embedded List on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring an embedded List on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an embedded List on a Symbol Mimic.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • Sql—see Sql.
  • System—see System.
  • TextColour—see TextColour.
  • TooltipText— see ToolTipText Animations.
  • Visible—see Visibility Animations.


Mimics Guide - BackColour (Animations)

BackColour

The BackColour defines the background color of the embedded List. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).

This property works in a similar way to the FillColour except that it applies to the background of an embedded List instead of the fill of an object. However, this animation can be overridden by the Background column in an SQL query.


Mimics Guide - GridColour (Animations)

GridColour

The GridColour defines the color of the grid lines on an embedded List. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).

This property works in a similar way to the FillColour except that it applies to the grid lines of an embedded List instead of the fill of an object.


Mimics Guide - GridSize (Animations)

GridSize

Allows you to animate the size of the grid on an embedded List. You can animate the GridSize so that it is a specific size or you can animate it so that the size changes according to the value or state of an item in the database.

The expression for the GridSize property has to define a number which is the size of the grid (measured in points). This property works in a similar way to the Height property for text, except that it applies to the size of the grid.


Mimics Guide - HeaderDkShadowColour (Animations)

HeaderDkShadowColour

The HeaderDkShadowColour defines the shadow color of the columns on an embedded List. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).

Column shadow shown in red

This property works in a similar way to the FillColour except that it applies to the shadow of the column headings instead of the fill of an object.


Mimics Guide - HeaderFaceColour (Animations)

HeaderFaceColour

The HeaderFaceColour property defines the fill color of the column headings on an embedded List. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).

Column face shown in green

This property works in a similar way to the FillColour except that it applies to the fill of the column headings instead of the fill of an object.


Mimics Guide - HeaderFont (Animations)

HeaderFont

The HeaderFont properties for the embedded List are identical to the font properties for text boxes except that they apply to the header text on the embedded List (see Font Animations).


Mimics Guide - HeaderHighlightColour (Animations)

HeaderHighlightColour

The HeaderHighlightColour property defines the highlight color of the column headings on an embedded List. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).

Column header highlight is Blue


Mimics Guide - HeaderShadowColour (Animations)

HeaderShadowColour

The HeaderShadowColour property defines the shadow color of the column headings on an embedded List. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).

Column header shadow is Blue


Mimics Guide - HeaderTextColour (Animations)

HeaderTextColour

The HeaderTextColour property defines the color of the text in the column headings on an embedded List. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).

HeaderTextColour is animated so that it is red.

This property is similar to the FillColour property in the Pen group (see Pen Animations).


Mimics Guide - Sql (Animations)

Sql

The Sql property represents the SQL query that defines what is shown in the embedded List. Typically, you would only animate this property if you were configuring an embedded List for use in a Group Template and Group Instances or if you were configuring an embedded List that was to be filtered by an animation.

When using an Sql animation, the string has to use the correct syntax. The easiest way to check that the SQL Query part of the animation string is correct is to display the Query tab on the Properties window of the embedded List, then right-click and select the Generate Animation option. This copies the SQL Query used for the embedded List and converts the copy into the correct syntax for the Sql animation property (the converted SQL Query is added to the Sql animation automatically, ready for you to edit it as required).

You can configure a button or another selectable Mimic object to apply different filters to an embedded list. To do this, you will need to animate the Sql property and set up a registry key pick action. For more information, see Using Registry Settings to Apply different Filters to an Embedded List.


Mimics Guide - System (Animations)

System

The System property represents the ClearSCADA system name and it is not designed to be used with animations.


Mimics Guide - TextColour (Animations)

TextColour

The TextColour property defines the default color of the text in the cells on the embedded List. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).


Mimics Guide - Embedded Alarms List Animations (Animations)

Embedded Alarms List Animations

You can animate the properties of an embedded Alarms List on a Mimic. Embedded Alarms Lists have the same animation properties as embedded lists, with two exceptions:

  • Embedded Alarms Lists have a Filter property (see Filter)
  • Embedded Alarms Lists have no Sql property as they are not Query lists.

For information on the other Embedded Alarms List animation properties, please refer to Embedded Query List Animations.


Mimics Guide - Filter (Animations)

Filter

You can animate the Filter property of an embedded Alarms List so that a filter is applied to the Alarms List. This creates a criteria for the Alarms List so that it can only display those alarms that are a specific category, state, or belong to specific items or are in a defined severity range (see Filter an Embedded Alarms List).

To animate the Filter property of an embedded Alarms List, you need to use the following syntax:

<filter1>="<value1>"&<filter2>="<value2>"

Where:

  • <filter1> is the name of the first filter condition that you want to apply. Do not include the angle brackets < >. You can use any of the following filter conditions:
  • Area—Represents a database Group. You can define multiple Areas (separate with ampersands, for example, Area="AreaName1" & Area="AreaName2").
  • Source—Represents a database item. You can define multiple Sources (separate with ampersands, for example, Source="Source1" & Source="Source2").
  • AOI—Represents an Area of Interest. You can define multiple AOIs (separate with ampersands, for example, AOI="AreaofInterest1" & AOI="AreaofInterest2").
  • MinSeverity—Represents the minimum severity for a severity range. The MinSeverity has to be used in conjunction with the MaxSeverity; they cannot be used independently. You can define up to 4 pairs of severity values (separate each pair with an ampersand &).
  • MaxSeverity—Represents the maximum severity for a severity range. The MaxSeverity has to be used in conjunction with the MinSeverity; they cannot be used independently. You can define up to 4 pairs of severity values (separate each pair with an ampersand &).
  • Categories—Represents a list of category names. The categories have to be separated by semi-colons. For example, Categories="Unknown Dial In; Outstation Error; Outstation Hardware". Unlike many of the other filter conditions, Categories can only be defined once.

You can use any of the filter categories. For more information, see Filter Alarms by Alarm Category in the ClearSCADA Guide to Alarms.

  • AlarmState—Represents an alarm state. The AlarmState can be set to All, Acknowledged, Cleared, Unacknowledged, Uncleared, or UnacknowledgedUncleared. Unlike many of the other filter conditions, AlarmState can only be defined once.
  • <value1>—Represents the criteria that has to be met for the first filter condition. The value has to be enclosed in double quotation marks " ". Do not enter the angle brackets < >.
  • &—Use the ampersand character (&) to add another filter condition.
  • <filter2>—Represents the second filter. Do not enter the angle brackets < >.
  • <value2>—Represents the value for the second filter. The value has to be enclosed in double quotation marks " ". Do not enter the angle brackets < >.

NOTE: Additional filters and values can be included by using the &. For example, <filter 3>="<value3>"&<filter4>="<value4>" and so on.

As long as the source of the Filter animation is a string value and uses the appropriate syntax, the Alarms List animation will be valid. So you can use registry settings to store different filters for an Alarms List, then use buttons to toggle the filters that are applied.

Further Information

Alarm Filter Syntax: see Alarm Filter String Syntax in the ClearSCADA Guide to Alarms.

Examples:

Example 1 - Filter by Point, Group, and Severity

The following entry filters the embedded Alarms List so that it only shows alarms for a point named 'AI1' that is stored in a Group named 'Main Site'. The Alarms List only includes alarms that are within the severity range 200-800 (the meaning of these values is defined in the server configuration - see Alarm and Event Severities in the ClearSCADA Guide to Server Administration).

'Area="Main Site"&Source="AI1"&MinSeverity="200"&MaxSeverity="800"'

Example 2 - Apply Different Filters by Selecting a Button

In this example, the Mimic contains an Alarms List that displays alarms of every state by default. The Mimic also contains three buttons: Critical Severity, High Severity, and All Alarm States. These buttons are configured to use registry pick actions so that when selected, they change the filter that is applied to the Alarms List (so that the Alarms List shows only critical alarms, only high alarms, and alarms of every state respectively).

The embedded Alarms List has a Filter animation with this configuration:

REGISTRY('Severity', '')

This sets the Filter property of the Alarms List to use the filter that is contained in the registry setting named Severity. The Severity registry setting is written when one of the Mimic's buttons is selected.

The Mimic's buttons are configured as follows:

  • Critical Severity—Configured to have a registry pick action with these settings: Name=Severity, Type=String, Value=MinSeverity="1000"&MaxSeverity="1000".
  • High Severity—Configured to have a registry pick action with these settings: Name=Severity, Type=String, Value=MinSeverity="667"&MaxSeverity="999".
  • All Alarm States—Configured to have a registry pick action with these settings: Name=Severity, Type=String, Value=MinSeverity="1"&MaxSeverity="1000".

When the Mimic is displayed in Run Mode, the Alarms List will respond to the buttons. When the Critical Severity button is selected, the Severity registry value has the following value written to it: MinSeverity="1000"&MaxSeverity="1000". As the source of the Filter animation for the Alarms List is the Severity registry value, the Alarms List is filtered to show only critical alarms.

Similarly, when the High Severity button is selected, the value MinSeverity="667"&MaxSeverity="999" is written to the Severity registry and so the Alarms List only shows High severity alarms.

When the All Alarm States button is selected, the value MinSeverity="1"&MaxSeverity="1000" is written to the Severity registry and the Alarms List shows alarms of every state.

NOTE: The registry values are usually stored in the
HKEY_CURRENT_USER\Software\Schneider Electric\ClearSCADA\ViewX\Mimics key in the registry on your client PC.


Mimics Guide - Embedded Trend Animations (Animations)

Embedded Trend Animations

You can animate the properties of an embedded Trend on a Mimic. Although Embedded Trends have unique properties, many of their properties are similar to those of other objects and can be used for similar types of animation:

  • BackAlpha—see BackAlpha.
  • BackColour—see BackColour.
  • LabelFont—Represents the text properties of the embedded Trend's label. These properties work in the same way as Font Animations.
  • MainFont—Represents the text properties of the values shown on the axes of the embedded Trend. These properties work in the same way as Font Animations.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring an embedded Trend on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an embedded Trend on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring an embedded Trend on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an embedded Trend on a Symbol Mimic.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • TitleFont—Represents the text properties of the title text. These properties work in the same way as Font Animations.
  • TootlipText—see ToolTipText Animations.
  • Visible—see Visibility Animations
  • XAxisVisible—see Visibility Animations
  • YAxesVisible—see Visibility Animations.


Mimics Guide - BackAlpha (Animations)

BackAlpha

The BackAlpha property works in a similar way to FillAlpha property, except that instead of representing the amount of transparency for the fill, it represents the amount of transparency that is applied to the background of an embedded Trend.


Mimics Guide - BackColour (Animations)

BackColour

The BackColour property represents the background color of the embedded Trend. You can animate this so that it uses a color that is associated with a database item (such as the alarm color), refers to a custom color, or is set to a specific color (an RGB value).

This property works in a similar way to the FillColour except that it applies to the background of an embedded Trend instead of the fill of an object.


Mimics Guide - Embedded X-Y Plot Animations (Animations)

Embedded X-Y Plot Animations

You can animate the properties of an embedded X-Y Plot on a Mimic. Although Embedded X-Y Plots have unique properties, many of the properties are similar to those of other objects and can be used for similar types of animation.

You can animate the following properties for an embedded X-Y Plot:

  • BackAlpha—see BackAlpha.
  • BackColour—see BackColour.
  • LabelFont—Represents the text properties of the embedded X-Y Plot's label. These properties work in the same way as Font Animations.
  • MainFont—Represents the text properties of the values shown on the axes of the embedded X-Y Plot. These properties work in the same way as Font Animations.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring an embedded X-Y Plot on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an embedded X-Y Plot on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring an embedded X-Y Plot on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an embedded X-Y Plot on a Symbol Mimic.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • TitleFont—Represents the text properties of the title text. These properties work in the same way as Font Animations.
  • TootlipText—see ToolTipText Animations.
  • Visible—see Visibility Animations.


Mimics Guide - Image and Remote Image Animations (Animations)

Image and Remote Image Animations

You can animate the following properties for images and remote images on a Mimic:

  • Alignment—see Alignment.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring an image on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an image on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring an image on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring an image on a Symbol Mimic.
  • PosAnchor—see Rotation Animations.
  • PosMax—see Rotation Animations.
  • PosMin—see Rotation Animations.
  • PosVal—see Rotation Animations.
  • RefreshRate—see Url and RefreshRate Animations.
  • ToolTipText—see ToolTipText Animations.
  • Url—see Url and RefreshRate Animations.
  • Visible—see Visibility Animations.


Mimics Guide - Alignment (Animations)

Alignment

The Alignment property is exclusive to images and remote images and it represents the positioning of the image within the image box that you draw when you add the image to a Mimic.

When you enter an expression to animate the Alignment property, the expression needs to define one of the following numbers:
Number for Expression | Alignment
0 | Stretch (the image is stretched to fill the image box).
1 | Tile (the image is repeated in the image box until the available space is used).
2 | Center (the center of the image is placed in the center of the image box).

For example, you could use the following expression to change the alignment of an image according to the alarm state of a point in the database:

IIF( ""<path and name of point>.AlarmState" = 4, 0, 2 )

Where <path and name of point> are the location and name of a point. Do not enter the angle brackets < >.

This means that when the point has an AlarmState of 4 (Unacknowledged Uncleared), the Alignment is 0 (Stretch). When the point has any other AlarmState, the Alignment is 2 (Center).


Mimics Guide - Url and RefreshRate Animations (Animations)

Url and RefreshRate Animations

The Url and RefreshRate properties define the location of the image or remote image and the rate at which it is updated respectively. You can animate these properties so that the image changes and is updated at different rates according to the value of an item in the database.

As an example, we are going to examine a Mimic that uses Url and RefreshRate animations to display one of 3 webcam images and update them at a specified rate.

Three webcams are used to provide security surveillance for various locations at a site. Each webcam is connected to a different server.

  • Webcam 1 is connected to a server with IP address 10.0.10.1
  • Webcam 2 is connected to a server with IP address 10.0.10.2
  • Webcam 3 is connected to a server with IP address 10.0.10.3

The images from each webcam are defined as 'Webcam/Image.jpg'.

A string point is used to represent the servers. Its value is used to correspond to the addresses of the servers. As the value of the string point is included in the expression for the remote image animation, changing the value of the string point causes the definition of the server location to change in the expression.

A remote image is used on a Mimic to show the images from the webcams. It is designed so that it only shows the images from one webcam at a time.

Mimic shows a remote image. The remote image is animated to show the image from one of the servers.

The remote image has the following animation:

  • Url—The Url defines the location of the remote image and is animated with this expression:
'http://'+""<location and name of string point>"+'<address of image>'

Where <location and name of string point> is the location and name of the string point. This represents the CurrentValue of the string point. As in other examples, do not enter the angle brackets < >. This expression sets the Url to include the server address as defined by the current value of the string point.

The <address of image> is the location and name of the image. For example, '.Webcam/Image.jpg'.

The Mimic also has three buttons (Area 1, Area 2, and Area 3). Each button is configured to work as a Method type of pick action so that when it is selected it hand controls the value of the string point. Each button hand controls the point so that its value is the IP address of the relevant server:

  • When the Area 1 button is selected, the value of the string point is hand controlled to 10.0.10.1 (the IP address of server 1). This animates the Url property of the remote image so that the Mimic shows the image from server 1 (webcam 1).
  • When the 'Area 2' button is selected, the value of the string point changes to 10.0.10.2 (the IP address of server 2). This animates the Url property of the remote image so that the Mimic shows the image from server 2 (webcam 2).
  • When the 'Area 3' button is selected, the value of the string point changes to 10.0.10.3 (the IP address of server 3). This animates the Url property of the remote image so that the Mimic shows the image from server 3 (webcam 3).

The buttons on the Mimic are configured as Method pick actions so that when selected, they hand control the value of the string point. The value of the string point defines the location of the server in the expression for the image's Url property. When the string point's value is set by one of the buttons being pressed, the Url is animated and the image from a webcam on a different server is shown.

The area that is monitored by webcam 2 is of greater importance than the areas covered by webcam 1 and webcam 3, and so it needs to be updated more frequently. To achieve this, the remote image also has an animation for its RefreshRate property.

The RefereshRate property defines how often the image is updated. To set the image from webcam 2 so that it is updated at faster rate than the other webcams, the following expression is used:

IIF (""<Path and Name of String Point>.CurrentValue"= 10.0.10.2, 1, 5)

Where <Path and name of String Point> is the location and name of the string point that has its value set to correspond with the address of one of the servers. The angle brackets are not included in the expression.

The expression defines that if the current value of the string point is 10.0.10.2 (the address of Server 2), then the remote image is updated every second (defined by the 1). If the current value of the string point is not 10.0.10.2 (i.e is 10.0.10.1 or 10.0.10.3), then the remote image is updated every 5 seconds.


Mimics Guide - Pie Chart Animations (Animations)

Pie Chart Animations

You can animate the following properties for pie charts:

  • Font—Represents the text properties of the labels, values, and percentages shown in the key for the pie chart. These properties work in the same way as Font Animations.
  • Key Pos—Use to animate the position of the pie chart's key (see Key Pos).
  • Key Style—Use to animate the type of key that is shown for the pie chart (see Key Style)
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring a pie chart on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a pie chart on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring a pie chart on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a pie chart on a Symbol Mimic.
  • PosAnchor—see Rotation Animations.
  • PosMax—see Rotation Animations.
  • PosMin—see Rotation Animations.
  • PosVal—see Rotation Animations.
  • Slice01 - Slice10—Use to associate each slice of the pie chart with a value (see Slice Animations).
  • ToolTipText—see ToolTipText Animations.
  • Visible—see Visibility Animations.


Mimics Guide - Key Pos (Animations)

Key Pos

A pie chart can have a key that indicates what each slice of the represents (as a value, percentage, label, or a combination of the three). You can use the Key Pos property to animate the key so that it is:

  • Not shown
  • Positioned to the left of the pie chart
  • Positioned to the right of the pie chart.

Typically, you would set the Key Pos on the Pie Chart Properties window and would not animate it. However, you can animate the Key Pos property if required.

You can animate the Key Pos so that the key is in a specific position or so that it changes according to the value or state of an object in the database. There are only three key positions, so the numbers you need for the expressions are:
Number for Expression | Key Position
0 | None
1 | Left
2 | Right

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 0, 1 )

This expression means that if the point named '1 Bit Digital' has an alarm state of 4 (i.e. has an unacknowledged uncleared alarm), the key is not visible (Key Pos is 0 - None). If the point has any other alarm state, the key is positioned to the left of the pie chart (the Key Pos is 1 - Left).


Mimics Guide - Key Style (Animations)

Key Style

A pie chart can have a key that indicates what each slice of the represents (as a value, percentage, label, or a combination of the three). The type of information that is displayed on the key is defined via the Key Style setting. Typically, you would set the Key Style on the Pie Chart Properties window. However, you can animate the Key Style is required.

You can animate the Key Style so that the key is in a specific style or so that it changes according to the value or state of an object in the database. There are several key styles and the numbers you need for the expressions are:
Number for Expression | Key Style
0 | Label Only
1 | Value Only
2 | Percentage Only
3 | Label and Value
4 | Label and Percentage
5 | Value and Percentage
6 | Label, Value, and Percentage

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 6, 0 )

This expression means that if the point named '1 Bit Digital' has an alarm state of 4 (i.e. has an unacknowledged uncleared alarm), the key shows the label, value, and percentage (Key Style is 6). If the point has any other alarm state, the key only shows the label (the Key Style is 0).


Mimics Guide - Slice Animations (Animations)

Slice Animations

You need to animate the slices of your pie charts so that they represent values in the database. Each pie chart can contain up to 10 slices.

Each slice has a group of animations:

  • Alpha—The Alpha property represents the amount of transparency that is applied to the slice.

The Alpha property works in the same way as the FillAlpha property for lines and shapes except that it animates fill of the slice. For more information, refer to the Fill Animations section (see FillAlpha).

  • Colour—The Colour property represents the fill color of the slice. This property works in the same way as the FillColour property for lines and shapes except that it applies to the fill of the slice.
  • Label—The Label property represents the label that can be shown on a slice. It is a string value. By animating this property, you can set the slice to display a defined string or you can associate it with a string value of any property in the database, for example, the CurrentStateDesc of a point.

If you enter a text string in the expression for the Label property, the text string has to be enclosed in single quotes. For example, if you enter 'State Display' as the expression, the slice will display:

State Display

If you enter a number, there is no need to enclose it in single quotes ' '.

If you use the Expression window to associate the Label property with a string value for an object in the database, the value that is shown in the slice will not use any formatting settings.

  • Value—Use the Value property to associate the slice with the value of an object in the database. Alternatively, you can enter a specific value. The value animation is used to calculate the size of the slice—the value for the Value property is compared to the values for the other slices and the size of the slice is altered accordingly. For example, if there are 2 slices and one has a value of 50 and the other has a value of 150, one slice will take up a quarter of the pie chart (50 out of a total 200 is 25%) and the other slice will take up three quarters of the pie chart (150 out of a total 200 is 75%).

Typically, you will associate the Value property with the CurrentValue property of a database point. You should use the browse button feature of the Expression window to associate the Value property with the required OPC Tag (CurrentValue for example).

Example:

The following pie chart has these animations in place:

  • KeyPos—1. The Key is positioned at the right of the pie chart.
  • KeyStyle—4. The Key shows the label and percentage for each slice.
  • Slice01:
  • Alpha—255. (This slice is visible i.e. has 0% transparency).
  • Colour—RGB( 0, 0, 150 ). The slice is set to be dark blue.
  • Label—'Pipeline Alarms'. The label for the slice shows 'Pipeline Alarms'.
  • Value—"Monitor Point 1.CurrentValue". The size of the slice is based on the current value of the Monitor Point 1 database point.
  • Slice02:
  • Alpha—0. (This slice is invisible i.e. has 100% transparency).
  • Colour—RGB( 200, 200, 150 ). The slice is set to a pale shade of yellow/brown but it is not visible as the Alpha setting is 0.
  • Label—'Pump Alarms'. The label for the slice shows 'Pump Alarms'.
  • Value—"Monitor Point 2.CurrentValue". The size of the slice is based on the current value of the Monitor Point 2 database point.

NOTE: If you want to remove a slice from a pie chart, you should set the value of the animation for the slice to 0 before you clear it (remove the slice). If the slice animation is not set to 0, the pie chart will continue to show the slice, even after you have cleared the animation for the slice. This is because the pie chart will maintain the previous value of the slice.


Mimics Guide - Pipe Animations (Animations)

Pipe Animations

You can animate the following properties for pipe objects:

  • Fill—see Fill Animations.
  • PickComment—see PickComment Animations.
  • PickDisabled—see PickDisabled Animations.
  • PickParam—see Pick Action Animations for Mimic Objects if you are configuring a shape on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a shape on a Symbol Mimic.
  • PickType—see Pick Action Animations for Mimic Objects if you are configuring a shape on a 'normal' Mimic, and see Pick Action Animations for Symbols if you are configuring a shape on a Symbol Mimic.
  • PosAnchor—see Position Animations.
  • PosMax—see Position Animations.
  • PosMin—see Position Animations.
  • PosVal—see Position Animations.
  • TooltipText—see ToolTipText Animations.
  • Visible—see Visibility Animations.
  • Width—see Width.


Mimics Guide - Width (Animations)

Width

The setting for the Width animation property defines the thickness of the pipe. Typically, you would not animate the Width property—you would set the width on the Pipe Properties window. However, you can animate the property if required.

The Width property requires a floating number, so you can enter any number for the width (the higher the number, the greater the thickness). Alternatively, you can use the Expression window's browse feature to associate the Width property with the value of a database item.


Mimics Guide - Fill Animations (Animations)

Fill Animations

You can use the properties in the Fill group (on the Animations window) to animate the fill area of the Mimic object. The fill area is the inner part of a shape, text box, etc.

You can animate the following Fill properties:

  • Blink—Defines whether the flash feature is on or off.
  • FillColour—The color that fills the area of the object.
  • FillAlpha—The level of transparency for the FillColour.
  • FlashFillAlpha—The level of transparency for the FlashFillColour.
  • FlashFillColour—The alternate FillColour used with a flash effect.
  • FlashGradAlpha—The level of transparency for the FlashGradColour.
  • FlashGradColour—The second alternate color used with a 3 color flash effect.
  • Flash Mode—Defines the type of flash that is being used.
  • FlashOffset—This is not designed for use as an animation.
  • GradAlpha—The level of transparency for the GradColour.
  • GradAngle—The angle of the gradient shading.
  • GradColour—The color of the gradient shading (on objects that have gradient shading).
  • GradXPos—The horizontal position of the gradient shading.
  • GradYPos—The vertical position of the gradient shading.
  • Hatch—Defines the type of hatch shading that is used when the Type is set to Hatch.
  • Type—Defines the type of fill that is applied to the Mimic object.

If you are animating the flash colors, the animations will only take effect if the Mimic object has the Blink property animated (or the Blink feature enabled on the object's Properties window, for example on a rectangle's Polyline Properties window).


Mimics Guide - Blink (Animations)

Blink

The Blink property is used to define whether the flash feature is on or off for the selected Mimic object.

The expression for the Blink property needs to equal TRUE for the flash feature to be on, and it has to equal FALSE for it to be off.

You can enter True or False as the expression, or you can use a more complex expression that returns a True or False answer. For example, if a Mimic object is to flash only when a specific 1 bit digital point is in state 1, you would need to enter the following as the expression for the Blink property of the Mimic object:

""<path and name of point>.CurrentState" = 1

Where <path and name of point> is the location and name of the point in the database. Do not enter the angle brackets < >.

CurrentState is the name of the point property that is used to animate the Mimic object's Blink property.

The final part of the expression defines that if the CurrentState value of the point is 1, then the result of the expression is TRUE and so the Blink is on. If the CurrentState is not 1, the result of the expression is FALSE and the Blink is off.


Mimics Guide - FillAlpha (Animations)

FillAlpha

The FillAlpha property of a Mimic object defines the amount of transparency that is applied to the FillColour.

Typically, you would animate the FillAlpha property so that it is set to a specific level. You could do this by entering a number between 0 and 255 for the FillAlpha property's expression (where 0 is completely transparent and 255 is opaque).

You can also use a property of a database item to animate the FillAlpha property. For example, you could animate a square so that it was only transparent when a specific analog point has a value less than 50. To achieve this, you could edit the expression for the FillAlpha property:

IIF (""<Path and Name of Point>.CurrentValue"<50, 135, 255)

Where <Path and Name of Point> are the location and name of the analog point (do not enter the angle brackets < >).

CurrentValue is the point property that is associated with the FillAlpha property.

You need to enter the angle bracket for the <50 part of the expression, as this defines the point value that is required for the transparency to be set to 135 or 255.

When the point's CurrentValue is less than 50 the FillColour of the square will have a transparency of 135 so it will be visible, but translucent. When the point's CurrentValue is not less than 50, the FillColour of the square will be 255 (opaque).

When the point value is less than 50, the square's fill color is translucent.
When the point value is greater than 50, the square's fill color is opaque.


Mimics Guide - FillColour (Animations)

FillColour

The FillColour property of a Mimic object defines the color that is used to fill the area of the object. The fill area is the inner part of the object (every part of the object except for the outline).

The expression for the FillColour property needs to result in an RGB value or needs to associate the FillColour with the Foreground or Background property of a database item.

Typically, you would animate the FillColour property so that it:

  • Is Fixed as a Specific Color—The expression for the FillColour needs to be a Red Green Blue (RGB) value between 0 and 255 for each color component (0-255 for red, 0-255 for green, 0-255 for blue).

The format for the expression is:

RGB(<red value>, <green value>, <blue value>)

For example, RGB (255, 0, 150)

  • Corresponds to the State Colors of an Object—You can animate the FillColour property by associating it with the Foreground or Background property of a database item. By using the Foreground or Background property to animate the FillColour, you set the Mimic object's color to correspond to the state colors for the database item (as defined on the color palette).

You can also associate the FillColour property with the Foreground or Background without entering an expression. To do this, you select the Foreground or Background tab from the browse window that is available from the browse button on the Expression window. This enters the expression automatically.

Select browse button, then OPC Tag option to access a list of the database items and their properties. You can select Background or Foreground for the required item.

  • Is a Specific Color Depending on the Value of Another Object—You can animate the FillColour according to the value for another database item property.

You can set the FillColour so that when an object has a specific value, the FillColour is one color, and when the object has a different value, the FillColour is a different color. For example, If you had a Mimic object that you wanted to be colored red when a digital point was in state 1, and blue when it was in any other state, you would use the CurrentState point property to animate the FillColour of the Mimic object:

IIF (""<Point Name and Path>.CurrentState" = 1, RGB (255, 0, 0), RGB (0, 0, 255))

Where <Point Name and Path> are the location and name of the point that you want to use to determine the color of the Mimic object. Do not enter the angle brackets < >.

The CurrentState is the point property that defines the state of the point. So, when the CurrentState is 1 (i.e. the point is in state 1), the FillColour will be RGB 255, 0, 0 which corresponds to Red 255, Green 0, Blue 0 (i.e. red). If the point is not in state 1, the FillColour will be RGB 0, 0, 255 which corresponds to Red 0, Green 0, Blue 255 (blue).


Mimics Guide - FlashFillAlpha (Animations)

FlashFillAlpha

The FlashFillAlpha property defines the amount of transparency that is applied to the FlashFillColour. This works in exactly the same way as the FillAlpha property, except that it applies to the alternate color that is used in the flash effect.


Mimics Guide - FlashFillColour (Animations)

FlashFillColour

The FlashFillColour property defines the alternate FillColour that is used with a flash effect. When animated to use the flash feature, the object will alternate between the FillColour and the FlashFillColour.

The FlashFillColour works in exactly the same way as the FillColour except that it corresponds to the alternate color for flash effects.


Mimics Guide - FlashGradAlpha (Animations)

FlashGradAlpha

The FlashGradAlpha property defines the amount of transparency that is applied to the FlashGradColour. This works in the same way as the FillAlpha property except that it applies to the second alternate color used with 3 color flash effects.


Mimics Guide - FlashGradColour (Animations)

FlashGradColour

The FlashGradColour property defines the second alternate color that is used with a 3 color flash effect. When animated to use the flash feature, the object will alternate between the FillColour, the FlashFillColour, and the FlashGradColour.

The FlashGradColour works in exactly the same way as the FillColour except that it corresponds to the second alternate color for flash effects.


Mimics Guide - Flash Mode (Animations)

Flash Mode

The Flash Mode property defines the type of flash effect. Each flash effect corresponds to a number, as follows:
Number for Expression | Effect
0 | Normal flashing effect
1 | On/Off flashing effect
2 | On/Off briefly on flashing effect
3 | On/Off briefly off flashing effect
4 | 2 color flashing effect
5 | 2 color fast flashing effect
6 | 4 color flashing effect

So, for a Mimic object to use a 2 color flashing effect, its Flash Mode property has to have an expression set to 4.

You can also use more complicated expressions to determine which flashing effect is used. For example, you can animate a Mimic object so that it uses a faster flashing effect when a point has unacknowledged uncleared alarms raised. To do this, you would animate the Flash Mode property so that it had the following expression:

IIF ("<path and name of point>.AlarmState" = 4, 1, 0)

Where <path and name of point> are the location and name of the point with which you want to associate the Mimic object.

The point's AlarmState property animates the Flash Mode—when the Alarm State is 4 (which corresponds to Unacknowledged Uncleared), the Flash Mode is 1 (which corresponds to On/Off Fast Flashing). When the point's AlarmState is any other value, the Flash Mode is 0 (Normal flashing).

As the Flash Mode is 0 when the point's AlarmState is 0 (Normal), you would also need to animate the Blink property so that the flash effect was only on when the point's AlarmState was any value except 0 (you only want the Mimic object to flash when the point has an alarm). To do this, you would animate the Blink property so that its expression is:

"<path and name of point>.AlarmState"<>0

For this expression, you do not enter the angle brackets around the path and name of point (as elsewhere, they are used to indicate that this is a database location and name), but you do need to enter the angle brackets before the 0 as these are used to indicate any value smaller or greater than 0.

The Blink expression works like this:

If the point's AlarmState is less than or greater than 0 (i.e. an alarm is raised), the result of the expression is TRUE and so the Blink is set to 1 (on). If the point's AlarmState is 0 (normal i.e. no alarms are raised) then the result of the expression is FALSE and the Blink is set to 0 (off).


Mimics Guide - FlashOffset (Animations)

FlashOffset

The FlashOffset defines the sequence for 4 color flashing effects. The different parts of the sequence are numbered 1-4, but it is very unlikely that you would want to animate this property as it is usually set on the Polyline Properties window or Text Properties window and is not designed for use as an animation.


Mimics Guide - GradAlpha (Animations)

GradAlpha

The GradAlpha property defines the amount of transparency that is applied to the GradColour. This works in exactly the same way as the FillAlpha property, except that it applies to the secondary color that is used in the Linear Gradient, Pipe Gradient, or Radial Gradient shading.


Mimics Guide - GradAngle (Animations)

GradAngle

The GradAngle defines the angle of the secondary color shading when the type of Fill is set to Linear Gradient and Pipe Gradient. The GradAngle value for an object with pipe shading defines the angle of the pipe shading. The default measurements are:

  • 0 = Horizontal
  • 90 = Vertical
  • 45 = Top-right corner
  • 135 = Top-left corner
  • 225 = Bottom-left corner
  • 315 = Bottom-right corner
  • 180 = Left-Right flange
  • -180 = Right-Left flange
  • 270 = Bottom-Top flange
  • -270 = Top-Bottom flange

It is unusual for the GradAngle to be animated, as the angle of the gradient shading is not usually changed after it has been defined on the Polyline Properties window or Text Properties window. However, if you wanted to animate the GradAngle, the expression for the GradAngle would need to result in a value between 0 and 360 (the value corresponds to degrees).


Mimics Guide - GradColour (Animations)

GradColour

The GradColour property defines the secondary color that is used with objects that have Linear Gradient, Pipe Gradient, or Radial Gradient shading. It works in exactly the same way as the FillColour except that it applies to the secondary color of the shading effect.


Mimics Guide - GradXPos (Animations)

GradXPos

The GradXPos defines the horizontal position of the secondary color shading when the type of Fill is set to Radial Gradient.

It is unusual for the GradXPos to be animated, as the position of the gradient shading is not usually changed after it has been defined on the Polyline Properties window or Text Properties window. However, if you wanted to animate the GradXPos, the expression for the GradXPos would need to result in a value between 0 and 100 (0 is at the far left and 100 is far right).


Mimics Guide - GradYPos (Animations)

GradYPos

The GradYPos defines the vertical position of the secondary color shading when the type of Fill is set to Radial Gradient.

It is unusual for the GradYPos to be animated, as the position of the gradient shading is not usually changed after it has been defined on the Polyline Properties window or Text Properties window. However, if you wanted to animate the GradYPos, the expression for the GradYPos would need to result in a value between 0 and 100 (0 is at the bottom and 100 is at the top).


Mimics Guide - Hatch (Animations)

Hatch

You can animate the hatch pattern on an object that has hatch shading, for example, you can animate it so that it changes pattern when a point changes state.

Each type of hatch pattern corresponds to a number, as follows:
Number for Expression | Hatch
0 | Horizontal
1 | Vertical
2 | Forward diagonal
3 | Backward diagonal
4 | Cross
5 | Diagonal cross
6 | 5 percent
7 | 10 percent
8 | 20 percent
9 | 25 percent
10 | 30 percent
11 | 40 percent
12 | 50 percent
13 | 60 percent
14 | 70 percent
15 | 75 percent
16 | 80 percent
17 | 90 percent
18 | Light downward diagonal
19 | Light upward diagonal
20 | Dark downward diagonal
21 | Dark upward diagonal
22 | Wide downward diagonal
23 | Wide upward diagonal
24 | Light vertical
25 | Light horizontal
26 | Narrow vertical
27 | Narrow horizontal
28 | Dark vertical
29 | Dark horizontal
30 | Dashed downward diagonal
31 | Dashed upward diagonal
32 | Dashed horizontal
33 | Dashed vertical
34 | Small confetti
35 | Large confetti
36 | Zigzag
37 | Wave
38 | Diagonal brick
39 | Horizontal brick
40 | Weave
41 | Plaid
42 | Divot
43 | Dotted grid
44 | Dotted diamond
45 | Shingle
46 | Trellis
47 | Sphere
48 | Small grid
49 | Small checker board
50 | Large checker board
51 | Outlined diamond
52 | Solid diamond

NOTE: The names for the hatches in ViewX match those used in Microsoft Windows.

Animating the Hatch property only has a visible effect on the Mimic object if the Type property is set to Hatch in the Mimic object's configuration or is animated to be 2 (2 corresponds to Hatch).

You can either edit the expression for the Hatch property so that it is one of the numbers for the hatch patterns, or you can use an expression to change the hatch pattern according to the value or state of a database item. For example, you could use the following expression to change the type of hatch according to the current state of a 2 bit digital point:

LOOKUP( ".DigitalPoint 2.CurrentState" + 1, 40, 47, 48, 50)

This expression animates the Hatch property according to the CurrentState value of a 2 bit digital point named 'DigitalPoint2'. When the 'DigitalPoint2' point is in state 0 the hatch pattern is weave (pattern number 40), when it is in state 1 the hatch pattern is sphere (47), for state 2 the hatch pattern is small grid (48), and when it is in state 3 the hatch pattern is large checker board (50).


Mimics Guide - Type (Animations)

Type

You can animate the Type property so that the type of fill shading that is applied to the Mimic object varies according to the value or state of an item in the database. For example, you can animate an object so that it uses solid shading when a point is in a normal state but uses hatch shading when the point is in an alarm state.

Each Type corresponds to a number:
Number for Expression | Type
0 | None
1 | Solid
2 | Hatch
4 | Linear Gradient
5 | Pipe Gradient
6 | Radial Gradient

For example, if you wanted a Mimic object to use a hatch fill when a 2 bit digital point is in state 0 and 1 and a solid fill when the point is in state 2 and 3, you could use this expression:

LOOKUP( "DigitalPoint 2.CurrentState" + 1, 2, 2, 1, 1)

Where <DigitalPoint 2> is the location and name of the 2 bit digital point (do not enter the angle brackets < > ), the CurrentState is the point property that animates the Type property of the Mimic object and the numerical values are:

  • +1 is needed as LOOKUP is 1 based (starts from 1) whereas the point's states are 0 based (start from 0).
  • The first 2 is the Type that will be applied when the point is in State 0. Type 2 is Hatch.
  • The second 2 is the Type that will be applied when the point is in State 1. Type 2 is Hatch.
  • The second 1 is the Type that will be applied when the point is in State 2. Type 1 is Solid.
  • The third 1 is the Type that will be applied when the point is in State 3. Type 1 is Solid.


Mimics Guide - FillMode Animations (Animations)

FillMode Animations

The FillMode property represents the Fill Mode setting for a line or shape. This can be either Even-Odd or Non-Zero and determines how Windows fills the areas within the polylines. Typically, you would define the Fill Mode for an object on its Properties window, but you can animate the property if required. For example, you can animate the FillMode property so that it changes according to the value of a point.

When animating the FillMode property, you will need to use the relevant number in the expression:
Number for Expression | Mode
0 | Even-Odd
1 | Non-Zero

Further Information

Creating a New Shape by Combining Mimic Objects.


Mimics Guide - Pen Animations (Animations)

Pen Animations

The Pen properties are identical to the Fill properties except that they apply to the text in a text box rather than the fill (see Fill Animations). For example, the FillColour property for the Pen group defines the color of the text whereas the FillColour for the Fill group defines the color of the area of a shape or text box.

Pen animations apply to the text in the text box
Fill animations apply to the fill area of the text box


Mimics Guide - Font Animations (Animations)

Font Animations

The Font properties of a Mimic object define the appearance of the text in a text box, and on embedded Lists and Graphs. The Font properties that you can animate include:

  • Family—the typeface.
  • Height—the size of the text.
  • HorzAlignment—the horizontal position of the text.
  • Orientation—the direction of the text.
  • Style—the appearance of the text (Bold, Italic etc.)
  • VertAlignment—the vertical position of the text.


Mimics Guide - Family (Animations)

Family

The Family property defines the type of font that is used. As with many font properties, you would usually set the Family on the Text Properties window and would not animate it. However, you can animate the Family so that it is set to a certain size by entering the relevant number for its expression. Alternatively, you can animate it so that the font changes according to the value or state of an item in the database.

For the Family property, you need to enter the name of the required font in single quotes like this: 'Courier New'.

For example, you could use the following expression to make the text change font according to the alarm state of a 1 bit digital point:

IIF( "<.1 Bit Digital>.AlarmState" = 4, 'Impact', 'Arial' )

Where <.1 Bit Digital> is the path and name of the 1 bit digital point and AlarmState is the point property that animates the Family property of the text box. The remaining part of the expression defines that when the point has an alarm state of 4 (unnaccpeted uncleared), the text box will use the Impact font and when the point has any other alarm state, the text box will use the Arial font.

The Family property of the text box is animated so that when an alarm is raised for a point, the text box uses the Impact font instead of the Arial font.


Mimics Guide - Height (Animations)

Height

The Height property defines the size of the text in the text box. Typically, you would set the size of the font on the Text Properties window and would not animate this property, but you can animate it if required.

You can animate the Height so that the text is fixed at a specific size or you can animate it so that the size changes according to the value or state of an item in the database. The result of the expression has to define a number which is the height of the text (measured in points).

For example, you could use the following expression to change the size of text according to the state of a point:

LOOKUP( "<DigitalPoint 2>.AlarmState" + 1, 10, 10, 15, 20, 8)

Where <DigitalPoint 2> is the location and name of the 2 bit digital point (do not enter the angle brackets < >), the AlarmState is the point property that animates the Height property of the text box and the numerical values are:

  • +1 is needed as LOOKUP is 1 based (starts from 1) whereas the point's alarm states are 0 based (start from 0).
  • The first 10 is the size in points of the Height that is applied when the point has an alarm state of 0 (no alarms raised).
  • The second 10 is the size in points of the Height that is applied when the point has an alarm state of 1 (alarms disabled).
  • The 15 is the size in points of the Height that is applied when the point has an alarm state of 2 (acknowledged uncleared alarm).
  • The 20 is the size in points of the Height that is applied when the point has an alarm state of 3 (unacknowledged cleared alarm).
  • The 25 is the size in points of the Height that is applied when the point has an alarm state of 4 (unacknowledged uncleared alarm).

So for this example, the text would be 10 pt when the digital point had a normal alarm state or had its alarms disabled. When the point has an acknowledged uncleared alarm, the text is in 15 pt, if there is an unacknowledged cleared alarm the text is in 20 pt, and if there is an unacknowledged uncleared alarm the text is in 25 pt. This type of animation could be useful when you need to attract an operator's attention to an alarm and do not want to use changing or flashing colors to indicate an alarm has been raised.


Mimics Guide - HorzAlignment (Animations)

HorzAlignment

The HorzAlignment property defines the horizontal position of the text within the text box. Typically, you would define the positioning on the Text Properties window, but you can animate the property if you wish. For example, you can animate the HorzAlignment so that it changes according to the value of a point.

When animating the HorzAlignment property, you will need to use the relevant number in the expression:
Number for Expression | Alignment Style
0 | Left
1 | Center
2 | Right

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 1, 0 )

In this expression, when the point named '1 Bit Digital' has an alarm state of 4 (unacknowledged uncleared alarm), the text is centerd horizontally (HorzAlignment 1). When the point has any other alarm state, the text is left aligned horizontally (HorzAlignment 0).

NOTE: For text to be positioned in the center of a text box, both the VertAlignment and HorzAlignment need to be set on the Text Properties window or animated.


Mimics Guide - Orientation (Animations)

Orientation

The Orientation property defines the direction of the text within the text box. Typically, you would define the orientation on the Text Properties window, but you can animate the property if required. For example, you can animate the Orientation so that it changes according to the value of a point.

When animating the Orientation property, you will need to use the relevant number in the expression:
Number for Expression | Direction
0 | Left to Right
1 | Top to Bottom
2 | Bottom to Top

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 1, 0 )

In this expression, when the point named '1 Bit Digital' has an alarm state of 4 (unacknowledged uncleared alarm), the text is centerd (HorzAlignment 1). When the point has any other alarm state, the text is left aligned (HorzAlignment 0).


Mimics Guide - Style (Animations)

Style

The Style property defines the appearance of the text within the text box. Typically, you would define the orientation on the Text Properties window, but you can animate the property if required. For example, you can animate the Style so that it changes according to the value of a point.

When animating the Style property, you will need to use the relevant number in the expression:
Number for Expression | Direction
0 | Regular
1 | Bold
2 | Italic
4 | Underline
8 | Strikeout

For combinations of styles, simply add the numbers together.

For example:

IIF( ".1 Bit Digital.CurrentState" = 1, 3, 2 )

In this expression, when the point named '1 Bit Digital' has a current state of 1, the text is bold and italic (number of bold style+number of italic style=number of bold italic style). When the point has any other alarm state, the text is italic only (Style 2).


Mimics Guide - VertAlignment (Animations)

VertAlignment

The VertAlignment property defines the vertical position of the text within the text box. Typically, you would define the positioning on the Text Properties window, but you can animate the property if you wish. For example, you can animate the VertAlignment so that it changes according to the value of a point.

When animating the VertAlignment property, you will need to use the relevant number in the expression:
Number for Expression | Alignment Style
0 | Top
1 | Center
2 | Bottom

For example:

IIF( ".1 Bit Digital.AlarmState" = 4, 1, 0 )

In this expression, when the point named '1 Bit Digital' has an alarm state of 4 (unacknowledged uncleared alarm), the text is centerd vertically (VertAlignment 1). When the point has any other alarm state, the text is left aligned vertically (VertAlignment 0).

NOTE: For text to be positioned in the center of a text box, the VertAlignment and HorzAlignment need to be set on the Text Properties window or animated.


Mimics Guide - Pick Action Animations for Mimic Objects (Animations)

Pick Action Animations for Mimic Objects

Each Mimic object has PickType and PickParam properties that you can use for animations. By animating these properties, you can configure a Mimic object so that when it is selected:

  • A pick action menu for an item in the database is displayed (Object Menu pick action).
  • Another display is shown (hyperlink pick action).
  • An action is performed (method pick action)
  • Writes a value to the registry (registry pick action).

To animate the PickType and PickParam properties, you need to use a number code and a parameter that has a specific format (the format varies according to the type of pick action). In the following sections, we provide details of the number codes and parameters, and also explain how to use PickType and PickParam animations to achieve a variety of goals:

  • Expressions for PickType and PickParam Animations
  • Animating an Object to Provide Access to a Pick Action Menu
  • Animating an Object to Provide Access to Selected Actions Only
  • Animating an Object to act as a Hyperlink
  • Animating an Object to Perform a Specific Action
  • Animating an Object to Write a Value to the Registry

NOTE: The sections listed above explain how to animate the PicKType and PickParam properties for ‘normal’ Mimic objects such as shapes and buttons. For Mimic symbols, see Pick Action Animations for Symbols.

Further Information

Associating Mimic Objects with Pick Actions.


Mimics Guide - Expressions for PickType and PickParam Animations (Animations)

Expressions for PickType and PickParam Animations

Mimic objects have PickType and PickParam properties that you can use to create pick action animations:

  • PickType—represents the type of pick action that is provided by the Mimic object. You need to define a number for the type of pick action you want to use (the numbers are included in the table below).
  • PickParam—represents what happens when you select the object for which the pick action is being configured. For example, if you are creating a hyperlink pick action, then the PickParam represents the target display that is shown when the hyperlink is selected. The syntax of the expression for the PickParam property varies according to the type of pick action (see the table below).

NOTE: For latched buttons, you can apply separate pick actions for when the button is pressed down and raised. The PickParam property applies to the raised button and the PickParamAlt button applies to the button when it appears to be pressed down (see PickParamAlt).

When you are creating expressions for the PickType and PickParam, you will need to use the following numbers and parameter formats:
Number for PickType Expression | PickParam
1 | Pick Action Menu. Uses standard ViewX reference, for example, SCX:////CPointAlgManual/Group.Point. For information on using pick action menu animations with buttons, see Button Animations. For information on using pick action menu animations with other types of Mimic objects, see: Animating an Object to Provide Access to a Pick Action Menu Or: Animating an Object to Provide Access to Selected Actions Only.
3 | Hyperlink. Uses standard ViewX reference or a link, for example, http://www.google.com (see Animating an Object to act as a Hyperlink). The target display replaces the existing Mimic.
4 | Hyperlink—the target is shown in an inset window (see Animating an Object to act as a Hyperlink).
5 | Method (control action)—see Animating an Object to Perform a Specific Action.
8 | Registry—see Animating an Object to Write a Value to the Registry.
10 | Hyperlink—the target is shown in a new full size window (see Animating an Object to act as a Hyperlink).
11 | Hyperlink—the hyperlink is on an inset Mimic and when selected, its target is shown in a new, resized inset window (see Animating an Object to act as a Hyperlink)

NOTE: If you use a PickParam animation with a custom menu, the animation will apply to the first menu option in the menu.

Further Information

Animating an Object to Provide Access to a Pick Action Menu

Animating an Object to Provide Access to Selected Actions Only

Animating an Object to act as a Hyperlink

Animating an Object to Perform a Specific Action

Animating an Object to Write a Value to the Registry

Button Animations

PickComment Animations.


Mimics Guide - Animating an Object to Provide Access to a Pick Action Menu (Animations)

Animating an Object to Provide Access to a Pick Action Menu

You can animate a Mimic object so that it provides access to a pick action menu when you select it in Run Mode. Operators and other users will use the pick actions on the Mimic to access different displays and control plant (if the relevant actions are available).

When you associate a pick action menu with a Mimic object, it contains each of the available pick actions by default (however, you can remove certain actions if required, see Animating an Object to Provide Access to Selected Actions Only).

Mimic object is animated to provide access to the complete pick action menu. The availability of the options will depend on the permissions allocated to each user's account.

To animate a Mimic object so that it provides access to the pick action menu of an item in the database:

  1. Double-click on the Mimic object that you want to animate.
    The Polyline Properties window is displayed (the Text Properties window is displayed if you are working with a text box instead of a shape).
  2. On the General tab, select the Animations button to display the Animations window.
  3. Select the PickParam property (this is the Mimic object property that determines whether the Mimic object provides access to a pick action menu, hyperlink, etc.).
  4. Select the Edit button.
    The Expression window is displayed.
  5. Select the browse button to access a browse window. You may also need to select an OPC Tag option from a context sensitive menu if there are parameters defined on your Mimic.
  6. Use the browse window to select the Value tag for the database item that has the pick action menu that you want to associate with the Mimic object.
  7. Select the OK button to close the browse window and confirm your selection.
    The Expression window shows an expression that defines the path of the selected database item.
  8. Change the expression so that it has this format:
"<path and name of database item>.ObjectLink"

Where <path and name of database item> is the location and name of the database item you selected in the browse window in step 6. Do not enter the angle brackets < >.

ObjectLink indicates that the object menu (pick action menu) of the database item is to be associated with the Mimic object.

  9. Select the OK button to close the Expression window.
  10. Close the Animations window.
  11. Save the Mimic.

When you display the Mimic in Run mode and select the Mimic object, a pick action menu is displayed.


Mimics Guide - Animating an Object to Provide Access to Selected Actions Only (Animations)

Animating an Object to Provide Access to Selected Actions Only

You can animate a Mimic object so that when it is selected in Run Mode, a pick action menu that only contains selected actions is displayed. This is useful when you need a Mimic object to provide access to some, but not all, types of action for an object. For example, you may want a Mimic object to provide access to all of a point's pick actions except the Properties action.

Mimic object provides access to a pick action menu that contains limited options. You can control which categories of pick action option are available.

To animate an object to provide access to specific actions only:

  1. Double-click on the Mimic object that you want to animate.
    The Polyline Properties window is displayed (the Text Properties window is displayed if you are working with a text box instead of a shape).
  2. On the General tab, select the Animations button to display the Animations window.
  3. Select the PickParam property (this is the Mimic object property that determines whether the Mimic object provides access to a pick action menu, hyperlink, etc.).
  4. Select the Edit button.
    The Expression window is displayed.
  5. Select the browse button to access a browse window. You may also need to select an OPC Tag option from a context sensitive menu if there are parameters defined on your Mimic.
  6. Use the browse window to select the Value tag for the item that has the pick action menu that you want to associate with the Mimic object.
  7. Select the OK button to close the browse window and confirm your selection.
    The Expression window shows an expression that defines the path of the selected database item.
  8. Change the expression so that it has this format:
"<path and name of database item>.ObjectLink"+'?<name of pick action>'

Where <path and name of database item> is the location and name of the database item you selected in the browse window in step 6. Do not enter the angle brackets < >.

ObjectLink indicates that the object menu of the database item is to be associated with the Mimic object.

+'<name of pick action>' is used to indicate that some options on the menu are to be excluded. The <name of pick action> is the code for the name of an action (see the table below) and you do not enter the angle brackets < >.

If you want multiple pick actions to be excluded from the pick action menu, you simply add the extra pick action names within the single quotes, using an & for each addition:

+ '?<name of pick action>&<name of pick action>&<name of pick action>'

For example, an expression for a pick action menu associated with a point named Analog Input 1 could be:

"...Analog Input 1.ObjectLink"+'?NoView&NoNotes&NoEvents'

This expression would link the Mimic object to the pick action menu for the 'Analog Input 1' point but would exclude the View, Notes, and Display Event List actions.

The following table lists the entries required for the pick action options:
Pick Action | Entry Required to Exclude the Action from the Pick Action Menu
View Status | NoView
Display Alarm View | NoAlarmView
Display Help View | NoHelpView
Display Default View | NoDefaultView
Notes | NoNotes
Display Events | NoEvents
Display Alarms | NoAlarms
Display | NoDisplay
Queries (actions for Queries Lists) | NoQueries
Trends (actions for Trend Graphs) | NoTrends
Methods (actions for controls) | NoMethods
User Methods (as defined in User Methods on the Form of a database item) | NoUserMethods
Alarm Methods (pick actions relating to alarms, such as Acknowledge Alarms) | NoAlarmMethods
Display Errors | NoErrors
Display References | NoRefs
Properties | NoProperties
Edit | NoEdit
Links | NoLinks
Locate in Database Explorer | NoNavSync
Locate in OPC Data Explorer | NoLocateOPCNavigator
Locate in Matching Template Object | NoNavSyncTempl

  9. Select the OK button to confirm the expression and close the Expression window.
  10. Select the PickType property on the Animations window. You have to define the type of pick action as well as the parameters for the pick action, otherwise the pick action menu will be unavailable.
  11. Select the Edit button to display the Expressions window.
  12. Enter 1 which is the number that corresponds to an Object Menu (i.e. pick action menu).
  13. Select the OK button to confirm the expression and close the Expression window.
  14. Close the Animations window.
  15. Save the Mimic.

The Mimic object is now animated so that when you select the object in Run Mode, the pick action menu for the relevant pick action menu is displayed. The pick action menu will only contain the options that have not been included in the expression for the PickParam property.


Mimics Guide - Animating an Object to act as a Hyperlink (Animations)

Animating an Object to act as a Hyperlink

You can animate a Mimic object to act as a hyperlink. When the Mimic object is selected in Run Mode, another display is shown. You can animate a Mimic object to hyperlink to another ViewX display, to a web page, or to a Third Party file.

For more information, see Hyperlinks.


Mimics Guide - Animating an Object to Perform a Specific Action (Animations)

Animating an Object to Perform a Specific Action

You can animate a Mimic object so that when it is selected in Run Mode, a specific action is performed rather than a pick action menu being displayed. For example, you could configure a shape to represent a button and animate it so that when selected, it acknowledges an alarm for a specific point.

Button is animated so that when selected, it performs the Acknowledge Alarm action for the point that stores the data for the water level in a river.

This feature is only possible for method actions (controls). For other types of action, you would need to animate the Mimic object so that it only provides access to the required action (the action would be the only option available from the pick action menu). For more information on removing options from a pick action menu, see Animating an Object to Provide Access to Selected Actions Only.

  1. Double-click on the Mimic object that you want to animate.
    The Polyline Properties window is displayed (the Text Properties window is displayed if you are working with a text box instead of a shape).
  2. On the General tab, select the Animations button to display the Animations window.
  3. Select the PickParam property (this is the Mimic object property that determines whether the Mimic object provides access to a pick action menu, hyperlink, etc.).
  4. Select the Edit button.
    The Expression window is displayed.
  5. Enter an expression in one of the following formats:
  1. For a method on the database item:
"<path and name of database item>.ObjectLink"+'?<name of method action>'

  2. For a method on an aggregate for the database item:
"<path and name of database item>.ObjectLink"+'?<name of aggregate>.<name of method action>'

  3. For a method on an alarm condition for the database item:
"<path and name of database item>.ObjectLink"+'?<name of alarm condition>.<name of method action>'

  4. For a method on an alarm condition on an aggregate for the database item:
"<path and name of database item>.ObjectLink"+'?<name of aggregate>.<name of alarm condition>.<name of method action>'

Where:

  • <path and name of database item> is the location and name of the database item you selected in the browse window in step 6. Do not include the angle brackets < >.
  • ObjectLink indicates that the object menu (pick action menu) of the database item is to be associated with the Mimic object.
  • <name of method action> is the name of the method that will be performed when the Mimic object is selected. The name has to be identical to the name of the method in the database. Do not include the angle brackets < >.
  • <name of aggregate> is the name of the aggregate in the database that provides the database item with access to the method. Do not include the angle brackets <>.

Database aggregates are special extensions to a database class that have their own names, fields, methods and alarm conditions. So, if a database item is part of a class that has an aggregate, the database item has access to the methods for its own class and the methods for the aggregate.

  • <name of alarm condition> is the name of the alarm condition in the database that provides the database item with access to the method. Do not include the angle brackets < >.

Alarm conditions are similar to database aggregates in that they provide access to additional fields and methods (specific to alarms). So, a database item can have access to the methods of its own class and the methods for the alarm conditions. As the aggregates can also have alarm conditions, it is possible for a database item to have methods for its own class, methods for its alarm conditions, methods for its aggregate, and methods for the alarm conditions of its aggregate.

You should use the Database Schema to determine whether the method you require is stored for the database item, an aggregate, an alarm condition, or an alarm condition for the aggregate and then use the appropriate syntax. For more information, see Working with the Database Schema in the ClearSCADA Guide to the Database.

If a parameter is required, you should add:

&<name of property affected by the method>="<value>"

Where the & indicates that an argument is to be specified, the <name of property affected by the method> is the property that changes when the method is performed (typically, this is the CurrentValue or Current State). The ="<value>" is the value that is set by the method. You should not enter the angle brackets, and remember to include the closing single quote' after the value, for example:

"...Analog Input 1.ObjectLink"+'?CurrentValue&Value="50"'
  5. Select the OK button to confirm the expression and close the Expression window.
  6. Select the PickType property.
  7. Select the Edit button to display the Expression window.
  8. Enter 5 as the PickType expression. The number 5 corresponds to the method type of pick action.
  9. Select the OK button to confirm the expression and close the Expression window.
  10. Close the Animations window.
  11. Save the Mimic.


Mimics Guide - Animating an Object to Write a Value to the Registry (Animations)

Animating an Object to Write a Value to the Registry

You can animate an object so that when it is selected, it writes a value to the registry. Common uses for this type of animation include applying different filters to embedded lists when an object is selected, and displaying different layers when an object is selected.

When animating an object to write a value to the registry, you need to set the PickType to 8 (for Registry) and you need to define the values that are to be written to the registry in the PickParam expression.

For information on animations that use the registry pick action, see Local Variables (Registry Key Settings).


Mimics Guide - Pick Action Animations for Symbols (Animations)

Pick Action Animations for Symbols

The procedures and formats for creating pick action animations for objects on Symbol Mimics are slightly different to those for pick actions on 'normal' Mimics. This is due to the Symbol objects being required to link to any object in the database.

In this section, we use examples to illustrate how you can configure pick action animations for Symbols. The examples include:

  1. Animating a Symbol Object to Provide Access to a Pick Action Menu.
  2. Animating a Symbol Object to Provide Access to Selected Pick Actions Only.
  3. Animating a Symbol Object to Hyperlink to Another Display.
  4. Animating a Symbol Object to Perform a Specific Action.
  5. Animating an Object to Write a Value to the Registry.


Mimics Guide - Animating a Symbol Object to Provide Access to a Pick Action Menu (Animations)

Animating a Symbol Object to Provide Access to a Pick Action Menu

To configure an object on a symbol so that it provides access to the pick action menu of any item that you associate with the symbol, you need to:

  1. Configure a group parameter (select the Edit menu, then Parameters, then Add, then define the name of the parameter and select the Group check box). The name of the group parameter will be an option that you can use to select the required expression, so it is better to define a suitable name. For example, if the symbol is designed for use with points, name the group parameter Point.
  2. Configure a child parameter named ObjectLink. The ObjectLink parameter has to be a child of the group parameter that you created in the previous step. It also has to be named ObjectLink as this is the property that links the pick action menu of an item to the symbol.
  3. Double click on the parameter object on the Mimic to display its Polyline Properties window.
  4. On the General tab, select the Animations button to display the Animations window.
  5. Select the PickParam property on the Animations window.
  6. Select the Edit button to display the Expression window.
  7. Select the browse button to display a context sensitive menu.
  8. Select the option that is named the same as the parameter you created in step 1.
    A further menu is displayed.
  9. Select the ObjectLink option.
    The correct expression is shown in the Expression field. It has the format:
"Parameter:<name of group parameter>.ObjectLink"

  10. Select the OK button to confirm the expression and close the Expression window.
  11. Select the PickType property.
  12. Select the Edit button to display the Expression window.
  13. Enter the number 1 for the PickType. This is the number for an Object Menu. (For a list of the numbers, see Pick Action Animations for Mimic Objects).
  14. Select the OK button to confirm the expression and close the Expression window.
  15. Close the Animations window.
    The parameter object is now animated to provide access to the pick action menu of any item that is associated with the symbol.


Mimics Guide - Animating a Symbol Object to Provide Access to Selected Pick Actions Only (Animations)

Animating a Symbol Object to Provide Access to Selected Pick Actions Only

To configure an object on a symbol to provide access to selected pick actions for any item that is associated with the symbol, you need to:

  1. Configure a group parameter (select the Edit menu, then Parameters, then Add, then define the name of the parameter and select the Group check box). The name of the group parameter will be an option that you can use to select the required expression so it is better to define a suitable name.
  2. Configure a child parameter named ObjectLink. The ObjectLink parameter has to be a child of the group parameter that you created in the previous step. It also has to be named ObjectLink as this is the property that links the pick action menu of an item to the symbol.
  3. Double click on the symbol object to display its Polyline Properties window.
  4. On the General tab, select the Animations button to display the Animations window.
  5. Select the PickParam property on the Animations window.
  6. Select the Edit button to display the Expression window.
  7. Select the browse button to display a context sensitive menu.
  8. Select the option that is named the same as the group parameter you created in step 1.
    A further menu is displayed.
  9. Select the ObjectLink option.
    The correct expression is shown in the Expression field. It has the format:
"Parameter:<name of group parameter>.ObjectLink

This links the Mimic object with the pick action menu of any item that is associated with the symbol.

  10. Add the extra expression data for the specific actions that you want to exclude from the pick action menu. The extra expression data should be in the following format:
+'?<name of action>'"

Repeat the + '?<name of action>' part for each action that you want to be excluded. For the <?name of action> part of the expression requires a specific entry. The entries are the same as those used for a 'normal' Mimic (see Animating an Object to Provide Access to Selected Actions Only).

  11. Select the OK button to confirm the expression and close the Expression window.
  12. Select the PickType property.
  13. Select the Edit button to display the Expression window.
  14. Enter the number for the required PickType. For an Object Menu, the number is 1. (The PickType numbers are the same as those used for pick actions on 'normal' Mimics).
  15. Select the OK button to confirm the expression and close the Expression window.
  16. Close the Animations window.
    The object on the symbol is now animated to provide access to a pick action menu for any item that is associated with the symbol. The pick action menu will only include those options that have not been excluded in the expression for the PickParam property.


Mimics Guide - Animating a Symbol Object to Hyperlink to Another Display (Animations)

Animating a Symbol Object to Hyperlink to Another Display

You can use parameters to animate a symbol object so that it acts as a hyperlink to another display. The value of the parameter defines the location of the display that is to be shown when the object is selected (the 'target' display).

For more information, see Animating a Symbol Object to Hyperlink to Another Display.


Mimics Guide - Animating a Symbol Object to Perform a Specific Action (Animations)

Animating a Symbol Object to Perform a Specific Action

You can animate an object on a symbol so that it performs a specific action when it is selected. This type of pick action animation is referred to as a method.

When configuring a symbol, you need the method to apply to any item with which the symbol is associated. To do this, you need to set the expression for the PickType animation property to 5 (which corresponds to method) and set the expression for the PickParam to one of the following:

  • For a method on the database item:
"Parameter:<name of group parameter>.ObjectLink"+'?<name of method action>'

  • For a method on the aggregate for the database item:
"Parameter:<name of group parameter>.ObjectLink"+'?<name of aggregate>.<name of method action>'

  • For a method on the alarm condition for the database item:
"Parameter:<name of group parameter>.ObjectLink"+'?<name of alarm condition>.<name of method action>'

  • For a method on the alarm condition for the aggregate of a database item:
"Parameter:<name of group parameter>.ObjectLink"+'?<name of aggregate>.<name of alarm condition>.<name of method action>'

Where:

  • <name of group parameter> is the name of a group parameter that you configure for the Mimic.
  • ObjectLink is the name of another parameter that you have configured as a child of the group parameter.
  • <name of method action> is the name of the method that will be performed when the Mimic object is selected. The name has to be identical to the name of the method in the database. Do not include the angle brackets < >.
  • <name of aggregate> is the name of the aggregate in the database that provides the database item with access to the method. Do not include the angle brackets < >.

Database aggregates are special extensions to a database class that have their own names, fields, methods and alarm conditions. So, if a database item is part of a class that has an aggregate, the database item has access to the methods for its own class and the methods for the aggregate.

  • <name of alarm condition> is the name of the alarm condition in the database that provides the database item with access to the method. Do not include the angle brackets < >.

Alarm conditions are similar to database aggregates in that they provide access to additional fields and methods (specific to alarms). So, a database item can have access to the methods of its own class and the methods for the alarm conditions. As the aggregates can also have alarm conditions, it is possible for a database item to have methods for its own class, methods for its alarm conditions, methods for its aggregate, and methods for the alarm conditions of its aggregate.

You should use the Database Schema to determine whether the method you require is stored for the database item, an aggregate, an alarm condition, or an alarm condition for the aggregate and then use the appropriate syntax. For more information, see Working with the Database Schema in the ClearSCADA Guide to the Database.

The parameter format we have described is suitable for actions that have no arguments ('options' or 'parameters'), such as Enable Alarms. For this specific example, the expression would be:

"Parameter:<name of group parameter>.ObjectLink"+'?Enable'

Where <name of group parameter> is the name of a group parameter that you have configured for the Mimic.

For actions that do have arguments, you need to add extra information. The format for the extra information is:

&<name of argument>="<value of argument>"'

Again, you do not enter the angle brackets < >. This additional information allows you to specify a value that is set when the Mimic object is selected. For example, if you wanted the Mimic object to Override the value of a point to 8 when the Mimic object was selected, you would define the expression as:

"Parameter:<name of group parameter>.ObjectLink"+'?Override&Value="8"'

For actions where you want to set multiple arguments, you simply repeat the extra information, using this format:

&<name of argument1>="<value of argument1>"&<name of argument2>="<value of argument2>"&<name of argument3>="<value of argument3>"'

Where argument 2 is the second set of extra information, argument 3 is the third set and so on. In all cases, you do not enter the angle brackets < > or the numbers.

To configure a parameter object so that it performs a specific action when selected, you need to:

  1. Configure a group parameter (select the Edit menu, then Parameters, then Add, then define the name of the parameter and select the Group check box). The name of the group parameter will be an option that you can use to select the required expression so it is better to define a suitable name. For example, if the symbol is designed for use with the Acknowledge Alarms action, we suggest you name the group parameter Acknowledge Alarm. If the symbol is to be used with the Override action, name the group parameter Override and so on.
  2. Configure a child parameter named ObjectLink. The ObjectLink parameter has to be a child of the group parameter that you created in the previous step, and has to be named ObjectLink as this is the property that links the pick action menu of an item to the symbol.
  3. Double click on the parameter object to display its Polyline Properties window.
  4. On the General tab, select the Animations button to display the Animations window.
  5. Select the PickParam property on the Animations window.
  6. Select the Edit button to display the Expression window.
  7. Select the browse button to display a context sensitive menu.
  8. Select the option that is named the same as the group parameter you created in step 1.
    A further menu is displayed.
  9. Select the ObjectLink option.
    The correct expression is shown in the Expression field. This links the Mimic object with the pick action menu of any item that is associated with the symbol.
  10. Add the extra expression data for the specific action and any arguments. The extra expression data should be in the following format:
+'?<name of action>' &'<name of argument>="<value of argument>"

This format is explained at the start of this section. It defines the specific action that is to be performed when the object is selected on a Mimic, and also the specific argument (value, state, etc.) that will be set (if applicable).

  11. Select the OK button to confirm the expression and close the Expression window.
  12. Select the PickType property.
  13. Select the Edit button to display the Expression window.
  14. Enter the number for the required PickType. The numbers are the same as those used for the PickParam (for a list of the PickParam numbers, see PickComment Animations)—for a Method, the number is 5.
  15. Select the OK button to confirm the expression and close the Expression window.
  16. Close the Animations window.
    The parameter object is now animated to perform a specific action on any item that is associated with the symbol. The action will only be performed if it is suitable for the type of item that is associated with the symbol. For example, if the action was to acknowledge alarms for the item, and the item cannot have alarms, the action would not be performed.


Mimics Guide - Animating a Symbol Object to Write a Value to the Registry (Animations)

Animating a Symbol Object to Write a Value to the Registry

You can animate a symbol object to write a value to the registry when it is selected. The value in the registry can then be used to filter an embedded List, show or hide another object etc. in the same way that a registry value is used on a 'normal' Mimic.

To explain how to use the Registry type of pick action with a Symbol object, we are going to guide you through an example. As you perform the steps in the example, you will create a button that will write a value to the registry when it is selected. For the example, selecting the button will apply a different filter to an embedded List.

When you have performed the steps in the example, you will be able to adapt the procedure to meet your own requirements.

NOTE: This example assumes that you have a folder named OS Reg that contains Modbus points that are associated with outstations named Modbus Outstation 1 or Modbus Outstation 2. If the Modbus driver is not installed, you can replace the references to Modbus points with a different type of point (you will need to enter a suitable source entry and registry values).

To animate a 'button' on a Symbol to write a value to the registry:

  1. Create a new Mimic and enter a suitable name for it. This Mimic is going to be the 'button' symbol.
  2. Edit the Mimic.
  3. Draw a rectangle on the Mimic. Use the shading and color effects to alter the appearance of the button as required.
  4. Add a text box to the Mimic. Size the text box so that it is the same size as the rectangle and position it over the rectangle.
  5. Set the Fill of the text box to None so that it is transparent.
  6. Define a suitable color for the Pen and use the Font tab to define suitable settings for the text.
  7. Select the Edit menu, then the Parameters option to display the Parameters window.
  8. Add the following parameters:
  • BoxText
  • Registry
  • RegistryKey

The BoxText parameter represents the text that will be shown in the text box, the Registry parameter represents the value that is written to the registry, and the RegistryKey represents the type of value.

You can leave the default settings for the Hint and Default Value of each parameter.

  9. Display the Animations window for the text box.
  10. Define these animations:
  • PickParam—Enter the following expression:
"Parameter:RegistryKey" + '("' + "Parameter:Registry" + '")'

  • PickType—8
  • Text—Enter the following expression:
"Parameter:BoxText"

These animations mean that when an embedded version of the Symbol is selected, the value defined in the embedded Symbol's Registry property will be written to the registry. Similarly, the value that is defined in the embedded Symbol's Text property will be shown in the text box.

  11. Close the Animations window.
  12. Save the Mimic.
  13. Create a new Mimic. Again, enter a suitable name for the Mimic. This Mimic is going to contain an embedded List and two versions of the 'button' Symbol that will apply different filters to the embedded List.
  14. Embed two versions of the symbol on the Mimic. Size and position them so that the Mimic looks like this:
  15. Embed the Points List below the two symbols like this:
  16. Display the Animations window for the embedded List and define this animation:
  • Sql—Enter the following expression:
'SELECT "FullName", "Id", "Foreground", "Blink", "Background", "CurrentValueFormatted", "CurrentStateDesc", "SourceName"FROM CDBPOINT WHERE "SourceName"=''' + REGISTRY( 'OS Filter', ' ' ) + ''''

This defines the columns that are included in the List, the location of the data that is to be shown in the List (the CDBPoint table), and it also defines the filter as being the SourceName equals the Registry value. The Registry value will be saved as 'OS Filter'.

  17. Close the Animations window.
  18. Display the Animations window for the embedded symbol on the left-hand side.
  19. Define these animations:
  • BoxText—Enter the following string as the expression:
'Outstation 1'

  • Registry—Enter the following string as the value that is written to the registry:
'OS reg.Modbus Outstation 1'

  • RegistryKey—Enter the name of the Registry value (this has to match the registry setting in the SQL of the embedded List):
'OS Filter'

  20. Close the Animations window.
  21. Display the Animations window for the embedded Symbol on the right-hand side.
  22. Define these animations:
  • BoxText—Enter the following string as the expression:
'Outstation 2'

  • Registry—Enter the following string as the value that is written to the registry:
'OS reg.Modbus Outstation 2'

  • RegistryKey—Enter the name of the Registry value (this has to match the registry setting in the SQL of the embedded List):
'OS Filter'

  23. Close the Animations window.
  24. Save the Mimic.
  25. Display the Mimic in Run Mode.
  26. Select the 'Outstation 2' button. (The 'Outstation 2' text is provided by the animation of the symbol's BoxText property that you created as a parameter).
    The embedded List is filtered so that it only shows the points on 'Outstation 2'. When you select the button, a value is written to the registry and this value causes the specified filter to be applied to the List.
  27. Select the 'Outstation 1' button.
    The embedded List is filtered so that it only shows the points on 'Outstation 1'.


Mimics Guide - PickComment Animations (Animations)

PickComment Animations

You can animate the PickComment for an object so that when you place the cursor over the Mimic object, a specific string is shown in the status bar. The string can be a set of characters that you define, or it could be any string from the database. The string has to be enclosed by single quotes, for example, 'Pump Controls'.

To animate the PickComment, either define the required string in the Expression window for the PickComment property, or use the Expression window's browse button to associate the PickComment with the string value of a database item. For example, you can associate the PickComment with the FullName property of a point.

The pick comment is shown in the status bar (below the Alarm Bell Button if it is displayed) when the cursor is positioned over the object that works as a type of pick action menu (Object Menu, Hyperlink, Registry etc.).

NOTE: You can only animate the PickComment property if the Mimic object has been configured to work as a pick action on the Pick Action Wizard (for example, to work as a method pick action or an Object Menu pick action) or if it is animated to work as a pick action (PickParam and PickType properties are animated).


Mimics Guide - PickDisabled Animations (Animations)

PickDisabled Animations

You can animate the PickDisabled property of an object to control when a pick action menu is available for the object.

The expression for the PickDisabled property needs to equal TRUE for the pick action menu to be available, and it has to equal FALSE for the pick action menu to be unavailable.

You can enter True or False as the expression, or you can use a more complex expression that returns a True or False answer. For example, if a Mimic object is to provide access to a pick action menu only when a specific 1 bit digital point is in state 0, you would need to enter the following as the expression for the PickDisabled property of the Mimic object:

"<path and name of point>.CurrentState" = 0

Where <path and name of point> is the location and name of the point in the database. Do not enter the angle brackets < >.

CurrentState is the name of the point property that is used to animate the Mimic object's PickDisabled property.

The final part of the expression defines that if the CurrentState value of the point is 0, then the result of the expression is TRUE and so the pick action menu is available. If the CurrentState is not 0, the result of the expression is FALSE and the pick action menu is unavailable.


Mimics Guide - Rotation Animations (Animations)

Rotation Animations

You can use animations to rotate a Mimic object according to the value or state of an item in the database. To do this, you need to animate 2 Mimic object properties:

  • PivotType—defines the anchor position of the object when it is rotated, for example, if the value is 4 for the animation, the Mimic object will rotate from the right-hand side (the right-hand side will not move).

You need to define the PivotType as a number in your expressions. The numbers and corresponding pivot types are:
Number for Expression | Rotation Position
0 | Center
1 | Top Left
2 | Top
3 | Top Right
4 | Right
5 | Bottom Right
6 | Bottom
7 | Bottom Left
8 | Left

  • Rotation—defines the angle of rotation for an object. Typically, you animate the Rotation property in conjunction with the PivotType property to rotate an object from a specific position, such as its bottom left corner.

The Rotation property is often used in animations that show analog read-outs such as dials, where the following expression is used to associate the angle for the rotation with the value of the point:

( "<.Point>.CurrentValue" / ".Pressure.FullScale" ) * 360

Where <.Point> is the path and name of the point (do not enter the angle brackets < > ). The CurrentValue property is the point' s current value and the FullScale is the highest possible point value. 360 is the maximum angle.

The point' s value is divided by the point' s maximum value. The result of this is multiplied by the maximum angle (360) which results in the angle that is used for the Rotation animation.


Mimics Guide - Position Animations (Animations)

Position Animations

There are four position properties that can be animated to make use of the movement feature. This allows a Mimic object to move along a defined path according to the value of an item in the database.

When creating a position animation (also referred to as a movement animation), you need to:

  1. Display the relevant Mimic in Design mode.
  2. Right-click on the object that is to be moved by the animation.
    A context sensitive menu is displayed.
  3. Select the Define Path option.
  4. Draw the path line for the Mimic object in the same way as you would draw a line. The path line defines the route that the Mimic object will take as it moves.
  5. Double-click to end the path definition. The path is shown as a red line.
  6. Display the Animations window for the Mimic object.
  7. Animate the position animation properties so that the Mimic object's position is associated with values in the database.
  • The 4 position animations are:
  • PosAnchor
  • PosMax
  • PosMin
  • PosVal

The PosAnchor property defines the anchor position of the object when it is moving along a path. The PosAnchor values are the same as those for the PivotType (see Rotation Animations). For example, if the expression for the animation is 3, the top right part of the object will be on the defined path route.

The PosMax, PosMin, and PosVal properties are used to scale the possible positions and place the Mimic object at the correct position according to a value in the database. Typically, you would associate the PosMax property with the FullScale value of an analog point, the PosMin property with the ZeroScale of the point, and the PosVal property with the CurrentValue of the point.


Mimics Guide - Size Animations (Animations)

Size Animations

There are 4 size properties that you can animate so that an object increases or decreases in size according to the value of an item in the database. This is useful for adding bar graphs to Mimics.

The size properties are:

  • SizeDir—This property defines the direction of the size change. The directions and the numbers that represent them in the expressions are:

    Number for Expression

    Size Direction

    0

    None

    1

    Vertical down

    2

    Vertical center

    3

    Vertical up

    4

    Horizontal left to right

    5

    Horizontal left to right and vertical down

    6

    Horizontal left to right and vertical center

    7

    Horizontal left to right and vertical up

    8

    Horizontal center

    9

    Horizontal center and vertical down

    10

    Horizontal center and vertical center

    11

    Horizontal center and vertical up

    12

    Horizontal right to left

    13

    Horizontal right to left and vertical down

    14

    Horizontal right to left and vertical center

    15

    Horizontal right to left and vertical up
  • SizeMax—This property defines the maximum size of the Mimic object. Typically, this is associated with the FullScale property of an analog point.
  • SizeMin—This property defines the minimum size of the Mimic item. Typically, this is associated with the ZeroScale property of an analog point.
  • SizeVal—This property defines the current size of the Mimic object and needs to be associated with a value or state for an item in the database, for example, the CurrentValue of a point.


Mimics Guide - ToolTipText Animations (Animations)

ToolTipText Animations

You can use the TooltipText property to animate the ToolTip for an object. The ToolTip is displayed when you position the cursor over the Mimic object in Run mode.

Common animations for the TooltipText property include:

  • Showing current values, states, alarm states, descriptions by associating the TooltipText property with a CurrentValue, CurrentState, CurrentStateDesc, AlarmStateDesc property etc.
  • Showing instructions—you can enter any text as the expression for the TooltipText property, so you can provide extra information if required.
  • Showing calculated values—you can enter calculations as expressions so that the Tooltip shows the result when you position the cursor over the object. For example, you could enter the following expression to allow the ToolTip to show the average value of a point:
( "<path and name of point>.PreviousValue" + "<path and name of point>.CurrentValue" ) / 2

Where both <path and name of point> entries are the location and name of the same point (the point for which the average value is to be shown in the ToolTip).

ToolTip showing the average value of the point (the text box shows the current value of the same point)


Mimics Guide - Visibility Animations (Animations)

Visibility Animations

You can animate the Visible property of a Mimic object to define when the Mimic object can be seen. For example, you can animate the Visible property so that a Mimic object is only visible when a specific point has an alarm raised.

The expression for the Visible property needs to include a True/False definition—the Visible property can only be 0 which is False (invisible) or 1 which is True (visible). For example, you could use the following expression to control the visibility of a text box according to the alarm state of a point:

IIF( "<Point path and name>.AlarmState" = 0, 0, 1 )

Where <Point path and name> is the path and name of a point (do not enter the angle brackets < > ) and .AlarmState is the point property that animates the Visible property. The remaining part of the expression defines that when the point has an AlarmState of 0 (normal), the text box has a Visibility setting of 0 (invisible), and when the point has any other AlarmState, the Visibility is 1 (visible). This means that when an alarm is raised for the point, the text box is shown on the Mimic.

Text box is invisible when the Pressure point is not in alarm.
Text box is visible when the Pressure point is in alarm.

Embedded Trends also have the following visibility properties:

  • XAxisVisible—The value for this animation property defines whether the X-Axis is visible on the Embedded Trend.
  • YAxesVisible—The value for this animation property defines whether the Y-Axes are visible on the Embedded Trend.

As with the Visibility property, the values for the XAxisVisible and YAxesVisible properties need to be expressions that include a True/False definition—the Visible property can only be 0 which is False (invisible) or 1 which is True (visible).


Mimics Guide - Animations for Historic Data (Animations)

Animations for Historic Data

You can add animated historic values to a Mimic. This is useful when you want a Mimic to show calculated values, such as the daily average value of a point.

To use historic data in an expression, you need to include the Historic properties of a point. For example, you could animate a text box to show the daily average of a point by using the following expression to animate the Value property:

"<point path and name>.Historic.ProcessedValue ('D-1D', 'D+1D', 3)"

Where <point path and name> defines the location and name of the point for which you want to show historic data. Do not enter the angle brackets < >.

.Historic is the table that contains the point's historic values, and ProcessedValue is the historic value of the point. The remaining part of the expression defines the time scale and the type of calculation:

'D-1D' is the start time of the time range (resample interval). It is a time in the OPC standard format, and in this case is the start of yesterday (Start of Current Day - 1 Day = start of previous day).

'D+1D' is the end time for the time range. Again it is a time in the OPC standard format. In this case, the end time is the start of the next day (Start of Current Day + 1 Day = Start of Next Day).

3 is the number that corresponds to the type of algorithm (average). The possible types of algorithm and their corresponding number are:
Number for Expression | Algorithm | Meaning
1 | Interpolated | The interpolated value within the resample interval.
2 | Total | The totalized value (time integral value) of the values in the resample interval.
3 | Average | The mean average of the values in the resample interval.
4 | Count | The number of raw values in the resample interval.
5 | StdDev | The standard deviation of the values in the resample interval. This indicates how much the raw values in the resample interval deviate from the mean average values.
6 | Min | The lowest value in the resample interval.
7 | MinTime | The lowest value in the resample interval and the time stamp for the value.
8 | Max | The highest value in the resample interval.
9 | MaxTime | The highest value in the in the resample interval and the time stamp for the value.
10 | Start | The value at the start of the resample interval. The timestamp is at the start of the interval.
11 | End | The value at the end of the resample interval. The timestamp is at the end of the interval.
12 | Delta | The difference between the first value and the last value in the resample interval.
13 | Variance | The variance of the values in the resample interval. This indicates how much the raw values in the resample interval deviate from the mean average values.
14 | Range | The difference between the minimum value and the maximum value in the resample interval.
15 | DurGood | The amount of time (in seconds) for which the data in the resample interval is Good quality.
16 | DurBad | The amount of time (in seconds) for which the data in the resample interval is Bad quality.
17 | PerGood | The percentage of data in the resample interval that is Good (1=100%).
18 | PerBad | The percentage of data in the resample interval that is Bad (1=100%).
19 | Sum | The sum total of the values in the resample interval.
20 | 24hAverage | The average value during the previous 24 hours. The 24 hour period starts from the latest raw value.
21 | 8hAverage | The average value during the previous 8 hours. The 8 hour period starts from the latest raw value.
22 | 1hAverage | The average value during the previous hour. The hour period starts from the latest raw value.
23 | Stepped | The stepped value. Typically, you would not use this algorithm in an expression as it returns the last value in the resample interval.
24 | MinLast | The lowest last value in the resample interval. Last values are used when the resample interval contains null values—the last value is the previous raw value and it is used instead of a null value.
25 | MaxLast | The highest last value in the resample interval. Last values are used when the resample interval contains null values—the last value is the previous raw value and it is used instead of a null value.
26 | AverageLast | The average last value in the resample interval. Last values are used when the resample interval contains null values—the last value is the previous raw value and it is used instead of a null value.
27 | MinInterpolated | The lowest interpolated value in the resample interval. Interpolated values are used when the resample interval contains null values—the interpolated value is the difference between the raw values and it is used instead of a null value.
28 | MaxInterpolated | The highest interpolated value in the resample interval. Interpolated values are used when the resample interval contains null values—the interpolated value is the difference between the raw values and it is used instead of a null value.
29 | AverageInterpolated | The average interpolated value in the resample interval. Interpolated values are used when the resample interval contains null values—the interpolated value is the difference between the raw values and it is used instead of a null value.
30 | EndLast | The value at the end of the resample interval or the last value prior to the resample interval (if there are no values for the resample interval). The timestamp is the time at the end of the resample interval, even if the value returned was not reported during the time span for the resample interval.


Mimics Guide - Alarm Conditions in Expressions (Animations)

Alarm Conditions in Expressions

If you want to animate a property according to the alarm state of an item in the database, you will need to include an alarm condition in the expression for the property. The alarm condition is a number that corresponds to one of the possible alarm states, as follows:
Number for Expression | Alarm State
0 | Normal
1 | Disabled
2 | Acknowledged Uncleared
3 | Unacknowledged Cleared
4 | Unacknowledged Uncleared


Mimics Guide - Mimic Parameters

Mimic Parameters

Mimic parameters are special properties that you can create for symbol Mimics (generic Mimics that are designed to be embedded on other Mimics). The properties can then be animated in the same way as other properties.

Mimic parameters are normally used with faceplate symbols—Mimics that contain specific information that are designed to be embedded on other Mimics. Although the faceplate symbols are configured to contain specific information, they are not designed to contain information for specific objects in the database—they are usually designed to be generic, so that they can show the same set of information for various objects.

NOTE: Mimic parameters should not be confused with parameter database items. Mimic parameters are designed for use with symbols, whereas parameter database items are used to store values which can be used as the source value for a variety of features, including Mimics and Logic programs.

Example:

The following faceplate symbol is created to act as a generic display for Pumps. It is to contain the name of a pump, its state, alarm state description, and state description.

Text boxes will contain the name, alarm state description, state, and state description.
Pump image

The following parameters are created for the pump faceplate symbol:

The Pump parameter is a parent group parameter. It contains the 4 parameters: AlarmStateDesc, CurrentState, CurrentStateDesc, and PumpID. Each of the parameters has a unique property name—none of the parameter names are already in use by embedded Mimics (embedded Mimics have no AlarmStateDesc, CurrentState, CurrentStateDesc, or PumpID properties).

The PumpID is associated with the top text box. It is associated with the Text property of the text box. This means that when the symbol Mimic is embedded on another Mimic, it can have its PumpID property animated by a ViewX expression. The ViewX expression will either define a value or associate the PumpID with the value of an object in the database. The value for the PumpID will be used as the value for the text box's Text animation property.

The CurrentState is associated with the second text box (the text box directly below the top text box). It is associated with the Text property of the text box. This means that when the symbol Mimic is embedded on another Mimic, it can have its CurrentState property animated by a ViewX expression. The ViewX expression will either define a value or associate the CurrentState with the value of an object in the database. The value for the CurrentState will be used as the value for the text box's Text animation property.

The CurrentStateDesc parameter is associated with the Text property of the third text box and the AlarmStateDesc parameter is associated with the Text property of the bottom text box.

The parameters have names that correspond to fields in the database, except the PumpID parameter. There is no field named PumpID. The parameter names affect the Auto Configure option that can be used when animating the symbol when it is embedded on another Mimic.

The faceplate symbol Mimic is saved and is then embedded on another Mimic. The embedded faceplate symbol Mimic has the same animation properties as other embedded Mimics (see Embedded Mimic Animations), and also an extra group of animation properties—the Pump animation properties. The parameters are added to the list of available animation properties.

The Pump animation properties can be configured to have a ViewX expression that defines a specific value or associates the properties with database item properties. For example, the CurrentStateDesc animation property can be associated with the CurrentStateDesc property of a specific point.

The expressions for the animations can be made manually, on an individual basis. However, the AutoConfigure feature allows the Pump animation properties to be associated with the corresponding fields for a selected database item.

The AutoConfigure feature is made available by selecting the embedded Mimic and then dragging the required database item from the Database Bar onto the embedded Mimic. The Auto Configure Animations option sets the embedded Mimic's parameters to be associated with the corresponding fields for the selected database item. However, the Auto Configure Animations feature can only set up those animations where the parameter name matches a field name of the database item.

So, when the Pump symbol is associated with a database point, the Auto Configure Animations feature will associate the point's values with the parameters as follows:
Point Property | Associated with Parameter
CurrentState | CurrentState
AlarmStateDesc | AlarmStateDesc
CurrentStateDesc | CurrentStateDesc

The PumpID parameter is not configured automatically. This is because the database point does not have a property named PumpID. The PumpID parameter has to be associated with an expression manually.

In the Parameters section, you will find the following information:

  • Displaying the Parameters Window
  • Adding a Mimic Parameter
  • Associating a Mimic Parameter with a Mimic Item
  • Editing a Mimic Parameter
  • Removing a Mimic Parameter
  • Animating Mimic Parameters on an Embedded Mimic.


Mimics Guide - Displaying the Parameters Window (Mimic Parameters)

Displaying the Parameters Window

You need to access the Parameters window if you want to add, edit, or remove a Mimic parameter.

To display the Parameters Window:

  1. Display a Mimic in Design mode.
  2. Select the Edit menu.
  3. Select the Parameters option.

The Parameters window lists Mimic parameters (if any have been configured) under these headings:

  • Name—The name that has been allocated to the parameter.
  • Hint—The Hint indicates the type of ViewX field that can be used to animate the parameter. The hints are:
  • ViewXBlink—The parameter can be animated by the blink property of a database item.
  • ViewXColor—The parameter can be animated by the foreground or background properties of a database item.
  • ViewXFormatString—The parameter can be animated by the format string property of a database item. The format string database item property corresponds to the Format setting on the Point Form. It represents the type of formatting that has been set for the database item.
  • ViewXFullScale—The parameter can be animated by the high range property or the high engineering units property of a database item.
  • ViewXObjectId—The parameter can be animated by the Object Id property (an internal number), or the name value that is stored for the Alarm View, Help View, or Default View for a database item.
  • ViewXObjectName—The parameter can be animated by the Name value or the name that is stored for the Alarm View, Help View, or Default View for a database item.
  • ViewXText—The parameter can be animated by the Value, Units, Description, CurrentStateDesc, ObjectName, or ObjectNotes properties of a database item.
  • ViewXValue—The parameter can be animated by the Value of a database item.
  • ViewXVariant—The parameter can be animated by the Value, Units, Description, CurrentStateDesc, ObjectName, or ObjectNotes properties of a database item.
  • ViewXZeroScale—The parameter can be animated by the low range property or the low engineering units property of a database item.
  • Default Value—The value that is used for the parameter if a value is not provided by a database item or defined as part of a ViewX expression.

The Parameters window also contains these buttons:

  • Add—Use to add a parameter (see Adding a Mimic Parameter)
  • Edit—Use to edit a parameter (see Editing a Mimic Parameter)
  • Remove—Use to remove a parameter (see Removing a Mimic Parameter)
  • Close—Use to exit the Parameters window.

There is also a Test Value field that you can use to check that the parameter is working as you expected. Simply enter a suitable value to see how the parameter will use the value. For example, if you have set up a parameter that uses a color value, when enter a number (0-255) in the Test Value field the Mimic item that is associated with the parameter should change to the appropriate color. The settings you enter in the Test Value field are purely for test purposes—they are not stored.


Mimics Guide - Adding a Mimic Parameter (Mimic Parameters)

Adding a Mimic Parameter

You need to create a Mimic parameter for each custom property that you want to use on an embedded Mimic. Each parameter will represent a new custom property that you can associate with a Mimic item. The parameters for the embedded Mimic can be animated in the same way as the other embedded Mimic animation properties (see Embedded Mimic Animations).

To add a parameter:

  1. Display the Parameters window (see Displaying the Parameters Window).
  2. Select the Add button to display the Add Parameter window.
  3. Define the settings for the new parameter:
  • Name—Enter a suitable name for the parameter. Parameter names cannot be the same as any of the animation properties that are available for embedded Mimics. Each parameter name has to be unique within a set of parameters.

We recommend that, where possible, you enter parameter names that match the names of the OPC tags they are designed to represent. For example, if you are creating a parameter that is to show the current value of an item, we recommend that you name the parameter CurrentValue. Parameters that share the same names as corresponding OPC tags can be set up more quickly on a Mimic via the Configure All feature.

  • Parent—Use this combo box to choose the parent group parameter for a parameter. Parameters can be grouped so that they can be animated as one set of parameters rather than individually.

You can only select a parent group parameter if a group parameter has been created.

  • Group—Use this check box to define whether a parameter is a group parameter or a normal parameter. Group parameters can contain other parameters and are designed to allow you to animate several parameters at once.

Select the check box to set the parameter to be a group parameter or clear it to set the parameter to be a normal parameter.

  • Hint—You can use the Hint combo box to choose the type of ViewX value that can be represented by the parameter. We recommend that you leave the Hint combo box set to the default setting of None, as ViewX will usually detect the appropriate type of ViewX value automatically.
  • Default Value—Enter the value that will be used for the parameter if no other value is provided by an expression.

When you have created the parameters you require, you need to associate them with items on a Mimic (see Associating a Mimic Parameter with a Mimic Item).


Mimics Guide - Associating a Mimic Parameter with a Mimic Item (Mimic Parameters)

Associating a Mimic Parameter with a Mimic Item

When you have created Mimic parameters, you need to associate them with Mimic items on a Mimic that is to be embedded. When you associate a parameter with a Mimic item property, when you animate the Mimic item it will show the value for the parameter. For example, if you create a parameter that shows the FullName value of an item and you associate it with the Text property of a text box, the text box will show the full name of any database item that is used to animate the text box.

To associate a parameter with a Mimic item:

  1. Display the Parameters window (see Displaying the Parameters Window).
  2. Position the Parameters window so that you can select the Mimic item and a parameter (you will need to drag the parameter onto the Mimic item).
  3. Select the required Mimic item.
  4. Select the required parameter and drag it onto the Mimic item.
    A context sensitive menu is displayed.
  5. Select the option for the Mimic item animation property that you want to associate with the parameter. For example, if you want the value of a parameter to be shown in a text box, associate the parameter with the text box's Text property.
  6. Repeat steps 2-5 inclusive for other parameters and Mimic items as required, then save the Mimic.

When you have associated parameters with Mimic items, you need to embed the Mimic and then animate its parameters (see Animating Mimic Parameters on an Embedded Mimic).


Mimics Guide - Editing a Mimic Parameter (Mimic Parameters)

Editing a Mimic Parameter

You can change the configuration of any Mimic parameter as required. To edit a parameter:

  1. Display the Parameters window (see Displaying the Parameters Window).
  2. Select the parameter that you want to edit.
  3. Select the Edit button to display the Edit Parameter window.
  4. Alter the settings on the Edit Parameter window as required, then select the OK button to confirm. The settings on the Edit Parameter window work in the same way as the corresponding settings on the Add Parameter window.


Mimics Guide - Removing a Mimic Parameter (Mimic Parameters)

Removing a Mimic Parameter

To remove a Mimic parameter:

  1. Display the Parameters window (see Displaying the Parameters Window).
  2. Select the parameter that you want to remove.
  3. Select the Remove button.

NOTE: If you remove a 'parent' group parameter, the 'child' parameters in the group are also removed.


Mimics Guide - Animating Mimic Parameters on an Embedded Mimic (Mimic Parameters)

Animating Mimic Parameters on an Embedded Mimic

When you have embedded a Mimic that has Mimic parameters, you can animate the parameters in the same way as you would animate any of the other embedded Mimic animation properties. However, if you have defined parameters that have the same name as OPC tags, you can also use the Auto Configure feature.

The Auto Configure feature is a useful tool that allows you to animate each parameter with suitable properties. It works by providing a Wizard that guides you through a simple, step-by-step procedure.

There are 3 ways to animate the parameters on an embedded Mimic:

  1. Using the Animations window.

You can use the Animations window to animate the parameters for an embedded Mimic. To do this, display the Animations window for the embedded Mimic (see Displaying the Animations Window), then select the parameter followed by the Edit option to display the Expression window. Use the Expression window to define a value or enter an expression that associates the value with one of the properties of a database item.

NOTE: Parameters that do not share their name with a corresponding OPC Tag for the required database item often need to be animated in this way. The system associates the parameter with the default value for the database item (if the parameter name does not match one of the item's OPC tags). However, the default value may be unsuitable for your parameter.

  2. Using the default association method. This method associates the selected parameter with the corresponding OPC tag or the default value for the database item.

We recommend that you only use the default association method if the embedded Mimic parameters have names that match the appropriate OPC tags for the required database item.

  1. Drag and drop the required database item from the Database Bar onto the embedded Mimic.
    A context sensitive menu is displayed.
  2. From the context sensitive menu, either:
  • Select the parameter that you want to associate with the selected database item.

If the parameter has the same name as the corresponding OPC tag for the database item, the animation is set up automatically—the object's value for the OPC tag is used as the value for the parameter.

If the parameter has a different name to the corresponding OPC tag, the parameter is associated with the default value for the database item. You may need to change the animation expression by using the Animations window (see Step 1).

NOTE: Instead of selecting a specific parameter, you can select the Configure All option. The Configure All option automatically associates the parameters in the group with the corresponding OPC tags or default tags of the selected database item.

  3. Using the Animation Wizard.

The Animation Wizard automatically detects which database item properties are suitable for each parameter. You simply choose whether the parameter is animated, and if so, by which property.

To use the Animation Wizard:

  1. Drag and drop the required database item from the Database Bar onto the embedded Mimic.
    A context sensitive menu is displayed.
  2. Select the Auto Configure Animations option to display the Animation Wizard.
    ClearSCADA automatically detects those properties that can be used to animate the selected parameter. Simply choose the required property.
    Use the check box to define whether the parameter is to be animated.

  3. Use the Yes, animate the property check box to define whether the property is to be associated with a value in the database. Select the check box if the property is to be animated otherwise leave it clear.
  4. Choose the database item property that is to be associated with the parameter from the list. ClearSCADA automatically detects those database item properties that can be used to animate the parameter.
  5. Select the Next button.
  6. Repeat steps iii to v inclusive for each parameter, then select the OK button to complete the parameter animations.

NOTE: You can configure a hyperlink to define the parameter values for a target Mimic (that uses Mimic parameters). For more information, see Hyperlinks that Define Values for Mimic Parameters on a Target Mimic.


Mimics Guide - Troubleshooting - Mimics

Troubleshooting - Mimics

This section describes:

  • Displaying Mimic Diagnostics
  • Using the Mimic Navigator to Locate Invalid Animations and Pick Actions
  • Slow Mimic Performance.

The Mimic Details window provides diagnostic information for the Mimic that is on display. If the Mimic is running too slowly, you may need to use the diagnostic information when attempting to improve performance.


Mimics Guide - Displaying Mimic Diagnostics (Troubleshooting - Mimics)

Displaying Mimic Diagnostics

You can use the Mimic Diagnostic feature to view statistics about the Mimic on display. The statistics are useful for diagnostic purposes, for example, you can determine whether there is a high level of processing required due to an excessive number of segments (this is common with imported DFX files).

To display the Mimic Diagnostics:

  1. Select the View menu.
  2. Select the Mimic Diagnostics option.
    The Mimic Details window is displayed. It contains information about the quantity of each type of Mimic item and segment on the Mimic.


Mimics Guide - Using the Mimic Navigator to Locate Invalid Animations and Pick Actions (Troubleshooting - Mimics)

Using the Mimic Navigator to Locate Invalid Animations and Pick Actions

You can use the Mimic Navigator feature to locate any invalid expressions for animations or incorrectly configured pick actions. The Mimic Navigator is a useful feature as it allows you to quickly identify which Mimic objects are configured incorrectly. It is also useful for selecting Mimic objects that are parts of groups or are positioned behind other Mimic objects and are more difficult to select with the cursor.

When you access the Mimic Navigator, the Mimic Navigator displays a tree structure. The tree structure contains a hierarchy. At the top level of the hierarchy are folders for each Layer on the Mimic. Each Layer folder contains representations of the Mimic objects that are positioned on that Layer on the Mimic. The Mimic objects can include shapes, buttons, embedded lists, or groups of objects. If a group of objects is listed, it is represented by a group folder icon that, when expanded, reveals the individual Mimic objects that form the group object.

If an animation or pick action is configured incorrectly, the Mimic Navigator will show the name of the incorrect Mimic object in red. It also uses red to indicate which Layer contains the erroneous Mimic object. If a grouped object is configured incorrectly, the object, its group, and the Layer on which the group is positioned, are all displayed on the Mimic Navigator in red.

To access the Mimic Navigator:

  1. Display the Mimic that you want to check for incorrect expressions. You need to display the Mimic in Design mode (see Displaying a Mimic).
  2. Select the View menu, then select the Mimic Navigator option.
    The Mimic Navigator is displayed.

If any of the Layer group names are shown in red, there is an incorrect animation or pick action for a Mimic object in that Layer. If the Layer group names are shown in black, it means the objects have valid configuration.

  3. Expand the Layer group(s) to locate the Mimic object (or group of objects) that has incorrect configuration. The Mimic object that has invalid configuration has its name displayed in red. There may be one or more Mimic objects with incorrect configuration, and each object may have multiple configuration errors.
  4. Double-click on the name of the required Mimic Object to select it on the Mimic and to display its Properties display.
  5. Use the Properties display to correct the configuration of the invalid animation or pick action, then Save the changes you have made.
  6. On the Mimic Navigator window, select the Validate button. The Mimic Navigator will refresh its data. If the changes you have made have corrected the configuration, the Mimic object will no longer be shown in red (though the name of the Layer that contains the Mimic Object will remain red). If you introduced a new configuration error, the Mimic object will continue to have its name displayed in red, as will the Layer that contains the object.


Mimics Guide - Slow Mimic Performance (Troubleshooting - Mimics)

Slow Mimic Performance

If a Mimic appears to be running slowly, you can try to improve performance by:

  • Upgrading your hardware or alter the network settings (see Changing Hardware and Network Settings to Improve Mimic Performance).
  • Altering the Mimic so that it places less demand on the processor (see Simplifying Mimics to Reduce the Demand on the Processor).


Mimics Guide - Changing Hardware and Network Settings to Improve Mimic Performance (Troubleshooting - Mimics)

Changing Hardware and Network Settings to Improve Mimic Performance

There are several hardware-related issues that can contribute to slow performing Mimics, including:

  • Slow server-client network speed—You can use Windows commands to investigate the speed of your server-client connections. In particular, PING allows you to check the speed of communications between the client and server.

You can also use the Windows trace route command (tracert -d) to investigate the path of the data as it is transferred through a network. This is useful for locating the network link that is causing the slow transfer speed.

If you locate a slow connection, the first step you should take is to enable Compression for the Node Cost on the ClearSCADA Client Configuration window (access the ClearSCADA Client Configuration window by double-clicking on the ClearSCADA Client icon in the Windows Control Panel). This should speed up the data transfers between your client PC and the ClearSCADA server.

ATTENTION: If your PC is connected to the server via a Local Area Network, enabling the Compression feature may worsen data transfer speed.

If the server-client network connection is still too slow, you will need to check the network hardware and infrastructure. You should check the latency and available bandwidth. Another factor to consider is that the switches, routers, etc. are working correctly and are suitable for the network requirements.

If the server-client connection speed is adequate, you may need to replace the graphics card or processor in your PC (see below).

  • Slow graphics card—Replace the graphics card with an up-to-date 3D AGP or PCIe graphics card.
  • Non-3D graphics card—Replace the graphics card with an up-to-date 3D AGP or PCIe graphics card.
  • PCI graphics card instead of AGP graphics card—Replace the graphics card with an up-to-date 3D AGP or PCIe graphics card.
  • Insufficient processing power—You can use Windows Task Manager to examine your CPU usage. On the Processes tab, examine the CPU entry for the ViewX.exe process. If it is around 98, the Mimic is placing a high demand on the processor.

You will need to upgrade your PC's processor.

  • Server is busy—If there is a high demand on the server's processor, the server may be unable to process data requests from your client PC efficiently. You will need to use the Windows Task Manager to investigate the performance of the server.

The server's processor may need to be upgraded.

  • Client disk is fragmented—If the cache on your client PC is fragmented, it can cause slow Mimic performance as the Mimic is stored in the cache. We recommend you use Windows to defragment the client's hard disk.


Mimics Guide - Simplifying Mimics to Reduce the Demand on the Processor (Troubleshooting - Mimics)

Simplifying Mimics to Reduce the Demand on the Processor

If you want to simplify your Mimics to improve their performance, you need to be aware of the Mimic configuration aspects that place the highest demand on the processor:

  • High Number of Transparent Items—Transparent and semi-transparent items require a higher amount of processing than solid colors. You can check the number of transparent items by examining the Transparent Objects data on the Mimic Details window (see Displaying Mimic Diagnostics).

Transparent items are a common cause of slower processing on Mimics that appear to be quite simple. The transparent items cannot be seen and yet cause a significant demand on the processor.

If your Mimic is slow, we suggest you investigate each of the possible causes. If a high number of transparent items appears to be causing slow performance, we suggest that you remove any unnecessary transparent or semi transparent effects.

  • High Number of Items with Gradient Shading—Items that have fill gradient, pipe gradient, or radial gradient shading cause a higher processing demand than solid color items. This is because gradient shading is more complex and requires extra processing.

You can examine the number of items with gradient shading by displaying the Mimic Details window and checking the various gradient fill entries (see Displaying Mimic Diagnostics).

If your Mimic is slow, we suggest you investigate each of the possible causes. If a high number of gradient fills appears to be causing slow performance, we suggest that you replace some of the gradient shading with solid shading.

  • High Number of Polylines—Mimics with a high number of polylines can cause extra demand on the processor. You may be able to reduce the number of polylines by using fewer lines with more segments. For example, Mimics that contain imported DXF files often contain excessive numbers of polylines as the lines on DXF files often consist of many separate lines—many of these lines are redundant.
  • High Number of Embedded Mimics—If your Mimic contains a high number of embedded Mimics, you may be able to improve performance by increasing the Embedded Mimic Cache Size setting on the Options window. To access the Options window, select the Tools menu, then the Options option. The Embedded Mimic Cache Size setting is located on the General tab.
  • Excessive Amount of Updates due to Fast Update Feature—When a Mimic updates, ViewX redraws the Mimic so that it is accurate. This can affect performance if there are an excessive amount of updates (due to a high number of Mimic items using the Fast Updates feature).

To determine the number of items that use the Fast Update feature on a Mimic, you need to examine the entries on the OPCDA Groups tab of the Server Status Tool (see Overview of the Server Status Tool in the ClearSCADA Guide to the Server Status Tool). First you should close any other Mimics on your client, then access the OPCDA Groups tab. In the Name column, examine the entries for your client PC—the entry with Fast at the end of the name is the entry for the Mimic you have on display. The Items number for the Fast entry is the number of items with Fast Update enabled on the Mimic.

If there are a high number of items with Fast Update enabled, you should either reduce the Fast Update rate so that the Mimic updates less frequently or disable the Fast Update feature for some items.

To change the Fast Update rate, see Define the Update Rates for a Mimic.

To disable the Fast Update feature, see Using the Expression Window.


Trends Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Trends Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Trends Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Trends Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Trends Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Trends Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to operate and configure Trends in ClearSCADA.

For details on the subjects covered in this Guide, see Welcome to the Trends Guide.


Trends Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for use by:

  • Operators and administrators who use Trends to view and compare data over time
  • Engineers who are responsible for creating and configuring Trends in the database.


Trends Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Trends Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Expressions

ClearSCADA Guide to Mimics

ClearSCADA Guide to Scripting

ClearSCADA Guide to X-Y Plots

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


Trends Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Trends Guide - Welcome to the Trends Guide

Welcome to the Trends Guide

Welcome to the ClearSCADA Guide to Trends. Trends are graphs that allow you to view and compare the data values of items in your database.

ClearSCADA supports Pre-Configured Trends, File Based Trends and Ad Hoc Trends.

In this Guide, we explain how to configure and use the various types of Trend.

When you have a good working knowledge of the Trend features, you will be able to create new Trends, and use Trends to view and compare the data for items in the database.

The Guide to Trends includes information on:

  • Understanding Trends
  • Configuring Trends
  • Using TrendSpec to Produce Ad Hoc Trends
  • Using Trends.

NOTE: You can display Trends on either a ViewX or WebX Client, but to configure a Trend you can only configure a Trends using the ViewX Client.


Trends Guide - Understanding Trends

Understanding Trends

Trends are graphical displays that plot the values of database points and time profiles. They allow you to view and compare the values of points over a specific period of time. This is particularly useful when you need to determine if there are any patterns in the data, for example, you may need to compare the level of water in three different rivers over a month period.

Visually, Trends have a similar appearance to X-Y Plots, but they have very different purposes:

  • Trends allow you to view values over a specific time period, with each value on the Trend representing a point value. Trends can be user-created in the database, automatically generated by ClearSCADA, or user-created and stored as an independent file.
  • X-Y Plots are designed for monitoring the historic values of related points. Each plotted value consists of two values - one taken from one point and the other from a different point. For more information on X-Y Plots, see Understanding X-Y Plots in the ClearSCADA Guide to X-Y Plots.

In this section, we explain the differences between the various types of Trend (see Pre-Configured Trends, File Based Trends and Ad Hoc Trends) and describe the features of the Trend display (see Understanding the Trend Display).


Trends Guide - Pre-Configured Trends, File Based Trends and Ad Hoc Trends (Understanding Trends)

Pre-Configured Trends, File Based Trends and Ad Hoc Trends

ClearSCADA supports these different types of Trend:

  • Pre-Configured Trends—These Trends are represented in the database by Trend database items. Pre-Configured Trends can display multiple traces and may combine current, raw historic and processed historic data on a single display. The configuration of these Trends is stored in the ClearSCADA database, and is retained when you close the Trend display.
  • File Based Trends—These Trends are similar to Pre-configured Trends in that they are created in ClearSCADA. However, File Based Trends are not stored in the database; they are stored as files that are separate from the database.
  • Ad Hoc Trends—ClearSCADA supports two types of Ad Hoc Trend.

‘Standard’ Ad Hoc Trends are generated by ClearSCADA on command and are not stored in the database. You can display a ‘standard’ ad hoc Trend by selecting the Display Current Trend or Display Historic Trend pick action or menu option (see Display a Trend in Run Mode). ‘Standard’ Ad Hoc Trends are temporary, and any configuration is lost when the Trend display is closed.

ClearSCADA also supports ‘Custom’ Ad Hoc Trends. ‘Custom’ Ad Hoc Trends can be configured using ClearSCADA’s proprietary specification language, TrendSpec. The configuration of these Trends is stored in the ClearSCADA database and is retained when you close the Trend display. Usually, ‘custom’ Ad Hoc Trends are accessed via hyperlinks on Mimics.

The trace(s) on Trends may display either:

  • Current Data—A trace that updates according to the current value of the point or master station accumulator. When the Trend is closed, the data displayed on the Trend is disregarded and cannot be re-displayed on the Trend.
  • Historic Data—A trace that displays historic data that has been logged by the ClearSCADA server into the Historic database (providing that Historic logging is enabled). Usually, there are a limited number of points and/or accumulators that have Historic logging enabled, as historic logging uses disk space on the ClearSCADA server.

When you display historic data on a Trend, the Trend displays the historic data that was logged during a specific time period. You can view the historic values either side of this period by panning the Trend (see View Earlier or Later Values on a Trend).

NOTE: The configuration of the point object determines if the ‘standard’ ad hoc Trend will display Raw Historic or Processed Historic data (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

You can create and configure Pre-Configured, File Based, and ‘custom’ Ad Hoc Trends in ClearSCADA providing that your User Account is assigned the Configure permission. You configure such Trends on a ViewX Client. For more information, see Configuring Trends, and see Using TrendSpec to Produce Ad Hoc Trends.

You can display many types of Trend on a ViewX or WebX Client (see Using Trends). Be aware that some web browser applications provide limited hyperlink support, which may stop some complex ‘custom’ Ad Hoc Trends from displaying in WebX.

Both Pre-configured Trends and Ad Hoc Trends can be saved as files. You can then open them in ClearSCADA at any time by selecting the File menu, then the Open option and browsing to the required Trend file.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends


Trends Guide - Understanding the Trend Display (Understanding Trends)

Understanding the Trend Display

Each Trend has an x-axis that represents time and one or more y-axes that represent the range of possible data values. The actual values of the points or master station accumulators are plotted on the Trend and are represented by markers which are connected by a trace line. The trace line can be a line, outlined bar, filled bar or stepped line. You can configure a Trend to display one or more traces simultaneously.

Key area displays information about the source of the Trace(s).
The database point values that are plotted on the Trend are represented by trace lines and markers.
The x-axis represents a specific period of time.
The y-axis represents the range of possible values.
The Title describes the Trend.

The Trend Window consists of:

  • Trend Trace
  • Trend Markers
  • Trend X-Axis
  • Trend Y-Axis
  • Trend Key
  • Trend Title.

It may also contain Trend Alarm Limits and Trend Annotations.


Trends Guide - Trend Trace (Understanding Trends)

Trend Trace

The Trace is a line that represents a point’s values over a period of time. You can display multiple traces on a Trend simultaneously.

The values that are plotted on the Trend are indicated by Trend Markers. The Trace line joins the markers.

When viewing a Trend, you can use the Hide Trace feature to remove one or more traces from view (see Hide and Show a Trace). This is useful when there are multiple traces on the Trend and the amount of data on display makes it difficult to use the Trend.

You can configure the trace to alter its source (the point that provides the values that are plotted on the Trend) and appearance. If your User account has the Configure permission, you can change the style and color of trace and change the type of trace markers as required (see Configure a Trace).

There are two types of trace:

  • Current Trace—Represents the current value of a point. A trace can be configured as a current trace for any database point. When a current trace is displayed, the trace is continually updated in the Trend display with the current value of the point.

As the trace is continuously updated, more and more values are plotted on the Trend. Over time, this will cause the Trend to scroll into the next interval as it is set to display the latest values. By using the Previous Interval tool or the Pan tool, you can set the Trend to display earlier values (you can view any of the values that have been plotted since you displayed the Trend). As the trace only represents current data, you cannot view values that were recorded before the Trend was displayed.

When you close the Trend, the current trace data is discarded and cannot be re-displayed on the Trend.

  • Historic Trace—Represents the historic value of a point. Historic traces are only available for those database points that have historic logging enabled in their configuration.

Historic traces show the values that have been stored historically for the point (have been stored in the historic database). Unlike with current traces, historic traces allow you to scroll backwards to earlier values that were recorded before the Trace was displayed. By using the Pan tool or Previous Interval tool, you can view any of the point’s historic values on the Trend.

Pre-Configured Trends, File Based Trends, and ‘Custom’ Ad Hoc Trends are capable of displaying current and historic traces simultaneously. ‘Standard’ Ad Hoc Trends can only display current traces or historic traces—they cannot display both simultaneously.

Further Information

View Earlier or Later Values on a Trend.


Trends Guide - Trend Markers (Understanding Trends)

Trend Markers

Trend markers are indicators that represent the individual values of the source point. They are shown on traces and are displayed by default.

Trend markers.

If your User account has the Configure permission, you can change the style and size of markers for each trace. You can choose from diamond, cross, or square shaped markers.

The color of the markers represents the quality of the data. The default marker colors are (from left to right):

  • Cyan—There is an annotation for the value.
  • Magenta—The data is deemed to be of bad quality. The data may be unreliable.
  • Blue—The data has been inserted or modified by a user.
  • Red—The data has not been validated by a user. This only applies when your system has been configured to have the Historic Validation feature enabled (it is disabled on the ClearSCADA Server Configuration Tool by default—see Enable or Disable Manual Historic Data Validation in the ClearSCADA Guide to Server Administration).
  • Green—The data is deemed to be of good quality (or it has been validated by a user if the Historic Validation feature is enabled on your system).

NOTE: The marker colors for your system may be different as they can be changed for each point via the point’s Color Palette (see Configure the Display Settings for a Trend).

Markers are shown on each trace by default, but you can choose to hide them as required (see Hide and Show Markers). The Hide Markers feature is often useful when there are multiple traces and the number of markers makes it difficult to use the Trend.


Trends Guide - Trend X-Axis (Understanding Trends)

Trend X-Axis

The x-axis is displayed at the bottom of the Trend by default. It represents an interval—the amount of time that can be shown on the Trend at once. For example, if a Trend has an x-axis that represents one hour, the Trend can only show one-hour’s worth of data on a single display.

x-axis

If you magnify the Trend (zoom in or out), you change the x-axis interval so that it shows a smaller or greater amount of time. If you have zoomed in or zoomed out, you can revert the Trend to the default setting for the x-axis by using the Revert to Defaults feature (see Display the Default Time Scale on a Trend). The default setting for the Trend is the x-axis interval that is saved for the Trend.

If your user account has the Configure permission, you can Configure the X-Axis.


Trends Guide - Trend Y-Axis (Understanding Trends)

Trend Y-Axis

Each Trend has at least one y-axis and can have many y-axes if required.

A y-axis is displayed by default at the left-hand side of a Trend. It provides a scale that allows you to determine how the point values (shown on the trace) compare to the entire range of possible values.

The y-axis has a title that indicates what the values represent and uses numerical values as a scale for the range of possible values (see Configure a Y-Axis).

Each Trend can display one or more y-axes (see Add a Y-Axis). The y-axes are added during configuration of the Trend and are used to show different scales. For example, a Trend could have two y-axes and two traces (each y-axis represents the scale for one of the traces).


Trends Guide - Trend Key (Understanding Trends)

Trend Key

The Key is displayed at the bottom of the Trend display. It lists the traces that are shown on the Trend and provides information about the source of the trace, its values, category, and so on.

Each row of the Key provides information for one of the traces on the Trend. By default, the key displays information in three columns: Trace, Type and Ruler Value. If your User account has the Configure permission for the Trend, you can use the Columns feature to display different or additional columns (see Define the Columns on the Key).

The predefined columns that can be displayed in the key include:

  • Trace—Indicates the label of the trace. The label is defined when the Trend is configured, and usually indicates the type of data that the trace represents. Each label is displayed in the same color as the markers for the trace (if markers are used).

The Trace column is shown by default.

  • Offset—Shows the offset that is in place (if any). The offset defines the start time that is shown on the x-axis and is defined when the Trend is configured.
  • Axis—Shows the label of the y-axis that is used as the range for the trace.
  • Algorithm—Shows the type of calculation (if any) that is performed on the raw historic data to produce the processed values that are shown on the trace (see Built-In Historic Algorithms for Processed Historic Data).

NOTE: The Algorithm column shows the type of calculation that is applied to the values on the trace—it does not show the result of the calculations (some of the results can be shown in other columns such as the Std.Dev column).

  • System—Indicates the name of the system on which the item represented by the trace is stored.
  • Type—Indicates whether the trace represents current data, raw historic data (historic data as it was reported), or processed historic data (calculated historic data). For more information on raw and processed historic data, please refer to:
  • Raw Historic Data on Trends
  • Processed Historic Data on Trends
  • Ruler Prev—Shows the last value that was plotted on the trace before the ruler value. (The ruler value is a value at a specific place on the Trend. The place is selected by using the Ruler tool—see Use the Ruler.)
  • Ruler Value—Shows the value at the position where the ruler line intersects the trace. (The ruler line is used to mark a specific place on the Trend—see Use the Ruler.)
  • Ruler Next—Shows the next value that was plotted on the trace after the ruler value. (The ruler value is a value at a specific place on the Trend. The place is selected by using the Ruler tool—see Use the Ruler.)
  • Latest Value—Shows the most recent value to be plotted on the trace.
  • Count—Shows the number of values that are shown on the trace.
  • Sum—Shows the sum total of the values that are shown on the trace.
  • Total—Shows the totalized (time integral) value of all of the values that are shown on the trace for the resample interval. The resample interval is defined in the configuration of the processed historic trace and defines the sample of values that are to be included in the calculation (the values in the resample interval time period). For more information on the resample interval, see Configure a Trace.

The result of the total calculation is equal to the area below the trace.

  • Minimum—The lowest value that is shown on the trace.
  • Maximum—The highest value that is shown on the trace.
  • Mean—The mean average value of the values that are shown on the trace.
  • Range—The range value of the values shown on the trace. This is the difference between the highest value on the trace and the lowest value on the trace.
  • Delta—The delta value is the difference between the first value on the trace and the last value on the trace.
  • Std. Dev.—The standard deviation of the values on the trace.

Statisticians often use standard deviation as a measure of spread. It allows the percentile rank to be calculated for any value on the trace. You will need an understanding of statistics to make use of the information provided in the Std.Dev column.

  • Variance—The variance of the values on the trace.

Like standard deviation, variance is used to measure the extent of the spread of values on the trace. As with the Std.Dev column, you will need an understanding of statistics to make use of the information provided in the Variance column.

  • Source(s)—The data source. The name of the item from which the values on the trace originate. The Sources entry also shows the scaling factor and an offset for the trace. By default, there is no scaling factor or offset applied, so the name of the source is followed by (x1.0, +0.0) where x1.0 is the scaling factor and +0.0 is the offset.

NOTE: Any calculated values are based on the time scale defined in the configuration of the x-axis (see Configure the X-Axis).


Trends Guide - Trend Title (Understanding Trends)

Trend Title

The Trend title is displayed at the top of the Trend and is normally used to describe the information that is shown on the Trend.

Title

It is defined when the Trend is configured (see Configure the Display Settings for a Trend).


Trends Guide - Trend Alarm Limits (Understanding Trends)

Trend Alarm Limits

When a point is used as the source of a Trace, it is possible to display the point’s alarm limits on the Trend. This is useful, as it allows you to compare the values plotted on the trace to the point’s High High, High, Low, and Low Low thresholds.

There are two types of alarm limits:

  • Constant Alarm Limits—Alarm limits that are constant and are defined in the configuration of a point. Many point types have constant alarm limits.

For example, the constant alarm limits for an analog point are defined in the point’s configuration, and match the value settings for the various thresholds (High High, High, Low, Low Low). So if the High limit is defined as 70, the High threshold for the point is fixed at 70 (unless the configuration is altered).

Constant alarm limits are shown as horizontal dotted lines.

Constant alarm limits are shown as horizontal, dotted lines and can be displayed and hidden by using the Show and Hide options (see Hide and Show the Alarm Limits). The lines are red by default, but you can change the color on a system-wide basis, if required (see Define the Colors for Point Trend Graphs in the ClearSCADA Guide to Server Administration).

You can also use the ClearSCADA Server Configuration Tool to change the default color from red to a color of your choice (see Define the Colors for Point Trend Graphs in the ClearSCADA Guide to Server Administration).

  • Variable Alarm Limits—Alarm limits that vary according to the time of day. Variable alarm limits require the point to be associated with a Time Profile and are only available for analog points on certain drivers.

A point can have one or more of its alarm limit thresholds associated with a Time Profile. The configuration of the Time Profile defines different values for different times of the day, for example, a Time Profile could be configured to have a value of 80 during daytime and 50 at night. If the Time Profile was associated with the High limit of an analog point, it would mean that the High alarm limit for that point changes from 50 to 80 and back to 50 depending on the time of day.

Variable alarm limits are shown on Trends as a trace rather than a line (as the alarm limit varies and so has to be plotted). By default, the variable alarm limits are similar in appearance to constant alarm limits, with the trace shown as a red dotted line. You can alter the appearance of the variable alarm limits by editing the trace (see Configure the Display Settings for a Trend).

Variable alarm limits are shown as dotted traces (by default).

As variable alarm limits are treated as traces, they are not affected by the Show and Hide Alarm Limits options. To display or hide a variable alarm limit, you need to use the Show and Hide Trace options for the variable alarm limit trace.

NOTE: If an analog point has constant values for some of its alarm limits and uses a Time Profile for others, both types of alarm limit will be shown on Trends for the analog point.

Further Information

Hide and Show a Trace.

Hide and Show the Alarm Limits.

Time Profiles: see Configuring Time Profiles in the ClearSCADA Guide to Core Configuration.


Trends Guide - Trend Annotations (Understanding Trends)

Trend Annotations

An annotation is a text comment that you can insert on any raw or processed historic trace on a Trend (see Insert an Annotation). You can insert, modify, and delete annotations about the historic data on a Trend, providing that your User Account is allocated the Annotate History security permission for that Trend.

Each annotation is indicated by an annotation marker. When you position the cursor over an annotation marker, the annotation text is displayed as a ToolTip (providing that the Show Annotations feature is enabled on the Trend).

Annotation markers are similar in appearance to value markers, but have their own specific color and shape.
When you place the cursor over an annotation marker, the annotation text is displayed as a ToolTip.

Annotation markers are light-blue by default (see Trend - Annotation in the ClearSCADA Guide to Core Configuration).

If you have the relevant security permissions, you can change the color, size, and shape of the annotation markers on a trace (see Configure a Trace).

Further Information

Hide and Show Annotations.

View Information about All Annotations on a Trace.


Trends Guide - Raw Historic Data on Trends (Understanding Trends)

Raw Historic Data on Trends

Raw historic data is data that has been stored historically in the ClearSCADA database with exactly the same values that were originally reported. For example, if a point is configured to have its data stored historically, and its current value is 6.0, then 6.5, then 6.4, then 6.2, the values will be stored as 6.0, 6.5 and 6.4 historically.

With Trends, you can configure a trace to represent raw historic data for any point or forecast that has the Historic feature enabled.

Raw historic data traces are often used in favor of processed historic traces as they are more accurate - they represent the actual values that were reported. However, in some circumstances, using a raw historic data trace can result in an impractical Trend. This is because if a trace has a high density of values for the time range of the Trend, the trace can become difficult to read.

The number of raw values shown on the trace is high in comparison to the number of pixels available, and so it becomes difficult to see the values on the trace.

If you want to view the actual historic values of a point or forecast on a trace, you need to choose the Raw Historic Trace option when you add the trace to a Trend.

When choosing to display raw historic values, you need to be aware that if the trace has to show an excessive amount of values, the trend may become difficult to use. If you have a cluttered trace, you can reduce the amount of values shown by adjusting the time range on the X-Axis. However, this also means that you have to compromise with the time range that is shown on the Trend.

You also need to consider the Point Limit setting of the trace. Each raw historic trace has a Point Limit setting that defines the maximum number of values that can be shown on the trace. If this number is exceeded, ClearSCADA switches the trace to Summary Mode for Raw Historic Traces. In Summary Mode, the trace is set to use processed historic data temporarily.


Trends Guide - Summary Mode for Raw Historic Traces (Understanding Trends)

Summary Mode for Raw Historic Traces

Summary Mode for raw historic traces is designed to help your system avoid the performance issues that can occur when traces have high numbers of values. It works by allowing you to define a Point Limit, which sets the maximum number of values that can be represented by a trace (for a Trend’s time range). If the Point Limit is exceeded, ClearSCADA automatically adjusts the trace so that it uses processed historic data instead of raw historic data. This results in a trace that shows a reasonable amount of values and is responsive (a high number of values on a trace can cause slow performance).

For example, if you set the Point Limit to 2000, it means the trace can show up to 2000 values on a single interval (i.e. the trace can represent up to 2000 values shown on screen at any one time). If the trace has 2300 values to show, ClearSCADA automatically sets the trace to use processed historic data with an interval of Per Pixel. As a result, the Trend covers the same time range but shows fewer values on the trace. As the values on the trace are now processed, they are not the actual reported values; they are calculated values.

When ClearSCADA has to display a Trend in Summary Mode, it sets the trace to:

  • use processed historic data instead of raw historic data
  • use an Interval type of Per Pixel.
  • use an Algorithm of Max for Bar traces or Min and Max for Step and Line traces. When Min and Max are used, the trace plots the minimum and maximum processed values for each resample interval.

The processed historic data is used as the source data when the trace’s values exceed the Point Limit. If you reduce the interval so that the values are lower than the Point Limit, the trace will revert to using raw historic values again.

Further Information

Processed Historic Data on Trends

Add a Trace to a Trend

Point Limit Setting: see Configure a Trace

Raw Historic Data on Trends

Processed Historic Data on Trends


Trends Guide - Processed Historic Data on Trends (Understanding Trends)

Processed Historic Data on Trends

ClearSCADA can perform calculations on the raw historic values in your database (see Raw Historic Data on Trends). The results of these calculations are called processed historic data, and like raw historic values, they can be used as the data source for a trace on a Trend.

The main benefits of processed historic data are:

  • You can use processed historic data to view statistical information on a Trend. For example, you can use historic algorithms to set a trace to represent the average values of a data source. With raw historic data, you can only view the actual values that are stored historically in the database.

There are many different types of algorithm (calculation) that you can use to produce processed historic data (see Built-In Historic Algorithms for Processed Historic Data).

  • You can control how many historic values are plotted on a Trend.

If your Trend is configured to show a raw historic trace, the trace has to plot each of the historic values for the time shown on the X-axis. So, if the X-axis is set to represent 1 day and the data source of the trace has historic values for every second, the trace will have to plot 86, 400 values. Plotting each of the raw historic values can result in a cluttered Trend that is difficult to use (although ClearSCADA does have built-in mechanisms to stop Trends from drawing an excessive amount of values and markers, see Summary Mode for Processed Historic Traces).

With processed historic data, you have greater control over the amount of values that are shown on a trace as you can set the resample interval (see Resample Interval for Processed Historic Data). The resample interval is a time period that defines when a historic value is calculated. For example, if you define a resample interval of 5M, it means ClearSCADA will calculate a new processed historic value every 5 minutes. So, for the processed historic value for 11:05, ClearSCADA would perform the calculation using the raw historic values for the period 11:00-11:05. The result of the calculation is the processed historic value that is drawn on the trace for 11:05. The next processed historic value is drawn at 11:10. This means that there are fewer values and markers on the trace.

Example:

A point is used to monitor the flow of water in a pipe and it is set to update every second. The point has the historic feature enabled and so a raw historic value is stored for the point each second.

An engineer wants to view the point’s values over the period of an entire hour and so creates a Trend with an X-axis set to represent 1 hour. The engineer then adds a trace to represent the point’s raw historic values. As the engineer knows the point has 3600 values for the required period, they alter the markers setting of the trace to 3600 so that a marker can be drawn for each value.

The trace is drawn, but is difficult to read because of the high density of values on show.

To make the Trend easier to use, the engineer creates a new trace; a processed historic trace for the same point. The trace is configured so that it uses the Average algorithm and has a resample interval of 5M (five minutes). This means that ClearSCADA will calculate the average value of the point and plot the result on the trace in five minute intervals. To calculate the average value, ClearSCADA will use the raw historic values for each 5 minute interval.

To make the Trend easier to use, the engineer uses the Show>None feature for the raw historic trace so that only the processed historic trace is visible.

The processed historic trace provides the engineer with the average values of the point over the 1 hour period. There are fewer values and markers as the processed historic values are calculated at 5 minute intervals (as defined by the resample interval) rather than every second. This allows the engineer to see rises and drops in the point’s value over the hour without the need to view the large number of raw historic values.


Trends Guide - Resample Interval for Processed Historic Data (Understanding Trends)

Resample Interval for Processed Historic Data

To create a processed historic value, ClearSCADA has to perform a calculation on a set of raw historic values (see Raw Historic Data on Trends). For example, to produce an average processed historic value, ClearSCADA performs the average calculation on the raw historic values reported by the point.

The amount of raw historic values that are included in each calculation is defined by the resample interval setting. For example, on a Trend, setting the Interval of a trace to 10M instructs ClearSCADA to perform a calculation using the raw historic values in 10 minute intervals. So, if ClearSCADA is calculating a processed historic value at 10:10, it will use the raw historic values for 10:00-10:10 in its calculation. The result of the calculation is then the processed historic value for 10:10. The next processed historic value will be calculated for 10:20 as the resample interval setting also defines how often ClearSCADA calculates the processed historic values.

The raw historic trace shows each of the point’s raw historic values for the period 10:00-10:10.

The processed historic trace shows calculated historic values. The values are calculated and plotted on the trace in 10 minute intervals as defined by the trace’s Interval setting. The result of each processed historic value is achieved by performing a calculation on the raw historic values in the resample interval. Here, the two processed historic values show the average value (at 10:00 and 10:10).

For information on how to configure the resample interval for a Trend, see Configuring Trends.

NOTE: On Trends that show processed historic data, the Trend switches to Summary Mode automatically if the amount of time represented by a single pixel exceeds the resample interval for a trace (see Summary Mode for Processed Historic Traces).

Further Information

Resample Interval (Historic Views): see Resample Interval for Historic Views in the ClearSCADA Guide to Server Administration.


Trends Guide - Summary Mode for Processed Historic Traces (Understanding Trends)

Summary Mode for Processed Historic Traces

For processed historic traces, ClearSCADA calculates each value according to the defined (resample) Interval for the trace. The results of the calculations are then plotted on the trace. When each pixel of the Trend display represents less time than the resample Interval, the trace is displayed in ‘normal’ mode and is drawn as a line, bar or step.

If each column of pixels represents a time greater than the resample interval for a trace, ClearSCADA switches the trace to ‘Summary Mode’ automatically. This is to help avoid slow performance, which can sometimes occur when drawing multiple values in the same pixel.

When a processed historic trace is shown in Summary Mode, each column of pixels represents an amount of time, and ClearSCADA has to draw multiple values for that time period. To help avoid slow performance when drawing multiple values in the same pixel, ClearSCADA draws a vertical line that represents the range of historic processed values that were calculated (for the time represented by 1 column of pixels). The top of the line represents the highest processed historic value calculated and the bottom of the line represents the lowest.

Example:

A trace is configured to represent the historic values of a point. The trace has a resample interval of 1M (1 minute).

The Trend on which the trace is shown has an X-axis representing a large period of time, meaning that each column of pixels represents more than 1 minute. Let’s say that each column of pixels represents 10M. This means that for each column of pixels, there will be 10 values (as the processed historic values are calculated every minute, but a single column of pixels represents 10 minutes).

Every minute, ClearSCADA has to draw a processed historic value. As each column of pixels represents 10 minutes, this means ClearSCADA would have to draw 10 values in each column. This is possible if each of the values are unique, as each value can be drawn as a single pixel in the column, but if one or more values are the same, ClearSCADA would have to draw a value in a pixel and then draw over it with another value. To avoid this, ClearSCADA switches the trace to Summary Mode.

With the trace in Summary Mode, ClearSCADA draws a vertical line for each column of pixels. In a ten minute period, the point’s processed historic values are 20, 20, 22, 21, 21, 21, 23, 24, 24, 28. ClearSCADA represents these values on the Trend by drawing a vertical line that is 1 pixel wide (the column of pixels represents the 10 minute period) and the bottom of the line is at 20 and the top of the line is at 28.


Trends Guide - Built-In Historic Algorithms for Processed Historic Data (Understanding Trends)

Built-In Historic Algorithms for Processed Historic Data

ClearSCADA has built-in historic algorithms that you can use with historic Trends and other historic features such as Historic Views. Each historic algorithm performs a calculation on the relevant raw historic values and returns the result, which can be used as a data source on a Trend or displayed in Queries. (For more information on raw historic values, see Raw Historic Data on Trends).

Each historic algorithm is applied to the values in a defined resample interval (a time period). For example, if the resample interval is 1D (1 day) and you use the 1hAverage algorithm, ClearSCADA will calculate the average value every hour from the start of the day. The resample interval is defined in the configuration of the Historic item, for example the Historic Trend, Historic Calculation, Historic View etc.

The following historic algorithms are often used when working with historic data:

  • 1hAverage
  • 24hAverage
  • 8hAverage
  • Average
  • Average Interpolated
  • Average Last
  • Count
  • Interpolated
  • Max
  • Max Interpolated
  • Max Last
  • MaxTime
  • Min
  • MinInterpolated
  • MinLast
  • MinTime
  • StdDev
  • Sum
  • Time Average
  • Total
  • Variance.

In addition to the algorithms we have listed, we also support the following historic algorithms, many of which are specified as part of the OPC historic standard:

  • Delta—The difference between the first value and the last value in the data for the resample interval. The time stamp of the result matches the start time of the sample.
  • DurGood—The duration (in seconds) of good data in the data for the resample interval.
  • DurBad—The duration (in seconds) of bad data in the data for the resample interval.
  • End—The last value in the data for the resample interval. The timestamp is the time at the time at which the last value was reported.
  • EndLast—Returns either the last value in the data for the resample interval or the latest value in the data prior to the resample interval (if there are no values in the defined resample interval). For example, if there are values in the defined resample interval, the EndLast algorithm works in the same way as the End algorithm: it will return the last value in the resample interval. However, if there are no values in the defined resample interval, the EndLast algorithm will return the last value prior to the resample interval. The timestamp is the time at the end of the defined resample interval, even if the actual value was taken from a sample prior to the defined resample interval. So the timestamp may not correspond with the time at which the last value was reported.
  • PerBad—The percentage of bad data in the data for the resample interval (1=100%).
  • PerGood—The percentage of good data in the data for the resample interval (1=100%).
  • Range—The difference between the maximum value and the minimum value in the data for the resample interval.
  • Start—The first value in the data for the resample interval. The timestamp is the time at which the first value in the sample was reported.
  • Stepped—This is specific to ClearSCADA and is an obsolete algorithm that is included for backwards compatibility reasons. The Stepped algorithm was designed to allow traces to be stepped, but this functionality is now provided by the Step First and Step Last Trace Style settings (see Configure a Trace).

For more information on the algorithms listed above (with the exception of Stepped), please refer to the OPC Foundation documentation or visit
http://www.opcfoundation.org).

NOTE: ClearSCADA also supports any custom historic algorithms that have been created on your system (see Historic Algorithms (Custom) in the ClearSCADA Guide to Server Administration). When you are configuring a Historic item, any custom historic algorithms are included in the list of available algorithms.

1hAverage

The 1hAverage algorithm produces an average value based on the good quality raw historic values reported for an hour period. The timestamp for each processed historic value produced by the 1hAverage algorithm is at the start of the resample interval.

For example, the following Trend shows a point’s raw historic values for the period 12:00-14:00.

By applying the 1hAverage algorithm to these raw historic values, ClearSCADA can create the following processed historic trace for the same time period. The resample interval of the trace is configured to be 30M, which means that ClearSCADA calculates the average hourly value at 30 minute intervals (samples) on the X-axis.

The result of each calculation is plotted on the trace at the start of that sample
.

So in this example, the average hourly value at 12:30 is calculated using each of the raw historic values for the period 12:30-13:00. The average hourly value for 13:00 is calculated using the raw historic values for the period 13:00-13:30 and so on.

To provide the result of the 1hAverage algortihm, ClearSCADA adds up each of the raw historic values in the hour period and then divides the total by the quantity of raw historic values in the hour period. The result is plotted on the trace at the start time of the sample.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

24hAverage

The 24hAverage algorithm produces an average value based on the good quality raw historic values reported for a 24 hour period. The timestamp for each processed historic value produced by the 24hAverage algorithm is at the start of the resample interval.

For example, the following Trend shows a point’s raw historic values for the period 11:00 on March 02 to 11:00 on March 03.

By applying the 24hAverage algorithm to these raw historic values, ClearSCADA can create the following processed historic trace for the same time period. The resample interval of the trace is configured to be 6H, which means that ClearSCADA plots the average 24 hour value in 6 hour intervals on the X-axis.

So in this example, the average 24 hourly value at 18:00 on March 02 is calculated using each of the raw historic values for the period March 02 18:00 to March 03 18:00.

To provide the result of the 24hAverage algortihm, ClearSCADA adds up each of the raw historic values in the 24 hour sample and then divides the result by the amount of raw historic values in the 24 hour sample. The result is plotted on the Trend at the time that corresponds to the start of the resample interval.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

8hAverage

The 8hAverage algorithm produces an average value based on the good quality raw historic values reported for an 8 hour period. The timestamp for each processed historic value produced by the 8hAverage algorithm is at the start of the resample interval.

For example, the following Trend shows a point’s raw historic values for the period 12:00 on March 02 to 12:00 on March 03.

By applying the 8hAverage algorithm to these raw historic values, ClearSCADA can create the following processed historic trace for the same time period. The resample interval of the trace is configured to be 1H, which means that ClearSCADA plots the processed historic values in 1 hour intervals (samples) on the X-Axis.

So in this example, the average 8 hourly value at 02:00 on March 03 is calculated using each of the raw historic values for the period March 02 18:00 to March 03 02:00. For the average 8 hourly value at March 03 04:00, the raw historic values for the period March 02 20:00 to March 03 04:00 are used in the calculation and so on.

To provide the result of the 8hAverage algortihm, ClearSCADA adds up each of the raw historic values in the 8 hour period starting at the beginning of the sample.The result is plotted on the Trend at the time that corresponds to the start of the resample interval.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Average

The Average algorithm produces a mean average value based on the good quality raw historic values reported for the resample interval. The average is calculated as the sum total of the values in the resample interval divided by the total number of values in the resample interval. The amount of time between value changes is not taken into account (for a time weighted average, use the Time Average accumulator).

The timestamp for each processed historic value produced by the Average algorithm is at the start of the resample interval.

For example, the following Trend shows a point’s raw historic values for the period 12:00 on March 02 to 12:00 on March 03.

By applying the Average algorithm to these raw historic values, ClearSCADA can create the following processed historic trace for the same time period. The resample interval of the trace is configured to be 1H, which means that ClearSCADA plots the processed historic values in 1 hour intervals (samples) on the X-Axis.

So in this example, the average value at 16:00 on March 02 is calculated using each of the raw historic values for the period March 02 16:00 to March 02 18:00. For the average value at March 02 18:00, the raw historic values for the period March 02 18:00 to March 02 20:00 are used in the calculation and so on.

To provide the result of the Average algortihm, ClearSCADA adds up each of the raw historic values in the resample interval period starting at the beginning of the sample. It then divides the sum by the quantity of raw historic values in that sample. The result is plotted on the Trend at the time that corresponds to the start of the resample interval.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Average Interpolated

The Average Interpolated algorithm calculates an average value based on:

  • The interpolated value for the start of the resample interval.
  • The good quality raw historic values in the resample interval.

For this calculation, ClearSCADA adds up the values listed above and then divides total by the number of values. The result is the average interpolated value and it has a timestamp that matches the start time of the sample.

For example, lets say a trace is configured to use the Average Interpolated algorithm and is set to have a resample interval of 10M (10 minutes). This means that for each 10 minute sample, ClearSCADA will calculate an interpolated average. ClearSCADA achieves this by:

  1. Estimating an interpolated value for the start of the resample interval. To do this, it performs a calculation that uses the last raw historic value before the start of the sample and also the first raw historic value in the sample. Internally, ClearSCADA calculates what value it would need to plot at the start of the resample interval if it were to draw a line between the last raw historic value before the sample and the first raw historic value in the sample.
    The shaded area shows the sample interval for which an average interpolated value is being calculated. This is for illustration purposes only and does not actually appear on Trends.
    Imagine that ClearSCADA drew a line between the last raw historic value before the start of the sample interval and the first raw historic value in the sample. The point at which the line would cross the time of the start of the sample is the interpolated value.

  2. ClearSCADA then calculates the average value for the sample. It adds up the interpolated value from step 1 and each of the raw historic values in the sample. It then divides the result by the number of values, so if there were 7 raw historic values in the sample, the total would be divided by 8 (as the interpolated value is also included).

The result of steps 1 and 2 is the average interpolated value for the sample and it is plotted at the start of the resample interval.

The average interpolated algorithm is useful when you want to calculate the average values for data that has gaps (periods of no values). This is because the average interpolated algorithm uses raw values outside of the sample in its calculation, which means it can still return a value even if the sample contains no values. For example, if the sample contains no values, ClearSCADA will use the last raw value before the sample and the first raw value after the sample to create two estimated values. These values match the values that would be plotted on the start time and end time of the sample were ClearSCADA to draw a line between the last raw historic value before the sample and the first raw historic value after the sample.

Imagine that ClearSCADA drew a line between the last raw historic value before the start of the sample interval and the first raw historic value after the sample. The points at which the lines would cross the time boundaries of the sample correspond to the values that ClearSCADA calculates if there are no raw historic values in the sample.

The 2 values that are calculated are then added together and divided by 2 to provide the average interpolated value for the resample interval. This value has a timestamp that matches the start of the resample interval.

If there are no values in the sample and there are no values after the sample, the interpolated value will be the same as the last value before the sample. As a result, the average interpolated value will also be the same as the last value before the sample, as there is only a single value to use in the calculation.

NOTE: If there is a raw historic value with a timestamp that matches the start of the sample exactly, and there are no values in the sample or after the sample, the raw historic value is used as the average interpolated value.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Average Last

The Average Last algorithm calculates an average value based on:

  • The last good quality raw historic value before the start of the resample interval
  • The good quality raw historic values in the resample interval.

To calculate the Average Last value, ClearSCADA:

  1. Adds up each of the raw historic values in the sample and the last raw historic value before the sample.
  2. Divides the result of step 1 by the quantity of values used in step 1 (i.e. the total number of good quality values in the sample plus 1).

The result of step 2 is the average last value and it has a timestamp that matches the start time of the sample.

Resample Interval (shaded)
The raw historic values that ClearSCADA will use in its calculation are circled (for illustration purposes only). It includes each of the good quality raw historic values in the sample and the last good quality raw historic value before to the sample.

For example, lets say a trace is configured to use the Average Last algorithm and is set to have a resample interval of 1M (1 minute). This means that for each 1 minute sample, ClearSCADA will calculate an average last value.

At 10:31, ClearSCADA has to plot an average last value on the trace. To do this, it adds the last raw historic value from before 10:31 to each of the values in the sample (10:31 - 10:32). In this case, the values are:

  • Value before sample: 33.4
  • Sample values: 29.11, 27.48, 30.32. 30.34, 34.12, 30.43.

So to calculate the average last value, ClearSCADA adds each of the values up to produce the sum total of 215.22. It then divides 215.22 by the quantity of values in the sample (including the last value before the sample) which is 7. The result of 215.22 divided by 7 is 30.74. The average last value that is plotted on the trace for 10:31 is 30.7.

If there are no values in the sample, the average last value will be the same as the last raw historic value before the sample.

NOTE: If there is a raw historic value with a timestamp that matches the start of the sample exactly, and there are no values in the sample or after the sample, the raw historic value is used as the average last value.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Count

The Count algorithm calculates the total number of good quality raw historic values in the resample interval. The result of the calculation has a timestamp that matches the start time of the sample.

For example, let’s say a Trend is configured to show the raw historic values of a point for the period 13:00 to 14:00. The point is updated every second, and so has 60 raw historic values per minute.

The raw historic value trace is hidden using the Show>None option for the trace, and then a new trace for the point is created. The new trace is a processed historic trace that is configured to use the Count algorithm and has an Interval setting of 10M (10 minutes). The trace is configured to use the Filled Bar style and a Bar Width of 1M (each bar is the same width as 1 minute of time on the X-Axis). The Trend shows:

By viewing the processed historic trace, a user can see that the point had regular amounts of 60 historic data values for each sample until the 14:00 sample. Between 14:00 and 14:10 (which would be the next bar on the Trend), the count value increased to overrange. This means that, at that time, the point had been reconfigured to be scanned more frequently than once per second (or had developed a fault).

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Interpolated

The Interpolated algorithm calculates a value that is:

  • Equal to or higher than the last raw historic value before the start of the sample. For the purposes of this section, we will refer to the last raw historic value before the start of the sample as the ‘last pre-sample’ historic value.

And:

  • Equal to or lower than the next raw historic value after the ‘last pre-sample’ historic value. The ‘next’ value may be in the sample or could be after the sample. If there is no ‘next’ raw historic value, the interpolated value will be exactly the same as the ‘last pre-sample’ value.

To perform the interpolated calculation, ClearSCADA takes the ‘last pre-sample’ calculation and the ‘next’ raw historic value after that, and creates an estimated value that is between the two. This calculation is the equivalent of ClearSCADA drawing a line between the ‘last pre-sample’ value and the ‘next’ raw historic value on a trace, with the result being the point where the start of the sample crosses that line.

Start of sample
Last historic raw value before the start of the sample
First historic raw after the ‘last pre-sample’ raw historic value.
The interpolated value for the sample is at the point where a straight line drawn between the ‘last pre-sample’ historic value and the ‘next’ historic value would cross the start of the resample interval.(The red circle shown at the point of connection is shown for illustration purposes only).

Interpolated values are useful when there are known gaps in the data. This is because ClearSCADA uses a value outside of the sample in its interpolated calculation, and so it can still return a result, even if there are no raw historic values in the sample (in this case, ClearSCADA returns the last raw historic value from before the sample as the integrated value).

For example, let’s say a Trend is configured to show a raw historic trace with the X-Axis set to show 2 hour intervals, starting at 12:00. There are raw historic values for the hours 12:00 to 14:00 and 14:00 to 16:00, but there are no raw historic values for the hours 16:00 to 18:00 and 18:00 to 20:00. There are, however, raw historic values for the hours 20:00 to 22:00 and onwards.

There are no raw historic values in the sample.

To calculate the integrated value for the sample, ClearSCADA uses the last value before the start of the sample and the next value after that. In this case, the next value is the first value after the end of the sample. It then calculates the interpolated value, which corresponds to the point at the start of the sample where a line between the ‘last pre-sample’ value and the next value would meet.

Imagine that a line was drawn between the last pre-sample raw historic value and the next raw historic value after that. The point where the line crosses the start of the sample is equal to the interpolated value for the sample. The point where the line crosses the start of the sample is shown here with a red circle (this is for illustration purposes only).

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Max

The Max algorithm calculates the highest good quality raw historic value in the resample interval. The result of the calculation (the highest value in the resample interval) has a timestamp that matches the start time of the sample.

For example, let’s say a Trend is configured to show the raw historic values of a point for the period 13:00 to 1310. The point is updated every 10 seconds, which means there are 6 raw historic values per minute. During the first minute, the point’s raw historic values are 78.65, 77.08, 81.02, 80.91, 82.4, and 80.75.

The point has 6 raw historic values for each minute interval. Here, the resample interval for the first minute is highlighted (for illustration purposes only).

By configuring a processed historic trace for the same point, and setting that trace to use a Max algorithm with a 1M (1 minute) resample interval, a user can view the maximum values for the point. A maximum value is calculated for each minute on the Trend (as defined by the resample interval of the trace).

The processed historic trace using the Max algorithm shows 11 values for the period 13:00 to 13:10, with each value matching the highest raw historic value in each minute interval. For example, in the minute 13:00 to 13:01, the highest raw value is 82.4 and so the calculated max value for the same period is 82.4.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Max Interpolated

The Max Interpolated algorithm works in a similar way to the Max algorithm, except that it also includes an extra value in the resample interval - the interpolated value. This means that a maximum value can still be calculated even if the resample interval contains no raw historic values, and so is ideal for situations when the maximum values need to be calculated but there are gaps in the data.

To calculate the interpolated value, ClearSCADA compares the last good quality raw historic value before the resample interval with the next good quality raw historic value (which may or may not be in the sample). It then calculates the interpolated value, which corresponds to the point at the start of the sample where a line between the ‘last pre-sample’ value and the next value would meet (for more information on how ClearSCADA calculates an interpolated value, see Interpolated).

ClearSCADA then examines the calculated interpolated value and the good quality raw historic values in the resample interval - the highest value is the max interpolated value.

The values that are circled in the illustration are the values that ClearSCADA will use in its calculation, with the circle at the start of the resample interval representing the interpolated value.

The max interpolated value is plotted on the trace with a timestamp that matches the start of the resample interval.

The max interpolated value is plotted on the trace with a timestamp that matches the start of the resample interval.

If there are no raw historic values in the resample interval, the Max Interpolated value is the same as the interpolated value (that ClearSCADA calculates as part of the Max Interpolated algorithm).

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Max Last

The Max Last algorithm calculates a maximum value based on:

  • The last good quality raw historic value before the start of the resample interval
  • The good quality raw historic values in the resample interval.

To calculate the Max Last value, ClearSCADA:

  1. Examines the good quality raw historic values in the sample and the last good quality raw historic value before the sample.
  2. Returns the highest value of those values examined in Step 1. This is the Max Last result and it has a timestamp that matches the start time of the sample.

Like the Max Interpolated algorithm, the Max Last algorithm is useful when there are gaps in the data - it allows a maximum value to be calculated for time periods where there are no good quality raw historic values. However, the Max Last algortihm only uses actual raw historic values, unlike the Max Interpolated algorithm which uses an estimated historic value (the interpolated value).

Resample Interval (shaded)
The raw historic values that ClearSCADA will use in its calculation are circled (for illustration purposes only). It includes each of the good quality raw historic values in the sample and the last good quality raw historic value before to the sample.

For example, lets say a trace is configured to use the Max Last algorithm and is set to have a resample interval of 1M (1 minute). This means that for each 1 minute sample, ClearSCADA will calculate a maximum last value.

At 10:31, ClearSCADA has to plot an maximum last value on the trace. To do this, it compares the last raw historic value from before 10:31 to each of the values in the sample (10:31 - 10:32). In this case, the values are:

  • Value before sample: 33.4
  • Sample values: 29.11, 27.48, 30.32. 30.34, 34.12, 30.43.

This means the max last value is 34.12 (the highest value). This value is plotted on the trace at 10:31.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends.

MaxTime

The Max Time algorithm calculates the maximum value based on the good quality raw values in the sample. The highest value is the Max Time value. Where the Max Time algorithm differs to the other maximum algorithms is that its timestamp is not the start of the sample; instead, it uses the timestamp for the highest value in the sample.

The MaxTime algorithm is useful in situations where the maximum values are needed and the exact time at which they were reported is significant.

For example, let’s say a point with historic enabled has the following values and time stamps:
Timestamp | Raw Historic Value
13:01:00 | 20.11
13:01:10 | 20.62
13:01:20 | 20.78
13:01:30 | 21.02
13:01:40 | 21.65
13:01:50 | 21.21

A Trend is configured to show the point’s historic data graphically. Rather than display each of the point’s raw historic data values, a processed historic trace is configured to use the Max Time algorithm. The trace has an Interval setting of 1M (1 minute), which means that at the start of every minute, ClearSCADA calculates the Max Time value using the raw historic values in the 1 minute sample (which starts from the beginning of the minute).

At 13:01, ClearSCADA has to calculate the Max Time value. To do this, it examines the raw historic values in the period 13:01:00 to 13:01:59. The highest value is the Max Time value, and so the result of the calculation is 21.65.

On the trace, the 21.65 value is plotted with the timestamp for the corresponding raw historic value. So, 21.65 is plotted at 13:01:40. Had any of the other maximum algorithms been used, the 21.65 value would have been plotted at 13:01:00 as the other maximum algorithms timestamp their results with the start time of the sample.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Min

The Min algorithm works in the same way as the Max algorithm except that it calculates the lowest value in a sample rather than the highest.

For information on the Max algorithm, see Max.

MinInterpolated

The Min Interpolated algorithm works in the same way as the Max Interpolated algorithm except that it calculates the lowest value in a sample rather than the highest.

For information on the Max Interpolated algorithm, see Max Interpolated.

MinLast

The Min Last algorithm works in the same way as the Max Last algorithm except that it calculates the lowest value in a sample rather than the highest.

For information on the Max Last algorithm, see Max Last.

MinTime

The Min Time algorithm works in the same way as the Max Time algorithm except that it calculates the lowest value in a sample rather than the highest.

For information on the Max Time algorithm, see MaxTime.

StdDev

ClearSCADA can calculate the standard deviation value for a sample of historic values. Standard deviation is a commonly used statistical calculation that is used to measure the spread of values over a time period. It is useful when investigating patterns in data as the standard deviation results use the same base units as the raw historic values in the sample, which means it easier to determine the statistical significance of the values.

The standard deviation algorithm complies with the OPC standard, which defines the calculation as:

Where: X is each good quality raw historic value in the sample, Avg(X) is the mean average value of the good quality raw historic values in the sample, and n is the number (quantity) of good quality raw historic values in the sample.

As part of the standard deviation calculation, ClearSCADA calculates the average value of the values in the sample. The result of the standard deviation calculation is indicitive of the amount of variance between the actual raw historic values in the sample and the average value of the raw historic values. This means that the larger the range of values in the sample, the greater the standard deviation value for the sample will be. Therefore, high standard deviation values often indicate unusual changes in the data source’s values, for example, a sudden trough of low values, peak of high values, or erratic changing between high and low values.

For example, on a Trend you can configure a processed historic trace to use the Std Dev algorithm and have an Interval of 1M. This would result in ClearSCADA calculating the standard deviation value for every minute (each sample contains 1 minute’s worth of raw historic data).

Raw historic trace showing the raw historic values. The values are fairly consistent, so there is not a wide spread.
Processed historic trace showing the standard deviation values of the data source. The values on the trace are low as the raw historic values are close to the mean average for the historic values.

Raw historic trace showing the raw historic values. The values rise and drop significantly, so there is a wide spread.
Processed historic trace showing the standard deviation values of the data source. The values on the trace are high as many of the raw historic values are not close to the mean average for the historic values.

In ClearSCADA, the timestamp for each Std Dev result is the start time of the sample. For example, if the sample starts at 01:00 and ends at 01:10, ClearSCADA would use the raw historic values for the period 01:00 to 01:10 in its calculation, then return the standard variant value with a timestamp of 01:00.

The standard deviation value for each sample uses the same units as the data source.

Further Information

Variance

Raw Historic Data on Trends

Processed Historic Data on Trends

Sum

The Sum algorithm calculates the total value of the good quality raw values in the sample. The result of the sum algorithm has a timestamp that matches the start time of the sample.

For example, let’s say a point with historic enabled has the following values and time stamps:
Timestamp | Raw Historic Value
13:01:00 | 20.11
13:01:10 | 20.62
13:01:20 | 20.78
13:01:30 | 21.02
13:01:40 | 21.65
13:01:50 | 21.21

A Trend is configured to show the point’s historic data graphically. A processed historic trace is configured to use the Sum algorithm. The trace has an Interval setting of 1M (1 minute), which means that at the start of every minute, ClearSCADA calculates the sum value using the raw historic values in the 1 minute sample (which starts from the beginning of the minute).

At 13:01, ClearSCADA has to calculate the sum value. To do this, it adds up the good quality raw historic values in the period 13:01:00 to 13:01:59. The result is the sum value (the sum total) and in this case, it is 46.61.

On the trace, the 46.61 value is plotted at 13:01 on the X-axis (13:01 being the start time of the sample).

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Time Average

The Time Average algorithm calculates a time-weighted average of the values in a sample. Unlike the Average algorithm which simply divides the sum of the values in the sample by the number of values, the Time Average algorithm takes into account the amount of time between value changes. This means that the average value is more indicitive of the actual values in the sample and is less influenced by a small number of unusual, fleeting values.

For example, let’s say a point has historic enabled and updates every 5 seconds. This means it has 12 raw historic values per minute. For the minute period 14:00 to 14:01, the point has the following values:
Timestamp | Raw Historic Value
14:00:00 | 20.11
14:00:05 | 20.62
14:00:10 | 20.78
14:00:15 | 21.02
14:00:20 | 21.65
14:00:25 | 21.65
14:00:30 | 21.65
14:00:35 | 21.65
14:00:40 | 21.65
14:00:45 | 21.65
14:00:50 | 22.45
14:00:55 | 22.45

With these values, an average algorithm would simply add up the raw historic values and then divide the total by 12. The result would be 21.44, which provides little indication that for half of the sample, the point value was 21.65.

The time average works differently - it performs a calculation that takes into account the amount of time that a value remains unchanged. This calculation is the equivalent of plotting the values in the sample on a Trend and then:

  1. Calculating an interpolated value for the start of the sample
  2. Calculating an interpolated value for the end of the sample
  3. Drawing a line between each value in the sample (including the interpolated values)
  4. Calculating the area below the line
  5. Dividing the result of the area calculation by the duration of the sample. The result of this step is the time average for the sample.

Here, a raw historic trace shows the actual raw historic values for the sample (14:00:00 to 14:01:00). The resample interval is highlighted for illustration purposes only.

To calculate the time average, ClearSCADA uses the raw historic values in the sample as well as an interpolated value for the start of the sample and the end of the sample. In this case, there is a raw value at the start time of the sample and so that is used instead of an interpolated value, however, there is no raw historic value for the end time of the sample and so an end interpolated value is calculated and used.

ClearSCADA uses the values in the sample (circled here, for illustration purposes only) and an interpolated value for the end time of the sample in its time average calculation.

To determine the time average value for the sample, ClearSCADA draws a line between the raw historic values (and interpolated values) and then calculates the area of the space below the line. It then divides the area amount by the duration of the sample. The result is the time average value for the sample and it has a timestamp that matches the start time of the sample (in this case, 14:00:00.

So on a Trend that shows a processed historic trace using the Time Average algorithm for the point, the Time Average value for 14:00:00 will be 21.53. The 21.53 is closer to the value that the point was in for the longest period during the sample (the point value was 21.65 for half of the sample).

Bar trace showing the time average for the minute 14:00:00 to 14:01:00
Line trace showing the raw historic values for the minute 14:00:00 to 14:01:00

Total

The Total algorithm is an integrated calculation that provides the totalized value of the data in the sample. It is useful when used with data sources that measure flow as the result of the total calculation is equal to volume.

The calculation that ClearSCADA performs to produce the total value is:

Time Average of Sample x Sample Duration = Total value.

(For information on the Time Average calculation, see Time Average).

For example, let’s say a historic-enabled point is used to represent a water flow measuring device. The point measurements are in liters and are updated every 5 seconds (so there are 12 raw historic values per minute).

For the minute starting 14:00:00, the point has these values:
Timestamp | Raw Historic Value (in liters)
14:00:00 | 20.11
14:00:05 | 20.62
14:00:10 | 20.78
14:00:15 | 21.02
14:00:20 | 21.65
14:00:25 | 21.65
14:00:30 | 21.65
14:00:35 | 21.65
14:00:40 | 21.65
14:00:45 | 21.65
14:00:50 | 22.45
14:00:55 | 22.45

To calculate the Total value for the minute starting 14:00:00, ClearSCADA:

  1. Calculates the time average value of the values in the sample. In this case, the time average value is 20.53.
  2. Multiplies 20.53 (the time average value) by 10 (the resample interval is 10 seconds). This provides the total value of 205.3. So for the minute starting 14:00:00, the calculated volume of water is 205.3 liters.
  3. ClearSCADA gives the total value a timestamp that matches the start time of the sample.

Trace representing the raw historic values
Trace representing the time average processed historic values
Trace representing the total processed historic values

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends

Variance

Like standard deviaton, the variance algorithm is a statistical calculation that is used to measure the spread of values over a time period. It is useful when investigating patters in data, especially on Trends as the squared results mean that peaks and troughs in the data are more noticeable than the standard deviation version of the same data. However, the results of variance calculations are squared, so they use different base units to the data source. For this reason, many statisticians prefer to use standard deviation when assessing the spread of values (standard deviation uses the same base units as the data source; the square root of the variance is the standard deviation).

To calculate the variance value for a sample, ClearSCADA:

  1. Calculates the mean average of the values in the sample
  2. For each raw historic value in the sample, ClearSCADA subtracts the mean average and then squares the result
  3. Finally, ClearSCADA calculates the mean average of the results of Step 2. The result is the variance value.

For example, let’s say a Trend is configured to show a processed historic trace that represents a point’s historic data. The point is updated every 10 seconds, and has point limits from 0 to 100.

The trace uses the Variance algorithm and have an Interval of 5M, which means that ClearSCADA calculates the variance value for every five minutes (each sample contains 5 minute’s worth of raw historic data - 30 raw historic values).

Trace showing the raw historic values for a point. The sample interval is highlighted (for illustration purposes only).

At 14:10, ClearSCADA has to plot a variance value. To do this, it takes the raw historic values for the period 14:10 to 14:15, which are: 92.02, 91.14, 92.83, 94.93, 94.42, 97.53, 96.48, 91.82, 92.62, 89.75, 85.91, 88.43, 87.75, 91.65, 96.59, 93.13, 93.19, 94.40, 95.14, 91.17, 89.16, 88.36, 93.01, 93.32, 95.80, 96.29, 96.43, 98.96, 97.57, 97.91. ClearSCADA then calculates the mean average of these values, which is 93.65.

For each value in the sample, ClearSCADA subtracts the average value of 93.65 and then squares the result (so there are 30 results). ClearSCADA then calculates the mean average of the 30 results, which produces a single value - the variance for the period 14:10 to 14:15. In this case, the variance is 11.11.

As the variance value does not use the same base units as the raw historic data, the value of 11.11 has little meaning. For this reason, many statisticians prefer to use standard deviation rather than variance, as standard deviation does use the same base units as the raw historic values (it is the square root of the variance). So for the same sample of raw historic data, the standard deviation algorithm would produce the value 2.3 which means that the majority of raw historic values in the sample are between 2.3 under or over the average value for the sample. So if the point was used to measure water level in liters, the majority of the point’s values for the sample would be within 2.3 liters of the average water level for that period.

While many statisticians prefer to use standard deviation, the variance algorithm can be useful, especially when viewing data on Trends. This is because the squared values of variance results make the rises and falls in values easier to view on a Trend (standard deviation values tend to be lower and so show less pronounced rises and falls).

The standard deviation trace has less pronounced rises and falls, so sudden value changes are more difficult to see on a Trend.
The squared results of variance calculations mean that changes in value are shown as pronounced peaks and troughs on a variance trace.
Trace showing the actual raw historic data.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends


Trends Guide - Configuring Trends

Configuring Trends

This section describes how to create and edit Pre-Configured Trends and File Based Trends via a series of windows in ViewX. For information on configuring ‘custom’ Ad Hoc Trends, see Using TrendSpec to Produce Ad Hoc Trends.

When you create a Trend, its appearance will be determined by the default appearance for new Trends. You can set these defaults, such as fonts and colors, for your ClearSCADA system.

You can customize a Trend’s appearance, for example the scaling of axes and the foreground and background colors. You can also add data traces and a secondary y-axis, and determine which columns display on the Trend key.

For details on how to configure Trends in ViewX, see:

  • Define the Default Settings for New Trends
  • Create a New Trend
  • Display a Trend in Design Mode
  • Configure the Display Settings for a Trend
  • Add a Trace to a Trend
  • Configure a Trace
  • Configure Multiple Data Sources for a Trace
  • Configure the X-Axis
  • Add a Y-Axis
  • Configure a Y-Axis
  • Delete a Y-Axis
  • Define the Columns on the Key.

NOTE: If you are accessing a Trend in an Operator Document Store, you will be able to access the configuration features of the Trend even if your User account does not have the Configure Database feature enabled.


Trends Guide - Define the Default Settings for New Trends (Configuring Trends)

Define the Default Settings for New Trends

You can use the Options window to define the default settings for Trends. These settings, which include marker colors, columns, and number of axes, will be applied to new Trends automatically. By defining the default settings for Trends, you may be able to reduce the amount of configuration required (depending on whether your Trends are to have similar settings).

NOTE: To access the Options window, you have to log on to your system via a User account that has the Configure Options feature enabled.

To change the default settings for your Trends:

  1. In ViewX, log on via a User account that has the Configure Options feature enabled, then select the Tools menu.
    A further menu is displayed.
  2. Select Options to display the Options window.
  3. On the Options window, select the Trends tab, then use the following settings to define your requirements for new Trends:
  • Defaults—These settings define which Trend features are shown by default:
  • Trend Properties — When you select this button the Trend Properties window is displayed. You can use the Trend Properties window to define the default appearance of newly created Trends (see Configure the Display Settings for a Trend).
  • Key Columns—When you select this button, the Select Columns window is displayed. You can use the Select Columns window to define which columns are shown on the key by default when a new Trend is created (see Define the Columns on the Key).

The Select Columns window differs slightly depending on how you access it. If you select Tools>Options and then select the Key Columns button, the Select Columns window only allows you to choose default columns. This is because custom columns, when used, are applied to a specific trace and so cannot be applied to all Trends (some Trends will not contain the specific trace). However, if you display the Select Columns window by right-clicking on a trace in the Key of a Trend, and then selecting the Columns option, you can choose custom columns and default columns (as the specific trace is known).

  • X Axis Properties — When you select this button, the Edit X Axis window is displayed. You can use the Edit X Axis window to define the default settings for the X Axis for newly created Trends (see Configure the X-Axis).
  • Y Axis Properties — When you select this button, the Edit Y Axis window is displayed. You can use the Edit Y Axis window to define the default settings for the Y Axis for newly created Trends (see Configure a Y-Axis).
  • Horizontal Grid (Default Axis)—Defines whether grid lines are shown for the ticks on the default y-axis. If you select the check box, horizontal grid lines are shown for each tick on the y-axis, and if you clear the check box they are not shown.

If you add another y-axis to the Trend, the new y-axis will only display horizontal grid lines if the Horizontal Grid (All Axis) check box is selected.

  • Horizontal Grid (All Axis)—Defines whether grid lines are shown for the ticks on any y-axes that you add to a Trend. If you select the check box, horizontal grid lines are shown for each tick on added y-axes, and if you clear the check box the grid lines are not shown.

The default y-axis only will have horizontal grid lines if the Horizontal Grid (Default Axis) check box is selected and the Horizontal Grid (All Axis) check box is clear.

  • Vertical Grid—Defines whether vertical grid lines are shown for the ticks on the x-axis for new Trends. If you select the Vertical Grid check box, the vertical grid lines will be shown when you create a new Trend; if you clear the check box, the vertical lines will not be shown.
  • Show ‘Now’ Line—Defines whether a vertical line that indicates the values for the current time (now) is shown on new Trends. If you select the Show ‘Now’ Line check box, the line is shown on new Trends; if you clear the check box, the line is not shown.
  • Extend Trace to ‘Now’—Defines whether the trace is extended to the current time on the Trend (when the trace values are not plotted up to the current time).

If you select the Extend Trace to ‘Now’ check box, the trace is extended so that the last reported value is the value used from the time of the last reported value up to the current time. If you clear the check box, the trace is not extended—the trace line ends at the time of the last value.

If the Interval is set to Per Pixel, the trace may be extended even if you clear the Extend Trace to ‘Now’ check box, as the server may use the current time as part of its calculation, for example, with Interpolated algorithms.

  • Show Alarm Limits—Defines whether lines that indicate the alarm thresholds for the traces are shown on new Trends. If you select the Show Alarm Limits check box, the threshold lines are shown on new Trends; if you clear the check box, the lines are not shown.

The Show Alarm Limits option only applies to constant alarm limits that are constant. If your Trend uses alarm limits that are associated with a Time Profile, the Time Profile alarm limits will vary according to the time of day and will not be affected by the Show Alarm Limits option.

  • Show Markers—Defines whether markers that indicate the values for the traces are shown on new Trends. If you select the Show Markers check box, the marker indicators are shown on new Trends; if you clear the check box, the marker indicators are not shown.
  • Show Annotations—Defines whether markers that indicate annotations are shown on new Trends. If you select the Show Annotations check box, the annotations markers are shown on new Trends; if you clear the check box, the annotations markers are not shown.
  • Show Key—Defines whether the key is shown on new Trends. If you select the Show Key check box, the key is shown on new Trends; if you clear the check box, the key is not shown.
  • X-Axis—Defines the default Offset and Interval for the x-axis (in time units). For example, if you set the Offset to H, the Trend will display data starting at the beginning of the current hour. If you set the Interval to 1H, the width of the x-axis will be 1 hour.
  • Display Ruler Dialog Automatically—Displays a window when you enable the ruler, which contains point values for the ruler position and six values before and after it.
  • Marker Colors—The colors that you define in this section are used whenever the Trend cannot obtain the color settings from the server. Typically, this is when the data source for the trace(s) on the Trend is from a non-ClearSCADA database, for example, another OPC database.

You can choose to define the following default marker colors (they are only used if color settings cannot be retrieved from a ClearSCADA server):

  • Validated/Good Data—The default color of the markers that indicate good quality values (values that are reliably accurate) or values that have been validated by a user (validation only applies when your system has been configured to have the Historic Validation feature enabled via the ClearSCADA Server Configuration Tool - see Historic Configuration Settings in the ClearSCADA Guide to Server Administration).
  • Unvalidated Data—The default color of the markers that indicate a value that has not been validated (validation only applies when your system has been configured to have the Historic Validation feature enabled via the ClearSCADA Server Configuration Tool - see Historic Configuration Settings in the ClearSCADA Guide to Server Administration).
  • Bad Data—The default color of the markers that indicate bad quality values (values that are unreliable and may be inaccurate).
  • Modified Data—The default color of the markers that indicate a value that has been modified by a user.
  • Annotations—The default color of the markers that indicate a user has added an annotation for the value.
  4. Select the OK button to confirm your choices and close the Options window. The selections you made will be applied to new Trends automatically as they are created.


Trends Guide - Create a New Trend (Configuring Trends)

Create a New Trend

Each Pre-Configured Trend in the database is represented by a Trend database item. The Trend database item is used to store the configuration of the Trend.

To create a new Trend database item:

  1. Log on to ViewX via a User account that has the Configure permission for the Group that is to contain the new Trend.
  2. Display the Database Bar (if it is not already shown), and expand the tree structure until you locate the Group that is to contain the new Trend.

NOTE: For information on the ClearSCADA Explorer Bars, see the ClearSCADA Guide to ViewX and WebX Clients.

  3. Right-click on the Group.
    A context sensitive menu is displayed.
  4. Select the New option, then the Trend option.
    A new Trend database item is added to the Group. The Trend is selected automatically, ready for you to define its name.
  5. Enter a name for the Trend and press the Enter key or select another part of the interface to confirm the entry.

When you have created a new Trend database item, you can display the Trend in Design mode (see Display a Trend in Design Mode).

NOTE: To create a new file based Trend, you need to open an existing file based Trend and then save it as a Trend file by using the Save as File option in the File menu. Alternatively, you can display a Trend that is stored in the database and save it as a Trend file, also by using the Save as File option.

Further Information

For information on creating a ‘custom’ ad hoc Trend, see Using TrendSpec to Produce Ad Hoc Trends.


Trends Guide - Display a Trend in Design Mode (Configuring Trends)

Display a Trend in Design Mode

To add traces to a Trend and edit its axes, define its display settings and so on, you need to display the Trend in Design mode.

To display a Trend in Design mode:

  1. Log on to ViewX via a User account that has the Configure permission for the Trend.
  2. In the Database Bar, right-click on the Trend that you want to display in Design mode, then select the Edit option from the context sensitive menu.
    The Trend is displayed in Design mode.

Alternatively, you can display a Trend in Run mode and select the Design toolbar button to switch to Design mode, or you may be able to double-click on the Trend database item to display it in Design mode (this is dependent on the configuration of your User account).

When a Trend is displayed in Design mode, the word ‘Design’ is shown in the Trend’s title banner at the top of the Trend display.

When you have displayed the Trend in Design mode, you can begin to configure it.


Trends Guide - Configure the Display Settings for a Trend (Configuring Trends)

Configure the Display Settings for a Trend

When you create a new Trend it uses the default display settings that are defined on the Options window (see Define the Default Settings for New Trends). You can change the display settings for an individual Trend so that they are different to the default Trend settings. This is useful when a Trend has to have different colors or fonts.

To configure the display settings for a Trend:

  1. Display the Trend in Design mode (see Display a Trend in Design Mode).
  2. Right-click in the main display area of the Trend (the area that will contain the traces).
    A context sensitive menu is displayed.
  3. Select the Edit Properties option.
    The Trend Properties window is displayed.
  4. Use the Title section to define and format the Trend’s title:
  • Title—Enter the text for the title on the Trend. As with other labels, the text for the title has to be enclosed in single straight quotation marks like this: 'Title text'.

NOTE: You can also use the browse button to locate and select a tag. The name of the tag will be used as the ‘Title’. When selecting a tag, you can select the Relative check box for a relative reference or clear it for an absolute reference. For more information, see Relative and Absolute References in the ClearSCADA Guide to Expressions.

  • Color—Select this button to open a color palette to select a color for the title. You can choose any of the colors or use the ... option to create a custom color (see The Color Palette Window in the ClearSCADA Guide to Core Configuration).
  5. Use the Main Font section to set the appearance of the text used in the body of the Trend:
  • Font—Select the font style for the Trend main text.
  • Height—Select the size of the main text (in points).
  • Bold—Select this if you want to display the main text as bold.
  • Italic—Select this if you want to display the main text as italic.
  6. Use the Title Font section to set the appearance for the font used for the Trend title:
  • Font—Select the font style for the Trend title.
  • Height—Select the size of the title text (in points).
  • Bold—Select this if you want to display the title as bold.
  • Italic—Select this if you want to display the title as italic.
  7. Use the Label Font section to set the appearance for the font used for labels on the Trend, for example axis labels:
  • Font—Select the font style for the Trend labels.
  • Height—Select the size of the label text (in points).
  • Bold—Select this if you want to display the labels as bold.
  • Italic—Select this if you want to display the labels as italic.
  8. In the Miscellaneous section:
  • Background Color—Select this button to open a color palette. Use the color palette to select a color or create a custom color for the Trend’s background. (see The Color Palette Window in the ClearSCADA Guide to Core Configuration).

NOTE: When you create a Trend, it uses the default color scheme that is defined by your operating system—typically, it sets the background of the Trend as gray and the foreground (the x-axis, labels, and so on) as black. To change the default settings, use the Windows® Control Panel to define the Display settings.

  • Alarm Limit Labels—Selects the position for the Alarm Limit Labels (constant alarm limits only; this option does not apply to alarm limits that are associated with Time Profiles). The available options are:
  • None—Alarm limit labels are not displayed.
  • Above, Left—Display alarm limit labels above the alarm limit line and on the left hand side of the Trend data area (inside the left y-axis).
  • Above, Right—Display alarm limit labels above the alarm limit line and on the right hand side of the Trend data area (inside the right y-axis).
  • Over, Left—Display alarm limit labels over the top of the alarm limit line and on the left hand side of the Trend data area (inside the left y-axis).
  • Over, Right—Display alarm limit labels over the top of the alarm limit line and on the right hand side of the Trend data area (inside the right y-axis).
  • Left—Display alarm limit labels beside the alarm limit line on the left outside the Trend data area (outside the left y-axis).
  • Right—Display alarm limit labels beside the alarm limit line on the right outside the Trend data area (outside the right y-axis).
  9. Select the OK button to close the Edit Properties window.
    The Trend will display the changes you made.
  10. Select the Save button [image] to store the changes to the Trend.


Trends Guide - Add a Trace to a Trend (Configuring Trends)

Add a Trace to a Trend

You can configure a Trend to show one or more traces. Each trace represents the values for a single source, which can be a point, a forecast, or a time profile. There are three types of trace:

  • Current Trace—Represents the current values of a data source such as a point or a time profile. These are useful for viewing an item’s values over a specific time span and also for comparing the values of multiple items (you can use multiple traces to represent different items on a Trend).

NOTE: A Trend that shows current data can display data from the time that the trace was configured up to the current time. For example, if you configured the trace at 10.00 and the current time is 10.30, the trace will represent the values for the 30 minute period between 10.00 and 10.30.

  • Raw Historic Trace—Represents the historic values that were reported for a data source such as a point (see Raw Historic Data on Trends). No scaling or other calculation is performed on the values for use in ClearSCADA. This option is only available if the data source has historic logging enabled in its configuration and there is historic data in the database.
  • Processed Historic Trace—Represents the ‘processed’ values for a data source such as a point (see Processed Historic Data on Trends). Processed values are produced by performing calculations on the raw historic values, typically to convert the values to a more useful scale. This option is only available if the source item has historic logging enabled in its configuration and there is historic data in the database.

To add a trace to a Trend:

  1. Display the Trend in Design mode (see Display a Trend in Design Mode).

The Trend display consists of the Trend area and the key (see Understanding the Trend Display). The Trend area is where the trace is shown. By default, a new Trend displays two axes (X and Y) and a Title. Extra y-axes can be added if required (see Add a Y-Axis).

The key is displayed below the Trend display area and lists the traces that are shown on the Trend (none by default). It also displays trace values in columns. You can choose which columns you want to display (see Define the Columns on the Key).

  2. In the Database Bar, select the item that is to be the source of a trace on the Trend and drag it onto the Trend.
    A context sensitive menu is displayed that allows you to choose which type of data you want the trace to represent:
  • Current Trace—The trace will represent the current data of the item
  • Raw Historic Trace—The trace will display the historic values that were reported for the item (that is, without performing any calculations on the values). This option is only available if the item has historic logging enabled and there is historic data in the database.

If you select the Raw Historic Trace option for a database point, a trace representing the point’s historic values is added to the Trend.

If you select the Raw Historic Trace option for a forecast item, a further menu is displayed. It contains options for each forecast that has been configured for the item (1-8) and an All option. Forecast 1 is the next forecast that will be performed when the Set Forecast action is executed. After a Set Forecast, the options are updated so that the forecast that was previously represented by the Forecast 8 option is now represented by the Forecast 7 option, the previous Forecast 7 by the Forecast 6 option and so on. The last forecast to be performed moves to the Forecast 8 option. This means that the Forecast 1 option represents the forecast that will be performed next.

By selecting a single forecast option, you add a single trace to the Trend. The trace represents the historic values for the selected forecast. If you select the All option, multiple traces are added to the Trend (each trace representing one of the forecasts).

If you select the Raw Historic Trace option for a point that has its limits set by a time profile item and is configured to store the limit profiles historically, a further menu is displayed. It contains options for each profile that has been configured for the point (1-8) and an All option. If you select a single profile option, a trace representing the point’s historic values for that profile is added to the Trend. If you select the All option, multiple traces are added to the Trend (each trace representing the point’s values for one of the profiles).

NOTE: The ability to store limit profiles historically is limited to certain drivers, such as the DNP3 SCADAPack E-Series driver. For more information, please refer to the documentation for the driver(s) on your system.

  • Processed Historic Trace—The trace will display the ‘processed’ historic values for the item. Processed values are produced by performing calculations on the raw historic values, typically to convert the values to a more useful scale. This option is only available if the item has historic logging enabled and there is historic data in the database.

As with the Raw Historic Trace option, there is an additional sub-menu if you are using the Trend to display Forecasts or data for a point that has its limits set by a Profile. The Forecast, Profile and All options work in the same way as with the Raw Historic Trace option - the only difference is that they apply to processed historic data instead of raw historic data.

NOTE: The context sensitive menu is only displayed if the item has historic and/or processed historic data available. If the item only has current data available, the trace is automatically configured to represent the current data and the context sensitive menu is not displayed.

When you have selected the required option, the trace is added to the Trend. It uses the default configuration settings for a trace (see Define the Default Settings for New Trends).

There are also alternative methods for adding a trace to a Trend:

  • Right-click on the key or on the Trend area, then select the Add Trace option and use the Add Trace window to select the item.

Or:

  • Select the Edit menu, then the Add Trace option, then use the Add Trace window to select the item.

Or:

  1. Select the OPC button [image] to display the OPC Data Bar.
  2. Expand the OPC tree structure to locate the item that you want to have displayed on the Trend. Click on the item to expand and display its contents.
    The item’s OPC tags are shown.
  3. Drag the tag you require onto the Trend (typically, you would drag the CurrentValue tag, but you can add any tag to the Trend).

NOTE: This technique only allows you to create a Current Trace.

Or:

  1. Select the OPC Historic button [image] to display the OPC Historic Bar.
  2. Expand the OPC tree structure to locate the item that you want to have displayed on the Trend.
  3. Drag the appropriate historic aggregate tag for the item onto the Trend. Many items only have a single historic aggregate tag, and so you only need to drag the item icon onto the Trend. However, some items such as Forecasts have multiple historic aggregate tags which you can view by expanding the item in the OPC Historic Bar. You can then drag each historic aggregate tag onto the Trend as required.
    A context sensitive menu is displayed.
  4. Select either Raw Historic or Processed Historic from the context sensitive menu.
  3. Select the Save button [image] to store the changes to the Trend.

When you have added a trace, you can configure it as required (see Configure a Trace).


Trends Guide - Configure a Trace (Configuring Trends)

Configure a Trace

When you first add a trace to a Trend, it uses the default settings that have been configured for your system. You can edit the trace so that it uses settings and that meet your requirements.

To edit a trace:

  1. Right-click on the name of the trace in the Trend key.
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Edit Trace window is displayed.
  3. Use the Source field to select the point that provides the data for the trace. If you have used drag and drop functionality to add a trace to the Trend, the Source field will show the name of the item that you dragged onto the Trend.

If you want to change the source or select a source for the first time, you can either enter the location of the point in the Source field or use the Browse button feature to select the required point tag. You can choose to use a relative or absolute reference to the tag by selecting or clearing the Relative check box on the Select Tag browse window (see Relative and Absolute References in the ClearSCADA Guide to Expressions).

  4. Use the Label field to define the text string that is used to represent the trace in the Key. It is the FullName property of the database item associated with the trace by default, but you can change it if required.

NOTE: As the Label is an expression, you need to enclose the Label entry with single straight quotation marks ' '.

  5. Use the Advanced Source Configuration button to access the Edit Source window. You can use the Edit Source window to define advanced settings for the data source. The options on the Edit Source window vary according to the type of data represented by the trace.

When you select the Advanced Source Configuration button, the Edit Source window is displayed.

Use the Edit Source window to define the source settings as follows:

  • Tag—Represents the property tag of the source of the trace. You can alter the tag by overwriting the entry in the Tag field or by using the browse button feature to locate and select a different property tag in the hierarchy.
  • Algorithm—Defines the algorithm type that is used to process the source’s historic data. For more information on the various algorithms, see Built-In Historic Algorithms for Processed Historic Data.

NOTE: The algorithm option is only available for Processed Historic traces.

NOTE: If the trace Interval is set to Per Pixel, only the following options are available in the Algorithm combo box—Average, Average Interpolated, Average Last, Interpolated, Max, Max Interpolated, Max Last, Min, Min Interpolated, Min Last.

  • X Offset— Defines a time offset for the trace. This is useful when there are multiple traces on a Trend. You can use the offset to set different time scales so that you can compare values over time. For example you could have a Trend that show one trace’s value for the current hour and another trace’s values value for the previous hour.

You can choose from any of the time periods provided in the combo box or you can overwrite the combo box entry with your own time interval (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).

This option is only available for Processed Historic and Raw Historic data. For more information on the two types of data, refer to:

  • Raw Historic Data on Trends
  • Processed Historic Data on Trends.
  • Multiplier—Allows you to apply scaling to the trace. Each value that is received from the server is multiplied by the Multiplier amount and then the Y Offset (below) is added to provide the scaled value. This is useful when value scaling is required.
  • Y Offset— Defines the position of the trace on the y-axis. This feature allows multiple traces to be displayed closer to each other on the y-axis for comparison purposes. The Y Offset value is added to each value that is received from the server for this particular trace so that the values appear higher or lower on the y-axis as required.

When you have defined the advanced source settings, select the OK button to close the Edit Source window and return to the Edit Trace window.

  6. Use the Trace section to define the appearance of the trace:
  • Y-Axis—Allows you to choose which of the y-axes applies to the trace. If your Trend only has one y-axis, you will only be able to select Left which is the default y-axis on the left-hand side of the Trend. If you add another y-axis, you will be able to select any of the extra y-axes instead of the left y-axis.
  • Style—Defines the type of trace. You can choose from:
  • Line—The trace is drawn as a line between the values.
  • Step First—The trace is drawn so that there is a right-angle between the values. The vertical part of the right-angle is drawn from the previous value, and the horizontal part indicates the next value (and contains the marker if markers are shown).
    Vertical part of the right-angle is drawn from the previous value
    Horizontal part of the right-angle is drawn to the next value

  • Step Last—The trace is drawn so that there is a right-angle between the values. The horizontal part of the right-angle is drawn from the previous value, and the vertical part indicates the next value (and contains the marker if markers are shown).
    Horizontal part of the right-angle is drawn from the previous value
    Vertical part of the right-angle is drawn to the next value

  • Bar—The trace is drawn as a bar (not filled).
  • Filled Bar—The trace is drawn as a bar and is filled in.

  • Gap Detect—This combo box is only available for historic traces with a Line or Step First or Step Last style. You can use the Gap Detect combo box to define the amount of time that is acceptable for a gap in the data. The trace will be interrupted by the gap if the Gap Detect setting is less than the amount of time for which the gap has occurred. If the Gap Detect setting is greater than the time span of the gap, the trace will be continuous (uninterrupted by the gap in the data).

For example, if the server is offline for ten minutes, then there will be a ten minute gap in the data where no values were retrieved or calculated. If the Gap Detect setting is less than 10M, there is a break in the trace between the data before the ten-minute gap and the data that follows the gap when the server returns to an online state. If the Gap Detect setting is greater than 10M, then the a line is drawn between the data before the gap and the data after the gap so that the missing values are treated as part of the trace (and the trace is uninterrupted).

  • Bar Width—This combo box is only available when the trace Style is set to Bar or Filled Bar and it defines the amount of time that can be covered by a single bar. The Width setting cannot be greater than the Interval.
  • Interval—Defines the amount of time between each value that is shown on the trace. You can choose from any of the time periods provided in the combo box or you can overwrite the combo box entry with your own time interval.

NOTE: Processed Historic traces have a Per Pixel option which allows ClearSCADA to determine the Interval automatically (it will use the time period represented by each pixel of the x-axis to calculate the interval). This option generates smoother Trend traces, but many of the Algorithm options listed above are not available in this mode.

  • Raw Overlay—This check box is only available for Processed Historic traces that have Interval set to Per Pixel. When you select the check box, the raw historic values are shown as markers on the trace in addition to the processed historic values (that the trace represents). If you clear the check box, the markers for the raw historic values are hidden.

For more information on processed historic traces, see Processed Historic Data on Trends.

  • Extend Trace to ‘Now’—Defines whether the trace is extended to the current time on the Trend (when the trace values are not plotted up to the current time).

If you select the Extend Trace to ‘Now’ check box, the trace is extended so that the last reported value is the value used from the time of the last reported value up to the current time.

If you clear the Extend Trace to ‘Now’ check box, the trace is not extended—the trace line ends at the time that corresponds to the last value.

NOTE: If the Interval is set to Per Pixel, the trace may be extended even if you clear the Extend to ‘Now’ check box, as the server may use the current time as part of its calculation, for example, with interpolated algorithms.

  • Point Limit—This field is only available for Raw Historic traces and it allows you to define the maximum number of values that can be shown on a Trend.

The Point Limit helps to reduce the load on the server as it means a Trend can only use a set number of values. If a trace requires more values than the defined Point Limit, the Trend will show no values for the trace.

Traces that require an excessive number of values place a high demand on server resources and can cause slow performance. By setting a point limit, you instruct ClearSCADA to only draw the trace if it has a reasonable amount of values. As a result, this means that traces with excessive numbers of values are not drawn and so do not affect performance.

The default Limit of 2500 is usually suitable for most systems, but you may need to alter the setting if there are Trends that have high numbers of values (in many cases, Trends with many values for a specific time period).

If a trace has a high number of values and the Trend is slow and less responsive than expected, operators may choose to change the time scale on the x-axis. Changing the time scale by using the Zoom tool means that there will be fewer values shown on the trace, and so it will place less demand on the server).

For more information on raw historic data, see Raw Historic Data on Trends.

  • Update— This field is only available on Current traces and allows you to define when the trace is updated.
  • On Interval— The trace updates at the end of the interval period using the value of the data source at that time. Any changes to the value that occur during the interval period are not displayed.
  • On Change— The trace updates whenever the value of the data source changes.
  • Interval/Change— Updates the trace whenever the value of the data source changes as well as at the end of the interval period.
  7. Define the appearance of the trace by using the Line settings:
  • Use the Color button to define the color of the trace. Choose a color from the color palette or select the ... option on the color palette and use the Color window to create a custom color (see The Color Palette Window in the ClearSCADA Guide to Core Configuration).
  • Use the Style combo box to define the appearance of the trace line. The line can be a solid line or a dashed line (there are several types of dashed line).
  • Use the Width spin box to define the thickness of the trace line (this is only available for Line, Step First and Step Last trace styles.
  8. Use the Markers settings to define the appearance of the markers that indicate the reported or calculated values:
  • Limit—Define the maximum number of markers that can be shown on a trace. The markers indicate each value. If the number of markers requested by the Trend exceeds the markers Limit, the markers are not shown. This is useful as it allows you to control the maximum number of markers that can be shown on a trace—an excessive amount of markers can result in the trace being less effective as it is difficult for operators to distinguish between the values.

Typically, the default setting of 250 is adequate, but you may need to increase the Limit if your Trends are not showing any markers (because they require more markers than are permitted by the Limit). However, you may need to reduce the Limit if your Trends are difficult to use because they contain too many markers.

  • Size—Define the size of the markers. You can choose a size from 1 to 5, where size 1 is the smallest and size 5 is the largest. You should choose the size that is suitable for the trace. For example, smaller marker sizes are recommended for traces that contain a high number of markers, as large markers can make traces appear cluttered, especially when there are a high number of values on display.
  • Style—Define the shape of the markers that are shown on the trace. You can choose from Diamond, Square, or Cross shapes.
  9. With a Raw Historic or Processed Historic trace, use the fields within the Annotations section to define the appearance of any annotation markers on the trace:
  • Size—Use the combo box to define the size of the annotation markers. You can choose a size from 1 (the smallest size) to 5 (the largest size). The default is 3.
  • Style—Use this combo box to define the shape of the annotation markers. The options are Square, Diamond, or Cross.

For more information, please refer to the following sections:

Annotations and annotation markers: see Trend Annotations.

Raw Historic data: see Raw Historic Data on Trends.

Processed Historic Data: see Processed Historic Data on Trends.

  10. Select the OK button to confirm your choices and close the Edit Trace window.
    Your Trend will display with the settings you selected.
  11. Select the Save button [image] to store the changes to the Trend.


Trends Guide - Configure Multiple Data Sources for a Trace (Configuring Trends)

Configure Multiple Data Sources for a Trace

For Current and Processed Historic traces it is possible to use multiple data sources to determine the value of the trace. Each value that is plotted on the trace is the sum of the values from two or more data sources for that particular time.

Before the values are calculated and plotted on the Trend, each value is multiplied by its Multiplier amount and then has its Y Offset added to the result. This provides the value that will then be added to the other values for that specific time.

Example:

A trace has 2 data sources. Both traces have an interval of 1M (they provide a value every minute). This value is then used to calculate the value that is plotted on the Trend.

After 1 minute, the value reported by the first data source is multiplied by its Multiplier amount and then has its Y Offset added to the result. This provides the value for the first data source. At the same time, the value from the second data source is also multiplied by its Multiplier amount and has its Y Offset added to the result. This provides the value for the second data source.

The value for the first data source is added to the value for the second data source and the resulting value is plotted on the Trend.

This process is repeated every minute.

To configure a trace to have multiple data sources:

  1. Right-click on the name of the trace in the Trend key.
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Edit Trace window is displayed.
  3. For a Current trace, set the Update field to On Interval. For a Processed Historic trace, clear the Raw Overlay check box.
  4. Select the Advanced Source Configuration Button
    The Edit Sources window is displayed.
  5. Select the Add button to add a new source to the list.
    The Edit Source window is displayed. Use the Edit Source window to define the source details for the trace in the same way as you would define the source details for any other trace (see Configure a Trace).
  6. Select the OK button on the Edit Source window to confirm your selection and close the Edit Source window.
    The new source is added to the list of sources on the Edit Sources window.
  7. You can add further sources by repeating steps 4 and 5 for each additional source.

If you want to alter one of the sources, select it in the list, then select the Edit button to display the Edit Source window. Use the Edit Source window to define the source details for the trace in the same way as you would define the source details for any other trace (see Configure a Trace).

If you want to remove one of the sources, select the source you want to remove in the list, then select the Remove button.

  8. Select OK button to confirm your changes and close the Edit Sources window.
  9. Select the Save button [image] to store the changes to the Trend.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends


Trends Guide - Configure the X-Axis (Configuring Trends)

Configure the X-Axis

When you first configure a Trend, the x-axis uses the default settings for your system. If the default settings are inappropriate for your requirements, you can alter the settings for the x-axis. For example, you may need to alter the amount of time that is represented on the x-axis by changing the Interval setting.

To configure the x-axis:

  1. Display the Trend that has the x-axis that you want to change (see Display a Trend in Design Mode).
  2. Right-click on the x-axis.
    A context sensitive menu is displayed.
  3. Select the Edit option.
    The Edit X-Axis window is displayed.

NOTE: Alternatively, you can display the Edit X-Axis window by selecting the Edit menu, then choosing the Edit X-Axis option.

  4. Select the mode for the x-axis from the Mode combo box. The mode defines the type of time scale shown on the x-axis and can be:
  • Absolute—The Trend displays the data for a specific time. You can use the navigation tools to view the values for different times, but the Trend will revert to the specified time when it is re-displayed. You can define the specific time by using the Start and End settings.
  • Relative to Now—The Trend displays the data for a time that is relative to the present time, for example, the data for yesterday.

For example, if the current time is 10.40 and the Relative to Now entry is NOW-4OM, the first time on the x-axis will be 10.00 (NOW-40 minutes). The amount of time shown on the x-axis is defined by the Interval.

Relative to Now (Start) defines the start time that is shown on the x-axis

  • Relative to Latest—The Trend displays the data for a time that is relative to the latest value to be plotted on the Trend.
  5. Use the Continuous check box to define whether the relative x-axis updates to show the values for the current time:
  • Select the check box if the x-axis is to update to show the values for the current time
  • Clear the check box if the x-axis is not to update to show the values for the current time.

Example:

The Continuous check box is selected (enabled). The Offset is H and the Interval is 1H, so the Trend displays the values for a one hour period from the start of the current hour.

The Trend is displayed at 10:30, and so the x-axis covers the range of times from 10:00 to 11:00.

The time reaches 11:00. The x-axis updates so that it covers the range of times from 11:00 to 12:00.

If the Continuous check box had been cleared, the x-axis would not have updated to show the times from 11:00 to 12:00—it would have remained showing the range 10:00 to 11:00.

  6. Use the combo box below the Continuous check box to define a preset time scale or a custom time scale for the x-axis (this only applies when the Mode is set to Relative to Now or Relative to Latest).

Choose from:

  • Current Minute—Sets the x-axis to represent 1 minute, beginning at the start of the current minute. (The Offset and Interval are configured automatically and are grayed out).
  • Previous Minute—Sets the x-axis to represent 1 minute, beginning at the start of the previous minute. (The Offset and Interval are configured automatically and are grayed out).
  • Current Hour—Sets the x-axis to represent 1 hour, beginning at the start of the current hour. (The Offset and Interval are configured automatically and are grayed out).
  • Previous Hour—Sets the x-axis to represent 1 hour, beginning at the start of the previous hour (The Offset and Interval are configured automatically and are grayed out).
  • Today—Sets the x-axis to represent 1 day, beginning at the start of the current day. (The Offset and Interval are configured automatically and are grayed out).
  • Yesterday—Sets the x-axis to represent 1 day, beginning at the start of the previous day. (The Offset and Interval are configured automatically and are grayed out).
  • This Week—Sets the x-axis to represent 1 week, beginning at the start of the current week. (The Offset and Interval are configured automatically and are grayed out).
  • Last Week—Sets the x-axis to represent 1 week, beginning at the start of the previous week. (The Offset and Interval are configured automatically and are grayed out).
  • This Month—Sets the x-axis to represent 1 month, beginning at the start of the current month. (The Offset and Interval are configured automatically and are grayed out).
  • Last Month—Sets the x-axis to represent 1 month, beginning at the start of the previous month. (The Offset and Interval are configured automatically and are grayed out).
  • This Year—Sets the x-axis to represent 1 year, beginning at the start of the current year. (The Offset and Interval are configured automatically and are grayed out).
  • Last Year—Sets the x-axis to represent 1 year, beginning at the start of the previous year. (The Offset and Interval are configured automatically and are grayed out).
  • Other—Allows you to define the time span shown on the x-axis. When you select the Other option, the Offset and Interval fields become available. Use the Offset and Interval fields to define the time scale shown on the x-axis.

If you have set the time scale for the x-axis to any of the predefined time scales (that is, selected any option except Other) proceed to step 8.

If you have set the time scale for the x-axis to Other, proceed to step 7.

  7. Use the Offset and Interval fields to define the time shown on the x-axis:
  • Offset—Defines the start time or end time of the x-axis. For example if the Offset is H then the start time for the X-Axix is the begining of the current hour.
  • Interval—The amount of time that is displayed on the x-axis at one time. For example, if the Interval is 12 hours, the x-axis displays a 12 hour period.

When entering the times for the Offset and Interval, you need to use the appropriate OPC Time formats (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).

You can skip from one period to another by using the Previous Interval and Next Interval navigation tools (see View Earlier or Later Values on a Trend).

NOTE: New Trends have a custom time scale with an Offset of H (hour), and an Interval of 1H (1 hour), by default. This means that the x-axis displays from the start of the current hour up to the end of the current hour.

  8. Use the Color button to define the color for the x-axis. You can select a color from the color palette or select the ... option to display the Color window. You can use the Color window to create a custom color as required (see The Color Palette Window in the ClearSCADA Guide to Core Configuration).
  9. Use the Position combo box to define the position of the x-axis on the Trend. You can chose to display the axis at the Top or the Bottom of the Trend.
  10. Use the Format combo box to select the time format for the x-axis. You can choose to display the time in the 24 Hour format, or the 12 Hour format. By default, a Trend uses the 24 hour format.
  11. Use the Minor Ticks spin box to define the number of small indicators that are shown on the x-axis. The minor ticks are positioned between the larger indicators, referred to as major ticks.
    Minor tick
    Major tick

You can define how many minor ticks are shown between each pair of major ticks.

  12. Select the OK button to confirm your selections and close the Edit X-Axis window.
    Your Trend will use the settings you have selected.

NOTE: The amount of data that is shown on your Trend is dependent on the amount of time that has elapsed since you inserted the trace. As time passes, more data will be shown on your Trend.

  13. Select the Save button [image] to store the changes to the Trend.


Trends Guide - Add a Y-Axis (Configuring Trends)

Add a Y-Axis

Each trace can be assigned to any of the y-axes on a Trend (see Configure a Trace). This allows database points with different ranges to be displayed on the same Trend without any loss of detail.

By default, each Trend has a single y-axis which is shown on the left-hand side. You can add extra y-axes as required.

To add a y-axis:

  1. Display the Trend to which you want to add a y-axis (see Display a Trend in Design Mode).
  2. Right-click on the Trend’s main display area.
    A context sensitive menu is displayed.
  3. Select Add Y-Axis.
    The Add Y-Axis window is displayed.
  4. Use the Name field to define the name for the y-axis. Enter a new name as required.
  5. Select the Side on which the additional y-axis will display. You can choose to display it on the Left or Right side of the Trend.
  6. Use the Color button to define the color of the y-axis. You can select a color from the Color palette or select the ... option to display the Color window. You can use the Color window to create a custom color (see The Color Palette Window in the ClearSCADA Guide to Core Configuration).
  7. Use the Format field to define the format of the value range shown on the y-axis (see Defining the Format of Displayed Values in the ClearSCADA Guide to Core Configuration).

NOTE: The format that you define for the y-axis is also used in the ToolTip displays of each marker.

  8. Use the settings in the Label section to configure the label for the y-axis:
  • Label—Either enter a suitable Label for the y-axis or use the browse button to select a Tag from the database (the value for the selected Tag will be used as the Label for the y-axis). If you enter a Label, remember that the text has to be enclosed with single straight quotation marks ' '.
  • Position—Choose the position of the label on the y-axis. You can choose from:
  • Top—Positions the Label so that it runs top to bottom, with the start of the Label being shown at the top of the y-axis. The end of the Label may extend beyond the bottom of the y-axis.
  • Center—Positions the Label so that it runs top to bottom, with the start of the Label being shown at the center of the y-axis. The end of the Label may extend beyond the y-axis.
  • Bottom—Positions the Label so that it runs top to bottom, with the end of the Label being shown at the bottom of the y-axis. The start of the Label may extend beyond the top of the y-axis.
  • Style—Use the Style combo box to define the orientation of the Label. The orientation can be:
  • Normal—Positions the Label so that it displays unrotated, with its letters running from top to bottom down the y-axis.
  • Rotated—Positions the Label so that it displays rotated 90 degrees counter-clockwise so that it runs from bottom to top up the y-axis.
  9. Use the Scale section to define the scaling settings for the y-axis:
  • Mode—Use to define the method of scaling used on the y-axis. Choose from:
  • Manual—You define the lowest value and highest value that can be shown on the y-axis (and therefore the Trend). You can define the values in the Minimum and Maximum fields in the Scale section.
  • Range—Scales the y-axis according to the Minimum and Maximum Trend values of the point (analog points) or the number of possible states (digital/binary points).

The Trend values are defined on the configuration Form of an analog point (see Define an Analog Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration).

The number of possible states for a digital point is defined by the Number of Bits setting on the digital point configuration Form (see Define the Number of Bits for a Digital Point in the ClearSCADA Guide to Core Point Configuration).

  • Automatic—Scales the y-axis automatically so that it can display the lowest and highest values that are on display within suitable limits. This means that the y-axis is updated so that the lowest and highest values can be shown.

If alarm limits are configured, they are displayed on the Trend (by default). You may need to hide the alarm limits to ensure that the Automatic scaling only shows limits suitable to the values on display (see Hide and Show the Alarm Limits).

  • Inverted—Use this check box to define whether the maximum values are shown at the top or the bottom of the y-axis. If you select the Inverted check box, the maximum values are shown at the bottom of the y-axis; if you clear the check box, they are shown at the top.
  • Logarithmic—Use this check box to define whether the y-axis is scaled using a base-10 logarithm to a minimum value (greater than 0) and a maximum value. Typically, you would only select the Logarithmic check box if the Trend has traces that have exponential curves.

Select the check box to apply Logarithmic scaling to the y-axis

Clear the check box to disable the Logarithmic scaling feature on the y-axis.

  • Minimum—Use to define the lowest value on the y-axis (only available when the Mode is set to Manual).
  • Maximum—Use to define the highest value on the y-axis (only available when the Mode is set to Manual).
  10. Use the Ticks section to define the settings for the markings on the y-axis:
  • States—Use to define whether state descriptions are shown on the y-axis. If you select the States check box to enable the states feature, you can then use the browse button to associate the state descriptions for a point with the ticks that are shown on the y-axis. For example, if a digital point has states of On and Off, the ticks will be labelled On and Off on the y-axis. (The ticks are named exactly the same as the point’s state descriptions).
  • Automatic—Use to define whether the ticks on the y-axis are positioned automatically.
  • Select the check box to set the ticks to be positioned at suitable intervals on the y-axis automatically.

If you select the Automatic check box, ClearSCADA will automatically determine how many ticks should be shown and place them at suitable positions.

  • Clear the check box to disable automatic tick positioning (you will be able to define the number of ticks on the y-axis).

If you clear the Automatic check box, any interval can be used on the y-axis and you will need to specify the number of major and minor ticks that are shown (in the Major and Minor fields respectively).

NOTE: The Automatic check box in the Ticks section is different to the Automatic option in the Scale section.

  • Major—Use to define the number of major ticks that are shown on the y-axis. This is only available when the Automatic check box for the Ticks section is clear.
  • Minor—Use to define the number of minor ticks that are shown on the y-axis. These are the ticks between the Major ticks. This is only available when the Automatic check box for the Ticks section is clear.
  11. Select the OK button to confirm your choices and close the Add Y-Axis window.
    Your Trend will display the new y-axis.
  12. Select the Save button [image] to store the changes to the Trend.


Trends Guide - Configure a Y-Axis (Configuring Trends)

Configure a Y-Axis

You can change the configuration of any of the y-axes that are shown on a Trend (provided your User account has the Configure permission for the Trend). This means you can adjust the:

  • Name of the y-axis
  • Position of the y-axis on the Trend
  • Label of the y-axis
  • Scaling of the y-axis
  • Ticks on the y-axis.

To configure a y-axis:

  1. Display the Trend that has the y-axis that you want to change (see Display a Trend in Design Mode).
  2. Right-click on the y-axis that you wish to configure.
    A context sensitive menu is displayed.
  3. Select the Edit option.
    The Edit Y-Axis Window is displayed.
  4. Use the Edit Y Axis window to change the settings for the y-axis. The settings on the Edit Y-Axis window work in the same way as the settings on the Add Y-Axis window (see Add a Y-Axis).
  5. Select the OK button to confirm your choices and close the Edit Y-Axis window.
    Your Trend will display with the settings you selected.
  6. Select the Save button [image] to store the changes to the Trend.


Trends Guide - Delete a Y-Axis (Configuring Trends)

Delete a Y-Axis

Each Trend can display multiple y-axes as required. If you need to remove a y-axis from a Trend:

  1. Display the Trend that has the y-axis that you want to remove (see Display a Trend in Design Mode).
  2. Right-click on the y-axis that you want to remove.
    A context sensitive menu is displayed.
  3. Select Delete.
    The selected y-axis is removed from the Trend display.
  4. Select the Save button [image] to store the changes to the Trend.

ATTENTION: Any traces that use the deleted y-axis are also removed from the Trend when you delete that y-axis. For this reason, you should assign traces to a y-axis that will remain on the Trend (see Configure a Trace).


Trends Guide - Define the Columns on the Key (Configuring Trends)

Define the Columns on the Key

You can determine which of the available columns are displayed in the Trend key. The columns categorize the various types of information that can be shown in the key for each trace.For information on the individual columns, see Trend Key.

To define which columns are shown on the Key, you need to use the Select Columns window. There are two ways of displaying the Select Columns window:

  • Select the Tools option, and then Options. This displays the Options window. Select the Trends tab and then select the Key Columns button to display the Select Columns window.

When you display the Select Columns window in this way, the choices you make are applied to all Trends by default. You can only choose from the default columns, as custom columns cannot be applied to all Trends (they need to be associated with a specific trace).

  • Display a Trend that contains a trace, then right-click in the Key and select Columns from the context sensitive menu. The Select Columns window is displayed and contains options that only apply to the current Trend.

When you display the Select Columns window in this way, you can choose from any of the default or custom columns, and can also create, edit or remove custom columns. This is because ClearSCADA can identify the traces that are shown on that Trend (custom columns require a reference to an OPC property in the database, and so have to be associated with a trace).

To configure the key:

  1. Display the Trend that has the key that you want to configure (see Display a Trend in Design Mode).
  2. Display the Select Columns window using one of the procedures described at the start of this section. Remember that custom columns are only available for individual Trends.

The Select Columns window contains a Predefined list of columns (see Trend Key) and a Custom section that you can use to add your own columns.

NOTE: Some columns are only suitable for Historic Trends, for example, the Algorithm column can only show data when used on a Historic Trend. This is because algorithms are not applied to current data.

  3. Select the columns that you want to be shown in the Trend Key:
  • Select the check boxes for those predefined columns that you want to be displayed in the Trend key.
  • Clear the check boxes for those predefined columns that you want to exclude from the Trend key.

If you have displayed the Select Columns window via the Columns option on the Key’s context sensitive menu, you can use custom columns. If you want to use custom columns, proceed to step 5. If you have no requirement for custom columns on the Trend, proceed to step 12.

If you have displayed the Select Columns window via the Options window, you can only use the default (predefined) columns. Proceed to step 12.

  4. Select the Add button to display the Add Custom Column window.

You can use the Add Custom Column window to create new columns that can be shown on the Trend’s key. The columns use expressions to define the value that they display, similar to animations on Mimics. As with animations, the expressions can refer to OPC tags and can use functions and so on, in the expressions syntax. For more information on expressions, see Welcome to the Guide to Expressions in the ClearSCADA Guide to Expressions.

  5. Enter the column Name (it should describe what the column will contain).
  6. In the Expressions list, select the trace for which you want to enter the expression.
  7. Select the Edit button.
    The Expression window is displayed.
  8. Define an Expression for the trace. The expression defines the source of the data that is shown in the custom column for the selected trace. Typically, the source is a property of a specific point. For example, if you created a custom column to show whether the source of the trace is under exclusive control, you could create the following expression:
"System:AI1.ExclusiveCtrlActive"

Where System is the name of your system, AI1 is the name of the database point that provides the data for the trace (the trace’s source) and ExclusiveCtrlActive is the property of the point. The value of the ExclusiveCtrlActive property indicates whether the point is under exclusive control and will be shown in the custom column for the trace. (The custom column will show 0 if the point is not under exclusive control or 1 if the point is under exclusive control).

For more information on using the Expression window and creating an expression, see Using the Expression Editors in the ClearSCADA Guide to Expressions.

  9. Select the OK button.
    The Expression window is closed and the expression is displayed in the Add Custom Columns window.
  10. Select the OK button to confirm the settings for the new column.
    The Add Custom Column window is closed and the new column is added to the Custom list on the Select Columns window.

If you need to change the configuration of a custom column, select the custom column from the list and then select the Edit button to display the Edit Custom Column window. This window works in the same way as the Add Custom Column window (see step 5).

If you need to remove a custom column, select the custom column from the list and then select the Delete button.

When you are satisfied with your selection of predefined columns and custom columns, proceed to step 12.

  11. Select the OK button to confirm your choices and close the Select Columns window.
    The Select Columns window is closed and the Trend key displays the columns you selected.
  12. Select the Save button [image] to store the changes to the Trend.


Trends Guide - Using TrendSpec to Produce Ad Hoc Trends

Using TrendSpec to Produce Ad Hoc Trends

With a Pre-Configured Trend, or a File Based Trend, you configure the Trend’s properties via a series of windows in ViewX (see Configuring Trends).

With a ‘custom’ Ad Hoc Trend, you produce the Trend’s definition using ClearSCADA’s proprietary specification language, TrendSpec. Many of the properties that you can specify using TrendSpec are equivalent to the properties that you can specify on a Pre-Configured or File Based Trend.

You can Base a TrendSpec Definition on the Definition of Another Ad Hoc Trend or write a TrendSpec definition from the beginning. Use a suitable text editing application to write the definition, or enter the definition directly into the relevant Mimic’s Script Editor, or hyperlink pick action’s URL.

You configure a pick action on a Mimic to enable users to access the ‘custom’ ad hoc Trend. You include the TrendSpec definition in the Mimic script or URL that determines the pick action’s activity. Users with User accounts that allow access to the Favorites Bar can add links to their Favorites list, to provide access to any frequently used ‘custom’ ad hoc Trends.

TrendSpec, used in conjunction with ClearSCADA’s scripting support, is particularly useful for allowing users to specify which combination of traces they want to display on a multiple trace ad hoc Trend, whenever they choose to display that Trend.

The subsections within this section explain:

  • The Basic TrendSpec Structure, including:
  • The Mandatory Section Identifiers
  • The Mandatory Values.
  • The Optional Values that you can include in a TrendSpec definition.
  • How to use TrendSpec to define:
  • Multiple Trace Ad Hoc Trends
  • Multiple Source Traces.
  • How to Base a TrendSpec Definition on the Definition of Another Ad Hoc Trend.

Also included is a section on Troubleshooting - TrendSpec.

For a series of examples that demonstrate how TrendSpec can be used to produce ‘custom’ ad hoc Trends and how to access those Trends from Mimics, see Example Configuration.

ATTENTION: Some web applications limit the length of the hyperlinks that can be used to access other displays. For this reason, we recommend that you use short TrendSpec definitions on those ‘custom’ ad hoc Trends that will be accessed via a WebX client.


Trends Guide - Basic TrendSpec Structure (Using TrendSpec to Produce Ad Hoc Trends)

Basic TrendSpec Structure

You can Base a TrendSpec Definition on the Definition of Another Ad Hoc Trend or write a TrendSpec definition from the beginning. Use a suitable text editing application to write the definition, or enter the definition directly into the relevant Mimic’s Script Editor.

Each Trend definition has to include the following identifiers and values, with commas separating, and parentheses surrounding, each subsection:

TREND
(
TRACE(<Data Mode>,<Y-Axis Name>,SOURCE (<Source Name>)),
XAXIS(<X-Axis Mode>),YAXIS(<Y-Axis Name>)
)

TREND, TRACE, SOURCE, XAXIS, and YAXIS are the definition’s Section Identifiers. Of these, the SOURCE section has to be specified within the TRACE section, and the TRACE, XAXIS and YAXIS sections have to be specified within the overall TREND section.

The entries in angle brackets <> indicate the Mandatory Values that have to be included in each Trend definition. Within each subsection, you can optionally specify further values in addition to these mandatory values—such additional Optional Values have to be specified after the Mandatory Value(s) in each subsection. The <Y-axis Name> mandatory values in the TRACE and YAXIS subsections have to be identical to each other.

Do not include the angle brackets <> in a Trend definition—they are used within the documentation to indicate where the actual content differs, depending on the required Trend structure.

The section and optional identifiers used in a TrendSpec definition are case insensitive. Any strings or expressions that reference an item in the ClearSCADA database are case sensitive.

Example:

TREND (TRACE(RawHistoric, 'Temperature',SOURCE ('Point3.Historic')),
XAXIS(RelativeLatest),YAXIS('Temperature'))

(For an ad hoc Trend that displays a trace of raw historic data for the point named Point3. The data indicates the point’s temperature (with the Y-axis being labelled ‘Temperature’). The X-axis constantly updates, so that the data shown is for a time that is relative to the latest value plotted on the Trend.)

For a TrendSpec definition to be used in script or a URL, the definition has to be appended to the rest of the script or URL content. This content needs to include the full path to the ad hoc Trend (typically SCX:////Trend/). For more information, see Base a TrendSpec Definition on the Definition of Another Ad Hoc Trend, and see Example Configuration.

With any Trend definition, ClearSCADA uses the ViewX defaults for any settings—such as the x-axis offset and interval, or the y-axis scale—that are not specified in the definition. These defaults are specified on the Trends tab of the ViewX Options window (see Define the Default Settings for New Trends).


Trends Guide - Section Identifiers (Using TrendSpec to Produce Ad Hoc Trends)

Section Identifiers

The mandatory section identifiers in a TrendSpec definition are:

  • TREND
  • TRACE
  • SOURCE
  • XAXIS
  • YAXIS.


Trends Guide - TREND (Using TrendSpec to Produce Ad Hoc Trends)

TREND

This is the TrendSpec section identifier into which the other Section Identifiers have to be nested (see Basic TrendSpec Structure).

The TREND section in a TrendSpec definition does not include any mandatory values, however it has to contain at least one TRACE, SOURCE, XAXIS, and YAXIS section.

If required, you can specify one or more TREND Optional Values. Such optional values can be placed anywhere within the TREND section, as long as they are placed outside of the above subsections.


Trends Guide - TRACE (Using TrendSpec to Produce Ad Hoc Trends)

TRACE

The TRACE section in a TrendSpec definition has to have two TRACE Mandatory Values. A SOURCE subsection has to follow these mandatory values.

If required, you can specify one or more TRACE Optional Values after the above TRACE mandatory values. TRACE optional values can be placed before or after the SOURCE subsection. For more information, see Optional Values.

For each TRACE section in a TrendSpec definition, there has to be a corresponding YAXIS section. If TrendSpec is used to define an ad hoc Trend that has multiple traces, the TrendSpec definition has to contain a separate TRACE section and a corresponding YAXIS section for each trace (see Multiple Trace Ad Hoc Trends).


Trends Guide - SOURCE (Using TrendSpec to Produce Ad Hoc Trends)

SOURCE

The SOURCE section resides within the TRACE section within a TrendSpec definition (see Basic TrendSpec Structure).

The SOURCE section has to contain one SOURCE Mandatory Value.

If required, you can specify one or more SOURCE Optional Values after the above mandatory value.

If a TRACE has more than one origin—whereby its value is the sum of two or more sources—the TRACE section has to contain a separate SOURCE section for each origin (see Multiple Source Traces).

Where an ad hoc Trend contains multiple traces, the TrendSpec definition has to include a separate TRACE section and corresponding SOURCE section for each trace (see Multiple Trace Ad Hoc Trends).


Trends Guide - XAXIS (Using TrendSpec to Produce Ad Hoc Trends)

XAXIS

An ad hoc Trend can only contain one x-axis and therefore a TrendSpec definition can only contain one XAXIS section. The section has to contain one XAXIS Mandatory Value.

If required, you can specify one or more XAXIS Optional Values after the above mandatory value.


Trends Guide - YAXIS (Using TrendSpec to Produce Ad Hoc Trends)

YAXIS

The YAXIS section in a TrendSpec definition has to contain one YAXIS Mandatory Value. The string that is specified for this value has to be identical to the string specified for the same mandatory value in the corresponding TRACE section.

A TrendSpec definition has to include one TRACE section and corresponding YAXIS section per trace. Therefore, a Trend that has multiple traces has to have multiple TRACE and corresponding YAXIS sections (see Multiple Trace Ad Hoc Trends).


Trends Guide - Mandatory Values (Using TrendSpec to Produce Ad Hoc Trends)

Mandatory Values

The Section Identifiers that are nested within the TREND section identifier have to each contain a mandatory value. The TRACE section has to contain two mandatory values. The syntax for each mandatory identifier value merely comprises the required value; the syntax for a string mandatory value comprises the required string, enclosed in single straight quotation marks, ' '.

For more information on mandatory values, see:

  • TRACE Mandatory Values
  • SOURCE Mandatory Value
  • XAXIS Mandatory Value
  • YAXIS Mandatory Value.

If required, you can optionally include further values after the mandatory values (see Optional Values). In each case, the mandatory value(s) have to be specified before any optional value(s). The syntax for optional values differs to that of the mandatory values. The exact syntax varies, depending on the type of optional value (see Optional Value Types and Assignments).

Mandatory and optional values that comprise strings or expressions that reference items in the ClearSCADA database are case sensitive. Section and other identifiers are case insensitive.


Trends Guide - TRACE Mandatory Values (Using TrendSpec to Produce Ad Hoc Trends)

TRACE Mandatory Values

The TRACE section within a TrendSpec definition has to contain two mandatory values, <Data Mode> and <Y-Axis Name>.

You should specify the <Data Mode> before the <Y-Axis Name> and separate the two entries with a comma.

TRACE Mandatory Values

Mandatory Value

Type

Comments

<Data Mode>

Identifier value

Use to define the type of data that the trace displays.

Specify one of these values:

Current, RawHistoric, or ProcessedHistoric

(For information about the type of data that each option represents, see Add a Trace to a Trend.)

Example:

Current
(for a trace that displays current data)

Only specify an option other than Current if Historic is enabled for the database item that is the source of the trace (for points, see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration; for accumulators, see Tabs on Accumulator Forms in the ClearSCADA Guide to Core Configuration).

A Trace can only have multiple sources if an option other than RawHistoric is specified (see Multiple Source Traces).

The <Data Mode> mandatory value is trace independent. As such, the traces on a multiple-trace ad hoc Trend can be assigned different <Data Mode> values to each other.

<Y-Axis Name>

String

Use to identify the y-axis that is associated with the trace.

The <Y-Axis Name> is used internally within the TrendSpec definition to link a trace to its respective y-axis. As such, the <Y-Axis Name> in the TRACE section of a definition has to be identical to the <Y-Axis Name> in the corresponding YAXIS section (see YAXIS Mandatory Value).

Example:

‘Sensor Value’
(for a y-axis that indicates a sensor’s value)

If required, you can specify one or more TRACE Optional Values after the above mandatory values in a TrendSpec definition.


Trends Guide - SOURCE Mandatory Value (Using TrendSpec to Produce Ad Hoc Trends)

SOURCE Mandatory Value

The SOURCE section has to reside within the TRACE section in a TrendSpec definition (see Basic TrendSpec Structure). The SOURCE section has to have one mandatory value, <Source Name>.

SOURCE Mandatory Values

Mandatory Value

Type

Comments

<Source Name>

String

Use to define the origin of the trace’s data.

Example:

‘Zone3.Point 3.Historic’
(For an ad hoc Trend that displays historic data for the point named ‘Point 3’. The point resides in the Group ‘Zone3’.)

The <Source Name> is case sensitive.

The <Source Name> is used internally within the TrendSpec definition, to provide the name of the source’s origin. The <Source Name> is not displayed in the Trend window. To display a label (name) for the source in the Key at the bottom of the Trend window, include either the Label or LabelExpr optional value in the TRACE section of the Trend’s definition (see TRACE Optional Values).

If required, you can specify one or more SOURCE Optional Values after the above mandatory value.

For Multiple Source Traces, the TRACE section has to include a separate SOURCE section per data source.


Trends Guide - XAXIS Mandatory Value (Using TrendSpec to Produce Ad Hoc Trends)

XAXIS Mandatory Value

The XAXIS section in a TrendSpec definition has to have one mandatory value, <X-Axis Mode>.
XAXIS Mandatory Values
Mandatory Value | Type | Comments
<X-Axis Mode> | Identifier value | Use to define the type of time scale used for the x-axis. Specify one of these values: Absolute, RelativeNow, or RelativeLatest. (For information on each type of x-axis mode, see Configure the X-Axis.) Example: RelativeLatest (For an ad hoc Trend that displays data for a time that is relative to the latest value to be plotted on the Trend.)

If required, you can specify one or more XAXIS Optional Values after the above mandatory value.


Trends Guide - YAXIS Mandatory Value (Using TrendSpec to Produce Ad Hoc Trends)

YAXIS Mandatory Value

The YAXIS sections in a TrendSpec definition each require one mandatory value, <Y-Axis Name>.

YAXIS Mandatory Values

Mandatory Value

Type

Comments

<Y-Axis Name>

String

Use to assign a name to the y-axis.

The <Y-Axis Name> is used internally within the TrendSpec definition to associate a trace with its respective y-axis. As such, the <Y-Axis Name> in the TRACE section of a definition has to be identical to the <Y-Axis Name> in the corresponding YAXIS section.

Example:

‘Sensor Value’
(for a y-axis that indicates a sensor’s value)

The <Y-Axis Name> is not displayed in the Trend window. To display a label (name) for the y-axis, include either the Label or LabelExpr optional value in the YAXIS section of the Trend’s definition (see YAXIS Optional Values).

If required, you can specify one or more YAXIS Optional Values after the above mandatory value.

For Multiple Trace Ad Hoc Trends, you need to associate each TRACE section with an appropriate YAXIS section.


Trends Guide - Optional Values (Using TrendSpec to Produce Ad Hoc Trends)

Optional Values

Each of the Section Identifiers in a Trend’s definition can contain optional value(s) in addition to the Mandatory Values.

You only need specify any optional values if they are to differ from the defaults set in ViewX. Trend defaults are set using the Trends tab on the Options window (see Define the Default Settings for New Trends).

Each optional value in a TrendSpec definition has to be defined after the mandatory value(s) in the section to which they relate:

TREND
(
TRACE(<Data Mode>,<Y-axis Name>,
SOURCE (<Source Name>,<SOURCE Optional Values>),
<TRACE Optional Values>),
XAXIS(<X-axis Mode>,<XAXIS Optional Values>),
YAXIS(<Y-axis Name>,<YAXIS Optional Values>),<TREND Optional Values>
)

(You can place TRACE Optional Values before or after the SOURCE section, as long as they appear after the TRACE Mandatory Values. Place TREND Optional Values anywhere within the TREND section, so long as they appear outside of each of the other sections.)

Define each optional value using this basic format:

<Identifier> = <value>

where:

<Identifier> is a reserved word that uniquely identifies a specific property.

<value> is of the appropriate type of value for that particular Identifier.

The exact syntax varies, depending on the type of value that the optional identifier supports (see Optional Value Types and Assignments).

If you specify multiple optional values in any section, separate each entry with a comma.

The tables in the sections that follow this one list the Identifiers that are supported by each section in a Trend’s definition, along with the type of value that each Identifier supports:

  • SOURCE Optional Values
  • TRACE Optional Values
  • XAXIS Optional Values
  • YAXIS Optional Values
  • TREND Optional Values.

You can specify any number and combination of optional values per section in your definition. Remember that you need to you use the same exact spelling for each Identifier’s name.

Any strings or expressions that reference an item in the ClearSCADA database are case sensitive. Section and other identifiers are case insensitive.

For examples that demonstrate how many of these optional values might be used in TrendSpec definitions, see Example Configuration.


Trends Guide - Optional Value Types and Assignments (Using TrendSpec to Produce Ad Hoc Trends)

Optional Value Types and Assignments

You need to assign each Optional Value a value of the appropriate type, using the appropriate syntax. This section explains the syntax that you need to use for each type of value:

  • Boolean
  • DATE
  • Identifier Value
  • Integer
  • Real
  • RGB
  • String
  • Supported FontStyle Identifier and Integer Values
  • Supported AggregateId Values.

The tables in the subsections that follow on from this section indicate the type of value that each optional identifier supports and provide examples of the values that you can specify.

Boolean

Specify a Boolean value in the format:

<Identifier> = <Boolean value>

where <Boolean value> is either:

  • True (indicating that the attribute is enabled or on)

or:

  • False (indicating that the attribute is disabled or off).

Example:

ShowMarkers = True
(to include markers on a TRACE)

DATE

Within TrendSpec, a DATE value has to be enclosed within the code %23. Specify a DATE using this format:

<Identifier> = %23<dd/MM/yyyy HH:mm:ss.SSS>%23

Specify the date in the above order, regardless of the Date Format used on your system. If you omit the HH:mm:ss.SSS time syntax, the time defaults to midnight at the start of the specified date.

Example:

StartTime = %2312/01/2009 09:45:00.000%23
(for the XAXIS interval to start at 09:45am on 12th January 2009)

Identifier Value

A TrendSpec Identifier Value is a string value that is specified without quotation marks, in the format:

<Identifier> = <Identifier value>

Example:

Format = TWENTYFOURHOUR
(for the XAXIS times to use 24-hour clock notation)

For a list of the identifier values that each optional identifier supports, see the tables in the subsections that follow; also see Supported FontStyle Identifier and Integer Values.

Identifier values are case insensitive and cannot include any character spaces.

Integer

Specify an integer in the format:

<Identifier> = <Integer>

Example:

Multiplier = 2.5
(for ClearSCADA to multiply a SOURCE’s raw values by 2.5 and display the resultant values on a trace)

For information on the integer values that you can specify for a FontStyle identifier, see Supported FontStyle Identifier and Integer Values.

Real

Specify a real value in the format:

<Identifier> = <Real>

Example:

MajorTicks = 4
(for a YAXIS to have four major ticks, regardless of the size of the Trend window)

RGB

An RGB color value has to be specified using this format:

<Identifier> = RGB(<red intensity>,<green intensity>,<blue intensity>)

where each color intensity is an integer between 0 and 255 inclusive (with RGB(0,0,0) being black and RGB(255,255,255) being white).

Example:

LineColour = RGB(204,102,0)
(to display a TRACE in light brown)

If required, use the Color window to find the RGB values for the color that you want to specify (see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration).

String

A string has to be enclosed within single straight quotation marks, in the format:

<Identifier> = '<string>'

Any string that references an item in the database is case sensitive.

Where a string is to evaluate as an expression:

  • Any constant reference to a value in the database has to be enclosed within two sets of single straight quotation marks in that expression. This is in addition to the single straight quotation marks that are required due to the identifier value being a string.

Example:

TitleExpr = '''AdHocTrends.Sensor1'''

  • Any OPC tag that is used to obtain a value from the database has to be enclosed within two sets of double straight quotation marks in that expression. This is in addition to the single straight quotation marks that are required due to the identifier value being a string.

Example:

TitleExpr = '""AdHocTrends.Sensor1.Name""'

Any string used in the expression has to be enclosed in two sets of single straight quotation marks.

Any OPC tag or string that references an item in the database is case sensitive.

For more information on the syntax you can use to reference an item in the database, see Syntax of OPC Property Tags in the ClearSCADA Guide to Expressions.

Supported FontStyle Identifier and Integer Values

You can include any of several FontStyle identifiers in a TrendSpec definition, in order to specify different font style(s) to the ViewX defaults. In each case, you can specify the required font style using one of these integer or identifier values:

Supported Identifier Values

FontStyleRegular

FontStyleBold

FontStyleItalic

FontStyleBoldItalic

FontStyleUnderline

FontStyleStrikeout

Example:

TitleFontStyle = FontStyleUnderline

Identifier values are case insensitive and cannot include any character spaces.

Supported Integer Values

0 (equating to FontStyleRegular)

1 (equating to FontStyleBold)

2 (equating to FontStyleItalic)

3 (equating to FontStyleBoldItalic)

4 (equating to FontStyleUnderline)

8 (equating to FontStyleStrikeout)

To specify a combination of the above styles, specify the sum of the integers that, when combined, provide the required style.

Examples:

LabelFontStyle = 3
(for the font assigned to the y-axis label’s text to appear in bold italic (providing that the font assigned to the LabelFont identifier supports such a style))

LabelFontStyle = 7
(with 7 being the sum of the separate integer values 3 + 4 (that is, FontStyleBoldItalic AND FontStyleUnderline), or 1 + 2 + 4 (FontStyleBold AND FontStyleItalic AND FontStyleUnderline))

For a more detailed example that demonstrates how the various FontStyle identifiers might be defined, see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

Supported AggregateId Values

With a trace that displays processed historic data, use the AggregateId identifier to define the algorithm that ClearSCADA uses to process that historic data. TrendSpec’s AggregateId identifier is equivalent to the Algorithm property on pre-configured Trends (see Configure a Trace).

To specify the algorithm that ClearSCADA is to use when processing historic data, you assign the SOURCE’s AggregateId the appropriate long value.

If a TRACE’s Interval identifier is set to a specific time period, you can assign the corresponding SOURCE’s AggregateId any one of a number of long values, including:
Long Value | Algorithm | Long Value | Algorithm
1 | Interpolated | 20 | DurBad
2 | Total | 21 | PerGood
3 | Average | 22 | PerBad
4 | Time Average | 25 | Sum
5 | Count | 26 | 24hAverage
6 | StdDev | 27 | 8hAverage
7 | MinTime | 28 | 1hAverage
8 | Min | 29 | Stepped
9 | MaxTime | 30 | Min Last
10 | Max | 31 | Max Last
11 | Start | 32 | Average Last
12 | End | 33 | Min Interpolated
13 | Delta | 34 | Max Interpolated
17 | Variance | 35 | Average Interpolated
18 | Range | 36 | End
19 | DurGood | --- | ---

If the TRACE’s Interval identifier is set to PerPixel, the long value that you can assign to the SOURCE’s AggregateId is limited to one of the following:
Long Value | Algorithm | Long Value | Algorithm
3 | Average | 32 | Average Last
8 | Min | 33 | Min Interpolated
10 | Max | 34 | Max Interpolated
30 | Min Last | 35 | Average Interpolated
31 | Max Last | --- | ---

Example:

A ‘custom’ ad hoc Trend is to show a trace of processed historic data.

The TrendSpec definition’s TRACE section includes this configuration:

Interval = ‘15M’

The SOURCE section within the TRACE section includes:

AggregateId = 3

This results in the trace showing the mean average value that ClearSCADA retrieved from the data source during each 15-minute interval. (AggregateId = 3 triggers ClearSCADA to calculate the mean average from the raw data values that it retrieved during each resample interval.)


Trends Guide - SOURCE Optional Values (Using TrendSpec to Produce Ad Hoc Trends)

SOURCE Optional Values

Specify any optional SOURCE values after the SOURCE Mandatory Value in a TrendSpec definition. Remember to include a comma at the end of the mandatory value before listing any of these optional values. Include a comma between each optional value’s definition.

The optional SOURCE values are equivalent to the properties that you can specify using the Edit Source window on a Pre-Configured or File Based Trend. For further information on these properties, see Configure a Trace.

The optional values that you can specify within the SOURCE section are:
SOURCE Optional Values
Identifier | Value Type | Comments
XOffset (Only applicable if the TRACE’s <Data Mode> is RawHistoric or ProcessedHistoric.) | Integer or String | Use to define a time offset for the trace. If required, use the XOffset to display source values from a different time period to that indicated by the x-axis. Either specify the XOffset as an integer, whereby the value has to be in seconds Example: XOffset = 300 (for the XOffset to be 300 seconds, or 5 minutes) or as a string, whereby the value has to be specified in the OPC Time Format. Example: XOffset = ‘5M’
Multiplier | Real | Use to define the amount by which ClearSCADA multiplies the data values. The scaled values form the source of the trace. Example: Multiplier = 1.500000 Also see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.
YOffset | Real | Use to define the position of the trace values on the y-axis. Example: YOffset = 0.200000 Also see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.
AggregateId (Only applicable if the TRACE’s <Data Mode> is ProcessedHistoric.) | Long | Use to specify that algorithm that ClearSCADA uses to process the source’s historic data. The values that you can specify vary, depending whether the TRACE’s Interval identifier is set to PerPixel or a specific time period (see Supported AggregateId Values). Example: AggregateId =10 (results in a trace that depicts the maximum value during each resample Interval.)


Trends Guide - TRACE Optional Values (Using TrendSpec to Produce Ad Hoc Trends)

TRACE Optional Values

Specify any optional TRACE values after the TRACE Mandatory Values, and make sure that they are outside of the SOURCE section, but within the TRACE section in a TrendSpec definition. Remember to include a comma before listing any optional values. Include a comma between each optional value’s definition.

Many of the optional TRACE values are equivalent to the properties that you can specify using the Edit Trace window on a Pre-Configured or File Based Trend. For further information on these properties, see Configure a Trace.

The optional values that you can specify within the TRACE section are:

TRACE Optional Values

Identifier

Value Type

Comments

Label

(Use as an alternative to the TRACE LabelExpr identifier.)

String

Use to define the text that identifies the trace in the Trend Key.

Example:

Label = 'Zone1.Sensor1'

Also see Use TrendSpec to Define a Multiple Trace Ad Hoc Trend.

To use an expression to define the value of the trace’s key label, use the TRACE LabelExpr identifier instead of the Label identifier.

LabelExpr

(Use as an alternative to the TRACE Label identifier.)

String

Use to define the text that identifies the trace in the Trend Key.

Example:

LabelExpr = '""Zone2.Reservoir.FullName""'

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

To specify a string, rather than an expression, use the TRACE Label identifier instead of the LabelExpr identifier.

TraceStyle

Identifier value

Use to define the type of trace. Specify one of these values:

TraceLine, TraceStepFirst, TraceStepLast, TraceBarLine, or TraceBarFill.

Example:

TraceStyle = TraceLine

Depending on the chosen TraceStyle, you might also want to specify the BarWidth or LineWidth.

Interval

Integer, string, or Identifier value

Use to specify the amount of time between each value shown on the trace.

If the TRACE’s <Data Mode> is Current, either specify the Interval as an integer, whereby the value has to be in seconds

Example:

Interval = 15

or as a string, whereby the value has to be specified in the OPC Time Format.

Example:

Interval = '15S'

If the TRACE’s <Data Mode> is ProcessedHistoric, you can specify the required Interval using either of the above value types. Alternatively, you can have ClearSCADA dynamically determine the Interval from the time period that is represented by each pixel on the x-axis. To do this, specify the identifier value PerPixel in this format:

Interval = PerPixel

If the TRACE’s <Data Mode> is ProcessedHistoric, use the corresponding SOURCE section’s AggregateId identifier to specify the algorithm that ClearSCADA uses to process the historic data. The trace depicts the resulting value for each resample Interval. Be aware that the AggregateId values are limited when the Interval is set to PerPixel (see Supported AggregateId Values).

BarWidth

(Only applicable if the TraceStyle is TraceBarLine, or TraceBarFill.)

Integer or string

Use to specify the amount of time that each bar represents.

Either specify the BarWidth as an integer, whereby the value has to be in seconds

Example:

BarWidth = 300
(for the BarWidth to be 300 seconds, or 5 minutes)

or as a string, whereby the value has to be specified in the OPC Time Format

Example:

BarWidth = '5M'

The BarWidth should not be greater than the Interval.

GapInterval

(Only applicable if the TraceStyle is TraceLine, TraceStepFirst, or TraceStepLast.)

Integer or string

Use to specify the maximum acceptable amount of time for a gap in the data. If no values were retrieved or calculated for a time period that exceeds this value, the trace will include a gap to indicate the lack of data at that time.

Either specify the GapInterval as an integer, whereby the value has to be in seconds

Example:

GapInterval = 2

or as a string, whereby the value has to be specified in the OPC Time Format

Example:

GapInterval = '2S'

RawOverlay

(Only applicable if the TRACE’s <Data Mode> is ProcessedHistoric.)

Boolean

Use to specify whether raw data markers are displayed on the Trend, in addition to the trace that indicates the processed data.

Example:

RawOverlay = True

Also see Use TrendSpec to Define a Multiple Trace Ad Hoc Trend.

If a trace has multiple sources (see Multiple Source Traces), the RawOverlay has to be set to False.

PointLimit

(Only applicable if the TRACE’s <Data Mode> is RawHistoric.)

Integer

Use to specify the maximum number of values that can be shown on the Trend.

Example:

PointLimit = 2500

ExtendToNow

Boolean

Use to specify whether the trace line is extended from the last reported value to the current time (‘now’).

Example:

ExtendToNow = True

UpdateMode

(Only applicable if the TRACE’s <Data Mode> is Current.)

Identifier value

Use to specify when the trace is updated.

Specify one of these values:

Interval, Change, or IntervalAndChange.

Example:

UpdateMode = Interval

(If a trace has multiple sources (see Multiple Source Traces), the UpdateMode has to be set to Interval.)

System

(Only required on ClearSCADA systems that have Multiple Databases)

String

Use to specify which ClearSCADA database supplies the trace’s source.

Example:

System = 'Main'

A trace’s System identifier has to contain the same value as the corresponding YAXIS StateSystem identifier (see YAXIS Optional Values).

LineColour

RGB

Use to specify the color of the trace line.

Example:

LineColour = RGB(0,0,0)

Also see Use TrendSpec to Define an Ad Hoc Trend’s Colors.

LineStyle

(Only applicable if the TraceStyle is TraceLine, TraceStepFirst, or TraceStepLast.)

Identifier value

Use to specify the appearance of the trace line.

Specify one of these values:

DashSolid, DashDash, DashDot, DashDashDot, or DashDashDotDot.

Example:

LineStyle = DashSolid

Also see Use TrendSpec to Define a Multiple Trace Ad Hoc Trend.

LineWidth

(Only applicable if the TraceStyle is TraceLine, TraceStepFirst, or TraceStepLast.)

Real

Use to specify the thickness of the trace line, in points.

Example:

LineWidth = 0.250000

MarkerLimit

Integer

Use to specify the maximum number of value markers that can be shown on the trace.

Example:

MarkerLimit = 250

MarkerSize

Integer

Use to specify the size of the trace’s value markers. Specify a size from 1 to 5, inclusive.

Example:

MarkerSize = 2

MarkerStyle

Identifier value

Use to specify the appearance of the trace’s value markers. Specify one of these values:

Diamond, Square, or Cross.

Example:

MarkerStyle = Diamond

Also see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.

ShowMarkers

Boolean

Use to specify whether Trend Markers are shown on the trace.

Example:

ShowMarkers = False
(to hide the markers)

ClearSCADA only takes into account the values of any other Marker identifiers if ShowMarkers = True (and in the case of ProcessedHistoric traces, when RawOverlay = True).

ShowTrace

Boolean

Use to specify whether the Trend Trace is shown on an ad hoc Trend.

Example:

ShowTrace = True

ShowAnnotations

(Only applicable if <Data Mode> is RawHistoric or ProcessedHistoric.)

Boolean

Use to specify whether Trend Annotations are shown on the trace.

Example:

ShowAnnotations = True

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

ClearSCADA only takes into account the values of any other Annotation identifiers if ShowAnnotations = True.

AnnotationStyle

(Only applicable if <Data Mode> is RawHistoric or ProcessedHistoric.)

Identifier value

Use to specify the appearance of any annotation markers.

Specify one of these values:

Diamond, Square, or Cross.

Example:

AnnotationStyle = Square

AnnotationSize

(Only applicable if <Data Mode> is RawHistoric or ProcessedHistoric.)

Integer

Use to specify the size of any annotation markers on the trace. Specify a size from 1 to 5, inclusive.

Example:

AnnotationSize = 3


Trends Guide - XAXIS Optional Values (Using TrendSpec to Produce Ad Hoc Trends)

XAXIS Optional Values

Specify any optional XAXIS values after the XAXIS Mandatory Value in a TrendSpec definition. Remember to include a comma at the end of the mandatory value before listing any of these optional values. Include a comma between each optional value’s definition.

Many of the optional XAXIS values are equivalent to the properties that you can specify using the Edit X Axis window on a Pre-Configured or File Based Trend. For further information on these properties, see Configure the X-Axis.

The optional values that you can specify within the XAXIS section are:
XAXIS Optional Values
Identifier | Value Type | Comments
StartTime (Only applicable if the <X-Axis Mode> is set to Absolute.) | DATE | Use to specify the earliest time period that is to be shown on the x-axis when the ad hoc Trend is first displayed. Specify the time and date in this format: StartTime = %23dd/MM/yyyy HH:mm:ss.SSS%23 Example: StartTime = %2321/11/2008 08:30:00.000%23 (Within a TrendSpec definition, a DATE value has to be enclosed within the code %23.)
EndTime (Only applicable if the <X-Axis Mode> is set to Absolute.) | DATE | Use to specify the latest time period that is to be shown on the x-axis when the ad hoc Trend is first displayed. Specify the time and date in this format: StartTime = %23dd/MM/yyyy HH:mm:ss.SSS%23 Example: EndTime = %2322/11/2008 08:30:00.000%23 (Within a TrendSpec definition, a DATE value has to be enclosed within the code %23.)
Offset (Only applicable if the <X-Axis Mode> is set to RelativeNow or RelativeLatest.) | String | Use to specify the earliest time that is displayed on the x-axis, in relation to the current time. You need to Specify a Relative Time in the OPC Relative Time Format. Example: Offset = 'Hour - 3 Hours' (for the x-axis to display an interval that starts 3 hours before the start of the current hour)
Interval (Only applicable if the <X-Axis Mode> is set to RelativeNow or RelativeLatest.) | String | Use to specify the amount of time that is displayed on the x-axis at one time. You need to Specify a Time Period in the OPC Time Format. Example: Interval = '1 Hour' or Interval = ‘1H’ Also see Use TrendSpec to Define a Multiple Trace Ad Hoc Trend.
Format | Identifier value | Use to specify the time format used for the x-axis. Specify one of these values: TwelveHour, or TwentyFourHour. Example: Format = TwentyFourHour (If TwelveHour is specified, the time on the x-axis is appended with AM or PM, as applicable.)
MinorTicks | Integer | Use to specify the number of minor tick indicators that are to appear between the major indicators on the x-axis. Enter a suitable value in the range 1 to 10 inclusive. Example: MinorTicks = 3
Position | Identifier value | Use to specify the position of the x-axis on the ad hoc Trend. Specify one of these values: Top, or Bottom. Example: Position = Bottom Also see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.
Continuous | Boolean | Use to specify whether the time period shown on the x-axis updates, relative to the current time. Example: Continuous = True
ShowGrid | Boolean | Use to specify whether vertical grid lines are shown for the major ticks on the x-axis. Example: ShowGrid = False (Use the YAXIS ShowGrid identifier to specify whether horizontal grid lines are displayed (see YAXIS Optional Values).)
ShowNow | Boolean | Use to specify whether a vertical line that indicates the values for the current time (‘now’) is shown on the Trend. Example: ShowNow = False
Colour | RGB | Use to specify the color of the x-axis. Example: Colour = RGB(0,0,0) Also see Use TrendSpec to Define an Ad Hoc Trend’s Colors.


Trends Guide - YAXIS Optional Values (Using TrendSpec to Produce Ad Hoc Trends)

YAXIS Optional Values

Specify any optional YAXIS values after the YAXIS Mandatory Value in a TrendSpec definition. Remember to include a comma at the end of the mandatory value before listing any of these optional values. Include a comma between each optional value’s definition.

Many of the optional YAXIS values are equivalent to the properties that you can specify using the Edit Y Axis window on a Pre-Configured or File Based Trend. For further information on these properties, see Add a Y-Axis.

The optional values that you can specify within the YAXIS section are:

YAXIS Optional Values

Identifier

Value Type

Comments

Label

(Use as an alternative to the YAXIS LabelExpr identifier.)

String

Use to define the text that identifies the Trend Y-Axis.

Example:

Label = 'Zone1.Motor2.Running'

To use an expression to define the value of the y-axis’ label, use the YAXIS LabelExpr identifier instead of this Label identifier.

LabelExpr

(Use as an alternative to the YAXIS Label identifier.)

String

Use to define the text that identifies the Trend Y-Axis.

Example:

LabelExpr = '""Main:Zone1.Sensor1.AlarmState""'

To specify a string, rather than an expression, use the YAXIS Label identifier instead of this LabelExpr identifier.

LabelPos

Identifier value

Use to specify the position of the y-axis’ label. Specify one of these values:

Top, Centre, or Bottom.

Example:

LabelPos = Top

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

LabelStyle

Identifier value

Use to specify the orientation of the y-axis’ label. Specify one of these values:

Normal, or Rotated.

Example:

LabelStyle = Normal

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

Position

Identifier value

Use to specify the position of the y-axis on the ad hoc Trend. Specify one of these values:

Left, or Right.

Example:

Position = Left

Also see Use TrendSpec to Define a Multiple Trace Ad Hoc Trend.

Visible

Boolean

Use to specify whether the Trend Y-Axis is shown on an ad hoc Trend. (You have to include one YAXIS section per trace in your TrendSpec definition, regardless of whether that y-axis is shown on the Trend.)

Example:

Visible = True

The value of this identifier is ignored if the TREND section includes a ShowYAxes identifier.

Format

(Only applicable when the YAXIS section of a definition does not include a States identifier.)

String

Use to specify the format of the values that are displayed on the y-axis.

To display a specific number of digits, enter a 0 for each digit that is required. The digit will still be displayed, even if it is zero.

To suppress a digit when it is zero, enter the code %23 for each such digit. The digit will only be displayed when it is non-zero.

Example:

Format = '0.0%23%23%23%23'

(To display a single decimal place, regardless of whether it is zero. Further decimal places (up to five in total) are displayed only when they are non-zero.)

For other syntax supported by the Format identifier, see Numeric Syntax in the ClearSCADA Guide to Core Configuration.

ScaleType

Identifier value

Use to specify how the y-axis is scaled. Specify one of these values:

Manual, Range, or Automatic.

Example:

ScaleType = Range

If the ScaleType is Manual, include the Minimum and Maximum identifiers in the YAXIS section of the definition.

If the YAXIS section includes the States identifier, set the ScaleType to Range.

Logarithmic

Boolean

Use to specify whether the y-axis is scaled using a base-10 logarithm.

Example:

Logarithmic = False

Minimum

(Only applicable if the ScaleType is Manual.)

Real

Use to specify the lowest value that is to appear on the y-axis.

Example:

Minimum = 0.000000

Also see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.

Maximum

(Only applicable if the ScaleType is Manual.)

Real

Use to specify the largest value that is to appear on the y-axis.

Example:

Maximum = 100.000000

Also see Use TrendSpec to Produce a Trace that has Multiple Data Sources.

Invert

Boolean

Use to specify whether the y-axis’ values are to be inverted.

Example:

Invert = False

Also see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.

AutoTicks

(Only applicable when the YAXIS section of a definition does not include a States identifier.)

Boolean

Use to specify whether ClearSCADA is to allocate the y-axis’ major and minor ticks automatically.

Example:

AutoTicks = True

If AutoTicks = False, include the MajorTicks and MinorTicks identifiers in the YAXIS section of the definition.

MajorTicks

(Only applicable if AutoTicks is False and no States identifier is specified.)

Integer

Use to specify the number of major tick indicators that are to be shown on the y-axis. Specify a suitable whole number in the range 2 to 100 inclusive.

Example:

MajorTicks = 11

MinorTicks

(Only applicable if AutoTicks is False and no States identifier is specified.)

Integer

Use to specify the number of minor tick indicators that are to be shown in between the y-axis’ MajorTicks. Specify a whole number between 0 and 10 inclusive.

Example:

MinorTicks = 1

States

String

Use the States identifier to associate the data source’s state descriptions with the ticks on the y-axis.

Example:

States = 'Eastern Region.Switch2'

ShowGrid

Boolean

Use to specify whether horizontal grid lines are shown for the ticks on the y-axis.

Example:

ShowGrid = False

Also see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.

(Use the XAXIS ShowGrid identifier to specify whether vertical grid lines are displayed (see XAXIS Optional Values).)

Colour

RGB

Use to specify the color of the y-axis.

Example:

Colour = RGB(0,0,0)

Also see Use TrendSpec to Define an Ad Hoc Trend’s Colors.

StateSystem

(Only required if the States identifier is specified and there are Multiple Databases)

String

Use to specify the ClearSCADA database from which the States identifier’s source is obtained.

Example:

StateSystem = 'Main'


Trends Guide - TREND Optional Values (Using TrendSpec to Produce Ad Hoc Trends)

TREND Optional Values

Place any optional TREND values outside of any other sections, but within the TREND section in a TrendSpec definition. Remember to include a comma before listing any of these optional values. Include a comma between each optional value’s definition.

Many of the optional TREND values are equivalent to the properties that you can specify using the Trend Properties window on a Pre-Configured or File Based Trend. For further information on these properties, see Configure the Display Settings for a Trend.

The optional values that you can specify within the TREND section are:

TREND Optional Values

Identifier

Value Type

Comments

Title

(Use as an alternative to the TitleExpr identifier.)

String

Use to define the Trend’s title.

Example:

Title = 'Sensor1'

Also see Use TrendSpec to Define a Multiple Trace Ad Hoc Trend.

To use an expression to define the value of the Trend’s title, use the TitleExpr identifier instead of this Title identifier.

ShowYAxes

Boolean

Use to specify whether any y-axes are shown on the ad hoc Trend. (You need to include a YAXIS section per trace in your TrendSpec definition, regardless of the value of the ShowYAxes identifier.)

Example:

ShowYAxes = True

If an ad hoc Trend is multi-trace and y-axes only need displaying for some of those traces, omit the TREND ShowYAxes identifier and include individual YAXIS Visible identifiers in your TrendSpec definition.

ShowXAxis

Boolean

Use to specify whether the x-axis is shown on the ad hoc Trend. (You need to include an XAXIS section in your TrendSpec definition, regardless of the value of the ShowXAxis identifier.)

Example:

ShowXAxis = True

ShowTitle

Boolean

Use to specify whether the Trend Title is shown on the ad hoc Trend.

Example:

ShowTitle = True

ClearSCADA only takes into account the values of any other Title identifiers if ShowTitle = True.

ShowKey

Boolean

Use to specify whether the Trend Key is shown on the ad hoc Trend.

Example:

ShowKey = False

TitleExpr

(Use as an alternative to the Title identifier.)

String

Use to define the Trend’s title.

Example:

TitleExpr = '''AdHocTrends.Sensor1'''

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

To specify a string, rather than an expression, use the Title identifier instead of this TitleExpr identifier.

AlarmLimitLabelPos

Identifier value

Use to specify the position of the alarm limit labels.

Specify one of these values:

LimitLabelNone, LimitLabelAboveLeft, LimitLabelAboveRight, LimitLabelOverLeft, LimitLabelOverRight, LimitLabelLeft, or LimitLabelRight

Example:

AlarmLimitLabelPos = LIMITLABELABOVERIGHT

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

TitleColour

RGB

Use to specify the color that is assigned to the Trend’s title.

Example:

TitleColour = RGB(0,0,0)

Also see Use TrendSpec to Define an Ad Hoc Trend’s Colors.

TitleFont

String

Use to specify the font used for the Trend’s title.

Example:

TitleFont = 'Tahoma'

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

TitleFontHeight

Integer

Use to specify the height of the font used for the Trend’s title.

Example:

TitleFontHeight = 8

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

TitleFontStyle

Identifier value or Integer

Use to specify the attributes assigned to the Title’s text. For information on the values that you can specify, see Supported FontStyle Identifier and Integer Values.

Example:

TitleFontStyle = FontStyleBold

or

TitleFontStyle = 1

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

MainFont

String

Use to specify the font used for the text that is shown in the main body of the Trend window.

Example:

MainFont = 'Tahoma'

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

MainFontHeight

Integer

Use to specify the height of the font used for the Trend’s body text.

Example:

MainFontHeight = 8

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

MainFontStyle

Identifier value or Integer

Use to specify the attributes assigned to the Trend’s body text. For information on the values that you can specify, see Supported FontStyle Identifier and Integer Values.

Example:

MainFontStyle = FontStyleRegular

or

MainFontStyle = 0

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

LabelFont

String

Use to specify the font used for the y-axes’ label.

Example:

LabelFont = 'Tahoma'

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

LabelFontHeight

Integer

Use to specify the height of the font used for the y-axes’ label.

Example:

LabelFontHeight = 8

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

LabelFontStyle

Identifier value or Integer

Use to specify the attributes assigned to the y-axes’ label’s text. For information on the values that you can specify, see Supported FontStyle Identifier and Integer Values.

Example:

LabelFontStyle = FontStyleBoldItalic

or

LabelFontStyle = 3

Also see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

BackgroundColour

RGB

Use to specify the color used for the ad hoc Trend’s background.

Example:

BackgroundColour = RGB(236,233,216)

Also see Use TrendSpec to Define an Ad Hoc Trend’s Colors.


Trends Guide - Multiple Trace Ad Hoc Trends (Using TrendSpec to Produce Ad Hoc Trends)

Multiple Trace Ad Hoc Trends

If required, you can include multiple Traces on an ad hoc Trend. With a multiple trace Trend, each Trace has a different source. This is useful for comparing the data of several points or master station accumulators.

When multiple traces are supported, the TrendSpec definition typically has this basic structure:

TREND
(
TRACE(<Data Mode>,<Y-axis1 Name>,SOURCE (<Source1 Name>)),
TRACE(<Data Mode>,<Y-axis2 Name>,SOURCE (<Source2 Name>)),...,
TRACE(<Data Mode>,<Y-axisn Name>,SOURCE (<Sourcen Name>)),
XAXIS(<X-axis Mode>),YAXIS(<Y-axis1 Name>), YAXIS(<Y-axis2 Name>),...,
YAXIS(<Y-axisn Name>))
)

If the TrendSpec definition is to include Optional Values in addition to the Mandatory Values shown above, the definition typically has this structure:

TREND
(
TRACE(<Data Mode>,<Y-axis1 Name>,
SOURCE (<Source1 Name>,<SOURCE1 Optional Values>),
<TRACE1 Optional Values>),
TRACE(<Data Mode>,<Y-axis2 Name>,
SOURCE (<Source2 Name>,<SOURCE2 Optional Values>),
<TRACE2 Optional Values>),...,
TRACE(<Data Mode>,<Y-axisn Name>,
SOURCE (<Sourcen Name>,<SOURCEn Optional Values>),
<TRACEn Optional Values>),
XAXIS(<X-axis Mode>,<XAXIS Optional Values>),
YAXIS(<Y-axis1 Name>,<YAXIS1 Optional Values>),
YAXIS(<Y-axis2 Name>,<YAXIS2 Optional Values>),...,
YAXIS(<Y-axisn Name>,<YAXISn Optional Values>),<TREND Optional Values>
)

You will probably want to include optional values, for example, to specify a different color for each trace and corresponding y-axis, to reposition a y-axis, or to set some y-axes so that they are not visible on the Trend. For an example that demonstrates this, see Use TrendSpec to Define a Multiple Trace Ad Hoc Trend.

In some situations, multiple TRACE sections can be assigned the same YAXIS section. You can use such a structure to avoid including multiple YAXIS sections that would contain identical configuration, apart from the <Y-axis Name>. For an example that demonstrates this, see Use a ‘Standard’ Ad hoc Trend as the Basis for a ‘Custom’ TrendSpec Definition.


Trends Guide - Multiple Source Traces (Using TrendSpec to Produce Ad Hoc Trends)

Multiple Source Traces

With a Pre-Configured or File Based Trend, you can optionally use the Edit Trace window to Configure Multiple Data Sources for a Trace.

With an ad hoc Trend, you use TrendSpec to define the data source(s) (or origins) of each trace.

A trace’s value comprises the sum of the value(s) of its origin(s). Hence, if the trace has two origins, its value comprises the sum of those two values. If an ad hoc Trend’s trace has multiple origins, you need to include a separate SOURCE section for each origin within the TRACE’s section:

TREND
(
TRACE(<Data Mode>,<Y-axis Name>,
SOURCE (<Source1 Name>,<SOURCE1 Optional Values>),
SOURCE (<Source2 Name>,<SOURCE2 Optional Values>),...,
SOURCE (<Sourcen Name>,<SOURCEn Optional Values>),
<TRACE Optional Values>),
XAXIS(<X-axis Mode>,<XAXIS Optional Values>),
YAXIS(<Y-axis Name>,<YAXIS Optional Values>),<TREND Optional Values>
)

There are restrictions that limit whether a trace can have multiple sources (see Rules for Traces that have Multiple Sources).

For an example that demonstrates how TrendSpec can be used to define a multiple source trace, see Use TrendSpec to Produce a Trace that has Multiple Data Sources.


Trends Guide - Rules for Traces that have Multiple Sources (Using TrendSpec to Produce Ad Hoc Trends)

Rules for Traces that have Multiple Sources

An ad hoc Trend’s trace can have multiple sources providing that either:

  • The TRACE’s <Data Mode> is set to Current and UpdateMode = Interval.

or:

  • The TRACE’s <Data Mode> is set to ProcessedHistoric and RawOverlay = False. (Be aware that no markers are displayed on a trace when RawOverlay = False.)

A multiple source trace has to obtain its data sources from the same ClearSCADA database. (On ClearSCADA systems that have Multiple Databases, use the TRACE section’s System identifier to specify the ClearSCADA database that provides a trace’s data source(s).)

Further Information

<Date Mode> is one of two TRACE Mandatory Values.

UpdateMode and RawOverlay are both TRACE Optional Values.


Trends Guide - Base a TrendSpec Definition on the Definition of Another Ad Hoc Trend (Using TrendSpec to Produce Ad Hoc Trends)

Base a TrendSpec Definition on the Definition of Another Ad Hoc Trend

You can base a TrendSpec definition on the definition of a ‘standard’ or ‘custom’ ad hoc Trend.

To base a definition on a ‘standard’ ad hoc Trend:

  1. Use the Display Current Trend or Display Historic Trend pick action to display the ad hoc Trend for a suitable point in the database.
  2. If required, ‘customize’ the ad hoc Trend by displaying the Trend in Design mode and editing the Trend’s attributes and/or adding further traces (see Display a Trend in Design Mode).
  3. Select the Edit menu from the ViewX menu bar.
    A context-sensitive menu is displayed.
  4. Select the Copy Shortcut option.
    The ad hoc Trend’s definition is copied to Microsoft® Windows’ temporary storage ‘clipboard’.
  5. Paste the content of the clipboard into a suitable location in ClearSCADA, or into a suitable application, as required.

For instance, you might want to paste the content:

  • Into a Mimic’s Script Editor, to use the content in a script subroutine. The subroutine has to include:
  • The prefix SCX:////Trend/ to specify the location of the ad hoc Trend
  • A script hyperlink function, such as Mimic.Navigate, Mimic.OpenInset, or App.OpenWindow, to specify whether the ad hoc Trend is to be displayed in a separate window or to replace the Mimic display from which it is called.

You need to enclose each line of the TrendSpec definition in double straight quotation marks (" ").

For an example of a script subroutine that includes a TrendSpec definition, see Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes.

For detailed information on scripting, see the ClearSCADA Guide to Scripting. (Scripting is disabled by default—you need to enable scripting on a Mimic before you can access that Mimic’s Script Editor (see Enable the Scripting Feature on a Mimic in the ClearSCADA Guide to Scripting).)

  • Directly onto a Mimic, to produce a hyperlink from the Mimic to the ad hoc Trend.
    Paste the content of the clipboard onto a Mimic, to produce a hyperlink to the ad hoc Trend.

ClearSCADA adds the entry as a text box, which is automatically configured to act as a hyperlink to the ad hoc Trend. The hyperlink is specified as a URL that includes the Trend’s file location and TrendSpec definition.

Edit the text box as required (see Editing a Text Box in the ClearSCADA Guide to Mimics).

  • Into the URL field on the Pick Action Configuration Wizard of a suitable object on a Mimic.

Access the URL as you would any URL on a Mimic: double-click on the Mimic object to display the Properties window, then use the Pick Action button to display the Pick Action Configuration wizard. Specify the type of pick action as a Hyperlink, then paste the content of the clipboard into the URL field (see Using the Pick Action Wizard to Create a Hyperlink in the ClearSCADA Guide to Mimics).

Paste the content of the clipboard into the URL field, to produce a hyperlink to the ad hoc Trend. The hyperlink includes the Trend’s definition.

The definition is automatically prefixed with the text SCX:////Trend/, which specifies the location of the ad hoc Trend.

Edit the TrendSpec definition as required. For instance, you might want the shortcut to display an ad hoc Trend for different point(s), or assign different attributes to some of the Trend’s components.

For an example that demonstrates a TrendSpec URL, see Use TrendSpec to Define an Ad Hoc Trend’s Colors.

  • Into Notepad or another suitable application, for further editing.
    Paste the content of the clipboard into Notepad, and then edit the ad hoc Trend’s definition. The definition is specified using TrendSpec, ClearSCADA’s proprietary Trend specification language.

    For an example that demonstrates this, see Use a ‘Standard’ Ad hoc Trend as the Basis for a ‘Custom’ TrendSpec Definition.


Trends Guide - Troubleshooting - TrendSpec (Using TrendSpec to Produce Ad Hoc Trends)

Troubleshooting - TrendSpec

When using TrendSpec to define the specification of an ad hoc Trend, you should check that the Trend displays as expected.

We suggest that regular checks are made as a TrendSpec definition is built up, or as a definition based on one Trend is changed to that required for another Trend.

NOTE: Some web applications limit the length of the hyperlinks that can be used to access other displays. For this reason, we recommend that you use short TrendSpec definitions if your ‘custom’ ad hoc Trends need to be accessed from a WebX client.

If a TrendSpec definition contains invalid source information, the source’s trace will be omitted from the ad hoc Trend and the source’s entry in the Trend Key will continue to display the message (Fetching Data...).

Check the TrendSpec definition and correct the erroneous source details.

Example:

The message (Fetching Data...) continues to be displayed when a particular ad hoc Trend is viewed. The source item itself has no errors and ClearSCADA is in comms with the device on which the source is located.

If ClearSCADA is unable to fetch the data for a particular source, this might indicate a problem with the definition’s source value(s).

Moving the cursor over the entry in the trace’s Key displays a ToolTip that indicates that ClearSCADA cannot locate the source item at the expected location.

If you look at the Mimic script that is used to display the ad hoc Trend, you can see that it shows that the SOURCE’s <Source Name> identifier value has been specified incorrectly.

This error is not apparent when the Trend is displayed, as both the TREND’s Title identifier and the TRACE’s Label identifier contain the correct values.

In this particular example, the SOURCE’s <Source Name> value is incorrect.

On ClearSCADA systems that have Multiple Databases, also check that the correct System identifier has been specified for the TRACE.

If a TrendSpec definition contains invalid configuration, a message will be displayed when an attempt is made to view that ad hoc Trend:

The message indicates where an error exists in the TrendSpec definition. Correct the error, save the configuration, and check that the ad hoc Trend displays correctly. If a further error is indicated, repeat the process.

Example1:

This message is displayed when an attempt is made to display an ad hoc Trend:

PARSE ERROR: The character '=' was expected after ' 3', ShowGrid = False, RGB' look within the statement 'YAXIS (-> <-)' line 1.

The TrendSpec definition for the Trend is displayed.

The YAXIS section of the definition is found to have the line:

YAXIS('Y Axis 3', ShowGrid = False, RGB(75,0,255)),

This is corrected to:

YAXIS('Y Axis 3', ShowGrid = False, Colour = RGB(75,0,255)),

The configuration is saved.

A second attempt is made to display the ad hoc Trend. The Trend now displays correctly.

Example2:

An error is displayed when an attempt is made to display an ad hoc Trend:

The error indicates that there is a problem with the Label identifier...
...looking at the TrendSpec definition, the Label identifier has mistakenly been placed in the SOURCE section, rather than the TRACE section of the definition.

The error is rectified and the configuration saved. The Trend displays correctly.

If a Mimic script that contains a TrendSpec definition has invalid syntax, an error will be displayed when an attempt is made to save that script. Correct the script syntax and save the configuration.

(If the TrendSpec definition, as opposed to the Mimic script within which the definition resides, has invalid configuration, an error is displayed when an attempt is made to view that Trend (see above).)

Example 3:

A message is displayed when an attempt is made to save some Mimic script that contains a syntax error:

The message indicates the location of the script syntax error...
...which in this example indicates the erroneous line that should start S = S &, rather than S &.

The syntax is corrected and the configuration saved.


Trends Guide - Example Configuration (Using TrendSpec to Produce Ad Hoc Trends)

Example Configuration

This section comprises several examples to demonstrate how TrendSpec might be used to enables users to view data in Trend form. The examples demonstrate how to:

  • Use TrendSpec to Define an Ad Hoc Trend’s Colors
  • Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes
  • Use TrendSpec to Define a Multiple Trace Ad Hoc Trend
  • Use TrendSpec to Produce a Trace that has Multiple Data Sources
  • Enable Users to Specify Which Traces to Include on an Ad Hoc Trend
  • Use a ‘Standard’ Ad hoc Trend as the Basis for a ‘Custom’ TrendSpec Definition.

Remember that if scripting is to be used on a Mimic, the scripting feature needs to be enabled on that Mimic (see Enable the Scripting Feature on a Mimic in the ClearSCADA Guide to Scripting).

For further information on scripting, see the ClearSCADA Guide to Scripting.


Trends Guide - Use TrendSpec to Define an Ad Hoc Trend's Colors (Using TrendSpec to Produce Ad Hoc Trends)

Use TrendSpec to Define an Ad Hoc Trend’s Colors

This example demonstrates how the Optional Values that define the colors of various elements in an ad hoc Trend might be used to customize that Trend.

Example:

The colors used in an ad hoc Trend are to differ from the ViewX defaults. TrendSpec is used to define the Trend’s colors. The Trend is accessed via a button on a Mimic. The button is configured to display the Trend using a hyperlink. The URL for the hyperlink comprises the location of the Trend file, along with its TrendSpec definition:

SCX:////Trend/TREND
(TRACE(ProcessedHistoric,'AxisName',LineColour = RGB(128,0,0),
Label = 'Sensor2', SOURCE ('AdHocTrends.Sensor2.Historic')),
YAXIS('AxisName',Colour = RGB(0,128,0)),
XAXIS(RelativeNow,Colour = RGB(204,102,0)),
TitleColour = RGB(75,0,255),BackgroundColour = RGB(255,225,225))

The TrendSpec definition sets the Trend to use the following colors when it is displayed:

TitleColour = RGB(75,0,255) within the TREND section defines the title’s color.
Colour = RGB(0,128,0) within the YAXIS section defines the color of the y-axis and its values.
LineColour = RGB(128,0,0) within the TRACE section defines the trace and associated data source’s color.
Colour = RGB(204,102,0) within the XAXIS section defines the color of the x-axis and its associated date and time values.
BackgroundColour = RGB(255,225,225) within the TREND section defines the color used for the Trend’s background.

The limits that are shown on the Trend are specific to the point source. They are displayed in red by default. You can change the alarm limit color on a system-wide basis, if required (see Define the Colors for Point Trend Graphs in the ClearSCADA Guide to Server Administration).

The marker colors vary, depending on the quality of the data and whether any annotations exist for any of the source’s values (see Define the Default Settings for New Trends).

For further information on using a TrendSpec definition in a URL, see Base a TrendSpec Definition on the Definition of Another Ad Hoc Trend.

For further information on specifying colors using RGB notation, see RGB.


Trends Guide - Use TrendSpec to Define an Ad Hoc Trend's Text Attributes (Using TrendSpec to Produce Ad Hoc Trends)

Use TrendSpec to Define an Ad Hoc Trend’s Text Attributes

This example demonstrates how the Optional Values that define the text attributes in an ad hoc Trend might be used to customize that Trend.

Example:

The fonts used in an ad hoc Trend are to differ from the ViewX defaults.

TrendSpec is used to define the font properties.

The Trend is accessed via a button on a Mimic. The button is configured to display the Trend using the ClearSCADA script hyperlink function Mimic.Navigate. This function means that when the button is selected, the ad hoc Trend is shown in the current window, replacing the Mimic from which the Trend was selected.

The script for the hyperlink comprises a subroutine that specifies the location of the Trend file, along with its TrendSpec definition:

sub MyAdHocTrend
dim S
S = "SCX:////Trend/"
S = S & "TREND("
S = S & "TRACE(PROCESSEDHISTORIC, 'Y Axis 1',"
S = S & "LabelExpr = '""AdHocTrends.Sensor1.FullName""',"
S = S & "ShowAnnotations = True,"
S = S & "SOURCE('AdHocTrends.Sensor1.Historic')),"
S = S & "XAXIS(RELATIVENOW),"
S = S & "YAXIS('Y Axis 1' , Label = 'Point Value',"
S = S & "LabelPos = CENTRE, LabelStyle = ROTATED),"
S = S & "TitleExpr = '""AdHocTrends.Sensor1.Name""',"
S = S & "ShowTitle = True, ShowKey = True,"
S = S & "AlarmLimitLabelPos = LIMITLABELOVERRIGHT,"
S = S & "TitleFont = 'Arial', TitleFontHeight = 10,"
S = S & "TitleFontStyle = FONTSTYLEBOLD, MainFont = 'Tahoma',"
S = S & "MainFontHeight = 8, MainFontStyle = FONTSTYLEBOLDITALIC,"
S = S & "LabelFont = 'Tahoma', LabelFontHeight = 8, LabelFontStyle = 0)"
Mimic.Navigate( S )
End Sub

The various FontStyle identifiers can be assigned either integer or identifier values (see Supported FontStyle Identifier and Integer Values). As such, LabelFontStyle, for instance, could be assigned either 0 or FontStyleRegular, in order for the label text to use a regular weight font.

The TrendSpec definition sets the text so that when the Trend is displayed, the text is assigned these properties:

The various Label identifiers within the YAXIS section define the position, rotation, and value of the y-axis label. The Label identifiers within the TREND section define the font properties.
The various Main identifiers within the TREND section define the text properties used for the alarm limits and x-axis. AlarmLimitLabelPos = LIMITLABELOVERRIGHT sets the alarm limit labels to appear over the limits themselves.
ShowAnnotations = True within the TRACE section means that any annotations associated with the trace are displayed whenever the cursor is placed over an annotation marker.
The various Title identifiers within the TREND section define the title’s properties. TitleExpr = '""AdHocTrends.Sensor1.Name""' within the TREND section defines the title of the Trend both here and in the Trend window’s header.
LabelExpr = '""AdHocTrends.Sensor1.FullName""' within the TRACE section defines the expression assigned to the text string that indicates the trace’s source in the key. ShowKey = True within the TREND section sets the key to be displayed at the bottom of the Trend window. (If ShowKey = False, the key (comprising the Trace, Type, and Ruler Value columns and their content) would be omitted from the Trend window.)

The properties of the font used in the key and the annotation pop-up are inherited from the Windows® system palette.

Further Information

For detailed information on scripting, see the ClearSCADA Guide to Scripting.

For information on using a hyperlink to display an ad hoc Trend, see Creating a Hyperlink to a Trend or X-Y Plot in the ClearSCADA Guide to Mimics.

For an example that further demonstrates how to associate a button on a Mimic with a script subroutine, see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.


Trends Guide - Use TrendSpec to Define a Multiple Trace Ad Hoc Trend (Using TrendSpec to Produce Ad Hoc Trends)

Use TrendSpec to Define a Multiple Trace Ad Hoc Trend

This example demonstrates how TrendSpec might be used to define a Trend that contains three traces. As with single-trace ad hoc Trends, each TRACE section in the TrendSpec definition for a multi-trace Trend has to have a corresponding YAXIS section, regardless of whether each y-axis is actually displayed on the Trend.

Example:

TrendSpec is used to define an ad hoc Trend that includes three traces. The definition for the Trend is used in a script subroutine, to enable the Trend to be accessed via a button on a Mimic. When selected, the button is configured to run the script and display the Trend. The ClearSCADA script hyperlink function App.OpenWindow sets the Trend to appear in a separate window to the Mimic from which it is accessed.

sub ThreeSensors
dim S
S = "SCX:////Trend/"
S = S & "TREND("
S = S & "TRACE(PROCESSEDHISTORIC, 'Y Axis 1' ,"
S = S & "Label = 'AdHocTrends.Sensor1',"
S = S & "SOURCE('AdHocTrends.Sensor1.Historic'),"
S = S & "TraceStyle = TRACELINE, RawOverlay = False,"
S = S & "LineColour = RGB(0,0,0),"
S = S & "LineStyle = DASHSOLID, LineWidth = 0.000000),"
S = S & "TRACE(PROCESSEDHISTORIC, 'Y Axis 2' ,"
S = S & "Label = 'AdHocTrends.Sensor2',"
S = S & "SOURCE('AdHocTrends.Sensor2.Historic'),"
S = S & "TraceStyle = TRACELINE, RawOverlay = False,"
S = S & "LineColour = RGB(0,128,0),"
S = S & "LineStyle = DASHDASH, LineWidth = 0.250000),"
S = S & "TRACE(PROCESSEDHISTORIC, 'Y Axis 3' ,"
S = S & "Label = 'AdHocTrends.Sensor3',"
S = S & "SOURCE('AdHocTrends.Sensor3.Historic'),"
S = S & "TraceStyle = TRACELINE, RawOverlay = True,"
S = S & "LineColour = RGB(75,0,255),"
S = S & "LineStyle = DASHDOT, LineWidth = 0.500000),"
S = S & "XAXIS(RELATIVELATEST, Interval = '6H'),"
S = S & "YAXIS('Y Axis 1' , Position = LEFT,"
S = S & "Visible = True, Colour = RGB(0,0,0)),"
S = S & "YAXIS('Y Axis 2' , Position = RIGHT,"
S = S & "Visible = True, Colour = RGB(0,128,0)),"
S = S & "YAXIS('Y Axis 3' , Position = RIGHT,"
S = S & "Visible = True, Colour = RGB(75,0,255)),"
S = S & "Title = 'Sensors 1 to 3')"
App.OpenWindow( S )
End Sub

The TrendSpec definition sets this particular ad hoc Trend to display traces of processed historic data from each data source. The RawOverlay identifier in each TRACE section determines whether the raw historic data values are also displayed on the Trend. (The RawOverlay identifier only applies when a TRACE’s <Data Mode> is set to PROCESSEDHISTORIC.)

Various other identifiers in the TrendSpec definition further control the Trend’s appearance:

The various Line identifiers within each TRACE section define the trace attributes, including whether the trace lines are solid, dashes, or dots.
The Position identifier within each YAXIS section controls whether the axes appear on the left or right. As two of the y-axes are configured to appear on the right in this example, ClearSCADA automatically positions them next to each other. (If only some of the axes were required, the Visible identifier could be set to False for those axes that were not required. Alternatively, you might want to consider assigning multiple traces to the same y-axis.)
The various Colour identifiers within the TRACE and YAXIS sections are used to match each trace with its respective axis.

Further Information

Multiple Trace Ad Hoc Trends.

For a further example that demonstrates a multiple trace ad hoc Trend, see Use TrendSpec to Produce a Trace that has Multiple Data Sources.

For detailed information on scripting, see the ClearSCADA Guide to Scripting.

For information on using a hyperlink to display an ad hoc Trend, see Creating a Hyperlink to a Trend or X-Y Plot in the ClearSCADA Guide to Mimics.

For an example that further demonstrates how to associate a button on a Mimic with a script subroutine, see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.

For an example that demonstrates the circumstances under with multiple traces can be assigned the same y-axis, see Use a ‘Standard’ Ad hoc Trend as the Basis for a ‘Custom’ TrendSpec Definition.


Trends Guide - Use TrendSpec to Produce a Trace that has Multiple Data Sources (Using TrendSpec to Produce Ad Hoc Trends)

Use TrendSpec to Produce a Trace that has Multiple Data Sources

This example demonstrates how you can use TrendSpec to define a trace that has more than one origin.

Example:

An ad hoc Trend is produced, which has a main trace that has multiple sources—the trace’s value is the sum of two point values. The Trend also includes the traces of the individual source points, for comparison with the main trace.

The ad hoc Trend has this TrendSpec definition:

TREND(
TRACE(PROCESSEDHISTORIC,'Y Axis 1', Label = 'Sensor1 + Sensor2 Total',
SOURCE('AdHocTrends.Sensor1.Historic'),
SOURCE('AdHocTrends.Sensor2.Historic'),
RawOverlay = False, LineStyle = DASHSOLID),
TRACE(PROCESSEDHISTORIC,'Y Axis 2', Label = 'Sensor1',
SOURCE('AdHocTrends.Sensor1.Historic'),
RawOverlay = True, LineColour = RGB(204,102,0),LineStyle = DASHDASH),
TRACE(PROCESSEDHISTORIC, 'Y Axis 3', Label = 'Sensor2',
SOURCE('AdHocTrends.Sensor2.Historic'),
RawOverlay = True, LineColour = RGB(204,102,0),
LineStyle = DASHDOT, MarkerStyle = Square),
XAXIS(RELATIVENOW, Interval = '24H'),
YAXIS('Y Axis 1'),
YAXIS('Y Axis 2', ScaleType = Manual,Maximum = 200.000000,
Position = Right, Colour = RGB(204,102,0)),
YAXIS('Y Axis 3', ScaleType = Manual, Maximum = 200.000000, Visible = False),
Title = 'Sum of Sensor1 and Sensor2')

In the above definition, the main trace, which is defined first, has two sources. These are specified by the lines:

SOURCE('AdHocTrends.Sensor1.Historic'),
SOURCE('AdHocTrends.Sensor2.Historic')

The main trace’s RawOverlay optional value is set to False to enable the trace to have multiple sources.

The TRACE and YAXIS sections for the individual points, Sensor1 and Sensor 2, are assigned the optional values

LineColour = RGB(204,102,0)

and

Colour = RGB(204,102,0)

to set those traces, labels, and y-axes to appear in brown.

As the TrendSpec definition does not specify otherwise, ClearSCADA automatically assigns a range to the main trace’s y-axis, Y Axis 1. The range is the sum of the full range of the two points that form the associated main trace’s value. As the points each have a range of 0 to 100, ClearSCADA assigns Y Axis 1 the range 0 to 200.

The YAXIS sections for the individual points Sensor 1 and Sensor 2 are assigned the optional values

ScaleType = Manual, Maximum = 200.000000

to scale the axes up to that of the main y-axis, Y Axis 1.

As Y Axis 2 and Y Axis 3 are identical, Y Axis 3 is omitted from the Trend window. This is achieved by including the YAXIS optional value

Visible = False

This results in an ad hoc Trend that has these properties:

The main trace’s value is the sum of two sources, AdHocTrends.Sensor1.Historic, and AdHocTrends.Sensor2.Historic. The TRACE’s RawOverlay optional value is set to False to enable the trace to have multiple sources.
The main trace’s y-axis, Y Axis 1. The y-axis’s range is 0 to 200. This is the sum of the full range of the two points that form the associated main trace’s value.
ScaleType = Manual and Maximum = 200.000000 within the YAXIS sections associated with the individual points, Sensor1 and Sensor2, sets those axes to be scaled up to that of the main y-axis, Y Axis 1.
The individual point sources that are combined to form the value of the main trace.

Further Information

Multiple Source Traces.

Multiple Trace Ad Hoc Trends.


Trends Guide - Enable Users to Specify Which Traces to Include on an Ad Hoc Trend (Using TrendSpec to Produce Ad Hoc Trends)

Enable Users to Specify Which Traces to Include on an Ad Hoc Trend

This example demonstrates how a dialog box might be used to enable users to specify which traces they want to view on an ad hoc Trend.

The example uses ClearSCADA scripting to display the dialog box from a Mimic. Users can select any combination of three check boxes to indicate which trace(s) they want to include on the Trend.

Example:

Users are able to view any combination of up to three traces on an ad hoc Trend. The Trend is displayed via a button on a Mimic. When the button is selected, a custom dialog box is displayed. The dialog box contains three check boxes—one for each trace—and an OK button. Users select the check boxes for the trace(s) that they want to view, then select the OK button to confirm their choice and display the ad hoc Trend, showing the selected trace(s).

A user selects the relevant button on the Mimic...
...to display a custom dialog box.
...to display an ad hoc Trend that includes the traces for the selected sensors.
...then selects the OK button...
The user selects the check boxes for the sensors in which they are interested (in this case, Sensors 2 and 3)...

To enable this functionality, scripting is enabled on the Mimic (see Enable the Scripting Feature on a Mimic in the ClearSCADA Guide to Scripting).

VBScript™ is used to write the required script subroutines. The main subroutine (called ‘mainProg’) includes:

  • The TrendSpec definition for the ad hoc Trend (including a separate TRACE and corresponding YAXIS section for each of the three possible traces)
  • A routine to check which combination of the three check boxes is selected on the dialog box when the OK button is activated
  • The ClearSCADA script hyperlink function Mimic.OpenInset, to display the ad hoc Trend in a separate window that is inset into the Mimic window.

A separate subroutine (called ‘ TraceCheckBoxDlg’) is used to define the custom dialog box, its content and functionality.

sub MainProg
Dim showTrend
Dim traceChecks(3)
Dim sTrendProps
Dim sTraces(3)
Dim sYAxis(3)
Dim sXAxis
Dim sTrend

showTrend = False

sTrend = "SCX:////Trend/TREND("
sTrendProps = "Title = 'Sensor Levels - Zone 2',"
sTrendProps = sTrendProps & "TitleColour = RGB(150,50,50),"
sTrendProps = sTrendProps & "TitleFontStyle = FontStyleBold),"

sXAxis = "XAXIS(RelativeNow, Position=Top,"
sXAxis = sXAxis & "Colour = RGB(255,50,50)),"

sTraces(0) = "TRACE(ProcessedHistoric,'Y Axis 1',"
sTraces(0) = sTraces(0) & "SOURCE('AdHocTrends.Sensor1',XOffset = 15,"
sTraces(0) = sTraces(0) & "YOffset = 12, Multiplier = 3),"
sTraces(0) = sTraces(0) & "Label = 'Sensor1',TraceStyle = TraceLine,"
sTraces(0) = sTraces(0) & "Interval = 400, PointLimit = 20,"
sTraces(0) = sTraces(0) & "ExtendToNow = False,"
sTraces(0) = sTraces(0) & "LineColour = RGB(250,50,50),"
sTraces(0) = sTraces(0) & "LineStyle = DashSolid,"
sTraces(0) = sTraces(0) & "LineWidth = 3, MarkerStyle = Diamond,"
sTraces(0) = sTraces(0) & "MarkerLimit = 250, MarkerSize = 3),"

sYAxis(0) = "YAXIS('Y Axis 1',Label = 'Sensor 1 Value',"
sYAxis(0) = sYAxis(0) & "LabelPos = Centre,LabelStyle = Normal,"
sYAxis(0) = sYAxis(0) & "Position = Left,ScaleType = Range,"
sYAxis(0) = sYAxis(0) & "Invert = true,ShowGrid = True,"
sYAxis(0) = sYAxis(0) & "Format = '%23%23.%23%23%23',"
sYAxis(0) = sYAxis(0) & "Colour = RGB(250,50,50)),"

sTraces(1) = "TRACE(ProcessedHistoric,'Y Axis 2',"
sTraces(1) = sTraces(1) & "SOURCE('AdHocTrends.Sensor2',"
sTraces(1) = sTraces(1) & "XOffset = 15, YOffset = 12, Multiplier = 3),"
sTraces(1) = sTraces(1) & "Label = 'Sensor2',TraceStyle = TraceLine,"
sTraces(1) = sTraces(1) & "Interval = 400, PointLimit = 20,"
sTraces(1) = sTraces(1) & "ExtendToNow = False,"
sTraces(1) = sTraces(1) & "LineColour = RGB(50,50,250),"
sTraces(1) = sTraces(1) & "LineStyle = DashSolid,"
sTraces(1) = sTraces(1) & "LineWidth = 3, MarkerStyle = Cross,"
sTraces(1) = sTraces(1) & "MarkerLimit = 250, MarkerSize = 3),"

sYAxis(1) = "YAXIS('Y Axis 2',Label = 'Sensor 2 Value', LabelPos = Centre,"
sYAxis(1) = sYAxis(1) & "LabelStyle = Normal,Position = Left,"
sYAxis(1) = sYAxis(1) & "ScaleType = Manual,Invert = True,"
sYAxis(1) = sYAxis(1) & "ShowGrid = True,Format = '%23%23.%23%23%23',"
sYAxis(1) = sYAxis(1) & "Colour = RGB(50,50,250),"
sYAxis(1) = sYAxis(1) & "Minimum = 25, Maximum = 230),"

sTraces(2) = "TRACE(ProcessedHistoric,'Y Axis 3',"
sTraces(2) = sTraces(2) & "SOURCE('AdHocTrends.Sensor3',"
sTraces(2) = sTraces(2) & "XOffset = 15, Multiplier = 3),"
sTraces(2) = sTraces(2) & "Label = 'Sensor3',TraceStyle = TraceLine,"
sTraces(2) = sTraces(2) & "Interval = 400, PointLimit = 20,"
sTraces(2) = sTraces(2) & "ExtendToNow = False,"
sTraces(2) = sTraces(2) & "LineColour = RGB(50,175,50),"
sTraces(2) = sTraces(2) & "LineStyle = DashSolid,"
sTraces(2) = sTraces(2) & "LineWidth = 3, MarkerStyle = Square,"
sTraces(2) = sTraces(2) & "MarkerLimit = 250, MarkerSize = 3),"

sYAxis(2) = "YAXIS('Y Axis 3',Label = 'Sensor 3 Value',"
sYAxis(2) = sYAxis(2) & "LabelPos = Centre,LabelStyle = Normal,"
sYAxis(2) = sYAxis(2) & "Position = Right,ScaleType = Range,"
sYAxis(2) = sYAxis(2) & "Invert = True,ShowGrid = True,"
sYAxis(2) = sYAxis(2) & "Format = '%23%23.%23%23%23',"
sYAxis(2) = sYAxis(2) & "Colour = RGB(50,175,50)),"

TraceCheckBoxDlg traceChecks
dim idx
For idx = 0 To 2
If traceChecks(idx) = True Then
sTrend = sTrend & sTraces(idx)
sTrend = sTrend & sYAxis(idx)
showTrend = True
End If
Next
if showTrend = True Then
sTrend = sTrend & sXAxis
sTrend = sTrend & sTrendProps
Mimic.OpenInset( sTrend ),20,20,70,70
End If
End Sub
sub TraceCheckBoxDlg( traceChecks )
Dim OKButton
Form.Init "Select Required Sensors"
Form.AddGroupBox 0,0,50,10,""

Set traceChecks(0) = Form.AddCheckBox(20,2, "Sensor 1")
Set traceChecks(1) = Form.AddCheckBox(20,4, "Sensor 2")
Set traceChecks(2) = Form.AddCheckBox(20,6, "Sensor 3")
Set OKButton = Form.AddPushButton(15,10,"OK")
Form.Show()
If Form.Selection = "OK" Then
End If
End sub

A button configured on the Mimic is used to call the ‘MainProg’ script subroutine. This functionality is enabled using the Pick Action Configuration Wizard (accessed via the Button Properties window):

The Pick Action Configuration Wizard is used to specify that a Script is to run when the Mimic button is selected.
On the Next page of the Wizard...

...the name of the Script subroutine ‘MainProg’ is specified.

The Mimic script enables any combination of three traces to be displayed on the ad hoc Trend. The check boxes that are selected on the custom dialog box determine which traces and associated y-axes are shown on the Trend. The TrendSpec definition used in the script determines the Trend’s properties.

So, if the three check boxes are selected on the dialog box, each of the three traces and y-axes are displayed. The TrendSpec definition sets the Trend’s properties (such as the color and location of the axes):

Whereas if only the Sensor 1 check box is selected, only Sensor1’s trace and y-axis are shown:

With this particular TrendSpec definition, the Multiplier optional value is used to multiply each sensor’s value by 3 before displaying the resultant value on the Trend (each sensor’s original range being 0 to 100). Additionally, with two of the sensors, the YOffset optional value is used to offset the sensor value by 12 when plotted against the corresponding y-axes. ClearSCADA uses these values in conjunction with each y-axis’s ScaleType (and, if applicable, any Minimum and Maximum values) to discover what range it needs to display for each y-axis.

Hence, the y-axis for Sensor3 runs from 0 to 300 (as ScaleType = Range and Multiplier = 3 expands the original 0 to 100 sensor range to three times its original value).

With Sensor2, the y-axis range of 25 to 230 is determined by the YAXIS Optional Values ScaleType = Manual, Minimum = 25 and Maximum = 230.

With Sensor1, the y-axis runs from 12 to 312 (as ScaleType = Range, Multiplier = 3, and YOffset = 12). With this sensor and Sensor2, ClearSCADA multiplies the original sensor values by 3, then increments the results by 12 before plotting the resulting values on the Trend. Hence with Sensor1, the y-axis range is also offset by 12.

As with any TrendSpec definition, ClearSCADA uses the current ViewX defaults for any Optional Values that are not explicitly defined.

Further Information

Add and Configure a Button on a Mimic: see Add a Button to a Mimic in the ClearSCADA Guide to Mimics, and see Editing a Button in the ClearSCADA Guide to Mimics.

Using the Script Configuration page of the Pick Action Configuration Wizard: see Associate a Mimic Script with a Script Pick Action in the ClearSCADA Guide to Scripting.

ClearSCADA-Specific Script Functions: see the ClearSCADA Guide to Scripting.

Using TrendSpec to Produce Ad Hoc Trends.


Trends Guide - Use a 'Standard' Ad hoc Trend as the Basis for a 'Custom' TrendSpec Definition (Using TrendSpec to Produce Ad Hoc Trends)

Use a ‘Standard’ Ad hoc Trend as the Basis for a ‘Custom’ TrendSpec Definition

This example demonstrates how you might use a ‘standard’ ad hoc Trend as the basis for defining a ‘custom’ ad hoc Trend.

Example:

A ‘custom’ ad hoc Trend is required to enable users to display processed historic data for three sensors, named Sensor 11 to Sensor 13. Rather than write a new TrendSpec definition from the beginning, the definition is to be based on that for one of the sensor’s ‘standard’ ad hoc Trends.

The Display Historic Trend pick action is used to display Sensor 11’s ‘standard’ historic ad hoc Trend.

The Design button [image] is selected on the File toolbar, to change the ad hoc Trend’s display mode from ‘Run’ to ‘Design’.

Traces for the other sensors are added to the Trend. This is done by selecting each sensor’s entry in the Database Bar, then dragging the selection onto the trace key in the Trend window.

Other traces can be added to a ‘standard’ ad hoc Trend that is displayed in Design mode...
...by dragging the required database entries onto the Trend’s trace key area.

As each entry is dragged into the trace key area, a context sensitive menu is displayed. In each case, the Processed Historic Trace option is selected.

The relevant option is selected to set each new trace to display processed historic data.

This results in the three traces being displayed on the ad hoc Trend:

From the ViewX menu bar’s Edit menu, the Copy Shortcut option is used to paste the ad hoc Trend’s definition into the clipboard.

The content of the clipboard is then pasted into Notepad.

The content is adjusted as required. In this particular case, line breaks are used to separate the various sections of the ad hoc Trend’s definition:

Minor modifications are made to the definition. For instance, the Label identifier for the first trace is replaced with an appropriate LabelExpr expression. Similarly, the Trend’s TitleExpr identifier is replaced with a Title identifier. (The TitleExpr derives its value from the ad hoc Trend’s original data source—the sensor from which the Trend was originally accessed.)

Although the ad hoc Trend’s definition contains three TRACE sections, it only contains two YAXIS sections. This is because two of the sensors, Sensor 11 and Sensor 13, have the same point value range (0 to 100) and can therefore be assigned the same y-axis (‘Y Axis 1’). Sensor 12 has a different point value range (0 to 120), so is assigned a different y-axis for that range. To make this association clearer, a Colour identifier is added to the YAXIS section for ‘Y Axis 2’. The Colour identifier is allocated the same color as that used for Sensor 12’s trace.

The ‘custom’ ad hoc Trend is to be accessed via a button on a Mimic. Script is to be used to display the Trend whenever the button is selected.

Scripting is enabled on the relevant Mimic (see Enable the Scripting Feature on a Mimic in the ClearSCADA Guide to Scripting).

The basic script structure is entered into the Mimic’s Script Editor. The ad hoc Trend’s definition is then pasted from Notepad into the script subroutine.

The Mimic is saved.

Users can display the ‘custom’ ad hoc Trend at any time, by selecting the relevant button on the Mimic.

...to display the ‘custom’ ad hoc Trend.
Users select the button on the Mimic...

Further Information

Add a Trace to a Trend.

For an example that demonstrates how to assign a script subroutine to a button on a Mimic, see Enable Users to Specify Which Traces to Include on an Ad Hoc Trend.

Using TrendSpec to Produce Ad Hoc Trends.


Trends Guide - Using Trends

Using Trends

Trends allow you to view the data from one or more database items in a graphical format. They are particularly useful for comparing the values of database points over a specific amount of time.

Trends have two modes: Run mode and Design mode. To configure a Trend, you need to display it in Design mode (see Configuring Trends). Run Mode is the operational mode, where operators can use the various Trend display tools and navigation features to view and compare data over time.

In the following sections, we explain how to access, navigate and operate Trends in Run mode:

  • Display a Trend in Run Mode
  • Zooming In and Out on a Trend
  • Display the Full Scale on a Y-Axis
  • View Earlier or Later Values on a Trend
  • View the Values for a Specific Time
  • Display the Latest Data Values on a Trend
  • Display the Default Time Scale on a Trend
  • Hide and Show Markers
  • Hide and Show a Trace
  • Hide and Show Annotations
  • Hide and Show the Key
  • Hide and Show the Title
  • Hide and Show the Grid Lines
  • Hide and Show the Axes
  • Hide and Show the Alarm Limits
  • Show the Current Time on a Trend
  • Insert an Annotation
  • View Information about All Annotations on a Trace
  • Modify an Annotation
  • Delete an Annotation
  • Use the Ruler
  • Display Continuous Data
  • Insert a Value on a Historic Trend
  • Modify a Value on a Historic Trend
  • Delete a Value from a Historic Trend
  • Validate Historic Trend Data
  • Copy Trend Data to the Clipboard
  • Print a Trend.


Trends Guide - Display a Trend in Run Mode (Using Trends)

Display a Trend in Run Mode

Operator level users (users that operate the system rather than configure it) need to use Trends in Run mode. When a Trend is displayed in Run mode, users can access the navigation features and use them to view and compare the data on the Trend.

On a ViewX client, security permissions and menu options determine whether you display Trends in Run mode or Design mode.

On a WebX client, you can only display Trends in Run mode.

In the following sections, we explain how to display the different types of Trend in Run mode:

  • Display a Pre-Configured Trend in Run Mode
  • Display an Ad Hoc Trend in Run Mode
  • Display a File Based Trend in Run Mode.

If your User account provides access to Favorites, you can use the Favorites menu or bar to display any Trends that you have previously added to your Favorites list. For more information, see Access and Display your Favorites in the ClearSCADA Guide to ViewX and WebX Clients.


Trends Guide - Display a Pre-Configured Trend in Run Mode (Using Trends)

Display a Pre-Configured Trend in Run Mode

Trends that are stored as items in the database are referred to as user created Trends or pre-configured Trends. They are added to the database by a user with the Configure permission and are configured to have the required settings.

Operator level users can access pre-configured Trends and display them in Run mode. They can then use the navigation and other operator-level features to view and compare the data on the Trend.

To display a pre-configured Trend in Run mode on a ViewX client:

  1. Log on to ViewX via a valid User account.
  2. Display the Database Bar. (For more information, see the ClearSCADA Guide to ViewX and WebX Clients).
  3. Expand the Database Bar tree structure until you can see the Trend you want to display.
  4. Right-click on the Trend database item, then select the Display option to display the Trend in Run mode.

Alternatively, you can display the Trend in Design mode and then use the Design mode button on the File toolbar to switch the Trend to Run mode. Depending on the configuration of your User account, you may also be able to display a Trend in Run mode by double-clicking on the Trend in the Database Bar.

If you want to display a Trend that is stored in your Operator Document Store:

  1. Select the Operator Document Store button on the Operate toolbar, or select the View menu then select the Explorer Bar menu, then select the Operator Documents option to display your Operator Document Store.
  2. Expand the hierarchy to reveal the Trends that are stored in your Operator Document Store.
  3. Right-click on the Trend database item, then select the Display option to display the Trend in Run mode.

You may also be able to display a pre-configured Trend from a Mimic, if a suitably configured Mimic exists on your system. A Mimic might, for example, include an embedded Trend or contain a button or hyperlink that allows you to display a Trend.

Further Information

Display a Pre-Configured Trend in Run Mode on a WebX Client: see View and Action Trends on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


Trends Guide - Display an Ad Hoc Trend in Run Mode (Using Trends)

Display an Ad Hoc Trend in Run Mode

‘Standard’ Ad Hoc Trends are Trends that are generated on demand. They are not stored as items in the database or as files. You can display an ad hoc Trend for any database point (you can also display historic ad hoc Trends for points that have historic logging enabled in their configuration).

Operator level users can access ‘standard’ ad hoc Trends and display them in Run mode. They can then use the navigation and other operator-level features to view and compare the data on the Trend.

To display a ‘standard’ ad hoc Trend in Run mode on a ViewX client:

  1. Log on to ViewX via a valid User account.
  2. Display the Database Bar. (For more information, see the ClearSCADA Guide to ViewX and WebX Clients).
  3. Expand the Database Bar tree structure until you can see the point or master station accumulator for which you want to display an ad hoc Trend.
  4. Right-click on the point or accumulator item.
    A context sensitive menu is displayed.
  5. To display a Trend of the point or accumulator’s current data, select the Display Current Trend option.

To display a Trend of the point or accumulator’s historic data (if historic data is available), select the Display Historic Trend option.

NOTE: The Display Historic Trend option is only available if historic logging is enabled in the configuration for the point or accumulator (for points, see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration; for accumulators, see Tabs on Accumulator Forms in the ClearSCADA Guide to Core Configuration).

The Trend is displayed. If the Trend plots current data, it will show values from the time that the Trend was displayed.

Alternatively, display a suitable List on a ViewX or WebX Client. Right-click on the relevant point or accumulator entry on the List and select the Display Current Trend or the Display Historic Trend option.

You may also be able to display a ‘standard’ ad hoc Trend from a Mimic, if a suitably configured Mimic exists on your system. For example, by selecting a hyperlink on a Mimic, or by selecting an object that is configured to display a context-sensitive menu, from which the Display Current Trend or Display Historic Trend options can be selected.

If required, users with the relevant permissions can add ‘custom’ ad hoc Trends to ClearSCADA. You typically display a ‘custom’ ad hoc Trend by selecting a button or hyperlink on a Mimic.

Further Information

Display a ‘Standard’ ad hoc Trend in Run Mode on a WebX Client: see View and Action Trends on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.

‘Custom’ ad hoc Trends: see Using TrendSpec to Produce Ad Hoc Trends.

Use the OPC Data Bar to display status attributes on a Trend: see Working with the OPC Data Bar in the ClearSCADA Guide to Core Configuration.

Use the OPC Historic Data Bar to display a Historic Trend: see Working with the OPC Historic Data Bar in the ClearSCADA Guide to Core Configuration.


Trends Guide - Display a File Based Trend in Run Mode (Using Trends)

Display a File Based Trend in Run Mode

File based Trends are Trends that are saved externally as files. They can be saved on any PC or suitable storage device.

Operator level users can access file based Trends and display them in Run mode. They can then use the navigation and other operator-level features to view and compare the data on the Trend. You can only display File Based Trends on ViewX clients.

To display a file based Trend in Run mode on a ViewX client:

  1. Log on to ViewX via a valid User account.
  2. Select the File menu, then select the Open option to display a browse window.
  3. Use the browse window to locate the Trend file that you want to display. Trend files have a .trn suffix.
  4. Select the Trend file in the browse window, then select the OK button.
    The Trend file is displayed. Depending on the settings in your User account, the Trend may be opened in Design mode or Run mode. If the Trend is displayed in Design mode, simply deselect the Design mode button on the toolbar, or select the View menu then deselect the Design option to toggle the Trend back to Run mode.


Trends Guide - Zooming In and Out on a Trend (Using Trends)

Zooming In and Out on a Trend

Like Mimics, Trends have Zoom tools that allow you to zoom in and zoom out on the Trend display. However, whereas the zoom tools on a Mimic make the Mimic objects appear larger or smaller, the zoom tools on a Trend alter the amount of time shown on the x-axis or the range of values shown on a y-axis.

By zooming in on a trace or an x-axis, you decrease the amount of time shown on the x-axis and so you can view the differences in trace values more closely. If you zoom out on a trace or x-axis, the x-axis shows more time and so more values are shown on the Trend (but in less detail).

If you zoom in on a y-axis, you decrease the range of values shown on the y-axis and so the Trend displays a more focused view of a smaller range of values. If you zoom out on a y-axis, you increase the range and so the trace on the Trend can show a wider range of values.

The following sections explain how to zoom in on an x-axis, trace, and y-axis:

  • Zoom In on a Trend
  • Zoom Out on a Trend.


Trends Guide - Zoom In on a Trend (Using Trends)

Zoom In on a Trend

To zoom in on a Trend’s trace(s) or x-axis either:

  1. Display a Trend in Run Mode.
  2. Either:
  • Select the Zoom In button on the Navigate toolbar.
    The Trend is magnified so that the x-axis shows a shorter time range.

Or:

  • Press the F7 function key.
    The Trend is magnified so that the x-axis shows a shorter time range.

Or:

  • Select the View menu, then select the Zoom In option.
    The Trend is magnified so that the x-axis shows a shorter time range.

Or:

  1. Select the Zoom Box on the Navigate toolbar.
    The Zoom Box is activated.
  2. Use the cursor to draw a zoom box over the area of the trace that you want to magnify.
    The Trend is magnified so that the x-axis shows a shorter time range.

Or:

  • Position the cursor over the x-axis or main display area of the Trend then roll the mouse wheel forward (this is only available if your mouse has a wheel).
    The Trend is magnified so that the x-axis shows a shorter time range.

Or:

  • Right-click on the x-axis or main display area of the Trend to display a context sensitive menu, then select the Zoom In option.
    The Trend is magnified so that the x-axis shows a shorter time range.

To zoom in on a y-axis:

  1. Display a Trend in Run Mode.
  2. Either:
  • Right-click on the y-axis to display a context sensitive menu, then select the Zoom In option.
    The y-axis is magnified so that it shows a smaller range of values.

Or:

  1. Select the Zoom Box on the Navigate toolbar.
    The Zoom Box is activated.
  2. Use the cursor to draw a zoom box over the y-axis that you want to magnify.
    The y-axis is magnified so that it shows a smaller range of values.

Or:

  • Position the cursor over the y-axis, then roll the mouse wheel forward (this is only available if your mouse has a wheel).
    The y-axis is magnified so that it shows a smaller range of values.


Trends Guide - Zoom Out on a Trend (Using Trends)

Zoom Out on a Trend

To zoom out on a Trend’s trace(s) or x-axis either:

  1. Display a Trend in Run Mode.
  2. Either:
  • Select the Zoom Out button on the Navigate toolbar.
    The Trend is magnified so that the x-axis shows a longer time range.

Or:

  • Press the F8 function key.
    The Trend is magnified so that the x-axis shows a longer time range.

Or:

  • Select the View menu, then select the Zoom Out option.
    The Trend is magnified so that the x-axis shows a longer time range.

Or:

  • Position the cursor over the x-axis or main display area of the Trend then roll the mouse wheel backwards (this is only available if your mouse has a wheel).
    The Trend is magnified so that the x-axis shows a longer time range.

Or:

  • Right-click on the x-axis or main display area of the Trend to display a context sensitive menu, then select the Zoom Out option.
    The Trend is magnified so that the x-axis shows a longer time range.

To zoom out on a y-axis:

  1. Display a Trend in Run Mode.
  2. Either:
  • Right-click on the y-axis to display a context sensitive menu, then select the Zoom Out option.
    The y-axis is magnified so that it shows a wider range of values.

Or:

  • Position the cursor over the y-axis, then roll the mouse wheel backwards (this is only available if your mouse has a wheel).
    The y-axis is magnified so that it shows a wider range of values.


Trends Guide - Display the Full Scale on a Y-Axis (Using Trends)

Display the Full Scale on a Y-Axis

If you have changed the zoom of the y-axis of a Trend, you can use the Full Scale option to redisplay the entire y-axis scale.

To display the full scale on a y-axis:

  1. Right-click on the y-axis.
    A context sensitive menu is displayed.
  2. Select Full Scale.
    The Trend will display the entire y-axis.


Trends Guide - View Earlier or Later Values on a Trend (Using Trends)

View Earlier or Later Values on a Trend

When you display a Trend, it shows a specific amount of time on the x-axis. This amount of time is defined in the configuration of the Trend and is called the interval. You can set the Trend to display data for a different interval. For more information, see:

  • Previous Interval and Next Interval
  • Pan a Trend
  • View the Values for a Specific Time
  • Display the Latest Data Values on a Trend.


Trends Guide - Previous Interval and Next Interval (Using Trends)

Previous Interval and Next Interval

By using the Previous Interval and Next Interval tools, you can force the Trend to display the interval prior to the currently displayed interval or the interval after the currently displayed interval.

To use the Previous Interval and Next Interval tools on a Trend:

  1. Display a Trend in Run Mode.
  2. Either:
  • Select the Previous Interval button or the Next Interval button on the Navigate toolbar.

Or:

  • Select the View menu, then select the Previous Interval option or Next Interval option.

Or:

  • Right-click on the x-axis and select the Previous Interval option or Next Interval option from the context sensitive menu.

Or:

  • Press the F3 function key for the Previous Interval tool or hold down the SHIFT key and press the F3 function key for the Next Interval tool.
  3. Repeat step 2 as often as required.

Example:

A Trend is displayed and it has 1 hour shown on the x-axis. The first time on the x-axis is 09.25 and the last time on the x-axis is 10.25.

The Previous Interval tool is used and the Trend displays the hour prior to the current hour: the x-axis starts at 08.25 and ends at 09:25.

The Previous Interval tool is used again and the Trend displays the hour prior to the currently displayed hour: the x-axis starts at 07.25 and ends at 08.25.

The Next Interval tool is used and the Trend displays the hour after the currently displayed hour: the x-axis starts at 08.25 and ends at 09.25.

The Next Interval tool is used again which causes the x-axis to display the original time scale again (09.25 - 10.25).


Trends Guide - Pan a Trend (Using Trends)

Pan a Trend

You can also use the Pan tool to force the Trend to show data plotted before or after the currently displayed interval. This is useful as it allows you to view data between two set intervals. For example, if the x-axis shows one hour from 09.25 to 10.25, the Previous Interval and Next Interval tools only allow you to view 08.25-09.25 and 10.25-11.25 respectively. By using the Pan tool, you can view any hour’s worth of data, for example, you could pan the Trend so that it displays values for the time period 09.55 to 10.55.

To use the Pan tool on a Trend:

  1. Display a Trend in Run Mode.
  2. Either:
  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select Pan.
    The cursor changes to a hand with a pointing finger [image] —this indicates that Pan mode is active.

Or:

  • Select the View menu, then select the Pan option to activate Pan mode.

Or:

  • Select the Pan button on the Navigate toolbar to activate Pan mode.
  3. Position the cursor over the main display area of the Trend.
  4. Press the left-hand mouse button. Keep the button pressed down.
  5. Drag the Trend to the left until the required time and values are displayed.
  6. Release the left-hand mouse button.
    The Trend pans to the selected time.

NOTE: To turn Pan mode off, repeat step 2 of the procedure above. If Pan mode is already active, selecting the Pan button or option toggles Pan mode to off.


Trends Guide - View the Values for a Specific Time (Using Trends)

View the Values for a Specific Time

You can use the Go To feature to display a specific time on a Trend. For example, you can choose to display the current minute—this causes the x-axis to change so that it only represents one minute (the current minute).

The Go To feature can display a variety of times including:

  • This Week
  • Previous Minute
  • Relative Time
  • Specific Time.

To use the Go To feature to display a preset period of Trend data:

  1. Display a Trend in Run Mode.
  2. Right-click on the x-axis.
    A context sensitive menu is displayed.
  3. Select the Go To option.
    The Go To Time window is displayed.
  4. Use the combo box at the top of the Go To Time window to select one of the following options:
  • Current Minute—The x-axis will represent the start of the current minute to the end of the current minute
  • Previous Minute—The x-axis will represent the start of the previous minute to the end of the previous minute
  • Current Hour—The x-axis will represent the start of the current hour to the end of the current hour
  • Previous Hour—The x-axis will represent the start of the previous hour to the end of the previous hour
  • Today—The x-axis will represent the start of the current day to the end of the current day
  • Yesterday—The x-axis will represent the start of the previous day to the end of the previous day
  • This Week—The x-axis will represent the start of the current week to the end of the current week
  • Last Week—The x-axis will represent the start of the previous week to the end of the previous week
  • This Month—The x-axis will represent the start of the current month to the end of the current month
  • Last Month—The x-axis will represent the start of the previous month to the end of the previous month
  • This Year—The x-axis will represent the start of the current year to the end of the current year
  • Last Year—The x-axis will represent the start of the previous year to the end of the previous year
  • Relative Time—The x-axis will represent a period of time that begins and ends at a time that is relative to the current time. When you select this option, you need to enter an Offset and an Interval (see step 5)
  • Specific Time—The x-axis will represent a specific time period. When you select this option, you need to enter a Time and Interval (see step 6).

If you have selected a predefined amount of time, the other fields on the Go To Time window are grayed out. Proceed to step 7.

If you selected the Relative Time option, proceed to step 5.

If you selected the Specific Time option, proceed to step 6.

  5. Define the Offset and Interval for the Relative Time:
  1. Select the browse button to the right of the Offset field.
    The Configure Offset window is displayed.
  2. Use the Configure Offset window to define the start time for the Trend:
  • Use the combo box at the top of the window to set the start time to a commonly used start time such as Day or Week.
  • Apply additional units of time by selecting the check box for the row that represents the required time units
  • Use the Add/Subtract combo box to define whether the additional time is added to the start time or subtracted from it
  • Enter the amount of additional time in the text entry field.

For example, to set the start time to 1 hour after the start of the current day, select Day in the combo box at the top, then select the check box for the Hours row, select Add, then enter 1 in the Hours text entry field. For more information on configuring an offset, see Offset Window in the ClearSCADA Guide to Core Configuration.

  3. Select the OK button to confirm the time entry and close the Configure Offset window.
  4. Select the browse button to the right of the Interval field.
    The Configure Interval window is displayed.
  5. Use the Configure Interval window to define the total amount of time to be shown on the x-axis.

As with the Configure Offset window, select the check box for the row that represents the type of time units that you want to use, then use the combo box to determine whether the offset is added to the start time (defined by the offset) or subtracted from it, then enter the amount of time units in the text entry field.

For more information on configuring an interval, see Interval Window in the ClearSCADA Guide to Core Configuration.

NOTE: You can only specify an interval that begins after the offset start time.

  6. Select the OK button.
    The Configure Interval window is closed. Proceed to step 7.
  6. Define the Time and Interval for the Specific Time:
  1. Use the Time combo box to select a specific date. When you select the combo box, a calendar is displayed.

Use the arrow buttons at the top of the calendar to switch between the months of the year, and select a date on the calendar grid. The date you select is marked by a red ring. For more information, see Specifying the Required Entry in a Date and Time Field in the ClearSCADA Guide to Core Configuration.

  2. Select the browse button to the right of the Interval field.
    The Configure Interval window is displayed.
  3. Use the Configure Interval window to define the total amount of time to be shown on the x-axis.

Select the check box for the row that represents the type of time units that you want to use, then use the combo box to determine whether the offset is added to the start time (defined by your Time selection) or subtracted from it, then enter the amount of time units in the text entry field. For more information, see Interval Window in the ClearSCADA Guide to Core Configuration.

NOTE: You can only specify an interval that begins after the start time.

  4. Select the OK button.
    The Configure Interval window is closed.
  7. Select the OK button.
    The Go To Time window is closed and the Trend is displayed. The Trend shows the data for the time period you defined.


Trends Guide - Display the Latest Data Values on a Trend (Using Trends)

Display the Latest Data Values on a Trend

The Go To Latest feature causes the Trend’s offset and interval to be adjusted to display the latest actual values (not calculated or interpolated) of the traces.

To use the Go To Latest feature:

  1. Right-click on the x-axis.
    A context sensitive menu is displayed.
  2. Select the Go Latest option.
    The Trend displays the latest values.


Trends Guide - Display the Default Time Scale on a Trend (Using Trends)

Display the Default Time Scale on a Trend

You can reset a Trend so that it shows the time scale and value range that it displayed when you first accessed the Trend. This is useful when you have used the navigation tools and need to revert to the Trend’s original display.

To reset the Trend so that it displays its original time scale and value range:

  1. Right-click on the x-axis.
    A context sensitive menu is displayed.
  2. Select the Revert to Defaults option.
    The Trend is reset so that it shows the same time scale and value range as it displayed when you first accessed the Trend.


Trends Guide - Hide and Show Markers (Using Trends)

Hide and Show Markers

You can define whether the markers are displayed for a specific trace or all traces. Hiding markers is useful when comparing the markers on specific traces—you can hide the markers on all of the traces except those traces in which you are interested. This makes it easier to compare the values as the markers of interest are not obscured by any other markers.

To hide or show all of the markers:

  1. Right-click on the main display area of the Trend.
    A context sensitive menu is displayed.
  2. Select or de-select the Markers option as required.
    The markers are shown or hidden on the selected trace.

To hide or show markers for one trace:

  1. Right-click on the trace name in the Key.
    A context sensitive menu is displayed.
  2. Select the Show option.
    A further menu is displayed.
  3. Enable or disable the Markers option as required.
    The markers are shown or hidden on the selected trace.

NOTE: There is also a Show>All option that allows you to display all traces, markers, annotations and constant alarm limits on a Trend. The Show>None option allows you to hide all traces, markers, annotations and constant alarm limits on a Trend.


Trends Guide - Hide and Show a Trace (Using Trends)

Hide and Show a Trace

The Hide Trace feature allows you to hide a trace so that it is no longer visible on the Trend. This is useful if you are using a Trend that has many traces - by hiding some of the traces, you can de-clutter the Trend so that it is easier to compare data accurately.

To hide or show a trace:

  1. Right-click on the trace name in the key.
    A context sensitive menu is displayed.
  2. Select the Show option.
    A further menu is displayed.
  3. Enable or disable the Trace option as required.
    The trace is hidden or shown on the Trend.

NOTE: There is also a Show>All option that allows you to display all traces, markers, annotations and alarm limits on a Trend. The Show>None option allows you to hide all traces, markers, annotations and constant alarm limits on a Trend.


Trends Guide - Hide and Show Annotations (Using Trends)

Hide and Show Annotations

You can choose to hide annotations from your Trend. This will not display the marker on the trace, or the annotation in the ToolTip for the value.

To hide and show annotations for every trace on the Trend:

  1. Right-click on the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Enable or disable the Show Annotations option to show/hide the annotations as required.
    The annotation marker is shown or hidden. If the annotation is hidden, the value’s ToolTip will no longer display the annotation text.

To hide or show the annotations for an individual trace:

  1. Right-click on the trace in the Key
    A context sensitive menu is displayed.
  2. Select the Show option to display a further menu.
  3. Enable or Disable the Annotations option to show/hide the annotations for the trace as required.

NOTE: When accessing the Show menu for an individual trace, there is also a Show>All option that allows you to display all traces, markers, annotations and constant alarm limits on a Trend. The Show>None option allows you to hide all traces, markers, annotations and constant alarm limits on a Trend.


Trends Guide - Hide and Show the Key (Using Trends)

Hide and Show the Key

You can choose to hide the Key so that the Trend makes maximum use of the display area. This is useful when you only need to view the trace and have no need for the information in the Key (or the options to which it provides access).

To hide and show the Key:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Enable or disable the Show Key option as required.
    The key is shown or hidden depending on whether you enabled or disabled the option.


Trends Guide - Hide and Show the Title (Using Trends)

Hide and Show the Title

You can choose to hide the Title on a Trend. This is useful when you have no need for a description of the Trend’s purpose or the data it contains.

To hide and show the Title:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Enable or disable the Show Title option as required.
    The Title is shown or hidden depending on whether you enabled or disabled the option.


Trends Guide - Hide and Show the Grid Lines (Using Trends)

Hide and Show the Grid Lines

You can display grid lines on the x-axis or the y-axes. The grid lines are a visual indicator that can make it easier to determine the values—you can use the grid lines to line up the values on the trace with the values and times shown on the axes.

The grid feature is especially useful when you are trying to determine the value of parts of a trace that are not positioned near to an axis.

To hide and show the grid lines:

  1. Right-click on the y-axis.
    A context sensitive menu is displayed.
  2. Enable the Show Grid option.
    The horizontal grid lines are displayed.
  3. Repeat step 1 to re-display the context sensitive menu for the y-axis.
  4. Disable the Show Grid option.
    The horizontal grid lines are hidden.
  5. You can show and hide the x-axis grid lines using the same method, except that you have to right-click on the x-axis.


Trends Guide - Hide and Show the Axes (Using Trends)

Hide and Show the Axes

You can choose to hide any of the axes so that the Trend makes more use of the display area.

To hide and show the axes:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Disable the Show X Axis option.
    The x-axis is removed from the Trend.
  3. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  4. Enable the Show X Axis option.
    The Trend redisplays the x-axis.
  5. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  6. Disable the Show Y Axis option.
    If you have multiple y-axes on your Trend, a further context sensitive menu is displayed.

NOTE: You can enable or disable individual y-axes, enable All to display all y-axes, or enable None to display no y-axes.

  7. Enable the None option.
    Each of the Trend’s axes are hidden.
  8. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  9. Disable the Show Y Axis option.
    If you have multiple y-axes on your Trend, a further context sensitive menu is displayed.
  10. Enable the All option.
    The Trend displays all of the y-axes.


Trends Guide - Hide and Show the Alarm Limits (Using Trends)

Hide and Show the Alarm Limits

You can use the Show Alarm Limits and Hide Alarm Limits to display or hide the constant alarm limits for an analog point on a Trend. Constant alarm limits are shown as a horizontal dotted line on a Trend and they represent the alarm limits defined for the point in its configuration (such as High High, High, Low, and Low Low).

Constant Alarm Limits
Constant Alarm Limits

Displaying the alarm limits can be useful as it allows you to compare the values plotted on a trace to the alarm limit values that have been configured for the analog point (that the trace represents). Of course, at certain times, you may wish to hide the alarm limits from view, for example, if there are lots of traces on a single Trend, the alarm limits may make it more difficult to view the information on display.

NOTE: If you have associated an analog point with a Time Profile, its alarm limits will vary according to the time of day. These variable alarm limits can be shown on a Trend in the form of a trace and they are not affected by the Show Alarm Limits and Hide Alarm Limits options.

You can choose to show or hide all constant alarm limits on the Trend or show and hide the constant alarm limits on a per-trace basis.

To hide and show all constant alarm limits on a Trend:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Enable or disable the Show Alarm Limits Option.
    The constant alarm limits are shown or hidden on the Trend depending on whether you enabled or disabled the option.

To hide and show the constant alarm limits for a specific trace on a Trend:

  1. Right-click on the relevant Trace in the Key.
    A context sensitive menu is displayed.
  2. Select the Show option to display a further menu, then select the Alarm Limits option to display a second further menu.
    A context sensitive menu is displayed. The options vary, depending on the limits that apply to the item that is the trace’s data source.
  3. Turn the individual limit(s) on or off, as required, or select one of the following options:
  • All—The Trend will show the all alarm limits for the selected trace.
  • None—The Trend will hide the all alarm limits for the selected trace.

The selected alarm limits are displayed on the Trend.

NOTE: If the Show All Alarm Limits option is turned on for the Trend, the individual trace settings will appear to have no effect as the Trend is set to display all constant alarm limits and overrides the trace settings. However, if the Show All Alarm Limits option is turned off, you can choose to show the constant alarm limits for each trace individually.

Further Information

Trend Alarm Limits.


Trends Guide - Show the Current Time on a Trend (Using Trends)

Show the Current Time on a Trend

To make a Trend display a line that indicates the current time:

  1. Right-click on the x-axis.
    A context sensitive menu is displayed.
  2. Select the Show ‘Now’ option.
    A line appears on the Trend indicating the current time.


Trends Guide - Insert an Annotation (Using Trends)

Insert an Annotation

An annotation is a text comment that you can insert on any raw or processed historic trace on a Trend. Annotations are indicated on traces by markers in the same way as values are represented by markers. However, annotation markers have their own specific color (defined in the configuration settings on your system). When you position the cursor over an annotation marker, the annotation text is displayed as part of the ToolTip for the marker.

NOTE: If you want to view annotations, the Show Annotations feature has to be enabled on the Trend.

To insert an annotation:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select the Annotations option.
    A further menu is displayed.
  3. Select the Insert option.
    The Insert Annotation window is displayed.
  4. Use the Trace combo box to select the trace with which the annotation will be associated.
  5. Use the Time combo box to select a specific date. When you select the combo box, a calendar is displayed. Use the arrow buttons at the top of the calendar to switch between the months of the year, and select a date from the grid at the bottom of the calendar. The date you select is enclosed in a red ring.

NOTE: An annotation cannot be inserted after the last valid historic value.

  6. Alter the time by highlighting the time values in the Time field and overwriting them with the required times.

NOTE: You can select a time and date within the interval that is currently displayed on the Trend. For example, if the current interval is 09:00 to 10:00 on the 21/05/07, then an annotation can only be inserted within this time.

  7. Enter the text for the annotation in the entry field.
  8. Select the OK button.
    The Insert Annotation window is closed and the annotation is added to the selected trace.

To view the annotation you have just created, position the cursor over the annotation marker for the new annotation.

Further Information

View Information about All Annotations on a Trace

Modify an Annotation

Delete an Annotation.

Raw Historic Data on Trends

Processed Historic Data on Trends


Trends Guide - View Information about All Annotations on a Trace (Using Trends)

View Information about All Annotations on a Trace

You can use the View option to display information about the annotations that have been inserted on a Trend. This is useful when you need to view specific details about a certain annotation, for example, the name of the user that created an annotation.

To display information about the annotations on a trace:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select the Annotations option.
    A further menu is displayed.
  3. Select the View option.
    The Annotations window is displayed.

The Annotations window provides information about the annotations for each trace. You can use the Trace combo box to select a different trace as required.

  4. Select the Close button to close the Annotations window.


Trends Guide - Modify an Annotation (Using Trends)

Modify an Annotation

You can modify any of the annotations that have already been inserted on a Trend. This is useful when additional information needs to be added to an annotation or there is a mistake in the annotation.

To modify an annotation:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select the Annotations option.
    A further menu is displayed.
  3. Select the Modify option.
    The Modify Annotation window is displayed.
  4. Use the Trace combo box to choose the trace that is associated with the annotation that you want to modify.
    The top section of the Modify Annotation window shows a list of the annotations for the selected trace.
  5. Select the annotation you wish to modify from the list.
    The annotation contents are displayed in the lower section.
  6. Make the changes to the annotation as required.
  7. Select the OK button to confirm the modifications and close the Modify Annotations window.

Further Information

Insert an Annotation

View Information about All Annotations on a Trace

Delete an Annotation.


Trends Guide - Delete an Annotation (Using Trends)

Delete an Annotation

To remove an annotation on a Trend:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select the Annotations option.
    A further menu is displayed.
  3. Select the Delete option.
    The Delete Annotation window is displayed.
  4. Use the Trace combo box to choose the trace that is associated with the annotation that you want to delete.
    The Delete Annotation window shows a list of the annotations for the selected trace.
  5. Select the annotation you wish to delete.
  6. Select the OK button to delete the annotation and close the Delete Annotations window.

Further Information

Insert an Annotation

View Information about All Annotations on a Trace

Modify an Annotation.


Trends Guide - Use the Ruler (Using Trends)

Use the Ruler

The Ruler tool allows you to add a ruler line to the Trend. The ruler line can be moved to any position on the Trend and it provides information about the values on the trace(s) at the point where the ruler line intersects the trace line. This is especially useful when comparing the values of multiple traces for a specific time.

To use the Ruler:

  1. Right-click on the main display area of the Trend.
    A context sensitive menu is displayed.
  2. Select the Ruler option.
    The cursor changes shape to indicate that the Ruler tool [image] is active.
  3. Position the cursor over the time for which you want to know the value.
    The ruler line is displayed. It intersects the trace and the x-axis and indicates the time that you have selected.

The time stamp and value of the trace at the time indicated by the ruler is shown in the Ruler Value column on the key.

  4. Right-click on the main display area of the Trend.
    A context sensitive menu is displayed.
  5. De-select the Ruler option.
    The ruler tool is deactivated.

When the Ruler tool is enabled, you can access the Trend Values window. This window shows the value at the ruler position and the 6 values before and after that position. To display the Trend Values window, right-click on the main display area of the Trend and select the Ruler Dialog option from the context sensitive menu.

The Trend Values window provides information about the values at the ruler position and also provides information about the previous six and following six values.


Trends Guide - Display Continuous Data (Using Trends)

Display Continuous Data

You can set a Trend to display the next interval automatically when the current time exceeds the time shown on the x-axis. When you have set the Trend to work in this way, the Trend is updated to show the latest interval so that you can see the current time.

To display continuous data on a Trend:

  1. Right-click on the x-axis.
    A context sensitive menu is displayed.
  2. Enable the Continuous option.

To turn the continuous data feature off, disable the Continuous option.


Trends Guide - Insert a Value on a Historic Trend (Using Trends)

Insert a Value on a Historic Trend

You can add a value to a historic Trend. This can be useful if, for some reason, data was not recorded and you want to add a historic value manually. For example, you may want to add a historic value if there was an instrument fault that meant its values could not be acquired for a short time.

To add a new value to a historic Trend:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select the Insert/Modify Data option.
    The Insert/Modify Data window is displayed.

NOTE: Values that have been inserted or modified are displayed in red.

  3. Use the Trace combo box to select the trace to which you want to add the new value.
  4. Use the Time combo box to define the date and time for the new value. You can choose the date from the context sensitive calendar window and overwrite the existing time value or you can overwrite both values.

NOTE: You can select any time and date that is within the interval that is currently displayed on the Trend.

  5. Use the Value spin box to set the value (or overwrite the value manually).
  6. Select the Insert button.
    The Insert/Modify window is closed, and the new value is added to the trace.

You can view information for the new value by positioning the cursor over the marker for the new value (the marker is blue if your system uses the default color settings). Information about the value is shown in the ToolTip, including the value, time stamp, and the name of the user that inserted the value.

Further Information

Modify a Value on a Historic Trend.

Delete a Value from a Historic Trend.


Trends Guide - Modify a Value on a Historic Trend (Using Trends)

Modify a Value on a Historic Trend

You can change the value of a marker on a historic Trend. This is useful when a value that has been recorded historically for a point is not representative of normal conditions. For example, you may want to modify a historic value if a recorded value is inaccurate due to an equipment malfunction.

To modify a value on a historic Trend:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select the Insert/Modify Data option.
    The Insert/Modify Data window is displayed.
  3. Use the Trace combo box to select the trace to which you want to modify the value.
  4. Select the value that you want to modify in the Time area.
  5. Use the Time combo box to define the date and time. You can choose the date from the context sensitive calendar window and overwrite the existing time value or you can overwrite both values.
  6. Use the Value spin box to set the value (or overwrite the value).
  7. Select the Modify button.
    The Insert/Modify window is closed, and the value is modified in the point’s historic data. This causes the trace to display the modified value.

You can view information for the modified value by positioning the cursor over the marker for the modified value (the marker is blue if your system uses the default color settings). Information about the value is shown in the ToolTip, including the value, time stamp, and the name of the user that modified the value.


Trends Guide - Delete a Value from a Historic Trend (Using Trends)

Delete a Value from a Historic Trend

You can delete a value from a historic Trend. This can be useful if a particular value is inaccurate, or was recorded erroneously, for example during maintenance.

To delete a value from a historic Trend:

  1. Right-click on the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select the Delete Data option.
    The Delete Data window is displayed.
  3. If applicable, use the Trace combo box to select the trace for which you want to delete a value.
  4. From the list of existing values, select the value that you want to delete.

NOTE: Values that have been inserted or modified are displayed in red.

  5. Select the OK button.
    A confirmation dialog box is displayed.
  6. Select Yes to confirm the deletion.
    The Delete Data window is closed and the selected value is deleted from the trace.

An entry is logged in the Event Journal, providing details about the value that has been deleted.

Further Information

Insert a Value on a Historic Trend.

Modify a Value on a Historic Trend.


Trends Guide - Validate Historic Trend Data (Using Trends)

Validate Historic Trend Data

On some ClearSCADA systems, historic data is marked as invalid until it has been checked and verified by a user (see Enable or Disable Manual Historic Data Validation in the ClearSCADA Guide to Server Administration). This can be useful, as it means that historic values have to be checked by a user and confirmed as being accurate before they can become valid.

Typically, ClearSCADA systems are set up to require manual historic data validation when there are known issues with measurement equipment, such as unreliable outstations or sensors.

If your system has been configured to make use of the historic validation feature, you will need to validate the historic values that are shown on a Trend.

To validate historic data on a Trend:

  1. Right-click in the main display area on the Trend.
    A context sensitive menu is displayed.
  2. Select Validate Data.
    The cursor will change to have a tick next to it
  3. Position the cursor next to the area of the trace that you want to validate, then press the left-hand mouse button down. Keep the left-hand mouse button pressed down and drag the cursor over the area that you want to validate.
    A highlight shows the area you have selected.
  4. Release the left mouse button to confirm the selection
    The Validate Data window is shown.
  5. Use the From and To combo boxes to alter the time span covered by highlighted selection as required.
  6. In the Traces list (which is only shown if your Trend has multiple traces with historic data), select the check boxes for those traces that you want to validate. Clear the check boxes for those traces that you do not want to validate.
  7. When you are satisfied with your selection, select the Validate check box and then select the OK button.
    The selected data is validated, the Validate Data window is closed and the trace marker colors change to indicate that the data has been validated.

To de-activate the Validation tool, repeat steps 1 and 2, only this time turn off the Validate Data option.

NOTE: If the values are unsatisfactory and need to be altered, you can change them by using the Modify Value feature (see Modify a Value on a Historic Trend).


Trends Guide - Copy Trend Data to the Clipboard (Using Trends)

Copy Trend Data to the Clipboard

NOTE: This section explains how to copy a Trend’s data to the clipboard. Users with the relevant permissions can also copy a Trend’s definition to the clipboard. For information on copying a Trend’s definition, see Base a TrendSpec Definition on the Definition of Another Ad Hoc Trend.

When you display a Trend, each trace displays values for the amount of time shown on the x-axis. You can copy these values to your PC’s clipboard and then import them into any application that supports pasting from the clipboard, for example Microsoft® Word or Excel.

When using the copy data to clipboard feature, you need to be aware of the following:

  • Copying raw historic data:

When you zoom out on a Trend that shows a raw historic trace, ClearSCADA determines how many values need to be retrieved from the server. If the number of values exceeds the Point Limit that has been configured for the raw historic trace, the raw values are not used on the Trend. Instead, a summary of the values is used.

If a summary of the values is being used, you cannot copy the data to the clipboard.

If a summary is not being used (the number of values required for the interval on the Trend is less than the Point Limit defined in the raw historic trace’s configuration), you can copy the raw data to the clipboard.

  • Copying processed historic data:

Trends that show processed historic data can also show raw data (if the Raw Overlay feature is enabled on the trace). If a Trend is showing a processed historic trace that also shows raw data, ClearSCADA determines how many raw values need to be retrieved from the server. If the number of raw values required exceeds the Marker Limit that has been configured for the processed historic trace, the raw values are not used on the Trend.

If a processed historic trace is not using the Raw Overlay feature, you can copy the processed historic data to the clipboard.

If a processed historic trace is using the Raw Overlay feature and the number of raw values is less than the Marker Limit, you can copy the processed historic values or the raw historic values to the clipboard. If the number of raw values exceeds the Marker Limit, you can only copy the processed historic values to the clipboard.

When you copy historic data from a Trace to the clipboard, it is stored using Tab Separated Values and the following syntax:

Label<tab>Source[;Source]<tab>Mode
Value<tab>Time
Value<tab>Time
Value<tab>Time

...and so on.

Where:

  • Label is the label that is shown in the Key
  • Source is the source of the data
  • Mode is Current, Raw Historic or Processed Historic.

If the copy feature was used to copy multiple trace data to the clipboard, each trace’s data is separated by a blank line, for example:

Label<tab>Source[;Source]<tab>Mode
Value<tab>Time
Value<tab>Time
Value<tab>Time
<Blank Line>
Label<tab>Source[;Source]<tab>Mode
Value<tab>Time
Value<tab>Time
Value<tab>Time

To copy the data for a single trace to the clipboard:

  1. Right-click on the trace in the Trend key.
    A context sensitive menu is displayed.
  2. Select the Copy to Clipboard option.
    If the trace is a raw data trace or a current data trace, the data for the trace is copied to the clipboard (unless the raw data trace is using a summary of the values rather than the actual raw values)
    If the trace is a processed historic trace, a context sensitive menu is displayed.
  3. Select either the Raw Data or Processed Data option.
    The data is copied to the clipboard. The Raw Data option is unavailable if the total number of values required for the interval on the trace exceeds the Marker Limit that has been configured for the trace.

You can now open a Third Party application and paste the ClearSCADA data.

To copy the data for all traces on a Trend to the clipboard:

  • Select the Edit menu, then select the Copy option.
    The data for all of the traces is copied to the clipboard. The data for each trace is separated in the copied data by a blank line.

For the raw historic data traces, the raw data is copied to the clipboard (unless the number of raw values for the trace exceeds the point limit).

For processed historic data traces, the processed historic data is copied to the clipboard. Any raw values that are shown on the processed historic trace are not copied.

Further Information

Raw Historic Data on Trends

Processed Historic Data on Trends


Trends Guide - Print a Trend (Using Trends)

Print a Trend

You can print a Trend that you have displayed in ViewX (see Display a Trend in Run Mode).

To print a Trend:

  1. Display a Trend in Run Mode.
  2. Select the Print button [image] on the Operate toolbar or select the File menu, then the Print option.

NOTE: For information on the ViewX toolbars, see the ClearSCADA Guide to ViewX and WebX Clients.

The Trend is sent to your printer.


X-Y Plots Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


X-Y Plots Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


X-Y Plots Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


X-Y Plots Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


X-Y Plots Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


X-Y Plots Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to use ClearSCADA’s X-Y Plots to compare the historic values of related database points in a graphical format.

For details about the subjects covered in this guide, see Welcome to the X-Y Plots Guide.


X-Y Plots Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for operator-level users and engineers who need to use or configure X-Y Plots (sometimes referred to as ‘scatter graphs’, ‘scatter trends’ or ‘scatter plots’).


X-Y Plots Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


X-Y Plots Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Expressions

ClearSCADA Guide to Security

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration


X-Y Plots Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


X-Y Plots Guide - Welcome to the X-Y Plots Guide

Welcome to the X-Y Plots Guide

Welcome to the ClearSCADA Guide to X-Y Plots. In this Guide, we explain how to configure and use X-Y Plots to compare the relationships between the values of different sources.

This guide provides information on:

  • Understanding X-Y Plots.
  • Configuring X-Y Plots.
  • Using X-Y Plots.


X-Y Plots Guide - Understanding X-Y Plots

Understanding X-Y Plots

X-Y Plots are special types of Trends that allow you to monitor the relationships between historic values. They are sometimes referred to as ‘scatter graphs’ or ‘scatter plots’ and are used to compare the historic values of related points over time.

Common uses for X-Y Plots include:

  • River monitoring—X-Y Plots are used to monitor the relationships between points that monitor water level and points that monitor water flow.
  • Wind farms—X-Y Plots are used to monitor the relationships between points that monitor wind speed and points that monitor power generation.
  • Water industry—X-Y Plots are used to monitor the relationships between points that monitor alum dosing and points that monitor turbidity.

Each X-Y plot consists of:

  • X-Axis—Used to plot the historic values from a specified source (typically a point). The X-Axis shows the range of values for the selected source, and the X component of each marker represents a value within the X-Axis range.
  • Y-Axis—Used to plot the historic values from a specified source (typically a different point to the source of the X-Axis). The Y-Axis shows the range of values for the selected source, and the Y component of each marker represents a value within the Y-Axis range.
  • Time Line—Represents the amount of time shown on the X-Y Plot. This can be increased or decreased as required.
    The Y-Axis represents the range of values for its source.
    The X-Axis represents the range of values for its source.
    The Time Line indicates the amount of time that is shown on the X-Y Plot.

  • Markers—Each marker represents two values plotted for a single time; one value for the X-Axis and one value for the Y-Axis. The X component of the marker represents a value on the X-Axis and the Y component represents a value on the Y-Axis.
    Markers represent a pair of values (one value plotted against the X-Axis, the other against the Y-Axis).


X-Y Plots Guide - Configuring X-Y Plots

Configuring X-Y Plots

Each X-Y Plot is represented in the database by an X-Y Plot database item. These items store the configuration settings for the X-Y Plots that define:

  • The amount of data that is shown on each X-Y Plot
  • The type of data that is shown on each X-Y Plot
  • The time scale covered by each X-Y Plot
  • The appearance of each X-Y Plot.

To create an X-Y Plot item and configure it so that it contains the information you require:

  1. Create an X-Y Plot Item
  2. Display an X-Y Plot in Design Mode
  3. Edit an X-Y Plot Item
  4. Configure the X-Y Plot Database Item Properties.

After configuring an X-Y Plot, you can proceed to view it in Run mode (see Using X-Y Plots).


X-Y Plots Guide - Create an X-Y Plot Item (Configuring X-Y Plots)

Create an X-Y Plot Item

Each X-Y Plot is represented in the database by an X-Y Plot database item. The X-Y Plot database item is used to store the settings that you make when you configure and save the X-Y Plot.

You need to create an X-Y Plot item for each X-Y Plot:

  1. Log on to ViewX via a User Account that has the Configure permission (for the System or Group that is to contain the X-Y Plot database item) and has the Configure Database setting enabled. The Configure permission is allocated via the Security window (see Allocating Security Permissions in the ClearSCADA Guide to Security) and the Configure Database setting is enabled via the User Form (see User Accountsin the ClearSCADA Guide to Security).
  2. In the Database Bar, right click on the system or Group that is to contain the X-Y Plot item, then select the New option, then the Other option, then the X-Y Plot option from the context sensitive menus.
    A new X-Y Plot item is added to the database. It is selected automatically, ready for you to define its name.
  3. Enter a suitable name for the X-Y Plot and then press the Enter key or select another part of the interface to confirm your entry.
    An X-Y Plot named ‘Flow and Level’

When you have created an X-Y Plot item, you can proceed to display it in Design mode (see Display an X-Y Plot in Design Mode).


X-Y Plots Guide - Display an X-Y Plot in Design Mode (Configuring X-Y Plots)

Display an X-Y Plot in Design Mode

To edit an X-Y Plot, you need to display it in Design mode. You will then have access to the X-Y Plot configuration features that allow you to change the appearance of the X-Y Plot, set source data for the axes, adjust the time-line etc.

To display an X-Y Plot in Design Mode:

  1. Log on to ViewX via a User account that has the Configure Documents and Configure Database features enabled (on the User Form) and has the Configure permission for the X-Y Plot item (or its parent Group).
  2. In the Database Bar, locate the X-Y Plot item and then right-click on it.
    A context sensitive menu is displayed.
  3. Select the Edit option.
    The X-Y Plot is displayed in Design mode.

Alternatively, you can display the X-Y Plot in Design mode by:

  • Double-clicking on the X-Y Plot in the Database Bar (if your User account has the Double Click Edits Documents setting enabled).
  • Selecting a link to the X-Y Plot in Design mode from a suitably configured Mimic.
  • Displaying the X-Y Plot in Run mode (see Using X-Y Plots), then selecting the Design mode toolbar button or selecting the Design option in the View menu.

When you have displayed an X-Y Plot in Design mode, you can proceed to edit it (see Edit an X-Y Plot Item).


X-Y Plots Guide - Edit an X-Y Plot Item (Configuring X-Y Plots)

Edit an X-Y Plot Item

When you have created an X-Y Plot database item, you need to edit it so that its axes are associated with source data, time line settings are appropriate etc. You can use the Edit Trace window to edit the X-Axis, Y-Axis, and Time Line as required.

To edit an X-Y Plot item, you have to be logged on via a User account that has the Configure permission for the item (see Allocating Security Permissionsin the ClearSCADA Guide to Security) and is configured to have the Configure Documents and Configure Database settings enabled on the User Form (see User Accounts in the ClearSCADA Guide to Security).

For information on editing the various X-Y Plot features, refer to:

  • Define the Y-Axis Settings
  • Define the X-Axis Settings
  • Define the Time Line Settings
  • Change the Appearance of the X-Y Plot Display.


X-Y Plots Guide - Define the X-Axis Settings (Configuring X-Y Plots)

Define the X-Axis Settings

You can use the Edit Trace window to define the source for the X-Axis and set any algorithms, offsets etc.

To define the X-Axis settings:

  1. Display the X-Y Plot in Design mode (see Display an X-Y Plot in Design Mode).
  2. Either:
  • Right-click just to the right of the Y-Axis or just above the X-Axis to display a context sensitive menu, then select the Edit Trace Settings option.
    The Edit Trace window is displayed.

Or:

  • Select the Edit menu, then select the Trace Settings option to display the Edit Trace window.
  3. Use the X-Axis section of the Edit Trace window to define the X-Axis settings:
  • Source—Define the data source that is used to determine the values that are represented by the X-Axis. You can either enter the location of the data source as a tag or you can select the data source from a list by using the browse button. The X-Axis will represent the range of values for the selected data source and the X component of the marker value will be a value from the selected data source.

For example, if you select an analog point named ‘Flow Monitor 1’ as the data source, the X-Axis will represent the range of possible values for the point (Zero Scale to Full Scale as long as the X-Axis uses Range scaling). The X component of each marker would be a value from the ‘Flow Monitor 1’ point (the value at the specific time shown on the Time Line).

  • Label—Define the text string that represents the trace in the key. The Label entry is an expression and is the full name property of the Source (by default). You can change the Label as required.

For more information on expressions, see Welcome to the Guide to Expressions in the ClearSCADA Guide to Expressions.

  • Offset—Define a time offset for the X-Axis (as required). When used, the offset sets ViewX to plot values from a specified amount of time in the past or future against the X-Axis. This is useful when you need to use the X-Y Plot to examine the relationship between the values of different sources at different times.

For example, if you want to examine the values on an X-Y Plot at 11:50 and the X-Axis offset is set to -10M (10 minutes in the past), the values that are plotted on the X-Axis for 11:50 are actually the values that were reported for the source point at 11:40. So, if there is no offset on the Y-Axis, the marker values for 11:50 will be:

  • X component = The value of the X-Axis source at 11:40 (ten minutes prior to the time at which the value is plotted on the X-Y Plot)
  • Y component = The value of the Y-Axis source at 11:50 (the value at the time it is plotted on the X-Y Plot).
  • Scale—Choose the method of scaling that will be used by the X-Axis. The method of scaling affects how the Y-Axis calculates the range of values that it represents.

Choose from:

  • Manual—You define the lowest value and highest value that can be shown on the X-Axis. You can define the values in the Minimum and Maximum fields in the Scale section.
  • Range—Scales the X-Axis according to the Zero Scale and Full Scale values of the point (as defined in the point’s configuration). This only applies to analog points.
  • Automatic—Scales the X-Axis automatically so that it can display the lowest and highest values that are on display within suitable limits. This means that the X-Axis is updated so that the lowest and highest values can be shown.
  • Algorithm—You have to choose the calculation that is to be used to provide the values for the X-Axis’s source data. The result of the calculation is plotted on the X-Y Plot instead of the actual value that was reported for the source. This is useful when you need to monitor calculated values, such as average values.

The algorithm calculation is performed at a regular interval (which is defined by the Resample Interval configuration setting of the data source). The time period between each resample interval is referred to as the calculation period. The algorithm calculation is performed on the values recorded during the calculation period. For example, if the algorithm is set to Average and the Resample Interval is 15M, the average value for the X-Axis’s source will be calculated every 15 minutes using the values that were reported during the previous 15 minutes.

You can choose from any of the following algorithms:

  • 1hAverage—The average value over an 1 hour period that starts at the beginning of the calculation period (defined by the resample interval).
  • 8hAverage—The average value over an 8 hour period that starts at the beginning of the calculation period (defined by the resample interval).
  • 24hAverage—The average value over an 24 hour period that starts at the beginning of the calculation period (defined by the resample interval).
  • Average—The mean average of the data for the calculation period (defined by the resample interval).
  • Average Interpolated—This is a calculation to estimate a value that is not included in the data for the calculation period (defined by the resample interval). The calculation uses the average value in the calculation period to define the estimated value.
  • Average Last—The average value or the last good average value (if there are no values in the calculation period that is defined by the resample interval).
  • Count—The number of raw values in the data for the calculation period (defined by the resample interval).
  • Delta—The difference between the first value and the last value in the raw data for the calculation period (defined by the resample interval).
  • DurBad—The duration (in seconds) of values marked as bad quality in the raw data for the calculation period (defined by the resample interval).
  • DurGood—The duration (in seconds) of values marked as good quality in the raw data for the calculation period (defined by the resample interval).
  • End—The last value in the data for the calculation period (defined by the resample interval). The timestamp is the time at the end of the sample, which may not correspond with the time at which the last value was reported.
  • Interpolated—This is a calculation to estimate a value that is not included in the data for the calculation period (defined by the resample interval).
  • Max—The highest value in the data for the calculation period (defined by the resample interval).
  • Max Interpolated—This is a calculation to estimate a value that is not included in the data for the calculation period (defined by the resample interval). The calculation uses the maximum value in the calculation period to define the estimated value.
  • Max Last—The maximum value or the last good maximum value (if there are no values in the calculation period that is defined by the resample interval).
  • MaxTime—The highest value in the data for the calculation period (defined by the resample interval) and the time at which it was reported.
  • Min—The lowest value in the data for the calculation period (defined by the resample interval).
  • Min Interpolated—This is a calculation to estimate a value that is not included in the data for the calculation period (defined by the resample interval). The calculation uses the minimum value in the calculation period to define the estimated value.
  • Min Last—The maximum value or the last good minimum value (if there are no values in the calculation period that is defined by the resample interval).
  • MinTime—The lowest value in the data for the calculation period (defined by the resample interval) and the time at which it was reported.
  • PerBad—The percentage of values marked as bad quality in the data for the calculation period (defined by the resample interval). (1=100%).
  • PerGood—The percentage of values marked as good quality in the data for the calculation period (defined by the resample interval). (1=100%).
  • Range—The difference between the maximum value and the minimum value in the data for the calculation period (defined by the resample interval).
  • Start—The first value in the data for the calculation period (defined by the resample interval). The timestamp is the time at the beginning of the sample, which may not correspond with the time at which the first value was reported.
  • StdDev—The standard deviation of the data for the calculation period (defined by the resample interval). Standard deviation is a commonly used measure of spread by statisticians. It allows the percentile rank to be calculated for any value in the data. You will need an understanding of statistics to make use of the information provided by this algorithm.
  • Sum—The total of the data for the calculation period (defined by the resample interval).
  • Time Average—The time-weighted average value for the calculation period (defined by the resample interval). The time-weighted average differs to the average algorithm as it takes into account the amount of time that the source remains at each value in the calculation period.
  • Total—The totalized value (time integral) of the data for the calculation period (defined by the resample interval).
  • Variance—The spread of the values in the data for the calculation period (defined by the resample interval). Like StdDev, Variance is used to measure the extent of the spread of values in the data, and you need an understanding of statistics to make use of the information provided by this algorithm.

Further Information

Resample Interval: see Specify how Often Historic Data is Calculated in the ClearSCADA Guide to Core Configuration.


X-Y Plots Guide - Define the Y-Axis Settings (Configuring X-Y Plots)

Define the Y-Axis Settings

You can use the Edit Trace window to define the source for the Y-Axis and set any algorithms, offsets etc.

To define the Y-Axis settings:

  1. Display the X-Y Plot in Design mode (see Display an X-Y Plot in Design Mode).
  2. Either:
  • Right-click just to the right of the Y-Axis or just above the X-Axis to display a context sensitive menu, then select the Edit Trace Settings option.
    The Edit Trace window is displayed.

Or:

  • Select the Edit menu, then select the Trace Settings option to display the Edit Trace window.
  3. Use the Y-Axis section of the Edit Trace window to define the Y-Axis settings:

The Y-Axis settings work in exactly the same way as the X-Axis settings except that they apply to the Y-Axis instead of the X-Axis. For more information, see Define the X-Axis Settings.


X-Y Plots Guide - Define the Time Line Settings (Configuring X-Y Plots)

Define the Time Line Settings

You can use the Edit Trace window to define the settings for the Time Line on an X-Y Plot. The settings allow you to define:

  • The default start time for the Time Line
  • The amount of time shown on the Time Line by default
  • The maximum number of values that can be shown
  • The shape, color, and size of marker.

To define the Time Line settings:

  1. Display the X-Y Plot in Design mode (see Display an X-Y Plot in Design Mode).
  2. Either:
  • Right-click just to the right of the Y-Axis or just above the X-Axis to display a context sensitive menu, then select the Edit Trace Settings option.
    The Edit Trace window is displayed.

Or:

  • Select the Edit menu, then select the Trace Settings option to display the Edit Trace window.
  3. Use the settings at the bottom of the window to define the Time Line configuration:
  • Start—Define whether the default start of the Time Line is a specific time or is relative to the current time. Choose:
  • Relative Time—The Time Line will begin at a data and time that is relative to the current time. You can use the adjacent field to define the start offset (enter the offset in the OPC Time format or select the browse button and use the Configure Start Offset window to define the start offset). For more information, see see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.
  • Specific Time—The Time Line will begin at a date and time that you specify. Use the adjacent combo-box to select the required start time and date.
  • Duration—Define the amount of time that is shown on the Time Line by default. The amount of time that you define is the interval for the X-Y Plot, for example, if you set the Duration to 1D, the Time Line can only show 1 day’s worth of data at a time. The Duration defines the default amount of time shown on the Time Line—the Time Line can be set to show different intervals by using the Go To option (see Move to a Specific Time on an X-Y Plot).

Enter the amount of time in the OPC Time format or select the browse button and use the Configure Duration window to define the interval. For more information, see see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.

NOTE: You can view the previous day’s data or the next day’s data by using the Previous Interval, Next Interval, and Pan tools (see Moving Between Intervals on an X-Y Plot).

  • Data Points—Define the number of values that will be shown on the X-Y Plot (where a single value consists of an X value and a Y value). You can choose between 1 and 5000.

Increasing the Data Points number will cause the X-Y Plot to display more values and so the X-Y Plot will provide greater detail. While this is often beneficiary, it can also cause slow performance if multiple users are accessing the X-Y Plot simultaneously and are navigating through the available intervals. This is because the server will need to recalculate the values for each interval. Conversely, decreasing the Data Points number will reduce the potential demand on system resources but will also provide less detailed information.

  • Marker—Choose the shape of the markers shown on the X-Y Plot. You can choose from Cross, Diamond, or Square.
    Cross markers
    Diamond markers
    Square markers

  • Color—Choose the color of the markers shown on the X-Y Plot. You can use the color button to select a color from the palette or select the ... color option and use the Color window to create a custom color (see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration).
  • Size—Choose the size of the markers shown on the X-Y Plot. You can choose from 1 to 5 with 1 being the smallest and 5 being the largest.
    Size 1 markers
    Size 3 markers
    Size 5 markers


X-Y Plots Guide - Change the Appearance of the X-Y Plot Display (Configuring X-Y Plots)

Change the Appearance of the X-Y Plot Display

You can use the Trend Properties window to change the appearance of an X-Y Plot. You can change the:

  • Title—You can change the text of the X-Y Plot title and alter its color
  • Fonts—You can change the style and size of the fonts used on the X-Y Plot
  • Background Color—You can change the background color of the X-Y Plot.

The ability to change the appearance of an X-Y Plot is useful for:

  • Presenting detailed X-Y Plot data more clearly
  • Giving descriptive titles to your X-Y Plots
  • Maintaining consistent color schemes throughout your system.

To alter the appearance of the X-Y Plot:

  1. Display the X-Y Plot in Design mode (see Display an X-Y Plot in Design Mode).
  2. Either:
  • Right-click just to the right of the Y-Axis or just above the X-Axis to display a context sensitive menu, then select the Edit Properties option.
    The Trend Properties window is displayed.

Or:

  • Select the Edit menu, then select the Properties option to display the Trend Properties window.
  3. Edit the Title as required:
  • In the Title field, alter the title by editing the text manually, or by using the browse button to select a tag from the database. Even if you enter a Title manually, you have to enclose the title with single quotation marks as it is a tag.
  • Use the Color button to define the color of the Title text. As with other color buttons, you can select a color from the palette or select the ... color option and then use the Color window to create a custom color. For more information, see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration.
  4. Edit the Main Font as required (the Main Font is used on the Time Line and both axes):
  • Font—Select the style of lettering from the list of available fonts.
  • Height—Use the spin-box to increase or decrease the size of the lettering as required.
  • Bold—Select the Bold check box to embolden the Main Font text, or clear the check box to use normal text. Emboldened text appears as darker and thicker text and is often used for emphasis.
  • Italic—Select the Italic check box to italicize the Main Font text, or clear the check box to use normal text. Italicized text appears as leaning text and is often used for emphasis.
  5. Edit the Title Font as required (the Title Font is only used for the Title text). The Font, Height, Bold, and Italic settings work in the same way as the Main Font settings.
  6. Edit the Label Font as required (the Label Font is only used for the text that is shown on the axes). The Font, Height, Bold, and Italic settings work in the same way as the Main Font settings.
  7. Use the Background color button to change the color of the X-Y Plot background as required. As with other color buttons, you can select a color from the palette or select the ... color option and then use the Color window to create a custom color.
    X-Y Plot with the background color set to a custom color (pale yellow) instead of the default gray.

For more information, see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration.


X-Y Plots Guide - Configure the X-Y Plot Database Item Properties (Configuring X-Y Plots)

Configure the X-Y Plot Database Item Properties

Each X-Y Plot database item has a configuration Form that you can use to:

  • Associate the X-Y Plot item with a Help View
  • Include/Exclude the X-Y Plot item from Exclusive Control
  • Associate the X-Y Plot item with up to 4 User Methods.

These configuration features are common to many types of database item. For more information, see Introduction in the ClearSCADA Guide to Core Configuration.


X-Y Plots Guide - Using X-Y Plots

Using X-Y Plots

You can use X-Y Plots to view the relationships between data from different sources on a single graphical display. Each X-Y Plot is configured to provide specific data over a specified time period. By accessing an X-Y Plot in Run mode, you can view the data on the plot, and alter the appearance of the X-Y Plot, including altering the time range that is shown.

In this section, we explain how to access an X-Y Plot in Run mode and use its various navigation features. We also describe how to change some aspects of an X-Y Plot’s appearance (for example, how to hide the X-Axis).

For information on displaying an X-Y Plot in Run mode, using the navigation features and showing and hiding the X-Y Plot’s features, refer to the relevant section:

  • Display an X-Y Plot in Run Mode
  • Zoom In on an X-Y Plot
  • Zoom Out on an X-Y Plot
  • Moving Between Intervals on an X-Y Plot
  • Pan the Axes on an X-Y Plot
  • Size an X-Y Plot According to the Amount of Data
  • Show and Hide the X-Y Plot Grid
  • Show and Hide the Title, Axes, and Time Line.


X-Y Plots Guide - Display an X-Y Plot in Run Mode (Using X-Y Plots)

Display an X-Y Plot in Run Mode

X-Y Plots, like Mimics and Trends, have 2 modes:

  • Design mode—Used by engineers to configure the X-Y Plot.
  • Run mode—Used by operators to view the data provided on the X-Y Plot.

In this section, we are going to explain how to access an X-Y Plot in Run mode. When you have displayed an X-Y Plot in Run mode, you can use it to examine the relationship between the values provided by the two data sources.

To display an X-Y Plot in Run mode:

  1. Log on to ViewX via a User account that has the Operate feature enabled (on the User Form) and has the Read and Browse permissions for the X-Y Plot item (or its parent Group).
  2. In the Database Bar, locate the X-Y Plot item and then right-click on it.
    A context sensitive menu is displayed.
  3. Select the Display option.
    The X-Y Plot is displayed in Run mode.

Alternatively, you can display the X-Y Plot in Run mode by:

  • Selecting a link to the X-Y Plot in Run mode from a suitably configured Mimic.
  • Displaying the X-Y Plot in Design mode (see Display an X-Y Plot in Design Mode), then de-selecting the Design mode toolbar button (or de-selecting the Design option in the View menu).

When you have displayed an X-Y Plot in Run mode, you can proceed to learn about the navigation tools. See:

  • Zoom In on an X-Y Plot
  • Zoom Out on an X-Y Plot
  • Moving Between Intervals on an X-Y Plot.


X-Y Plots Guide - Zoom In on an X-Y Plot (Using X-Y Plots)

Zoom In on an X-Y Plot

To magnify the data on an X-Y Plot so that the data is shown in greater detail:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Zoom In tool is also available when you are configuring the X-Y Plot in Design mode.

  2. Either:
  1. Select the Zoom In button on the Navigate Toolbar.
  2. Repeat as necessary.

Or:

  1. Right-click above the X-Axis and to the right of the Y-Axis to display a context sensitive menu.
  2. Select the Zoom In option.
  3. Repeat as necessary.

Or:

  1. Select the View menu, then select the Zoom In option.
  2. Repeat as necessary.

Or:

  1. Press the F7 function key.
  2. Repeat as necessary.

Or:

  • Roll the mouse wheel forwards until the required level of magnification is shown.

Or:

  1. Select the Zoom Box button on the Navigate Toolbar.
  1. With the left-hand mouse button depressed, draw a Zoom Box over the area you want to magnify, then release the left-hand mouse button.
  2. Repeat as necessary.

NOTE: Zooming in on the X-Y Plot will magnify the X-Y Plot so that you can see its data in greater detail but will also reduce the amount of data you can see on the X-Y Plot display (at that level of magnification).

To decrease the level of magnification, you need to use the Zoom Out tool (see Zoom Out on an X-Y Plot).


X-Y Plots Guide - Zoom Out on an X-Y Plot (Using X-Y Plots)

Zoom Out on an X-Y Plot

To reduce the level of magnification on an X-Y Plot so that more data is shown (but in less detail):

  1. Display an X-Y Plot in Run Mode.

NOTE: The Zoom Out tool is also available when you are configuring the X-Y Plot in Design mode.

  2. Either:
  1. Select the Zoom Out button on the Navigate Toolbar.
  2. Repeat as necessary.

Or:

  1. Right-click above the X-Axis and to the right of the Y-Axis to display a context sensitive menu.
  2. Select the Zoom Out option.
  3. Repeat as necessary.

Or:

  1. Select the View menu, then select the Zoom Out option.
  2. Repeat as necessary.

Or:

  1. Press the F8 function key.
  2. Repeat as necessary.

Or:

  • Roll the mouse wheel backwards until the required level of magnification is shown.

NOTE: Zooming out on the X-Y Plot will reduce the level of magnification on the X-Y Plot so that you can see more data but in less detail.

To increase the level of magnification, you need to use the Zoom In tool (see Zoom In on an X-Y Plot).


X-Y Plots Guide - Moving Between Intervals on an X-Y Plot (Using X-Y Plots)

Moving Between Intervals on an X-Y Plot

Each X-Y Plot has a Time Line that is configured to represent a specific amount of time. The total time that you can see on an X-Y Plot display at one time is referred to as the interval.

When you display an X-Y Plot, it shows the data for a specific interval. By using the following navigation tools, you can set the X-Y Plot to show the data for different time intervals:

  • Next Interval—see Move to the Next Interval on an X-Y Plot
  • Previous Interval—see Move to the Previous Interval on an X-Y Plot
  • Pan—see Pan to a Different Time on an X-Y Plot.
  • Go To—see Move to a Specific Time on an X-Y Plot


X-Y Plots Guide - Move to the Next Interval on an X-Y Plot (Using X-Y Plots)

Move to the Next Interval on an X-Y Plot

If you want to view data that was calculated and plotted for a time after the last time on the currently displayed interval, you need to use the Next Interval tool.

When you use the Next Interval tool, you force the X-Y Plot to display the data for the interval after the currently displayed interval. For example, if the current interval displays the data for 10.00-11.00, the Next Interval tool will set the X-Y Plot to display the data for 11.00-12.00.

To move to the next interval on an X-Y Plot:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Next Interval tool is also available when you are configuring the X-Y Plot in Design mode.

  2. Either:
  • Select the Next Interval button on the Navigate Toolbar.

Or:

  1. Right-click on the Time Line to display a context sensitive menu.
  2. Select the Next Interval option.

Or:

  • Select the View menu, then select the Next Interval option.

Or:

  • Press the F3 function key.

To move back to the previous interval, use the Previous Interval tool (see Move to the Previous Interval on an X-Y Plot).

NOTE: You can also use the Pan tool to move to the next interval (see Pan to a Different Time on an X-Y Plot).


X-Y Plots Guide - Move to the Previous Interval on an X-Y Plot (Using X-Y Plots)

Move to the Previous Interval on an X-Y Plot

If you want to view data that was calculated and plotted for a time before the first time on the currently displayed interval, you need to use the Previous Interval tool.

When you use the Previous Interval tool, you force the X-Y Plot to display the data for the interval before the currently displayed interval. For example, if the current interval displays the data for 10.00-11.00, the Previous Interval tool will set the X-Y Plot to display the data for 09.00-10.00.

To move to the previous interval on an X-Y Plot:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Previous Interval tool is also available when you are configuring the X-Y Plot in Design mode.

  2. Either:
  • Select the Previous Interval button on the Navigate Toolbar.

Or:

  1. Right-click on the Time Line to display a context sensitive menu.
  2. Select the Previous Interval option.

Or:

  • Select the View menu, then select the Previous Interval option.

Or:

  • Press the F3 function key.

To move forward to the next interval, use the Next Interval tool (see Move to the Next Interval on an X-Y Plot).

NOTE: You can also use the Pan tool to move to the previous interval (see Pan to a Different Time on an X-Y Plot).


X-Y Plots Guide - Pan to a Different Time on an X-Y Plot (Using X-Y Plots)

Pan to a Different Time on an X-Y Plot

You can use the Pan tool to ‘drag’ the Time Line on an X-Y Plot display to show any desired interval. The main advantage of the Pan tool over the other navigation tools is that it allows you to move the X-Y Plot freely between intervals; unlike the Next Interval and Previous Interval tools, it does not force the X-Y Plot to show the whole of the previous or next interval.

To use the Pan tool to display a different time on an X-Y Plot:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Pan tool is also available when you are configuring the X-Y Plot in Design mode.

  2. Activate the Pan tool by:
  • Selecting the Pan button on the Navigate toolbar
  • Selecting the View menu, then selecting the Pan option
  • Positioning the cursor over the Time Line, then pressing the mouse wheel button and keeping it held down.

When the Pan tool is activated, the cursor changes to resemble a hand.

  3. Pan the X-Y Plot as follows:
  • If you have used the Navigate toolbar or View menu to activate the Pan tool, position the cursor over the Time Line, then press the left-hand mouse button and keep it held down. With the mouse button depressed, move the cursor left or right to drag the Time Line so that it shows the previous interval or next interval as required. Release the left-hand mouse button to stop panning.
    Use the Pan tool to ‘grab’ the Time Line...
    ...and drag it to a different time.

  • If you have used the mouse wheel button to activate the Pan tool, keep the mouse wheel button pressed down and move the cursor left or right to drag the X-Y Plot to show the previous interval or next interval as required.
  4. When you have finished navigating the X-Y Plot, deactivate the Pan tool by:
  • De-selecting the Pan button on the Navigate toolbar
  • Selecting the View menu, then de-selecting the Pan option
  • Releasing the mouse wheel button (this only applies if you have used the mouse wheel button to activate the Pan tool).

NOTE: You can also use the Pan tool to pan the axes so that they show different values from the range of values (see Pan the Axes on an X-Y Plot).


X-Y Plots Guide - Move to a Specific Time on an X-Y Plot (Using X-Y Plots)

Move to a Specific Time on an X-Y Plot

You can use the Go To option to force the X-Y Plot display to show a specific interval. By using the Go To option, you change the amount of time that is shown on the Time Interval.

To move to a specific time on an X-Y Plot:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Go To option is also available when you are configuring the X-Y Plot in Design mode.

  2. Right-click on the Time Line to display a context sensitive menu.
  3. Select the Go To option to display the Go To Time window.
  4. Use the Go To Time window to specify the time that you want to display on the X-Y Plot:
  1. Use the combo-box to choose a specific time. Choose from:
  • Current Minute—Sets the Time Line to represent 1 minute starting from the beginning of the current minute.
  • Previous Minute—Sets the Time Line to represent 1 minute starting from the beginning of the previous minute.
  • Current Hour—Sets the Time Line to represent 1 hour starting from the beginning of the current hour.
  • Previous Hour—Sets the Time Line to represent 1 hour starting from the beginning of the previous hour.
  • Today—Sets the Time Line to represent 24 hours starting from the beginning of the current day.
  • Yesterday—Sets the Time Line to represent 24 hours starting from the beginning of the previous day.
  • This Week—Sets the Time Line to represent 7 days starting from the beginning of the current week.
  • Last Week—Sets the Time Line to represent 7 days starting from the beginning of the previous week.
  • This Month—Sets the Time Line to represent the current month starting from the beginning of the first day in the month.
  • Last Month—Sets the Time Line to represent the previous month starting from the beginning of the first day in the month.
  • This Year—Sets the Time Line to represent the current year starting from the beginning of the first day in the year.
  • Last Year—Sets the Time Line to represent the previous year starting from the beginning of the first day in the year.
  • Relative Time—Allows you to specify a time that is relative to the current time. When you select this option, the Offset and Interval fields become available for use (described later in this procedure).
  • Specific Time—Allows you to specify an exact date and time. When you select this option, the Time and Interval fields become available for use (described later in this procedure).
  2. Use the Offset combo-box to define the start time for the interval. You can either overwrite the existing entry with a new entry (in the OPC Date and Time Format, see Using OPC Time Formats) or you can select the browse button to display the Configure Offset window.

NOTE: The Offset combo-box is only available when the Relative Time option is selected on the Go To Time window.

You can use the Configure Offset window to define the start time for the interval as follows:

Use to set the offset start time
Each row of settings represents a specific type of time unit (shown at the end of the row, for example, Months).
Use the check box to enable/disable the row, the combo-box to define whether the offset period is applied before or after the offset start time, and the text entry field to define the number of units to be used in the offset period.
Shows the currently configured offset period
Shows the currently selected offset start time

  • Use the From the start of the current combo-box to define the time from which the offset should be measured. You can choose to measure the offset from the start of the current Second, Minute, Hour, Day, Week, Month, or Year.
  • Use each row of settings to define the offset period. Each row consists of a check box that enables/disables the row, an Add/Subtract combo-box that defines whether the offset period is applied before or after the offset start time (Subtract applies the offset period before the offset start time; Add applies the offset period after the offset start time), and a text entry field that allows you to specify the amount of time for the offset period.

For example, if you set the offset start time to be the start of the current Hour, select the check box for the Minutes row, select Subtract in the Minutes row, and then enter 14 in the text entry field for the Minutes row, the set the offset to 14 minutes prior to the start of the current hour. If you had selected Add instead of Subtract, the offset would be 14 minutes after the start of the current hour.

When you have defined the offset start time and offset period, select the OK button to confirm your selection and close the Configure Offset window. Alternatively, you can abort the offset configuration by selecting the Cancel button.

  3. Use the Time combo-box to select a specific date. You can either overwrite the existing entry manually by entering a new time and date or you can select the combo-box to display a calendar.

NOTE: The Time combo-box is only available when the Specific Time option is selected on the Go To Time window.

You can use the calendar to select a specific date. Select the arrow buttons at the top of the calendar to cycle through the months, then select the required date. The selected date is highlighted.

You can also select the name of the month to display a list of the months. To change the year, you can select the year at the top of the calendar to display a spin-box—use the spin-box to locate the required year.

If you use the calendar, you will still need to define the required time by overwriting the time part of the entry in the Time combo-box. You have to use the format:

HH:MM:ss:SSS

Where HH is the hour, MM is the minutes, ss is the seconds, and SSS is the milliseconds (optional).

  4. Use the Interval field to define the amount of time that is to be shown on the Time Line. You can enter the time manually (in the OPC Time format) or you can select the browse button to access the Configure Interval window.

NOTE: The Interval field is only available when the Relative Time or Specific Time options are selected on the Go To Time window.

If you want to use the Configure Interval window, display it by selecting the browse button, then select the check box(es) for the required types of time units. For example, if you want to define an interval in hours, you should select the check box for the row of settings that is labelled ‘Hours’

Select the check box for each type of time units you require. You can select multiple rows if required.

When you have selected the required check boxes, use the Add/Subtract combo-boxes to choose whether the amount of time you define begins after the Offset or Time or before it. Added times are applied after the Offset or Time; subtracted times are applied before the Offset or Time.

In the text entry field, enter the number of time units as required. For example, if you want to set the interval to be 16 hours prior to the selected start Time (defined on the Go To Time window), select the Hours check box, set the combo-box to Subtract, then enter 16 in the text entry field. If you wanted the interval to be 16 hours after the start Time, you would select Add instead of Subtract.

The gray field at the bottom of the Configure Interval window shows the interval setting that will be used.

When you have finished defining the interval, select the OK button to confirm your selection and close the Configure Interval window. Alternatively, select the Cancel button to abort.

  5. Select the OK button on the Go To Time window to confirm your selections and close the Go To Time window (alternatively, you can abort the process by selecting the Cancel button).
    The X-Y Plot displays the data for the selected time automatically.

By using the Go To window to navigate to a specific time on the X-Y Plot, you set the X-Y Plot to override its default settings (the settings that are configured for the X-Y Plot). You can reinstate the default settings at any time by using the Revert to Defaults option (see Reinstate the Default Settings for an X-Y Plot).


X-Y Plots Guide - Reinstate the Default Settings for an X-Y Plot (Using X-Y Plots)

Reinstate the Default Settings for an X-Y Plot

If you have used the Go To feature (see Move to a Specific Time on an X-Y Plot), you may have set the X-Y Plot’s Time Line to display a different amount of time than is specified in the Time Line’s configuration. You can reset the X-Y Plot to reinstate the default settings (defined in the Time Line’s configuration) at any time by using the Revert to Defaults option.

To reinstate the default settings for an X-Y Plot:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Go To option is also available when you are configuring the X-Y Plot in Design mode.

  2. Right-click on the Time Line to display a context sensitive menu.
  3. Select the Revert to Defaults option.
    The X-Y Plot disregards the Go To settings and reinstates the time settings that are defined in the Time Line’s configuration.


X-Y Plots Guide - Pan the Axes on an X-Y Plot (Using X-Y Plots)

Pan the Axes on an X-Y Plot

You can use the Pan tool to ‘drag’ the Y-Axis or X-Axis on an X-Y Plot so that other values in the axes’ range are displayed. For example, if the Y-Axis shows values 1 to 10 on a single display, you can use the Pan tool to drag the Y-Axis so that it shows other values, such as -10 to 0, or 20 to 30 as required.

To use the Pan tool to display a different range of values on the Y-Axis or X-Axis:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Pan tool is also available when you are configuring the X-Y Plot in Design mode.

  2. Activate the Pan tool by:
  • Selecting the Pan button on the Navigate toolbar
  • Selecting the View menu, then selecting the Pan option
  • Positioning the cursor on the Y-Axis, X-Axis, or the display area, then pressing the mouse wheel button and keeping it held down.

When the Pan tool is activated, the cursor changes to resemble a hand.

  3. Pan the X-Y Plot as follows:
  • If you have used the Navigate toolbar or View menu to activate the Pan tool, press the left-hand mouse button and keep it held down. With the mouse button depressed, move the cursor left or right or up or down to drag the axes to show different values. Release the button to stop panning.
    Use the Pan tool to ‘grab’ the display area...

...and drag it to show a different range of values on the Y-Axis and/or the X-Axis.

  • If you have used the mouse wheel button to activate the Pan tool, keep the mouse wheel button pressed down and move the cursor left or right or up or down to drag the axes to show different values.
  4. When you have finished navigating the X-Y Plot, deactivate the Pan tool by:
  • De-selecting the Pan button on the Navigate toolbar
  • Selecting the View menu, then de-selecting the Pan option
  5. Releasing the mouse wheel button (this only applies if you have used the mouse wheel button to activate the Pan tool).


X-Y Plots Guide - Size an X-Y Plot According to the Amount of Data (Using X-Y Plots)

Size an X-Y Plot According to the Amount of Data

You can use the Size to Data option to set ViewX to alter the magnification level of an X-Y Plot automatically. The X-Y Plot will then reduce the level of magnification so that the first value, last value, and all values in between can be seen at once.

To size an X-Y Plot automatically:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Size to Data option is also available when you are configuring the X-Y Plot in Design mode.

  2. Right-click above the X-Axis and to the right of the Y-Axis to display a context sensitive menu.
  3. Select the Size to Data option.
    The X-Y Plot alters its magnification level automatically so that you view the entire range of plotted values on the X-Y Plot


X-Y Plots Guide - Show and Hide the X-Y Plot Grid (Using X-Y Plots)

Show and Hide the X-Y Plot Grid

You can display grid lines on the X-Axis or the Y-Axis of an X-Y Plot. The grid lines are a visual indicator that can make it easier to determine the values—you can use the grid lines to line up the values and times on the X-Y Plot.

The grid feature is especially useful when you are trying to determine the value of markers that are not positioned near to an axis.

To show the grid lines:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Show Grid option is also available when you are configuring the X-Y Plot in Design mode.

  2. Right-click on the Y-Axis or X-Axis as required.
    A context sensitive menu is displayed.
  3. Select the Show Grid option.
    The horizontal or vertical grid lines are displayed (the horizontal lines are for the Y-Axis, and the vertical lines are for the X-Axis).

To hide the grid lines:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Show Grid option is also available when you are configuring the X-Y Plot in Design mode.

  2. Right-click on the Y-Axis or X-Axis as required.
    A context sensitive menu is displayed.
  3. De-select the Show Grid option.
    The horizontal or vertical grid lines are hidden (the horizontal lines are for the Y-Axis, and the vertical lines are for the X-Axis).


X-Y Plots Guide - Show and Hide the Title, Axes, and Time Line (Using X-Y Plots)

Show and Hide the Title, Axes, and Time Line

You can choose to hide the Title, Time Line, or axes so that the remaining features of the X-Y Plot make maximum use of the display area. This is useful when you only require some of the X-Y Plot features.

When you have hidden a Title, axis, or Time Line, you can use the Show options to redisplay the features as required.

To show and hide the Title, X-Axis, Y-Axis, or Time Line:

  1. Display an X-Y Plot in Run Mode.

NOTE: The Hide and Show options are also available when you are configuring the X-Y Plot in Design mode.

  2. Right-click on the X-Y Plot display (anywhere above the X-Axis and to the right of the Y-Axis, i.e. the area in which the values are shown).
    A context sensitive menu is displayed.
  3. Select or clear the relevant option (when selected the option is prefixed with a check mark):
  • Show Title—To show/hide the Title. Select the Show Title option to display the Title. Clear the option to hide the Title.
  • Show X Axis—To show/hide the X-Axis. Select the Show X Axis option to display the X-Axis. Clear the option to hide the X-Axis.
  • Show Y Axis—To show/hide the Y-Axis. Select the Show Y Axis option to display the Y-Axis. Clear the option to hide the Y-Axis.
  • Show Time Axis—To show/hide the Time Line. Select the Show Time Axis option to display the Time Line. Clear the option to hide the Time Line.
    X-Y Plot showing the X-Axis and Y-Axis, but hiding the Title and Time Line.


Expressions Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Expressions Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Expressions Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Expressions Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Expressions Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Expressions Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to create expressions - combinations of symbols and operators that ClearSCADA evaluates to obtain a single value. Expressions can be used to obtain values for many different aspects of ClearSCADA, including Mimics, Trends, Data Grids, Methods, and Historic calculations.

In this Guide, we explain how to use the expression editors and describe the required syntax for valid expressions in ClearSCADA. For details on the subjects covered in this Guide, see Welcome to the Guide to Expressions.


Expressions Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by engineers who have some programming experience and are responsible for the configuration of expressions for Mimics, Trends, Data Grids, Historic calculations, and methods. The grammar and syntax for expressions are similar to those in other programming languages such as C and Visual Basic.


Expressions Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Expressions Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Mimics

ClearSCADA Guide to Trends

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Logic

ClearSCADA Guide to the Database

ClearSCADA Guide to Server Administration.


Expressions Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Expressions Guide - Welcome to the Guide to Expressions

Welcome to the Guide to Expressions

Welcome to the ClearSCADA Guide to Expressions. This guide is designed for use by engineers that have some programming experience—the grammar and syntax for expressions are similar to those in other programming languages such as C and Visual Basic.

An expression is a combination of symbols and operators that ClearSCADA evaluates to obtain a single value. For example, an expression can be used in the animation for a text box in a Mimic so that the text box displays a different string according to the state of a point. Expressions can be used in the following parts of ClearSCADA:

  • Mimics (see the ClearSCADA Guide to Mimics)
  • Trends (see the ClearSCADA Guide to Trends)
  • Data Grids (see Configuring Data Grids in the ClearSCADA Guide to Core Configuration)
  • Methods (see Method Expressions)
  • Historic Calculations (see Configuring Historic Calculations in the ClearSCADA Guide to Core Configuration).

The following sections contain details about the syntax and functions for expressions. They also explain how to use the various Expression displays and fields:

  • Understanding the Basics of Expressions
  • Grammar for Expressions
  • Operators
  • Data Types
  • Evaluation of Expressions
  • Using the Expression Editors
  • Tags
  • Functions.


Expressions Guide - Understanding the Basics of Expressions (Welcome to the Guide to Expressions)

Understanding the Basics of Expressions

There are 2 types of expression in ClearSCADA:

  • Standard expressions that are used to calculate values
  • Method expressions that are used to perform actions. For example, a method expression can be used to override the value of a point, with the override value being calculated based on the state of another point. For more information, see Method Expressions.

Expressions can contain tags that are used to obtain values from a database. For example, an expression can contain a tag that represents the CurrentState value of a database point.

Expressions can 'call' various built-in functions. For example, you can include the REGISTRY function in an expression to read a value that is stored in the Windows registry. If you needed an expression to calculate the largest value in a list of values, you would include the MAX function in your expression. For more information on the available functions, see Functions.

Example:

The following expression is used to animate the color of a shape on a Mimic so that it changes color according to the value of an analog point:

IIF (".AI1.CurrentValue">=60, RGB(255,0,0), RGB(0,255,0))

Where:

  • IIF is a function that returns one of two values depending on the result of a comparison
  • ".AI1.CurrentValue" is the tag that is used to obtain the current value of a point named 'AI1'. (The 'AI1' point is stored in the same group as the Mimic in this example)
  • >=60 compares the value of the point with the value 60. If the point value is 60 or above, the color of the shape is set to the color defined by the first RGB function. If the point value is below 60, the shape is set to the color defined by the second RGB function
  • RGB(255,0,0) is a function. The expression contains 3 numbers that represent the color values (Red, Green, and Blue) for the color that is returned (in this case, red)
  • RGB(0,255,0) is a function. The expression contains 3 numbers that represent the color values (Red, Green, and Blue) for the color that is returned (in this case, green)
  • ) closes the arguments for the IIF function.

So, when the value of the 'AI1' point is below 60, the shape on the Mimic is green; when the value is 60 or above, the shape is red.

Now that you have a basic understanding of the purpose of expressions and know something about their syntax, you can start thinking about creating your own expressions. Before you start your own expressions, you should familiarize yourself with the Grammar for Expressions.

We also recommend that you refer to the following sections:

  • Method Expressions
  • Comments in Expressions
  • Operators
  • Data Types
  • Evaluation of Expressions
  • Using the Expression Editors—for information on the various expression editors that you can use to enter expressions.
  • Tags—for information on including tags in your expressions.
  • Functions—for information on the various built-in functions you can use in your expressions.


Expressions Guide - Grammar for Expressions (Welcome to the Guide to Expressions)

Grammar for Expressions

The following sections describe the syntax for the 4 types of expression:

  • Standard Expressions
  • Method Expressions
  • User Method Expressions
  • Data Grid Expressions.


Expressions Guide - Standard Expressions (Welcome to the Guide to Expressions)

Standard Expressions

Each standard expression consists of a simple expression. The following information shows the grammar for creating standard expressions:
<expression> ::= | <simple-expression> [ ( "=" | "<>" | "<" | "<=" | ">" | ">=" ) <simple-expression> ]
<simple-expression> ::= | [ "+" | "-" ] <term> [ ( "+" | "-" | OR ) <term> ]
<term> ::= | <factor> [ ( "*" | "/" | MOD | AND | XOR ) <factor> ]
<factor> ::= | [ NOT | "+" | "-" ] ( <function> | "(" <expression> ")" | <boolean> | <integer> | <real> | <date-time> | <string> | <tag> | <cell> | <cell-block> |)
<function> ::= | <function-name> "(" [ <expression> { "," <expression> } ] ")"
<boolean> ::= | TRUE | FALSE
<integer> ::= | <digit> { <digit> }
<digit> ::= | "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
<real> ::= | [ <integer> ] "." <integer> [ <exponent> ] | <integer> <exponent>
<exponent> ::= | ( "E" | "e" ) [ "+" | "-" ] <integer>
<date-time> ::= | "#" ( <date> | <time> | <date> " " <time> ) "#"
<date> ::= | <short-date> | <long-date>
<short-date> ::= | <day> "/" <month-number> "/" <year>
<long-date> ::= | <day> " " <month-name> " " <year>
<year> ::= | <digit> <digit> [ <digit> <digit> ]
<time> ::= | <hours> ":" <minutes> [ ":" <seconds> [ <fraction> ] ]
<fraction> ::= | "." <digit> [ <digit> [ <digit> ] ]
<string> ::= | "'" <text> "'"
<tag> ::= | """ ( <relative-tag> | [ <system-name> ":" ] <absolute-tag> | Parameter: <parameter-name> ) """
<relative-tag> ::= | "." { "." } ( <data-tag> | <historic-tag> | <historic-calc-tag> )
<absolute-tag> ::= | <data-tag> | <historic-tag> | <historic-calc-tag> | <server-status-tag> | <register-tag>
<data-tag> ::= | ( <item> | <search-key> ) [ "." ( <property-name> | <method-name> "(" [ <expression> { "," <expression> } ] ")" ) ]
<historic-tag> ::= | ( <item> | <search-key> ) [ "." <historic-algorithm-name> ] ";" <opc-aggregate> ";" <relative-time> ";" <interval>
<historic-calc-tag> ::= | ( <item> | <search-key> ) [ "." <historic-algorithm-name> ] ":" <interval> ":" <interval> ":" <interval>
<item> ::= | ( <group> | [ <group> "." ] <item-name> ) [ "." <aggregate-name> ]
<group> ::= | <group-name> [ "." <group> ]
<server-status-tag> ::= | "#" <status-tab-name> "." <status-key> "." <status-property-name>
<register-tag> ::= | "@" <register-name> "." <integer>

Where:

  • <function-name> is the name of any built in function (see Functions).
  • <text> is any literal text (if the text includes the single quotation character ', the character has to be replaced by two ' characters)
  • <day> is the day of the month, from 1 to 31.
  • <month-number> is the month number, from 1 to 12.
  • <month-name> is either the full month name (e.g. October) or short month name (e.g. Oct).
  • <hours> is a number from 0 to 23.
  • <minutes> is a number from 0 to 59.
  • <seconds> is a number from 0 to 59.
  • <system-name> is the name of a system available to ViewX (this only applies to in expressions that are evaluated by ViewX clients). A system is a ClearSCADA database.
  • <group-name> is the name of a group in the database
  • <item-name> is the name of an item in the database
  • <aggregate-name> is the name of an aggregate of an item in the database
  • <historic-algorithm-name> is the name of a historic algorithm of an item in the database (this can only be omitted when the item has exactly one historic algorithm)
  • <property-name> is the name of a property of an item or aggregate in the database
  • <method-name> is the name a method of an item or aggregate in the database
  • <search-key> is the value of a database search key (see Search Key Tags)
  • <parameter-name> is the full name (including group(s)) of a Mimic parameter. This is only applicable to expressions on Mimics (see the ClearSCADA Guide to Mimics)
  • <opc-aggregate> is the name of an OPC HDA aggregate (see OPC Historic Tags)
  • <relative-time> is an OPC relative time (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).
  • <interval> is an OPC time (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.)
  • <status-tab-name> is the name of a server status tab (see Server Status Property Tags)
  • <status-key> is the key value of a row in a server status tab (see Server Status Property Tags)
  • <status-property-name> is the name of a property of a server status tab (see Server Status Property Tags)
  • <register-name> is the name of a SCADAPack ES register (see SCADAPack ES Register Tags)
  • <field> is the name of a field in a data grid. This only applies to expressions in data grids.
  • <row> is the number of a row in a data grid. This only applies to expressions in data grids.

NOTE: You can also include comments in your expressions. Usually, comments are used to provide a brief description of the code so that other users can quickly determine its purpose. You can add comments to any part of the expression code (see Comments in Expressions).


Expressions Guide - Method Expressions (Welcome to the Guide to Expressions)

Method Expressions

Method expressions are a different type of expression. Unlike standard expressions that calculate a value, method expressions call a method on an item in the database to perform an action. For example, a method expression can be used to call the override method on a point.

There are many methods available for calling. You can use the database schema to find out which methods are available for each database item (see Working with the Database Schema in the ClearSCADA Guide to the Database).

Method expressions are used by:

  • Method Calls—You can enter a method expression in the Method field on the Method Call tab (see Stand-Alone Method Calls in the ClearSCADA Guide to Core Configuration).
  • Alarm Redirections—You can enter a method expression in the Method field on the Method Action tab of Forms (see Define the Method Action Details in the ClearSCADA Guide to Alarm Redirection).
  • Alarm Handling—You can enter a method expression for alarm handling methods (methods that are performed when an item changes alarm state). Enter a method expression in the Method field on the Alarm tab of the item's Form (see Configure a Method Action to Trigger at Every Alarm State Change in the ClearSCADA Guide to Core Configuration).
  • User Methods—These methods extend the syntax of method expressions to allow the user to be prompted for values (see User Method Expressions).

NOTE: User methods are custom methods that can be associated with any database item (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).

The following grammar is an extension of the grammar for Standard Expressions:

<method-expression> ::=

<method-name> "(" [ <expression> { "," <expression> } ] ")"

Where:

  • <method-name> is the name of the method to be executed, for example, Override
  • <expression> is a standard expression (which is an argument for the method).

The main difference with method expressions is that you start the expression with the <method-expression> instead of a <simple-expression>. The arguments for the method expression are standard expressions and use the grammar described in Standard Expressions.

Example:

The following expression is used to perform an override on a point.

Override(65)

The expression begins with the name of the method—the Override method.

There is a single argument: 65. This means that when the method is executed, it overrides the value of the point to 65.


Expressions Guide - User Method Expressions (Welcome to the Guide to Expressions)

User Method Expressions

User methods are custom pick actions—specifically customized menu options (pick actions) that you can associate with any database item (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).

You enter a user method expression in the Method field (User Methods tab) on the item's Form.

The following syntax is an extension of the grammar for Method Expressions:
<user-factor> ::= | <factor> | <prompt>
<prompt> ::= | "[" <string> "," <expression> "]"

Where:

  • <user-factor> replaces <factor> in the definition of <term> (see Standard Expressions).

The grammar includes an additional type of factor called a prompt. This allows you to request that the user enters a value when the pick action is executed. A prompt consists of 2 parts:

  1. A string that is used in the pick action's window as a label for the value.
  2. A default value. This is the value that is selected by default when the pick action's window is displayed. It also defines the type of value that the user is prompted to enter.

When the prompt factor is evaluated, it returns the value entered by the user.

Example:

User methods are often used to prompt a user to enter some values for a Logic program. For example, the following expression calls the 'Execute' method on a Logic program:

Execute( ['Number', 10] * 5, ['String', 'Closing'] )

The expression defines that there are 2 arguments for the method, one is a number and the other is a string. The default setting for the number is 10 and the default setting for the string is 'Closing'

When a user selects the user method for the relevant item, a window is displayed. The window requires that the user enters an integer (number) and a string:

The integer value is multiplied by 5 and passed as the first argument to the Logic program, and the string value is passed as the second argument. The Logic program then uses these values in its calculations.

If the user does not enter a number and string, the default settings of 10 and 'Closing' are used.


Expressions Guide - Data Grid Expressions (Welcome to the Guide to Expressions)

Data Grid Expressions

Expressions can use individual cells or blocks of cells (arrays) instead of other types of value. This means that expressions can use values from fields and rows in Data Grids. The grammar for data grid expressions is an extension of the grammar for (see Standard Expressions):
<cell> | <field><row>
<cell-block> | <field><row> ":" <field><row>

Where:

  • <cell> or <cell-block> is a <factor> in the definition of <term> (see Standard Expressions).
  • <field> is a field in the data grid
  • <row> is a row in the data grid.

NOTE: All functions support values from single cells, but only the AVERAGE, MAX, MIN, PRODUCT, and SUM functions support values from blocks of cells.

Examples:

Referencing single cells:

DATA1 + DATA5

This calculates the sum of the values that are stored in row 1 and row 5 of the field named DATA.

Referencing a block of cells from the same field:

MAX(DATA1:DATA6)

This calculates the maximum value of the values that are stored in rows 1 to 6 inclusive of the field named DATA.

Referencing a block of cells from different fields:

AVERAGE(A1:C6)

This calculates the average value of the values that are stored in the cells between row 1 of the field named A and row 6 of the field named C. The same expression could be defined as AVERAGE(C6:A1) as ClearSCADA automatically determines the range of cells, even if the last cell is defined first.

NOTE: Be careful to avoid recursive expressions that create circular references, for example, A1 = B1 + C1, B1 = A1 + D1.


Expressions Guide - Comments in Expressions (Welcome to the Guide to Expressions)

Comments in Expressions

You can add comments to your expressions by enclosing them in braces { }, for example:

{This is a comment. It allows you to advise other users about the expression without affecting how the expression is processed}.

The purpose of comments is to allow you to leave useful information about the expression within the expression code. The comment can then be read by other users who are examining the expression code. For example, if part of an expression is particularly complex or produces an unexpected result, you can add a comment to that part of the code to explain how it works to other users. Any text that is inside the braces is treated as a comment and will not affect the validity of the expression in any way.


Expressions Guide - Operators (Welcome to the Guide to Expressions)

Operators

The following groups of operators are available for use in your expressions (where appropriate):

  • Arithmetic Operators
  • Comparison Operators
  • Logical and Bitwise Operators

For information on the order in which the operators are used in expressions, see Operator Precedence.


Expressions Guide - Arithmetic Operators (Welcome to the Guide to Expressions)

Arithmetic Operators

You can use the following arithmetic operators in your expressions:

Operator

Symbol

Meaning

Negation

-

Indicates the negative value of an expression.

Power

**

Raises one number to the power of another.

Multiplication

*

Multiplies 2 numbers.

Division

/

Divides 2 numbers and returns a floating point number.

Modulus

Mod

Divides 2 numbers and returns the remainder as the result.

Addition/Concatenation

+

Adds a numeric expression to another numeric expression, adds a numeric expression to a string, adds a number to a date, or concatenates 2 strings.

When you add or concatenate 2 strings, a string is returned. The string expression will be evaluated as a string expression.

If you add a number to a date, the number is the number of days, and the value is returned as a date.

Subtraction

-

Subtracts a numeric expression from another numeric expression and returns the difference.

When dates are used, the subtraction operator subtracts one date from another date and returns the difference in days.

If you subtract number from a date, the number is the number of days, and the value is returned as a date.

For each of these operators, an empty expression is treated as zero (number), an empty string ' ', or TRUE (Boolean).

Boolean values are treated as:

  • TRUE = -1
  • FALSE = 0.

String expressions are evaluated as a number except when one string is added to another string.

See also:

Comparison Operators

Logical and Bitwise Operators.


Expressions Guide - Comparison Operators (Welcome to the Guide to Expressions)

Comparison Operators

The following table shows the comparison operators you can use in your expressions. In the descriptions, expression 1 refers to the expression to the left of the operator and expression 2 refers the expression to the right of the operator.
Operator | Symbol | Meaning
Equality | = | Compares one expression against another to see if they are equal. It is True if expression 1 is equal to expression 2, otherwise it is False.
Inequality | <> | Compares one expression against another to see if they are not equal. It is True if expression 1 is not equal to expression 2, otherwise it is False.
Less than | < | Compares one expression against another to see if the first expression is less than the second expression. It is True if expression 1 is less than expression 2, otherwise it is False.
Greater than | > | Compares one expression against another to see if the first expression is greater than the second expression. It is True if expression 1 is greater than expression 2, otherwise it is False.
Less than or equal to | <= | Compares one expression against another to see if the first expression is less than or equal to the second expression. It is True if expression 1 is less than or equal to expression 2, otherwise it is False.
Greater than or equal to | >= | Compares one expression against another to see if the first expression is greater than or equal to the second expression. It is True if expression 1 is greater than or equal to expression 2, otherwise it is False.

  • If both expressions are numeric, a numeric comparison is performed.
  • If both expressions are strings, a string comparison is performed.
  • If one expression is numeric and the other is a string, the numeric expression is treated as being less than the string expression.
  • If one expression is empty and the other is numeric, a numeric comparison is performed with 0 being used as the empty expression.
  • If one expression is empty and the other is a string, a string comparison is performed with a zero length string (' ') used as the empty expression.
  • If both expressions are empty, the expressions are regarded as equal.

See also:

Arithmetic Operators

Logical and Bitwise Operators.


Expressions Guide - Logical and Bitwise Operators (Welcome to the Guide to Expressions)

Logical and Bitwise Operators

You can use the following logical and bitwise operators in your expressions:

Operator

Symbol

Meaning

Logical negation

Not

If the expression is True, the result is False.

If the expression is False, the result is True.

For numbers, 0 is false and every other number is true.

For strings, an empty string is false and strings containing characters are true.

For dates, 30-DEC-1899 is False and other dates are True.

Logical conjunction or Bitwise conjunction

And

Logical conjunction operators are used when both expressions Boolean. Bitwise conjunction operators are used when both expressions are numeric.

If one expression is Boolean and the other is numeric, the Boolean expression is converted into a number (TRUE=-1, FALSE=0).

Both Expressions are Boolean:

True And True = True

True And False = False

False And True = False

False And False = False

One or More Numeric expressions:

The And operator performs a bitwise comparison of 2 bits and sets the bit in the result as follows:

Bit in Expression 1 is 0, Bit in Expression 2 is 0, result bit is 0.

Bit in Expression 1 is 0, Bit in Expression 2 is 1, result bit is 0.

Bit in Expression 1 is 1, Bit in Expression 2 is 0, result bit is 0.

Bit in Expression 1 is 1, Bit in Expression 2 is 1, result bit is 1.

If the expression contains one Boolean expression and one numeric expression, the result is a Boolean expression that is converted into a numeric value (-1 for True and 0 for False).

Logical disjunction or Bitwise disjunction

Or

For Boolean expressions:

True OR True = True

True OR False = True

False OR True = True

False OR False = False

For Numeric expressions:

The OR operator performs a bitwise comparison of 2 bits and sets the bit in the result as follows:

Bit in Expression 1 is 0, Bit in Expression 2 is 0, result bit is 0.

Bit in Expression 1 is 0, Bit in Expression 2 is 1, result bit is 1.

Bit in Expression 1 is 1, Bit in Expression 2 is 0, result bit is 1.

Bit in Expression 1 is 1, Bit in Expression 2 is 1, result bit is 1.

Logical exclusion or Bitwise exclusion

Xor

For Boolean expressions:

True Xor True = False

True Xor False = True

False Xor True = True

False Xor False = False

For Numeric expressions:

The Xor operator performs a bitwise comparison of 2 bits and sets the bit in the result as follows:

Bit in Expression 1 is 0, Bit in Expression 2 is 0, result bit is 0.

Bit in Expression 1 is 0, Bit in Expression 2 is 1, result bit is 1.

Bit in Expression 1 is 1, Bit in Expression 2 is 0, result bit is 1.

Bit in Expression 1 is 1, Bit in Expression 2 is 1, result bit is 0.

See also:

Arithmetic Operators

Comparison Operators.


Expressions Guide - Operator Precedence (Welcome to the Guide to Expressions)

Operator Precedence

The operator precedence is the order in which ClearSCADA performs the various operations when evaluating an expression. ClearSCADA performs the operations in order (highest precedence first, lowest precedence last).

When the operators have equal precedence, ClearSCADA performs them in the order they appear from left to right.
Precedence | Operator
5 (Highest precedence) | NOT, Negation
4 | Power
3 | Multiply, Divide, Modulus, AND, OR
2 | Addition, Subtraction, OR
1 (Lowest precedence) | Comparisons

So, operations with precedence 5 are performed before operations with precedence 4, 3, 2, and 1. Operations with precedence 4 are only performed before operations with precedence 3, 2, and 1 and so on.

Operations within parentheses are performed before their resultant value is used in the expression. For example:

10 * (35 - 5 + 10)

In this expression, the operators in the parentheses are performed first. So, 35-5 is performed first, resulting in 30. Then the 10 is added to make 40. The subtraction is performed before the addition as subtraction and addition have the same precedence, so ClearSCADA performs them in the order they appear from left to right.

When the operators in the parentheses have been performed, the resultant value of 40 is used in the expression.

The multiplication is performed next as it has the next highest precedence. The multiplication results in the value 400.


Expressions Guide - Data Types (Welcome to the Guide to Expressions)

Data Types

There are 4 types of data value that you can use in your expressions:

  • String
  • Number (Integer or Real)
  • Boolean
  • Date and Time.

NOTE: Many functions have arguments that need to be of a certain data type. If you use the wrong data type for an argument, ClearSCADA will try to convert the argument into the correct data type. For example, if you define a REAL value when a BOOL is required, ClearSCADA will try to convert the REAL into a BOOL. In the case of a string argument, the content of the string determines whether the conversion is successful. For example, if the required data type is Integer, but you define a string argument as “1234”, the argument will work successfully. This is because ClearSCADA can convert the content of the string into an Integer value successfully (the content of the string matches a valid value for the required data type).


Expressions Guide - String (Welcome to the Guide to Expressions)

String

A string value is one or more Unicode characters (letters, numbers, and punctuation characters). You can include a string in your expressions by enclosing the string characters in single quotation marks, for example:

'This is a string value.'

The string above is returned as:

This is a string value.

If you need to include single quotation marks as part of the string, simply enter 2 single quotations. For example:

'Dont''t'

The string above is returned as:

Don't

ATTENTION: To indicate a string, use single quotation marks ' '. Do not use double quotation marks “ “ as these are for indicating tags.


Expressions Guide - Number (Integer or Real) (Welcome to the Guide to Expressions)

Number (Integer or Real)

There are 2 types of number values:

Integer Values—Integer values are whole numbers that can be positive or negative. Zero (0) is also an integer value. Integers in ClearSCADA are represented in base 10 (decimal).

The range of numbers is:

-2147483648 to 2147483647

Real Values (sometimes referred to as floating-point values)—Real values are whole numbers with a decimal portion. They can also be expressed in scientific notation (exponential notation).

Real numbers are represented using the eight byte IEEE 754 standard for numerical representation (double precision). You can include numbers in this range:

From:

±2.2250738585072014 x 10 -308

To:

±1.7976931348623157 x10308

Numbers that begin with a single 0 and contain a decimal point are read as real values.

When a real value is expressed in scientific notation, the letter 'e' or 'E' is used to represent 'ten to the power of'.

Examples:
Number | Description | Decimal Equivalent
.0001 | Real value | 0.0001
0.0001 | Real value | 0.0001
00.0001 | Real value | 0.0001
1e-4 | Real value with exponentiation | 0.0001
1.0e-4 | Real value with exponentiation | 0.0001
65 | Integer value | 65


Expressions Guide - Boolean (Welcome to the Guide to Expressions)

Boolean

The Boolean data type has two values: the literals TRUE and FALSE.

A comparison returns a Boolean value as the condition has to be TRUE or FALSE.

Example:

The following expression is used to change the color of an object on a Mimic according to the state of a point named 'DIG 1':

IIF( "DIG 1.CurrentState" = 1, RGB(255,0,0), RGB(0,255,0 ))

This expression contains a condition that uses the current state of the point. If the current state is 1, the condition is TRUE; if the current state is not 1, the condition is FALSE. When the condition is TRUE, the Mimic object is colored red (the first RGB color) and when it is FALSE, the object is colored green (the second RGB color).


Expressions Guide - Date and Time (Welcome to the Guide to Expressions)

Date and Time

You can include date and time values in your expressions. These can be just a date, just a time, or both a date and time. There are 2 different formats for dates, one is called the short format and the other is called the long format.

The syntax for short date and time values is:

#<Day>/<Month No.>/<Year> <Hrs>:<Mins>:<Secs>.<Fraction>#

The syntax for long date and time values is:

#<Day> <Month Name> <Year> <Hrs>:<Mins>:<Secs>.<Fraction>#

Where:

  • <Day> is a number between 1 and 31
  • <Month No.> is a number between 1 and 12 and represents the month. When you use numbers for the month, you have to use forward slashes as separators.
  • <Month Name> is the name of the month. It can be long (the name in full, for example, OCTOBER) or can be short (an abbreviation, for example, OCT). When you enter the name of the month, you have to use spaces as separators instead of forward slashes.
  • <Year> is a 2 digit or 4 digit number for the year. When 2 digits are used, numbers below 25 are for the 21st Century and numbers above 25 are used for the 20th Century.

NOTE: If you only want a time value, you can choose to leave out the day, month number or month name, and year.

  • <Hrs> is a number between 00 and 23 and represents the hours (24 hour clock).
  • <Mins> is a number between 00 and 59 and represents the minutes.
  • <Secs> is a number between 00 and 59 and represents the seconds. The seconds are optional and can be excluded. They are treated as 00 if you do not use them in your expression.
  • <Fraction> is a number that represents the deciseconds, centiseconds, or milliseconds. If you enter 1 digit, the number is for deciseconds; enter 2 digits and the number is for centiseconds; enter a third digit and the number is for milliseconds.

NOTE: If you only require a date value, you can leave out the hours, minutes and seconds. This will return a date with midnight as the time (by default).

  • Forward slashes ( / ) are used to separate the date sections (Day, Month, and Year) when the short date format is used. When the long date format is used, spaces have to be used instead of forward slashes.
  • A space is used to separate the date and time.
  • Colons (:) are used to separate hours, minutes, and seconds.
  • A period (.) is used to separate the seconds from the fraction.
  • A hash (#) has to be included at the start and end of the date and time value.

Examples:

The following examples show the different types of date and time entry (some using the date only, others using the time only, and the final example using both date and time).

#12 Dec 2004#

#12 December 2004#

#15:25:56#

#15:25#

#12/05/04 15:25:56.43#

NOTE: Time entries have to be in the Coordinated Universal Time (UTC) format.

Further Information

Time Zones: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Expressions Guide - Evaluation of Expressions (Welcome to the Guide to Expressions)

Evaluation of Expressions

ClearSCADA expressions can be evaluated at a server or at a client depending on where they are being used. Expressions that are evaluated at a server can only include references to database items that are stored on that server—they cannot refer to items in other databases. Similarly, some functions are only available at the server.

When you are using expressions, you need to consider that:

  • Expressions for Mimic animations and Trend titles and labels are evaluated by the client and so can reference items in other databases.
  • Expressions for data grid cells, historic calculations, and calling methods (user methods, alarm methods etc.) are evaluated at a server and so can only include references to items that are on that specific server.
  • Several functions are only available on servers or clients (see Functions).

NOTE: WebX clients cannot support references that include a system (database).


Expressions Guide - Using the Expression Editors

Using the Expression Editors

There are several expression editors that you can use to create and modify expressions. The editor that you will use varies according to the type of database item you are configuring, for example, the Expression window is available when creating an expression in a Mimic whereas you will need to use the Expression field during the configuration of a historic calculation item.

In the following sections, we explain how to access and use the various expression editors:

  • Expression Window
  • Expression Fields
  • Expression Flowchart.

When you are familiar with the expression editors, you can use them to create and modify expressions. You can enter expressions manually and use the browse features to enter tags and colors.


Expressions Guide - Expression Window (Using the Expression Editors)

Expression Window

You can use the Expression window to create and modify an expression. You can type in the expression in the Expression field, select a tag via the browse button or create the expression using a combination of manually entered code and tags.

The fields and check boxes that are displayed on the Expression window vary according to the type of item with which the expression is used. For example, the Expression window for Mimics has some different features than the Expression window for Trends.

To display the Expression window, see Accessing the Expression Window.

For information on using the various fields and check boxes on the Expression window, see Working with the Expression Window.


Expressions Guide - Accessing the Expression Window (Using the Expression Editors)

Accessing the Expression Window

You will need to use the Expression window during the configuration of many different types of database item, including Mimics and Trends. The features that are provided by the Expression window will vary according to the type of item that you are configuring. For example, the Expression window for a Data Grid has slightly different settings than the Expression window for a Mimic.

You can use the Expression window to enter an expression. The expression defines the value that will be calculated by ClearSCADA.

To access the Expression window:

  • On a Mimic:
  • Display the Animations window for a Mimic object, select an animation property, then select the Edit button. You can then use the Expression window to define the expression for the animation (see Animations in the ClearSCADA Guide to Mimics).
  • Display the Expression Flowchart, double-click on a branch or leaf to display the Expression window. Alternatively, you can right-click on a branch or leaf then select the Edit option to display the Expression window (see Working with the Expression Flowchart Window).
  • Display the Pick Action Wizard and configure a Method pick action. When you come to configure the arguments for the method, you can double-click on any of the arguments to display the Expression window. Alternatively, you can right-click on an argument and select the Edit option from the context sensitive menu. You can then use the Expression window to define the expression for the selected argument.
  • Display the Pick Action Wizard and configure a script pick action. If you choose a function that has one or more arguments, then you can double-click on any of the arguments to display the Expression window. Alternatively, you can right-click on any of the arguments and select the Edit option from the context sensitive menu. For more information, see Scripting in the ClearSCADA Guide to Mimics.
  • On a Trend:
  • When you add or edit a custom column for the key, selecting the Edit button displays the Expression window. You can then use the Expression window to define the expression for the custom column. For more information, see the ClearSCADA Guide to Trends.
  • On a Data Grid:
  • When you select the Properties option for a cell, the Expression window is displayed. You can use the Expression window to create an expression that defines the value of the cell. For more information, see Configuring Data Grids in the ClearSCADA Guide to Core Configuration.
  • Display the Expression Flowchart, double-click on a branch or leaf to display the Expression window. Alternatively, you can right-click on a branch or leaf then select the Edit option to display the Expression window (see Working with the Expression Flowchart Window).

NOTE: The Tag and Historic Tag options for a cell work in the same way as the OPC Tag and OPC Historic Tag features of the Expression window.

The Expression window is not the only interface that you can use to enter an expression. Some fields provide similar functionality to the Expression window (see Expression Fields) and on Mimics and Data Grids you can also use the Expression Flowchart to create IIF statements.

Expression flowchart

For more information on using the Expression window, see Working with the Expression Window.


Expressions Guide - Working with the Expression Window (Using the Expression Editors)

Working with the Expression Window

When you have displayed the Expression window, you can use it to create expressions for:

  • Animations on Mimics (see Animations in the ClearSCADA Guide to Mimics)
  • Custom columns on Trends (see the ClearSCADA Guide to Trends)
  • Cell contents on Data Grids (see Configuring Data Grids in the ClearSCADA Guide to Core Configuration).

The Expression window consists of check boxes, an Expression work area, and a browse button.

  • Use the check boxes to enable and disable specific Expression features
  • Use the Expression work area to enter the expression.
  • Use the browse button to enter OPC tags, OPC Historic tags, colors etc.

Some check boxes are specific to the type of item you are configuring. The Expression window for Mimics provides a Hover check box and a Fast Updates check box that are not shown on the standard Expression window.

The image below shows the standard Expression window:

You can enter expressions manually in the Expression work area
Browse button provides access to OPC properties (tags), OPC historic properties, etc.
Relative check box allows you to specify whether a single tag expression uses a relative or absolute path

You can use the various features of the Expression window as follows:

  • Relative—Defines whether the tag in the expression uses a relative or absolute reference to an item in the database.

The Relative option is only available when the expression consists of exactly one tag. If the check box is selected so that it displays a check mark, the tag uses a relative reference to the item in the database; when the check box is clear, the tag uses an absolute reference. The Relative option is not available for use with file based Mimics and Trends or when the reference is to a database item in another database.

Further Information

Relative and Absolute References.

  • Hover—Defines whether the expression is used as part of a hover animation on a Mimic. This check box is only available when the Expression window is accessed when configuring a Mimic.

The Hover feature allows an object on a Mimic to change its appearance when the cursor is positioned over the object. For example, the Hover feature can be used to change the color of a shape when the cursor is positioned over the shape.

The expression defines the value of the object's property when the cursor is positioned over the object. So, if the expression was used to animate the FillColour property of a shape, and the expression was RGB(255,0,0), positioning the cursor over the shape will cause it to change color to red.

  • Fast Updates—Defines whether the tags in the expression are included in the client PC's fast updates group. The fast updates group is a set of values for which the client PC requests more frequent updates. The server sends updates for the values in the fast updates group more frequently than it sends updates for other values.

The Fast Updates feature is only applicable on Mimics on ViewX clients.

Select the Fast Updates check box, the tags are included in the client PC's fast updates group; clear it to exclude the tags from the fast updates group.

ATTENTION: Fast updates can place extra demand on system resources and so can affect system performance. For this reason, they should be used sparingly.

  • Expression work area—You can type an expression or make adjustments to part of an expression in the Expression work area.
  • Browse button—Use the browse button to enter a tag or color in the expression (tags represent the OPC properties of an object). The tag or color is inserted at the current position of the cursor in the expression. If part of the expression is selected, the tag or color replaces the selected expression code.

When you select the browse button, a context sensitive menu is displayed containing one or more of these options:

  • OPC Tag—Reference a specific property of an item in any available database. For example, you can reference the CurrentValue property of a database point. For more information, see OPC Tags.
  • OPC Historic Tag—Reference a historic tag. For more information, see OPC Historic Tags.
  • Historic Calculation Tag—Reference the source point or forecast for an historic calculation. For more information, see Historic Calculation Tags.
  • Color—Reference a color from the palette or a custom color in your expression. For more information, see RGB.
  • <Parameter Name>—Reference a Mimic parameter in an expression. This option only applies to Mimics that have parameters. For a description of how to reference a parameter, see Mimic Parameters.

For more information on parameters, see Parameters in the ClearSCADA Guide to Mimics.

NOTE: The context sensitive menu is only displayed if more than one type of expression reference is available. If only one type of expression reference is available, selecting the browse button will cause the relevant tag window to be displayed.


Expressions Guide - Expression Fields (Using the Expression Editors)

Expression Fields

On some configuration displays, the functionality of the Expression window is provided via a field. So, instead of using the browse button on the Expression window to select a tag or color, you will need to select the browse button for the relevant field. You can also enter the expression manually in the field as required.

When configuring Trends, the following fields provide similar functionality to the Expression window:

  • The Title field on the Trend Properties works in a similar way to the Expression window—you can enter an expression manually or use the browse button to select a tag. The Title field is used to edit the Graph title.
  • The Label field on the Edit Y Axis window works in a similar way to the Expression window—you can enter an expression manually or use the browse button to select a tag. The Label field is used to edit the label that is shown for the Y-Axis.
  • The Label field on the Edit Trace window provides similar functionality as the Expression window—you can enter an expression manually or use the browse button to select a tag.


Expressions Guide - Expression Flowchart (Using the Expression Editors)

Expression Flowchart

The Expression Flowchart window allows you to create IIF expressions for Mimics and Data Grids in a diagram format. This makes it easier to create complicated IIF expressions as you can easily visualize what happens with each condition.

NOTE: For information on IIF expressions, see IIF.

Each flowchart consists of branches and leaves. Branches contain boolean expressions, and the result of these expressions is True or False. There are 2 leaves for each branch. Each leaf represents a True result or a False result.

When ClearSCADA processes the flowchart, it begins with the first branch (the top-left branch) and proceeds through the flowchart until it reaches a leaf. The value in the leaf is used as the value of the expression.

Example:

The following flowchart is used with the FillColour animation property of a polygon on a Mimic.

Branch
Leaves

The branch expression tests whether the value of a digital point's alarm state is 4 (the point has an unacknowledged uncleared alarm).

The True leaf sets the color to be red and the False leaf sets the color to be green. This means that if the digital point has an uncleared alarm, the FillColour animation will have RGB (255, 0, 0) as its value (red) and if the digital point does not have an uncleared alarm, the FillColour animation will have RGB(0, 255, 0) as its value (green.

For more information on the Expression Flowchart Window, refer to:

  • Accessing the Expression Flowchart Window
  • Working with the Expression Flowchart Window.


Expressions Guide - Accessing the Expression Flowchart Window (Using the Expression Editors)

Accessing the Expression Flowchart Window

The Expression Flowchart window is only available via Mimics and Data Grids.

To display the Expression Flowchart for a Mimic, display a Mimic and then access the Animations window for an object on the Mimic (the object to which the expression will apply). On the Animation window, select the Flowchart button to display the Expression Flowchart window.

For more information, see Using the Flowchart Window in the ClearSCADA Guide to Mimics.

To display the Expression Flowchart for a Data Grid, display the Data Grid then right-click on a cell to display a context sensitive menu. Select the Flow Chart option from the menu to display the Expression Flowchart for the selected cell.

For more information, see Use a Flowchart to Build an Expression in the ClearSCADA Guide to Core Configuration.


Expressions Guide - Working with the Expression Flowchart Window (Using the Expression Editors)

Working with the Expression Flowchart Window

When you display a new Flowchart window, the flowchart contains a single leaf. Leaves are used to contain a result of an expression. Leaves are used with branches—branches contain the condition of the expression.

Leaf

When a branch is inserted, another leaf is added so that it the branch contains 2 leaves. One leaf is the result if the branch expression is True and the other is the result if the expression is False. Condition branches can then be chained together to form a complex series of conditions and results.

To create a flowchart, right-click on a branch or leaf to display a context sensitive menu. Use the options on the context-sensitive menu to create the flowchart:

  • Insert—Inserts a new condition branch.
  • Swap Branches—Swaps the True and False leaves of a condition branch. The expressions for the True leaf become the expressions for the False leaf and vice versa.
  • Edit—Displays the Expression window for a branch or leaf. Use the Expression window to define the IIF condition for a branch or the value for a leaf—use the browse button to select an OPC tag, OPC Historic tag, or a color.

NOTE: You can also access the Edit feature by double-clicking on a branch or leaf.

Further Information

Working with the Expression Window.

IIF.

NOTE: There are also the standard Cut, Copy, Paste, and Delete options.

If you are creating a flowchart for a Mimic, you can add the tags used in the expression to the Fast Updates group by selecting the Fast Updates check box. The Fast Updates check box works in the same way as the Fast Updates check box that is shown on the Expression window (see Working with the Expression Window).

To confirm your selections and close the Flowchart window, select the OK button.


Expressions Guide - Tags

Tags

As you create your own expressions, you will need to reference the values that are stored in the database, methods for items, SCADAPack ES registers etc.

Before you enter a reference in an expression, you should familiarize yourself with Relative and Absolute References. When you understand the difference between a relative reference and an absolute reference, you can begin to enter references in your expressions.

When you include a reference in an expression, the referenced value is used to determine the result. For example, an expression that uses the IIF function could contain a reference to a point's CurrentState property—the point's current state value affects the outcome of the expression.

For many types of reference, you can use the browse button of the relevant Expression editor to enter a tag or you can enter the reference manually. However, some types of reference can only be entered manually.

If you wish to alter a reference or you want to enter a reference manually, you have to use the correct syntax. The syntax varies according to the type of reference being made. The following sections explain how to enter the various different types of reference:

  • OPC Tags
  • OPC Historic Tags
  • Historic Calculation Tags
  • Indirect Tags
  • Mimic Parameters.

For information on entering a color, see RGB.

NOTE: Before you enter a tag, you need to know where your expression will be evaluated. Expressions that are evaluated at the server can only include references to database items that are stored on the same server. For more information, see Evaluation of Expressions.


Expressions Guide - Relative and Absolute References (Tags)

Relative and Absolute References

There are 2 types of references you can use in your tag:

  • Absolute References
  • Relative References.

Typically, relative references are used as they provide more flexibility and reduce the chances of references being broken.

When you select a tag from an Expression display, you can choose whether a reference is absolute or relative by using the Relative check box. If you select the Relative check box, the expression will use a relative reference and if you clear the check box, an absolute reference is used.


Expressions Guide - Absolute References (Tags)

Absolute References

Absolute references contain the full name of the referenced item. They can be used instead of relative references anywhere in the database, but have to be used for referencing items in other databases. File based Trends and Mimics also require absolute references when referencing items in the database.

Absolute references use the format:

"<full name of item>.<property>"

Where <full name of item> is the full name of the database item being referenced, including any groups, sub-groups, and the name of the item. The <property> part of the expression is the name of the property that is being referenced. The angle brackets < > are not included.

If the referenced item is located in a different database to the item that contains the expression, the reference has to include the name of the database (system) followed by a colon:

"<system>:<full name of item>.<property>"

Example:

A Mimic named 'Values' is in a group named 'SCADAPack Modbus'. The 'SCADAPack Modbus' group is contained within a group named 'Main'. The 'SCADAPack Modbus' group also contains a point named 'AIP3'.

A text box on the Mimic is configured to show the current value of the 'AIP3' point. The following expression is used:

"Main.SCADAPack Modbus.AIP3.CurrentState"

The expression uses an absolute reference—it includes the full name of the item (the names of each of the groups between the root group and the property are included as well as the name of the item and the property).


Expressions Guide - Relative References (Tags)

Relative References

Relative references contain the relative name of the item. The relative name starts from the item that contains the expression.

The tag for the relative reference begins with one or more dots—one dot for each level up in the hierarchy of the groups in the tree-structure. If both the item that contains the expression and the item that is being referenced are in the same group, the tag begins with a single dot.

In certain situations, you may need to define a method using an expression that references the item on which the expression is being configured. A common example of this is on point user methods where a point’s Method may use an expression that references the point. If the point is specifically named in the expression, the expression will only work as desired if the point’s name remains the same. This means that if the point is renamed or is copied and the copy used in another location, the expression will be invalid as the location in the reference will be incorrect. However, you can work around this situation by using the .$ notation. This allows you to use a dollar $ to represent the item being referenced. As the dollar does not define a specific item, it can be used with items that are to be renamed or copied without breaking the expression (as ClearSCADA will substitute the item’s name for the $).

For an example of how the .$ notation can be used, see A Custom Action used to Increment the Value of a Point in the ClearSCADA Guide to Core Configuration.

Example - Relative Reference:

A Mimic named 'Values' is stored in a group named 'SCADAPack Modbus'. The 'SCADAPack Modbus' group is contained within a group named 'Main'. The 'SCADAPack Modbus' group also contains a point named 'AIP3'.

A text box on the Mimic is configured to show the current value of the 'AIP3' point. The following expression is used:

".AIP3.CurrentState"

As both the Mimic and the point are in the same group, a single leading dot is used. If the 'AIP3' point was in a group named 'Modbus' in the 'Main' group, the relative reference would be:

"..Modbus.AIP3.CurrentState"

Two leading dots are required as ClearSCADA has to go up one level (to the 'Main' group) before going back down a level (to the 'Modbus' group).


Expressions Guide - OPC Tags (Tags)

OPC Tags

There are several types of OPC tag that you can use in your expressions:

  • Property Tags—represent the properties of database items
  • Method Tags—represent the methods of database items
  • Search Key Tags—represent custom search key database fields
  • Server Status Property Tags—represent the server's status properties
  • SCADAPack ES Register Tags—represent SCADAPack ES inputs and outputs.

For more information, please refer to the section that describes the type of OPC tag you want to reference.


Expressions Guide - Property Tags (Tags)

Property Tags

OPC tags represent the properties of database items, including their configuration field properties. To insert an OPC tag in an expression, you can either type in the tag manually, or you can use the Select Tag window.

To use the browse button to insert a tag, see Selecting an OPC Property Tag.

To enter an OPC tag manually, see Syntax of OPC Property Tags.

Selecting an OPC Property Tag

You can use the Select Tag window to insert a property Tag in your expression.

The Select Tag window is displayed when you:

  • Select the OPC Tag option on the browse button of the Expression window
  • Select the browse button for a field that provides similar functionality to the Expression window.
    Use the Relative check box to set the tag to absolute or relative
    The tag is shown here
    Use the tree-structure to locate and find the tag that you want to insert in your expression.

The Select Tag window lists the OPC 'tags' (properties) for items in the available ClearSCADA databases and third party OPC DA servers. The entries in the window are filtered so that you can only select those properties that are supported by the item for which you are defining an expression.

To select a property Tag:

  1. Position the cursor at the place in the expression that the tag is to be inserted.
  2. Display the Select Tag window then expand the Root group and navigate the hierarchical tree structure to locate the tag that you require.
  3. Select the tag.
    The Relative check box becomes available for use (only if the tag is in the same database as the item that contains the expression and the item is not a file based Mimic or Trend).
  4. Select the Relative check box to use a relative reference to the tag or clear it to use an absolute reference (see Relative and Absolute References).
  5. Select the OK button to confirm your selection and close the Select Tag window.
    The selected tag is entered in the expression field.

Syntax of OPC Property Tags

You can use an OPC tag to reference the properties of a database item. An OPC tag has the following syntax:

"<Item>"

"<Item>.<Property>"

"<Item>.<Database Aggregate>"

"<Item>.<Database Aggregate>.<Property>"

Where:

  • <Item> is the location of the database item. The location can be relative or absolute (see Relative and Absolute References).

If the item is in a different database, the syntax requires a prefix of:

<System>:

Where <System> is the name of the database that contains the item.

  • <Property> is the name of the property tag that you want to reference
  • <Database Aggregate> is the name of the database aggregate that has the required property. Database aggregates are extensions to a table in the database and they have their own name, table, properties and methods. For more information, see Aggregates in the ClearSCADA Guide to the Database.

For example, "MK:NERegion.Level.CurrentValue" is a reference to the CurrentValue property of the Level database item that is stored in the NERegion group in the MK database.

If you omit the <property> in the tag, the tag will use the default property for the defined database item or aggregate. The default property for an item or aggregate varies according to the type of item or aggregate, for example, the default property for a point is CurrentValue.

Examples:

Example 1-Absolute reference to a default property

The following example uses an absolute reference to the default property of a point named 'Analog Input 1':

"SCADAPack Modbus Group.SCADAPack Modbus Direct.Analog Input 1"

This assumes that the 'Analog Input 1' point is in the 'SCADAPack Modbus Direct' group which is in the 'SCADAPack Modbus Group' group.

Example 2-Absolute reference to a specific property

This example uses an absolute reference to the same 'Analog Input 1' point that was used in Example 1, except this time the expression defines a specific property of the point:

"SCADAPack Modbus Group.SCADAPack Modbus Direct.Analog Input 1.CurrentValue"

The specified property is CurrentValue.

Example 3-Absolute reference to the default property of a database aggregate

This example uses an absolute reference to the same 'Analog Input 1' point that was used in Examples 1 and 2, except this time the expression references the default property of the point's 'Historic' database aggregate:

"SCADAPack Modbus Group.SCADAPack Modbus Direct.Analog Input 1.Historic"

Example 4 - Absolute reference to a specific property of a database aggregate

This example uses an absolute reference to the same 'Analog Input 1' point that was used in Examples 1, 2, and 3 except this time the expression references the a specific property of the point's 'Historic' database aggregate:

"SCADAPack Modbus Group.SCADAPack Modbus Direct.Analog Input 1.Historic.PrevLogValue"

The specified property is PrevLogValue.

Example 5 - Relative reference to a specific property

This example uses a relative reference to the CurrentValue property of the same 'Analog Input 1' point that was used in Examples 1-4 inclusive. We assume that the item for which the expression is being created is stored in the 'SCADAPack Modbus Group' group.

".SCADAPack Modbus Direct.Analog Input 1.CurrentValue"

The 'Default' Mimic in the 'SCADAPack Modbus Group' group contains the expression that references the CurrentValue of the 'Analog Input 1' point in the 'SCADAPack Modbus Direct' group.

The dot at the start of the reference indicates that to get to the point that has the tag, ClearSCADA has to go up one level in the hierarchy from the item that contains the expression (1 dot is equal to going up 1 level in the hierarchy).

Example 6 - Relative reference to a different level in the database tree-structure

This example uses a relative reference to the CurrentValue property of the same 'Analog Input 1' point that was used in Examples 1-5 inclusive. This time, we assume that the 'SCADAPack Modbus Group' group contains a group named 'SCADAPack Modbus Direct' and another Group named 'SCADAPack Modbus PSTN'. The item that contains the expression is stored in the 'SCADAPack Modbus PSTN' group and it references the 'Analog Input 1' point that is in the 'SCADAPack Modbus Direct' Group.

"..SCADAPack Modbus Direct.Analog Input 1.CurrentValue"

The 'Default' Mimic in the 'SCADAPack Modbus PSTN' group contains an expression that references the CurrentValue property of the 'Analog Input 1' point in the 'SCADAPack Modbus Direct' group.

The dots at the start of the reference indicate the number of levels in the hierarchy between the item that contains the expression and the point that has the tag. So, the dots represent the 'SCADAPack Modbus Group' group and the 'SCADAPack Modbus Direct' group.

Example 7 - Reference to an item in another database

This example uses a reference to the CurrentState property of a point named 'Point 1'. The 'Point 1' point is stored in a group named 'SCADAPack Modbus Group' that is in another database. The other database (system) is named 'MK'.

"MK:SCADAPack Modbus Group.Point 1.CurrentState"


Expressions Guide - Method Tags (Tags)

Method Tags

To call one of a database item's methods, use the following syntax:

"<Item>.<Method>(<Argument 1>,<Argument 2>, ...)"

"<Item>.<Database Aggregate>.<Method>(<Argument 1>,<Argument 2>, ...)"

Where:

  • <Item> is the name and location of the database item that has the method that you want to call (see Relative and Absolute References)
  • <Method> is the name of the method
  • <Argument 1> is the value passed as the first argument to the method
  • <Argument 2> is the value passed as the second argument to the method
  • <Database Aggregate> is the name of the aggregate that contains the required method.

You can use the Database Schema to find out which database aggregates are available for a database item (see Working with the Database Schema in the ClearSCADA Guide to the Database).

NOTE: You can only call methods that return a value.

Examples:

Example 1 - Calling a Method with no Arguments

A text box on a Mimic is to be animated so that it displays the number of forecasts that have been calculated for a forecast item. The forecast item is named 'R1 FCast'.

To achieve this, the expression for the animation calls the GetForecastCount method of the 'R1 FCast' forecast item.

The following expression is used to animate the Value property of the text box:

".R1 FCast.GetForecastCount()"

Example 2 - Calling a Method with Arguments

A text box on a Mimic is to be animated so that it displays the forecast value for a forecast item at a specific time. The forecast item is named 'R1 FCast'.

To achieve this, the expression for the animation calls the GetForecastValueAtTime method of the 'R1 FCast' forecast item.

The following expression is used to animate the Value property of the text box:

".R1 FCast.GetForecastValueAtTime (1, #22 Sep 2010#)"

Each forecast can have up to 8 sets of forecast data. The first argument defines which set of forecast data is to be used in the expression (in this case, it is 1, which is the latest set of forecast data). The second argument defines the time stamp for the value. So the text box on the Mimic shows the predicted value for 22 September 2010 from the latest forecast.

Example 3 - Calling an Aggregate's Method with Arguments

A text box on a Mimic is to be animated so that it displays today's average value for a point named 'AI'. To achieve this, the expression for the animation calls the ProcessedValue method of the Historic database aggregate for the point.

The following expression is used to animate the Value property of the text box:

".AI.Historic.ProcessedValue ('D', 'D+1D', 'Average')"

Where:

.AI is the location and name of the point

Historic is the name of the database aggregate that contains the data to be used by the expression

ProcessedValue is the name of the method of the aggregate being called.

('D', 'D+1D', 'Average') are the arguments of the method. This method has 3 arguments:

  • The start time—Start of today (D)
  • The end time—End of the current day (D+1D)
  • The type of aggregate applied to the data—Average.

NOTE: The same effect can be achieved by selecting a Historic tag on the OPC Historic Tag window (see Selecting an OPC Historic Tag).

Example 4 - Calling a Method that Returns Values

Some methods return a value that can be displayed or used as an input elsewhere in your expression. One such method is CheckAccess, which returns a True or False value depending on whether the logged on user has a specified permission for the object with which the CheckAccess method is associated. This method is often used on systems where there is a need to check which permissions are available to the logged on user.

In this example, a Mimic contains a text box and a button. When selected by the user, the button causes the CheckAccess method to be called. The CheckAccess method detects whether the user has a specific permission for a specific item, in this case, the Override permission for a point named ‘ValveAPoint’.

If the user does have the Override permission for the ‘ValveAPoint’, the text box displays ‘ ‘Override Available’; if the user does not have the Override permission, the text box displays ‘Override Unavailable - Permission Restricted’.

To make this possible, a text box is added to a Mimic. The Text animation property of the text box is configured to have this expression:

IIF(".ValveAPoint.CheckAccess ('OVR')", 'Override Available', 'Override Unavailable - Permission Restricted')"

This instructs the text box to display ‘Override Available’ if the “.ValveAPoint.CheckAccess (‘OVR’)” method returns a True value or ‘Override Unavailable - Permission Restricted’) if it returns a False value.

A button is added to the Mimic. The button’s Visible animation property is configured to have the following expression:

".ValveAPoint.CheckAccess (‘OVR’)"

This sets the button to execute the ValveAPoint’s CheckAccess method when the button is selected. The (‘OVR’) part of the expression instructs the CheckAccess method to detect if the user has the Override permission. If the user has the Override permission, the CheckAccess method returns True; if the user does not have the Override permission, the CheckAccess method returns False. The value returned affects the text that is shown in the text box.

Further Information

For information on the abbreviations for the security permissions, please see ServerObject.CheckAccess in the ClearSCADA Guide to Scripting. The same abbreviations can be used when calling the CheckAccess method.


Expressions Guide - Search Key Tags (Tags)

Search Key Tags

Search Keys are custom database fields that are used to contain strings of characters or numbers. They are used to provide an alternative method of identifying items in the database—items can be identified by a search key value rather than the name of the item. For example, a search key can be created to contain the unique code number of each outstation. If the search key is configured to be a tag, every outstation in the database that has an entry in the search key field can then be referenced by its unique code number. So rather than having to reference an outstation by name in an expression, you can reference it by its code number entry for the search key.

To use the browse button to insert a search key tag, see Selecting a Search Key Tag.

To enter a search key tag manually, see Syntax of Search Key Tags.

Selecting a Search Key Tag

You can use the Select Tag window or Select Historic Tag window to insert a search key tag in your expression.

The Select Tag window is displayed when you:

  • Select the OPC Tag option on the browse button of the Expression window. If you select the OPC Tag option, the Select Tag window shows the search keys for OPC Data (current data).
  • Select the browse button for a field that provides similar functionality to the Expression window.

The Select Tag window lists the search keys for the items in the available ClearSCADA databases and third party OPC DA servers. The search keys are shown in the Search Keys branch.

Search keys are shown in the Search Keys branch.

You can access the various tags for each Search Key. For example, let’s say your system has a Search Key field named Map Reference that is shown on the Point tab of every database point. In the database, a point is configured to have R483 as its value for the Map Reference field. This is unique in the database - no other item can have R483 as its value for the Map Reference field. When you display the Select Tag window, the Search Key list shows R483 as an entry. If you expand R483, you can select any of the OPC property tags associated with that item (these are the property tags of the point that has R483 as its Map Reference value).

The Select Historic Tag window is displayed when you:

  • Select the OPC Historic Tag option on the browse button of the Expression window. If you select the OPC Tag option, the Select Tag window shows the search keys for OPC Data (current data); if you select the OPC Historic Tag option, the Select Tag window shows the search key tags for OPC Historic data.
  • Select the browse button for a field that provides similar functionality to the Expression window.

When you select a search key in the Select Historic Tag window, you can define which historic values you want to use, and what calculation you want ClearSCADA to perform on them. To do this, you can use the Algorithm field to choose the type of calculation, the Start Date to define the earliest value you want to use and the Interval to define the entire range of historic values to be used. For example, if you select a search key named HisAVE and select Average of Values for the Algorithm, H as the Start Date and 1H as the Interval, the expression will return the average value of the item that has HisAVE as its value for the search key. The average value will be calculated using the historic values from the start of the current hour up to the end of the current hour.

To select a search key tag:

  1. Position the cursor at the place in the expression that the tag is to be inserted.
  2. Display the Select Tag window by using the browse button, then expand the 'Search Keys' top level branch and navigate the hierarchical tree-structure to locate the tag you require.
  3. Select the tag.
  4. Select the OK button to confirm your selection and close the Select Tag window.
    The selected tag is inserted in the expression field.

If you wish to enter a search key tag manually, see Syntax of Search Key Tags.

Further Information

Configuring Search Keys: see Extra Database Fields in the ClearSCADA Guide to Server Administration.

Accessing Search Key Tags (OPC Data): see Access Search Key Tags in the ClearSCADA Guide to Core Configuration.

Accessing Search Key Tags (OPC Historic Data): see Access Historic Search Key Tags in the ClearSCADA Guide to Core Configuration.

Syntax of Search Key Tags

The syntax for a search key tag in an expression is similar to that for database items. The only difference is that <Item> is replaced by <Search Key>.

For referencing a database item:

"<Search Key>"

"<Search Key>.<Property>"

"<Search Key>.<Database Aggregate>"

"<Search Key>.<Database Aggregate>.<Property>"

These work in the same way as the Syntax of OPC Property Tags except that the <Search Key> replaces the <Item>.

Example:

"100.CurrentState"

This is a reference to the CurrentState property of the point that has 100 as a search key value.

For calling a method:

"<Search Key>.<Method>( <Argument1>, <Argument2> ... )"

"<Search Key>.<Database Aggregate>.<Method>( <Argument1>, <Argument2> ... )"

These work in the same way as the Method Tags except that the <Search Key> replaces the <Item>.

Example:

"100.GetForecastCount()" calls the GetForecastCount method of the forecast item that has 100 as its search key.

For referencing a historic tag:

"<Search Key>.<Database Aggregate>;<OPC Historic Algorithm>;<Start Time>;<Interval>"

"<Search Key>;<OPC Historic Algorithm>;<Start_Date>;<Interval>"

These work in the same way as the Syntax of an OPC Historic Tag except that the <Search Key> replaces the <Item>.

Example:

"3214.Forecast1;Max;D;1D" is a reference to the maximum value since the start of the current day for the Forecast item that has 3214 as a search key value. The maximum value is calculated from the values stored in the Forecast1 aggregate for the forecast item.

For referencing a historic calculation tag:

"<Search Key>.<Database Aggregate>:<Offset>:<Search Range>:<Maximum Search Range>"

"<Search Key>:<Offset>:<Search Range>:<Maximum Search Range>"

These work in the same way as the syntaxes in Syntax of a Historic Calculation Tag except that the <Search Key> replaces the <Item>.

Example:

"1121:-5M:1H:6H" is a reference to a historic calculation tag where 1121 is a search key value for the source point, -5M is the offset, 1H is the search range and 6H is the maximum search range.


Expressions Guide - Server Status Property Tags (Tags)

Server Status Property Tags

You can use a server status tag to reference a property that is shown on the Server Status Display (see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).

  • To use the browse button to insert a server status tag, see Selecting a Server Status Tag.
  • To enter a server status tag manually, see Syntax of Server Status Tags.

Selecting a Server Status Tag

You can use the Select Tag window to insert a server status tag in your expression.

The Select Tag window is displayed when you:

  • Select the OPC Tag option on the browse button of the Expression window
  • Select the browse button for a field that provides similar functionality to the Expression window.

The Select Tag window lists the server status tags that are available for the ClearSCADA systems (databases). The server status tags are shown in the Server Status branch.

Server Status tags are shown in the Server Status branch.

The top level of server status items represent the tabs on the Server Status Display. Some of the tabs in the Server Status Display are unavailable as they contain information that cannot be referenced (due to the changing locations and IDs of the data).

The items at the next level down represent the keys. These correspond to the rows of the Server Status Display's tabs. For example, the CURDB tab contains Config, Data, and Archive keys. These keys correspond to the 3 rows in the list in the Server Status Display's 'Current DB' tab.

The lowest level items represent the properties that correspond to the columns in the Server Status Display. These contain the specific values that are shown on the Server Status Display.

To select a server status tag:

  1. Position the cursor at the place in the expression that the tag is to be inserted.
  2. Display the Select Tag window by using the browse button, then expand the 'Server Status' top level branch and navigate the hierarchical tree-structure to locate the tag you require. (Each tab in the hierarchy represents a tab on the Server Status Display).
  3. Select the tag.
  4. Select the OK button to confirm your selection and close the Select Tag window.
    The selected tag is inserted in the expression field.

Syntax of Server Status Tags

The syntax for a server status tag is:

"#<Tab>.<Key>.<Property>"

Where:

  • <Tab> is the name of the tab that contains the property that is required
  • <Key> is the key value for the required row in the tab
  • <Property> is the name of the property that you want to reference.

Example:

A text box on a Mimic is to show the number of updates to the server's configuration file. This is shown on the Current DB tab of the Server Status Display (in the Config row in the Updates column).

On the Animations window for the text box, the following expression is entered for the Value property:

"#CURDB.Config.Updates"

Where:

  • CURDB is the name of the tab that contains the required property
  • Config is the key for the row that contains the required value
  • Updates is the name of the property that is required.


Expressions Guide - SCADAPack ES Register Tags (Tags)

SCADAPack ES Register Tags

You can use a SCADAPack ES register tag to reference a SCADAPack ES input or output.

  • To use the browse button to insert a SCADAPack ES register tag, see Selecting a SCADAPack ES Register Tag.
  • To enter a SCADAPack ES register tag manually, see Syntax of SCADAPack ES Register Tags.

Selecting a SCADAPack ES Register Tag

You can use the Select Tag window to insert a SCADAPack ES register tag in your expression.

The Select Tag window is displayed when you:

  • Select the OPC Tag option on the browse button of the Expression window
  • Select the browse button for a field that provides similar functionality to the Expression window.

The Select Tag window lists the SCADAPack ES register tags that are available for the ClearSCADA databases. The SCADAPack ES tags are shown in the Register Spaces branch.

SCADAPack ES register tags are shown in the Register Spaces branch.
Address numbers represent the I/O addresses
Register space names are set automatically

Each register space has a unique name and when you expand the register space, the available input and output address numbers are shown as tags. The register space names are allocated automatically when your ClearSCADA system is connected on SCADAPack ES.

To select a SCADAPack ES register tag:

  1. Position the cursor at the place in the expression that the tag is to be inserted.
  2. Display the Select Tag window by using the browse button, expand the 'Register Space' top level branch, then navigate the hierarchical tree-structure to locate the tag you require.
  3. Select the tag.
  4. Select the OK button to confirm your selection and close the Select Tag window.
    The selected tag is inserted in the expression field.

Syntax of SCADAPack ES Register Tags

A SCADAPack ES register tag has the following syntax:

"@<input/output>.<address>"

Where:

  • <input/output> is the name of the register space
  • <address> is the number of the input or output.

Example:

A text box on a Mimic is to show the value of the SCADAPack ES register for analog input 2. The text box's Value animation property has the following expression:

"@_SCADAPack ESIO_AI.2"

Where:

  • '_SCADAPack ESIO_AI' is the name of the register space
  • 2 is the register's address.


Expressions Guide - OPC Historic Tags (Tags)

OPC Historic Tags

To use an OPC historic tag in an expression, you can either type in the tag manually, or you can use the Select Historic Tag window. An OPC Historic tag calculates a value from a database item that has historic data.

To use the browse button to insert an OPC historic tag, see Selecting an OPC Historic Tag.

To enter an OPC historic tag manually, see Syntax of an OPC Historic Tag.

To reference an OPC historic tag using a search key, see Search Keys for OPC Historic Tags.

Further Information

Configuring Search Keys: see Extra Database Fields in the ClearSCADA Guide to Server Administration.

Accessing Search Key Tags (OPC Historic Data): see Access Historic Search Key Tags in the ClearSCADA Guide to Core Configuration.


Expressions Guide - Selecting an OPC Historic Tag (Tags)

Selecting an OPC Historic Tag

You can use the Select Historic Tag window to insert an OPC Historic Tag in your expression.

The Select Historic Tag window is displayed when you:

  • Select the OPC Historic Tag option on the browse button of the Expression window.
    The name of the selected item is shown here
    Use the Relative check box to set the reference to absolute or relative
    Select the type of calculation that is performed on the data
    Include the data within the range starting from this time (start of the current hour, start of the current day etc.)...
    ...and ending at the start date + the interval (1 hour etc.).
    Use the tree-structure to locate and select the item that you want to reference.

The Select Historic Tag window lists the items that are configured to store data historically in the ClearSCADA database or on a third party OPC HDA server.

To select a historic tag:

  1. Position the cursor at the place in the expression that the tag is to be inserted.
  2. Display the Select Historic Tag window.
  3. Navigate the hierarchical tree structure and select the item that you require.

NOTE: Each Forecast database item can hold between 1 and 8 separate Forecasts. If you use the Select Historic Tag window to specify a Forecast, you need to select one of the eight Forecasts in the hierarchical tree structure.

  4. Use the Relative check box to specify whether the path to the item is relative or absolute. Select the check box for a relative path or clear it for an absolute path (see Relative and Absolute References)
  5. Use the Algorithm combo box to select the calculation (OPC historic algorithm) that is performed on the block of data. For information on the available aggregates, see OPC Historic Aggregates (Algorithms).
  6. Use the Start Date and Interval combo boxes to enter the time range from which the historic data is taken.
  • Start Date—Use the combo box to specify the start date for the block of data that is to be read for the item, or enter your own date in the OPC relative time format, for example H-4H for the data to start from four hours before the beginning of the current hour.
  • Interval—Use the combo box to select a suitable period over which the data is to be read, or enter your own interval in the OPC time format, for example 3H for a three-hour period.

Further Information

OPC Time Formats: see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.

  7. Select the OK button to confirm your selections. The tag is entered in the expression.

If you want to reference an OPC Historic Tag manually in your expression, you will need to adhere to the required syntax (see Syntax of an OPC Historic Tag).


Expressions Guide - Search Keys for OPC Historic Tags (Tags)

Search Keys for OPC Historic Tags

You can use search keys as an alternative to name fields to identify database items. In certain circumstances, using search keys can provide a more effective way of referencing historic tags in your expressions.

Search keys for OPC historic tags work in a similar way to search keys for OPC data tags, see Search Key Tags.

Further Information

Configuring Search Keys: see Extra Database Fields in the ClearSCADA Guide to Server Administration.

Accessing Search Key Tags (OPC Historic Data): see Access Historic Search Key Tags in the ClearSCADA Guide to Core Configuration.


Expressions Guide - Syntax of an OPC Historic Tag (Tags)

Syntax of an OPC Historic Tag

You can use a historic tag to calculate a value from a database item's historic data. The historic tag performs a specific calculation on the item's historic data and returns a single value. A historic tag has the following syntax:

"<Item>.<Database Aggregate>;<OPC Historic Algorithm>;<Start Date>;<Interval>"

"<Item>;<OPC Historic Algorithm>;<Start Date>;<Interval>"

Where:

  • <Item> is the location of the database item. This can be a relative or absolute reference (see Relative and Absolute References)
  • <Database Aggregate> is the name of the database aggregate that contains the historic data that is to be used in the calculation. The <database aggregate> can be any of the historic database aggregates that are available to the database item. A historic database aggregate is an algorithm derived from the CDBHisBase table (see Understanding the Database in the ClearSCADA Guide to the Database).
  • <OPC Historic Algorithm> is the name of the calculation that is to be performed on the historic data (see OPC Historic Aggregates (Algorithms)).
  • <Start Date> is the beginning of the time period for which historic data is taken. The Start Date has to be entered in the OPC relative time format (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).
  • <Interval> is the period of time over which the value is calculated. The interval has to be entered in the OPC time format (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).

Do not enter the angle brackets < > .

NOTE: If the item only has a single historic database aggregate, you can leave out the <Database Aggregate> part of the expression. For example, points only have a single historic database aggregate and so the <Database Aggregate> part of the expression is not required. If there are multiple historic database aggregates, you have to include the <Database Aggregate> so that ClearSCADA knows which database aggregate to use. For example, forecasts have multiple historic database aggregates, so a database aggregate has to be specified in a historic tag to define which forecast is required.

Example:

The following expression is used to animate the Value property of a text box on a Mimic:

".Region.DEC System.AI;Average;H;1H"

The text box displays the average value since the start of the current hour for a point called 'AI'. The 'AI' point is located in a sub-group called 'Region.DEC System'.

The same result could be achieved by entering:

".Region.DEC System.AI.Historic;Average;H;1H"

If the expression was to reference a database item that has multiple historic database aggregates, such as a forecast, the database aggregate part of the expression has to be included. For example, if a text box on a Mimic was animated to show the maximum value since the start of the current day for a forecast called 'D1Forecast', the expression would be:

".Region.DEC System.D1Forecast.Forecast1;Max;D;1D"

Where:

  • Region.DEC System.D1Forecast is the name and location of the forecast
  • Forecast1 is the name of the required database aggregate. Each forecast database item can contain up to eight forecasts and is stored in its own database aggregate. By defining the database aggregate in the expression, you specify which of the eight forecasts are to be used in the calculation, in this case, Forecast1.
  • Max is the name of the OPC historic algorithm (this calculates the maximum value)
  • D defines the start range as the start of the current day
  • 1D defines the duration of the range as 1 day.


Expressions Guide - OPC Historic Aggregates (Algorithms) (Tags)

OPC Historic Aggregates (Algorithms)

OPC historic aggregates are calculations that can be applied to sets of historic data. For example, you can use the 'Max' OPC historic aggregates to calculate the maximum value in a set of historic data.

NOTE: To avoid confusion with database aggregates, we refer to the calculations that can be performed on historic data as historic algorithms. But in the OPC standard, these calculations are called OPC Historic Aggregates.

The following table lists the Algorithm options:

Algorithm Option

Algorithm

Description

1 Hour Moving Average

1hAverage

The average value over an hour period that starts at the beginning of the sample.

24 Hour Moving Average

24hAverage

The average value over a 24 hour period that starts at the beginning of the sample.

8 Hour Moving Average

8hAverage

The average value over an 8 hour period that starts at the beginning of the sample.

Average including last interpolated value

Average Interpolated

The average of the values in the sample. The average includes the interpolated value at the start of the interval.

Average including last value

Average Last

The average of the values in the sample. The average includes the last value reported before the start of the interval.

Average of values

Average

The average value of the values in sample (the sum of the values divided by the number of values).

Count of values

Count

The number of raw values in the sample.

Difference of first and last value

Delta

The last value minus the first value in the block of data. Produces a zero value if both values are the same; a negative value if the last value is smaller than the first; and a positive value if the last value is larger than the first.

Difference of maximum and minimum value

Range

The difference between the maximum value and the minimum value in the sample.

If only one value exists in the sample, a zero value is returned.

Duration in which data is bad

DurBad

The duration (in seconds) of bad data in the sample.

(Values for which the quality is Uncertain are not included.)

Duration in which data is good

DurGood

The duration (in seconds) of good data in the sample.

Interpolated value

Interpolated

This is a calculation to estimate a value that is not included in the sample.

ClearSCADA uses straight line (linear) interpolation to calculate an interpolated value at the start of the specified interval.

ClearSCADA estimates the interpolated value using the last known value before the start of the interval, and the first known value after the start of the interval.

Last value for the data in the interval

End

The last good quality value in the sample (sample).

Maximum including last interpolated value

Max Interpolated

The largest value in the sample (including the interpolated value at the start of the interval).

Maximum including last value

Max Last

The largest value in the sample (including the last known value before the start of the interval).

Maximum value

Max

The largest value within the sample.

Maximum value and time stamp

MaxTime

The largest value within the sample. The value is time stamped with the time at which it occurred. (The time is not displayed on Mimics or Data Grids, etc.)

Minimum including last interpolated value

Min Interpolated

The smallest value within the sample, including the interpolated value at the start of the interval.

Minimum including last value

Min Last

The smallest value within the sample, including the last known value before the start of the interval.

Minimum value

Min

The smallest value within the sample.

Minimum value and time stamp

MinTime

The smallest value within the sample. The value is time stamped with the time at which it occurred. (The time is not displayed on Mimics or Data Grids, etc.)

Percent in which data is bad

PerBad

The percentage of the data interval during which the quality of data is Bad.

Percent in which data is good

PerGood

The percentage of the data interval during which the quality of data is Good.

(1 = 100%)

Standard deviation of values

StdDev

The 'spread' of the values about their mean value.

Stepped analog

Stepped

Returns the last value before the start of the specified interval. This aggregate is included for backwards compatibility with old-style Graphs.

Sum of values

Sum

The sum of the historic values in the sample.

Time-weighted average

TimeAverage

An average value for the sample, taking into consideration the amount of time the data source remained in each value.

Totalized value (Time Integral)

Total

The totalized value of the data in the sample.

Value at end of the interval

End

The last value in the sample.

Value at start of the interval

Start

The first value in the sample.

Variance of values

Variance

The square of the standard deviation of the values.

For more information on how the algorithms are calculated, which values are included in a sample, and how time stamps are applied to processed historic values, see Built-In Historic Algorithms for Processed Historic Data in the ClearSCADA Guide to Trends.

Example: Referencing an OPC Historic Tag in an Expression

The tag for calculating the average value of an analog point, AIP4 within the group 'SCADAPack Modbus Direct' (itself within the group 'SCADAPack Modbus Group'), over a 2-hour period, starting three hours ago is:

"SCADAPack Modbus Group.SCADAPack Modbus Direct.AIP4;Average;H-3H;2H"

You can enter this tag manually, by typing it into the Expression window, or you can use the Select Historic Tag window to locate the data source and specify the required parameters for the tag.


Expressions Guide - Historic Calculation Tags (Tags)

Historic Calculation Tags

Historic calculations are used to evaluate an expression at defined intervals over a specified time sample. For example, in the water industry, historic calculations are used to calculate the level of a river at a specific location. This is achieved by having the historic calculation use the historic data from two points that are connected to level sensors. In its expression, the historic calculation uses the two inputs and the distance between the sensors and the location in the river for which an estimated level is required. The result of the calculation provides an estimated level for the required location and this value is stored by a forecast. The forecast can then be used to raise an alarm or trigger an event if the estimated value is above or below appropriate limits.

The results of historic calculations can be used by forecasts or stored in target points. For more information, see Configuring Historic Calculations in the ClearSCADA Guide to Core Configuration.

You can use the Select Historic Calculation Tag window to select the source point or forecast, time offset, and quality windows for a historic calculation's expression (see Selecting a Historic Calculation Tag).

The source point or forecast is shown here
Use the tree-structure to locate and select the source point or forecast.
Use to specify any time stamp offsets
Use to specify the time period for good quality values
Use to specify the time period for uncertain quality values
Use the Relative check box to set the reference to absolute or relative

Alternatively, you can enter the tag manually (see Syntax of an OPC Historic Tag).


Expressions Guide - Selecting a Historic Calculation Tag (Tags)

Selecting a Historic Calculation Tag

You can use the Select Historic Calculation Tag window to select the source point or forecast (the input) for the historic calculation's expression. You can also use it to define the time offset that affects the start time for the sample, and the times for the 2 quality windows (there are 2 time windows that the historic calculation uses to determine if the values from the source are good quality, uncertain quality, or bad quality).

The Select Historic Calculation Tag window is only available via the browse button for the Expression field on the Historic Calculation tab of the Historic Calculation Form.

To select the source point or forecast for a historic calculation:

  1. Display the Historic Calculation Form, then select the Historic Calculation tab.
  2. Position the cursor at the place in the expression that the tag is to be inserted.
  3. Select the browse button next to the Expression field and select the Historic Calculation Tag option to display the Select Historic Calculation Tag window.
  4. Expand the list to locate the point or forecast that is a source point for the historic calculation (a point or forecast that has historic data that is used in the historic calculation's expression).
  5. Select the point or forecast. If you select a forecast, you need to expand the forecast item and then choose one of the 8 forecasts. Each forecast item can contain up to 8 forecasts, each of which are stored in separate historic database aggregates. You need to select the database aggregate that contains the historic data that is to be used in the calculation.
  6. Use the Relative check box to define whether the reference to the point or forecast is absolute or relative. Select the check box for a relative reference; clear it for an absolute reference (see Relative and Absolute References).
  7. Use the Offset combo box to specify any time stamp adjustments that ClearSCADA is to apply to the Target value. Typically, you will need to use a negative time value, as the values for the target point are based on historic values from another point. For example, if the values for the target point were calculated from another point's values 1 hour in the past, the offset would be -1H. This would mean that the value of the source point at 09:00 would be used to calculate the value of the target point at 10:00, the value of the source point at 09:15 would be used to calculate the value of the target point at 10:15 and so on. When the value of the target point for the actual current time has been calculated, any further calculated values will be estimated values. For example, if the current time is 10:30, the value for the target point at 10:45 will be an estimated value that is calculated using the value of the source point at 09:45.

Positive offset values also alter the time range in which the historic calculation looks for a source value. However, positive offset values cause the historic calculation to use a source value with a time stamp after the time for the target point value. For example, if the target value needs to be calculated at 15:25 and the offset is +10M, the historic calculation will use the source point's value at 15:35 to calculate the value of the target point.

If the offset is set to 0, the time stamp for the target value is the same as the time stamp of the source value.

  8. Use the Search Range and Max Search Range combo boxes to specify the time period for good quality and uncertain quality values.

The historic calculation is set to calculate a value for the target point at a set interval. This means that the historic calculation looks for a source value with the time stamp for the time at which the expression is evaluated. There may not be a source value for this specific time, and so the historic calculation will look for a source value in the past.

The Max Search Range setting defines the maximum amount of time in which the historic calculation will look for a source value. For example, if the historic calculation is attempting to calculate a value at 10:00 and the Max Search Range is set to 1H, the historic calculation can look for a source value in the period 09:00 - 10:00 (1 hour before 10:00).

The Search Range setting defines a time period within the Max Search Range. If a source value is available within the Search Range period, the source value is deemed to have Good quality data. The historic calculation will use the latest source value that has been time stamped before the time that the expression is to be evaluated.

If there are no source values within the Search Range period, the historic calculation will look for a source value in the remaining part of the Max Search Range period. If it uses a source value from the remaining part of the Max Search Range period, the value is deemed to have Uncertain quality. If the historic calculation has to look in the Max Search Range for a source value, it will use the latest usable value.

If the historic calculation cannot locate a source value in the Search Range or the Max Search Range, it will not be able to calculate a value as the values outside the defined ranges are regarded as Bad quality.

If the historic calculation is unable to locate a value with good or uncertain quality, it will not return a value for the target point for that time. This means there will be a reduced number of records for the target point which can result in gaps in forecasted data.

NOTE: The Search Range has to be a shorter time than the Max Search Range.

  9. When you have selected a source point or forecast, offset, search range, and max search range, select the OK button.
    The Select Historic Calculation Tag window is closed and the tag is entered in the expression.
  10. Repeat steps 2-9 inclusive for any other source points or forecasts that are used in the expression for the historic calculation.

When you have selected the tags for the historic calculation's expression, you can continue to use the Historic Calculation Form to configure the expression and the other Historic Calculation settings.

For more information on Historic Calculations, please refer to the ClearSCADA Guide to Core Configuration.


Expressions Guide - Syntax of a Historic Calculation Tag (Tags)

Syntax of a Historic Calculation Tag

A historic calculation tag has the following syntax:

"<Item>.<Database Aggregate>:<Offset>:<Period>:<Maximum Period>"

"<Item>:<Offset>:<Period>:<Maximum Period>"

Where:

  • <Item> is the location of the source point or forecast. This can be a relative or absolute reference (see Relative and Absolute References)
  • <Database Aggregate> is the name of the database aggregate that contains the historic data that is to be used in the calculation. The <database aggregate> can be any of the historic database aggregates that are available to the database item. A historic database aggregate is an aggregate derived from the CDBHisBase table (see Understanding the Database in the ClearSCADA Guide to the Database).

NOTE: If the item only has a single historic database aggregate, you can leave out the <Database Aggregate> part of the expression For example, points only have a single historic database aggregate and so the <Database Aggregate> part of the expression is not required. If there are multiple historic database aggregates, you have to include the <Database Aggregate> so that ClearSCADA knows which database aggregate to use. For example, forecasts have multiple historic database aggregates, so a database aggregate has to be specified in a historic tag to define which forecast is required.

  • <Offset> is any time stamp adjustment (see Selecting a Historic Calculation Tag). The <Offset> must be entered in the OPC time format (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).
  • <Period> is the search range (see Selecting a Historic Calculation Tag). The <Period> must be entered in the OPC time format (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).
  • <Maximum Period> is the maximum search range (see Selecting a Historic Calculation Tag). The <Maximum Period> must be entered in the OPC time format (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).

Do not enter the angle brackets <>.

Example:

The flow of gas in a pipe is measured by two points:

  • 'Point 1'—This point stores data for a signal that has a range of 0-20. When the gas flow is less than 20, the data from this point is regarded as more accurate than the data from 'Point 2'.
  • 'Point 2'—This point stores data for a signal that has a range of 0-200. When the gas flow is equal to or greater than 20, this point is regarded as being more accurate than 'Point 1'.

A historic calculation is used to produce 3 days' worth of historic data based on the values from the two points. The historic calculation is named 'PipeFlow' and calculates the values at 15 minute intervals. It is configured to have a 'target' point named 'Flow'.

The 'Flow' point is an analog point that stores the result of the 'PipeFlow' historic calculation. It has a range of 0-200.

The historic calculation and the points are stored in the same group.

When the flow of gas is lower than 20, the historic calculation is to base its calculations on the values from 'Point 1'. When the flow of gas is 20 or higher, the historic calculation is to base its calculations on the values from 'Point 2'. The results of the calculations are stored by the 'Flow' point. To achieve this, the following expression is defined for the 'PipeFlow' historic calculation:

IIF (".Point 2:0:15M:30M" <20, ".Point 1:0:15M:30M", ".Point 2:0:15M:30M")

Where:

  • The IIF function is used to test the value of a point. In this case, if the 'Point 2' value is less than 20, the historic calculation will use the value from 'Point 1'. If the 'Point 2' value is 20 or more, the historic calculation will use the value from 'Point 2'.
  • The first expression:

".Point 2:0:15M:30M" <20

This compares the value of 'Point 2' against the number 20.

  • The second expression:

".Point 1:0:15M:30M"

defines the value that is to be used by the historic calculation when the first expression is TRUE.

  • The third expression:

".Point 2:0:15M:30M"

defines the value that is to be used by the historic calculation when the first expression is FALSE.

  • Each tag (within the entire expression) consists of:

<Item>:<Offset>:<Period>:<Maximum Period>

For example, the first tag has:

The Search Range setting defines a time period within the Max Search Range. If a source value is available within the Search Range period, the source value is deemed to have Good quality data. The historic calculation will use the latest source value that has been time stamped before the time that the expression is to be evaluated.

If there are no source values within the Search Range period, the historic calculation will look for a source value in the remaining part of the Max Search Range period. If it uses a source value from the remaining part of the Max Search Range period, the value is deemed to have Uncertain quality. If the historic calculation has to look in the Max Search Range for a source value, it will use the latest usable value.


Expressions Guide - Indirect Tags (Tags)

Indirect Tags

Indirect tags are tags that represent a property that derives its value from another tag. For example, an indirect tag can be used to represent the current value property, but for different database items.

A common use of indirect tags is to allow a Mimic to display certain properties, with the data source of those properties changing when a user selects a button. For example, in the electricity industry, a Mimic is often configured to present the data for the three phases of an electricity system. The Mimic shows the values for 1 phase at a time, with indirect tags being used to allow users to switch the data source from phase 1 items, to phase 2 or phase 3 items at the press of a Mimic button.

When using indirect tags, there are two factors to consider:

  • The indirect tag feature is designed to provide users with a way of changing the data source for a Mimic item. For example, a Mimic could use an indirect tag to animate a text box to show the current value of an item. The item that is used as the data source changes when a user selects an animated button.

Indirect tags are designed to have their data source changed by user interaction. This is because users are unlikely to change the data source excessively; frequent changes or updates to the data source for an indirect tag can place a high load on the system and cause slower system performance.

For this reason, you should avoid using indirect tags that reference properties that update frequently and automatically. For example, during communications, the CurrStatsMessages tag of a channel updates frequently and automatically. As a result, if an indirect tag references the CurrStatsMessages tag, it means that when the channel is being used for communications, the indirect tag will also have to update its value frequently. This can place a high load on the system and could affect system performance.

  • If you are configuring an embedded Mimic that uses indirect tags to reference Mimic parameters, you have to disable the Shared with other Embedded Mimics setting. If you enable the setting, the tags in the OPC group will update frequently and may cause slow system performance.

To use an indirect tag, you have to enclose the expression that is used to provide the values for the tag in square brackets [ ]. The expression can include any of the expression functions and has to define a valid OPC tag.The result of the expression within the square brackets is used to define the source of the value for the tag.

Example: Using Indirect Tags to Toggle the Values shown on a Mimic

The temperature in a control room is measured by two sensors. One sensor measures the temperature in Celsius and the other measures in Fahrenheit. Both of these sensors are represented by points in the ClearSCADA database (named 'Celsius' and 'Fahrenheit' respectively).

A Mimic contains a text box that displays the temperature of the control room. There is a button on the Mimic that toggles the text box so that it displays the value for the 'Celsius' point or the value for the 'Fahrenheit' point. This is achieved by using an indirect tag in an animation. The indirect tag allows the text box to show the CurrentValue property, but for different points.

The text box uses this animation expression for its Value property:

[IIF("Indirect Tags Group.Units.CurrentState" =0,'Indirect Tags Group.Celsius','Indirect Tags Group.Fahrenheit') +'.CurrentValue']

This animation instructs ClearSCADA to calculate the result of the expression and then use that result as the source of the value that is shown in the text box. The square brackets [] instruct ClearSCADA to use an indirect tag so the result of the expression defines the source of the value for the animation property. If the square brackets were not included, the result of the expression would be used as the actual value for the animation property.

In this case, ClearSCADA determines that if the CurrentState value of the 'Units' point (which is stored in a Group named 'Indirect Tags Group') is 0, then the result is the value that is stored in the CurrentValue tag for the 'Celsius' point. If the CurrentState value of the 'Units' point is anything other than 0, the result is the value that is stored in the CurrentValue tag for the 'Fahrenheit' point.

So, if the 'Celsius' point has a current value of 15 and the 'Units' point is in state 0, the text box displays the value that is stored in the CurrentValue tag of the 'Celsius' point i.e. it displays 15.

Text box shows the value stored in the CurrentValue tag of the 'Celsius' point.
The state of the 'Units' point determines whether the text box shows the value in the CurrentValue tag of the 'Celsius' point or the 'Fahrenheit' point.

If the 'Units' point is in state 1, the text box displays the value that is stored in the CurrentValue tag of the 'Fahrenheit' point i.e. it displays 59.

To allow the user to toggle between Celsius and Fahrenheit, a button on the Mimic is configured to have a method pick action that changes the state of the 'Units' point. So, when the button is pressed, it toggles the state of the 'Units' point and in turn, this toggles the value that is shown in the text box. The Text property of the button is also animated so that it shows 'Celsius' if the 'Units' point is in state 0 or 'Fahrenheit' if the 'Units' point is in state 1.


Expressions Guide - Mimic Parameters (Tags)

Mimic Parameters

You can use Mimic parameters in an expression. They are needed when you are creating embedded Mimics that need to be generic i.e. symbol Mimics that are not associated with any particular database item. For more information, see Parameters in the ClearSCADA Guide to Mimics.

Example:

An embedded Mimic called 'Quality Display' is created. It has a parameter called CurrentQualityDesc that is associated with the Value property of a text box. The following expression is used to animate the Value property:

"Parameter:CurrentQualityDesc"

The 'Quality Display' Mimic is embedded on another Mimic. The CurrentQualityDesc property of a point named 'AI1' is associated with the parameter of the embedded 'Quality Display' Mimic. The CurrentQualityDesc value of the 'AI1' point is displayed in the text box.

You can use the browse button in the Expression window to insert a parameter in your expression (see Selecting a Parameter). Alternatively, you can enter the parameter manually (see Syntax of a Mimic Parameter Tag).


Expressions Guide - Selecting a Parameter (Tags)

Selecting a Parameter

To insert a parameter in an expression:

  1. On an Expression display for the Mimic, move the cursor to the position in the expression where the parameter will be entered.
  2. Select the browse button to display a context sensitive menu.

Each of the Mimic's parameters are shown in the menu (between the options for tags and colors). If the Mimic has no parameters, there are no parameter options shown.

  3. Select the option for the required parameter, for example, if you want to insert a parameter named 'CurrentStateDesc', select the CurrentStateDesc option.
  4. Select the OK button to close the Expression display and confirm your selection.

For information on entering a parameter manually, see Syntax of a Mimic Parameter Tag.


Expressions Guide - Syntax of a Mimic Parameter Tag (Tags)

Syntax of a Mimic Parameter Tag

When configuring Mimics that have parameters, you can include references to the Mimic's parameters in your expressions.

A Mimic parameter tag has the following syntax:

"Parameter:<Parameter Name>"

"Parameter:<Group>.<Parameter Name>"

Where:

<Group> is the name of the parameter group that contains the parameter. This is not required if the parameter is not in a group. Each hierarchical level in the groups have to be separated by a period.

<Parameter Name> is the name of the parameter that you are referencing.

In each case, do not enter the angle brackets < >.

Example:

A Mimic named 'Title 1' contains a text box. The text box contains the words 'Main Valve'. A parameter is created for the Mimic. The parameter is named 'AlarmState' and it is associated with the text box. On the Animations window for the text box, the following expression is used to animate the Pen.FillColour property of the text box:

IIF("Parameter:AlarmState"=0, RGB(0,255,0),RGB(255,0,0))

This expression sets the text box to display its contents in red or green depending on the AlarmState value of any database item that is associated with the parameter. If the item's alarm state value is 0 (normal), the text will be displayed in green. If the item's alarm state is 1, 2, 3, or 4, the text will be displayed in red.


Expressions Guide - Functions

Functions

This section provides information about the functions that are available for use in your expressions.

Before you use a function in an expression, you should be familiar with the expression grammar, required syntaxes etc. (see Grammar for Expressions).

The functions that you can use in your expressions are grouped into these categories:

  • Numeric Functions
  • ABS—Returns the absolute value of a number.
  • ACOS—Returns the inverse Cosine (radians) of a number.
  • ASIN—Returns the inverse Sine (radians) of a number.
  • ATAN—Returns the inverse Tangent (radians) of a number.
  • AVERAGE—Returns the mean average of a set of numbers.
  • COS—Returns the Cosine (radians) of a number.
  • COSH—Returns the Hyperbolic Cosine of a number.
  • DEG—Converts radians to degrees.
  • EXP—Returns the base of a natural logarithm raised to a power (en)
  • FIX—Rounds a floating point value down to the nearest integer value.
  • INT—Returns a number as an integer.
  • LOG—Returns the natural logarithm of an input number as a real value.
  • LOG10—Returns the natural logarithm to base 10 of an input number as a real value.
  • MAX—Returns the highest value in a set of values.
  • MIN—Returns the lowest value in a set of values.
  • PI—Returns the value of pi as a real value.
  • POW—Raises a number to the power of another number.
  • PRODUCT—Returns the product of a set of values.
  • RAD—Converts degrees into radians.
  • ROUND—Returns a number rounded to a specified number of decimal places.
  • SIN—Returns the Sine (radians) of a number.
  • SINH—Returns the Hyperbolic Sine of a number.
  • SQRT—Returns the square root of a number.
  • SUM—Returns the sum total of a set of numbers.
  • TAN—Returns the Tangent (radians) of a number.
  • TANH—Returns the Hyperbolic Tangent of a number.
  • String Functions
  • CHR—Allows formatting characters to be included in an expression.
  • FORMATVAL—Applies formatting to a value and returns the result as a string value.
  • INSTRING—Returns a number that indicates the position of a substring in a string.
  • LEFT—Returns a specified number of characters starting from the left of an input string.
  • LEN—Returns the number of characters in an input string as a real value.
  • MID—Returns a specified number of characters from an input string.
  • RIGHT—Returns a specified number of characters starting from the right of an input string.
  • STR—Returns the string equivalent of a value.
  • Miscellaneous Functions
  • ARRAYELEMENT—Returns the value of a specified element in an array database item
  • EXISTS—Checks that items referenced in arguments exist in the database before a value is returned
  • HEAD—Returns the number of the head on which the Mimic or Trend is being displayed
  • IIF—Tests a condition and returns one of two values depending on whether the condition is true or false
  • LINK—Modifies a URL returned as a property of a database item so that the URL contains the system on which the database item is stored
  • LOCALE—Returns the locale of the currently logged on user as an integer value
  • LOOKUP—Returns the nth expression from a set of expressions
  • REGISTRY—Returns a specified value from the Windows registry
  • RGB—Returns a color
  • TIME—Evaluates an OPC relative time
  • USERNAME—Returns the name of the user account being used by the currently logged on user.

NOTE: Many functions have arguments that need to be of a certain data type. If you use the wrong data type for an argument, ClearSCADA will try to convert the argument into the correct data type. For example, if you define a REAL value when a BOOL is required, ClearSCADA will try to convert the REAL into a BOOL. In the case of a string argument, the content of the string determines whether the conversion is successful. For example, if the required data type is Integer, but you define a string argument as “1234”, the argument will work successfully. This is because ClearSCADA can convert the content of the string into an Integer value successfully (the content of the string matches a valid value for the required data type).


Expressions Guide - Numeric Functions (Functions)

Numeric Functions

The numeric functions include common mathematical functions. The numeric functions supported by ClearSCADA are:

  • ABS—Returns the absolute value of a number.
  • ACOS—Returns the inverse Cosine (radians) of a number.
  • ASIN—Returns the inverse Sine (radians) of a number.
  • ATAN—Returns the inverse Tangent (radians) of a number.
  • AVERAGE—Returns the mean average of a set of numbers.
  • COS—Returns the Cosine (radians) of a number.
  • COSH—Returns the Hyperbolic Cosine of a number.
  • DEG—Converts radians to degrees.
  • EXP—Returns the base of a natural logarithm raised to a power (en)
  • FIX—Rounds a floating point value down to the nearest integer value.
  • INT—Returns a number as an integer.
  • LOG—Returns the natural logarithm of an input number as a real value.
  • LOG10—Returns the natural logarithm to base 10 of an input number as a real value.
  • MAX—Returns the highest value in a set of values.
  • MIN—Returns the lowest value in a set of values.
  • PI—Returns the value of pi as a real value.
  • POW—Raises a number to the power of another number.
  • PRODUCT—Returns the product of a set of values.
  • RAD—Converts degrees into radians.
  • ROUND—Returns a number rounded to a specified number of decimal places.
  • SIN—Returns the Sine (radians) of a number.
  • SINH—Returns the Hyperbolic Sine of a number.
  • SQRT—Returns the square root of a number.
  • SUM—Returns the sum total of a set of numbers.
  • TAN—Returns the Tangent (radians) of a number.
  • TANH—Returns the Hyperbolic Tangent of a number.


Expressions Guide - ABS (Functions)

ABS

The ABS function is a mathematical function. It returns the absolute value of a number.
Function Name | ABS
Description | Provides the absolute value of a number.
Arguments | ABS(INTEGER or REAL) The ABS function can have one input and this can be either an integer or a real floating value—see Number (Integer or Real).
Returns | Absolute {Same type as input} The absolute value of the input. The output value is of the same type as the input value (integer or real).

Example:

ABS(-44)

The output is 44.


Expressions Guide - ACOS (Functions)

ACOS

The ACOS function is a mathematical function that returns the inverse Cosine (radians) of a number. The ACOS function returns a real value.
Function Name | ACOS
Description | Returns the inverse Cosine (radians) of a number.
Arguments | ACOS(INTEGER or REAL) The ACOS function can have one input and this can be either an integer or a real floating value—see Number (Integer or Real).
Returns | REAL The inverse Cosine (radians) value of the input.

Example:

ACOS( -1 )

The output is PI (3.1415926...)

See also:

ASIN

ATAN.


Expressions Guide - ASIN (Functions)

ASIN

The ASIN function is a mathematical function that returns the inverse Sine (radians) of a number. The ASIN function returns a real value.
Function Name | ASIN
Description | Returns the inverse Sine (radians) of a number.
Arguments | ASIN(INTEGER or REAL) The ASIN function can have one input and this can be either an integer or a real floating value—see Number (Integer or Real).
Returns | REAL The inverse Sine (radians) value of the input.

Example:

ASIN(1)

The output is 1.57.

See also:

ACOS

ATAN


Expressions Guide - ATAN (Functions)

ATAN

There are 2 types of ATAN function:

  • ATAN (Inverse Tangent)
  • ATAN (Angle From X-Axis to a Point).

ATAN (Inverse Tangent)

The ATAN function is a mathematical function that returns the inverse Tangent (radians) of a number. The ATAN function returns a real value.
Function Name | ATAN
Description | Returns the inverse Tangent (radians) of a number.
Arguments | ATAN(INTEGER or REAL) The ATAN function can have one input and this can be either an integer or a real floating value—see Number (Integer or Real).
Returns | REAL The inverse Tangent (radians) value of the input.

Example:

ATAN(1)

The output is 0.785

See also:

ACOS

ASIN

PI.

ATAN (Angle From X-Axis to a Point)

The ATAN function is a mathematical function that returns the angle (in radians) from the x-axis to a point (y,x). This is sometimes referred to as ATAN2.

Function Name

ATAN (also known as ATAN2).

Description

Returns the angle from the x-axis to a point (y, x).

Arguments

ATAN(Y, X)

Where Y is a REAL or INTEGER that represents a cartesian y co-ordinate, and X is a REAL or INTEGER that represents a cartesian x co-ordinate. For information on integers and real floating values—see Number (Integer or Real).

When there are 2 inputs (y and x), the result is equivalent to y divided by x. ATAN (y, x) is equivalent to ATAN (y/x).

Returns

REAL

The output is the angle (in radians) from the x-axis to a point (y,x)

Example:

ATAN(20, 3)

The output is 1.42 or the angle (in radians) from the x-axis to a point (y,x).


Expressions Guide - AVERAGE (Functions)

AVERAGE

The AVERAGE function is a mathematical function that returns the mean average of a set of values. The average value is a real value.
Function Name | AVERAGE.
Description | Returns the mean average of a set of values. There is an AVERAGE extension for use with Data Grids (see below).
Arguments | AVERAGE(INTEGER or REAL, INTEGER or REAL, INTEGER or REAL...) The values in the set of values have to be separated by commas and they can be integers or real floating values. For information on integers and real floating values—see Number (Integer or Real).
Returns | The mean average of the set of input values. The data type is the same as that of the input values (integer or real).

Example:

AVERAGE(2, 3, 4, 1)

The output is 2.5.

AVERAGE Extension for Data Grids Only

The AVERAGE function has been extended for use with Data Grids. It can support blocks of cells (arrays) as well as numerical values. This means that you can use fields and rows instead of numerical values in the AVERAGE function (or you can use a combination of blocks, single cells and numbers as required).

Syntax

AVERAGE(<Field1><Row1>, <Field2><Row1>, <Field3><Row1>...)

Where <Field1><Row1> is the name of a field in a row, <Field2><Row1> is the name of another field in the row and so on. Do not enter the angle brackets < >.

For blocks of cells, you have to define the first field and row and the last field and row in the range and separate them with a colon:

AVERAGE(<FirstFieldinRange><FirstRowinRange>:<LastFieldinRange><LastRowinRange>)

NOTE: You can enter the last field first and the first field last if required—ClearSCADA will still recognize the required range.

Examples of AVERAGE when used with Data Grids:

AVERAGE(A1:B9)

Where A1 defines the first cell to be used and B9 defines the last cell to be used. The AVERAGE function will use the data from the cells between the A1 cell and the B9 cell in its calculation. If we assume that A1 is the first cell in a field named A and B9 is the 9th cell in a field named B, the AVERAGE function will use the values from the cells in field A and the values from cells 1-9 inclusive from field B in its calculation.

AVERAGE(A1:B9, 3, 75, C6, C8, D11)

Where A1:B9 defines a block of cells (the cells between the A1 cell and the B9 cell), 3 and 75 define numerical values, C6, C8, and D11 define individual cells. The AVERAGE function will use the numerical values and the values from the defined cells (including the cells in the block) in its calculation.


Expressions Guide - COS (Functions)

COS

The COS function is a mathematical function that returns the Cosine (radians) of a number. The COS function returns a real value.
Function Name | COS
Description | Returns the Cosine (radians) of a number.
Arguments | COS(INTEGER OR REAL) The value can be an integer or a real floating value—see Number (Integer or Real).
Returns | The Cosine (radians) of a number. This is of the same type as the input (INTEGER or REAL).

Example:

COS( PI() )

The output is -1.

See also:

SIN

TAN.


Expressions Guide - COSH (Functions)

COSH

The COSH function is a mathematical function that returns the Hyperbolic Cosine of a number. The COSH function returns a real value.
Function Name | COSH
Description | Returns the Hyperbolic Cosine of a number.
Arguments | COSH(INTEGER OR REAL) The value can be an integer or a real floating value—see Number (Integer or Real).
Returns | The Hyperbolic Cosine of a number. This is of the same type as the input (INTEGER or REAL).

Example:

COSH(PI())

The output is 11.59.

See also:

SINH

TANH.


Expressions Guide - DEG (Functions)

DEG

The DEG function is a mathematical function that converts radians to degrees. It returns a real value.
Function Name | DEG
Description | Converts radians to degrees.
Arguments | DEG(INTEGER OR REAL) The radian value can be an integer or a real floating value—see Number (Integer or Real).
Returns | The value in degrees. This is a REAL value.

Example:

DEG( PI() )

The output is 180

See also:

RAD.


Expressions Guide - EXP (Functions)

EXP

The EXP function is a mathematical function that returns the base of natural logarithm raised to a power (en).
Function Name | EXP
Description | Returns the base of a natural logarithm raised to a power (en)
Arguments | EXP(INTEGER or REAL) The input value can be an integer or a real floating value—see Number (Integer or Real).
Returns | INTEGER or REAL (same data type as input).

Example:

EXP(2)

The output is 7.39

See also:

LOG

LOG10.


Expressions Guide - FIX (Functions)

FIX

The FIX function is a mathematical function that rounds a floating point number down to the nearest integer.
Function Name | FIX
Description | Rounds a floating point value down to the nearest integer value.
Arguments | FIX(REAL) The input value is a real floating value—see Number (Integer or Real).
Returns | INTEGER The nearest rounded down integer value to the input real value.

Examples:

FIX(1.735)

The output is 1.

FIX (8.5)

The output is 8

FIX(-8.5)

The output is -9.

See also:

INT.


Expressions Guide - INT (Functions)

INT

The INT function is a mathematical function that returns the integer version of a number. It removes the fractional part of the value, for example, INT (8.5) = 8.
Function Name | INT
Description | Returns the integer version of a number and removes any fractional part of the value.
Arguments | INT(INTEGER or REAL) For more information, see Number (Integer or Real)
Returns | INTEGER. The returned value is the input value as an integer with any fractional part of the value removed.

Examples:

INT(10)

The output is 10.

INT(10.74)

The output is 10.

See also:

FIX.


Expressions Guide - LOG (Functions)

LOG

The LOG function is a mathematical function that returns the natural logarithm of a number as a real value.
Function Name | LOG
Description | Returns the natural logarithm of an input number as a real value.
Arguments | LOG(INTEGER or REAL) The input number has to be greater than 0. For more information, see Number (Integer or Real).
Returns | REAL The natural logarithm value of the input number.

Example:

LOG(2)

The output is 0.69

See also:

EXP

LOG10.


Expressions Guide - LOG10 (Functions)

LOG10

The LOG10 function is a mathematical function that returns the logarithm to the base 10 of a number.
Function Name | LOG10
Description | Returns the logarithm to base 10 of an input number.
Arguments | LOG10(INTEGER or REAL) The input number has to be greater than 0. For more information, see Number (Integer or Real).
Returns | INTEGER or REAL The logarithm to base 10 of the input number.

Example:

LOG10 (2)

The output is 0.3

See also:

EXP

LOG


Expressions Guide - MAX (Functions)

MAX

The MAX function is a mathematical function that returns the highest value in a set of values. The highest value is a real value.
Function Name | MAX
Description | Returns the highest value from a set of values.
Arguments | MAX(INTEGER or REAL, INTEGER or REAL, INTEGER or REAL...) The values in the set of values has to be separated by commas and they can be integers or real floating values. For information on integers and real floating values—see Number (Integer or Real). There is a MAX extension for use with Data Grids only (see below).
Returns | The highest value in a set of input values. The data type is the same as that of the input values (integer or real).

Example:

MAX(2, 3, 4, 1)

The output is 4.

MAX Extension for Data Grids Only

The MAX function has been extended for use with Data Grids. It can support blocks of cells (arrays) as well as numerical values. This means that you can use fields and rows instead of numerical values in the MAX function (or you can use a combination of blocks, single cells and numbers as required).

Syntax

MAX(<Field1><Row1>, <Field2><Row1>, <Field3><Row1>...)

Where <Field1><Row1> is the name of a field in a row, <Field2><Row1> is the name of another field in the row and so on. Do not enter the angle brackets < >.

For blocks of cells, you have to define the first field and row and the last field and row in the range and separate them with a colon:

MAX(<FirstFieldinRange><FirstRowinRange>:<LastFieldinRange><LastRowinRange>)

NOTE: You can enter the last field first and the first field last if required—ClearSCADA will still recognize the required range.

Examples:

MAX(A1:B9)

Where A1 defines the first cell to be used and B9 defines the last cell to be used. The MAX function will use the data from the cells between the A1 cell and the B9 cell in its calculation. If we assume that A1 is the first cell in a field named A and B9 is the 9th cell in a field named B, the MAX function will use the values from the cells in field A and the values from cells 1-9 inclusive from field B in its calculation.

MAX(A1:B9, 3, 75, C6, C8, D11)

Where A1:B9 defines a block of cells (the cells between the A1 cell and the B9 cell), 3 and 75 define numerical values, C6, C8, and D11 define individual cells. The MAX function will use the numerical values and the values from the defined cells (including the cells in the block) in its calculation.


Expressions Guide - MIN (Functions)

MIN

The MIN function is a mathematical function that returns the lowest value in a set of values. The lowest value is a real value.
Function Name | MIN
Description | Returns the lowest value from a set of values.
Arguments | MIN(INTEGER or REAL, INTEGER or REAL, INTEGER or REAL...) The values in the set of values have to be separated by commas and they can be integers or real floating values. For information on integers and real floating values—see Number (Integer or Real). There is a MIN extension for use with Data Grids only (see below).
Returns | The lowest value in a set of input values. The data type is the same as that of the input values (integer or real).

Example:

MIN(2, 3, 4, 1)

The output is 1.

MIN Extension for Data Grids Only

The MIN function has been extended for use with Data Grids. It can support blocks of cells (arrays) as well as numerical values. This means that you can use fields and rows instead of numerical values in the MIN function (or you can use a combination of blocks, single cells and numbers as required).

Syntax

MIN(<Field1><Row1>, <Field2><Row1>, <Field3><Row1>...)

Where <Field1><Row1> is the name of a field in a row, <Field2><Row1> is the name of another field in the row and so on. Do not enter the angle brackets < >.

For blocks of cells, you have to define the first field and row and the last field and row in the range and separate them with a colon:

MIN(<FirstFieldinRange><FirstRowinRange>:<LastFieldinRange><LastRowinRange>)

NOTE: You can enter the last field first and the first field last if required—ClearSCADA will still recognize the required range.

Examples:

MIN(A1:B9)

Where A1 defines the first cell to be used and B9 defines the last cell to be used. The MIN function will use the data from the cells between the A1 cell and the B9 cell in its calculation. If we assume that A1 is the first cell in a field named A and B9 is the 9th cell in a field named B, the MIN function will use the values from the cells in field A and the values from cells 1-9 inclusive from field B in its calculation.

MIN(A1:B9, 3, 75, C6, C8, D11)

Where A1:B9 defines a block of cells (the cells between the A1 cell and the B9 cell), 3 and 75 define numerical values, C6, C8, and D11 define individual cells. The MIN function will use the numerical values and the values from the defined cells (including the cells in the block) in its calculation.

See also:

MAX.


Expressions Guide - PI (Functions)

PI

The PI function is a mathematical function that returns the value of pi as a real value.
Function Name | PI
Description | Returns the value of pi as a real value.
Arguments | PI()
Returns | The value of PI as a REAL (see Number (Integer or Real)).

Example:

PI()

The output is 3.1415926535898

See also:

ACOS

ASIN

ATAN

COS

COSH

SIN

SINH

TAN

TANH.


Expressions Guide - POW (Functions)

POW

The POW function is a mathematical function that raises a number to the power of another number. The result of the POW function is a real number.
Function Name | POW
Description | Raises a number to the power of another number.
Arguments | POW(Value INTEGER or REAL, Power Value INTEGER or REAL) The Value integer or real number is the number that will be raised. The Power Value integer or real number defines the power by which the Value will be raised. For information on integers and real floating values—see Number (Integer or Real).
Returns | INTEGER or REAL. The value that is returned by the POW function is the input value to the power of the power value input.

Example:

POW(6,10)

The output is 60466176.


Expressions Guide - PRODUCT (Functions)

PRODUCT

The PRODUCT function is a mathematical function that returns the product of a set of values (the result of value 1 multiplied by value 2 multiplied by value 3 multiplied by value 4 and so on). The product value is a real value.
Function Name | PRODUCT
Description | Returns the product of a set of values (the result of value 1 multiplied by value 2 multiplied by value 3 multiplied by value 4 and so on).
Arguments | PRODUCT(INTEGER or REAL, INTEGER or REAL, INTEGER or REAL...) The set of values for the PRODUCT calculation consists of comma separated values. The values can be integers or real floating values—see Number (Integer or Real). There is a PRODUCT extension for use with Data Grids (see below)
Returns | INTEGER or REAL depending on the data type of the inputs. The result is the product of a set of values.

Example:

PRODUCT(2, 3, 4, 1)

The output is 24 (2X3X4X1).

PRODUCT Extension for Data Grids Only

The PRODUCT function has been extended for use with Data Grids. It can support blocks of cells (arrays) as well as numerical values. This means that you can use fields and rows instead of numerical values in the PRODUCT function (or you can use a combination of blocks, single cells and numbers as required).

Syntax

PRODUCT(<Field1><Row1>, <Field2><Row1>, <Field3><Row1>...)

Where <Field1><Row1> is the name of a field in a row, <Field2><Row1> is the name of another field in the row and so on. Do not enter the angle brackets < >.

For blocks of cells, you have to define the first field and row and the last field and row in the range and separate them with a colon:

PRODUCT(<FirstFieldinRange><FirstRowinRange>:<LastFieldinRange><LastRowinRange>)

NOTE: You can enter the last field first and the first field last if required—ClearSCADA will still recognize the required range.

Examples:

PRODUCT(A1:B9)

Where A1 defines the first cell to be used and B9 defines the last cell to be used. The PRODUCT function will use the data from the cells between the A1 cell and the B9 cell in its calculation. If we assume that A1 is the first cell in a field named A and B9 is the 9th cell in a field named B, the PRODUCT function will use the values from the cells in field A and the values from cells 1-9 inclusive from field B in its calculation.

PRODUCT(A1:B9, 3, 75, C6, C8, D11)

Where A1:B9 defines a block of cells (the cells between the A1 cell and the B9 cell), 3 and 75 define numerical values, C6, C8, and D11 define individual cells. The PRODUCT function will use the numerical values and the values from the defined cells (including the cells in the block) in its calculation.


Expressions Guide - RAD (Functions)

RAD

The RAD function is a mathematical function that converts degrees to radians. It returns a real value.
Function Name | RAD
Description | Converts degrees into radians.
Arguments | RAD(INTEGER or REAL) The value that represents the degrees value can be an integer or a real floating value—see Number (Integer or Real).
Returns | REAL The result is the input (in degrees) converted into radians.

Example:

RAD(180)

The output is 3.14

See also:

DEG.


Expressions Guide - ROUND (Functions)

ROUND

The ROUND function is a mathematical function that returns a number rounded to a specified number of decimal places.

The ROUND function performs round to even rather than round to larger. This means that the function returns the number closest to the value of the expression. If the expression value is exactly halfway between two rounded values, the function returns the value that has an even last digit (the digit on the far right).

Function Name

ROUND

Description

Returns a number rounded to a specified number of decimal places.

Arguments

ROUND(INPUT NUMBER, DECIMAL PLACES)

Where:

  • INPUT NUMBER is an INTEGER or REAL and is the numerical expression that is to be rounded.
  • DECIMAL PLACES is also a numerical expression (INTEGER or REAL) and specifies the number of decimal places to return.

For more information on integers and real values, see Number (Integer or Real).

Returns

REAL.

The input number rounded to a specified number of decimal places.

Examples:

ROUND(1.27489, 2)

The output is 1.27

ROUND(1.4453,1)

The output is 1.4

ROUND(1.5, 0)

The output is 2.

ROUND(2.5, 0)

The output is 2.

ROUND(3.5, 0)

The output is 4.


Expressions Guide - SIN (Functions)

SIN

The SIN function is a mathematical function that returns the Sine (radians) of a number. The SIN function returns a real value.

Function Name

SIN

Description

Returns the Sine (radians) of a number

Arguments

SIN(INTEGER or REAL)

Where:

  • INTEGER or REAL and is the numerical expression upon which the SIN function is to be used.

For more information on integers and real values, see Number (Integer or Real).

Returns

REAL

The Sine (Radians) of the input number.

Example:

SIN(PI() /2)

The output is 1.

See also:

COS

TAN

PI.


Expressions Guide - SINH (Functions)

SINH

The SINH function is a mathematical function that returns the Hyperbolic Sine of a number. The SINH function returns a real value.

Function Name

SINH

Description

Returns the Hyperbolic Sine of a number

Arguments

SINH(INTEGER or REAL)

Where:

  • INTEGER or REAL and is the numerical expression upon which the SINH function is to be used.

For more information on integers and real values, see Number (Integer or Real).

Returns

REAL

The Hyperbolic Sine of the input number.

Example:

SINH(3.54)

The output is 17.22.

See also:

COSH

SINH

TANH.


Expressions Guide - SQRT (Functions)

SQRT

The SQRT function is a mathematical function that returns the square root of a number as a real value.

Function Name

SQRT

Description

Returns the square root of a number

Arguments

SQRT(INTEGER or REAL)

Where:

  • INTEGER or REAL and is the numerical expression upon which the SQRT function is to be used.

For more information on integers and real values, see Number (Integer or Real).

Returns

REAL

The square root of the input number.

Example:

SQRT(4)

The output is 2


Expressions Guide - SUM (Functions)

SUM

The SUM function is a mathematical function that returns the total value of a set of values. The total value is a real value.

Function Name

SUM

Description

Returns the sum total of a set of input values.

Arguments

SUM(INTEGER or REAL, INTEGER or REAL, INTEGER or REAL...)

Where each:

  • INTEGER or REAL is a numerical expression that defines a value in the set of values. The values have to be separated by a comma.

For more information on integers and real values, see Number (Integer or Real).

There is a SUM extension for use with Data Grids (see below).

Returns

REAL

The sum total of a set of values.

Example:

SUM(2, 3, 4, 1)

The output is 10.

SUM Extension for Data Grids Only

The SUM function has been extended for use with Data Grids. It can support blocks of cells (arrays) as well as numerical values. This means that you can use fields and rows instead of numerical values in the SUM function (or you can use a combination of blocks, single cells and numbers as required).

Syntax

SUM(<Field1><Row1>, <Field2><Row1>, <Field3><Row1>...)

Where <Field1><Row1> is the name of a field in a row, <Field2><Row1> is the name of another field in the row and so on. Do not enter the angle brackets < >.

For blocks of cells, you have to define the first field and row and the last field and row in the range and separate them with a colon:

SUM(<FirstFieldinRange><FirstRowinRange>:<LastFieldinRange><LastRowinRange>)

NOTE: You can enter the last field first and the first field last if required—ClearSCADA will still recognize the required range.

Examples:

SUM(A1:B9)

Where A1 defines the first cell to be used and B9 defines the last cell to be used. The SUM function will use the data from the cells between the A1 cell and the B9 cell in its calculation. If we assume that A1 is the first cell in a field named A and B9 is the 9th cell in a field named B, the SUM function will use the values from the cells in field A and the values from cells 1-9 inclusive from field B in its calculation.

SUM(A1:B9, 3, 75, C6, C8, D11)

Where A1:B9 defines a block of cells (the cells between the A1 cell and the B9 cell), 3 and 75 define numerical values, C6, C8, and D11 define individual cells. The SUM function will use the numerical values and the values from the defined cells (including the cells in the block) in its calculation.


Expressions Guide - TAN (Functions)

TAN

The TAN function is a mathematical function that returns the Tangent (radians) of a number. The TAN function returns a real value.

Function Name

TAN

Description

Returns the Tangent (radians) of a number.

Arguments

TAN(INTEGER or REAL)

Where:

  • INTEGER or REAL is a numerical expression that defines the value on which the TAN function is applied.

For more information on integers and real values, see Number (Integer or Real).

Returns

REAL

The Tangent (radians) of a number.

Example:

TAN(1.2)

The output is 2.57

See also:

COS

PI

SIN.


Expressions Guide - TANH (Functions)

TANH

The TANH function is a mathematical function that returns the Hyperbolic Tangent of a number. The TANH function returns a real value.

Function Name

TANH

Description

Returns the Hyperbolic Tangent of a number.

Arguments

TANH(INTEGER or REAL)

Where:

  • INTEGER or REAL is a numerical expression that defines the value on which the TANH function is applied.

For more information on integers and real values, see Number (Integer or Real).

Returns

REAL

The Hyperbolic Tangent of a number.

Example:

TANH(2.9)

The output is 0.99

See also:

COSH

PI

SINH.


Expressions Guide - String Functions (Functions)

String Functions

The String functions include common functions that are used to manipulate string values. ClearSCADA supports the following string functions:

  • CHR—Allows formatting characters to be included in an expression.
  • FORMATVAL—Applies formatting to a value and returns the result as a string value.
  • INSTRING—Returns a number that indicates the position of a substring in a string.
  • LEFT—Returns a specified number of characters starting from the left of an input string.
  • LEN—Returns the number of characters in an input string as a real value.
  • MID—Returns a specified number of characters from an input string.
  • RIGHT—Returns a specified number of characters starting from the right of an input string.
  • STR—Returns the string equivalent of a value.


Expressions Guide - CHR (Functions)

CHR

The CHR function allows formatting characters such as spaces, line breaks, and tabs to be included in an expression. ASCII codes are used to represent the required characters, for example, 10 represents line feed. Information about ASCII codes is widely available on the Internet.
Function Name | CHR
Description | Allows formatting characters to be included in an expression.
Arguments | CHR(INTEGER or REAL) The integer or real floating value is an expression that corresponds to an ASCII character (range 0 to 127). For information on integers and real floating values—see Number (Integer or Real).
Returns | STRING

Example:

A shape on a Mimic is animated to represent an analog point. A ToolTip is required for the shape—the ToolTip is to provide the High High and High alarm levels for the point. To achieve this, the shape's TooltipText property is animated by the following expression:

'Alarm Limits ' + CHR( 10 ) + ".AI.HighHighDesc" + ': ' + STR(".AI.HighHighLimit" ) + CHR( 10 ) + ".AI.HighDesc" + ': ' + STR(".AI.HighLimit" )

Where 'Alarm Limits' is a text string that is followed by a line break (represented by CHR( 10 ) ).

"AI.HighHighDesc" is the High High Description value of the "AI" point.

"AI.HighHighLimit" is the High High Limit value of the "AI" point. This is followed by another line break (CHR(10)).

"AI.HighDesc" is the High Description value of the "AI" point.

"AI.HighLimit" is the High Limit value of the "AI" point.

The STR function is also required (see STR).

The ToolTip for the shape displays the following information:

High High Desc
High Desc
High Limit
High High Limit

See also:

FORMATVAL

STR.


Expressions Guide - FORMATVAL (Functions)

FORMATVAL

The FORMATVAL function applies formatting to a value and returns a string value.

Function Name

FORMATVAL

Description

Applies formatting to a value and returns the result as a string value.

Arguments

FORMATVAL('Format String', Value String)

The input value contains two STRING values. The first is called the Format String and has to be enclosed in single quotes. The Format String defines the formatting that is to be applied to the Value String. The formatting can be Boolean, Integer or Real, String, or Date/Time. For information on the various format string codes and characters, see Defining the Format of Displayed Values in the ClearSCADA Guide to Core Configuration.

The second part of the value is the Value String and this is an expression that defines the value to which the formatting is to be applied. The Value String should not be enclosed with single quotes.

For more information on STRING values, see String.

Returns

STRING

The output string is the Value String after the formatting defined by the Format String has been applied.

Examples:

Boolean:

FORMATVAL('t', 0)

The output is 'f' because 0 is false and the format is t/f. The Format String for the t/f format is 't'.

Numeric:

FORMATVAL('#.00', 123.456)

The output is 123.46 as the '#.00' format string sets the result to have 2 digital places.

String:

FORMATVAL('>', 'AbRaCaDaBrA')

The output is ABRACADABRA as the '>' format string sets the entire result to upper case.

Date:

FORMATVAL('dd MMM yyyy',".Analog Point.CurrentTime")

The output is 31 Nov 2005. This expression returns the CurrentTime value of the 'Analog Point' database item in the required format (dd MMM yyyy). In this case, the CurrentTime value is '31/Nov/2005 12:52:18.625' and this is formatted to 2 numbers for the day, 3 letters for the month, and 4 numbers for the year only.

See also:

STR

CHR.


Expressions Guide - INSTRING (Functions)

INSTRING

The INSTRING function returns a number that indicates the position of a substring in a string.

Function Name

INSTRING

Description

Returns a number that indicates the position of a substring in a string. The first character in the string corresponds to index 1, the second to index 2 and so on. If the substring is not present, 0 is returned.

Arguments

INSTRING('STRING', 'SUBSTRING')

Where:

  • String is the string expression in which to search
  • Substring is the string for which to search.

Both the STRING value and the SUBSTRING value has to be enclosed in single quotes.

For more information, see String

Returns

REAL.

The returned value is a number that indicates the starting position of the substring value within the string value.

Example:

INSTRING('The quick brown fox', 'brown')

This will return 11 as 'brown' begins at the eleventh character from the left of the string.

INSTRING('The quick brown fox', 'jump')

This will return 0 (not found).

See also:

LEFT

MID

RIGHT

LEN.


Expressions Guide - LEFT (Functions)

LEFT

The LEFT function returns a specified number of characters from the left side of a string.

Function Name

LEFT

Description

Returns a specified number of characters starting from the left of an input string.

Arguments

LEFT('STRING', LENGTH)

Where:

  • String is the string expression in which to search. The string has to be enclosed within single quotations. For more information, see String
  • Length is a numerical expression (REAL or INTEGER) that indicates the number of characters to be returned. If the LENGTH is 0, no characters are returned. If the LENGTH is equal to or greater than the total number of characters in the string, the entire string is returned.

Returns

STRING.

The returned value is a string value that consists of the specified number of characters. The characters are taken from the defined input string, beginning at the first character from the left of the string.

Example:

The expression:

LEFT( 'Pipeline', 4 )

returns:

Pipe

(4 characters starting from the left of the 'Pipeline' string).


Expressions Guide - LEN (Functions)

LEN

The LEN function returns the number of characters in a string.
Function Name | LEN
Description | Returns the number of characters in an input string as a real value.
Arguments | LEN('STRING') Where String is the string expression in which to search. The string has to be enclosed within single quotations. For more information, see String.
Returns | REAL The returned value is a number that matches the total number of characters within the input string.

Example:

The following expression is used to return the number of characters in the name of a point:

LEN (".PointA_STA.Name")

The expression returns 10 as the name of the point is PointA_STA.

See also:

LEFT

MID

RIGHT


Expressions Guide - MID (Functions)

MID

The MID function returns a specified number of characters from a string.

The MID function is often used to manipulate strings, for example, to show shortened string values on Mimics.

Function Name

MID

Description

Returns a specified number of characters from an input string. The starting character is defined in the argument.

Arguments

MID('STRING', START, LENGTH)

Where:

  • String is the string expression in which to search. The string has to be enclosed within single quotations. For more information, see String
  • Start is a numerical expression that defines which is the first character to be included in the result. The first character in the input string is character 0, the next character is character 1, the next character 2 and so on. If the Start number is less than 0, the function begins with the first character. If the Start number is greater than or equal to the entire length of the input string, an empty string is returned.
  • Length is a numerical expression (REAL or INTEGER) that indicates the number of characters to be returned. If the LENGTH is 0, no characters are returned. If the LENGTH is equal to or greater than the total number of characters after the start character, the remaining characters are returned.

Returns

STRING.

The returned value is a string value that consists of the specified number of characters. The characters are taken from the defined input string, beginning at the first character from the left of the string.

Example:

MID( 'Main Site.Mains Control 1', 10, -1 )

The output is 'Mains Control 1'.

See also:

LEFT

LEN

RIGHT.


Expressions Guide - RIGHT (Functions)

RIGHT

The RIGHT function returns a specified number of characters from the right-hand side of a string.

The RIGHT function is often used to manipulate string inputs and outputs, for example, to show shortened string values on Mimics.

Function Name

RIGHT

Description

Returns a specified number of characters from the right-hand side of an input string.

Arguments

RIGHT('STRING', LENGTH)

Where:

  • String is the string expression in which to search. The string must be enclosed within single quotations. For more information, see String
  • Length is a numerical expression (REAL or INTEGER) that indicates the number of characters to be returned. If the LENGTH is 0, no characters are returned. If the LENGTH is equal to or greater than the total number of characters in the string, the entire string is returned.

Returns

STRING.

The returned value is a string value that consists of the specified number of characters. The characters are taken from the defined input string, beginning at the last character and moving backwards toward the left of the string.

Example:

RIGHT( 'Pipeline', 4 )

The output is 'line'.

See also:

LEFT

LEN

MID.


Expressions Guide - STR (Functions)

STR

The STR function returns the string equivalent of a value.

Function Name

STR

Description

Returns the string equivalent of a value. Usually, the STR function is used to combine a non-string value with string values.

Arguments

STR(Value)

Where:

  • Value is an expression that provides the value that is to be converted into a string.

Returns

STRING

The input value added to a string and returned as a string.

Example:

A text box is configured on a Mimic. The text box is animated so that it displays the current value of a point named 'Analog Point 1'.

The text box is to have a ToolTip that shows the last update time of the point when the cursor is positioned over the text box. To achieve this effect, the TooltipText property of the text box is animated with this expression:

'Last update time: '+ STR(".Analog Point 1.CurrentTime").

This allows the ToolTip for the text box to show a string that contains a time from the database (the CurrentTime property represents the time of the latest update to the point's values).

See also:

CHR

FORMATVAL


Expressions Guide - Miscellaneous Functions (Functions)

Miscellaneous Functions

The Miscellaneous category includes those functions that are not related to performing common mathematical functions or manipulating string values. The miscellaneous functions supported by ClearSCADA are:

  • ARRAYELEMENT—Returns a value from a specified element in an Array database item
  • EXISTS—Checks that items referenced in arguments exist in the database before a value is returned
  • HEAD—Returns the number of the head on which the Mimic or Trend is being displayed
  • IIF—Tests a condition and returns one of two values depending on whether the condition is true or false
  • LINK—Modifies a URL returned as a property of a database item so that the URL contains the system on which the database item is stored
  • LOCALE—Returns the locale of the currently logged on user as an integer value
  • LOOKUP—Returns the nth expression from a set of expressions
  • REGISTRY—Returns a specified value from the Windows registry
  • RGB—Returns a color
  • TIME—Evaluates an OPC relative time
  • USERNAME—Returns the name of the user account being used by the currently logged on user.


Expressions Guide - ARRAYELEMENT (Functions)

ARRAYELEMENT

Some database items, such as array variable items, have an array of values rather than one value. You can use the ARRAYELEMENT function in an expression to access any of the values in an array, for example, you could use the ARRAYELEMENT function to access the third value in an array of six values.

Function Name

ARRAYELEMENT

Description

Returns a value from a specified element in an array.

Arguments

ARRAYELEMENT("Tag", <ELEMENT NUMBER>)

Where:

"Tag" represents a tag for an array. The tag has to be for an array in an available database (see Tags)

<ELEMENT NUMBER> is the number of the array element that contains the value that is to be returned, for example, 4 will return the value in element 4 of the array. Do not include the angle brackets <>.

Arrays are usually 0 based, so 0 will be the first element, 1 the second element, 2 the third element and so on.

Returns

Variable - the type of value returned is dependent on the type of value in the defined element of the array. For example, if the element contains a string value, a string value is returned by the ARRAYELEMENT function.

Example:

An ST Program is used to write six values to a Float Array database item named ‘PCR67F’. One of these values - the value in the third element - is required as an input for a text box animation. The text box is configured to have a Value animation that uses the ARRAYELEMENT function in its expression:

ARRAYELEMENT(".PCR67F", 2)

This returns the value in the third element of the ‘PCR67F’ Array Variable item. As the text box is animated to display the value that is returned by its Value animation, it means that the text box will display the value of the third element in the ‘PCR67F’ Float Array.

Further Information

Array Database Items: see Using Variables to Store Data Values in the ClearSCADA Guide to Core Configuration.


Expressions Guide - EXISTS (Functions)

EXISTS

The EXISTS function is used to check that an item that is referenced in an argument exists in the database before a value is returned. For example, a symbol Mimic can use an EXISTS function in an expression to let a point value be displayed if the point exists in the database, but have no value shown if the point does not exist.

When using the EXISTS function, you need to be aware that the creation or deletion of a database item does not cause a re-evaluation of an expression. So, when an expression containing the EXISTS function runs, the expression is evaluated for that particular time - if the database item exists as that time, the EXISTS function returns True; if the item does not exist, the function returns False.

If the EXISTS function returns True, and subsequently the referenced item is deleted, the EXISTS function may continue to return True. The deletion of an item does not cause an expression to re-evaluate. Similarly, if a database item does not exist when an expression is evaluated, the EXISTS function returns False. If the item is subsequently created, the EXISTS function will continue to return False.

The EXISTS function can only update to reflect subsequent deletions or creations if the expression is re-evaluated. For example, an expression can contain an EXISTS function that references a point, as well as references to other tags. Changes in the values for the tags cause the expression to be re-evaluated, and so the EXISTS function is also re-evaluated. The result of the EXISTS function reflects whether the referenced point existed at the time of the re-evaluation.

EXISTS functions are used in the condition of an IIF function.

NOTE: The EXISTS function is only available in client expressions. It cannot be used in server expressions.

Function Name | EXISTS
Description | Checks that items referenced in arguments exist in the database before a value is returned.
Arguments | EXISTS("Tag") Where "Tag" represents any tag in an available database (see Tags)
Returns | BOOL A Boolean value that indicates whether the item exists in the database (True). If the item does not exist, the EXISTS function returns a False value.

Example:

A text box on a Mimic shows the current value of a point named 'Analog Input 1'. The Mimic is a symbol Mimic and is embedded on more than one Mimic. If the point is not in the same location in relation to the other Mimics, the text box shows the string 'The point is not available'. This functionality is provided by the EXISTS function.

The text box on the Mimic is configured to have its Value property animated using the following expression:

IIF (EXISTS (".Analog Input 1.CurrentValue"), ".Analog Input 1.CurrentValue", 'The point is unavailable')

The Mimic is embedded on a Mimic named 'Region'. The 'Region' Mimic is stored in a group that also contains a point named 'Analog Input 1'. This means that the text box shows the current value of the point as there is a point in the same location as defined in the expression (the expression defines the relative location as the point being in the same group as the Mimic).

The Mimic is also embedded on a Mimic named 'Station 65'. The 'Station 65' Mimic is stored in a group that contains other Mimics but no points. This means that the text box shows the 'The point is unavailable' string as there is no 'Analog Input 1' point in the same location as defined in the expression (the expression defines the relative location as the point being in the same group as the Mimic).


Expressions Guide - HEAD (Functions)

HEAD

The HEAD function returns the number of the head on which the Mimic or Trend is being displayed. The HEAD function is only of any practical use on systems with multiple heads (monitors).
Function Name | HEAD
Description | Returns the number of the head on which the Mimic or Trend is being displayed. The number can be: 0 - The Mimic or Trend is being displayed in WebX. 0 is returned even if there are multiple instances of the browser open on the same head. 1 - The Mimic or Trend is being displayed in a ViewX application that is running on Head 1. 2 - The Mimic or Trend is being displayed in a ViewX application that is running on Head 2. 3 - The Mimic or Trend is being displayed in a ViewX application that is running on Head 3. 4 - The Mimic or Trend is being displayed in a ViewX application that is running on Head 4. 5 - The Mimic or Trend is being displayed in a ViewX application that is running on Head 5.
Arguments | HEAD()
Returns | REAL The number of the head on which the Mimic or Trend is being displayed. For more information on integers and real values, see Number (Integer or Real).

Example:

IIF (HEAD () <=1,1,0)

In this example, the HEAD function is used to animate the Visible animation property of a text box on a Mimic. If the Mimic is displayed on the first head of a ViewX or WebX client, the text box will be displayed. If the Mimic is displayed on heads 2, 3, 4 or 5 of a ViewX client, the text box will not be shown.


Expressions Guide - IIF (Functions)

IIF

The IIF function is used to test a condition and return one of two values depending on whether the condition is true or false.

Function Name

IIF

Description

Tests a condition and returns one of two values depending on whether the condition is true or false.

Arguments

IIF(Condition, True Value, False Value)

Where:

  • Condition is a Boolean expression that defines the condition that is to be tested
  • True Value is an expression that is returned if the condition is true
  • False Value is an expression that is returned if the condition is false.

Returns

Dependent on the argument.

Example:

The following expression is used on a Mimic animation for the Style property of a button item. It uses the IIF function to determine the style of a button based on the alarm state of a point:

IIF( ".1 Bit Digital.AlarmState" = 4, 1, 0 )

If the point named ' 1 Bit Digital' has an alarm state of 4 (i.e. has an unacknowledged uncleared alarm), the style is latched (1 corresponds to the Latched style of button). If the point has any other alarm state (i.e. the Alarm State does not equal 4, the style is normal ( 0 corresponds to the Normal style of button).


Expressions Guide - LINK (Functions)

LINK

NOTE: The LINK function is only available for use in client expressions.

The LINK function is used to modify a URL that is returned by a property of a database item. It modifies the URL so that it includes the system on which the item is located. This is required when a Mimic on one system has a hyperlink to an item on another system.

Database items have several properties that return a URL that can be used by hyperlinks on Mimics. The URLs are used when a Mimic object is to act as a hyperlink to a database item.

As URLs do not include the system, the LINK function is required when a Mimic object is to link to a database item on another system. The LINK function modifies a URL to include the system. If the LINK function is not used, the hyperlink will only reference a local item (item on the same system as the Mimic).

For more information on hyperlinks, see Creating a Hyperlink Action in the ClearSCADA Guide to Mimics.

Function Name

LINK

Description

Modifies a URL returned as a property of a database item so that the URL contains the system on which the database item is stored. The LINK function is only for use in client expressions.

Arguments

LINK("Tag")

Where "Tag" is a reference to one of the following properties:

  • ObjectLink
  • HelpViewLink
  • Link1Link - Link8Link (Link2Link, Link3Link etc.)
  • AlarmViewLink (only available for objects that can have alarms)
  • DefaultViewLink (only available for Groups)

The Tag must be enclosed in double quotations " ".

Returns

STRING

The string is a URL that has been modified to include the system on which the database item is stored.

Example:

A Mimic named 'Site 1' is stored on a System named 'Northern Region'. It contains 2 hyperlinks—1 hyperlink to a Mimic named 'Pipeline 6' that is also stored on the 'Northern Region' system, and 1 hyperlink to a Mimic named 'Alarm Display' that is stored on the 'North West Region' system.

The hyperlink to the 'Pipeline 6' Mimic is created by animating the PickParam property of an item on the 'Site 1' Mimic with the following expression:

".Pipeline 6.ObjectLink"

The expression consists of the location of the hyperlink target (the display that is shown when the hyperlink is selected), followed by ObjectLink. When the item is selected (in Run mode), the 'Pipeline 6' Mimic will be displayed.

The hyperlink to the 'Alarm Display' Mimic is created by animating the PickParam property of an item on the 'Site 1' Mimic with the following expression:

LINK( "North West Region:Alarm Display.ObjectLink" )

The expression for the hyperlink is different to that of the 'Pipeline 6' hyperlink as the client needs to modify the URL returned by the ObjectLink property. When the client modifies the URL, it includes the name of the other system in the address. To achieve this, the LINK function is used and the location of the target display (Alarm Display) includes the name of the system on which it is stored (North West Region).


Expressions Guide - LOCALE (Functions)

LOCALE

The LOCALE function returns the locale of the logged on user as an integer value. This function is useful when working with different international versions of ClearSCADA, for example, you can use LOCALE to change the text shown in a text box on a Mimic according to the LOCALE of the logged on user.
Function Name | LOCALE
Description | Returns the locale of the currently logged on user as an integer value.
Arguments | LOCALE()
Returns | INTEGER The INTEGER returned represents the locale of the currently logged on user. The locale numbers are available on-line from www.microsoft.com (search for the term 'Locale ID' or 'LCID Chart'.

Example:

In the following example, the LOCALE function is used with an IIF function so that a Mimic is displayed on a client with a UK locale (locale number 2057), a text box displays 'SEUK Web site' and if it is displayed on a client with any other locale, the text box shows 'SEUS Web site'. The expression is used on the value property for the text box.

IIF (LOCALE () =2057, 'SEUK Web site', 'SEUS Web site')


Expressions Guide - LOOKUP (Functions)

LOOKUP

The LOOKUP function returns the nth expression from a set of expressions.

Function Name

LOOKUP

Description

Returns the nth expression from a set of expressions.

Arguments

LOOKUP( Index, Value 1, Value 2, ... )

Where:

  • Index is a numerical expression that defines which of the input values are returned. The range is 1 to n. The Index is an INTEGER or REAL, see Number (Integer or Real).
  • Value 1, Value 2 and so on are a list of expressions that define the possible values that can be returned by the function.

Returns

The nth expression from a set of expressions.

The data type of the returned value varies according to the data types of the inputs.

Example:

A Mimic item is animated to be a different color when a 2 bit digital point changes state. There needs to be a separate color for each of the point's 4 states.

The Mimic item has its FillColour property animated by the following expression:

LOOKUP(".2 Bit Digital.CurrentState"+1, RGB (255,0,0), RGB (0,255,0) RGB (0,0,255), RGB (255,255,0))

This means that when the point is in state 0, the Mimic item will be red (RGB 255,0,0). The +1 at the end of the point reference is needed as the arguments in an expression are numbered 1, 2, 3, 4 whereas the states of the point are numbered 0, 1, 2, 3.

When the point is in state 1, the Mimic item is green. When the point is in state 2, the Mimic item is blue, and when the point is in state 3, the Mimic item is yellow.

NOTE: The same effect can be achieved by using the CurrentStateColour property.


Expressions Guide - REGISTRY (Functions)

REGISTRY

NOTE: The REGISTRY function is only available for use in client expressions.

The REGISTRY function returns a specified value from the Windows registry. The value is read from the registry on the client PC that is displaying the Mimic or Trend that uses the expression. The values are located in the following registry key:

HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\ViewX/Mimics

If the value is not present, a new value is created with the specified default value. The default value can be a string or a numerical expression.

By using the registry on the client PCs, the expression allows the same Mimic or Graph to behave differently on different clients (as each client can have a different value).

Function Name

REGISTRY

Description

Returns a specified value from the Windows registry. The value is read from the registry on the client PC that is displaying the Mimic or Trend that uses the expression.

Arguments

REGISTRY(STRING, STRING or INTEGER or REAL)

The first value in the argument is a STRING and it is the name of the value that is to be read.

The second value in the argument can be a string, integer or real value and it is the default value for the registry.

If the registry already exists and has a value, the type of value you define for the second value in the argument has to match the type of value that is already in the Windows registry. If the Windows registry does not contain a value, a new registry will be created using the name that is specified in the argument. The type of the new registry is dependent on the second value in the argument - depending on what is defined as the second value, the new registry will be a STRING or a DWORD.

For more information on strings, integers and real floating values, see Data Types.

Returns

STRING, INTEGER or REAL depending on the data type of the inputs.

The result is a value from the Windows registry.

Example:

REGISTRY('Test', 'Default String')

If there is a value named 'Test' in the registry, the REGISTRY function will read the value and return it as a string value or integer value (depending on the type of value in the registry). If there is not a value named 'Test', the REGISTRY function will create a 'Test' value and will apply the 'Default String' value to it (in this case, the 'Test' registry will contain a string). The REGISTRY function will then return the value from the registry which is 'Default String'.


Expressions Guide - RGB (Functions)

RGB

The RGB function returns a color based on the specified Red, Green, and Blue components. The RGB function can be used to hard code colors, for example, to hard code colors on a Mimic so that the colors alter to indicate changes in state.
Function Name | RGB
Description | Returns a color.
Arguments | RGB(INTEGER, INTEGER, INTEGER) The first integer value represents the amount of red, the second integer value represents the amount of green, and the final integer value represents the amount of blue. Each color can be in the range 0 to 255.
Returns | INTEGER The integer value that is returned represents a color.

You can enter RGB functions manually or you can use the browse button on an Expression Editor to select a common color from a palette or create a custom color.

To select a color for use in an expression:

  1. Position the cursor at the location in the expression where the color is to be inserted. If you highlight part of the expression, the color will replace the highlighted code.
  2. Select the browse button next to the expression field on the expression window.
    A context sensitive menu is displayed.
  3. Select the Color option to display a color palette.
  4. Either select a color from the palette or select the ... option to display the Custom Color window. You can use the Custom Color window to create your own colors (see Using the Color Window in the ClearSCADA Guide to Mimics).

When you have selected a color, an RGB function for the color is entered into the expression. For example, RGB(0,0,204) is a dark shade of blue.

  5. Repeat steps 1 to 4 inclusive for each color that is to be included in your expression.

Example:

The following expression is used to animate the FillColour property of a shape on a Mimic.

IIF (".Digital Input 1"=0, RGB( 0, 255, 0 ), RGB (255, 0, 0))

This IIF statement sets the shape to be green - RGB (0, 255, 0) - when a digital point named 'Digital Input 1' is in state 0, and red - RGB ( 255, 0, 0) - when the digital point is in any other state.


Expressions Guide - TIME (Functions)

TIME

The TIME function evaluates an OPC relative time, for example, H-10M. It can be used to obtain a time that is relative to the current time.

Function Name

TIME

Description

Evaluates an OPC relative time.

Arguments

TIME(TIME VALUE)

Where:

  • TIME VALUE is a STRING that provides an OPC relative time value.

For more information on time values, see Date and Time.

Returns

TIME

Example:

On a system that uses SCADAPack Modbus outstations, the Retrieve Demand List action for a point requires a Start Time and End Time to be specified. The Start Time and End Time define the range of data to be retrieved from the outstation.

A user method can be set up to execute the Retrieve Demand List method but with a relative start and end time instead of user defined start and end times. The relative start and end time are defined in the expression in the Method field for the user method. The expression uses the TIME function.

The expression for the user method is defined as:

RetrieveDemandList(0, TIME('D'), 0, TIME('D+1D'))

Where RetrieveDemandList is the name of the method. The first 0 instructs the system to use the start time given in the second argument. The first TIME function calculates the start time as the beginning of today. The second 0 informs the system to use the end time given in the last argument. The second TIME function calculates the end time as the end of today.

Further Information

Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.


Expressions Guide - USERNAME (Functions)

USERNAME

The USERNAME function returns the name of the currently logged on user.

Typically, the USERNAME function is used to allow the name of the currently logged on user to be passed as an argument to a User Method.
Function Name | USERNAME
Description | Returns the name of the user account being used by the currently logged on user.
Arguments | USERNAME()
Returns | STRING The name of the user account being used by the currently logged on user. The current user is not logged on, USERNAME returns GUEST (for both ViewX and WebX clients).

Syntax

USERNAME()

The user name can be passed as an argument to a Logic program. (A string input variable has to be included in the VAR_INPUT list).

Example:

An ST program is created to add the values of 3 points, read the user name of the user that executed the program, and write the user name and the total value of the points to a string point on the server.

The ST program has variable inputs for the 3 points and a string variable input for the user name. The string variable input will use the value that is returned by the USERNAME function.

The ST program is executed via a User Method pick action called 'Total'. The configuration of the User Method includes:

  • Object—The name of the ST program database item.
  • Method—The name of the method that is performed when the User Method is selected, and a definition of its arguments.

In this case, the Method is Execute (USERNAME () ). This means that the User Method calls the Execute method on the ST program and passes the user's name to the ST program. The ST program then calculates the total of the 3 points and outputs the total as well as the user name that was provided by the USERNAME function. The output of the ST program is written to a string point on the server.

  • Title—This is the name of the User Method pick action, in this case, Total.

A user logs on to the server via a user account named 'Manager'. The user selects the 'Total' User Method for the ST program. The ST program reads the name of currently logged on user ('Manager') and the values of the 3 input points. For this example, let's say the point values are 12, 45, and 81.

The ST program calculates the total of the 3 input points and outputs the total along with the user name. The output of the ST program is written to a string point on the server. The current value of the string point is 138 Manager (total of 3 points + username).

Further Information

Working with Logic Programs in the ClearSCADA Guide to Logic.


Logic Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Logic Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Logic Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Logic Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Logic Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Logic Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to use the ClearSCADA ViewX interface to create and edit Logic programs. ClearSCADA supports Ladder Logic, Structured Text, Function Block Diagrams and Sequential Function Charts, all of which are part of the IEC 1131-3 Programming industrial control systems standard.

This Guide is designed to explain the interfaces and includes examples of various Logic programs. It is not a reference guide to the IEC 1131-3 Programming languages.

For information on the subjects covered in this Guide, see Welcome to the Guide to Logic.


Logic Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for engineers who are responsible for the design and creation of Logic programs (programs which define relationships between database items and system behavior). It is assumed that such engineers have an in-depth understanding of one or more of the Logic programming languages supported by ClearSCADA.


Logic Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Logic Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to the Database

ClearSCADA Guide to Expressions

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


Logic Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Logic Guide - Welcome to the Guide to Logic

Welcome to the Guide to Logic

Welcome to the ClearSCADA Guide to Logic. This guide is designed to aid you in the creation and design of ST programs, Function Block Diagrams, Ladder Diagrams, and Sequential Function Charts.

ClearSCADA supports 4 Logic languages that you can use to define relationships between values, control sequences, conversion calculations etc. These languages are part of the IEC 1131-3 Programming industrial control systems standard.

The ClearSCADA Guide to Logic consists of:

  • Working with Logic Programs
  • ST Programs
  • Ladder Diagrams
  • Function Block Diagrams
  • Sequential Function Charts
  • Built-in Functions, Function Blocks, and Conversions
  • User Function Blocks
  • Logic Program Properties and Values
  • Logic Data Types
  • Logic Specific Status Attributes.

In the sections listed above, you will find reference information that you can use to find out about the various Logic languages and how they are supported in ClearSCADA. The sections contain some detail about the programming of Logic programs, but are not designed to be a complete reference on the IEC 1131-3 standard. The purpose of this Guide is to provide details about how you can use ClearSCADA to create the Logic programs you require on your system.


Logic Guide - Working with Logic Programs

Working with Logic Programs

Before you configure your own Logic programs, you need to understand:

  • Which Logic languages are supported by ClearSCADA (see Supported Logic Languages)
  • How Logic Programs Work
  • Which type of Logic program you need to create (see Choosing a Logic Program).
  • What considerations you need to make when Using Outputs as Inputs (‘Feedback Loops’) in Logic Programs
  • How to determine the Execution Order for Logic Programs.

NOTE: If your Logic program does not run or has unexpected results, please refer to Troubleshooting Logic Programs.


Logic Guide - Supported Logic Languages (Working with Logic Programs)

Supported Logic Languages

ClearSCADA supports 4 of the languages included in the International Electro-technical Commission (IEC) standard for programming industrial control systems (IEC 1131-3):

  • Ladder Diagrams
  • Function Block Diagrams (FBDs)
  • Sequential Function Charts (SFCs)
  • Structured Text programs (ST)

In ClearSCADA these languages are referred to as Logic programs, and you can use them to:

  • Define complex relationships between the values for the properties of items in the database
  • Perform calculations
  • Execute methods on items in the database (one shots, overrides, controls etc.)

For example, in the water industry, a Function Block Diagram can be used to turn pumps on when the water level drops to a specified limit.

The Logic programs are interchangeable—you can use one type of Logic program with a different type of Logic program. For example, you can use ST programs with Function Block Diagrams or Ladder Diagrams. The only exception is Sequential Function Charts which can only be used with ST programs.


Logic Guide - How Logic Programs Work (Working with Logic Programs)

How Logic Programs Work

Each Logic program is configured to represent a calculation or a procedure. The Logic program uses values from the database (inputs) as part of the calculation or procedure. The result of the calculation or procedure is either written to the ClearSCADA database as a value or is used to execute a method such as a control.

Logic programs can be set to execute:

  • When an input value changes
  • At specified times.

When a Logic program begins, it reads its input values (Tag Read). These values can be the values of items in the database or can be values specified in a query.

After reading its input values, the Logic program executes. The calculation or procedure that is defined in the configuration of the Logic program is executed. The input values are used as part of the calculation or procedure.

When the Logic program has executed, it has an output. The output is either:

  • The setting of an item's property, for example, a value that is written to a point

or:

  • The execution of a method on an item in the database, for example, the output of a Logic program can initiate the Refresh Outstation method.

Logic programs are designed to have a similar architecture to PLC programs. The procedure for executing a Logic program is:

  1. Logic program reads its inputs
  2. Logic program executes
  3. Logic program writes its outputs

This sequence of events cannot be altered. The inputs are read first, and then the program executes, and then the outputs are written. Logic programs cannot use any other type of structure.

NOTE: Methods are sometimes referred to as 'actions'.


Logic Guide - Choosing a Logic Program (Working with Logic Programs)

Choosing a Logic Program

You need to decide which type of Logic program you are going to use. For many requirements, you can use any of the Logic programs to achieve the required effect. However, in some situations you may need to choose a specific type of program.

By answering the questions below, you can determine whether you need to create a specific type of Logic program or can use the Logic program of your choice:

If you have a choice of which Logic program to use, we recommend that you use the Logic program that you find easiest to use. For many engineers, Ladder Diagrams are the easiest type of Logic program to understand. Ladder Diagrams use relay ladder Logic and are similar to traditional PLC programs.

Like Ladder Diagrams, Function Block Diagrams and Sequential Function Charts are graphical displays. Many users prefer to use graphical programs as they show each of the elements that form the program. It is easier to create a complex program when you can see its elements.

Structured Text (ST) is a text based programming language and is a very flexible type of Logic program. You can use ST programs to provide any type of supported behavior, but to program them you will need a good understanding of the ST language and strong programming skills.

For detailed information on the Logic languages, please refer to the following sections:

  • ST Programs
  • Ladder Diagrams
  • Function Block Diagrams
  • Sequential Function Charts.

When creating Logic programs, you may also need to refer to:

  • User Function Blocks
  • Built-in Functions, Function Blocks, and Conversions
  • Logic Program Properties and Values.


Logic Guide - Using Outputs as Inputs ('Feedback Loops') in Logic Programs (Working with Logic Programs)

Using Outputs as Inputs (‘Feedback Loops’) in Logic Programs

The outputs in your Logic programs can also be used as inputs, for example, you can use the output result of an ADD function as an input on a DIV function. When an output is also an input, it is referred to as a ‘feedback loop’.

If your Logic program uses ‘feedback loops’ you should use ClearSCADA’s built-in diagnostics tool to check the execution order of your program.

  • For more information on the execution order of ‘feedback loops’, see Execution Order for Logic Programs.


Logic Guide - Execution Order for Logic Programs (Working with Logic Programs)

Execution Order for Logic Programs

Each part of a Logic program is executed in a sequence referred to as the execution order. The way in which ClearSCADA determines the execution order varies according to the type of Logic program:

  • For ST programs, the execution order is clearly defined in the language syntax (ClearSCADA compiles then executes the code from top to bottom).
  • For Sequential Function Charts, the execution order is defined by the logical state transitions in the charts.
  • For Function Block Diagrams and Ladder Diagrams, ClearSCADA examines the diagrams and then generates the Structured Text (ST) equivalent of the program. ClearSCADA then compiles the ST and executes it in the same way that it would execute the code for an ST Program database item.

The execution order of Function Block Diagrams and Ladder Diagrams is determined by ClearSCADA when it generates an ST equivalent of the graphical program. Typically, when ClearSCADA generates the ST equivalent, it attempts to order the program so that inputs are processed before outputs, based on the block relationship.

For example, if we take the following simple Function Block Diagram:

When this FBD is saved, ClearSCADA will generate the ST equivalent of the program which is:

PROGRAM $FBD
VAR
dig5 AT %M(.dig5) : BYTE;
dig2 AT %M(.dig2) : BYTE;
dig3 AT %M(.dig3) : BYTE;
dig4 AT %M(.dig4) : BYTE;
END_VAR
VAR
$B1_ENO : BOOL := FALSE;
$B1 : BYTE;
$B2_ENO : BOOL := FALSE;
$B2 : BYTE;
END_VAR
$B1 := AND( IN1 := dig3, IN2 := dig2, ENO => $B1_ENO );
$B2 := OR( IN1 := $B1, IN2 := dig4, ENO => $B2_ENO );
IF $B2_ENO THEN
dig5 := $B2;
END_IF;

END_PROGRAM

The program has been arranged so that:

  • The OR block is processed before the output 'D'
  • Inputs to the OR block are processed before the OR block is processed
  • Inputs to the AND block are processed before the AND block is processed.

If outputs are also used as inputs (‘feedback loops’), the execution order can become complicated. In these cases, we advise that you use ClearSCADA’s built-in diagnostics tool to check the execution order of your programs. The diagnostics tool shows the ST that ClearSCADA generates for your diagram, from which you can clearly see the execution order. If the order is not as you expected, you can alter your diagram as required. When you save the altered diagram, ClearSCADA will generate new ST for the program and you can use this to see how your changes have affected the execution order.

To run the diagnostics tool, simply display the Logic program in Design Mode, then select the Build menu, then the Compile with Diagnostics option.

Example:

The following function block diagram is an example of a Logic program that could be used as a safety interlock for controlling a pump. It is used to control a pump - the pump cannot be started when there is no flow. This is achieved by establishing these relationships:

  • When a ‘StartPump’ signal is sent, the pump motor starts. However, if a flow has not been detected after a 120 second period, the pump is stopped and locked out (the pump stops responding to controls).
  • When a ‘StopPump’ signal is sent, the pump motor stops running.
  • When a ‘ResetPump’ signal is sent, the pump is no longer locked out. A ‘StartPump’ signal can be sent to the pump to attempt to start it, but if a flow is not detected within 120 seconds, the pump will be locked out again.

As you can see, the ‘LockedOut’ output is also used as an input for an AND function. This means there is a ‘feedback loop’.

Engineers can view the execution order by running the Compile with Diagnostics tool. This displays the function block diagram as ST code in the compiler, and lists the order in which the various elements of the program are executed.

The execution order is shown in the ST code in the Compiler.

The Compile with Diagnostics feature is selected and it shows the ST that ClearSCADA has generated for the Function Block Diagram. The execution order is clearly shown in the ST code, with the code being executed from top to bottom:

By analyzing the ST that has been generated for the Function Block Diagram, we can see that the execution order is as follows:

ClearSCADA executes the elements to produce the ‘LockedOut’ output/input first, and then executes the elements required to produce the ‘PointState’ output.


Logic Guide - Troubleshooting Logic Programs (Working with Logic Programs)

Troubleshooting Logic Programs

When configuring a Logic program, you can use the compile feature to check the validity of your program. For more information, see:

  • Compiling an ST Program or ST Library
  • Compiling a Ladder Diagram
  • Compiling a Function Block Diagram or Function Block Library
  • Compiling a Sequential Function Chart.

However, it is possible to have a program compile successfully at the time of configuration, but be unable to execute correctly at a later date. If your program is unable to execute correctly, there are many possible causes, including:

  • A database item that is referenced by the Logic program has been deleted from the database. In this situation, you need to either reconfigure the program to reference a different item or create a new item with the same address and name as the item that was deleted.
  • The program is set to execute On Input Processed and does not contain a valid input (see Define the Execution Method for a Logic Program)
  • The program cannot read from, or write to, a property tag that is referenced in the program
  • The program contains a calculation that is attempting to divide by 0
  • A subscript value for an array exceeds the range specified for the array
  • The order of execution is not as expected. This is often due to the use of ‘feedback loops’ where an output is also used as an input. You can use the Compile with Diagnostics option to view the actual order in which ClearSCADA executes your program and then adjust your program accordingly (see Execution Order for Logic Programs).

In many cases, you will need to reconfigure your Logic program.

To find out more information about the specific configuration issue that is affecting the execution of your Logic program, we recommend that you:

  1. Display the Logic Execution Status List (display the Queries Bar, expand the Queries branch, then display the Logic Execution Status List).
  2. Locate the entry that corresponds to your Logic program
  3. Examine the Error Message entry for your program. The Error Message provides a brief description of the cause of the Logic program’s inability to execute.
  4. Re-configure the Logic program so that the issue described in the Error Message is resolved.


Logic Guide - ST Programs

ST Programs

Structured Text is a high level programming language that you can use to define the relationships between values.

ST programs can consist of:

  • Variables—Input and output values that can change. There are also internal variables which are values that are only used within the ST program. For example, an ST program can read the value of an input (such as the value from a property of a database item), use an internal value to perform a calculation on the input value, then write the result of the calculation to an output value.
  • Constants—These are special types of value that are used by the ST program. These values are fixed and cannot change (they are constant).
  • Data Types—There are several types of value. You need to specify which type of value is applicable to each variable. For example, values such as descriptions are STRING values (they contain a string of characters) whereas values from analog points are REAL or LREAL values.

There are built-in data types, also referred to as literals, that you can use to define the type of a value. You can also use derived data types to apply meaningful names to values, group internal values, and form arrays etc.

  • Methods—These are actions that can be performed by an ST program. For example, an ST program can be created to acknowledge an alarm when a specific condition occurs.
  • Control Structures—Control structures are used to define the Logic of the ST program. By using keywords and adhering to the formatting rules, you can create a flow of conditions and results. These define the behavior that the ST program provides.
  • Function Blocks—Function blocks are blocks of code that provide specific functionality, for example, convert a temperature in Celsius to a temperature in Fahrenheit. The function blocks can be used over and over again in each of your Logic programs, including ST programs.

To configure an ST program, you will need an appreciation of the Structured Text standard. As the ST programs are not graphical, some users find them more difficult to work with. However, you need to have an understanding of ST as you may need to use ST when working with Function Block Diagrams, Sequential Function Charts etc. This is especially true if you need to reference historic data or are using SQL queries.

We recommend that you familiarize yourself with the following sections, even if you do not intend to work with ST programs:

  • Create an ST Program in the ClearSCADA Database
  • Edit an ST Program
  • Understanding the Basic Structure of an ST Program
  • Statements, Expressions and Operators
  • Entering a Comment
  • Internal Variables
  • Direct Variables
  • Constants
  • Historic Values in ST Programs
  • Built-In Data Types
  • Derived Data Types
  • Setting the Default Values
  • Executing Methods on Database Items
  • Controlling the Flow of the Program
  • Using an ST Program to Call an SQL Query
  • Inserting, Updating, and Deleting Values by Using SQL in an ST Program
  • Passing Multiple Parameters into an SQL Query in an ST Program
  • Function Blocks in ST Programs
  • Using Libraries in ST Programs
  • Compiling an ST Program or ST Library
  • Debugging an ST Program or ST Library
  • Viewing the Variables in your ST Program

By familiarizing yourself with some of the ST basics, you will find it much easier to understand the principles of the other types of Logic program.

For information on configuring the various properties of an ST program, see Logic Program Properties and Values.


Logic Guide - Create an ST Program in the ClearSCADA Database (ST Programs)

Create an ST Program in the ClearSCADA Database

Before you can create an ST program in ClearSCADA, you need to add an ST Program item to the database. The ST Program item will store the ST code that you create.

To create an ST Program database item:

  1. In the Database Bar, right-click on the system, Group, or Group Template that is to contain the ST program.
    A context sensitive menu is displayed.
  2. Select the New option, then the Logic option, then the Structured Text Program option.
    A new ST program database item is added to the hierarchy. It is selected automatically, ready for you to define its name.
  3. Enter a suitable name for the ST program then press the Enter key or select another part of the interface to confirm.
  4. You have now created the ST program database item. To create your ST program, you will need to edit it (see Edit an ST Program).


Logic Guide - Edit an ST Program (ST Programs)

Edit an ST Program

To enter the code for an ST program, you need to edit as ST Program database item. During the editing process, you will enter the code that defines the behavior that is to be provided by the program, for example, you could enter the code that allows the ST program to perform a calculation. When you save the code, the program you have created is stored in the ST Program database item.

To edit an ST program:

  • In the Database Bar, either double-click on an ST program item or right-click on it and select the Edit option from the context sensitive menu.
    The ST program is displayed in Design mode. You can only edit an ST program in Design mode.
    Enter your ST program code in the editor.
    Diagnostic information is shown in the Compiler.

The main display area of the ST program editor shows the ST program. Each ST program has PROGRAM <program name>, ;, and END_PROGRAM by default as ST programs require these attributes. You will define the Logic of your ST program between PROGRAM and END_PROGRAM.

At the bottom of the ST program editor is a smaller frame. This frame is the compiler. ClearSCADA displays diagnostic information in this section.

To code an ST program, you will need an understanding of the Structured Text language. We explain some of the basic principles of the ST language in the following sections, but you may need to broaden your knowledge by referring to a Third Party source:

  • Understanding the Basic Structure of an ST Program
  • Entering a Comment
  • Internal Variables
  • Direct Variables
  • Indirect Variables
  • Constants
  • Setting the Default Values
  • Built-In Data Types
  • Derived Data Types
  • Executing Methods on Database Items
  • Controlling the Flow of the Program
  • Using an ST Program to Call an SQL Query
  • Inserting, Updating, and Deleting Values by Using SQL in an ST Program
  • Passing Multiple Parameters into an SQL Query in an ST Program
  • Function Blocks in ST Programs
  • Using Libraries in ST Programs.

The following sections explain how to check that your ST program is coded correctly:

  • Compiling an ST Program or ST Library
  • Debugging an ST Program or ST Library
  • Viewing the Variables in your ST Program.

The following section explains how to configure your ST program (including how to define when the program is executed):

  • Logic Program Properties and Values.


Logic Guide - Understanding the Basic Structure of an ST Program (ST Programs)

Understanding the Basic Structure of an ST Program

Before you begin to create your own ST programs, you need to be aware of the basic structure of an ST program.

  1. The start of the program.

ST programs begin with a PROGRAM keyword and a program name. This is followed by a VAR keyword and a list of variables.

  2. The variable blocks.

There are 2 types of VAR block—VAR blocks for internal variables and VAR blocks for direct and indirect variables. Variables of different types have to be defined in separate blocks.

For internal variables, the VAR block will begin with a VAR keyword. The variables are defined after the VAR keyword and use the format:

<name> : <type>;

For direct and indirect variables, the VAR block will also begin with a VAR keyword. The variables are defined after the VAR keyword and use this format:

<name> <instruction> (<item>.<variable>) : <variable type>;

For example:

VAR
Desc AT %I(.Valve.Position.CurrentStateDesc) : STRING;
END_VAR

Each VAR block is ended by an END_VAR keyword.

When you are using variables, you need to:

  1. Define the type for any arguments
  2. Separate each argument type with a comma, for example, STRING, BYTE,STRING; means there are 3 arguments, the first is a string, the second is a byte, and the final argument is a string.
  3. Use VAR INPUT definitions to allow the ST program to receive inputs from a user/another ST program. The VAR INPUT keyword needs to be included in the recipient program (so, if one ST program receives the inputs for its indirect variables from another program, the program that receives the inputs has to have VAR INPUTS).
  4. Define the VAR INPUTS in the same order in which they are to be executed.

To allow a program to use the values from another program, the arguments for the indirect variables’ inputs have to be in the same order in both programs. For example, Program 1 defines a method that has outputs in this order: STRING, BYTE. These values are output to Program 2. In Program 2, the VAR INPUT definition has to define that the first argument is a STRING and the second argument is a BYTE as this is the order defined in Program 1.

  5. Set the Interval to 0s on the ST Program Form for the recipient ST program. Programs that use manually entered input values or input values from other programs cannot be executed on an interval basis. However, they can be executed by another program (the other program executes the recipient ST program at a regular interval), according to a schedule, and manually. If required, configure a schedule to execute the program at specific times (see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration).

If you execute a recipient ST program manually, you will be prompted to enter the input value. You need to enter the input value in the dialog box and select the OK button to proceed. You will only be prompted to enter a value if the recipient program has inputs defined, but the inputs are not associated with other programs.

  3. The method block.

If an ST program uses methods, the methods are defined in a METHOD block. The METHOD block has to follow the VAR block(s) and also come before the ST code for the program. If the ST program does not use methods, there is no METHOD block and the ST code for the program follows the last VAR block.

The METHOD block begins with a METHOD keyword. The methods that the program uses are listed and use this format:

<name> <instruction> (<item>.<method>) : <argument types>;

For example:

METHOD
OVR AT %M(AIs.AnalogInp.Override) : LREAL;
END_METHOD

The METHOD block is ended by an END_METHOD keyword.

  4. The ST code for the program. This can include statements, expressions, and operators.
  5. The end of the program.

Each ST program is ended with the END_PROGRAM keyword.

In the following basic example, the ST program contains 3 variables and 3 methods. ST programs can contain as many variables and methods as required.

For the example, entries in angle brackets < > indicate a name or type that you have to enter for the program. These will vary depending on the items you want to reference and the names you want to use. You should not enter the angle brackets in your ST programs—we use them here to indicate that you need to specify a name, location, or data type that will vary according to your needs.

PROGRAM <program name>
VAR
<name> : <type>;
<name> : <type>;
<name> : <type>;
END_VAR
METHOD
<name> AT %M(<location and name of item>.<method>) : <argument types>;
<name> AT %M(<location and name of item>.<method>) : <argument types>;
<name> AT %M(<location and name of item>.<method>) : <argument types>;
END_METHOD
<ST code>;
<ST code>;
<ST code>;
END_PROGRAM

The ST program begins with a PROGRAM definition and the program name. This is followed by a VAR definition, and the names and types of the variables that are used by the program. The list of variables is referred to as a VAR block, and it is ended by an END_VAR definition.

If the ST program uses methods, a METHOD block is defined after the VAR block. The METHOD block consists of the METHOD keyword followed by the name of a method, an instruction, the location and name of the item to which the method will be applied, the name of the method to be applied, and the argument types that will be used (argument types are types of data for specific settings, for example, the Override method needs an argument type that specifies the type of value for the override value). The METHOD block is ended with an END_METHOD keyword.

The ST code that defines the behavior that the program provides is entered after the METHOD block (or after the VAR block if there is no METHOD block).

The program is ended by the END_PROGRAM keyword.

NOTE: Constants also need separate VAR blocks—see Constants.


Logic Guide - Statements, Expressions and Operators (ST Programs)

Statements, Expressions and Operators

You need to use Structured Text statements, expressions, and operators to define the instructions, calculations, and relationships for each ST program.

The types of operators and expressions that you use in your ST program affects the order in which the expressions are evaluated.

For more information, refer to the following sections:

  • Statements
  • Expressions
  • Operators.


Logic Guide - Statements (ST Programs)

Statements

Statements are used to provide an instruction, such as assign a variable. They can contain expressions (which are calculations). The basic format for a statement is:

<variable>:= <expression>;

Where the <expression> is a calculation that produces a new value for <variable> when the statement is evaluated.

Examples:

This statement defines the value of a variable named 'FlowRate'. It defines a constant value (also known as a literal value):

FlowRate:= 64.5;

The next statement defines a basic expression that can be used to increase a value by a defined amount:

Count:= Count + 1;

The value for the Count variable increases by 1 each time the statement is evaluated.

These are simple examples of statements. You can create much more complicated statements, including statements with nested expressions.


Logic Guide - Expressions (ST Programs)

Expressions

Expressions are calculations or evaluations that are defined within Statements. They can use one or more operators, functions, and variables.

Each ST expression produces a value which can be wither a built-in data type (see Built-In Data Types) or a derived data type (see Derived Data Types). These values can be used within a program or can be written to items in the database.

An expression can be simple or complex. A simple expression includes a single calculation, for example:

y + 10

or a Boolean expression such as:

x = y

A complex expression contains several calculations that are used to produce a value, for example:

(x + y) * 2

Expressions are evaluated in order. The precedence of the operators and other expressions in the statement determines when an expression is evaluated. Expressions are evaluated in this order:

  1. Parenthesized expressions, such as:
(x + y) * 2

  2. Function calls, such as:
COS(x)

Where COS is the function being called, and x is the argument.

Within this order, operators are evaluated in precedence order (see Operators). For example, a parenthesized expression with negation will be evaluated before a parenthesized expression with inequality.

NOTE: For Boolean operators, the expression is evaluated up to the part of the statement at which the value can be determined.


Logic Guide - Operators (ST Programs)

Operators

Operators are the calculations and conditions that are used to define the behavior that is provided by a Logic program. Each operator provides a specific calculation or comparison, for example, the > operator means 'greater than' and the < operator means 'less than'. They can be used in an expression that compares values like this:

IF Value1 > 50 THEN
Value2 := 10;
ELSIF Value1 < 50 THEN
Value2 := 5;
END_IF;

In this expression, if Value1 is greater than 50, then Value2 is 10. If Value1 is less than 50, then Value2 is 5.

Each operator has a precedence level. This determines the order in which the operations are evaluated.

The following table shows the available operators and their precedence:
Operator | Description | Precedence Level
( <expression> ) | Expression inside parentheses ( ) | 1 (Highest)
Function (<expression>) | Parameter list of a function or function evaluation | 2
** | Exponentiation | 3
- | Negation | 4
NOT | Value with opposite sign | 4
* | Multiplication | 5
/ | Division | 5
MOD | Modulus operation | 5
+ | Addition | 6
- | Subtraction | 6
< | Less than | 7
> | Greater than | 7
<= | Less than or equal to | 7
>= | Greater than or equal to | 7
= | Equality | 8
<> | Inequality | 8
AND, & | Boolean AND | 9
XOR | Boolean exclusive OR | 10
OR | Boolean OR | 11 (Lowest)


Logic Guide - Entering a Comment (ST Programs)

Entering a Comment

Comments are notes that you can add to your ST program. They are useful as they allow you to annotate your code with descriptions etc.

Comments are optional and have no effect on the program. Typically, they are used to explain the structure and purpose of sections of ST code to other users.

To enter a comment in your ST program, you need to use the following format:

(* <comment>*)

For example:

(* This calculation is used to increase the count each time the input is greater than 50*)


Logic Guide - Internal Variables (ST Programs)

Internal Variables

Each type of Logic program can contain internal variables. These are values that are used by the program but are not written to an item in the database. They are used for:

  • Conversions
  • Separating long, complex calculations into smaller sets of calculations
  • Storing program states.

Unlike direct variables, internal variables are not stored in the database. This means that if the program or the server is reset, the internal variables will reset to their default value (you can stop internal variables from resetting by using the RETAIN keyword, as explained later in this section). As internal variables are not stored, they are not transferred to any standby servers (again, this can be avoided by using the RETAIN keyword).

Internal variables are stored internally so that Logic programs can maintain the internal variables for each execution. For example, if an internal variable is used as a count, the previous value needs to be stored so that the program can use it to determine the next value.

NOTE: Internal variables need to be separated from direct variables, constants and function blocks in the VAR lists. This means that if you have a program that uses constants, internal variables, direct variables, and function blocks, you will have at least 4 VAR lists—1 for constants, 1 for internal variables, 1 for direct variables, and 1 for function blocks.

For information on adding internal variables or using the RETAIN keyword, please refer to the relevant sections:

  • Adding an Internal Variable to an ST Program
  • Using the RETAIN Keyword in an ST Program.


Logic Guide - Adding an Internal Variable to an ST Program (ST Programs)

Adding an Internal Variable to an ST Program

To add an internal variable to an ST program, you need to define the internal variable in a VAR list. You can then use the internal variable throughout the ST program.

You have to define internal variables in the following format:

VAR
<Value Name> : <Value Type>;
END_VAR

Where <Value Name> is the name you allocate to the internal variable, and <Value Type> is the data type of the internal variable (see Built-In Data Types and see Derived Data Types).

You can then refer to the internal variable by name in your ST program. For example:

VAR
TimeCount:TIME;
END_VAR
VAR
TimedStart AT %M(.Power.StartMotor.CurrentState):BOOL;
END_VAR
IF TimeCount > T#60s THEN
TimedStart := TRUE;
ELSE
TimedStart := FALSE;
END_IF;

This program uses an internal variable to act as a timer. When the timer exceeds 60, the state of a direct variable (TimedStart) changes from FALSE to TRUE.

The internal variable is defined in a separate VAR list to the direct variable. This is because internal variables and direct variables cannot be listed in the same variables list. To overcome this, you need to create multiple VAR lists. Each VAR list needs to be structured in the same way as any other VAR list except that the END_VAR only has a semi-colon at the end of the final VAR list.

For more information on data types such as BOOL, please refer to Built-In Data Types. You can also create custom data types that allow you to group internal variables and define meaningful names for value types (see Derived Data Types).

For information on Logic keywords that you can use to control the behavior of the program, such as IF and THEN see Controlling the Flow of the Program.


Logic Guide - Using the RETAIN Keyword in an ST Program (ST Programs)

Using the RETAIN Keyword in an ST Program

Normally, internal variables are not stored for use after the program or server has been reset. Similarly, they are not transferred to any standby servers.

However, it is possible to store internal values so that:

  • They are not reset to their initial values when the server or program is reset
  • They are transferred to any standby servers.

To do this, you need to use a RETAIN keyword. The RETAIN keyword instructs the program to store the internal variable so that it can transferred and used after a reset.

In ST programs, you need to use the following format to retain the internal variables:

VAR RETAIN
<Value name> :<Value type>;
END_VAR

For example:

VAR RETAIN
TempConversion: INT;
END_VAR

Where TempConversion is the name of the internal variable and INT is the type of value that it represents (an integer).


Logic Guide - Direct Variables (ST Programs)

Direct Variables

Direct variables are values that are read from (or written to) items in the ClearSCADA database. You need to reference direct variables in your Logic programs to allow them to react to values in the database and apply changes to values in the database.

There are several ways of accessing direct variables in your ST programs. The most effective type of access for you to use varies according to what you need to achieve.

Usually, if you need your Logic program to read values from the database or write values to the database, you will use a:

  • Variables List (see Using the VAR List to Access Direct Variables).

However, there are some situations in which using an alternative way of accessing the direct variables is more effective:

  • If you need to prevent your ST program from using values stored in the cache, you may need to use a VAR list in conjunction with the NOCACHE keyword. For example, you will need to use the NOCACHE keyword if your ST program has values that accumulate with each execution of the program (see Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program).
  • If you need your ST program to reference the same properties for a large number of database items of the same type, you should use a Database Object Structure (see Using Database Object Structures to Access Direct Variables).By using a Database Object Structure, you can reduce the amount of time and effort required to create the references to the database.
  • If you need your ST program to access multiple database items that meet certain criteria (but are not named explicitly in the program), you should use an SQL Query to access the database. The SQL Query can be included within your ST program (see Using SQL Queries to Access Direct Variables).
  • If you need your ST program to read values from, or write values to an array, you need to use Vectors to access the direct variables (see Using Vectors to Access Direct Variables).
  • If you need to access historic values, please refer to Historic Values in ST Programs.


Logic Guide - Using the VAR List to Access Direct Variables (ST Programs)

Using the VAR List to Access Direct Variables

For ST programs, you need to define direct variables in a VAR variables list. The variables list comes after the PROGRAM keyword and uses this syntax:

VAR
<Name of variable> AT <AccessType>: <Type of variable>;
END_VAR

For example:

VAR
Input AT %I(..TemperatureSensor.CurrentValueFormatted): STRING;
END_VAR;

In this example, the variable value is a read only value (indicated by %I). It is read from the CurrentValueFormatted tag of the TemperatureSensor database item. The reference to the TemperatureSensor item is relative—the two periods indicate the levels in the hierarchy.

The %I code is used to indicate that the variable is read only. Read Only is one of three possible access types for variables:
Characters | Access Type
%I | Read Only
%Q | Write Only
%M | Read and Write

When you reference a database item in a Structured Text program, you can specify a field or leave the program to reference the default field for the database item. For example, if you do not specify a field for a point, the CurrentValueFormatted field is referenced.

You can specify which field is referenced by adding the name of the required field to the end of the item's path. You have to place a period between the end of the path and the name of the field, for example:

Desc AT %I(.Valve.Position.CurrentStateDesc) :STRING;

In this example, the CurrentStateDesc field is referenced and is used for a read-only string value.

NOTE: Direct variables need to be separated from internal variables, constants and function blocks in the VAR lists.

For more information on data types such as STRING, please refer to Built-In Data Types. You can also create custom data types that allow you to define meaningful names for value types (see Derived Data Types).

For information on Logic keywords that you can use to control the behavior of the program, such as IF and THEN see Controlling the Flow of the Program.

Example: Reading a Point Value and Writing it to Another Point

In this example, an ST program is used to read the current value of a point named 'TemperatureSensor1'. The value that is read is then written to the current value of a point named ‘TemperatureSensor2'.

PROGRAM ReadTempWriteTemp

VAR

Input AT %I(TemperatureSensor1.CurrentValue): INT;

Output AT %M(TemperatureSensor2.CurrentValue): INT;

END_VAR;

Output:=Input;

END_PROGRAM

The %I is used to read a value from the database and %M is used to write a value to the database (%M can be used to both read and write).


Logic Guide - Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program (ST Programs)

Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program

You can use the NOCACHE keyword in your Logic programs to prevent the program from using a cached value. This is required when you need a value to accumulate each time a program executes, for example, when a total count value needs to increase when an input value changes.

If the NOCACHE keyword is not used, the ST program will use the value that was in place when the program first executed. This means that when a series of values are reported for one of the ST program's inputs, the value of the variable that is affected by the inputs will be the same. In the example below, the NOCACHE keyword is used to prevent the program from calculating the Total value as 0.0 + the current value of the Value variable. So, if the program receives 10 values for the Value variable, the program will use the default value of 0.0 for the Total value on the first execution, but will not use 0.0 on subsequent executions. If the NOCACHE keyword was not used, the program would use the 0.0 value for the Total value for each execution.

Example:

PROGRAM TotalValues
VAR
FirstTime:BOOL := TRUE;
END_VAR
VAR
Value AT %M(Input Point Value): REAL;
END_VAR
VAR NOCACHE
Total AT %M(Total Point): REAL;
END_VAR;
IF FirstTime THEN
Total := 0.0;
FirstTime := FALSE;
END_IF;
Total := Total+Value;
END_PROGRAM

In this example, the FirstTime value is a Boolean value (true/false) that is used to define whether the program is being executed for the first time. By default, it is set to TRUE.

The Value variable is a real value that the program reads from the Input Point Value database item.

The Total value is a NOCACHE value (it is not cached and is retrieved each time the program executes). The Total value is a real value that is calculated by the program each time it executes. The result of the calculation is written to the Total Point database item.

The If statement determines whether the Total value is 0 or is another value. If the FirstTime value is TRUE then the Total value is 0.0 (the FirstTime value is only TRUE the first time that the program executes). If the FirstTime value is FALSE, the FALSE value is maintained and the Total value is the current Total value + the value of the Value variable.

This means that the first time the program executes, the Total value is 0.0. Before the first execution of the program completes, it sets the FirstTime value to FALSE so that the next execution of the program will cause the Total value to change from 0.0. At the end of the first execution of the program, the Total value is set to the same value as the Value variable (Total=0.0 + Value = Same value as Value variable).

On subsequent executions of the program, the FirstTime value will be FALSE and so the Total will be the current Total value + the value of the Value variable. The program will not use 0.0 as the Total value each time, as the 0.0 is not cached.

To define a NOCACHE value, you have to create a separate VAR list for the values to which the NOCACHE feature applies. The VAR list has to be started as VAR NOCACHE. The values need to be entered beneath the VAR NOCACHE definition in the same way as with normal VAR lists, and the VAR list needs to be closed with END_VAR.


Logic Guide - Using Database Object Structures to Access Direct Variables (ST Programs)

Using Database Object Structures to Access Direct Variables

When using direct variables, you need to declare the variables that are used by the Logic program. The variables have to be declared in VAR blocks. This can be time-consuming if the Logic program needs to reference the same set of properties for many different items of the same type.

ClearSCADA provides a structure for referencing multiple fields of a single database item. The structure is called a database object structure, and it allows you to group a set of fields for a type of item. The structure is included at the top of the Logic program and can be referenced within the program. This means that you can reference the name of the structure instead of referencing multiple fields several times in the same program.

For example, if your ST program references the CurrentValueFormatted, CurrentState, and QualityStateDesc of 30 points, you would have to enter the variables for each separate point. This means you would have to define the CurrentValueFormatted, CurrentState, and QualityStateDesc variables 30 times (each field for each point).

By using a database object structure, you can create a single reference to the CurrentValueFormatted, CurrentState, and QualityStateDesc fields. The database object structure includes the specified fields in the relevant class (in this case, the CDBPoint class). This means that the same database object structure can be used to reference the specified fields for any item in the class—it can be used for any point.

Example:

A Logic program needs to reference the CurrentValueFormatted, HighLimit, CurrentState and CurrentStateDesc fields of a 20 different points. If the database object structure is not used, you will have to add these fields to the program (for each of the 20 points).

The following database object structure is used:

TYPE
PointValues : DATABASE_OBJECT(CDBPOINT)
CurrentValueFormatted: LREAL;
CurrentState: BOOL;
QualityStateDesc: STRING;
END_DATABASE_OBJECT;
END_TYPE

By using the database object structure, the fields are grouped at the top of the program. The database object structure is allocated a name (PointValues). Where the program needs to refer to the fields, the name of the database object structure and the specific point is used. This means that the database object structure can be used to refer to the same specified fields for multiple points.

In the program, references to the point values use this format:

<name of variable> AT %M(<path of item>) : <name of DATABASE_OBJECT structure>;

For example:

InputVal AT %M(.Group 1.LimitPoint) : PointValues.CurrentValueFormatted;

Where InputVal is the name of the variable, and AT %M indicates that the value is a read/write value. (Group 1.LimitPoint) specifies the location of the point that is being referenced (the 'LimitPoint' that is stored in the 'Group 1' Group). PointValues is the name of the database object structure, and .CurrentValueFormatted is the specific field that needs to be referenced.

This means that each point value can be referenced by a single line. The VAR list only needs to contain the database object structure and one set of the fields that are to be included—there is no need to reference each field for each item.

When you create a database object structure, you need to adhere to these rules:

  • The database object structure has to be specified within a TYPE definition.
  • The TYPE definition has to be positioned at the top of the ST program, above the PROGRAM information.
  • The name of the database object structure is the first part of the definition. It is followed by DATABASE_OBJECT (<class name>) where <class name> is the name of the class of database items.

You can view the classes of database items by using the ClearSCADA database schema (see Working with the Database Schema in the ClearSCADA Guide to the Database).

  • The list of referenced fields has to include field names that are identical to the field names in the database. Each field name has to be followed by its data type.

NOTE: When using an SQL Query with a DATABASE_OBJECT structure, you have to include the Id column as the first column in the SQL Query. This is because DATABASE_OBJECT structures have an Id field, although this field is not referenced in the DATABASE_OBJECT definition.

  • To end the list of fields, you have to enter END_DATABASE_OBJECT; To end the TYPE definition, you must enter END_TYPE.
  • The Logic program has to be entered after END_TYPE

NOTE: You cannot access database aggregates via DATABASE_OBJECT structures. You need to use standard read/write declarations to access database aggregates.


Logic Guide - Using SQL Queries to Access Direct Variables (ST Programs)

Using SQL Queries to Access Direct Variables

You can use SQL Queries in your ST programs to access the ClearSCADA database.

NOTE: SQL Queries can only be used in ST programs to access the ClearSCADA database. They cannot be used to access other databases.

ClearSCADA includes an extension to the IEC-1131 standard that allows you to use Structured Query Language (SQL) to query the ClearSCADA database. When you use an SQL Query in an ST Program, the SQL Query has to request data for the values specified in the STRUCT data structure or DATABASE_OBJECT structure (to which the values from the resultset are passed). This means that the data types specified in your STRUCT or DATABASE_OBJECT structures have to match the data types of the columns in your SQL query. When using DATABASE_OBJECT structures, the names of the values in the DATABASE_OBJECT also have to match the names of the columns in the SQL query.

When you use an SQL query to provide values for a STRUCT data structure, the values from the SQL query's resultset can only be read. STRUCT data structures cannot be used for writing to the database or calling methods. The names of the values defined in the STRUCT data structure can be anything you choose, but the data types of the values have to match the data types of the columns in your SQL query.

You can use an SQL query and a DATABASE_OBJECT structure to read the values in the resultset, write new values to the database objects represented by the rows in the resultset, and access the methods for the objects represented by the rows in the resultset. This is possible as each row of values returned for a DATABASE_OBJECT structure represent the values of a specific item in the database.

The values and value types of the DATABASE_OBJECT structure have to match the column names and value types defined in the SQL query (including the Id column which is automatically added to DATABASE_OBJECT structures).

Typically, you will use DATABASE_OBJECT structures with SQL queries more often than STRUCT data structures, as DATABASE_OBJECT structures allow for greater interaction with the database.

Further Information

STRUCT data structures: Using Structured Data Types to Group Internal Values.

DATABASE_OBJECT structures: see Using Database Object Structures to Access Direct Variables.

Using an ST Program to Call an SQL Query.

Inserting, Updating, and Deleting Values by Using SQL in an ST Program.


Logic Guide - Using Vectors to Access Direct Variables (ST Programs)

Using Vectors to Access Direct Variables

You can use vectors to read from and write to array fields in the ClearSCADA database. Vectors are similar to arrays in that they can contain multiple values, but they also have a Length and Capacity that mean they can be used to only read or write a specific number of values.

For more information, see Vectors.


Logic Guide - Indirect Variables (ST Programs)

Indirect Variables

Indirect variables are a ClearSCADA specific extension to the IEC 1131-3 language. They allow an ST Program to perform calculations on tags that are specified at runtime as opposed to hard coded tags that are used at compile time. At runtime, the program will either prompt the user to enter a string (the string is the tag of an item in the database) or will use a string from another program and use the string to calculate the tag for a direct variable. For example, the user could enter the name of a point and the point would be used in the ST program's calculation. Indirect variables are normally used with ST Programs that are triggered by schedules and method pick actions.

To enter an indirect variable, you need to use this format:

VAR_INPUT
<Name of Variable> : STRING;
END_VAR
VAR
<Name of Variable> AT<AccessType>(<Parameter>{Input Variable}<Parameter>): <TYPE>;
END_VAR

Where:

  • The VAR_INPUT declaration defines an input variable that is a String type.
  • The VAR declaration defines the indirect variable:
  • <Name of Variable> is the name that you allocate to the indirect variable. Do not enter the angle brackets < >.
  • AT <AccessType> defines whether the indirect variable is read only (%I), write only (%Q), or read and write (%M).
  • <Parameter> defines part of a tag. This is coded into the program and is not affected by the user input/input from another program for the indirect variable. The <Parameter> parts of the indirect variable are optional.
  • {Input Variable} represents the part of the tag that will be substituted by the string that is entered by the user or provided by another program. The input variable has to match the name of the input variable defined in the VAR_INPUT declaration and has to be enclosed in braces { }.
  • <TYPE> is the type of the internal variable, for example, STRING.

Example 1: Using Indirect Variables to Utilize Values provided by a User

This example demonstrates a very simple use of indirect variables. It uses an ST program that adds the values of 2 inputs and then writes the result to an output point. The inputs are provided by a user - when the ST program is executed, it prompts the user to define the source of the input values.

For this example, the following database items are created:

  • An ST Program
  • Three Internal Analog Points (named Analog Point 1, Analog Point 2, and Analog Point 3)
  • A Mimic

The ST Program is configured to use indirect variables as follows:

PROGRAM Addition
VAR_INPUT
Input1 : STRING;
Input2 : STRING;
END_VAR

VAR
Point1 AT %I(.{Input1}.CurrentValue) : LREAL;
Point2 AT %I(.{Input2}.CurrentValue) : LREAL;

Output AT %M(.Analog Point 3.CurrentValue) : LREAL;
END_VAR
Output := Point1 + Point2;

END_PROGRAM

The indirect variables are '.{Input1}.CurrentValue' and '.{Input1}.CurrentValue'. The { } instruct ClearSCADA to prompt the user for the source of the inputs. The period before the { } means that ClearSCADA will search for the source within the same Group that contains the ST program.

When executed, the program will add the current values of Input 1 and Input 2 and then write that value to the 'Analog Point 3' point.

The Mimic is configured so that it contains a button that has shows ‘Total Values’ and has a pick action animation. When the button is selected, it will trigger the Execute action for the ST Program. A text box is added to the Mimic and is configured to have a Value animation that sets the text box to display the CurrentValue property of the 'Analog Point 3' internal point..

This button is animated to have a Method pick action that executes the program when selected.
This text box has its Value property animated to show the output of the program (the total value of the 2 inputs).

A user selects the 'Total Values' button, which triggers the Execution action for the ST Program. ClearSCADA prompts the user to define Input 1 and Input 2 for the program.

In the Input 1 field, the user enters:

Analog Point 1

In the Input 2 field, the user enters:

Analog Point 2

The user then selects the OK button and the ST Program executes. It reads the current values of Analog Point 1 and Analog Point 2, adds the two values together, and then writes the result to Analog Point 3.

The text box on the Mimic is animated to show the current value of Analog Point 3, which means it displays the result of the ST Program (which was written to the Analog Point 3 point). So if Analog Point 1’s current value was 10 and Analog Point 2’s current value was 8, the ST program would write the value 18 to Analog Point 3 and this would be shown in the text box on the Mimic.

Example 2: Using Indirect Variables to Utilize Values provided by another Program

This simple example shows how indirect variables can be used to allow an ST program to use values that are provided by another ST program.

Program 1 has the following code:

PROGRAM Program1
METHOD
Exec AT %M(.Program2.Execute):STRING;
END_METHOD;
Exec ('Analog Input Point');
END_PROGRAM

The first program is named Program1 and is used to perform a method. The method is named Exec within the ST program. The Exec method declaration sets the method to Execute argument. This means that the program will write a value. The value is written to the Program2 program (which is the other ST program) which is also defined in the method declaration. The type of value that will be written is a STRING.

The method declaration is finished with the END_METHOD keyword.

The Exec ('Analog Input Point'); line instructs the Exec method to write Analog Input Point as the string value. This means that when Program 1 is executed, it will write an Analog Input Point string to the Program2 program.

The Program2 program contains the following code:

PROGRAM Program2
VAR_INPUT
PointName :STRING;
END_VAR
VAR
CurValue AT %M({PointName}.CurrentValueFormatted): LREAL;
END_VAR
CurValue:=24.4;
END_PROGRAM;

Program 2 has two variables. The first is PointName, which is a string value. The VAR INPUT keyword instructs the program that it is receiving an input value (the input value is received from Program 1). In Program 2, the input value is called PointName and it is a string. The data type for the VAR INPUT has to match the data type for the output of Program 1.

Program 2 automatically detects that it has a string input from Program 1 (there is only 1 input).

The second variable is CurValue which is the CurrentValueFormatted of the item that has the same name as the PointName variable. In this case, it means that the CurValue is the value that is written to the current value of the database item that is named 'Analog Input Point'. The CurValue is a long real value.

The variable declarations are ended by END_VAR.

The CurValue :=24.4; line sets the value that is written to the current value of the database item that is named 'Analog Input Point'.


Logic Guide - Constants (ST Programs)

Constants

Constant values are values that remain the same each time the program executes, such as pi, time intervals, fixed text string etc. For example, if a program needs a point to change state after a 2 minute pause, a constant can be used to define the 2 minute time period. Although the time period does decrease from 120 seconds to 0 seconds as the program executes, it is still represented by a constant as the time value is fixed as 120 seconds when the program is executed.

NOTE: Constant variables need to be separated from internal variables, direct variables and function blocks in the VAR lists. This means that if you have a program that uses constants, internal variables, direct variables, and function blocks, you will have at least 4 VAR lists—1 for constants, 1 for internal variables, 1 for direct variables, and 1 for function blocks.

To enter a constant value, you need to use this format:

VAR CONSTANT
<Constant Name> : <Value Type> = <Value including code characters>;
END_VAR

For example:

VAR CONSTANT
Timer:TIME := T#60s;
END_VAR

Where VAR CONSTANT instructs the program that the value is a constant, read only value. Timer is the name of the constant, and TIME is the value type. T# is the code for time values (see Time and Date Values) and 60s is 60 seconds. The s for seconds is lower case, as are time units. END_VAR is used to end the list of constants. If there are other VAR lists after the constant list, the END_VAR should not have a semi-colon at the end. However, if the constant list is the last list of variables for your program, you have to add a semi-colon to the end, like this: END_VAR;

NOTE: Unlike internal and direct variables, constants can only be of a certain data type. Each constant value has to be one of the Built-In Data Types.


Logic Guide - Historic Values in ST Programs (ST Programs)

Historic Values in ST Programs

You can use historic data variables in your ST programs and Function Block Diagrams.

The following sections explain how to add raw and processed historic variables, and describe how to specify which historic values are used by your program:

  • Accessing Historic Direct Variables
  • Processed Historic Values in ST Programs (Historic Data Arrays)
  • Historic Functions and Arguments.


Logic Guide - Accessing Historic Direct Variables (ST Programs)

Accessing Historic Direct Variables

You can use historic data variables in your ST programs and Function Block Diagrams. You can refer to raw values or processed values that use historic algorithms (average values for example).

In this section, we explain:

  • Raw Historic Values in ST Programs
  • Raw Historic Values in SQL Queries

Raw Historic Values in ST Programs

You can use raw historic values as inputs in your ST programs.

In ST Programs, you need to specify the raw historic variables in the VAR variables list. The format for a historic variable needs to be:

<name of variable> AT %I(<Path of point>.Historic.<Historic Function> (<arguments for historic function>) : <type of variable>;

For example:

LastHistoricValue AT %I(Analog Input.Historic.RawValue ('D-1H', 'H+1H', 0, TRUE)) : LREAL;

The variable definition (above) has the name LastHistoricValue. The %I is used as historic values have to be read only.

Analog Input is the name of the point (which is located in the root directory). Historic is required to instruct the program to use the point's historic data. RawValue is the historic function (see Historic Functions and Arguments for more information).

('D-1H', 'H+1H', 0, TRUE) indicates the arguments for the RawValue function. Each different type of function requires different arguments. The arguments are listed in Historic Functions and Arguments.

LREAL is used to indicate the type of value that is the output of the historic variable.

ATTENTION: You should construct your queries so that they query limited amounts of historic data. Large and inappropriate query searches can severely affect system performance and can potentially delay other system operations.

Raw Historic Values in SQL Queries

You can use SQL Queries in your Logic programs to retrieve multiple raw historic values. As the values are retrieved via an SQL Query, the Logic program only retrieves one value at a time—multiple values are retrieved by using a 'loop' such as a WHERE or FOR clause. This causes the program to retrieve the historic values in the specified range one at a time, in turn.

To retrieve multiple historic values via SQL, you first need to define a TYPE. The Type defines a record set which includes the fields for which values are to be returned. The SQL query needs to be added to the VAR variables list, and it has to reference the record set.

Example:

In this example, an SQL Query is used in an ST Program. It allows the ST Program to retrieve a point's historic values between the start of the current hour (H in the OPC time standard) and the end of the current hour (H+1H in the OPC time standard).

TYPE
HistoricRecord : STRUCT
Time : DATE_AND_TIME;
ValueAsReal : LREAL;
END_STRUCT;
END_TYPE
PROGRAM NewStructuredTextProgram
VAR
Historic AT %S(SELECT RecordTime, ValueAsReal FROM CDBHistoric JOIN
CDBPoint USING (Id) WHERE CDBPoint.FullName = 'Random.Value' AND RecordTime
BETWEEN { OPC 'H' } AND { OPC 'H+1H' }) : RESULTSET OF HistoricRecord;
END_VAR;
END_PROGRAM

At the start of the program, there is a TYPE definition. This is used to create a record set. In this case, the record set is named HistoricRecord and it is a structured data type (STRUCT).

The values that are to be retrieved for the record set are specified in the TYPE definition: Time and Value. The data types for these values are also specified (DATE_AND_TIME and LREAL).

The VAR variables list contains the SQL Query that is used to define which point is to have its historic values read. It also defines the time range for the values—the program will only read the historic values for the period within the defined time range.

We will look at each part of the variable definition in turn:

Historic AT %S

Historic is the name of the variable that includes the SQL Query. AT %S informs the program that the variable uses an SQL Query.

(SELECT RecordTime, ValueAsReal FROM CDBHistoric

This is the first part of the SQL Query. It instructs the program to retrieve the values from the RecordTime field and the ValueAsReal field in the CDBHistoric class. The RecordTime value will be used as the Time value (specified in the TYPE definition at the start of the program) and the ValueAsReal value will be used as the ValueAsReal value.

JOIN CDBPoint USING (Id)

As the CDBHistoric class does not contain the name of the required point, the SQL Query needs to define a JOIN. The JOIN combines the CDBPoint class and the CDBPoint class into a single table. To combine the point values and the historic values correctly for each point, the SQL Query has to define the criteria by which the program will join the two tables. The USING (Id) definition instructs the program to join the data in the CDBPoint class to the data in teh CDBHistoric class based on the Id values—the Ids for the points are identical in both the CDBHistoric class and the CDBPoint class.

WHERE CDBPoint.FullName = 'Random.Value' AND RecordTime BETWEEN { OPC 'H' }
AND {OPC 'H+1H' })

The WHERE clause specifies the point for which historic data is to be retrieved. It also specifies the fields for which values are to be returned. The BETWEEN clause specifies the time range—the SQL Query only returns values that were stored during the specified time range.

: RESULTSET OF HistoricRecord;

Finally, the RESULTSET OF HistoricRecord instructs the program that the values that are returned are to be the values for the HistoricRecord record set.

ATTENTION: You should construct your queries so that they query limited amounts of historic data. Large and inappropriate query searches can severely affect system performance and can potentially delay other system operations.


Logic Guide - Processed Historic Values in ST Programs (Historic Data Arrays) (ST Programs)

Processed Historic Values in ST Programs (Historic Data Arrays)

You can use processed historic data values in your ST programs.

An ST program can be used to retrieve processed historic data from the ClearSCADA database and return the processed values into a historic array.

Historic arrays allow a Logic program to use multiple historic values as inputs. The array acts as a table, with each returned value occupying one row of the table. You can then use your ST program Logic to use the returned values.

NOTE: Historic Arrays can only be used as single dimension tables with one column. Unlike arrays for current data, historic arrays cannot return values that can be used in a matrix.

When you use processed historic values in an ST program, you need to enter a variable for the array in the VAR variables list. The variable has to be defined using the following format:

<name of variable> AT %H(<path of point>.Historic;<name of historic algorithm>; <start of time range>;<frequency of values>) : ARRAY [<number of first value in range>..<number of last value in range>] OF <data type of variable>;

Example:

The following variable is used to return the average historic value for each hour in the day:

HourlyAverage AT %H(AnalogInput.Historic;Average;D-1D;1H) : ARRAY [0..23] OF LREAL;

Where HourlyAverage is the name of the variable. %H is required as this instructs the program to use historic data.

AnalogInput is the name of the point that has the historic data that the ST program is going to use. Historic;Average; indicates that the program will use the values that are stored for the point's Historic.Average tag. D-1D;1H indicates the time period for the historic data—the values for each hour (1H) starting from the beginning of yesterday (D-1D).

ARRAY [0..23] is used to instruct the program that the values will be returned as an array, and that there will be 24 values (0-23 inclusive). OF LREAL; indicates that the values in the array will be long real values.

The historic array returns 24 average values, for example,

A [0] : = 3.5;

A [1] : = 3.9;

A [3] : = 3.6;

A [4] : = 3.6;

A [5] : = 3.2;

A [6] : = 3.7;

and so on.

Each of these values can be used in the ST Program.


Logic Guide - Historic Functions and Arguments (ST Programs)

Historic Functions and Arguments

You need to use historic functions to specify which historic values are used by your program. Each historic function requires values for its arguments (as shown below). You have to include each argument when you use a historic function in an ST program or Function Block Diagram.

The arguments include StartTime and EndTime which define a time span, RecordIdx which is the number used to identify one historic value, and Forward which is used to instruct the program to move through a series of historic values. Forward arguments can have values of True or False (True means proceed forward to the next historic record; False means proceed backwards to the previous historic record).

You will need to use the following information when using a historic function:
Function | Arguments | Returns
RawCount | StartTime, EndTime | The number of values between the StartTime and EndTime
RawValue | StartTime, EndTime, RecordIdx, Forward | Value between StartTime and EndTime at RecordIdx
RawTimeStamp | StartTime, EndTime, RecordIdx, Forward | Time value between StartTime and EndTime at RecordIdx
RawQuality | StartTime, EndTime, RecordIdx, Forward | Quality value between StartTime and EndTime at RecordIdx
RawQualityDesc | StartTime, EndTime, RecordIdx, Forward | Quality description between StartTime and EndTime at RecordIdx
RawCountRange | StartTime, Interval | The number of values between StartTime and StartTime+Interval at RecordIdx
RawValueRange | StartTime, Interval, RecordIdx, Forward | Value between StartTime and StartTime+Interval at RecordIdx
RawTimestampRange | StartTime, Interval, RecordIdx, Forward | Value between StartTime and StartTime+Interval at RecordIdx
RawQualityRange | StartTime, Interval, RecordIdx, Forward | Value between StartTime and StartTime+Interval at RecordIdx
RawQualityDescRange | StartTime, Interval, RecordIdx, Forward | Value between StartTime and StartTime+Interval at RecordIdx
ProcessedValue | StartTime, EndTime, AggregateId | Historic value between StartTime and EndTime using AggreagteId.

For a list of the historic algorithms that are available, see OPC Historic Aggregates (Algorithms) in the ClearSCADA Guide to Expressions.

Further Information

Raw Historic Values in ST Programs.

Add Raw Historic Values to Function Block Diagrams.


Logic Guide - Built-In Data Types (ST Programs)

Built-In Data Types

There are many different types of built-in value (literal value) that you can add to your Logic programs, including:

  • Integer Values
  • Floating Point Values
  • Binary Values
  • Time and Date Values
  • String Values.

The built-in value types, sometimes referred to as literal data types, use a specific name to define the data type. For example, text values are STRING values. You can use Derived Data Types to allocate different names to value types.


Logic Guide - Integer Values (ST Programs)

Integer Values

Integer values are whole numbers. Typically, they are used to represent amounts such as counts. In this section, we explain:

  • Integer Types—A brief description of the various types of integer you can use.
  • Integer Formats—Explains how to define the base for an integer value.
  • Typed Literals—Describes how to assign appropriate types of integer for the literal numbers in a program.

Integer Types

Integer types are often used when defining the variables in an ST program. They allow you to specify the range of permittable values for a variable.

There are two varieties of integer type—signed and unsigned. Signed integers allow positive and negative numbers to be used, whereas unsigned integers only allow positive numbers. Each variety of signed and unsigned integer is suited to representing a specific range of values and bits (see table below).
Integer Type | Bits | Range
SINT (Short Integer) | 8 | -128 to +127
INT (Integer) | 16 | -32768 to 32767
DINT (Double Integer) | 32 | -231 to +231 -1
USINT (Unsigned Short Integer) | 8 | 0 to 255
UINT (Unsigned Integer) | 16 | 0 to 216-1
UDINT (Unsigned Double Integer) | 32 | 0 to 232-1

When you add integers to your Logic programs, you need to use a suitable type of integer. You should consider the possible range of counts, then use the table above to determine which type of integer is appropriate for covering the expected range.

When using literal values in a program, you need to pay special attention to the integer type you use, as literal values use the smallest type of integer possible. For example, if you use the literal value 2, it will be a SINT by default. As the result of a calculation is the same type as the largest operand in the calculation, this can cause confusion due to the result type not supporting the range needed for the result of the calculation. For example, for 2**7 (which is 27), you may expect 128 as a result, but the result is -1. This is because the smallest type of integer for 2 is a SINT and the smallest type of integer for 7 is also SINT. As the type of value for the highest operand (7) is SINT, the result of the calculation is also SINT. But as SINT can only support the range -128 to +127, it cannot store the result of 128. Instead, it returns -1.

For this reason, you need to be careful when defining literal values and you should consider the required integer type for the result. There are two possible ways of working around these situations:

  • You can use internal variables for the values (see Adding an Internal Variable to an ST Program)
  • You can cast one of the operands, for example, SINT_TO_DINT(2) **7.

Further Information

Integer Formats

Typed Literals.

Integer Formats

When you are specifying an integer value, either as a constant or as part of a variables definition, you need to specify the base. The base defines the type of value for the integer, and can be:

  • Decimal—Decimal values can use negative and positive signs, no signs, or underscores to represent commas. For example:

-2100, 2100, +2100, 2_100.

  • Binary—Binary values are base 2 values. You need to use 2# to indicate that the values are base 2, and you need a value for each bit. For example:

2#1111_1111 is 255 (8 bits)

2#0000_1110 is 14 (8 bits)

  • Octal—Octal values are base 8 values. You need to use 8# to indicate that the values are base 8, for example:

8#377 is 255

8#030 is 24.

  • Hexadecimal—Hexadecimal values are base 16 values. You need to use 16# to indicate that the values are base 16, for example:

16#FF is 255

16#B8 is 184

Further Information

Integer Types

Typed Literals

Typed Literals

When you use constant literal numbers in an ST program, they are automatically assigned a type. The type that is assigned is the integer type that has the lowest range that can support the literal number. For example, if you enter 200 as a constant literal, the 200 will automatically be assigned a USINT integer type (SINT integers only support -128 to 127, so cannot be used. USINT is the next lowest integer type and as it supports 0 to 255, it can be used).

The result of a calculation that uses constant literals is also assigned a type automatically. The integer type that is assigned to the result matches the integer type with the highest range in the expression. So, if the expression is 150+400, the result is assigned the INT integer type (the 150 is assigned USINT and the 400 is assigned INT).

The automatic assigning of integer types can cause unexpected results, as the result of an expression may be a number that exceeds the range of the integer type for the result. This causes an overflow. For example, with the following program, you would expect the value of A to be 300 (the result of 100 x 3):

VAR
A : INT;
END_VAR
A := 100 * 3;

However, in this case, the value of A is 44, even though the integer type for A has been defined as INT, which supports 300. The reason for this is that in the expression 100*3, SINT is used for both 100 and 3 (as SINT supports the range -128 to 127). This means that the result of the expression is also SINT as it matches the integer type of the highest number in the expression. As the expected result of the expression is 300, this means there is an overflow - the result value exceeds the range supported by the result integer type. And so 100*300 results in 44. The 44 for the SINT result is then converted into an INT as declared for A at the start of the program.

ClearSCADA allows you to use typed literals to avoid this situation. By using typed literals, you can declare a specific integer type for each constant literal in your program. When there is a declared integer type for a constant literal, the program uses the declared integer type; the smallest integer type is not assigned automatically.

To declare a specific integer type for a constant literal, you need to use the following syntax:

<Integer Type>#<Constant Literal>

Where:

  • <Integer Type> is the integer type that will be assigned to the constant literal. Do not enter the angle brackets < >.
  • <Constant Literal> is the number to be used in the expression. Do not enter the angle brackets < >.

So, if we take the example that we used before, 100*3, the program could be defined like this:

VAR
A : UINT;
END_VAR

A := INT#100 * 3;

As you can see, the 100 is declared as an INT whereas the 3 is assigned a SINT automatically (the lowest integer type that supports 3). The code would also produce the expected result if the 100 was SINT and the 3 was INT or if both 100 and 3 were INT. This is because one of the constant literals has to be of an integer type that is also large enough to support the expected result.

So, as the expression has an INT and a SINT for its constant literals, the result is assigned an INT (the highest integer type used by the constant literals in the expression). The expected result of the expression - 300 - is supported by integer type of the result (INT, which supports -32, 768 to +32, 767). This means that the result of the expression does not overflow and is the expected 300.

The result of 300 is then converted from INT to UINT as A was declared as a UINT at the start of the program. As UINT supports the range 0 to 65,535, the 300 value is stored by the A variable. However, had the integer type of A been declared as an integer type that does not support the result of 300, the value for A would be truncated. To obtain the expected result, you need to use appropriate integer types for:

  • The result of the expression in the program. Remember that it is assigned the same type of integer as the highest integer type used by the constant literals in the expression.
  • The variable that is used to store the result of the expression. The variable has to be assigned an integer type that supports the expected result of the expression, otherwise the expression may produce the correct result but the result will be stored as a truncated value.

Further Information

Integer Types

Integer Formats.


Logic Guide - Floating Point Values (ST Programs)

Floating Point Values

Floating point values are analog values (also referred to as REAL values). They are used for values that can be any number within a range, for example, temperature values.

There are 2 types of floating point value (REAL and LREAL). For more information, see Floating Point Types.

For information on the formatting rules that apply to floating point values, see Floating Point Formats.

Floating Point Types

You may use floating point types when defining the variables in an ST program. The floating point types specify the range of values that is permitted for a variable.

There are two types of floating point:
Floating Point Type | Bits | Range
REAL (Real numbers) | 32 | ±10±38
LREAL (Long real numbers) | 64 | ±10±308

NOTE: REAL values have a precision of 1 in 223. LREAL values have a precision of 1 in 252.

When you add floating point values to your Logic programs, you need to use a suitable type of floating point value. You should consider the possible range of numbers, then use the table above to determine which type of floating point value can cover the expected range.

Floating Point Formats

When you are specifying a floating point value, enter a normal decimal. This applies whether you are using a floating point value as a constant or as part of a variables definition. For large and small values, you can use E or e to denote the exponential value of ten, for example, 0.9E20 or 0.3765e+14.


Logic Guide - Time and Date Values (ST Programs)

Time and Date Values

There are several types of time and date value that you can use in your Logic programs.

You can use the time and date values to specify:

  • Time durations
  • Calendar dates and specific times

When you enter a time or date value, you need to specify the type of value (see Time and Date Types) and the amount for the value (see Time and Date Formats).

Time and Date Types

There are 4 types of time and date value:
Time and Date Type | Bits | Purpose
TIME | Varies | Use to store an amount of time that begins after an event takes place. For example, use TIME to store a timeout that occurs when plant is in a specific state. The time is stored as days, hours, minutes, seconds, and milliseconds.
DATE | Varies | Use to store a calendar date.
TIME_OF_DAY (or TOD). | Varies | Use to store a time (real time clock). TIME_OF_DAY is also be referred to as TOD.
DATE_AND_TIME (or DT) | Varies | Use to store the date and time of day (real time clock)

When you define a time and date value, you need to use a specific format (see Time and Date Formats).

Time and Date Formats

Each type of data and time value needs to be entered in a specific format. There are special codes that allow the program to recognize the type of time or date value being used, and there are conventions for entering the times and dates.

The format conventions are:

  • TIME—There are two formats for TIME values: short and long. The short format uses T# to represent TIME, whereas the long format uses TIME#. Usually, the short format is used, but you may wish to use the long format for its improved readability.

Both formats use these characters:

  • d—day
  • h—hours
  • m—minutes
  • s—seconds
  • ms—milliseconds

For example, T#12d3h2s is 12 days, 3 hours, and 2 seconds in the short format. In the long format, the same amount of time is TIME#12d_3h_2s.

  • DATE—As with TIME values, there are short and long formats for DATE values. The short format uses D# to represent DATE, whereas the long format uses DATE#.
  • TIME_OF_DAY—As with other types of time and date values, TIME_OF_DAY values can use short and long formats. The short format uses TOD# to represent TIME_OF_DAY whereas the long format uses TIME_OF_DAY#.
  • DATE_AND_TIME—As with other types of time and date values, DATE_AND_TIME values can use short and long formats. The short format uses DT# to represent DATE_AND_TIME whereas the long format uses DATE_AND_TIME#.


Logic Guide - Binary Values (ST Programs)

Binary Values

Digital values (binary values) are stored in bit strings. There are 5 types of bit string.

When you need to use a binary value in your Logic program, you have to define the type of binary value and the actual value. For more information, see Binary Value Types and see Binary Value Formats.

Binary Value Types

There are several types of binary value:
Binary Type | Description | Bits | Range
BOOL | Boolean value | 1 | 0 OR 1, True or False
BYTE | String of 8 bits | 8 | 0 to 255
WORD | String of 16 bits | 16 | 0 to 65536
DWORD | String of 32 bits | 32 | 0 to 232

NOTE: For Boolean values, 0 is False and 1 is True.

You need to define the type of the value when you define a binary value in the program.

Binary Value Formats

When you define a binary value, you need to enter a valid value. This can be 0, 1, TRUE, or FALSE.

There are no formatting requirements for binary values. To define the value of a binary value type, you have to set its value to one of the following:

  • 0
  • 1
  • TRUE
  • FALSE


Logic Guide - String Values (ST Programs)

String Values

If you need to use a text value in your program, you need to define the value as a STRING.

STRING values are used to store text. For example, STRING values are often used to store messages such as descriptions, batch information, and messages that are used with string points in the ClearSCADA database.

STRING values can contain printable and non-printable characters, and have to be enclosed within single quotes like this: 'example'.

Strings allow a maximum of 255 characters unless you specify a different fixed length in the VAR list.

Example:

VAR
WarningMessage: STRING [60]:= 'Attention. The state has changed';
END_VAR

In this example, WarningMessage is the name of the STRING value. STRING [60] instructs the program that the value is a string value and has a maximum of 60 characters. 'Attention. The state has changed' is the value of the string—the text that is stored.

There are special characters that are reserved. These characters allow you to insert a non-printable character, a dollar sign, quotation marks, etc. The special characters are:
Character Code | Description
$<hexadecimal number> | The character that is represented by the hexadecimal number, for example, '$32' is 2.
$$ | A single dollar sign $
$' | A single quote character '
$L or $l | A line feed character
$N or $n | New line character
$P or $p | Form feed, new page
$R or $r | Carriage return character
$T or $t | Tab character


Logic Guide - Derived Data Types (ST Programs)

Derived Data Types

ClearSCADA supports derived data types for use in ST programs (and Function Block Diagrams that include ST programs). The derived data types are designed to make it easier for you to read and write structured text programs—they allow you to name and group values that are used by your ST programs.

This section explains:

  • Using Derived Data Types to Create Names for Types of Value.
  • Using Structured Data Types to Group Internal Values.
  • Using Enumerated Data Types to Create Names for State Values.
  • Arrays
  • Vectors.


Logic Guide - Using Derived Data Types to Create Names for Types of Value (ST Programs)

Using Derived Data Types to Create Names for Types of Value

You can create derived data types so that types of values in your programs have meaningful names.

For example, the value from a pressure gauge is a REAL value. By creating a new data type for this value, you can allocate it a more meaningful name such as PRESSURE.

Example:

TYPE
PRESSURE: REAL;
END_TYPE

As you can see, new data types need to be included in a TYPE definition. The TYPE definition has to come before the PROGRAM definition.

In the example, only one new data type has been created, so there is only one entry within the TYPE definition. However, if you needed to add more new data types, you would add them to the existing TYPE definition—you do not need a TYPE definition for each separate data type.

When you define a new data type, you need to use this format:

<name of new data type>: <type of value for the data type>;

So, in the example above, the <name of new data type> is PRESSURE and the <type of value for the data type> is REAL.

When you have created a new data type, you can use it in your Logic program. To do this, you need to add it to the list of variables (VAR).


Logic Guide - Using Structured Data Types to Group Internal Values (ST Programs)

Using Structured Data Types to Group Internal Values

Structured Data Types allow you to group internal values (values that are used by the program but are not written to an item in the database). This means that when you create a data structure, you create a custom data type that contains several internal values. You can then refer to these values in your Logic program by referencing the data structure.

NOTE: You cannot use structured data types for direct variables (values that need to be written to items in the ClearSCADA database).

The main advantages of structured data types is that they allow you to group internal values and they reduce the number of variables you need to define.

When you create a data structure, you need to define the values that are to be grouped within STRUCT and END_STRUCT keywords. The STRUCT and END_STRUCT keywords have to be defined within the TYPE and END_TYPE definition.

You should list the values that you want to be grouped in the data structure within the STRUCT and END_STRUCT keywords. As with other value definitions, you need to enter the name of the value, then a colon (:), then define the type of value. Each value has to be separated by a semi-colon (;).

TYPE <data structure name>
STRUCT
<value name>:<value type>;
<value name>:<value type>;
<value name>:<value type>;
END_STRUCT;
END_TYPE

When you have defined the data structures, you need to add them to the VAR variables list. To do this, simply create a variable name for the value and then use the name of the data structure when you define the type of value. You need to define each data structure as a variable (unless 'nested' data structures are used—we will explain these later in this section):

VAR
<Variable name>:<data structure name>;
<Variable name>:<data structure name>;
<Variable name>:<data structure name>;
END_VAR

When you have defined the VAR variables list, you can refer to the values included in the data structures. To do this, use the following format when referencing a value in your Logic program:

<Variable name>.<value name>

As with many of the Logic structures, it is easier to understand the concepts and the formatting by referring to an example. The example in this section uses data structures to group the values that can be used for pumps in the water industry. It shows:

  • How data structures can be used to group values
  • How data structures need to be defined
  • How data structures need to be added as variables in the VAR list

Example of Data Structures

Let us assume that you want to create a Logic program that needs to use internal values for a pump. It needs to use the pump status, alarm count, and latest value. You can group these values in a data structure:

TYPE PUMP:
STRUCT
Status: BOOL;
AlarmCount: INT;
LatestUpdate: DATE_AND_TIME;
END_STRUCT;
END_TYPE

The name of the data structure is defined as PUMP. For each internal variable, the name of the value is defined and so is its data type (BOOL, INT, DATE_AND_TIME). The data structure is defined within STRUCT and END_STRUCT keywords which are enclosed within the TYPE and END_TYPE keywords.

The data structure feature becomes more useful when the data structure needs to be used to represent the internal values for multiple items. So, rather than using the PUMP data structure for 1 pump, let's look at how it can be used for 3 pumps:

TYPE
STRUCT PUMP:
Status: BOOL;
AlarmCount: INT;
LatestUpdate: DATE_AND_TIME;
END_STRUCT;
END_TYPE

The 3 pumps can refer to the PUMP data structure. By grouping the data for each pump into a data structure, it is easier to recognize the source of each value. It is also easier to use the values in the program.

Once the data structure has been defined, it needs to be added as a variable in the VAR list. As with other types of variable, each data structure requires a variable name. As the PUMP data structure needs to be used to provide the values for 3 separate items, there has to be 3 variables with PUMP as their data type:

VAR
Pump1Data :PUMP;
Pump2Data: PUMP;
Pump3Data: PUMP;
END_VAR

Pump1Data is the name allocated to the PUMP data structure for Pump 1. The other variables have similar names, for example, Pump3Data uses PUMP to access data for Pump 3. The data types for the data structure variables have to match the data structure name.

In the Logic program, any references to the values in the data structures use the following format:

<Variable name>.<value name>

This means that a reference to the AlarmCount value of Pump 3 would be entered as:

Pump3Data.AlarmCount

A reference to the LatestUpdate value of Pump 1 would be entered as:

Pump1Data.LatestUpdate


Logic Guide - Using Enumerated Data Types to Create Names for State Values (ST Programs)

Using Enumerated Data Types to Create Names for State Values

You can use the enumerated data types facility to apply names to state values. This can be useful as it allows state values to have names that are more descriptive of the value. For example, you can use an enumerated data type to define the state values of a valve as Open and Closed rather than 0 and 1.

Enumerated data types make it easier to understand a program. The more descriptive state values mean it is easy to work out what states the program uses. It also means you can obtain the correct state numbers without referring to the ClearSCADA Database Schema, as you can use any state name to reference a state number. For more information on the ClearSCADA Database Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.

Another advantage of enumerated data types is that they reduce the amount of alterations you need to make if you decide to change the states. For example, a valve could have Open to represent state 0 and Closed to represent state 1. If you changed the states so that state 0 meant the valve was closed and state 1 meant the vale was open, you would only need to change the enumerated data types in TYPE sections of your Logic programs. If you did not use enumerated data types, you would need to change the states of every instance of the valve's values.

Enumerated data types have to be defined within the TYPE and END_TYPE keywords. The format for an enumerated data type is:

<Enumerated data type name>:(<state name>, <state name>);

For example:

PUMP_STATES:(STOPPED, RUNNING, FAILED, INVALID);

The STOPPED state name corresponds to State 0, RUNNING corresponds to State 1, FAILED corresponds to State 2, and INVALID corresponds to State 3. As you have used state names to reference the various states, you cannot reference the states by number. For example, you cannot reference the RUNNING state as 1.

The number of <state name> entries varies according to the number of states for the item. In each case, the first state name corresponds to State 0, the second state name corresponds to State 1, the third state name corresponds to State 2 and so on.

You can use any names for the states; there is no need to match the state names to the names used in the ClearSCADA Database Schema. However, if you are defining multiple enumerated data types, you need to use different names (an enumeration cannot contain the same name as another enumeration).

Example:

There are enumerations for a valve and a pump. The valve has 4 states that are defined in an enumeration (OPEN, CLOSED, FAILED, and INVALID).

The pump also has 4 states (STOPPED, RUNNING, FAILED, and INVALID). In the pump enumeration, the STOPPED and RUNNING states are acceptable, but the FAILED and INVALID state names cannot be used as the same names are used for the valve enumeration.

To avoid this situation, we suggest that you use item specific state names. So, for the valve and the pump, you would use enumeration states such as these:

Valve (VALVE_OPEN, VALVE_CLOSED, VALVE_FAILED, VALVE_INVALID);
Pump (PUMP_STOPPED, PUMP_RUNNING, PUMP_FAILED, PUMP_INVALID);

You can use the same enumeration state names for items of the same type. So if there were two different pumps, you could use PUMP_STOPPED, PUMP_RUNNING, PUMP_FAILED, and PUMP_INVALID as long as both pumps have the same states.


Logic Guide - Using Nested Data Structures (ST Programs)

Using Nested Data Structures

You can 'nest' data structures within other data structures. This is useful for creating a sub-group of values. For example, if a Logic program needs to use the values of 3 different pumps, it may have a data structure for a pump. The PUMP data structure contains definitions for CurrentState: REAL; and UpdateTime: TIME; variables. The variables for each of the pumps will be set to use the PUMP data structure.

The Logic program also needs to use the name of the engineer that last calibrated each pump, and the time at which the calibration took place. To achieve this, another data structure is created:

STRUCT Calibration_Struct
CalibDate: DATE_AND_TIME;
Engineer: STRING;
END_STRUCT;

The Calibration_Struct data structure is included within the TYPE and END_TYPE definition, and is positioned above the PUMP data structure. (Data structures that are to be nested within other data structures have to be entered above the non-nested data structures).

The PUMP data structure is then altered to include the Calibration_Struct data structure:

STRUCT PUMP
Calibration: Calibration_Struct;
CurrentState: REAL;
UpdateTime: TIME;
END_STRUCT;

So, in the PUMP data structure (shown above), the Calibration : Calibration_Struct; line embeds the Calibration_Struct data structure within the PUMP data structure.

The VAR variables list then needs to include the PUMP data structure. The Calibration_Struct data structure is not needed as a variable as it is included in the PUMP data structures:

VAR
Pump1Data: PUMP;
Pump2Data: PUMP;
Pump3Data: PUMP;
END_VAR

In the Logic program, references to the values of the pumps will use the following format:

<Name of variable>.<name of field>

For example, Pump1Data.CurrentState is a reference to the current state value of Pump 1.

To reference the calibration values, use the following format:

<Name of variable>.<name of nested data structure>.<name of field>

For example, Pump1Data.Calibration_Struct.Engineer is a reference to the name of the engineer that calibrated Pump 1.


Logic Guide - Arrays (ST Programs)

Arrays

You can use arrays to form a matrix of values. The matrix can be multidimensional and can contain Data Structures, Enumerated Data Types, New Data Types, values from other Arrays and any of the built-in value types such as INT, REAL, and STRING.

NOTE: Arrays can only be used with internal variables. For direct variables, you have to use the VECTOR keyword, see Vectors.

To create an array, define the Array within the VAR and END_VAR keywords using the following format:

<Array Name> : ARRAY [<x dimensions>, <y dimensions>] OF <Value Type or Value Name>;

For example:

VAR
TEMPERATURE_MATRIX:ARRAY[1..4,1..5] OF REAL;
END_VAR

In this example, the name of the array is TEMPERATURE_MATRIX. [1..4,1..5] defines the columns and rows of the matrix (1x4 columns, 1x5 rows) and OF REAL; defines the type of values that are to be entered in the matrix.

When it comes to defining values for each of the matrix cells, you need to define the value in the following format:

<Value name>[<matrix grid reference>]:=<value>;

For example:

EngineTemperature[2,5]:=42.5;

This would place the value 42.5 in the second column in cell 5, like this:

42.5

In ViewX, you can use the Debug tool to view the values for each cell (see Debugging an ST Program or ST Library).

Further Information

Vectors.


Logic Guide - Vectors (ST Programs)

Vectors

A vector is a special type of STRUCT that has an array as its value. It allows you to read values from and write values to an array in the database. It also allows you to define the source of array values for use by methods that require array values, such as the Set Forecast method. To use a vector in an ST program, you need to use the VECTOR keyword.

Vectors are similar to arrays, except that they have three properties:

  • Capacity—The maximum number of values that can be read/written by the vector
  • Length—The actual number of values that are read/written by the vector. This can be defined in the declaration or will be calculated automatically.
  • Value—The array of the vector. The vector's array will use values that are read from an array in the database, such as an array variable database item.

The syntax for a vector is:

VECTOR[value range] OF <Value Type>;

Where:

  • VECTOR is the keyword
  • [value range] is the maximum number of values that can be read or written. For the value range, you have to start with 0 (the first value) and end with the number of the last permitted value. Use two points between the first and last values, for example, [0..99] sets the value range to 100 values (0 being the first value, 99 the hundredth value).
  • OF <Value Type> defines the value type of the direct variable that is read or is being written to. For example, OF UDINT; or OF DINT;

For example:

VAR
V AT %M(.Values) : VECTOR[0..99] OF DINT;
END_VAR

Sets the V variable to represent the vector. The source of the vector's array is defined as the database item named 'Values', and the capacity of the vector is defined as [0..99]. The value type of the vector's array is set to DINT. This means that the Capacity property of the vector is set to 100 (0 to 99 inclusive) and the Value property is set to reference the array of the 'Values' database item. The Length is not defined, but will be calculated automatically - it will match the number of values that are actually read from the 'Values' item's array. So, if there are 10 values in the array, the Length will be set to 10.

You can also write to the properties of a vector in the same way as you would write to the properties of any item, for example, you can set the Length of a vector by using <variable>.length := <length value>. Where <variable> is the name of the variable that represents the vector and <length value> is the number value for the length or is a calculation to determine the length.

VAR
V AT %M(.Values) : VECTOR[0..99] OF DINT;
V.Length := 6;

END_VAR

In the example above, the Length of the vector is set to 6 so that only 6 values are read from or written to the array.

NOTE: The Capacity property of a vector is read-only.

Examples:

Example 1 - Using a Vector to Read from an Array

The following example shows how the VECTOR keyword can be used in an ST program that reads from an array and uses the array values to calculate an average value.

In this program, the variable named Values can read to and write from the direct variable named Values (which is a variable array database item). As the direct variable is an array, a vector is used to read and write the values. The VECTOR keyword is used and has a value range of one hundred values (0..99).The value range is the capacity of the vector. The value type of the array is DINT.

The Average variable is a read and write direct variable associated with the Average database item (which is a variable double database item). The data type for the average variable is LREAL.

An internal variable, SUM, is used to store the result of the average calculation in the program. The SUM variable is of the data type DINT.

The code for calculating the average value and writing it to the Average variable double database item is:

Sum := 0;
FOR I := 0 TO Values.Length -1 DO
Sum := Sum+Values.Value[I];
END_FOR;
Average := DINT_TO_LREAL (Sum) /DINT_TO_LREAL (Values.Length);

So the program starts by initializing the Sum value to 0. The internal variable I is used to represent the index numbers of the elements in the array (each array element can contain a value, for example, the first element in an array has an index number of 0 and can contain one value; the second element has an index number of 1 and can contain one value and so on). The total number of array elements is defined by the Length value of the Values variable (the Values variable is a direct variable that represents the Values array database item). So, for the array elements with index numbers between 0 and the Length amount minus 1, the ST program will perform the calculation:

Sum := Sum+Values.Value[I];

When the ST program has read the values from the Values array, it calculates the average which is the Sum value divided by the Length value of the vector. The result of this calculation is stored in the Average variable database item.

Let's assume that the Values array database item has 5 values (stored in its 5 elements). When the ST program runs, it first initializes the Sum value at 0 and then begins to read the values in the array. It begins by reading the value from the array element with index number 0. This value is stored in the internal variable, Sum. The ST program then reads the value from the array element with index number 1 and adds the value to the Sum value. This is repeated until the ST program has read the values from the array elements with index numbers 0, 1, 2, 3, and 4. Although the ST program can read up to 100 elements ([0..99]), it can read fewer elements as required; it does not have to read 100 elements.

When the ST program has read the five array elements in the Values array database item, it calculates the average value. To do this, it divides the Sum amount by the Length value of the Vector. The result of this calculation is written to the Average variable database item.

Example 2 - Using a Vector to Write to an Array

In this example, the VECTOR keyword is used to allow an ST program to calculate new values and write them to an array database item.

In the VAR list, a single variable is defined. The variable is named Fib and it is a direct variable to the database item named Fibonacci Sequence (which is a variable array database item). The variable is defined as a VECTOR with a capacity of 100 values ([0 to 99]) and is of the data type UDINT.

The first part of the IF statement declares that if the length of the vector is 0, then the value in the array element with index number 0 is set to 0, and the length of the vector is changed to 1.

The second part of the IF statement declares that if the length of the vector is 1, then the value in the array element with index number 1 is set to 1, and the length of the vector is changed to 2.

The final part of the IF statement only applies if the length of the vector is between 2 and 99. If the length is between 2 and 99, the value for that element is the value of the previous element plus the value of the element before that, and the vector length is increased by 1.

So, if the Fibonacci Sequence array item contains no values, when the ST program first runs it will set the number of values the array can contain to 1 and will set the value for the only element in the array to 0.

The next time the ST program is executed, it will detect that the Fibonacci Sequence array item contains a single value and so the vector has a length of 1. This means that the ST program will increase the number of array elements to 2. The element with index number 0 will contain the 0 that was already in the array and the element with index number 1 will contain a new value defined by the ST program, in this case, 1.

The next time the ST program is executed, it will detect that the Fibonacci Sequence array item contains two values and that the vector has a length of 2. The ST program will increase the length of the vector by one to accommodate a new value and will then calculate the new value. The new value is the total of the previous two values stored in the array. In this case, the previous two values are 0 and 1 and so the new value is 1. The new value is stored in the element with index number 2.

The next time the ST program is executed, it will detect that the Fibonacci Sequence array item contains three values and that the vector has a length of 3. The ST program will increase the length of the vector by one to accommodate a new value and will then calculate the new value. The new value is the total of the previous two values stored in the array. In this case, the previous two values are 1 and 1 and so the new value is 2. The new value is stored in the element with index number 3.

Each time the ST program is executed, it will increase the length of the vector by 1 and calculate a new value. When the length of the vector is 99 (and so there are 100 values in the array), the ST program will no longer create new values or increase the length of the vector.

Example 3 - Using Vectors with Methods that Require Values in an Array

In this example, a vector is used to read the values from an array variable database item. The values that are read are used as the values for the SetForecast method on a Forecast database item.

The V variable is defined as a direct variable that references a Long Array variable database item named 'Values'. As the variable is a direct variable, the Vector keyword is used (the Vector keyword has to be used for reading from an array in the database). The range of the Vector is defined as 0-99, as this is the capacity of the vector and the data type is defined as DINT.

The ST program calls two methods—the Set Forecast method on a Forecast database item named 'Forecast (Array)' and the Set Forecast method on a Forecast database item named 'Forecast (Vector)'. Each method requires three types of value: a string, a date-time, and an array.

For the 'Forecast (Array)' item's Set Forecast method (defined as SFA in the program), the program declares that the array value is an ARRAY OF DINT. This means that the Set Forecast method will use the values in the specified array (in this case, the values in the array for the vector, as defined later in the program by the V.Value entry). As the range of the vector is defined as 0..99, it means the SFA method will use 100 values.

For the 'Forecast (Vector)' item's Set Forecast method (defined as SFV in the program), the program declares that the array value is a VECTOR OF DINT. This means that the Set Forecast method will only use the amount of array values specified by the vector's Length property. So, if the vector's length is 10, the Set Forecast will only use the first ten values from the vector's array (the source of the vector's array is an array in the database, such as an array variable database item).

The SFA and SFV parts of the ST Program define the values for the methods.

For the SFA method (the Set Forecast method for the 'Forecast (Array)' database item), the string value is 'Test', the date-time value is NOW(), and the source of the array is V.Value. This means that the array values that are to be used for the method are those defined as the Value property of the V variable (which, in this program, is the vector). The value property of the V variable is the array referenced by the vector - the 'Values' array database item.

For the SFV method (the Set Forecast method for the 'Forecast (Vector)' database item), the string value is 'Test', the date-time value is NOW(), and the source of the array is V. This means that the vector is used as the source of the array values (v is the variable that represents the vector in the program). The length property of the vector determines how many array values are used and the value property of the vector is the source of the array values. So if the Length of the vector is 10, the SFV method will only use the first ten values in the'Values' array item (the 'Values' array item is the source of the vector's array).


Logic Guide - Setting the Default Values (ST Programs)

Setting the Default Values

You can assign default values to any of the variables and derived data types. This is useful for programs that need to be set to a specific value prior to them being executed.

You can define default values in a VAR block (in which case, they cannot be overridden) or in a TYPE block (in which case they can be overridden by values in the VAR block).

The following sections describe the formats for entering default values:

  • Default Values for Built-in Data Types (Literals)
  • Default Values for Derived Data Types
  • Default Values for Enumerated Data Types
  • Default Values for Structured Data Types.


Logic Guide - Default Values for Built-in Data Types (Literals) (ST Programs)

Default Values for Built-in Data Types (Literals)

The format for entering default values for integer, real, bit, string, time, and date and time variables is:

VAR
<Value name> : <data type> := <default value>;
END_VAR

The following example shows how default values can be set for a variety of built-in data types:

VAR
a: INT:= 535;
d: DATE:= D#2004-06-21;
t: TIME_OF_DAY:= TOD#12:30:07;
n: TIME:= T#1h30m;
p: ARRAY[1..4] OF INT:= [10,90,12,14];
q: ARRAY[1..100] OF REAL:= [100(20.5)];
END_VAR;

NOTE: The default value for the q variable sets 100 array values to have a default value of 20.5.


Logic Guide - Default Values for Derived Data Types (ST Programs)

Default Values for Derived Data Types

The format for entering default values for derived data types is:

TYPE
<Derived Data Type Name>:<Data Type>:=<Default Value>;
END_TYPE

For example:

TYPE
Temperature:REAL:=20.0;
END_TYPE


Logic Guide - Default Values for Enumerated Data Types (ST Programs)

Default Values for Enumerated Data Types

The format for defining a default value for an enumerated data type is:

TYPE
<Enumerated Data Type Name>: (<Data Type>, <Data Type>) :=<Default Value>;
END_TYPE

For example:

TYPE
ControlStatus: (Healthy, Overrange, Failed):=Failed;
END_TYPE

In the example, ControlStatus is the name of the enumerated data type. Healthy, Overrange, and Failed are the names that are applied to the state values as part of the enumerated data type definition. The default value of the enumerated data type is set to Failed.


Logic Guide - Default Values for Structured Data Types (ST Programs)

Default Values for Structured Data Types

The format for defining a default value for a structured data type is:

TYPE <Structured Data Type Name>:
STRUCT
<Value Name>:<Value Type>:=<Default Value>;
<Value Name>:<Value Type>:=<Default Value>;
<Value Name>:<Value Type>:=<Default Value>;
END_STRUCT;
END_TYPE
VAR
<Variable Name>:<Structured Data Type Name>;
END_VAR;

For example:

TYPE
TEMPERATURE:REAL;
END_TYPE
TYPE
TemperatureControl:
STRUCT
Current: TEMPERATURE;
SetPoint: TEMPERATURE:=30.1;
Update: DATE_AND_TIME:= DT#1970-01-01-00:00:00;
Status: ControlStatus;
Desc: STRING:= 'Current Temperature';
END_STRUCT;
END_TYPE
VAR
Temp1:TemperatureControl;
END_VAR;

In this example, the user defined data type is defined in the first TYPE section, the structured data type is defined in the second TYPE section, and the default values are defined in the STRUCT section. The default values are specified as part of the structured data type definition.

NOTE: If values were defined for Current, SetPoint, Update, Status, or Desc in the VAR list, the values in the VAR list would override the default values set in the data structure.


Logic Guide - Executing Methods on Database Items (ST Programs)

Executing Methods on Database Items

Many items in the ClearSCADA database can be manipulated by a method. For example, a database point can be manipulated by an Override method so that its value is set to a specific value that cannot be changed until the Override is released. Methods are sometimes referred to as 'actions'.

This section explains:

  • Viewing which Methods are Available
  • Entering Methods in your ST Program


Logic Guide - Viewing which Methods are Available (ST Programs)

Viewing which Methods are Available

Each database item has specific methods available for use. These vary according to the type of database item. There are also additional methods that may be available to an item—if the item has aggregates, there may be methods that are associated with the aggregate.

This means that when you want to use a method for a database item, you can use:

  • A method that is associated with the database item
  • A method that is associated with an aggregate that is used by the database item. For example, methods that relate to the historic features of a database item.

You should use the ClearSCADA Database Schema to find out about the methods that are available (see Working with the Database Schema in the ClearSCADA Guide to the Database).

NOTE: You can use the ClearSCADA Database Schema to view the available methods for the class of item to which you want to apply the method. When doing this, we recommend that you also look at the methods that are available to each of the item's parent classes and also the aggregates. The historic tables may also include any historic methods that are available.


Logic Guide - Entering Methods in your ST Program (ST Programs)

Entering Methods in your ST Program

When you know which method you want to use, you need to define it within a METHOD declaration. The METHOD declaration has to be entered below the PROGRAM keyword but above the actual program code in your ST program (we recommend that you enter it after the VAR list).

When you have declared the method, you can refer to it in your ST program. Referencing a method in a program is often described as 'calling' a method.

This section explains:

  • Declaring a Method in a METHOD Block
  • Declaring a Method in a DATABASE_OBJECT Structure
  • Calling a Method


Logic Guide - Declaring a Method in a METHOD Block (ST Programs)

Declaring a Method in a METHOD Block

The format you need to use to declare a method in a METHOD block varies slightly depending on whether the method is associated with a database item or an aggregate.

For information on the required format, refer to the relevant section:

  • Declaring a Method that is Associated with a Database Object Class
  • Declaring a Method that is Associated with an Aggregate.

Declaring a Method that is Associated with a Database Object Class

If your program uses a method that is associated with a class of database item (rather than associated with an argument), you need to define the method. To do this, you have to declare the method in the format described in this section.

If you are using a method that is associated with an argument, see Declaring a Method that is Associated with an Aggregate.

When you declare a method for a database item, you have to enclose the declaration in a METHOD keyword and END_METHOD keyword. This has to be entered above the PROGRAM. We recommend that you define the METHOD after the VAR list.

To declare a method, you need to use this format:

METHOD
<Method name> AT %M(<database item>.<method name>): <value type>;
END_METHOD

Where the first <Method name> is the name of the method in the program. The <database item> is the path and name of the database item upon which the method will be used, and the second <method name> is the name of the method as it appears in the database. The <value type> is the argument for the method. There may be no arguments, in which case there is no <value type> entry, a single argument as shown, or multiple arguments which are separated by commas (<value type>, <value type>, <value type>).

You may need to use the ClearSCADA Database Schema to locate the name of the method in the database (see Working with the Database Schema in the ClearSCADA Guide to the Database).

For example:

METHOD
OVR AT %M(AIs.AnalogInp.Override): LREAL;
END_METHOD

Where METHOD defines the start of the method declaration.

OVR is the name of the override value in the ST program (the name you will use to refer to the method later in the program).

AT %M instructs the program to use a method associated with the database item.

(AIs.AnalogInp.Override) defines the path of the database item upon which the method will be used. In this case, AnalogInp is the name of the database item and it is located in a group named AIs. The .Override is a reference to the name of the method that is to be performed. The name has to be identical to the name of the method as it appears in the ClearSCADA database schema.

LREAL; sets the value of the method to be a long real value, with the semi-colon indicating the end of the value. If the method does not set a value, the value type is not required—you would end the method definition by placing the semi-colon after the closing parenthesis. For example, the Enable Alarms method does not require a value, and so it would be defined as:

AccAlrm AT %M(AIs.AnalogInp.EnableAlarms);

END_METHOD defines the end of the method declaration.

Declaring a Method that is Associated with an Aggregate

When you declare a method for an aggregate, you need to use a slightly different format to that which is required for database item methods. The difference is that you have to include the aggregate name in the path of the database item.

So, the format for entering an aggregate method is:

METHOD
<Method name in program> AT %M(<path of database item>.<aggregate class>.<method name in database>): <value type>;
END_METHOD

For example:

METHOD
PromoteOS AT %M(PSTNOutstation.PSTN.PromoteDialOut): DINT, DINT, BOOL;
END_METHOD

Where METHOD defines the start of the method declaration.

PromoteOS is the name of the method in the ST program (the name you will use to refer to the method later in the program).

AT %M instructs the program to use a method associated with a database item (in this case, it will use an aggregate for the item).

(PSTNOutstation.PSTN.PromoteDialOut) defines the path of the database item upon which the method will be used. In this case, PSTNOutstation is the name of the database item. PSTN is the name of the aggregate class and PromoteDialOut is a reference to the name of the method that is to be performed. The name has to be identical to the name of the method as it appears in the ClearSCADA database schema.

DINT, DINT, BOOL; sets the value types that will be used by the method.

In this case, the method will use two DINT values and a BOOL value, for example, an interval, a duration, and an immediate start state. The method could then be used to promote the outstation at a set interval (defined by the first DINT value), for a set duration (defined by the second DINT value), and could start immediately or be delayed depending on the state of the BOOL value.

END_METHOD defines the end of the declaration.

For example, in the program the method could be used like this:

IF Input.CurrentValueFormatted <50 THEN
Override (80.5);
AccAlarm();
END_IF;
PromoteOS (900, 3600, TRUE);

This code works by setting the program to override the input current value to 80.5 if the current value is reported as less than 50. If the override has to be used, an alarm is raised (AccAlarm) and the outstation is promoted every 15 minutes (900 seconds) for a total of 1 hour (3600 seconds) and starts immediately (TRUE).


Logic Guide - Declaring a Method in a DATABASE_OBJECT Structure (ST Programs)

Declaring a Method in a DATABASE_OBJECT Structure

You can also declare methods in a DATABASE_OBJECT structure. This allows you to group methods with database fields.

As with defining variables in a DATABASE_OBJECT structure, the main advantages of declaring methods in a DATABASE_OBJECT structure are:

  • It reduces the amount of time need to write the program as you can reference the DATABASE_OBJECT structure rather than the same methods for different database items.
  • The methods declared in the DATABASE_OBJECT structure can be used with any items of the same class.
  • It makes the program easier to write, read, and understand.

If you declare methods in a DATABASE_OBJECT that is used with an SQL query, you can use the SQL to return methods in the RESULTSET instead of values. For example, you can override any points that have CurrentQuality Desc values of 'Bad'.

NOTE: Aggregate methods cannot be declared in a DATABASE_OBJECT structure.

To declare methods in a DATABASE_OBJECT structure, you need to use the following format:

TYPE
<database item name>: DATABASE_OBJECT (<class of database item>)
<Method name>: METHOD;
END_DATABASE_OBJECT;
END_TYPE

Where <database item name> is the name of the database item to which the methods apply.

DATABASE_OBJECT instructs the program that the methods are part of a database object structure.

(<class of database item>) is the class with which the method is associated. This may be the class for the database item or one of its parent classes. For example, it could be CSCADAPackMPoint for a SCADAPack Modbus point or CDBPoint for all types of point.

<Method name> is the name that you are going to use to identify the method in your program. For methods that are defined in DATABASE_OBJECT structures, you have to enter a name that matches the name of the method in the ClearSCADA database. For example, for an Acknowledge Alarm method, you have to define its name as Accept (as that is the name of the method in the ClearSCADA database).

METHOD instructs the program that the type of value in the DATABASE_OBJECT is a method. You need to repeat the <Method name>:METHOD; line for each separate method that is to be included.

END_DATABASE_OBJECT; ends the database object structure definition and END_TYPE ends the type declaration.

Example:

TYPE
AlarmConditions: (AlarmNormal, AlarmDisabled, AlarmAcceptedUncleared, AlarmUnacceptedCleared, AlarmUnacceptedUncleared);
END_TYPE
TYPE
AlarmDBOBJ: DATABASE_OBJECT (CDBPoint)
AlarmState:AlarmConditions;
Accept: METHOD;
END_DATABASE_OBJECT;
END_TYPE

In the program, the following ST is used to set the Input1 point so that its UnacknowledgedCleared alarms are acknowledged automatically:

VAR
Input1 AT %O(Input1) :AlarmDBObj;
END_VAR;
PROGRAM
IF(Input1.AlarmState = UnacknowledgedCleared) THEN
Input1.Accept();
END_IF;
END_PROGRAM

This program uses an enumerated data type (see Using Enumerated Data Types to Create Names for State Values). The enumerated data type defines a value named AlarmConditions that has 5 state values. The ClearSCADA Database Schema defines the states as:

  • State 0—Normal
  • State 1—Disabled
  • State 2—AcknowledgedUncleared
  • State 3—UnacknowledgedCleared
  • State 4—UnacknowledgedUncleared

The encapsulated data type is named and has its state values defined in the first TYPE declaration.

NOTE: You can use any names for the states in encapsulated data types (they do not have to match the names of states in the ClearSCADA Database Schema).

The second TYPE declaration is used to define the DATABASE_OBJECT structure for the methods. It is named AlarmDBOBJ, and it is set to be a DATABASE_OBJECT that uses the CDBPoint class. The following values and methods are included in the DATABASE_OBJECT:

AlarmState:AlarmConditions;
Accept: METHOD;

The AlarmState value returns a value for the AlarmConditions data type. This means it returns a value that corresponds to one of the AlarmConditions states.

The Accept value defines the method that is used in the program (the Acknowledge method). The name of the Accept value has to match the name of the method as it appears in the ClearSCADA database schema, so in this case it is Accept as the name of the Acknowledge Alarm method is Accept. The METHOD part of the value instructs the program that the value is a method.

In the program, the VAR list contains:

Input1 AT %O(Input1) :AlarmDBObj;

This defines a value (Input1) that is a database item (%O). The Input1 value is associated with the Input1 database item and its values are returned for the AlarmConditions database object structure. This means that the program will use the Input1 item's values that correspond to the values that are specified in the AlarmDBObj structure.

PROGRAM
IF(Input1.AlarmState = UnacknowledgedCleared) THEN Input1.Accept();
END_IF;
END_PROGRAM

This part of the program defines the Logic of the program i.e. the behavior that is defined by the program. The Logic references one of the values that is defined in the AlarmDBObj method (Accept). Referencing a method is referred to as calling a method (see Calling a Method). In this case, the Acknowledge method is applied to the Input1 item when its AlarmState value is Unacknowledged Cleared.


Logic Guide - Calling a Method (ST Programs)

Calling a Method

When you have defined the method declaration, you can reference the methods in your program. Referencing is also referred to as 'calling'.

To reference a method, use the following format within the ST program:

<Method name in program> (<method value>);

Where <Method name in program> is the name of the method that you defined in the METHOD declaration. This is not the name of the method as it appears in the ClearSCADA database schema—it is the name you allocated to the method.

<method value> is the value that you want the method to invoke. If there are multiple values, you need to separate each value with a comma, and if there are no values then you need to enter ().

For example:

Override (35.6);

This means the Override method is used to set the point to have a value of 35.6

EnableAlarms();

This means that the EnableAlarms method is used. As it has no values (it activates the alarm feature for an item), the () is entered.

PromoteOS (900, 3600, TRUE);

This means that the PromoteOS method has 3 arguments—900 is the interval, 3600 is the duration, and TRUE sets the outstation to perform a One Shot immediately.

In the METHOD declaration for the PromoteOS method, the PromoteOS value definition has to include value types for each of the values:

METHOD
PromoteDialOut AT %M(PSTNOS.PSTN.PromoteDialOut):DINT,DINT,BOOL;
END_METHOD

The DINT, DINT, and BOOL definition set the 3 arguments (the interval and duration are DINTs and the immediate One Shot argument is a Boolean).

The path for the PSTNOS database item includes the PSTN aggregate aswell as the PromoteDialOut method. For methods that are associated with arguments rather than the database item, you need to define the method in this format:

<Method name in program> AT %M(<Name of database item>.<Name of aggregate>.<Name of method in ClearSCADA Database>):<value type>,<value type>, <value type>;

You only need to add <value type> for each argument for the method.


Logic Guide - Controlling the Flow of the Program (ST Programs)

Controlling the Flow of the Program

Once you have defined the variables, database object structures etc. for your program, you can begin to define the Logic.

The Logic that you define will determine what happens when the program executes. For example, it will determine whether values are written to the database or methods are performed on database items. The result of the program will depend on the variables and the structure of the Logic.

To define the Logic, you need to refer to the variables and use a series of Logic conditional statements. The conditional statements allow you to define the flow of your program.

There are several types of conditional statement, including:

  • IF - THEN - ELSE
  • IF - THEN - ELSIF - ELSE
  • AND, OR, and XOR
  • CASE - OF
  • FOR - TO - BY
  • WHILE - DO
  • REPEAT - UNTIL
  • RETURN.


Logic Guide - IF - THEN - ELSE (ST Programs)

IF - THEN - ELSE

The IF-THEN-ELSE statement is a commonly used ST statement. It allows you control the value of an item based on the value of another item.

Example:

IF Level > 75 THEN
Pump1 := FALSE;
Pump2 := FALSE;
ELSE
Pump1 := TRUE;
Pump2 := TRUE;
END_IF;

In this Logic, the Pump state and Power state are set to OFF (FALSE) when the value of the Level is less than 75. When the value of the level is not less that 75 (i.e. is greater than 75), the Pump and Power states are set to ON (TRUE). This type of Logic can be used in the water industry where a pump needs to be turned on to pump water out of a pipe when the level is greater than 75.

You need to enter IF-THEN-ELSE statements in the following format:

IF <item name or value name> = <value> THEN
<Value name> := <specific value>;
ELSE
<Value name> := <specific value>;
END_IF;

You can also nest IF-THEN-ELSE statements to create complicated control Logic. For example:

IF PumpQuality = Good THEN
IF Valve = CLOSED THEN
Valve := OPEN;
END_IF;
ELSE
PumpQuality := Bad;
END_IF;

In this example, the parent IF-THEN-ELSE statement instructs the program to evaluate the nested IF-THEN-ELSE statement when the PumpQuality is Good. If the PumpQuality is Bad, the program will not evaluate the nested statement.

The nested IF-THEN-ELSE statement is only executed when the PumpQuality is Good. It instructs the program to check if the valve is closed. If it is closed, then the program will open the valve.

When you nest an IF-THEN-ELSE statement, you need to apply the same formatting rules. The statement needs to be started with an IF keyword and has to be ended with an END_IF; keyword.

NOTE: We recommend that you indent nested IF-THEN-ELSE statements as this makes the program easier to read.


Logic Guide - IF - THEN - ELSIF - ELSE (ST Programs)

IF - THEN - ELSIF - ELSE

The IF-THEN-ELSIF-ELSE statement is a commonly used ST statement that allows you control the value of an item based on the value of other items. The ELSIF part of the statement combines ELSE and IF.

You have to enter IF-THEN-ELSIF-ELSE statements in the following order:

IF <code> THEN
<code>;
ELSIF
<code>;
ELSE
<code>;

END_IF;

Where <code> is any valid code structure. When using the IF-THEN-ELSIF-ELSE keywords, the keywords have to be used in that order (IF first, followed by THEN, and then ELSIF, with ELSE last).

Example:

IF Level > 75 THEN
Pump1 := TRUE;
Pump2 := TRUE;
ELSIF Level > 50
Pump1 := TRUE;
Pump2 := FALSE;
ELSE
Pump1 := FALSE;
Pump2 := FALSE;
END_IF;

In this Logic, there are 2 pumps (Pump 1 and Pump 2) and the program uses the values of an input called Level to control the state of these pumps:

  • When the value of Level is greater than 75, both pumps are set to True (both pumps are on).
  • When the value of Level is less than 75 but greater than 50, Pump 1 is set to True (on) and Pump 2 is set to False (off).
  • When the value of Level is less than 75 and less than 50, both of the pumps are set to False (off).


Logic Guide - AND, OR, and XOR (ST Programs)

AND, OR, and XOR

You can use AND, OR and XOR for multiple conditions. These keywords provide the following results:
Input Values | AND | OR | XOR
Input A = True Input B = True | True | True | False
Input A = True Input B = False | False | True | True
Input A = False Input B = True | False | True | True
Input A = False Input B = False | False | False | False

The syntax for entering an AND, OR or XOR keyword is:

<Value name> := <Value1> <Keyword> <Value2>;

Where value name is the name of the variable that will store the result of the statement, Value1 is the first input value, Value2 is the second input value, and Keyword is AND, OR or XOR as required.

Examples:

Output := Input1 AND Input2;

This sets the value of the variable named Output to be True if Input1 and Input 2 are both True, or False if only one of the inputs is True.

Output := Input1 OR Input2;

This sets the value of the variable named Output to be True if either Input1 or Input 2 are True. The Output value will only be False if both of the inputs are False.

Output := Input1 XOR Input2;

This sets the value of the variable named Output to be True if one of the inputs is True and the other is False. The Output will only be False if both of the inputs are True or both of the inputs are False.


Logic Guide - CASE - OF (ST Programs)

CASE - OF

You can use the CASE - OF statement to set the values of defined variables based on an integer input. For example, you can use the CASE - OF statement to set the values of points named 'Point 2' and 'Point 3' based on the status value of a point named 'Point 1'. The 'Point 1' status is represented by an integer value that is used as an input.

When you enter a CASE - OF statement, you need to use the following format:

CASE <Name of Integer Input> OF
<Integer Value 1> : <Statements>;
<Integer Value 2> : <Statements>;
ELSE
<Statements>;
END_CASE;

Where <Name of Integer Input> is the name of the integer variable that is used to determine the values of the other variables. The <Name of Integer Input> has to be defined in the VAR list for the program.

<Statements> represents the values that are set when the integer variable is the defined value. You can set multiple statements based on the integer variable being a defined value. For example, if Integer Value 2 is 6, you can define statements that set variable 3 to 90 and variable 4 to 15. The format for defining a statement is:

<Variable name> := <value>;

You can use the ELSE statement to define the values for the statements when the integer input is not a value included in the CASE - OF definition. For example, if an integer value has 6 possible settings and only setting 1 and 2 are used in the CASE - OF statement, the ELSE statement needs to be used to define the variable values when the integer value is 3, 4, 5, or 6. You need to end the CASE - OF statement with an END_CASE; keyword.

Example:

TYPE
FanCooler: (Low, High, Off);
END_TYPE
PROGRAM CoolerSpeed
VAR
Fan_Setting: INT;
SPEED: INT;
COOLER: FanCooler;
END_VAR
COOLER := Off;
CASE Fan_Setting OF
1: SPEED := 5;
2: SPEED := 10;
3,4,5: SPEED := 20; COOLER := Low;
6..8: SPEED := 40; COOLER := High;
ELSE
SPEED := 0;
END_CASE;
END_PROGRAM

In this example, the Logic is used to set the speed of a fan and its cooler based on the integer input of the fan.

An encapsulated data type is created to define the fan cooler settings. The data type is named FanCooler and it defines the three fan cooler values (Low, High, and Off).

At the start of the program, the COOLER variable is defined as Off. This means that the COOLER variable is set to Off unless set to be Low or High by the Logic.

The variables list contains 3 variables: Fan_Setting which represents the integer value that indicates the state of the fan, SPEED which represents the rate at which the fan is running, and COOLER which represents the fan cooler setting. The Fan_Setting variable is set to INT as it provides an integer value. This value is used by the Logic program to determine the values of the COOLER and SPEED variables. The SPPED variable is also an integer value (for the example, the values are internal values), and the data type for the COOLER variable is FanCooler (a reference to the encapsulated data type).

The CASE - OF statement is used to define how the Logic program sets the values for the variables:

When the Fan_Setting variable is 1, the program sets the SPEED variable to 5.

When the Fan_Setting variable is 2, the program sets the SPEED variable to 10.

When the Fan_Setting variable is 3, 4, or 5, the program sets the SPEED variable to 20 and the COOLER variable to Low.

When the Fan_Setting variable is 6 to 8 inclusive, the program sets the SPEED variable to 40 and the COOLER variable to High.

Other Fan_Setting variable values cause the program to set the SPEED variable to 0.


Logic Guide - FOR - TO - BY (ST Programs)

FOR - TO - BY

You can use the FOR - TO - BY statement to create a loop—the program repeats a set of statements on each execution, until a specific value is reached.

When you use a FOR - TO - BY statement, you need to enter it in this format:

FOR <Variable> :=<Initial value> TO <End loop value> BY <Decrement value>
DO
<Statements>;
END_FOR;

Where <Variable> is the name of the value that will be used to determine whether the program continues to execute the <Statements>. With FOR - TO - BY statements, you enter the variable in the FOR - TO - BY declaration and not in the VAR list. The variable has to be an integer.

The <Initial value> is the starting value of the integer <Variable>.

TO <End loop value> defines the value at which the program will stop executing the <Statements>. When the <Variable> reaches the <End loop value>, the program will no longer attempt to execute the <Statements>.

BY <Decrement value> defines the amount by which the <Variable> value will change upon each execution. The BY declaration is optional and is +1 by default.

DO <Statements> defines the statements that the program performs each time that the program executes and the <Variable> value is not the <End loop value>.

Example:

FOR InputA := 10 TO -10 BY -1 DO
Square[InputA] := InputA * InputA;
END_FOR;

In this example, the FOR - TO - BY statement instructs the program to decrease the InputA value by 1 on each execution of the program. It will decrease the InputA value by 1 until the InputA value is -10.

The Square[InputA] : InputA * InputA calculation is performed after each execution. This array is used to produce the square values of the array variables (which would be defined in the array above the FOR - TO - BY statement in the program).

As the array values are calculated based on the current value of InputA, it means that each time the program executes, it provides a new set of results for the array. This occurs due to the FOR - TO - BY statement decreasing the InputA value by 1 for each execution (until the InputA value is -10). As the InputA value is lower for each execution, the results for the array values are different for each execution (the program uses the InputA value to calculate the values for the array).


Logic Guide - WHILE - DO (ST Programs)

WHILE - DO

You can use the WHILE - DO statement to set a program to execute statements in a loop while an input is true. A typical use of the WHILE - DO statement is to set a program to define values or perform methods on a resultset of an SQL Query when a particular condition is in place.

NOTE: The WHILE - DO expression is evaluated before the statements are executed. This means that if the expression in the WHILE - DO definition is false, the program will not begin to execute the statements in the program.

You can define a WHILE - DO statement by using this format:

WHILE <Condition expression> DO
<Statements>;
END_WHILE;

Where:

<Condition expression> is the expression that defines the value that has to be true before the program will check the statements.

<Statements> are the values and methods that are set as a result of the <Condition expression> being true.

Example:

TYPE
AlarmConds : DATABASE_OBJECT (CDBPoint)
AlarmDesc: STRING;
Accept: METHOD;
END_DATABASE_OBJECT;
END_TYPE
PROGRAM Name
VAR
PointList AT %S(Select Id, AlarmDesc FROM CDBPoint): RESULTSET OF AlarmConds;
END_VAR
WHILE PointList.Value.AlarmDesc='Unacknowledged Cleared' DO
PointList.Value.Accept();
PointList.Next();
END_WHILE;
END_PROGRAM;

In this example, we use a DATABASE_OBJECT structure to group a type of value and a method. In this case, the DATABASE_OBJECT structure references the CDBPoint class and includes the AlarmDesc value (which is a STRING) and the Accept method (that acknowledges alarms).

In the VAR list, the variable defines the SQL Query that is used to obtain data from the CDBPoint class. The name of the SQL Query is defined as PointList and it is used to extract the Id and AlarmDesc values from the CDBPoint class (the Query returns the values for the RESULTSET of the AlarmConds DATABASE_OBJECT structure).

In the Logic of the program, the WHILE - DO statement is used to instruct the program to acknowledge any point alarms that are Unacknowledged Cleared:

WHILE PointList.Value.AlarmDesc= 'Unacknowledged Cleared' DO
PointList.Value.Accept();
PointList.Next();

END_WHILE;

This defines that as long as the current record in the SQL Query result set has an AlarmDesc value of 'Unacknowledged Cleared', the Accept method has to be used. The Accept method is applied so that the 'Unacknowledged Cleared' alarm is acknowledged for the point to which the current record relates.

The PointList.Next() instruction sets the program to proceed to the next record in the result set once the current record has had any 'Unacknowledged Cleared' alarms acknowledged.

The Logic program continues to step through each of the records in the record set, acknowledging any 'Unacknowledged Cleared' alarms until it reaches the end of the record set. When the records have been checked, the program stops executing.


Logic Guide - REPEAT - UNTIL (ST Programs)

REPEAT - UNTIL

You can use the REPEAT - UNTIL statement to create a loop that continues to execute until a specified condition occurs. For example, you can use a REPEAT - UNTIL program to increase a count by 1 and a value by 10 until the value reaches 100:

REPEAT
CountValue := CountValue+1;
CurrentValueFormatted : = CurrentValueFormatted +10;
UNTIL
CurrentValueFormatted >=100
END_REPEAT;

Where CountValue and CurrentValueFormatted are the names of variables (that would be defined in the VAR list).

In this example, the program increases the CountValue by 1 and the CurrentValueFormatted by 10 on each execution. This part of the program repeats itself until the CurrentValueFormatted is equal to or greater than 100.

If the CurrentValueFormatted is 200 when the program starts, the program will still increase the CountValue by 1 and the CurrentValueFormatted by 10 one time—REPEAT statements are performed at least once (as the condition is a the end of the statement).

When you enter a REPEAT - UNTIL statement, you need to use the following format:

REPEAT
<Statements>;
UNTIL
<Condition>
END_REPEAT

Where <Statements> defines the values and methods that are set by the program in the REPEAT statement. <Condition> is the value that causes the program to stop repeating the Logic defined in the REPEAT statement.


Logic Guide - RETURN (ST Programs)

RETURN

You can use the RETURN statement within a Function Block (see Function Blocks in ST Programs). The RETURN statement terminates the Function Block but instructs the program to use the Function Block values that had been calculated up to that point. For example, if a Function Block calculates 4 output values and the RETURN statement is positioned after the second value has been calculated, the first 2 values will be used by the program but the 3rd and 4th values will not be used as the RETURN statement terminates the function block before they are calculated.

The RESULT statement is useful when certain values that are calculated by a Function Block are not required in a particular scenario. You should enter the RETURN statement at the position where you want the program to terminate the Function Block (when a defined condition occurs).

Example:

FUNCTION_BLOCK POWERLOAD
VAR_INPUT
CURRENT,POWER1,POWER2,POWER3:REAL;
END_VAR
VAR_OUTPUT
OVERLOAD:BOOL;
END_VAR
IF((power1 * current) > 100) THEN
overload := TRUE;
RETURN;
END_IF;
IF((power1 * (current + 10)) > 100 THEN
overload := TRUE;
RETURN;
END_IF;
IF((power1 * (current + 20)) > 100 THEN
overload := TRUE;
END_IF;
END_FUNCTION_BLOCK;

In this example, the Function Block is used to determine whether there is a power overload. If the power1 value x the current value is equal to or greater than 100, there is a power overload and so the overload value is true.

If the power2 value x the current value +10 is equal to or greater than 100, there is a power overload and so the overload value is true.

If the power3 value x the current value +20 is equal to or greater than 100, there is a power overload and so the OVERLOAD value is true.

Each IF statement needs to be performed in turn. There is a RETURN statement after the first IF statement and another after the second IF statement. This means that if the overload value is true after the first IF statement, the rest of the program is ignored. Similarly, if the overload value is true after the second IF statement, the rest of the program is ignored.


Logic Guide - Using an ST Program to Call an SQL Query (ST Programs)

Using an ST Program to Call an SQL Query

You can code an ST program to retrieve information from the database via an SQL Query. The requested data is returned in a RESULTSET and can then be used in the ST Program's calculations.

Each Query returns a RESULTSET that has these variables:

  • .Valid—This is a Boolean variable that indicates whether the current row is Valid (True is valid; False is invalid).
  • .Idx—This is a DINT and is the index number of the current row.
  • .Size—This is a DINT and is the total number of rows in the RESULTSET.
  • .Value—This corresponds to the Type defined in the Query and represents the requested property of the current row.

The following methods can be used to navigate through the RESULTSET:

  • .First()—Go to first record in RESULTSET
  • .Last()—Go to last record in RESULTSET
  • .Next()—Go to the subsequent record in the RESULTSET
  • .Prev()—Go to the preceding record in the RESULTSET

NOTE: The SQL Query in an ST Program can only access data in the ClearSCADA database.

The syntax for calling an SQL Query in an ST program is:

TYPE
<Name of Type for RESULTSET>:<STRUCT or DATABASE_OBJECT>
<Member Name> : <Type>;
<Member Name> : <Type>;
<Method Name>: METHOD;
<END_STRUCT or END_DATABASE_OBJECT>;
END_TYPE
PROGRAM <Program Name>
VAR
<Var name> AT %S(SELECT <column 1>, <column 2>,<column 3> FROM <Database Table> WHERE <Filter>) :RESULTSET OF <Name of Type for RESULTSET>;
END_VAR

Where:

  • Type indicates the start of the type definition.
  • <Name of Type for RESULTSET> is the name of the user defined type that will contain the data returned by the SQL SELECT Query.
  • <STRUCT> declares the start of a Structure and <DATABASE_OBJECT> indicates the start of a database object structure. Structures are used when the ST Program only needs to reference one field of an item's data; DATABASE_OBJECT structures are used when the ST Program needs to reference more than one of a database item's fields. When declaring a DATABASE_OBJECT structure, the required database table has to be included in parenthesis after DATABASE_OBJECT, for example, DATABASE_OBJECT(CPointAlgManual).
  • <Member Name> : <Type>; declares the name and type of a data field that you want to use in your ST Program. For DATABASE_OBJECT structures, the name has to match the name of a column in the SQL Query. You can declare as many member names and types as required.
  • <Method Name> : METHOD; declares the name of a method that is available to the declared structure. For example, the DATABASE_OBJECT(CPointAlgManual) structure has an Current Value method that can be declared as: CurrentValueFormatted: METHOD; The method can then be called in the ST Program by using the syntax <Variable Name>.Value.CurrentValueFormatted(); where <Variable Name> is the name of the variable that is used to store the RESULTSET of the SQL Query.
  • <END_STRUCT or END_DATABASE_OBJECT>; ends the structure declaration.
  • END_TYPE ends the Type declaration.
  • PROGRAM <Program Name> declares the start of the ST program. The Program Name can be any name you require.
  • VAR defines the start of the variable declaration.
  • <Var name> AT %S declares the name of the variable used for the SQL Query and AT %S indicates that the variable will be used to contain data returned from an SQL SELECT Query. You can enter any name for the variable.
  • (SELECT <column 1>, <column 2>,<column 3> FROM <Database Table> WHERE <Filter>) defines the columns that are to be included in the SQL Query.

The column names have to match the names of columns in the selected database table (and the member names for the DATABASE_STRUCTURE, as these also have to match the columns in the selected database table).

NOTE: When you are using a DATABASE_OBJECT structure, the first column in your SQL Query has to be the Id column. This is because DATABASE_OBJECT structures have an Id field (although it is not included as one of the member names for the DATABASE_OBJECT structures).

The FROM <Database Table> part defines which table in the database the SQL Query is to search for the defined columns, and the WHERE <Filter> part defines any filtering. For example, SELECT CurrentValueFormatted FROM CPointAlgManual WHERE FullName LIKE 'Pumps.%') instructs the Query to search for the CurrentValueFormatted column in the CPointAlgManual table and to filter its results to include only those that are in the 'Pumps' Group or one of its children.

  • RESULTSET OF <Name of Type for RESULTSET> declares that the results of the Query will be returned into a RESULTSET of the defined type (the name of the type should match the name of the type that was defined at the start of the TYPE declaration).

When you have declared the Type, Members, Methods, and SQL Query as required, you can use the RESULTSET variables and methods in your ST Program. Typically, they are used within WHILE...DO functions.

NOTE: Do not enter the angle brackets < >. As with other syntax descriptions, you should not enter the angle brackets unless specifically instructed to do so.

Examples:

Example 1.

The following example shows an ST Program that is used to search for internal analog points in a Group named 'Power Simulation'. When the program locates the internal points, it steps through each record and increases the corresponding point's current value by 1:

TYPE
Point : DATABASE_OBJECT(CPointAlgManual)
CurrentValueFormatted : LREAL;
CurrentState : INT;
END_DATABASE_OBJECT;
END_TYPE
PROGRAM SQLTestHanddressPts
VAR
Pts AT %S(SELECT Id, CurrentValueFormatted, CurrentState FROM CPointAlgManual WHERE FullName LIKE 'Power Simulation.%') : RESULTSET OF Point;
END_VAR
WHILE Pts.Valid DO
Pts.Value.CurrentValueFormatted := Pts.Value.CurrentValueFormatted + 1;
Pts.Next();
END_WHILE;
END_PROGRAM

Example 2.

The following example shows an ST Program that is used to search for advanced outstations. When the program locates the outstations, it steps through each record and resets the corresponding outstation's communication statistics:

TYPE
Outstation : DATABASE_OBJECT( CAdvOutstation )
ResetCommsStatistics : METHOD;
END_DATABASE_OBJECT;
END_TYPE
PROGRAM ResetAllOsCommsStats
VAR
Os AT %S(SELECT Id FROM CAdvOutstation) : RESULTSET OF Outstation;
END_VAR
WHILE Os.Valid DO
Os.Value.ResetCommsStatistics();
Os.Next();
END_WHILE;
END_PROGRAM


Logic Guide - Inserting, Updating, and Deleting Values by Using SQL in an ST Program (ST Programs)

Inserting, Updating, and Deleting Values by Using SQL in an ST Program

You can use the INSERT, UPDATE, and DELETE Data Manipulation Language (DML) statements in SQL queries within your ST programs. These statements are especially useful when creating, updating, or removing values in data tables.

Although ClearSCADA supports the use of INSERT, UPDATE and DELETE with any of the database tables, we strongly recommend that you do not use these statements with any query that affects the configuration of the database on a regular basis. Frequent alterations to the configuration may cause slow performance and affect the running of your system. This does not affect data tables as they do not store configuration.

If you are using the INSERT, UPDATE and DELETE statements, they need to be declared in your SQL query. When the ST program runs, it will create a queue of the insertions, updates and deletions it needs to make and will only perform these actions once the program has executed.

To use the INSERT, UPDATE or DELETE statement, you need to include the statement keyword in your SQL query and use %D to declare that DML statements are being used. You can use multiple DML statements in the same ST program—when the program has executed, the insertions, updates and deletions are performed in the order in which they appear in the code.

If you wish to include parameters for an insertion, you can do so by using the ? character to represent the values and the WITH_PARAMS keyword to indicate that there are parameters (see Passing Multiple Parameters into an SQL Query in an ST Program).

Example:

The following example shows how an ST program can make use of the DML statements. In this example, the program:

  1. Deletes the values from a data table item called 'LogicDataTable'.
  2. Inserts an entry in the data table with STRING[64] and DINT type values. The values will be used for the StringField and NumberField fields for the new entry in the data table. In this case, the values are: 20 and 'First Record'.
  3. Updates the data table so that NumberField entries are increased by 5.
  4. Inserts another entry into the data table, again with STRING[64] and DINT type values. The values used for the entry are 10 and 'Second Record'.
  5. Deletes entries that have a specific NumberField value (in this case, 25).

The ST program code is as follows:

PROGRAM test
VAR
Num : DINT;
Str : STRING[64];

END_VAR
VAR
Init AT %D(DELETE FROM LogicDataTable );

R1 AT %D(INSERT INTO LogicDataTable VALUES ( ?, ? ) ) WITH_PARAMS Str, Num;

R2 AT %D(UPDATE LogicDataTable SET NumberField = NumberField + 5 );

R3 AT %D(DELETE FROM LogicDataTable WHERE NumberField = ?) WITH_PARAMS Num;

END_VAR
Init.Execute();
Num := 20;
Str := 'First Record';
R1.Execute();
R2.Execute();
Num := 10;
Str := 'Second Record';
R1.Execute();
Num := 25;
R3.Execute();

END_PROGRAM

If you look at the program code, you will see that in the second VAR declaration there are 4 variables; 1 for each DML statement:

  • The Init variable contains a query that instructs the program to delete data from the LogicDataTable object when the variable is called.
  • The R1 variable contains a query that instructs the program to insert values into the LogicDataTable object when the variable is called - it will create a row with 2 values of a specific type (defined in the first VAR declaration).
  • The R2 variable contains a query that instructs the program to update the NumberField fields in the LogicDataTable object so that they increase by 5.
  • The R3 variable contains a query that instructs the program to delete entries from that LogicDataTable that have a specific NumberField value.

In the code following the second VAR declaration, you can see the order in which the methods will be called:

  1. When the program is executed, the Execute method will be called on the query in the Init variable: data will be removed from the LogicDataTable object.
  2. The Execute method will be called on the query in the R1 variable. This will create a new entry in the LogicDataTable that has 20 for the NumberField value and 'First Record' for the StringField value.
  3. The Execute method will be called on the query in the R2 variable. This will update the row in the LogicDataTable so that the row has 5 added to its NumberField value. So the row will have a NumberField of 25.
  4. The Execute method will be called on the query in the R1 variable again. This will create another new row, this time with the values 10 and 'Second Record'.

Finally, the Execute method will be called on the query in the R3 variable. This will delete the entries in the LogicDataTable that have 25 as their value in the NumberField field. So, the first row that was inserted by the program will be deleted.

Further Information

WITH_PARAMS: Passing Multiple Parameters into an SQL Query in an ST Program.


Logic Guide - Passing Multiple Parameters into an SQL Query in an ST Program (ST Programs)

Passing Multiple Parameters into an SQL Query in an ST Program

You can pass multiple parameters into an SQL query in an ST program. This is useful when you want to apply additional criteria that has to be met by the values in the RESULTSET (this works similarly to a filter) and is also useful when you are using DML statements to insert multiple values for one or more rows in a table (see Inserting, Updating, and Deleting Values by Using SQL in an ST Program).

To enter multiple parameters in an SQL query within an ST program, you need to use the ? character to represent the value of each parameter and the WITH_PARAMS keyword to define the parameters.

When entering multiple parameters in an SQL query in an ST program, you need to use the ? character to represent each parameter value in the query. The WITH_PARAMS keyword has to be used in the RESULTSET and each parameter listed after the WITH_PARAMS keyword has to correspond to the name of one of the ST program's VAR inputs. You should separate the parameters after the WITH_PARAMS keyword with commas.

The order of the parameters that you define after the WITH_PARAMS keyword corresponds to the order of the ? characters defined in the SQL query. You can repeat the parameters so that the same parameter can be used multiple times in the SQL.

Example:

In this example of an ST Program, the parameters for the SQL query are defined as VAR_INPUTs with the names objName and objFullScale. In the SQL query, the ? character is used to represent the parameters. The DATABASE_OBJECT is used to define the database table (in this case, CPointAlg) and the type of value for the properties defined in the SQL query (Name and FullScale).

TYPE
Point: DATABASE_OBJECT (CPointAlg)
Name:STRING;
FullScale: LREAL;
END_DATABASE_OBJECT;
END_TYPE
PROGRAM NameAndFullScale
VAR_INPUT
objName : STRING;
objFullScale: LREAL;
END_VAR
VAR
objList AT %S(SELECT Id, Name, FullScale FROM CPointAlg WHERE Name LIKE? || '%' AND FullScale > ?) : RESULTSET OF Point WITH_PARAMS objName, objFullScale;
END_VAR
;
END_PROGRAM

So, the SQL query in the ST Program will return the Id, Name, and FullScale values from the CPointAlg database table. It will only return the values for those items that have a Name value that is like the value of the first parameter followed by any amount of characters and has a FullScale value that is greater than the value of the second parameter. The first parameter is the objName parameter as this is the first parameter listed after the WITH_PARAMS keyword. The objFullScale parameter is the second parameter as it is listed second after the WITH_PARAMS keyword. So in the SQL query, the first ? character corresponds to the objName parameter and the second ? character corresponds to the objFullScale parameter. If the SQL query was to contain an additional ? character, an additional parameter would be required in the list of parameters after the WITH_PARAMS keyword. The additional parameter in the list could be a new parameter or could be one of the existing parameters used again, for example, it could be another use of the objFullScale parameter.


Logic Guide - Function Blocks in ST Programs (ST Programs)

Function Blocks in ST Programs

Function blocks are blocks of code that define a type of Logic behavior or calculation. As they provide a specific Logic behavior or calculation, they can be used in ST programs and other Logic programs. This means you can save time when coding your ST programs as if there are function blocks (default or custom) that provide the Logic or calculations that you require in your program, you can attach the function block instead of recreating the code. Function blocks act as 'building blocks' that you can use to create your programs.

Each function block has inputs, an internal data structure that defines the Logic that is provided by the function block, and outputs.

You can define a built-in function block within an ST program. The function block will use inputs to perform a specified calculation, then write the results to outputs. If you enter a function block within an ST program, the function block is only available to that ST program. For more information, see Built-In Function Blocks.

Alternatively, you can define a function block in a Structured Text Library or in a Function Block Library. The Libraries can be used over and over again in your Logic programs. This means you can define the function block once in an ST Library or Function Block Library and use it in as many programs as you wish (see Using Libraries in ST Programs).

For information on the required syntax when entering a function block in an ST program, please refer to Built-In Function Blocks.


Logic Guide - Using Libraries in ST Programs (ST Programs)

Using Libraries in ST Programs

We recommend that you store reusable blocks of code in Structured Text libraries. The ST libraries can then be attached to other ST programs. The advantages of using ST libraries, include:

  • ST libraries reduce the amount of time and effort needed to create ST programs. If you create an ST library for a block of code that is needed in several ST programs, you can write the code for the library once and then attach the library to each ST program as required.
  • ST libraries reduce the amount of time it takes to make alterations to a block of code that is used in several ST programs. You can make the required changes to the ST library and then update the library in each ST program. This is much quicker than having to alter the code in each ST program separately.

You can also use Function Block Libraries to store custom function blocks that can be referenced by multiple Logic programs.

For more information on ST Libraries and Function Block Libraries, see User Function Blocks.


Logic Guide - Compiling an ST Program or ST Library (ST Programs)

Compiling an ST Program or ST Library

You can use the Build menu options to compile your ST program. The compilation feature is useful as it checks that your program has the correct syntax.

There are 2 compile options:

  • Compile—Compiles the program. If the program is invalid, the compiler display provides a message that briefly describes the syntax error in your program. If the syntax is correct, the compiler displays a success message.
  • Compile with Diagnostics—Compiles the program and provides detailed diagnostic information (the Logic in ST, the ST code formatted with indented text etc., and the op codes which is the machine code version of the ST code). As with the Compile option, there are messages for any errors in the syntax. If the syntax is correct, the compiler displays a success message.

NOTE: The Compile with Diagnostics tool is useful when working with other types of Logic program that you want to use as ST programs. For example, you may find it easier to create a Function Block Diagram and then use the Compile with Diagnostics tool to access the ST code for the Function Block Diagram. You can then copy this code into an ST program (you have to remove the $ signs in the code).

To compile an ST program or ST library:

  1. Display the ST program or ST library in Design mode.
  2. Select the Build menu, then select the Compile option or the Compile with Diagnostics option as required.
    The program or library is compiled and the compile messages are shown in the Compiler display.
    Compiler display shows compiler messages and diagnostics.

If there are syntax errors, you will need to alter the ST code. Typically, the causes of syntax errors are minor, such as the wrong type of value being specified or a missing semi-colon.

When you have successfully compiled your program, you can use the Debug option to check that its Logic defines the required behavior (see Debugging an ST Program or ST Library).


Logic Guide - Debugging an ST Program or ST Library (ST Programs)

Debugging an ST Program or ST Library

You can use the Debug feature to debug your ST program or ST library. The debugging feature allows you to check that your program provides the expected Logic functions. It is particularly useful when you need to check separate parts of large programs—you can step through each section of the program and view its effect on the variables. To view the variables, you need to use the Variables window (see the Variables option later in this section). This helps you to determine which parts of your ST programs are not working as intended (if any).

NOTE: A Logic program can only be debugged by one user at a time. When a user has a Logic program in debug mode, it cannot be executed manually or by schedules.

There are two ways to start the debugging process:

  • When displaying an ST program or ST library in Design mode, you can select the Start Debugging option from the Build menu. This switches the ST program or ST library and starts the debugging feature.
  • You can display an ST program or ST library in Run mode (either from the Database Bar or by switching the ST program or library to Run mode manually), then select the Start Debugging option from the Debug menu.

Typically, you will need to use the debugging feature to debug separate sections of an ST program. For example, if a complex ST program is not returning the values you expected, you will need to debug each calculation within the program separately—this allows you to determine which sections of the ST program are incorrect.

To debug parts of a program, you need to use the Debug menu options:

  • Go—The debugger runs the program until it reaches a breakpoint or the program completes.
  • Restart—Starts the debugging feature again (after it has been stopped).
  • Stop Debugging—Stops the debugging feature. The debugger will not run again until you select the Restart option.
  • Insert/Remove Breakpoint—Inserts or removes a break point at a selected position. You need to use this option to divide your program into sections.

To insert a breakpoint, position the cursor in the line of code that you want to use as a breakpoint, then select the Insert/Remove Breakpoint option.

The debugger only runs the program up to the Breakpoint

The debugger will only run up to the breakpoint—it does not run the parts of the program that are after the breakpoint. By using the Variables window (see Viewing the Variables in your ST Program), you can view the values that are created by the program up until the breakpoint. By examining the values, you can determine whether the code in the section before the breakpoint is causing unexpected results.

If the code up to the breakpoint is working as expected, you can remove the breakpoint using the Insert/Remove Breakpoint option. Alternatively, you can disable it by selecting the Enable/Disable Breakpoint option.

  • Enable/Disable Breakpoint—You can use the Enable/Disable Breakpoint option to turn a breakpoint on or off without having to insert or delete it. This is useful when you want the debugger to run past a breakpoint you have inserted, but you do not want to remove the breakpoint (because you need to use it again at some point).

The Enable/Disable Breakpoint option works as a toggle. When you first select it, you disable a breakpoint so that the debugger ignores it. When you select it again, the breakpoint is enabled and the debugger will stop running the program at the breakpoint.

  • Step Into—When a program is being debugged, the debugger ignores the code in any function blocks that are contained within the program. You can set the debugger to run the function block code as well as the rest of the program code by selecting the Step Into option.

The Step Into option is useful when investigating function blocks within an ST program. If the function blocks have already been debugged, there is no need to use the Step Into option.

  • Step Over—Sets the debugger to ignore any further statements in a function block that is contained within the ST program. If the debugger is set to Step Into when you select this option, it will execute the current statement in the function block and then return to the main part of the ST program. It will not execute the remaining calculations in the function block (unlike the Step Out option).

The debugger is set to Step Over by default.

  • Step Out—Sets the debugger to ignore any further statements in a function block that is contained within the ST program. If the debugger is set to Step Into when you select this option, it will execute the remaining statements in the function block and then return to the main part of the ST program.
  • Run to Cursor—Sets the debugger to execute the program statements up to the cursor position. When you select this option, the position of the cursor acts like a breakpoint.
  • Show Next Statement—Positions the cursor at the line of the next statement that is to be executed.
  • Variables—Displays the Variables window. You need to use this window to view the values that are being produced by each section of the ST program. By examining the values that are produced, you can determine which values are unexpected (and therefore which parts of the ST code may be incorrect). For more information, see Viewing the Variables in your ST Program.
  • Rerun on Completion—By default, when the debugger has executed every statement successfully, it waits a short time before starting the debugging process again. You can use the following options to control how long the debugger waits and whether it will repeat the debugging process:
  • Enabled—When this option is selected, the debugger will repeat itself after it has executed each statement successfully. It will wait for a specific amount of time before it repeats.

If you clear this option, the debugger will only run once.

  • Break on Error—The debugger will execute each statement in the program (up to a breakpoint if a breakpoint is defined). If there is an error in the program, the debugger will stop at the line in which the error occurs.
  • After 1s, 2s, 5s, 10s, 30s, 60s—Defines the amount of time the debugger will wait after successfully executing each statement before it starts again. The options correspond to 1 second, 2 seconds, 5 seconds, 10 seconds, 30 seconds, and 60 seconds respectively.


Logic Guide - Viewing the Variables in your ST Program (ST Programs)

Viewing the Variables in your ST Program

When you display an ST program in Run mode, you can view a list of the variables in an ST program. The list shows the current values for the variables and is often used during debugging. The variables window is useful during debugging as it allows you to view the variables that are produced by each section of the code (you need to use breakpoints to separate the ST code into sections).

To display the variables window:

Either:

  1. Display your ST program in Design mode, then select the Build menu then the Start Debugging option.
    The program switches to Run mode.
  2. Select the Debug menu, then select the Variables option.
    The variables window is displayed.

Or:

  1. Display the ST program in Run mode (right-click on it in the Database Bar then select the Display option).
  2. Select the Debug menu, then select the Variables option.
    The variables window is displayed.

The variables window contains expandible lists of the variables in your ST program. For each variable, it lists the Name of the variable, the Type (which shows the data type), and the Value (which shows the current value of the variable).

For more information, please refer to Debugging an ST Program or ST Library.


Logic Guide - Ladder Diagrams

Ladder Diagrams

Ladder Diagrams are graphical programs that are similar to 'relay ladder' programs. Traditionally, 'relay ladder' programs have been used to program PLCs and similar devices. They are ideally suited to programs that provide complicated AND and OR logic.

If you are familiar with 'relay ladder' programs, you will soon become accustomed to working with Ladder Diagrams as they use similar symbols and features.

The following sections explain the concepts and features of Ladder Diagrams:

  • How Ladder Diagrams Work
  • Ladder Diagram Components
  • Create a Ladder Diagram Database Item
  • Edit a Ladder Diagram
  • Ladder Diagram Display
  • Add Variables to a Ladder Diagram
  • Add Processed Historic Values to Ladder Diagrams
  • Add a Constant Value to a Ladder Diagram
  • Add a Function to a Ladder Diagram
  • Add a Function Block to a Ladder Diagram
  • Add a Conversion to a Ladder Diagram
  • Add a Comment to a Ladder Diagram
  • Controlling the Flow of a Ladder Diagram
  • Edit a Variable on a Ladder Diagram
  • Rename a Variable on a Ladder Diagram
  • Delete a Variable on a Ladder Diagram
  • Compiling a Ladder Diagram
  • Viewing the Variables in your Ladder Diagram
  • Changing the Update Interval for a Ladder Diagram.

For information on the properties of the Ladder Diagram database item, see Logic Program Properties and Values.


Logic Guide - How Ladder Diagrams Work (Ladder Diagrams)

How Ladder Diagrams Work

In ClearSCADA, each Ladder Diagram represents a circuit consisting of 2 rails. Between the 2 rails are a 'rung' of contacts and coils that represent the inputs and outputs. Each 'rung' represents an AND Logic function. By adding branches to a rung, you can create OR Logic functions.

Power for the circuit starts at the left rail and passes through the contacts and coils to the right rail. The power can only pass through the contacts if they are in a 'true' state. When power reaches a coil and passes to the right rail, an output is written.

For example, a simple Ladder Diagram can be used to set a pump to start when both a flow is detected and power is detected in the pump. The inputs from the flow detection and pump power sensors are represented by direct contacts and the command to start the pump is represented by a coil.

In the Ladder Diagram shown above, the StartPump coil is only put into effect when the FlowPresent and PumpPower contacts are 'true'. As the FlowPresent contact is 'false', the power from the left rail cannot pass the FlowPresent contact and so the StartPump coil is not activated.

If both the FlowPresent and PumpPower contacts were 'true', the power from the left rail would pass through the contacts to the StartPump coil and on to the right rail. This means that the circuit is complete and the StartPump coil is put into effect.

By default, each rail on the Ladder Diagram is 'true'. In ClearSCADA, you can set the state of a rail to be dependent on another value. This allows you to associate Ladder Diagrams with other Ladder Diagrams or other Logic programs. For example, you can set the left rail of a Ladder Diagram to be 'false' except when a Function Block Diagram has an output of 'true'. This means that the Ladder Diagram only runs when the Function Block Diagram has been executed and returned a 'true' value—the output of the Function Block Diagram program is written to the state of the left rail.


Logic Guide - Ladder Diagram Components (Ladder Diagrams)

Ladder Diagram Components

ClearSCADA uses the following symbols to represent the various parts of a Ladder Diagram:
Symbol | Description
 | Direct contact. This type of contact allows the power to flow from the left rail to the right rail when the value is 1.
 | Inverted contact.This type of contact allows the power to flow from the left rail to the right rail when the value is 0.
 | Positive sensing contact.This type of contact acts as a pulse. When there is power from the left rail, the contact value momentarily switches to 1. When there is no power, the contact value is 0.
 | A negative sensing contact acts as a pulse. It has the reverse effect of the Positive sensing contact. When there is power, the contact value is 0. When there is no power, the contact value momentarily switches to 1.
 | A direct coil writes a value to a database item. If there is power from the left rail, it writes a 1 value. If there is no power from the left rail, it writes a 0 value.
 | Inverted coil. This output writes a value to a database item. It has the reverse effect of a direct coil. If there is power from the left rail, it writes a 0 value. If there is no power from the left rail, it writes a 1 value.
 | Set coil. This output is set to 1 when there is power from the left rail. Set Coil works in a similar way to an 'On' switch—when it is set to On by the power from the left rail, it remains On until it is specifically set to Off (by a reset).
 | Reset coil. This output is set to 0 when there is power from the left rail. Set Coil works in a similar way to an 'Off' switch—when it is set to Off by the power from the left rail, it remains Off until it is specifically set to On (by a Set).
 | Positive sensing coil. This output acts as a pulse. When the input from the left rail changes from 0 to 1, the coil outputs a 1 value. When the next rung of the Ladder Diagram is executed, the positive sensing coil reverts to having a 0 output.
 | Negative sensing coil. This output acts as a pulse. When the input from the left rail changes from 1 to 0, the coil outputs a 1 value. When the next rung of the Ladder Diagram is executed, the positive sensing coil reverts to having a 0 output.

Ladder Diagrams can also contain Constants, Connection Blocks, Functions, Function Blocks, and Conversions (see Controlling the Flow of a Ladder Diagram).


Logic Guide - Create a Ladder Diagram Database Item (Ladder Diagrams)

Create a Ladder Diagram Database Item

Each Ladder Diagram needs to be represented in the ClearSCADA database by a Ladder Diagram item. When you have created a Ladder Diagram item, you can access its Edit feature which allows you to create the Ladder Diagram program.

To create a Ladder Diagram database item:

  1. In the Database Bar, right-click on a system, Group, or Group Template to display a context sensitive menu.
  2. Select the New option, then the Logic option, then the Ladder Diagram option from the context sensitive menu.
    A new Ladder Diagram item is added to the system, Group, or Group Template. It is selected automatically, ready for you to enter its name.
  3. Enter a suitable name for the Ladder Diagram then press the Enter key or select another part of the interface.
    Ladder Diagram database item (shown in a Group).

Now that you have created a Ladder Diagram database item, you can edit it (see Edit a Ladder Diagram).


Logic Guide - Edit a Ladder Diagram (Ladder Diagrams)

Edit a Ladder Diagram

You can display a Ladder Diagram in Design mode by double-clicking on a Ladder Diagram item in the Database Bar. In Design mode, you can edit the Ladder Diagram by adding or removing contacts and coils and making connections.

To edit a Ladder Diagram, either:

  • Double-click on a Ladder Diagram item in the Database Bar.

Or:

  • Right-click on a Ladder Diagram item in the Database Bar, then select the Edit option from the context sensitive menu.

The Ladder Diagram is displayed in the ViewX Application window (see Ladder Diagram Display).


Logic Guide - Ladder Diagram Display (Ladder Diagrams)

Ladder Diagram Display

When you double-click on a Ladder Diagram item or select its Edit option, the Ladder Diagram display is shown.

The Ladder Diagram display consists of:

Database Bar. You can drag items such as points from the Database Bar onto the Ladder Diagram.
Direct and Internal Variables. These tabs contain lists of the properties and values that are included in the Ladder Diagram.
The Ladder Diagram.
You can design the Ladder Diagram by adding contacts, coils, etc.
The compiler display. Compiling and debugging information is shown here.

  • Database Bar—The Database Bar contains a hierarchical view of the ClearSCADA database. You can drag an item from the Database Bar onto the Ladder Diagram to create a contact or coil for the item.
  • Direct and Internal Variables—The variables tabs contain a list of the values that are included in the Ladder Diagram. The Direct tab contains the values that are associated with database items, and the Internal tab contains a list of internal variables such as function blocks.
  • Ladder Diagram—The Ladder Diagram contains the rails, contacts, coils, functions, function blocks, and connections that form the Ladder Diagram. This is where you create the Logic of the Ladder Diagram.
  • Compiler Display—The compiler display is where ClearSCADA displays diagnostic information for your Ladder Diagram. Any messages associated with compiling and debugging are shown here.


Logic Guide - Add Variables to a Ladder Diagram (Ladder Diagrams)

Add Variables to a Ladder Diagram

Each value that is read or written by your Ladder Diagram is represented by a variable or a constant. Constant values are fixed values and are described in Add a Constant Value to a Ladder Diagram. Variable values change according to the data that is stored in your system and the calculations that are performed on it.

There are 2 types of variable:

  • Internal variables are values that are used by the program but are not written to an item in the database. For example, values that are used in a conversion.
  • Direct variables are values that are stored in the database, for example, a point value.

The following sections explain how to add variables to your Ladder Diagram:

  • Add a Direct Variable to a Ladder Diagram
  • Add an Internal Variable to a Ladder Diagram.


Logic Guide - Add a Direct Variable to a Ladder Diagram (Ladder Diagrams)

Add a Direct Variable to a Ladder Diagram

The method that you use to add a direct variable to your Ladder Diagram will vary depending on whether the diagram already contains an instance of the value.

If your diagram does not already contain an instance of the direct variable that you want to add, refer to Add the First Instance of a Direct Variable to a Ladder Diagram.

If your diagram already contains an instance of the direct variable that you want to add, refer to Add Another Instance of a Direct Variable to a Ladder Diagram.

Add the First Instance of a Direct Variable to a Ladder Diagram

To add the first or only instance of a direct variable to a Ladder Diagram:

  1. In the Database Bar, select the database item that represents the direct variable that you want to add to the Ladder diagram. For example, if you want to add the value of a point named 'INT 1', select the 'INT 1' point item. When you select the item, keep the left-hand mouse button pressed down.
  2. Drag and drop the database item onto the Ladder Diagram.
    The Add Direct Variable window is displayed.
  3. Use the Add Direct Variable window to define the settings for the direct variable:
  • Name—Enter the name for the direct variable. This name will be used to refer to the variable within the program. A name is entered automatically when you drag a direct variable onto the Ladder Diagram, but you can change it as required.
  • Tag Type—Choose the type of direct variable tag. This can be:
  • Read/Write (%M)—The Ladder Diagram can both read the value and overwrite it with a new value.
  • Read Only (%I)—The Ladder Diagram can only read the value and cannot change it.
  • Write Only (%Q)—The Ladder Diagram cannot read the variable but can write a new value to it.
  • Tag—This is the name of the OPC property that represents the variable that you want to add to the Ladder Diagram. The tag can be an OPC tag (for normal, direct variable values) or an OPC Historic tag (see Add Processed Historic Values to Ladder Diagrams).
  • Type—Choose the type of value. The value type needs to be appropriate to the value that is represented by the selected tag. For more information, please refer to Built-In Data Types.
  • Insert—Choose the type of variable tag that you are adding to the Ladder Diagram. Choose the required type of contact or coil from the combo box (see Ladder Diagram Components).
  • Retained—The Retained feature is designed to be used with internal variables. When selected, it allows the internal variable to be stored and transferred to other servers (in a multi-server setup).

For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.

  • No Cache—Use the No Cache check box to determine whether the program uses the latest value or the initial value for a variable on each execution. If you check the No Cache check box, the program will use the latest value for the variable rather than the default value. If you clear the No Cache check box, the program will use the default value for the variable on each execution.

The No Cache feature is especially useful with variables that are used as counts. For more information on the No Cache feature, please refer to Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program.

  4. Select the OK button to confirm.
    A direct variable tag is added to the Ladder Diagram. You can then draw connections to or from it (see Controlling the Flow of a Ladder Diagram).

If you need to add another instance of the direct variable to your Ladder Diagram, see Add Another Instance of a Direct Variable to a Ladder Diagram.

Add Another Instance of a Direct Variable to a Ladder Diagram

You can use the Variables list to add multiple instances of the same direct variable to a Ladder Diagram. You can add the first instance of the direct variable by dragging the corresponding database item from the Database Bar onto the Ladder diagram and then configuring the variable settings. For subsequent instances of the direct variable, you can use the Add option that is available from the Direct tab of the Variables list:

To add another instance of a direct variable:

  1. In the Variables list (above the Ladder Diagram in the ladder display), select the Direct tab.
    A list of the Ladder Diagram's direct variables is shown.
  2. Click anywhere on the Variables pane.
    A context sensitive menu is displayed.
  3. Select the Add option.
    The Add Direct Variable window is displayed.

NOTE: As an alternative to steps 1-3 inclusive, you can drag and drop the same item onto the Ladder Diagram twice. When you add a direct variable, the Add Direct Variable window is displayed. You will need to rename the second instance of the item by using the Add Direct Variable window's Name field.

  4. Use the Add Direct Variable window to define the new instance of the variable:
  • Enter a Name for the direct variable. The name has to be unique. It cannot have the same name as any variables that are already included in the Ladder diagram.
  • Use the Tag Type combo box to define whether the variable is Read Only, Write Only, or Read/Write.
  • Use the browse button feature of the Tag field to select the database property that is the source of the variable's value. The tag can be an OPC tag (for normal, direct variable values) or an OPC Historic tag (see Add Processed Historic Values to Ladder Diagrams).
  • Use the Type combo box to choose the type of value. The value type needs to be appropriate to the value that is represented by the selected tag. For more information, please refer to Built-In Data Types.
  • The Retained feature is designed to be used with internal variables. When selected, it allows the internal variable to be stored and transferred to other servers (in a multi-server setup).

For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.

  • Use the No Cache check box to determine whether the program uses the latest value or the initial value for a variable on each execution. If you check the No Cache check box, the program will use the latest value for the variable rather than the default value. If you clear the No Cache check box, the program will use the default value for the variable on each execution.

The No Cache feature is especially useful with variables that are used as counts. For more information on the No Cache feature, please refer to Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program.

  5. Select the OK button to confirm your selection.
    The Add Direct Variable window is closed.
  6. Select the new variable in the Variables list and keep the left-hand mouse button pressed down.
  7. Drag the new variable from the Variables list onto the Ladder diagram.
    A context sensitive menu is displayed.
  8. Select the option that corresponds with the type of variable that you are adding to the Ladder diagram (see Ladder Diagram Components).
    A new contact or coil is added to the Ladder diagram, depending on the option you selected. The contact or coil represents the new instance of the variable.


Logic Guide - Add an Internal Variable to a Ladder Diagram (Ladder Diagrams)

Add an Internal Variable to a Ladder Diagram

Internal variables are values that are used by the program but are not written to an item in the database. They are used for:

  • Conversions
  • Separating long, complex calculations into smaller sets of calculations
  • Storing program states.

To add an internal variable to a Ladder Diagram:

  1. On the Ladder diagram display, select the Internal tab on the Variables list.
  2. Right-click in an empty row on the Variables list to display a context sensitive menu.
  3. Select the Add option to display the Add Internal Variable window.
  4. Use the Add Internal Variable window to define the settings for the internal variable:
  • Enter a Name for the direct variable. The name has to be unique. It cannot have the same name as any variables that are already included in the Ladder diagram.
  • Use the Type combo box to choose the type of value. The value type needs to be appropriate to the internal variable. For more information, please refer to Built-In Data Types.
  • In the Initial Value field, enter the default value for the internal variable. This is the first value of the internal variable. The internal variable will reset to this value for each execution of the Ladder Diagram executes unless the Retained feature is used (see below).
  • Use the Retained check box to determine whether the internal variable is stored and transferred to other servers. For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.
  • Check the Retained check box to allows the internal variable to be stored and transferred to other servers (in a multi-server setup).
  • Clear the Retained check box to prevent the internal variable from being stored and transferred to other servers. This will result in the internal variable being reset to its initial value each time the Ladder Diagram executes.
  5. Select the OK button to confirm the settings and close the Add Internal Variable window.
  6. Select the internal variable in the Variables list and keep the left-hand mouse button pressed down.
  7. Drag the internal variable from the Variables list onto the Ladder diagram.
    A context sensitive menu is displayed.
  8. Select the option that corresponds with the type of internal variable that you are adding to the Ladder diagram (see Ladder Diagram Components).
    A new contact or coil is added to the Ladder diagram, depending on the option you selected. The contact or coil represents the internal variable.


Logic Guide - Add Processed Historic Values to Ladder Diagrams (Ladder Diagrams)

Add Processed Historic Values to Ladder Diagrams

You can add processed historic values (historic values that have been calculated using a historic algorithm) to your Ladder Diagrams. This may be useful if you need to use a daily average or some other calculated value as part of the ladder Logic.

To add a processed historic value to a Ladder Diagram:

  1. Display the Add Direct Variable window by performing one of these procedures:

Either:

  1. In the Variables list (above the Ladder Diagram in the ladder display), select the Direct tab.
    A list of the Ladder Diagram's direct variables is shown.
  2. Right-click on the direct variable that you want to use again.
    A context sensitive menu is displayed.
  3. Select the Add option.
    The Add Direct Variable window is displayed.

Or:

  1. In the Variables list (above the Ladder Diagram in the ladder display), select the Direct tab.
    A list of the Ladder Diagram's direct variables is shown.
  2. Right-click on the direct variable that you want to use again.
    A context sensitive menu is displayed.
  3. Select the Add option.
    The Add Direct Variable window is displayed.
  2. In the Name field, enter a suitable name for the variable.
  3. Use the Tag Type combo box to define whether the variable is Read Only, Write Only, or Read/Write.
  4. Select the browse button next to the Tag field.
    A context sensitive menu is displayed.
  5. Select the OPC Historic Tag option to display the Select Historic Tag window.
  6. Expand a Root Group folder. Each Root Group folder represents a system.
  7. Expand the group folders until you locate the item that has the required historic data. This is the item that has the historic data that you want to use as a value on your Ladder Diagram.
  8. Expand the item. A historic icon is shown.
  9. Select the historic icon. This will associate the variable tag with the historic data of the selected database item.
  10. Use the check box and combo boxes at the bottom of the Select Historic Tag window to define the time span and historic algorithm:
  • Relative—Use to determine whether a relative or absolute reference is used to reference the item's historic tag.
  • Check the check box to use a relative reference to the item's historic tag. The reference will work as long as the location of the selected database item remains the same in relation to the Ladder Diagram.
  • Clear the check box to use an absolute reference. The reference will only work when the selected database item remains in the current location.
  • Algorithm—Choose the type of historic calculation that ClearSCADA uses to process the historic data.
  • Start Date—Choose or enter the start time for the range of historic values. The Ladder Diagram can only use historic values that have been recorded after the selected date.

You can choose from the following default options or you can enter a start time:

  • M—The time period starts at the beginning of the current minute.
  • M-1M—The time period starts at the beginning of the previous minute.
  • H—The time period starts at the beginning of the current hour.
  • H-1H—The time period starts at the beginning of the previous hour.
  • D—The time period starts at the beginning of the current day.
  • D-1D—The time period starts at the beginning of the previous day.
  • W—The time period starts at the beginning of the current week.
  • W-1W—The time period starts at the beginning of the previous week.

To enter a start date, simply enter the time in the OPC format. For example, if you want the start date to be 3 weeks prior to the start of the current week, enter W-3W.

  • Interval—Enter or choose the duration of the time period. The Ladder Diagram will only use those historic values that were recorded after the start date and within the specified interval. For example, if the Start Date is H and the Interval is 30M, the time period is 30 minutes after the start of the current hour. Any historic values that were recorded for the item outside of this time period are disregarded.

As with the Start Date, you can choose from the list of default intervals, or you can enter your own interval in the OPC time format.

  11. Select the OK button to confirm your selection and close the Select Historic Tag window.
  12. On the Add Direct Variable window, use the Type combo box to choose the type of value for the historic variable. The type of value that you select has to be appropriate for the type of database item. For more information, see Built-In Data Types.
  13. Leave the Retained check box clear. The Retained feature is designed to be used with internal variables. When selected, it allows the internal variable to be stored and transferred to other servers (in a multi-server setup).

For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.

  14. Use the No Cache check box to determine whether the program uses the latest value or the initial value for a variable on each execution. If you check the No Cache check box, the program will use the latest value for the variable rather than the default value. If you clear the No Cache check box, the program will use the default value for the variable on each execution.

The No Cache feature is especially useful with variables that are used as counts. For more information on the No Cache feature, please refer to Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program.

  15. Select the OK button to confirm your selections and close the Add Direct Variable window.
  16. Select the historic variable in the Variables list (Direct tab) and keep the left-hand mouse button pressed down.
  17. Drag the historic variable from the Variables list onto the Ladder diagram.
    A context sensitive menu is displayed.
  18. Select the option that corresponds with the type of internal variable that you are adding to the Ladder diagram (see Ladder Diagram Components).
    A new contact or coil is added to the Ladder diagram, depending on the option you selected. The contact or coil represents the internal variable.


Logic Guide - Add a Constant Value to a Ladder Diagram (Ladder Diagrams)

Add a Constant Value to a Ladder Diagram

Constant values are values that remain the same each time the program executes, such as pi, time intervals, fixed text string etc. For example, if a program needs a point to change state after a 2 minute pause, a constant can be used to define the 2 minute time period. Although the time period does decrease from 120 seconds to 0 seconds as the program executes, it is still represented by a constant as the time value is 120 seconds when the program is executed.

To add a constant value to a Ladder Diagram:

  1. Right-click on the background of the Ladder diagram.
    A context sensitive menu is displayed.
  2. Select the Add Constant option.
    The Set Constant window is displayed.
  3. Enter the Constant value. The value needs to include any code characters. For more information, see Built-In Data Types.
  4. Select the OK button to confirm the entry and close the Set Constant window.
    A constant tag is added to the Ladder Diagram. Constant tags are colored blue, and can be connected to other parts of the diagram.

NOTE: Unlike internal and direct variables, constants can only be of a certain data type. Each constant value has to be one of the Built-In Data Types.


Logic Guide - Add a Function to a Ladder Diagram (Ladder Diagrams)

Add a Function to a Ladder Diagram

Functions are single calculations that can be applied to a value. Each function reads an input, performs a calculation, and outputs the result of the calculation as a value. There are many types of function (each function type performs a different type of calculation).

Functions are useful for converting values, adding values, etc.

To add a function to a Ladder Diagram:

  1. Right-click on the background of the Ladder Diagram.
    A context sensitive menu is displayed.
  2. Select the Functions option to display another menu.
  3. Select the option for the type of function that you want to add to the Ladder Diagram.
    A further menu is displayed.
  4. Select the function that you require.
    The function is added to the Ladder Diagram.

For more information on the available functions, see Built-In Functions.


Logic Guide - Add a Function Block to a Ladder Diagram (Ladder Diagrams)

Add a Function Block to a Ladder Diagram

Function blocks are blocks of code that define a type of Logic behavior or calculation. You can use them in your Ladder Diagrams to provide the Logic or calculations that you require in your program. There are several types of function block available, and you can also create custom function blocks if required.

To add a function block to a Ladder Diagram:

  1. Right-click on the background of the Ladder Diagram.
    A context sensitive menu is displayed.
  2. Select the Function Blocks option to display another menu.
  3. Select the option for the type of function block that you want to add to the Ladder Diagram.

    The function block is added to the Ladder Diagram.

For more information on the available function blocks, see Built-In Function Blocks.

NOTE: You can also add User Function Blocks to your Ladder Diagrams (see User Function Blocks).


Logic Guide - Add a Conversion to a Ladder Diagram (Ladder Diagrams)

Add a Conversion to a Ladder Diagram

Conversions are built-in features that convert the data type of one value into a different data type. For example, the BYTE_TO_BOOL conversion turns a byte value into a boolean value. Typically, the conversions are needed when an input value of one data type needs to be converted into another data type for the Logic program to work.

To add a conversion to a Ladder Diagram:

  1. Right-click on the background of the Ladder Diagram.
    A context sensitive menu is displayed.
  2. Select the Conversions option to display another menu.
  3. Select the option for the data type that you want to convert on the Ladder Diagram.
    A further menu is displayed    .
  4. Select the option that describes the type of conversion. For example, to convert a boolean value into a string value, select the BOOL_TO_STRING option.
    The conversion is added to the Ladder Diagram.

For more information on the data types, see Built-In Data Types.


Logic Guide - Add a Comment to a Ladder Diagram (Ladder Diagrams)

Add a Comment to a Ladder Diagram

When you are designing a Ladder Diagram, you can add comments that can be read by other users. You can use the comments to add any text, but typically they are used to explain the purpose of various parts of the Ladder Diagram.

To add a comment to a Ladder Diagram:

  1. Right-click on the background of the Ladder Diagram.
    A context sensitive menu is displayed.
  2. Select the Add Comment option to display the add comment window.
  3. Enter your comment.
  4. Select the OK button to confirm your entry and close the Add Comment window.
    The comment is added to the Ladder Diagram.

You can move the comment around on the Ladder Diagram in the same way as other items.

You can edit the comment by double-clicking on it—this will display the Edit Comment window which works in the same way as the Add Comment window.


Logic Guide - Controlling the Flow of a Ladder Diagram (Ladder Diagrams)

Controlling the Flow of a Ladder Diagram

When you have added the various conversions, functions, function blocks etc. that form your Ladder Diagram, you need to make connections. The connections define how the various components relate to one another.

When making connections, you may need to move items around the diagram. To do this, simply select the item, then drag it to the required location before releasing the left-hand mouse button.

For more information on connections, refer to:

  • Make a Connection on a Ladder Diagram
  • Add a Connection Block to a Ladder Diagram.


Logic Guide - Make a Connection on a Ladder Diagram (Ladder Diagrams)

Make a Connection on a Ladder Diagram

To make a connection on a Ladder Diagram:

  1. Select a connection box on one of the items you want to connect. Keep the left-hand mouse button pressed down.
  2. Drag the cursor to a connection box on the other item (the item to which you are connecting the item in step 1).
  3. Release the left-hand mouse button.
    A connection line is drawn (if the connection is valid).


Logic Guide - Add a Connection Block to a Ladder Diagram (Ladder Diagrams)

Add a Connection Block to a Ladder Diagram

You can use connection blocks to group multiple connection lines. The connection blocks work in a similar way to the OR function block—if any of the inputs from the connection block are true, the output of the connection block is true. Connection blocks are designed to reduce the clutter on your Logic diagrams.

To add a connection block to a Ladder Diagram:

  1. Right-click on the background of the diagram to display a context sensitive menu.
  2. Select the Add Connection Block option.
    A new connection block is added to the diagram.

You can connect single or multiple connection lines to the input and output connection boxes on the connection block. The system will group the lines automatically so that the diagram is clear and uncluttered.


Logic Guide - Edit a Variable on a Ladder Diagram (Ladder Diagrams)

Edit a Variable on a Ladder Diagram

You can edit any variable that you have added to your Ladder Diagram. This is useful when you have made a mistake or when you need to make a small adjustment to the program.

To edit a variable on a Ladder Diagram:

  1. In the Variables list above the Ladder Diagram, right-click on the variable you want to edit (on the Direct tab or Internal tab as appropriate).
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Edit Direct Variable window or Edit Internal Variable window is displayed, Depending on which type of variable you selected.
  3. Use the Edit Direct Variable window or Edit Internal Variable window to alter the settings for the variable. The settings work in the same way as on the Add Direct Variable window and the Add Internal Variable window (see Add Variables to a Ladder Diagram).


Logic Guide - Rename a Variable on a Ladder Diagram (Ladder Diagrams)

Rename a Variable on a Ladder Diagram

As you need to allocate a different name to each variable, you may need to rename the variables you have on your Ladder Diagram.

To rename a variable on a Ladder Diagram:

  1. In the Variables list above the Ladder Diagram, right-click on the variable you want to rename (on the Direct tab or Internal tab as appropriate).
    A context sensitive menu is displayed.
  2. Select the Rename option.
    The name of the variable is selected. You can alter or overwrite the name as required—simply use the keyboard to enter the new name for the variable.
  3. Press the Enter key or select another part of the interface to confirm the name entry.


Logic Guide - Delete a Variable on a Ladder Diagram (Ladder Diagrams)

Delete a Variable on a Ladder Diagram

You can use the Delete option to remove unwanted variables from your Ladder Diagram.

To delete a variable on a Ladder Diagram:

  1. In the Variables list above the Ladder Diagram, right-click on the variable you want to delete (on the Direct tab or Internal tab as appropriate).
    A context sensitive menu is displayed.
  2. Select the Delete option.
    A confirmation window is displayed.
  3. Select the OK button to confirm the deletion and close the confirmation window.
    The variable is removed from the Ladder Diagram.


Logic Guide - Compiling a Ladder Diagram (Ladder Diagrams)

Compiling a Ladder Diagram

You can use the Build menu options to compile your Ladder Diagram. The compilation feature is useful as it checks that your Ladder Diagram has the correct syntax.

There are 2 compile options:

  • Compile—Compiles the diagram. If the program is invalid, the compiler display provides a message with a brief explanation of any syntax errors. If the syntax is correct, the compiler displays a success message.
  • Compile with Diagnostics—Compiles the Ladder Diagram and provides detailed diagnostic information. As with the Compile option, there are messages for any errors in the syntax. If the syntax is correct, the compiler displays a success message.

NOTE: The Compile with Diagnostics tool is useful when you want to use a Ladder Diagram as an ST programs. For example, you may find it easier to create a Ladder Diagram and then use the Compile with Diagnostics tool to access the ST code for the Ladder Diagram. You can then copy this code into an ST program (you have to remove the $ signs in the code).

To compile a Ladder Diagram:

  1. Display the Ladder Diagram in Design mode.
  2. Select the Build menu, then select the Compile option or the Compile with Diagnostics option as required.
    The Ladder Diagram is compiled and the compile messages are shown in the Compiler display.
    Compiler display

If there are errors, you will need to alter the Ladder Diagram. Typically, the causes of invalid syntax are minor, such as the wrong type of value being specified or a missing connection.


Logic Guide - Viewing the Variables in your Ladder Diagram (Ladder Diagrams)

Viewing the Variables in your Ladder Diagram

When you display a Ladder Diagram in Run mode, you can view a list of the variables it uses. The list shows the current values for the variables. The variables window is useful as it allows you to view the variables that are produced by part of the diagram.

To display the variables window:

  1. Display the Ladder Diagram in Run mode (right-click on it in the Database Bar then select the Display option).
  2. Select the Run menu, then select the Variables option.
    The variables window is displayed.

The variables window contains expandible lists of the variables in your Ladder Diagram. For each variable, it lists the Name of the variable, the Type (which shows the data type), and the Value (which shows the current value of the variable).


Logic Guide - Changing the Update Interval for a Ladder Diagram (Ladder Diagrams)

Changing the Update Interval for a Ladder Diagram

You can use the Update Interval feature to define how often your ClearSCADA client PC requests updates for a Ladder Diagram. By default, ClearSCADA clients request an update from a ClearSCADA server for the latest variable values every second.

By using the Update Interval feature, you can set your ClearSCADA client PC to request variable updates at a slower rate.

To change the update interval for a Ladder Diagram:

  1. Display the Ladder Diagram in Run mode (right-click on it in the Database Bar then select the Display option).
  2. Select the Run menu, then select the Update Interval option.
    A further menu is displayed.
  3. Select the required interval from the list of options. The intervals range from 1 second to 60 seconds.


Logic Guide - Function Block Diagrams

Function Block Diagrams

Function Block Diagrams are graphical programs that allow you to define a series of processes that are dependent on a flow. The flow of a signal from one function block to another means that you can create complex relationships between values, functions etc. to define the Logic behavior of your program.

To familiarize yourself with the concepts and features for Function Block Diagrams, refer to these sections:

  • How Function Block Diagrams Work
  • Function Block Diagram Components
  • Create a Function Block Diagram Database Item
  • Edit a Function Block Diagram
  • Function Block Diagram Display
  • Add Variables to a Function Block Diagram
  • Add Processed Historic Values to Function Block Diagrams
  • Add a Constant Value to a Function Block Diagram
  • Add a Function to a Function Block Diagram
  • Add a Function to a Function Block Diagram
  • Add a Conversion to a Function Block Diagram
  • Add a Comment to a Function Block Diagram
  • Create a Ladder Diagram within a Function Block Diagram
  • Controlling the Flow of a Function Block Diagram
  • Edit a Variable on a Function Block Diagram
  • Rename a Variable on a Function Block Diagram
  • Delete a Variable on a Function Block Diagram
  • Compiling a Function Block Diagram or Function Block Library
  • Viewing the Variables in your Function Block Diagram
  • Changing the Update Interval for a Function Block Diagram
  • Viewing the Values on a Function Block Diagram.

For information on the properties of the Function Block Diagram database items, see Logic Program Properties and Values.


Logic Guide - How Function Block Diagrams Work (Function Block Diagrams)

How Function Block Diagrams Work

Function Block Diagrams have inputs and outputs, and also contain functions, function blocks, conversions etc. Each Function Block Diagram uses its functions, function blocks etc. to determine outputs based on the values for its inputs.

By creating connections between the various function block components, you can create complex behavior Logic. For example, the following Function Block Diagram is used to control a pump in the water industry:

In this example, the states of the four input points (StartPump, StopPump, ResetLockOut, and FlowPresent) are used to determine whether the pump starts, stops, or is reset. The connections between the various functions and function blocks define the behavior that is provided by the Function Block Diagram:

  • If the StartPump input is true, the pump will start (PumpStart output is true) as long as the FlowPresent value is true and the pump is not locked out (LockedOut value is false).
  • If the pump is locked out (LockedOut value is true), the PumpStart output will not change in response to the StartPump or StopPump inputs—it will only change after the ResetLockOut input has become true and the LockedOut output is false.
  • The PumpState output can only be true if the StartPump input is true, and the FlowPresent input is true, and the LockedOut output is false. This means that the pump will only be switched on when
  • it has a start signal
  • can detect a flow
  • is not locked out

There is a time delay between the StartPump and StopPump signals affecting the state of the PumpState output. This means that fleeting state changes will not affect the outputs.


Logic Guide - Function Block Diagram Components (Function Block Diagrams)

Function Block Diagram Components

Function Block Diagrams can consist of the following items:

  • Ladder Diagram components such as rails—see Create a Ladder Diagram within a Function Block Diagram.
  • Connection Boxes—see Add a Connection Block to a Function Block Diagram.
  • Built-in Function Blocks—see Add a Function Block to a Function Block Diagram.
  • Built-in Functions—see Add a Function to a Function Block Diagram.
  • Constants—see Add a Constant Value to a Function Block Diagram.
  • Conversions—see Add a Conversion to a Function Block Diagram.
  • Direct Variables—see Add Variables to a Function Block Diagram.
  • Internal Variables—see Add Variables to a Function Block Diagram.
  • User Function Blocks—see User Function Blocks.

The various components of a Function Block Diagram are connected via connection lines, which you can draw to link the connection box of one component to a connection box on another component. These connections allow you to control the flow of the Function Block Diagram (see Edit a Variable on a Function Block Diagram).


Logic Guide - Create a Function Block Diagram Database Item (Function Block Diagrams)

Create a Function Block Diagram Database Item

Each Function Block Diagram needs to be represented in the ClearSCADA database by a Function Block Diagram item. When you have created a Function Block Diagram item, you can access its Edit feature which allows you to create the Function Block Diagram program.

To create a Function Block Diagram database item:

  1. In the Database Bar, right-click on a system, Group, or Group Template to display a context sensitive menu.
  2. Select the New option, then the Logic option, then the Function Block Diagram option from the context sensitive menu.
    A new Function Block Diagram item is added to the system, Group, or Group Template. It is selected automatically, ready for you to enter its name.
  3. Enter a suitable name for the Function Block Diagram then press the Enter key or select another part of the interface.
    Function Block Diagram database item (shown in a Group).

Now that you have created a Function Block Diagram database item, you can edit it (see Edit a Function Block Diagram).


Logic Guide - Edit a Function Block Diagram (Function Block Diagrams)

Edit a Function Block Diagram

You can display a Function Block Diagram in Design mode by double-clicking on a Function Block Diagram item in the Database Bar. In Design mode, you can edit the Function Block Diagram by adding or removing values and components such as functions.

To edit a Function Block Diagram, either:

  • Double-click on a Function Block Diagram item in the Database Bar.

Or:

  • Right-click on a Function Block Diagram item in the Database Bar, then select the Edit option from the context sensitive menu.

The Function Block Diagram is displayed in the ViewX Application window (see Function Block Diagram Display).


Logic Guide - Function Block Diagram Display (Function Block Diagrams)

Function Block Diagram Display

When you double-click on a Function Block Diagram item or select its Edit option, the Function Block Diagram display is shown.

The Function Block Diagram display consists of:

Database Bar. You can drag items such as points from the Database Bar onto the Function Block Diagram.
Direct and Internal Variables. These tabs contain lists of the properties and values that are included in the Function Block Diagram.
The Function Block Diagram.
You can design the Function Block Diagram by adding values, functions, etc.
The compiler display. Compiling and debugging information is shown here.

  • Database Bar—The Database Bar contains a hierarchical view of the ClearSCADA database. You can drag an item from the Database Bar onto the Function Block Diagram to create a variable for the item.
  • Direct and Internal Variables—The variables tabs contain a list of the values that are included in the Function Block Diagram. The Direct tab contains the values that are associated with database items, and the Internal tab contains a list of internal variables such as function blocks.
  • Function Block Diagram—The Function Block Diagram contains the functions, function blocks, variables, constants, etc. form the Function Block Diagram. This is where you create the Logic of the Function Block Diagram.
  • Compiler Display—The compiler display is where ClearSCADA displays diagnostic information for your Function Block Diagram. Messages associated with compiling and debugging are shown here.


Logic Guide - Add Variables to a Function Block Diagram (Function Block Diagrams)

Add Variables to a Function Block Diagram

Each value that is read or written by your Function Block Diagram is represented by a variable or a constant. Constant values are values that are fixed and are described in Add a Constant Value to a Function Block Diagram. Variable values change according to the data that is stored in your system and the calculations that are performed on it.

There are 2 types of variable:

  • Internal variables are values that are used by the program but are not written to an item in the database. For example, values that are used in a conversion.
  • Direct variables are values that are stored in the database, for example, a point value.

The following sections explain how to add variables to your Function Block Diagram:

  • Add a Direct Variable to a Function Block Diagram
  • Add an Internal Variable to a Function Block Diagram.


Logic Guide - Add a Direct Variable to a Function Block Diagram (Function Block Diagrams)

Add a Direct Variable to a Function Block Diagram

The method that you use to add a direct variable to your Function Block Diagram will vary depending on whether the diagram already contains an instance of the value.

If your diagram does not already contain an instance of the direct variable that you want to add, refer to Add the First Instance of a Direct Variable to a Function Block Diagram.

If your diagram already contains an instance of the direct variable that you want to add, refer to Add Another Instance of a Direct Variable to a Function Block Diagram.

Add the First Instance of a Direct Variable to a Function Block Diagram

To add the first or only instance of a direct variable to a Function Block Diagram:

  1. In the Database Bar, select the database item that represents the direct variable that you want to add to the Function Block Diagram. For example, if you want to add the value of a point named 'INT 1', select the 'INT 1' point item. When you select the item, keep the left-hand mouse button pressed down.
  2. With the left-hand mouse button still pressed down, drag the item onto the Function Block Diagram display.
    The Add Direct Variable window is displayed.
  3. Use the Add Direct Variable window to define the settings for the direct variable:
  • Name—Enter the name for the direct variable. This name will be used to refer to the variable within the program. A name is entered automatically when you drag a direct variable onto the Function Block Diagram, but you can change it as required.
  • Tag Type—Choose the type of direct variable tag. This can be:
  • Read/Write (%M)—The Function Block Diagram can both read the value and overwrite it with a new value.
  • Read Only (%I)—The Function Block Diagram can only read the value and cannot change it.
  • Write Only (%Q)—The Function Block Diagram cannot read the variable but can write a new value to it.
  • Tag—This is the name of the OPC property that represents the variable that you want to add to the Function Block Diagram. The tag can be an OPC tag (for normal, direct variable values) or an OPC Historic tag (see Add Processed Historic Values to Function Block Diagrams).
  • Type—Choose the type of value. The value type needs to be appropriate to the value that is represented by the selected tag. For more information, please refer to Built-In Data Types.
  • Insert—Choose the type of variable tag that you are adding to the Function Block Diagram. Choose the required type of variable from the combo box (see Function Block Diagram Components).
  • Retained—The Retained feature is designed to be used with internal variables. When selected, it allows the internal variable to be stored and transferred to other servers (in a multi-server setup).

For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.

  • No Cache—Use the No Cache check box to determine whether the program uses the latest value or the initial value for a variable on each execution. If you check the No Cache check box, the program will use the latest value for the variable rather than the default value. If you clear the No Cache check box, the program will use the default value for the variable on each execution.

The No Cache feature is especially useful with variables that are used as counts. For more information on the No Cache feature, please refer to Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program.

  4. Select the OK button to confirm.
    A direct variable tag is added to the Function Block Diagram. You can then draw connections to or from it (see Controlling the Flow of a Function Block Diagram).

If you need to add another instance of the direct variable to your Function Block Diagram, see Add Another Instance of a Direct Variable to a Function Block Diagram.

Add Another Instance of a Direct Variable to a Function Block Diagram

You need to use the Variables list to add multiple instances of the same direct variable to a Function Block Diagram. You can add the first instance of the direct variable by dragging the corresponding database item from the Database Bar onto the Function Block Diagram and then configuring the variable settings. For subsequent instances of the direct variable, you need to use the Add option that is available from the Direct tab of the Variables list:

  1. In the Variables list (above the Function Block Diagram Display), select the Direct tab.
    A list of the Ladder Diagram's direct variables is shown.
  2. Right-click on the direct variable that you want to use again.
    A context sensitive menu is displayed.
  3. Select the Add option.
    The Add Direct Variable window is displayed.
  4. Use the Add Direct Variable window to define the new instance of the variable:
  • Enter a Name for the direct variable. The name has to be unique. It cannot have the same name as any variables that are already included in the Function Block Diagram.
  • Use the Tag Type combo box to define whether the variable is Read Only, Write Only, or Read/Write.
  • Use the browse button feature of the Tag field to select the database property that is the source of the variable's value. The tag can be an OPC tag (for normal, direct variable values) or an OPC Historic tag (see Add Processed Historic Values to Function Block Diagrams).
  • Use the Type combo box to choose the type of value. The value type needs to be appropriate to the value that is represented by the selected tag. For more information, please refer to Built-In Data Types.
  • The Retained feature is designed to be used with internal variables. When selected, it allows the internal variable to be stored and transferred to other servers (in a multi-server setup).

For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.

  • Use the No Cache check box to determine whether the program uses the latest value or the initial value for a variable on each execution. If you check the No Cache check box, the program will use the latest value for the variable rather than the default value. If you clear the No Cache check box, the program will use the default value for the variable on each execution.

The No Cache feature is especially useful with variables that are used as counts. For more information on the No Cache feature, please refer to Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program.

  5. Select the OK button to confirm your selection.
    The Add Direct Variable window is closed.
  6. Select the new variable in the Variables list. Keep the left-hand mouse button pressed down.
  7. Drag the new variable from the Variables list onto the Function Block Diagram.
    A context sensitive menu is displayed.
  8. Select the option that corresponds with the type of variable that you are adding to the Function Block Diagram (see Function Block Diagram Components).
    A new variable is added to the Function Block Diagram, depending on the option you selected.


Logic Guide - Add an Internal Variable to a Function Block Diagram (Function Block Diagrams)

Add an Internal Variable to a Function Block Diagram

Internal variables are values that are used by the program but are not written to an item in the database. They are used for:

  • Conversions
  • Separating long, complex calculations into smaller sets of calculations
  • Storing program states.

To add an internal variable to a Function Block Diagram:

  1. On the Function Block Diagram display, select the Internal tab on the Variables list.
  2. Right-click in an empty row on the Variables list to display a context sensitive menu.
  3. Select the Add option to display the Add Internal Variable window.
  4. Use the Add Internal Variable window to define the settings for the internal variable:
  • Enter a Name for the direct variable. The name has to be unique. It cannot have the same name as any variables that are already included in the Function Block Diagram.
  • Use the Type combo box to choose the type of value. The value type needs to be appropriate to the internal variable. For more information, please refer to Built-In Data Types.
  • In the Initial Value field, enter the default value for the internal variable. This is the first value of the internal variable. The internal variable will reset to this value for each execution of the Ladder Diagram executes unless the Retained feature is used (see below).
  • Use the Retained check box to determine whether the internal variable is stored and transferred to other servers. For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.
  • Check the Retained check box to allows the internal variable to be stored and transferred to other servers (in a multi-server setup).
  • Clear the Retained check box to prevent the internal variable from being stored and transferred to other servers. This will result in the internal variable being reset to its initial value each time the Function Block Diagram executes.
  5. Select the OK button to confirm the settings and close the Add Internal Variable window.
  6. Select the internal variable in the Variables list. Keep the left-hand mouse button pressed down.
  7. Drag the internal variable from the Variables list onto the Function Block Diagram.
    A context sensitive menu is displayed.
  8. Select the option that corresponds with the type of internal variable that you are adding to the Function Block Diagram (see Function Block Diagram Components).
    A new variable item is added to the Function Block Diagram.


Logic Guide - Add Processed Historic Values to Function Block Diagrams (Function Block Diagrams)

Add Processed Historic Values to Function Block Diagrams

You can add processed historic values (historic values that have been calculated using a historic algorithm) to your Function Block Diagrams. This may be useful if you need to use a daily average or some other calculated value as part of the Function Block Diagram Logic.

To add a processed historic value to a Function Block Diagram:

  1. Display the Add Direct Variable window by performing one of these procedures:

Either:

  1. In the Variables list (above the Function Block Diagram display), select the Direct tab.
    A list of the Function Block Diagram's direct variables is shown.
  2. Right-click on the direct variable that you want to use again.
    A context sensitive menu is displayed.
  3. Select the Add option.
    The Add Direct Variable window is displayed.

Or:

  1. In the Variables list (above the Function Block Diagram display), select the Direct tab.
    A list of the Function Block Diagram's direct variables is shown.
  2. Right-click on the direct variable that you want to use again.
    A context sensitive menu is displayed.
  3. Select the Add option.
    The Add Direct Variable window is displayed.
  2. In the Name field, enter a suitable name for the variable.
  3. Use the Tag Type combo box to define whether the variable is Read Only, Write Only, or Read/Write.
  4. Select the browse button next to the Tag field.
    A context sensitive menu is displayed.
  5. Select the OPC Historic Tag option to display the Select Historic Tag window.
  6. Expand a Root Group folder. Each Root Group folder represents a system.
  7. Expand the group folders until you locate the item that has the required historic data. This is the item that has the historic data that you want to use as a value on your Function Block Diagram.
  8. Expand the item. A historic icon is shown.
  9. Select the historic icon. This will associate the variable tag with the historic data of the selected database item.
  10. Use the check box and combo boxes at the bottom of the Select Historic Tag window to define the time span and algorithm:
  • Relative—Use to determine whether a relative or absolute reference is used to reference the item's historic tag.
  • Check the check box to use a relative reference to the item's historic tag. The reference will work as long as the location of the selected database item remains the same in relation to the Function Block Diagram.
  • Clear the check box to use an absolute reference. The reference will only work when the selected database item remains in the current location.
  • Algorithm—Choose the type of historic algorithm that ClearSCADA uses to process the historic data .
  • Start Date—Choose or enter the start time for the range of historic values. The Function Block Diagram can only use historic values that have been recorded after the selected date.

You can choose from the following default options or you can enter a start time:

  • M—The time period starts at the beginning of the current minute.
  • M-1M—The time period starts at the beginning of the previous minute.
  • H—The time period starts at the beginning of the current hour.
  • H-1H—The time period starts at the beginning of the previous hour.
  • D—The time period starts at the beginning of the current day.
  • D-1D—The time period starts at the beginning of the previous day.
  • W—The time period starts at the beginning of the current week.
  • W-1W—The time period starts at the beginning of the previous week.

To enter a start date, simply enter the time in the OPC format. For example, if you want the start date to be 3 weeks prior to the start of the current week, enter W-3W.

  • Interval—Enter or choose the duration of the time period. The Function Block Diagram will only use those historic values that were recorded after the start date and within the specified interval. For example, if the Start Date is H and the Interval is 30M, the time period is 30 minutes after the start of the current hour. Any historic values that were recorded for the item outside of this time period are disregarded.

As with the Start Date, you can choose from the list of default intervals, or you can enter your own interval in the OPC time format.

  11. Select the OK button to confirm your selection and close the Select Historic Tag window.
  12. On the Add Direct Variable window, use the Type combo box to choose the type of value for the historic variable. The type of value that you select has to be appropriate for the type of database item. For more information, see Built-In Data Types.
  13. Leave the Retained check box clear. The Retained feature is designed to be used with internal variables. When selected, it allows the internal variable to be stored and transferred to other servers (in a multi-server setup).

For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.

  14. Use the No Cache check box to determine whether the program uses the latest value or the initial value for a variable on each execution. If you check the No Cache check box, the program will use the latest value for the variable rather than the default value. If you clear the No Cache check box, the program will use the default value for the variable on each execution.

The No Cache feature is especially useful with variables that are used as counts. For more information on the No Cache feature, please refer to Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program.

  15. Select the OK button to confirm your selections and close the Add Direct Variable window.
  16. Select the historic variable in the Variables list (Direct tab). Keep the left-hand mouse button pressed down.
  17. Drag the historic variable from the Variables list onto the Function Block Diagram.
    A context sensitive menu is displayed.
  18. Select the option that corresponds with the type of internal variable that you are adding to the Function Block Diagram (see Function Block Diagram Components).
    A new variable is added to the Function Block Diagram.


Logic Guide - Add Raw Historic Values to Function Block Diagrams (Function Block Diagrams)

Add Raw Historic Values to Function Block Diagrams

To use raw historic values in Function Block Diagrams, you will need to have an appreciation of how historic values are used in ST programs (see Add Raw Historic Values to Function Block Diagrams).

When you add a raw historic value to a Function Block Diagram, you need to enter its function and arguments as part of the variable tag:

  1. Edit your Function Block Diagram (see Edit an ST Program).
  2. In the Database Bar, select the point that has historic data that is to be used in your Function Block Diagram.
  3. Drag the point onto the Function Block Diagram to display the Add Variable window.
  4. In the Tag field, add the following after the path of the point:
Historic.<historic function> (<arguments required by function>)

Where <historic function> is the name of the historic function that you need to use, and <arguments required by function> are the times and values needed by the historic function. For example:

Analog Input.Historic.RawValue ('D-1H', 'H+1H', 0, TRUE)

You have to enter this information manually—it cannot be selected from a browse list.

  5. Define the other settings for the variable (see Add Variables to a Function Block Diagram).
  6. Select the OK button to confirm.

Further Information

Historic Functions and Arguments.


Logic Guide - Add a Constant Value to a Function Block Diagram (Function Block Diagrams)

Add a Constant Value to a Function Block Diagram

Constant values are values that remain the same each time the program executes, such as pi, time intervals, fixed text string etc. For example, if a program needs a point to change state after a 2 minute pause, a constant can be used to define the 2 minute time period. Although the time period does decrease from 120 seconds to 0 seconds as the program executes, it is still represented by a constant as the time value is 120 seconds when the program is executed.

To add a constant value to a Function Block Diagram:

  1. Right-click on the background of the Function Block Diagram.
    A context sensitive menu is displayed.
  2. Select the Add Constant option.
    The Set Constant window is displayed.
  3. Enter the Constant value. The value needs to include any code characters. For more information, see Built-In Data Types.
  4. Select the OK button to confirm the entry and close the Set Constant window.
    A constant tag is added to the Function Block Diagram. Constant tags are colored blue, and can be connected to other parts of the diagram.

NOTE: Unlike internal and direct variables, constants can only be of a certain data type. Each constant value has to be one of the Built-In Data Types.


Logic Guide - Add a Function to a Function Block Diagram (Function Block Diagrams)

Add a Function to a Function Block Diagram

Functions are single calculations that can be applied to a value. Each function reads an input, performs a calculation, and outputs the result of the calculation as a value. There are many types of function (each function type performs a different type of calculation).

Functions are useful for converting values, adding values, etc.

To add a function to a Function Block Diagram:

  1. Right-click on the background of the Function Block Diagram.
    A context sensitive menu is displayed.
  2. Select the Functions option to display another menu.
  3. Select the option for the type of function that you want to add to the Function Block Diagram.
    A further menu is displayed.
  4. Select the function that you require.
    The function is added to the Function Block Diagram.

For more information on the available functions, see Built-In Functions.


Logic Guide - Add a Function Block to a Function Block Diagram (Function Block Diagrams)

Add a Function Block to a Function Block Diagram

Function blocks are blocks of code that define a type of Logic behavior or calculation. You can use them in your Function Block Diagrams to provide the Logic or calculations that you require in your program. There are several types of function block available, and you can also create custom function blocks if required.

To add a function block to a Function Block Diagram:

  1. Right-click on the background of the Function Block Diagram.
    A context sensitive menu is displayed.
  2. Select the Function Blocks option to display another menu.
  3. Select the option for the type of function block that you want to add to the diagram.

    The function block is added to the Function Block Diagram.

For more information on the available function blocks, see Built-In Function Blocks.


Logic Guide - Add a Conversion to a Function Block Diagram (Function Block Diagrams)

Add a Conversion to a Function Block Diagram

Conversions are built-in features that convert the data type of one value into a different data type. For example, the BYTE_TO_BOOL conversion turns a byte value into a boolean value. Typically, the conversions are needed when an input value of one data type needs to be converted into another data type for the Logic program to work.

To add a conversion to a Function Block Diagram:

  1. Right-click on the background of the Function Block Diagram.
    A context sensitive menu is displayed.
  2. Select the Conversions option to display another menu.
  3. Select the option for the data type that you want to convert on the Function Block Diagram.
    A further menu is displayed    .
  4. Select the option that describes the type of conversion. For example, to convert a boolean value into a string value, select the BOOL_TO_STRING option.
    The conversion is added to the Function Block Diagram.

For more information on the data types, see Built-In Data Types.


Logic Guide - Add a Comment to a Function Block Diagram (Function Block Diagrams)

Add a Comment to a Function Block Diagram

When you are designing a Function Block Diagram, you can add comments that can be read by other users. You can use the comments to add any text, but typically they are used to explain the purpose of various parts of the diagram.

To add a comment to a Function Block Diagram:

  1. Right-click on the background of the Function Block Diagram.
    A context sensitive menu is displayed.
  2. Select the Add Comment option to display the add comment window.
  3. Enter your comment.
  4. Select the OK button to confirm your entry and close the Add Comment window.
    The comment is added to the Function Block Diagram.

You can move the comment around on the Function Block Diagram in the same way as other items.

You can edit the comment by double-clicking on it—this will display the Edit Comment window which works in the same way as the Add Comment window.


Logic Guide - Create a Ladder Diagram within a Function Block Diagram (Function Block Diagrams)

Create a Ladder Diagram within a Function Block Diagram

ClearSCADA allows you to use Ladder Diagrams within Function Block Diagrams. This is useful as it allows you to create Logic sequences that are more appropriate to Ladder Logic and connect them to the Logic in a Function Block Diagram.

Before you create a Ladder Diagram in a Function Block Diagram, you should familiarize yourself with the concepts and design of Ladder Logic (see Ladder Diagrams).

To create a Ladder Diagram in a Function Block Diagram:

  1. Right-click on the background of the Function Block Diagram.
    A context sensitive menu is displayed.
  2. Select one of these options:
  • Add Left Power Rail—Adds a left power rail to the diagram. The left power rail is the source of the values (i.e. needs to be connected to inputs).
  • Add Right Power Rail—Adds a right power rail to the diagram. The right power rail is the result of the Ladder Diagram (i.e. needs to be connected to outputs).

The rail is added to the diagram.

You can add coils and contacts to the diagram and connect them to the rails. This is done in exactly the same way as when you add contacts and coils to a Ladder Diagram.

You can then connect the rails to other Logic components in your Function Block Diagram. Connect the rails via the connection boxes on the outside of the rails:

Connect right-hand rails to your Function Block Diagram via this connection box.
Connect left-hand rails to your Function Block Diagram via this connection box.


Logic Guide - Controlling the Flow of a Function Block Diagram (Function Block Diagrams)

Controlling the Flow of a Function Block Diagram

When you have added the various conversions, functions, function blocks etc. that form your Function Block Diagram, you need to make connections. The connections define how the various components relate to one another.

When making connections, you may need to move items around the diagram. To do this, simply select the item, then drag it to the required location before releasing the left-hand mouse button.

For more information on connections, refer to:

  • Make a Connection on a Function Block Diagram
  • Add a Connection Block to a Function Block Diagram.


Logic Guide - Make a Connection on a Function Block Diagram (Function Block Diagrams)

Make a Connection on a Function Block Diagram

To make a connection on a Function Block Diagram:

  1. Select a connection box on one of the items you want to connect. Keep the left-hand mouse button pressed down.
  2. Drag the cursor to a connection box on the other item (the item to which you are connecting the item in step 1).
  3. Release the left-hand mouse button.
    A connection line is drawn (if the connection is valid).

If the connection lines on your Function Block Diagram are cluttered and overlap, you can reposition them manually. To do this, simply double-click on the line you want to reposition. This will cause a new connection box to appear on the line. You can then drag the selection box to a different, more appropriate position as required.

Double-click on a connection line to add a connection box. You can then drag the connection box to reposition the entire line. You can add further connection boxes by double-clicking on the line between any of the existing connection boxes.


Logic Guide - Add a Connection Block to a Function Block Diagram (Function Block Diagrams)

Add a Connection Block to a Function Block Diagram

You can use connection blocks to group multiple connection lines. The connection blocks work in a similar way to the OR function block—if any of the inputs from the connection block are true, the output of the connection block is true. Connection blocks are designed to reduce the clutter on your Logic diagrams.

To add a connection block to a Function Block Diagram:

  1. Right-click on the background of the diagram to display a context sensitive menu.
  2. Select the Add Connection Block option.
    A new connection block is added to the diagram.

You can connect single or multiple connection lines to the input and output connection boxes on the connection block. The system will group the lines automatically so that the lines are clear and the diagram is uncluttered.


Logic Guide - Edit a Variable on a Function Block Diagram (Function Block Diagrams)

Edit a Variable on a Function Block Diagram

You can edit any variable that you have added to your Function Block Diagram. This is useful when you have made a mistake or when you need to make a small adjustment to the program.

To edit a variable on a Function Block Diagram:

  1. In the Variables list above the diagram, right-click on the variable you want to edit (on the Direct tab or Internal tab as appropriate).
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Edit Direct Variable window or Edit Internal Variable window is displayed, Depending on which type of variable you selected.
  3. Use the Edit Direct Variable window or Edit Internal Variable window to alter the settings for the variable. The settings work in the same way as on the Add Direct Variable window and the Add Internal Variable window (see Add Variables to a Function Block Diagram).


Logic Guide - Rename a Variable on a Function Block Diagram (Function Block Diagrams)

Rename a Variable on a Function Block Diagram

As you need to allocate a different name to each variable, you may need to rename the variables you have on your Function Block Diagram.

To rename a variable on a Function Block Diagram:

  1. In the Variables list above the diagram, right-click on the variable you want to rename (on the Direct tab or Internal tab as appropriate).
    A context sensitive menu is displayed.
  2. Select the Rename option.
    The name of the variable is selected. You can alter or overwrite the name as required—simply use the keyboard to enter the new name for the variable.
  3. Press the Enter key or select another part of the interface to confirm the name entry.


Logic Guide - Delete a Variable on a Function Block Diagram (Function Block Diagrams)

Delete a Variable on a Function Block Diagram

You can use the Delete option to remove unwanted variables from your Function Block Diagram.

To delete a variable on a diagram:

  1. In the Variables list above the diagram, right-click on the variable you want to delete (on the Direct tab or Internal tab as appropriate).
    A context sensitive menu is displayed.
  2. Select the Delete option.
    A confirmation window is displayed.
  3. Select the OK button to confirm the deletion and close the confirmation window.
    The variable is removed from the diagram.


Logic Guide - Compiling a Function Block Diagram or Function Block Library (Function Block Diagrams)

Compiling a Function Block Diagram or Function Block Library

You can use the Build menu options to compile your Function Block Diagram or Function Block Library (see User Function Blocks). The compilation feature is useful as it checks that your Function Block Diagram has the correct syntax.

There are 2 compile options:

  • Compile—Compiles the diagram. If the diagram is invalid, the compiler display provides a message that describes the reason for the syntax error. If the syntax is correct, the compiler displays a success message.
  • Compile with Diagnostics—Compiles the Function Block Diagram and provides detailed diagnostic information. As with the Compile option, there are messages for any errors in the syntax. If the syntax is correct, the compiler displays a success message.

NOTE: The Compile with Diagnostics tool is useful when you want to use a Function Block Diagram to form the basis of an ST program. For example, you may find it easier to create a Function Block Diagram and then use the Compile with Diagnostics tool to access the ST code for the diagram. You can then copy this code into an ST program (you have to remove the $ signs in the code).

To compile a Function Block Diagram:

  1. Display the Function Block Diagram or Function Block Library in Design mode.
  2. Select the Build menu, then select the Compile option or the Compile with Diagnostics option as required.
    The Function Block Diagram is compiled and the compile messages are shown in the Compiler display.
    Compiler display

If the program is invalid, you will need to alter the Function Block Diagram. Typically, the causes of syntax errors are minor, such as the wrong type of value being specified or a missing connection.


Logic Guide - Viewing the Variables in your Function Block Diagram (Function Block Diagrams)

Viewing the Variables in your Function Block Diagram

When you display a Function Block Diagram in Run mode, you can view a list of the variables it uses. The list shows the current values for the variables. The variables window is useful as it allows you to view the variables that are produced by part of the diagram.

To display the variables window:

  1. Display the Function Block Diagram in Run mode (right-click on it in the Database Bar then select the Display option).
  2. Select the Run menu, then select the Variables option.
    The variables window is displayed.

The variables window contains expandible lists of the variables in your Function Block Diagram. For each variable, it lists the Name of the variable, the Type (which shows the data type), and the Value (which shows the current value of the variable).


Logic Guide - Changing the Update Interval for a Function Block Diagram (Function Block Diagrams)

Changing the Update Interval for a Function Block Diagram

You can use the Update Interval feature to define how often your ClearSCADA client PC requests updates for a Function Block Diagram. By default, ClearSCADA clients request an update from a ClearSCADA server for the latest variable values every second.

By using the Update Interval feature, you can set your ClearSCADA client PC to request variable updates at a slower rate.

To change the update interval for a Function Block Diagram:

  1. Display the Function Block Diagram in Run mode (right-click on it in the Database Bar then select the Display option).
  2. Select the Run menu, then select the Update Interval option.
    A further menu is displayed.
  3. Select the required interval from the list of options. The intervals range from 1 second to 60 seconds.


Logic Guide - Viewing the Values on a Function Block Diagram (Function Block Diagrams)

Viewing the Values on a Function Block Diagram

When you display a Function Block Diagram in Run mode, you can view the values at each stage of the diagram. To display the value at a chosen stage, simply double-click on the connection line for the value in which you are interested—the value is shown in a green box. For example, if you were interested in the value that is coming from an input variable, just double-click on the connection line between the input variable and the Logic item to which it connects.

Double-click on the connection line to display the value at this stage of the Function Block Diagram.

Alternatively, you can right-click on the connection line and select the Display Value option to display the value.

NOTE: You can only display the values when the Function Block Diagram is displayed in Run mode.


Logic Guide - Sequential Function Charts

Sequential Function Charts

Sequential Function Charts represent a sequence of Logic. They allow you to create a Logic program that defines system behavior that occurs in steps, depending on specified conditions.

One of the main advantages of Sequential Function Charts (SFCs) is that only the active parts of the SFCs are executed, and you can easily see which parts are inactive. This means it is easy to determine what condition caused a step to occur.

The following sections explain the basic concepts of Sequential Function Charts and explain how to set up an SFC:

  • Sequential Function Chart Components
  • How Sequential Function Charts Work
  • Simultaneous Sequences
  • Create a Sequential Function Chart Database Item
  • Display a Sequential Function Chart
  • Add Direct and Internal Variables to a Sequential Function Chart
  • Add a Step to a Sequential Function Chart
  • Define a Step as the First Step in a Sequential Function Chart
  • Add a Transition to a Sequential Function Chart
  • Edit a Transition
  • Display the Actions Window on a Sequential Function Chart
  • Add an Action to a Sequential Function Chart
  • Edit an Action on a Sequential Function Chart
  • Edit an Action Association
  • Add a Comment to a Sequential Function Chart
  • Edit a Comment on a Sequential Function Chart
  • Add a Method Variable to a Sequential Function Chart
  • Initiate a Method on a Sequential Function Chart
  • Insert a Breakpoint on a Step in a Sequential Function Chart
  • Delete Sequential Function Chart Components
  • Rename Sequential Function Chart Components
  • Compiling a Sequential Function Chart
  • Viewing the Variables in your Sequential Function Chart
  • Changing the Update Interval for a Sequential Function Chart.

For information on the properties of the Sequential Function Chart database items, see Logic Program Properties and Values.


Logic Guide - Sequential Function Chart Components (Sequential Function Charts)

Sequential Function Chart Components

Sequential Function Charts represent a sequence of Logic. The sequence consists of a collection of the following components:

  • Steps
  • Transitions
  • Actions
  • Action Associations
  • Comments.


Logic Guide - Steps (Sequential Function Charts)

Steps

Each step represents a state that the program is to monitor. For example, a step could represent a check for the state of a particular point.

The Start step is the initial step. The second step is CheckLevel. The CheckLevel step only becomes active if the condition defined by the PipeAlarm transition is true. When the CheckLevel step is active, the Start step becomes inactive.

The arrangement of the steps in your Sequential Function Chart determines the order in which the various actions and conditions are read. The system begins with a step that is marked as being the initial step, and proceeds to the next step via a transition. Transitions define specific conditions (see Transitions). When the system reaches a step, the step becomes active. The system can only proceed to the next step (or steps) if the transition between the steps defines a condition that is true. For example, if Step 3 is active, Step 4 will only become active if the condition for the transition that connects Step 3 to Step 4 is true.

Steps cannot be connected directly to other steps—each step has to be connected to one or more transitions. However, steps can be connected to Actions.

You can associate multiple steps with a single transition. This is useful when you want several branches of steps and actions to occur at the same time as a result of a specific condition. For more information, see Simultaneous Sequences.


Logic Guide - Transitions (Sequential Function Charts)

Transitions

Transitions represent a condition such as an item being in a specific state, or a value being in a specific range. The step that follows the transition is only activated if the condition defined in the transition is true.

For example, a transition could be configured to represent this condition:

Value>50

When a the value of the point that is associated with the transition is greater than 50, the condition is true—the step after the transition will become active. If the point's value is less than 50, the transition's condition is false and the next step will not become active.


Logic Guide - Actions (Sequential Function Charts)

Actions

Actions are used to associate a step with a specific response. The response can be change the state or value of one of the Sequential Function Block's variables, or can be to initiate a method for any database item. For example, an action can be used to associate a step with the EnableAlarms method for a point. When the step is active, the action will initiate the EnableAlarms method for the relevant point.

2 actions associated with a single 'Stop' step.

To use an action on an SFC, you need to use the Actions window to add an action (see Add an Action to a Sequential Function Chart). When you have added an action, you need to configure it (see Edit an Action on a Sequential Function Chart).

If you are using an action to perform a method, you will need to add a method to the SFC (see Add a Method Variable to a Sequential Function Chart), and then configure the action to refer to the method (see Initiate a Method on a Sequential Function Chart).

When you use an action on an SFC, you will also need to configure an action association (see Action Associations). The action association defines when the action is initiated.


Logic Guide - Action Associations (Sequential Function Charts)

Action Associations

You can configure an action association for each action. The settings for an action association define:

  • The type of action and when the action occurs upon becoming active. For example, you can set an action to only occur once when the action is activated, or you can set an action to occur repeatedly after a specified time delay. The type of action and time for the action are defined via the Qualifier and Duration settings on the Edit Action Association window.
  • The name for the action. This is the name that is used to reference the action on the Sequential Function Chart.
  • Indicator variables. These are text entries that can be displayed next to the action. The indicator variables are optional and are used to provide information about the completion of an action.

You can use an indicator variable to display the name(s) of the direct or internal variables that are affected by an action. This is useful as it allows operators to see which variables are affected by each action.


Logic Guide - Comments (Sequential Function Charts)

Comments

As with the other types of graphical Logic programs, Sequential Function Charts allow you to add comments. The comments are for annotation purposes and have no effect on the system. They are useful as they allow you to add textual information for use by operators (explanations of sections of the SFC, etc.).

Comments are displayed in green comment boxes and can be positioned anywhere on your Sequential Function Charts.


Logic Guide - Connections (Sequential Function Charts)

Connections

The components on a Sequential Function Chart (except comments) are connected by connection lines. These lines connect the connection boxes of steps to those of transitions, and they also connect steps to actions.

To create a connection line, simply select a connection box, then drag the cursor to another connection box. When you release the left-hand mouse button, the connection is drawn.

NOTE: An invalid symbol is displayed in place of the cursor if the connection you are attempting to make is invalid (for example, if you are trying to connect a step to another step).


Logic Guide - How Sequential Function Charts Work (Sequential Function Charts)

How Sequential Function Charts Work

Sequential Function Charts depict a sequence of steps. Each step represents a state that the program is to monitor. For example, a step could represent a check for the state of a particular point.

Steps cannot be connected directly to other steps—each step has to be connected to one or more transitions.

Transitions represent a condition such as a point value or state. For example, a transition could represent the value of an analog point being greater than 50. When a transition's condition is true, the step before the transition is deactivated and the step that follows the transition is activated. This allows you to design a flow of Logic.

Typically, the flow starts at the top and proceeds downwards. However, you can design your SFCs to have a sequence that flows in any direction.

ClearSCADA begins executing a Sequential Function Chart (SFC) from the step that is defined as the initial step. When the condition of the transition between the initial step and the second step is true, the system will proceed to the second step. When the second steps becomes active, the initial step becomes inactive. Similarly, when the condition for the transition between the second step and third step is true, the system will proceed to the third step and the second step becomes inactive. This process continues throughout the Sequential Function Diagram.

Transitions can be connected to multiple steps. This allows you to create multiple branches of steps and transitions that work independently and simultaneously (see Simultaneous Sequences).

Steps can be associated with an action. This means that a specified action occurs when the step becomes active. The configuration for the action includes ST code that defines the result of the action, for example, Value:=TRUE; could be used to set a variable named Value to state 1 (True).

Actions can also be configured to reference method variables. The method variables are associated with a specific method, such as Enable Alarms or Override, and a specific database item. If an action references a method, the action will cause that method to be performed on the database item that is associated with the method when the action becomes active. For example, if an action references a method named Alarms, the Alarms method will be performed when the action becomes active. The configuration of the method associates the method with a database item and a specific method for that item.

Example:

The following SFC shows how the sequence can be structured from top to bottom:

  1. S1 is step 1. The system begins executing the SFC from this step.
  2. If the condition for the DoReset transition is true, the S1 step is deactivated and the Check step is activated.
  3. If the TRUE transition has a condition that is true, the Check step is deactivated and the OpenTP step is activated.
  4. If the OpenTP step is activated, the DoOpenTP action is performed. The configuration for the action defines what happens when the action is performed—it could write a value or state or could execute a method.
  5. If the OpenTP.T variable value is greater than 2 seconds, the OpenTP step is deactivated and the Close CB step is activated.
  6. If the CloseCB step is activated, the DoCloseCB action is performed.
  7. If the CloseCB.T variable value is greater than 2 seconds, the CloseCB step is deactivated and the Close MP step is activated.
  8. If the CloseMP step is activated, the DoCloseMP action is performed.
  9. If the CloseMP.T variable value is greater than 2 seconds, the CloseMP step is deactivated and the S6 step is activated.
  10. If the S6 step is activated, the ResetAll action is performed.
  11. If the condition for the transition that follows S6 is true, the whole sequence repeats itself, starting from S1.


Logic Guide - Simultaneous Sequences (Sequential Function Charts)

Simultaneous Sequences

In How Sequential Function Charts Work, we explained the basic principles of a Sequential Function Chart. However, the SFC in the example only had a single branch (or path). You can connect multiple steps to a transition so that there are multiple branches—each branch is independent of the other branches but is executed at the same time. This allows you to create an SFC that has several processes that occur simultaneously as a result of a specific condition.

To create simultaneous sequences, simply create steps and transitions in the same way as you would for a single branched sequence, then connect the first steps of the simultaneous branches to the transition. When the selected transition is true, the simultaneous branches will occur at the same time.

You can bring the simultaneous branches back into a single sequence by connecting the final steps in the branches to a single transition that occurs after the branches.

Example:

The following Sequential Function Chart shows a basic program that could be used to control a drain and pump when there is a high level of fluid in a pipeline:

The sequence begins with the Start step, and the first condition that has to be met is that the PipeAlarm transition has to be true. The PipeAlarm transition corresponds to the state of a point that monitors the alarm status of the pipe. So, if ClearSCADA detects an alarm condition at the pipe, the Start step is deactivated and the next step (CheckLevel) is activated.

For the CheckLevel step, the system checks the value of a point that monitors the level of fluid in the pipe. The transition defines that the next steps (CheckFlow and OpenDrain) will only be executed if the value for the level is higher than 70.

If the level is higher than 70, the system executes the next steps simultaneously. The OpenDrain step and its sub-steps are executed at the same time as the CheckFlow step and its sub-steps. The conditions in the two paths are independent—the OpenDrain sub-steps and transitions are not affected by the CheckFlow sub-steps and transitions and vise-versa.

The steps after the Level>70 transition occur at the same time.

When the OpenDrain step is active, it triggers the Drain action. The Drain action has been configured on the Actions window for the SFC to change the state of a point. The point is used to control a drain cover in the pipe—when the point is in state 0, the drain is closed; when it is in state 1, the drain is open. The qualifier of the Drain action association defines that the action only occurs once, when the action first becomes active.

When the Drain action has been executed, this branch of the SFC will continue with the Level<50 transition. However, the Level<50 transition will only be performed if the Drain action has been executed and the CheckLevelAgain step in the CheckFlow branch of the SFC is active. The branches that occur simultaneously have to be complete so that their last step is active before the next transition (Level<50) becomes active.

When the CheckFlow step is active, the system checks for another condition (defined by the Flow<25 and Flow>25 transitions). If the value of the Flow point is less than 25, the system proceeds to the PumpOn step. If the value is more than 25, the system will proceeds to the CheckLevelAgain (as the OpenDrain step is also occurring, and there is a flow in the pipe, the fluid level will drop eventually).

When the PumpOn step is active, it triggers the Pump action. The Pump action has been configured on the Actions window for the SFC to change the state of a point. The point is used to turn a pump on and off—when the point is in state 0, the pump is off; when it is in state 1, the pump is on. The qualifier of the Pump action association defines that the action only occurs once, when the action first becomes active.

When the pump is turned on, the flow of fluid in the pipe will increase. This is also aided by the open drain (the drain is opened at the same time as the CheckFlow step). So, the next part of this branch is to determine whether the flow is greater than 25 (Flow>25).

When the flow is greater than 25, the CheckLevelAgain step becomes active. If the Drain action has been executed and the CheckLevelAgain step is active, the system will proceed to the Level<50 transition.

If the level is lower than 50, the amount of fluid in the pipe is normal and so the SFC can be stopped—the system proceeds to the Stop step and performs the CloseDrain action and the StopPump action.

If the level is higher than 50, the drain remains open and the pump remains on. They will only be closed and turned off when the level drops below 50.


Logic Guide - Create a Sequential Function Chart Database Item (Sequential Function Charts)

Create a Sequential Function Chart Database Item

Each Sequential Function Chart needs to be represented in the ClearSCADA database by a Sequential Function Chart item. When you have created a Sequential Function Chart item, you can access its Edit feature which allows you to create the Sequential Function Chart program.

To create a Sequential Function Chart database item:

  1. In the Database Bar, right-click on a system, Group, or Group Template to display a context sensitive menu.
  2. Select the New option, then the Logic option, then the Sequential Function Chart option from the context sensitive menu.
    A new Sequential Function Chart item is added to the system, Group, or Group Template. It is selected automatically, ready for you to enter its name.
  3. Enter a suitable name for the Sequential Function Chart then press the Enter key or select another part of the interface.
    Sequential Function Chart database item (shown in a Group).

Now that you have created a Sequential Function Chart database item, you can display it and edit it as required.


Logic Guide - Display a Sequential Function Chart (Sequential Function Charts)

Display a Sequential Function Chart

You can display an SFC in Design mode or Run mode. In Design mode you can create and edit the program, whereas in Run mode, you can interact with the program in the same way that an operator (i./e. you cannot edit the program).

  • To display an SFC in Run mode:
  1. In the Database Bar, right-click on the SFC that you want to display.
    A context sensitive menu is displayed.
  2. Select the Display option.
  • To display an SFC in Design mode:
  1. In the Database Bar, right-click on the SFC that you want to display.
    A context sensitive menu is displayed.
  2. Select the Edit option.

The grid is shown when the SFC is in Design mode.

You can also toggle between Run mode and Design mode by selecting and de-selecting the Design mode button.

Mimics can also be configured to contain links to Logic displays such as SFCs.


Logic Guide - Add Direct and Internal Variables to a Sequential Function Chart (Sequential Function Charts)

Add Direct and Internal Variables to a Sequential Function Chart

You need to add variables to your Sequential Function Charts. There are 3 types of variable:

  • Internal variables represent values that are not stored in the ClearSCADA database. Internal variables are used for calculations etc. within the SFC.
  • Direct variables represent values that are stored in the ClearSCADA database. Direct variables are used for the SFC's inputs and outputs.
  • Method variables represent method actions such as Override and Enable Alarms (see Add a Method Variable to a Sequential Function Chart).

In this section, we explain how to add a direct variable and an internal variable:

  1. Display the SFC in Design mode (see Display a Sequential Function Chart).
  2. Either:
  1. Right-click in a row on the Direct tab or the Internal tab (as appropriate) to display a context sensitive menu.
  2. Select the Add option to display the Add Direct Variable window or the Add Internal Variable window.

Or:

  1. In the Database Bar, select the database item that has the direct variable that you want to add to the SFC. Keep the left-hand mouse button pressed.
  2. Drag the database item onto the SFC. Release the left-hand mouse button to display the Add Direct Variable window.
  3. Use the Add Direct Variable window or Add Internal Variable window to define the settings for the new variable. The windows contain a selection of these settings (the settings vary according to whether the variable is direct or internal):
  • Name—Enter the name for the variable. This name will be used to refer to the variable within the program. A name is entered automatically when you drag a variable onto the Sequential Function Chart, but you can change it as required.
  • Tag Type—Choose the type of variable tag. This can be:
  • Read/Write (%M)—The Sequential Function Chart can both read the value and overwrite it with a new value.
  • Read Only (%I)—The Sequential Function Chart can only read the value and cannot change it.
  • Write Only (%Q)—The Sequential Function Chart cannot read the variable but can write a new value to it.
  • Tag—This is the name of the OPC property that represents the variable that you want to add to the Sequential Function Chart.
  • Type—Choose the type of value. The value type needs to be appropriate to the value that is represented by the selected tag (see Built-In Data Types).
  • Insert—Choose the type of variable tag that you are adding to the Sequential Function Chart. Choose the required type of variable from the combo-box (see Sequential Function Chart Components).
  • Retained—The Retained feature is designed to be used with internal variables. When selected, it allows the internal variable to be stored and transferred to other servers (in a multi-server setup).

For more information on the Retain feature, see Using the RETAIN Keyword in an ST Program.

  • No Cache—Use the No Cache check box to determine whether the program uses the latest value or the initial value for a variable on each execution. If you check the No Cache check box, the program will use the latest value for the variable rather than the default value. If you clear the No Cache check box, the program will use the default value for the variable on each execution.

The No Cache feature is especially useful with variables that are used as counts. For more information on the No Cache feature, please refer to Using VAR NOCACHE to Prevent Cached Values Being Used in an ST Program.

  4. Select the OK button to confirm the selections and close the Add Direct Variable or Add Internal Variable window.
    The new variable is added to the SFC—it is listed on the Direct or Internal tab (as appropriate).

You can now reference the direct or internal variable in the conditions for the transitions and in the ST code for any actions.


Logic Guide - Add a Step to a Sequential Function Chart (Sequential Function Charts)

Add a Step to a Sequential Function Chart

Steps represent states that the program is to monitor. For example, a step could represent a check for value of a specific point. For more information, see Steps.

A step is only performed if it is active. It becomes active when the condition for the transition that connects it to the previous step is true. The initial step does not have a transition to a previous step—it is performed whenever the system executes the Sequential Function Chart.

A step becomes inactive when the condition for the transition that connects the step to the next step is true.

To add a step to an SFC:

  1. Display the SFC in Design mode (see Display a Sequential Function Chart).
  2. Right-click on the background of the SFC.
    A context sensitive menu is displayed.
  3. Select the Add Step option.
    A new step is added to the SFC.


Logic Guide - Define a Step as the First Step in a Sequential Function Chart (Sequential Function Charts)

Define a Step as the First Step in a Sequential Function Chart

You need to define a step as the initial step so that the Sequential Function Chart (SFC) can determine which step it needs to perform first. To do this, you have to use the Initial Step feature.

To define a step as the first step in an SFC:

  1. Display the SFC in Design mode (see Display a Sequential Function Chart).
  2. Right-click on the step that is to be the first step in the SFC.
    A context sensitive menu is displayed.
  3. Select the Initial Step option.
    The step is set to be the first step. Two vertical lines are added to the step to indicate it is the first step in a sequence


Logic Guide - Add a Transition to a Sequential Function Chart (Sequential Function Charts)

Add a Transition to a Sequential Function Chart

Transitions represent a condition such as an item being in a specific state, or a value being in a specific range. The step that follows the transition is only activated if the condition defined in the transition is true.

For more information, see Transitions.

To add a transition to a Sequential Function Chart:

  1. Display the SFC in Design mode (see Display a Sequential Function Chart).
  2. Right-click on the background of the SFC.
    A context sensitive menu is displayed.
  3. Select the Add Transition option.
    The transition is added to the SFC

You can edit the transition by right-clicking on it and selecting the Edit option from the context sensitive menu (see Edit a Transition).


Logic Guide - Edit a Transition (Sequential Function Charts)

Edit a Transition

When you add a transition to a Sequential Function Chart (SFC), you need to edit it so that it has a condition. The next step on the SFC will only become active if the transition's condition is true.

The condition that you enter should be similar to the conditions for IF statements in ST. For example, if the condition is only to be true when a variable named Level has a value greater than 10, the condition would be:

Level>10

To edit a transition:

  1. On the Sequential Function Chart, right-click on the transition that you want to configure.
    A context sensitive menu is displayed.
  2. Select the Edit option to display the Edit Transition window.
  3. Enter a new condition for the transition. The condition should be an ST expression of the type that would be entered in an IF statement. For example, PumpValue:=10 would mean the transition is true if the variable named PumpValue has a value of 10.
  4. Select the OK button to confirm the entry and close the Edit Transition window.

Further Information

Transitions.

IF - THEN - ELSE.


Logic Guide - Display the Actions Window on a Sequential Function Chart (Sequential Function Charts)

Display the Actions Window on a Sequential Function Chart

You should display the Actions window on a Sequential Function Chart if you need to:

  • Add an action to your SFC
  • View the actions that are already on your SFC
  • Edit an action on your SFC.

To display the Actions window:

  1. Display the SFC in Design mode (see Display a Sequential Function Chart).
  2. Either:
  1. Select the Edit menu.
  2. Select the Actions option.

Or:

  1. Right-click on the background of the SFC.
    A context sensitive menu is displayed.
  2. Select the Actions option.

The Actions window is displayed.

The Actions window contains a list of the actions that have been created for use in the SFC program. The names of each action are listed under the Name column, and the Type column indicates the Logic language that the system uses to identify and perform the relevant action.

You can use the Actions window to add new actions, edit actions, rename actions, and delete actions.


Logic Guide - Add an Action to a Sequential Function Chart (Sequential Function Charts)

Add an Action to a Sequential Function Chart

You need to add an action to your Sequential Function Chart for each action that is performed by the program, for example, for each output that writes a value to a point.

To add an action to an SFC:

  1. Display the Actions Window on a Sequential Function Chart.
  2. Right-click on a row in the Actions window.
    A context sensitive menu is displayed.
  3. Select the Add option.
    The Add Action window is displayed.
  4. Enter the name for the new action. We recommend that you enter a name that indicates the purpose of the action.
  5. Select the OK button to confirm the entry. The Add Action window is closed and the action is added to the list in the Action window.
  6. Select the action in the Actions window. Keep the left-hand mouse button pressed down.
  7. Drag the action onto a Step or Action that is to be associated with the action on the SFC, then release the left-hand mouse button.
    The action is added to the SFC.

You can define the configuration of the action by right-clicking on it and selecting the Edit option from the context sensitive menu (see Edit an Action on a Sequential Function Chart).


Logic Guide - Edit an Action on a Sequential Function Chart (Sequential Function Charts)

Edit an Action on a Sequential Function Chart

You need to edit each action that you add to a Sequential Function Chart (SFC). By editing an action, you can associate it with a ClearSCADA action such as a control. Alternatively, you can enter any Structured Text code so that the action runs a Logic program.

To edit an action on an SFC:

  1. Right-click on an action in the Actions window.
    A context sensitive menu is displayed.
  2. Select the Edit option.
    The Action Program window is displayed.
  3. Enter the ST code for the action. For more information on ST, see ST Programs.

Common codes for actions include setting a point value or point state. For example, PumpState :=True; sets an action to change the state of a variable named PumpState to state 1 (True).

When you have configured an action, you will need to configure an action association (see Edit an Action Association). The action association configuration defines the type of action and when the action occurs.


Logic Guide - Edit an Action Association (Sequential Function Charts)

Edit an Action Association

When you have added an action to your SFC, you need to configure an action association. The settings in the action configuration define when the action takes place, and whether it is repeated, works as a pulse etc.

The action association configuration also allows you to create indicator variables for your actions. These are indicators that can be shown on the SFC to show operators which variables are affected by an action.

To configure an action association:

  1. On the Sequential Function Chart, right-click on the action that you want to configure.
    A context sensitive menu is displayed.

NOTE: You have to right-click on the action on the SFC—if you right-click on the action in the Actions window, a different context sensitive menu is displayed.

  2. Select the Edit option to display the Edit Action Association window.

Use the Qualifier combo-box to define when the action is to be performed. The available options include:

  • N—The action is executed repeatedly while the step is active. This means that the action will occur again and again until the program proceeds to the next step in the sequence.
  • R—The action resets another instance of the same action. This is used in conjunction with actions that use an S qualifier.

Actions that use an S qualifier are executed repeatedly until they are reset. They are reset when another instance of the same action is executed (the other instance of the action has to have an R qualifier).

  • S—Actions that use an S qualifier are executed repeatedly until they are reset. They are reset by an action with an R qualifier (see above).
  • P—The action is a pulse action. It is executed once when the step is first activated and then once again when the step is deactivated.
  • P0—The action is a pulse action. It is executed once when the step is deactivated.
  • P1—The action is a pulse action. It is executed once when the step is first activated.
  • L—The action is time limited. It executes repeatedly for a defined time period.
  • D—The action is time delayed. It is executed after a defined time period has passed.
  • SD—The action is stored and time delayed. The action is executed repeatedly after a defined time period has expired. The action is executed even if the associated step is deactivated before the start of the time period.
  • DS—The action is time delayed and stored. The action is executed repeatedly after a defined time period has expired. The action is not executed if the associated step is deactivated before the start of the time period.
  • SL—The action is time limited and stored. The action is executed repeatedly for defined time period.
  3. Use the Duration field to define the time period for time delayed and time limited qualifiers. You have to enter the time period in the OPC time format, for example, T#30s for 30 seconds.
  4. Use the Name field to define a name for the action association. The name has to be exactly the same as the name of the action that the action association affects. For example, if an action named PowerOff is used to write a value to a point that controls the power supply, the action association for that action also has to be named PowerOff.
  5. Use the Indicator Variables section to define any indicators. The indicator variables are optional and are used to provide information about the completion of an action.

You can use an indicator variable to display the name(s) of the direct or internal variables that are affected by an action. This is useful as it allows operators to see which variables are affected by each action. For example, if a Stop action affects the state of a 'PowerStatus' variable, an indicator variable could be used to show 'PowerStatus' next to the Stop action on the SFC.

Qualifier
Action
Indicator Variable

To create an indicator variable:

  1. Select the Add button on the Edit Action Association window to display the Add Variable window.
  2. In the Add Variable window, enter the name of a variable that is affected by the action with which the indicator variable will be associated. The name has to be identical to the name of the selected variable. For example, if a Start action affects a RunState direct variable, the indicator variable for the Start action also has to be named RunState.
  3. Select the OK button or press the Enter key to confirm the name.

If an action affects more than one variable, you can add more indicator variables by repeating steps i-iii inclusive. The additional indicator variables will be listed after the first indicator variable in comma separated format.

You can rename an indicator variable, by selecting an indicator variable in the list, then selecting the Rename button. You can then enter a new name for the indicator variable.

You can also remove an indicator variable by selecting an indicator variable in the list, then selecting the Delete button.

  4. Select the OK button to confirm your selections.
    The Edit Action Association window is closed and the action association is configured according to your selections.


Logic Guide - Add a Comment to a Sequential Function Chart (Sequential Function Charts)

Add a Comment to a Sequential Function Chart

You can add comments to your Sequential Function Charts. The comments have no effect on the way an SFC works, but they can be used to provide information to other users. For example, you can add a comment that explains what happens when a certain action is performed.

To add a comment to an SFC:

  1. Display the SFC in Design mode (see Display a Sequential Function Chart).
  2. Right-click on the background of the SFC.
    A context sensitive menu is displayed.
  3. Select the Add Comment option.
    The Add Comment window is displayed.
  4. Enter the required comment. (Overwrite the default entry of <<comment>>).
  5. Select the OK button to confirm your entry and close the Add Comment window.
    The comment is added to the SFC. It will be visible to the users that access the SFC.


Logic Guide - Edit a Comment on a Sequential Function Chart (Sequential Function Charts)

Edit a Comment on a Sequential Function Chart

You can alter a comment that has been added to a Sequential Function Chart by right-clicking on the comment and selecting the Edit option from the context sensitive menu. This displays the Edit Comment window which you can use in the same way as the Add Comment window (see Add a Comment to a Sequential Function Chart).


Logic Guide - Add a Method Variable to a Sequential Function Chart (Sequential Function Charts)

Add a Method Variable to a Sequential Function Chart

If your Sequential Function Chart contains actions that are to initiate ClearSCADA methods (controls such as Override, Enable Alarms etc.), you need to add method variables.

Each method variable declares a method for use in your Sequential Function Chart (SFC). The configuration of the method variable corresponds to the METHOD declaration in ST (see Executing Methods on Database Items).

To add a method variable to an SFC:

  1. Display the SFC in Design mode (see Display a Sequential Function Chart).
  2. Select the Method tab.
  3. Right-click in the list on the Method tab to display a context sensitive menu.
  4. Select the Add option to display the Add Method Variable window.
  5. Use the Add Method Variable window to define the settings for the method declaration:
  • Name—Enter the name for the method variable. This is the name that will be used to reference the variable within the ST code.
  • Object—Use the browse button feature to select the database item that has the method that you want to use. For example, if you want to add the EnableAlarms method for a point named 'Power', use the browse button feature to select the 'Power' point.
  • Method—Use the Method combo-box to select the method that you want to add to the SFC. The list contains the methods that are available for the selected database item. The Hand Control method is unavailable as it does not work in the same way as other methods. If you need to write a current value, you should use add a direct variable and write to it instead.
  • Prototype—The Prototype field is only available for methods that set a specific value, for example, methods that override an analog point so that the point has a value of 50.

Use the Prototype field to define the type of value(s) that will be written by the method. The actual values that will be written are defined in the configuration of the actions that will be associated with the method.

If the Prototype field is available, it will display at least one value type that is appropriate to the method. Typically, you will not need to change the value type(s). If you do decide to change them, you need to enter value types that are appropriate for the type of database item to which the value is written (see Built-In Data Types).

  6. Select the OK button to confirm your choices.

You can now include the method in the ST code for one of the actions on the SFC (see Edit an Action on a Sequential Function Chart). When you associate the action with a step, the defined method will be performed when the step takes place (see Edit an Action Association).


Logic Guide - Initiate a Method on a Sequential Function Chart (Sequential Function Charts)

Initiate a Method on a Sequential Function Chart

If you want your Sequential Function Chart to contain a step that initiates a method (control for a specific item), you need to follow this procedure:

  1. Display the SFC in Design mode (see Display a Sequential Function Chart).
  2. Locate the step that you want to associate with the method. If the SFC does not contain a suitable step, create a step (see Add a Step to a Sequential Function Chart) and link it to the SFC by drawing connection lines.
  3. Add a method variable (see Add a Method Variable to a Sequential Function Chart). You will need to configure the method variable so that it is associated with the relevant database item and the required method.
  4. Add an action (see Add an Action to a Sequential Function Chart). You will need to configure the action so that it has ST code that it references the method and defines the value or state that the method will set (where appropriate).
  5. Configure an action association (see Edit an Action Association) that defines when the method will be initiated.

You need to configure the action association so that:

  • The method configuration defines the correct method and database item that is to be initiated.
  • The step is associated with the action that initiates the method.
  • The action is associated with the correct step, and has ST code that references the method (and defines any values or states that are set by the method).
  • The action association defines the correct settings for the action.
  6. Save the SFC.

Example:

A point named 'Valve' is to have its state overridden by a condition on a Sequential Function Chart (SFC). When the OPENVALVE step of the SFC is reached, the program will cause ClearSCADA to change the 'Valve' point's state to state 1 (True).

On the SFC, a new step is created. The step is named OPENVALVE.

An action named Override is created. This is the action that will be associated with the OPENVALVE step.

A new method is created with these settings:

  • Name—ValveOverride
  • Object—.Valve
  • Method—Override
  • Prototype—USINT

The action is configured so that its ST code references the ValueOverride method and defines the state that is to be set:

ValueOverride (True);

When the OPENVALVE step takes place, the Override action is initiated.

The Override action causes the 'Valve' point to change to state 1 (True). The configuration of the 'Valve' point defines that state 1 corresponds to the valve being opened.

The action item on the SFC is connected to the OPENVALVE step.

Finally, an action association is edited so that a ValveOpen indicator variable is shown for the action, and the qualifier is set to N (the override will repeat automatically when the step is True).


Logic Guide - Insert a Breakpoint on a Step in a Sequential Function Chart (Sequential Function Charts)

Insert a Breakpoint on a Step in a Sequential Function Chart

You can insert a breakpoint on a step so that the Sequential Function Chart only executes up to the selected step—it does not perform the steps after it. This is useful for testing that sections of your SFC work correctly (debugging).

To insert a breakpoint on a step in an SFC:

  1. On the SFC, right-click on the step on which you want to insert the breakpoint.
    A context sensitive menu is displayed.
  2. Select the Insert Breakpoint option.
    A breakpoint is set on the step. A red dot appears on the step to indicate that a breakpoint has been inserted.

The program will only execute up to the selected step.

To cancel the breakpoint, right-click on the step to display a context sensitive menu, then select:

  • Remove Breakpoint—Deletes the breakpoint.
  • Disable Breakpoint—Leaves the breakpoint in place, but disables it so that the program can execute beyond the selected step.


Logic Guide - Delete Sequential Function Chart Components (Sequential Function Charts)

Delete Sequential Function Chart Components

You can delete steps, transitions, comments, variables and actions by right-clicking on the relevant item on the SFC, Direct tab, Indirect tab, Methods tab, or in the Actions window, then selecting the Delete option from the context sensitive menu.


Logic Guide - Rename Sequential Function Chart Components (Sequential Function Charts)

Rename Sequential Function Chart Components

You can rename steps, transitions, and actions by right-clicking on the relevant item on the SFC, Direct tab, Indirect tab, Methods tab, or in the Actions window, then selecting the Rename option from the context sensitive menu. To rename the item, simply enter a new name that overwrites the existing name, then press the Enter key or select another part of the interface to confirm your selection.


Logic Guide - Compiling a Sequential Function Chart (Sequential Function Charts)

Compiling a Sequential Function Chart

You can use the Build menu options to compile your Sequential Function Chart (SFC). The compilation feature is useful as it checks that your Sequential Function Chart has the correct syntax.

There are 2 compile options:

  • Compile—Compiles the chart. If the chart is invalid, the compiler display provides an message with a brief explanation of the cause of the syntax error. If the syntax is correct, the compiler displays a success message.
  • Compile with Diagnostics—Compiles the SFC and provides detailed diagnostic information. As with the Compile option, there are messages for any errors in the syntax. If the syntax is correct, the compiler displays a success message.

To compile a Sequential Function Chart:

  1. Display the Sequential Function Chart in Design mode.
  2. Select the Build menu, then select the Compile option or the Compile with Diagnostics option as required.
    The Sequential Function Chart is compiled and the compile messages are shown in the Compiler display.
    Compiler display

If the chart has invalid syntax, you will need to alter the SFC. Typically, the causes of errors are minor, such as the wrong type of value being specified or a missing connection.


Logic Guide - Viewing the Variables in your Sequential Function Chart (Sequential Function Charts)

Viewing the Variables in your Sequential Function Chart

When you display a Sequential Function Chart in Run mode, you can view a list of the variables it uses. The list shows the current values for the variables. The variables window is useful as it allows you to view the variables that are produced by part of the chart.

To display the variables window:

  1. Display the Sequential Function Chart in Run mode (right-click on it in the Database Bar then select the Display option).
  2. Select the Debug menu, then select the Variables option.
    The variables window is displayed.

The variables window contains expandible lists of the variables in your Ladder Diagram. For each variable, it lists the Name of the variable, the Type (which shows the data type), and the Value (which shows the current value of the variable).


Logic Guide - Changing the Update Interval for a Sequential Function Chart (Sequential Function Charts)

Changing the Update Interval for a Sequential Function Chart

You can use the Update Interval feature to define how often your ClearSCADA client PC requests updates for a Sequential Function Chart (SFC). By default, ClearSCADA clients request an update from a ClearSCADA server for the latest variable values every second.

By using the Update Interval feature, you can set your ClearSCADA client PC to request variable updates at a slower rate.

To change the update interval for an SFC:

  1. Display the Sequential Function Chart in Run mode (right-click on it in the Database Bar then select the Display option).
  2. Select the Run menu, then select the Update Interval option.
    A further menu is displayed.
  3. Select the required interval from the list of options. The intervals range from 1 second to 60 seconds.


Logic Guide - Built-in Functions, Function Blocks, and Conversions

Built-in Functions, Function Blocks, and Conversions

ClearSCADA provides a set of built-in functions, function blocks, and conversions that you can use in your Logic programs. They provide common industrial control system functionality and are especially useful on Function Block Diagrams and Ladder Diagrams as you can add them to your programs via context sensitive menus.

For information on the 'extra' EN and ENO function connections, the built-in functions, built-in function blocks, and built-in conversions, please refer to the following sections:

  • Using EN and ENO to Control when a Function is Performed
  • Built-In Functions
  • Built-In Function Blocks
  • Conversions.

You can access all of the built-in options from the context sensitive menu that is displayed when you right-click on the background of a Function Block Diagram or Ladder Diagram. You can also include them in your ST program code.

Right-click on the background of a Function Block Diagram or Ladder Diagram to display the context sensitive menu. The menu provides access to the built-in functions, function blocks, and conversions. You can only access the context sensitive menu when the diagram is displayed in Design mode.

NOTE: When using functions and function blocks, you need to configure an appropriate output data type; the output data type has to be suitable for storing the result. If the output data type is inappropriate, the output may cause an overflow and the value will be inaccurate. For example, if you set an EXPT function to have constant inputs of 10 and 6, the result is 64 as the actual result of 100000 is converted to binary and so results in 64. To store the actual result, the input values have to be converted to DINT or UDINT.


Logic Guide - Using EN and ENO to Control when a Function is Performed (Built-in Functions, Function Blocks, and Conversions)

Using EN and ENO to Control when a Function is Performed

Functions used in Ladder Diagrams and Function Block Diagrams have an extra input and output. The extra input is EN and the extra output is ENO:

  • EN—The EN input represents ENABLED and it is used to control whether the function is performed. When the EN input is used, the function is only performed if the EN input is true. For example, if the EN input is used on an ADD function, the output of the ADD function will only be the sum total of its two normal inputs if its EN input is true. If the EN input is false, the output of the ADD function will be 0, irrespective of its inputs.
    The output of the ADD function is 0, despite the inputs being 2 and 5. The output is 0 instead of 7 as the ADD function is not performed due to the PumpAlarm direct variable being in state 0 (false). If the PumpAlarm direct variable changes to state 1 (true) the output of the ADD function will be 7 (2+5).

  • ENO—The ENO output represents ENABLED OUTPUT and it is used to show that a function has executed successfully. If the ENO value is True, the function has executed successfully; if the ENO value is False, the function has not executed successfully and there is an error such as an arithmetic overflow.

You can set a function to be both EN and ENO at the same time. This allows you to control whether the function is performed and to determine whether it is executed successfully. By chaining the ENO output of one function to the EN input of another, you can create a flow of functions that are only executed if the previous function was successful.

In ST, you can refer to the EN and ENO input and outputs in the same way as other variables. For example:

VAR_INPUT
EN: BOOL := 0;
END_VAR
VAR_OUTPUT
ENO : BOOL;
END_VAR


Logic Guide - Combining Functions with other Functions (Built-in Functions, Function Blocks, and Conversions)

Combining Functions with other Functions

You can combine functions so that the outputs of one function are the inputs of another function. This allows you to create complex Logic programs where the results of one function affect the results of other functions.

In a Function Block Diagram, you can connect the output of one function to an input of another function by drawing the connection in the same way as you would connect a tag to an input.

In an ST Program, you need to declare a function and then include the second function (and its arguments) as one of the arguments for the first function. For example, to use the output of a DIV function as one of the inputs for an ADD function, you need to use this syntax:

Output := ADD (DIV (A, B), C)

Where Output is a variable defined earlier in the program, A and B are the arguments for the DIV function, and C is the second argument for the ADD function. So the ADD function uses the output of A/B as Input 1 and C as Input 2:

Output := ADD (DIV (10, 5), 20)

In this case, ADD uses 2 as Input 1 (10/5=2) and 20 as Input 2, so the ADD function outputs 22.

The only limitation with combining inputs and outputs is that the output from one function needs to be of the data type that is required by the input of another function. So, if a function outputs a Boolean value, it can only be used as the input for a function that requires a Boolean input (unless a conversion is used).


Logic Guide - Built-In Functions (Built-in Functions, Function Blocks, and Conversions)

Built-In Functions

ClearSCADA provides 9 categories of built-in function:

  • Arithmetic
  • Bit String
  • Bitwise/Boolean
  • Comparison
  • Date and Time
  • Numerical
  • Selection
  • String
  • Misc


Logic Guide - Arithmetic (Built-in Functions, Function Blocks, and Conversions)

Arithmetic

The Arithmetic menu provides access to functions that perform an arithmetic calculation. They perform arithmetic on the inputs to determine the value of an output.

The following arithmetic options are available:

  • ADD
  • DIV
  • EXPT
  • MOD
  • MOVE
  • MUL
  • SUB.

NOTE: When using arithmetic functions in ST Programs, you should use the available operators when performing a function on 2 values. For example, Output := Input 1 + Input 2 is more efficient than Output := Add (Input 1, Input 2). However, for functions that have multiple arguments, you should use the comma separated format, for example, Output := Add (Input 1, Input 2, Input 3, Input 4).

ADD
Function Name | ADD
ST Operator | +
Description | Provides a sum total of the 2 inputs.
Arguments | Input 1 - Input n {ANY_MAGNITUDE} The ADD function can have 2 or more inputs and these can be of any type within the ANY_MAGNITUDE category (see Data Type Hierarchy).
Returns | Total {Same type as input} The total value of the inputs combined (Input 1 + Input 2 + Input 3 and so on). The type of output is dependent on the inputs.

Examples:

Function Block Diagram - ADD:

The ADD function is used to provide a total of 2 inputs. In this case, Input 1 is 2 and Input 2 is 5. The ADD function returns 7 (2+5=7)

ST Program - ADD:

The ADD function is used to provide the total value of 3 inputs. In this case, Input 1 is 2, Input 2 is 5, and Input 3 is 17. The ADD function returns 24 (2+5+17=24):

Output := ADD (Input 1, Input 2, Input 3);

Where Output, Input 1, Input 2 and Input 3 are defined as variables earlier in the ST program.

Alternatively, the same calculation can be made by using the following syntax:

Output := Input 1 + Input 2 + Input 3;

Again, where Output, Input 1, Input 2 and Input 3 are defined as variables earlier in the ST Program.

DIV
Function Name | DIV
ST Operator | /
Description | The output is the result of Input 1 divided by Input 2. On a Function Block Diagram, Input 1 is the top input and Input 2 is the bottom input.
Arguments | Input 1 {ANY_NUM} Input 2 {ANY_NUM} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as Input 1} The value of Input 1 divided by Input 2. The type of output is dependent on the inputs.

NOTE: For integer inputs, the output is the same as Input 1 except that the fractional part of the value is discarded.

Examples:

Function Block Diagram - DIV:

Input 1 is 10 (the top input) and Input 2 is 5 (the bottom input). The output is 5 as 10 divided by 5 is 2.

ST Program - DIV:

The DIV function is used to provide the result of Input 1 divided by Input 2.

Output := Input 1 / Input 2;

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. In this case, let's assume Input 1 is 60 and Input 2 is 10. The DIV function returns 6 as 60/10=6.

Alternatively, the same calculation can be made by using the following syntax:

Output := DIV (Input 1, Input 2);

EXPT
Function Name | EXPT (Exponential)
ST Operator | **
Description | The output is Input 1 to the power of Input 2. On Function Block Diagrams, the top input is Input 1 and the bottom input is Input 2.
Arguments | Input 1 {ANY_NUM} Input 2 {ANY_NUM} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as Input 1} The Output = Input 1 to the power of Input 2.

Examples:

Function Block Diagram - EXPT:

The output is the top input to the power of the bottom input. So, if the top input is 3 and the bottom input is 2, the output is 32 (3X3=9).

ST Program - EXPT:

The EXPT function outputs Input 1 to the power of Input 2.

Output := EXPT (Input 1, Input 2);

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. In this case, let's assume Input 1 is 10 and Input 2 is 6. The Expt function returns 1000000 as 106=1000000.

MOD
Function Name | MOD (Modulo)
ST Operator | MOD
Description | The output is the modulo result of a division (the remainder of a division). For the MOD function, Input 1 is divided by Input 2 and the remainder is the output. In Function Block Diagrams, Input 1 is the top input and Input 2 is the bottom input.
Arguments | Input 1 {ANY_INT} Input 2 {ANY_INT} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {INT} The Output = The remainder of Input 1 / Input 2

Examples:

Function Block Diagram - MOD:

Input 1 is 5 and Input 2 is 2. This means that the MOD function provides an output of 1 as 5/2 = 2 with 1 remaining.

ST Program - MOD:

The MOD function outputs the remainder from Input 1 divided by Input 2.

Output := MOD (Input 1, Input 2);

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. In this case, let's assume Input 1 is 10 and Input 2 is 3. The MOD function returns 1 as 10/3=3 with 1 remaining.

MOVE
Function Name | MOVE
ST Operator | :=
Description | The input is moved to the output. This is especially useful when used with the EN and ENO expressions as it allows the input to be moved to the output depending on the state of a boolean input (see Using EN and ENO to Control when a Function is Performed).
Arguments | Input 1 {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {ANY} The Output = Input 1

Example:

Function Block Diagram - MOD:

A MOVE function is used to output a specific value when a defined input is True. To achieve this, an EN expression is used with the MOVE function. The EN expression uses a Boolean input from a direct input variable (PumpAlarm). The 'normal' input for the MOVE function has a constant input of 3. When the direct input variable is in State 1 (True), the constant value is moved to the output (so the output is 3). When the input variable is in State 0 (false), the output is 0.

In an ST Program there is no need to use a MOVE function as the same result can be achieved by using an IF-THEN statement.

MUL
Function Name | MUL (Multiply)
ST Operator | *
Description | Multiplies the inputs to provide the output.
Arguments | Input 1 - Input n {ANY_NUM} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as input} The Output = Input 1 x Input 2 x Input 3 and so on.

Examples:

Function Block Diagram - MUL:

The output is the result of the top input multiplied by the bottom input. So, if the top input is 2 and the bottom input is 19, the output is 38 (2 x 19=38).

ST Program - MUL:

The MUL function is used to provide the result of Input 1 divided by Input 2:

Output := Input 1 * Input 2;

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. In this case, let's assume Input 1 is 60 and Input 2 is 10. The DIV function returns 600 as 60 x 10=600 (the asterisk * represents the MUL function).

When there are more than 2 inputs, it is more efficient to use the following syntax:

Output := MUL (Input 1, Input 2, Input 3, Input 4 and so on);

For example:

Output := MUL (12, 4, 32, 6);

This would return 9126 as this is the result of 12 x 4 x 32 x 6.

SUB
Function Name | SUB (Subtract)
ST Operator | -
Description | Outputs the result of Input 1 minus Input 2.
Arguments | Input 1 {ANY_MAGNITUDE} Input 2 {ANY_MAGNITUDE} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as input} The Output = Input 1 - Input 2.

Examples:

Function Block Diagram - SUB:

The output is the result of the top input minus the bottom input. So, if the top input is 7 and the bottom input is 5, the output is 2 (7-5=2).

ST Program - SUB:

The SUB function is used to provide the result of Input 1 minus Input 2:

Output := Input 1 - Input 2;

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. In this case, let's assume Input 1 is 17 and Input 2 is 10. The SUB function returns 7 as 17 -10 = 7.

The same effect can be achieved by using the following syntax:

Output := SUB (Input 1, Input 2);


Logic Guide - Bit String (Built-in Functions, Function Blocks, and Conversions)

Bit String

Bit String functions allow you to manipulate the bits of binary inputs. The Bit String functions include:

  • ROL
  • ROR
  • SHL
  • SHR.

ROL
Function Name | ROL (Rotate Left)
Description | Rotates each bit n positions to the left. So, rotating by 1 means the first bit in the string becomes the last bit in the string, the second bit becomes the new first bit and so on.
Arguments | IN {ANY_BIT} IN is a bit string. N {ANY_INT} N is an integer that defines the number of positions the ROL function will move the characters. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as input} The Output is the number that represents the new binary string.

Examples:

Function Block Diagram - ROL:

The ROL function has two inputs. The top input (IN) is 146 which corresponds to the binary string of 10010010. The bottom input (N) is 3 which instructs the function to rotate the bits left by 3 positions. The output is 148 which corresponds to the binary string 10010100. So, the ROL function has rotated the bits 3 positions to the left:
Input String | 10010010
Rotation Left x3 | 10010100

ST Program - ROL:

The ROL function is used to rotate the positions of the bits in the Input string to the left:

Output := ROL (IN, N);

Where Output, IN and N are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := ROL (IN:= 146, N:= 3);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example).

ROR
Function Name | ROR (Rotate Right)
Description | Rotates each bit n positions to the right. So, rotating by 1 means the first bit in the string becomes the second bit in the string, the second bit becomes the third bit and so on. The last bit becomes the new first bit in the string.
Arguments | IN {ANY_BIT} IN is a bit string. N {ANY_INT} N is an integer that defines the number of positions the ROR function will move the characters. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as input} The Output is the number that represents the new binary string.

Examples:

Function Block Diagram - ROR:

The ROR function has two inputs. The top input (IN) is 146 which corresponds to the binary string of 10010010. The bottom input (N) is 3 which instructs the function to rotate the bits right by 3 positions. The output is 84 which corresponds to the binary string 10010100.

So, the rotate right function has rotated the bits 3 positions to the right:
Input String | 10010010
Rotation Right x3 | 10100100

The binary string that results from 3 rotations right is 01010010 which corresponds to the decimal value of 84. So the value of the output is 84.

ST Program - ROR:

The ROR function is used to rotate the positions of the bits in the Input string to the right:

Output := ROR (IN, N);

Where Output, IN, and N are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := ROR (IN:= 146, N:= 3);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example).

SHL
Function Name | SHL (Shift Left)
Description | Moves each bit n positions to the left, losing any characters that are moved from the start of the string and replacing them with 0s at the end. So, if the string is shifted 2 positions to the left, the first two bits are removed and two extra 0s are added to the end of the string to replace them.
Arguments | IN {ANY_BIT} Input 1 is a bit string. N {ANY_INT} N is an integer that defines the number of positions the SHL function will move the characters. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as input} The Output is the number that represents the new binary string.

Examples:

Function Block Diagram - SHL:

The SHL function has two inputs. The top input (IN) is 146 which corresponds to the binary string of 10010010. The bottom input (N) is 3 which instructs the function to shift the bits left by 3 positions. The output is 144 which corresponds to the binary string 10010000.

So, the shift left function has deleted the first 3 bits and added 3 zeros to the end of the string:
Input String | 10010010
Shift Left x3 | 10010000

The binary string that results from 3 shifts left is 10010000 which corresponds to the decimal value of 84. So the value of the output is 84.

ST Program - SHL:

The SHL function is used to shift the positions of the bits in the Input string to the left, losing any characters that are shifted from the start of the string and replacing them with zeros at the end of the string:

Output := SHL (IN, N);

Where Output, IN, and N are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := SHL (IN:= 146, N:= 3);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example).

SHR
Function Name | SHR (Shift Right)
Description | Moves each bit n positions to the right, losing any characters that are moved from the end of the string and replacing them with 0s at the start. So, if the string is shifted 2 positions to the right, the last two bits are removed and two extra 0s are added to the start of the string to replace them.
Arguments | IN {ANY_BIT} IN is a bit string. N {ANY_INT} N is an integer that defines the number of positions the SHR function will move the characters. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as input} The Output is the number that represents the new binary string.

Examples:

Function Block Diagram - SHR:

The SHR function has two inputs. The top input (IN) is 146 which corresponds to the binary string of 10010010. The bottom input (N) is 3 which instructs the function to shift the bits right by 3 positions. The output is 18 which corresponds to the binary string 10010.

So, the shift right function has deleted the last 3 bits and added 3 zeros to the start of the string:
Input String | 10010010
Shift Right x3 | 00010010

The leading zeros are ignored and so the binary string that results from 3 shifts left is 10010 which corresponds to the decimal value of 18. So the value of the output is 18.

ST Program - SHR:

The SHR function is used to shift the positions of the bits in the Input string to the right, losing any characters that are shifted from the end of the string and replacing them with zeros at the start of the string:

Output := SHR (IN, N);

Where Output, IN and N are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := SHR (IN:= 146, N:= 3);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example).


Logic Guide - Bitwise/Boolean (Built-in Functions, Function Blocks, and Conversions)

Bitwise/Boolean

The Bitwise/Boolean functions allow you to manipulate boolean values. You can use the functions to create conditions that affect the flow of the Logic program.

The Bitwise/Boolean functions are used to determine an output based on 2 inputs (except for the NOT function, which has a single input). The Bitwise/Boolean functions are:

  • AND
  • NOT
  • OR
  • XOR.

For Bitwise, the functions are applied to the inputs. The function is applied to the two corresponding bits. For example, if the AND function is used with the following inputs:

Input 1: 011011
Input 2: 101101

The result is 001001. This works by applying the AND function to the corresponding bits. So, as the last two bits on each line are both 1, the result of adding those bits is 1 (true). The last but one bits on each line are 1 and 0, so the result is 0 (false) as both inputs are not true.

AND
Function Name | AND
Description | Outputs a Boolean value. The output is True if both inputs are true; if either input is False, the AND function has a False output.
Arguments | Input 1 to Input n {ANY_BIT} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as input} If any of the inputs is False, the output is False. The output is only True if each of the inputs is True.

Examples:

Function Block Diagram - AND:

A Function Block Diagram has two Boolean inputs: FlowPresent and StopPump. The AND function only outputs a True value if both the FlowPresent and StopPump values are True. If either of the input values are False, the AND function outputs a False value.

ST Program - AND:

The AND function is used to provide a Boolean value that is only True if both inputs are True. The syntax for an AND function in an ST Program is:

Output := AND (Input 1, Input 2);

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Both Input 1 and Input 2 are Boolean inputs.

NOT
Function Name | NOT
Description | Outputs the opposite value to the input.
Arguments | Input 1 {BOOL} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} If Input 1 is True, the Output is False If Input 1 is False, the Output is True.

Examples:

Function Block Diagram - NOT:

An input named 'FlowPresent' provides a Boolean value. When True, it means that a sensor has detected a flow; when False, the sensor has not detected a flow.

The NOT function returns the opposite value to the input, so if the 'FlowPresent' input is True, the NOT function returns a False value. If the 'FlowPresent' input is False, the NOT function returns a True value.

ST Program - NOT:

The NOT function is used to provide a Boolean value that is True if the input is False, and False if the input is True. The syntax for a NOT function in an ST Program is:

Output := NOT (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. Input 1 is a Boolean input and Output is also a Boolean value.

OR
Function Name | OR
Description | Outputs a True value when any of its inputs are True.
Arguments | Input 1 to Input n {ANY_BIT} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} If any of the inputs is True, the output is True. The output is only False if each of the inputs is False.

Examples:

Function Block Diagram - OR:

An OR function has 2 inputs - Input 1 is from a flow sensor and is named 'FlowPresent' and Input 2 is from a Pump control and is named 'StopPump'. When the function receives a True input from either 'FlowPresent' or 'StopPump' it outputs a True value. The output is only False if all of its inputs are False

ST Program - OR:

The OR function is used to provide a Boolean value that is True if any of its inputs are True. The syntax for an OR function in an ST Program is:

Output := OR (Input 1, Input n);

Where Output, Input 1 and Input n are defined as variables earlier in the ST program. Each input is separated by a comma and is a Boolean. The Output value is also a Boolean.

XOR
Function Name | XOR
Description | Outputs a True value when its inputs are not the same i.e. it has True and False inputs.
Arguments | Input 1 to Input n {ANY_BIT} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} The output is True if it has different inputs. It is only False if its inputs are all True or all False.

Examples:

Function Block Diagram - XOR:

An XOR function has 2 inputs - Input 1 is from a flow sensor and is named 'FlowPresent' and Input 2 is from a Pump control and is named 'StopPump'. When the function receives a True input from 'FlowPresent' and a False input from 'StopPump' it outputs a True value (as it has different input values). Similarly, when it receives a False value from 'FlowPresent' and a True value from 'StopPump' it outputs a True value.

If the 'FlowPresent' value is True and the 'StopPump' value is True, the output is False as the XOR function does not have different inputs. Similarly, if both of the input values are False, the output is False. The output is only True when the XOR function has both True and False inputs.

ST Program - XOR:

The XOR function is used to provide a Boolean value that is True only when the function has True and False inputs. If the inputs are the same (all True or all False), the output is False. The syntax for an XOR function in an ST Program is:

Output := XOR (Input 1, Input n);

Where Output, Input 1 and Input n are defined as variables earlier in the ST program. Each input is separated by a comma and is a Boolean. The Output value is also a Boolean.

Alternatively, you can also use this syntax:

Output := Input 1 XOR Input 2;


Logic Guide - Comparison (Built-in Functions, Function Blocks, and Conversions)

Comparison

You can use the COMPARISON functions to manipulate the flow of a program. For example, you can use an EQ function set a part of a program to be performed only if both of its input values are the same. This means that you can control whether the program, or parts of the program, run in different situations.

The available COMPARISON functions are:

  • EQ
  • LE
  • LT
  • GE
  • GT
  • NE.

EQ
Function Name | EQ (Equal To)
Description | Outputs a True value when its inputs are equal in value.
Arguments | Input 1 to Input n {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} The output is True only if the input values are equal in value.

Examples:

Function Block Diagram - EQ:

An EQ function has 2 inputs (in this case, 2 constant values). Both of the constants are set to 2, and so are equal. As the EQ's inputs are the same, its output is True.

If the top input was changed to 4, the EQ function would output a False value—it can only output a True value if all of its inputs are exactly the same.

ST Program - EQ:

The syntax for an EQ function in an ST Program is:

Output := EQ (Input 1, Input n);

Where Output, Input 1 and Input n are defined as variables earlier in the ST program. Each input is separated by a comma and is a Boolean. The Output value is also a Boolean.

Alternatively, you can use an operator:

Output := (Input 1=Input n);

This syntax is more commonly used with IF statements, for example, IIF (Input 1 = Input 2).

LE
Function Name | LE (Less Than or Equal To)
Description | Outputs a True value when Input 1 is less than or equal to the other inputs.
Arguments | Input 1 to Input n {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} The output is True only if Input 1 is less than or equal to the other input values. If Input 1 is greater than any of the other inputs, the LE function outputs a False value.

Examples:

Function Block Diagram - LE:

An LE function has 2 inputs (in this case, 2 constant values). Input 1 is has a value of 2 and Input 2 has a value of 4. The LE function outputs a True value as Input 1 is less than or equal to the other inputs.

If Input 1 was changed to have a value of 4, the LE would still output a True value as Input 1 would be equal to Input 2. It is only when Input 1 is greater than the other Inputs that the LE function outputs a False value.

ST Program - LE:

The syntax for an LE function in an ST Program is:

Output := LE (Input 1, Input n);

Where Output, Input 1 and Input n are defined as variables earlier in the ST program. Each input is separated by a comma and is a Boolean. The Output value is also a Boolean.

Alternatively, you can use an operator:

Output := (Input 1 <= Input n);

LT
Function Name | LT (Less Than)
Description | Outputs a True value when Input 1 is less than the other inputs.
Arguments | Input 1 to Input n {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} The output is True only if Input 1 is less than the other input values. If Input 1 is greater than or equal to any of the other inputs, the LT function outputs a False value.

Examples:

Function Block Diagram - LT:

An LT function has 2 inputs (in this case, 2 constant values). Input 1 is has a value of 2 and Input 2 has a value of 4. The LT function outputs a True value as Input 1 is less than the other inputs.

If Input 1 was changed to have a value of 4, the LE function would output a False value as Input 1 would be equal to Input 2; it would not be less than Input 2. It is only when Input 1 is less than the other Inputs that the LT function outputs a True value.

ST Program - LT:

The syntax for an LT function in an ST Program is:

Output := LT (Input 1, Input n)

Where Output, Input 1 and Input n are defined as variables earlier in the ST program. Each input is separated by a comma and is a Boolean. The Output value is also a Boolean.

Alternatively, you can use an operator:

Output := (Input 1 < Input n);

GE
Function Name | GE (Greater Than or Equal To)
Description | Outputs a True value when Input 1 is greater than or equal to the other inputs.
Arguments | Input 1 to Input n {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} The output is True only if Input 1 is greater than or equal to the other input values. If Input 1 is less than any of the other inputs, the GE function outputs a False value.

Examples:

Function Block Diagram - GE:

A GE function has 2 inputs (in this case, 2 constant values). Input 1 is has a value of 4 and Input 2 has a value of 2. The GE function outputs a True value as Input 1 is greater than the other inputs.

If Input 2 was changed to have a value of 4, the GE function would output a True value as Input 1 would be equal to Input 2. If Input 2 was changed to 5 instead of 4, the GE function would output a False value as it would not be greater than or equal to Input 2.

ST Program - GE:

The syntax for a GE function in an ST Program is:

Output := GE (Input 1, Input n)

Where Output, Input 1 and Input n are defined as variables earlier in the ST program. Each input is separated by a comma and is a Boolean. The Output value is also a Boolean.

Alternatively, you can use an operator:

Output := (Input 1 >= Input n);

GT
Function Name | GT (Greater Than)
Description | Outputs a True value when Input 1 is greater than the other inputs.
Arguments | Input 1 to Input n {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} The output is True only if Input 1 is greater than the other input values. If Input 1 is less than or equal to any of the other inputs, the GT function outputs a False value.

Examples:

Function Block Diagram - GT:

A GT function has 2 inputs (in this case, 2 constant values). Input 1 is has a value of 4 and Input 2 has a value of 2. The GT function outputs a True value as Input 1 is greater than the other inputs.

If Input 2 was changed to have a value of 4, the GT function would output a False value as Input 1 would be equal to Input 2; it would not be greater than Input 2. It is only when Input 1 is greater than the other Inputs that the GT function outputs a True value.

ST Program - GT:

The syntax for a GT function in an ST Program is:

Output := GT (Input 1, Input n)

Where Output, Input 1 and Input n are defined as variables earlier in the ST program. Each input is separated by a comma and is a Boolean. The Output value is also a Boolean.

Alternatively, you can use an operator:

Output := (Input 1 > Input n);

NE
Function Name | NE (Not Equals)
Description | Outputs a True value when Input 1 is different to Input 2.
Arguments | Input 1 {ANY} Input 2 {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {BOOL} The output is True only if Input 1 is different to Input 2. If Input 2 has the same value as Input 1, the NE function outputs a False value.

Examples:

Function Block Diagram - NE:

An NE function has 2 inputs (in this case, 2 constant values). Input 1 is has a value of 4 and Input 2 has a value of 2. The NE function outputs a True value as Input 1 is different to Input 2.

If Input 2 was changed to have a value of 4, the NE function would output a False value as Input 1 would be equal to Input 2. It is only when Input 1 is different to Input 2 that the NE function outputs a True value.

ST Program - NE:

The syntax for a NE function in an ST Program is:

Output := NE (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Each input is separated by a comma and is a Boolean. The Output value is also a Boolean.


Logic Guide - Date and Time (Built-in Functions, Function Blocks, and Conversions)

Date and Time

You can use the Date and Time functions to manipulate date and time values, for example, you can create an output that consists of separate date and time inputs.

The available Date and Time functions are:

  • ADD_DT_TIME
  • ADD_TOD_TIME
  • CONCAT_D_TOD
  • DIVTIME
  • DT_TO_DATE
  • DT_TO_TOD
  • EXTRACT_DT_YEAR
  • EXTRACT_DT_MONTH
  • EXTRACT_DT_DAY
  • EXTRACT_DT_HOUR
  • EXTRACT_DT_MINUTE
  • EXTRACT_DT_SECOND
  • EXTRACT_DT_MILLISECOND
  • MULTIME
  • NOW
  • SUB_DATE_DATE
  • SUB_DT_DT
  • SUB_DT_TIME
  • SUB_TOD_TIME
  • SUB_TOD_TOD
  • MAKE_DATE_AND_TIME
  • MAKE_DATE
  • MAKE_TIME_OF_DAY
  • MAKE_TIME
  • MAKE_DATE_AND_TIME_FROM_OPC
  • MAKE_TIME_FROM_OPC
  • UTC_TO_LOCAL
  • LOCAL_TO_UTC.

ADD_DT_TIME
Function Name | ADD_DT_TIME
Description | Adds a date and time input to a time interval input and outputs the result.
Arguments | Input 1 {DATE_AND_TIME} Input 2 {TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE_AND_TIME}

Examples:

Function Block Diagram - ADD_DT_TIME:

An ADD_DT_TIME function has two inputs:

  • Input 1 is a date and time value (in this case, a NOW function which provides the current date and time)
  • Input 2 is a constant with a time value of T#10m (10 minutes).

NOTE: You can use the UTC_TO_LOCAL function to convert the NOW input from UTC time to Local time.

The ADD_DT_TIME function adds the time interval defined by Input 2 (10 minutes) to the NOW time, and outputs the result. So, if the NOW time is 2006-03-21-09:27.31.546, the ADD_DT_TIME function adds 10 minutes to that time and outputs 2006-03-21-09:37.31.546.

ST Program - ADD_DT_TIME:

The syntax for an ADD_DT_TIME function in an ST Program is:

Output := ADD_DT_TIME (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Each input is separated by a comma. Output and Input 1 are Date and Time values and Input 2 is a Time value (it defines an interval).

Further Information

Time Zones: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.

ADD_TOD_TIME
Function Name | ADD_TOD_TIME
Description | Adds a time interval to a specified time of day.
Arguments | Input 1 {TIME_OF_DAY} Input 2 {TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME_OF_DAY} The output is the Time of Day provided by Input 1 + the Time interval provided by Input 2.

Examples:

Function Block Diagram - ADD_TOD_TIME:

An ADD_TOD_TIME function has 2 inputs (in this case, the inputs are constants):

  • Input 1 defines 10:10:00 as a Time of Day value (TOD#)
  • Input 2 defines 10 minutes as a Time interval value (T#).

The ADD_TOD_TIME function adds the 10 minute time interval to the 10:10:00 time of day value and outputs the result: 10:20:00.000

ST Program - ADD_TOD_TIME:

The syntax for an ADD_TOD_TIME function in an ST Program is:

Output := ADD_TOD_TIME (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Each input is separated by a comma. Output and Input 1 are Time of Day values and Input 2 is a Time value (it defines an interval).

CONCAT_D_TOD
Function Name | CONCAT_D_TOD
Description | Combines a date input with a time of day input to provide a date time output.
Arguments | Input 1 {DATE} Input 2 {TIME_OF_DAY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE_AND_TIME} The output is the Date provided by Input 1 + the Time of Day provided by Input 2.

Examples:

Function Block Diagram - CONCAT_D_TOD:

A CONCAT_D_TOD function has 2 inputs (in this case, the inputs are constants):

  • Input 1 defines 2006-03-11 as a Date value (D#)
  • Input 2 defines 10:10:00 as a Time of Day value (TOD#).

The CONCAT function concatenates the date value and time of day value. The result is a Date and Time output of 2006-03-11-10:10:00.000

ST Program - CONCAT_D_TOD:

The syntax for a CONCAT_D_TOD function in an ST Program is:

Output := CONCAT_D_TOD (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Each input is separated by a comma. Input 1 is a Date value, Input 2 is a Time of Day value and the Output is a Date and Time value.

DIVTIME
Function Name | DIVTIME
Description | Provides a time interval output that is the result of a time interval input divided by an integer input.
Arguments | Input 1 {TIME} Input 2 {INT} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME} The output is the result of Input 1/Input 2.

Examples:

Function Block Diagram - DIVTIME:

A DIVTIME function has 2 inputs (in this case, the inputs are constants):

  • Input 1 is a time value and is set to 59h (59 hours)
  • Input 2 is an integer and is set to 4.

The DIVTIME function divides 59 hours by 4 to provide the output of 14h45m (14 hours and 45 minutes).

ST Program - DIVTIME:

The syntax for a DIVTIME function in an ST Program is:

Output := DIVTIME (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Each input is separated by a comma. Input 1 is a Time value, Input 2 is an integer value and the Output is a Time value.

DT_TO_DATE
Function Name | DT_TO_DATE
Description | Converts a Date and Time input into a Date output (the output will not include a time).
Arguments | Input 1 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE} The output is the result of Input 1 - the Time supplied by Input 1.

Examples:

Function Block Diagram - DT_TO_DATE:

A DT_TO_DATE function has an input of NOW. This sets the input to be the current date and time. The DT_TO_DATE function returns the date part of the input as its output.

ST Program - DT_TO_DATE:

The syntax for a DT_TO_DATE function in an ST Program is:

Output := DT_TO_DATE (Input 1)

Where Output is a Date value and Input 1 is a Date and Time value.

DT_TO_TOD
Function Name | DT_TO_TOD
Description | Converts a Date and Time input into a Time of Day output (the output will not include a date).
Arguments | Input 1 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME_OF_DAY} The output is the result of Input 1 - the Date supplied by Input 1.

The DT_TO_TOD function works in a similar way to the DT_TO_DATE function except that it determines its output by using Time part of the Date and Time input instead of the Date part. For ST Programs, a similar syntax is used:

Output := DT_TO_TOD (Input 1)

EXTRACT_DT_YEAR
Function Name | EXTRACT_DT_YEAR
Description | Converts a Date and Time input into an integer output for the year.
Arguments | Input 1 {DATE_AND_TIME}
Returns | Output {INT} The output is the year part of the Date and Time input.

Examples:

Function Block Diagram - EXTRACT_DT_YEAR:

An EXTRACT_DT_YEAR function has an input of NOW. This sets the input to be the current date and time. The EXTRACT_DT_YEAR function returns the year part of the date in the Date and Time input as its output. So, if the date and time value of the input was 2006-03-21-10:25:00.000, the EXTRACT_DT_YEAR function would return 2006 (the year part of the Date and Time input).

ST Program - EXTRACT_DT_YEAR:

The syntax for an EXTRACT_DT_YEAR function in an ST Program is:

Output := EXTRACT_DT_YEAR (Input 1)

Where Output is an integer value and Input 1 is a Date and Time value.

EXTRACT_DT_MONTH
Function Name | EXTRACT_DT_MONTH
Description | Converts a Date and Time input into an integer output for the month.
Arguments | Input 1 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {INT} The output is the month part of the Date and Time input.

The EXTRACT_DT_MONTH function works in the same way as the EXTRACT_DT_YEAR function except that it returns an integer that is formed from the month part of the Date and Time input instead of the year part. For ST Programs, a similar syntax is used:

Output := EXTRACT_DT_MONTH (Input 1)

EXTRACT_DT_DAY
Function Name | EXTRACT_DT_DAY
Description | Converts a Date and Time input into an integer output for the day.
Arguments | Input 1 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {INT} The output is the day part of the Date and Time input.

The EXTRACT_DT_DAY function works in the same way as the EXTRACT_DT_YEAR function except that it returns an integer that is formed from the day part of the Date and Time input instead of the year part. For ST Programs, a similar syntax is used:

Output := EXTRACT_DT_DAY (Input 1)

EXTRACT_DT_HOUR
Function Name | EXTRACT_DT_HOUR
Description | Converts a Date and Time input into an integer output for the hour.
Arguments | Input 1 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {INT} The output is the hour part of the Date and Time input.

The EXTRACT_DT_HOUR function works in the same way as the EXTRACT_DT_YEAR function except that it returns an integer that is formed from the hour part of the Date and Time input instead of the year part. For ST Programs, a similar syntax is used:

Output := EXTRACT_DT_HOUR (Input 1)

EXTRACT_DT_MINUTE
Function Name | EXTRACT_DT_MINUTE
Description | Converts a Date and Time input into an integer output for the minute.
Arguments | Input 1 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {INT} The output is the minute part of the Date and Time input.

The EXTRACT_DT_MINUTE function works in the same way as the EXTRACT_DT_YEAR function except that it returns an integer that is formed from the minute part of the Date and Time input instead of the year part. For ST Programs, a similar syntax is used:

Output := EXTRACT_DT_MINUTE (Input 1)

EXTRACT_DT_SECOND
Function Name | EXTRACT_DT_SECOND
Description | Converts a Date and Time input into an integer output for the second.
Arguments | Input 1 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {INT} The output is the second part of the Date and Time input.

The EXTRACT_DT_SECOND function works in the same way as the EXTRACT_DT_YEAR function except that it returns an integer that is formed from the second part of the Date and Time input instead of the year part. For ST Programs, a similar syntax is used:

Output := EXTRACT_DT_SECOND (Input 1)

EXTRACT_DT_MILLISECOND
Function Name | EXTRACT_DT_MILLISECOND
Description | Converts a Date and Time input into an integer output for the millisecond.
Arguments | Input 1 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {INT} The output is the millisecond part of the Date and Time input.

The EXTRACT_DT_MILLISECOND function works in the same way as the EXTRACT_DT_YEAR function except that it returns an integer that is formed from the milliseconds part of the Date and Time input instead of the year part. For ST Programs, a similar syntax is used:

Output := EXTRACT_DT_MILLISECOND (Input 1)

MULTIME
Function Name | MULTIME
Description | Outputs a time interval value that is the result of a time interval value multiplied by an integer value.
Arguments | Input 1 {TIME} Input 2 {INT} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME}

Examples:

Function Block Diagram - MULTIME:

A GT function has 2 inputs (in this case, 2 constant values). Input 1 is has a time value of 59 hours (TIME#59h) and Input 2 has an integer value of 4. The MULTIME function outputs a time value of 9d20h as this is the result of 59 hours multiplied by 4.

ST Program - MULTIME:

The syntax for a MULTIME function in an ST Program is:

Output := MULTIME (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Input 1 is a time value, Input 2 is an integer value, and the Output is a time value.

NOW
Function Name | NOW
Description | Outputs the current date and time (taken from the server when the Logic program executes)
Arguments | None.
Returns | Output {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.

Examples:

Function Block Diagram - NOW:

A NOW function can be used as an input for other functions, for example, as an input for an ADD_DT_TIME function. The NOW function provides the current date and time.

ST Program - NOW:

The syntax for a NOW function in an ST Program is:

Output := NOW()

The NOW function can also be used in place of a Date and Time Input in an ST Program:

Output := ADD_DT_TIME (NOW, Input 2)

Where Output and Input 2 are defined as variables earlier in the ST program. The NOW function replaces Input 1 (it provides the current date and time for Input 1).

SUB_DATE_DATE
Function Name | SUB_DATE_DATE
Description | Subtracts an date input from another date input to provide a time output.
Arguments | Input 1 {DATE} Input 2 {DATE} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME} The Output is the result of Input 1 - Input 2

Examples:

Function Block Diagram - SUB_DATE_DATE:

A SUB_DATE_DATE function has 2 inputs (in this case, 2 constants):

  • Input 1 is set to D#2006-03-30
  • Input 2 is set to D#2005-03-21.

The SUB_DATE_DATE function returns a time value of 374d as 2006-03-30 minus 2005-03-21 = 374 days.

ST Program - SUB_DATE_DATE:

The syntax for a SUB_DATE_DATE function in an ST Program is:

Output := SUB_DATE_DATE (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Input 1 and Input 2 are date and time values and the Output is a time value.

SUB_DT_DT
Function Name | SUB_DT_DT
Description | Subtracts a date time input from another date time input to provide a time output. (It outputs the time difference between the two input dates and times).
Arguments | Input 1 {DATE_AND_TIME} Input 2 {DATE_AND_TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME} The Output is the result of Input 1 - Input 2

Examples:

Function Block Diagram - SUB_DT_DT:

A SUB_DT_DT function has 2 inputs (in this case, a NOW function and a constant):

  • Input 1 is connected to a NOW function
  • Input 2 is set to DT#2002-03-11-10:00:25.431.

The SUB_DATE_DATE function returns a time value that is the result of the current date and time - 2002-03-11-10:00:25.431.

ST Program - SUB_DT_DT:

The syntax for a SUB_DT_DT function in an ST Program is:

Output := SUB_DT_DT (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Input 1 and Input 2 are date and time values and the Output is a time value.

SUB_DT_TIME
Function Name | SUB_DT_TIME
Description | Subtracts a time input from a date time input to provide a date time output.
Arguments | Input 1 {DATE_AND_TIME} Input 2 {TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE_AND_TIME} The Output is the result of Input 1 - Input 2

Examples:

Function Block Diagram - SUB_DT_TIME:

A SUB_DT_TIME function has 2 inputs (in this case, a NOW function and a constant):

  • Input 1 is connected to a NOW function
  • Input 2 is set to T#45m.

The SUB_DT_TIME function returns a date time value that is the result of the current date and time - 45 minutes.

ST Program - SUB_DT_TIME:

The syntax for a SUB_DT_TIME function in an ST Program is:

Output := SUB_DT_TIME (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Input 1 is a date time value, Input 2 is a time value, and the Output is a date and time value.

SUB_TOD_TIME
Function Name | SUB_TOD_TIME
Description | Subtracts a time input from a time of day input to provide a time of day output.
Arguments | Input 1 {TIME_OF_DAY} Input 2 {TIME} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME_OF_DAY} The Output is the result of Input 1 - Input 2

Examples:

Function Block Diagram - SUB_TOD_TIME:

A NOW function is used to provide the current time for a SUB_TOD_TIME function. As the NOW function provides a date time value, a DT_TO_TOD function has to be used to convert the NOW output into a TOD value that can be used as an input by the SUB_TOD_TIME function.

For its other input, the SUB_TOD_TIME function has a constant that is set to T#35m (35 minutes):

The SUB_TOD_TIME function returns a time value that is the result of the current time - 35 minutes.

ST Program - SUB_TOD_TIME:

The syntax for a SUB_TOD_TIME function in an ST Program is:

Output := SUB_TOD_TIME (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Input 1 is a time of day value, Input 2 is a time value, and the Output is a time of day value.

SUB_TOD_TOD
Function Name | SUB_TOD_TOD
Description | Subtracts a time of day input from a time of day input to provide a time output.
Arguments | Input 1 {TIME_OF_DAY} Input 2 {TIME_OF_DAY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME} The Output is the result of Input 1 - Input 2

Examples:

Function Block Diagram - SUB_TOD_TOD:

A NOW function is used to provide the current time for a SUB_TOD_TOD function. As the NOW function provides a date time value, a DT_TO_TOD function has to be used to convert the NOW output into a TOD value that can be used as an input by the SUB_TOD_TOD function.

For its other input, the SUB_TOD_TIME function has a constant that is set to TOD#16:00:23.144:

The SUB_TOD_TIME function returns a time value that is the result of the current time - 16:0023:144 i.e the difference in time between the current time and 16:0023:144.

ST Program - SUB_TOD_TOD:

The syntax for a SUB_TOD_TOD function in an ST Program is:

Output := SUB_TOD_TOD (Input 1, Input 2)

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program. Input 1 is a time of day value, Input 2 is a time of day value, and the Output is a time value.

MAKE_DATE_AND_TIME
Function Name | MAKE_DATE_AND_TIME
Description | Provides a date and time output that is made up from the components supplied via the inputs.
Arguments | Y {INT} Y provides the year. MO {SINT} MO provides the month. D {SINT} D provides the day. H {SINT} H provides the hour. MI {SINT} MI provides the minutes. S {SINT} S provides the seconds. MS {INT} MS provides the milliseconds. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE_AND_TIME}

Examples:

Function Block Diagram - MAKE_DATE_AND_TIME:

The MAKE_DATE_AND_TIME outputs a date time value that is made up from the components supplied via its inputs (the year is taken from the Y input, month from the MO input and so on). On a live system, the inputs for a MAKE_DATE_AND_TIME function are often the results of a calculation, with the inputs being variable depending on the outputs of other functions etc.

ST Program - MAKE_DATE_AND_TIME:

The syntax for a MAKE_DATE_AND_TIME function in an ST Program is:

Output := MAKE_DATE_AND_TIME (Y, MO, D, H, MI, S, MS);

Where Output, Y, MO, D, H, MI, S, and MS are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := MAKE_TIME_AND_TIME (Y:= 2006, MO:= 02, D:= 14, H:= 12, MI:= 41, S:= 21, MS:= 17);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example).

MAKE_DATE
Function Name | MAKE_DATE
Description | Provides a date output that is made up from the components supplied via the inputs.
Arguments | Y {INT} Y provides the year. MO {INT} MO provides the month. D {INT} D provides the day. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE}

Examples:

Function Block Diagram - MAKE_DATE:

The MAKE_DATE outputs a date value that is made up from the components supplied via its inputs (the year is taken from the Y input, month from the MO input, and the day from the D input). On a live system, the inputs for a MAKE_DATE function are often the results of a calculation, with the inputs being variable depending on the outputs of other functions etc.

ST Program - MAKE_DATE:

The syntax for a MAKE_DATE function in an ST Program is:

Output := MAKE_DATE (Y, MO, D);

Where Output, Y, MO, and D are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := MAKE_DATE (Y:= 2006, MO:= 02, D:= 14);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example above).

MAKE_TIME_OF_DAY
Function Name | MAKE_TIME_OF_DAY
Description | Provides a time of day output that is made up from the components supplied via the inputs.
Arguments | The arguments are (from top to bottom): H {INT} H provides the hour. MI {INT} MI provides the minutes. S {INT} S provides the seconds. MS {INT} MS provides the milliseconds. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME_OF_DAY}

Examples:

Function Block Diagram - MAKE_TIME_OF_DAY:

The MAKE_TIME_OF_DAY function outputs a time of day value that is made up from the components supplied via its inputs (the hour is taken from the H input, minute from the MI input, seconds from the S input and the milliseconds from the MS input). On a live system, the inputs for a MAKE_TIME_OF_DAY function are often the results of a calculation, with the inputs being variable depending on the outputs of other functions etc.

ST Program - MAKE_TIME_OF_DAY:

The syntax for a MAKE_TIME_OF_DAY function in an ST Program is:

Output := MAKE_TIME_OF_DAY (H, MI, S, MS);

Where Output, H, MI, S and MS are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := MAKE_TIME_OF_DAY (H:= 18, MI:= 25, S:= 13, MS:= 32);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example above).

MAKE_TIME
Function Name | MAKE_TIME
Description | Provides a time output that is made up from the components supplied via the inputs.
Arguments | The arguments are (from top to bottom): D {INT} D provides the day. H {INT} H provides the hour. MI {INT} MI provides the minutes. S {INT} S provides the seconds. MS {INT} MS provides the milliseconds. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME}

Examples:

Function Block Diagram - MAKE_TIME:

The MAKE_TIME function outputs a time value that is made up from the components supplied via its inputs (the day is taken from the D input, hour from the H input, minute from the MI input, seconds from the S input and the milliseconds from the MS input). On a live system, the inputs for a MAKE_TIME function would most likely be the results of a calculation, with the inputs being variable depending on the outputs of other functions etc.

ST Program - MAKE_TIME:

The syntax for a MAKE_TIME function in an ST Program is:

Output := MAKE_TIME (D, H, MI, S, MS);

Where Output, D, H, MI, S and MS are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := MAKE_TIME (D:= 11, H:= 14, MI:= 32, S:= 21, MS:= 07);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example above).

MAKE_DATE_AND_TIME_FROM_OPC
Function Name | MAKE_DATE_AND_TIME_FROM_OPC
Description | Provides a date and time output that is made up from the input string (which defines a time in the OPC time format). Typically, this input is provided by a value in the database, for example, the TrendOffset tag of a point.
Arguments | Input 1 {STRING - OPC Time Format} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE_AND_TIME}

Examples:

Function Block Diagram - MAKE_DATE_AND_TIME_FROM_OPC:

The MAKE_DATE_AND_TIME_FROM_OPC function provides a date and time value. The output is calculated by using the OPC time provided by the string input. In the example shown above, the V1 input is a tag (the tag represents the TrendOffset configuration property of a point. The TrendOffset is a time value defined in the OPC time format, in this case, M-10M). The MAKE_DATE_AND_TIME_FROM_OPC function uses the OPC time defined in the input string and the current time (on the server) to calculate its output. So, at 09:11:00.000 on April 3rd 2006, the MAKE_DATE_AND_TIME_FROM_OPC function outputs 2006-04-03-09:01:00.000 (the current time - ten minutes from the start of the current minute as defined by the V1 input). Not that the date format used here is YYYY, MM, DD.

ST Program - MAKE_DATE_AND_TIME_FROM_OPC:

The syntax for a MAKE_DATE_AND_TIME_FROM_OPC function in an ST Program is:

Output := MAKE_DATE_AND_TIME_FROM_OPC (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a String that contains a time value in the OPC time format.

MAKE_TIME_FROM_OPC
Function Name | MAKE_TIME_FROM_OPC
Description | Provides a time output that is made up from the input string (which defines a time in the OPC time format). The input may be a value in the database, for example, the TrendUpdateRate tag of a point.
Arguments | Input 1 {STRING - OPC Time Format} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {TIME}

Examples:

Function Block Diagram - MAKE_TIME_FROM_OPC:

The MAKE_TIME_FROM_OPC function outputs a time value that is based on the OPC time provided by the input. In the example shown above, the StringPoint input is a tag (the tag represents the CurrentValueFormatted property of an internal string point). The CurrentValueFormatted of the string point is 2D, so the MAKE_TIME_FROM_OPC function converts the OPC time of the string point into a time value for the ST program: 2d.

ST Program - MAKE_TIME_FROM_OPC:

The syntax for a MAKE_TIME_FROM_OPC function in an ST Program is:

Output := MAKE_TIME_FROM_OPC (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a String that contains a time value in the OPC time format.

UTC_TO_LOCAL
Function Name | UTC_TO_LOCAL
Description | Outputs the time provided by Input 1 in Local time format. This allows the ST program to make adjustments according to local time changes such as British Summer Time. Local time settings are defined by the operating system.
Arguments | Input 1 {DATE_AND_TIME - UTC time format} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE_AND_TIME - Local time format}

Examples:

Function Block Diagram - UTC_TO_LOCAL:

The UTC_TO_LOCAL function converts a date and time input from Universal Coordinated Time into local time. In the example shown above, the UTC_TO_LOCAL function applies the local time settings to the input time and date. In this case, the UTC_TO_LOCAL function takes the input time and adds 1 hour for the output (the local time settings are 1 hour in advance).

ST Program - UTC_TO_LOCAL:

The syntax for a UTC_TO_LOCAL function in an ST Program is:

Output := UTC_TO_LOCAL (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a Date and Time value.

Further Information

Time Zones: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.

LOCAL_TO_UTC
Function Name | LOCAL_TO_UTC
Description | Outputs the local time provided by Input 1 in UTC time format. Local time settings are defined by the operating system.
Arguments | Input 1 {DATE_AND_TIME - Local time format} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DATE_AND_TIME - UTC time format}

Examples:

Function Block Diagram - LOCAL_TO_UTC:

The LOCAL_TO_UTC function converts a date and time input from local time into Universal Coordinated Time. In the example shown above, the LOCAL_TO_UTC function takes the local time input and removes the local time settings to provide an output in UTC. In this case, the LOCAL_TO_UTC function takes the input time and removes 1 hour for the output (the local time settings are 1 hour in advance).

ST Program - LOCAL_TO_UTC:

The syntax for a LOCAL_TO_UTC function in an ST Program is:

Output := LOCAL_TO_UTC (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a Date and Time value.

Further Information

Time Zones: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Logic Guide - Numerical (Built-in Functions, Function Blocks, and Conversions)

Numerical

Numerical functions allow you to calculate values as absolute values, trigonometric values, natural exponential values, base 10 logarithms, natural logarithms, or square root values. You can also truncate a floating point value into an integer.

You should only use the Numerical functions if you have an understanding of the mathematical principles associated with each of the available functions (the functions are named after a mathematical principle).

The numerical functions are:

  • ABS
  • ACOS
  • ASIN
  • ATAN
  • COS
  • EXP
  • LOG
  • LN
  • SIN
  • SQRT
  • TAN
  • TRUNC.

ABS
Function Name | ABS
Description | Converts a numerical input into an absolute value. The absolute value is the output and is also a REAL or LREAL value.
Arguments | Input 1 {ANY_NUM} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {Same data type as input}

Examples:

Function Block Diagram - ABS:

The ABS function converts values into positive values (if the input is positive, the output is positive; if the input is negative, the output is positive). In this example, the constant input is -324 so the ABS function outputs 324.

ST Program - ABS:

The syntax for an ABS function in an ST Program is:

Output := ABS (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents any type of numerical value.

ACOS
Function Name | ACOS
Description | Converts a REAL or LREAL input into an arc cosine (inverse cosine). The arc cosine value is the output and is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. This value has to be between 0 and 1. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}. This value is in radians.

Examples:

Function Block Diagram - ACOS:

In this example, the input of 0.431 is provided by the CurrentValueFormatted property of a point. The ACOS function converts the value into an arc cosine value of 1.12519562771659 and this is used as the output.

ST Program - ACOS:

The syntax for an ACOS function in an ST Program is:

Output := ACOS (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

ASIN
Function Name | ASIN
Description | Converts a REAL or LREAL input into an arc sine (inverse sine). The arc sine value is the output and is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. This value has to be between 0 and 1. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}. This value is in radians.

Examples:

Function Block Diagram - ASIN:

In this example, the input of 0.431 is provided by the CurrentValueFormatted property of a point. The ASIN function converts the value into an arc sine value of 0.445600699078308 and this is used as the output.

ST Program - ASIN:

The syntax for an ASIN function in an ST Program is:

Output := ASIN (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

ATAN
Function Name | ATAN
Description | Converts a REAL or LREAL input into an arc tangent (inverse tangent). The arc sine value is the output and is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}. This value is in radians.

Examples:

Function Block Diagram - ATAN:

In this example, the input of 5 is provided by the CurrentValueFormatted property of a point. The ATAN function converts the value into an arc tangent value of 1.37340076694502 and this is used as the output.

ST Program - ATAN:

The syntax for an ATAN function in an ST Program is:

Output := ATAN (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

COS
Function Name | COS
Description | Converts a REAL or LREAL input into a cosine value that is the output. The cosine value is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. This value is in radians. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}

Examples:

Function Block Diagram - COS:

In this example, the input of 5 is provided by the CurrentValueFormatted property of a point. The COS function converts the value into a cosine value of 0.283662185463226 and this is used as the output.

ST Program - COS:

The syntax for a COS function in an ST Program is:

Output := COS (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

EXP
Function Name | EXP
Description | Converts a REAL or LREAL input into a natural exponential value that is the output. The exponential value is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}

Examples:

Function Block Diagram - EXP:

In this example, the input of 5 is provided by the CurrentValueFormatted property of a point. The EXP function converts the value into an exponential value of 148.413159102577 and this is used as the output.

ST Program - EXP:

The syntax for an EXP function in an ST Program is:

Output := EXP (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

LOG
Function Name | LOG
Description | Converts a REAL or LREAL input into a base 10 logarithm value that is the output. The base 10 logarithm is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}

Examples:

Function Block Diagram - LOG:

In this example, the input of 5 is provided by the CurrentValueFormatted property of a point. The LOG function converts the value into a base 10 logarithm value of 0.698970004336019 and this is used as the output.

ST Program - LOG:

The syntax for a LOG function in an ST Program is:

Output := LOG (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

LN
Function Name | LN
Description | Converts a REAL or LREAL input into a natural logarithm value that is the output. The natural logarithm is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}

Examples:

Function Block Diagram - LN:

In this example, the input of 5 is provided by the CurrentValueFormatted property of a point. The LN function converts the value into a natural logarithm value of 1.6094379124341 and this is used as the output.

ST Program - LN:

The syntax for an LN function in an ST Program is:

Output := LN (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

SIN
Function Name | SIN
Description | Converts a REAL or LREAL input into a sine value that is the output. The sine value is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. This value is in radians. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}.

Examples:

Function Block Diagram - SIN:

In this example, the input of 5 is provided by the CurrentValueFormatted property of a point. The SIN function converts the value into a sine value of -0.958924274663138 and this is used as the output.

ST Program - SIN:

The syntax for a SIN function in an ST Program is:

Output := SIN (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

SQRT
Function Name | SQRT
Description | Outputs the square root value of the input value. Both the input and output values are REAL or LREAL values.
Arguments | Input 1 {REAL or LREAL}. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}

Examples:

Function Block Diagram - SQRT:

In this example, the input of 5 is provided by the CurrentValueFormatted property of a point. The SQRT function outputs the square root of 5 which is 2.23606797749979.

ST Program - SQRT:

The syntax for an SQRT function in an ST Program is:

Output := SQRT (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

TAN
Function Name | TAN
Description | Converts a REAL or LREAL input into a tangent value that is the output. The tangent value is also a REAL or LREAL.
Arguments | Input 1 {REAL or LREAL}. This value is in radians. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {REAL or LREAL}

Examples:

Function Block Diagram - TAN:

In this example, the input of 5 is provided by the CurrentValueFormatted property of a point. The TAN function converts the value into a tangent value of -3.38051500624659.

ST Program - TAN:

The syntax for a TAN function in an ST Program is:

Output := TAN (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).

TRUNC
Function Name | TRUNC
Description | Truncates the floating value of the input into a double integer value. The double integer value is used as the output.
Arguments | Input 1 {REAL or LREAL}. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {DINT}

Examples:

Function Block Diagram - TRUNC:

In this example, the input of 5.75423 is provided by the CurrentValueFormatted property of a point. The TRUNC function truncates the value into a double integer value of 5.

ST Program - TRUNC:

The syntax for a TRUNC function in an ST Program is:

Output := TRUNC (Input 1);

Where Output and Input 1 are defined as variables earlier in the ST program. The Input 1 variable represents a REAL or LREAL type of value (the output is the same type of value as Input 1).


Logic Guide - Selection (Built-in Functions, Function Blocks, and Conversions)

Selection

You can use selection functions to provide a single output from a selection of inputs. One of the inputs is used as the output for the function—the type of function determines which output is used. Selection functions are useful when you need a program to choose an appropriate value from several inputs.

The selection functions are:

  • LIMIT
  • MAX
  • MIN
  • MUX
  • SEL.

LIMIT

Function Name

LIMIT

Description

Outputs a value that is within the limits that are provided by the inputs:

  • If the IN input is less than the MIN input, the output is the same as the MIN input.
  • If the IN input is greater than the MX input, the output is the same as the MX input.
  • If the IN input is greater than the MIN input but less than the MX input, the output is the same as the IN input.

Arguments

MIN {ANY}.

The MIN input defines the minimum value that can be used as the output. This is used as the output if the IN input is less

than the MIN input.

IN {ANY}

The IN input defines the input that is to be used as the output. It is only used if it is greater than the MIN input and less than the MX input.

MX {ANY}

The MX input defines the maximum value that can be used as the output. This is used as the output if the IN input is greater than the MX input.

For more information on the data types for the inputs and outputs, see Data Type Hierarchy.

Returns

Output {ANY} The data type is of the same type as the inputs.

Examples:

Function Block Diagram - LIMIT:

In this example, the inputs are constant values. The IN input is greater than the MIN input and less than the MX input and so is used as the output value. If the IN input was 1, it would be less than the MIN input and so the MIN input would be used as the output instead. Similarly, if the IN input was 10, it would be greater than the MX input and so the output would be 8 as the LIMIT function would use the MX input instead of the IN input.

ST Program - LIMIT:

The syntax for a LIMIT function in an ST Program is:

Output := LIMIT (MIN, IN, MX);

Where Output, MIN, IN, and MX are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := LIMIT (MIN:= 2, IN:= 5, MX:= 8);

Where the numbers are the input values (in this case, they are the same numbers as used in the Function Block Diagram example).

MAX
Function Name | MAX
Description | Outputs the same value as its greatest input.
Arguments | Input 1 - Input n {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {ANY}. The MAX function outputs the same value as its greatest input. The output is of the same type as the input.

Examples:

Function Block Diagram - MAX:

In this example, the inputs are constant values. The MAX function outputs the same value as its highest input. In this case, it has inputs of 2, 5, and 8 and so it outputs 8.

ST Program - MAX:

The syntax for a MAX function in an ST Program is:

Output := MAX (Input 1, Input n);

Where Output, Input 1 and Input n are defined as variables earlier in the ST program.

MIN
Function Name | MIN
Description | Outputs the same value as its lowest input.
Arguments | Input 1 - Input n {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {ANY}. The MIN function outputs the same value as its lowest input. The output is of the same type as the input.

Examples:

Function Block Diagram - MIN:

In this example, the inputs are constant values. The MIN function outputs the same value as its lowest input. In this case, it has inputs of 4 and 5, so it outputs 5.

ST Program - MIN:

The syntax for a MIN function in an ST Program is:

Output := MIN (Input 1, Input n);

Where Output, Input 1 and Input n are defined as variables earlier in the ST program.

MUX

Function Name

MUX

Description

The MUX function outputs the same number as one of its inputs. The input that is chosen is dependent on the value of the K input.

The MUX function has a K input and 2 or more other inputs. The unnamed inputs are recognized as being 0 for the first (top) input, 1 for the second input, 2 for the third input, 3 for the fourth input and so on. The number of the K input is used to identify which of the other inputs has the value that is to be used as the output.

Arguments

K {ANY_INT}.

The number for the K input is used to identify the input that is to be used as the output for the MUX function.

Input 0 - Input n {ANY}

Each input is identified by a number, with the first (top) input being 0, the second being 1, the third being 2 and so on.

For more information on the data types for the inputs and outputs, see Data Type Hierarchy.

Returns

Output {ANY}

The K input is a number. This number is used to identify the input that has the value that is to be used as the output. The output value is of the same type as the value provided by the designated input.

Examples:

Function Block Diagram - MUX:

In this example, the K value is provided by a tag that represents the CurrentValueFormatted property of a point named 'FlowPresent'. As the 'FlowPresent' point is a digital, it provides a Boolean value and this has to be converted into an integer by using a BOOL_TO_INT conversion. The other inputs are provided by constant values, with Input 0 being 4 and Input 1 being 5.

As the current value of the 'FlowPresent' is True, the integer value for the K input is 1. This means that the value for the MUX output is the same as the value for Input 1 which is 5.

ST Program - MUX:

The syntax for a MUX function in an ST Program is:

Output := MUX (K, Input 0, Input n);

Where Output, K, Input 0 and Input n are defined as variables earlier in the ST program.

SEL
Function Name | SEL
Description | The SEL function outputs the same number as one of its inputs. The input that is chosen is dependent on the value of the G input—if G is False, the IN0 value is used as the output; if G is True, the IN1 value is used instead.
Arguments | G {BOOL}. The value of the G input is used to determine whether the output matches the IN0 input or the IN1 input. If the G input is False, the output matches IN0; if the G input is True, the output matches IN1. IN0 {ANY} IN1 {ANY} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {ANY} The output value matches the input value of IN0 or IN1. The value of the G input determines whether IN0 or IN1 is used.

Examples:

Function Block Diagram - SEL:

In this example, the Boolean value for G comes from a tag that references the CurrentValueFormatted property of a digital point named 'FlowPresent'. The IN0 and IN1 values are provided by constants. As the 'FlowPresent' value is True (1), the SEL function outputs the same value as IN1, which in this case is 5.

ST Program - SEL:

It is unlikely that you would use a SEL function in an ST program as the same functionality can be provided by an IF statement. However, if you did choose to use a SEL function, you would need to use this syntax:

Output := SEL (G, IN0, IN1);

Where Output, G, IN0 and IN1 are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := SEL (G:= True, IN0:= 4, IN1:= 5);

Where the True, 4 and 5 values are the input values (in this case, they are the same values as used in the Function Block Diagram example above).


Logic Guide - String (Built-in Functions, Function Blocks, and Conversions)

String

You can use the STRING functions to manipulate strings, for example, you can create a string output that consists of 2 other strings.

The available STRING functions are:

  • CONCAT
  • DELETE
  • ELEMENT
  • FIND
  • INSERT
  • LEFT
  • LEN
  • MID
  • REPLACE
  • RIGHT.

CONCAT
Function Name | CONCAT
Description | The CONCAT function concatenates its inputs. The inputs are strings and the output is a combination of the input strings (the function appends the strings into a single string).
Arguments | Input 1 {STRING} Input n {STRING} For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {STRING} The output is a combination of the input strings.

Examples:

Function Block Diagram - CONCAT:

In this example, the CONCAT function has a string input of 'POINT' and a string input of 'DESC'. The function concatenates the inputs to provide an output of POINTDESC.

ST Program - CONCAT:

To use a CONCAT function in an ST program, you need to use this syntax:

Output := CONCAT (Input 1, Input 2);

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program.

DELETE

Function Name

DELETE

Description

Removes a defined amount of characters from an input string and outputs the remainder of the string.

Arguments

IN {STRING}

The IN input is a string input. It has a specified number of characters removed by the DELETE function then its remaining characters are used as the output.

L {INT}

The L input defines the number of characters that will be removed from the IN input for the output string.

P {INT}

The P input defines the position of the character in the string where the deletion starts (1 is the first character, 2 is the second character, 3 is the 3rd character and so on).

For more information on the data types for the inputs and outputs, see Data Type Hierarchy.

Returns

Output {STRING}

The output is the characters remaining from the IN string (IN string - L characters starting from P).

Examples:

Function Block Diagram - DELETE:

In this example, the IN is ALARMCONDITIONS, the L is 10, the P is 6 and so the output is ALARM. 10 characters have been deleted from the 6th character (inclusive) onwards—CONDITIONS has been removed.

ST Program - DELETE:

To use a DELETE function in an ST program, you need to use this syntax:

Output := DELETE (IN, L, P);

Where Output, IN, L, and P are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := DELETE (IN:= 'ALARMCONDITIONS', L:= 10, P:= 6);

Where the 'ALARMCONDITIONS', 10 and 6 values are the input values (in this case, they are the same values as used in the Function Block Diagram example above).

ELEMENT

Function Name

ELEMENT

Description

The ELEMENT function allows a Logic program to select parts of a string and return the selected parts as a string value. For example, it can be used to return the fourth value in a comma separated list.

Arguments

E {INTEGER}

E is the element number. This specifies the location of the string to be extracted. 1 is the first string in the input string, 2 is the second string in the input string and so on.

Input 1 {STRING}

Input 1 specifies the delimiter (the string that acts as the separator in the full string input). For example, if the string input is a comma separated list, Input 1 will be a comma character as the strings in the input are separated by commas.

Input 2 {STRING}

Input 2 is the string input from which the ELEMENT output will be taken. It consists of one or more values (each of which is also a string) which are separated by a delimiter. Typically, the delimiter is a comma, but it can be any character or characters.

D {INTEGER}

D is the Direction. This specifies the starting position - if D is 0, the starting position is the left of the Input 2 string, which means that the output will be calculated from the left-hand side of the string; if D is any other number, the output is calculated from the right-hand side of the string.

For more information on the data types for the inputs and outputs, see Data Type Hierarchy.

Returns

Output {STRING}

The output is the string that is at the defined position in the input string (which contains many separated string values).

Examples:

Function Block Diagram - ELEMENT:

In this example, the ELEMENT function is used to return one string from a list of four. For the example, the input string is a constant with four values, but you could just as easily map a string containing values from a database to a string variable database item and use the string variable as the source of the input.

The state of a digital point is used as the E input. An ADD function is used to add 1 to the input as the digital point states begin at 0 whereas the element numbers begin at 1.

A string constant is used for IN1. It defines the delimiter as a comma.

A constant is used for the D input. As it is 0, the string position is calculated from the left of the input string.

As the ‘State’ direct variable is 1, the value for E is 2 (the ADD function adds an extra 1). This means that the second string value in the string input will be returned. As D is 0, the second string is counted from the left-hand side of the input string, and so the output of the ELEMENT function is ‘Slow’.

FIND

Function Name

FIND

Description

The FIND function searches for a specific string in a string input. If it locates the specified string, it outputs a number that corresponds to the starting position of the specified string within the input string. As with the other string position numbers, 1 is the first character in the string, 2 is the second, 3 is the third and so on.

Arguments

Input 1 {STRING}

This input is a string input. This is the string in which the FIND function searches for the specified string.

Input 2 {STRING}

This input is also a string input and it is the specified string i.e. the FIND function searches for an instance of the Input 2 string within the Input 1 string.

For more information on the data types for the inputs and outputs, see Data Type Hierarchy.

Returns

Output {DINT}

The output is a number that identifies the starting position of the Input 2 string within the Input 1 string (1 is the first character in the string, 2 is the second, 3 is the third and so on). If the output is 0, the Input 2 string cannot be found within the Input 1 string.

Examples:

Function Block Diagram - FIND:

In this example, Input 1 is 'SENSOROVERRIDE' and Input 2 is 'OVERRIDE'. The FIND function searches in the SENSOROVERIDE input for an instance of OVERRIDE. It locates an instance of OVERRIDE starting at the seventh character in the SENSOROVERRIDE input, and so the FIND function outputs 7.

ST Program - FIND:

To use a FIND function in an ST program, you need to use this syntax:

Output := FIND ('Input 1', 'Input 2');

Where Output, Input 1 and Input 2 are defined as variables earlier in the ST program.

INSERT

Function Name

INSERT

Description

Inserts one string into another string at a specified position, then outputs the result.

Arguments

IN1 {STRING}

The IN1 string is the string that is used as the basis for the output. The IN2 string is inserted into the string provided by the IN1 input.

IN2 {STRING}

The string that is inserted into the string provided by IN1.

P {INT}

Defines the insertion point in the IN1 string into which the IN2 string is inserted. As with the other string position numbers, 1 is the first character in the string, 2 is the second, 3 is the third and so on.

For more information on the data types for the inputs and outputs, see Data Type Hierarchy.

Returns

Output {STRING}

The output is a string that is the result of the IN2 string being inserted into the IN1 string at the position defined by P.

Examples:

Function Block Diagram - INSERT:

In this example, IN1 is 'ALARM', IN2 is 'OVERRIDDEN', and P is 6. The INSERT function takes the 'ALARM' string and inserts the 'OVERRIDDEN' string into it at character 6. It then outputs the resulting string which is ALARMOVERRIDDEN. In this case, the IN2 string has been inserted at the end of the string by defining P as the number after the last character in the IN1 string. If P had been set to 4, the output would have been 'ALAROVERRIDDENM'.

ST Program - INSERT:

To use an INSERT function in an ST program, you need to use this syntax:

Output := INSERT ('Input 1', 'Input 2', P);

Where Output, Input 1, Input 2, and P are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := INSERT (IN1:= 'ALARM', IN2:= 'OVERRIDDEN', P:= 6);

Where the 'ALARM', 'OVERRIDDEN', and 6 values are the input values (in this case, they are the same values as used in the Function Block Diagram example above).

LEFT
Function Name | LEFT
Description | Outputs a specific number of characters taken from a string input. The characters are taken from the left-hand side of the input string (starting with the first character).
Arguments | IN {STRING} The IN input is a string input. The LEFT function uses characters from the IN input for its output. L {INT} Defines the number of characters in the IN input that are used for the output. The output begins with the first character of the IN input and continues for the L amount of characters. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {STRING} The output is a string that is the L number of characters from the IN string, starting from the left.

Examples:

Function Block Diagram - LEFT:

In this example, the IN input is 'PIPELINE STRUCTURE FAILURE' and the L input is 18. This means that the LEFT function will return 18 characters from the IN input, starting with the left-most character (the first character). So, as the IN input is 'PIPELINE STRUCTURE FAILURE', the LEFT function outputs 'PIPELINE STRUCTURE' (the first 18 characters from the IN string).

ST Program - LEFT:

To use a LEFT function in an ST program, you need to use this syntax:

Output := LEFT ('IN', L);

Where Output, IN and L are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := LEFT (IN:= 'PIPELINE STRUCTURE FAILURE', L:= 18);

Where the 'PIPELINE STRUCTURE FAILURE' and 18 values are the input values (in this case, they are the same values as used in the Function Block Diagram example above).

LEN
Function Name | LEN
Description | Outputs the total number of characters in the input string.
Arguments | Input 1 {STRING} The input is a string input. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {INT} The output is the total number of characters in the Input 1 string.

Examples:

Function Block Diagram - LEN:

In this example, the input is 'PIPELINE STRUCTURE FAILURE' and so the LEN output is 26 (there are 26 characters in the input string).

ST Program - LEN:

To use a LEN function in an ST program, you need to use this syntax:

Output := LEN ('Input 1');

Where Output and Input 1 are defined as variables earlier in the ST program.

MID
Function Name | MID
Description | Outputs a specific number of characters taken from a string input. The characters are taken from a specified position in the input string.
Arguments | IN {STRING} The IN input is a string input. The MID function uses characters from the IN input for its output. L {INT} Defines the number of characters in the IN input that are used for the output. P {INT} Defines the starting point for the MID output. The starting point corresponds to a character in the IN string and the MID output will only include a specified number of characters from the starting point onwards. As with the other string position numbers, 1 is the first character in the string, 2 is the second, 3 is the third and so on. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {STRING} The output is a string that is the L number of characters taken from the IN input from the P starting position.

Examples:

Function Block Diagram - MID:

In this example, the IN input is 'PIPELINE', the L input is 4 and the P input is 5. This means that the MID function will return 4 characters from the IN input, starting from the fifth character. So, as the IN input is 'PIPELINE', the MID function outputs 'LINE' (4 characters from the IN input starting from the fifth character from the left).

ST Program - MID:

To use a MID function in an ST program, you need to use this syntax:

Output := MID ('IN', L, P);

Where Output, IN, L and P are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := MID (IN:= 'PIPELINE', L:= 4, P:=5);

Where the 'PIPELINE' 4 and 5 values are the input values (in this case, they are the same values as used in the Function Block Diagram example above).

REPLACE

Function Name

REPLACE

Description

Outputs a specific number of characters taken from a string input. The characters are taken from a specified position in the input string.

Arguments

IN1 {STRING}

The IN1 input is a string input. The REPLACE function uses characters from the IN1 input for its output: it replaces characters from the IN1 input with characters from the IN2 input.

IN2 {STRING}

The IN2 input is a string input. The REPLACE function uses characters from the IN2 input for its output: it replaces characters from the IN1 input with characters from the IN2 input.

L {INT}

Defines the number of characters in the IN1 input that are to be replaced by the characters in the IN2 input.

P {INT}

Defines the starting point for the replacement i.e. the position in the IN1 string where the IN2 characters will be inserted. As with the other string position numbers, 1 is the first character in the string, 2 is the second, 3 is the third and so on.

For more information on the data types for the inputs and outputs, see Data Type Hierarchy.

Returns

Output {STRING}

The output is a string that is the IN1 string with a specified number of its characters replaced by the characters in the IN2 string.

Examples:

Function Block Diagram - REPLACE:

In this example, the IN1 input is 'PIPELINE ALARM', IN2 is 'STATUS', L is 6 and P is 10. This means that the REPLACE function will take the IN1 input, remove 6 characters from character 10 onwards and replace them with 'STATUS'. This provides an output of 'PIPELINE STATUS'.

ST Program - REPLACE:

To use a REPLACE function in an ST program, you need to use this syntax:

Output := REPLACE ('IN1','IN2', L, P);

Where Output, IN1, IN2, L and P are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := REPLACE (IN1:= 'PIPELINE ALARM', IN2:= 'STATUS' L:= 6, P:=10);

Where the 'PIPELINE ALARM', 'STATUS', 6 and 10 values are the input values (in this case, they are the same values as used in the Function Block Diagram example above).

RIGHT
Function Name | RIGHT
Description | Outputs a specific number of characters taken from a string input. The characters are taken from the right-hand side of the input string (ending with the last character).
Arguments | IN {STRING} The IN input is a string input. The RIGHT function uses characters from the IN input for its output. L {INT} Defines the number of characters in the IN input that are used for the output. The output ends with the last character of the IN input and starts the L number of characters prior to the end. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Output {STRING} The output is a string that is the L number of characters from the IN string, starting from the right.

Examples:

Function Block Diagram - RIGHT:

In this example, the IN input is 'PIPELINE STRUCTURE FAILURE' and the L input is 17. This means that the RIGHT function will return 17 characters from the IN input, starting with the right-most character (the last character). So, as the IN input is 'PIPELINE STRUCTURE FAILURE', the RIGHT function outputs 'STRUCTURE FAILURE' (the last 17 characters from the IN string).

ST Program - RIGHT:

To use a RIGHT function in an ST program, you need to use this syntax:

Output := RIGHT ('IN', L);

Where Output, IN and L are defined as variables earlier in the ST program.

Alternatively, you can use the following syntax:

Output := RIGHT (IN:= 'PIPELINE STRUCTURE FAILURE', L:= 17);

Where the 'PIPELINE STRUCTURE FAILURE' and 17 values are the input values (in this case, they are the same values as used in the Function Block Diagram example above).


Logic Guide - Misc (Built-in Functions, Function Blocks, and Conversions)

Misc

The following function blocks are categorized as miscellaneous:

  • SYSTEM
  • OPEN_PORT
  • OPEN_FILE
  • OPEN_FILE_EX
  • WRITE_FILE
  • WRITE_FILE_BYTE
  • CLOSE_FILE
  • EXECUTE_SQL

These function blocks are available from the Misc sub-menu on Function Block Diagrams.

SYSTEM
Function Name | SYSTEM
Description | Allows an .exe file to be executed from a Logic program. The SYSTEM function places each execute command in a list, with the latest command being added to the bottom of the list. The commands are executed in turn and can only be executed when the previous command has been executed (if the command runs an application, the application has to be closed before the next system command is executed). For this reason, there can be delays between the time a Logic program is run and the time the executable file is executed (the command from the SYSTEM function is placed in a queue).
Arguments | IN {STRING} The IN input is a string that specifies the path to an executable file. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Executes the executable file at the location specified in the IN input. If the .exe file cannot be found at the defined location, the SYSTEM function will have no effect.

Examples:

Function Block Diagram - SYSTEM:

In this example, the IN input is 'C:\Windows\Nd.exe', so when the program executes, the Nd application will run.

ATTENTION: Do not use SYSTEM to call interactive processes, such as running interactive programs like Microsoft Notepad. Interactive processes only complete after the user closes the application and so will prevent any other system commands from executing.

ST Program - SYSTEM:

To use a SYSTEM function in an ST program, you need to use this syntax:

VAR
A : DINT;
END_VAR
A := SYSTEM( 'C:\Windows\SetInstall.exe' );

The output of the SYSTEM function has to be stored as a variable (DINT). In this case, a variable named A is used and the string for the SYSTEM's IN input is 'C:\Windows\SetInstall.exe'.

OPEN_PORT
Function Name | OPEN_PORT
Description | Opens a serial port. When a port is open, data can be written to it by using the WRITE_FILE function (see WRITE_FILE).
Arguments | SPEC {STRING} A string input that is a serial port specification, for example 'COM1,9600,8,N,1,NONE'. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | FileID {UDINT} Returns the FileID of the file that is to be used when the port is writing or closing.

Example:

ST Program - OPEN_PORT:

To use an OPEN_PORT function in an ST program, you need to use this syntax:

PORT := OPEN_PORT( 'COM1,9600,8,N,1,NONE' );

Where PORT is a variable declared earlier in the ST program.

OPEN_FILE
Function Name | OPEN_FILE
Description | Opens a file on disk in text mode. The file can be used to store a value, text etc. When a file has been opened, data can be written to it by using the WRITE_FILE function (see WRITE_FILE).
Arguments | FILENAME {STRING} The FILENAME string defines the name of the file that is to be opened. APPEND {BOOL} Controls whether data is added to the end of the file (True) or the existing data is overwritten (False). For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | FileID {UDINT} Returns the FileID of the file. The FileID is used to identify the file when writing and closing.

NOTE: You should only use the OPEN_FILE function in ST Programs.

Example:

ST Program - OPEN_FILE:

To use an OPEN_FILE function in an ST program, you need to use this syntax:

FileNumber := OPEN_FILE( FILENAME, APPEND );

Where FileNumber, FILENAME, and APPEND are variables that are declared earlier in the ST program. The FILENAME variable has to be a string and the APPEND variable has to be a Boolean. The FileNumber variable will be used to store the FileID that is returned when the specified file is opened.

OPEN_FILE_EX
Function Name | OPEN_FILE_EX
Description | Opens a file on disk in binary or text mode. The file can be used to store a value, text etc. When a file has been opened, data can be written to it by using the WRITE_FILE function (see WRITE_FILE) or WRITE_FILE_BYTE function (see WRITE_FILE_BYTE).
Arguments | FILENAME {STRING} The FILENAME string defines the name of the file that is to be opened. APPEND {BOOL} Controls whether data is added to the end of the file (True) or the existing data is overwritten (False). BINARY {BOOL} Controls whether the file is opened in text mode (False) or binary mode (True). For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | FileID {UDINT} Returns the FileID of the file. The FileID is used to identify the file when writing and closing.

NOTE: You should only use the OPEN_FILE_EX function in ST Programs.

Example:

ST Program - OPEN_FILE_EX:

To use an OPEN_FILE_EX function in an ST program, you need to use this syntax:

FileNumber := OPEN_FILE_EX( FILENAME, APPEND, BINARY );

Where FileNumber, FILENAME, APPEND, and BINARY are variables that are declared earlier in the ST program. The FILENAME variable has to be a string, and the APPEND and BINARY variables have to be Booleans. The FileNumber variable will be used to store the FileID that is returned when the specified file is opened.

WRITE_FILE
Function Name | WRITE_FILE
Description | Allows data to be written to an open file or serial port. When the data has been written, the file or port needs to be closed by using the CLOSE_FILE function (see CLOSE_FILE). If the data needs to contain a 0 byte, you should use WRITE_FILE_BYTE instead (see WRITE_FILE_BYTE).
Arguments | FILEID {UDINT} The FILEID is a number that identifies the file or port to which data is to be written. DATA {STRING} The data that is to be written to the file or serial port. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Zero {UDINT} The WRITE_FILE function returns zero.

NOTE: You should only use the WRITE_FILE function in ST Programs.

Example:

ST Program - WRITE_FILE:

To use a WRITE_FILE function in an ST program, you need to use this syntax:

WriteExport := WRITE_FILE( FILEID, DATA );

Where WriteExport, FILEID, and DATA are variables that are declared earlier in the ST program. The FILEID variable has to be a UDINT and identifies the file or port to which the data is to be written and the DATA string is the actual data that is written.The WriteExport variable will store the value that is returned by the WRITE_FILE function.

A common use for the WRITE_FILE function is to provide a serial ASCII export process. To achieve this, an OPEN_PORT function is used to open a serial port and then a WRITE_FILE function is used to write data to the port:

FileId := OPEN_PORT('COM1,9600,8,N,1,NONE');
ErrorCode := WRITE_FILE(FileId, WriteString);
FileId := CLOSE_FILE(FileId);

In this code, the ST Program opens the defined COM port and then performs a WRITE_FILE function. The WRITE_FILE function writes the string that is stored in the WriteString variable to the port (the FileId in the WRITE_FILE function declaration corresponds to the FileId that is returned by the OPEN_PORT function. When the string has been written to the port, the CLOSE_FILE function is used to close the port. This allows data stored in a string to be written to a serial port so that it can be accessed by other applications etc.

WRITE_FILE_BYTE
Function Name | WRITE_FILE_BYTE
Description | Allows data (single byte) to be written to an open file or serial port. When the data has been written, the file or port needs to be closed by using the CLOSE_FILE function (see CLOSE_FILE). Unlike WRITE_FILE, WRITE_FILE_EX allows a single byte to be written.
Arguments | FILEID {UDINT} The FILEID is a number that identifies the file or port to which data is to be written. DATA {BYTE} The data that is to be written to the file or serial port. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Zero {UDINT} The WRITE_FILE_BYTE function returns zero.

NOTE: You should only use the WRITE_FILE_BYTE function in ST Programs.

Example:

ST Program - WRITE_FILE_BYTE:

To use a WRITE_FILE_BYTE function in an ST program, you need to use this syntax:

WriteExport := WRITE_FILE_BYTE( FILEID, DATA );

Where WriteExport, FILEID, and DATA are variables that are declared earlier in the ST program. The FILEID variable has to be a UDINT and identifies the file or port to which the data is to be written and the DATA variable is the data that is written. The DATA has to be a byte data type, for example, 16xFF. The WriteExport variable will store the value that is returned by the WRITE_FILE_BYTE function.

A common use for the WRITE_FILE_BYTE function is to provide a serial ASCII export process. To achieve this, an OPEN_PORT function is used to open a serial port and then a WRITE_FILE_BYTE function is used to write data to the port:

FileId := OPEN_PORT('COM1,9600,8,N,1,NONE');
ErrorCode := WRITE_FILE_BYTE(FileId, WriteValue);
FileId := CLOSE_FILE(FileId);

In this code, the ST Program opens the defined COM port and then performs a WRITE_FILE_BYTE function. The WRITE_FILE_BYTE function writes the value that is stored in the WriteValue variable to the port (the FileId in the WRITE_FILE_BYTE function declaration corresponds to the FileId that is returned by the OPEN_PORT function). When the string has been written to the port, the CLOSE_FILE function is used to close the port. This allows byte data types to be written to a serial port so that they can be accessed by other applications etc.

CLOSE_FILE
Function Name | CLOSE_FILE
Description | Closes an open file or serial port. The CLOSE_FILE should be used after data has been written to a file or serial port.
Arguments | FILEID {UDINT} The FILEID is a number that identifies the file or port that is to be closed. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Zero {UDINT} The CLOSE_FILE function returns zero.

NOTE: You should only use the CLOSE_FILE function in ST Programs.

Example:

ST Program - CLOSE_FILE:

To use a CLOSE_FILE function in an ST program, you need to use this syntax:

ClosePort := CLOSE_FILE(FILEID);

Where ClosePort and FILEID are variables that are declared earlier in the ST program. The FILEID variable has to be a UDINT and identifies the file or port that is to be closed. The ClosePort variable is a UDINT and stores the zero that is returned by the CLOSE_FILE function.

For an example of the CLOSE_FILE function being used in an ST Program, refer to the example in WRITE_FILE.

EXECUTE_SQL
Function Name | EXECUTE_SQL
Description | Executes an SQL Query. The SQL Query is executed at the end of the Logic program execution process, during the write outputs phase.
Arguments | SQL {STRING} The SQL is a valid SQL Query statement. For more information on the data types for the inputs and outputs, see Data Type Hierarchy.
Returns | Boolean. The SQL executes at the end of the Logic program and the success (True) or failure (FALSE) of the SQL statement is not available to the Logic program.

The preferred way of inserting, updating or deleting data via SQL from Logic is to use the %D in the variable syntax (see Inserting, Updating, and Deleting Values by Using SQL in an ST Program).

EXECUTE_SQL is deprecated and is retained for backward compatibility only.


Logic Guide - Built-In Function Blocks (Built-in Functions, Function Blocks, and Conversions)

Built-In Function Blocks

ClearSCADA includes built-in function blocks that you can use in your Logic programs. The built-in function blocks are available in Function Block Diagrams and ST programs and are categorized as:

  • Counters
  • CTD
  • CTU
  • CTUD
  • State Change Detectors
  • F_TRIG
  • R_TRIG
  • Set and Reset Bistables
  • RS
  • SR
  • Timers
  • TOF
  • TON
  • TP


Logic Guide - Counters (Built-in Functions, Function Blocks, and Conversions)

Counters

The following counter function blocks provide incremental and decremental counters:

  • CTD—Decremental counter
  • CTU—Incremental counter
  • CTUD—Incremental and decremental counter.

CTD

Function Block Name

CTD

Description

CTD is a down counter function block and it is typically used to indicate when a count has decreased to a minimum value.

Arguments

CD {BOOL}

Determines when the counter decreases. The counter will go down by 1 when the CD input changes from False to True. The counter does not change again until the CD input changes from True to False and then back to True. The counter is only affected by the CD input changing from False to True.

If the counter reaches the number specified by the PV input, the counter will no longer decrease, even if the CD input continues to change from False to True.

LD {BOOL}

Indicates whether there is a Load. If the LD value is True, the CV output is set to the preset value (PV) irrespective of the count; if the LD value is False, the CV output has a value that corresponds to the number of times the CD value has changed.

PV {INT}

This is an integer input that defines the starting number for the counter.

Returns

Q {BOOL}

The Q output defines whether the count is active or inactive. If the CV output is greater than 0, the Q output is False and the counting is active; if the CV output reaches 0, the Q output is True and the counting stops.

CV {INT}

The CV output is the value of the counter. It decreases by 1 each time the CD input changes from False to True.

The CV output begins as the same number as the PV input. It can decrease until it reaches 0, at which point the Q output becomes True and the counting stops.

Examples:

Example - CTD Function Block Diagram:

In this Function Block Diagram, the LD output begins as True, and so the CV output is set to be the same as the PV input of 10. The LD output then becomes False and so the counting begins (as the CV output can now be affected by the CD input). The CD input changes from True to False and then back to True again. This causes the CV output to decrease by 1 as the CD input has changed from False to True once. The Q output remains as False as the CV output is above 0. The Q output will only change to True when the CD input has changed from False to True a further 9 times (reducing the CV output to 0). When the Q output changes to True, the counting stops.

Example - CTD ST Program:

The syntax for entering a CTD function block in an ST program is:

VAR
CD_IN AT %M(.Digital Point1): BOOL;
LD_IN: AT %M(.Digital Point2): BOOL;
END_VAR
VAR
PV_IN: INT;
Q_OUT: BOOL;
CV_OUT: INT;
FB : CTD;
END_VAR
FB( CD := CD_IN, LD := LD_IN, PV := PV_IN, Q := Q_OUT, CV := CV_OUT );

The direct variables are declared in a separate VAR block to the internal variables. The input and output variables for the CTD function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the CD input variable is named CD_IN). In this example, the direct variables for the CD and LD inputs (CD_IN and LD_IN) reference digital points (the Boolean values for these inputs are taken from digital points in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( CD := CD_IN, LD := LD_IN, PV := PV_IN, Q := Q_OUT, CV := CV_OUT );

So, the ST Program uses the CD_IN input as the CD input for the FB function block (which has already been declared as a CTD type). For the LD input, it uses the LD_IN variable, and for the PV input it uses the PV_IN variable. For its outputs, it uses the Q_OUT variable for the Q output and the CV_OUT variable for the CV output.

CTU

Function Block Name

CTU

Description

CTU is an up counter function block and it is typically used to indicate when a count has increased to a maximum value.

Arguments

CU {BOOL}

Determines when the counter increases. The counter will go up by 1 when the CU input changes from False to True. The counter does not change again until the CU input changes from True to False and then back to True. The counter is only affected by the CU input changing from False to True.

If the counter reaches the number specified by the PV input, the counter will no longer increase, even if the CU input continues to change from False to True.

R {BOOL}

Indicates whether there is a reset. If the R value is True, the CV output is set to 0 irrespective of the count; if the R value is False, the CV output has a value that corresponds to the number of times the CU value has changed.

PV {INT}

This is an integer input that defines the maximum number for the counter.

Returns

Q {BOOL}

The Q output defines whether the count is active or inactive. If the CV output is less than the PV number, the Q output is False and the counting is active; if the CV output reaches the PV number, the Q output is True and the counting stops.

CV {INT}

The CV output is the value of the counter. It increases by 1 each time the CU input changes from False to True.

The CV output begins at 0. It can increase until it reaches the PV value, at which point the Q output becomes True and the counting stops.

Examples:

Example - CTU Function Block Diagram:

In this Function Block Diagram, the R output begins as True, and so the CV output is set to 0. The R output then becomes False and so the counting begins (as the CV output can now be affected by the CU input). The CU input changes from False to True. This causes the CV output to increase by 1 as the CU input has changed from False to True once. The Q output remains as False as the CV output is less than the PV input. The Q output will only change to True when the CU input has changed from False to True a further 9 times (increasing the CV output to 10). When the Q output changes to True, the counting stops.

Example - CTU ST Program:

The syntax for entering a CTU function block in an ST program is:

VAR
CU_IN AT %M(.Digital Point1): BOOL;
R_IN: AT %M(.Digital Point2): BOOL;
END_VAR
VAR
PV_IN: INT;
Q_OUT: BOOL;
CV_OUT: INT;
FB : CTU;
END_VAR
FB( CU := CU_IN, R := R_IN, PV := 10, Q := Q_OUT, CV := CV_OUT );

The direct variables are declared in a separate VAR block to the internal variables. The input and output variables for the CTU function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the CU input variable is named CU_IN). In this example, the direct variables for the CU and R inputs (CU_IN and R_IN) reference digital points (the Boolean values for these inputs are taken from digital points in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( CU := CU_IN, R := R_IN, PV := 10, Q := Q_OUT, CV := CV_OUT );

So, the ST Program uses the CU_IN input as the CU input for the FB function block (which has already been declared as a CTU type). For the R input, it uses the R_IN variable, and for the PV input it uses the value 10. For its outputs, it uses the Q_OUT variable for the Q output and the CV_OUT variable for the CV output.

CTUD

Function Block Name

CTUD

Description

CTUD is an up and down counter function block and it is typically used to indicate when a count has decreased to 0 or increased to a specified maximum number.

Arguments

CU {BOOL}

Determines when the counter increases. The counter will go up by 1 when the CD input changes from False to True. The counter does not increase again until the CD input changes from True to False and then back to True (although it may decrease, if the CD input changes from False to True). The counter is only affected by the CD input changing from False to True.

If the counter reaches the number specified by the PV input, the counter will no longer increase, even if the CD input continues to change from False to True.

CD {BOOL}

Determines when the counter decreases. The counter will go down by 1 when the CD input changes from False to True. The counter does not decrease again until the CD input changes from True to False and then back to True (although it may increase if the CU input changes from False to True). The counter is only affected by the CD input changing from False to True.

If the counter reaches 0, it will no longer decrease, even if the CD input continues to change from False to True.

R {BOOL}

Indicates whether there is a reset. If the R value is True, the CV output is set to 0 irrespective of the count; if the R value is False, the CV output has a value that corresponds to the number of times the CU and CD values have changed.

LD {BOOL}

Indicates whether there is a Load. If the LD value is True, the CV output is set to the same value as PV irrespective of the count; if the LD value is False, the CV output has a value that corresponds to the number of times the CU and CD values have changed.

PV {INT}

This is an integer input that defines the maximum number for the counter.

Returns

QU {BOOL}

The QU output defines whether the up count is active or inactive. If the CV output is less than the PV number, the Q output is False and the counting is active; if the CV output reaches the PV number, the QU output is True and the counting up stops.

QD {BOOL}

The QD output defines whether the down count is active or inactive. If the CV output is greater than 0, the QD output is False and the counting is active; if the CV output reaches 0, the QD output is True and the counting down stops.

CV {INT}

The CV output is the value of the counter. It increases by 1 each time the CU input changes from False to True and decreases by 1 when the CD input changes from False to True.

The CV is set to 0 when the R input is True and is set to the same number as the PV input when the LD input is True.

Examples:

Example - CTUD Function Block Diagram:

In this Function Block Diagram, we assume that the CV counter begins at 0 following the R input being True. The R input then changes to False and the CU input changes from False to True (as shown). This causes the CV value to increase by 1. The QU and QD outputs remain as False as the CV value is greater than 0 and less than the PV value.

The CD input changes from False to True. This makes the CV counter decrease by 1 and so it returns to 0. As the CV value is 0, the QD output changes to True.

Example - CTUD ST Program:

The syntax for entering a CTUD function block in an ST program is:

VAR
CU_IN AT %M(.Digital Point1): BOOL;
CD_IN: AT %M(.Digital Point2): BOOL;
R_IN: AT %M(.Digital Point3): BOOL;
LD_IN: AT %M(.Digital Point4): BOOL;
END_VAR
VAR
PV_IN: INT;
QU_OUT: BOOL;
QD_OUT: BOOL;
CV_OUT: INT;
FB : CTUD;
END_VAR
FB( CU := CU_IN, CD := CD_IN, R := R_IN, LD := LD_IN, PV := 10, QU := QU_OUT, QD := QD_OUT, CV := CV_OUT );

The direct variables are declared in a separate VAR block to the internal variables. The input and output variables for the CTUD function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the CD input variable is named CD_IN). In this example, the direct variables for the CU, CD, R and LD inputs (CU_IN, CD_IN, R_IN and LD_IN) reference digital points (the Boolean values for these inputs are taken from digital points in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( CU := CU_IN, CD := CD_IN, R := R_IN, LD := LD_IN, PV := 10, QU := QU_OUT, QD := QD_OUT, CV := CV_OUT );

So, the ST Program uses:

  • The CU_IN input as the CU input
  • The CD_IN input as the CD input
  • The R_IN input as the R input
  • The LD_IN input as the LD input
  • 10 as the PV input.

The FB declaration sets the ST program to use a CTUD type of function block.

For the outputs, the ST program uses the QU_OUT variable for the QU output, the QD_OUT variable for the QD output, and the CV_OUT variable for the CV output.


Logic Guide - State Change Detectors (Built-in Functions, Function Blocks, and Conversions)

State Change Detectors

There are 2 types of built-in function blocks for detecting changes of state:

  • F_TRIG
  • R_TRIG.

F_TRIG
Function Block Name | F_TRIG
Description | F_TRIG is an edge detection function block. It detects a change in the state of a Boolean input. The output from an F_TRIG function block produces a pulse when True.
Arguments | CLK {BOOL} When the CLK input changes from True to False, the Q output changes to True for one execution of the function block. The Q output then returns to being False until the CLK input changes from True to False again.
Returns | Q {BOOL} The Q output changes state according to the CLK input. When the CLK input changes from True to False, the Q output becomes True. It remains True for one execution of the F_TRIG function block and then returns to being False.

Examples:

Example - F_TRIG Function Block Diagram:

In this example, the CLK input comes from a digital point named 'PressureAlert'. The CLK input changes from True to False causing the Q output to change from False to True. The Q output remains True for one execution of the function block and then returns to being False.

Example - F_TRIG ST Program:

The syntax for entering an F_TRIG function block in an ST program is:

VAR
CLK_IN AT %M(.Digital Point1): BOOL;
END_VAR
VAR
Q_OUT: BOOL;
FB : F_TRIG;
END_VAR
FB( CLK := CLK_IN, Q => Q_OUT);

The direct variable is declared in a separate VAR block to the indirect variables. The input and output variables for the F_TRIG function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the CLK input variable is named CLK_IN). In this example, the direct variable for the CLK input (CLK_IN) references a digital point (the Boolean value for the input is taken from a digital point in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( CLK := CLK_IN, Q => Q_OUT);

So, the ST Program uses the CLK_IN input as the CLK input for the FB function block (which has already been declared as an F_TRIG type). For the Q output, it uses the Q_OUT variable.

R_TRIG
Function Block Name | R_TRIG
Description | R_TRIG is an edge detection function block. It detects a change in the state of a Boolean input. The output from an F_TRIG function block produces a pulse when True.
Arguments | CLK {BOOL} When the CLK input changes from False to True, the Q output changes to True for one execution of the function block. The Q output then returns to being False until the CLK input changes from False to True again.
Returns | Q {BOOL} The Q output changes state according to the CLK input. When the CLK input changes from False to True, the Q output becomes True. It remains True for one execution of the R_TRIG function block and then returns to being False.

Examples:

Example - R_TRIG Function Block Diagram:

In this example, the CLK input comes from a digital point named 'PressureAlert'. The CLK input changes from False to True causing the Q output to change from False to True. The Q output remains True for one execution of the function block and then returns to being False.

Example - R_TRIG ST Program:

The syntax for entering an R_TRIG function block in an ST program is:

VAR
CLK_IN AT %M(.Digital Point1): BOOL;
END_VAR
VAR
Q_OUT: BOOL;
FB : R_TRIG;
END_VAR

FB( CLK := CLK_IN, Q => Q_OUT);

The direct variable is declared in a separate VAR block to the indirect variables. The input and output variables for the R_TRIG function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the CLK input variable is named CLK_IN). In this example, the direct variable for the CLK input (CLK_IN) references a digital point (the Boolean value for the input is taken from a digital point in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( CLK := CLK_IN, Q => Q_OUT);

So, the ST Program uses the CLK_IN input as the CLK input for the FB function block (which has already been declared as an R_TRIG type). For the Q output, it uses the Q_OUT variable.


Logic Guide - Set and Reset Bistables (Built-in Functions, Function Blocks, and Conversions)

Set and Reset Bistables

The Set-Reset and Reset-Set bistables are useful function blocks as they allow an output state to be determined by the states of two inputs. This is especially useful for providing push button functionality, for example, an SR function block can be used to provide the functionality for start and stop buttons—the output of the SR function block is dependent on whether the input is true for the start button, the stop button, or both.

There are 2 Set and Reset bistables:

  • RS—The Reset input is dominant in the RS function block.
  • SR—The Set input is dominant in the SR function block.

RS

Function Block Name

RS

Description

RS is a reset latch where the Reset is dominant over the Set. It can be used to determine the state of a Boolean output based on the states of 2 Boolean inputs.

Arguments

S {BOOL}

The Set input S only affects the Q1 output when the R1 input is False. If the S input changes from False to True and the R1 input is False, the change to the S input will cause the Q1 output to become True. The Q1 output will then stay True until the R1 state changes; Q1 will not respond to the S input changing state again until R1 has become True and then changed to False again.

R1 {BOOL}

The Reset input R1 is dominant in the RS function block. When its input is True, the Q1 output is False; when the R1 input is False, the value of the Q1 output is dependent on the S input.

Returns

Q1 {BOOL}

The Q1 output is True when the R1 input is True. When the R1 input is False, the Q1 input can respond to the S input:

  • If the S input changes from False to True and the R1 input is False, the Q1 output becomes True.
  • If the S input changes from True to False while the R1 input is False, the Q1 output remains True.
  • If the R1 input is True, the Q1 output is False irrespective of the state of S.

Examples:

Example - RS Function Block Diagram:

It is easier to understand the functionality of the RS function block if you imagine the S and R1 inputs as corresponding to power buttons, and the Q1 output as the result of those buttons being pressed.

The S input receives its value from a point that represents a 'power on' button on plant; the R1 input receives its value form a point representing the 'power off' button.The True state corresponds to the buttons being pressed (active) and the False state corresponds to the buttons not being pressed (inactive).

The power on button is pressed (S is True) and the power off button is not pressed (R1 is False), so the power is on (Q1 is True). As the power on button cannot turn the power off, further changes to the S input will not affect the output (as long as R1 remains False). The power remains on until the off button is pressed (Q1 remains True until R1 becomes True).

When the power off button is pressed (R1 becomes True), the output becomes False (the power is off). The output will remain False until the R1 input changes to False (the power off button is not pressed) and the S input is True (the power on button is pressed).

If both buttons are pressed at the same time (S and R1 are both True), the R1 input is dominant and so the power is off (Q1 is False).

Example - RS ST Program:

The syntax for entering an RS function block in an ST program is:

VAR
S_IN AT %M(.Digital Point1): BOOL;
R1_IN AT %M(.Digital Point2): BOOL;
END_VAR
VAR
Q1_OUT: BOOL;
FB : RS;
END_VAR

FB( S := S_IN, R1 := R1_IN, Q1:= Q1_OUT );

The direct variables are declared in a separate VAR block to the indirect variables. The input and output variables for the RS function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the R1 input variable is named R1_IN). In this example, the direct variables for the S input (S_IN) and R1 input (R1_IN) reference digital points (the Boolean values for the inputs are taken from digital points in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( S := S_IN, R1 := R1_IN, Q1 := Q1_OUT );

So, the ST Program uses the S_IN input as the S input for the FB function block (which has already been declared as an RS type). It uses the R1_IN variable as the value for the R1 input and for the Q1 output it uses the Q1_OUT variable.

SR

Function Block Name

SR

Description

SR is a reset latch where the Set is dominant over the Reset. It can be used to determine the state of a Boolean output based on the states of 2 Boolean inputs.

Arguments

S1 {BOOL}

The Set input S1 is dominant in the SR function block. When its input is True, the Q1 output is True; when the S1 input is False, the value of the Q1 output is dependent on the R input.

R {BOOL}

The Reset input R only affects the Q1 output when the S1 input is False. If the R input changes from False to True and the S1 input is False, the change to the R input will cause the Q1 output to become True. The Q1 output will then stay True until the S1 state changes; Q1 will not respond to the R input changing state again until S1 has become True and then changed to False again.

Returns

Q1 {BOOL}

The Q1 output is True when the S1 input is True. When the S1 input is False, the Q1 input can respond to the R input:

  • If the R input changes from False to True and the S1 input is False, the Q1 output becomes True.
  • If the R input changes from True to False while the S1 input is False, the Q1 output remains True.
  • If the S1 input is True, the Q1 output is True irrespective of the state of R.

Examples:

Example - SR Function Block Diagram:

It is easier to understand the functionality of the SR function block if you imagine the S1 and R inputs as corresponding to power buttons, and the Q1 output as the result of those buttons being pressed.

The S1 input receives its value from a point that represents a 'power on' button on plant; the R input receives its value form a point representing the 'power off' button.The True state corresponds to the buttons being pressed (active) and the False state corresponds to the buttons not being pressed (inactive).

The power on button is pressed (S1 is True) and the power off button is not pressed (R1 is False), so the power is on (Q1 is True). As the power on button cannot turn the power off, further changes to the S1 input will not affect the output (as long as R remains False). The power remains on until the power on button is no longer pressed (S1 is False) and the power off button is pressed (R is True). This means that Q1 remains True until S1 becomes False and R becomes True.

The power on button is no longer pressed and so S1 becomes False. Both S1 and R are False as neither button has been pressed and the Q1 output is True as the S1 input was previously True.

As both inputs are False, pressing the power off button sets the Q1 output to False as the R input only has an effect when the S1 input is False.

If both buttons are pressed at the same time (S1 and R are both True), the S1 input is dominant and so the power is on (Q1 is True).

Example - SR ST Program:

The syntax for entering an SR function block in an ST program is:

VAR
S1_IN AT %M(.Digital Point1): BOOL;
R_IN AT %M(.Digital Point2): BOOL;
END_VAR
VAR
Q1_OUT: BOOL;
FB : SR;
END_VAR

FB( S1 := S1_IN, R := R_IN, Q1:= Q1_OUT );

The direct variables are declared in a separate VAR block to the indirect variables. The input and output variables for the SR function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the R input variable is named R_IN). In this example, the direct variables for the S1 input (S1_IN) and R input (R_IN) reference digital points (the Boolean values for the inputs are taken from digital points in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( S1 := S1_IN, R := R_IN, Q1 := Q1_OUT );

So, the ST Program uses the S1_IN input as the S1 input for the FB function block (which has already been declared as an SR type). It uses the R_IN variable as the value for the R input and for the Q1 output it uses the Q1_OUT variable.


Logic Guide - Timers (Built-in Functions, Function Blocks, and Conversions)

Timers

The timer function blocks are useful when you need an output to be dependent on the state of an input, but also require a delay. Delays with state changes are often needed when the communications equipment is known to be unreliable, for example, when you know that sensors sometimes report incorrect states due to signal interference.

There are 2 types of built-in timer function block:

  • TOF—A false output is delayed by a specified amount of time.
  • TON—A true output is delayed by a specified amount of time.
  • TP—A pulse is output for a specified time.

TOF

Function Block Name

TOF

Description

Sets an output to False after a specified time delay. This is useful when the input signals are unreliable due to interference etc. By having a delay, you can stop fluctuating input values from affecting the output—a True input will set the Q output to True immediately, but a False input will have to remain False for a set time before it causes the Q output to become False.

Arguments

IN {BOOL}

When the IN input changes to False, the timer ET begins to increase. The output remains True until the ET time reaches the time limit defined by the PT input. When the ET time reaches the PT time, the output changes to False (only if the IN input is still False).

PT {TIME}

The PT input defines the amount of time for the delay. The output cannot change to False unless the IN input is False for the PT time.

Returns

Q {BOOL}

The Q Boolean output is True whenever the IN input is True. If the IN input changes to False, the Q output remains True until the ET time has reached the limit defined by the PT time. If the IN input is still False then the ET time reaches the PT time, the Q output changes to False.

ET {TIME}

The ET time counter begins when the IN input changes from True to False. It increases toward the time limit defined by the PT input. When it reaches the PT limit, the ET counter stops and the output either changes or remains the same (depending on whether the IN input is still False).

Examples:

Example - TOF Function Block Diagram:

The POWER Boolean provides the input for IN. It begins as False and then changes to True which causes the Q output to change to True. The IN input then changes to False, and the ET counter begins to count up to the amount of time defined by the PT input (in this case, 30 seconds). After 15 seconds, the IN input changes back to True. When the ET counter reaches 30 seconds, the Q output remains True as the IN input was not continuously False for 30 seconds.

The IN input changes from True to False again. As before, the ET counter starts to increase from 1s upwards toward 30 seconds. During this time, the IN input remains False. When the ET counter reaches 30s, the Q output changes to False as the IN input has been False for over 30 seconds.

Example - TOF ST Program:

The syntax for entering a TOF function block in an ST program is:

VAR
IN_IN AT %M(.Digital Point1): BOOL;
END_VAR
VAR
PT_IN: TIME;
Q_OUT: BOOL;
ET_OUT: TIME;
FB : TOF;
END_VAR

FB( IN := IN_IN, PT := PT_IN, Q => Q_OUT, ET => ET_OUT );

The direct variable is declared in a separate VAR block to the indirect variables. The input and output variables for the TOF function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the PT input variable is named PT_IN). In this example, the direct variable for the IN input (IN_IN) references a digital point (the Boolean value for the input is taken from a digital point in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( IN := IN_IN, PT := PT_IN, Q => Q_OUT, ET => ET_OUT );

So, the ST Program uses the IN_IN input as the IN input for the FB function block (which has already been declared as a TOF type). The PT input is provided by the PT_IN variable, the Q output is stored by the Q_OUT variable, and the ET output is stored by the ET_OUT variable.

TON

Function Block Name

TON

Description

Sets an output to True after a specified time delay. This is useful when the input signals are known to be unreliable, for example, when input signals are affected by interference. By having a delay, you can stop fluctuating input values from affecting the output—a False input will set the Q output to False immediately, but a True input will have to remain True for a set time before it causes the Q output to become True.

Arguments

IN {BOOL}

When the IN input changes to True, the timer ET begins to increase. The output remains False until the ET time reaches the time limit defined by the PT input. When the ET time reaches the PT time, the output changes to True (only if the IN input is still True).

PT {TIME}

The PT input defines the amount of time for the delay. The output cannot change to True unless the IN input is True for the PT time.

Returns

Q {BOOL}

The Q Boolean output is False whenever the IN input is False. If the IN input changes to True, the Q output remains False until the ET time has reached the limit defined by the PT time. If the IN input is still True then the ET time reaches the PT time, the Q output changes to True.

ET {TIME}

The ET time counter begins when the IN input changes from False to True. It increases toward the time limit defined by the PT input. When it reaches the PT limit, the ET counter stops and the output either changes or remains the same (depending on whether the IN input is still True).

NOTE: When using TON, you should have the execution set to an interval so that the program re-executes and re-evaluates the condition of the timer. TON timers do not function as a SLEEP or WAIT type command.

Examples:

Example - TON Function Block Diagram:

The ShutDown Boolean provides the input for IN. It begins as True and then changes to False which causes the Q output to change to False. The IN input then changes to True, and the ET counter begins to count up to the amount of time defined by the PT input (in this case, 30 seconds). After 15 seconds, the IN input changes back to False. When the ET counter reaches 30 seconds, the Q output remains False as the IN input was not continuously True for 30 seconds.

The IN input changes from False to True again. As before, the ET counter starts to increase from 1s upwards toward 30 seconds. During this time, the IN input remains True. When the ET counter reaches 30s, the Q output changes to True as the IN input has been True for over 30 seconds.

Example - TON ST Program:

The syntax for entering a TON function block in an ST program is:

VAR
IN_IN AT %M(.Digital Point1): BOOL;
END_VAR
VAR
PT_IN: TIME;
Q_OUT: BOOL;
ET_OUT: TIME;
FB : TON;
END_VAR

FB( IN := IN_IN, PT := PT_IN, Q => Q_OUT, ET => ET_OUT );

The direct variable is declared in a separate VAR block to the indirect variables. The input and output variables for the TON function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the PT input variable is named PT_IN). In this example, the direct variable for the IN input (IN_IN) references a digital point (the Boolean value for the input is taken from a digital point in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( IN := IN_IN, PT := PT_IN, Q => Q_OUT, ET => ET_OUT );

So, the ST Program uses the IN_IN input as the IN input for the FB function block (which has already been declared as a TON type). The PT input is provided by the PT_IN variable, the Q output is stored by the Q_OUT variable, and the ET output is stored by the ET_OUT variable.

TP

Function Block Name

TP

Description

Sets an output to True for a defined time duration. This is useful when a change in state needs to be indicated for a set amount of time, for example, a pulse timer could be used to activate alarm sirens on site for 10 minutes.

Arguments

IN {BOOL}

When the IN input changes from False to True, the timer ET begins to increase. The Q output remains True until the ET time reaches the time limit defined by the PT input. When the ET time reaches the PT time, the output changes to False even if the IN input remains True.

PT {TIME}

The PT input defines the amount of time for the delay. The output changes to True for the PT time and then reverts to False.

Returns

Q {BOOL}

The Q output is True whenever the IN input changes from False to True. The output remains True until the ET counter reaches the time specified by the PT input (at which point it reverts to False).

The Q output can be False even if the IN input is True—the output will only be True for the PT time. When the PT time has expired, the Q output reverts to False even if the IN input remains True. In this situation, the Q output would not become True again unless the IN input changes from True to False and then back to True again.

ET {TIME}

The ET time counter begins when the IN input changes from False to True. It increases toward the time limit defined by the PT input. When it reaches the PT limit, the ET counter stops and the output reverts to False. The ET counter then resets to 0.

NOTE: When using TP, you should have the execution set to an interval so that the program re-executes and re-evaluates the condition of the timer. TP timers do not function as a SLEEP or WAIT type command.

Examples:

Example - TP Function Block Diagram:

The ShutDown Boolean provides the input for IN. It begins as False and then changes to True which causes the Q output to change to True. This starts the ET counter which begins to count up to the amount of time defined by the PT input (in this case, 30 seconds). After 30 seconds, the Q output changes back to False and the ET counter resets to 0. The Q output will not change from False to True again until the IN input changes from True to False and then back to True (the output only changes when the IN input changes from False to True).

Example - TP ST Program:

The syntax for entering a TP function block in an ST program is:

VAR
IN_IN AT %M(.Digital Point1): BOOL;
END_VAR
VAR
PT_IN: TIME;
Q_OUT: BOOL;
ET_OUT: TIME;
FB : TP;
END_VAR

FB( IN := IN_IN, PT := PT_IN, Q := Q_OUT, ET :=ET_OUT );

The direct variable is declared in a separate VAR block to the indirect variables. The input and output variables for the TP function block are also allocated names that are different to the names of the inputs and outputs in the function block as this makes it easier to understand the ST program (for example, the PT input variable is named PT_IN). In this example, the direct variable for the IN input (IN_IN) references a digital point (the Boolean value for the input is taken from a digital point in the database).

In the second VAR block, the internal variables are declared, including an FB variable that defines the type of function block.

The ST Program can then reference the variables as inputs and outputs for the function block:

FB( IN := IN_IN, PT := PT_IN, Q := Q_OUT, ET :=ET_OUT );


Logic Guide - Conversions (Built-in Functions, Function Blocks, and Conversions)

Conversions

You can use the Conversions options to convert a variable of one data type into a variable of a different data type. For example, you can convert a boolean value into a byte value by using the BOOL_TO_BYTE conversion.

To access the conversions on a Function Block Diagram or Ladder Diagram:

  1. Display the diagram in Design mode.
  2. Right-click on the background of the diagram to display a context sensitive menu.
  3. Select the Conversions option to display a further menu.
  4. Select the option for the type of value that you want to convert. For example, if you want to convert a string value into a byte value, select the String option.
    A further menu is displayed.
  5. Select the option that corresponds to the type of value into which the value will be converted. For example, if you want to convert a string into a byte, select the STRING_TO_BYTE option.
    A conversion box is added to the diagram.
  6. Connect the value that is to be converted to the connection box on the left of the conversion box. The value will be converted and will be the output of the connection box. You can connect a write tag to the right connection box so that the converted value is written to the database, or you can connect the right connection box to a function block.

NOTE: If a Logic program is invalid due to an incorrect data type, a message is displayed in the compiler display at the bottom of the Logic diagram. The message indicates the type of data that is expected (required) and the input or output at which an incorrect data type was found. You can use this information to determine where conversions are needed and where different types of conversion are required.

To use conversions in ST programs, simply reference the conversion by its name within an expression. The names the conversions are same as the option names on the context sensitive menus, for example, BOOL_TO_BYTE, STRING_TO_DINT, INT_TO_SINT etc.

The format for using a conversion in ST is:

<Name of Target Variable> := <Conversion type> (<Name of Source Variable>);

Where:

<Name of Target Variable> is the name of the variable that is to be affected by the result of the conversion (the converted value).

<Conversion type> is the name of the conversion, such as BYTE_TO_BOOL.

<Name of Source Variable> is the name of the variable that has the source value that is the input for the conversion.

In each case, do not enter the angle brackets < >.

NOTE: When using conversions in ST programs, you need to enter the name of the conversion in its full form (as shown in the Conversion options on the context sensitive menu for Function Block Diagrams and Ladder Diagrams). For example, for date and time conversions, you have to enter DATE_AND_TIME and not use the abbreviated form (DT). The only exceptions to this rule are DT_TO_DATE and DT_TO_TOD.


Logic Guide - Using Logic to Run an Executable File (Built-in Functions, Function Blocks, and Conversions)

Using Logic to Run an Executable File

You can use the SYSTEM function to allow a Logic program to run a .exe file. For more information, see SYSTEM.


Logic Guide - Using Logic to Write to a File or Serial Port (Built-in Functions, Function Blocks, and Conversions)

Using Logic to Write to a File or Serial Port

You can use the OPEN_PORT and WRITE_FILE functions to write data to a serial port. This is useful for exporting ASCII data to a serial port.

You can also use the WRITE_FILE function to write data to a file. For more information, please refer to:

  • OPEN_PORT
  • OPEN_FILE
  • WRITE_FILE
  • CLOSE_FILE.


Logic Guide - User Function Blocks

User Function Blocks

ClearSCADA allows you to create custom function blocks. You can use custom function blocks, referred to as user function blocks, to significantly reduce the amount of Logic programming required on your system.

User function blocks allow you to create special items that can be referenced by other Logic programs. These special items are called Libraries, and you can use them to store function blocks that need to be used by several programs. As the configuration for a user function block is stored in a Library, it means you can include the function block in a program simply be referencing the Library. There is no need for you to program the function block in each Logic diagram or ST program.

There are 2 types of Library:

  • ST Library
  • Function Block Library

Both ST Libraries and Function Block Libraries allow you to create custom function blocks that can be referenced by other Logic programs. Before you decide which type of library you are going to use, you should consider:

  • The number of functions to be included in your library—ST Libraries can include multiple functions, but Function Block Libraries can only contain a single function.
  • Your personal preference—do you find it easier to work with the code of ST programs or the more graphical interface of Function Block Diagrams? If you prefer to use ST code, you should create an ST Library; if you prefer the Function Block Diagrams, you should consider a Function Block Library, but please be aware that Function Block Libraries can only contain one function.

When you have decided on the type of library you are going to use, you can create a suitable database item and then edit the library.

To create, edit, reference, and update Libraries, refer to the relevant section:

  • Create an ST Library
  • Edit an ST Library
  • Create a Function Block Library
  • Edit a Function Block Library
  • Reference an ST Library or Function Block Library in a Logic Diagram
  • Reference an ST Library or Function Block in an ST Program
  • Update an ST Library or Function Block Library.


Logic Guide - Create an ST Library (User Function Blocks)

Create an ST Library

Before you can configure an ST library to represent a custom function block, you need to create an ST library database item. The database item will be used to store the configuration settings for the ST library.

To create an ST library:

  1. In the Database Bar, right-click on the system, Group, or Group Template that is to contain the ST library.
    A context sensitive menu is displayed.
  2. Select the New option, then the Logic option, then the Structured Text Library option.
    A new ST library item is added to the tree-structure. It is selected automatically, ready for you to define its name.
  3. Enter a suitable name, then press the Enter key or select another part of the interface to confirm your selection.

Now that you have created an ST library item, you can edit it (see Edit an ST Library).


Logic Guide - Edit an ST Library (User Function Blocks)

Edit an ST Library

You need to edit each ST Library so that it contains the code that defines a user function block.

To edit an ST library:

  1. In the Database Bar, right-click on the ST library item to display a context sensitive menu.
  2. Select the Edit option to display the ST Library Editor window. This window works in the same way as the ST Program window—it has a section for entering the ST code and a compiler section.
  3. Enter the ST code for the custom function block. Begin the code by using the FUNCTION_BLOCK definition, then define the VAR_INPUTS, VAR_OUTPUTS, and expressions in blocks in the same way as any other ST program (see Compiling an ST Program or ST Library).

NOTE: An example of the code for an ST Library is included at the end of this section.

  4. Use the compile tools to check the syntax of the ST Library code (see Compiling an ST Program or ST Library).
  5. Save the ST Library.

Example:

The following ST code is used in an ST Library to provide the Logic that converts a value in Celsius to a value in Fahrenheit:

FUNCTION_BLOCK Celsius_to_Fahrenheit
VAR_INPUT
Celsius:INT;
END_VAR
VAR_OUTPUT
Fahrenheit:INT;
END_VAR
Fahrenheit := ((Celsius*9/5) + 32);
Fahrenheit := Fahrenheit;
END_FUNCTION_BLOCK
PROGRAM ConvertLoad
VAR
c : Celsius_to_Fahrenheit;
END_VAR
VAR
LOAD AT %M(.Load) :LREAL;
STATUS AT %M(.Status) :BYTE;
END_VAR
VAR
In : INT := 30;
Out : INT;
END_VAR;
c(Celsius := In, Fahrenheit => Out);
IF LOAD = 0 THEN
STATUS:= 0;
ELSIF LOAD < 50 THEN
STATUS := 1;
ELSIF LOAD < 90 THEN
STATUS := 2;
ELSE
STATUS := 3;
END_IF;
END_PROGRAM

The code can be referenced by multiple Logic programs. This means that the Celsius to Fahrenheit conversion only needs to be created once (in an ST Library) and it can be included in as many Logic programs as required.

When you have edited the ST Library, you can reference it in other Logic programs. For more information, see Reference an ST Library or Function Block Library in a Logic Diagram and Reference an ST Library or Function Block in an ST Program.


Logic Guide - Create a Function Block Library (User Function Blocks)

Create a Function Block Library

Before you can configure a Function Block Library to represent a custom function block, you need to create a Function Block Library database item. The database item will be used to store the configuration settings for the Function Block Library.

To create a Function Block Library:

  1. In the Database Bar, right-click on the system, Group, or Group Template that is to contain the Function Block Library.
    A context sensitive menu is displayed.
  2. Select the New option, then the Logic option, then the Function Block Library option.
    A new Function Block Library item is added to the tree-structure. It is selected automatically, ready for you to define its name.
  3. Enter a suitable name, then press the Enter key or select another part of the interface to confirm your selection.

Now that you have created a Function Block Library item, you can edit it (see Edit a Function Block Library).


Logic Guide - Edit a Function Block Library (User Function Blocks)

Edit a Function Block Library

When you have added a Function Block Library database item, you can edit it so that it contains the Logic that defines the functionality of your custom function block.

To edit a Function Block Library:

  1. In the Database Bar, right-click on the Function Block Library item to display a context sensitive menu.
  2. Select the Edit option to display the Function Block Library Editor display. This window works in the same way as the Function Block Diagram display—it has a section for defining the variables, a design section for creating the Function Block Diagram, and a compiler section for checking the syntax.

NOTE: As an alternative to steps 1 and 2, you can double-click on the Function Block Library item to display it in Design mode.

  3. Create the Logic for the custom function block by adding variables, constants, functions, and function blocks in the same way that you would create a Function Block Diagram. For further information, see Function Block Diagrams and Built-in Functions, Function Blocks, and Conversions.

When you save the Function Block Library and reference it in a Logic diagram, the function block library will appear as a graphical representation of the function block—it will have input and output connections and will provide the Logic functionality that you have defined. Obviously, if you reference the Function Block Library in an ST program, you will not see the graphical representation of the Function Block Library.

  4. Use the compile tools to check the syntax of the Function Block Library (see Compiling a Function Block Diagram or Function Block Library).
  5. Save the Function Block Diagram.

When you have edited the Function Block Diagram, you can reference it in other Logic programs. For more information, see Reference an ST Library or Function Block Library in a Logic Diagram and Reference an ST Library or Function Block in an ST Program.


Logic Guide - Reference an ST Library or Function Block Library in a Logic Diagram (User Function Blocks)

Reference an ST Library or Function Block Library in a Logic Diagram

When you have created one or more ST Libraries or Function Block Libraries, you can reference them in other Logic programs, including Logic diagrams such as Function Block Diagrams.

NOTE: For information on referencing a library in an ST program, see Reference an ST Library or Function Block in an ST Program.

By referencing an ST Library or Function Block Library, you allow a Logic program to use the Logic behavior that is defined in the library without having to program it. This is useful when the same Logic is needed in multiple programs.

To reference an ST Library or Function Block Library in a Logic Diagram:

  1. Display the Logic diagram in Design mode.
  2. Select the Edit menu.
  3. Select the Libraries option to display the Libraries window.

The Libraries window contains a list of the ST and Function Block Libraries that are available.

  4. Check the check boxes for those libraries that you want to reference in the Logic diagram (and clear the check boxes for those libraries that are not required)..
  5. Select the OK button to confirm your selection and close the Libraries window.
  6. On the Logic diagram, right-click on the background of the diagram to display a context sensitive menu.
  7. Select the User Function Blocks option.
    A further menu is displayed. The further menu contains a list of the custom function blocks that you have created.
  8. Select the option for the function block that you require.
    A further option is displayed. The option has the same name as the custom function block.
  9. Select the option that has the same name as the required function block.
    The custom function block is added to your Logic diagram.

You can connect variables and constants to the inputs and outputs of the custom function block. To do this, you should use the same methods that you use to make connections to a built-in function block (see Built-In Function Blocks).


Logic Guide - Reference an ST Library or Function Block in an ST Program (User Function Blocks)

Reference an ST Library or Function Block in an ST Program

To reference an ST Library or Function Block Library in an ST program, you need to enable the Libraries and then define them as variables in the code. There is no need to define the function block with FUNCTION_BLOCK...END_FUNCTION_BLOCK.

As with referencing libraries in a Logic diagram, you can only reference those libraries that you enable via the Libraries window.

To reference an ST Library or Function Block Library in an ST Program:

  1. Display the ST program in Design mode.
  2. Select the Edit menu.
  3. Select the Libraries option to display the Libraries window.
  4. Check the check boxes for the libraries that you want to use in the ST program and clear the check boxes for those libraries that are not required.
  5. Select the OK button to confirm your selection and close the Libraries window.
  6. Edit the code for the ST program.

You need to include the user function block (that is defined in one of the Libraries) in a VAR...END_VAR definition. The VAR definition needs to use the following format:

VAR
<Variable name>: <Name of library>;
END_VAR

Where <Variable name> is the name that you will use to reference the user function block within the ST code of the program you are editing.

<Name of library> is the name of the user function block that you defined in the ST Library or Function Block Library (this is the same name as the ST Library or Function Block Library).

Do not enter the angle brackets < >. We use the angle brackets to indicate that the name is dependent on the entries you have made.

When you have defined the variables, you can use expressions to define the values and Logic for the program (see ST Programs).

For example, if you are referencing an ST Library named 'Celsius_To_Fahrenheit' then the ST program code could be:

PROGRAM Celsius_To_Fahrenheit_Conversion
VAR
TempC :LREAL:=20.0;
TempF:LREAL;
END_VAR
VAR
C_TO_F: Celsius_To_Fahrenheit;
END_VAR
C_TO_F(Celsius := TempC,Fahrenheit => TempF);
END_PROGRAM

  7. Save the ST program.


Logic Guide - Update an ST Library or Function Block Library (User Function Blocks)

Update an ST Library or Function Block Library

If you need to make changes to an ST Library or Function Block Library, you have to edit the Library and then update any Logic programs that reference the Library. Working this way means that your Logic programs will use the updated version of the Library.

To update an ST Library or Function Block Library:

  1. In the Database Bar, either double-click on the ST Library or Function Block Library item or right-click on it and select the Edit option from the context sensitive menu.
    The library is displayed in Design mode.
  2. Alter the code or Function Block diagram as required. You can use the Build menu options to check the code (see Update an ST Library or Function Block Library).
  3. Save the Library. Now you need to update the Logic programs that reference the Library.
  4. For each Logic program that references the altered Library:
  1. Display the Logic program in Design mode.
  2. Select the Edit menu, then select the Library Update option.
  3. Save the ST program.


Logic Guide - Logic Program Properties and Values

Logic Program Properties and Values

Each type of Logic program is represented in the database by a database item. Like other database items, ST Programs, ST Libraries, Function Block Diagrams, Ladder Diagrams, and Sequential Function Charts have configuration Forms.

To learn about the settings that are available on ST Program, Ladder Diagram, Function Block Diagram, and Sequential Function Chart Forms, see Configure an ST Program, Ladder Diagram, SFC or FBD.

To learn about the settings that are available on the ST Library Form, see Configure an ST Library.

As with other types of database item, the Logic programs also have OPC tags for their configuration properties. You can view these tags by using the OPC Data Bar (see OPC Properties for Logic Programs).


Logic Guide - Configure an ST Program, Ladder Diagram, SFC or FBD (Logic Program Properties and Values)

Configure an ST Program, Ladder Diagram, SFC or FBD

Each Logic database item has its own Form that you can use to configure relevant settings. The Forms for ST Programs, Ladder Diagrams, Sequential Function Charts and Function Block Diagrams are very similar. You can use them to:

  • View the Name and configure the Help View for the Logic program. These settings are available on the Identification tab. For more information, see Defining Identification Details in the ClearSCADA Guide to Core Configuration.
  • Associate the Logic program with up to 4 custom pick actions by using the User Methods tab. For more information, see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration.
  • Enable or Disable a Logic Program
  • Define the Severity of a Logic Program's Alarms and Events
  • Define the Execution Settings for a Logic Program
  • Define when a Logic Program Updates its Outputs
  • Define whether a Logic Program Executes Methods after a Failed Method
  • Define the Conversion Types for a Logic Program
  • Define the Number of Instructions for a Logic Program
  • Define the Time Zone to be used for Calculations within the Logic Program.

NOTE: To create the code or diagram for a Logic program, you have to use the dedicated Logic editor.

To display a Logic program's Form and configure its settings:

  1. In the Database Bar, right-click on the Logic program icon to display a context sensitive menu.
  2. Select the Properties option to display the relevant Form.
    Use these settings to enable or disable the Logic program, define the severity of its alarms and events and set its priority number.
    Use the Execution settings to define when and how the Logic program is executed.
    Use these settings to define how the Logic program converts values, and to set the Instruction limit and Execution Queue Size.
    Use these settings to define whether the Logic program can be triggered by a change in value, define when the program updates its outputs, and define how the program reacts to methods that cannot be performed successfully.
    Use the Identification tab to view the Name of the Logic program and define its Help View.
    Use the User Methods tab to associate the Logic program with up to 4 custom actions.
    Use the Logic tab to define the execution, conversion settings etc.

NOTE: Alternatively, you can select the Properties option for the program from any instance of the program's context sensitive menu. For example, you may have a Mimic that provides access to an ST Program's Form or to its context sensitive menu.

  3. Use the Identification tab to define the Help View for the Logic program as required. (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  4. Use the User Methods tab to associate the Logic program with up to 4 custom pick actions as required (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  5. Select the Logic tab.
  6. Use the In Service check box to Enable or Disable the Logic program (see Enable or Disable a Logic Program).
  7. Use the Severity combo box to set the severity for alarms and events that are associated with the Logic program (see Define the Severity of a Logic Program's Alarms and Events).
  8. Use the execution-related settings to define when and how the Logic program can be executed (see Define the Execution Settings for a Logic Program):
  • Priority—Use to define whether the Logic program is executed in preference to other Logic programs (see Define the Priority of a Logic Program)
  • Execution Method—Use to define whether the Logic program is executed on a time basis or when its inputs change (see Define the Execution Method for a Logic Program)
  • Interval—Use to define how often timed execution of the Logic program takes place (see Define the Interval Settings for a Logic Program).
  • Interval Offset—Use to define the start time for the first timed execution (see Define the Interval Settings for a Logic Program).
  • Interval Offset Time Zone—Use to define the time zone to be used when calculating the time for the first timed execution (see Define the Interval Settings for a Logic Program).
  • Input Change Detection—Use to define whether the Logic program is executed when it detects a change in the value of one of its inputs (see Define whether a Logic Program Executes when the Value of an Input Changes)
  • Execute on Quality Change—Use to define whether the Logic program is executed when it detects a change in the quality of one of its inputs (see Define whether a Logic Program Executes when the Quality of an Input Changes)
  • Allow Manual Execution—Use to control the availability of the Execute action that is used to manually execute the Logic program (see Define whether a Logic Program can be Executed Manually)
  • Execution Permission—Use to define the permission required to access the Execute action for the Logic program (see Define which Permission is Required to Execute a Logic Program)
  9. Use the Trigger setting to configure the Logic program to execute in response to a change in the value of a selected property of a specific database item (see Associate the Execution of a Logic Program with a Property in the Database).
  10. Use the Update Outputs setting to Define when a Logic Program Updates its Outputs.
  11. Use the Ignore Method Errors setting to Define whether a Logic Program Executes Methods after a Failed Method.
  12. Use the Byte - String Conversions and String to Time Conversion Mode settings to Define the Conversion Types for a Logic Program.
  13. Use the Instruction Limit setting to Define the Number of Instructions for a Logic Program.
  14. Use the Execution Queue Size setting to define the maximum number of values (reported by an outstation) that can be stored in the execution queue. The default setting of 250 is usually appropriate (see Define the Maximum Number of Executions that can be Queued).
  15. Use the Program Time Zone setting to define the time zone to be used if the Logic program uses time conversion functions (see Define the Time Zone to be used for Calculations within the Logic Program).
  16. Save the Logic program's Form to confirm and store your selections.


Logic Guide - Enable or Disable a Logic Program (Logic Program Properties and Values)

Enable or Disable a Logic Program

ClearSCADA can only execute active Logic programs. Logic programs are active by default, but they can be deactivated (and re-activated) by selecting the In Service check box on the Logic tab.

To enable or disable a Logic program:

  1. Display the configuration Form for the relevant program (see Configure an ST Program, Ladder Diagram, SFC or FBD).
  2. Select the Logic tab.
  3. Check the In Service check box to enable the program or clear it to disable the program.

To configure the other Logic tab settings, see Configure an ST Program, Ladder Diagram, SFC or FBD.


Logic Guide - Define the Severity of a Logic Program's Alarms and Events (Logic Program Properties and Values)

Define the Severity of a Logic Program's Alarms and Events

You can use the Severity combo box on the Logic tab to set the severity level for the alarms and events that are associated with the selected Logic program. This is useful when certain programs are more significant than others.

To define the severity of a Logic program's alarms and events:

  1. Display the configuration Form for the relevant program (see Configure an ST Program, Ladder Diagram, SFC or FBD).
  2. Select the Logic tab.
  3. Choose the Severity level that is appropriate for the program you are configuring. The default range of Severity options is None (lowest importance), Low, Medium, High, Critical (highest importance). These options are configurable via the Server Configuration Tool and may have been altered on your system.

To configure the other Logic tab settings, see Configure an ST Program, Ladder Diagram, SFC or FBD.


Logic Guide - Define the Execution Settings for a Logic Program (Logic Program Properties and Values)

Define the Execution Settings for a Logic Program

When you have defined the program code for your program, you need to configure it so that the system can execute it. To do this, you need to use the various Execution settings, the Trigger setting and the Execution Queue Size setting. Depending on your selections, the system will execute the program:

  • At regular intervals
  • When its inputs are processed
  • When it detects changes to the values of its inputs
  • When it is triggered by a change to a value in the database (only applicable Logic programs that have an On Interval execution method)
  • When there is a change in the quality of any of its inputs (only applicable to Logic programs that have an On Input Processed execution method).

To define the execution settings for a Logic Program:

  1. Display the configuration Form for the relevant program (see Configure an ST Program, Ladder Diagram, SFC or FBD).
  2. Select the Logic tab.
  3. Define the following execution-related settings:
  • Priority—Use to define whether the Logic program is executed in preference to other Logic programs (see Define the Priority of a Logic Program)
  • Execution Method—Use to define whether the Logic program is executed on a time basis or when its inputs change (see Define the Execution Method for a Logic Program)
  • Interval—Use to define how often timed execution of the Logic program takes place (see Define the Interval Settings for a Logic Program).
  • Interval Offset—Use to define the start time for the first timed execution (see Define the Interval Settings for a Logic Program).
  • Interval Offset Time Zone—Use to define the time zone to be used when calculating the time for the first timed execution (see Define the Interval Settings for a Logic Program).
  • Input Change Detection—Use to define whether the Logic program is executed when it detects a change in the value of one of its inputs (see Define whether a Logic Program Executes when the Value of an Input Changes)
  • Execute on Quality Change—Use to define whether the Logic program is executed when it detects a change in the quality of one of its inputs (see Define whether a Logic Program Executes when the Quality of an Input Changes)
  • Allow Manual Execution—Use to control the availability of the Execute action that is used to manually execute the Logic program (see Define whether a Logic Program can be Executed Manually)
  • Trigger—Use to set the Logic program to execute in response to a change in the value of a selected property of a specific database item (see Associate the Execution of a Logic Program with a Property in the Database)
  • Execution Queue Size—Use to define the maximum number of values (reported by an outstation) that can be stored in the execution queue. The default setting of 250 is usually appropriate (see Define the Maximum Number of Executions that can be Queued).
  4. Save the configuration changes you have made.

Define the Priority of a Logic Program

Each Logic program has a Priority setting that you can use to define whether the program is executed in preference to other programs that are scheduled to execute at the same time.

ClearSCADA executes one Logic program at a time. If more than one Logic program is scheduled to occur at the same time, ClearSCADA executes the program that has the lowest Priority number first. This means that by defining a range of different Priority numbers for your Logic programs, you can prioritize all (or a selected few) of your programs.

If multiple Logic programs with the same Priority setting are scheduled to occur at the same time, ClearSCADA execute them in according to the queue time. The program that has been queued for the longest amount of time is executed first, and the program that has been queued for the least amount of time is executed last.

Logic programs have a Priority of 0 by default. Programs with 0 Priority are executed first, followed by programs with 1 Priority, and then programs with 2 Priority and so on.

To change the Priority of a Logic program, display the Logic Program Form, select the Logic tab, then enter an appropriate number in the Priority field. Remember that Logic programs with the lowest numbers are executed in preference to those with higher numbers.

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.

Define the Execution Method for a Logic Program

Each Logic program has an Execution Method setting that you can use to define whether the program is executed as a response to its inputs or on a timed basis.

The Execution Method setting provides 2 options:

  • On Input Processed—The program is executed whenever one of its inputs is processed. This means that every time ClearSCADA receives a value for one of the inputs, it will execute the program (even if the value has not changed since the last time the program was executed).

A program that uses On Input Processed will only execute if there is a change to one of its inputs and that input is deemed to be valid. The following inputs are valid:

  • %I — but only if the program does not use the NOCACHE attribute, and the tag for the variable references a field, method, aggregate or historic tag
  • %M — but only if the program has no assignments (does not write to the variable), does not use the NOCACHE attribute, and the tag for the variable references a field, method, aggregate or historic tag.

The following inputs are invalid:

  • %O
  • Inputs using NOCACHE
  • Inputs that reference a register or status tag
  • %M inputs that have assignments.

If the program does contain a valid input, it will not execute and a message will be displayed.

The On Input Processed setting should not be confused with the Input Change Detection setting, which causes the program to be executed whenever ClearSCADA detects that the value of one of the inputs has changed since the previous execution. For more information on the Input Change Detection setting, see Define whether a Logic Program Executes when the Value of an Input Changes.

  • On Interval—The program is executed regularly at timed intervals. You need to define the timed intervals in the Interval and Interval Offset fields (see Define the Interval Settings for a Logic Program).

To change the Execution Method of a Logic program, display the Logic Program Form, select the Logic tab, then choose the appropriate setting from the Execution Method combo box.

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.

Define the Interval Settings for a Logic Program

Logic programs have several Interval settings that can be used when the Execution Method is set to On Interval (see Define the Execution Method for a Logic Program). They allow you to define the time of a Logic program’s 'first' timed execution or value check, and how often subsequent timed executions and value checks take place.

The Interval settings are:

  • Interval—Use to define either:
  • The amount of time between each execution of the program
  • How frequently the program checks the value of the Trigger item (this only applies to programs that have an Execution Method of On Interval and are configured to use a Trigger—see Associate the Execution of a Logic Program with a Property in the Database)
  • How frequently the program checks changes to its inputs (this is only applicable if the Input Change Detection setting is enabled, see Define whether a Logic Program Executes when the Value of an Input Changes).

If a Logic program has a Trigger and Input Change Detection enabled, it will check the value of the Trigger and the value of its inputs according to the defined Interval. The program will execute if either the Trigger item value has changed or a change to an input has been detected.

You can enter the time in the OPC Time Interval format or use the Interval window to define the appropriate time (see Interval Window in the ClearSCADA Guide to Core Configuration). If you want a Logic program to execute automatically, you need to define an appropriate Interval time that is greater than 0. An Interval of 0 means that the Logic program is not executed automatically (it can only be executed manually by a user or by another Logic program triggering the Execute action).

By default, the program will execute, check the value of its inputs, or check the value of its Trigger when the Logic driver starts and then will continue to be execute or check the values every 10 seconds (as the default Interval Offset is NOW and the default Interval setting is 10S).

By changing the Interval, you can alter the amount of time between each timed execution or check.

NOTE: Manual executions have no effect on any timed executions. Apart from the very first execution, the time of the next timed execution is: the time of the previous timed execution + the Interval. So, if the previous execution was at 13:10:05 and the Interval is 15S, the next timed execution would be 13:10:20, even if there was a manual execution between 13:10:05 and 13:10:20.

  • Interval Offset—Use to define the start time for the first execution or value check for the Logic program. By default, the Interval Offset setting is blank which means that the default setting for the field is NOW. As a result, it means that the first execution or value check occurs as soon as the Logic driver starts with subsequent executions or value checks taking place according to the Interval setting.

However, you can change the Interval Offset so that there is a delay between the Logic Driver starting and the first timed execution or value check taking place. The calculation works like this:

Time of Logic Driver Starting+Interval Offset='First' timed execution or value check.

For example, if you set the Interval Offset to M, the first execution or value check will not take place until the start of the first minute after the Logic Driver has started. So if the Logic Driver started at 12:15:19, the 'first' execution or value check would not take place until 12:16:00 (the start of the next minute). The 'first' execution or value check is the initial execution or value check after the Logic Driver starts or after a change to the Interval Offset has been saved.

If the Logic Driver is already running when you make the Interval Offset change, the time of the configuration change replaces the time of the Logic Driver starting in the calculation:

Time of Interval Offset Config Change+Interval Offset='First'timed execution or value check

As with the Interval, you can enter the Interval Offset in the OPC time interval format or you can use the Interval window that is displayed when you select the browse button next to the Interval field.

  • Interval Offset Time Zone—Use to define the clock that is used when calculating the time for the Interval Offset. You can choose from:
  • Coordinated Universal Time (UTC)
  • Local Time without Daylight Saving Time
  • Local Time with Daylight Saving Time (for regional variations to GMT standard time, such as British SummerTime).

ClearSCADA uses the time zone to calculate the current time which is then used during the application of the Interval Offset and Interval settings.

To change the Interval, Interval Offset, or Interval Offset Time Zone of a Logic program, display the Logic Program Form, select the Logic tab, then enter the required times in the Interval or Interval Offset fields. You have to use the OPC Time Interval format. If you are changing the Interval Offset Time Zone, simply select the required time zone from the combo box as appropriate.

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.

Using OPC Time Formats.

Define whether a Logic Program Executes when the Value of an Input Changes

If a Logic program is configured to have an Execution Method setting of On Interval, you can configure the system to automatically execute the program whenever one of the program’s inputs changes value. This is useful, as it means you can set a Logic program to execute on a timed basis, but only if its inputs have changed value.

To choose whether a Logic program executes only when its inputs have changed, you need to use the Input Change Detection check box on the Logic tab of Logic Program Form:

  • If you check the Input Change Detection check box, the system will only execute the program if one of the program's inputs changes. This means that if the program is scheduled to be executed, but none of its inputs have changed value, the program will not be executed.

NOTE: If your Logic program is designed to use database values in a calculation, and then write the result to a point, you should consider enabling the Execute on Quality Change feature (see Define whether a Logic Program Executes when the Quality of an Input Changes).

  • If you clear the Input Change Detection check box, the system will execute the program according to its Interval settings (see Define the Interval Settings for a Logic Program). The program will still be executed even if the program's input values have not changed since it was last executed. The program will have updated events etc. relating to the execution.

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.

Define whether a Logic Program Executes when the Quality of an Input Changes

You can configure a Logic program so that it is executed whenever one of its inputs changes value and/or the quality of any of its inputs changes. This is useful if you need to use your Logic program to provide certain behavior in the event of a quality change.

Example:

A Logic program is configured to execute On Input Processed and has Execute on Quality Change enabled. It is coded so that it reads the values of 4 points on an outstation.

When the point values change, the Logic program calculates the total value of the points and writes the result to another point (a derived point). The Logic program also includes code that sets the program to exclude any points that have Bad quality from its calculation. If any of the points are excluded due to Bad quality, the Logic program is set to write ‘Bad’ to the Current Quality property of the derived point.

When the value of any of the 4 input points changes, the Logic program executes, calculates the total value and writes the result to the derived point. The Logic program also executes if the quality of any of the input points changes.

There is a power failure and the outstation goes offline. ClearSCADA detects the fault and changes the quality of the 4 points to Bad as they may be inaccurate or out of date. But the current values of the points remain the same as before the power failure.

As Execute on Quality Change is enabled and 1 or more of the 4 input points have changed quality, the Logic program executes. The 4 input points now have Bad quality and so they are excluded from the Logic program’s calculation. This means that the result of the calculation is 0 and this is the value that is written to the derived point. As one or more of the inputs also have Bad quality, the Logic program sets the Current Quality value of the derived point to Bad. This means that the Current Value and Current Quality of the derived point indicates that there may be a problem with the Logic program or its inputs.

If the Execute on Quality Change feature was disabled, the Logic program would only execute when any of the input values changed. So when the outstation failed, the Logic program would not execute as the values for the points would not have changed. Consequently, the value of the derived point would remain the same - there would be no indication that the values used to calculate the derived point value are now unreliable.

To choose whether a Logic program executes when the quality states of its inputs have changed, you need to use the Execute on Quality Change check box on the Logic tab of Logic Program Form:

  • If you check the Execute on Quality Change check box, the system will execute the program if it detects:
  • A change in the value of the input (Logic programs that are set to On Input Processed execute automatically when their input values change)
  • A change in the quality of the input.
  • If you clear the Execute on Quality Change check box, the system will execute the program only when its input values change.

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.

Define whether a Logic Program can be Executed Manually

To execute a Logic program manually, users select the Execute action from the context-sensitive menu for the Logic program database item. The availability of the Execute action is dependent on the permissions of the user’s User account and the configuration of the Logic program—if the Logic program’s Allow Manual Execution setting is selected, the Execute action is available; if the Allow Manual Execution setting is de-selected, the Execute action is unavailable, even if the user has sufficient permissions to access the actions for the program.

Being able to control the availability of the Execute action is useful as it means you can create Logic programs that can only be executed by ClearSCADA, either as a response to input changes or on a timed basis.

To define whether a Logic program can be executed manually, display the Logic Program Form, select the Logic tab, then either:

  • Check the Allow Manual Execution check box to make the Execute action available on the context-sensitive menu for the Logic program.

Or

  • Clear the Allow Manual Execution check box to make the Execute action unavailable on the context-sensitive menu for the Logic program.

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.

Define which Permission is Required to Execute a Logic Program

You can use the Execution Permission setting to define which security permission (if any) is required to access a Logic program’s Execute action. Each Logic program has its own Execution Permission setting, so you can control which users can execute Logic programs on a per-program basis.

NOTE: The availability of the Execute action can also be restricted by using the Allow Manual Execution setting (see Define whether a Logic Program can be Executed Manually). If the Allow Manual Execution setting is disabled for a Logic program, users will not be able to access the program’s Execute action even if they have the required Execution Permission.

Example:

A Logic program named ‘PumpControl’ is configured to have an Execution Permission setting of Control. It is also configured to have the Allow Manual Execution setting enabled.

A user logs on via a User account named ‘A Hall’. The ‘A Hall’ user has the Control permission for the ‘PumpControl’ program. This means that ‘A Hall’ can access the Execute action for the ‘PumpControl’ program, as Control is the defined Execution Permission.

Another Logic program named ‘SensorVariation’ is also configured to have an Execution Permission of Control. However, the ‘A Hall’ user does not have the Control permission for the ‘SensorVariation’ program. When the ‘A Hall’ user accesses the context sensitive menu for the ‘SensorVariation’ program, the Execute action is not included as an option.

The configuration of the ‘PumpControl’ program is changed so that it no longer has Allow Manual Execution enabled. With the change in place, the ‘A Hall’ user is unable to select the Execute action for the ‘PumpControl’ program, even though ‘A Hall’ has the Control permission. This is because the Allow Manual Execution setting is disabled; the Execute permission is unavailable to users, irrespective of their permissions for the program.

To define the Execution Permission for a Logic program, display the Logic Program Form, select the Logic tab, then use Execution Permission combo box to choose the required permission. Only users that have the selected permission will be able to access the program’s Execute action (which is only available if the Allow Manual Execution setting is also enabled, see Define whether a Logic Program can be Executed Manually).

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.

Associate the Execution of a Logic Program with a Property in the Database

If your Logic program is configured to execute On Interval (see Define the Execution Method for a Logic Program), you can use the Trigger setting to associate the Logic program with any property of any database item. When there is a change to the value of the selected property, the Logic program will execute.

If the Logic program is set to have an Execute Method of On Interval, the time specified for the Interval defines how often the program checks the value of the Trigger item. For example, if the Interval is 30S, the program will check the value of the Trigger item every 30 seconds, and the program will only execute if the value of the Trigger item has changed.

The Trigger feature is useful when you need a Logic program to execute as a response to the value or state of a database item that is not used as an input in the program. For example, you may have a Logic program that uses various points as inputs, but is triggered by the state of the outstation with which those points are associated. The outstation state is not defined as an input in the program (as it is not relevant to the program), but when the state of the outstation changes, the Logic program executes.

You can set a Logic program to execute in response to a change to any property field in the database. To do this, display the Logic Program Form, select the Logic tab, then use the browse button feature of the Trigger field to select the required property. When the value of the selected property changes, the Logic program will be executed.

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.

Define the Maximum Number of Executions that can be Queued

If your Logic program is configured to execute On Input Processed (see Define the Execution Method for a Logic Program), you can use the Execution Queue Size setting to define the maximum number of executions that can be placed in a queue. This feature is designed for use with programs that need to perform calculations on values that are reported by outstations.

When an outstation reports values, it reports them in a block (multiple values are reported at once). As a Logic program can only be executed in response to one value at a time, ClearSCADA stores the block of values in a queue, referred to as the execution queue. Any Logic programs that use the values reported by the outstation then use the values in the queue—they execute for each value in turn. This means that Logic programs execute in response to the reported values rather than the current values (some of the current values may have been updated by the time the program is executed).

The Execution Queue Size defines the maximum number of values that can be stored in the execution queue. Typically, the default Execution Queue Size of 250 is appropriate. However, you may need to change this setting if your program is not performing its calculations on the reported values (this often means that there are too many values being reported, and the execution queue is full and so cannot store any new values).

If the execution queue becomes full, any further values reported by the outstation will be disregarded, so if the Execution Queue Size is too small, data could be lost.

To change the Execution Queue Size, display the Logic Program Form, select the Logic tab, then enter the required number in the Execution Queue Size field. We recommend that you do not increase the Execution Queue Size beyond 1000 as doing so may cause the server to run out of memory.

Further Information

Display the Logic Program Form: see Configure an ST Program, Ladder Diagram, SFC or FBD.


Logic Guide - Define when a Logic Program Updates its Outputs (Logic Program Properties and Values)

Define when a Logic Program Updates its Outputs

You can use the Logic program Forms to define when a Logic program updates its output values:

  1. Display the configuration Form for the relevant program (see Configure an ST Program, Ladder Diagram, SFC or FBD).
  2. Select the Logic tab.
  3. Use the Update Outputs combo box to set a program to update its outputs:
  • Changed Outputs Only—If the program calculates values that are different to the existing output values, the existing output values are overwritten. The new values from the program’s results replace the existing output values (but only for those outputs that have different values to those in the program’s results). This setting is useful when you only want the program to update the outputs to reflect changes in the Logic program’s calculated results.

The main advantages of using the Changed Outputs Only setting are that the program will only generate historic records for values that have changed and there is no needless processing (as ClearSCADA only writes new values to the outputs that need to be updated and only generates historic records for values that have changed).

  • All Outputs (Always)—The program will write a new value, even if the result of the program returns the same output value as the existing output value. This setting is useful when you only want the program to update on every execution.

The main advantage of using the All Outputs (Always) setting is that you can check that the program is executing correctly at the required intervals or when the inputs are updated. This means you can have confidence that the program is functioning correctly, even though its outputs are not changing.

  • All Outputs (If Any Changed)—If the program returns one or more output values that are different to the existing values, new values are written for each of the outputs. This setting is mainly designed for use with Logic programs that write to the PresetTimestamp or PresetQuality fields of internal points.

To help you understand how the All Outputs (If Any Changed) setting works, we will begin by explaining how the PresetTimestamp and PresetQuality fields can be used.

The Preset Timestamp and PresetQuality data fields are used to store the time stamp and quality values for the internal point’s historic record. By default, the PresetTimestamp value is the current time and the PresetQuality value is Good, but by writing to these fields, you can apply a different time stamp and quality value. This is useful when you use an internal point to store a value that is derived from other point values, for example, for storing the average value of a selection of points. By writing to the PresetTimestamp and PresetQuality fields, you can set the historic record of the internal point to match the time stamps and quality values of the points used in the calculation. If the PresetQuality and PresetTimestamp were not written, the internal point’s historic record would use the time stamp for the time of the calculation and the quality would be ‘Good’ (which may not be the case).

The PresetQuality and PresetTimestamp are written when the internal point is next updated, and once written, are reset. This means that once they have been applied, they have no effect on further updates (unless the program is coded so that the PresetQuality and PresetTimestamp fields are written to again).

If you have a Logic program that writes to the PresetQuality and/or PresetTimestamp fields, your choice of Update Outputs affects when the Preset values are applied:

  • With the Changed Outputs Only setting, the Preset fields are only applied if there is a change to the calculated value (that is to be stored in the internal point changes). This is because the Logic program is set to only write to the CurrentValue of the internal point if the calculated value has changed since the last execution. If the Logic program does not write to the CurrentValue, there is no new historic value to be logged and so the Preset values are ignored.
  • With the All Outputs (If Any Changed) setting, the Preset fields are applied if the Logic program’s inputs have a change of quality, a different time stamp, or the result of the Logic program’s calculation changes. If any of these changes occur, the Logic program writes to the CurrentValue, PresetTimestamp and PresetQuality fields of the internal point. This means that a historic record is created even if the calculated value of the Logic program has not changed.
  • With the All Outputs (Always) setting, the Preset fields are applied every time the Logic program executes. This is because the Logic program writes the PresetTimestamp, PresetQuality and CurrentValue of the internal point on each execution, irrespective of whether any of these values has changed. As a result, there is a historic value logged for every execution of the Logic program.

To configure the other Logic tab settings, see Configure an ST Program, Ladder Diagram, SFC or FBD.


Logic Guide - Define whether a Logic Program Executes Methods after a Failed Method (Logic Program Properties and Values)

Define whether a Logic Program Executes Methods after a Failed Method

You can use the Ignore Method Errors check box to define how a Logic program reacts to methods that are unable to be performed successfully. This feature is especially useful with programs that are used to perform several methods in sequence.

Use the Ignore Method Errors check box to define whether the program ignores methods that cannot be performed successfully.

When a program executes, it reads its inputs, then evaluates its internal calculations, then writes its outputs. Finally, it performs its methods (if any). It performs each method in turn.

By default, if one of its methods cannot be performed, the program aborts any attempt to perform subsequent methods. This means that one erroneous method in a program will result in other methods being aborted.

You can change this setting so that the program will ignore erroneous methods, and continue to perform any other methods.

To control whether a Logic program continues to execute its methods following an unsuccessful method:

  1. Display the configuration Form for the relevant program (see Configure an ST Program, Ladder Diagram, SFC or FBD).
  2. Select the Logic tab.
  3. Either:
  • Check the Ignore Method Errors check box to allow the program to ignore erroneous methods and continue to execute further methods.

Or:

  • Clear the Ignore Method Errors check box to set the program so that it makes no attempt to execute methods following an unsuccessful attempt to perform a method.

To configure the other Logic tab settings, see Configure an ST Program, Ladder Diagram, SFC or FBD.


Logic Guide - Define the Conversion Types for a Logic Program (Logic Program Properties and Values)

Define the Conversion Types for a Logic Program

You can use the Byte-String Conversions and String to Time Conversion Mode combo boxes to define how a Logic program converts values. The conversions that you select will effect the results of the program, so you need to choose the correct types of conversion for your needs.

To define the conversion types:

  1. Display the configuration Form for the relevant program (see Configure an ST Program, Ladder Diagram, SFC or FBD).
  2. Select the Logic tab.
  3. Use the Byte - String Conversions combo box to choose the conversion type for converting byte values into string values.

The available options include:

  • Character—The system will use ASCII codes to convert the byte number into a string value. Each character has a a corresponding ASCII code—the program will read the byte value as an ASCII code.
  • Decimal Integer—The system will use binary codes to convert the byte number into a string value. Each character has a corresponding binary code—the program will read the byte value as a binary code.
  • Hexadecimal Integer—The system will use hexadecimal codes to convert the byte number into a string value. Each character has a corresponding hexadecimal value—the program will read the byte value as a hexadecimal value.
  4. Use the String to Time Conversion Mode combo box to define the format of string values that are converted to time values. The format can be:
  • Windows—String values are converted to time values in the Windows format (DD/MM/YEAR HH:MM:SS.ms).

NOTE: The Windows format varies according to the locale that is set for your PC.

  • IEC 61131-3—String values are converted to time values in the IEC 61131-3 standard format DATE#YEAR-DD-MM-HH:MM, for example, DATE#2004-03-20-12:15:00.

To configure the other Logic tab settings, see Configure an ST Program, Ladder Diagram, SFC or FBD.


Logic Guide - Define the Number of Instructions for a Logic Program (Logic Program Properties and Values)

Define the Number of Instructions for a Logic Program

You can use the Instruction Limit setting to define the maximum number of instructions permitted for a Logic program. The program will be aborted if this number of instructions is reached before the program has been executed. This means that if a program contains code errors that can cause an ‘infinite loop’, the Instruction Limit will stop the program from using all of the CPU resources.

Each program has a number of instructions. The instructions are referred to as op codes. You can see the op codes for a single execution of an ST program by using the Compile with Diagnostics feature (see Compiling an ST Program or ST Library).

When a program is executed, the system performs each instruction in turn. This continues until each of the instructions in the program have been executed or the Instruction Limit has been reached.

Normally, a program runs and has its instructions executed without affecting system performance. This is because the default setting for the Instruction Limit is 10000, and it would take a very large program to require this many instructions.

However, if there is an infinite loop in the program, the program will not be able to complete. The system continues to perform each instruction in turn, but as the code or diagram structure is badly constructed, the list of instructions cannot be completed. This means that eventually the Instruction Limit is reached and the program is aborted.

The Instruction Limit feature prevents badly written programs from using all of the CPU resources.

Example of a Program with an Infinite Loop Logic Error:

The following code is incorrect and contains a Logic error that causes an infinite loop:

PROGRAM NAME
VAR
i:INT := 20;
Count : INT;
END_VAR
WHILE i < 50 DO
Count := COUNT +1;
END_WHILE;
END_PROGRAM

In the example, the WHILE statement is used to increase the Count value by +1 when the i value is less than 50. As the i value is defined as 20, it is less than 50 and so the count will increase by 1—this is an infinite loop as the program cannot end. The system would continue to attempt to execute this program until the Instruction Limit was reached, at which point it would abort the program.

To identify that the code contains a Logic error, you could examine the Logic Execution Status List (a Query list). The list contains a Number of Instructions entry which shows the number of instructions on the last execution of the program. If this number is approaching the Instruction Limit or exceeds it, there may be a Logic error and you will need to examine the code for an infinite loop. Of course, it may be that your program is very large and has intentional loops and a very high number of instructions. If this is the case, you may need to alter the Instruction Limit setting.

To change the Instruction Limit setting:

  1. Display the configuration Form for the relevant program (see Configure an ST Program, Ladder Diagram, SFC or FBD).
  2. Select the Logic tab.
  3. Enter the required maximum number of instructions per program in the Instruction Limit field.

To configure the other Logic tab settings, see Configure an ST Program, Ladder Diagram, SFC or FBD.


Logic Guide - Define the Time Zone to be used for Calculations within the Logic Program (Logic Program Properties and Values)

Define the Time Zone to be used for Calculations within the Logic Program

If your Logic program makes use of time conversion functions such as MAKE_DATE_AND_TIME_FROM_OPC, it needs to be able to interpret the relative parts of the time values. For example, if an OPC Relative time is defined as 'DAY+5H', the program needs to be able to determine whether DAY begins at midnight UTC, midnight local time with Daylight Saving Time, or midnight local time without Daylight Saving Time. By default, a Logic program will use Co-ordinated universal Time (UTC).

By using the Program Time Zone setting, you can choose which time zone is to be used when interpreting relative time values.

To change the Program Time Zone:

  1. Display the configuration Form for the relevant program (see Configure an ST Program, Ladder Diagram, SFC or FBD).
  2. Select the Logic tab.
  3. Use the Program Time Zone combo box to choose the appropriate time zone setting for your Logic program:
  • Coordinated Universal Time (UTC)
  • Local Time without Daylight Saving Time
  • Local Time with Daylight Saving Time (for regional variations to GMT standard time, such as British SummerTime).

The Program Time Zone setting that you choose is used for time conversions within the Logic program (the Interval Offset Time Zone setting defines the time zone that is used to determine when the program is executed—see Define the Interval Settings for a Logic Program).

  4. Save any changes that you have made to the configuration.

Further Information

Date and Time.

Time Zones: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Logic Guide - Configure an ST Library (Logic Program Properties and Values)

Configure an ST Library

You can use the ST Library Form to configure the settings for an ST Library. The Form allows you to:

  • View the Name and configure the Help View for the ST Library. These settings are available on the Identification tab. For more information, see Defining Identification Details in the ClearSCADA Guide to Core Configuration.
  • Associate the ST Library with up to 4 custom pick actions by using the User Methods tab. For more information, see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration.
  • Choose the Color for Function Blocks Stored in ST Libraries
  • Create a ToolTip for an ST Library.

NOTE: You cannot use the ST Library Form to code the function block(s) for an ST Library. You need to use the ST Library Editor to create the code (see Using Libraries in ST Programs).

To display the ST Library Form and configure its settings:

  1. In the Database Bar, right-click on the ST Library icon to display a context sensitive menu.
  2. Select the Properties option to display the ST Library Form.
    Use the Library tab to set the color for Function Blocks in the library and define a ToolTip.
    Use the Identification tab to set the Help View for the ST Library.
    Use the User Methods tab to associate the ST Library with up to 4 custom actions.

  3. Use the Identification tab to define the Help View for the ST Library as required (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  4. Use the User Methods tab to associate the ST Library with up to 4 custom pick actions as required (see Using the User Methods Tab to Define Custom Actions the ClearSCADA Guide to Core Configuration).
  5. Use the Color button to set the color for Function Blocks that are stored in the ST Library (see Choose the Color for Function Blocks Stored in ST Libraries).
  6. Use the Comment field to enter a string that will be shown as a generic ToolTip for function blocks that are stored in the ST Library (see Create a ToolTip for an ST Library).
  7. Save the ST Library Form.


Logic Guide - Choose the Color for Function Blocks Stored in ST Libraries (Logic Program Properties and Values)

Choose the Color for Function Blocks Stored in ST Libraries

You can use the Color button on the Library tab of the ST Library Form to define the color for function blocks that are stored in the library. When a function block that is stored in the library is added to a Function Block Diagram, the function block will be colored accordingly. For example, if you choose red and then use one of the ST Library's function blocks on a Function Block Diagram, the function block will be displayed in red.

This 'POWER' function block is stored in an ST Library and is added to a Function Block Diagram as a User Function Block. As the ST Library has its Color setting to Red, the function block is displayed in red.

To choose the color for a function block that is stored in the ST Library:

  1. Display the ST Library Form and select the Library tab (see Configure an ST Library).
  2. Select the Color button to display the Color Palette.
  3. Use the Color Palette to choose an existing system color or custom color or select the ... button to access the Color window. You can use the Color window to create a new custom color. For more information on the Color Palette and Color window, see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration.

To configure the other Library tab settings, see Configure an ST Library.


Logic Guide - Create a ToolTip for an ST Library (Logic Program Properties and Values)

Create a ToolTip for an ST Library

You can use the Comment field on the Library tab of the ST Library Form to create a generic ToolTip for the function blocks that are stored in the ST Library. When one of the function blocks is used as a user function block on a Function Block Diagram, the diagrammatic version of the function block will be associated with the comment. When a user positions the cursor over the function block, a ToolTip will be displayed containing the comment. This feature is especially useful when you want to provide an indication as to which ST Library contains the code for a function block—by providing details of the ST Library in your comment, you can make it easy for other operators and engineers to locate the ST Library that contains the function block.

Comment is shown as a ToolTip

To create a generic comment for an ST Library ToolTip:

  1. Display the ST Library Form and select the Library tab (see Configure an ST Library).
  2. Enter the string for the ToolTip in the Comment field.

To configure the other Library tab settings, see Configure an ST Library.


Logic Guide - OPC Properties for Logic Programs (Logic Program Properties and Values)

OPC Properties for Logic Programs

Logic programs are represented in the ClearSCADA database by database items. Like other database items, Logic programs have properties that can be accessed via OPC.

To view the properties for a Logic program:

  1. Select the OPC button on the Operate toolbar to display the OPC Bar in place of the Database Bar.
  2. Expand the System icon, then expand the Root Group.
  3. Expand the hierarchy until you locate the required Logic program.
  4. Expand the program to reveal its tags. Each tag represents a property (and the value that is stored for that property) of the Logic program. Further tags are located within the Config tag.
  5. Position the cursor over any of the tags to display a brief description of the tag in a ToolTip.


Logic Guide - Logic Data Types

Logic Data Types

Logic programs have values that use the data type names that are specified in the IEC 1131-3 standard. These data type names have different names in the Windows Automation standard and the ClearSCADA code. This means that the name for the data type of a value will vary depending on whether you access it in Logic, OPC (which uses the Windows Automation standard), or the ClearSCADA Database Schema (which uses the ClearSCADA code data type names).

In this section, we explain how to Display the OPC Data Type for a Property. We also provide a table that shows the different data type names for each standard (see Data Types for Logic, OPC, and ClearSCADA) and information on how the categories for data types (see Data Type Hierarchy).


Logic Guide - Display the OPC Data Type for a Property (Logic Data Types)

Display the OPC Data Type for a Property

You can view the OPC data type for any property in the database by performing the following steps:

  1. Select the OPC button to display the OPC Data Bar.
  2. Expand the Root branch in the tree-structure.
  3. Continue to expand the branches until you have located the required property for the relevant database item.
  4. Right-click on the database item property to display a context sensitive menu.
  5. Select the Display Value option to access the Value window.
  6. Examine the Data Type entry. This shows the OPC data type name for the value.

A table that shows the OPC data type names and their corresponding Logic and ClearSCADA data type names is included in Data Types for Logic, OPC, and ClearSCADA.


Logic Guide - Data Types for Logic, OPC, and ClearSCADA (Logic Data Types)

Data Types for Logic, OPC, and ClearSCADA

Each Logic program has values that are of a specific data type, for example, the Name value of a point is a STRING data type. However, the name for the data type varies depending on whether you access the value via Logic, OPC, or ClearSCADA (access the value in the ClearSCADA database schema). For example, in Logic, the Name value of a point is a STRING data type, whereas the Name value in OPC is a VT_BSTR data type.

The following table shows the names of the data types in Logic, OPC (automation), and ClearSCADA:

Logic | OPC (Automation) | ClearSCADA (shown on Database Schema) | Range
BOOL | VT_BOOL | Boolean | True or False
SINT | VT_I1 | Byte | -128 to 127
INT | VT_I2 | Word | -32768 to 32767
DINT | VT_I4 | Long | -2147483648 to 2147483647
USINT | VT_UI1 |  | 0 to 255
UINT | VT_UI2 | Unsigned Word | 0 to 65535
UDINT | VT_UI4 | Unsigned Long | 0 to 4294967295
REAL | VT_R4 | Float | 32 bit precision floating point
LREAL | VT_R8 | Double | 64 bit precision floating point
TIME | VT_DATE |  |
TIME_OF_DAY | VT_DATE | Time |
DATE | VT_DATE |  |
DATE_AND_TIME | VT_DATE | Time |
STRING | VT_BSTR | Variant |
BYTE | VT_UI1 |  | 0 to 255
WORD | VT_I2 |  | 0 to 65535
DWORD | VT_I4 | Color | 0 to 4294967295

Internally, Logic uses:

  • A FILETIME to represent DATE, and DATE_AND_TIME. Conversion to VT_DATE usually involves a small loss of precision, for example a VT_DATE is only accurate to a few uS, whereas a FILETIME is accurate to 100nS. In the conversion to VT_DATE, the FILETIME is rounded to the nearest 10uS. DATE and DATE_AND_TIME values can be mapped to VT_DATE and VT_BSTR variant types.
  • A signed 64 bit integer to represent TIME types, where each increment represents 1mS. TIME types can be mapped to a number of VARIANT types including VT_BSTR, VT_UI1, VT_I2, VT_I4, VT_R4, VT_R8 and VT_VARIANT. For numeric values, the value is the number mS, for VT_BSTR, the time value is converted to a string. The format of the string is either day [-]hh:mm:ss.mmm, or an 61131 time constant T#XhYmZs depending on the configuration of the program.
  • A FILETIME to represent TIME_OF_DAY. The actual value is offset to the unix epoch of 1-JAN-1970. Thus 1-JAN-1970 00:00:00.000 represents 00:00:00.000, and 1-JAN-1970 23:59:59.999 represents 23:59:59.999. Values outside of the range 1-JAN-1970 00:00:00.000 to 1-JAN-1970 23:59:59.999 are not strictly valid. TIME_OF_DAY values cannot be mapped to VARIANT types.

The data types that are available to a function, function block etc. are organized into a hierarchy. For more information, see Data Type Hierarchy.

For more information on the ClearSCADA Database Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.


Logic Guide - Data Type Hierarchy (Logic Data Types)

Data Type Hierarchy

Many functions and function blocks can use various types of values. To make things simpler, the data types are grouped into categories. For example, the SUB function can use LREAL, REAL, DINT, INT, SINT, UDINT, UINT, USINT, and TIME inputs. These data types are part of the ANY_MAGNITUDE category. This means that when we state that the SUB function has inputs that can be of the type ANY_MAGNITUDE, its inputs can be of any data type that is in the ANY_MAGNITUDE category (as shown below).

The categories for the various data types are organized in a hierarchy as follows:

So, if a function is described as requiring inputs of the type ANY_BIT, it means that the function's inputs can be DWORD, WORD, BYTE, or BOOL. ANY_BIT is the name of a category; it is not a data type in its own right.

For information on the data types supported by each function and function block, see Built-in Functions, Function Blocks, and Conversions.


Logic Guide - Using Actions Associated with Logic Programs

Using Actions Associated with Logic Programs

Logic program database items provide access to a variety of actions, some of which are designed specifically for use with Logic. In this section, we describe the purpose of these ‘Logic-specific’ pick actions, which include:

  • Disable Execution
  • Enable Execution
  • Execute
  • Restart Execution
  • Set Variable.


Logic Guide - Disable Execution (Using Actions Associated with Logic Programs)

Disable Execution

Associated with: ST Programs, Function Block Diagrams, Ladder Diagrams, Sequential Function Charts

Security permission required to access this pick action: Configure

The Disable Execution action allows you to set a Logic program so that it cannot be executed. Once you have selected the Disable Execution action for a Logic program, the program’s Execute method cannot be triggered (and the Execute action cannot be selected).

If you use the Disable Execution action on a Logic program, that program will be unable to execute again until its Enable Execution action is selected. If you select the Enable Execution action, the Execute action and method for the Logic program become available again, and so the Logic program can be triggered to execute when required.

You can see whether a Logic program has had its execution status set to disabled by using the Status Display (the Execution status shows Enabled or Disabled). For more information, see Logic Specific Status Attributes.

Also see Enable Execution.


Logic Guide - Enable Execution (Using Actions Associated with Logic Programs)

Enable Execution

Associated with: ST Programs, Function Block Diagrams, Ladder Diagrams, Sequential Function Charts

Security permission required to access this pick action: Configure

By using the Enable Execution action, you can allow a Logic program to be executed via the Execute action or Execute method. The Enable Execution action is only available on Logic programs that currently cannot be executed (programs that previously had their Disable Execution action selected).

You can see whether a Logic program has had its execution status set to enabled or disabled by using the Status Display (the Execution status shows Enabled or Disabled). For more information, see Logic Specific Status Attributes.

Also see Disable Execution.


Logic Guide - Execute (Using Actions Associated with Logic Programs)

Execute

Associated with: ST Programs, Function Block Diagrams, Ladder Diagrams

Security permission required to access this pick action: Configure

Use the Execute action to trigger a Logic program manually. When you select the Execute action, the Logic program runs and the functionality provided by the program is applied. For example, if you have a Logic program that calculates the average value of two input points, when you select its Execute action, the program will read its inputs and calculate the average value at that time.

You can only select the Execute action if the Logic program’s execution status is set to Enabled (see Enable Execution) and the Logic program is configured to allow manual execution (see Define whether a Logic Program can be Executed Manually).


Logic Guide - Restart Execution (Using Actions Associated with Logic Programs)

Restart Execution

Associated with: ST Programs, Function Block Diagrams, Ladder Diagrams, Sequential Function Charts.

Security permission required to access this pick action: Configure

Use the Restart Execution action to reset a Logic program’s internal variables to their initial values and recalculate the next execution time (if the program executes On Interval).

When you select the Restart Execution action, all internal variables are reset to their initial values and the Logic program is queued for execution immediately. Any intervals for future executions are calculated from the time you selected Restart Execution (now). The only exception to this is if the Logic program has a defined offset, in which case, when you select the Restart Execution action, the offset is applied before the program is queued for execution.

NOTE: The Restart Execution action is not applicable to ST Libraries.


Logic Guide - Set Variable (Using Actions Associated with Logic Programs)

Set Variable

Associated with: ST Programs, Function Block Diagrams, Ladder Diagrams, Sequential Function Charts. This action is also available on ST Libraries but has no effect

Security permission required to access this pick action: Control

Use the Set Variable action to define the value for a variable in a Logic program. This is useful when you need to test that a Logic program uses a variable as expected, prior to setting the Logic program as ‘live’ on your system. For example, let’s say you create a Logic program that is to trigger an action when a Boolean input variable is True. During testing, you can use the Set Variable action to set the variable to True so that you can check that the Logic program responds to the True value with the expected response.

When you select the Set Variable action for a Logic program, a Set Variable dialog box is displayed. In the dialog box, enter the Name of the variable you want to set, then use the Value field to define the test value. The defined value will be applied to the specified variable and will remain in place until it is overwritten by a reported value or you set the variable manually.


Logic Guide - Logic Specific Status Attributes

Logic Specific Status Attributes

You can view the status of any Logic program by accessing its Status Display:

  1. In the Database Bar, right-click on the Logic program in which you are interested to display its context sensitive menu.
  2. Select the View Status option to display the Logic program’s Status Display.

The Status Display provides status information about the Logic program, including attributes that are common to many types of database item such as Id and Full Name, as well as the following Logic-specific status attributes:

  • Execution—Has three possible entries:
  • Enabled—The Logic program has been manually enabled via the Enable Execution method. This means that the Logic program can be executed.
  • Disabled—The Logic program has been manually disabled via the Disable Execution method. This means that the Logic program cannot be executed unless a user manually enables the Logic program. However, if the Logic program is copied or exported, the copy or export version will revert to the default setting of Enabled and so could be executed.
  • Out of Service—The Logic program cannot be executed as it is set to out of service in its configuration. The Logic program will not execute, even if the Enable Execution method is used—it can only execute when it has the In Service setting enabled in its configuration.
  • Overruns—The number of times that the program has overrun. An overrun is when the program is set to execute at a set interval, but it takes longer than the interval to run. Overruns usually indicate that a Logic program is not running as often as required. If a program is overrunning, you should investigate it thoroughly to determine exactly why it is taking longer than expected to run, then make the appropriate configuration changes. If a Logic program continues to overrun, it can affect the running of other Logic programs.
  • Last Execution—The start time of the Logic program’s latest execution.
  • Execution Time—The length of time taken for the program’s latest execution.
  • Debugging—Indicates whether a ViewX client has the Logic program open in Debug mode (Yes or No). If the Debugging status is Yes, the Logic program will not run and cannot execute as another user is debugging the program. Manual and scheduled executions of the program cannot take place until the program is taken out of debugging mode (and the Debugging status becomes No).


QueryPad Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


QueryPad Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


QueryPad Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


QueryPad Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


QueryPad Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


QueryPad Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to use QueryPad, an SQL diagnostics tool that is supplied with your ClearSCADA software solution.

For details about the subjects covered in this Guide, see Welcome to the ClearSCADA Guide to QueryPad.


QueryPad Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed to be used by any user who is responsible for creating SQL queries.


QueryPad Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


QueryPad Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


QueryPad Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


QueryPad Guide - Welcome to the ClearSCADA Guide to QueryPad

Welcome to the ClearSCADA Guide to QueryPad

Welcome to the ClearSCADA Guide to QueryPad, an SQL query diagnostics tool that is supplied with your ClearSCADA software solution. In this Guide, we will explain how to use QueryPad to test your SQL queries and improve their efficiency.

QueryPad is an application that runs independently of ViewX and it provides diagnostic information about your SQL query. By examining the diagnostics information, you can see how the Query Processor (used to process SQL queries in ClearSCADA) handles your query, and use that information to determine whether your query could be changed to work more efficiently.

In the QueryPad Guide, we describe how to run, connect, and use the diagnostic features of the QueryPad application. We also provide information about the various phases of the Query Processor’s processing, as to make effective use of the QueryPad diagnostics, you will need to understand how the Query Processor processes queries.

For information on running and using QueryPad, refer to:

  1. Working with QueryPad.

For information on the various phases undertaken by the Query Processor when you submit an SQL query, refer to:

  1. SQL Parsing and Verification
  2. SQL Join Optimization
  3. SQL Execution.


QueryPad Guide - Working with QueryPad

Working with QueryPad

QueryPad is an SQL query diagnostics tool that runs independently of ViewX and is supplied as part of your ClearSCADA software solution. It allows you to test your SQL queries and provides details that may help you to improve the efficiency of your queries (and therefore improve performance).

In this section, we explain how to:

  • Display QueryPad
  • Connect QueryPad to a Database
  • Define whether QueryPad Displays the Results of your SQL Query
  • Add your SQL Query to QueryPad
  • Run your Query in QueryPad
  • Use the QueryPad diagnostics (see Understanding the QueryPad Diagnostics)
  • Use QueryPad to View the Underlying Database Tables
  • View your QueryPad Command History
  • Disconnect QueryPad from a Database.


QueryPad Guide - Display QueryPad (Working with QueryPad)

Display QueryPad

The QueryPad application is located in the same directory as your ClearSCADA installation by default. To run it, you need to use Windows Explorer to locate the QueryPad.exe file, then double-click on QueryPad.exe. Alternatively, you can use a command prompt to run the QueryPad.exe application.

When you run QueryPad, the QueryPad window is displayed. It is empty by default:

The QueryPad window consists of:

  • Menu—Contains the following menus and options:
  • File—Contains a single option: Exit. Select this option if you want to quit and close the QueryPad window.
  • Edit—Contains these options:
  • Undo—Cancels the previous action you made using the QueryPad window
  • Cut—Removes a highlighted section and places it on your PC’s clipboard
  • Copy—Copies a highlighted section to your PC’s clipboard
  • Paste—Adds the contents of your PC’s clipboard into the SQL Entry Pane
  • Clear—Removes the information shown in the Information Pane.
  • Information Pane—Displayed in the top half of the QueryPad window, the Information Pane is read-only and it is where the diagnostic information about your SQL Query is displayed.
  • SQL Entry Pane—Displayed in the bottom half of the QueryPad window, the SQL Entry Pane is where you need to enter or paste your SQL Query. Pressing the Enter key in your SQL Query causes a line break. To run the SQL Query for diagnostics, you should press the Ctrl and Enter keys simultaneously.
  • Status Bar—Shown at the bottom of the QueryPad window, the Status Bar provides the following information:
  • Connection Status—Indicates whether QueryPad is connected to a database
  • Asynchronous Mode Status—Indicates whether Asynchronous Mode is on or off. In many situations, Asynchronous Mode should be off as this mode is designed primarily for internal testing.
  • Resultset Fetching Status—Indicates whether QueryPad fetches and displays the results of your query. If it is on, QueryPad will include the results of your query in its diagnostics; if it is off, QueryPad will execute your query but will only provide diagnostic details about the query. For information on how to turn Resultset Fetching on and off, see Define whether QueryPad Displays the Results of your SQL Query.


QueryPad Guide - Connect QueryPad to a Database (Working with QueryPad)

Connect QueryPad to a Database

Before you can use QueryPad to test a query, you need to connect it to the appropriate system (the system that contains the tables that you reference in your query). QueryPad can connect to 1 system at a time.

To connect QueryPad to the appropriate database, you can either:

  • Use a QueryPad command to connect to a system:
  1. Display QueryPad
  2. In the SQL Entry Pane, enter the following:
?Connect <system name> <username> <password>

Where:

  • ?Connect is the command to connect to a database
  • <system name> is the name of the database to which you want QueryPad to connect. Do not include the angle brackets < >.
  • <username> and <password> are the user name and password for a ClearSCADA user account. If you have a username but do not use a password with that account, just enter the username and ignore the <password> part of the command. Do not include the angle brackets < >.
  • Your entry is case sensitive.

For example, the following command would connect QueryPad to a database named Main via the ‘MNoble’ user account which uses the password ‘SE661’:

?Connect Main MNoble SE661

NOTE: If you omit the username and password, QueryPad will connect via the Guest user account for the selected database.

  3. When you have entered the appropriate command, press a Ctrl key and the Enter key simultaneously to execute the command.
  • Use the Connect dialog box to connect to a system. The Connect dialog box is displayed if you try to run an SQL Query in QueryPad and QueryPad is not currently connected to a system. (You can also display the Connect dialog box by entering ?CONNECT without any parameters, then pressing a Ctrl key and the Enter key simultaneously)
  1. Enter your SQL Query in the SQL Query Entry Pane, then press a Ctrl key and the Enter key at the same time. If QueryPad is not already connected to a system, the Connect dialog box is displayed.
  2. Use the System combo-box to choose the required system (database)
  3. Use the User field to define the name of the user account that is to be used. If the Guest user account is to be used, leave the User field empty.
  4. Enter the password for the selected user account in the User field (or leave the User field empty if the Guest user account is to be used for the connection)
  5. Select the OK button.

If the connection is valid, the Information Pane will display:

Connecting to <system name>...
Connected OK

If the connection fails, an error message detailing the reason for the failure is shown. For example, if you attempt to log on via a user account that does not exist, the error message will be:

*** LogOn failed - Access is denied. ***


QueryPad Guide - Define whether QueryPad Displays the Results of your SQL Query (Working with QueryPad)

Define whether QueryPad Displays the Results of your SQL Query

By using the RESULTSET command, you can choose whether QueryPad displays the results of your query. The default setting for the RESULTSET command is On, which means that QueryPad will fetch and display the results of your query when it is executed. The results are shown in the Information Pane along with diagnostic information.

Result set is shown in Information Pane along with diagnostic information.

Depending on your needs, you may choose to set the RESULTSET command to Off so that QueryPad does not show the results of your query. This may be useful if you are only interested in the diagnostic information (which is shown when your query is executed). Turning off RESULTSET also means that the query can be executed more quickly and that the Information Pane will be less cluttered (as it will only display the diagnostics).

To turn RESULTSET on or off:

  1. In the SQL Entry Pane, enter the following:
?RESULTSET <On or Off>

Where:

<On or Off> is case sensitive. Do not enter the angle brackets < >. For example, to turn RESULTSET from off to on, enter:

?RESULTSET On
  2. Press a Ctrl key and the Enter key simultaneously to enter the command.
    A message is displayed in the Information Pane showing whether Resultset is Off or Resultset is On.

NOTE: If you want to change RESULTSET, you can enter ?RESULTSET On or ?RESULTSET Off and press Ctrl and Enter before you enter your SQL query.


QueryPad Guide - Add your SQL Query to QueryPad (Working with QueryPad)

Add your SQL Query to QueryPad

To test an SQL query in QueryPad, you need to add your query to the SQL Entry Pane (the lower section of the QueryPad display). There are two ways of doing this, either:

  • Enter your SQL query manually in the SQL Entry Pane. You can type in your SQL Query, using the Enter key to insert a line break.

Or:

  • Copy your SQL Query from another display such as the SQL window for a List (displayed when you access a list and then select the View menu, then SQL option). Simply highlight the SQL query, then use the copy option (available in the Edit menu and also by pressing the Ctrl and C keys simultaneously) to store a copy of the SQL on your PC’s clipboard. Then select an entry position in the SQL Entry Pane and use the Paste option (available in the Edit menu and also by pressing Ctrl and V keys simultaneously) to add the copied SQL query to QueryPad.

When you have added your SQL Query to QueryPad, you can proceed to test it (see Run your Query in QueryPad).


QueryPad Guide - Run your Query in QueryPad (Working with QueryPad)

Run your Query in QueryPad

When you have entered or pasted your SQL Query into the SQL Query Entry Pane in QueryPad, you can run it by pressing a Ctrl key and the Enter key simultaneously.

When you press Ctrl and Enter at the same time, QueryPad will attempt to execute the query.

If your SQL query does not require any parameters, QueryPad will execute the query. However, if your query requires user-defined parameters, a Parameters dialog box is displayed, prompting you to enter the parameters:

There is a row for each required parameter, with the first parameter in the query being shown as the uppermost row and numbered 01. Next to the parameter number is an indication of the type of parameter that QueryPad is expecting, for example, (STRING) means that the QueryPad is expecting a string value.

For each parameter:

  • Use the combo-box for the row to choose the type of value for the parameter that you define. This is the type of value that will be passed, and if it cannot be converted to the type of value that QueryPad expects, an error will be returned.
  • Use the field next to the combo-box to define the value for the parameter.

When you have defined any required parameters, select the OK button to close the Parameters dialog box and run the SQL query.

When QueryPad executes the query, it will perform one of the following, depending on the RESULTSET status:

  • Execute the query and provide diagnostic information only in the Information Pane
  • Execute the query and display the query along with diagnostic information in the Information Pane.

For further information on the RESULTSET command, see Define whether QueryPad Displays the Results of your SQL Query.

When QueryPad executes your query, it provides diagnostic information about the query in the Information Pane. For more information on the diagnostics, see Understanding the QueryPad Diagnostics.

Further Information

Value Types: see Data Types in the ClearSCADA Guide to Expressions.


QueryPad Guide - Understanding the QueryPad Diagnostics (Working with QueryPad)

Understanding the QueryPad Diagnostics

When you execute a query in QueryPad, diagnostic information is shown in the Information Pane. The diagnostic information provides details about the action taken by the Query Processor when you submitted your query.

Diagnostics information is shown in the Information Pane.

To make use of the diagnostics information, you need to understand how the Query Processor responds when you submit a query.

When an SQL query is submitted, the Query Processor runs through the following phases:

  1. Parse the query (see SQL Parsing and Verification). During this phase the Query Processor checks your query has the correct syntax. If the syntax is correct, the Query Processor proceeds to the next phase.
  2. Verify the query (see SQL Parsing and Verification). During this phase, the Query Processor checks that your query has correct grammar. If the grammar is correct, the Query Processor proceeds to the next phase.
  3. Join optimization (see SQL Join Optimization). During this phase, the Query Processor calculates an efficient way to access the tables that are referenced in your query. When it has determined an appropriate access plan, the Query Processor executes your query.
  4. Execute the query (see SQL Execution). The Query Processor executes your query and returns the appropriate result set. Depending on the settings you have in place in QueryPad, the results may be shown in the Information Pane. The Information Pane will also contain diagnostic data.

For more detailed information, please refer to the documentation for each phase (as listed above).


QueryPad Guide - Use QueryPad to View the Underlying Database Tables (Working with QueryPad)

Use QueryPad to View the Underlying Database Tables

You can use QueryPad to view the underlying database tables, the columns in those tables, and any foreign keys for the tables. To display information about the underlying database tables, you need to use the following commands:

  • TABLES—Use to display information about the database tables that can be searched (on the system to which QueryPad is connected)
  • COLUMNS—Use to display information about the columns in the tables that can be searched (on the system to which QueryPad is connected)
  • KEYS—Use to display information about any foreign keys for the tables that can be searched (on the system to which QueryPad is connected).


QueryPad Guide - TABLES Command (Working with QueryPad)

TABLES Command

You can use QueryPad’s TABLES command to display information about the tables that can be searched (on the system to which QueryPad is currently connected).

The tables used by ClearSCADA are grouped into sets, referred to as schemas. The schemas are used to organize the database into related groups, for example, there are schemas for every driver, Core tables, Historic tables etc.

To use the TABLES command:

  1. Display QueryPad
  2. Connect to the appropriate system (see Connect QueryPad to a Database)
  3. Enter the ?TABLES command followed by the arguments that are appropriate to your requirements. The correct syntax is:
?TABLES <Schema> <Table>

Where:

  • <Schema> is the name of the group that contains the tables you want QueryPad to display. Do not include the angle brackets < >.
  • <Table> is the name of the table that you want QueryPad to display.

If you specify an exact schema and table, then only the tables in that schema are listed. However, if you specify a pattern for a schema or table (by using the % character), then the tables that match the pattern are listed. For example:

?TABLES % %

This will set QueryPad to list every table (the first % represents all schemas and the second % represents all tables)

?TABLES % %Point%

This will set QueryPad to list every table that has ‘Point’ as part of its name (the first % represents every schema, and %Point% represents those tables that contain Point and any other characters as part of their name)

?TABLES ScadaPackModbus %Analog%

This will set QueryPad to list those tables in the ScadaPackModbus schema that have Analog as part of their name.

NOTE: The wildcards use the standard SQL LIKE syntax.

  4. Press Ctrl and Enter simultaneously to submit your command.
    QueryPad displays a list of the tables that match the criteria set in your command.

For each table in the list, QueryPad displays:

  • Row—The number of the row occupied by the table in QueryPad’s result set (table list)
  • Name—The name of the table.
  • Owner—The schema to which the table belongs
  • Remarks—The display name of the table (if it has a display name). This matches the name that is shown on the tab for the aggregate on Forms in ViewX.


QueryPad Guide - COLUMNS Command (Working with QueryPad)

COLUMNS Command

You can use QueryPad’s COLUMNS command to display information about the columns in a table or in a particular set of tables. When you use the COLUMNS command, QueryPad displays a list of the columns that match the criteria in your command. QueryPad can only provide columns information for those tables that are on the system to which QueryPad is currently connected.

To use the COLUMNS command:

  1. Display QueryPad
  2. Connect to the appropriate system (see Connect QueryPad to a Database)
  3. Enter the ?COLUMNS command followed by the arguments that are appropriate to your requirements. The correct syntax is:
?COLUMNS <Schema> <Table> <Column>

Where:

  • <Schema> is the group that contains the tables that have the columns you want QueryPad to display. Do not include the angle brackets < >.
  • <Table> is the name of the table that contains the columns that you want QueryPad to display.
  • <Column> is the name of the column you want QueryPad to display.

If you specify an exact schema and table, then only the columns of that table are listed. However, if you specify a pattern for a schema or table (by using the % character), then the columns that match the pattern are listed. For example:

?COLUMNS % % %

This will list the columns in every table (as the % represents every schema, every table, and every column respectively)

?COLUMNS % CDBObject %

This will list every column in the CDBObject table.

?COLUMNS % CPointAlgManual Current%

This will list every column that is in the Internal Analog table and has a name that begins with ‘Current’.

?COLUMNS % % CurrentState

This will list the CurrentState columns of every table.

  4. Press Ctrl and Enter simultaneously to submit your command.
    QueryPad displays a list of the columns that match the criteria set in your command.

For each column in the list, QueryPad displays:

  • Row—The number of the row occupied by the column in QueryPad’s result set (column list). This row number is for the results displayed in QueryPad and is included to make it easier to read the QueryPad results. It does not relate to the rows in the database.
  • Name—The name of the column.
  • Datatype—The type of the data in the column. This can be:
  • 2 (VT_I2) - Signed 2-byte integer
  • 3 (VT_I4) - Signed 4-byte integer (also used for reference and color columns)
  • 4 (VT_R4) - Single precision floating point
  • 5 (VT_R8) - Double precision floating point
  • 7 (VT_DATE) - Date/time
  • 8 (VT_BSTR) - String
  • 11 (VT_BOOL) - Boolean
  • 12 (VT_VARIANT) - Column can contain data of any of the other types
  • 17 (VT_UI1) - Unsigned 1-byte integer
  • 18 (VT_UI2) - Unsigned 2-byte integer
  • 18 (VT_UI4) - Unsigned 4-byte integer
  • Length—For columns that contain strings, the Length indicates the maximum number of characters permitted. For other types of column, the Length is 1. The string length only applies when data is returned via an external interface such as ODBC or OLE DB (if the string exceeds the maximum length, it will be truncated). If you use a Query Processor interface such as QueryPad, a Queries List or a Query in Logic, the full string will be displayed (the string is not truncated if it exceeds the maximum length).
  • Table_Name—The name of the table to which the column belongs.
  • Desc—A description of the column.
  • Table Owner—The schema to which the table that contains the column belongs.
  • QP_Attr—The column’s attributes. The attributes are a bitmask, which means that a number of the attributes can be combined by adding the relevant individual values. For example, if the QP_Attr is 12 (4+8), it means that the column in the ConfigVersion field and it is read-only.

The possible attributes are:

  • 1 - The column is an index column (may or may not be unique).
  • 2 - The column is a unique index column (will be combined with 1).
  • 4 - The column is the ConfigVersion field.
  • 8 - The column is read-only.
  • 16 - The column is the Object ID.
  • 32 - The column specifies the foreground color.
  • 64 - The column specifies the blink.
  • 128 - The column is the item's short name.
  • 256 - The column is the item's full name.
  • 512 - The column specifies the background color.
  • 1024 - Not used.
  • 2048 - The column is a historic record ID.
  • 4096 - The column is the Event Journal's sequence number.
  • 8192 - The column is the Event Journal's comment number. This is used in conjunction with the sequence number to control Event Journal comments.
  • 16384 - The column specifies a hyperlink.
  • 32768 - The column is the Event Journal’s Source column.
  • 65536 - The column is an Area Of Interest field.
  • 131072 - The column belongs to an alarm condition.
  • 262144 - The column can be used as a constraint column.
  • Ordinal—A number that identifies the position of the column in its table. The ordinal number indicates the order in which the columns are defined in your query (as the ?COLUMNS command returns the columns sorted in alphabetical order).


QueryPad Guide - KEYS Command (Working with QueryPad)

KEYS Command

You can use QueryPad’s KEYS command to display information about any Foreign Keys for the tables in the database. A Foreign Key is a column in one table that has values that are used in a Primary Key in another table.

Each table has a Primary Key which is a column that contains values that uniquely identify each row in the table. For example, the DBObject table lists every database item, and so its Primary Key is the ObjectId column (which is hidden from view by default).

If a table has a column that contains values that are used in the Primary Key in another table, that column is referred to as a Foreign Key. The table that contains the Foreign Key is called the Foreign Table. (The table with Primary Key values that match the Foreign Key values is called the Primary Table).

Example:

In ClearSCADA, the CSCADAPackMAnalog table contains information about SCADAPack Modbus analog points. Each row represents a different point, and so the ObjectIds of the points are the Primary Key for the table. The table also contains an Outstation column. The values in the Outstation column are the unique identifiers of the outstations with which the analog points are associated.

If you wish to see the CSCADAPackMAnalog table’s ID, Name and Outstation columns, display the CSCADAPackMAnalog table in ClearSCADA and edit its SQL query to:

SELECT
ID, ID, FULLNAME, OUTSTATIONID
FROM
CSCADAPACKMANALOG

ID is the Primary Key for the CSCADAPackMAnalog table.
The Outstation column contains values that are used as the Primary Key in another table, and so this means the Outstation column is a Foreign Key.

The CAdvModbusOS table contains values for each individual advanced Modbus outstation. Each row represents an individual outstation and so the ID is the Primary Key for the table.

The Outstation ID is the Primary Key of the CAdvModbusOS table. The values in the ID column for the CAdvModbusOS table are also used in the Outstation column in the CSCADAPackMAnalog table. This means that there is a Primary Key-Foreign Key relationship between the two tables: CAdvModbusOS is a Primary Table in relation to the CSCADAPackMAnalog table (and the Outstation column of the CSCADAPackMAnalog table is the foreign key).

To use QueryPad to display information about foreign keys:

  1. Display QueryPad
  2. Connect to the appropriate system (see Connect QueryPad to a Database).
  3. Enter the ?KEYS command followed by the arguments that are appropriate to your requirements. The correct syntax is:
?KEYS <Primary Schema or %> <Primary Table> <Foreign Schema> <Foreign Table>

Where:

  • <Primary Schema> is the name of the Primary schema (the schema that contains the Primary Table). You can also enter % instead of a Primary Schema if you wish (this will not affect what information is displayed in QueryPad). Do not include the angle brackets < >.
  • <Primary Table> is the name of the Primary Table. You need to include the Primary Table for the KEYS command otherwise the KEYS command will not return the information you require.
  • <Foreign Schema> is the name of the Foreign schema (the schema that contains the Foreign Table). Do not include the angle brackets < >.
  • <Foreign Table> is the name of the Foreign Table. Do not include the angle brackets < >.

If you specify an exact Foreign Schema and Foreign Table, then QueryPad will only display information about the foreign keys that are part of that Foreign Schema and/or Table. However, if you specify a pattern for a Foreign Schema or Foreign Table (by using the % character), QueryPad will display information about every Foreign Key for the chosen Primary Table. For example:

% CAdvModbusOS % %

QueryPad will display Foreign Key information about every Foreign Key for the CAdvModbusOS table.

% CAdvModbusOS % CDBPulse

QueryPad displays information about the CDBPulse table’s Foreign Keys to the CAdvModbusOS table.

The information that is listed in QueryPad includes:

  • Row—The number of the row occupied by the Foreign Key in QueryPad’s result set (Foreign Key list). This row number is for the results displayed in QueryPad and is included to make it easier to read the QueryPad results. It does not relate to the rows in the database.
  • PK_TABLE—The name of the Primary Table.
  • PK_COLUMN—The name of the column that is the Primary Key for the Primary Table.
  • FK_TABLE—The name of the Foreign Table.
  • FK_COLUMN—The name of the column in the Foreign Table that is recognized a Foreign Key to the Primary Table.
  • KEY_SEQ—A sequence number. This should be 1.
  • PK_OWNER—The schema to which the Primary Table belongs.
  • FK_OWNER—The schema to which the Foreign Table belongs.


QueryPad Guide - View your QueryPad Command History (Working with QueryPad)

View your QueryPad Command History

You can use Ctrl+a directional key to view the commands you have made (in sequential order). This is useful when you have used QueryPad to display a significant amount of information, as it allows you to quickly find previous commands so that you can retreat them or make further commands that are similar.

To view the command history, you have to be logged on to QueryPad and have made one or more commands.

To view the command history:

  • Press a Ctrl key and the up directional key to display the previous command that you entered in QueryPad. The command is shown in the SQL Entry Pane.
  • Press a Ctrl key and the down directional key to display the next command that you entered in QueryPad. This only applies after you have used Ctrl+Up to view a previous command. Again, the command is shown in the SQL Entry Pane.


QueryPad Guide - Disconnect QueryPad from a Database (Working with QueryPad)

Disconnect QueryPad from a Database

When you have finished using QueryPad, you should disconnect it from the database to which it is connected.

To disconnect QueryPad from a database:

  1. Display QueryPad
  2. In the SQL Entry Pane, enter the following:
?Disconnect
  3. When you have entered the command, press a Ctrl key and the Enter key simultaneously to execute it. QueryPad is disconnected from the database and a disconnection message is shown in the Information Pane.


QueryPad Guide - SQL Join Optimization

SQL Join Optimization

When a query is submitted, the Query Processor parses and verifies the query (see SQL Parsing and Verification). If the query passes the parsing and verification checks, the Query Processor begins the optimization process.

During the optimization process, the Query Processor performs calculations on every possible permutation for accessing the information required for your query. It then chooses the permutation that places the least demand on system resources. This means that your query is executed as efficiently as possible.

The optimization process is called the SQL Join Optimization phase, and to perform it, the Query Processor uses the SQL Join Optimization Algorithm.

The SQL Join Optimization Algorithm consists of 4 stages:

  1. Build the Sub-Clause List
  2. Determine the Sub-Clause Types
  3. Calculate the Table Order Permutations
  4. Calculate Cost and Determine the Final Access Plan.

In each of the above sections, SQL terms are used frequently. If you are unfamiliar with SQL terminology or need extra information about a term, please refer to SQL Join Optimization Terminology.


QueryPad Guide - SQL Join Optimization Terminology (SQL Join Optimization)

SQL Join Optimization Terminology

The SQL Join Optimization documentation uses many SQL terms. As there are many different extensions of SQL and terminology varies between organizations and countries, we have provided a small glossary of the some of the terms we use (listed here alphabetically):

  • Access Path
  • Access Plan
  • Constant Expression
  • Cost
  • Final Access Plan
  • Index Columns
  • Index Value
  • Inner Join
  • Internal Data Structure (‘The Referenced Table’)
  • Join Order
  • Outer Join
  • Sub-Clause.


QueryPad Guide - Access Path (SQL Join Optimization)

Access Path

The access path is the way in which the Query Processor accesses each table that is to be searched (as defined in your query).

There are 3 types of access path that can be used:

  • Scan—To obtain the values required for your query, the Query Processor has to read every row in the relevant table. Scan is an inefficient type of access path.
  • Non-Unique Lookup—To obtain the values required for your query, the Query Processor has to read several, but not all, rows in the relevant table (there are several rows with the same value for a column in the table, for example, there could be many rows with the same value for the ParentGroupId column). Non-Unique Lookup access paths can only be used with Index Columns.
  • Unique Lookup—To obtain the values required for your query, the Query Processor has to read one specific row in the relevant table (there is only one row with the required value, for example, a search for an item’s Id would mean that the Query Processor has to read the Id column for 1 row in the object table). Unique Lookup is an extremely efficient type of access path.

To determine which type of access path has to be used for each table that is referenced in your query, the Query Processor examines the access sub-clauses in your query (see Access Sub-Clauses).

At the end of the SQL Join Optimization phase, the Query Processor will have calculated access paths for every possible permutation of the Join Order. So, for a query that searches 2 tables, there will be 2 join orders (Table A, Table B; Table B, Table A) and 2 access paths (one for Table A and one for Table B).

The access paths and join order for a permutation are referred to collectively as an Access Plan.


QueryPad Guide - Access Plan (SQL Join Optimization)

Access Plan

During the join optimization phase, the Query Processor calculates:

  • An Access Path for each table that is referenced in your query
  • Every possible permutation (Join Order) for the tables in your query.

When referred to collectively, the access paths and join order for a single permutation are called an Access Plan.

The Query Processor will calculate an access plan for every permutation, and will also calculate the cost of each access plan. The access plan with the lowest cost is the access plan that will be used to obtain the values for your query. This is called the Final Access Plan.


QueryPad Guide - Constant Expression (SQL Join Optimization)

Constant Expression

A constant expression is an expression that consists only of:

  • Literals (fixed data values)
  • Parameter markers (references to variables)
  • Constant functions, such as CURRENT_TIMESTAMP.

For example:

  • 123
  • 1 + 2
  • TIMESTAMP '2009-12-12 00:10:00'
  • OPC'D'
  • CURRENT_TIMESTAMP
  • ?
  • ? || '%'

In the various expressions and conditions used throughout the SQL Join Optimization documentation, Value1, Value2 etc., are used to represent constant expressions.


QueryPad Guide - Cost (SQL Join Optimization)

Cost

The cost is a calculated amount that reflects the search’s demand on system resources. So, a search with a high cost places higher demand on system resources than a search with low cost.

The Query Processor attempts to execute your queries as efficiently as possible by using the search with the lowest cost.


QueryPad Guide - Final Access Plan (SQL Join Optimization)

Final Access Plan

The Final Access Plan is the access plan that the Query Processor will use to obtain the values required for your query. It is the access plan that the Query Processor has calculated to have the lowest cost.


QueryPad Guide - Index Columns (SQL Join Optimization)

Index Columns

An Indexed Column is a column in the database that can be accessed more quickly than other columns (there are internal mechanisms that allow these columns to be searched more easily than the other columns).

There are a limited number of Index Columns, and the Index Columns that are available vary according to the type of table that is being searched. The following table shows the Index Columns that are available for each type of database table:
Table Type | Unique Indices | Non-Unique Indices
Object | Id, FullName | ParentGroupId, Search Keys
Aggregate | - | Id
Alarm Condition | - | Id
Event Journal | RecordId | Id, Source, FileId
Point Historic | RecordId | Id
Processed Historic | RecordId | Id
Forecast Historic | RecordId | Id
Data Grid | - | -
Data Table | - | As configured

The columns are listed in cost order, for example, for the Object table, the Id column has a lower cost than the FullName column (and so can be searched more efficiently than the FullName column).

The values in the rows of an Index Column are referred to as index values.


QueryPad Guide - Index Value (SQL Join Optimization)

Index Value

An Index Value is the value for a particular row in an Indexed Column (see Index Columns).


QueryPad Guide - Inner Join (SQL Join Optimization)

Inner Join

A join between tables where the order in which the tables are searched does not affect the result.


QueryPad Guide - Internal Data Structure ('The Referenced Table') (SQL Join Optimization)

Internal Data Structure (‘The Referenced Table’)

For each table that is referenced by your query, the Query Processor has an internal data structure; an internal representation of the table that is being searched. For example, if your query is searching for point values and historic point values, there will be 2 internal data structures: 1 data structure representing the CDBPoint table (as this is the database table that contains the point values) and 1 data structure that represents the CDBHistoric table (the database table that contains historic point data).

We also refer to an internal data structure as ‘the referenced table’.

Each internal data structure is associated with:

  • An access path that determines how the rows in the table are to be searched
  • Constraints that reduce the number of rows in the table that are to be searched for a Scan or Non-Unique Lookup access path. There can be 0 constraints, a single constraint, or multiple constraints
  • A filter condition (which may be empty) that determines whether a row should be returned in the result set
  • A cost that is calculated based on the table type, access path, and constraints.

The attributes listed above are used by the Query Processor when determining an efficient way to execute your query.


QueryPad Guide - Join Order (SQL Join Optimization)

Join Order

A join order is a permutation of the order in which the tables referenced in your query are searched. For example, if your query is being used to search two tables - Table A and Table B, the possible join orders are:

  • A, B
  • B, A

The order in which the tables are searched can have a significant effect on the performance of a query. For this reason, the Query Processor calculates the cost for each Access Plan, and then uses the results to determine which joint order is the most efficient.


QueryPad Guide - Outer Join (SQL Join Optimization)

Outer Join

A join between tables where the order in which the tables are searched does affect the result.


QueryPad Guide - Sub-Clause (SQL Join Optimization)

Sub-Clause

A sub-clause is an AND-separated condition. The Query Processor creates an internal list of the sub-clauses in your query and categorizes them. It does this to avoid any performance inhibiting factors that may occur as a result of the order of the sub-clauses in your query. The internal list also allows the Query Processor to access the sub-clauses more efficiently when making calculations.


QueryPad Guide - SQL Join Optimization Algorithm (SQL Join Optimization)

SQL Join Optimization Algorithm

When a query is submitted, the Query Processor runs its parsing and verification checks (see SQL Parsing and Verification), then, if the query passes those checks, the Query Processor begins the optimization phase.

During the optimization phase, the Query Processor runs the SQL Join Optimization algorithm. This allows it to identify the most efficient way to access the data required for your query.

The SQL Join Optimization algorithm consists of these stages:

  1. Build the Sub-Clause List
  2. Categories the sub-clauses (see Determine the Sub-Clause Types):
  1. Add filter sub-clauses to the filter condition of the referenced table
  2. Add constraint sub-clauses to the constraints of the referenced table
  3. Calculate the Table Order Permutations:

For each permutation of the join-order:

  1. Examine each access clause:
  • If the access sub-clause references a single table, use it to determine that table’s access path
  • If the access sub-clause references two tables, it is assigned to the right-most table. If the sub-clause references an indexed column, it is used to determine the access path; if it does not reference an indexed column, it is added to the filter condition for the table.
  • If a table already has an access path, and the sub-clause can provide a better access path, the sub-clause used to provide the previous access path is added to the table’s filter condition
  2. Examine each link sub-clause:
  • Assess the link sub-clause to the filter condition of the right-most table that is referenced by the sub-clause
  3. Determine the cost of each access path (see Calculate Cost and Determine the Final Access Plan)
  4. Multiply the cost of each access path together to determine the cost for the join order (see Calculate Cost and Determine the Final Access Plan). At this stage, the join order and its associated access paths are referred to as the access plan.
  4. Choose the access plan with the lowest cost. This access plan is now referred to as the Final Access Plan (see Calculate Cost and Determine the Final Access Plan).

When the Query Processor has determined the most appropriate access plan (the Final Access Plan), it executes the query by performing the execution algorithm (see SQL Execution).


QueryPad Guide - Build the Sub-Clause List (SQL Join Optimization)

Build the Sub-Clause List

Your SQL query may use conditions to limit the Query Processor’s search so that it only searches for data that meets certain criteria. The conditions affect the way the query is processed, and so for the first stage of the optimization algorithm, the Query Processor builds a list of sub-clauses (conditions that are separated by AND operators).

For example, in the following condition, there are two sub-clauses:

( Id = 10 OR Id =12 ) AND Value >= 75.0

The sub-clauses are:

  • ( Id = 10 OR Id =12 )
  • Value >= 75.0

By creating the list of sub-clauses, the Query Processor can avoid any performance inhibiting issues related to the order of the sub-clauses. This is because the sub-clause list allows the Query Processor to use the sub-clauses in any order without affecting the result.

To build the sub-clause list, the Query Processor examines the join specifiers and the WHERE clause in your query:

  • If your query’s join clause uses a NATURAL JOIN of the form ‘Table A NATURAL JOIN Table B’, a sub-clause is added to the sub-clause list. The sub-clause that is added takes the form TableA.Column=TableB.Column and there is 1 sub-clause added for each column that is present in both Table A and Table B.
  • If your query’s join clause uses an ON condition, the Query Processor splits the condition into AND-separated sub-clauses, with each sub-clause added to the sub-clause list.
  • If your query’s join clause uses USING (ColumnList), the Query Processor will add a sub-clause of the form TableA.Column = TableB.Column to the sub-clause list. It will add 1 sub-clause for each column in the defined ColumnList.
  • The Query Processor will also split the WHERE clause in your query into AND-separated sub-clauses. Each of these AND-separated clauses are added to the sub-clause list.

When the Query Processor has built the sub-clause list, it may transform some of the list entries into one or more equivalent sub-clauses. This process does not affect the syntax of your SQL query, it is simply used to make it easier for the Query Processor to calculate access paths.

The Query Processor will also collate comparisons in your query—it disregards any redundant comparisons, for example, if a sub-clause has >10 and >11, >10 will be ignored as it is made redundant by the >11 . Again, this does not affect the syntax of your query, but allows the Query Processor to handle your query more efficiently.

When the sub-clause list has been built, the Query Processor will categorize the sub-clauses to improve efficiency (see Determine the Sub-Clause Types).


QueryPad Guide - Determine the Sub-Clause Types (SQL Join Optimization)

Determine the Sub-Clause Types

When the Query Processor has created a list of the sub-clauses in your query, it begins to categorize the sub-queries according to type. By categorizing the sub-queries, the Query Processor can perform the remaining phases of the optimization algorithm more efficiently.

There are 5 categories of sub-clause:

  • No-Dependency Sub-Clauses
  • Constraint Sub-Clauses
  • Access Sub-Clauses
  • Filter Sub-Clauses
  • Link Sub-Clauses.

When the Query Processor has categorized the sub-clauses, it places some of the sub-clauses in internal lists and some in the filter condition for the tables that are referenced. It uses the internal lists and filter conditions in a later phase of the algorithm. For example, the Query Processor places the access sub-clauses in an internal list so that when it needs to check the access sub-clauses for later phases of the algorithm, it can find the access sub-clauses quickly and efficiently.

When the Query Processor has categorized the sub-queries, it will proceed with the next phase of the SQL Optimization algorithm: Calculate the Table Order Permutations.


QueryPad Guide - No-Dependency Sub-Clauses (SQL Join Optimization)

No-Dependency Sub-Clauses

No dependency sub-clauses are sub-clauses that do not reference a table. These types of sub-clause are of little use in a query, but may exist as they are valid SQL.

During the ‘Determine Sub-Clause Type’ phase of the optimization algorithm, the Query Processor identifies any no-dependency sub-clauses in your query and uses them to create a special condition.

At the very start of the query’s execution phase (see SQL Execution), the Query Processor evaluates the no-dependency sub-clause ‘special condition’. If it is true, the query is executed, the search is performed and the appropriate result set is returned; if it is false, the query is not executed, the search is not performed and an empty result set is returned.

NOTE: The execution phase of a query comes after the Parse, Verify, and Optimize phases.


QueryPad Guide - Constraint Sub-Clauses (SQL Join Optimization)

Constraint Sub-Clauses

During the ‘Determine Sub-Clause Type’ phase of the optimization algorithm, the Query Processor identifies any constraint sub-clauses. The constraint sub-clauses in your query are used to limit the number of rows that need to be searched by the Query Processor. As they can significantly reduce the amount of data that has to be searched, constraint sub-clauses can have a major affect on the efficiency of your query.

The Query Processor identifies the constraint sub-clauses by looking in your query for sub-clauses that have the following characteristics:

  • They reference a single table
  • They have to reference a constraint column (which may be an indexed column). The constraint columns are shown in the table below
  • They have to be in a specific form (see table below).

    Table Type

    Constraint Columns

    Required Form

    Event Journal

    Id, Source

    Column = Value1

    Where Value1 is a constant expression

    Event Journal

    Id, Source

    Column = Value1 OR Column = Value2 OR...

    Where Value1 and Value2 are constant expressions and the ... indicates that there may be further components consisting of OR and a constant expression.

    Event Journal

    Source

    Source LIKE Value1

    Where Value1 is a constant expression

    Event Journal

    Source

    Source LIKE Value1 OR Source = Value2

    Where Value1 and Value2 are constant expressions.

    Event Journal

    Historic

    RecordTime

    RecordTime "op" Value1

    Where "op" is any comparison operator other than <> and Value1 is a constant expression.

In your query, you can apply one or more constraints to a single column. You can also apply constraints to multiple columns in the same table.

Constraint sub-clauses are not used to determine the access path even if they meet the requirements for an access sub-clause. Also, constraint sub-clauses are not added to a table’s filter condition.

When the Query Processor has identified the constraint sub-clauses in your query, it adds them to an internal list of constraints which is used later in the optimization algorithm.


QueryPad Guide - Access Sub-Clauses (SQL Join Optimization)

Access Sub-Clauses

An access sub-clause is a sub-clause that references one column in one table or two columns in two tables, and at least one referenced column has to be an index column (see Index Columns). The Query Processor uses the access sub-clauses to determine the access paths for your query (see Access Path).

During the Determine Sub-Clause Type phase of the optimization algorithm, the Query Processor identifies the access sub-clauses in your query. To do this, it looks for sub-clauses that have the following characteristics:

  • Either:
  • References 1 index column in 1 table

or

  • References 2 columns in 2 tables, with at least 1 of the columns being an index column
  • Takes one of the following forms:
  • TableA.Column = Value1
  • TableA.Column = Value1 OR TableA.Column = Value2 OR ...
  • TableA.Column1 = TableB.Column2

Where:

  • ‘TableA’ and ‘TableB’ are references to different tables
  • ‘Value1’ and ‘Value2’ are constant expressions
  • ‘Column’, ‘Column1’, and ‘Column2’ are references to columns
  • ‘OR...’indicates that in a real SQL Query, there may be further OR conditions of the form TableA.Column = Value.

When the Query Processor has identified the access sub-clauses in your query, it adds them to an internal list. The Query Processor refers to this list in a later stage of the optimization algorithm (it uses the access sub-clauses in its calculations to determine the access plan for your query).


QueryPad Guide - Filter Sub-Clauses (SQL Join Optimization)

Filter Sub-Clauses

A filter sub-clause is a sub-clause that references a single table and is not used to determine the access path (it references a single table and does not match the criteria needed for a constraint or access sub-clause).

When the Query Processor has identified the filter sub-clauses, it adds them to an internal list. In a later phase of the optimization algorithm, the Query Processor will assign each filter sub-clause to the filter condition of the table that it references. The filter condition of the table is then used during execution to determine which rows of the table will be included in the result set.

Further Information

Constraint Sub-Clauses

Access Sub-Clauses

Access Path

SQL Execution.


QueryPad Guide - Link Sub-Clauses (SQL Join Optimization)

Link Sub-Clauses

A link sub-clause is a sub-clause that:

  • References more than 2 tables

Or:

  • References 2 tables but cannot be used as an access sub-clause (as it does not meet the criteria for an access sub-clause).

When the Query Processor has identified the link clauses in a query, it stores them temporarily in an internal list. Later in the optimization algorithm, the Query Processor will assign each of the link sub-clauses to a filter condition for an appropriate table. The table that is chosen is:

  • One of the tables that is referenced by the link sub-clause in your query
  • The right-most table in the table order (as calculated by the Query Processor).

The link sub-clauses are assigned for every permutation of the table order (see Calculate the Table Order Permutations).

Example:

When the Query Processor has categorized the sub-clauses in a query, it begins to calculate the permutations for the table order. For each permutation, the Query Processor assigns the link sub-clauses to the right-most table in the table order. So, if a query is used to search three tables (Table A, Table B, and Table C) and the query contains a link sub-clause that references Table B and Table C, the link sub-clause will be assigned to each permutation as follows:

  • A,B,C

The link sub-clause is allocated to Table C as, in this order, Table C is the right-most table that is referenced by the sub-clause.

  • A,C,B

The link sub-clause is allocated to Table B as, in this order, Table B is the right-most table that is referenced by the sub-clause.

  • B,A,C

The link sub-clause is allocated to Table C as, in this order, Table C is the right-most table that is referenced by the sub-clause.

  • B,C,A

The link sub-clause is allocated to Table C as, in this order, Table C is the right-most table that is referenced by the sub-clause.

  • C,A,B

The link sub-clause is allocated to Table B as, in this order, Table B is the right-most table that is referenced by the sub-clause.

  • C,B,A

The link sub-clause is allocated to Table B as, in this order, Table B is the right-most table that is referenced by the sub-clause.


QueryPad Guide - Calculate the Table Order Permutations (SQL Join Optimization)

Calculate the Table Order Permutations

To run your SQL query as efficiently as possible, the Query Processor calculates the most effective order in which to access the tables you have referenced. To do this, the Query Processor examines the joins in your query and works out every possible order it could use to access the tables you have referenced. These orders are called permutations, and for each permutation, the Query Processor is able to establish:

  • A join order (the order in which the tables are accessed for that permutation)
  • An access path (the way in which the Query Processor will read the tables referenced in the permutation)
  • The cost (the demand that the permutation places on system resources).

So for each permutation, there is a join order, and one or more access paths. The join order and access paths for a single permutation are referred to as the permutation’s access plan. The Query Processor uses the access plan that has the lowest cost (see Calculate Cost and Determine the Final Access Plan).

When calculating the join orders for accessing the tables, the Query Processor:

  • Calculates the permutations for up to 5 tables. It uses the tables in the order in which they appear in your query and can calculate up to 120 permutations.

So, if you have referenced 7 tables using inner joins, the Query Processor will work out the permutations for the first 5 tables, and will then use the most efficient of these permutations (the remaining 2 tables will be accessed after the first 5 tables in the same order as they appear in your query).

If you have used an outer join for one of the first 5 tables, the Query Processor will only calculate the permutations for the tables that preceded the outer join. Any tables that are referenced after the outer join are accessed in the order in which they appear in your query (even if the 5 table limit has not been reached).

  • Calculates the cost of each permutation (see Calculate Cost and Determine the Final Access Plan). The permutation with the lowest cost places the least demand on system resources. This is the access path that the Query Processor will use to obtain the values needed for your query.

Examples:

In the following examples, database tables are represented by the letters A, B, C, D, and E, with A being Table A, B being Table B and so on:

  • If your query only has a single join that specifies A JOIN B, the Query Processor will calculate the 2 permutations (A,B; B, A). It will then choose the most efficient of the two permutations as its access path.
  • If your query references three tables using two inner joins (A JOIN B JOIN C), the Query Processor calculates the 6 possible permutations:

It then chooses to use the permutation that has the lowest cost.

  • If the first two joins in your query specify A JOIN B OUTER JOIN C, the Query Processor will calculate 2 permutations (A,B,C; B, A, C). Any joins that appear after the outer join will be accessed in the order in which they are defined in your query.

The Query Processor will then use the permutation that has the lowest cost.

  • If the first five joins in your query specify A JOIN B JOIN C OUTER JOIN D JOIN E, the Query Processor will calculate 6 permutations:

The Query Processor will then use the permutation that has the lowest cost.

The Query Processor does not calculate the permutations for any join that appears after an outer join, even if the limit of 5 joins has not yet been reached. So in this case, Table E is accessed last as the permutations are only calculated for the first 4 tables (the tables referenced before the outer join in the query).

For information on how the Query Processor calculates the cost of each access plan, see Calculate Cost and Determine the Final Access Plan.


QueryPad Guide - Calculate Cost and Determine the Final Access Plan (SQL Join Optimization)

Calculate Cost and Determine the Final Access Plan

With the access plan for each permutation established (see Calculate the Table Order Permutations), the Query Processor can begin calculating the cost of each access plan. The cost is the demand the access plan will place on system resources - the access plan with the highest cost is the least efficient and the access plan with the lowest cost is the most efficient (and will be used by the Query Processor for your query).

As part of its calculation for the costs, the Query Processor considers the type of table being searched and the type of access path being used (Scan, Non-Unique Lookup, or Unique Lookup):
Table Type | Scan Cost | Non-Unique Lookup Cost | Unique Lookup Cost
Object | Database item count/100 | Average number of items per group Or Number of items in search map | 1
Aggregate | Aggregate count/100 | 1 | 1
Alarm Condition | Number of items that can have alarms/33 | 1 | 1
Event Journal | Total number of records | Average number of records per database item | 1
Point Historic | - | Average number of records per database point | 1
Processed Historic | - | Average number of records per database point | 1
Forecast Historic | - | 100 | 1
Data Grid | Number of rows in Data Grid | - | 1
Data Table | Number of rows in Data Table | Number of rows in Data Table | 1

When considering the cost and Final Access Plan, you need to be aware that:

  • The Query Processor approximates the number of database items or aggregates in a table by using the nearest database index. This number is reduced by a factor of 100 to represent the fact that scanning items is quicker than scanning the same number of historic records.
  • If an Id or Source constraint has been applied to an Event Journal scan, the cost is the average number of records per database item multiplied by the number of items that match the constraint. If the constraint includes LIKEs, the number of items that match each LIKE is approximated as 1000.
  • If a RecordTime constraint has been applied to an Event Journal, Point Historic or Processed Historic lookup, the cost is reduced by a factor of 100.
  • Historic tables cannot be scanned (it is impossible to retrieve every historic record for every database item). Any access plan that contains a historic scan is rejected outright, and if all of the access plan permutations for a query involve a historic scan, the entire query is rejected.

You can achieve a similar effect to a historic scan by using SELECT ... FROM CDBHistoric WHERE Id IN ( SELECT Id FROM CHistory ). However, we recommend that you do not attempt this unless you are certain that the database does not contain large amounts of historic data.

  • If the cost of a table is calculated as 0 (e.g. there are no objects in that table), that table is not used to calculate the overall cost of the query. If a table with a cost of 0 was used in the calculation, it is possible that an empty table at the beginning of the table order could cause the Query Processor to choose an access plan with a high cost. To avoid this situation, tables with a cost of 0 are ignored.
  • If there are no access sub-clauses that reference two tables, or there is only one permutation, then the join order specified in the query is used. In this case, access and link sub-clauses are still assigned to tables to determine access paths, but the cost calculation is skipped.

When the cost of each access plan has been calculated, the Query Processor chooses the access plan with the lowest cost as the Final Access Plan (the access plan that will be used to retrieve the values requested in your Query). If there are multiple access plans with the same lowest cost, the Query Processor will use the first access plan that it calculated with that cost. For example, if there are 4 access plans that have the lowest cost of 1, the Query Processor will use the first access plan that it calculated (out of those 4 permutations).

The cost of each access plan and details of the Final Access Plan can be found in the database log file (see Display a Server Log File in the ClearSCADA Guide to Server Administration).

When the Query Processor has chosen the appropriate access path for the Final Access Plan, it begins the SQL Query Execution Process (see SQL Execution).


QueryPad Guide - SQL Parsing and Verification

SQL Parsing and Verification

Before it can execute your SQL query, the Query Processor has to run through several phases, the first of which is the parsing and verification phase. During the parsing and verification phase, the Query Processor checks that your SQL query is correct both syntactically and semantically (complies with the rules for SQL queries).

When a query is submitted, the Query Processor undertakes the two stages of the SQL Parsing and Verification phase:

  1. The Query Processor begins the Parsing and Verification stage by checking the syntax of your query. This involves checking that the form of the query complies with the rules for Structured Query Language.
  • If the syntax of your query is valid, it passes the parsing check and the Query Processor will proceed to the verification check.
  • If the syntax of your query is invalid, the Query Processor stops attempting to process the query and an error is logged in ClearSCADA. Your query is not executed.
  2. During the verification check, the Query Processor tests the semantics (the meaning) of your query. This involves checking that:
  • Every column and table reference is valid
  • The types and operands for a given operator are valid, for example, CurrentValue+2 is valid, but CurrentValue+'Teststring' is invalid
  • The types of the arguments for a given function are valid, for example, ABS(CurrentValue) is valid, but ABS(FullName) is invalid
  • Your query complies with the other SQL rules, including aliases being used consistently, columns being grouped correctly (if GROUP BY is used) etc.

If your query passes the verification check, the Query Processor continues to process the query by progressing to the join optimization phase (see SQL Join Optimization).

If your query fails the verification check, the Query Processor stops processing your query and an error is logged in ClearSCADA. Your query is not executed.

For more information on SQL syntax, please refer to the SQL Technical Reference documentation.


QueryPad Guide - SQL Execution

SQL Execution

When the Query Processor has completed the SQL Join Optimization phase, it proceeds to the execution phase, which is the final phase that is undertaken. During the execution phase, the Query Processor:

  1. Evaluates the ‘special condition’ for any no-dependency sub-clauses (sub-clauses that do not reference a table):
  • If your query contains no-dependency sub-clauses and they have ‘special conditions’ that evaluate to true, your query is executed. The Query Processor will perform the relevant search and return the appropriate result set.
  • If your query contains no-dependency sub-clauses, and one or more of those sub-clauses has a ‘special condition’ that evaluates to false, your query is not executed. Your search is not performed and an empty result set is returned (steps 2-4 inclusive of the execution phase are not applied to your query).
  • If your query does not contain no-dependency sub-clauses, your query is executed. The Query Processor will perform the relevant search and return the appropriate result set.
  2. Next, the Query Processor reads the rows of the referenced table(s). The access path of the referenced table is used to determine which of the rows are read:
  • If the access path is Scan, each of the rows are read. However, if constraints are in place, the scan may be limited to rows that match certain criteria, for example, a filter may limit the scan to rows in a specified time range.
  • If the access path is Non-Unique Lookup by Value, the Query Processor reads those rows that have an index value that matches the value specified in the condition.
  • If the access path is Unique Lookup by Value, the Query Processor reads the single row that has an index value that matches the value specified in the condition.
  3. With the rows read, the Query Processor proceeds by merging the row sets (this only applies if your query references multiple tables).
  4. Finally, the Query Processor reads each row in the row set. For each row in the row set, it creates a row that is added to the result set. The row that is added to the row set has the appropriate values for that row (the values that were requested in your query).

Any features that affect a row’s place in the result set are applied independently for each row. So, ordering, grouping, TOP etc., are applied to each row as it is added to the result set. This is much more efficient than applying ordering after the rows have been added to the result set.

When the Query Processor has added a row to the Result Set for each row in the Row Set, the execution phase is completed and the results are returned.


Scripting Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Scripting Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Scripting Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Scripting Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Scripting Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Scripting Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to access and use the Script editors for Mimics and the Alarm Banner in ViewX. By using these interfaces, you can create custom VBScripts that provide additional functionality.

For information on the subjects covered in this Guide, see Welcome to the Scripting Guide.


Scripting Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for engineers who have knowledge of VBScript and are responsible for configuring Mimics and the Alarm Banner to provide additional functionality. Although the Guide contains some examples of VBScript, it is not designed to document the VBScript programming language.


Scripting Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Scripting Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Mimics

ClearSCADA Guide to Trends

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


Scripting Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Scripting Guide - Welcome to the Scripting Guide

Welcome to the Scripting Guide

For many users, ClearSCADA already includes the user-friendly features and interfaces needed they need to fulfill their roles successfully. However, in some circumstances, you may need additional functionality that is not currently provided. To accommodate this, we have included a script feature that you can use to add functionality via Mimics and the Alarm Banner.

The script feature allows you to create client-side scripts (using VBScript™) to provide the extra functionality you need. For example, you can use Mimic scripts to provide navigation features, display dialog boxes, create Forms and to issue multiple controls via a single pick action.

In the ClearSCADA Guide to Scripting, you will find information on how to access the Script Editors and save and run scripts. We also provide information on the various ClearSCADA-specific objects, functions and properties that you can use in your Alarm Banner and Mimic scripts.

NOTE: To create Mimic and Alarm Banner scripts, you will need a thorough understanding of VBScript. While we do provide some script examples, it is beyond the scope of this documentation to deliver detailed information on VBScript.

To learn more about Mimic and Alarm Banner scripts, please refer to the following sections:

  • Scripts - Port and Firewall Information
  • Mimic Scripts:
  • Enable the Scripting Feature on a Mimic
  • Display the Script Editor for a Mimic
  • Code a Mimic Script
  • Save a Mimic Script
  • Run a Mimic Script
  • Associate a Mimic Script with a Script Pick Action
  • Set a Script to Run when a Mimic is First Displayed in Run Mode
  • Common Uses for Mimic Scripts
  • Alarm Banner Scripts
  • Display the Script Editor for the Alarm Banner
  • Code an Alarm Banner Script
  • Save an Alarm Banner Script
  • Run an Alarm Banner Script
  • Common Uses for Alarm Banner Scripts
  • Script Libraries. Script Libraries allow you to save parts of scripts in the database. You can then reference the Script Libraries in your Alarm Banner or Mimic scripts instead of having to enter the code that is stored in a Script Library repeatedly.
  • Debugging a Script.

We also provide details about the ClearSCADA-specific script objects, functions and properties that you can use in your scripts, including:

  • Global Functions
  • Application Functions and Properties
  • Form and Control Object Functions and Properties
  • Menu Functions
  • Mimic Functions and Properties
  • Alarm Banner Functions and Properties
  • User Messaging Functions.


Scripting Guide - Scripts - Port and Firewall Information (Welcome to the Scripting Guide)

Scripts - Port and Firewall Information

If a script causes changes in the database, any updates are reported to the server via SOAP using HTTP and Port 81 (by default - the Port address can be changed via the Server Configuration Tool see Server Port in the ClearSCADA Guide to Server Administration). For this reason, the ports and any firewalls need to be configured so that the client and server are able to communicate via the relevant port.

When a Mimic that contains a script is first displayed on a ViewX client, the client requests the server to provide information about which port to use. The Mimic then uses the port number specified by the server, so any subsequent changes to the port number will cause the script to stop working (as the Mimic cannot be updated via the new port number). A similar situation can occur with Alarm Banner scripts, except that they only request port information from the server when a user selects an Alarm Banner option that calls the Server or Object property of an alarm.

On WebX clients, Mimics use the same port that is used for the WebX connection. If the port (defined in the server configuration) is already in use by another application such as IIS when WebX is run, WebX will be unable to connect to the server. If WebX is able to connect to the server and a Mimic is displayed, the scripting will work as expected. However, if the port number is changed at the server while the Mimic is displayed in WebX, the scripting and navigation features of that Mimic will no longer work correctly (as the WebX server will have lost its connection to the server).

NOTE: Firewalls may block requests and stop scripts from functioning correctly. We recommend that you set up an exception for your firewall so that it allows your scripts to make requests and run as intended.


Scripting Guide - Mimic Scripts

Mimic Scripts

The ClearSCADA scripting feature for Mimics is designed to provide a more flexible medium for creating user interfaces such as animated Mimic displays. By using the Mimic scripting feature, you can create scripts that provide useful functionality that is specifically tailored to your requirements.

To create a Mimic script, you first need to enable the scripting feature for your Mimic as the feature is disabled by default (see Enable the Scripting Feature on a Mimic). Once the scripting feature is enabled, you can access the Script Editor and use it to create a suitable script. To create a script, you will need to have an in-depth understanding of the VBScript language.

In this section, we explain how to:

  • Enable the Scripting Feature on a Mimic
  • Display the Script Editor for a Mimic.

We also provide information about the ClearSCADA-specific functions and properties you can use when you Code a Mimic Script and describe how to use the script’s context sensitive menu (see Using a Script’s Context Sensitive Menu).

At the end of this section, we provide some examples of Mimic scripts:

  • Common Uses for Mimic Scripts

If your script is not producing the expected results or cannot run in ClearSCADA, please refer to:

  • Report a Script Failure - Disable CompressWebRequests.


Scripting Guide - Enable the Scripting Feature on a Mimic (Mimic Scripts)

Enable the Scripting Feature on a Mimic

The scripting feature is turned off on Mimics by default. If you want to use the scripting feature, you need to enable the scripting feature for the Mimic on which you are working.

To enable the scripting feature:

  1. In Design mode, double-click on the background of the Mimic to display the Mimic Properties window. Alternatively, you can right-click on the background of the Mimic and select the Properties option from the context sensitive menu.
  2. On the Mimic tab, select the Enabled check box in the Script section. This turns on the scripting feature for the Mimic.

NOTE: If you want to disable the scripting feature, clear the Enabled check box. This will disable scripting on the Mimic and also delete its scripts (if any are configured).

You can now access the script editor (see Display the Script Editor for a Mimic).


Scripting Guide - Display the Script Editor for a Mimic (Mimic Scripts)

Display the Script Editor for a Mimic

To create a script, you need to enter the script in the Script Editor.

You can display the Script Editor by:

  • Selecting the Edit button in the Script section on the Mimic tab of the Mimic Properties window (see Define the Script Settings for a Mimic in the ClearSCADA Guide to Mimics).

Or:

  • Right-clicking on a Mimic item and selecting the Edit Script option from the context sensitive menu.

Or:

  • Right-clicking on a Script Library item and selecting the Edit option from the context sensitive menu.

NOTE: The Edit Script option is only available if the selected Mimic item has scripting enabled (see Enable the Scripting Feature on a Mimic).

Once you have displayed the Script Editor, you can create your Mimic script by typing into the Script Editor.


Scripting Guide - Code a Mimic Script (Mimic Scripts)

Code a Mimic Script

When you have displayed the Script Editor for a Mimic, you can use it to code a new Mimic script or edit an existing Mimic script.

To code a Mimic script, you need to have an in-depth knowledge of VBScript. You also need an appreciation of the ClearSCADA-specific functions and properties that are available for use in your Mimic scripts.

ClearSCADA provides a range of functions and properties that you can use in your Mimic scripts. These ClearSCADA-specific functions and properties derive from ClearSCADA Script Objects, which include:

  • Application objects
  • Menu objects
  • Form objects (some of the Form functions and properties return another type of object called a ControlObject which also has its own functions and properties).
  • Mimic objects (these objects have functions and properties that are only available for use in Mimic scripts).
  • Server objects (some of the server functions and properties return another type of object called a ServerObject which also has its own functions and properties).

NOTE: There is also an Alarm Banner object, but it is only available for use with Alarm Banner Scripts.

Collectively, the categories of script objects are sometimes referred to as global objects.

So, in your Mimic scripts, you can use the following functions and properties:

  • Global Functions. These are functions that are available for each type of script object.
  • Application Functions and Properties
  • Menu Functions
  • Form and Control Object Functions and Properties
  • Mimic Functions and Properties
  • Server and ServerObject Functions and Properties.

When coding a script, you an use the script’s context sensitive menu to access useful features such as Cut, Copy, Paste, Find, Replace, Go To, various Breakpoint options for debugging, and also the Libraries option for referencing Script Libraries (see Using a Script’s Context Sensitive Menu).


Scripting Guide - Using a Script's Context Sensitive Menu (Mimic Scripts)

Using a Script’s Context Sensitive Menu

When you are editing your script, you can use the script context sensitive menu to access some useful features. To display the context sensitive menu, simply position the cursor on the background of the Script Editor display and then click the right-hand mouse button.

The context sensitive menu contains these useful options:

  • Cut—Use to remove selected code and store it in your PC’s clipboard area.
  • Copy—Use to copy the selected code and store the copy in your PC’s clipboard area.
  • Paste—Use to insert the contents of your PC’s clipboard area into the code at the selected insertion point.
  • Delete—Use to remove the selected code. The removed code is not stored in the clipboard area.
  • Select All—Use to select all of the code in the Script Editor display.
  • Find—Use to display a Find window. You can use the Find window to locate specified characters in the code. To do this, enter the characters you want to search for in the Find what field, and make a choice for the following settings:
  • Match Whole Word Only—Select this check box if you want ClearSCADA to only search for complete instances of the Find what entry. For example, if you enter A=1 in the Find what field and select the Match Whole Word Only check box, ClearSCADA will only find A=1 where A=1 appears as its own separate entity in the code. ClearSCADA will not find A=1 where A=1 is part of a longer string of characters, for example, ClearSCADA would not find the A=1 in ‘CDA=1’.

If you want ClearSCADA to find every instance of the Find what entry, irrespective of whether they appear as part of a longer entry, clear the Match Whole Word Only check box.

  • Match Case—Select this check box if you want ClearSCADA’s search for the Find what entry to be case sensitive; clear the check box if you want ClearSCADA to ignore the case.
  • Direction—Use to determine whether ClearSCADA searches from the top of the code to the bottom (Down) or from the bottom of the code to the top (Up).

When you have made your choices, select the Find Next button to locate the next instance of the Find what entry in the code. Continue to select the Find Next button to proceed to the next instance of the Find what entry as required.

  • Replace—Use to display a Replace window which you can use to find and replace characters in your code. The Replace window works in a similar way to the Find window, except that it has these additional settings:
  • Replace with—Enter the text that will be used in place of the Find what entry. When ClearSCADA locates an instance of the Find what entry in the code, you have the choice of replacing it with the entry in the Replace with field.
  • Replace In—Choose to replace only in a selected part of the code (Selection) or the whole code (Whole File). You can only choose Selection if you have highlighted a portion of the code.
  • Replace—Select this button to confirm that you want to replace the instance of the Find what term that ClearSCADA has located with the defined Replace with term.
  • Replace All—Select this button if you want ClearSCADA to replace every instance of the Find what term with the term defined in the Replace with field.

The Replace window does not have Direction settings.

  • Go To—Use to display the Go To Line window. You can use the Go To Line window to set ClearSCADA to move the cursor to a specific line in the code. To do this, simply enter the required line number in the Line Number field, then select the OK button.
  • Insert Breakpoint—Use to add a breakpoint to the code. This works in the same way as the Insert Breakpoint option that is available via the Debug menu (see Debug Menu).
  • Remove Breakpoint—Use to delete a breakpoint. This is only available if there is a breakpoint in the script. For more information, see Debug Menu.
  • Disable Breakpoint—Use to disable a breakpoint. The breakpoint remains in the script but is ignored. This option is only available if there is a breakpoint in the script (see Debug Menu).
  • Enable Breakpoint—Use to enable a breakpoint that is currently disabled. This option is only available if there is a disabled breakpoint in the script (see Debug Menu).
  • Libraries—Use to reference a script library (see Reference a Script Library in a Script).


Scripting Guide - Save a Mimic Script (Mimic Scripts)

Save a Mimic Script

Mimic scripts can be stored in Mimics or Script Libraries. When a Mimic script is saved, you can access a range of debugging facilities for checking the validity of your script.

To store a script in a Mimic, you have to:

  1. Enable the Scripting feature for the individual Mimic (see Enable the Scripting Feature on a Mimic)
  2. Create the script
  3. Save the script by performing one of the following:
  • Select File>Save
  • Select the Save toolbar button
  • Press the Ctrl and S keys simultaneously

You can use Script Libraries to store scripts that are available for use on many Mimics—the Mimic scripts can reference the Script Libraries so that you don't need to type in the same script repeatedly. For more information, see Script Libraries.


Scripting Guide - Run a Mimic Script (Mimic Scripts)

Run a Mimic Script

Normally, Mimic scripts are run when a script pick action has been selected. For example, a button on a Mimic can be configured to have a script pick action, so that when the button is selected, the Mimic’s script runs. The vast majority of script functions can only be run in this way. For more information on how to configure such a pick action, see Associate a Mimic Script with a Script Pick Action.

However, there are some exceptions—if you use the Mimic_Load or Mimic_Navigate functions, the script can run without being triggered by a pick action. For more information, see Set a Script to Run when a Mimic is First Displayed in Run Mode.

When a script has been triggered, it runs on the client PC and is head-specific i.e. when required to return head-specific information, the script will return values relating to the head on which they are running. For example, if a user name is to be returned, ClearSCADA will return the user name of the user who is logged on to the head on which the script is running.


Scripting Guide - Associate a Mimic Script with a Script Pick Action (Mimic Scripts)

Associate a Mimic Script with a Script Pick Action

When you have created a script, you can associate it with a pick action so that the script is run when a specific Mimic item is selected.

To associate a script with a pick action for a Mimic item:

  1. In Design mode, double-click on the Mimic item that will be selected to run the script.
    The Properties window is displayed (the type of Properties window varies according to the type of Mimic item).
  2. On the General tab, select the Pick Action button.
    The Pick Action Configuration Wizard runs.
  3. On the first 'page' of the Wizard, select the Script option then select the Next button.
  4. On the second 'page' of the Wizard, define the following settings:
  • Mode—Choose from:
  • Call Specific Function—When the pick action is selected, a specific function will be called. The function is selected in the Function combo box and is a function from a script.
  • Execute Code Fragment—When the pick action is selected, part of a script is executed.

Enter the section of script that is to be executed in the Code field. Typically, you would enter code to call a function declared in the script that has been created for the Mimic.

  • Execute Code Fragment on Top Level Mimic—Designed for use on embedded Mimics, the Execute Code Fragment on Top Level Mimic mode allows part of a script to be executed on the Mimic that contains the embedded Mimic. So when you select the embedded Mimic’s pick action, the script segment that you define will run on the top level Mimic (the Mimic that contains the embedded Mimic).

You have to define the section of script that is to be executed in the Code field. Typically, you would enter code to call a function declared on the top level Mimic.

  • Function—This combo box is only available when the Mode is set to Call Specific Function. Use the combo box to select the specific function that is to be called when the pick action is selected. If the function in your script or script library shares the same name as a function that is in another script or script library that is also being used by the Mimic, only one of the functions will be available. For this reason, take care when naming functions in your scripts and script libraries.
    If a Mimic is to use functions from its script and one or more script libraries, you should set the functions in the script and script libraries to have unique names (they need to be unique in the script and the script libraries used by the Mimic, but do not have to be unique on the system).
  • Code—This text entry field is only displayed if the Mode is set to Execute Code Fragment or Execute Code Fragment on Top Level Mimic. In the Code field, type or paste the fragment of code that is to be executed when the pick action is selected.
  • Permission—Use this combo box to select the security level for the pick action. The pick action will only be available to users that have the selected permission allocated to their User account. For more information on User accounts and permissions, see User Accounts in the ClearSCADA Guide to Security.
  5. Select the Next button.

If the selected function requires arguments, proceed to step 6. If the function does not require arguments, proceed to step 9.

  6. On the third 'page' of the Wizard, define the values for the arguments:

This 'page' lists the available arguments. The name of the argument is shown in the Name column, the required data type is shown in the Type column, and the expression for the argument is shown in the Value column.

  1. Right-click on the argument that you want to configure.
    A context sensitive menu is displayed.
  2. Select the required option:
  • Edit—Displays the Expressions window that you can use to configure an expression for the argument. Proceed to step iii.
  • <Pre-Defined Argument>—Depending on the type of function you have selected, there may be pre-defined argument options. These options correspond to the arguments that are defined in the Mimic's script.

If you select any of these options, the value for the argument will be set to match the corresponding value in the Mimic's script.

If you select a <Pre-Defined Argument> option, the selected argument is shown in the Value column. Proceed to step v.

  3. Use the Expressions window to create an expression that defines the argument value.
    For more information, see Using the Expression Editors in the ClearSCADA Guide to Expressions.
  4. Select the OK button to confirm the expression and close the Expression window.
  5. Repeat steps i-v for each argument as required. When you have defined the required arguments, proceed to step 7.

NOTE: To remove the expression for an argument, right-click on the argument in the list then select the Clear option.

  7. Select the Next button.

NOTE: If you are creating a script for a button, you will need to repeat steps 4-6 inclusive for when the button is up (not pressed down).

  8. Enter a Pick Action Comment as required. The pick action comment is displayed in the status bar when the cursor is positioned over the relevant Mimic item.
  9. Select the Next button.
  10. Select the Finish button to complete the pick action configuration.

When the Mimic is displayed in Run mode, selecting the Mimic item for which you configured the pick action will cause a script or part of a script to run.


Scripting Guide - Set a Script to Run when a Mimic is First Displayed in Run Mode (Mimic Scripts)

Set a Script to Run when a Mimic is First Displayed in Run Mode

You can use the Mimic_ Load function to set a script to run when the Mimic that contains the script is displayed in Run Mode. This means that the script will run when a User accesses the Mimic (the script does not have to be triggered by any other form of user interaction).

If you are using a script that requires parameters that are specified as part of a hyperlink, you have to use the Mimic_Navigate function instead of the Mimic_Load function. This is because the Mimic_Load function runs as soon as the Mimic opens i.e. before the parameters from the hyperlink have been read). The Mimic_Navigate function works in exactly the same way as the Mimic_Load function except that it runs at a later stage, and so it allows parameters to be read from hyperlinks.

To set a script to run automatically when a Mimic is first displayed in Run mode, simply include a Mimic_Load or Mimic_Navigate function in your script. The Mimic_Load function instructs the system to run the script when the Mimic is first displayed in Run Mode. The Mimic_Navigate function has a similar effect, but it allows hyperlink parameters to be used as it runs in a later stage of the Mimic opening sequence.

NOTE: Mimic_Load and Mimic_Navigate functions only run when the Mimic is displayed in Run Mode.

The syntax for using the Mimic_Load function is:

Sub Mimic_Load()
End Sub

A similar syntax is used for the Mimic_Navigate function:

Sub Mimic_Navigate( )
End Sub

The Mimic_Load and Mimic_Navigate functions have no parameters.


Scripting Guide - Common Uses for Mimic Scripts (Mimic Scripts)

Common Uses for Mimic Scripts

The following examples show how scripts can be used to provide common functionality requirements. By examining the scripts, you can see how various effects are achieved. You can use the same scripting principles to create your own scripts.

The examples include:

  • Using a Script to Display Dialog Boxes
  • Using a Script to Issue Two Controls from One Pick Action
  • Using a Script to Create a Form
  • Using a Script to Provide Navigation Features
  • Using a Script to Define and Display a ‘Custom’ Ad Hoc Trend
  • Using a Script to Access the Print Settings
  • Using a Script to Display a Log On/Log Off Window
  • Using a Script to Access the Change Password Window
  • Using a Script to Access Aggregates.


Scripting Guide - Using a Script to Display Dialog Boxes (Mimic Scripts)

Using a Script to Display Dialog Boxes

You can use scripts to display dialog boxes when a Mimic item is selected. When you create scripts that display dialog boxes, you may need to use the following:

  • vbOKOnly—Display OK button.
  • vbOKCancel—Display OK and Cancel buttons.
  • vbAbortRetryIgnore—Display Abort, Retry, and Ignore buttons.
  • vbYesNoCancel—Display Yes, No, and Cancel buttons.
  • vbYesNo—Display Yes and No buttons.
  • vbRetryCancel—Display Retry and Cancel buttons.
  • vbCritical—Display Critical Message icon.
  • vbQuestion—Display Warning Query icon.
  • vbExclamation—Display Warning Message icon.
  • vbInformation—Display Information Message icon.
  • vbDefaultButton1—First button is default.
  • vbDefaultButton2—Second button is default.
  • vbDefaultButton3—Third button is default.
  • vbDefaultButton4—Fourth button is default.
  • vbApplicationModal—Application modal. The user has to respond to the message box before continuing work in the current application.
  • vbSystemModal—System modal. Applications are suspended until the user responds to the message box.

The following example shows how a script can be used to display 2 warning dialog boxes (in sequence) when a Mimic item is selected. The Mimic item represents a water tank and selecting it results in the tank being emptied (after the 2 warning dialog boxes have been displayed). The script is named 'Warning' (as defined in the first line) and is as follows:

Public Function Warning(sMessage, sTankControl)
Dim iResponse
Dim oTankPoint
iResponse = MsgBox (sMessage, vbExclamation + vbOKCancel + vbDefaultButton1, "Warning")
If iResponse = vbOK Then
iResponse = MsgBox("Are you sure?", vbExclamation + vbYesNo + vbDefaultButton2, "Empty Tank?")
If iResponse = vbYes Then
Set oTankPoint = Server.FindObject(sTankControl)
If Not (oTankPoint Is Nothing) Then
oTankPoint.Interface.Override 1
Warning = 0
Else
MsgBox "Object not found"
Warning = 1
End If
Else
MsgBox "Action Canceled"
Warning = 1
End If
Else
Warning = 1
End If
End Function

The script begins with a Public Function that defines the Warning function and 2 string values (sMessage and sTankControl).

The script has 2 variables: iResponse and oTankPoint. The i is used to indicate that the variable is an integer and o is used to indicate that the variable is an object in the database. This is not required, but is regarded as good practice as it allows other users to determine the type of value required for each variable in the script.

The variables are defined as:

Dim iResponse
Dim oTankControl

When the script pick action for the water tank Mimic item is configured, it is associated with the Warning script and the following entry is entered for its value:

"This will empty the tank", "WaterTank.TankMonitorPoint"

When the water tank item is selected on the Mimic, a warning dialog box is displayed. The warning dialog box has a "This will empty the tank" message (defined as the first value in the entry on the Pick Action Wizard. The second entry ("WaterTank.TankMonitorPoint") defines the point on which the override method is performed later in the script.

The warning dialog box has the "This will empty the tank" message and two buttons—OK and Cancel. The warning dialog box and the buttons are defined by the following section of the script:

iResponse = MsgBox (sMessage, vbExclamation + vbOKCancel + vbDefaultButton1, "Warning")

The title of the dialog box is 'Warning'.

This is defined by:

If iResponse = vbOK Then
iResponse = MsgBox("Are you sure?", vbExclamation + vbYesNo + vbDefaultButton2, "Empty Tank?")

The second warning dialog box contains the message 'Are You Sure?' and has a Yes and No button. The button that is highlighted by default is the No button (button 2). The title of the warning dialog box is 'Empty Tank?'.

When the Yes button is selected, a method is performed. This is defined by:

If iResponse = vbYes Then
Set oTankPoint = Server.FindObject(sTankControl)
If Not (oTankPoint Is Nothing) Then
oTankPoint.Interface.Override 1
Warning = 0
Else
MsgBox "Object not found"
Warning = 1
End If

If the Yes button on the second warning dialog box is selected, the server locates the sTankControl object. The sTankControl object is defined as "WaterTank.TankMonitorPoint" on the Pick Action Wizard (the second value that is entered). If the server can find the point, it performs an override method with a value of 1 and the value of the Warning function is set to 0. The return value of the Warning function can be used by other scripts.

If the server cannot locate the sTankControl object, the script sets the value of the oTankPoint variable to null and a message box is displayed. The message box contains the message "Object not found". If the object cannot be found, the value of the Warning function is set to 1.

When the No button is selected on the second warning dialog box, another message dialog box is displayed. The message dialog box is an information dialog box and has the title and message 'Action Canceled'. If the action is canceled, the value of the Warning function is set to 1.

This is defined by the following section of the script:

Else
MsgBox "Action Canceled"
Warning = 1
End If

If the Cancel button is selected on the first warning dialog box, the dialog box is closed. This is defined by the last part of the script:

Else
Warning = 1
End If


Scripting Guide - Using a Script to Issue Two Controls from One Pick Action (Mimic Scripts)

Using a Script to Issue Two Controls from One Pick Action

You can use a script to allow a single pick action to issue two controls. This is useful when multiple responses are required to a specific occurrence.

In the following example, a script is used to allow a point override control and an acknowledge alarm control to be performed when a Mimic item is selected. When a user selects the Mimic item (in this case, a water tank), an alarm is acknowledged for a point named 'Water Control', and the same point is overridden to have its value set to 50. The script for the two controls is:

Public Function TankEmergency (sTankControl)
Dim oTankPoint
Set oTankPoint = Server.FindObject(sTankControl)
If Not (oTankPoint Is Nothing) Then
oTankPoint.Interface.AcceptWithComment "Alarm Acknowledged via Mimic"
oTankPoint.Interface.Override 50
Set oTankPoint = Nothing
End If
End Function

The start of the script defines the name of the script and its variables:

Public Function TankEmergency (sTankControl)
Dim oTankPoint

The script is named TankEmergency and it has a string value and one variable: sTankControl (the string value) and oTankPoint (the variable).

The script sets the oTankPoint variable to apply the control to the object that is defined by the sTankControl value. The sTankControl value is the database item that is specified on the Pick Action Wizard for the tank item on the Mimic. In this case, the sTankControl value is the 'Water Control' point.

When the tank item on the Mimic is selected, the Acknowledge With Comment control is applied to the 'Water Control' point. The alarm for the point is acknowledged, and the comment for the alarm is "Alarm Acknowledged via Mimic". This is defined by the following section:

oTankPoint.Interface.AcceptWithComment "Alarm Acknowledged via Mimic"

When the Acknowledge With Comment control has been performed, another control is performed—an Override is performed on the 'Water Control' point. The Override sets the value of the point to 50.

This is defined by the following line:

oTankPoint.Interface.Override 50

When the controls have been performed, the oTankPoint variable is set to nothing so that it is removed from memory. This is defined by the line:

Set oTankPoint = Nothing

The script has to be associated with a Script pick action for the water tank Mimic item. To do this, the Pick Action Wizard is displayed for the water tank item and the Script option is selected on the first 'page' of the Wizard. On the second 'page', the Mode is set to Call Specific Function (as the TankEmergency function is to run when the Mimic item is selected). The Function is set to TankEmergency and the Permission is set to Read (the pick action will be available to users with the Read permission, which is usually every user on the system).

On the third 'page' of the Wizard, the sTankControl argument values are edited. On the Expression window for the argument, the name of the database item that is represented by the sTankControl variable is defined. In this case, the argument is defined as:

".Water Control.FullName"

as the 'Water Control' point is located in the root of the system (as is the Mimic that contains the water tank item). The FullName property of the 'Water Control' point is returned. By using an OPC Tag rather than a constant reference, the pick action will still apply to the 'Water Control' point if the name of the point changes (the pick action is set to use the FullName property of the point).

NOTE: When referencing a database item for a script pick action, you can use a constant reference which requires single quotations (as shown in the example) or you can refer to an OPC tag which uses double quotations " ").

A pick action comment is set on the next 'page' of the Wizard, and then the pick action configuration is completed when the Finished button is selected on the final 'page'.

When the Mimic is displayed in Run mode, selecting the water tank item causes the script to run. This acknowledges an alarm for the 'Water Control' point (if there is an alarm) and sets the alarm comment for the acknowledge control to be 'Alarm Acknowledged via Mimic'. The script also causes the 'Water Control' point to be overridden with a value of 50.


Scripting Guide - Using a Script to Create a Form (Mimic Scripts)

Using a Script to Create a Form

A common requirement for scripts is to create a Form that is displayed when a Mimic item is selected.

In this section, we will describe the script that creates the following Form:

The Form contains a Yes/No combo box, a text entry field, and OK and Cancel buttons. The text entry field is for a password, so the entry has to match the specified password. This type of Form could be used to shutdown equipment etc.

By examining the script that is used to create the Verify Control Action Form, you can learn how to add fields, buttons, and combo boxes to Forms. The script for the Form is:

Option Explicit
Public Function VerifyControl(Point)
Dim frmComboBox
Dim frmEditBox
Dim frmOKButton
Dim frmCancelButton
Dim sMasterPassword
Dim iReturnValue
Dim oClearSCADAPoint
sMasterPassword = "abc"
Form.Init "Verify Control Action"
Form.AddGroupBox 0,0,100,8,""
Form.AddStaticText 2,1, "Are you sure you wish to execute this control?"
Form.AddStaticText 2,3, "Enter master password"
Set frmComboBox = Form.AddComboBox(60,1)
frmComboBox.Add("Yes")
frmComboBox.Add("No")
frmComboBox.Selection = 1 '0 is first element, 1 is second, etc.
Set frmEditBox = Form.AddEditBox(60,3)
frmEditBox.Password = True
frmEditBox.MaxLength = 10
frmEditBox.Value = ""
Set frmOKButton = Form.AddPushButton(60,5,"OK")
frmOKButton.Default = True
Set frmCancelButton = Form.AddPushButton(75,5,"Cancel")
Form.Show
If Form.Selection = "OK" Then
If frmComboBox.Selection <> 0 Then
iReturnValue = MsgBox("You must select ""Yes"" from the pulldown menu for this action to be executed", vbOKOnly+vbExclamation, "Action not executed")
ElseIf frmEditBox.Value <> sMasterPassword Then
iReturnValue = MsgBox("Incorrect password specified", vbOKOnly+vbExclamation, "Action not executed")
Else
Set oClearSCADAPoint = Server.FindObject(Point)
If oClearSCADAPoint Is Nothing Then
iReturnValue = MsgBox("Unable to find the object", vbOKOnly+vbExclamation, "Action not executed")
Else
oClearSCADAPoint.Interface.Override oClearSCADAPoint.Interface.CurrentValue+5
iReturnValue = MsgBox("Action successfully performed",vbOKOnly+vbInformation, "Action performed successfully ")
End If
End If
ElseIf Form.Selection = "" Then'This is when they click Esc or the X, allows them to get some feedback.
'We don't give feedback when they click Cancel
iReturnValue = MsgBox("Action canceled", vbOKOnly+vbInformation, "Action not executed")
End If

End Function

We will now explain each section of the script so that you can understand how the script provides the various features of the Form. You can then use the same scripting principles to create your own Forms.

The script begins with Option Explicit which means the script has to define each function before it uses the functions. The name of the script function is defined as VerifyControl and (Point) defines the variable that represents the FullName value that is entered on the Pick Action Wizard (to define which database item is to be controlled).

Option Explicit

Public Function VerifyControl(Point)

The variables that are used by the script are defined next to Dim entries. The frm is used as the prefix for Form variables, s is the prefix for the string variable, i is the prefix for an integer variable, and o is the prefix for a database item definition. These prefixes are not compulsory, but they are useful as they allow engineers to determine the type of each variable without having to investigate.

Dim frmComboBox
Dim frmEditBox
Dim frmOKButton
Dim frmCancelButton
Dim sMasterPassword
Dim iReturnValue
Dim oClearSCADAPoint

The sMasterPassword = "abc" line defines the sMasterPassword variable as being "abc". This means that the user has to enter abc as the password.

sMasterPassword = "abc"

The settings that define the appearance of the Verify Control Action Form are defined by the following lines:

Form.Init "Verify Control Action"
Form.AddGroupBox 0,0,100,8,""
Form.AddStaticText 2,1, "Are you sure you wish to execute this control?"
Form.AddStaticText 2,3, "Enter master password"
Set frmComboBox = Form.AddComboBox(60,1)
frmComboBox.Add("Yes")
frmComboBox.Add("No")
frmComboBox.Selection = 1 '0 is first element, 1 is second, etc.

The Form.Init "Verify Control Action" sets the title of the Form. The Form.AddGroupBox 0,0,100,8, "" line defines the appearance and position of the section border that is shown within the Form. The co-ordinates start at the top-left corner and end at the bottom right-hand corner.

The Form.AddStaticText entries define the position and text for the text labels that appear on the Form.

Set frmComboBox = Form.AddComboBox(60,1)
frmComboBox.Add("Yes")
frmComboBox.Add("No")
frmComboBox.Selection = 1 '0 is first element, 1 is second, etc.

The Set frmComboBox = Form.AddComboBox (60,1) line defines the location of a combo box on the Form.

The frmComboBox.Add lines define the options that are available in the combo box.

The frmComboBox.Selection = 1 '0 is first element, 1 is second, etc. line sets the numbers for the combo box options. 0 is the first option, 1 is the second option. The text after the ' is commented out.

The following script is used to define the settings for the password field:

Set frmEditBox = Form.AddEditBox(60,3)
frmEditBox.Password = True
frmEditBox.MaxLength = 10
frmEditBox.Value = ""

The Form.AddEditBox (60,3) section defines that the field is a text entry field (edit box) and has the co-ordinates 60, 3. (The co-ordinates define the field's position on the box).

The frmEditBox.Password = True line sets the password field to hide the text entry and replace the characters with asterisks. This means that the password cannot be seen by other users when an engineer types in the password.

The frmEditBox.MaxLength = 10 line sets the password length to 10 characters.

The frmEditBox.Value = "" line sets the password field to be empty by default.

The following script is used to define the OK and Cancel buttons:

Set frmOKButton = Form.AddPushButton(60,5,"OK")
frmOKButton.Default = True

Set frmCancelButton = Form.AddPushButton(75,5,"Cancel")

The OK button is set to be highlighted by default (= True), so that if the user presses the Enter key, the OK button is selected.

If the user selects the OK button on the Form, ClearSCADA checks to see if the Yes option has been selected in the combo box. If it has not been selected, a dialog box is displayed. The message box displays the message 'You must select "Yes" from the pulldown menu for this action to be executed'. The title of the dialog box is "Action not executed". This is defined by the following section of the script:

Form.Show
If Form.Selection = "OK" Then
If frmComboBox.Selection <> 0 Then

iReturnValue = MsgBox("You must select ""Yes"" from the pulldown menu for this action to be executed", vbOKOnly+vbExclamation, "Action not executed")

If the user selects the OK button on the Form and the Yes option has been selected, ClearSCADA checks to see if the correct password has also been entered.

If the incorrect password has been entered, a dialog box is displayed containing the message "Incorrect password specified". The title of the dialog box is "Action not executed".

This is defined by the following section of the script:

ElseIf frmEditBox.Value <> sMasterPassword Then
iReturnValue = MsgBox("Incorrect password specified", vbOKOnly+vbExclamation, "Action not executed")

If the correct password is entered, but ClearSCADA cannot locate the database item, a dialog box is displayed. The dialog box contains the message "Unable to find the object". The title of the dialog box is "Action not executed".

This is defined by the following section of the script:

Else
Set oClearSCADAPoint = Server.FindObject(Point)
If oClearSCADAPoint Is Nothing Then
iReturnValue = MsgBox("Unable to find the object", vbOKOnly+vbExclamation, "Action not executed")

If the correct password has been entered, ClearSCADA attempts to locate the database item that is represented by the Point variable. The point that this variable represents is selected on the Pick Action Wizard when the script is set up as the Mimic item's pick action. The Pick Action Wizard has to be set to reference a FullName property of an object or another property that contains the fullname of the object. In this case, we will assume that the Pick Action Wizard is set to reference the FullName property of the point.

If the database item can be found, an Override method is performed and sets the value to 5. When the override has taken place, a dialog box is displayed containing the message "Action performed successfully".

This is defined by the following section of the script:

Else
oClearSCADAPoint.Interface.Override oClearSCADAPoint.Interface.CurrentValue+5
iReturnValue = MsgBox("Action successfully performed",vbOKOnly+vbInformation, "Action performed successfully ")

End If

If the user selects the Close window button (at the top corner of the Form) or presses the Esc key, the action is canceled. A dialog box is displayed containing the message "Action canceled", and it has the title "Action not executed". There is no dialog box message if the user selects the Cancel button.

This is defined by the following section of the script:

ElseIf Form.Selection = "" Then'This is when they click Esc or the X, allows them to get some feedback.
'We don't give feedback when they click Cancel
iReturnValue = MsgBox("Action canceled", vbOKOnly+vbInformation, "Action not executed")

End If


Scripting Guide - Using a Script to Provide Navigation Features (Mimic Scripts)

Using a Script to Provide Navigation Features

You can use scripts to provide the following navigation features:

  • Close the Mimic Display
  • Go to Next Mimic in Sequence
  • Go to Previous Mimic in Sequence
  • Show Another Display in an Inset Window
  • Show Another Display in a Full-Size Window
  • Hyperlink to Another Display.

Close the Mimic Display

You can use a script to close a Mimic display—when a user selects the relevant Mimic item, the Mimic display is closed.

NOTE: If the Mimic item is selected on a WebX client, the script will close the web browser application.

The script for closing a Mimic display is Mimic.Close, for example:

Public Function CloseMimic
Mimic.Close

End Function

Go to Next Mimic in Sequence

You can use a script to cause the Mimic display to show the next Mimic in a sequence ('chained' Mimics). When a user selects the relevant Mimic item, the next Mimic in the sequence is displayed in place of the current Mimic.

The script for displaying the next Mimic in a sequence is Mimic.GoForward, for example:

Mimic.GoForward

GoForward provides the same functionality as the Forward button on the Navigate toolbar.

NOTE: The script has no effect if the current Mimic is not part of a 'chain' of Mimics. The next Mimic can only be shown if there is a sequence (the sequence is created when hyperlinks to other Mimics are selected on a Mimic).

Example:

A Mimic named 'Pump 1' is on display. It contains a hyperlink to another Mimic called 'Pump 2' and a button named 'Next'. The 'Next' button is configured to have a script pick action that is associated with a 'NextMimic' function. The script for the 'NextMimic' function includes:

Mimic.GoForward

On the 'Pump 1' Mimic, an operator selects the hyperlink and the 'Pump 2' Mimic is shown in place of the 'Pump 1' Mimic.

The 'Pump 2' Mimic contains a button that, when selected, causes the previous Mimic in a sequence to be displayed. This button is associated with a script that includes:

Public Function PrevMimic
Mimic.GoBack

End Function

When the button on the 'Pump 2' Mimic is selected, the script is run and the GoBack function is performed. This causes the Mimic display to navigate back to the previous Mimic in the 'chain'—the 'Pump 1' Mimic.

The operator selects the 'Next' button on the 'Pump 1' Mimic. The script is run and the next Mimic in the sequence is displayed—the 'Pump 2' Mimic is shown again.

Go to Previous Mimic in Sequence

You can use a script to cause the Mimic display to show the previous Mimic in a sequence ('chained' Mimics). When a user selects the relevant Mimic item, the previous Mimic in the sequence is displayed in place of the current Mimic.

The script for displaying the previous Mimic in a sequence is:

Mimic.GoBack

GoBack provides the same functionality as the Backward button on the Navigate toolbar.

NOTE: The script has no effect if the current Mimic is not part of a 'chain' of Mimics. The previous Mimic can only be shown if there is a sequence (the sequence is created when hyperlinks to other Mimics are selected on a Mimic).

Example:

A Mimic named 'Pump 1' is on display. It contains a hyperlink to another Mimic called 'Pump 2'. The user selects the hyperlink and the 'Pump 2' Mimic is shown in place of the 'Pump 1' Mimic.

The 'Pump 2' Mimic contains a button that, when selected, causes the previous Mimic in a sequence to be displayed. This button is associated with a script that includes:

Public Function PrevMimic
Mimic.GoBack

End Function

When the button on the 'Pump 2' Mimic is selected, the script is run and the GoBack function is performed. This causes the Mimic display to navigate back to the previous Mimic in the 'chain'—the 'Pump 1' Mimic.

A hyperlink to the 'Pump 2' Mimic is selected. This causes the 'Pump 2' Mimic to be displayed.
An operator selects the 'Previous' button on the 'Pump 2' Mimic. This button is associated with the GoBack function in the script (via a script pick action), so that when it is selected, the GoBack function is performed and the Mimic display shows the previous Mimic (the 'Pump 1' Mimic is displayed again).

Show Another Display in an Inset Window

You can use a script to set a pick action to show another display in an inset window, for example, you can create a script that causes a web page to be displayed in an inset window. The web page is displayed when a Mimic item is selected.

The script for an inset window is Mimic.OpenInset, for example:

Public Function GoWebPage
Mimic.OpenInset "http://www.schneider-electric.com", "0","0","200","400"
End Function

OpenInset has to be followed by the address of the display, the X and Y co-ordinates of the display, and then the Width and Height settings. The address can be a URL or
a ClearSCADA display. The address for ClearSCADA displays has to use the format:

SCX:///LOCAL/<Database Class>/<path>

An easy way to find the address for a ClearSCADA display is to access the display, then add it to your favorites. If you display the Favorites bar, you can right-click on the display link and select the Properties option to display the Properties window. You can then copy the address from the Properties window and paste it into your script.

If there are double-quotes in the address or URL, you need to enter additional double-quotes around them in the script. For example, if the address is for an Alarms List with filtering, the address could be:

Mimic.OpenInset "SCX:///LOCAL/AlarmList/Area = "Filter1"

In the script, this would need to be defined as:

Mimic.OpenInset "SCX:///LOCAL/AlarmList/Area = ""Filter1"""

Show Another Display in a Full-Size Window

You can use a script to set a pick action to show another display in a full-size window (as opposed to an inset window). For example, you can create a script that causes a web page to be displayed. The web page is displayed when a Mimic item is selected.

The script for a new window is App.OpenWindow, for example:

Public Function GoWebPage
App.OpenWindow "http://www.schneider-electric.com"

End Function

OpenWindow has to be followed by the address of the display. The address can be a URL or a ClearSCADA display. The address for ClearSCADA displays has to use the format:

SCX:///LOCAL/<Database Class>/<path>

An easy way to find the address for a ClearSCADA display is to access the display, then add it to your favorites. If you display the Favorites bar, you can right-click on the display link and select the Properties option to display the Properties window. You can then copy the address from the Properties window and paste it into your script.

If there are double-quotes in the address or URL, you need to enter additional double-quotes around them in the script. For example, if the address is for an Alarms List with filtering, the address could be:

Mimic.OpenWindow "SCX:///LOCAL/AlarmList/Area = "Filter1"

In the script, this would need to be defined as:

Mimic.OpenWindow "SCX:///LOCAL/AlarmList/Area = ""Filter1"""

Hyperlink to Another Display

You can use a script to set a pick action to hyperlink to another display.

The script for a hyperlink is Mimic.Navigate, for example:

Public Function TargetMimic
Mimic.Navigate "SCX:///LOCAL/CMimic/MainGroup.Pipeline"

End Function

This example script provides a link to a Mimic named 'Pipeline'. The 'Pipeline' Mimic is located in a Group named 'MainGroup'. The format of the Mimic's address has to be:

SCX:///LOCAL/<Database Class>/<path>

An easy way to find the address for a ClearSCADA display is to access the display, then add it to your favorites. If you display the Favorites bar, you can right-click on the display link and select the Properties option to display the Properties window. You can then copy the address from the Properties window and paste it into your script.

If there are double-quotes in the address or URL, you need to enter additional double-quotes around them in the script. For example, if the address is for an Alarms List with filtering, the address could be:

Mimic.Navigate "SCX:///LOCAL/AlarmList/Area = "Filter1"

In the script, this would need to be defined as:

Mimic.Navigate "SCX:///LOCAL/AlarmList/Area = ""Filter1"""


Scripting Guide - Using a Script to Define and Display a 'Custom' Ad Hoc Trend (Mimic Scripts)

Using a Script to Define and Display a ‘Custom’ Ad Hoc Trend

ClearSCADA supports several types of Trend (see Pre-Configured Trends, File Based Trends and Ad Hoc Trends in the ClearSCADA Guide to Trends). Many types of Trend are configured using a series of windows in ViewX. However, ‘custom’ ad hoc Trends are configured using TrendSpec, ClearSCADA’s proprietary specification language.

To allow users to display a ‘custom’ ad hoc Trend, you need to add a Hyperlink or Script pick action to the relevant Mimic (see Creating a Hyperlink to a Trend or X-Y Plot in the ClearSCADA Guide to Mimics). To define the Trend’s properties, you need to incorporate the TrendSpec definition into the Trend’s hyperlink URL or script subroutine.

Refer to the relevant sections in this ClearSCADA Guide to Scripting for information on coding Mimic scripts.

For information on defining a ‘custom’ ad hoc Trend’s properties using TrendSpec, see Using TrendSpec to Produce Ad Hoc Trends in the ClearSCADA Guide to Trends.

For a series of worked examples, including several that demonstrate how TrendSpec definitions might be incorporated into Mimic scripts, see Example Configuration in the ClearSCADA Guide to Trends.


Scripting Guide - Using a Script to Access the Print Settings (Mimic Scripts)

Using a Script to Access the Print Settings

You can use a script to display the print settings for a Mimic. When a user selects the relevant Mimic item, the Windows Print window is displayed. They can use the Print window to define the print settings and initiate a print-out of the Mimic.

Print Stats item has a script pick action that is associated with a PrintMimic script.
When the Print Stats item is selected, the script runs and causes the Print window to be displayed.

The script for accessing the print settings is Mimic.Print, for example:

Public Function PrintMimic
Mimic.Print
End Function


Scripting Guide - Using a Script to Display a Log On/Log Off Window (Mimic Scripts)

Using a Script to Display a Log On/Log Off Window

You can use a script to access the Log On or Log Off window.

The script to display the Log On or Log Off window is App.LogOn or App.LogOff, for example:

Public Function LogOnSys
App.LogOn

End Function

Or:

Public Function LogOffSys
App.LogOff

End Function


Scripting Guide - Using a Script to Access the Change Password Window (Mimic Scripts)

Using a Script to Access the Change Password Window

You can use a script to access the Change Password window for a User account. When the relevant Mimic item is selected, the Change Password window for the logged on user is displayed.

The script to display the Change Password window is App.ChangePassword, for example:

Public Function ChangeUserPassword
App.ChangePassword

End Function

NOTE: The Change Password window is only displayed if a user is logged on.


Scripting Guide - Using a Script to Access Aggregates (Mimic Scripts)

Using a Script to Access Aggregates

You can use a script to access the aggregates (and aggregate properties) of database items. This is especially useful for setting historic features and changing certain configuration settings via a script.

The following example consists of can be used to locate a channel and change its connection type to serial by accessing the ConnectionType aggregate. For this example, a Modbus channel is used (this would require the Modbus driver to be installed on a 'real' system).

Sub SetConnTypeSerial()
Set modbusChan = Server.FindObject(Server.ThisObject.Parent.FullName & ".Modbus Channel 1")
modbusChan.Interface.ConnectionPoint = 0
comPort = InputBox("Please enter a valid COM Port:")
modbusChan.Interface.ConnectionPoint.Port = comPort

End Sub

Where:

  • Set modbusChan = Server.FindObject(Server.ThisObject.Parent.FullName & "Modbus Channel 1") is used to search for the database item named 'Modbus Channel 1'. The script is set to search in the same Group as the Mimic that contains the script (it searches in the Parent Group of the current object which is the Mimic that contains the script). The ServerObject that is returned by the FindObject function is stored in the variable named 'modbusChan'.
  • modbusChan.Interface.ConnectionPoint = 0 is used to access the ConnectionPoint aggregate of the 'Modbus Channel 1' database item (the 'Modbus Channel 1' database item is a channel and is represented by the ServerObject that is stored in the modbusChan variable.
  • comPort = InputBox("Please enter a valid COM Port:") is used to display a prompt window. The prompt window requests that the user enters a valid COM port. The entry that is made by the user is stored in the comPort variable.
  • modbusChan.Interface.ConnectionPoint.Port = comPort sets the Port parameter for the ConnectionPoint aggregate of the 'Modbus Channel 1' item. The Port parameter is set to be the same as the user entry that is stored in the comPort variable.


Scripting Guide - Alarm Banner Scripts

Alarm Banner Scripts

The ClearSCADA scripting feature for the Alarm Banner allows you to create scripts that provide additional functionality via the Alarm Banner. Using VBScript, you can access the Alarm Banner Functions and Properties to:

  • Add menu options to the context sensitive menu (that is displayed whenever you select an alarm in the Alarm Banner).
  • Set the added menu options to run a script
  • Create scripts that extract information from the Alarm Banner. The information can then be used within ClearSCADA or sent to external applications such as work management systems.
  • Create scripts that provide extra functionality for interaction with the alarms and the database items associated with the alarms. For example, you can create an Alarm Banner script that calls a method on a database item that is associated with a selected alarm.

To write the code for an Alarm Banner script, you will need an in-depth understanding of the VBScript language and an appreciation of the Alarm Banner functions and properties. You can write the code in the Script Editor for the Alarm Banner.

In this section, we explain how to:

  • Display the Script Editor for the Alarm Banner
  • Code an Alarm Banner Script. When you code an Alarm Banner script, you can use the script’s context sensitive menu to access useful features in the same way as when coding a Mimic script (see Using a Script’s Context Sensitive Menu).
  • Save an Alarm Banner Script
  • Run an Alarm Banner Script

We also provide some examples of how Alarm Banner scripts can be used:

  • Common Uses for Alarm Banner Scripts.


Scripting Guide - Display the Script Editor for the Alarm Banner (Alarm Banner Scripts)

Display the Script Editor for the Alarm Banner

When creating an Alarm Banner script, you need to write the required code in the Script Editor for the Alarm Banner. To display the Script Editor:

  1. Log on to ViewX as a User that has the Configure permission for the system on which you want to create the script (the 'Root' system).
  2. In the Database Bar, right-click on the server item (the system) to display its context sensitive menu.
  3. Select the Edit Global Script option to display the Script Editor.
    Alarm Banner Script Editor showing an Alarm Banner script.

Once the Script Editor is displayed, you can type in the code for your new script or amend the code of any existing script as required.

Further Information

Alarm Banner Functions and Properties

Save an Alarm Banner Script

Run an Alarm Banner Script

Common Uses for Alarm Banner Scripts.


Scripting Guide - Code an Alarm Banner Script (Alarm Banner Scripts)

Code an Alarm Banner Script

When you have displayed the Script Editor for the Alarm Banner, you can use it to code a new Alarm Banner script or edit an existing Alarm Banner script.

To code an Alarm Banner script, you need to have an in-depth knowledge of VBScript. You also need an appreciation of the ClearSCADA-specific functions and properties that are available for use in your Alarm Banner scripts.

ClearSCADA provides a range of functions and properties that you can use in your Alarm Banner scripts. These ClearSCADA-specific functions and properties derive from ClearSCADA Script Objects, which include:

  • Application objects
  • Menu objects
  • Form objects (some of the Form functions and properties return another type of object called a ControlObject which also has its own functions and properties).
  • Alarm Banner objects (these objects have functions and properties that are only available for use in Alarm Banner scripts).
  • Server objects (some of the server functions and properties return another type of object called a ServerObject which also has its own functions and properties). With Alarm Banner scripts, you can only use Server and ServerObject functions and properties if you have used the Server property of an alarm in an alarm collection. (The alarms in an alarm collection have a Server property that returns a ServerObject).

NOTE: There is also a Mimic object, but it is only available for use with Mimic Scripts.

Collectively, the categories of script objects are sometimes referred to as global objects.

So, in your Alarm Banner scripts, you can use the following functions and properties:

  • Global Functions. These are functions that are available for each type of script object.
  • Application Functions and Properties
  • Menu Functions
  • Form and Control Object Functions and Properties
  • Alarm Banner Functions and Properties
  • Server and ServerObject Functions and Properties. These functions and properties are only available if you have used the Server property of an alarm in an alarm collection (the alarm collection is returned by the Alarms or SelectedAlarms properties of the AlarmBanner object, and each alarm in the collection has a Server property which returns a ServerObject).


Scripting Guide - Save an Alarm Banner Script (Alarm Banner Scripts)

Save an Alarm Banner Script

Alarm Banner scripts can be stored in the database, either as part of the Alarm Banner or in Script Libraries. To store a script in the database as part of the Alarm Banner, you have to display the Script Editor for the Alarm Banner:

  • Select File>Save
  • Select the Save toolbar button
  • Press the Ctrl and S keys simultaneously

You can use Script Libraries to store scripts that are available for use in your Alarm Banner script—the Alarm Banner script can reference the Script Libraries so that you don't need to type in the same script repeatedly. For more information, see Script Libraries.


Scripting Guide - Run an Alarm Banner Script (Alarm Banner Scripts)

Run an Alarm Banner Script

An Alarm Banner script only runs as a result of the associated Alarm Banner context menu option being selected. For example, if you create a script that adds a 'Send Alarm Data’ option to the Alarm Banner’s context sensitive menu, the Alarm Banner script will only run when that option is selected. If your script adds multiple options to the Alarm Banner, you have to also define what happens when each option is selected in your script.

When you select an alarm in the Alarm Banner, a context sensitive menu is displayed. If you have created an Alarm Banner script, the BuildAlarmMenu function is called. Any additional menu items that are defined in your script after the BuildAlarmMenu function are automatically added to the context sensitive menu.

BuildAlarmMenu function is called when you select an alarm, and any extra options are added to the Alarm Banner’s context sensitive menu.

When you select one of the additional Alarm Banner options that you have created in your script, the script runs and the resulting action that you have coded occurs.

Further Information

Common Uses for Alarm Banner Scripts.


Scripting Guide - Common Uses for Alarm Banner Scripts (Alarm Banner Scripts)

Common Uses for Alarm Banner Scripts

In this section, we provide examples of common uses for Alarm Banner scripts:

  • Example 1: Extracting Alarm Information from the Alarm Banner
  • Example 2: Extracting Alarm Information and User Entered Content.


Scripting Guide - Example 1: Extracting Alarm Information from the Alarm Banner (Alarm Banner Scripts)

Example 1: Extracting Alarm Information from the Alarm Banner

The purpose of this example is to show you how to create a script that extracts information from the Alarm Banner and then use it elsewhere. In the example, the alarm information is extracted and used in a message box. Typically, on a 'live' system, the Alarm Banner script is used to extract alarm information from the Alarm Banner, and this information is then sent to a Third Party work management system.

In the following example code, the Alarm Banner script is to add a new menu item to the Alarm Banner’s context sensitive menu. The option will be called 'Medium Alarm Selected', 'One Alarm Selected, n Total', or 'More Than One Alarm Selected' depending on whether the user has selected one medium priority alarm, one non-medium priority alarm, or multiple alarms. When the new menu item is selected, a message box is displayed containing information about the selected alarm(s).

Function MsgBox( Title, Msg )
Form.Init Title
Form.AddStaticText 0, 0, Msg
Form.AddPushButton 4, 4, "OK"
Form.Show
End Function
Function BuildAlarmMenu
If AlarmBanner.SelectedAlarms.Count = 1 Then
If AlarmBanner.SelectedAlarms(0).SeverityDesc = "Medium" Then
AlarmBanner.AddMenuItem "Medium Alarm Selected", "DoOneItemSelection"
Else
AlarmBanner.AddMenuItem "One Item Selected, " & AlarmBanner.Alarms.Count & " total", "DoOneItemSelection"
End if
Elseif AlarmBanner.SelectedAlarms.Count > 1 Then
AlarmBanner.AddMenuItem "More Than One Alarm Selected", "DoMultiAlarmSelection"
End If
End Function
Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Severity " & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname
End Function
Function DoOneItemSelection
ShowAlarmInfo AlarmBanner.SelectedAlarms(0)
End Function
Function DoMultiAlarmSelection
for each A in AlarmBanner.SelectedAlarms
ShowAlarmInfo A
Next
End Function

The first function in the script is the MsgBox function which defines the appearance of the message box that is to be displayed when one of the new menu options is selected.

Next comes the BuildAlarmMenu function which has to contain the Alarm Banner functions and properties that are used to add and define the new Alarm Banner options. Within the BuildAlarmMenu function, the SelectedAlarms.Count, SelectedAlarms.SeverityDesc, AddMenuItem and Alarms.Count functions and properties define that:

  • If a single alarm is selected in the Alarm Banner and the alarm has Medium severity, the new menu option is shown as 'Medium Alarm Selected' and when selected, calls the 'DoOneAlarmSelection' function (which is defined later in the script)
  • If a single alarm is selected in the Alarm Banner and the alarm does not have Medium severity, the new menu option is shown as 'One Alarm Selected, n Total' and when selected, calls the 'DoOneAlarmSelection' function (which is defined later in the script).
  • If multiple alarms are selected in the Alarm Banner, the new option is shown as 'More Than One Alarm Selected', and when selected, calls the 'DoMultiAlarmSelection' function (again, defined later in the script).

This is followed by the definition of the ShowAlarmInfo (Alarm) function which is called by both the 'DoMultiAlarmSelection' and 'DoOneAlarmSelection' functions. The definition instructs ClearSCADA about the categories of alarm information to display in the message box.

Next is the definition of the 'DoOneAlarmSelection' function which calls the ShowAlarmInfo function for the first selected alarm.

Finally, the script has the definition for the 'DoMultiAlarmSelection' function which instructs the script to call the 'ShowAlarmInfo' function for each alarm in the collection of alarms (returned by the SelectedAlarms property).

See Also:

AlarmBanner.AddMenuItem.

AlarmBanner.AddMenuSeparator.

Example 2: Extracting Alarm Information and User Entered Content.


Scripting Guide - Example 2: Extracting Alarm Information and User Entered Content (Alarm Banner Scripts)

Example 2: Extracting Alarm Information and User Entered Content

In this example, the script is used to add a menu option to the alarm banner, that when selected, extracts alarm information from the Alarm Banner and displays it on a Form. The Form also contains a field which requires the user to enter information. When the user has entered the requested information and selected the OK button, a confirmation window is displayed. If the user selects the Yes button on the confirmation window, the extracted Alarm Banner information and the details entered by the user are displayed in a message box.

On a real system, instead of displaying the alarm information and user input on a message box, it is more likely that you would create a script to send the extracted information to another application. For example, you could send the alarm information and user-defined input to a work management program. The method and scripting required to send the information to Third Party programs varies for each application—for more information, please refer to the documentation supplied with your Third Party application.

Public Sub BuildAlarmMenu
If AlarmBanner.SelectedAlarms.Count > 0 Then
AlarmBanner.AddMenuItem "Acknowledge Related Alarms", "AcknowledgeRelated"
End If
End Sub
Public Sub AcknowledgeRelated
If AlarmBanner.SelectedAlarms.Count > 0 Then
Form.Init "Process Alarms"
Form.AddStaticText 1, 1, "Alarms Selected:"
Count = 0
For Each objAlarm In AlarmBanner.SelectedAlarms
Form.AddStaticText 1, 3 + Count, objAlarm.Source & ", " & objAlarm.Message
Count=Count + 1
Next
Form.AddStaticText 1, 4 + Count, "Further Information:"
Set frmEdit = Form.AddEditBox(25, 4 + Count, 50, 1)
Set frmOk = Form.AddPushButton(45, 7 + Count, "OK")
Set frmCancel = Form.AddPushButton(60, 7 + Count, "Cancel")
frmOk.Default = True
Form.Show
If Form.Selection = "OK" Then
lResult = MsgBox("Process the alarms with information '" & frmEdit & "'?", vbYesNo + vbDefaultButton2 + vbQuestion, "Confirm Action")
If lResult = vbYes Then
Form.Init "Result"
Form.AddStaticText 1, 1, "Alarms Selected:"
Count = 0
For Each objAlarm In AlarmBanner.SelectedAlarms
Form.AddStaticText 1, 3 + Count, objAlarm.Source & ", " & objAlarm.Message
Count = Count + 1
Next
Form.AddStaticText 25, 4 + Count, frmEdit
Set frmOk = Form.AddPushButton(45, 7 + Count, "OK")
Set frmCancel = Form.AddPushButton(60, 7 + Count, "Cancel")
frmOk.Default = True
Form.Show
End If
End If
End If
End Sub

This script adds an Acknowledge Related Alarms option to the Alarm Banner.

When a user selects the Acknowledge Related Alarms option, a Form is displayed. The Form contains alarm information extracted from the Alarm Banner as well as a Further Information field.

The user enters additional details about the alarm in the Further Information field.

The user then selects the OK button and a confirmation window is displayed. The confirmation window contains the information entered by the user.

The user selects the Yes button and the extracted alarm information and the user-defined information are displayed in a message box.

See Also:

Example 1: Extracting Alarm Information from the Alarm Banner.


Scripting Guide - Global Functions

Global Functions

Global functions, also referred to as 'Common functions' are functions that are available for each type of object. This means that they can be used in both Mimic scripts and Alarm Banner scripts, and as they do not reference a particular type of object, their syntax has no object preface.

Like other ClearSCADA-specific functions, the Global functions provide additional functionality.

The Global functions are:

  • GetRegistry
  • SetRegistry
  • System
  • Sleep
  • SetBusy
  • DisplayObjectMenu
  • LocalTimeToUTC
  • UTCToLocalTime.

NOTE: Examples of the syntax for Global functions are included in the function descriptions (listed above).


Scripting Guide - GetRegistry (Global Functions)

GetRegistry

The GetRegistry function allows a script to retrieve a value from a registry

Syntax

GetRegistry (Name, Default)

Description

Reads a value from a registry.

Arguments

Name {string}

The Name defines the entry in the registry that is to be read by the script. The Name you enter has to match the name of the required registry.

Default {string or integer}

The Default value is an optional variant and is used to define the value that will be used if the script cannot find an entry in the registry.

Returns

Returns a string or integer value from the registry.

NOTE: The registry values are usually stored in the
HKEY_CURRENT_USER\Software\Schneider Electric\ClearSCADA\ViewX\Mimics key in the registry on your client PC.

Example:

RegValue = GetRegistry("CoreReg", 17)

This sets the RegValue variable (defined earlier in the script) to have the same value as the value stored in the CoreReg registry. If the script cannot find a value in the registry, the value 17 is used instead and is also created in the registry.

See Also:

SetRegistry.


Scripting Guide - SetRegistry (Global Functions)

SetRegistry

The SetRegistry function allows a script to write a value to a registry,
Syntax | SetRegistry (Name, Value)
Description | Writes a value to the registry.
Arguments | Name {string} The Name defines the registry that is to be written to by the script. The Name entry in your script has to match the name of the required registry. Value {string or integer} The value that is to be written to the registry.
Returns | None.

NOTE: The registry values are usually stored in the HKEY_CURRENT_USER\Software\Schneider Electric\ClearSCADA\ViewX\Mimics key in the registry on your client PC.

Example:

SetRegistry ("CoreReg", 58)

This writes the value 58 to the CoreReg registry.

See Also:

GetRegistry.


Scripting Guide - System (Global Functions)

System

The System function allows DOS commands to be issued from the script,
Syntax | System (Command)
Description | Issues a DOS command from the script.
Arguments | Command {string} This is a DOS command.
Returns | None.

Example:

System ("net send 192.168.0.117 Server1 is down")

This send the network message 'Server 1 is down' to the PC with IP address 192.168.0.117.


Scripting Guide - Sleep (Global Functions)

Sleep

The Sleep function allows a script to pause for the defined amount of time.
Syntax | Sleep (Time)
Description | Causes the script to pause for a defined number of milliseconds.
Arguments | Time {integer} The Time value is in milliseconds.
Returns | None.

Example:

Sleep (10)

The script will wait for 10 milliseconds before proceeding.


Scripting Guide - SetBusy (Global Functions)

SetBusy

The SetBusy function allows a script to define whether the cursor changes to indicate that the script is running. This function is often used when scripts have to perform a process which can take an extended amount of time to complete—during this time, the cursor can change shape to a busy icon, indicating to the user that the script is running normally and that there is a delay before the script can run to completion.
Syntax | SetBusy (Boolean)
Description | When True, causes the cursor to indicate that a script is busy running.
Arguments | SetBusy {Boolean} You have to set the Boolean value to True if the busy cursor is to be enabled; false if the busy cursor is to be disabled.
Returns | None. If the Boolean value is true, the cursor icon will change to indicate that a script is running; if the Boolean value is false, the cursor icon will remain the same irrespective of whether a script is running.

Example:

SetBusy (True)

The cursor icon will change when the script is running so that users can identify that the script is running and has not yet run to completion.


Scripting Guide - DisplayObjectMenu (Global Functions)

DisplayObjectMenu

The DisplayObjectMenu function allows a script to display the pick action menu for a specified database item.,

Syntax

DisplayObjectMenu (Object Reference, Options)

Description

Displays the pick action menu for a specified database item.

Arguments

Object Reference {string}

The address of the database item that has the pick action menu that you want the script to display.

Options {string}

You can choose to exclude some of the menu options from the menu. To do this, simply add the relevant No option to the syntax, using & to separate each option that is to be excluded. Any options that are not excluded will be shown in the menu. The No options are:

  • NoView—Excludes the View Status option.
  • NoAlarmView—Excludes the Display Alarm View option.
  • NoHelpView—Excludes the Display Help View option.
  • NoDefaultView—Excludes the Display Default View option.
  • NoNotes—Excludes the Notes option.
  • NoEvents—Excludes the Display Events option.
  • NoAlarms—Excludes the Display Alarms option.
  • NoDisplay—Excludes the Display option.
  • NoQueries—Excludes query based options such as Display Objects
  • NoTrends—Excludes the options for Trends.
  • NoMethods—Excludes the options for Methods.
  • NoErrors—Excludes the Display Errors option.
  • NoRefs—Excludes the Display References option.
  • NoProperties—Excludes the Properties option.
  • NoEdit—Excludes the Edit option.
  • NoLinks—Excludes any link options (link options are added via the Server Configuration Tool, see Link Fields in the ClearSCADA Guide to Server Administration).
  • NoNavSync—Excludes the Locate in Database Explorer option.
  • NoNavSyncTempl—Excludes the Locate Matching Template Object option.
  • NoUserMethods—Excludes any User Methods (i.e. custom methods that have been defined on the User Methods tabs on Forms)
  • NoAlarmMethods—Excludes any alarm related options (Acknowledge Alarms, Enable Alarms etc.)
  • NoLocateOPCNavigator—Excludes the Locate in OPC Data Explorer option.

Returns

None.

Example:

DisplayObjectMenu("CentralGroup.DigPoint1", "NoProperties&NoMethods")

This sets the script to display the pick action menu for the 'DigPoint1' point. The pick action menu shows each of the options for the 'DigPoint1' point except the Properties option and the various method options.


Scripting Guide - LocalTimeToUTC (Global Functions)

LocalTimeToUTC

The LocalTimeToUTC function allows a script to convert a local time value into a Universal Co-ordinated Time (UTC) value,
Syntax | LocalTimeToUTC (Time)
Description | Converts a local time value into a UTC value.
Arguments | Time {DateTime} The local time DateTime value that is to be converted into a UTC DateTime value.
Returns | Time {DateTime}. A UTC time value.

Example:

UTCTime = LocalTimeToUTC (LocalTimeInput)

Where:

UTCTime is the name of the variable that is used to store the result of the conversion.

LocalTimeInput is the name of the variable that stores the local time that is to be converted to UTC. The LocalTimeInput has to store a DateTime value.


Scripting Guide - UTCToLocalTime (Global Functions)

UTCToLocalTime

The UTCToLocalTime function allows a script to convert a UTC time value into a local time value,
Syntax | UTCToLocalTime (Time)
Description | Converts a UTC value into a local time value.
Arguments | Time {DateTime} The UTC DateTime value that is to be converted into a local time DateTime value.
Returns | Time {DateTime}. A local time value.

Example:

LocalTime = UTCToLocalTime (UTCTimeInput)

Where:

LocalTime is the name of the variable that is used to store the result of the conversion.

UTCTimeInput is the name of the variable that stores the UTC time that is to be converted to local time. The UTCTimeInput has to store a DateTime value.


Scripting Guide - Application Functions and Properties

Application Functions and Properties

The Application script object has functions and properties that affect ViewX. They allow a script to perform various tasks in ViewX, including opening windows, logging on and off, changing a password, displaying the online help, exiting ViewX and returning the number of the head on which the script is running.

The Application object is available to for use in both Mimic and Alarm Banner scripts, and it has the following functions and properties:

  • Application Functions
  • App.OpenWindow
  • App.LogOn and App.LogOff
  • App.LogOnUser and App.LogOffUser
  • App.ChangePassword
  • App.DisplayHelp
  • App.Exit
  • Application Properties
  • App.Head
  • App.Homepage.


Scripting Guide - Application Functions (Application Functions and Properties)

Application Functions

Application functions are functions that affect ViewX. They can be used to open a window, log a user on or off, change a user's password, display the online help, specify a particular head or quit ViewX.

Each application function references an Application (App) object. So, in your script, you need to use the following format to reference an application function:

App.<function name>

The application functions that you can use in your scripts are:

  • App.OpenWindow
  • App.LogOn (see App.LogOn and App.LogOff)
  • App.LogOff (see App.LogOn and App.LogOff)
  • App.LogOnUser (see App.LogOn and App.LogOff)
  • App.LogOffUser (see App.LogOn and App.LogOff)
  • App.ChangePassword
  • App.DisplayHelp
  • App.Exit.

You can also use the Global Functions that are available for the App object.

NOTE: The App object also has properties that can be accessed (see Application Properties).


Scripting Guide - App.OpenWindow (Application Functions and Properties)

App.OpenWindow

The OpenWindow application function sets the script to open another display when executed. For example, you could create a script that, when executed, causes an object property Form, Mimic, etc. to be displayed in a new window.

Syntax

App.OpenWindow (URL)

Description

The OpenWindow application function opens another window, such as a an object property Form, Mimic, etc., when executed.

If the current window is maximized, the new window will also be maximized. If the current window is not maximized, the new window will be opened at the same size but with a position offset down and to the right of the calling window.

Arguments

URL {string}

The URL of the display that is opened. The target display can be a Mimic, Trend, Report, Form or any other type of display.

For Mimic scripts, the URL has to use the ClearSCADA address format:

SCX:////<Class>/<Database Item>.

For Alarm Banner scripts, the URL has to use the ClearSCADA address format:

SCX:////<System Name>/<Class>/<Database Item>

This is because the Alarm Banner is not associated with a system, and so any hyperlinks have to specify the system that contains the display that is to be shown in a new window.

Returns

None.

Example 1.

This example displays a Mimic:

App.OpenWindow ("SCX:////CMimic/.System Overview")

Where:

  • App. is the object being referenced
  • OpenWindow is the name of the application function being used
  • ("SCX:////CMimic/.System Overview") is the URL of a display, in this case, the 'System Overview' Mimic.

Example 2.

This example displays a Form for an internal analog point named 'AI1':

App.OpenWindow ("SCX:////CPointAlgManual/.AI1")

See also:

Mimic.Close

App.Homepage

Mimic.GoBack

Mimic.GoForward

Mimic.Navigate

Mimic.OpenInset.


Scripting Guide - App.LogOn and App.LogOff (Application Functions and Properties)

App.LogOn and App.LogOff

The LogOn and LogOff functions are application functions and are used to prompt the user to log on or log off the current user.
Syntax | App.LogOn ( ) App.LogOff ( )
Description | The LogOn application function displays the Log On Window, prompting the user to log on via their User account. Once the user has logged on, they will remain logged on until they log off or until another user logs on via the same client. The LogOff application function logs off the current user.
Arguments | None.
Returns | None.

Example:

App.LogOn

App.LogOff

See Also:

App.ChangePassword.


Scripting Guide - App.LogOnUser and App.LogOffUser (Application Functions and Properties)

App.LogOnUser and App.LogOffUser

The LogOnUser and LogOff functions are application functions and are used to log on/log off a specified system using a specified user name and password.
Syntax | App.LogOnUser (System, User, Password) App.LogOffUser (System)
Description | The LogOnUser application function logs on to a specified system using a specified username and password. Unlike the LogOn application function, it does not display the Log On Window or prompt the user to enter log on details. The LogOffUser application function logs off the specified system.
Arguments | System {String} The name of the system to which the specified user is going to be logged on/off. User {String} The user name that is used to log on to the specified system. Password {String} The password for the user name that is used to log on to the specified system.
Returns | None.

Example:

App.LogOnUser ("SP1-SYS", "AYOUNG", "AY07AV")

This would log on to the SP1-SYS system via the AYOUNG user account using the password AY07AV.


Scripting Guide - App.ChangePassword (Application Functions and Properties)

App.ChangePassword

The ChangePassword function is an application function that opens the Change Password window. This allows the currently logged on user to change their own password.
Syntax | App.ChangePassword ( )
Description | The ChangePassword application function opens the Change Password window when executed. You can then use the Change Password window to alter the password for your User account. This is dependent on the configuration of your User account—you can only change your password if the Change Password check box is selected on the User Form for your account.).
Arguments | None.
Returns | None.

Example:

App.ChangePassword

See also:

App.LogOn and App.LogOff


Scripting Guide - App.DisplayHelp (Application Functions and Properties)

App.DisplayHelp

The DisplayHelp function is an application function that is used to display the ClearSCADA online help window.
Syntax | App.DisplayHelp ( )
Description | The DisplayHelp application function opens the online help window when executed. You can then use the Online Help window to view the reference documentation for your system, such as help files on Mimics, Logic, point configuration etc.
Arguments | None.
Returns | None.

Example:

App.DisplayHelp
Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Scripting Guide - App.Exit (Application Functions and Properties)

App.Exit

The Exit function is an application function that is used to close ViewX.
Syntax | App.Exit ( )
Description | The Exit application function closes ViewX when executed.
Arguments | None.
Returns | None.

Example:

App.Exit
Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Scripting Guide - Application Properties (Application Functions and Properties)

Application Properties

The App object has the following property that you can use in your scripts:

  • App.Head.
  • App.Homepage.


Scripting Guide - App.Head (Application Functions and Properties)

App.Head

The Head property is an application property that is used to return the head number of the application. This is only of any practical use on multi-head systems.
Syntax | App.Head
Description | Returns the head number of the application.
Arguments | None.
Returns | Integer. The head number of the application. This can be: 0 - For a WebX head. WebX heads return 0, even if there are multiple browser windows open. 1 - ViewX started from head 1. 2 - ViewX started from head 2. 3 - ViewX started from head 3. 4 - ViewX started from head 4. 5 - ViewX started from head 5.

Example:

In this example, the script will cause a WebX client to navigate back to the previous page. However, the same script will cause a ViewX client to close the Mimic instead.

IF App.Head =0 THEN
Mimic.GoBack()
ELSE
Mimic.Close
END IF


Scripting Guide - App.Homepage (Application Functions and Properties)

App.Homepage

The Homepage application property can be used in conjunction with the OpenWindow application function. It allows the Homepage Mimic to be opened when the OpenWindow script is executed.
Syntax | App.Homepage
Description | The Homepage property returns the Homepage property of the current user.
Argument | None.
Returns | URL {string}. The Homepage application property returns the address of the home page for the currently logged on user. This is the home page defined in the configuration of the user's User account (on the User Form) or is defined via the Tools menu (if the current logged on user is the Guest user).

Example:

sHomepage = App.Homepage
App.OpenWindow sHomepage

Where:

  • sHomepage is the name of a variable used to store the string that is returned by the App.Homepage function.
  • App.Homepage is the function used to return the Homepage of the currently logged on user.
  • App.Openwindow is the object being referenced (App.) and the name of the application function being used (OpenWindow).

See also:

App.OpenWindow

Mimic.Navigate

Mimic.OpenInset.


Scripting Guide - Form and Control Object Functions and Properties

Form and Control Object Functions and Properties

The Form script object has functions and properties that allow you to create a Form and add various fields, combo boxes, check boxes etc. to it. The Form functions that add settings to Forms return a special Form object called a ControlObject. Each ControlObject that is returned represents a specific setting and has common ControlObject properties as well as functions and properties that are specific to the type of setting that has been added. For example, Form.AddStaticText returns a ControlObject that has the common ControlObject properties as well as the StaticText properties.

The Form object and the ControlObject returned by some of its functions are available for use in both Mimic and Alarm Banner scripts. Their functions and properties are as follows:

  • Form Functions
  • Form.Init
  • Form.Show
  • Form.Clear
  • Form.Remove
  • Form.AddStaticText
  • Form.AddGroupBox
  • Form.AddEditBox
  • Form.AddPushButton
  • Form.AddCheckBox
  • Form.AddRadioButton
  • Form.AddComboBox
  • Form.AddListBox
  • Form.AddDateTime
  • Form.AddQuery
  • Form.AddSlider
  • Form Properties
  • Form.Title
  • Form.Selection
  • Control Object Properties
  • X and Y
  • Visible
  • Disabled
  • Group
  • Static Text Properties
  • StaticText.Text
  • Group Box Properties
  • GroupBox.Text
  • GroupBox.Width
  • GroupBox.Height
  • Edit Box Functions
  • EditBox.SetRange
  • Edit Box Properties
  • EditBox.Value
  • EditBox.Width
  • EditBox.Lines
  • EditBox.MaxLength
  • EditBox.ReadOnly
  • EditBox.Password
  • EditBox.Align
  • EditBox.VScroll
  • EditBox.WordWrap
  • Editbox.SelectText
  • Editbox.ShowKeypad
  • PushButton Properties
  • PushButton.Text
  • PushButton.Default
  • PushButton.Align
  • Check Box Properties
  • CheckBox.Checked
  • CheckBox.Text
  • CheckBox.LeftText
  • Radio Button Properties
  • RadioButton.Checked
  • RadioButton.Text
  • RadioButton.LeftText
  • Combo Box Functions
  • ComboBox.Clear
  • ComboBox.Add
  • ComboBox.Insert
  • ComboBox.Delete
  • ComboBox.Selection
  • Combo Box Properties
  • ComboBox.Sort
  • ComboBox.Count
  • List Box Functions
  • ListBox.Clear
  • ListBox.Add
  • ListBox.Insert
  • ListBox.Delete
  • ListBox.IsSelected
  • ListBox.SetSelected
  • List Box Properties
  • ListBox.Selection
  • ListBox.Rows
  • ListBox.Columns
  • ListBox.Sort
  • ListBox.Multiple
  • ListBox.Count
  • DateTime Properties
  • DateTime.Value
  • DateTime.Format
  • Query Functions
  • Query.SetParamControl
  • Query.Value
  • Query Properties
  • Query.Width
  • Query.Query
  • Query.SelectedRow
  • Slider Properties
  • Slider.Value
  • Slider.Minimum
  • Slider.Maximum
  • Slider.TickFrequency
  • Slider.Width.


Scripting Guide - Form Functions (Form and Control Object Functions and Properties)

Form Functions

The Form functions allow you to create scripts that display custom Forms. The custom Forms can have text boxes, edit boxes, list boxes and many of the other features that you might expect to see on a Form.

Each Form function and property references a Form object. So, in your script, you need to use the following format to reference a Form function or property:

Form.<function name>

Each Form object has the following functions:

  • Form.Init
  • Form.Show
  • Form.Clear
  • Form.Remove
  • Form.AddStaticText
  • Form.AddGroupBox
  • Form.AddEditBox
  • Form.AddPushButton
  • Form.AddCheckBox
  • Form.AddRadioButton
  • Form.AddComboBox
  • Form.AddListBox
  • Form.AddDateTime
  • Form.AddQuery
  • Form.AddSlider.

Remember that each Form Function returns a control that also has its own properties (and functions in the case of the Edit, Combo Box and List functions). Many Form objects also have Control Object Properties.


Scripting Guide - Form.Init (Form and Control Object Functions and Properties)

Form.Init

The Form.Init function allows a script to clear the Form and add a defined title.
Syntax | Form.Init(Title)
Description | Clears the Form and adds a specified title.
Arguments | Title {string} The Title can be seen at the top of the Form (in the Title banner). It can be entered manually, or can be a variable that contains a text value.
Returns | None.

Example:

Form.Init("Alarm Set")

This clears the Form and adds the title: Alarm Set. The script would then have Add functions to add text boxes, fields etc. to the Form, which would be followed by the Show function that displays the Form and its contents.

See Also:

Form.Clear

Form.Show

Form.Remove

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime


Scripting Guide - Form.Show (Form and Control Object Functions and Properties)

Form.Show

The Show function allows the script to display a Form.
Syntax | Form.Show()
Description | Displays a Form. The next function in the script is not performed until the Form is closed by a user.
Arguments | None.
Returns | None.

Example:

Form.Show()

Displays a Form that has been created earlier in the script.

See Also:

Form.Init


Scripting Guide - Form.Clear (Form and Control Object Functions and Properties)

Form.Clear

The Clear function removes controls etc., from a Form. In effect, the Clear function works in the same way as the Init function except that it cannot specify the title for the Form. Only the Init function can specify the title.
Syntax | Form.Clear()
Description | Removes the controls from a Form.
Arguments | None.
Returns | None.

Example:

Form.Clear

Clears a Form that has been defined earlier in the script.

See Also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime


Scripting Guide - Form.Remove (Form and Control Object Functions and Properties)

Form.Remove

The Remove function removes a specific control (field, button, combo box etc.) from the Form.
Syntax | Form.Remove(Control Object)
Description | Removes a specific field, combo box, check box, button etc. from the Form.
Arguments | Control Object The Control Object has to match the name of a variable that is used in the script to store the control object. The variable should be the variable that stores the control object that is returned by the Add function that was used to create the control that you want to remove. Control objects are returned by the Add functions for Forms such as AddComboBox etc.
Returns | None.

Example:

The following script adds 2 combo boxes to a Form. The combo boxes provide the same functionality and so the Form.Remove function is used to remove one of the combo boxes.

Form.Init "Verify Control Action"
Form.AddGroupBox 0,0,100,8,""
Form.AddStaticText 2,1, "Are you sure you wish to execute this control?"
Set frmExecuteNow = Form.AddComboBox(60,1)
frmExecuteNow.Add("Yes")
frmExecuteNow.Add("No")
frmExecuteNow.Add("Wait")
frmExecuteNow.Selection = 1
Set frmExecuteControl = Form.AddComboBox(80,1)
frmExecuteControl.Add("Yes")
frmExecuteControl.Add("No")
frmExecuteControl.Add("Wait")
frmExecuteControl.Selection = 1
Form.Show

Where:

  • frmExecuteNow is the name of the variable used to store the FieldObject that is returned by the AddComboBox function.
  • The Add functions are used to add values to the FieldObject i.e. add options to the combo box.
  • Selection is used to indicate the option that is selected by default (0 is the first option, 1 the second option, 2 the third option and so on).

The script creates the following Form:

The second combo box (referenced in the script by the frmExecuteControl variable) is no longer required, and so the following script is added to the script:

Form.Remove(frmExecuteControl)

This is added one line above the Form.Show function. It removes the control that is referenced by the frmExecuteControl variable (it removes the second combo box).

When the script is executed, the Form is shown as:


Scripting Guide - Form.AddStaticText (Form and Control Object Functions and Properties)

Form.AddStaticText

The AddStaticText function allows the script to add text to a Form. The text can be used to provide instructions, label a field etc.

Syntax

Form.AddStaticText(X, Y, Text)

Description

Displays a Form. The next function in the script is not performed until the Form is closed by a user.

Arguments

X {integer}

Represents the horizontal position of the text on the Form—the position on the 'X-Axis' at which the text begins.

Y {integer}

Represents the vertical position of the text on the Form—the position on the 'Y-Axis' at which the text begins.

Text {string}

The text that is to be shown on the Form.

Returns

Static Text Control Object

Static Text Control Objects have common Control Object Properties as well as their own specific properties that can be used in the script (see Static Text Properties).

Example:

Set Description = Form.AddStaticText(2,2, "Set the Values for the Pump")

Adds the words 'Set the Value for the Pump' to the Form at the position that corresponds to 2, 2. The control is stored in the Description variable that is defined earlier in the script.

See Also:

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime

Static Text Properties.


Scripting Guide - Form.AddGroupBox (Form and Control Object Functions and Properties)

Form.AddGroupBox

The AddGroupBox function allows the script to add a section box to the Form. Typically, section boxes are used to group controls on the Form.

Syntax

Form.AddGroupBox(X, Y, Width, Height, Text)

Description

Adds a section box to a Form.

Arguments

X {integer}.

Represents the horizontal position of the section box on the Form—the position on the 'X-Axis' at which the section box begins. The number represents a percentage of the Form's X co-ordinate, where 0 is absolute left.

Y {integer}

Represents the vertical position of the section box on the Form—the position on the 'Y-Axis' at which the section box begins. The number represents a percentage of the Form's Y co-ordinate, where 0 is the top of the Form.

Width {integer}

Defines the width of the section box.

Height {integer}

Defines the height of the section box.

Text {string}

The text that is shown at the top of the section box (the label of the section box). The Text argument is optional.

Returns

Group Box Control Object

Group Box Control Objects have common Control Object Properties as well as their own specific properties that can be used in the script (see Group Box Properties).

Example:

Set SectionBoxTitle = Form.AddGroupBox(0,0,100,8,"This is the Text for the Section Box")

This adds a section box to the Form. The section box is positioned at the co-ordinates 0,0 (top left corner as the co-ordinates are 0% of the Form's co-ordinates) and is 100 wide and 8 high. It has a text value of "This is the Text for the Section Box" which is shown as a label:

The Control Object that is returned by the AddGroupBox function is stored in the SectionBoxTitle variable that is defined earlier in the script.

See Also:

Form.AddStaticText

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime

Group Box Properties.


Scripting Guide - Form.AddEditBox (Form and Control Object Functions and Properties)

Form.AddEditBox

The AddEditBox function allows the script to add a text entry field to the Form. Text entry fields are used when the user needs to manually enter information on the Form

Syntax

Form.AddEditBox(X, Y, Width, Lines)

Description

Adds a text entry field to a Form.

Arguments

X {integer}.

Represents the horizontal position of the field on the Form—the position on the 'X-Axis' at which the field begins. The number represents a percentage of the Form's X co-ordinate, where 0 is absolute left.

Y {integer}

Represents the vertical position of the field on the Form—the position on the 'Y-Axis' at which the field begins. The Y argument is optional. The number represents a percentage of the Form's Y co-ordinate, where 0 is at the top.

Width {integer}

Defines the width of the field.

Lines {integer}

Sets the number of lines of text that can be entered into the field. Enter 1 for a single line field, or enter a number higher than 1 for a multi-line field. If a user enters more lines of text than is defined for a multi-line field, scroll bars appear for the field.

Returns

Edit Control Object

Edit Control Objects have common Control Object Properties as well as their own specific functions and properties that can be used in the script—see see Edit Box Functions and see Edit Box Properties.

Example:

Set EnterInfo = Form.AddEditBox(2, 3, 80, 4)

This adds a multi-line text entry field to the Form. The Control Object that is returned by the AddEditBox function is stored as the EnterInfo variable that is defined earlier in the script.

See Also:

Form.AddStaticText

Form.AddGroupBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime

Edit Box Functions.


Scripting Guide - Form.AddPushButton (Form and Control Object Functions and Properties)

Form.AddPushButton

The AddPushButton function allows the script to add a selectable button to the Form.

Syntax

Form.AddPushButton(X, Y, Text)

Description

Adds a push button to a Form.

Arguments

X {integer}

Represents the horizontal position of the button on the Form—the position on the 'X-Axis' at which the button begins.

Y {integer}

Represents the vertical position of the button on the Form—the position on the 'Y-Axis' at which the button begins.

Text {string}

Defines the text that is shown on the push button.

Returns

Push Button Control Object

Push Button Control Objects have common Control Object Properties as well as their own specific properties that can be used in the script (see PushButton Properties).

Example:

Set SelectOption = Form.AddPushButton(2, 3, "Parameters")

This adds a button to the Form. The button has the word Parameters on it and it returns a Control Object that is stored in the SelectOption variable that is defined earlier in the script.

See Also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime

PushButton Properties.


Scripting Guide - Form.AddCheckBox (Form and Control Object Functions and Properties)

Form.AddCheckBox

The AddCheckBox function allows the script to add a check box to the Form.
Syntax | Form.AddCheckBox(X, Y, Text)
Description | Adds a check box to a Form.
Arguments | X {integer} Represents the horizontal position of the check box on the Form—the position on the 'X-Axis'. Y {integer} Represents the vertical position of the check box on the Form—the position on the 'Y-Axis'. Text {string}. Defines the text that is shown next to the check box.
Returns | Check Box Control Object Check Box Control Objects have common Control Object Properties as well as their own specific properties that can be used in the script (see Check Box Properties).

Example:

Set TurnOn = Form.AddCheckBox(2, 3, "Activate")

This adds a check box to the Form. The check box has the word Activate next to it. The check box returns a Control Object that is stored in the TurnOn variable that is defined earlier in the script.

See Also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime

Check Box Properties.


Scripting Guide - Form.AddRadioButton (Form and Control Object Functions and Properties)

Form.AddRadioButton

The AddRadioButton function allows the script to add a radio button (option button) to the Form.
Syntax | Form.AddRadioButton(X, Y, Text)
Description | Adds a radio button to a Form.
Arguments | X {integer} Represents the horizontal position of the radio button on the Form—the position on the 'X-Axis'. Y {integer} Represents the vertical position of the radio button on the Form—the position on the 'Y-Axis'. Text {string} Defines the text that is shown next to the radio button.
Returns | Radio Button Control Object Radio Button Control Objects have common Control Object Properties as well as their own specific properties that can be used in the script (see Radio Button Properties).

Example:

Set UseLimits2 = Form.AddRadioButton(25, 3, "Use Alternate Limits")

This adds a radio button to the Form. The radio button has the words Use Alternate Limits next to it. The radio button returns a Control Object that is stored in the UseLimits2 variable that is defined earlier in the script.

See Also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddComboBox

Form.AddListBox

Form.AddDateTime

Radio Button Properties.

Group.


Scripting Guide - Form.AddComboBox (Form and Control Object Functions and Properties)

Form.AddComboBox

The AddComboBox function allows the script to add a combo box to the Form.
Syntax | Form.AddComboBox(X, Y, pStrings)
Description | Adds a combo box to a Form.
Arguments | X {integer} Represents the horizontal position of the combo box on the Form—the position on the 'X-Axis'. Y {integer} Represents the vertical position of the combo box on the Form—the position on the 'Y-Axis'. pStrings {string array} Represents the options that are shown in the combo box.
Returns | Combo Box Control Object Combo box Control Objects have common Control Object Properties as well as their own specific functions and properties that can be used in the script—see Combo Box Functions and see Combo Box Properties.

Example:

The following script creates a Form that has a combo box with 3 options (named Internal, Analog, and Digital respectively):

Public Sub ComboExample
Dim pStrings (2)
Dim frmCombo

pStrings(0) = "Internal"
pStrings(1) = "Analog"
pStrings(2) = "Digital"

Form.Init ("Point Type")
Set frmCombo = Form.AddComboBox(2,2,pStrings)
Form.Show
End Sub

The pStrings array is declared as a variable, with each of its options also defined before the Form.Init function. The Form.AddComboBox function then has the arguments of 2, 2 for the positioning of the combo box and pStrings is a reference to the pStrings variable (which is the string array).

See Also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddListBox

Form.AddDateTime

Combo Box Functions

Combo Box Properties.


Scripting Guide - Form.AddListBox (Form and Control Object Functions and Properties)

Form.AddListBox

The AddListBox function allows the script to add a list box to the Form.
Syntax | Form.AddListBox(X, Y, Rows, Columns, pStrings)
Description | Adds a list box to a Form.
Arguments | X {integer} Represents the horizontal position of the list box on the Form—the position on the 'X-Axis'. Y {integer} Represents the vertical position of the list box on the Form—the position on the 'Y-Axis'. Rows {integer} Defines the number of rows in the list. Columns {integer} Defines the number of columns in the list (this is optional). pStrings {string array} Represents the options that are shown in the list box.
Returns | List Box Control Object List box Control Objects have common Control Object Properties as well as their own specific functions and properties that can be used in the script—see List Box Functions and see List Box Properties.

Example:

The following script creates a Form that has a list box with 3 options (named Temperature, Pressure, and Humidity respectively):

Public Sub ListExample
Dim pStrings (2)
Dim frmCombo

pStrings(0) = "Temperature"
pStrings(1) = "Pressure"
pStrings(2) = "Humidity"

Form.Init ("ListBox")
Set frmCombo = Form.AddListBox(2,2,10,2,pStrings)
Form.Show
End Sub

The pStrings array is declared as a variable, with each of its options also defined before the Form.Init function.

The Form.AddListBox function then has the arguments of 2, 2 for the positioning of the list box, 10 for the number of rows, 1 for the number of columns, and pStrings is a reference to the pStrings variable (which is the string array).

See Also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddDateTime

List Box Functions

List Box Properties.


Scripting Guide - Form.AddDateTime (Form and Control Object Functions and Properties)

Form.AddDateTime

The AddDateTime function allows the script to add a date/time field to the Form.
Syntax | Form.AddDateTime(X, Y)
Description | Adds a date/time selection field to the Form.
Arguments | X {integer} Represents the horizontal position of the Date/Time field on the Form—the position on the 'X-Axis'. Y {integer} Represents the vertical position of the Date/Time field on the Form—the position on the 'Y-Axis'.
Returns | Date Time Control Object DateTime Control Objects have common Control Object Properties as well as their own specific properties that can be used in the script (see DateTime Properties).

Example:

Set TimeStamp = Form.AddDateTime(1,1)

This adds a Date/Time field to the Form at co-ordinates 1, 1. The Control Object that is returned by the DateTime function is stored in the TimeStamp variable that is defined earlier in the script.

See Also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

DateTime Properties.


Scripting Guide - Form.AddQuery (Form and Control Object Functions and Properties)

Form.AddQuery

The Form.AddQuery function allows you to add a Queries List control to the Form. You will need to have a good understanding of the SQL language when using this function.

Syntax

Form.AddQuery(X, Y, Width, Lines, SQL Query)

Description

Adds a list control to a Mimic. The list control contains the results of the SQL Query that is defined in the script.

Arguments

X {integer}

Represents the horizontal position of the Date/Time field on the Form—the position on the 'X-Axis'.

Y {integer}

Represents the vertical position of the Date/Time field on the Form—the position on the 'Y-Axis'.

Width {integer}

Defines the width of the field.

Lines {integer}

Defines the approximate number of rows. Enter 1 for a single line row, or enter a number higher than 1 for a multiple rows.

SQL Query {string}

An SQL Query that defines which data is to be retrieved from the database and displayed in the Queries List control.

Returns

Query Control Object

Query Control Objects have common Control Object Properties as well as their own specific functions and properties that can be used in the script see Query Functions and see Query Properties.

Example:

Set QueryList = Form.AddQuery( 1, 3, 150, 20, "SELECT Name, TypeDesc FROM CMimic" )

This creates a 150 pixel wide, 20 line Queries List box that is positioned at 1 on the X-Axis and 3 on the Y-Axis. It contains the names and types of items in the CMimic class.

See also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime

Query Functions

Query Properties.


Scripting Guide - Form.AddSlider (Form and Control Object Functions and Properties)

Form.AddSlider

The Form.AddSlider function allows you to add a slider control to the Form
Syntax | Form.AddSlider(X, Y, Width, Value)
Description | Adds a slider control to a Form.
Arguments | X {integer} Represents the horizontal position of the slider on the Form—the position on the 'X-Axis'. Y {integer} Represents the vertical position of the slider on the Form—the position on the 'Y-Axis'. Width {integer} Defines the width of the slider. Value {integer} Defines the initial position of the slider when the slider is first displayed.
Returns | Slider Control Object Slider Control Objects have common Control Object Properties as well as their own specific properties that can be used in the script (see Slider Properties).

Example:

Set Slider = Form.AddSlider( 1, 1, 50, 0)

This creates a slider that is positioned at 1 on the X-Axis, 1 on the Y-Axis, is 50 pixels wide and has 0 as its initial value (the slider is positioned at 0 when it is first displayed).

See also:

Form.AddStaticText

Form.AddGroupBox

Form.AddEditBox

Form.AddPushButton

Form.AddCheckBox

Form.AddRadioButton

Form.AddComboBox

Form.AddListBox

Form.AddDateTime

Form.AddQuery

Slider Properties.


Scripting Guide - Form Properties (Form and Control Object Functions and Properties)

Form Properties

Every Form object has the following properties:

  • Form.Title
  • Form.Selection.

Remember that each Form Function returns a control that also has its own properties (and functions in the case of the Edit, Combo Box and List functions). Many Form objects also have Control Object Properties


Scripting Guide - Form.Title (Form and Control Object Functions and Properties)

Form.Title

The Form.Title property allows the script to define the name of the Form (shown in the title banner).
Syntax | Form.Title = Name
Description | Defines the title of the Form. The Form.Title property overwrites any other titles (such as the title defined by the Form.Init function).
Arguments | Name {string}
Returns | String

Example:

Form.Title = "Display Window"

This sets the title of the Form to: Display Window.


Scripting Guide - Form.Selection (Form and Control Object Functions and Properties)

Form.Selection

The Form.Selection property returns the text that is on the button that was used to close the Form.
Syntax | Form.Selection
Description | Indicates which button was selected in order to close the Form. The Form.Selection property is read-only.
Arguments | None
Returns | String Returns the text that is shown on the button that was used to close the Form. If there is no text on the button, an empty string is returned.

Example:

Msgbox Form.Selection

On a Form that has multiple buttons for closing, the selection property can be used to determine which of the buttons was pressed to close the window. For example, it can be used to determine whether the OK button or Cancel button was pressed (the property will return OK or Cancel respectively).


Scripting Guide - Control Object Properties (Form and Control Object Functions and Properties)

Control Object Properties

The Control Object properties are properties that are common to the following Form features:

  • Static Text
  • Push buttons
  • Groups
  • Edit Boxes
  • Check boxes
  • Radio Buttons
  • Combo Boxes
  • List boxes
  • DateTime Fields
  • Queries
  • Sliders.

Each of the Form features have their own functions and/or properties as well as the following control properties:

  • X and Y
  • Visible
  • Disabled
  • Group.


Scripting Guide - X and Y (Form and Control Object Functions and Properties)

X and Y

The X Control Object property allows the script to set the X-Axis co-ordinate of the Control Object, and the Y Control Object property allows it to set the Y-Axis co-ordinate.
Syntax | ControlObject.X = Number or ControlObject.Y = Number Where ControlObject is the name of the control object that you are positioning and Number is the number for the co-ordinate.
Description | Sets the position of the Control Object on the X-Axis (horizontal positioning) or Y-Axis (vertical positioning)
Arguments | ControlObject {string} The name of the Control Object that you want to position. Number {integer} The number for the X-Axis or Y-Axis co-ordinate.
Returns | Integer.

Example:

AlarmButton.X = 10

This would position the control named AlarmButton at X co-ordinate 10.


Scripting Guide - Visible (Form and Control Object Functions and Properties)

Visible

The Visible Control Object property allows the script to set the visibility of the Control Object.
Syntax | ControlObject.Visible = Value Where ControlObject is the name of the Control Object that you are hiding/showing.
Description | Sets the position of the Control Object on the X-Axis (horizontal positioning).
Arguments | ControlObject {string} The name of the Control Object that you want to show/hide. Value {Boolean} If set to True (1), the control is visible; if set to False (0) it is invisible.
Returns | Boolean.

For an example of how the Visible property can be used, see Mimic.Layers.


Scripting Guide - Disabled (Form and Control Object Functions and Properties)

Disabled

The Disabled Control Object property allows the script to set the Control Object to be 'grayed out' i.e. visible, but unavailable for selection or entry.
Syntax | ControlObject.Disabled = Value Where ControlObject is the name of the Control Object that you are hiding/showing.
Description | Sets the control to be 'grayed out' i.e. visible, but unavailable.
Arguments | Value {Boolean} If set to True (1), the Control Object is visible but unavailable for selection; if set to False (0) the Control Object is visible and available for selection.
Returns | Boolean.

Example:

A script is created that allows the following Form to be displayed when an 'Override' button is selected on a Mimic:

It is decided that another field should be added to the Form and that the field should indicate the type of action that is to be executed. As the Form is only displayed when the user attempts to override a point for Valve 1, the new field needs to indicate that an Override control will be executed. The new field is for information only, and so is to be 'grayed out'.

A new variable named frmConfirm is added to the script, and a StaticText item containing the string "Action to be performed on Valve 1" is also added. The settings for the new field (Edit box) are defined by the lines:

Set frmConfirmAction = Form.AddEditBox(60,5)
frmConfirmAction.MaxLength = 10
frmConfirmAction.Value = "Override"
frmConfirmAction.Disabled = True

This adds a new edit box at co-ordinates 60, 5. It has a maximum character length of 10, and its value is set to be Override. As the field is to be 'grayed out', the Disabled property is referenced and set to True.

When the Form is re-displayed, the new grayed out field is added:


Scripting Guide - Group (Form and Control Object Functions and Properties)

Group

The Group Control Object property is designed for use with the radio button Control Object. It allows the script to group a series of radio buttons, so that only one of the radio buttons can be selected at one time.
Syntax | ControlObject.Group = Value. Where ControlObject is the name of the Control Object that is to be part of a group or excluded from a group.
Description | Sets the Control Object to be included/excluded from a group. When a radio button Control Object has its Group property set to True, it becomes part of a Group. The Group contains subsequent radio buttons in the script until another radio button with its Group property set to True is found. A radio button that has its Group property set to True indicates the start of a new Group.
Arguments | Value {Boolean} If set to True (1), the radio button Control Object is part of a new Group; if set to False (0), the radio button Control Object is either part of an existing Group or is not to be included in a Group at all. Radio buttons have their Group property set to False by default, so you only need to set the Group property to True if you want to start a new Group in the script.
Returns | Boolean.

Example:

A button on a Mimic is associated with a script that, when executed, causes a Form to be displayed. The Form contains 2 groups of radio buttons for setting the alignment of a shape. The user can select 1 radio button from each group.

...and 1 from the second group of radio buttons (Top, Middle, or Bottom).
Users can select 1 radio button in the first group (Left, Center, Right)...

To create the 2 groups of radio buttons, the following script is included in the script:

Set frmLeft = Form.AddRadioButton(2,2,"Left")
frmLeft.Group = True
Set frmCenter = Form.AddRadioButton(2,4,"Center")
Set frmRight = Form.AddRadioButton(2,6,"Right")
Set frmTop = Form.AddRadioButton(15,2,"Top")
frmTop.Group = True
Set frmMiddle = Form.AddRadioButton(15,4,"Middle")
Set frmBottom = Form.AddRadioButton(15,6,"Bottom")

The first line, Set frmLeft = Form.AddRadioButton(2,2,"Left"), sets the frmLeft variable to add a radio button at co-ordinates 2, 2, with the text label "Left". The second line, frmLeft.Group = True, sets the 'Left' radio button to be in a group (its Group property is set to True). Subsequent radio buttons will be included in the same group as the 'Left' button until the script comes to another Group = True. So, the 'Center' and 'Right' radio buttons are included in the same group as the 'Left' button, and the user will only be able to select one option from 'Left', 'Center', and 'Right'.

As the 6th line sets the Group property of the frmTop variable to True, a new group is started. Any radio buttons that are created after the 'Top' radio button will be included in the same group as the 'Top' radio button and not in the same group as the 'Left', 'Center' and 'Right' radio buttons. As with the first group, the user can only select one option from the group, and so can only select one from 'Top', 'Middle' or 'Bottom'.

To set the radio buttons to affect an item on the Mimic, an If statement would be used.


Scripting Guide - Static Text Properties (Form and Control Object Functions and Properties)

Static Text Properties

The Static control that is returned by a StaticText function has the following properties:

  • StaticText.Text
  • X and Y
  • Visible
  • Disabled.


Scripting Guide - StaticText.Text (Form and Control Object Functions and Properties)

StaticText.Text

The Static Text Control Object that is returned by the AddStaticText function has a Text property. The Text property represents the text that is displayed for the Static text.
Syntax | Static Text Control Object.Text = Text Where Static Text Control Object is the name of the variable (declared in your script) that is used to store the static text Control Object that is returned by the AddStaticText function.
Description | Defines the text that is shown as static text.
Arguments | Text {string} Defines the text that is shown as static text.
Returns | String

Example:

StaticText1.Text = "Pump 14"

Where:

  • StaticText1 is the name of the variable that stores the static text Control Object returned by the AddStaticText function
  • "Pump 14" is the text that is shown for the static text value.


Scripting Guide - Group Box Properties (Form and Control Object Functions and Properties)

Group Box Properties

The GroupBox Control Object that is returned by the AddGroupBox function has the following properties:

  • GroupBox.Text
  • GroupBox.Width
  • GroupBox.Height
  • X and Y
  • Visible
  • Disabled.


Scripting Guide - GroupBox.Text (Form and Control Object Functions and Properties)

GroupBox.Text

The GroupBox Control Object that is returned by the AddGroupBox function has a Text property. The Text property represents the text that is displayed on the heading of the Group Box.
Syntax | ControlObject.Text = Text Where ControlObject is the name of the variable (declared in your script) that is used to store the GroupBox Control Object that is returned by the AddGroupBox function.
Description | Sets the text that is shown as the heading for the Group Box.
Arguments | Text {string} Defines the text that is shown as the heading for the Group Box.
Returns | String

Example:

GroupBox1.Text = "Section A"

Where:

  • GroupBox1 is the name of the variable that stores the GroupBox control returned by the AddGroupBox function
  • "Section A" is the text that is shown for the heading of the Group Box.


Scripting Guide - GroupBox.Width (Form and Control Object Functions and Properties)

GroupBox.Width

The GroupBox Control Object that is returned by the AddGroupBox function has a Width property. The Width property represents the width setting of the Group Box.
Syntax | ControlObject.Width = Value Where ControlObject is the name of the variable (declared in your script) that is used to store the GroupBox Control Object that is returned by the AddGroupBox function.
Description | Sets the width of the Group Box.
Arguments | Value {integer} Defines the width setting of the Group Box. This is based on the average character width, so 1 is approximately 1 character wide.
Returns | Integer

Example:

GroupBox1.Width = 10

Where:

  • GroupBox1 is the name of the variable that stores the GroupBox Control Object returned by the AddGroupBox function
  • 10 is the width setting for the Group Box (10% of the usable area of the Form).


Scripting Guide - GroupBox.Height (Form and Control Object Functions and Properties)

GroupBox.Height

The GroupBox Control Object that is returned by the AddGroupBox function has a Height property. The Height property represents the height setting of the Group Box.
Syntax | Object.Height = Value Where Object is the name of the variable (declared in your script) that is used to store the GroupBox Control Object that is returned by the AddGroupBox function.
Description | Sets the height of the Group Box.
Arguments | Value {integer} Defines the height setting of the Group Box.
Returns | Integer

Example:

GroupBox1.Height = 10

Where:

  • GroupBox1 is the name of the variable that stores the GroupBox Control Object returned by the AddGroupBox function
  • 10 is the height setting for the Group Box.


Scripting Guide - Edit Box Functions (Form and Control Object Functions and Properties)

Edit Box Functions

The EditBox Control Object that is returned by the AddEditBox function has the following function:

  • EditBox.SetRange

See Also:

Edit Box Properties.


Scripting Guide - EditBox.SetRange (Form and Control Object Functions and Properties)

EditBox.SetRange

The EditBox.SetRange function allows the script to set an Edit Box to only allow numerical entries within a defined range.
Syntax | ControlObject.SetRange(Min,Max) Where ControlObject is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the Edit Box to only allow numerical entries within a defined range. A spin-box is added to the Edit Box to allow users to scroll through the available settings.
Arguments | Min {integer} Defines the lowest number permitted in the Edit Box. Max {integer} Defines the highest number permitted in the Edit Box.
Returns | Integer.

Example:

EditBox1.SetRange 3,50

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 3 is the lowest permitted entry
  • 50 is the highest permitted entry.


Scripting Guide - Edit Box Properties (Form and Control Object Functions and Properties)

Edit Box Properties

The EditBox Control Object that is returned by the AddEditBox function has the following properties:

  • EditBox.Value
  • EditBox.Width
  • EditBox.Lines
  • EditBox.MaxLength
  • EditBox.ReadOnly
  • EditBox.Password
  • EditBox.Align
  • EditBox.VScroll
  • EditBox.WordWrap
  • Editbox.SelectText
  • Editbox.ShowKeypad
  • X and Y
  • Visible
  • Disabled.

See Also:

Edit Box Functions.


Scripting Guide - EditBox.Value (Form and Control Object Functions and Properties)

EditBox.Value

The EditBox Control Object that is returned by the AddEditBox function has a Value property. The Value property represents the value that is shown in the Edit Box.
Syntax | ControlObject.Value = Value Where ControlObject is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the value or string that is shown in the Edit Box.
Arguments | Value {string or integer} A string value defines the text that is shown in the Edit Box. An integer value defines the number that is shown in the Edit Box. You need to define a string or a number. If the SetRange function is used in the script, the EditBox.Value should be a value within the defined range.
Returns | String or Integer depending on the type of argument defined.

Examples:

EditBox1.Value = 10

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 10 is the integer value for the Edit Box.
EditBox1.Value = "Test Value"

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • Test Value is the string value for the Edit Box.


Scripting Guide - EditBox.Width (Form and Control Object Functions and Properties)

EditBox.Width

The EditBox Control Object that is returned by the AddEditBox function has a Width property. The Width property represents the width setting of the Edit Box.
Syntax | ControlObject.Width = Value Where ControlObject is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the width of the Edit Box.
Arguments | Value {integer} A number that defines the width setting of the Group Box. This is based on the average character width, so 1 is approximately 1 character wide.
Returns | Integer

Example:

EditBox1.Width = 10

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 10 is the width setting for the Edit Box.


Scripting Guide - EditBox.Lines (Form and Control Object Functions and Properties)

EditBox.Lines

The EditBox Control Object that is returned by the AddEditBox function has a Lines property. The Lines property represents the number of lines permitted in the Edit Box.
Syntax | ControlObject.Lines = Value Where Object is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the number of lines for the Edit Box.
Arguments | Value {integer} A number that defines the permitted number of lines in the Edit Box.
Returns | Integer

Example:

EditBox1.Lines = 4

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 4 is the number of lines in the Edit Box.


Scripting Guide - EditBox.MaxLength (Form and Control Object Functions and Properties)

EditBox.MaxLength

The EditBox Control Object that is returned by the AddEditBox function has a MaxLength property. The MaxLength property represents the maximum number of characters permitted in the Edit Box.
Syntax | ControlObject.MaxLength = Value Where ControlObject is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the maximum number of characters for the Edit Box.
Arguments | Value {integer} Defines the maximum number of characters in the Edit Box.
Returns | Integer

Example:

EditBox1.MaxLength = 40

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 40 is the maximum number of characters for the Edit Box.


Scripting Guide - EditBox.ReadOnly (Form and Control Object Functions and Properties)

EditBox.ReadOnly

The EditBox Control Object that is returned by the AddEditBox function has a ReadOnly property. The ReadOnly property allows you to restrict the Edit Box so that it can only display a value - users are unable to alter or add to the value in the Edit Box.
Syntax | ControlObject.ReadOnly = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the Edit Box to be read only or read/write.
Arguments | Value {Boolean} If set to True (1), the Edit box is read only; if set to False (0) it is read/write.
Returns | Boolean

Example:

EditBox1.ReadOnly = True

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • True is the boolean value that sets the Edit Box to read only.


Scripting Guide - EditBox.Password (Form and Control Object Functions and Properties)

EditBox.Password

The EditBox Control Object that is returned by the AddEditBox function has a Password property. The Password property allows the Edit Box to hide the characters that are entered in the Edit Box—each character is displayed as an asterisk. This is useful for password fields, where the password needs to be entered but has to be hidden from view.
Syntax | ControlObject.Password = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the Edit Box to hide characters (use an asterisk in place of each character). The Password property can only be used with Edit Boxes that have 1 line. Multiple lines of password text are not supported.
Arguments | Value {Boolean} If set to True (1), the Edit box uses asterisks; if set to False (0) it does not hide the characters.
Returns | Boolean

Example:

EditBox1.Password = True

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • True is the boolean value that sets the Edit Box to use asterisks.


Scripting Guide - EditBox.Align (Form and Control Object Functions and Properties)

EditBox.Align

The EditBox Control Object that is returned by the AddEditBox function has an Align property. The Align property defines the default position for text that is entered into the Edit Box.
Syntax | ControlObject.Align = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the default position of text in the Edit Box.
Arguments | Value {integer} 0—Sets the default position to left. 1—Sets the default position to center. 2—Sets the default position to right.
Returns | Integer (alignment value)

Example:

EditBox1.Align = 1

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 1 sets the default position of the value in the Edit Box to be aligned centrally.


Scripting Guide - EditBox.VScroll (Form and Control Object Functions and Properties)

EditBox.VScroll

The EditBox Control Object that is returned by the AddEditBox function has a VScroll property. The VScroll property determines whether the Edit Box has a vertical scroll bar.
Syntax | ControlObject.VScroll = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets the vertical scroll bar for the Edit Box. The scroll bar is are only visible if the Edit Box is set to have multiple lines.
Arguments | Value {Boolean} If set to True (1), the Edit box has a vertical scroll bar; if set to False (0) it does not have a vertical scroll bar.
Returns | Boolean

Example:

EditBox1.VScroll = True

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • True sets the Edit Box to have a vertical scroll bar.
    Vertical scroll bar is made available for the Edit Box.


Scripting Guide - EditBox.WordWrap (Form and Control Object Functions and Properties)

EditBox.WordWrap

The EditBox Control Object that is returned by the AddEditBox function has a WordWrap property. The WordWrap property determines whether the value in the Edit Box wraps whole words onto the next line in the box.
Syntax | ControlObject.WordWrap = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Sets word wrapping for the Edit Box. Word wrapping is only applicable if the Edit Box is set to have multiple lines.
Arguments | Value {Boolean} If set to True (1), the Edit box has uses word wrapping; if set to False (0) it does not use word wrapping.
Returns | Boolean

Example:

EditBox1.WordWrap = 1

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 1 sets the Edit Box to use word wrapping.


Scripting Guide - Editbox.SelectText (Form and Control Object Functions and Properties)

Editbox.SelectText

The EditBox Control Object that is returned by the AddEditBox function has a SelectText property. The SelectText property determines whether the value in the Edit Box is selected by default when the Form is displayed.
Syntax | ControlObject.SelectText = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Selects the specified value by default when the Form is displayed.
Arguments | Value {Boolean} If set to True (1), the Edit box has its value selected automatically by default; if set to False (0) it does not have its value selected by default.
Returns | Boolean

Example:

EditBox1.SelectText = 1

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 1 sets the Edit Box to have option 1 selected by default when the Form is displayed.


Scripting Guide - Editbox.ShowKeypad (Form and Control Object Functions and Properties)

Editbox.ShowKeypad

The EditBox Control Object that is returned by the AddEditBox function has a ShowKeypad property. The Showkeypad property determines whether an alphanumeric keypad is made available for the Edit Box. The keypad allows users to select numbers and letters for field entries from an on-screen display (the keypad) rather than having to type in the entries using a traditional keyboard
Syntax | ControlObject.ShowKeypad = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the EditBox Control Object that is returned by the AddEditBox function.
Description | Provides access to an on screen keypad for manual entry of values.
Arguments | Value {Boolean} If set to True (1), the Edit box provides access to a keypad; if set to False (0) the EditBox does not provide access to a keypad and any user-defined inputs have to be made manually.
Returns | Boolean

Example:

EditBox1.ShowKeypad = 1

Where:

  • EditBox1 is the name of the variable that stores the EditBox Control Object returned by the AddEditBox function
  • 1 sets the Edit Box to have an alphanumeric keypad.


Scripting Guide - PushButton Properties (Form and Control Object Functions and Properties)

PushButton Properties

The PushButton Control Object that is returned by the AddPushButton function has the following properties:

  • PushButton.Text
  • PushButton.Default
  • PushButton.Align
  • X and Y
  • Visible
  • Disabled.


Scripting Guide - PushButton.Text (Form and Control Object Functions and Properties)

PushButton.Text

The PushButton Control Object that is returned by the AddPushButton function has a Text property. The Text property represents the text that is shown on the button.
Syntax | ControlObject.Text = Text Where ControlObject. is the name of the variable (declared in your script) that is used to store the PushButton Control Object that is returned by the AddPushButton function.
Description | Sets the string that is shown on the Push Button.
Arguments | Text {string}
Returns | String

Example:

PushButton1.Text = "Clear Form"

Where:

  • PushButton1 is the name of the variable that stores the PushButton Control Object returned by the AddPushButton function
  • "Clear Form" is the string that is shown on the button.


Scripting Guide - PushButton.Default (Form and Control Object Functions and Properties)

PushButton.Default

The PushButton Control Object that is returned by the AddPushButton function has a Default property. The Default property allows the push button to be selected by pressing the Enter key (this is dependant on the Default property being set to True and no other buttons being set to True).
Syntax | ControlObject.Default = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the PushButton Control Object that is returned by the AddPushButton function.
Description | Sets the default property setting of the Push Button. This can be True or False. If there are multiple Push Buttons with a True default setting, pressing the Enter key will select the Push Button that was most recently set to have a True default setting.
Arguments | Value {Boolean} If set to True (1), the Push Button is set to True and will be 'pressed' when the user presses the Enter key (unless other Push Buttons are also set to True, in which case, the Enter key will activate the Push Button that has most recently been set to True). If the Push Button is set to False (0), it will not be affected by a user pressing the Enter key.
Returns | Boolean

Example:

PushButton1.Default = 1

Where:

  • PushButton1 is the name of the variable that stores the PushButton Control Object returned by the AddPushButton function
  • 1 sets the Push Button to True. When a user presses the Enter key, the Push Button is selected (unless another Push Button has been set to True more recently).


Scripting Guide - PushButton.Align (Form and Control Object Functions and Properties)

PushButton.Align

The PushButton Control Object that is returned by the AddPushButton function has an Align property. The Align property defines the default position for text that is shown on the Push Button.
Syntax | ControlObject.Align = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the PushButton Control Object that is returned by the AddPushButton function.
Description | Sets the default position of text on the Push Button.
Arguments | Value {integer} 0—Sets the default position to left. 1—Sets the default position to center. 2—Sets the default position to right.
Returns | Integer (alignment value)

Example:

PushButton1.Align = 2

Where:

  • PushButton1 is the name of the variable that stores the PushButton Control Object returned by the AddPushButton function
  • 2 sets the text on the Push Button to be aligned to the right.
    The text on the Push Button is right aligned.


Scripting Guide - Check Box Properties (Form and Control Object Functions and Properties)

Check Box Properties

The CheckBox Control Object that is returned by the AddCheckBox function has the following properties:

  • CheckBox.Checked
  • CheckBox.Text
  • CheckBox.LeftText
  • X and Y
  • Visible
  • Disabled.


Scripting Guide - CheckBox.Checked (Form and Control Object Functions and Properties)

CheckBox.Checked

The CheckBox Control Object that is returned by the AddCheckBox function has a Checked property. The Checked property defines whether the check box is selected (displays a check mark).
Syntax | ControlObject.Checked = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the CheckBox Control Object that is returned by the AddCheckBox function.
Description | Sets the check box to selected (filled with a check mark) or clear.
Arguments | Value {Boolean} If set to True (1), the Check Box is selected automatically by default; if set to False (0) it is clear.
Returns | Boolean

Example:

CheckBox1.Checked = 1

Where:

  • CheckBox1 is the name of the variable that stores the CheckBox Control Object returned by the AddCheckBox function
  • 1 sets the Check Box to selected.


Scripting Guide - CheckBox.Text (Form and Control Object Functions and Properties)

CheckBox.Text

The CheckBox Control Object that is returned by the AddCheckBox function has a Text property. The Text property defines the text that is shown next to the check box.
Syntax | ControlObject.Text = Text Where ControlObject. is the name of the variable (declared in your script) that is used to store the CheckBox Control Object that is returned by the AddCheckBox function.
Description | Sets the string that is shown next to the check box. The text is shown to the right of the Check Box unless the LeftText property is set to True (in which case the text is shown to the left of the Check Box).
Arguments | Text {string}
Returns | String

Example:

CheckBox1.Text = "Show Disabled Points"

Where:

  • CheckBox1 is the name of the variable that stores the CheckBox Control Object returned by the AddCheckBox function
  • "Show Disabled Points" is the text shown next to the Check Box.


Scripting Guide - CheckBox.LeftText (Form and Control Object Functions and Properties)

CheckBox.LeftText

The CheckBox Control Object that is returned by the AddCheckBox function has a LeftText property. The LeftText property defines where the text that is shown next to the check box is displayed.
Syntax | ControlObject.LeftText = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the CheckBox Control Object that is returned by the AddCheckBox function.
Description | Sets the position of the text that is shown next to the Check Box.
Arguments | Value {Boolean} If set to True (1), the Check Box has its text shown to the left of the Check Box; if set to False (0), the text is shown to the right of the Check Box.
Returns | Boolean

Example:

CheckBox1.LeftText = "Show Disabled Points"

Where:

  • CheckBox1 is the name of the variable that stores the CheckBox Control Object returned by the AddCheckBox function
  • "Show Disabled Points" is the text shown to the left of the Check Box.


Scripting Guide - Radio Button Properties (Form and Control Object Functions and Properties)

Radio Button Properties

The RadioButton Control Object that is returned by the AddRadioButton function has the following properties:

  • RadioButton.Checked
  • RadioButton.Text
  • RadioButton.LeftText
  • X and Y
  • Visible
  • Disabled
  • Group.


Scripting Guide - RadioButton.Checked (Form and Control Object Functions and Properties)

RadioButton.Checked

The RadioButton Control Object that is returned by the AddRadioButton function has a Checked property. The Checked property defines whether the Radio Button is selected.
Syntax | ControlObject.Checked = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the RadioButton Control Object that is returned by the AddRadioButton function.
Description | Sets the RadioButton to be selected or de-selected.
Arguments | Value {Boolean} If set to True (1), the Radio Button is selected automatically by default; if set to False (0) it is de-selected.
Returns | Boolean

Example:

RadioButton1.Checked = 1

Where:

  • RadioButton1 is the name of the variable that stores the RadioButton Control Object returned by the AddRadioButton function
  • 1 sets the Radio Button to be selected.


Scripting Guide - RadioButton.Text (Form and Control Object Functions and Properties)

RadioButton.Text

The RadioButton Control Object that is returned by the AddRadioButton function has a Text property. The Text property defines the text that is shown next to the Radio Button.
Syntax | ControlObject.Text = Text Where ControlObject. is the name of the variable (declared in your script) that is used to store the Radio Button Control Object that is returned by the AddRadioButton function.
Description | Sets the string that is shown next to the Radio Button. The text is shown to the right of the Radio Button unless the LeftText property is set to True (in which case the text is shown to the left of the Radio Button).
Arguments | Text {string}
Returns | String

Example:

RadioButton1.Text = "Use Alternate Limits"

Where:

  • RadioButton1 is the name of the variable that stores the RadioButton Control Object returned by the AddRadioButton function
  • "Use Alternate Limits" is the text shown next to the Radio Button.


Scripting Guide - RadioButton.LeftText (Form and Control Object Functions and Properties)

RadioButton.LeftText

The RadioButton Control Object that is returned by the AddRadioButton function has a LeftText property. The LeftText property defines where the text that is shown next to the Radio Button is displayed.
Syntax | ControlObject.LeftText = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the Radio Button Control Object that is returned by the AddRadioButton function.
Description | Sets the position of the text that is shown next to the Radio Button.
Arguments | Value {Boolean} If set to True (1), the Radio Button has its text shown to the left of the Check Box; if set to False (0), the text is shown to the right of the Radio Button.
Returns | Boolean

Example:

RadioButton1.LeftText = "Use Alternate Limits"

Where:

  • RadioButton1 is the name of the variable that stores the RadioButton Control Object returned by the AddRadioButton function
  • "Use Alternate Limits" is the text shown to the left of the Radio Button.


Scripting Guide - Combo Box Functions (Form and Control Object Functions and Properties)

Combo Box Functions

The ComboBox Control Object that is returned by the AddComboBox function has the following functions:

  • ComboBox.Clear
  • ComboBox.Add
  • ComboBox.Insert
  • ComboBox.Delete

See Also:

Combo Box Properties


Scripting Guide - ComboBox.Clear (Form and Control Object Functions and Properties)

ComboBox.Clear

The ComboBox Control Object that is returned by the AddComboBox function has its own functions which include the Clear function. The Clear function removes any entries from the Combo Box.
Syntax | ControlObject.Clear() Where ControlObject. is the name of the variable (declared in your script) that is used to store the Combo Box Control Object that is returned by the AddComboBox function.
Description | Removes every entry from the Combo Box.
Arguments | None.
Returns | None.

Example:

ComboBox1.Clear()

Where:

  • ComboBox1 is the name of the variable that stores the ComboBox Control Object returned by the AddComboBox function
  • Clear() removes every entry from the combo box.


Scripting Guide - ComboBox.Add (Form and Control Object Functions and Properties)

ComboBox.Add

The ComboBox Control Object that is returned by the AddComboBox function has its own functions which include the Add function. The Add function adds a selectable option to the Combo Box.
Syntax | ControlObject.Add(Text) Where ControlObject. is the name of the variable (declared in your script) that is used to store the Combo Box Control Object that is returned by the AddComboBox function.
Description | Adds a selectable option to the Combo Box. The option you add is inserted at the bottom of the Combo Box's list. To add an option to a different location in the list, you need to use the Combo Box's Insert function (see ComboBox.Insert).
Arguments | Text {string} The text that is shown for the option in the Combo Box.
Returns | String

Example:

ComboBox1.Add("All Areas")

Where:

  • ComboBox1 is the name of the variable that stores the ComboBox Control Object returned by the AddComboBox function
  • "All Areas" is the name for the option being added.


Scripting Guide - ComboBox.Insert (Form and Control Object Functions and Properties)

ComboBox.Insert

The ComboBox Control Object that is returned by the AddComboBox function has its own functions which include the Insert function. The Insert function adds a selectable option to a specific position in the Combo Box's list.
Syntax | ControlObject.Insert(Index Number, Text) Where ControlObject. is the name of the variable (declared in your script) that is used to store the Combo Box Control Object that is returned by the AddComboBox function.
Description | Adds a selectable option to the Combo Box. The option is added at the position defined by the Index Number.
Arguments | Index Number {integer} A number that corresponds to the position of the option in the Combo Box list. 0 is at the top of the list and the other numbers follow in sequence, so that the highest number is at the bottom of the list. Text {string} The text that is shown for the option in the Combo Box.
Returns | Integer and String.

Example:

The following script is used to add a Combo Box to a Form:

Public Function ComboBoxForm
Dim frmComboBox
Dim pstrings (5)
pstrings(0) = "None"
pstrings(1) = "All Areas"
pstrings(2) = "Area 1"
pstrings(3) = "Area 2"
pstrings(4) = "Area 3"
pstrings(5) = "Area 4"
Form.Init "Verify Control Action"
Form.AddGroupBox 0,0,100,8,""
Set frmComboBox = Form.AddComboBox (15,25, pstrings)
frmComboBox.Insert 1, "Main Area"
frmComboBox.Insert 2,"Central Building"
Form.Show
End Function

The pstrings variable defines the default options for the Check Box. The numbers for the options define their position in the Combo Box list, with 0 being at the top of the list and the highest number (in this case, 5) at the bottom of the list.

The AddComboBox function is used to add the Combo Box to the Form. It is positioned at co-ordinates 15, 25 on the Form and references the pstrings variable for its list entries.

The Insert function is used to add 2 more options to the Combo Box list. The first option is named "Main Area" and has an index number of 1. This means it is placed below the existing list option that has index number 0, but above the other list entries.

The second option is named "Central Building" and has an index number of 2. This means it is placed below the entries with index numbers 0 and 1, but above the other entries.


Scripting Guide - ComboBox.Delete (Form and Control Object Functions and Properties)

ComboBox.Delete

The ComboBox.Delete function works in a similar way to the ComboBox.Insert function, except that it removes options from the list rather than inserts them.
Syntax | ControlObject.Delete(Index Number) Where Object is the name of the variable (declared in your script) that is used to store the Combo Box Control Object that is returned by the AddComboBox function.
Description | Removes a selectable option from the Combo Box. The Index Number defines which option is removed (its number corresponds to the position of an option in the list, with 0 being at the top and the highest number being at the bottom).
Arguments | Index Number {integer} A number that corresponds to the position of the option in the Combo Box list.
Returns | Integer

Example:

ComboBox1.Delete(4)

Where:

  • ComboBox1 is the name of the variable that stores the ComboBox Control Object returned by the AddComboBox function
  • 4 is the Index Number for the option that is being removed.


Scripting Guide - Combo Box Properties (Form and Control Object Functions and Properties)

Combo Box Properties

The ComboBox Control Object that is returned by the AddCombobox function has the following properties:

  • ComboBox.Selection
  • ComboBox.Sort
  • ComboBox.Count
  • X and Y
  • Visible
  • Disabled.

See Also:

Combo Box Functions.


Scripting Guide - ComboBox.Selection (Form and Control Object Functions and Properties)

ComboBox.Selection

The ComboBox Control Object that is returned by the AddComboBox function has a Selection property. The Selection property allows you to determine which Combo Box option is selected when the Form is closed. This information can then be used to determine the next course of action. For example, if the Combo Box options correspond to controls, the Selection property could be used in the script to determine which Control Object was selected, and therefore which Control Object needs to be executed.
Syntax | ControlObject.Selection Where ControlObject. is the name of the variable (declared in your script) that is used to store the Combo Box Control Object that is returned by the AddComboBox function.
Description | References the Index Number of the Combo Box option that is currently selected at the time the Form is closed.
Arguments | None.
Returns | Integer (the Index Number of the option that is selected when the Form is closed).

Example:

The following script is used to provide the functionality for an Override feature on a Mimic. When a Mimic object is selected, a Form is displayed that has an Override Combo Box. The Combo Box has 2 options—one overrides a point's value to 50, the other overrides the point's value to 80.

Public Function ComboBoxForm
Dim ObjAlarmValue
Dim frmComboBox
Dim pstrings (1)
Dim frmOKButton
Dim frmCancelButton
Dim frmStaticText
pstrings(0) = "Override to Normal"
pstrings(1) = "Override to High High"
Form.Init "Override AI1 Point"
Set frmStaticText = Form.AddStaticText (1,2,"Override AI1 Point")
Set frmComboBox = Form.AddComboBox (20,2, pstrings)
Set frmOKButton = Form.AddPushButton(60,5,"OK")
frmOKButton.Default = True
Set frmCancelButton = Form.AddPushButton(75,5,"Cancel")
Form.Show
If Form.Selection = "OK" Then
Select Case frmComboBox.Selection
Case 0
Set ObjAlarmValue = Server.FindObject(Server.GetOPCValue(".AI1.Fullname"))
ObjAlarmValue.Interface.Override 50

Case 1
Set ObjAlarmValue = Server.FindObject(Server.GetOPCValue(".AI1.Fullname"))
ObjAlarmValue.Interface.Override 80
End Select
End If
End Function

The Form is set to have a Combo Box, an OK button and a Cancel button. The Combo Box has 2 options, named "Override to Normal" and "Override to High High".

If the user selects the OK button, the script performs one of 2 actions, depending on which option is selected in the Combo Box.

If "Override to Normal" is selected (this is Case 0 as it has an Index Number of 0), the script performs an Override of 50 on the point named AI1. The Server.GetOPCValue function is used in conjunction with the Server.FindObject function—this is because the Server.FindObject function does not support relative references, but by using the Server.GetOPCValue function as well, you can use a relative reference (although this involves extra requests).

If "Override to High High" is selected (this is Case 1 as it has an Index Number of 1), the script performs an Override of 80 on the point named AI1.

If the user does not select the OK button, and closes the Form by selecting the Cancel button or the Close window icon, the script does not execute.


Scripting Guide - ComboBox.Sort (Form and Control Object Functions and Properties)

ComboBox.Sort

The ComboBox Control Object that is returned by the AddComboBox function has a Sort property. The Sort property allows the script to place the Combo Box list options in alphabetical order instead of the default Add or Insert orders.

When you use the ComboBox.Add function, the list option that you add is added to the bottom of the list. This means that the order of the list is defined by the order in which you add options to the list. If you use the ComboBox.Insert function, the list option you create is added to a specific place in the list and so you define the list order by specifying the positions of the options. With the ComboBox.Sort property, you can set a combo box to ignore the Add and Insert orders and apply sorting by alphabetical order of the list option names.
Syntax | ControlObject.Sort = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the Combo Box Control Object that is returned by the AddComboBox function.
Description | Re-orders the Check Box options into alphabetical order.
Arguments | Value {Boolean} If set to True (1), the Combo Box options are ordered alphabetically; if set to False (0), the Combo Box options are ordered according to when they were added (if the ComboBox.Add function was used) or in a user-defined order (if the ComboBox.Insert function was used).
Returns | Boolean

Example:

A script adds a Combo Box to a Form. The script does not make use of the Combo Box's Sort property, and so the Combo Box's 3 options are ordered according to the order in which they were created:

  • Display Alarms—This option is shown at the top of the list as it was the first option to be added.
  • Acknowledge Alarm—This option is shown next on the list as it was added after the Display Alarms option but before the Hand Control Point option.
  • Hand Control Point—This option is shown at the bottom of the list as is the latest list option to be added.

The script is altered so that the Combo Box list options are shown in alphabetical order:

ComboBox1.Sort = True

Where ComboBox1 is the variable that is used to store the ComboBox Control Object that is returned by the AddComboBox function, and True sets the Combo Box's options to be listed alphabetically.

When the Form is next displayed, the Combo Box options are displayed in alphabetical order:

  • Acknowledge Alarm
  • Display Alarms
  • Hand Control Point.


Scripting Guide - ComboBox.Count (Form and Control Object Functions and Properties)

ComboBox.Count

The ComboBox Control Object that is returned by the AddComboBox function has a Count property. The Count property returns a number that corresponds to the number of options in the Combo Box list.
Syntax | ControlObject.Count Where ControlObject. is the name of the variable (declared in your script) that is used to store the Combo Box Control Object that is returned by the AddComboBox function.
Description | Returns a numeric value that matches the total number of options in the Combo Box's list. The Count property is read only.
Arguments | None.
Returns | Integer (the total number of options in the Combo Box's list).

Example:

A Combo Box has 6 options. In the script, the following script is used to display a message box containing a count of the options:

MsgBox ComboBox1.Count

Where:

  • ComboBox1 is the name of the variable that is used to store the ComboBox Control Object that is returned by the AddComboBox function. When the script is executed, a message box is displayed containing the number 6 (the total number of options in the Combo Box's list).


Scripting Guide - List Box Functions (Form and Control Object Functions and Properties)

List Box Functions

The ListBox Control Object that is returned by the AddListBox function has the following functions:

  • ListBox.Clear
  • ListBox.Add
  • ListBox.Insert
  • ListBox.Delete
  • ListBox.IsSelected
  • ListBox.SetSelected.

See Also:

List Box Properties.


Scripting Guide - ListBox.Clear (Form and Control Object Functions and Properties)

ListBox.Clear

The ListBox Control Object that is returned by the AddListBox function has a Clear function. The Clear function can be used to remove the entries in the List Box.
Syntax | ControlObject.Clear Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Removes the entries from the List Box.
Arguments | None.
Returns | None.

Example:

ListBox.Clear()

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script).

This script removes the options from the List Box.


Scripting Guide - ListBox.Add (Form and Control Object Functions and Properties)

ListBox.Add

The ListBox Control Object that is returned by the AddListBox function has an Add function. The Add function can be used to add an entry to the List Box.
Syntax | ControlObject.Add(Text) Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Adds an option to the List Box. The option that is added is allocated the next Index Number, so if the last option in the List Box had 6 as its Index Number, the option that is added by the Insert function would be allocated an Index Number of 7.
Arguments | Text {string} The text that is shown for the option in the List Box.
Returns | String

Example:

ListBox.Add("Point Alg1")

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • "Point Alg1" is the name of the option that is being added to the List Box.


Scripting Guide - ListBox.Insert (Form and Control Object Functions and Properties)

ListBox.Insert

The ListBox Control Object that is returned by the AddListBox function has an Insert function. The Insert function can be used to add an entry to a specific position in the List Box.
Syntax | ControlObject.Insert (Index Number, Text) Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Adds an option to a specific position in the List Box. When you insert an option in a List Box, the options that appear below the new option in the list have their Index Numbers increased by 1. So, if you insert an option with an Index Number of 4, the option that previously had Index Number 4 will now have Index Number 5, the option that had Index Number 5 will have Index Number 6 and so on.
Arguments | Index Number {integer} A number that corresponds to the position of the option in the List Box (descending order with 0 at the top and the highest number at the bottom of the List Box). Text {string} The text that is shown for the option in the List Box.
Returns | Not applicable. The function does not return anything.

Example:

ListBox.Insert(2,"Point Alg1")

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • 2 is the Index Number for the inserted option,
  • "Point Alg1" is the name of the option.

This means that the option will be placed below the options that have Index Number 0 and 1, but above the options that have Index Numbers of 3 or higher.


Scripting Guide - ListBox.Delete (Form and Control Object Functions and Properties)

ListBox.Delete

The ListBox Control Object that is returned by the AddListBox function has a Delete function. The Delete function can be used to remove an entry from a specific position in the List Box.
Syntax | ControlObject.Delete (Index Number) Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Removes an option from a specific position in the List Box. When you delete an option in a List Box, the options that appear below the new option in the list have their Index Numbers reduced by 1. So, if you delete an option with an Index Number of 4, the option that previously had Index Number 5 will now have Index Number 4, the option that had Index Number 6 will have Index Number 5 and so on.
Arguments | Index Number {integer} A number that corresponds to the position of the option in the List Box (descending order with 0 at the top and the highest number at the bottom of the List Box).
Returns | Integer

Example:

ListBox.Delete(2)

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • 2 is the Index Number for the deleted option.

The option that was previously associated with Index Number 3 will be associated with Index Number 2 once the existing Index Number 2 option has been deleted.


Scripting Guide - ListBox.IsSelected (Form and Control Object Functions and Properties)

ListBox.IsSelected

The ListBox Control Object that is returned by the AddListBox function has an IsSelected function. The IsSelected function can be used to determine if specific entries are selected.
Syntax | ControlObject.IsSelected (Index Number) Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Use to determine whether an option is selected. The IsSelected function returns a Boolean value (True if the option is selected; False if the option is not selected).
Arguments | Index Number {integer} A number that corresponds to the position of the option in the List Box (descending order with 0 at the top and the highest number at the bottom of the List Box).
Returns | Boolean

Example:

The IsSelected function can be used with IF statements, so that an action can be performed if a specific option has been selected.

IF ListBox.IsSelected(2) THEN

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • 2 is the Index Number for the option being checked.

If option 2 is selected, the action that would be defined after THEN would be performed. If option 2 is not selected, another action would be performed (which would be defined after an ELSE function in the script).


Scripting Guide - ListBox.SetSelected (Form and Control Object Functions and Properties)

ListBox.SetSelected

The ListBox Control Object that is returned by the AddListBox function has a SetSelected function. The SetSelected function can be used to set specific entries to be selected by default when the Form is displayed.

Syntax

ControlObject.SetSelected (Index Number, Value)

Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.

Description

Use to set specific entries to be selected by default when the Form is displayed.

Arguments

Index Number {integer}

A number that corresponds to the position of the option in the List Box (descending order with 0 at the top and the highest number at the bottom of the List Box).

Value {Boolean}

If set to True (1), the selected option is set to be selected when the Form is displayed; if set to False (0), the selected option is not selected when the Form is displayed.

Returns

Not applicable. The function does not return anything.

Example:

ListBox.SetSelected(2,TRUE)

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • 2 is the Index Number for the option being set
  • TRUE is the boolean that sets the option to be selected by default when the Form is displayed.


Scripting Guide - List Box Properties (Form and Control Object Functions and Properties)

List Box Properties

The ListBox Control Object that is returned by the AddListBox function has the following properties:

  • ListBox.Selection
  • ListBox.Rows
  • ListBox.Columns
  • ListBox.Sort
  • ListBox.Multiple
  • ListBox.Count
  • X and Y
  • Visible
  • Disabled.

See Also:

List Box Functions


Scripting Guide - ListBox.Selection (Form and Control Object Functions and Properties)

ListBox.Selection

The ListBox Control Object that is returned by the AddListBox function has a Selection property. The Selection property can be used to return the Index Number of currently selected option in the List Box.
Syntax | ControlObject.Selection Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Returns the Index Number of the option that is currently selected when the Form is closed. The Selection property can only be used if the Multiple property is disabled (i.e. False). If the Multiple property is enabled, the IsSelected function can be used for each option to return the Index Numbers of the selected options.
Arguments | None.
Returns | Integer (the Index Number of the option that is selected when the Form is closed).

Example:

MsgBox ListBox.Selection

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • Selection is used to return the Index Number of the currently selected option. The Index Number is shown in the message box that is displayed when this part of the script is executed.


Scripting Guide - ListBox.Rows (Form and Control Object Functions and Properties)

ListBox.Rows

The ListBox Control Object that is returned by the AddListBox function has a Rows property. The Rows property allows you to define the number of rows in the List Box.
Syntax | ControlObject.Rows = Rows Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Sets the number of rows in the List Box.
Arguments | Rows {integer} Defines the number of rows for the List Box.
Returns | Integer

Example:

ListBox.Rows = 8

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • Rows = 8 sets the List Box to have 8 rows.


Scripting Guide - ListBox.Columns (Form and Control Object Functions and Properties)

ListBox.Columns

The ListBox Control Object that is returned by the AddListBox function has a Columns property. The Columns property allows you to define the number of columns in the List Box.
Syntax | ControlObject.Columns = Columns Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Sets the number of columns in the List Box.
Arguments | Columns {integer} Defines the number of columns for the List Box.
Returns | Integer

Example:

ListBox.Columns = 2

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • Columns = 2 sets the List Box to have 2 columns.


Scripting Guide - ListBox.Sort (Form and Control Object Functions and Properties)

ListBox.Sort

The ListBox Control Object that is returned by the AddListBox function has a Sort property. The Sort property allows you to sort the List Box options into alphabetical order.

Syntax

ControlObject.Sort = Value

Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.

Description

Re-orders the Check Box options into alphabetical order.

If the options are not reordered alphabetically, they are ordered according to when they were added or the positions in which they were inserted (by the ListBox.Add and ListBox.Insert functions respectively).

If the options are ordered alphabetically, the order in which the options were added and the positions in which they were inserted has no bearing on the order in the list—the list will be sorted by name in alphabetical order.

Arguments

Value {Boolean}

If set to True (1), options are sorted in alphabetical order; if set to False (0), the options are not sorted in alphabetical order (they are sorted according to the order in which they were added or in the positions in which they were inserted).

Returns

Boolean

Example:

A Form has a List Box with 8 options. The options were added by using the ListBox.Add function, and they were added in this order:

  • Drainage (added first)
  • None (added second)
  • All Areas (added third)
  • Corridor 16 (added fourth)
  • Corridor 11 (added fifth)
  • Boiler Room (added sixth)
  • Air Control (added seventh)
  • Canteen (added last)

The following script is used to set the options to be sorted alphabetically:

ListBox.Sort = True

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • Sort = True sets the List Box to be sorted in alphabetical order.
    The options are sorted in alphabetical order. The order in which they were added to the list has no bearing on the order of options any more.


Scripting Guide - ListBox.Multiple (Form and Control Object Functions and Properties)

ListBox.Multiple

The ListBox Control Object that is returned by the AddListBox function has a Multiple property. The Multiple property allows several of the List Box options to be selected simultaneously.
Syntax | ControlObject.Multiple = Value Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Determines whether the List Box can have multiple options selected simultaneously or is limited to a single selection. List Boxes are set to Multiple = False by default (so they can only have one option selected). If the Multiple property is set to True, the Selection property cannot be used.
Arguments | Value {Boolean} If set to True (1), more than one option can be selected; if set to False (0),only one option can be selected.
Returns | Boolean

Example:

ListBox.Multiple = True

Where:

  • ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script)
  • True sets the List Box to allow multiple options to be selected at one time.
    List Box with multiple options selected simultaneously


Scripting Guide - ListBox.Count (Form and Control Object Functions and Properties)

ListBox.Count

The ListBox Control Object that is returned by the AddListBox function has a Count property. The Count property returns the number of entries in the List Box.
Syntax | ControlObject.Count Where ControlObject. is the name of the variable (declared in your script) that is used to store the List Box Control Object that is returned by the AddListBox function.
Description | Allows the script to determine how many entries there are in the List Box (the number of options that the List Box contains).
Arguments | None.
Returns | Integer (the total number of entries in the List Box)

Example:

MsgBox.ListBox.Count

Where:

ListBox is the name of the variable used to store the List Box Control Object that is returned by the AddListBox function (which would be defined earlier in the script).

This script causes a message box to be displayed—the message box contains the number that is returned by the Count property.


Scripting Guide - DateTime Properties (Form and Control Object Functions and Properties)

DateTime Properties

The DateTime Control Object that is returned by the AddDateTime function has the following properties:

  • DateTime.Value
  • DateTime.Format
  • X and Y
  • Visible
  • Disabled.


Scripting Guide - DateTime.Value (Form and Control Object Functions and Properties)

DateTime.Value

The DateTime Control Object that is returned by the AddDateTime function has a Value property. The Value property can be used to set the time and date for the DateTime item on the Form.
Syntax | ControlObject.Value = Date/Time Where ControlObject. is the name of the variable (declared in your script) that is used to store the DateTime Control Object that is returned by the AddDateTime function.
Description | Sets the date and time for the DateTime item on the Form.
Arguments | Date/Time {string} The "Date/Time" value has to be in a valid time format (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).
Returns | String

Example:

DateTime1.Value = "25/06/2006"

Where:

  • DateTime1 is the name of the variable used to store the DateTime Control Object that is returned by the AddDateTime function (which would be defined earlier in the script)
  • "25/06/2006" sets the date to 25th June 2006.


Scripting Guide - DateTime.Format (Form and Control Object Functions and Properties)

DateTime.Format

The DateTime Control Object that is returned by the AddDateTime function has a Format property. The Format property can be used to define how Date and Time values are displayed.

Syntax

ControlObject.Format = DateTime Format

Where ControlObject. is the name of the variable (declared in your script) that is used to store the DateTime Control Object that is returned by the AddDateTime function.

Description

Use to define how Date and Time values are displayed.

Arguments

DateTime Format {string}

This string sets the date and time format and consists of a combination of the following characters:

  • d—day of month with no leading zero, for example, 4
  • dd—day of month with leading zero, for example, 04
  • EEE—abbreviated day of week, for example, MON
  • EEEE—day of week in full, for example, MONDAY
  • M—month with no leading zero, for example, 9 (for September)
  • MM—month with leading zero, for example, 09 (for September)
  • MMM—abbreviated month, for example, Apr
  • MMMM—month in full, for example, April
  • yy—2 digit year, for example, 06 (for 2006)
  • yyyy—year in full, for example, 2006
  • h—hour in 12 hour clock format without a leading zero
  • hh—hour in 12 hour clock format with a leading zero (where applicable)
  • H—hour in 24 hour clock format without a leading zero
  • HH—hour in 24 hour clock format with a leading zero (where applicable)
  • m—minutes with no leading zero
  • mm—minutes with leading zero (where applicable)
  • s—seconds with no leading zero
  • ss—seconds with leading zero (where applicable)
  • S—milliseconds
  • A—indicates whether the time is AM or PM.

Example:

DateTime1.Format = "d/MM/yyyy"

Where:

  • DateTime1 is the name of the variable used to store the DateTime Control Object that is returned by the AddDateTime function (which would be defined earlier in the script)
  • "d/MM/yyyy" sets the date to be displayed as day of month with no leading zero, then month with leading zero, then a four digit year, for example, "5/06/2006" sets the date to 5th June 2006.


Scripting Guide - Query Functions (Form and Control Object Functions and Properties)

Query Functions

The Query Control Object has the following functions:

  • Query.SetParamControl.


Scripting Guide - Query.SetParamControl (Form and Control Object Functions and Properties)

Query.SetParamControl

The Query.SetParamControl function allows the script to define the values for the query parameters (where applicable).

Syntax

Query.SetParamControl (<Parameter Number>, <Parameter Value Source>)

Description

Defines the value for any required parameters.

Arguments

<Parameter Number> {integer}

The Parameter Number is the Index number of the parameter. 0 is the first parameter, 1 is the second parameter, 2 is the third parameter and so on. Do not enter the angle brackets <>.

<Parameter Value Source> {Control}

The Parameter Value Source references the control on the Form that is the source of the value for the parameter.

Returns

None

Example:

In the following excerpt from a script, the SetParamControl function is used to set the first parameter (parameter 0) to the value provided by the E variable (the entry entered into the edit box that is represented by E in the script).

Dim E
Set E = Form.AddEditBox( 1, 1, 150 )
Dim Query
Set Query = Form.AddQuery( 1, 3, 150, 20, "SELECT Name, TypeDesc FROM CDBObject WHERE Name LIKE ? || '%'" )
Query.SetParamControl 0, E

NOTE: If the parameter is a boolean, the control for the parameter has to be a check box control. Similarly, if the parameter is a date/time value, the control for the parameter has to be a date/time control.


Scripting Guide - Query.Value (Form and Control Object Functions and Properties)

Query.Value

The Query.Value function allows the script to access a particular value in the result set of the SQL query. The script can access the values in any row and any column (the columns correspond to the categories listed after SELECT in the query).

Syntax

Query.Value (<Row Number>, <Column Number>)

Description

Returns the value from the specified row and column in the SQL query result set.

Arguments

<Row Number> {integer}

The Row Number is the number of the row in the list that contains the value to be returned. 0 is the first row, 1 is the second row, 3 is the third row and so on. Do not enter the angle brackets <>.

<Column Number> {integer}

The Column Number is the number of the column in the list that contains the value to be returned. 0 is the first column, 1 is the second column, 2 is the third column and so on. The first column is the first category that is listed after SELECT in the SQL Query, for example, if the SQL Query contains SELECT Name, TypeDesc, then Name is the first column and is numbered 0. TypeDesc is the second column and is numbered 1.

Do not enter the angle brackets < >.

Returns

Variable. The value in the defined row and column.

Example:

A script returns the following resultset which is displayed in a Queries List box:

To access the third value in the Type column, the script has to contain the following:

Query.Value (2,1)

As 2 is the third row (the row numbers begin at 0) and 1 is the second column. This is because the column numbers also begin at 0, and 0 is the column on the left-hand side of the list box.

This would return the third value in the Type column which is 'Group'.


Scripting Guide - Query Properties (Form and Control Object Functions and Properties)

Query Properties

The Query Control Object that is returned by the AddQuery function has the following properties:

  • Query.Width
  • Query.Height
  • Query.Query
  • Query.SelectedRow

It also has common Control Object Properties.


Scripting Guide - Query.Width (Form and Control Object Functions and Properties)

Query.Width

The Query Control Object that is returned by the AddQuery function has a Width property. The Width property represents the width setting of the Queries List box.
Syntax | ControlObject.Width = Value Where ControlObject is the name of the variable (declared in your script) that is used to store the Query Control Object that is returned by the AddQuery function.
Description | Sets the width of the Queries List box.
Arguments | Value {integer} Defines the width setting of the Queries List box. This is based on the average character width, so 1 is approximately 1 character wide.
Returns | Integer

Example:

Query1.Width = 100

Where:

  • Query1 is the name of the variable that stores the Query Control Object returned by the AddQuery function
  • 100 is the width setting for the Queries List (100 characters wide).


Scripting Guide - Query.Height (Form and Control Object Functions and Properties)

Query.Height

The Query Control Object that is returned by the AddQuery function has a Height property. The Height property represents the height setting of the Queries List box.
Syntax | ControlObject.Height = Value Where ControlObject is the name of the variable (declared in your script) that is used to store the Query Control Object that is returned by the AddQuery function.
Description | Sets the height of the Queries List box.
Arguments | Value {integer} Defines the height setting of the Queries List box. This is based on the average character width, so 1 is approximately 1 character wide.
Returns | Integer

Example:

Query1.Height = 80

Where:

  • Query1 is the name of the variable that stores the Query Control Object returned by the AddQuery function
  • 80 is the height setting for the Queries List (approximately 80 characters high).


Scripting Guide - Query.Query (Form and Control Object Functions and Properties)

Query.Query

The Query Control Object that is returned by the AddQuery function has a Query property. The Query property represents the SQL Query that is used to retrieve data from the database.
Syntax | ControlObject.Query = "SQL Query" Where ControlObject is the name of the variable (declared in your script) that is used to store the Query Control Object that is returned by the AddQuery function.
Description | Defines the SQL Query code that is used to retrieve data from the database.
Arguments | <SQL Query> {string} <SQL Query> represents the SQL code that is used to retrieve data from the database. The SQL code has to be entered as a string (enclosed in double quotes) and has to use the correct SQL syntax. You need a good understanding of SQL to use this function effectively. Do not enter the angle brackets < >.
Returns | None.

Example:

Query1.Query ="SELECT Name, TypeDesc FROM CDBObject"

Where:

  • Query1 is the name of the variable that stores the Query Control Object returned by the AddQuery function
  • "SELECT Name, TypeDesc FROM CDBObject" is the SQL Query that is used to retrieve data from the database. In this case, it retrieves the names of the items in the CDBObject class


Scripting Guide - Query.SelectedRow (Form and Control Object Functions and Properties)

Query.SelectedRow

The Query Control Object that is returned by the AddQuery function has a SelectedRow property. The SelectedRow property represents the currently selected row in the Queries List box.
Syntax | ControlObject.SelectedRow = <index number> Where ControlObject is the name of the variable (declared in your script) that is used to store the Query Control Object that is returned by the AddQuery function.
Description | Represents the currently selected row on the Queries List box. Typically, the SelectedRow value is used as an input for another function.
Arguments | <Index Number> The number of the list item that is currently selected. If no item is selected in the list, the Index Number is -1. The first item in the list has the Index Number of 0, the second an Index Number of 1, the third an Index Number of 2 and so on. Do not enter the angle brackets < >.
Returns | None.

Example:

In this extract from a script, the SelectedRow property is used to determine what is displayed in a message box. If the SelectedRow property has a value of -1, it means there are no items in the Queries List box currently selected and so the message box contains the message "No row selected". If the SelectedRow property contains any other value, the message box displays a message stating the name and type of the selected item.

If Q.SelectedRow = -1 Then
MsgBox "No row selected"
Else
Dim Name, TypeDesc
Name = Q.Value( Q.SelectedRow, 0 )
TypeDesc = Q.Value( Q.SelectedRow, 1 )
MsgBox "You clicked on " & Name & " which is a " & TypeDesc
End If


Scripting Guide - Slider Properties (Form and Control Object Functions and Properties)

Slider Properties

The Slider Control Object that is returned by the AddSlider function has the following properties:

  • Slider.Value
  • Slider.Minimum
  • Slider.Maximum
  • Slider.TickFrequency
  • Slider.Width


Scripting Guide - Slider.Value (Form and Control Object Functions and Properties)

Slider.Value

The Slider.Value property can be used to set the initial value for the slider when it is first displayed.
Syntax | Slider.Value = InitialValue
Description | Sets the slider to a defined value when it is first displayed.
Arguments | InitialValue {integer}. A value within the Minimum to Maximum range (defined by the Slider.Minimum and Slider.Maximum properties).
Returns | None.

Example:

Slider.Value = 50

This sets the slider to be positioned at 50 when it is first displayed (in this example, the minimum value is 0 and the maximum value is 100, so the slider is positioned in the center.


Scripting Guide - Slider.Minimum (Form and Control Object Functions and Properties)

Slider.Minimum

The Slider.Minimum property is used to set the lowest value for the slider.
Syntax | Slider.Minimum = LowestValue
Description | Defines the lowest value on the slider.
Arguments | LowestValue {integer}. Defines the lowest value that can be selected on the slider.
Returns | None.

Example:

Slider.Minimum = 10

This sets the slider range so that it begins at 10. There are no slider positions lower than 10.


Scripting Guide - Slider.Maximum (Form and Control Object Functions and Properties)

Slider.Maximum

The Slider.Maximum property is used to set the highest value for the slider.
Syntax | Slider.Maximum = HighestValue
Description | Defines the highest value on the slider.
Arguments | HighestValue {integer}. Defines the highest value that can be selected on the slider.
Returns | None.

Example:

Slider.Maximum = 250

This sets the slider range so that it ends at 250. There are no slider positions higher than 250.


Scripting Guide - Slider.TickFrequency (Form and Control Object Functions and Properties)

Slider.TickFrequency

The Slider.TickFrequency property is used to define the number of ticks on the slider.
Syntax | Slider.TickFrequency = TickValue
Description | Defines the frequency of ticks on the slider.
Arguments | TickValue {integer}. Defines the frequency of ticks on the slider. For example, if the Minimum is 0 and the Maximum is 100 and you set the TickValue to 10, the entire range of values for the slider is divided into 10 sections, with each section marked by a tick.
Returns | None.

Example:

Slider.Minimum = 0
Slider.Maximum = 100
Slider.TickFrequency = 10

This sets the slider range so that it begins at 0 and ends at 100. The entire range is divided into 10 sections with each section marked by a tick.

Ticks


Scripting Guide - Slider.Width (Form and Control Object Functions and Properties)

Slider.Width

The Slider Control Object that is returned by the AddSlider function has a Width property. The Width property represents the width setting of the Slider
Syntax | ControlObject.Width = Value Where ControlObject is the name of the variable (declared in your script) that is used to store the Slider Control Object that is returned by the AddSlider function.
Description | Sets the width of the Slider.
Arguments | Value {integer} Defines the width setting of the Slider. This is based on the average character width, so 1 is approximately 1 character wide.
Returns | Integer

Example:

Slider.Width = 150

Where:

  • Slider is the name of the variable that stores the Slider Control Object returned by the AddSlider function
  • 150 is the width setting for the slider (approximately 150 characters wide).


Scripting Guide - Mimic Functions and Properties

Mimic Functions and Properties

Mimic functions and properties allow you to create scripts that access Mimic features including navigation and Layers. Specifically designed for use in Mimic scripts, the Mimic functions and features cannot be used in Alarm Banner scripts.

To access the Mimic functions and properties, there are two types of object that you can reference in your script:

  • Mimic—This object allows you to access the functions and properties of the Mimic that contains the script.
  • TopMimic—Designed for use with Mimics that contain embedded Mimics, this object allows you to access the functions and properties of the top-level Mimic. A top-level Mimic is the Mimic database item that is currently on display (and it may contain embedded Mimics).

For example, let’s say a user displays a Mimic named ‘Site Overview’ and this Mimic contains an embedded Mimic. The ‘Site Overview’ Mimic does not have a script, but the embedded Mimic does. In the script, the code references both the TopMimic object and the Mimic object. The references to the TopMimic object are used to access the functions and properties of the top-level Mimic that is displayed i.e. the ‘Site Overview’ Mimic. The references to the Mimic object are used to access the functions and properties of the Mimic that contains the script i.e. the embedded Mimic.

The embedded Mimic contains a script that references both the TopMimic object and the Mimic object. The references to the TopMimic object access the properties and functions of the Site Overview Mimic as this is the top-level Mimic that is on display. The references to the Mimic object access the properties and functions of the embedded Mimic (as the embedded Mimic is the Mimic that contains the script).
The ‘Site Overview’ Mimic is the top-level Mimic (the Mimic that is displayed). It contains an embedded Mimic.
Embedded Mimic

If a Mimic contains embedded Mimics within embedded Mimics, the TopMimic object relates to the Mimic database item that is on display (i.e. the Mimic that contains the embedded Mimics).

An embedded Mimic named ‘High Values’ that contains another embedded Mimic (named ‘Pump A’).
Top-level Mimic named ‘Flow’.
The embedded ‘High Values’ Mimic does not contain a script. However, the ‘Pump A’ Mimic that is embedded within the ‘High Values’ Mimic does have a running script. In the script, the TopMimic object is referenced. The TopMimic reference applies to the top-level Mimic that is on display. So in this case, TopMimic is a reference to the 'Flow' Mimic and not the 'Pump A' Mimic that contains the script. The script can use the functions of the 'Flow' Mimic, as that is the top-level Mimic (it contains the other Mimics).

If you are creating a script for a Mimic that has no embedded Mimics, the TopMimic and Mimic objects will work in exactly the same way (as the top level Mimic and the Mimic containing the script are one and the same).

For information on the various Mimic and TopMimic functions and properties, see:

  • Mimic Functions
  • Mimic.Close
  • Mimic.GoBack
  • Mimic.GoForward
  • Mimic.Print
  • Mimic.Navigate
  • Mimic.OpenInset.
  • Mimic Properties
  • Mimic.BackColour
  • Mimic.SystemName
  • Mimic.Layers
  • Animation Properties for Mimic Items on Layers
  • Mimic.Parameters.
  • TopMimic Functions
  • TopMimic Properties.


Scripting Guide - Mimic Functions (Mimic Functions and Properties)

Mimic Functions

The Mimic functions that you can use in your Mimic scripts allow you to utilize the print feature of Mimics as well as some navigation features, including Go Back and Go Forward.

The Mimic functions that you can use are:

  • Mimic.Close
  • Mimic.GoBack
  • Mimic.GoForward
  • Mimic.Print
  • Mimic.Navigate
  • Mimic.OpenInset.

Each Mimic function references a Mimic object. So, in your script, you need to use the following format to reference a Mimic function:

Mimic.<function name>


Scripting Guide - Mimic.Close (Mimic Functions and Properties)

Mimic.Close

The Mimic.Close function allows a script to close the Mimic display on which the script is running.
Syntax | Mimic.Close()
Description | Closes the Mimic display on which the script is running.
Arguments | None
Returns | None

Example:

Mimic.Close

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Scripting Guide - Mimic.GoBack (Mimic Functions and Properties)

Mimic.GoBack

The Mimic.GoBack function allows the script to navigate from a Mimic to the previous display. This only applies to Mimics that are in a 'chain'.
Syntax | Mimic.GoBack()
Description | Naviagtes from a Mimic back to the previous Mimic in the sequence.
Arguments | None
Returns | None

NOTE: The script has no effect if the current Mimic is not part of a 'chain' of Mimics. The previous Mimic can only be shown if there is a sequence (the sequence is created when hyperlinks to other Mimics are selected on a Mimic).

For an example, see Go to Previous Mimic in Sequence.


Scripting Guide - Mimic.GoForward (Mimic Functions and Properties)

Mimic.GoForward

The Mimic.GoForward function allows the script to navigate from a Mimic to the next display. This only applies to Mimics that are in a 'chain'.
Syntax | Mimic.GoForward()
Description | Naviagtes from a Mimic forward to the next Mimic in the sequence.
Arguments | None
Returns | None

NOTE: The script has no effect if the current Mimic is not part of a 'chain' of Mimics. The next Mimic can only be shown if there is a sequence (the sequence is created when hyperlinks to other Mimics are selected on a Mimic).

For an example, see Go to Next Mimic in Sequence.


Scripting Guide - Mimic.Print (Mimic Functions and Properties)

Mimic.Print

The Mimic.Print function allows the script to print the Mimic on which the script is running.
Syntax | Mimic.Print()
Description | Prints the Mimic on which the script is running.
Arguments | None
Returns | None


Scripting Guide - Mimic.Navigate (Mimic Functions and Properties)

Mimic.Navigate

The Mimic.Navigate function allows the script to open a defined display in the current window
Syntax | Mimic.Navigate(URL)
Description | Opens a defined display in the current window.
Arguments | URL {string} The address of the display that is to be opened. The URL has to use the ClearSCADA address format.
Returns | String

Example:

Mimic.Navigate("SCX:////CMimic/Overview Mimic")

When run, this script causes a Mimic named 'Overview Mimic' to be displayed in the current window, replacing the Mimic that contained the script.

For more information, see Hyperlink to Another Display.

NOTE: Take care not to confuse the Mimic.Navigate function (which is a function of the Mimic object) with the Mimic_Navigate function. The Mimic_Navigate function is an event handler function and varies according to the language in which you are coding.


Scripting Guide - Mimic.OpenInset (Mimic Functions and Properties)

Mimic.OpenInset

The Mimic.OpenInset function allows the script to open a defined display in a new window. The new window is set to be a specific size.

Syntax

Mimic.OpenInset(URL, X, Y, W, H)

Description

Opens a defined display in a new window.

Arguments

URL {string}

The address of the display that is to be opened. The URL has to use the ClearSCADA address format.

X {integer}

Represents the horizontal position of the new window—the position on the 'X-Axis' at which the window begins. The number represents a percentage of the original Mimic's X co-ordinate.

Y {integer}

Represents the vertical position of the new window—the position on the 'Y-Axis' at which the window begins. The number represents a percentage of the original Mimic's Y co-ordinate.

Width {integer}

Defines the width of the new window. The number represents a percentage of the original Mimic's width.

Height {integer}

Defines the height of the new window.The number represents a percentage of the original Mimic's height.

Example:

Mimic.OpenInset "SCX:////CMimic/OverView", 20, 20, 20, 20

When the Mimic object that is associated with this script is selected, a new window will be displayed. The window will be inset at co-ordinates 20, 20. The co-ordinates are calculated as a percentage of the original Mimic's co-ordinates, with the top-left corner of the original Mimic being 0,0. So an X co-ordinate of 20 will be the original Mimic's X co-ordinate + 20% i.e indented from the left of the original Mimic by 20%. The Y co-ordinate will be the original Mimic's Y co-ordinate -20% i.e lower than the original Mimic by 20%.

The height and width will be 20% of the height and width of the original Mimic.

The original Mimic is the Mimic that contains the script.

For more information, see Show Another Display in an Inset Window.


Scripting Guide - Mimic Properties (Mimic Functions and Properties)

Mimic Properties

The Mimic Object has the following properties:

  • Mimic.BackColour
  • Mimic.SystemName
  • Mimic.Layers. The Mimic.Layers property provides access to the animation properties of any Mimic item. For many Mimic items, these properties correspond to the entries for that item on the Animation window, but there are a few exceptions—see Animation Properties for Mimic Items on Layers.
  • Mimic.Parameters
  • Mimic.FullName.

It also has the following Control Object properties which are normally associated with the Control Objects returned by Form functions and properties:

  • X and Y
  • Visible
  • Disabled.

See Also:

Mimic Functions.


Scripting Guide - Mimic.BackColour (Mimic Functions and Properties)

Mimic.BackColour

The Mimic.BackColour property can be used to set the background color of the Mimic that contains the script.
Syntax | Mimic.BackColour = Color Value
Description | Sets the background color of the Mimic on which the script is running.
Arguments | Color Value {RGB}. A Red, Green, Blue color value in the format: RGB(Red value, Green value, Blue value). Other color values, such as hexadecimal color values can be used, but we recommend RGB values.
Returns | RGB

Example:

Mimic.BackColour = RGB(255,0,0)

This sets the background color of the Mimic to red (red value is 255, green and blue values are 0).

NOTE: The Mimic.Backcolour property does not apply to embedded Mimics.


Scripting Guide - Mimic.SystemName (Mimic Functions and Properties)

Mimic.SystemName

The Mimic.SystemName property returns the system name associated with the host of the Mimic script.
Syntax | Mimic.SystemName
Description | Returns the system name of the system on which the Mimic that contains the script is running.
Arguments | None.
Returns | String

Example:

MsgBox "Mimic System = " + Mimic.SystemName

This returns the name of the system and displays it in a message box.

NOTE: The SystemName property is read-only.


Scripting Guide - Mimic.Layers (Mimic Functions and Properties)

Mimic.Layers

The Mimic.Layers property can be used to allow a script to access the Layers on a Mimic. By using the Mimic.Layers property, you can access the individual properties of each Layer, which include the properties of each item on that Layer. You can also use a For Each In statement to iterate around a collection of Layers.

Syntax

For accessing the Visibility property of a Layer, the syntax is:

Mimic.Layers (Layer Name or Index Number).Layer Property

If the Layers property is being used to access the properties of an item on the Mimic Layer, such as the properties of a shape, the syntax is:

Mimic.Layers (Layer Name or Index Number).Item("Item Name").Object Property

The Object Property is the name of one of the item's animation properties, for example, Text is the name of an animation property for a text box item. You can access any animation properties for an item in this way, and some items have additional properties that you can access see Animation Properties for Mimic Items on Layers.

Description

Provides access to the properties of the Layers on the Mimic that contains the script. It can also be used to access the properties of the Mimic objects on the Layers.

Arguments

Layer Name {string}

This has to match the name given to the Layer during its configuration.

Index Number {integer}

This value is allocated to the Layer automatically. The number of a Layer corresponds to its position in the list on the Layers window. The Layer at the top of the list has Index Number 0, and the other Layers are ordered decrementally i.e. the next Layer in the list has Index Number 1, the next Layer has Index Number 2 and so on.

Layer Property {string}

The name of the Layer property that the script is to reference. Each Layer has a Visibility property and an Items property. The Visibility property determines whether the Layer can be seen (True = visible; False = hidden), and the Items property is used to access the properties of individual shapes, text boxes etc. on the Mimic Layer.

Item {string}

The Item property provides access to the properties of individual objects on a Layer, for example, the properties of a shape.

Item Name {string}

This value has to match the name of the object's property. You cannot reference a property of a Mimic object by Index Number.

Object Property {string}

The name of the Mimic object property that the script is to reference. Each Mimic object has its own properties. The properties that are available for use in a script are the same as those that are available for use in animations (see Animations in the ClearSCADA Guide to Mimics).

Returns

Variant. The value that is returned is dependent on the type of property being accessed.

Example:

In this example, the Mimic.Layers property is used to access the Visibility property of each Layer. This allows the script to hide and show the different Layers. In this case, the script shows or hides a Layer depending on whether an appropriate button is selected.

Selecting the buttons toggles the Layers.

The Mimic has the following Layers:

  • Front—Contains the buttons and the title. Each button is associated with a script pick action.
  • Tank1—Contains the tank image and point value on the left.
  • Tank2—Contains the tank image and point value in the middle.
  • Tank3—Contains the tank image and point value on the right.
  • Back—Contains the background object (in this case, a white rectangle).

The following script is used to provide the hide/show functionality:

Sub ToggleLayer1
If Mimic.Layers(1).Visible = True Then
Mimic.Layers(1).Visible = False
Else
Mimic.Layers(1).Visible = True
End If
End Sub
Sub ToggleLayer2
If Mimic.Layers(2).Visible = True Then
Mimic.Layers(2).Visible = False
Else
Mimic.Layers(2).Visible = True
End If
End Sub
Sub ToggleLayer3
If Mimic.Layers(3).Visible = True Then
Mimic.Layers(3).Visible = False
Else
Mimic.Layers(3).Visible = True
End If
End Sub

The first sub routine is named ToggleLayer1 and it references Layer 1's Visible property:

If Mimic.Layers(1).Visible = True Then
Mimic.Layers(1).Visible = False
Else
Mimic.Layers(1).Visible = True
End If

The Layer is being referenced by its Index Number, in this case, 1. The Index Number corresponds to the Layers position on the Layers window, with the Layer at the top of the list having Index Number 0, and the other numbers being allocated in descending order, so the next Layer on the list has Index Number 1, the next Layer Index Number 2 and so on. Alternatively, the Layers can be referenced by name, with the name being entered as a string, for example:

Mimic.Layers("Tank1"). Visible = True

The script defines that if Layer 1's Visible property is True i.e. Layer 1 is currently on display, the script will change the Visible property to False when executed (hide the Layer). If Layer 1's Visible property is False, the script will change the Visible property to True so that Layer 1 is displayed.

The button on the left ('Show Tank 1') is associated with the ToggleLayer1 sub routine. This means that when the button is selected, it will toggle the visibility of the Tank1 Layer (hide/show the tank image and point value on the left).

The ToggleLayer2 and ToggleLayer3 sub routines work in the same way as the ToggleLayer1 sub routine, except that they toggle the middle tank image and point value and the right tank image and point value respectively. The middle button ('Show Tank 2') is associated with the ToggleLayer2 sub routine and the right button ('Show Tank 3') is associated with the ToggleLayer3 sub routine.

So, when the 'Show Tank 1' button is selected, it toggles the visibility of the 'Tank1' Layer, when the 'Show Tank 2' button is selected, it toggles the visibility of the 'Tank2' Layer, and when the 'Show Tank 3' button is selected, it toggles the visibility of the 'Tank3' Layer.

Selecting the 'Show Tank 2' button runs the 'ToggleLayer2' sub routine. This shows or hides the 'Tank2' Layer (which has Index Number 2) depending on whether the layer is already displayed/hidden.

Animation Properties for Mimic Items on Layers

When using the Mimic.Layers property, you can access any of the animation properties for any Mimic item on that Layer. The properties are the same as the properties that are shown on the Animations window for that item. For example, a Remote Image item has Alignment, PickComment, PickDisabled, PickParam, PickType, PosAnchor, PosMax, PosMin, PosVal, RefreshRate, TooltipText, Url, and Visible.

There are also some additional properties that you can access which are not shown on the Animations window. These include:

  • X1, Y1, X2, and Y2—Available on every Mimic item, the X1, X2, Y1, and Y2 properties represent the co-ordinates of the item on the Mimic. X1 is the horizontal position (X-Axis) of the top left of the item, X2 is the horizontal position of the bottom right of the item, Y1 is the vertical position (Y-Axis) of the top left of the item, and Y2 is the vertical position of the bottom right of the item. These properties are read only.
  • CurrentColIdx—This animation property is only available for embedded Queries Lists on Mimics. An animation for the CurrentColldx property returns the index number of the last selected column (0 is the first column from the left, 1 is the next column to the right, 3 the next column to the right and so on). If -1 is returned, it means that a column was not previously selected.
  • CurrentRowIdx—This animation property is only available for embedded Queries Lists and embedded Alarms Lists on Mimics. An animation for the CurrentRowIdx property returns the index number of the currently selected row (0 is the top row, 1 is the next row down, 2 the next row down and so on). If -1 is returned, it means that there is no row currently selected.
  • CurrentRowId—This animation property is only available for embedded Queries Lists on Mimics. An animation for the CurrentRowId property returns the ID of the database item represented by the currently selected row. If -1 is returned, it means that there is no row currently selected or the ID for the relevant database item is unavailable.
  • CurrentRowName—This animation property is only available for embedded Queries Lists on Mimics. An animation for the CurrentRowName property returns the name of the database item represented by the currently selected row. If nothing is returned, it means that there is no row currently selected.
  • CurrentRowSource—This animation property is only available for embedded Alarms Lists on Mimics. An animation for the CurrentRowSource property returns the source of the alarm represented by the currently selected row. Typically, the source is the name of a database item. If nothing is returned, it means that there is no row currently selected.

For more information on the properties on the Animations window, see Using the Animations Window in the ClearSCADA Guide to Mimics.


Scripting Guide - Mimic.Parameters (Mimic Functions and Properties)

Mimic.Parameters

The Mimic.Parameters property can be used to access the parameters of the Mimic that is running the script.

When the Mimic.Parameters property is used, the parameters can only be read by the script.
Syntax | Mimic.Parameters.Parameter Name
Description | Provides access to the parameters for the Mimic on which the script is running.
Arguments | Parameter Name {string} The name of the parameter that you want to access.
Returns | Variant. The value that is returned is dependent on the type of parameter being accessed.

Example:

A Mimic contains 2 embedded Mimics. The embedded Mimics represent a dial and have the following configuration:

Value field
Dial display
Parameter Details button
Value line

The Mimic has these parameters:

  • CurrentValue—Sets the Mimic to display the CurrentValue property of the database item that is associated with the parameter.
  • FullScale—Sets the Mimic to display the FullScale property of the analog point that is associated with the parameter. This is the point's maximum value.
  • Name—Sets the Mimic to display the Name property of the database item that is associated with the parameter.
  • ObjectLink—Sets the Mimic to link to the pick action menu of the database item that is associated with the parameter.
  • ZeroScale—Sets the Mimic to display the ZeroScale property of the analog point that is associated with the parameter. This is the point's minimum value.

The Value line on the Mimic has the following animations:

  • PivotType—4
  • Rotation—("Parameter:Point.CurrentValue" / ("Parameter:Point.FullScale" - "Parameter:Point.ZeroScale")) * 90

This sets the line to rotate according to the current value of the database item that is associated with the parameter. The angle of rotation is calculated based on the database item's FullScale, CurrentValue, and ZeroScale values.

The Value field has the following animations in place:

  • PickParam—"Parameter:Point.ObjectLink"
  • PickType—1
  • Value—"Parameter:Point.Name" + ': ' + STR("Parameter:Point.CurrentValue")

These animations set the value field to provide access to the pick action menu for the item associated with the Point parameter, and to also display the name and current value of the

The Value field is linked to the CurrentValue, Name, and ObjectLink parameters.

The 'Parameter Details' button is associated with a script pick action. The script for the pick action is:

Sub ParameterTest
Set test = Mimic.Parameters
Form.Init("Parameter Details..")
Form.AddStaticText 2, 1, "Parameter"
Form.AddStaticText 20, 1, "Value"
Form.AddStaticText 2, 2, "-------------"
Form.AddStaticText 20, 2, "-------"
Form.AddStaticText 2, 3, "Full Scale"
If test.Point.FullScale = "" Then
Form.AddStaticText 20, 3, "<blank>"
Else
Form.AddStaticText 20, 3, test.Point.FullScale
End If
Form.AddStaticText 2, 4, "Zero Scale"
If test.Point.ZeroScale = "" Then
Form.AddStaticText 20, 4, "<blank>"
Else
Form.AddStaticText 20, 4, test.Point.ZeroScale
End If
Form.AddStaticText 2, 5, "Current Value"
If test.Point.CurrentValue = "" Then
Form.AddStaticText 20, 5, "<blank>"
Else
Form.AddStaticText 20, 5, test.Point.CurrentValue
End If
Form.AddStaticText 2, 6, "Name"
If test.Point.Name = "" Then
Form.AddStaticText 20, 6, "<blank>"
Else
Form.AddStaticText 20, 6, test.Point.Name
End If
Form.AddStaticText 2, 7, "Object Link"
If test.Point.ObjectLink = "" Then
Form.AddStaticText 20, 7, "<blank>"
Else
Form.AddStaticText 20, 7, test.Point.ObjectLink
End If
Set button = Form.AddPushButton(10, 10, "Ok")
Form.Show()
End Sub

The script sets the 'Parameter Details' button to display a Form when selected. The Form references the parameters for the Mimic, for example, the point.ZeroScale parameter. When the 'Parameter Details' button is selected in Run Mode, it will display a Form that shows the FullScale, ZeroScale, Name, CurrentValue, and ObjectLink address of the database item that is associated with the Mimic.

The Mimic is saved and is then embedded twice on a Mimic named 'Meters'. The first embedded version of the Mimic is associated with an analog point named 'Point 1' and the second embedded version of the Mimic is associated with a point named 'Point 2'.

The value lines on the embedded Mimics are rotated according to the values of 'Point 1' and 'Point 2' respectively. Similarly, the Value fields show the Name and CurrentValue values for 'Point 1' and 'Point 2'.

When the 'Parameter Details' button for the first version of the embedded Mimic (the embedded Mimic associated with 'Point 1') is selected, a Form is displayed. The Form shows the FullScale, ZeroScale, Name, CurrentValue, and ObjectLink address of the 'Point 1' point.

Similarly, when the 'Parameter Details' button for 'Point 2' is selected, a Form is displayed containing the FullScale, ZeroScale, Name, CurrentValue, and ObjectLink address of the 'Point 2' point.


Scripting Guide - Mimic.FullName (Mimic Functions and Properties)

Mimic.FullName

The Mimic.FullName property returns the full name of the Mimic that contains the script
Syntax | Mimic.FullName
Description | Returns the full name of the Mimic that contains the script that is running.
Arguments | None.
Returns | String

Example:

MsgBox "Mimic Name = " + Mimic.FullName

This returns the name of the Mimic that contains the script and displays it in a message box.

NOTE: The FullName property is read-only.


Scripting Guide - TopMimic Functions (Mimic Functions and Properties)

TopMimic Functions

The TopMimic object has the same functions as the Mimic object. The only difference is that the TopMimic object represents the top-level Mimic that is on display, whereas the Mimic object represents the Mimic that contains the script that is running.

The TopMimic functions that you can use are:

  • TopMimic.Close
  • TopMimic.GoBack
  • TopMimic.GoForward
  • TopMimic.Print
  • TopMimic.Navigate
  • TopMimic.OpenInset.

These functions work in a similar way to the corresponding Mimic object functions, only they apply to the top-level Mimic rather than the Mimic that contains the script. For example, TopMimic.Close allows you to close the top-level Mimic that is on display, whereas Mimic.Close allows you to close the Mimic that contains the script that is running. For more information on the purpose of each function, see Mimic Functions.

If the top-level Mimic is the Mimic that contains the script that is running, using the TopMimic functions will produce the same results as using the Mimic functions (as the top-level Mimic and the Mimic that contains the script are one and the same).

Each TopMimic function references a TopMimic object. So, in your script, you need to use the following format to reference a TopMimic function:

TopMimic.<function name>


Scripting Guide - TopMimic Properties (Mimic Functions and Properties)

TopMimic Properties

The TopMimic Object has the following properties:

  • TopMimic.BackColour
  • TopMimic.SystemName
  • TopMimic.Layers
  • TopMimic.Parameters
  • TopMimic.FullName.

These properties work in the same way as the similarly named properties of the Mimic object. The only difference is that they apply to the top level Mimic (the Mimic database item that is currently displayed). For example, TopMimic.SystemName allows you to display the full name of the top-level Mimic, whereas Mimic.FullName allows you to display the full name of the Mimic that contains the script that is running. For more information on the purpose of each property, see Mimic Properties.

If the top-level Mimic is the Mimic that contains the script that is running, using the TopMimic properties will produce the same results as using the Mimic properties (as the top-level Mimic and the Mimic that contains the script are one and the same).

TopMimic objects also have the following Control Object properties which are normally associated with the Control Objects returned by Form functions and properties:

  • X and Y
  • Visible
  • Disabled.

See Also:

TopMimic Functions.


Scripting Guide - Menu Functions

Menu Functions

Menu functions allow you to create context sensitive menus from scripts. You can use the functions to create a new menu, create options for a new menu and display a new menu. When the menu is displayed, the index number of the selected menu option is returned. This index number can then be used within your script when defining the action to be taken for the selected menu option. For example, if the menu option is to set the value of a point, you would use the menu functions to create the context sensitive menu and the options in the menu, but the actual functionality of the options would be defined later in the script (using other functions, such as Server Functions).

Menu functions are associated with the Menu object and are available for Mimic scripts and Alarm Banner scripts. For more information on the individual menu functions, refer to the following sections:

  • Menu.Init
  • Menu.AddItem
  • Menu.AddMenu
  • Menu.AddSeparator
  • Menu.Display.


Scripting Guide - Menu.Init (Menu Functions)

Menu.Init

The Menu.Init function allows a script to create a context sensitive Menu.
Syntax | Menu.Init
Description | Creates a context sensitive Menu.
Arguments | None
Returns | None

Example:

Menu.Init

This creates a new context sensitive menu. The script would then have Add functions to add options to the menu (see Menu.AddItem). These would be followed by the Display function that shows the Menu and its contents (see Menu.Display).


Scripting Guide - Menu.AddItem (Menu Functions)

Menu.AddItem

The Menu.AddItem function allows a script to add an option to a context sensitive menu.
Syntax | Menu.AddItem(Text)
Description | Adds an option to the menu. Each option on the menu has an Index Number. The Index Numbers of a menu and its sub-menus are numbered from top to bottom, with the next number in the sequence allocated to the next selectable option, irrespective of whether it is on a menu or on a sub-menu.
Arguments | Text {string} The text that is shown for the option in the menu.
Returns | String

Example:

Menu.AddItem("Set Value for Point A1")

Where:

  • "Set Value for Point A1" is the name of the option as shown on the menu.

The Add.Item function creates the option in the menu, but does not define the functionality of that option (which has to be defined after the Menu.Display function, using other functions such as the Server Functions).


Scripting Guide - Menu.AddMenu (Menu Functions)

Menu.AddMenu

The Menu.AddMenu function allows a script to add a sub-menu to a context sensitive menu.
Syntax | Menu.AddMenu(Text)
Description | Adds a sub-menu to the menu. The Index Numbers of a menu and its sub-menus are numbered from top to bottom, with the next number in the sequence allocated to the next selectable option, irrespective of whether it is on a menu or on a sub-menu. The Index Number 0 is reserved for the user quitting the menu without selecting an option.
Arguments | Text. The string is the text that is shown for the sub-menu. This can be any string of characters enclosed in double quotes " "

Example:

The following script is used to add a sub-menu to a menu. The sub-menu contains 3 options (each option represents an increment of 10 and could be used to set the value of a point):

Public Function PointControlMenu
Dim Submenu
Menu.Init
Set Submenu = Menu.AddMenu("Set Value for Point A1")
Submenu.AddItem("10")
Submenu.AddItem("20")
Submenu.AddItem("30")
0
Menu.Display
End Function

Where:

  • Dim Submenu defines the name of the variable that is used to store the Control Object that is returned by the AddMenu function. In this case, the variable is named Submenu.
  • Menu.Init creates the menu
  • Set Submenu = Menu.AddMenu("Set Value for Point A1") creates the sub-menu and sets the Control Object to be stored in the Submenu variable
  • Submenu.AddItem("10") adds the first option to the sub-menu. It is named "10"
  • Submenu.AddItem("20") adds the second option to the sub-menu. It is named "20"
  • Submenu.AddItem("30") adds the third option to the sub-menu. It is named "30"
  • Menu.Display sets the menu to be displayed.
    Menu containing sub-menu option
    Sub-menu containing sub-menu options

Two more options are added to the top-level menu:

Menu.AddItem("Display Controls Point A1")
Menu.AddItem("Display Notes Point A1")

This means that the menu options are allocated the following Index Numbers:

  • Display Controls Point A1—Index Number 1 as it is at the top of the menu
  • Display Notes Point A1—Index Number 2 as it is second in the menu (from top to bottom)
  • 10—Index Number 3 as it is third in the menu (from top to bottom). 10 is a sub-menu option and is numbered in the same way as the top level menu options. The option for the sub-menu ('Set Value for Point A1') does not have an Index Number as it does not return a value.
  • 20—Index Number 4
  • 30—Index Number 5

The AddMenu function adds the menu options and returns the index of the selected option only; it does not define the functionality of the options (the functionality can be defined using other functions such as the server functions after the Menu.Display function in the script).


Scripting Guide - Menu.AddSeparator (Menu Functions)

Menu.AddSeparator

The Menu.AddSeparator function allows a script to add a separation line to a context sensitive menu.
Syntax | Menu.AddSeparator
Description | Adds a separation line to the menu or sub-menu.
Arguments | None
Returns | None

Example:

Menu.AddSeparator

This adds a separation line to the menu or sub-menu.

Separator line


Scripting Guide - Menu.Display (Menu Functions)

Menu.Display

The Menu.Display function allows the script to display a menu. The Menu.Display function has to be used at the end of the menu definition (after Menu.Init, Menu.AddItem, Menu.AddMenu etc.)
Syntax | Menu.Display()
Description | Displays a Menu.
Arguments | None
Returns | The index number of the selected option.

Each menu option has an index number. The menu options are indexed in top to bottom order. This means that the first menu option has index number 1, the second index number 2 and so on. If there are sub-menus, the options in the sub-menus are treated as if they are top level menu options.

For the menu shown below, the options are numbered as follows:

  • Display Control Point A1—Index Number 1
  • Display Notes Point A1—Index Number 2
  • 10—Index Number 3
  • 20—Index Number 4
  • 30—Index Number 4
  • 40—Index Number 5
  • 50—Index Number 6

The sub-menu does not have an index number. Similarly, the separator also does not have an index number.

The Menu.Display() function will return the index number of the menu option that is selected. If no menu option is selected, the Menu.Display function returns 0. You can then use the reference number when you define the functionality of the option in your script (using other functions such as the Server Functions).

Example:

Menu.Display()


Scripting Guide - Alarm Banner Functions and Properties

Alarm Banner Functions and Properties

The AlarmBanner object that is available for use in Alarm Banner scripts has its own functions and properties. You can use the functions and properties to provide extra functionality and to extract information from the Alarm Banner. For example, you can add menu options to the Alarm Banner’s context sensitive menu and extract alarm information such as the Message and Source. Any information that is extracted from the Alarm Banner can then be displayed in Forms or message boxes or can be sent to other applications such as work management programs.

In this section, we describe:

  • Alarm Banner Functions
  • BuildAlarmMenu
  • AlarmBanner.AddMenuItem
  • AlarmBanner.AddMenuSeparator
  • Alarm Banner Properties
  • AlarmBanner.Alarms
  • AlarmBanner.SelectedAlarms

Both the AlarmBanner.Alarms and AlarmBanner.SelectedAlarms properties return an alarm collection. Each alarm in an alarm collection has its own properties which you can also access (Alarm Collection Properties).

  • Alarm Collection Properties
  • Server
  • Object
  • Time
  • Source
  • Condition
  • Subcondition
  • Message
  • Cookie
  • State
  • CategoryDesc
  • Severity
  • SeverityDesc

We also provide examples of uses for Alarm Banner scripts: see Common Uses for Alarm Banner Scripts.


Scripting Guide - Alarm Banner Functions (Alarm Banner Functions and Properties)

Alarm Banner Functions

You can use the Alarm Banner functions to add options and separator lines to the context sensitive menu that is displayed when a user right-clicks on the Alarm Banner.

The functions that you can use in your Alarm Banner scripts are:

  • BuildAlarmMenu
  • AlarmBanner.AddMenuItem
  • AlarmBanner.AddMenuSeparator

You have to use the BuildAlarmMenu function in your script prior to using the AlarmBanner.AddMenuItem or AlarmBanner.AddMenuSeparator functions, otherwise your AlarmBanner functions will be ignored.

Each of the Alarm Banner functions references an Alarm Banner object which means that to reference them in your script, you need to use the following syntax:

AlarmBanner.<function name>

NOTE: The AlarmBanner object also has properties that can be referenced in your script (see Alarm Banner Properties).


Scripting Guide - BuildAlarmMenu (Alarm Banner Functions and Properties)

BuildAlarmMenu

When a user right-clicks on the Alarm Banner, ClearSCADA displays a context sensitive menu. The options that are shown on this menu are either the default menu options or are the default options plus additional options that you have defined in an Alarm Banner script. However, ClearSCADA can only call the functions that define the additional options if it first calls the BuildAlarmMenu function. For this reason, you need to include the BuildAlarmMenu function in your Alarm Banner scripts and it has to be defined before you define any AlarmBanner.AddMenuItem and AlarmBanner.AddMenuSeparator functions.

The BuildAlarmMenu function is different to the other Alarm Banner functions as it does not reference the Alarm Banner object. This means that there is no special syntax required - you simply need to define the start of the function by using Function BuildAlarmMenu and define the end of the function by using End Function. Between the start and end of the BuildAlarmMenu function, you can use the AlarmBanner.AddMenuItem and AlarmBanner.AddMenuSeparator functions to specify the names of the options to be added to the AlarmBanner menu and the names of the functions that they will call.

For an example of how BuildAlarmMenu can be used in a script, see Example 1: Extracting Alarm Information from the Alarm Banner.


Scripting Guide - AlarmBanner.AddMenuItem (Alarm Banner Functions and Properties)

AlarmBanner.AddMenuItem

The AddMenuItem function allows a script to add a menu option to the context sensitive menu that is available via the Alarm Banner. The AddMenuItem function is only available for use in Alarm Banner scripts and has to come after the BuildAlarmMenu function in the script.
Syntax | AlarmBanner.AddMenuItem (Title, Function)
Description | Adds a menu item to the context sensitive menu that is available for alarms in the Alarm Banner.
Arguments | Title {string} Defines the name that will be shown for the new option on the Alarm Banner’s context sensitive menu. Function {string} The name of the function that will be called when the menu option is selected. The function has to be defined later in the script
Returns | None.

Example:

In this example, the AddMenuitem function is used to add 3 options to the context sensitive menu for the Alarm Banner: Show Alarm Details, Print Alarm Details, and Display Alarm Report Form. Each option has a function that defines what action occurs when the option is selected. These functions would be defined elsewhere in the script (AlarmInfo, PrintAlarmInfo, and DisplayAlarmForm).

Function BuildAlarmMenu
AlarmBanner.AddMenuItem "Show Alarm Details","AlarmInfo"
AlarmBanner.AddMenuItem "Print Alarm Details","PrintAlarmInfo"
AlarmBanner.AddMenuItem "Display Alarm Report Form","DisplayAlarmForm"
End Function

Options added to Alarm Banner context sensitive menu.

See also:

AlarmBanner.AddMenuSeparator


Scripting Guide - AlarmBanner.AddMenuSeparator (Alarm Banner Functions and Properties)

AlarmBanner.AddMenuSeparator

The AddMenuSeparator function allows a script to add a separator line to the context sensitive menu that is available via the Alarm Banner. The AddMenuSeparator function is only available for use in Alarm Banner scripts.
Syntax | AlarmBanner.AddMenuSeparator
Description | Adds a separator line below a menu item in the context sensitive menu that is available for alarms in the Alarm Banner. The separator line is added below the last menu item that appears before the AddMenuSeparator function in the script.
Arguments | None.
Returns | None.

Example:

In this example, the AddMenuSeparator function is used to add a separator line between the “Print Alarm Details” and “Display Alarm Form” options on the context sensitive menu for the Alarm Banner:

Function BuildAlarmMenu
AlarmBanner.AddMenuItem "Show Alarm Details","AlarmInfo"
AlarmBanner.AddMenuItem "Print Alarm Details","PrintAlarmInfo"
AlarmBanner.AddMenuSeparator
AlarmBanner.AddMenuItem "Display Alarm Report Form","DisplayAlarmForm"
End Function
Separator line added to the context menu in accordance with the order of menu items added in the script. The line appears after the last menu option prior to AddMenuSeparator in the script.

See also:

AlarmBanner.AddMenuItem.


Scripting Guide - Alarm Banner Properties (Alarm Banner Functions and Properties)

Alarm Banner Properties

The AlarmBanner object has the following properties that you can access in your Alarm Banner scripts:

  • AlarmBanner.Alarms
  • AlarmBanner.SelectedAlarms.


Scripting Guide - AlarmBanner.Alarms (Alarm Banner Functions and Properties)

AlarmBanner.Alarms

The AlarmBanner.Alarms property represents a collection of the alarms currently in the Alarm Banner. It is only available for the Alarm Banner object and so only applies to Alarm Banner scripts.
Syntax | AlarmBanner.Alarms
Description | Represents the alarms currently in the Alarm Banner.
Arguments | None.
Returns | Alarm Collection. A collection of alarms (the alarms in the Alarm Banner). You can then access the properties of individual alarms in the collection (see Alarm Collection Properties).

Example:

In this example, the function AllAlarms calls the PrintAlarmInfo function for the alarms in the Alarm Banner. The PrintAlarmInfo function would be defined elsewhere in the script and would define what alarm information from each alarm is printed.

Function AllAlarm
for each A in AlarmBanner.Alarms
PrintAlarmInfo A
Next
End Function

The letter A represents each alarm in the collection. A is simply a variable and you can use any letter or word to represent each alarm.

See also:

Alarm Collection Properties


Scripting Guide - AlarmBanner.SelectedAlarms (Alarm Banner Functions and Properties)

AlarmBanner.SelectedAlarms

The AlarmBanner.SelectedAlarms property represents a collection of the alarms that are currently selected in the Alarm Banner. It is only available for the Alarm Banner object and so only applies to Alarm Banner scripts.
Syntax | AlarmBanner.SelectedAlarms
Description | Represents the alarms that are currently selected in the Alarm Banner.
Arguments | None.
Returns | Alarm Collection. A collection of alarms (the alarms selected in the Alarm Banner). You can then access the properties of individual alarms in the collection (see Alarm Collection Properties).

Example:

In this example, the function AllAlarms calls the ReassignAlarm function for the currently selected alarms in the Alarm Banner. The ReassignAlarm function would be defined elsewhere in the script and would define the user to which the alarms are to be reassigned.

Function AllAlarm
for each A in AlarmBanner.SelectedAlarms
ReassignAlarm A
Next
End Function

The letter A represents each alarm in the collection. A is simply a variable and you can use any letter or word to represent each alarm.

See also:

Alarm Collection Properties


Scripting Guide - Alarm Collection Properties (Alarm Banner Functions and Properties)

Alarm Collection Properties

The AlarmBanner.Alarms and AlarmBanner.SelectedAlarms properties return an alarm collection which contains one or more alarms. Each of the alarms in an alarm collection has its own properties that you can access in your script.

The properties of the alarms in an alarm collection are:

  • Server
  • Object
  • Time
  • Source
  • Condition
  • Subcondition
  • Message
  • Cookie
  • State
  • CategoryDesc
  • Severity
  • SeverityDesc.


Scripting Guide - Server (Alarm Banner Functions and Properties)

Server

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection. The alarms in the alarm collection have a Server property that returns a Server object. In your script, you can access the Server object and its Server Functions and Server Properties.
Syntax | Server
Description | Represents the server on which the returned alarm has been raised.
Arguments | None.
Returns | Server. The Server object has Server Functions and Server Properties that you can access in your script.

Example:

In this example, the script writes the values 123 and 456 into a data table’s Column A and Column B respectively. To achieve this, the script uses the Query property of the alarm collection’s Server property.

Dim sQuery
Set sQuery = Alarm.Server.Query("INSERT INTO DataTableName(ColumnA, ColumnB) VALUES ('123', '456')")
If sQuery.Error Then
MsgBox "Error inserting: " & sQuery.ErrorMessage
End If

DataTableName is the name of a variable that is defined elsewhere in the script. It represents a Data Table that is stored on the server that is represented by the server property.


Scripting Guide - Object (Alarm Banner Functions and Properties)

Object

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection and each alarm in the collection has an Object property. The Object property represents the item for which the alarm was raised and it has the same properties as other similar object properties, such as the serverobject that is returned by the Server.FindObject function.
Syntax | Object
Description | Represents the database item for which the returned alarm has been raised.
Arguments | None.
Returns | ServerObject A reference to an item in the database. The returned ServerObject has its own ServerObject Functions and ServerObject Properties.

Example:

In this example, Alarm.Object.Fullname is used to return the Fullname property of the item for which the selected alarm has been raised. In this case, the Fullname property is displayed on a message box along with various other alarm information.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Severity " & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function


Scripting Guide - Time (Alarm Banner Functions and Properties)

Time

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection and each alarm in the collection has a Time property. The Time property represents the time at which the alarm was raised.
Syntax | Time
Description | Returns the time at which the alarm was raised.
Arguments | None.
Returns | Time {DateTime}. The time stamp for the alarm.

Example:

In this example, Alarm.Time is used to return the time stamp of the selected alarm. The time stamp is displayed in a message box next to the text "Time", and the severity description, the alarm item’s full name, and the name of the logged on user are also shown.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Severity " & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function

Further Information

Source.


Scripting Guide - Source (Alarm Banner Functions and Properties)

Source

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection and each alarm in the collection has a Source property. The Source property returns a string which represents the item for which the alarm has been raised. While the string usually contains the FullName of the database item that is the source of the alarm, it may also be unrelated to the name of the source item, for example, the source could be the string that has been defined in the Alarm Source configuration setting for a point.
Syntax | Source
Description | Returns a string that represents the database item that is the source of the alarm.
Arguments | None.
Returns | Source {String}. A string that represents the item that is the source of the alarm. Typically, this is the FullName value of the source item.

In this example, Alarm.Source is used to return the string that represents the source of the selected alarm. The string is displayed in a message box next to the text "Source", and the time of the alarm, the severity description, the alarm item’s full name, and the name of the logged on user are also shown.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Severity" & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", "Source" & Alarm.Source & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function

Further Information

Time.


Scripting Guide - Condition (Alarm Banner Functions and Properties)

Condition

Alarms have a condition which provides an indication of the type of alarm that has been raised. The condition of each alarm is active when the alarm is unacknowledged and/or uncleared, and is inactive when an alarm is acknowledged and cleared. As alarms in the Alarm Banner are either uncleared, unacknowledged, or both, you cannot see an alarm with an inactive condition.

The condition has one or more sub-conditions, one of which will be active whenever the alarm condition is active. The sub-conditions describe the various states of the condition and provide a more specific indication of the type of alarm. For example, a simple analog point has a condition called 'AnalogValue' which has six subconditions: 'Overrange', 'HighHigh', 'High', 'Low', 'LowLow', and 'Underrange'. So when the alarm is uncleared and/or unacknowledged, the 'AnalogValue' condition is active and one of its six subconditions is also active (the active subcondition corresponds to the state of the alarm, so if the point’s value is in the High alarm limit range, the 'High' subcondition will be active).

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection, and each alarm in the collection has a Condition property. The Condition property represents the active condition of the selected alarm. You can access the Condition in your script.
Syntax | Condition
Description | Returns a string containing the name of the active condition for the alarm.
Arguments | None.
Returns | String. A string that contains the name of the alarm’s active condition.

In this example, Alarm.Condition is used to return the string that represents the active condition of the selected alarm. The string is displayed in a message box next to the text "Condition", and the source of the alarm, the time of the alarm, the severity description, the alarm item’s full name, and the name of the logged on user are also shown.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Condition" & Alarm.Condition & ", "Severity" & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", "Source" & Alarm.Source & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function

See also:

Subcondition.

Further Information

Alarm Conditions: see Understanding Alarm Conditions and Subconditions in the ClearSCADA Guide to Alarm Redirections.


Scripting Guide - Subcondition (Alarm Banner Functions and Properties)

Subcondition

Alarms have a condition which, when active, has to have one active subcondition. The active subcondition provides an indication of the state of the alarm.

Alarm conditions can have single or multiple subconditions, with each subcondition representing one of the alarm’s possible states. The alarm condition can only have one active subcondition at any time. For example, an advanced outstation has a condition called 'OutstationComms' which has four subconditions: 'Disconnected', 'Failed', 'AvailableMDRPFailed', and 'HealthyOtherFailed'. So when the outstation has an uncleared and/or an unacknowledged alarm and that alarm is due to the outstation failing, the 'OutstationComms' condition is active and the 'Failed' subcondition is active.

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection and each alarm in the collection has a Subcondition property. The Subcondition property represents the active subcondition of the selected alarm. You can access the Subcondition in your script.
Syntax | Subcondition
Description | Returns a string that represents the name of the active subcondition for the alarm.
Arguments | None.
Returns | String. A string that contains the name of the alarm’s active subcondition.

In this example, Alarm.Subcondition is used to return the string that represents the active subcondition of the selected alarm. The string is displayed in a message box next to the text "Subcondition", and the source of the alarm, the time of the alarm, the severity description, the alarm item’s full name, and the name of the logged on user are also shown.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Subcondition" & Alarm.Subcondition & ", "Severity" & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", "Source" & Alarm.Source & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function

See also:

Condition.

Further Information

Alarm Conditions: see Understanding Alarm Conditions and Subconditions in the ClearSCADA Guide to Alarm Redirection.


Scripting Guide - Message (Alarm Banner Functions and Properties)

Message

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection and each alarm in the collection has a Message property. The Message property returns a string which contains the message for the alarm (the message provides information about the cause of the alarm). You can access the Message property in your Alarm Banner script.
Syntax | Message
Description | Returns a string containing the message for the alarm.
Arguments | None.
Returns | Message {String}. The alarm message is returned as a string.

In this example, Alarm.Message is used to return the alarm message string of the selected alarm. The string is displayed in a message box next to the text "Message", and the time of the alarm, the severity description, the alarm item’s full name, and the name of the logged on user are also shown.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Severity" & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", "Message" & Alarm.Message & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function

Further Information

Alarm Banner: see Alarm Banner in the ClearSCADA Guide to Alarms.


Scripting Guide - Cookie (Alarm Banner Functions and Properties)

Cookie

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection. Each alarm in an alarm collection has a unique cookie number which is used to identify each instance of alarm (if an alarm is re-raised, it will be allocated a new cookie). While alarm cookies are not displayed in the Alarm Banner, you can access them in your Alarm Banner scripts by using the Cookie property.
Syntax | Cookie
Description | Returns the unique cookie number of the alarm.
Arguments | None.
Returns | Cookie {integer}. The alarm cookie is returned as a number.

In this example, Alarm.Cookie is used to return the alarm cookie number of the selected alarm. The number is displayed in a message box next to the text "Cookie", and the time of the alarm, the severity description, the alarm item’s full name, and the name of the logged on user are also shown.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Severity" & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", "Cookie" & Alarm.Cookie & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function


Scripting Guide - State (Alarm Banner Functions and Properties)

State

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection. Each alarm in an alarm collection has a State property which is a number that represents the state of the alarm. The number that is returned by the State property varies according to the state of the alarm:

  • Alarm is enabled, uncleared and has been acknowledged = 7
  • Alarm is enabled, uncleared and has not been acknowledged = 3
  • Alarm is enabled, cleared, and has not been acknowledged = 1

In this context, the term 'enabled' means the alarm has been raised (and so is enabled on the Alarm Banner).

Accessing an alarm’s State property in your Alarm Banner script can be useful as it allows you to code different outcomes depending on the state of the alarm.
Syntax | State
Description | Returns the number for the state of the alarm (1, 3, or 7).
Arguments | None.
Returns | State {integer}. The alarm state is returned as a number.

Example:

In this example, the State property of an alarm is used to determine whether the Source of the alarm is added to a combo box on a Form.

For Each objAlarm In AlarmBanner.SelectedAlarms
If objAlarm.Object.CheckAccess("ALM")
And objAlarm.State < 4 Then
frmDrop.Add objAlarm.Source
AddToArray sPointNames,
objAlarm.Source
End If

For each alarm in the alarm collection returned by the Selected Alarms property, the script:

  • Checks that the user has sufficient permissions to access the object of the alarm (the item that is associated with the raised alarm)
  • Checks if the alarm has an alarm state that is less than 4. If the alarm state is less than 4, the Source of the alarm is added to an array (the Source is a string that is usually the name of the database item associated with the alarm). If the alarm state is greater than 4, its Source is not added to the combo box.

The combo box would be created earlier in the script, prior to this extract.


Scripting Guide - CategoryDesc (Alarm Banner Functions and Properties)

CategoryDesc

Alarm categories are classes of conditions and are used to provide a general indication of the type of alarm that has been raised. The Condition and Subcondition of the alarm provide more specific indications of the type of alarm. For example, a simple analog point has a condition called 'AnalogValue' which has six subconditions: 'Overrange', 'HighHigh', 'High', 'Low', 'LowLow', and 'Underrange'. The point’s value is 5 which is in the 'LowLow' threshold that has been configured for the point. This means that an alarm is raised for the point and the alarm has the following attributes:

  • Category: Point State
  • Condition: AnalogValue
  • Subcondition: LowLow

From the example, you can see that the Category provides a very general indication of the type of alarm that has been raised, the Condition shows a more specific indication of the type of alarm, and the Subcondition shows the point state that has caused the alarm to be raised.

To access the Category of an alarm in your script, you need to use the CategoryDesc property of the alarm. You can access the CategoryDesc property of any alarm in an alarm collection that has been returned by the Alarm.SelectedAlarms or Alarm.Alarms properties. The CategoryDesc property returns the alarm’s category value as a string.
Syntax | CategoryDesc
Description | Returns the category of the alarm.
Arguments | None.
Returns | Category {string}. The alarm’s category is returned as a string.

In this example, Alarm.CategoryDesc is used to return the alarm category of the selected alarm. The number is displayed in a message box next to the text "Category", and the time of the alarm, the severity description, the alarm item’s full name, and the name of the logged on user are also shown.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Severity" & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", "Category" & Alarm.CategoryDesc & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function


Scripting Guide - Severity (Alarm Banner Functions and Properties)

Severity

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection. Each alarm in an alarm collection has a Severity property which is a number that represents the significance of the alarm. The number that is returned by the Severity property corresponds to the Severity level of the alarm. The default severity range is:

  • Critical severity = 1000
  • High severity = 667-999
  • Medium severity = 334-666
  • Low severity = 1-333
  • No severity = 0

However, the severity range can be customized on your system by using the Server Configuration Tool (see Alarm and Event Severities in the ClearSCADA Guide to Server Administration). So you need to know what severity range is in place before you create an Alarm Banner script that uses the Severity property.

Accessing an alarm’s Severity property in your Alarm Banner script can be useful as it allows you to code different outcomes depending on the significance of the alarm.
Syntax | Severity
Description | Returns the number for the alarm’s severity.
Arguments | None.
Returns | Severity {integer}. The alarm severity is returned as a number.

Example:

In this example, the Severity property of an alarm is used to determine whether the Source of the alarm is added to a combo box on a Form. It sets the script to only add the sources of High and Critical alarms to the combo box (assuming the default severity range is in place).

For Each objAlarm In AlarmBanner.SelectedAlarms
If objAlarm.Object.CheckAccess("ALM")
And objAlarm.Severity > 666 Then
frmDrop.Add objAlarm.Source
AddToArray sPointNames,
objAlarm.Source

End If


Scripting Guide - SeverityDesc (Alarm Banner Functions and Properties)

SeverityDesc

The Alarm.SelectedAlarms and Alarm.Alarms properties both return an alarm collection. Each alarm in the collection has a SeverityDesc property that you can access in your Alarm Banner script. The SeverityDesc property returns the Severity of the alarm as a string (unlike the Severity property which returns the Severity as a number).

The string that is returned by the SeverityDesc property contains the name of the Severity range that corresponds to the value of the alarm’s source. For example, if the default severity ranges are in place and an analog point’s value rises to 800, an alarm is raised and the severity of that alarm is High (as 800 falls within the default range for the High severity). This means that the alarm’s SeverityDesc property will return 'High'.
Syntax | SeverityDesc
Description | Returns the severity of the alarm.
Arguments | None.
Returns | Severity {string}. The alarm’s severity is returned as a string.

In this example, Alarm.SeverityDesc is used to return the severity description of the selected alarm. The string is displayed in a message box next to the text "Severity", and the time of the alarm, the alarm item’s full name, and the name of the logged on user are also shown.

Function ShowAlarmInfo( Alarm )
MsgBox "One Alarm Selected", "Severity" & Alarm.SeverityDesc & ", Time " & Alarm.Time & ", logged on user name " & Alarm.Server.Username & ", Object name " & Alarm.Object.Fullname

End Function


Scripting Guide - Server and ServerObject Functions and Properties

Server and ServerObject Functions and Properties

The Server object has functions and properties that allow you to create a script that interacts with the database by reading or writing values or returning the names of specific database items. For example, you can use a Server function to set a script to read the value of a database point.

Server functions and properties are associated with the server object. However, some server functions return a ServerObject that has its own functions and properties which can also be accessed.

Server and ServerObject functions and properties can be used in Mimic scripts and also in Alarm Banner scripts (the server functions are available via the Server property of the alarm collection returned by the Alarms or SelectedAlarms property; the serverobject functions are available via the Object property of the alarm collection).

For more information on the individual Server functions and properties, refer to the following sections:

  • Server Functions
  • Server.GetOPCValue
  • Server.SetOPCValue
  • Server.FindObject
  • Server Properties
  • Server.RootObject
  • Server.ThisObject
  • Server.UserName
  • Server.Query
  • ServerObject Functions
  • ServerObject.CheckAccess
  • ServerObject.FindChild
  • ServerObject Properties
  • ServerObject.Id
  • ServerObject.Name
  • ServerObject.FullName
  • ServerObject.Class
  • ServerObject.Interface
  • ServerObject.IsGroup
  • ServerObject.Parent
  • ServerObject.Children
  • ServerQuery Properties
  • ServerQuery.ColumnCount
  • ServerQuery.ColumnNames
  • ServerQuery.RowCount
  • ServerQuery.Rows
  • ServerQuery.Error
  • ServerQuery.ErrorMessage


Scripting Guide - Server Functions (Server and ServerObject Functions and Properties)

Server Functions

Server functions allow you to create a script that interacts with the database by:

  • Writing a value to an OPC tag
  • Reading (and returning) the value of an OPC tag
  • Locating (and returning the Name value of) an item in the database.

As the Server functions need to interact with the database, they can only be completed successfully if there is a healthy connection between the client on which the script is running and the server. The connection is made via the XML server using Port 80 (by default) so that scripts can run correctly on both ViewX and WebX clients. The Port address can be changed via the Server Configuration Tool (see Connection and Update Settings in the ClearSCADA Guide to Server Administration).

The Server functions that are available for you to use in your scripts are:

  • Server.GetOPCValue
  • Server.SetOPCValue
  • Server.FindObject. The FindObject function returns a ServerObject item that also has its own functions and properties that you can use in your script—see ServerObject Functions and ServerObject Properties
  • Server.LookUpObject. The LookUpObject function returns a ServerObject item that also has its own functions and properties that you can use in your script—see ServerObject Functions and ServerObject Properties

Each of the Server functions references a Server object, which means that in your script you will need to use the following format to reference them:

Server.<function name>

NOTE: The Server object also has properties that can be referenced in your script (see Server Properties).


Scripting Guide - Server.GetOPCValue (Server and ServerObject Functions and Properties)

Server.GetOPCValue

The GetOPCValue function is a server function that allows a script to read the value from a tag in the database. A tag is a combination of the address of a database item and the name of one of its properties.
Syntax | Server.GetOPCValue (Tag)
Description | The GetOPCValue server function allows a script to read a value from a database item property (referenced by tag).
Arguments | Tag {string} Defines the property and address of the database item that is to be read.
Returns | Value {variant}. Returns the value for the property that is specified by the Tag. This can be integer, string, Boolean etc.

Example:

sStateDesc = Server.GetOPCValue (".AI1.AlarmDesc")
MsgBox "The Current Alarm State of this Point is " & sStateDesc

Where:

  • sStateDesc is the name of the variable that is used to store the value that is returned by the GetOPCValue function.
  • (".AI1.AlarmDesc") tells the script the location of the value that is to be read. In this case, the AlarmDesc value of the 'AI1' point is being read. The tag is a string.
  • MsgBox instructs the script to display a Windows message box
  • "The Current Alarm State of this Point is " is the pre-defined text string that is shown in the message box
  • & sStateDesc instructs the script to add the value stored by the sStateDesc variable to the pre-defined string on the message box. The ampersand & is a VBScript operator.

See also:

Server.SetOPCValue


Scripting Guide - Server.SetOPCValue (Server and ServerObject Functions and Properties)

Server.SetOPCValue

The SetOPCValue function is a server function that allows a script to write a value to the database.
Syntax | Server.SetOPCValue (Tag, Value)
Description | The SetOPCValue server function allows a script to write a value to an object property referenced by tag.
Arguments | Tag {string} Defines the location of the database item to which the value is being written. Value {variant} The value defines the value that is written to the database.
Returns | None.

Example:

sDesc = InputBox ("Enter the New High High Desc")
Server.SetOPCValue ".AI1.HighHighDesc", sDesc

Where:

  • sDesc = InputBox ("Enter the New High High Desc") instructs the script to display an Input Box that has the message "Enter the New High High Desc". sDesc is the name of the variable that is used to store the value that is entered in the input box.
  • Server.SetOPCValue ".AI1.HighHighDesc", sDesc instructs the script to write the value that is stored in the sDesc variable (entered in the input field by the user) to the HighHighDesc configuration field of the 'AI1' point.

See also:

Server.GetOPCValue.


Scripting Guide - Server.FindObject (Server and ServerObject Functions and Properties)

Server.FindObject

The FindObject function is a server function that allows a script to locate an item in the database. The FindObject function returns a ServerObject that has its own functions and properties.
Syntax | Server.FindObject (Name)
Description | Locates an item in the database and allows a script to manipulate the item. The FindObject function returns a ServerObject. A ServerObject is a ClearSCADA specific script object that has its own functions and properties which can be manipulated.
Arguments | Name {string} Defines the name of the item in the database that you want to find. It returns a reference to an object.
Returns | ServerObject A reference to an item in the database. The returned ServerObject has its own ServerObject Functions and ServerObject Properties.

NOTE: The FindObject function does not allow relative paths. However, you can work around this by using the Server.GetOPCValue function. For an example of how the Server.GetOPCValue and FindObject functions can be used together, see ComboBox.Selection.

Example 1.

Set objAI1Point = Server.FindObject ("AI1")
MsgBox "This Sensor is" &objAI1Point.Name

Where:

  • objAI1Point is the variable that is used to store the ServerObject that is returned by the FindObject function.
  • ("AI1") is the name and location of the database item that is to be searched for by the FindObject function. In this case, it is a point named "AI1" that is located in the root of the system.
  • MsgBox "This Sensor is" instructs the script to display a message box containing the text "This Sensor is"
  • &objAI1Point.Name instructs the script to add the Name value of the ServerObject (that is returned by the FindObject function and stored in the objAI1Point variable) to the message box. When the message box is displayed, it contains the message "This Sensor is AI1".

Example 2.

Set objPoint = Server.FindObject(Server.ThisObject.Parent.FullName + "DigitalPoint1")
objPoint.Interface.Override 1

Where:

  • Set objPoint = Server.FindObject instructs the script to use the Server FindObject function to locate the database item that provides the value for the 'objPoint' variable.
  • (Server.ThisObject.Parent.FullName + "DigitalPoint1") defines the location of the database item. The location is defined by a Server property (Server.ThisObject) and a ServerObject property (Parent). The Server and ServerObject properties instruct the script to begin the search at the parent of the group that contains the Mimic (the Mimic is ThisObject). FullName + "DigitalPoint1" instructs the script to search for the database item that has a FullName value that matches "DigitalPoint1".
  • objPoint.Interface.Override 1 instructs the script to use the Interface of the objPoint variable to perform an Override with a value of 1. The Interface is a ServerObject property and it provides access to the point's methods, properties etc.

See also:

Server.LookUpObject

Server.RootObject

Server.ThisObject.


Scripting Guide - Server.LookUpObject (Server and ServerObject Functions and Properties)

Server.LookUpObject

The LookUpObject function is a server function that allows a script to locate an item in the database. The LookUpObject function works in a similar way to the Server.FindObject function, except that it uses an Object Id (the unique identification reference of a database item) instead of an Object Name. The LookUpObject function returns a ServerObject that has its own functions and properties (see see ServerObject Functions and see ServerObject Properties).
Syntax | Server.LookUpObject (ObjectId)
Description | Locates an item in the database and allows a script to manipulate the item. The LookUpObject function returns a ServerObject. A ServerObject is a ClearSCADA specific script object that has its own functions and properties which can be manipulated.
Arguments | Object Id {integer} The unique Id number of the item that you want to locate in the database.
Returns | ServerObject A reference to an item in the database. The returned ServerObject has its own ServerObject Functions and ServerObject Properties.

Example:

Set objAI1Point = Server.LookUpObject (601)
MsgBox "This Sensor is named:" &objAI1Point.Name

Where:

  • objAI1Point is the variable that is used to store the ServerObject that is returned by the LookUpObject function.
  • (601) is the unique Object Id of the database item that is to be searched for by the
  • LookUpObject function. In this case, it is the point with the Object Id of 601 that is located in the root of the system.
  • MsgBox "This Sensor is named:" instructs the script to display a message box containing the text "This Sensor named:"
  • &objAI1Point.Name instructs the script to add the Name value of the ServerObject (that is returned by the LookUpObject function and stored in the objAI1Point variable) to the message box. When the message box is displayed, it contains the message:
"This Sensor is named: <Name of point that has Object ID 601>".

See also:

Server.FindObject

Server.RootObject

Server.ThisObject.


Scripting Guide - Server Properties (Server and ServerObject Functions and Properties)

Server Properties

The Server object has the following properties that you can use in your scripts:

  • Server.RootObject
  • Server.ThisObject
  • Server.UserName
  • Server.Query.


Scripting Guide - Server.RootObject (Server and ServerObject Functions and Properties)

Server.RootObject

The RootObject property is a server property that represents the top level item in the database.
Syntax | Server.RootObject
Description | Represents the top level of the database (the Root of the database).
Arguments | None.
Returns | ServerObject A ServerObject is a ClearSCADA specific script object that has its own functions (see ServerObject Functions) and properties (see ServerObject Properties) which can be manipulated.

Example:

The following script is used to display a message box that contains the name of the root object:

Set ServerRoot = Server.RootObject
MsgBox ServerRoot.Name

Where:

  • ServerRoot is the name of the variable used to store the ServerObject that is returned by the RootObject property.
  • MsgBox ServerRoot.Name instructs the script to display a message box that contains the Name value of the ServerObject that is stored by the ServerRoot variable (this is the ServerObject that is returned by the RootObject property).

See also:

Server.ThisObject

Server.UserName.


Scripting Guide - Server.ThisObject (Server and ServerObject Functions and Properties)

Server.ThisObject

The ThisObject property is a server property that returns a reference to the Mimic that contains the script
Syntax | Server.ThisObject
Description | References the Mimic that contains the script.
Arguments | None.
Returns | ServerObject A ServerObject is a ClearSCADA specific script object that has its own functions (see ServerObject Functions) and properties (see ServerObject Properties) which can be manipulated.

Example:

The following script is used on a Mimic in a Group Template. It allows the Group Instance versions of the Mimic (that contains the script) to provide a button that can override the 'DigitalPoint1' point to 1:

Set objPoint = Server.FindObject(Server.ThisObject.Parent.FullName + "DigitalPoint1")
objPoint.Interface.Override 1

Where:

  • objPoint is the name of the variable that is used to store the ServerObject that is returned by the FindObject property.
  • The FindObject property instructs the script to search for a point named 'DigitalPoint1' that is stored in the same parent Group as the Mimic that contains the script. The ThisObject property returns the ObjectLink that references the Mimic that contains the script, then the Parent property instructs the script to search in the Group that contains the Mimic, and finally the FullName + "Digital Point1" instructs the script to search for a database item with a FullName value of "Digital Point1".
  • objPoint.Interface.Override 1 instructs the script to perform an Override control to the value of 1 on the ServerObject that is stored in the objPoint variable.

The FindObject and ThisObject properties are used to allow the script to search in the same group as the Mimic that contains the script, irrespective of the name of the Group (so ideal for use with Group Templates and Instances).

See also:

Server.RootObject

Server.UserName.


Scripting Guide - Server.UserName (Server and ServerObject Functions and Properties)

Server.UserName

The UserName property is a server property that - when called from a Mimic - returns the name of the currently logged on user on that client.
Syntax | Server.UserName
Description | Returns the user name of the currently logged on user.
Arguments | None.
Returns | UserName {string} The user name of the currently logged on user.

Example:

The following script is used to display a message box that contains the name of the currently logged on user:

sCurrentUser = Server.UserName
MsgBox sCurrentUser

Where:

  • sCurrentUser is the name of the variable used to store the UserName that is returned by the UserName property.
  • MsgBox sCurrentUser instructs the script to display a message box containing the value that is stored in the sCurrentUser variable.

See also:

App.LogOn and App.LogOff.


Scripting Guide - Server.Query (Server and ServerObject Functions and Properties)

Server.Query

The Query property is a server property that - when called from a Mimic - returns a ServerQuery (similar to a ServerObject in that it is only used internally to represent data, only a ServerQuery is used specifically to represent the resultset of an SQL Query). The ServerQuery has its own properties which include ColumnCount, ColumnNames, RowCount, Rows, Error, and ErrorMessage (see ServerQuery Properties).

Syntax

Server.Query

Description

Performs a query on the database.

The Server.Query function returns a ServerQuery - a ClearSCADA specific script object that has its own properties which can be manipulated.

Arguments

SQL {string}

The SQL for the query.

The SQL Query can make use of any of the SQL commands that are available in ClearSCADA, including SELECT, UPDATE, INSERT, and DELETE.

The permissions of your User account may restrict the query—the SQL query can only access those database items to which your User account has the Read permission enabled.

Returns

ServerQuery

The result of the SQL Query is returned as a ServerQuery. The ServerQuery has its own properties which you can use to access the data in the query (see ServerQuery Properties).

For more information on SQL queries, see SQL Query Structure of the Guide to Lists.

Example:

In this example, a script is used to perform an SQL Query on a Data Grid database item. The script uses the Server.Query property and also makes use of the properties of the ServerQuery that is returned by the Server.Query property.

The example script has been created specifically to show the syntax for the Server.Query property and the properties of the resultant ServerQuery script object. To keep the example simple, we have used message boxes to display the values retrieved by the query. On a live system, you would be more likely to want to write the values to another part of the database or use them in calculations.

Option Explicit
Public Sub ServerQueryTest
Dim DGRS
Dim DGRows
Dim DGColNames
Dim r, c
Dim string

Set DGRS = Server.Query("SELECT * FROM DGTest")
If Not(DGRS.Error) Then
DGRows = DGRS.Rows
DGColNames = DGRS.ColumnNames
For c = 0 To (DGRS.ColumnCount - 1)
MsgBox DGColNames(c)
Next
For r = 0 To (DGRS.RowCount - 1)
string = ""
for c = 0 to (DGRS.ColumnCount - 1)
string = string & DGRows(r,c) & " , "
Next
Msgbox Cstr(r) & string
Next
Else
Msgbox DGRS.ErrorMessage, vbCritical + vbOKOnly, "Error in SQL Command"
End If
Set DGRS = Server.Query("INSERT INTO DGTest(Str, Lng, Bool) VALUES ('Test3', 45, False)")
If DGRS.Error Then
Msgbox DGRS.ErrorMessage, vbCritical + vbOKOnly, "Error in SQL Command"
End If
End Sub

The script works like this:

The DGRS variable is set to represent the result of the SQL Query that is performed on the 'DGTest' database item. The SQL Query requests the data from DGTest (SELECT* FROM DGTest).

If the SQL Query is successful, the Server.Query property returns a ServerQuery. The DGRows variable is then set to be the same value as the value of the ServerQuery’s Rows property.

The 'c' variable is set to represent the columns of the Query resultset. The range of columns to be accessed by the script is defined as column 0 to the ColumnCount value of the ServerQuery -1. The -1 is used with the ColumnCount property of the ServerQuery so that the range has 3 values, with the count starting at 0. The columns that are included in the range then have their column names displayed in message boxes (each column name is displayed in a separate message box). The column names are accessed by using the ColumnNames property of the ServerQuery.

The 'r' variable is set to represent the rows of the Query resultset. The range of rows to be accessed by the script is defined as row 0 to the RowCount value of the ServerQuery -1. The -1 is used with the RowCount property of the ServerQuery so that the range has the correct number values, with the count starting at 0. For each row in the range, the script initializes the value to be empty, then inserts the value that is stored for the row (in the Rows property of the ServerQuery). The values of each row are displayed in a message box (1 message box per row of values) and the values show in the message box are separated by a comma.

If the query specified for the Server.Query property cannot be completed successfully, a message box is displayed showing an error message. The title of the error message box is “Error in SQL Command” and the error message that is displayed is the value stored by the ErrorMessage property of the ServerQuery. The message box is set to have a critical warning symbol and a single OK button.

When the script has displayed the relevant message box(es), it will attempt to insert a new row of values into the 'DGTest' database item. The three values it will insert are of the types Str, Lng, and Bool respectively and are 'Test 3', '45', and 'False'. If the script is unable to create this row of values for the 'DGTest' item, it will display a message box. The title of the error message box is “Error in SQL Command” and the error message that is displayed is the value stored by the ErrorMessage property of the ServerQuery. The message box is set to have a critical warning symbol and a single OK button.


Scripting Guide - ServerObject Functions (Server and ServerObject Functions and Properties)

ServerObject Functions

The ThisObject, RootObject, and FindObject functions and properties return
a ClearSCADA specific script object called a ServerObject. The ServerObject has its own functions and properties that you can use in your script.

The ServerObject functions are:

  • ServerObject.CheckAccess
  • ServerObject.FindChild.

For information on the ServerObject properties, see ServerObject Properties.

ServerObject functions require information from the database (and so a connection to the server is required). The connection is made via the XML server using Port 80 (by default) so that the functions work in scripts running on both ViewX and WebX clients. The Port address can be changed via the Server Configuration Tool (see Connection and Update Settings in the ClearSCADA Guide to Server Administration).


Scripting Guide - ServerObject.CheckAccess (Server and ServerObject Functions and Properties)

ServerObject.CheckAccess

The ServerObject.CheckAccess function allows a script to check whether the currently logged on user has a specific permission for an item.

Syntax

ServerObject.CheckAccess (Permission)

Description

Checks whether the currently logged on user has a specific permission for an item.

Arguments

Permission.

The permission is a string that represents one of the database item's access permissions. The required characters are:

  • RD—Read
  • BRS—Browse
  • CTL—Control
  • OVR—Override
  • ALM—Acknowledge Alarms
  • VWA—View Alarms
  • RMA—Remove Alarms
  • NOT—Notes
  • RET—Retrieve Data
  • PRM—Promote
  • TUN—Tune Limits
  • AHS—Annotate Historic
  • MHS—Modify Historic
  • VHS—Validate Historic
  • DIS—Enable/Disable
  • DLM—Disable Alarms
  • DCT—Disable Control
  • SWL—Switch Line
  • DIA—Diagnostics
  • EXC—Exclusive Control
  • MEC—Manage Exclusive Control
  • CFG—Configure
  • SEC—Security
  • ADM—Sys Admin

For more information on the various permissions, see Allocating Security Permissions in the ClearSCADA Guide to Security.

Returns

Boolean.

True if the currently logged on user has the defined permission; False if the currently logged on user does not have the defined permission.

Example:

The following script is used to display a message box that contains a message. The message differs depending on whether the currently logged on user has the Override/Release permission for a point named 'Tank Level':

Set objLevelPoint = Server.FindObject("Tank Level")
If objLevelPoint.CheckAccess("OVR") = True Then
objLevelPoint.Interface.Override 50
Else
Msgbox ("User Does Not Have Override Permissions")
End If

Where:

  • objLevelPoint is the name of a variable that is used to store the ServerObject that is returned by the FindObject function.
  • "Tank Level" is the name of the database item that the FindObject function searches for.
  • If objLevelPoint.CheckAccess("OVR") instructs the script to check the value of the CheckAccess property of the ServerObject that is stored in the objLevelPoint variable. In this case, it checks for the "OVR" Override/Release permission.
  • If the currently logged on user has the "OVR" permission for the "Tank Level" database item, an Override of 50 is set for the objLevelPoint. This is achieved by accessing the Interface property for the ServerObject that is stored by the objLevelPoint variable.
  • If the currently logged on user does not have the "OVR" permission for the "Tank Level" database item, a message box is displayed containing the message "User Does Not Have Override Permissions".


Scripting Guide - ServerObject.FindChild (Server and ServerObject Functions and Properties)

ServerObject.FindChild

The ServerObject.FindChild function allows the script to find items that are stored in Groups without having to use the full path of each item. This is useful when a script needs to locate several items that are stored within the same Group.
Syntax | ServerObject.FindChild (Name)
Description | The FindChild function is designed to allow the script to search a Group for an item in that Group. If an item with the defined name is found, a ServerObject is created within the script for that item. By using the FindChild function, you can avoid the need for using the full path names of the items in a Group.
Arguments | Name {string}. The Name is what the FindChild function searches for in the child Group. The function will return a ServerObject for any item that is in the child Group and has a name that matches the defined Name argument.
Returns | ServerObject Returns a a ServerObject that represents a database item that is stored within a specific Group. The ServerObject has its own functions and properties that can then be manipulated.

Example:

A Group named 'Tanks' contains a database point named 'Tank Level'. A script is to read the value of the point and display it in a message box. The FindChild function allows the script to locate the point by name, rather than having to use the full path of the point.

Set objTanksGroup = Server.FindObject("Tanks")
Set objPointLevel = objTanksGroup.FindChild("Tank Level")
MsgBox "Tank Level = " &objPointLevel.Interface.CurrentValue

Where:

  • objTanksGroup is the name of the variable that stores the ServerObject that is returned by the FindObject function.
  • Server.FindObject("Tanks") instructs the script to search for the database item named "Tanks". In this example, the "Tanks" item is a Group.
  • objPointLevel is the name of the variable that stores the ServerObject that is returned by the FindChild function.
  • objTanksGroup.FindChild("Tank Level") instructs the script to search for a child item named "Tank Level" within the group that is stored by the objTanksGroup variable (in this case, the group is the "Tanks" group and is stored as a ServerObject in the objTanksGroup variable).
  • MsgBox = "Tank Level = " &objPointLevel.Interface.CurrentValue instructs the script to display a message box that contains the message "Tank Level = x" where x is the current value of the database item referenced by the ServerObject that is stored in the objPointLevel variable. In this case, x is the current value of the "Tank Level" point. The Interface property is used to access the properties of the ServerObject.

See also:

Server.FindObject

Server.RootObject

Server.ThisObject.


Scripting Guide - ServerObject Properties (Server and ServerObject Functions and Properties)

ServerObject Properties

The ServerObject script objects that are returned by the several of the Server Functions have their own properties. You can access these properties in your script.

For many ServerObjects, the ServerObject properties are:

  • ServerObject.Id
  • ServerObject.Name
  • ServerObject.FullName
  • ServerObject.Class
  • ServerObject.Interface
  • ServerObject.IsGroup
  • ServerObject.Parent
  • ServerObject.Children.


Scripting Guide - ServerObject.Id (Server and ServerObject Functions and Properties)

ServerObject.Id

The ServerObject.Id property returns the Id value for the database item that is referenced in the script by the ServerObject. The Id is a unique number that identifies the item in the database and is used to link an item to its history and events etc.
Syntax | ServerObject.Id
Description | Accesses the Id value of a database item that is referenced by a ServerObject in the script.
Arguments | None.
Returns | Id {integer} The Id value of database item that is referenced in the script by the ServerObject. The Id is unique to the database item and is an identifier that is used for accessing the item's historic data and events.

Example:

The following script is used to display the Id of a point named 'Tank Level' in a message box:

Set objTankLevel = Server.FindObject("Tanks.Tank Level")
MsgBox "Tank Level Id = " &objTankLevel.Id

Where:

  • objTankLevel is the name of the variable that stores the ServerObject that is returned by the FindObject function.
  • Server.FindObject("Tanks.Tank Level") instructs the script to search for the 'Tank Level' item that is stored in the 'Tanks' Group.
  • MsgBox "Tank Level Id = " &objTankLevel.Id instructs the script to display a message box that contains the message 'Tank Level Id = x' where x is the Id value of the item referenced by the ServerObject that is stored in the objTankLevel variable.


Scripting Guide - ServerObject.Name (Server and ServerObject Functions and Properties)

ServerObject.Name

The ServerObject.Name property returns the Name value for the database item that is referenced in the script by the defined ServerObject. The Name value consists of the item's name only; it does not contain the path of the item.
Syntax | ServerObject.Name
Description | Accesses the Name property of a database item that is referenced in the script by the defined ServerObject.
Arguments | None.
Returns | Name {string} The Name of the database item that is referenced in the script by a ServerObject.

Example:

A script is created that, when executed, will cause a message box to display the name of a point. The point is named 'Tank Level' and it is stored in a Group named 'Tanks'.

The script is as follows:

Set objLevelPoint = Server.FindObject("Tanks.Tank Level")
If Not objLevelPoint Is Nothing Then
PointName = objLevelPoint.Name
MsgBox PointName
Else
MsgBox "Point not found"
End If

Where:

  • objLevelPoint is the name of the variable that stores the ServerObject that is returned by the FindObject function.
  • Server.FindObject("Tanks.Tank Level") instructs the script to search for a database item named 'Tank Level' in a Group named 'Tanks'.
  • If Not objLevelPoint Is Nothing Then tells the script what to do if the objLevelPoint variable has a value. The If Not objLevelPoint Is Nothing means that if the objLevelPoint is not nothing i.e. the objLevelPoint has a value, then proceed with the following action.
  • PointName = objLevelPoint.Name instructs the script to set the PointName variable to have the same value as the Name property of the objLevelPoint variable. Remember that the PointName is only set to be the same as the objLevelPoint.Name property if the GroupName has a value.
  • MsgBox PointName instructs the script to display a message box containing the value that is stored by the PointName variable (the value is the same as the Name property of the objLevelPoint variable).
  • Else MsgBox "Point not found" tells the script what to do if the objLevelPoint variable does not have a value (i.e. If objLevelPoint Is Nothing). In this case, the script will display a message box containing the message "Point not found".


Scripting Guide - ServerObject.FullName (Server and ServerObject Functions and Properties)

ServerObject.FullName

The ServerObject.FullName property returns the FullName value for the database item that is referenced in the script by the ServerObject. The FullName value consists of the full path of the item.
Syntax | ServerObject.FullName
Description | References the complete path name for the item that is referenced by the ServerObject.
Arguments | None.
Returns | FullName {string} The FullName value is a reference to the item that is referenced by the ServerObject and consists of the complete path name of the address.

The FullName property works in the same way as the ServerObject.Name property, except that it returns the full path of the item, not just its name.

Example:

The following script searches for a database item named 'Tank Level' in a Group named 'Tanks' and then displays its FullName property value in a message box:

Set objTanksGroup = Server.FindObject("Tanks")
Set objTankLevel = objTanksGroup.FindChild("Tank Level")

MsgBox "Tank Level FullName = " &objTankLevel.FullName

Where:

  • objTanksGroup is the variable that stores the ServerObject that is returned by the FindObject function.
  • Server.FindObject("Tanks") instructs the script to search for an item named 'Tanks'. In this case, the item is a Group.
  • objTankLevel is the name of the variable that stores the ServerObject that is returned by the FindChild function.
  • objTanksGroup.FindChild("Tank Level") instructs the script to search for an item named 'Tank Level' in the Group that is referenced by the objTanksGroup ServerObject (in this case, in the 'Tanks' Group).
  • MsgBox "Tank Level FullName = " &objTankLevel.FullName instructs the script to display a message box that contains the message 'Tank Level FullName = x' where x is the FullName property value of the ServerObject that is stored in the objTankLevel variable. In this case, the ServerObject represents the 'Tank Level' point and so the message box displays the FullName value of the 'Tank Level' point.


Scripting Guide - ServerObject.Class (Server and ServerObject Functions and Properties)

ServerObject.Class

The ServerObject.Class property returns the name of the parent class for the database item that is referenced in the script by the ServerObject. The Class is the table in the database that contains the category of item (for more information, see Understanding the Database in the ClearSCADA Guide to the Database).
Syntax | ServerObject.Class
Description | References the class of the database item that is referenced in the script by the ServerObject.
Arguments | None.
Returns | Class {string} The class of the database item that is referenced in the script by the ServerObject. The Class is a table in the database schema (see Working with the Database Schema in the ClearSCADA Guide to the Database).

Example:

The following script is used to display a message box showing the class of an internal analog point named 'Tank Level' (that is stored in a Group named 'Tanks'):

Set objTankLevel = Server.FindObject("Tanks.Tank Level")

MsgBox "Tank Level Class = " &objTankLevel.Class

Where:

  • objTankLevel is the name of the variable that stores the ServerObject that is returned by the FindObject function.
  • Server.FindObject("Tanks.Tank Level") instructs the script to search for the item named 'Tank Level' in the 'Tanks' Group.
  • MsgBox "Tank Level Class = " &objTankLevel.Class instructs the script to display a message box containing the message 'Tank Level Class = x' where x is the Class value of the item referenced by the objTankLevel variable (in this case, the objTankLevel variable stores the ServerObject that is returned by the FindObject function). So x is the Class value of the 'Tank Level' database item.


Scripting Guide - ServerObject.Interface (Server and ServerObject Functions and Properties)

ServerObject.Interface

The ServerObject.Interface property allows a script to access the properties, methods and aggregates of the database item that is referenced by the ServerObject. For example, if a script is to issue a control to a point, the point will be referenced by a ServerObject in the script and the ServerObject.Interface property will be used to access the point's control.
Syntax | ServerObject.Interface
Description | Provides access to the properties, methods, and aggregates of the database item that is referenced by the ServerObject.
Arguments | None.
Returns | Value {variant}. When reading a property value, the Interface property returns a value. The value is a variant (string, integer, Boolean etc. depending on the type of value being read).

Example 1: Calling a Method

The following script is used to override a point so that its value is 10:

Set objPoint = Server.FindObject(Server.ThisObject.Parent.FullName + ".DigitalPoint1")
objPoint.Interface.Override 10

Where:

  • Server.FindObject(Server.ThisObject.Parent.FullName + "DigitalPoint1") instructs the script to search for a point named 'Digital Point1' that is stored in the same group as the Mimic that contains the script. If the script locates a suitable point, the reference is returned as a ServerObject.
  • objPoint.Interface.Override 10 instructs the script to access the Override method of the item that is referenced by the ServerObject that is stored in the objPoint variable. To access the Override method, the script has to use the ServerObject's Interface property. The number 10 is the parameter for the Override i.e. the script overrides the 'Digital Point1' point to a value of 10.

Example 2: Calling an Aggregate

The following example is used to call the historic aggregate on a point:

Set ObjPoint = Server.FindObject(".Main Valve")
ObjPoint.Interface.Historic=True
ObjPoint.Interface.Historic.Compress = 1

Where:

  • Server.FindObject(".Main Valve") is used to locate the database item named 'Main Valve'. In this case, the 'Main Valve' item is a point. The ServerObject that is returned by the FindObject function is stored in the ObjPoint variable.
  • ObjPoint.Interface.Historic=True is used to set the point's historic setting to enabled. The Interface property is used to access the point's Historic aggregate (and True means it is set to Enabled).
  • ObjPoint.Interface.Historic.Compress = 1 is used to enable the compression feature for the point's historic data. The Interface property is used to access the Compress property of the point's Historic aggregate (and 1 sets the Compression feature to enabled).

For a more detailed example of a script being used to call an aggregate, see Using a Script to Access Aggregates.

Example 3: Reading a Value

The following script displays a message box that contains the Current Quality Description value of a database point:

Set objTankLevel = Server.FindObject("Tanks.Tank Level")

MsgBox "Tank Level Quality = " &objTankLevel.Interface.CurrentQualityDesc

Where:

  • objTankLevel is the name of the variable that stores the ServerObject that is returned by the FindObject function.
  • Server.FindObject("Tanks.Tank Level") instructs the script to search for a point named 'Tank Level' that is located in a Group named 'Tanks'. It returns a ServerObject that references the 'Tank Level' point.
  • MsgBox "Tank Level Quality = " &objTankLevel.Interface.CurrentQualityDesc instructs the script to display a message box that contains the message 'Tank Level Quality = x' where x is the value for the point's CurrentQualityDesc property. The CurrentQualityDesc property is accessed via the ServerObject's Interface property.


Scripting Guide - ServerObject.IsGroup (Server and ServerObject Functions and Properties)

ServerObject.IsGroup

The ServerObject.IsGroup property allows a script to determine whether the database item that is referenced by the ServerObject is a Group (Group database item).
Syntax | ServerObject.IsGroup
Description | Indicates whether the database item that is referenced by the ServerObject is a Group.
Arguments | None.
Returns | Group {Boolean} If the IsGroup returns a True value, the database item referenced by the ServerObject is a Group; if it returns a False value, the ServerObject references a different type of database item.

Example:

The following script searches for an item. If the item it searches for is a Group, the script performs an additional search, executes a method, and displays a message box.

Set objTanks = Server.FindObject("Tanks")
If objTanks.IsGroup = True Then
Set objLevelPoint = objTanks.FindChild("Tank Level")
objLevelPoint.Interface.Override 50
MsgBox "Point Overridden to " &objLevelPoint.Interface.CurrentValue
End If

Where:

  • objTanks is the name of the variable that stores the ServerObject that is returned by the FindObject function.
  • Server.FindObject("Tanks") instructs the script to search for a database item named 'Tanks'.
  • If objTanks.IsGroup = True Then instructs the script to execute the next line if the ServerObject stored in the objTanks variable references a Group database item.
  • Set objLevelPoint = objTanks.FindChild("Tank Level") instructs the script to search for an item named 'Tank Level'. It searches for the item in the Group that is referenced by the ServerObject that is stored in the objLevelPoint variable.
  • objLevelPoint.Interface.Override 50 instructs the script to access the Override method of the 'Tank Level' item that is referenced by the ServerObject that is stored in the objLevelPoint variable. The 50 is the parameter for the Override—the 'Tank Level' point is overridden to have a value of 50.
  • MsgBox "Point Overridden to " &objLevelPoint.Interface.CurrentValue sets the script to display a message box after the 'Tank Level' point has been overridden. The message box contains the message 'Point Overridden to x' where x is the CurrentValue of the database item that is referenced by the ServerObject that is stored in the objLevelPoint variable i.e. the CurrentValue of the 'Tank Level' point.

If the script finds an item named 'Tanks' that is not a Group, it will not attempt to find the 'Tank Level' point and will not perform an Override. Similarly, it will not display a message box.


Scripting Guide - ServerObject.Parent (Server and ServerObject Functions and Properties)

ServerObject.Parent

The ServerObject.Parent property allows a script to access the properties of the parent database item
Syntax | ServerObject.Parent
Description | Identifies the parent item (Group) of the database item that is referenced by the ServerObject.
Arguments | None.
Returns | Value {variant}. When reading a property value, the Parent property returns a value. The value is a variant (string, integer, Boolean etc. depending on the type of value being read).

Example:

The following script displays a message box that contains the FullName value of the Group that contains the Mimic in which the script is stored:

Set objHomeMimic = Server.ThisObject
MsgBox "Parent Group = " &objHomeMimic.Parent.FullName

Where:

  • objHomeMimic is the name of the variable that stores the ServerObject that is returned by the ThisObject function.
  • Server.ThisObject instructs the script to search for the Mimic that contains the script. It returns a ServerObject that references the Mimic.
  • MsgBox "Parent Group = " &objHomeMimic.Parent.FullName instructs the script to display a message box that contains the message 'Parent Group = x' where x is the FullName value of the Group that is referenced by the ServerObject stored in the objHomeMimic variable. The FullName property of the parent Group is accessed via the ServerObject's Parent property.

So, when the script is executed, it displays a message box that shows the FullName value of the Group that contains the Mimic (that stores the script).


Scripting Guide - ServerObject.Children (Server and ServerObject Functions and Properties)

ServerObject.Children

The ServerObject.Children property allows a script to collect all items in a database Group so that it can interact with each 'child' item in the Group in turn.
Syntax | ServerObject.Children
Description | Collects the items in a Group, allowing the script to interact (read, write, issue controls etc.) with each item in a Group in turn.
Arguments | None.
Returns | None.

Example:

In this example, the ServerObject.Children property is used to allow a script to override each point in a group named 'Pipeline Controls' to a value of 50:

Set objValveGrp = Server.FindObject("Pipeline Controls")
If Not(objValveGrp Is Nothing) Then
For Each Point In objValveGrp.Children
If Point.Interface.TypeName = "CPointAlgManual" Then
If Point.Interface.OverrideAllowed Then
Point.Interface.Override 50
End If
End If
Next

End If

Where:

  • objValveGrp is the name of the variable that stores the ServerObject that is returned by the FindObject function.
  • Server.FindObject("Pipeline Controls") instructs the script to search for a database item named 'Pipeline Controls'.
  • If Not(objValveGrp Is Nothing) Then instructs the script to perform the subsequent actions only if the objValveGrp variable contains a ServerObject i.e only proceed with the script actions if the 'Pipeline Controls' item is found.
  • For Each Point In objValveGrp.Children instructs the script to perform the actions on each point that is a child of the Group referenced by the ServerObject stored in the objValveGrp variable. So, the script should only perform the actions on points in the 'Pipeline Controls' Group.
  • If Point.Interface.TypeName = "CPointAlgManual" Then instructs the script to only perform the subsequent actions on those points that have a TypeName property value of "CPointAlgManual' i.e. only perform the actions on analog points. This line is required so that the script will work if there are digital points in the 'Pipeline Controls' Group (it will ignore the digital points).
  • If Point.Interface.OverrideAllowed Then instructs the script to only perform the subsequent actions on those analog points that have an OverrideAllowed property value set to True i.e. those points that have Overrides enabled on their Forms. This line is needed so that the script can ignore those analog points that have Overrides disabled.
  • Point.Interface.Override 50 instructs the script to override the analog points (that have Overrides enabled) to a value of 50.
  • Next sets the script to repeat the process for the next analog point in the Group.


Scripting Guide - ServerQuery Properties (Server and ServerObject Functions and Properties)

ServerQuery Properties

The ServerQuery that is returned by the Server.Query property represents the result set of the SQL Query and has the following properties:

  • ServerQuery.ColumnCount
  • ServerQuery.ColumnNames
  • ServerQuery.RowCount
  • ServerQuery.Rows
  • ServerQuery.Error
  • ServerQuery.ErrorMessage.


Scripting Guide - ServerQuery.ColumnCount (Server and ServerObject Functions and Properties)

ServerQuery.ColumnCount

The ServerQuery.ColumnCount property returns the total number of columns in the Query that is returned by the Server.Query property.
Syntax | ServerQuery.ColumnCount
Description | Returns the total number of columns in the SQL Query that is returned by the Server.Query property (see Server.Query) The ColumnCount property is useful when the number of columns returned by the query is unknown.
Arguments | None.
Returns | Count {integer}. The count is the total number of columns in the Query that is returned by the Server.Query property.

For an example that shows how the ServerQuery.ColumnCount property can be used, please refer to Server.Query.


Scripting Guide - ServerQuery.ColumnNames (Server and ServerObject Functions and Properties)

ServerQuery.ColumnNames

The ServerQuery.ColumnNames property returns the names of the columns that are returned for the Server.Query property.
Syntax | ServerQuery.ColumnNames
Description | Returns the names of the columns in the SQL Query that is returned by the Server.Query property (see Server.Query).
Arguments | None.
Returns | Names {array of strings}. The names of the columns in the Query that is returned by the Server.Query property.

For an example that shows how the ServerQuery.ColumnNames property can be used, please refer to Server.Query.


Scripting Guide - ServerQuery.RowCount (Server and ServerObject Functions and Properties)

ServerQuery.RowCount

The ServerQuery.RowCount property returns the total number of rows in the Query that is returned by the Server.Query property.
Syntax | ServerQuery.RowCount
Description | Returns the total number of rows in the SQL Query that is returned by the Server.Query property (see Server.Query).
Arguments | None.
Returns | Count {integer}. The count is the total number of rows in the Query that is returned by the Server.Query property.

For an example that shows how the ServerQuery.RowCount property can be used, please refer to Server.Query.


Scripting Guide - ServerQuery.Rows (Server and ServerObject Functions and Properties)

ServerQuery.Rows

The ServerQuery.Rows property returns the values contained in the rows that are returned for the Server.Query property.
Syntax | ServerQuery.Rows
Description | Returns the values of the rows in the SQL Query that is returned by the Server.Query property (see Server.Query).
Arguments | None.
Returns | Rows {2 dimensional array of variants}. The values of the rows in the Query that is returned by the Server.Query property.

For an example that shows how the ServerQuery.Rows property can be used, please refer to Server.Query.


Scripting Guide - ServerQuery.Error (Server and ServerObject Functions and Properties)

ServerQuery.Error

The ServerQuery.Error property indicates whether the SQL Query for the Server.Query succeeded or failed.
Syntax | ServerQuery.Error
Description | Indicates whether the SQL Query for the Server.Query property has failed.
Arguments | None.
Returns | Error {Boolean}. Returns a True value if the SQL Query for the Server.Query property failed or a False value if the SQL Query was successful (see Server.Query).

For an example that shows how the ServerQuery.Error property can be used, please refer to Server.Query.


Scripting Guide - ServerQuery.ErrorMessage (Server and ServerObject Functions and Properties)

ServerQuery.ErrorMessage

The ServerQuery.ErrorMessage property provides a brief description of the cause of a failed SQL Query for the Server.Query.
Syntax | ServerQuery.ErrorMessage
Description | Describes the cause of a failed SQL Query for the Server.Query property (see Server.Query). Typically, SQL error messages are due to the syntax of the SQL Query being incorrect.
Arguments | None.
Returns | Message {String}.

For an example that shows how the ServerQuery.ErrorMessage property can be used, please refer to Server.Query.

Further Information

Constructing SQL Queries: see SQL Query Structure in the ClearSCADA Guide to Lists.


Scripting Guide - User Messaging Functions

User Messaging Functions

ClearSCADA includes an in-built user messaging system that allows users to send messages to other logged on users. By default, these messages are processed by ClearSCADA and are displayed in standard message dialog boxes on the recipients’ clients. However, by using the user messaging function and VB Script, you can define different functionality that will occur when a client receives a user message.

There is a single user messaging function:

  • OnMessageReceived


Scripting Guide - OnMessageReceived (User Messaging Functions)

OnMessageReceived

ClearSCADA includes a built-in user messaging system—a user can select the Notify User action and send a message to any other logged on user. By default, the message is displayed in a standard message dialog box on the recipient’s client. However, by using the OnMessageReceived function in the global script for a client, you can instruct the client to perform other functions when a message is received.

The OnMessageReceived function can only be used in the Global Script for a client. When any user that is logged on via that client receives a message (from another user), ClearSCADA checks to see if the client’s global script contains the OnMessageReceived function. If it does, the OnMessageReceived function is performed and the message is handled in the way defined by the script. If the global script does not contain the OnMessageReceived function, the message is displayed in a standard message dialog box.

A common use for the OnMessageReceived function is to create customized dialog boxes for user messages. These customized dialog boxes are displayed instead of the standard message boxes. However, by using VBScript, it is possible to create more complex procedures for user messages, for example, it is possible to create message boxes that contain user input fields that allow the recipient of a message to send a specific type of response to the sender. This response can then be used to trigger functions on the sender’s client.

Syntax

OnMessageReceived (UserName, Title, Message)

Description

Instructs ClearSCADA to handle incoming user messages in the manner defined in the client’s global script.

Arguments

UserName {string}

The User Name argument allows ClearSCADA to include the user name of the message sender in the message display.

Title {string}

The Title argument allows ClearSCADA to include the message’s title in the message display.

Message {string}

The Message argument allows ClearSCADA to include the body of the message in the message display.

You have to enter UserName, Title and Message as the actual arguments. ClearSCADA will take the string values for the UserName, Title and Message from the message that is received.

Returns

Nothing. There is no return value.

Example: Displaying a User Message in a Customized Dialog Box

In this example, a user named J Thomas sends a message to a user named M Noble. The OnMessageReceived function is used in the global script on M Nobel’s client to instruct ClearSCADA to display the message in a customized dialog box.

On the client that is used by M Noble, the Global Script contains the OnMessageReceived function and defines the settings for the custom dialog box:

Sub OnMessageReceived( UserName, Title, Message )
MsgBox "Message from " & UserName & vbCRLF & Message, vbOK, Title
End Sub

Working on a different client, the user J Thomas uses the Notify User action to send a message to M Noble. J Thomas defines the title and body of the message and then sends it to M Noble.

When the message arrives at M Noble’s client, ClearSCADA detects that the client’s global script contains the OnMessageReceived function and so the message will not be displayed in the standard, default dialog box. Instead, ClearSCADA handles the message in the manner defined in the global script - it takes the UserName (the name of the sender is included with the message automatically), Title, and Message (body) of the incoming message and displays it in a message box that contains “Message from” and the sender’s User Name on one line and the message body on another line, with OK and Cancel buttons below.

If the OnMessageReceived function had not been present in the client’s global script, the message from J Thomas would have been displayed in the default message dialog box (shown below):

Further Information

Notify User: see Send a Message to a User on another ViewX Client in the ClearSCADA Guide to ViewX and WebX Clients.


Scripting Guide - Script Libraries

Script Libraries

Script libraries are scripts that are stored in accessible items in the database. They can be referenced by any Mimic or Alarm Banner script and are designed to reduce the amount of time and effort required to create scripts that contain the same code. For example, if you create a Script Library that provides access to a Change Password Window, you can reference the Script Library from multiple Mimic scripts—the Mimics that reference the Script Library will be able to use the Change Password script, but do not need to contain the code of the Change Password script. This means that the amount of coding required for the Mimic scripts is significantly reduced as the code for the Change Password script only ever needs to be entered once (in the Script Library).

In this section, we explain how to:

  • Create a Script Library
  • Reference a Script Library in a Script.


Scripting Guide - Create a Script Library (Script Libraries)

Create a Script Library

To create a Script Library:

  1. In the Database Bar, right-click on the Group or System that is to contain the Script Library item.
    A context sensitive menu is displayed.
  2. Select the New option to display a further menu.
  3. Select the Other option to display a further menu.
  4. Select the Script Library option to create a Script Library database item. The Script Library database item is added to the database tree structure and is selected, ready for you to define its name.
  5. Enter a suitable name for the Script Library.
  6. Double-click on the Script Library item or right-click on it and select the Edit option to display the Script Editor for the Script Library.
  7. Type in the script for the Script Library.

ATTENTION: Be careful when naming functions in your scripts and script libraries. The names of the functions should be unique so that they do not clash with the names of functions in other script libraries (that may be used in conjunction with your script). If the function names are the same, ClearSCADA will only be able to use one of the functions.

  8. Save the Script Library.

The Script Library that you have created can now be referenced by any script of the same language.

Further Information

Reference a Script Library in a Script.


Scripting Guide - Reference a Script Library in a Script (Script Libraries)

Reference a Script Library in a Script

When you have created one or more Script Libraries, you can reference them in your scripts. The reference allows your Mimic or Alarm Banner script to run the code that is stored in the Script Library as if the code were included in the Mimic or Alarm Banner script.

Example:

Ten Mimics require a script that causes a Form with two user-entry fields to be displayed. Rather than re-enter the code for creating a Form with two fields ten times, the Form with two fields code is saved in a Script Library. Then a reference to the Script Library is added to the scripts for each of the ten Mimics.

One of the Mimics is displayed and its script runs. This causes a Form with two user-entry fields to be displayed, as the Mimic script runs in the same way as if it actually contained the code that is stored in the referenced Script Library. Every one of the ten Mimics will behave in the same manner—they will run their own scripts as if they contain the code that is in the Script Library.

To reference a Script Library in a script:

  1. Display the Script Editor for the script (see Display the Script Editor for the Alarm Banner or see Display the Script Editor for a Mimic).
  2. Right-click on the background of the Script Editor to display a context sensitive menu. (Alternatively, you can select the Edit menu).
  3. Select the Libraries option to display the Libraries window.
  4. Use the Libraries window to select the Script Libraries that you want to reference in your script:
  • Select the check box next to the name of a Script Library to reference the Script Library in your script.
  • Clear the check box next to the name of a Script Library to remove the reference to the Script Library from your script.

You can now reference the functions in the Script Library in your script. To do this, you can reference the functions by name in the same way that you would reference any function in VBScript.

If you are creating a Mimic script, you can also choose the functions from the Function combo box which is available when you configure a Script pick action (see Associate a Mimic Script with a Script Pick Action).


Scripting Guide - Debugging a Script

Debugging a Script

You can use ClearSCADA’s Debug feature to check the validity of your script. This is a useful way of locating syntax errors and mistakes in your code that cause unexpected results.

The Debug feature is available for use with Mimic scripts and Alarm Banner scripts, and to access it you will need to have the Debug toolbar on display (select View>Toolbars>Debug Bar if it is not shown).

In this section we explain how to use the:

  • Debug Menu
  • Debug Toolbar.

We also provide details on how to:

  • Debug a Script
  • Report a Script Failure - Disable CompressWebRequests.

NOTE: The Debug feature is only available after you have installed the Microsoft Windows scd 10en.exe feature. This feature is provided as a Third Party application on your ClearSCADA CD/DVD.


Scripting Guide - Debug Menu (Debugging a Script)

Debug Menu

You can use the Debug menu to access the various debugging options. The Debug menu is only displayed when you:

  1. Display a Mimic that contains a script
  2. Enable Debug Mode by selecting the Debug Mode button on the Debug toolbar.

Or:

  1. Display an Alarm Banner script
  2. Enable Debug Mode by selecting the Debug Mode button on the Debug toolbar.

The Debug menu contains these options:

  • Debug Mode—Activates and deactivates the debugger. When the debugger is deactivated, the Debug menu is not available. You can reactivate the debugger by pressing a Ctrl key and the F5 key simultaneously or by selecting the Debug Mode toolbar button.
  • Continue—Proceeds with the script from the breakpoint onwards.
  • Stop Debugging—Ends the debugging session.
  • Break—Use to interrupt a script that is running and put the script into debug mode. This is useful if a script is taking a long time to run or is unable to complete.
  • Step Over—Performs the current line then proceeds to the next line.
  • Step In—Enters a function that is within the script.
  • Step Out—Performs the current function then exits to the call level of the script.
  • Run to Cursor—Performs the script up to the line at which the cursor is positioned.
  • Set Next Statement—Skips to the statement that is on the line that you select. The lines of script between the previous statement and the selected statement are ignored.
  • Breakpoints—You can use these options to edit the breakpoints:
  • Insert/Remove Breakpoint—Adds or removes a breakpoint at the selected line. You need to place the cursor at the required line before selecting this option.
  • Enable/Disable Breakpoint—Activates or deactivates the selected breakpoint. This is useful when testing the script as it allows you to keep a breakpoint in the script even though it is to be inactive for one run of the script. The breakpoint can then be enabled for the next run.
  • Remove All Breakpoints—Deletes each of the breakpoints in the script.
  • Disable All Breakpoints—Disables each of the breakpoints in the script. The breakpoints remain in their positions but are not active.
  • Edit Breakpoints—Displays the Breakpoints window which you can use to add a breakpoint, change the line number of a breakpoint, remove a breakpoint, and jump to the line of script on which the breakpoint is used.
  • Show Next Statement—Moves the cursor to the next statement in the script.

There is also a Debug toolbar that contains buttons for the debugging options (see Debug Toolbar).


Scripting Guide - Debug Toolbar (Debugging a Script)

Debug Toolbar

You can use the Debug toolbar to access the various debugging options. The Debug toolbar is not shown by default, but you can display it by following this procedure:

  1. Select the View menu
  2. Select the Toolbars option
  3. Select the Debug Bar option.

The Debug toolbar has buttons that correspond to the options in the Debug Menu.


Scripting Guide - Debug a Script (Debugging a Script)

Debug a Script

You can use the ClearSCADA Debug feature to check for errors in your scripts. They are also useful when trying to establish why a script is producing unexpected results, even though it has the correct syntax. The way in which you need to use the Debug feature varies slightly according to whether your script contains a coding error.

If you run your script and it contains errors:

  1. When the script runs, an error dialog box is displayed. It informs you which line of the script contains the first error and prompts you to run the script in Debug mode.
  2. Select the Yes button to run the script in Debug mode.
    The script runs in Debug mode and breaks on the line that contains the first error.
  3. Remove the error by changing the code appropriately. When your script contains no errors, it will run successfully and you will no longer be prompted to run the script in Debug mode.

If you run your script and it runs successfully without errors but doesn’t produce the expected results:

  1. Enter Debug mode for the script by selecting the Debug Mode button on the Debug Toolbar. If you are debugging a Mimic script, you will need to display the Mimic in Run mode before selecting the Debug Mode button.
    The script is displayed in Debug mode.
  2. Use the Insert Breakpoint toolbar button to insert breakpoints where you suspect there may be problems in the script. Alternatively, you can select Breakpoints>Insert/Remove Breakpoint from the Debug menu.
    The debugger will break at the breakpoints in turn.
  3. Trigger the script to run.
  • For Mimics, the script will either run when you first display the Mimic or will run when you select an appropriate Mimic script pick action.
  • For the Alarm Banner, the script will run when you right-click in the Alarm Banner (if a breakpoint is inserted on the line containing BuildAlarmMenu) or when you select one of the menu options added to the Alarm Banner’s context sensitive menu by the script.
  4. Use the Step Over/Step In/Run To toolbar buttons to insert breakpoints to step through the code. (Alternatively, you can use the similarly named options in the Debug menu). By setting ClearSCADA to run segments of the code and then breaking, you may be able to determine where the unexpected results are occurring and then you can make appropriate adjustments.

For more information on the options represented by the Debug toolbar buttons, see Debug Menu.

If you experience continued problems with your script and you have checked it and debugged it thoroughly, you can report the problem to Schneider Electric (see Report a Script Failure - Disable CompressWebRequests).

NOTE: The Debug feature is only available after you have installed the Microsoft Windows scd 10en.exe feature which is provided as a Third Party application on your ClearSCADA CD/DVD.


Scripting Guide - Report a Script Failure - Disable CompressWebRequests (Debugging a Script)

Report a Script Failure - Disable CompressWebRequests

If one of your scripts is not running or behaving as expected, you should first check that the script uses the correct syntax and is correctly coded (see Debug a Script).

If your script is correct and is still producing errors or providing unexpected results, there may be an internal error. Although rare, this can sometimes be noticed when client-side scripts are using server methods (are accessing the server). In this situation, you should contact Schneider Electric for expert assistance.

To help us diagnose your scripting problem, you should do the following:

  1. Use the Server Status Tool to enable Web Server Data logging (access the Server Status Tool, expand the Logging branch in the General section, right-click on the Web Server Data entry in the list and select the Enable option). For more information, see Logging and Monitoring in the ClearSCADA Guide to Server Administration.
  2. On the client PC that runs the script, log on to Windows as an administrator level user then set the CompressWebRequests registry setting to False:
  1. Select the Microsoft Windows Start button, then the Run option, then enter Regedit in the Open field.
    Regedit runs.
  2. Expand the tree structure to locate the registry key settings at:
HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\ViewX\
CompressWebRequests
  3. Right-click on the CompressWebRequests registry key, then select the Modify option to display the Edit String window.
  4. Change the Value data entry to False then select the OK button.
  3. In ViewX (or WebX if you are using a Mimic script), trigger the script to run again. This will cause a log file to be generated at the server. The log file will contain details of the incoming and outgoing requests and responses.
  4. Repeat steps 1 and 2, only this time select the Disable option for the Web Server Data entry and change the Value data for the CompressWebRequests registry key back to True.
  5. Locate the latest log file generated at the server.
  6. Send the latest log file and a copy of the script to Schneider Electric. We will also need a explanation of what you were trying to achieve with the script and a description of the type of errors you were experiencing. Our expert engineers will then use the log files, your script, and the information you provided to determine the cause of the problem and provide a solution.

ATTENTION: Setting the Web Server Data logging to Enable and changing the CompressWebRequests registry key to False will generate a large amount of logging on busy systems. For this reason, you should disable Web Server Data logging and set the CompressWebRequests registry key to True as soon as you have run the script and caused the server to generate a log file.


Server Administration Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Server Administration Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Server Administration Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Server Administration Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Server Administration Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Server Administration Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to use the Server Configuration Tool. Available on ClearSCADA servers, the Server Configuration Tool contains a variety of settings that have a system-wide effect, including:

  • Partners settings to define the number of servers and the relationships between servers
  • Custom fields
  • Alarm severity ranges
  • Historic settings for keeping records of old data
  • Archiving settings for making back-ups of historic data
  • Security settings for controlling access to ClearSCADA.

For information on the settings that can be defined from the Server Configuration Tool, see Welcome to the Server Administration Guide.


Server Administration Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by system administrators who are responsible for setting up and managing the ClearSCADA system.


Server Administration Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see see Operating Systems.

Further Information

Server Requirements:see System Server Requirements

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations:see Recommended PC Configurations.


Server Administration Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to the Database

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Logic

ClearSCADA Guide to Security

ClearSCADA Guide to Mimics

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Client Administration.


Server Administration Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Server Administration Guide - Welcome to the Server Administration Guide

Welcome to the Server Administration Guide

The Server Administration Guide is designed to provide information to the users that configure the ClearSCADA server settings. It describes how to use the ClearSCADA Server Configuration Tool and ViewX to setup the ClearSCADA server and specific features such as Archiving and disk space monitoring. It also describes how to use some of the features of the ClearSCADA Server Status Tool.

Server Configuration Tool

The ClearSCADA Server Configuration Tool is designed to be used by administrator level users. We regard server administrators as high level users that have knowledge of some configuration tasks as well as installing ClearSCADA and setting up the ClearSCADA server(s). These users should understand the system setup and server arrangements.

If you are unfamiliar with the server configuration process, we recommend that you complete each section of the Server Administration Guide in turn so that you learn about the available features. Before you begin, you should familiarize yourself with the Operating Systems and Operational Limitations - Server.

When you are ready to configure your ClearSCADA server, you can use the Partners settings to set up the server arrangement. For more information, please refer to the relevant section in the System Architectures chapter:

  • Lone Server Architecture
  • Hot-Standby Pair Architecture
  • Hot-Standby Pair with Sentinel Server Panel Architecture
  • Triple Standby Architecture.

If you are familiar with the server configuration process, you can refer to the section that describes the settings for which you require information. A list of the settings and the corresponding sections is included in Understanding the ClearSCADA Server Configuration Tool.


Server Administration Guide - System Server Requirements (Welcome to the Server Administration Guide)

System Server Requirements

The following sections describe the recommended computer specifications for ClearSCADA:

  • Servers and Desktop Computers
  • Screen Resolution
  • Disk Drives and RAID Arrays
  • Operating Systems
  • Web Browser Support
  • Operational Limitations - Server.


Server Administration Guide - Servers and Desktop Computers (Welcome to the Server Administration Guide)

Servers and Desktop Computers

There are many factors to consider when purchasing computers for use as ClearSCADA servers, including the expected activity of the system, the amount of historic data required, and the number of database items. While the requirements for each system will vary according to the demands placed on the system, we do make the following recommendations:

  • For systems with 10,000 to 20,000 database items and 1 to 2 clients, desktop PCs will be sufficient. Systems of this size are regarded as small systems.
  • For systems with 20,000 to 50,000 database items and 2 to 5 clients, desktop PCs may be sufficient but this is dependent on the purpose of the system. If the system is a very active system with a high amount of through traffic, server class computers may be required. This is also the case if there are more than 5 clients.
  • For systems with 50,000 or more database items and 5 or more clients, server class computers are required.

When choosing the appropriate type of computers to use, you also need to consider the use of Disk Drives and RAID Arrays.


Server Administration Guide - Screen Resolution (Welcome to the Server Administration Guide)

Screen Resolution

The minimum recommended screen resolution for ClearSCADA is 1024x768.


Server Administration Guide - Disk Drives and RAID Arrays (Welcome to the Server Administration Guide)

Disk Drives and RAID Arrays

For optimal performance, you should aim to have three high performance disks (or preferably, three RAID arrays):

  • One disk to store the operating system program installation and ClearSCADA database
  • One disk to store the historic data files
  • One disk to store the Event Journal data.

This allows for faster access times as each disk is dedicated to a single purpose. It also reduces the chances of disk fragmentation as it becomes less likely that any of the disks will have less than 50% of their capacity available. Of course, with high performance disks or RAID arrays, this architecture becomes even more efficient.

However, if you cannot implement a high performance system with three RAID arrays or high performance disks, you can use the same principles to take advantage of your existing hardware. By separating the a highly active directory from the other parts of your system, you should be able to improve the disk access speed (and therefore, system performance).

If your system only has two disks, you need to determine which of the two directories has the highest level of activity - the Historic directory or the Event Journal directory. To do this:

  1. Access the Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to Server Status) and display the Historic>Historian statistics.
  2. Examine the Total File entries for the Event data and the Raw data:
  • If the total number of Event data files is significantly higher than the total number of Raw data files, you should move the Event Journal directory to a separate disk.
  • If the total number of Raw data files is significantly higher than the total number of Event data files, you should move the Historic data directory to a separate disk.
  • If the total number of Raw data file and Event data files are not significantly different, you can choose whether you want to move Historic data or Event Journal data to another disk.
  3. Change the location of the files by using the System Configuration>Location settings on the Server Configuration Tool (see Locations of the Database Folders).

If your system only has a single disk, you may experience slow performance due to an excessive amount of data needing to be written or read on the disk at the same time. This will depend on the amount of activity on your system and the size of the system as well as the type of disk being used. While partitioning the disk can have some benefits, they are negligible when compared to the effects of adding another physical disk. Partitioning the disk correctly also requires an expert knowledge of partitioning and can be time consuming. Using multiple disks will have a much more noticeable effect on your system performance than partitioning a disk. So if required, you can improve performance by adding separate physical disks. When you have added one or two separate physical disks, you can then move the Historic files and/or Event Journal files to the new disks.

If you can only use a single disk system, you may be able to improve performance by investing in a higher specification disk. At the time of writing - January 2008 - we make the following recommendations:

  • For desktop PCs, we recommend hard disks with a seek time of 4 ms and spindle speed of 10,000 rpm as high performance.
  • For a high performance enterprise class or RAID addition class disk, we recommend disks with a seek time of 3 ms and spindle speed of 15,000 rpm.


Server Administration Guide - Operating Systems (Welcome to the Server Administration Guide)

Operating Systems

ClearSCADA can be installed on 32 bit or 64 bit computers:

  • 32 Bit
  • 64 Bit.

Systems running on server hardware need to use server operating systems such as Windows Server 2008, or Windows Server 2003. Server operating systems are designed for servicing entire systems rather than individual computers or small networks. For this reason, they are better suited for larger ClearSCADA systems with more than two clients.

Systems running on desktop hardware need to run desktop operating systems that are designed for user interaction on the computer on which they are installed. For ClearSCADA, the following operating systems can be used:

  • Windows 7
  • Windows Vista
  • Windows XP

ATTENTION: Windows XP, Windows Vista, and Windows 7 should not be used for servers with more than two clients. This is because the TCP/IP security measures in these operating systems can cause significant delays.

32 Bit

ClearSCADA can be installed on computers using the following operating systems:

Server Hardware

  • Windows Server 2008 (Standard and Enterprise editions) - initial release/Service Pack 2
  • Windows Server 2003 Release 2 (Standard and Enterprise editions) - Service Pack 2
  • Windows Server 2003 (Standard and Enterprise editions) - Service Pack 2.

Desktop Hardware

  • Windows 7 (Professional and Ultimate editions) - initial release, and Service Pack 1
  • Windows Vista (Business and Ultimate editions) - Service Pack 1, and Service Pack 2
  • Windows XP (Professional edition) - Service Pack 3.

ClearSCADA also requires Internet Explorer 6, Internet Explorer 7, Internet Explorer 8, or Internet Explorer 9 (see Web Browser Support). Other browsers are not supported.

NOTE: Windows Server 2008 does not support Crystal Reports XI Release 2.

64 Bit

ClearSCADA can be installed on computers using the following operating systems:

Server Hardware

  • Windows Server 2008 Release 2 (Standard and Enterprise editions) - initial release/Service Pack 1
  • Windows Server 2008 (Standard and Enterprise editions) - initial release/Service Pack 2
  • Windows Server 2003 Release 2 (Standard and Enterprise editions) - Service Pack 2
  • Windows Server 2003 (Standard and Enterprise editions) - Service Pack 2.

Desktop Hardware

  • Windows 7 (Professional and Ultimate editions) - initial release, and Service Pack 1
  • Windows Vista (Business and Ultimate editions) - Service Pack 1, and Service Pack 2.

ClearSCADA also requires Internet Explorer 6, Internet Explorer 7, the 32-bit version of Internet Explorer 8, or the 32-bit version of Internet Explorer 9 (see Web Browser Support). Other browsers are not supported.

NOTE: Windows Server 2008 and Windows Server 2008 Release 2 do not support Crystal Reports XI Release 2.


Server Administration Guide - Web Browser Support (Welcome to the Server Administration Guide)

Web Browser Support

ClearSCADA’s web interface, WebX, uses Microsoft’s ActiveX Controls technology to display Mimics, Lists, Trends etc. As ActiveX Controls are exclusive to Microsoft, this means ClearSCADA supports:

  • Internet Explorer 6
  • Internet Explorer 7
  • Internet Explorer 8
  • Internet Explorer 9.

WARNING

unexpected behavior of application (internet explorer 9).

There is a known issue with Internet Explorer 9’s Cross-Site Scripting (XSS) Filter that can cause Internet Explorer 9 to ‘hang’. This only applies when:

  • Using IE9 to connect to ClearSCADA over the Internet
  • Using IP addresses in the URL for the ClearSCADA server
  • The default security settings for the Local Intranet zone have been modified.

For more information about this issue and instructions on how to prevent or correct this issue, see Internet Explorer 9 XSS Filter Issue - ‘Hanging’.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

Internet Explorer 9 XSS Filter Issue - ‘Hanging’

A bug in Internet Explorer 9 may cause ‘hanging’ - IE9 will ‘freeze’ and be unable to display the requested information. This relates to a problem with IE9’s Cross-Site Scripting (XSS) filter and only occurs if you use WebX to access a ClearSCADA server:

  • Over the Internet
  • Over an Intranet connection where:
  • a node name is used in the URL

and

  • the security settings for the Local Intranet zone have been modified so that the XSS filter is enabled.
  • By using an IP address to reference the ClearSCADA server (rather than a node name).

Typically, the ‘hanging’ occurs when displaying Query lists (including Events Lists) that have complex filters. For example, if you use WebX to display an Events List that has multiple WHERE, AND, OR filters specified in its query, IE9 may hang. The most common scenario where this can happen is if the Display Events action is selected for an object on a Mimic.

There is a simple and effective work around that will allow you to display filtered query lists in WebX. All you need to do is add the connection to the server to the list of Trusted Sites and then disable the XSS Filter setting.

To add a WebX to ClearSCADA server connection to your Trusted Sites:

  1. Using a WebX client, log on to the ClearSCADA server you want to access. You will need to use a Username and Password that is valid for a ViewX User account (and that User account must have suitable permissions to access the server).
  2. Once you have logged on to the server, select Tools>Internet Options to display the IE9 Internet Options dialog.
  3. Select the Security tab.
  4. Select the Trusted Sites icon.
  5. Select the Sites button to display the Trusted Sites dialog.

The URL of the WebX connection to the server should be shown in the Add this website to the zone field.

  6. Add the URL to the list of Trusted Sites:
  • If you use secure URLs (https:), select the Add button. The connection to the ClearSCADA server is now added to your list of Trusted Sites and will be unaffected by the XSS filter issue.
  • If you use non-secure URLs. (http:), you should clear the Require server verification (https:) for all sites in this zone check box. This allows you to add non-secure sites to the Trusted Zone. Then select the Add button to add the connection to the ClearSCADA server to your list of Trusted Sites.
  7. On the Security tab, select the Trusted Sites icon and then select the Custom Level button. This displays the Security Settings dialog.
  8. Scroll down to the Enable XSS Filter setting.
  9. Select Disable for the Enable XSS Filter setting.
  10. Select the OK button.
  11. On the Internet Options dialog, select the Close button.
  12. Repeat this process on each WebX client.

Alternatively, you could access the Custom Level settings for the Internet zone and disable the Enable XSS Filter setting. However, this would apply to all connections over the Internet, not just those to a ClearSCADA server. For this reason, we recommend that you use the Trusted Sites work around as described above.


Server Administration Guide - Operational Limitations - Server (Welcome to the Server Administration Guide)

Operational Limitations - Server

We recommend that your ClearSCADA system complies with the following operational limits:
Parameter | 32 Bit Limit | 64 Bit Limit | Notes
Maximum number of objects (database items) | 150,000 Objects | 900,000 Objects | Exceeding these limits on 32 bit platforms will cause DBServer to run out of virtual address space.
Maximum burst rate of non-historic updates | 10,000 per second | 10,000 per second |
Maximum burst rate of historic data updates | 1,000 per second | 1,000 per second |
Maximum burst rate of alarms and events | 500 per second | 500 per second |
Maximum sustained rate of historic data updates per point | 4 per minute | 4 per minute | Exceeding these limits will create historic files in excess of 1.3MB (the maximum recommended historic file size for standard hardware). This limit can be exceeded provided that care is taken when selecting appropriate hardware and communication links.
Maximum sustained rate of events per journal section (256 Objects) | 1, 650 per hour | 1,650 per hour | Exceeding these limits will create historic files in excess of 1.3MB (the maximum recommended historic file size for standard hardware). This limit can be exceeded provided that care is taken when selecting appropriate hardware and communication links.
Maximum number of historic files | 10,000,000 files | 50,000,000 files | Exceeding these limits on 32 bit platforms will cause DBServer to run out of virtual address space.
Maximum number of historic data records | 6,000,000,000 records | 30,000,000,000 records |
Maximum number of event records | 1,000,000,000 records | 5,000,000,000 records |
Maximum number of alarms | 65,000 alarms | 65,000 alarms |
Maximum number of ViewX clients | 100 | 100 |
Maximum number of WebX clients | 500 | 500 |
Maximum Server to Server Link latency | 150ms | 150ms | Exceeding this limit can result in the servers being unable to synchronize correctly, server timeouts and can also cause slow performance.
Minimum Server to Server link bandwidth | 512 Kbit per second | 512 Kbit per second | 512 Kbit per second is the minimum server-to-server bandwidth for a medium sized system e.g. up to 5,000 points. Larger systems need correspondingly higher bandwidth.

For information on client operational limitations, please see Operational Limitations - Client in the ClearSCADA Guide to Client Administration.


Server Administration Guide - Recommended PC Configurations (Welcome to the Server Administration Guide)

Recommended PC Configurations

The following table lists the recommended PC configurations for a variety of client and server scenarios. In the table, the term ‘object’ refers to a database item whereas ‘point’ refers to a specific type of database item that stores I/O (a database point). Historic points are database points that have the Historic feature enabled.
Application | PC Requirement
Small stand-alone client-server with up to 1000 objects | 2GHz processor, 512MB RAM, 500MB free disk space. Desktop class hardware and operating system.
Small stand-alone client-server with up to 10,000 objects and 1-2 remote clients | 2GHz processor, 3GB RAM, 25GB free disk space. Desktop class hardware and operating system.
Server with 10,000 objects, 5,000 historic points stored for 2 years on-line, 3 or more clients | 2 x 2GHz processor, 2GB RAM, 100 GB free disk space, separate disk for historic data. Server class hardware and operating system.
Server with 50,000 objects, 25,000 historic points stored for 2 years on-line, multiple clients | 2 x 3GHz processor, 4GB RAM, 100 GB free disk space, separate disk for historic data. Server class hardware and operating system. For 32 bit operating systems, the 3GB address space should be enabled.
Server with 100,000 objects, 75,000 historic points stored for 2 years on-line, multiple clients | 4 x 3GHz processor, 6GB RAM, 140GB Raid 5 disk set for operating system and configuration database. 1TB x Raid 5 disk set for historic data. Server class hardware and operating system. For 32 bit operating systems, the 3GB address space should be enabled.
Server with 175,000 objects, 100,000 historic points stored for 2 years on-line, multiple clients | 4 x 3GHz processor, 8GB RAM, 140GB Raid 5 disk set for operating system and configuration database. 2TB x Raid 5 disk set for historic data. 64 bit server class hardware and operating system.
Server with 250,000 objects, 150,000 historic points stored for 2 years on-line, multiple clients | 8 x 3GHz processor, 12GB RAM, 140GB Raid 5 disk set for operating system and configuration database. 4TB x Raid 5 or Raid 0+1 disk set for historic data. 64 bit server class hardware and operating system.
Server with 450,000 objects, 250,000 historic points stored for 2 years on-line, multiple clients | 8 x 3GHz processor, 24GB RAM, 140GB Raid 5 disk set for operating system and configuration database. 4TB x Raid 5 or Raid 0+1 disk set for historic data. 64 bit server class hardware and operating system.

Where multiple CPUs are mentioned in the table (above), multiple core processors can be used for a similar result i.e. a dual core processor can be used in place of two processors.

You need to choose appropriately sized hard disks. We recommend that your hard disks have at least enough space to store double the amount of historic records, event records and configuration changes records you expect your system to generate over a given period. You should also account for how long it will take for your hard disk(s) to become full. For example, if you estimate that your total number of events, historic records, and configuration changes will use 15 GB of disk space over a year, you should use a hard disk that has a minimum of 30 GB (and replace the disk or free space on the disk after approximately 1 year).

For more information on the required desktop and server class operating systems, see Operating Systems.

For information on ViewX and WebX client recommendations, see Client PC Requirements in the ClearSCADA Guide to Client Administration.

NOTE: The typical point to object ratio is around 1:2. So for a system with 50,000 points, this equates to around 100,000 objects. However, ratios vary per system and this should only be regarded as an estimate. Some ratios may require lower or higher specification computers, depending on the actual configuration.

NOTE: You can calculate the amount of disk space you will need by examining the size of each historic record and event journal record, and then multiplying these sizes by the amount of records you want to store.

Further Information

Disk architectures: Disk Drives and RAID Arrays.

Client PC Requirements in the ClearSCADA Guide to Client Administration.

For further information on PC requirements specific to your particular operating system, see the relevant system requirement pages at http://www.microsoft.com


Server Administration Guide - File Locations (Default) (Welcome to the Server Administration Guide)

File Locations (Default)

ClearSCADA installs files in several locations. Some of these files you may need to access during the configuration of your system and so you should familiarize yourself with the default locations.

The following sections detail the default file locations for ClearSCADA on various Windows operating systems:

  • Windows XP File Locations
  • Windows Vista and Windows 7 32 Bit File Locations
  • Windows Vista and Windows 7 64 Bit File Locations
  • Windows Server 2003 32 Bit File Locations
  • Windows Server 2003 64 Bit File Locations
  • Windows Server 2008 32 Bit File Locations
  • Windows Server 2008 64 Bit File Locations.

These are the default file locations—the files on your system may be in different locations, depending on how the system has been installed and configured.

You can change the location of the server files by using the Server Administration Tool. For more information, refer to:

  • Dictionary Settings
  • WebX Settings
  • Logging and Monitoring.


Server Administration Guide - Windows XP File Locations (Welcome to the Server Administration Guide)

Windows XP File Locations

The default file locations for systems running on Windows XP operating systems are:
Data | Default Location
Configuration | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Database
Data (Current Data) | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Database
Historic Data | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Database\History
Event Journal | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Database\Journal
Historic Files | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Database\HisFiles
Data Files | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Database\DataFiles
Archive Index | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Database
Dictionary Files | C:\Program Files\Schneider Electric\ClearSCADA\Dictionary
Server File Base Log | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Logs
Server Exception Dump | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA\Dumps
Web SSL Certificate | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA
Web SSL Private Key | C:\Documents and Settings\All Users\Application Data\Schneider Electric\ClearSCADA
Web Style Sheets and Images | C:\Program Files\Schneider Electric\ClearSCADA\WWW
Installation Files | C:\Program Files\Schneider Electric\ClearSCADA
ViewX Cache | C:\Documents and Settings\All Users\Application Data\ Schneider Electric\ClearSCADA\ViewXCache
User Profile Data | C:\Documents and Settings\<User Name>\Local Settings\Application Data\Schneider Electric\ClearSCADA
Alarm Sounds Cache | C:\Documents and Settings\All Users\Application Data\ Schneider Electric\ClearSCADA\ViewXAlarmSoundCache
Driver Log Files | C:\Documents and Settings\All Users\Application Data\ Schneider Electric\ClearSCADA\Logs\Drivers
IO Logs and Comms Logs | C:\Documents and Settings\All Users\Application Data\ Schneider Electric\ClearSCADA\Logs\Drivers
Driver Upload and Download Data | C:\Documents and Settings\All Users\Application Data\ Schneider Electric\ClearSCADA\Database C:\Documents and Settings\All Users\Application Data\ Schneider Electric\ClearSCADA\Database\Slave

ClearSCADA also adds ClearSCADA Service Manager, ViewX, and ClearSCADA Server Icon to the desktop.


Server Administration Guide - Windows Vista and Windows 7 32 Bit File Locations (Welcome to the Server Administration Guide)

Windows Vista and Windows 7 32 Bit File Locations

The default file locations for 32 bit systems running on Windows Vista or Windows 7 operating systems are:
Data | Default Location
Configuration | C:\ProgramData\Schneider Electric\ClearSCADA\Database
Data (Current Data) | C:\ProgramData\Schneider Electric\ClearSCADA\Database
Historic Data | C:\ProgramData\Schneider Electric\ClearSCADA\Database\History
Event Journal | C:\ProgramData\Schneider Electric\ClearSCADA\Database\Journal
Historic Files | C:\ProgramData\Schneider Electric\ClearSCADA\Database\HisFiles
Data Files | C:\ProgramData\Schneider Electric\ClearSCADA\Database\DataFiles
Archive Index | C:\ProgramData\Schneider Electric\ClearSCADA\Database\
Dictionary Files | C:\Program Files\Schneider Electric\ClearSCADA\Dictionary
Server File Base Log | C:\ProgramData\Schneider Electric\ClearSCADA\Logs
Server Exception Dump | C:\ProgramData\Schneider Electric\ClearSCADA\Logs\Dumps
Web SSL Certificate | C:\ProgramData\Schneider Electric\ClearSCADA
Web SSL Private Key | C:\ProgramData\Schneider Electric\ClearSCADA
Web Style Sheets and Images | C:\Program Files\Schneider Electric\ClearSCADA\WWW
Installation Files | C:\Program Files\Schneider Electric\ClearSCADA
ViewX Cache | C:\ProgramData\Schneider Electric\ClearSCADA\ViewXCache
User Profile Data | C:\Users\AppData\Local\Schneider Electric\ClearSCADA
Alarm Sounds Cache | C:\ProgramData\Schneider Electric\ClearSCADA\ViewXAlarmSoundCache
Driver Log Files | C:\ProgramData\Schneider Electric\ClearSCADA\Logs\Drivers
IO Logs and Comms Logs | C:\ProgramData\Schneider Electric\ClearSCADA\Logs\Drivers
Driver Upload and Download Data | C:\ProgramData\Schneider Electric\ClearSCADA\Database C:\ProgramData\Schneider Electric\ClearSCADA\Database\Slave

ClearSCADA also adds ClearSCADA Service Manager, ViewX, and ClearSCADA Server Icon to the desktop.


Server Administration Guide - Windows Vista and Windows 7 64 Bit File Locations (Welcome to the Server Administration Guide)

Windows Vista and Windows 7 64 Bit File Locations

The default file locations for 64 bit systems running on Windows Vista or Windows 7 operating systems are:
Data | Default Location
Configuration | C:\ProgramData\Schneider Electric\ClearSCADA\Database
Data (Current Data) | C:\ProgramData\Schneider Electric\ClearSCADA\Database
Historic Data | C:\ProgramData\Schneider Electric\ClearSCADA\Database\History
Event Journal | C:\ProgramData\Schneider Electric\ClearSCADA\Database\Journal
Historic Files | C:\ProgramData\Schneider Electric\ClearSCADA\Database\HisFiles
Data Files | C:\ProgramData\Schneider Electric\ClearSCADA\Database\DataFiles
Archive Index | C:\ProgramData\Schneider Electric\ClearSCADA\Database\
Dictionary Files | C:\Program Files\Schneider Electric\ClearSCADA\Dictionary
Server File Base Log | C:\ProgramData\Schneider Electric\ClearSCADA\Logs
Server Exception Dump | C:\ProgramData\Schneider Electric\ClearSCADA\Logs\Dumps
Web SSL Certificate | C:\ProgramData\Schneider Electric\ClearSCADA
Web SSL Private Key | C:\ProgramData\Schneider Electric\ClearSCADA
Web Style Sheets and Images | C:\Program Files\Schneider Electric\ClearSCADA\WWW
Installation Files | C:\Program Files\Schneider Electric\ClearSCADA C:\Program Files (x86)\Schneider Electric\ClearSCADA The installation files for the server and many drivers are installed to the Program Files directory. ViewX and some other drivers are installed to the Program Files (x86) directory.
ViewX Cache | C:\ProgramData\Schneider Electric\ClearSCADA\ViewXCache
User Profile Data | C:\Users\<Server Name>\AppData\Local\Schneider Electric\ClearSCADA C:\Users\<User Name>
Alarm Sounds Cache | C:\ProgramData\Schneider Electric\ClearSCADA\ViewXAlarmSoundCache
Driver Log Files | C:\ProgramData\Schneider Electric\ClearSCADA\Logs\Drivers
IO Logs and Comms Logs | C:\ProgramData\Schneider Electric\ClearSCADA\Logs\Drivers
Driver Upload and Download Data | C:\ProgramData\Schneider Electric\ClearSCADA\Database C:\ProgramData\Schneider Electric\ClearSCADA\Database\Slave

ClearSCADA also adds ClearSCADA Service Manager, ViewX, and ClearSCADA Server Icon to the desktop. ClearSCADA Client Connections is located at C:\Program Files (x86)\Schneider Electric\ClearSCADA.


Server Administration Guide - Windows Server 2003 32 Bit File Locations (Welcome to the Server Administration Guide)

Windows Server 2003 32 Bit File Locations

The default file locations are the same as those used for 32 bit systems running on Windows XP (see Windows XP File Locations).


Server Administration Guide - Windows Server 2003 64 Bit File Locations (Welcome to the Server Administration Guide)

Windows Server 2003 64 Bit File Locations

The default file locations are the same as those used for 64 bit systems running on Windows XP (see Windows XP File Locations).


Server Administration Guide - Windows Server 2008 32 Bit File Locations (Welcome to the Server Administration Guide)

Windows Server 2008 32 Bit File Locations

The default file locations are the same as those used for 32 bit systems running on Windows Vista (see Windows Vista and Windows 7 32 Bit File Locations).


Server Administration Guide - Windows Server 2008 64 Bit File Locations (Welcome to the Server Administration Guide)

Windows Server 2008 64 Bit File Locations

The default file locations are the same as those used for 64 bit systems running on Windows Vista (see Windows Vista and Windows 7 64 Bit File Locations).


Server Administration Guide - Working with the ClearSCADA Server Configuration Tool

Working with the ClearSCADA Server Configuration Tool

When you have started ClearSCADA as a service, you may need to make some alterations to the ClearSCADA server configuration. For example, you may need to change the Partners settings so that the ClearSCADA server is used as part of a multi-server system rather than the default Lone Server arrangement.

To make alterations to the ClearSCADA server configuration, you need to use the various features of the ClearSCADA Server Configuration Tool.

Before you begin to configure the server(s), you should familiarize yourself with the ClearSCADA Server Configuration Tool by referring to these sections:

  1. The Server Icon
  2. Accessing the ClearSCADA Server Configuration Tool.
  3. Understanding the ClearSCADA Server Configuration Tool.


Server Administration Guide - The Server Icon (Working with the ClearSCADA Server Configuration Tool)

The Server Icon

When you install ClearSCADA on a server and run it as a service, the server icon is displayed in the Windows taskbar (at the bottom right-hand side of the screen).

The server icon is shown in the Windows taskbar.

The server icon is displayed in one of 5 colors, depending on its state:

  • Blue—The server is running and is the Main server.
  • Yellow—The server is a Standby server and is in the process of synchronizing with the Main server.
  • Cyan—The server is a Standby server and has synchronized with the Main server.
  • Green—The server is attempting to determine its status (it will change color to indicate it is Main, Standby, or has detected an error).
  • Magenta—The server has detected an error.

If the server icon is magenta, you should investigate the cause of the detected error:

  1. Right-click on the server icon to display a context sensitive menu.

If the context sensitive menu contains the option Start Database, proceed to step ii.

If the context sensitive menu contains the option Invalid Database, proceed to step iii.

If the context sensitive menu contains the option Invalid Metadata, proceed to step iv.

If the context sensitive menu contains the option Invalid Standby Configuration, proceed to step v.

If the context sensitive menu contains the options Database Save Error, Journal Save Error, or Database and Journal Save Error, proceed to step vi.

If the context sensitive menu contains the option Isolated Standby, proceed to step vii.

If the context sensitive menu contains the option Configuration Unlicensed, proceed to step viii.

If the context sensitive menu contains the option Exception Occurred, proceed to step ix.

  2. Select the Start Database option.
    A dialog box is displayed containing information about the error that has been detected:
  • Blank Database—If you are running a new database on a Main server and expect it to be empty, select the Start Database option on the dialog box to continue. If you are working on a Standby Server, you need to check that the Main server is running and is connected correctly before you select the Start Database option—if the Main server is not running, the Standby server will run with the empty database and will switch to Main. When the real Main server connects to the standby that is now Main, the real Main server will switch to Standby and the blank database will overwrite the real database. For this reason, only select the Start Database option on a Standby server if you are certain that the Main server is running and can connect to the Standby server correctly.

When you select the Start Database option, the server will run the empty database and you can access it via ViewX or WebX.

If you expect to run a database that contains database items, select the Stay in Safe Mode option and then check the name and location of your database files. To do this, display the latest log file for the server (see Display a Server Log File) and examine its contents. In the log file, it specifies the location in which the server looks for the database files (ClearSCADAData.dat or ClearSCADA.dat depending on your system build).

Use Windows Explorer to check that your database files are named correctly and are stored in the correct location (rename them or move them if they are incorrectly named or stored in the wrong location). You also need to check that the Windows SYSTEM user has sufficient security permissions to access the database files (ClearSCADA uses the SYSTEM user to access the database files). When the files are correctly named and in the right location and can be accessed by the Windows SYSTEM user, restart the server (see Start and Stop the System Server). The server should now be able to run the database.

If the server continues to detect errors, please contact Schneider Electric.

  • Missing Database Modules—This means that the modules (drivers) that are required by the database are not installed on the Standby server. The Main server and Standby server need to have the same drivers installed (the Standby server can have extra drivers as well if required).

If you want to preserve the database configuration, select the Stay in Safe Mode option so that the server does not attempt to run the database. You will need to install the missing modules on the Standby server, then restart the Standby server (see Start and Stop the System Server).

If you do have no need to install the missing drivers, select the Discard Configuration option. This instructs the server to run the database and dispose of any configuration that requires a driver that is not installed.

If the server continues to detect errors, please contact Schneider Electric.

  • Database Load Errors—The server has detected an internal error. Please select the Stay in Safe Mode option and contact Schneider Electric for assistance. It is beneficial to our engineers if you can provide a copy of the latest server log files for analysis.
  • Database checks failed—The server has detected an internal problem. Please select the Stay in Safe Mode option and contact Schneider Electric for assistance. It is beneficial to our engineers if you can provide a copy of the latest server log files for analysis.

You do not need to continue with the steps in this procedure.

  3. If the Invalid Database option is displayed, it means that the database file is unsupported or is corrupt. You need to check that the build version of the database file is supported by your version of ClearSCADA. For assistance, contact Schneider Electric.

You do not need to continue with the steps in this procedure.

  4. If the Invalid Metadata option is displayed, it means that the server has detected a problem with the registry key settings. If your system uses extra database fields, check their configuration and correct any mistakes (see Extra Database Fields). If the extra database fields are configured correctly, you should contact Schneider Electric for advice.

You do not need to continue with the steps in this procedure.

  5. Select the Invalid Standby Configuration option to display a dialog box. The dialog box provides information about the differences between the configuration on the Main server and the configuration on the Standby server:

The differences can include:

  • The Standby server is not configured as a partner to the main server. You need to reconfigure the main server.
  • The Standby server does not have the modules (drivers) required by the main server available. You need to install the modules on the Standby server.
  • The configuration of certain server features, such as alarm limits, on the Standby server is different to the configuration settings on the main server. You need to reconfigure the servers so that they have the same settings.
  • The multiple point state alarms on the Standby server differ to those on the main server. You need to reconfigure the servers so that they have the same settings.

When you have checked that the Standby server configuration settings are identical to those on the Main server, you can select the Retry Transfer option. If the configuration is the same, the server should run correctly.

If the server continues to experience difficulties, select the Stay in Safe Mode option and contact Schneider Electric for advice.

You do not need to continue with the steps in this procedure.

  6. If the context sensitive menu contains the options Database Save Error, Journal Save Error, or Database and Journal Save Error, it means that the server is unable to save the database or journal files. You should locate the files and check that they can be accessed by ClearSCADA (use Windows to give the Windows SYSTEM level user full access to the files and to unlock the files). You should also check that the disk to which the files are written is not full as this can also cause the server to detect a database and/or journal save error.

If the files are accessible and the disk has a suitable amount of available space, contact Schneider Electric for advice.

You do not need to continue with the steps in this procedure.

  7. Select the Isolated Standby option to display a dialog box that prompts you to choose between:
  • Go Main
  • Stay Standby

When these options are available, it means that the server is a Standby server that has become isolated due to a network failure.

If you know that the Main server is still running, select the Stay Standby option. The server will remain as a Standby server and will reconnect with the Main server as soon as the network connection is restored.

If the Main server is not running, select the Go Main option to switch the Standby server to Main. The Standby server will become the Main server and will run independently. When the network is restored, the server will arbitrate with the other server(s) to avoid a Main-Main situation.

You do not need to continue with the steps in this procedure.

  8. If the Configuration Unlicensed option is available it means that the server does not have a valid license and so cannot run the database. You need to set up a valid license (see Server License Settings).

You do not need to continue with the steps in this procedure.

  9. If the Exception Occurred option is available it means that the server has detected an internal problem. Please contact Schneider Electric for assistance. It is beneficial to our engineers if you can provide a copy of the latest server log files for analysis.


Server Administration Guide - Accessing the ClearSCADA Server Configuration Tool (Working with the ClearSCADA Server Configuration Tool)

Accessing the ClearSCADA Server Configuration Tool

To define the configuration settings for a ClearSCADA server, you will need to use the ClearSCADA Server Configuration Tool.

NOTE: In the unlikely event that your system’s Guest user account is configured to have the System Admin permission for the Root Group (system), you will be able to use the Server Configuration Tool without logging on. For security reasons, many systems do not allow the Guest user to have the System Admin permission.

To access the ClearSCADA Server Configuration Tool:

  1. Right-click on the ClearSCADA icon in the Windows system tray.
    A context sensitive menu is displayed.
  2. Select the Configuration option.
    The ClearSCADA Server Configuration Tool is displayed.
  3. Select a System in the tree structure that is shown on the left-hand side of the ClearSCADA Server Configuration Tool.
    A Log On prompt is displayed.
  4. Enter your Username and Password to log on to the system in the same way as you would log on to ViewX.

NOTE: Your user account can only provide access if it has been allocated the System Admin permission for the selected system. For information on creating a User account, see User Accounts in the ClearSCADA Guide to Security. For information on allocating permissions, see Allocating Security Permissions in the ClearSCADA Guide to Security.

When you have successfully logged on, you can access the server settings for the selected system. To access the server settings, expand the system, server, and categories of settings by double-clicking on them in the tree-structure.


Server Administration Guide - Understanding the ClearSCADA Server Configuration Tool (Working with the ClearSCADA Server Configuration Tool)

Understanding the ClearSCADA Server Configuration Tool

The ClearSCADA Server Configuration Tool contains a tree structure that groups the types of server settings. When you select one of the groups, the relevant settings are shown in the right-hand panel.

Tree-structure
Settings

The server settings are grouped as follows:

  • Database Configuration—Contains the settings that affect the items in the database, including:
  • Alarm Action Calendar—Refer to Alarm Action Calendar Settings.
  • Alarm Limits—Refer to Alarm Limits.
  • Descriptions—Refer to Standard Point Descriptions.
  • Extra Table Queries—Refer to Extra Table Queries
  • Historic Algorithms—Refer to Historic Configuration Settings.
  • Historic Regions—Refer to Historic Configuration Settings.
  • Point State Alarms—Refer to Point State Alarms.
  • Quality Classifications—Refer to Point Quality Classifications.
  • Severities—Refer to Alarm and Event Severities.
  • Global Parameters:
  • Advanced—Refer to Send Buffer Size.
  • Channels—Refer to Channel Settings.
  • Drivers—Refer to Driver Settings.
  • <Driver name>—Refer to the driver-specific documentation.
  • Outstations—Refer to Outstation Settings.
  • Points—Refer to Points Settings
  • Historic Configuration:
  • Archiving—Refer to Archiving.
  • Configuration Changes—Refer to Settings for Configuration Changes Auditing.
  • Event Journal—Refer to Event Journal Storage Settings.
  • Historic Data—Refer to Historic Data Storage Settings.
  • Historic Files—Refer to Enable or Disable Historic Files.
  • Search Limits—Refer to Search Limits for Historic Data and the Event Journal.
  • SQL Query Configuration:
  • Historic Views—Refer to Historic Views
  • Linked ODBC Tables—Linked ODBC Tables
  • Parameters—Refer to Use the Parameters Settings to Define the SQL Query Row and Size Limit
  • System Configuration:
  • Alarms—Refer to Alarms Settings
  • Data Files—Refer to Data Files Settings
  • Dictionaries—Refer to Dictionary Settings
  • E-Mail—Refer to E-Mail Settings
  • Emulate Server Version—Refer to Server Emulation
  • Events—Refer to Events List Settings
  • Exclusive Control—Refer to Exclusive Control Settings
  • File Upload—Refer to File Upload Settings
  • Location—Refer to Locations of the Database Folders
  • Logging—Refer to Logging and Monitoring
  • Partners—Use the Partners Settings to define the type of system you are configuring. Refer to the relevant type of system:
  • Lone Server Architecture
  • Hot-Standby Pair Architecture
  • Hot-Standby Pair with Sentinel Server Panel Architecture
  • Triple Standby Architecture
  • Permanent Standby Servers.
  • Permission Restrictions—see Setting up System Security in the ClearSCADA Guide to Security
  • Printing—Refer to Printer Settings
  • Security—see Setting up System Security in the ClearSCADA Guide to Security
  • System Calls—see System Calls Settings.
  • Web—Refer to WebX Settings.

You should not alter the Registry settings without expert advice from Schneider Electric.

The ClearSCADA Guide to Server Administration describes how to use each of the ClearSCADA Server Configuration features (with the exception of the driver specific settings which are described in the relevant driver documentation) and also explains how to:

  • Set up a Port Server
  • Start and Stop the System Server
  • Start and Stop a Driver.
  • Set up Archiving.
  • Set up Communications Logging.
  • Monitor the Available Disk Space.
  • Configure the Alarm and Event Printer Service.
  • Check the Integrity of your System.

If you are familiar with the ClearSCADA server configuration process, refer to the section that explains the features for which you require information.

If you are unfamiliar with the ClearSCADA server configuration process, you should refer to the relevant type of system setup for further instructions:

  • Lone Server Architecture
  • Hot-Standby Pair Architecture
  • Hot-Standby Pair with Sentinel Server Panel Architecture
  • Triple Standby Architecture
  • Permanent Standby Servers.


Server Administration Guide - System Architectures

System Architectures

Having installed ClearSCADA on a server and displayed the Server Configuration Tool, you are ready to begin the server configuration. The first stage of the server configuration is to define the type of system architecture to which the server belongs.

You can use the Server Configuration Tool’s Partners settings to configure the server so that it recognizes the structure of your system and can interact with any other servers. To do this, you should have an understanding of the various server architectures and server connection and monitoring features.

In the following sections, we describe the various server architectures, explain how the servers synchronize and interact with each other, and provide information on each of the server features that you can configure in the Partners settings:

  • Lone Server Architecture
  • Hot-Standby Pair Architecture
  • Hot-Standby Pair with Sentinel Server Panel Architecture
  • Triple Standby Architecture
  • Permanent Standby Servers
  • De-Militarized Zone (DMZ) Permanent Standby Servers
  • Dual Network Servers
  • Configure the Partners Settings of a Server
  • Synchronization Process for Multi Server Architectures
  • Main-Standby Changeovers
  • Perform a Manual Changeover on a Multi-Server System
  • Main-Main and Main-Main-Main Situations
  • Test the Servers in a Multi-Server Architecture
  • Frequently Asked Questions - Server Architecture.

NOTE: Multi-server systems (redundancy) are only supported by full versions of ClearSCADA. You can find information about the version you have installed by running ViewX and selecting Help>About.

NOTE: For information on using a ClearSCADA system with Remote Desktop applications, see ClearSCADA on Citrix and Terminal Services.


Server Administration Guide - Lone Server Architecture (System Architectures)

Lone Server Architecture

The simplest form of ClearSCADA system is a Lone Server architecture. This involves a single server that runs independently, stores the database and communicates with the clients and hardware (outstations, PLCs etc.).

As Lone Server architectures have only one server, there is no redundancy. If there is an unexpected problem with the server or it loses its connections to the clients or hardware, the ClearSCADA system will go offline.

To set up a lone server architecture, you need to log on to the server and configure it to have the appropriate settings. For more information, see Configure a Lone Server.


Server Administration Guide - Configure a Lone Server (System Architectures)

Configure a Lone Server

If your system uses a single server, you need to configure a lone server architecture as follows:

  1. Install ClearSCADA and the required drivers on the server.
  2. Re-start the server (ClearSCADA runs as a service and will start when your server’s system starts up).
  3. When the server has been re-started, you will see a ClearSCADA server icon in the Windows taskbar. The ClearSCADA server icon is magenta if there is no database or blue if there is an existing database. If the ClearSCADA server icon is magenta, you will need to set up the client connections (see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration). If the icon is blue, you can right-click on the ClearSCADA server icon to display a context sensitive menu, then select the Configuration option to display the Server Configuration Tool.
  4. Log on to the Server Configuration Tool if required and then access the System Configuration>Partners settings.
  5. Set the Type to Lone Server.
  6. Setup your ClearSCADA license:
  • If you have been issued with a dongle, insert the dongle into an available parallel port or USB port. The server will detect the License settings automatically.
  • If you are using a software license, check that the license file (ClearSCADA.lic) is stored in the required location (C:/Program Files/Schneider Electric/ClearSCADA/ClearSCADA.lic by default).

You can use Windows Explorer to check that your license file is stored in the correct location. If the license file is not in the correct location, use Windows Explorer to locate and move the file as required.

You can use the License settings to view the current license information or change the location of the license file if required (see Server License Settings).

  7. Define the other server configuration settings as required. Please refer to Understanding the ClearSCADA Server Configuration Tool for information on the other server settings.
  8. Re-start the ClearSCADA server to apply the configuration settings (see Start and Stop the System Server).
  9. Create a Blank Database.
  10. Setup User Groups and User accounts (see Welcome to the Security Guide in the ClearSCADA Guide to Security).
  11. Define the security settings for your database (see Allocating Security Permissions in the ClearSCADA Guide to Security).
  12. Setup the Archiving facility.
  13. Setup your system to Monitor the Available Disk Space.
  14. Familiarize yourself with channel logging and the Server Status Tool (see Working with the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).


Server Administration Guide - Hot-Standby Pair Architecture (System Architectures)

Hot-Standby Pair Architecture

A Hot-Standby Pair architecture uses two servers to provide redundancy and allow for load sharing.

NOTE: Multi-server systems (redundancy) require a license and so are only supported by full versions of ClearSCADA.

In a Hot-Standby Pair, one server acts as the Main server and the other server acts as a Standby server. The Main server runs the system drivers and acts as the primary server whereas the Standby server is used as a backup server.

During synchronization, the Main server updates the Standby server. This process provides the Standby server with data and configuration that accurately represents the data on the Main server (see Synchronization Process for Multi Server Architectures). So, if the Main server goes offline or there is a manual changeover, the Standby server can take over the duties of the Main server and the system will continue to run.

When an offline server is able to resume normal operations, it communicates with the other server (which is now Main) and becomes the Standby server.

If the Standby loses its connection with the Main server, a Main-Main situation can occur. This is when both servers act as Main servers because they cannot communicate with each other.

ATTENTION: If an offline Main-Standby connection is recovered, and the server that was originally Main is restored as the Main server, the data reported while the Standby server was Main may be lost. For example, if Server A has been Main for 10 hours when the connection is lost, Server B switches to Main. The connection to Server A is restored within 2 hours, and as Server A has been Main for longer than Server B (in total), it is set to Main and Server B is switched to Standby. The data that was reported to Server B while it was Main may be lost. If Duty-Duty support is enabled, the data will be merged (see Enable or Disable Duty Mode), otherwise the data is only retrievable if the outstations or PLCs being used support Windback. For more information, refer to the documentation for your outstations, PLCS etc.

To set up a Hot-Standby Pair architecture, see Configure a Hot-Standby Pair.

Further Information

Hot-Standby Pair with Sentinel Server Panel Architecture

Triple Standby Architecture

Permanent Standby Servers

Configure the Partners Settings of a Server

Synchronization Process for Multi Server Architectures

Main-Standby Changeovers

Perform a Manual Changeover on a Multi-Server System

Main-Main and Main-Main-Main Situations

Test the Servers in a Multi-Server Architecture

Frequently Asked Questions - Server Architecture.


Server Administration Guide - Configure a Hot-Standby Pair (System Architectures)

Configure a Hot-Standby Pair

For a Hot-Standby Pair connection to work correctly, you need to configure the Main server to recognize the Standby server. Similarly, you need to configure the Standby server to connect to the Main server. This is achieved by using the Partners settings on the Server Configuration Tool.

The successful configuration of a Hot-Standby Pair is also dependent on certain settings being in place on both the Main server and the Standby server. If you follow the instructions in this section, you will learn how to check which Main server settings need to be duplicated on the Standby server.

To configure a Hot-Standby Pair:

  1. Install ClearSCADA and the relevant drivers on the server that is to begin as the Main server.
  2. Re-start the server (ClearSCADA runs as a service and will start when your server’s system starts up).
  3. When the server has been re-started, you will see a ClearSCADA server icon in the Windows taskbar. The ClearSCADA server icon is magenta if there is no database or blue if there is an existing database. If the icon is magenta, you will need to set up the client connections (see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration). If the icon is blue, you can right-click on the ClearSCADA server icon to display a context sensitive menu, then select the Configuration option to display the Server Configuration Tool.
  4. Log on to the server that starts as Main and configure it to be part of a Hot-Standby Pair (see Configure the Partners Settings of a Server). You should set the Type to Hot-Standby Pair and use the Standby A column of fields to define the connection settings of the Standby server. For example, in the diagram below, you would set the Name/IP Address, Port, compression settings (Compress), and ICMP Monitors for the Main Connection between the Main server and the Standby server by using the fields in the Standby A column.
  5. Use the Server Configuration Tool to define the other server configuration settings for the Main server as required (see Understanding the ClearSCADA Server Configuration Tool).
  6. Re-start the server to apply the configuration settings (see Start and Stop the System Server).
  7. Create a Blank Database.
  8. Set up the client connections (see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration).
  9. Set up User Groups and User accounts (see Welcome to the Security Guide in the ClearSCADA Guide to Security).
  10. Define the security settings for your database (see Allocating Security Permissions in the ClearSCADA Guide to Security).
  11. Set up the Archiving facility.
  12. Set up your system to Monitor the Available Disk Space.
  13. Install ClearSCADA on the server that starts as the Standby server.

ATTENTION: You should install the same drivers on the Standby server as those installed on the Main server. If the Main server has drivers that are not installed on the Standby, the Standby server will not be able to establish a connection with the Main server.

  14. Log on to the server that starts as Standby and configure it to be part of a Hot-Standby Pair (see Configure the Partners Settings of a Server). You should set the Type to Hot-Standby Pair and use the Standby A column of fields to define the connection settings of the Main server.
  15. Define the same server configuration settings as those that are in place on the Main server. To do this, you can either:
  • Export the settings from the Main server to the Standby server (contact Schneider Electric for more information).
  • Apply the configuration settings to the Standby server manually by using the Server Configuration Tool (see Understanding the ClearSCADA Server Configuration Tool). This is the recommended method for implementing changes to the server configuration (i.e. making adjustments to existing server configuration settings).

The main advantage of using this method is that you can make small adjustments on each server, rather than having to make the changes on one server then export the settings. However, this method of server configuration can mean that:

  • Server configuration could take a longer amount of time, especially if the servers are being setup for the first time.
  • Server settings could be different on the servers due to system administrator making a mistake, for example, entering an incorrect value.
  • Server settings could be different due to a system administrator not having a record of the settings on the other server(s). This is especially applicable when the servers are at different geographical locations. For this reason, we recommend that you make notes of each setting that you change.
  16. Re-start the Standby server to apply the configuration settings (see Start and Stop the System Server).
  17. Set up the client connections (see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration).
  18. Perform a manual changeover to check that both servers can switch to Main (see Perform a Manual Changeover on a Multi-Server System). You should also take this opportunity to test the performance of the architecture (see Test the Servers in a Multi-Server Architecture).

When you have configured the server architecture, we recommend that you configure a Logic program to map the server status values to digital points so that alarms can be raised should a server become unavailable. For more information, see How Can I Detect that a Server has Failed?.


Server Administration Guide - Hot-Standby Pair with Sentinel Server Panel Architecture (System Architectures)

Hot-Standby Pair with Sentinel Server Panel Architecture

A Hot-Standby Pair with Sentinel panel architecture uses a Hot-Standby Pair Architecture with the connections to outstations, PLCs etc. being made via a Sentinel panel.

The Sentinel panel allows ClearSCADA to route inputs and outputs (I/O) to the server that is Main. To do this, the Sentinel panel determines which server is the Main server and overrides ClearSCADA's built-in arbitration mechanism. This means that if the LAN/WAN link fails, only one of the servers will go Main (the Sentinel panel instructs one of the servers to act as a Standby when the LAN/WAN link fails).

The Sentinel panel provides a visual display that allows users to determine the status of the server databases (whether a server is Main/Standby/Synchronizing/Failed). It can also be used to initiate changeovers or force a particular server to act as the Main server.

NOTE: Multi-server systems (redundancy) require a license and so are only supported by full versions of ClearSCADA.

ATTENTION: If a Main server goes offline and is then restored as the Main server, the data reported while the Standby server was Main may be lost. For example, if Server A has been Main for 10 hours when it goes offline, Server B switches to Main. Server A is restored within 2 hours, and as it has been Main for longer than Server B (in total), it is set to Main and Server B is switched to Standby. The data that was reported to Server B while it was Main may be lost. The data is only retrievable if the outstations or PLCs being used support Windback. For more information, refer to the documentation for your outstations, PLCS etc.


Server Administration Guide - Configure a Hot-Standby Pair with Sentinel Server Panel (System Architectures)

Configure a Hot-Standby Pair with Sentinel Server Panel

To configure a Hot-Standby Pair with Sentinel Server Panel, you need to follow the same instructions as used when configuring a normal Hot-Standby Pair Architecture, but with two additional configuration changes:

  • Set both the Main and Standby servers to have their Type set to Hot-Standby Sentinel (in the Server Configuration Tool’s System Configuration>Partners settings).
  • When accessing the System Configuration>Partners settings on the Main server, you should enter the Sentinel COM Port address. The address is the number of the port on the Main server that is used for the connection to the Sentinel COM port.

You should enter the address as: COM<number> where <number> is the number of the port being used. For example, if Port 6 on the Main server is being used for the connection to the Sentinel Panel, enter: COM6

  • Similarly, when accessing the System Configuration>Partners settings on the Standby server, you should also enter the Sentinel COM Port address. The address is the number of the port on the Standby server that is used for the connection to the Sentinel COM port.

Again, the address has to be entered as COM<number> where <number> is the number of the port being used.

The other configuration settings are identical to those of a normal Hot-Standby Pair.

Further Information

Hot-Standby Pair Architecture.

Add a Permanent Standby Server to a System.

Define the Server’s Arbitration Priority.


Server Administration Guide - Triple Standby Architecture (System Architectures)

Triple Standby Architecture

Triple Standby server architectures are similar to Hot-Standby pair architectures except that instead of there being one Standby server, there are two. As with Hot-Standby Pair arrangements, one of the servers is recognized as the Main server, with the other servers being Standby servers. Clients and plant can be connected to any of the servers, but the data they report is sent to the Main server and stored in the Main server’s database. The Main server then updates the databases in the Standby servers so that they match the Main server database.

The diagram above shows a possible Triple Standby architecture, where two servers are connected via a LAN and they connect to the third server via a WAN.

Triple Standby architectures provide additional backup in the event of a hardware, software or network failure.

  • On systems with dual connections, the server architecture will continue to run as a Triple Standby in the event of the Main server losing its connection with one of the two others. However, this only applies if the two other servers can still connect to each other. As the Main server is unable to use the lost connection, communications to both servers will be made via the healthy connection. This may have an impact on system performance as there will be no load balancing due to there only being one available connection.
  • If the Main server loses its connections with both of the other servers but the other servers can still communicate with each other, the Main server will become isolated. The other two servers will arbitrate to determine which of the two is to switch to Main, and they will continue to run as a Hot-Standby Pair until the isolated server is restored. When the isolated server is able to connect to the other two servers, the three servers will arbitrate to determine which server is Main.

ATTENTION: If a Main server goes offline and is restored as the Main server, the data reported while a Standby server was Main may be lost. For example, if Server A has been Main for 10 hours when it goes offline, Server B switches to Main and Server C remains as a Standby. Server A is restored within 2 hours, and as it has been Main for longer than Server B and Server C (in total), it is set to Main and Server B is switched to Standby. The data that was reported to Server B while it was Main may be lost. The data is only retrievable if the outstations or PLCs being used support Windback. For more information, refer to the documentation for your outstations, PLCS etc.

  • If the servers are unable to connect, the Standby servers will become isolated and will respond according to their Action on Isolated setting (see Define what Action Should Be Taken when the Server is Isolated). Depending on the servers’ configuration, this could result in a Main-Main or Main-Main-Main situation.

When a manual changeover is performed, the Main server will switch to Standby and the Standby server that has been running the longest amount of time will switch to become the new Main server.

NOTE: Multi-server systems (redundancy) require a license and so are only supported by full versions of ClearSCADA.


Server Administration Guide - Configure Triple Standby (System Architectures)

Configure Triple Standby

For a Triple Standby architecture to work correctly, you need to configure the Main server to recognize the two Standby servers. Similarly, you need to configure the Standby servers to connect to the Main server. This is achieved by using the Partners settings on the Server Configuration Tool.

The successful configuration of a Triple Standby architecture is also dependent on certain settings being in place on the Main server and the Standby servers. If you follow the instructions in this section, you will learn how to check which Main server settings need to be duplicated on the Standby servers.

To configure a Triple Standby architecture:

  1. Install ClearSCADA on the server that starts as Main, taking special care to install
  2. the drivers you require.
  3. Re-start the server (ClearSCADA runs as a service and will start when your server’s system starts up).
  4. When the server has been re-started, you will see a ClearSCADA server icon in the Windows taskbar. The ClearSCADA server icon is magenta if there is no database or blue if there is an existing database. If the icon is magenta, you will need to set up the client connections (see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration). If the icon is blue, you can right-click on the ClearSCADA server icon to display a context sensitive menu, then select the Configuration option to display the Server Configuration Tool.
  5. Log on to the server that starts as Main and access the System Configuration>Partners settings (see Configure the Partners Settings of a Server).
  6. Use the Partners settings to set up the server as part of a Triple Standby architecture and define the connection settings between the server and the other servers in the architecture.

When using the Partners settings to configure a Triple Standby architecture, you need to be aware that the Standby A column represents the connections between the server you are configuring and the primary Standby server. Typically, this is the Standby server with the highest Arbitration Priority setting i.e. the Standby server that will switch to Main if the Main server goes offline or loses its connection.

The Standby B column represents the connections between the server you are configuring and the secondary Standby server (the Standby server with the lowest Arbitration Priority).

The Permanent Standby settings are only for use with architectures that use a Permanent Standby server (see Add a Permanent Standby Server to a System).

  • Set the Type to Triple Standby (see Set the Type of Server).
  • Use the Standby A column of fields to define the connection settings of the primary Standby server (see Configure the Main and Backup Connections).
  • Use the Standby B column of fields to define the connection settings of the secondary Standby server (see Configure the Main and Backup Connections).
  • Define the Arbitration Priority of the Main server so that it has the highest setting of the three servers. The Arbitration Priority setting is on the Miscellaneous tab.
  7. Use the Server Configuration Tool to define the other server configuration settings for the Main server as required (see Understanding the ClearSCADA Server Configuration Tool).
  8. Re-start the server to apply the configuration settings (see Start and Stop the System Server).
  9. Create a Blank Database.
  10. Set up the client connections (see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration).
  11. Set up User Groups and User accounts (see Welcome to the Security Guide in the ClearSCADA Guide to Security).
  12. Define the security settings for your database (see Allocating Security Permissions in the ClearSCADA Guide to Security).
  13. Set up the Archiving facility.
  14. Set up your system to Monitor the Available Disk Space.
  15. Install ClearSCADA on the server that starts as the Standby server.

ATTENTION: You should install the same drivers as those installed on the Main server. If the Main server has drivers that are not installed on the Standby, the Standby server will fail.

  16. Log on to the Standby server that will switch to Main (and remain as Main after arbitration with the other Standby server) if the current Main server fails.
  17. Configure the Standby server to be part of a Triple Standby architecture (see Configure the Partners Settings of a Server).

You should:

  • Set the Type to Triple Standby (see Set the Type of Server).
  • Use the Standby A column of fields to define the connection settings of the primary Standby server (see Configure the Main and Backup Connections). In this case, the primary Standby server for the server you are configuring is the server that begins as the Main server (as it has the highest Arbitration Priority setting of the two other servers).
  • Use the Standby B column of fields to define the connection settings of the secondary Standby server (see Configure the Main and Backup Connections). In this case, the secondary Standby server is the other Standby server in the architecture (i.e. not the Main and not the Standby server that you are currently configuring).
  • Define the Arbitration Priority of the Standby server so that it has the second highest setting of the three servers.
  18. Define the same server configuration settings as those that are in place on the Main server. To do this, you can either:
  • Export the settings from the Main server to the Standby server (contact Schneider Electric for more information).
  • Apply the configuration settings to the Standby server manually by using the Server Configuration Tool (see Understanding the ClearSCADA Server Configuration Tool). This is the recommended method for implementing changes to the server configuration (i.e. making adjustments to existing server configuration settings).

The main advantage of using this method is that you can make small adjustments on each server, rather than having to make the changes on one server then export the settings. However, this method of server configuration can mean that:

  • Server configuration could take a longer amount of time, especially if the servers are being setup for the first time.
  • Server settings could be different on the servers due to a system administrator making a mistake, for example, entering an incorrect value.
  • Server settings could be different due to a system administrator not having a record of the settings on the other server(s). This is especially applicable when the servers are at different geographical locations. For this reason, we recommend that you make notes of each setting that you change.
  19. Re-start the Standby server to apply the configuration settings (see Start and Stop the System Server).
  20. Set up the client connections (see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration).
  21. Install ClearSCADA on the server that starts as the second Standby server (the Standby server that you have not yet configured during this procedure).

ATTENTION: You should install the same drivers as those installed on the Main server. If the Main server has drivers that are not installed on the Standby, the Standby server will go offline.

  22. Log on to the remaining Standby server (the Standby server that you have not yet configured during this procedure).
  23. Configure the Standby server to be part of a Triple Standby architecture (see Configure the Partners Settings of a Server).

You should:

  • Set the Type to Triple Standby (see Set the Type of Server).
  • Use the Standby A column of fields to define the connection settings of the primary Standby server (see Configure the Main and Backup Connections). In this case, the primary Standby server for the server you are configuring is the server that begins as the Main server (as it has the highest Arbitration Priority setting of the two other servers).
  • Use the Standby B column of fields to define the connection settings of the secondary Standby server (see Configure the Main and Backup Connections). In this case, the secondary Standby server is the other Standby server in the architecture (i.e. not the Main and not the Standby server that you are currently configuring).
  • Define the Arbitration Priority of the Standby server so that it has the lowest highest setting of the three servers.
  24. Define the same server configuration settings as those that are in place on the Main server. To do this, you can either:
  • Export the settings from the Main server to the Standby server (contact Schneider Electric for more information).
  • Apply the configuration settings to the Standby server manually by using the Server Configuration Tool (see Understanding the ClearSCADA Server Configuration Tool).
  25. Re-start the Standby server to apply the configuration settings (see Start and Stop the System Server).
  26. Set up the client connections (see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration).
  27. Perform manual changeovers to check that the servers can switch to Main (see Perform a Manual Changeover on a Multi-Server System). You should also take this opportunity to test the performance of the architecture (see Test the Servers in a Multi-Server Architecture).

When you have configured the server architecture, we recommend that you configure a Logic program to map the server status values to digital points so that alarms can be raised should a server become unavailable. For more information, see How Can I Detect that a Server has Failed?.


Server Administration Guide - Permanent Standby Servers (System Architectures)

Permanent Standby Servers

Permanent Standby servers can only be set to Standby and are used as an additional part of a Hot-Standby Pair or Triple Standby architecture. Also known as ‘Corporate Servers’, Permanent Standby servers can reduce the demand placed on the Main and Standby servers in a multi-server architecture/

A Permanent Standby server can be used:

  • As a ‘performance firewall’—clients can connect to the system via the Permanent Server instead of the Main or Standby server, which reduces the demand on the Hot-Standby Pair’s resources.
  • To improve performance for clients. This applies to read operations where the clients would have to connect to the Standby server over a slow WAN. Instead of reading data from the Standby server, the clients can be connected to the Permanent Standby locally—they can read the data from the Permanent Standby instead of the Standby and so avoid the need to use the WAN.
  • To increase the amount of historic data that is available on-line. By configuring a Permanent Server to store more historic data on-line, you can increase the amount of historic data that is available on-line without affecting the Main and Standby server’s resources. For example, a Permanent Standby server can be configured to store historic data on-line for 5 years while the Main and Standby servers can be configured to store historic data on-line for only 1 year.

It is also possible to configure clients so that they connect to the Permanent Standby in preference to the other servers (they will only connect to the Main or Standby server if the Permanent Standby server is offline). To achieve this, you simply need to configure the client connection to the Permanent Standby server to have a lower cost than the cost settings for the connections to the Main and Standby servers (see Define the Node Cost for a Client - System Connection in the ClearSCADA Guide to Client Administration).

ClearSCADA allows you to connect up to four Permanent Standby servers to a Hot Standby Pair architecture or up to three Permanent Standby servers to a Triple Standby architecture. Typically, a system that uses Permanent Standby servers is set up as follows:

  • Clients that are used by operators and engineers are connected to a Hot-Standby Pair or Triple Standby architecture. As these are the users that use the system to monitor and control plant, they need to have a larger amount of system resources available so that they can react quickly and efficiently to ‘real-life’ situations on site.
  • Clients that are used by managers, administrators and analysts are connected to a Permanent Standby server. This provides access to the data on the system without placing a high demand on the resources of the Main and Standby servers. So managers, administrators and analysts can access the system data and statistics without affecting the load on the Main and Standby servers.

In the setup shown in the following diagram, two Permanent Standby servers are used to reduce the load on the Main server and Standby server. The load is reduced by having the majority of users access the system via the Permanent Standby servers with fewer users accessing via the Main and Standby servers.

On some systems, Permanent Standby servers are also used to store large amounts of historic data. This is an effective way of making data available to users without using the resources of the Main and Standby servers.

NOTE: A Permanent Standby server that is used in a Triple Standby architecture can only connect to two of the three Main/Standby servers. For more information, see Configure Triple Standby.

NOTE: Multi-server systems (redundancy) require a license and so are only supported by full versions of ClearSCADA.

To set up a multi-server architecture that uses one or more Permanent Standby servers, refer to the relevant section:

  • Add a Permanent Standby Server to a System
  • Configure a Permanent Standby Server
  • Configure the Main Server to Recognize a Permanent Standby Server
  • Configure a Standby Server to Recognize a Permanent Standby Server.


Server Administration Guide - Add a Permanent Standby Server to a System (System Architectures)

Add a Permanent Standby Server to a System

You can add one or more Permanent Standby servers to an existing Hot-Standby, Hot-Standby Sentinel, or Triple Standby architecture. Adding Permanent Standby servers is useful when you need to reduce the load on the system as they allow managers, administrators, and analysts to access the data on the system without affecting the resources of the Main and Standby servers.

The number of Permanent Standby servers you can add depends on the type of system architecture you already have in place:

  • On a Hot-Standby Pair (or Hot-Standby Pair with Sentinel Panel), you can add up to four Permanent Standby servers.
  • On a Triple Standby system, you can add up to three Permanent Standby servers, but each Permanent Standby server can only connect to two of the three Main/Standby servers.

NOTE: A Permanent Standby server can only connect to two of the three servers in a Triple Standby architecture. You specify the connection to the two servers in the configuration for the Permanent Standby server. Usually, Permanent Standby servers are configured to connect to the two servers that are most likely to go Main (i.e. the two servers with the highest Cost settings).

When you add a Permanent Standby server to a system, you need to perform configuration tasks on the server that starts as Main and the server(s) that starts as Standby as well as the Permanent Standby server. This is because each server needs to be able to recognize the other servers that connect to it.

To add a Permanent Standby server to an existing system, you need to:

  1. Log on to the Permanent Standby that you are adding and configure it to recognize the Main server and the Standby server(s) (see Configure a Permanent Standby Server).
  2. Repeat step 1 for each Permanent Standby server that you are adding to the system architecture.
  3. Log on to the server that starts as Main and configure it to recognize each Permanent Standby server (see Configure the Main Server to Recognize a Permanent Standby Server).
  4. Log on to the Standby server and configure it to recognize each Permanent Standby server (see Configure a Standby Server to Recognize a Permanent Standby Server). On Triple Standby systems, you need to configure each Standby to which the Permanent Standby servers connect. This may be one or both of the Standby servers depending on the set up of your system.


Server Administration Guide - Configure a Permanent Standby Server (System Architectures)

Configure a Permanent Standby Server

The Permanent Standby server has to be able to connect to the Main server so that the Main server can update the Permanent Standby server’s database. To make this possible, you need to configure the Permanent Standby server so that it can recognize the connection to the Main server.

To configure a Permanent Standby server:

  1. On the Permanent Standby server, access the Server Configuration Tool and log on via a User account with the System Admin permission (if log on is required).
  2. Access the System Configuration>Partners settings and set the Type to Permanent Standby.
  3. In the Main Connection section on the Standby tab, use the Standby A fields to define the settings for the primary connection between the Permanent Standby server and the server that starts as the Main server in the architecture.

For more information on the Name/IP Address, Port, Compress, and ICMP Monitor settings, see Configure the Main and Backup Connections.

Use the Standby A column to define the settings for the primary connection between the Permanent Standby server and the Main server.

  4. In the Backup Connection section, use the Standby A settings to define the secondary connection between the Permanent Standby server and the Main server (this only applies if dual ethernet connections are being used; leave the fields empty if there is only one connection between the Permanent Standby server and the Main server):
  • In the IP Address field, enter the IP address of the Permanent Standby server’s network card (the card that is used for the secondary connection with the Main server).
  • Use the Compress check box to enable or disable compression on the secondary connection between the Permanent Standby server and the Main server. For more information, see Define the Server Compression Settings.
  5. Use the Standby A column’s Monitor settings to define the monitor connect and request timeouts for the connection between the Permanent Standby server and the server that starts as Main (see Define the Monitor Timeout Settings for a Server).
  6. Use the Standby A column’s Transfer settings to define the transfer update, connect and request timeouts for the connection between the Permanent Standby server and the server that starts as Main (see Define the Transfer Update Rate and Transfer Timeouts).
  7. Use the Duty Mode check box to enable or disable Duty Mode for the connection between the Permanent Standby server and the Main server (see Enable or Disable Duty Mode).
  8. Configure the settings for the connection(s) between the Permanent Standby server and the Standby server by repeating steps 3-7 inclusive, only this time using the Standby B column of fields instead of the Standby A column. The Standby B column of settings work in exactly the same way as the Standby A settings except that they apply to the server that starts as Standby.

NOTE: If you are adding a Permanent Standby server to a Triple Standby architecture, you can only configure it to connect to the Main server and one of the two Standby servers. The Permanent Standby server will only connect to the server that starts as Main and the specific Standby server you define—it will not connect to the other Standby server.

  9. Use the Miscellaneous tab to define the Heartbeat Timeout as required (see Define the Heartbeat Timeout for a Server).
  10. If you are configuring a Permanent Standby server that is part of a Hot-Standby Pair with Sentinel Server Panel architecture, you should enter the Sentinel COM Port address on the Miscellaneous tab. The address is the number of the port on the Permanent Standby server that is used for the connection to the Sentinel COM port.

If you are configuring a Permanent Standby server that is part of a Hot-Standby Pair or Triple Standby architecture, you can skip this step and proceed to step 11.

  11. Restart the Permanent Standby Server to apply the changes (see Re-Start the ClearSCADA Server).

When you have configured the Permanent Standby Server, it will be able to recognize the server that starts as Main and the server that starts as Standby (in the case of Triple Standby architectures, it will be able to recognize one of the two servers that start as Standby).

But for the Permanent Standby server to be fully incorporated into your system architecture, you should also:

  • Configure the Main Server to Recognize a Permanent Standby Server
  • Configure a Standby Server to Recognize a Permanent Standby Server.


Server Administration Guide - Configure the Main Server to Recognize a Permanent Standby Server (System Architectures)

Configure the Main Server to Recognize a Permanent Standby Server

The Main server has to be able to connect to each Permanent Standby server so that it can update their databases. To make this possible, you need to configure the Main server so that it can recognize the connection to the Permanent Standby server(s):

  1. On the server that starts as Main, access the Server Configuration Tool and log on via a User account with the System Admin permission (if log on is required).
  2. Access the System Configuration>Partners settings
  3. Select the Permanent Standby tab.
  4. In the Main Connection section on the Permanent Standby tab, define the primary connection between the Main server and the Permanent Standby server. To do this, you need to use the Name/IP Address, Port, and Compress settings. There are several columns of these settings and the column you need to use depends on whether the Permanent Standby server is the first, second, third or fourth Permanent Standby server you are adding to the system architecture:
  • On Hot-Standby systems, we recommend you use the Permanent Standby A column of settings for the first Permanent Standby server you add, Permanent Standby B for the second Permanent Standby server, Permanent Standby C for the third, and Permanent Standby D for the fourth (you only need to configure the settings for the number of Permanent Standby servers you have)
  • On Triple Standby systems, we recommend you use the Permanent Standby B column of settings for the first Permanent Standby server you add, Permanent Standby C for the second Permanent Standby server, and Permanent Standby D for the third.

Define the primary connection between the Main server and Permanent Standby server as follows:

  • In the Name/IP Address field, enter the name of the connection between the Main and Permanent Standby server or enter the IP address of the Permanent Standby server’s network card (the card that is used for the primary connection with the Main server).
  • In the Port field, enter the address of port that the Permanent Standby server uses to connect with the Main server. This is the port on the Permanent Standby server and not the port on the Main server.
  • Use the Compress check box to enable or disable compression on the primary connection between the Main server and the Permanent Standby server. For more information, see Define the Server Compression Settings.
  5. In the Backup Connection section, use the settings to define the secondary connection between the Main server and the Permanent Standby server. Again, you need to use the relevant column of settings (Permanent Standby A for the first Permanent Standby server that you add, Permanent Standby B for the second and so on). You only need to configure the Backup Connection settings if dual ethernet connections are being used; leave the fields empty if there is only one connection between the Main and the Permanent Standby.

To define the back up connection:

  • In the IP Address field, enter the IP address of the Permanent Standby server’s network card (the card that is used for the secondary connection with the Main server).
  • Use the Compress check box to enable or disable compression on the secondary connection between the Main server and the Permanent Standby server. For more information, see Define the Server Compression Settings.
  6. Use the Transfer settings to define the Update Rate, Connect Timeout and Request Timeout for the connection between the Main server and the Permanent Standby server(s). For more information on these settings, see Define the Transfer Update Rate and Transfer Timeouts.
  7. If you are configuring a Main server that is part of a Hot-Standby Pair with Sentinel Server Panel architecture, you should enter the Sentinel COM Port address on the Miscellaneous tab. The address is the number of the port on the Main server that is used for the connection to the Sentinel COM port.

If you are configuring a Main server that is part of a Hot-Standby Pair or Triple Standby architecture, you can skip this step and proceed to step 8.

  8. Restart the Main Server to apply the changes (see Re-Start the ClearSCADA Server).

Now that you have defined the connections from the Main server to the Permanent Standby server, you can proceed to Configure a Standby Server to Recognize a Permanent Standby Server.


Server Administration Guide - Configure a Standby Server to Recognize a Permanent Standby Server (System Architectures)

Configure a Standby Server to Recognize a Permanent Standby Server

The Standby server has to be able to connect to the Permanent Standby server as if the Standby switches to Main, it will be required to update the Permanent Standby server’s database. To make this possible, you need to configure the Standby server so that it can recognize the connection to the Permanent Standby server.

NOTE: You only need to configure the Standby server to recognize the Permanent Standby server(s) that connect to the Standby server. So on Triple Standby systems, you may have a Standby server that has no connections to a Permanent Standby server (as the Permanent Standby servers connect to the other Standby server) or you may have to configure one or more connections to either or both of the Standby servers.

To configure a Standby server to recognize a Permanent Standby server:

  1. On the server that starts as Standby, access the Server Configuration Tool and log on via a User account with the System Admin permission (if log on is required).
  2. Access the System Configuration>Partners settings
  3. Select the Permanent Standby tab.
  4. In the Main Connection section on the Permanent Standby tab, define the primary connection between the Standby server and the Permanent Standby server. To do this, you need to use the Name/IP Address, Port, and Compress settings. There are several columns of these settings and the column you need to use depends on whether the Permanent Standby server is the first, second, third or fourth Permanent Standby server you are adding to the system architecture:
  • On Hot-Standby systems, we recommend you use the Permanent Standby A column of settings for the first Permanent Standby server you add, Permanent Standby B for the second Permanent Standby server, Permanent Standby C for the third, and Permanent Standby D for the fourth (you only need to configure the settings for the number of Permanent Standby servers you have)
  • On Triple Standby systems, we recommend you use the Permanent Standby B column of settings for the first Permanent Standby server you add, Permanent Standby C for the second Permanent Standby server, and Permanent Standby D for the third.

Define the primary connection between the Standby server and Permanent Standby server as follows:

  • In the Name/IP Address field, enter the name of the connection between the Standby and Permanent Standby server or enter the IP address of the Permanent Standby server’s network card (the card that is used for the primary connection with the Standby server).
  • In the Port field, enter the address of port that the Permanent Standby server uses to connect with the Standby server. This is the port on the Permanent Standby server and not the port on the Standby server.
  • Use the Compress check box to enable or disable compression on the primary connection between the Standby server and the Permanent Standby server. For more information, see Define the Server Compression Settings.
  5. In the Backup Connection section, use the settings to define the secondary connection between the Standby server and the Permanent Standby server. Again, you need to use the relevant column of settings (Permanent Standby A for the first Permanent Standby server that you add, Permanent Standby B for the second and so on). You only need to configure the Backup Connection settings if dual ethernet connections are being used; leave the fields empty if there is only one connection between the Standby and the Permanent Standby.

To define the back up connection:

  • In the IP Address field, enter the IP address of the Permanent Standby server’s network card (the card that is used for the secondary connection with the Standby server).
  • Use the Compress check box to enable or disable compression on the secondary connection between the Standby server and the Permanent Standby server. For more information, see Define the Server Compression Settings.
  6. Use the Transfer settings to define the Update Rate, Connect Timeout and Request Timeout for the connection between the Standby server and the Permanent Standby server(s). For more information on these settings, see Define the Transfer Update Rate and Transfer Timeouts.
  7. If you are configuring a Standby server that is part of a Hot-Standby Pair with Sentinel Server Panel architecture, you should enter the Sentinel COM Port address on the Miscellaneous tab. The address is the number of the port on the Standby server that is used for the connection to the Sentinel COM port.

If you are configuring a Standby server that is part of a Hot-Standby Pair or Triple Standby architecture, you can skip this step and proceed to step 8.

  8. Restart the Standby Server to apply the changes (see Re-Start the ClearSCADA Server).


Server Administration Guide - De-Militarized Zone (DMZ) Permanent Standby Servers (System Architectures)

De-Militarized Zone (DMZ) Permanent Standby Servers

De-Militarized Zone (DMZ) Permanent Standby servers are servers that are used as an additional part of a Hot-Standby Pair or Triple Standby architecture. Like 'normal' Permanent Standby servers, they can only be set to Standby and cannot switch to Main. However, they have one key difference to 'normal' Permanent Standby servers—DMZ servers have no connection back to the system, and so cannot write to the system. This means that DMZ Permanent Standby servers offer more protection against malicious attacks, as they cannot be used to write data or interfere with the ClearSCADA database. Another benefit is that as there is no connection back to the system, it makes the configuration of a firewall between the system and the DMZ Permanent Standby server a much simpler task.

DMZ Permanent Standby servers are only able to provide read-only access to clients. Any clients that connect to ClearSCADA via a DMZ Permanent Standby server can be used to display data, but cannot be used to perform controls etc.

With a 'normal' Permanent Standby server, the Permanent Standby server can send data to, and receive data from the Main and Standby servers.
With a DMZ Permanent Standby server, the DMZ Permanent Standby server can only receive updates from the Main server (as part of the synchronization process). Any read requests are handled locally by the DMZ server itself, based on the information it has received from the Main server.

As with normal Permanent Standby servers, DMZ Permanent Standby servers can be used:

  • As a ‘performance firewall’—clients can connect to the system via the DMZ Permanent Server instead of the Main or Standby server, which reduces the demand on the Hot-Standby Pair’s resources. However, the clients will only provide read access to the system data; they cannot be used to perform controls as the DMZ Permanent Standby server cannot write to the system.
  • To improve performance for clients. This applies to read operations where the clients would have to connect to the Standby server over a slow WAN. Instead of reading data from the Standby server, the clients can be connected to the DMZ Permanent Standby locally—they can read the data from the DMZ Permanent Standby instead of the Standby and so avoid the need to use the WAN.
  • To increase the amount of historic data that is available on-line. By configuring a DMZ Permanent Server to store more historic data on-line, you can increase the amount of historic data that is available on-line without affecting the Main and Standby server’s resources. For example, a DMZ Permanent Standby server can be configured to store historic data on-line for 5 years while the Main and Standby servers can be configured to store historic data on-line for only 1 year.

ClearSCADA allows you to connect up to four DMZ Permanent Standby servers to a Hot Standby Pair architecture or up to three DMZ Permanent Standby servers to a Triple Standby architecture. Typically, a system that uses DMZ Permanent Standby servers is set up as follows:

  • Clients that are used by operators and engineers are connected to a Hot-Standby Pair or Triple Standby architecture. As these are the users that use the system to monitor and control plant, they need to have a larger amount of system resources available so that they can react quickly and efficiently to ‘real-life’ situations on site.
  • Clients that are used by managers, administrators and analysts are connected to a Permanent Standby server or a DMZ Permanent Standby server. This provides access to the data on the system without placing a high demand on the resources of the Main and Standby servers. So managers, administrators and analysts can access the system data and statistics without affecting the load on the Main and Standby servers. Users that connect to the system via a DMZ Permanent Standby server cannot perform controls and other ‘write’ actions.

NOTE: A DMZ Permanent Standby server that is used in a Triple Standby architecture can only connect to two of the three Main/Standby servers. For more information, see Configure Triple Standby.

NOTE: Multi-server systems (redundancy) require a license and so are only supported by full versions of ClearSCADA.

To set up a multi-server architecture that uses one or more DMZ Permanent Standby servers, refer to the following section:

  • Add a DMZ Permanent Standby Server.


Server Administration Guide - Add a DMZ Permanent Standby Server (System Architectures)

Add a DMZ Permanent Standby Server

The process for adding and configuring a DMZ Permanent Standby server is very similar to the process used when adding and configuring a 'normal' Permanent Standby server. The only differences are:

  • When you configure the server that is to be a DMZ Permanent Standby server, you need to select DMZ Permanent Server in the Type combo box.
  • When you are configuring the Main and Standby servers to recognize the DMZ Permanent Standby server(s), you need to select the DMZ check box. The DMZ Permanent Standby server will be unable to connect to the system if the DMZ check box(es) are cleared.

ATTENTION: If you configure a 'normal' Permanent Standby server and then configure the Main server or Standby server to have the DMZ setting enabled for the Permanent Standby server, the connection will fail. A Main server or Standby server can only connect to a Permanent Standby Server if the Permanent Standby server’s Type is set to Permanent Standby Server and the DMZ check box is clear on the Main and Standby servers. Similarly, a Main or Standby server can only connect to a DMZ Permanent Standby server if the DMZ Permanent Standby server’s Type is set to DMZ Permanent Standby Server and the DMZ check box is selected on the Main and Standby servers.

The other aspects of the DMZ Permanent Server configuration are the same as those for the configuration of a 'normal' Permanent Server.

So, to configure a DMZ Permanent Standby server, you need to:

  1. Add a DMZ Permanent Standby server in the same way as you would add a 'normal' Permanent Standby server, with the following exception:
  • Choose DMZ Permanent Standby Server as the Type. Do not choose Permanent Standby Server as the type as this will set the server to have a connection back to the ClearSCADA system.
  2. Configure the DMZ Permanent Standby server to recognize the Main and Standby servers as appropriate. (Use the Standby A and Standby B settings in the same way as you would when configuring a 'normal' Permanent Standby' server).
  3. Configure the Main server to recognize the DMZ Permanent Standby server. To do this, you need to use the settings in the Permanent Standby A, Permanent Standby B, Permanent Standby C and Permanent Standby D columns, in the same way as you would when configuring a Main server to recognize a 'normal' Permanent Standby server. The only difference is that you need to select the DMZ check box so that the Main server can establish a connection to the DMZ Permanent Standby server.
  4. Configure the Standby server to recognize the DMZ Permanent Standby server. To do this, you need to use the settings in the Permanent Standby 1 or Permanent Standby 2 columns, in the same way as you would when configuring a Standby server to recognize a 'normal' Permanent Standby server. The only difference is that you should select the DMZ check box so that the Standby server can establish a connection to the DMZ Permanent Standby server.

Further Information

Add a Permanent Standby Server to a System

Configure a Permanent Standby Server.


Server Administration Guide - Dual Network Servers (System Architectures)

Dual Network Servers

Some servers are fitted with two network cards and so can support dual networking (multiple physical connections between network devices). Typically, dual network servers are used with ClearSCADA to provide redundancy—they allow a server to have two physical connections to another server, meaning that should one network path fail, ClearSCADA can use the ‘backup’ network path instead. Dual networking can also be used to isolate networks and to provide additional bandwidth.

To configure dual networking, you need to use Microsoft Windows Control Panel (Control Panel>Network Connections). In the configuration for each network card, you will need to define:

  • An IP address—Used to identify the port used by each card
  • A subnet—Defines the number of IP addresses that are available in the network.

When you have set up each network card in Windows, you will need to configure ClearSCADA to recognize the two network cards (see Configure the Main and Backup Connections).

Further Information

For more information on setting up network cards in Windows, please refer to the documentation supplied with your network cards.


Server Administration Guide - Configure the Partners Settings of a Server (System Architectures)

Configure the Partners Settings of a Server

The Server Configuration Tool has a Partners section that you should use to define the server architecture being used on your system.

The Partners section contains:

  • Type—Use to define the type of architecture or server that you are configuring (see Type).
  • Standby tab—Use to define the Main and Standby server connection settings (see Standby Tab)
  • Permanent Standby tab—Use to define the connection settings for Permanent Standby servers (see Permanent Standby Tab)
  • Miscellaneous tab—Use to define the Action on Isolated, Arbitration Priority, Historic Synchronization, Sentinel COM Port, Heartbeat Timeout, Historic Modified Life, and Historic Annotation Life settings as required.


Server Administration Guide - Type (System Architectures)

Type

Use the Type field on the Partners section of the Server Configuration Tool to define the type of server you are configuring. For more information, see Set the Type of Server.


Server Administration Guide - Standby Tab (System Architectures)

Standby Tab

Use the Standby tab to configure the settings for the connection between the server on which you are working and the other Main/Standby servers in the architecture.

The Standby tab’s settings are arranged in columns, with settings for Standby A and settings for Standby B (only available when the Type is set to Triple Standby). Use the settings in the Standby A column to define the configuration of the connection between the server you are configuring and one of the other Main/Standby servers in the architecture. On Triple Standby systems, the Standby B settings can be used to define the connection to the other Main/Standby in the architecture.

The Standby tab contains these settings:

  • Main Connection—Use to configure the main connection between the server and the other server(s) in the system architecture. The Main Connection settings are:
  • Name/IP Address—Use to define the name(s) or IP address(es) of the other server(s) in the system architecture (see Define the Names/IP Addresses of the Other Servers).
  • Port—Use to define which ports are used by the other server(s) in the system architecture (see Define the Port Settings for a Server’s Connections).
  • Compress—Use to enable or disable data compression for communications with each of the other servers in the system architecture (see Define the Server Compression Settings).
  • ICMP Monitor 1—Use to define the IP address of the device that will be tested by an additional ICMP check (see Define the ICMP Monitor Settings for a Server).
  • ICMP Monitor 2—Use to define the IP address of the device that will be tested by an additional ICMP check (see Define the ICMP Monitor Settings for a Server).
  • ICMP Monitor 3—Use to define the IP address of the device that will be tested by an additional ICMP check (see Define the ICMP Monitor Settings for a Server).
  • Backup Connection—Use to configure the backup connection between the server and the other server(s) in the system architecture. You only need to use the following Backup Connection settings if your system uses dual ethernet connections:
  • IP Address—Use to define the IP address(es) of the other server(s) in the system architecture (see Define the Names/IP Addresses of the Other Servers).
  • Port—Use to define which ports are used by the other server(s) in the system architecture (see Define the Port Settings for a Server’s Connections).
  • Compress—Use to enable or disable data compression for communications with each of the other servers in the system architecture (see Define the Server Compression Settings).
  • ICMP Monitor 1—Use to define the IP address of the device that will be tested by an additional ICMP check (see Define the ICMP Monitor Settings for a Server).
  • ICMP Monitor 2—Use to define the IP address of the device that will be tested by an additional ICMP check (see Define the ICMP Monitor Settings for a Server).
  • ICMP Monitor 3—Use to define the IP address of the device that will be tested by an additional ICMP check (see Define the ICMP Monitor Settings for a Server).
  • Monitor—Use to define the timeout settings for the checks that are performed via the Main Connection and the Backup Connection:
  • Connect Timeout—Define the amount of time, in seconds, that the server will wait for a monitor connection to occur (see Define the Monitor Timeout Settings for a Server).
  • Request Timeout—Define the amount of time, in seconds, that the server will wait for a response from the other server(s). For more information, see Define the Monitor Timeout Settings for a Server.
  • Transfer—Use to define the establishment and update settings for the Main-Standby communications:
  • Update Rate—The number of seconds between each attempt to update the data on the Standby server (see Define the Transfer Update Rate and Transfer Timeouts).

ATTENTION: Do not adjust the Update Rate setting of 5 unless instructed to do so by a Schneider Electric engineer. Incorrect use of the Update Rate setting can cause slow system performance.

  • Connect Timeout—Define the amount of time, in seconds, that the server will wait for a connection to occur (see Define the Transfer Update Rate and Transfer Timeouts).

ATTENTION: Do not adjust the Connect Timeout setting of 60 unless instructed to do so by a Schneider Electric engineer. Incorrect use of the Connect Timeout setting can affect the establishment of new connections (may fail to connect or only connect intermittently).

  • Request Timeout—Define the amount of time, in seconds, that the server will wait for the Standby server to respond to a data transfer request (see Define the Transfer Update Rate and Transfer Timeouts). The default Request Timeout is 240.
  • Duty Mode—Use to see Enable or Disable Duty Mode. Please be aware that Duty Mode is sometimes referred to as Duty Duty.


Server Administration Guide - Permanent Standby Tab (System Architectures)

Permanent Standby Tab

Use the Permanent Standby tab to configure the settings for the connection between the Main or Standby server on which you are working and the Permanent Standby servers in the architecture.

You only need to configure connection settings for those Permanent Standby servers that connect to the server on which you are working. For example, if you are configuring the Main server in a Triple Standby architecture, you need to configure connection settings for each of the Permanent Standby servers (as they need to connect to the Main server). But if you are configuring one of the Standby servers, you may not need to configure Permanent Standby server settings (as the Permanent Standby servers may connect to the other Standby server instead).

The settings on the Permanent Standby tab are arranged in columns, with each column representing a different Permanent Standby server.

On Hot-Standby Pair systems, we recommend you use the columns as follows:

  • Permanent Standby A—Use the settings in this column for the first Permanent Standby server that you add to the system architecture. Leave them blank if there are no Permanent Standby servers on your system.
  • Permanent Standby B—Use the settings in this column for the second Permanent Standby server that you add to the system architecture. Leave the settings blank if there is no second Permanent Standby server on your system.
  • Permanent Standby C—Use the settings in this column for the third Permanent Standby server that you add to the system architecture. Leave the settings blank if there is no third Permanent Standby server on your system.
  • Permanent Standby D—Use the settings in this column for the fourth Permanent Standby server that you add to the system architecture. Leave the settings blank if there is no fourth Permanent Standby server on your system.

On Triple Standby systems, we recommend you use the columns as follows:

  • Permanent Standby B—Use the settings in this column for the first Permanent Standby server that you add to the system architecture. Leave the settings blank if there is no Permanent Standby server on your system.
  • Permanent Standby C—Use the settings in this column for the second Permanent Standby server that you add to the system architecture. Leave the settings blank if there is no second Permanent Standby server on your system.
  • Permanent Standby D—Use the settings in this column for the third Permanent Standby server that you add to the system architecture. Leave the settings blank if there is no third Permanent Standby server on your system.

The settings on the Permanent Standby tab work in the same way as the similarly named settings on the Standby tab. The only difference is that they apply to the connection between the server you are configuring and the various Permanent Standby servers.

For more information, refer to the following sections:

  • Main Connection—see Configure the Main and Backup Connections
  • Backup Connection—see Configure the Main and Backup Connections
  • Transfer—see Define the Transfer Update Rate and Transfer Timeouts.


Server Administration Guide - Miscellaneous Tab (System Architectures)

Miscellaneous Tab

You can use the Miscellaneous tab to configure the following settings for the server:

  • Action on Isolated—Define what action the server takes if it loses its connection to the other server(s). For more information, see Define what Action Should Be Taken when the Server is Isolated.
  • Arbitration Priority—Define whether the server becomes Main in preference to other servers in Main-Main or Main-Main-Main situations (see Define the Server’s Arbitration Priority).
  • Historic Synchronization—Define the amount of historic data that is synchronized (see Define the Server’s Historic Synchronization Settings).
  • Sentinel COM Port—Define the address of the server port that is used to connect to a Sentinel Panel. This only applies to servers in a Hot-Standby with Pair Sentinel Panel architecture (see Configure a Hot-Standby Pair with Sentinel Server Panel).
  • Heartbeat Timeout—Define the amount of time the server will wait for other servers to respond to a heartbeat poll (see Define the Heartbeat Timeout for a Server).
  • Historic Modified Life—Define the amount of time for which the server stores modified historic data (see Define the Server’s Historic Modified and Annotation Life Settings)
  • Historic Annotation Life—Define the amount of time for which the server stores annotation data (see Define the Server’s Historic Modified and Annotation Life Settings).


Server Administration Guide - Set the Type of Server (System Architectures)

Set the Type of Server

The Server Configuration Tool’s System Configuration>Partners settings include Type, which you can use to define the type of server architecture to which the server you are configuring belongs. For example, if you are configuring a server that is to be a Standby server in a Triple Standby architecture, you should set the Type to Triple Standby.

The Type setting defines the server’s role in the system architecture and can be set to:

  • Lone Server—The server is a stand-alone server (see Lone Server Architecture). The server you are configuring does not connect to any other server in the system.
  • Hot-Standby Pair—The server is part of a Hot-Standby Pair (either the Main server or the Standby server). For more information, see Hot-Standby Pair Architecture.
  • Triple Standby—The server is part of a Triple Standby architecture (either the Main server or one of the two Standby servers). For more information, see Triple Standby Architecture.
  • Permanent Standby—The server is a Permanent Standby that is used in conjunction with a Hot-Standby Pair or Triple Standby architecture (see Permanent Standby Servers).
  • Hot Standby Sentinel—The server is part of a Hot-Standby Pair that connect to outstations, PLCs and similar devices via a Sentinel Panel (the server is either the Main server or the Standby server). For more information, see Hot-Standby Pair with Sentinel Server Panel Architecture.
  • DMZ Permanent Standby—The server is a Permanent Standby that is used in conjunction with a Hot-Standby Pair or Triple Standby architecture and has the DMZ (De-militarized Zone) setting enabled (see De-Militarized Zone (DMZ) Permanent Standby Servers).


Server Administration Guide - Configure the Main and Backup Connections (System Architectures)

Configure the Main and Backup Connections

Multi-server systems can use single or dual ethernet (dual network) connections between the servers.

When a single ethernet connection is used, there is only one connection and this is referred to as the ‘Main’ connection.

When dual ethernet connections are used, there are two connections—the ‘Main’ connection and a ‘Backup’ connection. The ‘Backup’ connection is only used if the ‘Main’ connection fails. If a failed ‘Main’ connection is restored, the server will stop using the ‘Backup’ connection and will return to using the ‘Main’ connection instead.

Dual ethernet connections can only be used with servers that support dual networking and have two network cards. ClearSCADA only supports dual networking when:

  • The server’s 2 network cards have different subnets (defined in the network card configuration made via the Windows Control Panel>Network Connections settings).
  • The server’s 2 network cards have the same subnet but use ‘teaming’. When ‘teaming’ is enabled, both Windows and ClearSCADA recognize the two cards as a single network. ‘Teaming’ is a server feature that is supported by some network cards. For information on setting up the ‘teaming’ feature, please refer to the manufacturer’s documentation supplied with your server or network cards.

If your server has 2 network cards that have the same subnet but do not support ‘teaming’, you can either:

  • Re-engineer your network so that there are two subnets, and then reconfigure the network cards to use the subnets (the network cards should use different subnets).

or:

  • Configure ClearSCADA to use only a single network (set ClearSCADA to ignore the second network interface).

You can configure the settings for the ‘Main’ and ‘Backup’ connections on the Server Configuration Tool’s Partners tab:

To configure the Main Connection and Backup Connection settings, perform the following tasks on each server in the server architecture:

  1. Display the Server Configuration Tool and access the System Configuration>Partners settings.
  2. Define the Names/IP Addresses of the Other Servers.
  3. Define the Port Settings for a Server’s Connections.
  4. Define the Server Compression Settings.
  5. Define the ICMP Monitor Settings for a Server.

Define the Names/IP Addresses of the Other Servers

When you are configuring a server that is part of a multi-server architecture, you need to specify the Name or IP Address of every other server in the architecture. The server will use this information in conjunction with the Port settings to recognize the other servers.

You need to specify the Name or IP Address for every server that connects via the main connection. If a dual ethernet connection is in operation, you will also need to specify the IP Address of every server that connects via the backup connection.

The Server Configuration Tool’s Partners settings includes a Main Connection section and a Backup Connection section.

In the Main Connection section, you should define the Name or IP Address of every other server that uses the main connection to communicate with the server you are configuring.

  • If you are configuring the server that starts as Main in a Hot-Standby Pair, you should enter the Name or IP Address of the Standby server in the Name/IP Address field in the Standby A column. This should be the name of the connection or the IP address of the network card used by the Standby server to connect to the Main server that you are currently configuring.
  • If you are configuring the server that starts as the Standby in a Hot-Standby Pair, you should enter the name or IP Address of the Main server in the Name/IP Address field in the Standby A column. This should be the name of the connection or the IP address of the network card used by the Main server to connect to the Standby server that you are currently configuring.
  • If you are configuring the server that starts as Main in a Triple Standby architecture, you should define the name or IP address of one of the Standby servers in the Name/IP Address field in the Standby A column. You should use the Name/IP Address field in the Standby B column to define the name or address of the other Standby server. In both cases, you need to define the names of the connections or enter the IP addresses used by the network cards in the Standby servers.
  • If you are configuring a server that starts as Standby in a Triple Standby architecture, you should define the name or IP address of the Main server in the Name/IP Address in the Standby A column. You should use the Name/IP Address field in the Standby B column to define the name or IP address of the other Standby server. In both cases, you need to define the names of the connections or enter the IP addresses used by the network cards in the other servers.
  • If you are configuring a Permanent Standby server, you should define the name or IP address of the Main server in the Name/IP Address field in the Standby A column. This should be the name of the connection or the IP address of the network card used by the Main server to connect to the Permanent Standby server that you are currently configuring.

You should use the Name/IP Address field in the Standby B column to define the name or IP address of the Standby server. Be aware that on Triple Standby systems, a Permanent Standby server can only connect to one of the two Standby servers, and so you should define the name or IP address of the chosen Standby server.

NOTE: If there is a dual ethernet network connection, you should enter the IP addresses of the servers.

If your system uses a dual ethernet connection, you can use the Backup Connection section to define the IP address of every other server that connects via the backup connection.

  • If you are configuring the server that starts as Main in a Hot-Standby Pair, you should enter the IP Address of the Standby server in the field in the Standby A column. This should be the IP address of the network card used by the Standby server to connect to the Main server that you are currently configuring.
  • If you are configuring the server that starts as the Standby in a Hot-Standby Pair, you should enter the IP Address of the Main server in the field in the Standby A column. This should be the IP address of the network card used by the Main server to connect to the Standby server that you are currently configuring.
  • If you are configuring the server that starts as Main in a Triple Standby architecture, you should define the IP address of one of the Standby servers in the field in the Standby A column. You should also enter the IP address of the other Standby server in the field in the Standby B column. In both cases, you need to enter the IP addresses used by the network cards in the Standby servers.
  • If you are configuring a server that starts as Standby in a Triple Standby architecture, you should define the IP address of the Main server in the Standby A field and the IP address of the other Standby server in the Standby B field. In both cases, you need to enter the IP addresses used by the network cards in the other servers.
  • If you are configuring a Permanent Standby server, you should define the IP address of the Main server in the field in the Standby A column. You should use the field in the Standby B column to define the IP address of the chosen Standby server.

When you have defined the Names or IP Addresses for the Main Connection (and Backup Connection as required), you will need to define the following settings:

  • Port (see Define the Port Settings for a Server’s Connections)
  • Compress (see Define the Server Compression Settings)
  • ICMP Monitor 1 (see Define the ICMP Monitor Settings for a Server)
  • ICMP Monitor 2 (see Define the ICMP Monitor Settings for a Server)
  • ICMP Monitor 3 (see Define the ICMP Monitor Settings for a Server).

Define the Port Settings for a Server’s Connections

For servers that are part of a multi-server architecture, you need to specify which ports the other servers in the architecture use for the main connection (where applicable). The port information is used in conjunction with the Name or IP Address to allow the server to recognize the other servers in the server architecture.

To define the port settings for a server’s primary connection, you need to use the Server Configuration Tool’s Partners settings. The Port fields are shown in the Main Connection sections which are available on the Standby tab and the Permanent Standby tab. You should use the Standby tab to define the Port settings for the primary connections between Main/Standby servers. Use the Permanent Standby tab to define the Port settings for the primary connections between Main/Standby servers and Permanent Standby servers.

There are Port settings on the Standby and Permanent Standby tabs.

There are Port fields for:

  • Standby A—The other server in a Hot-Standby Pair or one of the other servers in a Triple Standby architecture. On Triple Standby systems, we recommend that you use the Standby A column of fields to represent the server that starts as Main.
  • Standby B—The remaining server in a Triple Standby architecture.
  • Permanent Standby A—The first Permanent Standby server, if Permanent Standby servers are being used
  • Permanent Standby B—The second Permanent Standby server, if two or more Permanent Standby servers are being used.
  • Permanent Standby C—The third Permanent Standby server, if three or more Permanent Standby servers are being used
  • Permanent Standby D—The fourth Permanent Standby server, if four Permanent Standby servers are being used.

You need to enter the correct port number for each of the other servers that use the Main Connection. If you do not know which ports are being used by the other servers, you can access this information by using the Server Configuration Tool. Simply log on to the other server, access the Server Configuration Tool, and examine the Server entry in the Global Parameters>Advanced settings. The Server entry is the port number that is used to connect via the Main connection. You will need to repeat this on each of the servers in the architecture (assuming that you do not already know which ports are used by the other servers).

Example:

If you were configuring the Main server in a Hot-Standby architecture, you would:

  1. In the Main Connection section, enter the IP address of the Standby server in the Name/IP Address field for the Standby A column.
  2. To find out which port is being used by the Standby server, you log on to the Standby server, display its Server Configuration Tool, and check the Server entry in the Global Parameters>Advanced settings. The Server entry is 5481.
  3. Return to the Partners settings on the Main server and enter 5481 in the Port field for the Standby A column in the Main Settings section.

When you have defined the Port addresses for the Main Connection, you will need to define the following settings:

  • Compress (see Define the Server Compression Settings)
  • ICMP Monitor 1 (see Define the ICMP Monitor Settings for a Server)
  • ICMP Monitor 2 (see Define the ICMP Monitor Settings for a Server)
  • ICMP Monitor 3 (see Define the ICMP Monitor Settings for a Server).

Define the Server Compression Settings

Performance issues can arise on multi-server systems that have connections with limited bandwidth. To avoid these issues, you can enable the compression feature for each server on both the main connection and the backup connection.

The compression feature reduces the amount of data that is sent between servers in a multi-server architecture. This is useful on systems that have connections with limited bandwidth as it means data can be transferred between servers more quickly. However, the compression feature makes greater use of the servers’ processors as the data has to be compressed and decompressed.

We recommend that you only enable the compression feature on servers with low bandwidth connections (typically less than 10Mb per second). You should not enable compression on connections that have adequate bandwidth as this will may result in reduced performance at the server (as the server has to compress and decompress data unnecessarily).

To enable or disable compression, you need to use the Server Configuration Tool’s Partners settings. The Partners settings provide Compress check boxes for the connections between the server you are configuring and each of the other servers in the architecture:

  • On the Standby tab, there are Compress check boxes for the Main and Backup connections in both the Standby A and Standby B columns (which represent the connections to the other Main/Standby servers).
  • On the Permanent Standby tab, there are Compress check boxes for the Main and Backup connections in the Permanent Standby A, Permanent Standby B, Permanent Standby C, and Permanent Standby D columns (which represent the connections from the Main/Standby server you are configuring to the Permanent Standby servers on your system).

To enable compression, simply select the relevant Compress check box; to disable compression, clear the relevant Compress check box. For example, if you are configuring a Standby server that is part of a Hot-Standby pair architecture and you want to enable compression on the primary connection to the Main server, select the Compress check box in the Standby A column. This instructs ClearSCADA to compress the data transactions between the Standby server you are configuring and the Main server in the Hot-Standby Pair (when the servers are communicating via the primary connection).

If you enable compression on one server in a multi-server architecture, we recommend that you configure the same Compress settings on the other servers. If the servers in a multi-server architecture have different compression settings, the settings of whichever server is Main are applied. This means that the data transactions may switch between being compressed and decompressed depending on which server is Main at the time of the data transfer.

NOTE: You can quantify the effects of the compression feature by examining the Server>Links statistics on the Server Status Tool (see Links (Server) in the ClearSCADA Guide to the Server Status Tool).

Define the ICMP Monitor Settings for a Server

Each ClearSCADA server in a multi-server architecture performs checks on the other servers in the architecture. By default, each server performs two checks:

  • A ClearSCADA server to ClearSCADA server check via TCP/IP. This check is designed to test the status of the ClearSCADA software in each of the servers in the architecture. If this check returns a ‘healthy’ result, it indicates that the server software is working correctly and that the network between the servers is operational.
  • A ClearSCADA server to Server hardware check via ICMP. This check is designed to test the status of the server components.

These default checks are used by ClearSCADA to detect problems with the servers and the network connection between the servers. However, you can also configure ClearSCADA to perform up to three additional ICMP checks on ICMP compatible devices that are connected to the network, such as client PCs, printers and routers. These extra checks are useful as they can also be used to provide confirmation of a network failure.

The diagram below shows a server on one side of a WAN (Site A) monitoring the server on the other side (Site B).

The server at Site B also performs the same checks on the server at Site A.

To configure the additional ICMP Monitor checks for a server:

  1. Access the System Configuration>Partners settings on the Server Configuration Tool.
  2. In the ICMP Monitor 1, ICMP Monitor 2 and ICMP Monitor 3 fields, enter the IP Addresses of the devices that are to be tested by the additional ICMP Monitor checks. For example, if you are configuring a server to perform an additional ICMP monitor check on a client and a router, you would enter the IP address of the client in the ICMP Monitor 1 field and the IP address of the router in the ICMP Monitor 2 field.
  3. If the server has a back up connection (uses dual ethernet connections), enter the IP addresses for the devices in the corresponding ICMP Monitor fields in the Backup Connection section.
  4. Right-click on the system icon in the hierarchy on the Server Configuration Tool, then select the Apply Changes option. The ICMP settings you have made are now in place.

During normal conditions, the servers will run the TCP/IP server-server and ICMP checks continuously and return ‘healthy’ results.

If the TCP/IP check returns a ‘failed’ result, the servers use the ICMP checks to determine the reason for the TCP/IP failure:

  • If all of the ICMP checks return ‘failed’ results, it indicates that the network between the servers has failed. The server that is Main at that time will continue to run as the Main server. The server that is Standby will use its Action on Isolated setting to determine what action should be taken (see Define what Action Should Be Taken when the Server is Isolated).
  • If some, but not all, ICMP checks fail, it means that the network between the servers is operational (as at least one ICMP check was successful). The failed ICMP checks indicate that a server has failed, possibly due to:
  • hardware failure, such as a failed component in the server
  • software failure, for example, an operating system error
  • human error, for example, if a server has been shut down manually by mistake.

In this situation, if the healthy server (the server that has not failed) is the Standby server, it will switch to Main. If the healthy server is the Main server, it will continue as the Main server.


Server Administration Guide - Define the Monitor Timeout Settings for a Server (System Architectures)

Define the Monitor Timeout Settings for a Server

Each server in a multi-server architecture monitors the other servers in the architecture to check that the hardware, software and network connections are working correctly. To do this, each server performs up to 4 checks:

  • A TCP/IP server software to server software check
  • A ICMP server to server hardware check
  • Up to two additional ICMP server to server hardware checks.

For more information on these checks, see Define the ICMP Monitor Settings for a Server).

During each check, a server attempts to make a connection with one of the other servers in the architecture. It also requests a response from the other server. If the connection is not made or a response is not received within a specified amount of time, the other server regards itself as isolated and takes the appropriate action (as defined in the Action on Isolated setting, see Define what Action Should Be Taken when the Server is Isolated).

You can configure the amount of time a server will wait for a connection to another server and how long it will wait for a response to a request. To do this, you need to use the System Configuration>Partners settings in the Server Configuration Tool. The Standby tab of the Partners settings has a Monitor section that contains the monitoring Connect Timeout and Request Timeout settings

  • Connect Timeout—Define the amount of time, in seconds, that the server will wait for a monitor connection to occur. If there is no monitor connection between the server you are configuring and the other server after the defined Connect Timeout, the other server will regard itself as isolated and will take the appropriate action (as defined in the Action on Isolated setting, see Define what Action Should Be Taken when the Server is Isolated).
    The default setting is 60.
  • Request Timeout—Define the amount of time, in seconds, that the server will wait for a response from the other server(s). If there is no response after the defined Request Timeout, the other server will regard itself as isolated and will take the appropriate action (as defined in the Action on Isolated setting, see Define what Action Should Be Taken when the Server is Isolated).
    The default setting is 240.

Typically, the default settings of 60 and 240 seconds are appropriate. However, if you need the checks to detect faults more quickly, you can reduce the timeout amounts. But be aware that if the timeouts are too short, a server may regard itself as isolated before it has had time to process a response to a request (or complete the connection establishment process).


Server Administration Guide - Define the Transfer Update Rate and Transfer Timeouts (System Architectures)

Define the Transfer Update Rate and Transfer Timeouts

The Server Configuration Tool’s System Configuration>Partners settings have Transfer sections that you can use to define:

  • How often the server will attempt to update the data on the other server(s) in the architecture (Update Rate)
  • The amount of time the server will wait for a connection to be made to the other server(s) (Connect Timeout)
  • The amount of time the server will wait for the other server(s) to respond to a request (Request Timeout).
  • Whether the server has Duty Mode enabled or disabled. This setting is only applicable to Main/Standby servers and so is only available on the Standby tab. For more information on Duty-Duty support, see Enable or Disable Duty Mode.
  • Whether the Permanent Standby server is a De-militarized Zone Permanent Standby server (DMZ). This setting is only applicable to Permanent Standby servers and so is only available on the Permanent Standby tab. For more information, see Add a DMZ Permanent Standby Server.

There are Transfer settings for each server connection, with connections to the Main/Standby servers represented by the Standby A and Standby B columns on the Standby tab.

The Transfer settings for connections to Permanent Standby servers are shown on the Permanent Standby tab in columns representing each Permanent Standby (Permanent Standby A, Permanent Standby B, Permanent Standby C, and Permanent Standby D).

You need to set appropriate update and timeout times as these settings affect the running of your multi-server architecture. For many systems, you will not need to change the default settings,. However, if you require alternate time settings, you need to be aware of the possible effects that can be caused by changing the times.

For each server that can be a Standby server in the system architecture, you can define the following Transfer settings:

  • Update Rate—The number of seconds between each attempt to update the data on the Standby server. For many systems, you will not need to change the default setting of 5 seconds.

If you have a large system, the main server may be affected by a high load due to a high number of updates placing a large demand on the server’s resources. If your system is experiencing slow performance, you may need to increase the Update Rate so that the main server updates the Standby server(s) less frequently.

If the data on the Standby server is being updated too slowly, you may need to decrease the Update Rate so that updates occur more frequently. Be aware that this may affect the load on the main server and so could lead to slow performance.

ATTENTION: Do not adjust the Update Rate setting of 5 unless instructed to do so by a Schneider Electric engineer. Incorrect use of the Update Rate setting can cause slow system performance.

  • Connect Timeout—Define the amount of time, in seconds, that the server will wait for a connection to occur. This works in the same way as the Connect Timeout field in the Monitor section, except that it applies to the server's attempts to establish a connection with another server for the purpose of transferring data (rather than establishing a connection for monitoring the other server). For more information, see Define the Monitor Timeout Settings for a Server.

Typically, the default setting of 60 seconds is appropriate. You may need to increase the Connect Timeout if the system incorrectly regards a connection as having failed when it is still in the process of being established.

ATTENTION: Do not adjust the Connect Timeout setting of 60 unless instructed to do so by a Schneider Electric engineer. Incorrect use of the Connect Timeout setting can affect the establishment of new connections (may fail to connect or only connect intermittently).

  • Request Timeout—Define the amount of time, in seconds, that the server will wait for the Standby server to respond to a data transfer request. If there is no response after the defined Request Timeout, the Standby server is deemed to have failed.


Server Administration Guide - Enable or Disable Duty Mode (System Architectures)

Enable or Disable Duty Mode

Duty Mode, also known as Duty Duty mode, allows a Standby server to transfer data to a Main server following a Main-Main situation. It is designed for use on Hot-Standby Pair systems that have devices that can report independently to any server in the server architecture. For example, PSTN outstations often have the ability to dial in to the Main server or any Standby server independently.

Main-Main situations can occur when the connection between the Main server and the Standby server is lost. As the servers cannot connect to each other, they become isolated and, depending on their configuration, can switch to Main. When more than one server is Main, the Main servers will communicate with the outstations independently as they cannot communicate with the other servers.

When the communications load is reduced or the connection between the servers is restored, the servers arbitrate to determine which server switches to Standby.

If the Duty Mode feature is disabled (as it is by default), any data that is on the server that switches to Standby is lost. This is because the server that remains as Main after the arbitration process has to send a copy of its data to the Standby server. The data from the Main server overwrites the data on the Standby server so that both servers have the same data.

By enabling the Duty Mode feature, you can configure ClearSCADA to keep the data on the server that is the Standby (after the arbitration process). This is made possible as the Duty Mode feature allows ClearSCADA to compare the time stamps of the data on the servers. The data with the most recent time stamps is kept and is merged into the data on the Main server and the rest of the data is discarded.

When the Main server receives the more recent data, from the Standby server, it merges the data with its own data and then sends an update to the Standby server. This means that the Main and Standby servers have identical data.

You can enable or disable Duty Mode on any server that is part of a Hot-Standby Pair architecture (we do not recommend that this setting is used with Triple Standby systems). However, enabling Duty Mode will increase the load on the server and may affect system performance.

When configuring Duty Mode support, you should first establish that all servers in the system architecture have the same settings i.e Duty Mode is enabled on every server or is disabled on every server. If Duty Mode is enabled on some servers but disabled on others, your system may lose data during a Main-Main situation.

To enable Duty Mode:

  1. Display the Server Configuration Tool and access the System Configuration>Partners settings.
  2. In the Transfer section on the Standby tab, there are Duty Mode check boxes for each of the servers with which the server you are configuring communicates. Select the check boxes to enable Duty Mode. For example, if you select the Duty Mode check box for Standby A, it means that if the server you are configuring goes Standby following a Main-Main situation, it can update Standby A if required. Remember that your Duty Mode settings have to be consistent on each of the servers in the architecture.

If you want to disable Duty Mode, clear the Duty Mode check boxes as required.

NOTE: You also need to enable Duty Mode on the relevant outstations via the Outstation Configuration Forms.

Further Information

‘First Pass’ Synchronization Process (Duty Mode Enabled).


Server Administration Guide - Define what Action Should Be Taken when the Server is Isolated (System Architectures)

Define what Action Should Be Taken when the Server is Isolated

In multi-server architectures, it is possible for a Main server to lose its connection to the Standby server(s), for example, if there is a network failure. When this happens, the Standby server is deemed to be ‘isolated’ - it cannot communicate with the Main server.

NOTE: With Triple Standby architectures, a Standby server is only isolated if it loses its connection with both of the other servers. If it loses its connection to just one of the other servers, it will arbitrate with the remaining server and work as a Hot-Standby Pair.

When a Standby server becomes isolated, it can perform one of two actions:

  • It can switch to Main. This means that if the connections with the other servers in the architecture are lost, the server will switch to Main. As a result, the server can continue to function independently in the event of a network failure. When the network is restored, the server will arbitrate with the other servers to restore a Main-Standby relationship so that a Main-Main situation is avoided.

We usually recommend that servers in multi-server architectures are set to go Main if they become isolated.

  • It can remain as an Isolated Standby. If the connections with the other servers are lost, the server will remain as a Standby server. It will remain as a Standby until the connection is restored at which point it will arbitrate with the other servers.

We recommend that servers are only set to remain as Isolated Standby servers on systems that require manual intervention in the event of connection failures.

To define how the server will behave if it loses its connections with the other servers, you need to use the Action on Isolated combo box. This can be found in the Server Configuration Tool’s System Configuration>Partners settings where it is shown on the Miscellaneous tab.

You can choose from:

  • Go Main—The server will switch to Main if it loses its connection with the other servers. If the server is part of a Triple Standby architecture and it only loses a connection to one of the other servers, it will arbitrate with the remaining server (they will function as a Hot-Standby Pair until the connection with the third server is restored).
  • Go Isolated Standby—If the server loses its connection with the other servers, it will become a Standby server and remain as a Standby server until the network connections are restored. When the network connections are restored, it will arbitrate with the other server(s).

As with the Go Main setting, if the server is part of a Triple Standby architecture and it only loses a connection to one of the other servers, it will not become an isolated Standby (it will arbitrate with the remaining server and will function as part of a Hot-Standby Pair).


Server Administration Guide - Define the Server's Arbitration Priority (System Architectures)

Define the Server’s Arbitration Priority

Servers in a multi-server architecture may lose their connections with the other servers, for example, a Main server may lose its connection to a Standby server due to a network failure. When a Main server loses its connection to a Standby server, it can result in a Main-Main situation (or even Main-Main-Main situation if all network connections fail in a Triple Standby architecture). During a Main-Main situation, more than one server runs as a Main server. This means that when the connection between the servers is restored, the servers have to arbitrate to determine which server is to continue running as the Main server and which server is to switch to being a Standby server.

During the arbitration process, the servers use the following information to determine which server continues as Main:

  1. Arbitration Priority setting in the servers’ configuration
  2. Amount of time each server has been running as Main. The server that has been running as Main for the longest amount of time continues as the Main server.
  3. Amount of time each server has been running (as either/both Main or Standby).The server that has been running the longest amount of time continues as the Main server.
  4. The ASCII value of the servers’ node names. The server with the highest ASCII value for its name continues as the Main server.

These factors are considered in order, so the amount of time each server has been running is only considered in the arbitration process if the servers have identical Arbitration Priority settings.

You can use the Server Configuration Tool’s System Configuration>Partners settings to access and define the Arbitration Priority setting for a server. The Arbitration Priority setting is shown on the Miscellaneous tab.

The Arbitration Priority setting works by allowing you to enter a priority number. The server with the highest number is the server that continues to run as the Main server following a Main-Main situation. For example, if Server A has an Arbitration Priority of 0 and Server B has an Arbitration Priority of 1, then Server B will be the Main server after a Main-Main situation has been resolved. Server A would be switched from Main to Standby as its Arbitration Priority number is lower than the Arbitration Priority number of Server B.

NOTE: The ClearSCADA arbitration process can be overridden by a Sentinel Panel (in Hot-Standby Pair Sentinel Server architectures only). For more information, see Hot-Standby Pair with Sentinel Server Panel Architecture.


Server Administration Guide - Define the Server's Historic Synchronization Settings (System Architectures)

Define the Server’s Historic Synchronization Settings

On multi-server systems, the Main server and Standby server(s) synchronize their data so that the Standby server contains an accurate, up to date backup of the Main server’s data. During the synchronization process, the Main server and Standby server(s) synchronize data, including historic data. However, the amount of historic data that is synchronized is dependent on the Historic Synchronization settings in the server configuration.

There are two Historic Synchronization settings:

  • Writeable Data Only—The Main server will only update the Standby server(s) with the historic data that is writeable i.e. the historic data that can still be modified on the system. This is the default setting and is appropriate for many systems as it means the synchronization of historic data is as fast and efficient as possible. There is no need to synchronize the historic data that is non-writeable as it does not change and so will be the same on both the Main and Standby servers.
  • All Data—The Main server will update the Standby server(s) with both the writeable and non-writable historic data. This provides the Standby server with an exact copy of the historic data on the Main server, but takes considerably longer for the synchronization process to complete.

You can use the Server Configuration Tool’s System Configuration>Partners settings to access and define the Historic Synchronization setting for a server. The Historic Synchronization setting is shown on the Miscellaneous tab.

In normal operational conditions, you should choose the Writeable Data Only option so that the synchronization is optimized.

You should only choose the All Data option if the Standby server has lost its historic data due to a major failure. In such circumstances, you should configure the Main server to use the All Data historic synchronization setting so that the Standby server is updated with all historic data. When the synchronization is complete, you should then change the Main server’s configuration so that it uses the Writeable Data Only setting. This means that subsequent historic synchronization only includes the data that can change (the Standby server will already have the non-writeable historic data as this was copied to the Standby server during the earlier All Data synchronization).

NOTE: We recommend that you configure the same Historic Synchronization settings on each of the servers in the architecture. For example, if you set the Main server’s Historic Synchronization setting to Writeable Data Only, you should also set the Historic Synchronization settings of the Standby server(s) to Writeable Data Only.

Example:

A Hot-Standby Pair system consists of a Main server and a Standby server that are situated at different locations. They connect to each other via a WAN link.

The two servers have been running correctly for several years. They are both configured to use the Writeable Data Only setting so that synchronization of historic data is as fast and efficient as possible.

A fire breaks out at the site that houses the Standby server and the Standby server is destroyed. A new server is obtained and configured to be the replacement Standby server in the Hot-Standby Pair. The servers establish a connection and the Main server updates the new Standby server with its data. As the Main server is still set to use the Writeable Data Only setting, it means that only the historic data that can change is copied to the new Standby server; the Standby server does not contain the non-writeable data.

To solve this, a user re-configures the Main server so that it uses the All Data option. During the next synchronization, the Main server updates the Standby server with both writeable and non-writeable historic data. As all of the historic data is being copied to the Standby server, the synchronization process takes a much longer time to complete.

When the synchronization process is finished, the Main and Standby servers contain the same data (both writeable and non-writeable historic data). The user then re-configures the Main server so that it uses the Writeable Data Only option again. This means that subsequent synchronisations will only involve the writeable data—there is no need for the Main server to update the Standby server with the non-writeable data as the Standby server already contains the non-writeable data and it will not change. If the user did not alter the Main server’s configuration and it still used the All Data option, each synchronization would copy all of the historic data from the Main to the Standby. This would be a waste of time and system resources as the Standby would already contain the non-writeable historic data.


Server Administration Guide - Define the Heartbeat Timeout for a Server (System Architectures)

Define the Heartbeat Timeout for a Server

You can use the Heartbeat Timeout setting to define how long a server will wait before terminating a link that has been used for receiving heartbeat poll requests, but is currently idle. By default, the Heartbeat Timeout setting is 300 seconds, which means if there are no heartbeat request polls sent via an open link within 300 seconds, the server will close the link.

You can use the Server Configuration Tool’s System Configuration>Partners settings to access and define the Heartbeat Timeout setting for a server. The Heartbeat Timeout setting is shown on the Miscellaneous tab and you can use it to define the required Heartbeat Timeout in seconds. The default setting is 300 seconds and this is the recommended setting for many systems. Typically, there is no need to change this setting and we suggest that you only alter the Heartbeat Timeout if specifically requested to do so by a Schneider Electric engineer.

The remainder of this section explains how ClearSCADA uses heartbeat request polls and the heartbeat timeout to determine whether links are idle and therefore need to be closed.

In a multi-server architecture, each server polls the other servers to check that the servers can respond to each other. This is achieved by each server sending a poll request to the other servers. This poll request is called a heartbeat poll.

When a server receives a poll request, it replies by sending a response that indicates its status. This allows the servers to check that they can send communications to, and receive communications from, each server in the architecture. During normal conditions, the servers will:

  • Send heartbeat poll requests to the other servers
  • Receive heartbeat poll requests from the other servers
  • Respond to heartbeat poll requests by sending a status response.

When a server first starts, it establishes links to every other server in the architecture. Once a link has been established, the server then sends a heartbeat poll request to the other servers. In normal circumstances, the other servers will respond by sending a status response in return (via the same link). The other servers will also detect that there is a new server in the architecture and will establish their own links to the server, and send heartbeat poll requests.

So each server has 2 ‘heartbeat poll’ links with every other server. For example, in a two-server architecture, Server A has two links to Server B:

  • The link that was established by Server A, which is the link that Server A uses to send heartbeat poll requests to Server B. This link is also used by Server B to reply to the heartbeat poll requests from Server A.
  • The link that was established by Server B, which is the link that Server B uses to send heartbeat poll requests to Server A. This link is also used by Server A to reply to the heartbeat poll requests from Server B.

Each server sends a heartbeat poll request every 10 seconds. When a server receives a heartbeat poll request, it usually replies with a status response almost instantly, via the same link on which it received the request.

Once a heartbeat poll link has been established, it remains open unless no heartbeat poll requests are sent via the link for a defined time period. This time period is called the Heartbeat Timeout, and by default it is 300 seconds. If no heartbeat poll requests have been received via a link within the Heartbeat Timeout time, the recipient server (the server that is to respond to the expected poll requests) closes the link. This means that resources are not wasted on maintaining inactive links.

Example:

Server A and Server B are configured as part of a Hot-Standby Pair architecture. Server A is Main and Server B is Standby. Both servers are configured to have the default Heartbeat Timeout setting of 300 seconds.

The two servers are started. The Main server establishes a link with the Standby server and sends a heartbeat poll request via the link. The Standby server receives the heartbeat poll request and replies with a status response via the same link.

The Standby server also establishes a link to the Main server and sends a heartbeat poll request via the link. The Main server receives the heartbeat poll request and replies with a status response via the same link.

The Standby server suffers from a power supply problem and goes offline. It can no longer communicate with the Main server.

The Main server, unaware of the problem, sends a heartbeat poll request to the Standby server. The Standby server does not respond. The Main server will continue to send heartbeat poll requests every 10 seconds, until the Request Timeout is reached (the Request Timeout defined in the Transfer section of the Main server’s Partners settings, see Define the Transfer Update Rate and Transfer Timeouts). If the Main server has not received a response from the Standby server before the Request Timeout is reached, the Main server closes the link.

The Main server is also expecting to receive heartbeat poll requests via the other link (the link that was initiated by the Standby server). As the Standby server is offline, it is no longer sending heartbeat poll requests.

The Main server waits for the defined Heartbeat Timeout of 300 seconds. If the Standby server has not sent a heartbeat poll request via the link within the 300 second timeout period, the Main server closes the link.


Server Administration Guide - Define the Server's Historic Modified and Annotation Life Settings (System Architectures)

Define the Server’s Historic Modified and Annotation Life Settings

Modified historic data and annotations for historic data are not archived to disk as they can usually be stored on-line without having a detrimental effect on system performance. This is due to the small size of modified historic data and annotation records and the fact that there are usually a low amount of such records. The modified historic data and annotations are made available on-line by being stored on the servers in the system architecture.

By default, each server is set to store modified historic data and annotations for 520 weeks (10 years). For many systems, this setting is appropriate. However, you may choose to extend the number of weeks if your system is expected to continue running for over 10 years. Extending the number of weeks will mean that the modified historic data and annotations can be stored for a longer time but it will also place an extra demand on the server’s resources. The extra demand is negligible and is unlikely to affect system performance.

You can change the amount of time for which each server stores modified historic data and annotation data by using the Server Configuration Tool’s System Configuration>Partners settings. The Miscellaneous tab of the Partners settings has Historic Modified Life and Historic Annotation Life fields which you can use to change the number of weeks for which the historic modified and historic annotations data is stored on the server.

If your system is not expected to run for more than 10 years, we recommend that you leave the default settings of 520 weeks in place.


Server Administration Guide - Synchronization Process for Multi Server Architectures (System Architectures)

Synchronization Process for Multi Server Architectures

Synchronization is used to allow the Standby servers in multi server architectures to accurately reflect the data on the Main server. During the synchronization process, the Main server checks the data on the Standby servers and updates them as required.

The way that the synchronization process works differs slightly depending on whether the servers have Duty Mode enabled or disabled. However, in both cases the synchronization process consists of a ‘first pass’ and ongoing ‘short passes’. The ‘first pass’ occurs when the Main server first connects or re-connects to another server and usually takes longer to complete than a ‘short pass’ as there is more data to be transferred. The ‘short passes’ occur continuously after the ‘first pass’ has completed. They allow the Main server to update the Standby servers regularly.

For information on the ‘first pass’ part of the synchronization process, please refer to:

‘First Pass’ Synchronization Process (Duty Mode Disabled)

Or

‘First Pass’ Synchronization Process (Duty Mode Enabled)

If you are unsure as to whether your server has Duty Mode enabled or disabled, you can view the setting on the Partners section of the Server Configuration Tool (see Enable or Disable Duty Mode).

For information on the ‘short passes’, see ‘Short Pass’ Synchronization Process.


Server Administration Guide - 'First Pass' Synchronization Process (Duty Mode Disabled) (System Architectures)

‘First Pass’ Synchronization Process (Duty Mode Disabled)

The synchronization process takes place whenever a Main server connects or re-connects to another server. The steps that are taken during the synchronization process differ depending on whether the Duty Mode is enabled or Disabled on the servers. In this section, we describe the synchronization process for servers that have Duty Mode disabled (which is the default Duty Mode setting).

The synchronization process starts when:

  • A Main server establishes or re-establishes a connection with another server
  • ClearSCADA is started on a Standby server that is connected to a Main server that is already running.

For example, if a Main server loses its connection with a Standby server due to a disconnected network cable, when that cable is reconnected, the synchronization process begins.

The synchronization process consists of these steps (which are performed in order):

  1. The Main server transfers some of its Boolean (Enabled/Disabled) server configuration settings to the Standby server: Exclusive Control, Event Journal, Historic Data, Historic Validation, Historic Files, Alarms & Events, Quality Classification, Alarm Response, and Configuration Changes Auditing. Only the Enabled/Disabled settings are transferred, the other settings for each of the features need to be configured manually.
  2. The Main server transfers any metadata (custom fields) to the Standby server.
  3. The Main server transfers the database structure to the Standby server. The database structure is the hierarchy of groups, database items etc.
  4. Configuration CRC (Cyclic Redundancy Checks) values are calculated from the specific configuration details of the database items. The Main server retrieves the configuration CRCs from the Standby server and compares them to the configuration CRCs on the Main server.
  5. Any configuration data on the Main server that has different CRCs to the configuration on the Standby server is transferred to the Standby server. This means that the configuration data is the same on both the Main server and Standby server.
  6. Non-configuration data such as point states, time stamps, quality values etc., for database items is transferred from the Main server to the Standby server.
  7. Alarm data and event data is transferred from the Main server to the Standby server.

NOTE: Steps 1-7 inclusive are referred to as the ‘initial’ synchronization. When steps 1-7 have taken place, clients can connect to the Standby server and the remaining steps 8-11 continue in the background.

  8. Alarm Redirection data is transferred from the Main server to the Standby server.
  9. The Main server queries the historic files on the Standby server (it uses file size and time stamps). On small to medium sized systems, this should take a matter of minutes. On systems with large amounts of historic data (the design limit is 6 billion records on 32 bit systems and 30 billion records on 64 bit systems), the historic data query could take many minutes or even hours.
  10. Any historic files on the Main server that have different file sizes and time stamps to the historic files on the Standby server are transferred to the Standby server. This will include files that have been modified for events logged since the last synchronization as well as any new historic files that have been created.
  11. The Main server queries the file sizes and modified time stamps of the Event Journal data files on the Standby server.
  12. Any event journal files on the Main server that do not match the event journal files on the Standby server are transferred to the Standby server. This will include files that have been modified for events logged since the last synchronization as well as any new files that have been created.
  13. The Main server transfers the historic files (generated reports) to the Standby server.

Each time a Main server connects to another server, the synchronization process has to take place. This means that the other server is regularly updated with the data on the Main server. The first time that this synchronization takes place is called a ‘first pass’. Following the completion of the ‘first pass’, the Main server and the other server will continue to synchronize on a regular basis. Each of these continuous synchronisations is called a ‘short pass’. A ‘short pass’ consists of the same steps as a ‘first pass’ but is completed more quickly as there is less data to be transferred and so the synchronization takes less time to complete.

During the ‘first pass’, steps 1-7 of the synchronization has to be completed before the Standby server can connect to the Main server. After step 7 has been completed, the Standby server can be used to access the database on the Main server. The remaining steps of the ‘first pass’ will continue to take place.

When the ‘first pass’ has completed, the Main server and the Standby server will continue to synchronize on a regular basis. The frequency of the continued synchronisations is set via the Update Rate setting on the Partners section of the Server Configuration Tool (see Define the Transfer Update Rate and Transfer Timeouts).

The ongoing synchronisations that take place after the ‘first pass’ are called ‘short passes’ (see ‘Short Pass’ Synchronization Process).

Further Information

‘First Pass’ Synchronization Process (Duty Mode Enabled)

‘Short Pass’ Synchronization Process

Enable or Disable Duty Mode.


Server Administration Guide - 'First Pass' Synchronization Process (Duty Mode Enabled) (System Architectures)

‘First Pass’ Synchronization Process (Duty Mode Enabled)

If Duty Mode is enabled on the servers, the complete synchronization process works slightly differently—there are additional steps to allow the comparison of data between the Standby and Main servers and the merging of data into the Main server.

As with the complete synchronization process when Duty Mode is disabled, the process takes place when:

  • A Main server establishes or re-establishes a connection with another server
  • ClearSCADA is started on a Standby server that is connected to a Main server that is already running.

If Duty Mode is enabled on the servers, the complete synchronization process consists of these steps (which are performed in order):

  1. The Main server transfers some of its Boolean (Enabled/Disabled) server configuration settings to the Standby server: Exclusive Control, Event Journal, Historic Data, Historic Validation, Historic Files, Alarms & Events, Quality Classification, Alarm Response, and Configuration Changes Auditing. Only the Enabled/Disabled settings are transferred, the other settings for each of the features need to be configured manually.
  2. The Main server transfers any metadata (custom fields) to the Standby server.
  3. The Main server transfers the database structure to the Standby server. The database structure is the hierarchy of groups, database items etc.
  4. Configuration CRC (Cyclic Redundancy Checks) values are calculated from the specific configuration details of the database items. The Main server retrieves the configuration CRCs from the Standby server and compares them to the configuration CRCs on the Main server.
  5. Any configuration data on the Main server that has different CRCs to the configuration on the Standby server is transferred to the Standby server. This means that the configuration data is the same on both the Main server and Standby server.
  6. The time stamps of the data on the Main server and Standby server are compared. The data for each database item is examined individually, and the data with the most recent time stamps is used; the data with older time stamps is disregarded.
  7. Non-configuration data such as point states, time stamps, quality values etc., for database items is transferred from the Main server to the Standby server.
  8. Alarm data and event data is transferred from the Main server to the Standby server.

NOTE: Steps 1-8 inclusive are referred to as the ‘initial’ synchronization. When steps 1-8 have taken place, clients can connect to the Standby server and the remaining steps 9-14 continue in the background.

  9. Alarm Redirection data is transferred from the Main server to the Standby server.
  10. The historic files on the Standby server are compared to the historic files on the Main server. If the Standby server has historic files that are different to those on the Main server, the files are retrieved from the Standby server and merged into the Main server’s data.
  11. The Main server queries the file sizes and modified times of the historic files on the Standby server.
  12. Any historic files on the Main server that are different to the historic files on the Standby server are transferred to the Standby server. This will include files that have been modified for events logged since the last synchronization as well as any new historic files that have been created.
  13. The Event Journal files on the Standby server are compared to the Event Journal files on the Main server. If the Standby server has Event Journal files that are different to those on the Main server, the files are retrieved from the Standby server and merged into the Main server’s data.
  14. The Main server queries the file sizes and modified time stamps of the Event Journal data files on the Standby server.
  15. Any event journal files on the Main server that do not match the event journal files on the Standby server are transferred to the Standby server. This will include files that have been modified for events logged since the last synchronization as well as any new files that have been created.
  16. The Main server transfers the historic files (generated reports) to the Standby server.

Each time a Main server connects to another server, the synchronization process has to take place. This means that the other server is regularly updated with the data on the Main server. The first time that this synchronization takes place is called a ‘first pass’. Following the completion of the ‘first pass’, the Main server and the other server will continue to synchronize on a regular basis. Each of these continuous synchronisations is called a ‘short pass’. A ‘short pass’ consists of the same steps as a ‘first pass’ but is completed more quickly as there is less data to be transferred and so the synchronization takes less time to complete.

During the ‘first pass’, steps 1-8 of the synchronization has to be completed before the Standby server can connect to the Main server (when Duty Mode is enabled). After step 8 has been completed, the Standby server can be used to access the database on the Main server. The remaining steps of the ‘first pass’ will continue to take place.

When the ‘first pass’ has completed, the Main server and the Standby server will continue to synchronize on a regular basis. The frequency of the continued synchronisations is set via the Update Rate setting on the Partners section of the Server Configuration Tool (see Define the Transfer Update Rate and Transfer Timeouts).

The ongoing synchronisations that take place after the ‘first pass’ are called ‘short passes’ (see ‘Short Pass’ Synchronization Process).

Further Information

‘First Pass’ Synchronization Process (Duty Mode Disabled)

‘Short Pass’ Synchronization Process

Enable or Disable Duty Mode.


Server Administration Guide - 'Short Pass' Synchronization Process (System Architectures)

‘ Short Pass’ Synchronization Process

When a Main server detects a new connection or re-establishes a connection with a server, it runs the ‘first pass’ synchronization process. During this process, the Main server updates the other server. Once the ‘first pass’ is complete, the Main server continues to update the Standby server on a regular basis. These regular updates are called ‘short passes’ as they usually take less time to complete than a ‘first pass’ (as the Main server only has to update the Standby server with new data, not all data).

‘Short passes’ take place continuously after a ‘first pass’. The frequency of the ‘short passes’ is defined by the Update Rate setting on the Server Configuration Tool (though it is possible for ‘short passes’ to be delayed, which we explain later in this section).

During a ‘short pass’:

  1. The Main server checks to see if its database structure has changed since the previous 'pass'. Any changes to the database structure are transferred to the Standby server. The database structure is the hierarchy of groups, items etc.
  2. The Main server checks to see if there have been any configuration changes since the previous 'pass'. Any configuration changes are transferred to the Standby server.
  3. The Main server checks to see if there have been any changes to the saved data or dynamic data since the previous 'pass'. Any saved data or dynamic data changes are transferred to the Standby server.
  4. The Main server checks to see if there have been any updates to the alarm or event data since the previous 'pass'. Any new alarm or event data is transferred to the Standby server.
  5. The Main server checks to see if any new historic records have been created on the Main server since the previous 'pass'. Any new historic records or modified historic records are transferred to the Standby server. Any historic record that is on the Main server but has not yet been transferred to the Standby server is regarded as ‘new’.
  6. If there are new historic records, at least 1 of them has to be transferred during a ‘short pass’ (the next ‘short pass’ cannot occur until at least 1 historic record has been transferred).
  7. The Main server checks to see if any new event records have been created on the Main server since the previous 'pass'. Any new event records are transferred to the Standby server.
  8. The Main server transfers the historic files (generated reports) to the Standby server.

If the Standby server is not fully synchronized with the Main server by the time the next ‘short pass’ is due, the current ‘short pass’ is ended and the next ‘short pass’ takes place. The only exception to this rule is if there are new historic records to be transferred, but no historic records were transferred during the ‘short pass’. In this situation, the next ‘short pass’ is delayed until at least 1 historic record has been transferred.

For example, let’s say that the Main server has new historic records that need to be transferred to the Standby server during a ‘short pass’. The Update Rate has been set to 2 seconds. The ‘short pass’ begins, but after 2 seconds, it has yet to transfer any historic records. The next ‘short pass’ is due to start, but as no new historic records have been transferred, it has to be delayed. A further second passes and 1 historic record is transferred. With 1 historic record transferred, the ‘short pass’ can end and the next ‘short pass’ can begin (1 second later than expected).

NOTE: The synchronization process is performed as quickly as possible via each re-established Main-Standby connection. If connections with more than one Standby server are re-established at the same time, the Main server will attempt to perform the synchronization process on both Standby servers as quickly as possible. The amount of time it takes to fully synchronize the Standby servers will vary according to the speed of the connection and the data on the Standby servers. For example, if Standby server A requires more data from the Main server than Standby server B, it will take a longer amount of time to fully synchronize Standby server A than Standby server B (as less data has to be transferred).

Further Information.

‘First Pass’ Synchronization Process (Duty Mode Disabled)

‘First Pass’ Synchronization Process (Duty Mode Enabled)

Enable or Disable Duty Mode.


Server Administration Guide - Main-Standby Changeovers (System Architectures)

Main-Standby Changeovers

In multi-server architectures, one or more Standby servers act as backup servers to the Main server. If the Main server goes offline, a Standby server switches from Standby to Main so that it can carry out the duties of the Main server. The switch from Standby to Main (or vise-versa) is called a changeover.

A changeover occurs due to:

  • Hardware failure—If there is a problem with the server hardware, the server acting as the Main server may go offline. The server will be unavailable for use as a Main server or Standby server until the faulty hardware is repaired or replaced.
  • Communications failure—If the Main server loses its connection with the Standby server, a Main-Main situations may occur. This is where both servers act as Main servers. In such situations, when the communication link is restored, the servers will arbitrate to determine which server is Main and which is Standby. Main-Main situations can cause problems, especially when PSTN outstations are being used, but these problems can usually be avoided by using IMCP Monitor points (see Define the ICMP Monitor Settings for a Server).
  • Software failure—Incorrect configuration could place an excessive demand on system resources and cause the Main server to go offline.
  • A manual changeover is performed (see Perform a Manual Changeover on a Multi-Server System). Manual changeovers are user controlled Main-Standby switches; a user stops or restarts the Main server to force the Standby server to switch to Main. This is an excellent way to check that the Main server and Standby server can switch correctly without having a significant impact on the system.

Typically, manual changeovers are performed on a regular basis at times when an unsuccessful changeover will have a minimal effect on the system.


Server Administration Guide - Perform a Manual Changeover on a Multi-Server System (System Architectures)

Perform a Manual Changeover on a Multi-Server System

On multi-server systems such as Hot-Standby Pair and Triple Standby, you will need to perform a manual changeover; a user initiated changeover that sets a Standby server to switch to Main. You will need to perform a manual changeover after configuring the servers so that the Main and Standby server(s) can switch to Main when needed. We also recommend that you perform manual changeovers on a regular basis at times when system activity is low (and so the changeover will not have a major effect on the running of the system).

On a Hot-Standby Pair system, a manual changeover will set the Standby server to Main.

On a Triple Standby system, a manual changeover will set one of the Standby servers to Main. For this reason, you will need to perform two manual changeovers when you are first testing that the servers in the architecture can switch to Main—one changeover for the connection between the Main and Standby 1 and one changeover for the connection between Standby 1 and Standby 2.

To perform a manual changeover:

  1. Access the server that is running as the Main server.
  2. Stop or restart the server that is running as the Main server (see Start and Stop the System Server).

If you are working on a Hot-Standby Pair system, stopping or restarting the Main server will cause the Standby server to switch to Main. When the server that began as the Main server restarts, the two servers will arbitrate to determine which server remains as Main and which is the Standby (see Define the Server’s Arbitration Priority).

If you are working on a Triple Standby system, stopping or restarting the Main server will cause the two Standby servers to arbitrate. One of the Standby servers will switch to Main while the other will remain as a Standby. The two servers will then work as a Hot-Standby Pair until the Main server is restored. If you are testing the server architecture for the first time, you should perform another manual changeover, only this time stop the server that is running as Main (i.e. the Standby server that switched to Main after the previous changeover). This second changeover will result in the remaining Standby server switching to Main.

  3. Re-start any servers that have been stopped. This will allow you to check that the servers in the architecture are running correctly, as Main or Standby.


Server Administration Guide - Main-Main and Main-Main-Main Situations (System Architectures)

Main-Main and Main-Main-Main Situations

Multi-server systems are designed to provide backup servers in the event of a hardware, software, or network failure. When the servers are online and can connect to each other, one server will act as the Main server and the other server(s) will act as the Standby server. However, if a hardware, software, or network fault occurs, the servers may not be able to communicate with each other and this can result in a Main-Main or a Main-Main-Main situation.

  • A Main-Main situation is when two servers in the same architecture run as Main servers at the same time.
  • A Main-Main-Main situation is when the three servers in a Triple Standby architecture run as Main servers at the same time.

During a Main-Main or Main-Main-Main situation, each server acts independently. When the connections between the servers are restored, the servers use ClearSCADA’s arbitration process to determine which server continues as Main and which server(s) switch to Standby.

The servers will use the following information (in order) to determine which server continues as Main (with the other server or servers switching to Standby):

  1. Arbitration Priority setting in the servers’ configuration.

The server with the highest Arbitration Priority setting continues as the Main server. Step 2 (below) is only considered if the highest Arbitration Priority setting is the same on more than one server. For example, if there are three servers and Server1 has an Arbitration Priority of 1, and Server2 and Server3 both have an Arbitration Priority of 2, Server1 switches to Standby and Step 2 is used as the next arbitration criteria between Server2 and Server3.

  2. Amount of time each server has been running as Main.

The server that has been running as Main for the longest amount of time continues as the Main server. If the servers have been running as Main for the same amount of time, Step 3 (below) is used as the next arbitration criteria.

  3. Amount of time each server has been running (as either/both Main or Standby).

The server that has been running the longest amount of time continues as the Main server. If the servers have been running for the same amount of time, Step 4 (below) is used as the next arbitration criteria.

  4. The ASCII value of the servers’ node names.

The server with the highest ASCII value for its name continues as the Main server.

NOTE: The arbitration process can be overruled by the Sentinel Panel on Hot-Standby Pair Sentinel Server architectures.

When the servers have arbitrated, the servers will attempt to synchronize. If the Duty Mode feature is disabled, the server that continues as Main will overwrite the data on the Standby server(s) so that each of the servers has the same data as the Main. If Duty Mode is enabled, the Standby server(s) will update the Main server before the Main server overwrites the Standby server(s). For more information, see Enable or Disable Duty Mode.

Users that perform configuration tasks on clients need to be aware of the implications of performing configuration tasks during a Main-Main or Main-Main-Main situation (we recommend that users only undertake configuration tasks during Main-Main and Main-Main-Main situations if Duty Mode is enabled).


Server Administration Guide - Test the Servers in a Multi-Server Architecture (System Architectures)

Test the Servers in a Multi-Server Architecture

When you have configured the servers in your architecture, you need to test that they are capable of meeting the demands of your system.

To monitor the server performance, you need to:

  1. Check that Standby Servers are Synchronized with the Main Server
  2. Check the Transfer Times.


Server Administration Guide - Check that Standby Servers are Synchronized with the Main Server (System Architectures)

Check that Standby Servers are Synchronized with the Main Server

If a changeover cannot be performed, you should check the synchronization status of the servers as a Standby server can only switch to Main if it is synchronized.

To check the synchronization status:

  1. Log on to the Main server.
  2. Display the Server Status Tool by right-clicking on the server icon and selecting the Status option.
  3. Display the Standby>Links status information.
  4. Examine the Sync entry for each of the Standby servers. If the servers have not synchronized successfully, the Sync status will be No. This means that the standby servers cannot be synchronized with the Main server and so cannot switch to Main if required.
  5. Examine the Errors entries for the Standby servers. As the synchronization process has failed, the Errors entries will provide information about the cause of the failure(s). Common causes of synchronization errors include:
  • Network failures—Use network monitoring tools such as ICMP Monitor points to check the status of the network between the Main and Standby servers.
  • Server failures—Investigate any problems relating to the server hardware and software.
  • Write failures (insufficient disk space on the Standby servers)—Free up some disk space on the Standby server or add extra disk space.

For more information on the status displays, see Links (Standby) in the ClearSCADA Guide to the Server Status Tool.


Server Administration Guide - Check the Transfer Times (System Architectures)

Check the Transfer Times

When you have checked that the Main and Standby servers are synchronized, you need to check the performance of the servers by examining the transfer times. For an efficient system, the servers have to be able to transfer the necessary amount of data quickly.

To check the transfer times:

  1. Log on to the Main server.
  2. Display the Server Status Tool by right-clicking on the server icon and selecting the Status option.
  3. Display the Standby>Counters status information. The status information consists of three lines of entries for each connection to a Standby server:
  • Line 1 (First)—Provides information about the first pass.
  • Line 2 (Total)—Provides total statistics for the data transfers.
  • Line 3 (Last)—Provides information about the latest pass.

You need to focus on Line 2, in particular, the Count and Time status values.

  4. For each connection, divide the Time status value by the Count status value. The result of this calculation is the average amount of time spent transferring data from the Main server to the Standby server.

If the average transfer time value is greater than or equal to the Update Interval for the Main server (defined in the Partners settings, see Define the Transfer Update Rate and Transfer Timeouts), then there is a problem with the amount of data being transferred. The cause of the problem is likely to be a slow network (low bandwidth) or an excessive amount of updates being reported.

  5. Examine the various count statuses for each server connection. The count statuses indicate the amount and type of data being sent to the Standby server(s). You should pay look closely at these statuses:
  • Data—The number of data changes that have been transferred from the Main to the Standby server.
  • Evt—The number of event records that have been transferred from the Main to the Standby server.
  • His Rec—The number of historic records that have been transferred from the Main to the Standby server.

If the Data and Evt counts appear to be high i.e. there appear to be more updates per transfer than you would expect, then there may be a configuration problem. Typically, this type of problem is experienced when values are being reported too frequently, for example, fluctuating point values are being reported because insufficient deadbands have been configured. To resolve this, you need to examine the Event Journal entries and use the event information to determine which database items are reporting new values too frequently (proceed to step 6).

If the His Rec count is higher than expected, there may be too many historic records being reported. You need to investigate this further by using the Historic Transfer status information (proceed to step 10).

If the Data, Evt and His Rec counts show values within the expected range for your system, it means that the link itself is incapable of transferring the data as efficiently as required. To improve the speed of data transfer, you will need to upgrade the connection. As you have identified the connection hardware as the cause of the problem, you do not need to continue with the remaining steps in this section.

  6. Log on to one of the Main server’s clients and access the Event List.
  7. Use the Event List to determine which database items are reporting their values too frequently.
  8. Access the Forms for the database items and use them to configure appropriate value limits and deadbands. For more information, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration and see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.
  9. Having made the configuration changes, log on to the Main server and check the Counters status information. If the database items have been configured with suitable limits, the Data and Evt statuses should indicate that a reduced amount of data is being transferred from Main to Standby.

If the Data, Evt and His Rec status values are as expected, the data transfer should be working to maximum efficiency. If the link is still slow, the link itself is the cause of the problem—you will need to upgrade the connection. As you have identified the connection hardware as the cause of the problem, you do not need to continue with the remaining steps in this section.

If the Data and Evt status values are as expected, but the His Rec status value is higher than expected, there is too much historic data being transferred. Proceed to step 10.

  10. On the Main server, access the Server Status Tool and examine the Historic Transfer status information. This information provides details about the historic data that is transferred from the Main server to the Standby server.
  11. Examine the Curr Data, Curr Upd, and Curr Del statuses.
  12. When new historic data is reported, it is placed in the queue to be transferred from the Main to the Standby server. The amount of data in the queue is shown in the Curr Data column. Similarly, the Curr Upd column shows the number of historic update records pending transfer, and the Curr Del column shows the number of pending historic deletions.

In normal circumstances, the three statuses will show an amount at the beginning of the historic cycle, and by the end of the historic cycle, the amount will have reduced. Over subsequent historic cycles, the status amounts should eventually reach 0.

If the status amounts increase over several historic cycles, it means that there is too much historic data waiting to be transferred—either there is an excessive amount of historic data being generated or the link is insufficient for the amount of data it needs to transfer. You can either reduce the amount of historic data being generated (by disabling the Historic feature on database items) or you can upgrade the link.


Server Administration Guide - Frequently Asked Questions - Server Architecture (System Architectures)

Frequently Asked Questions - Server Architecture

In this section, we answer some of the most frequent questions relating to configuring and monitoring servers, including:

  • What is a Good Setup for a System that has an Unreliable Network Connection?
  • When Should I Change the Transfer Timeouts?
  • How do I Monitor the Performance of the Servers?
  • How Can I Monitor Server Activity?
  • How Can I Monitor the Connection Status?
  • How Can I Improve Server Performance?
  • How Can I Detect that a Server has Failed?
  • Why Does the Standby Server have a Reduced Amount of Historic Data?
  • What Timeout Settings Do Servers Use to Determine Connection Failures?


Server Administration Guide - What is a Good Setup for a System that has an Unreliable Network Connection? (System Architectures)

What is a Good Setup for a System that has an Unreliable
Network Connection?

We recommend that you only use reliable connections between the Main and Standby servers. However, if this is not possible, you can use the Duty Mode feature (Duty Duty) to restrict the effect that intermittent connections can have on the system. This is dependent on the type of outstations and PLCs being used (they have to be able to connect to either of the servers independently).

For more information, see Enable or Disable Duty Mode.


Server Administration Guide - When Should I Change the Transfer Timeouts? (System Architectures)

When Should I Change the Transfer Timeouts?

On many systems, the default timeout settings are appropriate:

  • Update Rate: 5
  • Connect Timeout: 60
  • Request Timeout: 240

However, if you need to detect problems with the connection more quickly, you can reduce the timeout amounts. We do not recommend that you reduce the timeouts unless specifically advised to do so by a Schneider Electric engineer as if the timeouts are too short, the system may incorrectly regard a connection or server as having failed.

For more information, see Define the Transfer Update Rate and Transfer Timeouts.


Server Administration Guide - How do I Monitor the Performance of the Servers? (System Architectures)

How do I Monitor the Performance of the Servers?

To check the performance of the servers, you need to examine the server status information on the Server Status Display. You need to focus on the Standby>Links and Standby>Counters information.

For more details, see Test the Servers in a Multi-Server Architecture.


Server Administration Guide - How Can I Monitor Server Activity? (System Architectures)

How Can I Monitor Server Activity?

You can view the activity currently being undertaken by a server. To do this, you need to access the Server Status Display and navigate to the Links information.

For more information, refer to:

  • Server Links: see Links (Server) in the ClearSCADA Guide to the Server Status Tool.
  • Standby Links: see Links (Standby) in the ClearSCADA Guide to the Server Status Tool.


Server Administration Guide - How Can I Monitor the Connection Status? (System Architectures)

How Can I Monitor the Connection Status?

You can use the Server Status Display to determine whether the server on which you are working can connect to the other servers in the architecture. To view the status of the connections to the other servers, you need to examine the Polls status information (see Polls in the ClearSCADA Guide to the Server Status Tool).

You can also use ICMP Polls to monitor the connection between servers and to differentiate between server and network failures (see Define the ICMP Monitor Settings for a Server).


Server Administration Guide - How Can I Improve Server Performance? (System Architectures)

How Can I Improve Server Performance?

If your server performance appears to be inadequate for your requirements:

  1. Check that you are running the latest version of the software. Schneider Electric is committed to the ongoing development of our products and we continuously seek to improve server performance. The latest version of the software may significantly improve your system performance.

For the latest version of the software, please contact Schneider Electric.

  2. Test the Servers in a Multi-Server Architecture. You may discover that the Main server is transferring an excessive amount of data to the Standby servers. This can be solved by re-configuring the database so that less data is reported.

You may also discover that the network connection between the servers is inadequate for the amount of data transfer required.

  3. Upgrade your hardware. If the latest software versions and reducing the amount of data being transferred does not improve performance to the required level, you will need to upgrade your server hardware. You may also need to upgrade your network.


Server Administration Guide - How Can I Detect that a Server has Failed? (System Architectures)

How Can I Detect that a Server has Failed?

There are several displays that indicate server failure, including the:

  • Server Icon—The server icon changes color to magenta if there is an error or failure.
  • Event Journal—The Main server logs an event for the Standby servers when the Standby servers are connected, disconnected or synchronized.
  • Server Status Display—The Server Status Display provides information about the status of the servers (see Polls in the ClearSCADA Guide to the Server Status Tool).

You can also use the ICMP Polls feature (see Define the ICMP Monitor Settings for a Server).

However, to make users aware of server failures as soon as possible, we recommend that you map the server statuses to internal digital points. This means that if a server fails, an alarm is generated and added to the Alarm List and Alarm Banner (the alarm is associated with the point that contains the mapped data).

We recommend that you set up the following server failure detection configuration:

  1. Create an internal digital point.
  2. Create a Function Block Diagram as follows:

Where:

  • Server1SYNC is a new direct input variable that has the following configuration:
  • Name—Server1SYNC. This is just the name used to identify the tag in the program and can be any name you choose.
  • Tag Type—Read/Write (%M)
  • Tag—Browse to the following OPC tag for the standby server: Sync.
  • Type—STRING

NOTE: The Type has to match the type of value being read. In this case, the Type has to be STRING as the Sync status value is a string. You can view the type of the status values by displaying the OPC Bar, browsing to the required tag, right-clicking on it and selecting its Display Value option. This displays information about the tag, including its Data Type.

  • ‘YES’ is a constant
  • EQ is an Equality comparison function
  • INTERNALPOINTSERVER1STATUS is a new direct output variable that has the following configuration:
  • Name—INTERNALPOINTSERVER1STATUS. This is just the name used to identify the tag in the program and can be any name you choose.
  • Tag Type—Write Only (%Q)
  • Tag—Browse to the internal digital point you created earlier in this procedure and select it.
  • Type—BOOL (the output of an equality comparison function has to be Boolean)
  3. Save the Function Block Diagram. With the default settings in place, the program will run every second.
  4. Access the Form for the internal digital point you created earlier in this procedure.
  5. On the Digital Point tab, configure State 0 so that when the point enters State 0, an alarm is raised. State 0 corresponds to the Sync state of the standby server being false i.e. the Standby server is not synchronized and is unavailable, therefore there is no backup server (unless you are using a Triple Standby system, in which case, the other Standby server may still be available).
  6. Configure State 1 so that when the point enters State 1, an event is logged. State 1 corresponds to the Sync state of the Standby server being true i.e. the Standby server is synchronized and is available for use.
  7. Save the point.

If you are working on a Hot-Standby Pair system, you have completed the configuration and do not need to continue with the steps in this procedure. When the Standby server is not synchronized or is unavailable due to a hardware failure or network failure, the internal digital point will raise an alarm. The alarm will be displayed in the Alarm Banner and Alarm List. You can also configure a Mimic to display the alarm information if required.

If you are working on a Triple Standby system, proceed with step 8.

  8. Create two additional internal digital points. One of these points will represent the state of the second standby server and the other will represent the state of both standby servers, so name them accordingly.
  9. Edit the Function Block Diagram you created earlier in this procedure so that it contains the following:

Where:

  • Server2SYNC—Is a new direct input variable with the following settings:
  • Name—Server2SYNC. This is just the name used to identify the tag in the program and can be any name you choose.
  • Tag Type—Read/Write (%M)
  • Tag—Browse to the following OPC tag for the second standby server: Sync.
  • Type—STRING
  • ‘YES’ is a constant
  • EQ is an Equality comparison function
  • INTERNALPOINTSERVER2STATUS is a new direct output variable that has the following configuration:
  • Name—INTERNALPOINTSERVER2STATUS. This is just the name used to identify the tag in the program and can be any name you choose.
  • Tag Type—Write Only (%Q)
  • Tag—Browse to the internal digital point you created earlier in this procedure (the point that represents the status of the second Standby server) and select it.
  • Type—BOOL (the output of an equality comparison function is Boolean)
  • AND is a Bitwise/Boolean function that returns a True value only if both inputs are True. As the AND function’s inputs are the SYNC states of the two servers, it means that if both of the standby servers are not synchronized and are unavailable, the AND function will read two False values and so will write a False value to the INTERNALPOINTBOTHSTANDBYS output variable.
  • INTERNALPOINTBOTHSTANDBYS is a new direct output variable that has the following configuration:
  • Name—INTERNALPOINTBOTHSTANDBYS. This is just the name used to identify the tag in the program and can be any name you choose.
  • Tag Type—Write Only (%Q)
  • Tag—Browse to the internal digital point you created earlier in this procedure (the point that represents the status of both Standby servers) and select it.
  • Type—BOOL (the output of an equality comparison function is Boolean)
  10. Save the Function Block Diagram. The Function Block Diagram is now configured to write values to the internal digital points if the servers are not synchronized or are unavailable.
  11. Display the Form for the point that represents the server status of the second Standby server.
  12. On the Digital Point tab, configure State 0 so that when the point enters State 0, an alarm is raised. State 0 corresponds to the Sync state of the second standby server being false i.e. the Standby server is not synchronized and is unavailable, therefore there is no backup server.
  13. Configure State 1 so that when the point enters State 1, an event is logged. State 1 corresponds to the Sync state of the Standby server being true i.e. the Standby server is synchronized and is available for use.
  14. Save the point.
  15. Display the Form for the point that represents the server status of the both Standby servers.
  16. On the Digital Point tab, configure State 0 so that when the point enters State 0, an alarm is raised. State 0 corresponds to a False value (which is written to the point by the Function Block Diagram if both of the server’s are not synchronized or unavailable).
  17. Configure State 1 so that when the point enters State 1, an event is logged. State 1 corresponds to the to a True value (which is written to the point by the Function Block Diagram if both of the server’s are synchronized and available).
  18. Save the point.

The Function Block Diagram will execute every second. If a Standby server is unsynchronized or unavailable, an alarm (associated with one of the digital points) will be raised, alerting users to the situation. This alarm will be shown in the Alarm List and Alarm Banner and you can also configure Mimics to show the alarm information.

Further Information

Function Block Diagrams in the ClearSCADA Guide to Logic.

Designing a Mimic in the ClearSCADA Guide to Mimics.

Create and Configure a Point in the ClearSCADA Guide to Core Point Configuration.


Server Administration Guide - Why Does the Standby Server have a Reduced Amount of Historic Data? (System Architectures)

Why Does the Standby Server have a Reduced Amount of Historic Data?

On a multi-server system, it is possible for a Standby server to have less historic data than the Main server. This situation occurs when each of the following criteria are met at the same time:

  • The Archive After setting (Historic Data) is enabled in the Main server’s configuration settings
  • The Standby server has been offline for an amount of time that is greater than the Main server’s Archive After setting
  • The Main server is set to synchronize writeable historic data only (see Define the Server’s Historic Synchronization Settings).

If the above criteria are met, and the Standby server is restored, the Main server will only transfer the writeable historic data to the Standby server during synchronization. This means that the Standby server will contain less historic data than the Main server. To resolve this problem, temporarily configure both the Main server and Standby server to use the All Data option for historic synchronization (see Define the Server’s Historic Synchronization Settings), then restart the Standby server. On re-start, the servers will synchronize and the Main server will transfer the historic data over to the Standby server. When the synchronization is complete, both the Main and Standby servers will contain the same historic data. At this stage, you can reconfigure the Main and Standby servers so that they use the Writeable Data Only historic synchronization setting.


Server Administration Guide - What Timeout Settings Do Servers Use to Determine Connection Failures? (System Architectures)

What Timeout Settings Do Servers Use to Determine Connection Failures?

On a multi-server system, a server synchronization timeout occurs when a Standby server takes too long to process an update from the Main server.

When the Main server sends an update to a Standby server, the Main server expects the Standby server to process the update and send a response within a defined time period. This time period is the Request Timeout and it is defined in the Transfer section of the servers’ Partners settings (see Define the Transfer Update Rate and Transfer Timeouts).

If a Standby server does not respond to an update from the Main server within the Request Timeout period, the Main server regards the Standby server as offline. The Main server then halts the transfer.

Each Standby server also checks the state of the Main server. Every 10 seconds, the Standby server sends a poll request to the Main server. If the poll takes longer than a defined time period, the Standby server regards the Main as being offline, and will take appropriate ‘fall-over’ action (which may include the Standby server switching to become the new Main server in the architecture). The amount of time permitted to complete the poll (send the poll request and receive a valid response from the Main server) is defined in the Request Timeout field in the Monitor section of the servers’ Partners settings (see Define the Monitor Timeout Settings for a Server).

NOTE: The Heartbeat Timeout setting is used by ClearSCADA servers to close any open heartbeat poll links that are ‘idle’. For more information, see Define the Heartbeat Timeout for a Server.


Server Administration Guide - ClearSCADA on Citrix and Terminal Services

ClearSCADA on Citrix and Terminal Services

You can run ClearSCADA on remote desktop setups such as Citrix XenApp and Microsoft Terminal Services. These products allow Citrix and Terminal Services clients to provide the features of a ViewX client without having ViewX installed locally.

In the following sections, we provide an overview of the ClearSCADA-Citrix/Terminal Services concept and also offer an insight into the pros and cons of this type of architecture:

  • Understanding ClearSCADA on Citrix and Terminal Services
  • Considerations for Running ClearSCADA on Citrix and Terminal Services.

If you decide that this type of architecture is suited to your requirements, you will need to contact a specialist Citrix or Terminal Services agent for more information. The agent will:

  • Inform you about the number of servers and clients you will need for your system
  • Configure the connections between ClearSCADA and Citrix or Terminal Services.

There are no settings in ClearSCADA that need to be changed specifically for use with Citrix or Terminal Services. The only ClearSCADA specific requirement is that a ViewX or WebX client is installed/set up on the Citrix/Terminal Services server(s). These clients need to be connected to the ClearSCADA server in the same way as a ‘normal’ ViewX or WebX client. However, your agent will need to be aware of the Requirements for Citrix XenApp or Microsoft Terminal Services.


Server Administration Guide - Understanding ClearSCADA on Citrix and Terminal Services (ClearSCADA on Citrix and Terminal Services)

Understanding ClearSCADA on Citrix and Terminal Services

ClearSCADA supports the two leading remote desktop applications: CitriX XenApp 5 and Microsoft Terminal Services. With remote desktop technology, the client applications run on a server and are not installed locally on the clients. However, each remote desktop client can access and interact with the server’s applications. This means that, to the end user, it appears as if the server’s applications are installed on the clients.

To make this possible, mouse movements, selections and keyboard entries on a client PC are sent to the server. At the server, the user interaction is applied to the actual application, and then graphics are sent back to the clients so that the user interfaces are updated.

When ClearSCADA is used with remote desktop applications, ClearSCADA is installed on the Citrix or Terminal Services server. Each Citrix/Terminal Services client can then access ClearSCADA via ViewX or WebX on the Citrix/Terminal Services server. A separate instance of ViewX runs for each individual Citrix/Terminal Services client, so to the end user, it appears as if they are using a ViewX or WebX client.

NOTE: A ClearSCADA client configuration has to be configured for each Citrix/Terminal Services client that is to access ClearSCADA (see Citrix or Terminal Services Client - System Connections in the ClearSCADA Guide to Client Administration).

The main purpose of running ClearSCADA on a Citrix server or a Terminal Services server is to centralize the ViewX application on a single server and allow clients to access ViewX or WebX remotely. This reduces the overheads involved when upgrading and maintaining ViewX as the application is only installed on a single machine rather than multiple clients.

The following diagram shows a simple 1 Citrix/Terminal Services server setup:

This simple setup involves a ClearSCADA server which is connected to a Citrix/Terminal Services server that is running ViewX (or WebX). The ClearSCADA server communicates with ViewX/WebX on the Citrix/Terminal Services server in the same way as it would communicate with any ViewX/WebX client.

The Citrix/Terminal Services server runs a single ViewX or WebX application and is connected to the ClearSCADA server and one or more Citrix/Terminal Services clients. A separate ViewX session runs for each Citrix/Terminal Services client, which allows the client users to interact with ClearSCADA in the same way as if they were using a ViewX or WebX client.

For each ViewX session, the Citrix/Terminal Services server sends graphics to the clients (the graphics recreate the ViewX/WebX interface on the client PCs). This allows the client PCs to provide access to the ViewX and WebX interface. So the clients can be used in the same way as a ViewX or WebX client even though they don’t have ViewX or WebX installed locally.

Client user interactions, such as mouse clicks, selections and keyboard entries are reported to the Citrix/Terminal Services server. There, the user interactions are applied to the corresponding session of ViewX/WebX. The changes are then reported to the ClearSCADA server where they are used to update the ClearSCADA database and trigger actions on site etc.

Every time a client user logs on, a new session is created. The session associates an instance of ViewX or WebX with that particular user, so that the user experience is just like working on a normal ViewX or WebX client (even though the clients share a single ViewX or WebX application). To make this possible, each session requires a ClearSCADA license and a Citrix/Terminal Services license.

More complex architectures work in the same way, except that there may be multiple Citrix/Terminal Services servers (grouped into server ‘farms’). The key factors are that:

  • Data is only sent between the ClearSCADA server and one or more Citrix/Terminal Services servers that are running ViewX/WebX.
  • Graphics are sent from the Citrix/Terminal Services server to the Citrix/Terminal Services client(s).
  • User activity at the client (mouse clicks, keyboard entries etc.) are reported to the Citrix/Terminal Services server where they are applied to ViewX/WebX. The changes are then reported to the ClearSCADA server where the corresponding actions/database updates take place.
  • With Citrix servers that are in a ‘farm’, one of the servers has a data store that contains static configuration information that can be shared by the other servers. For example, information about printer settings can be stored on one server and accessed by other servers in the farm. This centralizes non-ClearSCADA data and reduces the time and cost of maintaining and upgrading applications, printers etc.

However, Terminal Services does not provide a central data store and so applications, printers etc., have to be installed and configured on each server in the server farm.


Server Administration Guide - Considerations for Running ClearSCADA on Citrix and Terminal Services (ClearSCADA on Citrix and Terminal Services)

Considerations for Running ClearSCADA on Citrix and Terminal Services

There are several advantages to running ViewX or WebX on a Citrix server or Terminal Services server:

  • Administration is centralized. Each Citrix or Terminal Services server has 1 installation of ViewX or WebX and this single application can then be accessed by each Citrix or Terminal Services client. So Citrix/Terminal Services clients can be used to access the ViewX or WebX interface without having ViewX or WebX installed locally - the clients use the ViewX or WebX that is running on the Citrix or Terminal Services server.
  • As ViewX/WebX is only installed on the server(s), any upgrades or maintenance to ViewX/WebX only have to be performed on the server(s). So maintenance of ViewX is easier and quicker, and may be more cost-effective.

However, while using ClearSCADA with Citrix or Terminal Services has several benefits, there is also a cost - higher bandwidth is required. This is because the Citrix or Terminal Services server(s) has to send graphics to each of its clients. High bandwidth is needed to allow quantities of graphics to be sent effectively.

So, if you are interested in running ClearSCADA on Citrix or Terminal Services servers, you need to consider:

  • The overhead of upgrading and maintaining ‘normal’ ViewX and WebX clients compared to the cost of upgrading and maintaining ViewX/WebX running on a single server
  • The cost and availability of high bandwidth connections between your Citrix or Terminal Services servers and their clients
  • How many Citrix or Terminal Services servers and clients your system will require
  • The cost of implementing and running Citrix or Terminal Services (initial set up, hardware, software, licenses, support etc.).

A Citrix/Terminal Services agent will be able to advise you on a suitable setup for your requirements and the associated costs.

Further Information

Requirements for Citrix XenApp or Microsoft Terminal Services.


Server Administration Guide - Requirements for Citrix XenApp or Microsoft Terminal Services (ClearSCADA on Citrix and Terminal Services)

Requirements for Citrix XenApp or Microsoft Terminal Services

To use ClearSCADA with Citrix XenApp or Microsoft Terminal Services effectively, you should check that the:

  • ClearSCADA server meets the recommended ClearSCADA server specifications (see System Server Requirements)
  • Citrix/Terminal Services server(s) meets the recommended specifications as defined by Citrix or Microsoft.
  • Citrix/Terminal Services server(s) also has sufficient memory to run the required number of ViewX or WebX sessions (in addition to the operating system, XenApp or Terminal Services, and any other applications).
  • Citrix/Terminal Services server(s) and clients have connections with sufficient bandwidth.

In the following sections, we provide information on the system specifications needed to run ClearSCADA on Citrix and Terminal Services:

  • Bandwidth for Citrix XenApp and Microsoft Terminal Services
  • Memory Requirements for Citrix XenApp and Microsoft Terminal Services.

For more details on the specifications for Citrix XenApp and Microsoft Terminal Services, please contact the agent or vendor.


Server Administration Guide - Bandwidth for Citrix XenApp and Microsoft Terminal Services (ClearSCADA on Citrix and Terminal Services)

Bandwidth for Citrix XenApp and Microsoft Terminal Services

For a ClearSCADA-Citrix/Terminal Services system to work efficiently, high speed connections are required between the Citrix/Terminal Services server(s) and the Citrix/Terminal Services clients. This is because each Citrix/Terminal Services server has to send graphics to its clients, and graphics are larger files and so take longer to transmit.

The amount of bandwidth required varies depending on whether you are using Citrix XenApp or Microsoft Terminal Services. Our recommendations are:

  • Citrix XenApp
  • Minimum bandwidth: 2 Mbps bandwidth, 50 ms latency
  • Recommended bandwidth: 100 Mbps bandwidth, 1 ms latency
  • Microsoft Terminal Services:
  • Minimum bandwidth: 10 Mbps bandwidth, 20 ms latency
  • Recommended bandwidth: 100 Mbps bandwidth, 1 ms latency.

Remember that the bandwidth recommendations stated above apply to the connections between either the:

  • Citrix server and the Citrix clients
  • Terminal Services server and the Terminal Services clients

They do not apply to the connection between the Citrix/Terminal Services server and the ClearSCADA server (as data is transferred via this connection, not graphics).

ATTENTION: If the bandwidth for the connection(s) is insufficient, the clients will be updated at inappropriately slow rates.


Server Administration Guide - Memory Requirements for Citrix XenApp and Microsoft Terminal Services (ClearSCADA on Citrix and Terminal Services)

Memory Requirements for Citrix XenApp and Microsoft Terminal Services

Each Citrix server or Terminal Services server requires an appropriate amount of memory and disk space to run:

  • The operating system
  • Citrix XenApp/Terminal Services
  • The required number of ViewX sessions
  • Any other applications.

Each ViewX session requires the same amount of RAM and hard disk space as a ViewX client:

  • 512 MB RAM
  • 10 MB Hard Disk Space.

For example, if you require 8 Citrix or Terminal Services clients, the Citrix/Terminal Services server needs:

  • Sufficient RAM and hard disk space to run the operating system, Citrix/Terminal Services, and any other programs

plus

  • 512 MB RAM and 10 MB hard disk space for each client. As there are 8 clients, this means 4096 MB (4GB) RAM and 80 MB hard disk space.

For information on the minimum specifications for Citrix XenApp, Microsoft Terminal Services, the server operating systems and any other applications, please refer to the manufacturer’s documentation.


Server Administration Guide - Set up a Port Server

Set up a Port Server

ClearSCADA includes an application called a 'port server' that can provide:

  • Remote access to serial ports—ClearSCADA (and other applications if required) can access the serial ports on a remote computer.
  • Modem sharing—Multiple PSTN channels can communicate via the same modem. This is especially useful when there are limited modem resources available.
  • Port sharing—Multiple direct channels can communicate using different protocols via the same serial port. The following protocols are supported:
  • Modbus RTU (including SCADAPack Modbus and SCADAPack RealFLO)
  • Modbus ASCII
  • DNP3
  • IEC 60870

To setup a port server:

  1. Determine which type of Port Server Setup provides the functionality you require.
  2. Install the Port Server Software.
  3. Configure a Static Serial Port if required (this is dependent on the type of port server setup).
  4. Restart the Port Server Service.
  5. Create the Channels in the Database.

For assistance with common issues relating to port server setup, please refer to one of the following sections:

  • Troubleshooting Dynamically Assigned Ports.
  • Troubleshooting Statically Assigned Ports.

To determine which one of these sections is applicable to your setup, you should first learn about the different port server setups (see Port Server Setup).


Server Administration Guide - Port Server Setup (Set up a Port Server)

Port Server Setup

There are several ways in which a port server can be setup:

  • Port Server on Remote Computer for Remote Access to Serial Ports.
  • Port Server for Modem Sharing.
  • Port Server for Port Sharing
  • Install the Port Server Software.

You should refer to the section that describes the setup you require.


Server Administration Guide - Port Server on Remote Computer for Remote Access to Serial Ports (Set up a Port Server)

Port Server on Remote Computer for Remote Access to Serial Ports

You can install the port server software on a remote computer to allow the ClearSCADA server(s) to access any devices that are connected to the remote computer's serial port(s). The remote computer can provide connections to multiple servers (and external applications) as well as the serial connection to outstations or other devices.

The remote computer has TCP/IP network connection to the ClearSCADA servers. It also has serial connections to the outstations that monitor and control plant.

The ClearSCADA servers can communicate with the outstations via the remote computer. The servers communicate with the remote computer via a TCP/IP connection. The remote computer then communicates with the outstations that are connected to the serial port.

Data received by the port server via the TCP/IP network is transmitted to the outstations via the assigned serial port. Similarly, data received via the assigned serial port is transmitted to the server via the TCP/IP network. Both statically assigned ports and dynamically assigned ports can provide remote access to serial ports.

One of the uses for remote access to serial ports is to provide each server in a multi-server system access to the same devices. This type of communications setup is required as a serial connection is point-point—it only allows for a single connection, whereas multiple connections are needed due to there being multiple ClearSCADA servers (and possibly other external applications).

Any serial port on the remote computer can be assigned when requested by
a ClearSCADA server (this is referred to as a dynamically assigned port) or can be assigned by the port server as soon as it starts (this is referred to as a statically assigned port). The type of port you need is dependent on your requirements:

  • If ClearSCADA is the only application that needs to access the remote computer's serial ports, then you should setup a dynamically assigned port.

To setup the port server to use a dynamically assigned port, you need to:

  1. Install the port server on the remote computer (see Install the Port Server Software).
  2. In ClearSCADA, configure the relevant channels (Direct or PSTN) and set their Connection Types to Remote Serial (see Create the Channels in the Database).
  • If other applications need to access a particular port, then you need to setup a statically assigned port as dynamically assigned ports are unique to ClearSCADA.

For each statically assigned port, the port server opens a user defined TCP/IP port to which any application (including ClearSCADA) can connect. Data sent and received is forwarded to and from the corresponding serial port.

Statically assigned ports are available to ClearSCADA and other external applications such as Telnet client. The port server software is installed on the remote computer, and when the remote computer is booted, the port server runs and it assigns the required ports. This allows a ClearSCADA server or external application to communicate with serial devices that are connected to the remote computer.

For a statically assigned port, you will need to:

  1. Install the port server on the remote computer (see Install the Port Server Software).
  2. Configure an entry in the remote computer's registry for each serial port (see Configure a Static Serial Port).

If ClearSCADA is using the port, proceed to step iii.

If ClearSCADA is not using the port, you have completed setting up the port.

  3. In ClearSCADA, configure the relevant channels (Direct or PSTN) and set their Connection Types to TCP/IP (see Create the Channels in the Database).


Server Administration Guide - Port Server for Modem Sharing (Set up a Port Server)

Port Server for Modem Sharing

You can install the port server software on a ClearSCADA server or remote PC (or use the in-built port server software on SCADAPack ES) to allow multiple PSTN channels to share a single modem. This is useful when there are limited modem resources available.

There are 2 possible topologies for modem sharing:

  • ClearSCADA server or SCADAPack ES using port server for modem sharing
  • Remote PC using port server

The port server setup for modem sharing works as follows:

  • The ClearSCADA server communicates with the Port Server software via a TCP/IP link. The TCP/IP link can be a connection to a remote PC that runs the Port Server software or can be a link within a ClearSCADA server or an SCADA Pack ES (the ClearSCADA server/SCADA Pack ES runs the Port Server software).
  • The Port Server software allows a modem that is connected to a serial port on the ClearSCADA server/SCADA Pack ES/remote PC to be shared by multiple PSTN channels.
  • The modem communicates with the outstations and other devices.

PSTN channels need to be configured for each connection to the modem (one channel for each connection that needs to share the modem). The PSTN channel configuration for the PSTN channels should be set to share the modem. There should only be one dial-in channel otherwise the channel will fail.

If a channel attempts to make a call while the modem is being used by another channel, the call attempt will fail and a 'blocked' error will be logged. However, the number of call attempts will not increment, and the call will be retried as many times as required until it succeeds, fails, or the requests timeout elapses. The requests timeout is defined on the Drivers section of the Server Configuration Tool (see Define the Driver Request Timeouts).

When the port is not being used, it uses the port settings/modem command of the dial-in channel (if any) to prepare itself for any incoming calls.

To set up the port server to provide modem sharing facilities:

  1. Install the port server on the ClearSCADA server or remote PC as required (see Install the Port Server Software). If you are using a SCADA Pack ES, you do not need to install the port server software (it is already provided in the SCADA Pack ES).
  2. In ClearSCADA, configure a PSTN channel for each driver that will share the modem. Configure the channels to have their:
  • Connection Type set to Remote Serial
  • Node Name set to:
  • localhost (when the port server is installed on the ClearSCADA server or a SCADA Pack ES)
  • The name/address of the remote PC (when the port server is installed on a remote PC).
  • Port set to the same port on each channel (this should be the port to which the modem is connected)
  • Shared setting enabled.

Each channel can, if necessary, have different port settings (Baud Rate, Data Bits etc.). The port server will change the port settings as required before each outgoing call. Similarly, the channels can also have different modem commands (the port server will change the modem command as required).

NOTE: To be able to support sharing, your modem needs to be able to connect with each of the outstations, PLCs, and other devices that are to use the modem. Some devices, particularly older outstations, require the modem to be set up in such a way that the modem is unable to be shared (as the modem’s configuration means it cannot connect to other devices).

For more information, see Create the Channels in the Database.

NOTE: If you require remote access to a SCADA Pack ES via a dial-up connection, the port server provides a RAS server. This is available on any port that uses modem sharing. If you are not using modem sharing, then you can also enable the RAS server on a static port by specifying a modem command in the port's settings (see Configure a Static Serial Port).


Server Administration Guide - Port Server for Port Sharing (Set up a Port Server)

Port Server for Port Sharing

You can install the port server software on a ClearSCADA server or remote PC (or use the in-built port server software on SCADA Pack ES) to allow a single port to be used for communications using multiple protocols. This is especially useful on a SCADA Pack ES as there are a limited number of ports available.

There are 2 possible topologies for port sharing:

  • ClearSCADA server or SCADA Pack ES using port server for port sharing
  • Remote PC using port server for port sharing

The port server setup for port sharing works as follows:

  • The drivers in the ClearSCADA server communicate with the Port Server software via a TCP/IP link. The TCP/IP link can be a connection to a remote PC that runs the Port Server software or can be a link within a ClearSCADA server or a SCADA Pack ES (the ClearSCADA server/SCADA Pack ES runs the Port Server software).
  • The Port Server software allows a serial port on the ClearSCADA server/SCADA Pack ES/remote PC to be used for communications with multiple protocols.
  • The communication device that is connected to the port (radio etc.) is used to send and receive data to and from the outstations and other devices.

The port used for communicating via many different protocols is set to dynamic mode. This allows different ClearSCADA drivers to communicate via a single serial port. For example, the DNP3 driver and SCADAPack Modbus drivers can both communicate via the same serial port even though they use different protocols.

When the port server receives data from an outstation or similar device via the serial port, it places the incoming data in a buffer. It then checks the incoming data for specific protocol signatures—when it recognizes the protocol, it sends the data to the relevant driver in the ClearSCADA server via a TCP/IP connection. Similarly, when the port server receives data from a driver in the ClearSCADA server, it places the data in a queue before sending the data to the relevant outstation. By default, there is a delay of 50ms between each message that is sent. This delay can be changed by altering the registry setting:

  1. Use Regedit to access:
HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\PortServer

  2. Change the InterMessageDelay.

To configure a port server for port sharing:

  1. Install the Port Server Software.
  2. In ClearSCADA, configure a direct channel of the relevant type for each protocol that is to be used by the serial port. Configure the direct channels are so that their:
  • Connection Type is set to Remote Serial
  • Node Name is set to:
  • localhost (when the port server is installed on the ClearSCADA server/a SCADA Pack ES)
  • The name/address of the remote PC (when the port server is installed on a remote PC).
  • Port is set to the same port on each channel (this has to be the port that is to be shared)
  • Shared setting is enabled.

You will need to configure one channel per protocol and should apply the same settings to each of the channels (Baud Rate, Data Bits etc.). The channels can be of any of the following protocols:

  • Modbus RTU (including SCADAPack Modbus and SCADAPack RealFLO)
  • Modbus ASCII
  • DNP3
  • IEC 60870.

For more information, see Create the Channels in the Database.


Server Administration Guide - Install the Port Server Software (Set up a Port Server)

Install the Port Server Software

You need to install the port server software so that it can provide remote access to serial ports or allow channels to share a modem or port. Depending on your system requirements (see Port Server Setup), you will need to install the port server on a ClearSCADA server or on a remote computer (the port server software is already installed on SCADA Pack ES).

NOTE: For this section, we assume that the servers are already configured and have connections to clients and the remote computer (if required). If you have not yet configured your servers and connections, see System Architectures.

To install the Port Server software:

  1. Begin the installation process for a Server or a ViewX client and proceed through the steps until the ClearSCADA Setup Wizard displays the Custom Setup Type 'page'.
  2. Select the Port Server branch.
    A context sensitive menu is displayed.
  3. Select either the Will be installed on local hard drive option or Entire feature will be installed on local hard drive option.

NOTE: You can install the ViewX client software on the remote computer, but this is not a requirement.

  4. Select the Next button.
  5. Select the Install button.
    The selected software begins to install.
  6. Select the Finish button to close the ClearSCADA Setup Wizard.

If you have installed the port server and need to use dynamically assigned ports, proceed to Create the Channels in the Database. You will need to use dynamically assigned ports if you are going to use the port server to allow ClearSCADA to have exclusive access to a remote computer's serial ports. You will also need to use dynamically assigned ports when using the modem sharing and port sharing features.

If you have installed the port server and need to use a statically assigned port, proceed to Configure a Static Serial Port. You will need to use a statically assigned port if you are going to use the port server to allow ClearSCADA and other external applications to have access to a remote computer's serial ports.

NOTE: The port server can use a mixture of static and dynamic ports if required.


Server Administration Guide - Configure a Static Serial Port (Set up a Port Server)

Configure a Static Serial Port

For remote serial communications via statically assigned ports (see Port Server on Remote Computer for Remote Access to Serial Ports), you need to reserve a port for use rather than allow the ports to be used on demand. To do this, you need to edit the registry settings on the remote computer.

To configure a serial port:

  1. On the remote computer, run regedit. (For more information, refer to your Microsoft Windows documentation).
  2. Expand the HKEY_LOCAL_MACHINE key to reveal its contents.
  3. Expand the SOFTWARE key to reveal its contents.
  4. Expand the Schneider Electric key to reveal its contents.
  5. Expand the ClearSCADA key to reveal its contents.
  6. Expand the PortServer/Ports key to reveal its contents.
  7. Right-click in the right-hand pane that contains the contents of the Ports key.
    A context sensitive menu is displayed.
  8. Select the New option.
    A further menu is displayed.
  9. Select the String Value option.
    A new string value is added. It is selected automatically, ready for you to enter its name.
  10. Enter the TCP/IP port number that is to be used for the statically assigned port. We recommend that you use high numbers (over 10000) as these are less likely to already be in use by other applications.

If you specify a port that is already in use, the ClearSCADA server will not be able to assign to the required port (see Troubleshooting Statically Assigned Ports).

  11. Press the Enter key or select another part of the interface to confirm the name entry.
  12. Right-click on the string value (the number string).
    A context sensitive menu is displayed.
  13. Select the Modify option.
    The Edit String window is displayed.
  14. In the Value Data field, enter the settings for the serial port that is to be used. The settings that you enter need to match the settings of the equipment attached to the port (the required settings should be provided in the documentation supplied by the equipment manufacturer).

Enter the settings (in comma separated value format):

  • Port Name—The name of the serial port, for example, COM1.
  • Baud Rate—The speed of data transfer via the port, for example, 9600.
  • Number of Data Bits—The number of data bits used to transmit each byte of data. This is a number between 4 and 8 (inclusive), for example, 8.
  • Parity—The setting for the parity bit that can be used as a method of error checking. The parity can be:
  • N—For no parity
  • E—Even parity.
  • O—Odd parity.
  • M—Mark parity.
  • S—Space parity.
  • Number of Stop Bits—Defines the number of bits that are placed after each character in the transmitted data. This is either 1, 1.5, or 2.
  • Flow Control—Defines when and how data is transmitted. The flow control can be:
  • NONE—Flow control is not applied to the data.
  • XON XOFF—The operating system controls the flow of data by sending XON and XOFF signals to indicate whether the communications equipment can receive data.
  • HARDWARE—The communications equipment uses Request to Send (RTS) and Clear to Send (CTS) signals to control the flow of data (and the operating system should prevent data overruns).
  • TOGGLE—Microsoft Windows controls the flow of data by sending a Request to Send (RTS) signal to the receiver when the transmission buffer contains data.

NOTE: There is also an optional modem command suffix that can be used to activate modem sharing or RAS on a port. This modem command follows the Flow Control and is preceded by a semi-colon instead of a comma. For information on an appropriate modem command, please refer to the documentation supplied with your modem hardware.

Examples:

COM3,9600,7,E,2,NONE

The port name is COM3, the Baud Rate is 9600, the number of Data Bits is 7, the Parity is even, the number of Stop Bits is 2, and Flow Control is not applied.

COM4,115200,8,N,1,HARDWARE;AT&F0E0V1S0=1

The port name is COM4, the Baud Rate is 115200, the number of Data Bits is 8, the Parity is Null, the number of Stop Bits is 2, the Flow Control is HARDWARE, and the modem command is AT&F0E0V1S0=1. The values are separated by commas except the Flow Control and Modem command which are separated by a semi-colon.

  15. Select the OK button.
    The Edit String window is closed.
  16. Repeat steps 7-15 inclusive for each additional serial port.

When you have configured the port(s), you need to Restart the Port Server Service.


Server Administration Guide - Restart the Port Server Service (Set up a Port Server)

Restart the Port Server Service

When you have setup the port, you need to restart the port server service so that the changes can take effect.

To restart the port server service:

  1. Display the Microsoft Windows Services window (select Start, then Settings, then Control Panel, then Administrative Tools, then double-click on Services).
  2. Right-click on the Port Server service in the list to display a context sensitive menu.
  3. Select the Restart option to stop, then start the Port Server service. This will instigate the changes you have made.

When you have restarted the Port Server service, you need to Create the Channels in the Database.


Server Administration Guide - Create the Channels in the Database (Set up a Port Server)

Create the Channels in the Database

When you have installed the Port Server software and setup the static port(s) as required, you need to create channels in the database. The channels represent the connections between the ClearSCADA servers and the remote computer or modem (depending on your system setup).

You need to configure channels that are appropriate to the types of serial devices that are connected to the remote computer or communicate with ClearSCADA via a modem. For example, if you are using the port server to allow ClearSCADA to communicate with a SCADAPack Modbus device via a remote computer, you will need to configure SCADAPack Modbus PSTN or SCADAPack Modbus Direct channels.

In this section, we explain how to create and configure the channels that are required for your port server setup. For details on the channel settings that do not specifically relate to the port server setup, you should refer to the documentation for the relevant driver. For example, if you need information on the settings for a SCADAPack Modbus PSTN channel, you will need to refer to the ClearSCADA Guide to the SCADAPack Modbus Driver.

You need to create and configure Channels for Dynamically Assigned Ports if:

  • You are using the port server to provide ClearSCADA with exclusive access to a remote computer's serial ports.
  • You are using the port server to allow modem sharing.

You need to create and configure Channels for Statically Assigned Ports if:

  • You are using the port server to provide ClearSCADA and other external applications access to a remote computer's serial ports.


Server Administration Guide - Channels for Dynamically Assigned Ports (Set up a Port Server)

Channels for Dynamically Assigned Ports

To create a channel for a dynamically assigned port:

  1. In ClearSCADA, create a new channel of the relevant type and driver. For example, if a SCADAPack Modbus outstation has a direct connection to the remote computer's serial port, then you need to create a new SCADAPack Modbus Direct Channel; if a PSTN SCADAPack Modbus outstation is used then you need to create a SCADAPack Modbus PSTN Channel.
  2. Name the channel appropriately, and configure its settings as described in the documentation for the relevant driver. For example, if you are configuring a SCADAPack Modbus PSTN channel, configure its settings as described in the ClearSCADA Guide to the SCADAPack Modbus Driver.
  3. When configuring the channel, set the:
  • Connection Type to Remote Serial. This allows the port to be assigned dynamically.
  • Node Name to be the name of the computer on which you installed the port server software. This can be the name of the ClearSCADA server or the name of the remote computer, depending on the type of port server setup you are using.

If the port server is to be used for modem or port sharing, you should also:

  • Enable the Shared setting on every channel that will use the shared modem or port. To do this, select the Shared check box on the Connection tab of the Channel Form.

NOTE: We suggest that you configure your channels to have alarms and severities. This will allow ClearSCADA to raise an alarm if it detects a communications failure on a channel.

  4. Save the configuration.


Server Administration Guide - Channels for Statically Assigned Ports (Set up a Port Server)

Channels for Statically Assigned Ports

To create a channel for a statically assigned port:

  1. In ClearSCADA, create a new channel of the relevant type and driver. For example, if the remote computer connects to a SCADAPack Modbus outstation via PSTN, you need to create a SCADAPack Modbus PSTN Channel.
  2. Name the channel appropriately, and configure its settings as described in the documentation for the relevant driver. For example, if you are configuring a SCADA Pack Modbus PSTN channel, configure its settings as described in the ClearSCADA Guide to the SCADA Pack Modbus Driver.
  3. When configuring the channel, set the:
  • Connection Type to TCP/IP.
  • Host Address to the name or IP address of the remote computer.
  • Port number to match the TCP/IP port on the remote computer port to which the serial channel is connected. The Port number has to be the same as the port number that you defined when you configured the port (see Configure a Static Serial Port).
  4. Save the configuration.

For extra help with configuring port server connections, refer to:

  • Troubleshooting Dynamically Assigned Ports
  • Troubleshooting Statically Assigned Ports.


Server Administration Guide - Enable Logging for the Port Server (Set up a Port Server)

Enable Logging for the Port Server

ClearSCADA can create log files containing useful diagnostics for the port server.

For port server log files to be created, the port server needs to be configured to have logging enabled. To do this, you need to edit the registry settings.

To enable the port server logging:

  1. Select the Start button on the Windows taskbar, then select the Run option to display the Run window.
  2. Enter the following text in the Open field and select OK to run the registry editor:
Regedit

  3. Use the Registry Editor to locate the registry settings at:
HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\PortServer

  4. Right-click on the LogEnable setting to display a context sensitive menu.
  5. Select the Modify option.
    The Edit String window is displayed.
  6. Enter True, Yes, T, Y, or 1 to enable port server logging.
  7. Select the OK button to confirm the setting.
    Port server logging is now enabled.

The port server log files can now be used for diagnostic purposes (see Serial Connection Problems).

NOTE: You can also use a registry editor to make other changes to the port server log files (see Changing the Content of the Port Server Log Files).


Server Administration Guide - Troubleshooting Dynamically Assigned Ports (Set up a Port Server)

Troubleshooting Dynamically Assigned Ports

ClearSCADA can detect remote serial communications failures on dynamically assigned ports. Any such failures are shown in the Events List which you can access from a ViewX or WebX client.

You can also configure communications channels so that, in the event of a communications failure, ClearSCADA raises an alarm. You can then view and respond to the alarm via the Alarm Banner, Alarms List, relevant Queries Lists, and suitably configured Mimics. For further information, please refer to the documentation for the relevant driver, for example, for information on configuring a SCADA Pack Modbus channel, please refer to the ClearSCADA Guide to the SCADA Pack Modbus Driver.

Each alarm or event has a message that describes the cause of the failed communications. Common alarm/event messages for communication failures on dynamically assigned ports are:

  • Communications State - Failed: Invalid COM Port.
  • Communications State - Failed: COM Port Already Assigned.
  • Communications State - Failed: Assign to COM Port Failed.
  • Communications State - Failed: Invalid Host.
  • Communications State - Failed: Unable to Connect to TCP/IP Port.
  • Communications State - Failed: Assign to Remote COM Port Failed.


Server Administration Guide - Communications State - Failed: Invalid COM Port (Set up a Port Server)

Communications State - Failed: Invalid COM Port

ClearSCADA will detect a communications failure if a channel has an invalid serial port defined in its configuration. (A port that does not exist on the remote computer).

If a channel has an invalid serial port defined, we recommend that you:

  • Change the channel configuration so that it defines an available serial port. (For more information, refer to the driver specific documentation).


Server Administration Guide - Communications State - Failed: COM Port Already Assigned (Set up a Port Server)

Communications State - Failed: COM Port Already Assigned

ClearSCADA will detect a communications failure if a channel attempts to use a serial port that is already being used by another application or channel. In such circumstances, ClearSCADA will add a 'Failed: COM port already assigned' event to the Events List.

Common causes of 'Failed: COM port already assigned' statuses are:

  • A shared channel and a non-shared channel both being assigned to the same serial port
  • 2 or more dial-in channels being used when sharing a modem
  • The port settings for one or more channels being different when the port is a shared port. The port settings for each of the channels that share the port has to be identical.
  • There are multiple channels of the same protocol type set up to share the same serial port. There can only be 1 channel per protocol for a shared port.

We recommend that you either:

  • Change the channel configuration so that it defines a different serial port or uses a different protocol. (For more information, refer to the driver specific documentation).
  • Change the other application (on the remote computer) or other ClearSCADA channel so that it uses a different serial port.


Server Administration Guide - Communications State - Failed: Assign to COM Port Failed (Set up a Port Server)

Communications State - Failed: Assign to COM Port Failed

If the port server software is unable to assign to the serial port, even though the serial port is available, ClearSCADA will detect an error and generate a 'Communications State - Failed: Assign to COM Port Failed' event. These errors are often caused by the port sharing feature being enabled for protocols that do not support sharing.

We recommend that you:

  • Only enable sharing on those channels for which port sharing is supported and required. The following protocols support port sharing:
  • Modbus RTU (including SCADAPack Modbus and SCADAPack RealFLO)
  • Modbus ASCII
  • DNP3
  • IEC 60870.

You should disable port sharing on all other channels (see Port Server for Port Sharing).

For additional help with assign to COM port failures, please contact Schneider Electric.


Server Administration Guide - Communications State - Failed: Invalid Host (Set up a Port Server)

Communications State - Failed: Invalid Host

A channel can fail due to the server being unable to obtain the IP address of the remote computer.

We recommend that you:

  1. Check that the Node Name that is defined in the configuration of the remote serial channel matches the name of the remote computer.
  2. Check the network setup and equipment.
  3. Check the network connection by 'pinging' the remote computer from the main server. To do this, access the Microsoft Windows Command Prompt and enter:
Ping <name of remote computer>

Do not enter the angle brackets.

If the network connection is working correctly, the remote computer server will return data that you will see in the Command Prompt window. If there is no reply, there is a fault with your network.


Server Administration Guide - Communications State - Failed: Unable to Connect to TCP/IP Port (Set up a Port Server)

Communications State - Failed: Unable to Connect to TCP/IP Port

If the TCP/IP connection between the servers and the remote computer cannot be established, the corresponding channel will fail.

We recommend that you:

  1. Check that the Node Name that is defined in the configuration of the remote serial channel corresponds to the name or IP address of the remote computer.
  2. Check the network connection by 'pinging' the remote computer from the main server. To do this, access the Microsoft Windows Command Prompt and enter:
Ping <IP address or name of remote computer>

Do not enter the angle brackets.

If the network connection is working correctly, the remote computer server will return data that you will see in the Command Prompt window. There is not a fault with your network so proceed to step 3.

If there is no reply, there is a network fault.

  3. Use the Microsoft Windows Services window to check that the Port Server service is running on the remote computer.
  4. Check any firewalls in place on your network. The Port Server (TCP/IP port 20876) has to be available (not blocked).


Server Administration Guide - Communications State - Failed: Assign to Remote COM Port Failed (Set up a Port Server)

Communications State - Failed: Assign to Remote COM Port Failed

A channel can fail due to errors occurring on the connection between the driver and the port server when the port is being assigned.

We recommend that you:

  1. Check the network connection by 'pinging' the remote computer from the main server. To do this, access the Microsoft Windows Command Prompt and enter:
Ping <IP Address or name of remote computer>

Do not enter the angle brackets.

If the network connection is working correctly, the remote computer server will return data that you will see in the Command Prompt window. As this confirms that there is not a fault with your network we recommend that you contact Schneider Electric for assistance.

If there is no reply, there is a network fault.


Server Administration Guide - Troubleshooting Statically Assigned Ports (Set up a Port Server)

Troubleshooting Statically Assigned Ports

For statically assigned ports, ViewX and WebX clients can only display messages that relate to the TCP/IP network connection between the ClearSCADA servers and the remote computer. Any errors relating to TCP/IP connection failures will be displayed as event messages in the Events List and as alarms on alarm displays such as the Alarm Banner, Lists, and suitably configured Mimics.

If there are communication problems on a statically assigned port, you need to check for:

  • TCP/IP Connection Problems
  • Serial Connection Problems.


Server Administration Guide - TCP/IP Connection Problems (Set up a Port Server)

TCP/IP Connection Problems

Problems with the TCP/IP network connection between the ClearSCADA servers and the remote computer are displayed in the Events List and they are also displayed as alarms on the various alarm displays.

The possible messages for TCP/IP connection failures are:

  • Communications State - Failed: Invalid Host.
  • Communications State - Failed: Unable to Connect to TCP/IP Port.
  • Communications State - Failed: Assign to TCP/IP Port Failed.

If none of the above messages are displayed, the communication failure may be due to Serial Connection Problems.

Communications State - Failed: Invalid Host

A channel can fail due to the server being unable to obtain the IP address of the remote computer.

We recommend that you:

  1. Check that the Host Address that is defined in the configuration of the channel matches the name of the remote computer.
  2. Check the network connection by 'pinging' the remote computer from the main server. To do this, access the Microsoft Windows Command Prompt and enter:
Ping <name of remote computer>

Do not enter the angle brackets.

If the network connection is working correctly, the remote computer server will return data that you will see in the Command Prompt window. If there is no reply, there is a fault with your network.

Communications State - Failed: Unable to Connect to TCP/IP Port

If the TCP/IP connection between the servers and the remote computer cannot be established, the corresponding channel will fail.

We recommend that you:

  1. Check that the Host Address that is defined in the configuration of the remote serial channel corresponds to the name or IP address of the remote computer.
  2. Check that the Port that is defined in the channel configuration corresponds to the port number defined in the remote computer's registry.
  3. Check the network connection by 'pinging' the remote computer from the main server. To do this, access the Microsoft Windows Command Prompt and enter:
Ping <IP Address or name of remote computer>

Do not enter the angle brackets.

If the network connection is working correctly, the remote computer server will return data that you will see in the Command Prompt window. There is not a fault with your network so proceed to step 4.

If there is no reply, there is a network fault.

  4. Use the Microsoft Windows Services window to check that the Port Server service is running on the remote computer.
  5. Check any firewalls in place on your network. The TCP/IP port that you specified has tobe available (not blocked).

Communications State - Failed: Assign to TCP/IP Port Failed

A channel can fail due to errors occurring on the connections between the driver and the port server.

If there is a Communications State - Failed: Assign to TCP/IP Port Failed message, you should check the network connection by 'pinging' the remote computer from the main server. To do this, access the Microsoft Windows Command Prompt and enter:

Ping <IP Address or name of remote computer>

Do not enter the angle brackets.

If the network connection is working correctly, the remote computer server will return data that you will see in the Command Prompt window. This indicates that there is not a fault with your network, and in this situation you should contact Schneider Electric for assistance.

If there is no reply, there is a network fault.


Server Administration Guide - Serial Connection Problems (Set up a Port Server)

Serial Connection Problems

If the port server fails to assign to a static serial port, the port server will log an error in its log file. You can use the log file to determine the cause of any problems relating to the port server:

  1. Access the Port Server's Log File.
  2. Determine the Cause of the Failures.

If the assign continues to fail, contact Schneider Electric for assistance.

Access the Port Server's Log File

The log file contains diagnostic information about the serial communications.

To access the port server log file:

  1. Use Microsoft® Windows Explorer® to locate the log file. By default, it is in the 'Logs' sub-folder which is in the same folder as the installed port server software. The log file is named 'PortServer_001.log'. There may be additional log files if the log file becomes full.
  2. Use a text editor such as Notepad to open the log file.

The log file contains diagnostic information that you can use to analyze any errors that have occurred (see Determine the Cause of the Failures).

NOTE: You can alter the logging settings so that the log files contain other types of information if required (see Changing the Content of the Port Server Log Files).

Determine the Cause of the Failures

When you have displayed the port server's log file, you can use it to diagnose the cause of failures.

By default, the log file only records errors such as failures to assign to a serial port. Each error indicates:

  • The serial port to which the error relates to
  • The activity that the Port Server was undertaking when the error occurred
  • The reason for the failure. This is reported by the operating system.

Changing the Content of the Port Server Log Files

By default, the port server log files contain information about errors that relate to the port server. You can change the registry settings so that the log files record:

  • Application—General information about the port server including which port is used by the Telnet server and a record of when the port server is shutdown.
  • Errors—Errors that relate to the port server.
  • I/O—Information about the data transfer (input and output via the ports).
  • Serial Ports—Information about the ports (when they are assigning, being de-assigned etc.)
  • Clients—Information about the drivers that are using the ports.
  • Modems—Information relating to modem sharing.
  • Remote Access—Information about remote access services connections (RAS)
  • Protocol Sharing—Information about the any port sharing.

These options are stored as a bit mask in the registry. You can set the log files to record one or more of the above types of information.

To change the registry settings:

  1. Select the Start button on the Windows taskbar.
  2. Select the Run option to display the Run window.
  3. Enter:
Regedit
  4. Select the OK button to run the registry editor.
  5. Expand the keys to locate the PortServer key, then select it. The Port Server key is located at:
HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\PortServer
  6. Right-click on the LogLevel registry setting for the Port Server to display a context sensitive menu.
  7. Select the Modify option to display the Edit DWORD Value window.
  8. In the Value field, enter the number for the required type(s) of logging.
  • Bit 0 corresponds to Application. For Application logging, enter 1.
  • Bit 1 corresponds to Errors. For Errors logging, enter 2.
  • Bit 2 corresponds to I/O. For I/O logging, enter 4.
  • Bit 3 corresponds to Serial Ports. For Serial Ports logging, enter 8.
  • Bit 4 corresponds to Clients. For Clients logging, enter 16.
  • Bit 5 corresponds to Modems. For Modems logging, enter 32.
  • Bit 6 corresponds to Remote Access. For Remote Access logging, enter 64.
  • Bit 7 corresponds to Protocol Sharing. For Protocol Sharing, enter 128.

If you want a combination of logging information, enter the total for both numbers. For example, if you want Errors logging, I/O logging and Modems logging, enter 38 (Errors logging is 2, I/O logging is 4 and Modems logging is 32).

NOTE: We recommend that you enable Errors logging.

  9. Select the OK button.
  10. Re-start the port server service to instigate the changes (see Restart the Port Server Service).


Server Administration Guide - Server License Settings

Server License Settings

Each ClearSCADA system requires a server license that defines which drivers are available, the number of database points permitted, the number of client commendations permitted etc.

In the following sections, we explain how to associate a server with a license file and use the License Details window to view license information:

  • Displaying the License Details Window
  • Understanding the License Details Window
  • Associating a Server with a License File.

Depending on the configuration of your system, each ViewX client may also need a license. For more information, see Associate a ViewX Client - System Connection with a Client License.


Server Administration Guide - Displaying the License Details Window (Server License Settings)

Displaying the License Details Window

To display the License Details window:

  1. Right-click on the ClearSCADA Server icon in the Windows taskbar.
    A context sensitive menu is displayed.
  2. Select the License Details option.
    The License Details window is displayed.

Further Information

Understanding the License Details Window

Associating a Server with a License File.


Server Administration Guide - Understanding the License Details Window (Server License Settings)

Understanding the License Details Window

The License Details window provides information about your license settings and the drivers, database items, clients, etc. that are permitted on your system.

The License Details window displays the following information:

  • License—Indicates the location of the license file. By default this is C:\Program Files\Schneider Electric\ClearSCADA\ClearSCADA.lic which also applies if a dongle is being used. You can use the Browse button feature to specify a different location for the license file (see Associating a Server with a License File).
  • Validity—Indicates whether the license is recognized by the ClearSCADA software. If the license is recognized, the Valid field shows Yes; if ClearSCADA detects that the license file is invalid, the Valid field shows No.
  • Version—Indicates the version number of the license file. The version number is used to validate the license and relates to the license features. The license file that we provide you with has a version number that is compatible with your system.

The Version field is empty if a dongle is being used.

  • Machine ID—Displays the unique identifier of the server PC.
  • Dongle—Displays the status and identification number of the dongle (if a dongle is being used).
  • Source—Indicates whether your system uses a license file or a dongle license.
  • Expires—Indicates the date and time at which the license expires (becomes invalid).
  • Runtime—Displays the number of hours for which the system will continue to run in the event of the license expiring.
  • Support Version—Displays the number of the software version that the server is licensed to run.
  • Database Points—Indicates the number of database points that can be added to your system. The license specifies this limit.

Accumulators, variables, and parameters can be used without licenses, so you do not need to include them in the number of points for your points license. Other types of point, such as standard database points and internal database points do need to be licensed.

Points in Group Templates do not require licenses, as they are ‘configuration models’ and are not used to store data in the database. However, points in Group Instances do require licenses.

  • ViewX Clients—Displays the number of ViewX clients that can be connected to the server. The license specifies this limit.
  • OPC Clients—Indicates the number of OPC clients that can be connected to the server. An OPC client license is needed for each connection between the ClearSCADA database and an OPC or OPCHDA interface. The license specifies this limit.
  • Data Access Clients—Shows the number of data access clients that can be connected to the server. A data access client license is needed for each connection between the ClearSCADA database and an ODBC or automation interface. The license specifies this limit.
  • Web Connections—Indicates the number of WebX clients that can be connected to the server. A web connection license is needed for each connection between the ClearSCADA database and a http:// interface. The license specifies this limit.
  • PLC Drivers—Shows the number of licensed drivers (protocols) available to the PLC driver (DriverPLC).
  • Drivers—Indicates the drivers for which the server is licensed to use on your system.
  • Features—Indicates whether the server is licensed to use Main Standby functionality (Main Standby is displayed if the server is licensed to use Main Standby; the field is empty if the server is not licensed to use Main Standby).

If your license file is in an appropriate location and you have finished viewing the License settings, you can continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn how to Start and Stop the System Server.


Server Administration Guide - Associating a Server with a License File (Server License Settings)

Associating a Server with a License File

You can use the License Details window to associate a server with a license file.

When you purchase a ClearSCADA system, Schneider Electric provide a license dongle or a license file. The server automatically detects dongle settings (when the dongle is plugged in to the relevant port on the server), but if you are using a license file, you will need to specify the location of the file. To do this, you can use the ClearSCADA Server Configuration Tool.

By default, the license file is located with the ClearSCADA installed files at:

C:\Program Files\Schneider Electric\ClearSCADA\ClearSCADA.lic.

If your license file is at a different location, you will need to associate it with the server by defining its location:

  1. Use Windows Explorer to place your license file in the required location.
  2. Display the License Details window (see Displaying the License Details Window).
  3. Use the Browse button feature in the License File section to select the new location of the license file.
  4. Select the OK button. The settings you defined are confirmed and the ClearSCADA Server Configuration Tool is closed.

The license settings that are defined for the license file or dongle are detected by the server automatically (as long as the server can locate the license file or detect the dongle in a parallel port or USB port).

When you have finished specifying the location of the license file, you can continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn how to Start and Stop the System Server.

NOTE: To allow a ViewX client to connect with the server, you may also need to Associate a ViewX Client - System Connection with a Client License.


Server Administration Guide - Start and Stop the System Server

Start and Stop the System Server

When you install ClearSCADA on a server, you need to setup the ClearSCADA server to run as a service so that you can start and stop the server when required. You may need to start, stop, and restart the ClearSCADA server when you make changes to certain parts of the server configuration.

This section explains how to:

  • Start the ClearSCADA Server.
  • Stop the ClearSCADA Server.
  • Re-Start the ClearSCADA Server.
  • Perform a Manual Changeover
  • Access the DBStartup Log File.


Server Administration Guide - Start the ClearSCADA Server (Start and Stop the System Server)

Start the ClearSCADA Server

When you install ClearSCADA on a server, 'you' need to setup the ClearSCADA server to run as a service. The ClearSCADA server will then run automatically whenever the server PC is turned on.

You may need to stop the ClearSCADA server and re-start it to allow certain features to be available.

To setup the ClearSCADA server to run as a service and start the ClearSCADA server:

  1. Select the Start menu, then the Programs option, then the Schneider Electric
    ClearSCADA     option, then the Service Manager option.
    The Service Manager window is displayed.
  2. Select the Start button on the Service Manager window. The ClearSCADA server will run (there may be a short delay—you can see the status of the server in the panel at the bottom of the Service Manager window).


Server Administration Guide - Stop the ClearSCADA Server (Start and Stop the System Server)

Stop the ClearSCADA Server

You may need to stop the ClearSCADA server when you alter certain server configuration settings or when making a backup of your database. You are usually prompted on screen whenever you need to stop the ClearSCADA server.

To stop the ClearSCADA server:

  1. Right-click on the ClearSCADA Server icon.
    A context sensitive menu is displayed.
  2. Select the Shutdown Server option.
    The ClearSCADA server shuts down.

Alternatively, you can:

  • Stop the ClearSCADA server via a WebX client by selecting the Diagnostics button, then selecting the Shutdown button.

Or:

  1. Access the Service Manager window by selecting the Start menu, then the Programs option, then the Schneider Electric ClearSCADA option, then the Service Manager option.
  2. Select the Stop button on the Service Manager window.

NOTE: If Group Instance propagation is in progress, the server will shut down after the pending transactions have been completed.


Server Administration Guide - Re-Start the ClearSCADA Server (Start and Stop the System Server)

Re-Start the ClearSCADA Server

Some server configuration alterations only come into effect if the ClearSCADA server is restarted.

To re-start the ClearSCADA server:

  1. Access the Service Manager window by selecting the Start menu, then the Programs option, then the Schneider Electric ClearSCADA option, then the Service Manager option.
  2. Select the Stop button on the Service Manager window.
  3. When the ClearSCADA server has stopped (indicated in the panel at the bottom of the Service Manager window), select the Start button on the Service Manager window.

Alternatively, you can:

  1. Access the Services applet (Control Panel>Administrative Tools>Services).
  2. Right-click the ClearSCADA Server service.
    A context sensitive menu is displayed.
  3. Select the Restart option.
    The ClearSCADA server shuts down and re-starts.

NOTE: If Group Instance propagation is in progress, the server will shut down after the pending transactions have been completed.


Server Administration Guide - Manual Changeover (Start and Stop the System Server)

Manual Changeover

The manual changeover feature is for use on systems that have Hot-Standby Pair or Triple-Standby server arrangements. It allows you to define which server is the Main server.

There are many possible reasons for needing to perform a manual changeover. Two common uses are:

  • Switching a Standby server to Main as the original Main server is to be shut down for maintenance.
  • Switching a Standby server to Main due to geographical factors. On a multi-server system, it is often easier to implement changes at the Main server. If the server at your current location is a Standby server, you can switch it to Main. This means you do not have to travel to the other server (which may be a considerable distance away).

There are two ways to perform a manual changeover:

  • Using the Change Main Server Action in ViewX (see Manual Changeover without Server Shutdown). This is the recommended way of performing a manual changeover as it can be completed successfully without shutting down any of the servers.
  • Shutting Down the Server that is Currently Main (see Manual Changeover with Server Shutdown). This forces a changeover as ClearSCADA performs an automatic changeover whenever ClearSCADA detects that the Main server has stopped (either intentionally or as a result of a failure).


Server Administration Guide - Manual Changeover without Server Shutdown (Start and Stop the System Server)

Manual Changeover without Server Shutdown

By using the Change Main Server action, you can perform a manual changeover without shutting down any of the servers in your server architecture. This is the recommended way of changing which server is Main as it means your system continues to run uninterrupted while the changeover takes place.

The Change Main Server action is available from any ViewX client that is connected to your system. So you can select it from a ViewX client that is connected to the server that is currently Main or from a ViewX client that is connected to a Standby server. However, you can only use the Change Main Server action if you log on via a User account that has the System Admin permission for the server.

To perform a manual changeover without shutting down any server in your system architecture:

  1. Log on to a ViewX client that is connected to your system (either the Main server or one of the Standby servers). You need to log on via a User account that has the System Admin permission.
  2. Either:
  1. Right-click on the system icon for the server that is currently Main.
    A context sensitive menu is displayed.
  2. Select the Change Main Server action.
    The Change Main Server dialog box is displayed. When you select the Change Main Server action from the Main server icon, the Change Main Server dialog box has a Server Name combo box.
  3. Use the Server Name combo box to choose which of the Standby servers should become the Main server when the changeover takes place.
  4. Select the OK button to confirm your selection.
    The changeover takes place and the server that was Main becomes a Standby and the selected Standby server becomes Main.

Or:

  1. Right-click on the system icon for the Standby server (or one of the Standby or Permanent Standby servers if there are multiple Standby/Permanent Standby servers).
    A context sensitive menu is displayed.
  2. Select the Change Main Server action.
    The Change Main Server dialog box is displayed. When you select the Change Main Server action from a Standby server icon, the Change Main Server dialog box has a Server Name text entry field.
  3. In the Server Name field, enter the name of the server that is to become the Main server when the changeover takes place.
  4. Select the OK button to confirm your selection.
    The changeover takes place and the server that was Main becomes a Standby and the selected Standby server becomes Main.

Further Information

Manual Changeover with Server Shutdown.


Server Administration Guide - Manual Changeover with Server Shutdown (Start and Stop the System Server)

Manual Changeover with Server Shutdown

If you need to perform a manual changeover, we recommend that you use the Change Main Server action (see Manual Changeover without Server Shutdown). This is because it allows the changeover to take place without requiring any of your servers to shutdown, and so your system can run continuously while the changeover takes place. It also allows you to choose which Standby server switches to become the Main server.

However, if you wish, you can perform a manual changeover that requires a server shutdown. Performing a changeover in this way will mean:

  • The running of your system is interrupted while the changeover takes place
  • ClearSCADA will arbitrate which Standby server is to become Main. You cannot choose which Standby server becomes Main.

To perform a manual changeover that requires a server shutdown, stop the ClearSCADA server on the Main server (see Stop the ClearSCADA Server). This causes a changeover to take place as ClearSCADA performs a changeover automatically whenever the Main server is stopped intentionally or stops because of a fault. As soon as the Main server stops, one of the Standby servers becomes the Main server (ClearSCADA arbitrates to determine which of the other servers becomes Main).

To restart the ClearSCADA server, see Re-Start the ClearSCADA Server.

NOTE: If the server is not starting as expected, you should display the information in the DBStartup log file and contact Schneider Electric (see Access the DBStartup Log File). We will use the information in the DBStartup log file to assess the situation and help you find a solution.


Server Administration Guide - Access the DBStartup Log File (Start and Stop the System Server)

Access the DBStartup Log File

If the startup process cannot complete successfully, you will need to access the DBStartup log file(s). The DBStartup log file(s) log each stage of the start up process and can be used by Schneider Electric to diagnose startup problems.

To access the DBStartup log file:

  1. Right-click on the server icon in the Windows taskbar.
    A context sensitive menu is displayed.
  2. Select the View_DBStartup_<Number>.log option to display the log file in a text editor program such as Notepad. The <Number> part of the option is the number for the log file. If there is too much data to fit into a single log file, ClearSCADA will create as many DBStartup log files as are needed. You may need to access several of these log files when reporting startup problems to Schneider Electric.

The log file contains information about each phase of the startup process with an indication as to whether each phase was successful or unsuccessful. If you experience startup problems, Schneider Electric will ask for specific information about the phases. The information you need to provide is included in the log file.

Many common startup problems relate to the database containing items for drivers that have not been installed, and the data.dat file being missing or in the incorrect location.

NOTE: If you experience difficulties with the shutdown process, you should report the problem to Schneider Electric. When diagnosing the problem, Schneider Electric will ask for the shutdown data in the log file—this information is located at the bottom of the main log file for your system (also accessed via the server icon in the Windows taskbar) and is not included in the DBStartup log file.


Server Administration Guide - Start and Stop a Driver

Start and Stop a Driver

You can use the ClearSCADA Server Status Tool to start and stop a driver. This may be necessary when:

  • Setting up driver logging—it may be necessary to stop and re-start the driver for the logging settings to take effect (see Driver Settings).
  • Upgrading or making alterations to a data source. Some drivers, such as the ODBC driver and the OPC driver, have a software connection to the data source, and this connection is locked once it is in place. It can be difficult to upgrade or make an alteration to a data source when a software connection is locked, and so you may need to stop a driver to release the software connection. When you have made the upgrade or alterations, you can re-start the driver which then re-establishes the software connection.

To start, stop, or re-start a driver:

  1. Run the ClearSCADA Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to Server Status).
  2. Log on if required, then expand the General branch, and select Modules.
  3. Right-click on the driver that you want to start, stop, or re-start to display a context sensitive menu.
  4. Select the relevant option:
  • Start—To start the driver. The driver will run and will re-establish its software connections.
  • Stop—To stop the driver. The driver will stop running and will release its software connections.
  • Re-start—To stop the driver, then start it again.
  • Autostart—The driver will start automatically as long as there are items for that driver in the database (the driver’s Object entry has to be above 0). When the driver starts automatically, it runs and re-establishes its software connections without any user interaction.

If the database does not contain any items for a driver that is set to autostart, the driver will be unable to start automatically (even if configured to do so). This is a precautionary measure so that unused drivers do not access your system resources.

When you are familiar with the start, stop, and re-start techniques, you can proceed to learn how to Alarm Limits.


Server Administration Guide - Alarm Action Calendar Settings

Alarm Action Calendar Settings

You can use the Alarm Action Calendar "branch" on the ClearSCADA Server Configuration Tool to define the default time settings for new alarm action calendars. These settings are useful when your system has calendars that use the same schedule times for the individual days of the week—by defining the default settings, you allow new calendars to already have the required settings in place when they are first created. This reduces the amount of configuration work required.

Before you define the default settings for alarm action calendars, you need to be familiar with the configuration of calendars and understand how they are used with the Alarm Redirection feature. If you are unfamiliar with these concepts, see Introduction to Alarm Redirection of the ClearSCADA Guide to Alarm Redirection.

To define the default Alarm Action Calendar settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch of the tree-structure.
  3. Select the Alarm Action Calendar branch to display the Alarm Action Calendar settings.

The Alarm Action Calendar settings work in a similar way to the Edit Day Schedule window that engineers use when configuring calendars. By right-clicking in the Times area, you can access a context sensitive menu that has an Add Time option for adding new custom time periods to the days in the list. When there are times in the Times section, the context sensitive menu will also have a Delete option for removing custom times, and a Modify option for editing the settings for the custom times.

  4. Use the Day combo box to choose the day of the week for which the selected times will apply.
  5. Right-click in the Times area and select the Add Time option to display the Add Time window.
  6. Use the Time spin box to define the start of a time period for which there is a specific alarm redirection (the alarm redirections are set on the Calendar Forms).
  7. Use the Redirection List combo box to choose the alarm redirection that will be used during the specified time period (the end of the time period is at 00:00 of the next day or the start of the next time period for the current day). The Redirection List options are:
  • Non-Working—Corresponds to the alarm redirection settings that are specified on the Non-Working Time Redirections tab of each Calendar's Form. Typically, these settings are used to define alarm redirections that are used when work stations are unmanned, for example, during times that are out of normal working hours.
  • Working 1 to Working 7—Correspond to the alarm redirection settings that are specified on the Working Redirections tabs (Working 1 - Working 7) of each Calendar's Form. Typically, these settings are used to define alarm redirections that are used during non-standard out of work hours.
  8. Select the OK button to confirm the time settings. The time is added to the Times section.
  9. Repeat this procedure for each required time.

If you need to alter the settings for a time, right-click on the time then select the Modify option from the context sensitive menu. Use the Modify Time window in the same way as you use the Add Time window—the only difference is that you are changing the settings of an existing time rather than creating a new time.

If you need to remove a time, right-click on the time then select the Delete option.

When you have finished defining the default Alarm Action Calendar settings, you can continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Alarm Limits.


Server Administration Guide - Alarm Limits

Alarm Limits

You can use the Alarm Limits section of the ClearSCADA Server Configuration Tool to enable the multiple alarms feature and the master station alarm limits feature. These features allow different alarm limits to be applied to the points in your database (although master station alarm limits only apply to analog points and are only used at the master station).

By using multiple sets of alarm limits, you can use different alarm limits in different circumstances. For example, a group of points can be switched from using a 'Summer' set of alarm limits to a 'Winter' set of alarm limits when the seasons change.

By using the master station alarm limits feature, you can apply extra alarm limits to analog points at the master station. This means that analog points can use up to 18 alarm limits instead of the 'standard' number of alarm limits (the 'standard' number varies according to the type of point and the driver to which it relates).

This section explains how to:

  • Set Up Multiple Alarm Limits
  • Setup Master Station Analog Point Alarm Limits.

There are also explanations of how engineers and operators can:

  • Switch Between Multiple Alarm Limits
  • Display Alarm Limit Information
  • Alarm Limits for Moved Points and Groups.

The Alarm Limits settings are optional settings. You should only alter the default settings if you specifically need to setup multiple alarm limits or master station alarm limits on your system.


Server Administration Guide - Set Up Multiple Alarm Limits (Alarm Limits)

Set Up Multiple Alarm Limits

Typically, each database point has a single set of alarm limits that define which point values or states correspond to alarm conditions. However, you can use the Alarm Limits section of the ClearSCADA Server Configuration Tool to setup two sets of alarm limits to points.

By using two sets of alarm limits, groups of points can be switched from using one set of limits to the other. For example, a group of points can be switched from using a 'Summer' set of alarm limits to a 'Winter' set of alarm limits when the seasons change.

NOTE: You can use the multiple alarm limits feature in conjunction with the master station alarm limits feature to allow the master station to use different sets of alarms (master station alarms or 'standard' alarms). For more information, see Setup Master Station Analog Point Alarm Limits

To enable the multiple alarm limits feature and define the descriptions and suffixes for the limits:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select the Alarm Limits branch to access the Alarm Limits settings.
  4. Select the Enabled check box in the Multiple Alarm Limits section.
    The Field Name Suffix and Description fields become available. There is a Field Name Suffix and a Description field for each set of alarm limits).
  5. For each set of alarm limits:
  1. Use the Field Name Suffix fields to define the names of the two database fields that will represent the two sets of alarm limits.

Ordinarily, each alarm limit has a single field in the database that describes the limit, for example, 'HighHighLimitStd'. When multiple alarm limits are enabled, each alarm limit field is replaced by 2 fields (one for each set of limits).

The names you enter in the Field Name Suffix fields replace the Std (standard) part of the alarm limit database fields. For example, if the 2 suffixes are Summer and Winter, then the field names for the High High limits are HighHighLimitSummer and HighHighLimitWinter.

  2. Enter a brief explanation for each set of alarm limits in the Description fields. The descriptions are used to indicate what each alarm limit means and are shown on displays such as the Point Form.

If you are unfamiliar with ClearSCADA server configuration and you want to make further changes, we recommend that you proceed to learn about the other Alarm settings:

  • Setup Master Station Analog Point Alarm Limits.
  • Switch Between Multiple Alarm Limits.
  • Display Alarm Limit Information.
  • Alarm Limits for Moved Points and Groups.


Server Administration Guide - Setup Master Station Analog Point Alarm Limits (Alarm Limits)

Setup Master Station Analog Point Alarm Limits

You can use the master station alarm limits feature to allow a second set of alarm limits to be applied to analog points. Master station alarm limits are only applied at the ClearSCADA server (the ‘master station’) and they allow up to 18 alarm limits to be defined for each analog point.

Normally, analog points use a ‘standard’ set of alarm limits which are defined in the point configuration. For example, a DNP3 SCADAPack analog input point has a 'standard' set of 8 alarm limits—4 High limits and 4 Low limits (it also has Overrange, Normal, and Underrange limits). The ‘standard’ alarm limits that are defined on the Analog Point Form can be downloaded to the relevant outstation (if supported). On the outstation, the alarm limits can be used for triggering dial-ins, logging events, or used in local outstation programs such as Ladder Logic. (this is dependent on the driver that is installed and the type of outstation being used).

By enabling the master station alarm limits feature, you can allow analog points to use a separate set of alarm limits (referred to as master station alarm limits). These additional alarm limits allow up to 18 alarm limit ranges to be defined for each analog point, irrespective of the type of outstation with which the point is associated. This can be useful if you need greater control over the alarms that are raised and displayed in ClearSCADA.

Master station alarm limits are only applied at the ClearSCADA server and are not downloaded to outstations. Each outstation that has analog points continues to use the ‘standard’ alarm limits to trigger dial-ins, Logic programs etc. However, when an outstation reports a value to ClearSCADA, the ClearSCADA server uses the master station alarm limits to determine whether to raise an alarm.

If the ClearSCADA server is using master station alarm limits and raises an alarm for a point, information about the alarm is displayed in the Alarm Banner, Alarms List and the Points List. The ‘master station’ alarm state for the point is stored in the historic database and is shown in place of the ‘standard’ alarm state.

You can use the Server Configuration Tool to enable or disable the master station alarm limits feature as required:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select the Alarm Limits branch to access the Alarm Limits settings
  4. Either:
  • Select the Enabled check box (in the Analog Point Alarm Limits section). This allows the master station alarm limit feature to be used with the analog points in your database.

Once enabled, an additional Master Station Alarm Limits tab becomes available on the Analog Point Forms. You can use the tab to define up to a total of 18 alarm limits that the server will use instead of the limits on the Analog Point tab. These additional limits are not downloaded to the outstation.

or:

  • Clear the Enabled check box (in the Analog Point Alarm Limits section). This disables the master station alarm limit feature—the 'standard' alarm limits will be used for the analog points in your database.

NOTE: If the multiple alarm limits feature is enabled as well as the master station limits feature, there are two set of master station alarm limits and two sets of 'standard' alarm limits. This means that the master station can be set to use one of two 'standard' sets of alarms or one of two sets of master station alarms (see Set Up Multiple Alarm Limits).

Further Information

Switch Between Multiple Alarm Limits.

Display Alarm Limit Information.

Alarm Limits for Moved Points and Groups.


Server Administration Guide - Switch Between Multiple Alarm Limits (Alarm Limits)

Switch Between Multiple Alarm Limits

When you have enabled the multiple alarm limits feature (see Set Up Multiple Alarm Limits), users can switch a Group between sets of alarm limits by using the Set Alarm Limits action.

The Set Alarm Limits action allows you to set some or all of the points in a Group to use a specific set of alarm limits, with a single instruction. To switch the alarm limits, you simply access the Set Alarm Limits option for a Group and then choose:

  • Which set of alarm limits will now be used (by using the Alarm Limits option)
  • Whether the alarm limits will be applied to all points in the Group (including those in sub-Groups within the Group).

If you select the Replace Limits on Descendants check box, the alarm limits will apply to all points in the Group and replace any previously selected limits.

If you clear the check box, the alarm limits are used by all points in the Group and sub-Groups that are set to ‘inherit from parent’. Points in sub-Groups that do not inherit from the parent Group continue to use any previously selected alarm limits.

This section explains how to switch the alarm limits of a Group, and also provides examples that describe how the multiple alarm limits feature works.

The multiple alarms examples include:

  • Example of Group and sub-Groups being Switched between sets of Alarm Limits.
  • Example of Parent Group and Selected Sub-Groups being Switched between Alarm Limits.

To switch the alarm limits of the points in a Group:

  1. Run ViewX and log-on.

NOTE: To switch alarm limits for a Group, you will need to log on via a user account that has the Tune Limits permission for the Group.

  2. Use the Database Bar to locate the Group for which you want to switch the alarm limits.
  3. Right-click on the Group.
    A context sensitive menu is displayed.
  4. Select the Set Alarm Limits option.
    The Set Alarm Limits window is displayed.
  5. Use the Alarm Limits combo box to either:
  • Select the set of alarm limits that the points in the Group will use.
  • Select the Inherit from Parent option. This resets the Group to use the same set of alarm limits as its parent Group (the parent Group is the Group or system that contains the Group you selected in step 3).
  6. Use the Replace Limits of Descendants check box to determine whether any sub-Groups that have previously been changed to a particular set of alarm limits are reset to use the alarm limits used by their parent Group.
  • Select the Replace Limits of Descendants check box to set all points in the Group and its sub-Groups to use the chosen Alarm Limits.
  • Clear the Replace Limits of Descendants check box to only apply the selected Alarm Limits to those points that are in sub-Groups that are set to Inherit from Parent.
  7. Select the OK button to apply the new alarm limits.

Depending on the type of outstations being used, engineers and operators may need to download configuration to each outstation that has points that have changed their alarm limits. To do this, the engineer or operator needs to use the Download Configuration action (see Downloading Configuration Changes in the ClearSCADA Guide to Core Configuration).

NOTE: When you switch the alarm limits for a Group, any 'tuned' limits for the individual points in the Group are lost.

Further Information

Example of Group and sub-Groups being Switched between sets of Alarm Limits.

Example of Parent Group and Selected Sub-Groups being Switched between Alarm Limits.

Example of Group and sub-Groups being Switched between sets of Alarm Limits

There are two sets of alarm limits—Summer limits and Winter limits. The Summer limits are used during the warmer months and the Winter limits are used during the colder months.

The System Group (root Group) has had its alarm limits set so that its points use the Summer limits.

As the seasons change, the various site Groups need to be switched so that they use the Winter alarm limits.

The Set Alarm Limits action is used on the System Group. When the Set Alarm Limits window is displayed, the user selects the Winter limits in the Alarm Limits combo box and selects the Replace Limits of Descendants check box.

This sets the all of the points in the System Group to use the Winter limits.

Example of Parent Group and Selected Sub-Groups being Switched between Alarm Limits

There are two sets of alarm limits—Normal Weather Conditions and Bad Weather Conditions. The Normal Weather Conditions limits are used whenever the weather conditions are fair. The Bad Weather Conditions limits are used whenever there are periods of bad weather—they allow different alarm limits to be set to reduce the number of alarms that are raised in severe conditions.

A Group has been configured to represent a geographical region. It contains three sub-Groups. The sub-Groups represent the sites in the region and include a headquarters Group, a Site 1 Group, and a Site 2 Group. Each sub-Group contains the points etc. that represent the plant at the site.

Although the sites that are represented by the sub-Groups are grouped in the same region, only the Headquarters site and Site 1 are located within a few miles of each other. Site 2 is located many miles away. This means that the weather conditions at the Headquarters and Site 1 are usually similar, but Site 2 can have completely different weather.

To reduce the amount of time and effort it takes to switch the alarm limits of the various site Groups, the Set Alarm Limits action is used to define the following settings:

  • Region—Normal Weather Conditions
  • Headquarters—Inherit from Parent
  • Site 1—Inherit from Parent
  • Site 2—Normal Weather Conditions

This means that the points in all of the sites use the Normal Weather Conditions limits.

The weather changes at the Headquarters and Site 1, and so the Headquarters and Site 1 Groups need to be switched to use the Bad Weather Conditions limits.

The Set Alarm Limits action is used on the Region Group. When the Set Alarm Limits window is displayed, the user defines these settings:

  • Alarm Limits—Bad Weather Conditions.
  • Replace Limits of Descendants—Disabled.

When the Bad Weather Conditions limits are applied, the points in the Headquarters Group and the Site 1 Group switch to use the Bad Weather Conditions limits—they inherit the limits that are used by the 'parent' Region Group.

The Site 2 Group continues to use the Normal Weather Conditions limits as it is not affected by the Region Group's settings. The Site 2 Group is set to use the Normal Weather Condition limits and does not inherit the limits of the 'parent' Group. Also, it is not forced to use the same alarm limits as the 'parent' Group as the Replace Limits of Descendants check box was cleared (disabled) when the 'parent' Group was set to use the Bad Weather Conditions limits.


Server Administration Guide - Display Alarm Limit Information (Alarm Limits)

Display Alarm Limit Information

You can use the Status displays (also referred to as View windows) for points and Groups to determine which alarm limits are currently being used.

For individual points, the Status display provides information about tuned limits, including the identity of the user that tuned the limits and the time at which they were tuned.

For Groups, the Status display indicates the name of the set of alarm limits that are currently in use. The named alarm limits are used by all points in the Group except those that are in sub-Groups that have been configured to use a specific set of limits.

To access the alarm limit information on a Status display:

  1. Run ViewX and log-on.
  2. Use the Database Bar or a suitably configured Mimic to locate the point or Group for which you want to access information.
  3. Right-click on the point or Group to display a context sensitive menu, then select the View Status option to view the Status display for the selected point or Group.

The Status Display shows information about the current status of the point. The information that is shown will vary according to the point's configuration, the features that are enabled on your system, and the drivers that are installed on your system.

For information about the alarm limits, you need to examine the entries for the following status properties (if available):

  • Alarm Limits
  • M/S Alarm Limits
  • State Alarm
  • Current M/S State

If you selected a point, and the point is using tuned limits, there is an Alarm Limits entry that provides information about who performed the tuning and when it took place. There is also an M/S Alarm Limits entry if the master station alarm limits feature is in use and the master station alarm limits have been tuned.

If the multiple alarm limits feature is enabled and you select a point that has not had its limits tuned, there is an Alarm Limits entry. The Alarm Limits entry shows the description of the alarm limits that are currently in effect.

If you selected a Group, and the multiple alarm limits feature is enabled, there is an Alarm Limits that shows the description of the alarm limits that are currently in effect.

If you selected an analog point that is set to use the master station alarm limits, the State Alarm entry shows the alarm state (Enabled Inactive, Acknowledged Cleared etc.) for the point. The master station has used the master station alarm limits to determine the alarm state for the analog point. There is also a Current M/S State that shows the alarm state description for the point (this corresponds to the descriptions for the master station alarm limits on the Point Form).

  4. Select the Close button to close the Status display.

Further Information

Alarm states: see Alarm Severity, Status, and Category in the ClearSCADA Guide to Alarms.

Alarm Limits for Moved Points and Groups.


Server Administration Guide - Alarm Limits for Moved Points and Groups (Alarm Limits)

Alarm Limits for Moved Points and Groups

When use the Database Bar to move an item to a new location, the alarm limit settings of the item can be affected.

The following sections describe how moving a point or Group can affect the alarm limit settings:

  • Alarm Limit Settings when a Point is Moved.
  • Alarm Limit Settings when a Group is Moved.


Server Administration Guide - Alarm Limit Settings when a Point is Moved (Alarm Limits)

Alarm Limit Settings when a Point is Moved

Alarm limit settings are not maintained when you move a point to a new location—the point will use the alarm limits of the destination Group by default. This applies even if the point's alarm limits have been tuned.

Example:

A Group named 'Central Site' contains a point named 'Heat Sensor AI'. The points in the 'Central Site' Group use 'Summer' alarm limits.

A Group named 'Northern Site' contains points that use 'Winter' alarm limits.

The 'Heat Sensor AI' point is moved from the 'Central Site' Group into the 'Northern Site' Group. The 'Heat Sensor AI' point will be set to use the 'Winter' alarm limits (depending on the model of outstation, this may not take effect until the outstation's configuration is downloaded).

Point in 'Central Site' Group uses 'Normal' alarm limits.
Point uses 'Bad Weather' alarm limits when it is moved into the 'Northern Site' Group.


Server Administration Guide - Alarm Limit Settings when a Group is Moved (Alarm Limits)

Alarm Limit Settings when a Group is Moved

If the items in a Group are set to use a specific set of alarm limits, then the items will continue using those limits if the Group is moved into another Group—the destination Group's alarm limit settings do not replace those of the moved Group.

If a sub-Group is inheriting its alarm limits from a parent Group, and it is moved to within another Group, the sub-Group will inherit the alarm limits of its new parent Group.

Example:

A Group named 'Central Site' contains points that use 'Normal Weather' alarm limits.

A Group named 'Northern Site' contains points that use 'Bad Weather' alarm limits.

The 'Central Site' Group is moved into the 'Northern Site' Group. The points in the 'Central Site' Group continue to use the 'Normal Weather' alarm limits as they are not affected by the alarm limit settings of the 'Northern Site' Group.

Points in the 'Central Site' Group continue to use the 'Normal Weather' alarm limits.
Points in the 'Northern Site' Group use the 'Bad Weather' alarm limits.


Server Administration Guide - Standard Point Descriptions

Standard Point Descriptions

You can use the Descriptions section of the ClearSCADA Server Configuration Tool to define standard descriptions for point units, states, and control actions. The descriptions are made available for selection when configuring a point (dependent on point type etc.) and are designed to help keep point descriptions consistent on your system.

This section explains how to:

  • Define Standard Descriptions for Measurement Units.
  • Define Descriptions for Numeric Point States.
  • Define Descriptions for Discrete Point States.
  • Remove a Standard Point Description.

The standard point description settings are optional settings. You should only alter the default settings if you specifically need to setup different descriptions for your point units, states, and control actions.


Server Administration Guide - Define Standard Descriptions for Measurement Units (Standard Point Descriptions)

Define Standard Descriptions for Measurement Units

You can use the Descriptions section of the ClearSCADA Server Configuration Tool to define the descriptions that are available during configuration. The descriptions are accessed via the Units combo box on those Forms that allow you to define a measurement unit.

Unit descriptions are defined on the Descriptions section
Units can be selected on Forms

To add a units description so that it can be selected on a Form:

  1. Display the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select the Descriptions branch.
    The Descriptions section is shown.
  4. Select the Add button in the Units section.
    A new description is added to the list of Units descriptions. It is selected automatically, ready for you to enter the description.
  5. Enter the description, for example, gallons.
  6. Press the Enter key to confirm the entry.

To check that the Units description has been configured, display the Form for an analog point, select the Analog Point tab, and select a Units combo box—the unit should be available.

Now you can define more descriptions or continue with the server configuration process:

  • If you want to define or remove more descriptions, repeat this procedure or see:
  • Define Descriptions for Numeric Point States.
  • Define Descriptions for Discrete Point States.
  • Define Descriptions for Control Actions.
  • Remove a Standard Point Description.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Extra Database Fields.


Server Administration Guide - Define Descriptions for Numeric Point States (Standard Point Descriptions)

Define Descriptions for Numeric Point States

You can use the Descriptions section of the ClearSCADA Server Configuration Tool to define the numeric point state descriptions that are available. The descriptions are accessed via the Description combo boxes for alarm limits on the Forms for several types of point.

Descriptions for numeric point states are available for selection in the alarm limit Description combo boxes on the Analog Point Form.

The descriptions define the options that are available from the Description combo boxes. The descriptions can be overridden with manual entries if required.

To add numerical point state descriptions:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select Descriptions.
    The Descriptions section is shown.
  4. Select the Add button in the Numerical Point States section.
    A new description is added to the list of Numerical Point States descriptions. It is selected automatically, ready for you to enter the description.
  5. Enter the required description, for example, Very High.
  6. Press the Enter key to confirm the entry.
    The custom description is now an option on the Description combo boxes for the analog point alarm limits.

To check that the Numerical point state description has been configured, display the Form for an analog point, select the Analog Point tab, and select a Description combo box—the custom description should be available.

You can define more descriptions or continue with the server configuration process:

  • If you want to define or remove more descriptions, repeat this procedure or see:
  • Define Standard Descriptions for Measurement Units.
  • Define Descriptions for Discrete Point States.
  • Define Descriptions for Control Actions.
  • Remove a Standard Point Description.


Server Administration Guide - Define Descriptions for Discrete Point States (Standard Point Descriptions)

Define Descriptions for Discrete Point States

You can use the Descriptions section of the ClearSCADA Server Configuration Tool to define the discrete point state descriptions. You can access the descriptions that you define via the Description combo boxes for states on Digital Point Forms.

NOTE: Discrete Point State descriptions are also available on Forms for specific types of point that have distinct, separate states.

Descriptions for discrete point states are available for selection in the state Description combo boxes on the Digital Point Forms (and selected other Forms).

The descriptions define the options that are available from the Description combo boxes for digital point states. The descriptions can be overridden with manual entries if required.

To add a discrete point state description:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select Descriptions.
    The Descriptions section is shown.
  4. Select the Add button in the Discrete Point States section.
    A new description is added to the list of Discrete Point States descriptions. It is selected automatically, ready for you to enter the description.
  5. Enter the description, for example, Maintenance.
  6. Press the Enter key to confirm the entry.
    The description is now an option in the Description combo boxes for digital point states.

To check that the Discrete State description has been configured, display the Form for a digital point, select the Digital Point tab, and select a Description combo box—the custom description should be available.

Now you can define more descriptions or continue with the server configuration process:

  • If you want to define or remove more descriptions, repeat this procedure or see:
  • Define Standard Descriptions for Measurement Units.
  • Define Descriptions for Numeric Point States.
  • Define Descriptions for Control Actions.
  • Remove a Standard Point Description.


Server Administration Guide - Define Descriptions for Control Actions (Standard Point Descriptions)

Define Descriptions for Control Actions

You can use the Descriptions section of the ClearSCADA Server Configuration Tool to define control descriptions. You can access the descriptions that you define via the Description combo boxes for control actions on Digital Point Forms and Pulse Action Forms.

The custom description that you define in the Control Actions section...
...is available for selection on the Digital Point Form (and on the Pulse Action Form).

The control action descriptions are configured to indicate the purpose of an action, for example, Raise Load.

To define a custom description for a control action:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select Descriptions.
    The Descriptions section is shown.
  4. Select the Add button in the Control Actions section.
    A new description is added to the list of Control Action descriptions. It is selected automatically, ready for you to enter the description.
  5. Enter the description, for example, Raise Load.
  6. Press the Enter key to confirm the entry.
    The description is now an option in the Description combo boxes for digital point controls.

To check that the Control Action description has been configured, display the Form for a digital point, select the Control tab, and select a Description combo box—the custom description should be available.

Now you can define more descriptions or continue with the server configuration process:

  • If you want to define or remove more descriptions, repeat this procedure or see:
  • Define Standard Descriptions for Measurement Units.
  • Define Descriptions for Numeric Point States.
  • Define Descriptions for Discrete Point States.
  • Remove a Standard Point Description.


Server Administration Guide - Remove a Standard Point Description (Standard Point Descriptions)

Remove a Standard Point Description

You can use the ClearSCADA Server Configuration Tool to delete any unwanted Units, Numeric Point States, Discrete Point States, or Control Actions descriptions. When you have deleted a description, it will not be shown in the relevant combo box, for example, if you delete a Units description, it will not be shown in Units combo boxes.

To remove a custom description:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select Descriptions.
    The Descriptions section is shown.
  4. Select the description that you want to remove.
  5. Select the Remove button for the section that contains the description you want to remove. For example, if you want to remove a Units description, select the Remove button that is below the Units section.
    The description is removed.

Now you can define more descriptions or continue with the server configuration process:

  • If you want to define more descriptions, see:
  • Define Standard Descriptions for Measurement Units.
  • Define Descriptions for Numeric Point States.
  • Define Descriptions for Discrete Point States.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Extra Database Fields.


Server Administration Guide - Extra Database Fields

Extra Database Fields

You can use ViewX to add extra fields (custom fields) to the database. The fields can be used to store links to other database items, lists of items (combo boxes), strings (data entry fields), Boolean configuration data (check boxes), or can be extra value fields.

The extra fields allow you to define additional configuration settings that are specific to your system. They also allow your system to store additional values that can be used by various applications.

This section describes the different Types of Extra Database Field and explains how to:

  • Display the Metadata Window
  • Create or Modify an Extra Field
  • Create or Modify an Extra Label
  • Remove an Extra Configuration Field or Extra Label.

We recommend that you familiarize yourself with the database structure before you attempt to add or remove database fields (see Welcome to the Guide to the Database in the ClearSCADA Guide to the Database).


Server Administration Guide - Types of Extra Database Field (Extra Database Fields)

Types of Extra Database Field

You can add 5 types of field:

  • Link Fields.
  • Drop Down List Fields can be added to any of the available tables.
  • Search Key Fields can be added to any of the available tables.
  • Check Box Fields can be added to any of the available tables.

The configuration fields are used to contain data that relates to the setup and functionality of an item, and the data fields are used to store values.

Extra fields, with the exception of extra point data fields, are shown as columns on Queries Lists and can be included in filters.


Server Administration Guide - Link Fields (Extra Database Fields)

Link Fields

You can add extra 'link' fields to the items in the database. Each link field has a browse button that you can use to associate an item with another item of a specific type, for example, an outstation.

A common use for link fields is to allow an internal point to be associated with an outstation. This allows other displays, such as Mimics and Lists, to show the different types of points that are associated with an outstation, not just the physical points (analogs, digitals etc.).


Server Administration Guide - Drop Down List Fields (Extra Database Fields)

Drop Down List Fields

You can add extra 'drop down list' fields to the items in the database. Drop down lists are also referred to as combo boxes. Each drop down list is a byte type field, and can have one of a configurable list of values. For example, you can add a drop down list field to categorize points according to the type of plant.

The extra list fields in the database are displayed as combo boxes on the Forms for the relevant items.

Combo Box is added to Point tab


Server Administration Guide - Search Key Fields (Extra Database Fields)

Search Key Fields

Search key fields are fields that contain a string of characters and/or numbers. You can add extra character search key fields to a database table. The database maintains an index for each field to allow for fast and efficient searching.

Example:

A Grid Reference search key field is added to each outstation in the database. The Grid Reference is used to define the geographical location of each site.

The outstations are configured and have the relevant map co-ordinates defined in their Grid Reference fields.

A user needs to display a list of the outstations that are used at a site with the Grid Reference TL65. On the Filter window for the Outstations List, the user defines the filter as:

The user selects the OK button and the Outstations List is displayed. It is filtered so that it only displays those outstations that have TL65 as their Grid Reference.


Server Administration Guide - Check Box Fields (Extra Database Fields)

Check Box Fields

You can add extra check box fields for items in the database. The extra fields appear as check boxes on the Forms of each appropriate item. Check box fields are standard fields with the type set to Boolean.

Example:

In this example, points are used as part of a fire control system and a site security system. To help users identify the system to which a point relates, extra check boxes are added to the Point Form, with each check box representing one of the two systems.

The extra check boxes are added to the CDBPoint table in the database. The check box fields are displayed as check boxes on the Forms and allow the points to be defined as relating to Fire Control or Site Security. The relevant check box is selected to indicate to which of the two systems the point relates.


Server Administration Guide - Data Fields (Extra Database Fields)

Data Fields

You can add extra data fields to each point in the database (except pulse points). The data fields can contain any information that you require and are added to the CDBPoint table (see Class Information in the ClearSCADA Guide to the Database). For example, you may need to store a Boolean value that indicates whether a point was modified successfully by an external program.

To add an extra point data field, you need to add a Standard type of extra field and then configure it to have Data as its Section setting. If you want it to be hidden from view, you will need to clear the Show on Form setting for the field. For more information, see Create or Modify an Extra Field.

Example:

An external application is used to export the values of a point to another system. The program needs to write a time value to the point so that it can determine the times at which previous exports have taken place. When the next export occurs, the data that was reported between the last export time and the current time will be exported.

The Extra Point Data Fields feature is used to create an ExportTime field. The program will write the time of the latest export to the ExportTime field.

NOTE: Point Data fields are not shown as columns on Queries Lists and cannot be included in filters.


Server Administration Guide - Display the Metadata Window (Extra Database Fields)

Display the Metadata Window

To create or modify an extra field or label, you need to use the Metadata window. When you access the Metadata window, you can view a list of the extra fields and labels that are currently in place on your system. You can add, edit, or remove the extra fields and labels as required.

To display the Metadata window:

  1. Run ViewX on a server and log on via a User account with the System Admin permission on the system (Root Group) and the Configure Database permission (enabled via the Form for the User account).
  2. In the Database Bar, right-click on the system icon to display a context-sensitive menu.
  3. Select the Edit Metadata option to display the branch to display the Metadata window.

The Metadata window contains two tabs: Fields and Labels. The Fields tab allows you to add, edit and remove extra configuration fields, whereas the Labels tab allows you to add, edit and remove text that appears on a Form (the text is referred to as a label).

Further Information

Create or Modify an Extra Field

Create or Modify an Extra Label

Remove an Extra Configuration Field or Extra Label.


Server Administration Guide - Create or Modify an Extra Field (Extra Database Fields)

Create or Modify an Extra Field

You can use ViewX on a server to create extra fields in the database. These fields are shown as combo boxes, data entry fields, or check boxes on Forms.

NOTE: If you want to add an extra point data field, see Data Fields.

In this section, we explain how to:

  • Add a New Extra Field
  • Modify an Existing Extra Field.


Server Administration Guide - Add a New Extra Field (Extra Database Fields)

Add a New Extra Field

You can use the Metadata window to create a new extra field. The field that you create can be configured so that it is available for users to use on Forms etc., or you may choose to create a field that is not visible to users but is used to store calculated values in the database.

To create a new extra field:

  1. Display the Metadata Window.
  2. With the Fields tab active, select the Add button to create a new field.
    The Add Field window is displayed, prompting you to select the type of field you want to add.

Choose from:

  • Standard—for extra Check Box Fields. You will also select this option if you want to add a standard point data field (see Data Fields)
  • Link—for extra Link Fields
  • Search Key—for extra Search Key Fields
  • List—for extra Drop Down List Fields.
  3. Select the OK button to confirm your choice.
    An Edit Field window is displayed.
  4. Use the Edit Field window to configure the settings for the field (the settings vary according to the type of field you are adding):
  • Define the Name of a Extra Field
  • Choose the Database Table for an Extra Field
  • Define the Position of an Extra Field
  • Define where an Extra Field is Shown on Queries Lists
  • Define the Number of Characters Permitted in an Extra Field
  • Define the Data Section for a Standard Custom Field
  • Define whether a Standard Custom Field is Shown on a Form
  • Define the Type of Value that is Stored in a Standard Custom Field
  • Define the Type of Item with which an Extra Link Field can be Associated
  • Add a Hyperlink to the Pick Action Menu of a Link Field’s Target Item
  • Define the Options for a List Field’s Drop-Down List
  • Define whether a Search Key Field can also be used as an OPC Tag
  • Set the Permission Required to Set the Value of an Extra Field
  • Define the Name of the View Status Information for an Extra Field.

When you have added the new field, it will appear in the list on the Metadata window.

Now that you have added a extra field, we recommend that you add an extra label so that the field has a descriptive label that indicates its purpose to other users (see Create or Modify an Extra Label). Obviously, you should only add a label if the field you have added is a visible field; adding a label for a hidden field will result in the label being visible on the Form but with no visible field next to it.


Server Administration Guide - Modify an Existing Extra Field (Extra Database Fields)

Modify an Existing Extra Field

You can alter the configuration of any extra field that has been added to the database. Making the alterations is a simple process and allows you to implement modifications as required.

  1. Display the Metadata Window.
  2. With the Fields tab active, select the extra field that you wish to modify (select the field from the list).
  3. With the field highlighted, select the Edit button to access the Edit Field window.
  4. Use the Edit Field window to configure the new settings for the field (the settings vary according to the type of field you are adding):
  • Define the Name of a Extra Field
  • Choose the Database Table for an Extra Field
  • Define the Position of an Extra Field
  • Define where an Extra Field is Shown on Queries Lists
  • Define the Number of Characters Permitted in an Extra Field
  • Define the Data Section for a Standard Custom Field
  • Define whether a Standard Custom Field is Shown on a Form
  • Define the Type of Value that is Stored in a Standard Custom Field
  • Define the Type of Item with which an Extra Link Field can be Associated
  • Add a Hyperlink to the Pick Action Menu of a Link Field’s Target Item
  • Define the Options for a List Field’s Drop-Down List
  • Define whether a Search Key Field can also be used as an OPC Tag
  • Set the Permission Required to Set the Value of an Extra Field
  • Define the Name of the View Status Information for an Extra Field.

When you have modified the field, you will be returned to the Metadata window. You may also wish to edit the label that accompanies the field (see Modify an Extra Label).

Define the Name of a Extra Field

You can define the name for the new field by using the Field Name setting on the Edit Field window (see Create or Modify an Extra Field). The name of the field is the name used to identify the field internally and is not shown on the Form. To add a text name for a field to a Form, you need to create a label for a new field (see Add an Extra Label).

To define the name of an extra field, you need to display the Edit Field window (see Add a New Extra Field or see Modify an Existing Extra Field).

When you have displayed the Edit Field window, you can define its name by using the Field Name setting:

  • Field Name—Enter the name of the database field. The field name has to be:
  • Different to the names of any fields already in the table that is to contain the database field
  • Different to the names of fields in any ‘parent’ tables of the table that is to contain the database field (as the table that contains the database field will inherit fields from the ‘parent’ table)
  • Different to the names of fields in any ‘child’ tables of the table that is to contain the database field (as a ‘child’ table will inherit fields from the table that contains the database field).

The field name can consist of up to 19 alpha-numeric characters for drop-down list fields and link fields or up to 23 characters for the other types of field. We recommend that you create a name that is indicitive of the field’s purpose. To help future upgrades run as smoothly as possible, we also recommend that you define names that are not common terms in the product, such as Tag.

When you have defined the Field Name, you can continue to define the other field settings as required.

Choose the Database Table for an Extra Field

Each custom field is added to a table in the database. The table to which you add an extra field affects where the custom field is shown. For example, if you add a field to the CDBPoint table, the custom field will be shown on Point Forms.

To define the database table for an extra field, you need to use the Edit Field window (see Add a New Extra Field or see Modify an Existing Extra Field).

When you have displayed the Edit Field window, you can define which database table will contain the field by using the Table setting:

  • Table—Use the Table combo box to choose the database table that will contain the custom field.

Choose from:

  • CAccumulatorBase—To add the field to the CAccumulatorBase table. The field will be shown on the first Reset tab of Accumulator Forms.
  • CAdvChannel—To add the field to the CAdvChannel table. The field will be shown on a new tab on the Channel Forms.
  • CAdvOutstation—To add the field to the CAdvOutstation table. The field will be shown on the Outstation tab on Outstation Forms.
  • CAdvSet—To add the field to the CAdvSet table. The field will be shown on a new Outstation Set tab on Outstation Set Forms.
  • CAlarmObject—To add the field to the CAlarmObject table. The field will be shown on the Alarms tab.
  • CCalendar—To add the field to the CCalendar table. The field will be shown on a new tab.
  • CCustomColour—To add the field to the CCustomColour table. The field will be shown on the Color tab of the Custom Color Form.
  • CDBAlarmAction—To add the field to the CDBAlarmAction table. The field will be shown on the Action tab of the Form for Alarm Redirection Action items.
  • CDBDevice—To add the field to the CDBDevice table. The field will be shown on a new tab on the Forms for devices (scanners, outstations, PLCs, etc.).
  • CDBMethodCall—To add the field to the CDBMethodCall table. The field will be shown on the Method Call tab on the Method Call Form.
  • CDBObject—To add the field to the CDBObject table. The field will be shown on the Identification tab.
  • CDBPoint—To add the field to the CDBPoint table. The field will be shown on the Point tab on Point Forms.
  • CDBPointSource—To add the field to the CDBPointSource table. The field will be shown on a new tab on Forms for scanners and simple point sources.
  • CDBSystemCmd—To add the field to the CDBSystemCmd table. The field will be shown on the System Command tab on the System Command Form.
  • CDBUser—To add the field to the CDBUser table. The field will be shown on the General tab on the User Form.
  • CDBUserBase—To add the field to the CDBUserBase table. The field will be shown on a new tab on the User Form.
  • CFileObject—To add the field to the CFileObject table. The field will be shown on a new tab on the Forms for Mimics, Trends and X-Y Plots.
  • CForecast—To add the field to the CForecast table. The field will be shown on the Forecast tab on Forecast Forms.
  • CGroup—To add the field to the CGroup table. The field will be shown on the Group tab on Forms for Groups, Group Instances, Group Templates and Operator Document Stores.
  • CHistoricCalc—To add the field to the CHistoricCalc table. The field will be shown on the Historic Calculation tab on the Historic Calculation Form.
  • CParam—To add the field to the CParam table. The field will be shown on the Parameter tab on the Forms for Parameter items.
  • CProfile—To add the field to the CProfile table. The field will be shown on the Profile tab on the Time Profile Form.
  • CResettingAccumulator—To add the field to the CResettingAccumulator table. The field will be shown on the second Reset tab on the Forms for accumulator items.
  • CSchedule—To add the field to the CSchedule table. The field will be shown on the Schedule tab on the Schedule Form.
  • CScriptLibrary—To add the field to the CScriptLibrary table. The field will be shown on a new tab on the Script Library Form.
  • CValueMap—To add the field to the CValueMap table. The field will be shown on the Value Map tab on the Forms for Value Map items.
  • CVariable—To add the field to the CVariable table. The field will be shown on the Variable tab on the Forms for Variable items.

When you have defined the Table, you can continue to define the other field settings as required.

Define the Position of an Extra Field

Each custom field has to be allocated a position on a tab for the relevant Forms. Each tab is divided into a grid of 20 columns and 100 rows (you cannot see the columns or rows). The columns are numbered 1-20 from left to right and the rows are numbered 1-100 from top to bottom. The position of an extra field is determined by its Column setting and a Row setting. The Column setting determines the horizontal position of the field and the Row setting determines the vertical position of the field.

Each field needs a unique position, and so when you are defining the position of a new field, you should first check to see which positions on the tab are available. Then, when you define the position of your new field, define a position that is not already in use by other fields. If you are going to add a label to accompany your new field, you should also check that there is enough room for your label—the label will be displayed in the column to the left of the defined location.

To define the position of an extra field, you need to use the Edit Field window (see Add a New Extra Field or see Modify an Existing Extra Field).

When you have displayed the Edit Field window, you can define the position of the field by using the Column and Row settings:

  • Column—Use the Column spin box to define the horizontal position of the custom field.
  • Row—Use the Row spin box to define the vertical position of the custom) field.

When you have defined the Column and Row, you can continue to define the other field settings as required.

Define where an Extra Field is Shown on Queries Lists

You can use the Edit Field window to define whether an extra field is included in Queries Lists, and if so, where its column is shown on the Lists. To do this, you need to display the Edit Field window (see Add a New Extra Field or see Modify an Existing Extra Field) and then use the List Priority setting:

  • List Priority—Use the List Priority combo box to define whether the extra field is shown on Queries Lists, and if so, where its column is shown:
  • Select None to stop the extra field from being shown on Queries Lists.
  • Select High to add the field to Queries Lists. It will be shown as a column toward the left-hand side of the List, after the default columns that have high priority (the priority levels of the default fields that are shown on Lists are internal—you cannot alter their settings).
  • Select Medium to add the field to Queries Lists. It will be shown as a column toward the middle of the List, to the right of the default columns and extra field columns that have high priority.
  • Select Low to add the field to Queries Lists. It will be shown as a column toward the right of the List, to the right of the default columns and extra field columns that have medium priority.

When you have defined the List Priority, you can continue to define the other field settings as required.

Define the Number of Characters Permitted in an Extra Field

If you are adding or modifying a Standard type of custom field or a Search Key type of custom field, you can use the Size setting to define the number of characters that are permitted for the field. With Search Key fields, the Size setting determines the number of characters that are included when data is returned via ODBC.

To define the number of characters permitted in an extra field, you need to use the Edit Field window (see Add a New Extra Field or see Modify an Existing Extra Field).

When you have displayed the Edit Field window, you can define the number of permitted characters by using the Size setting:

  • Size—Use the Size spin box to define the number of characters that are:
  • Permitted in the standard field

Or:

  • Can be returned for the search key field when the data is returned via ODBC. When ClearSCADA returns the search key field (in a Query etc.), it does not truncate any data that it cannot fit into the field. However, data that is returned via ODBC is truncated—the data that it cannot fit into the field is lost.

NOTE: The Size setting is only available for Standard and Search Key fields.

When you have defined the Size, you can continue to define the other field settings as required.

Define the Data Section for a Standard Custom Field

If you are adding or modifying a Standard type of custom field, you can use the Section setting to define the data section in which the field will be stored.

ATTENTION: Your choice of data section can affect system performance, so you need to choose an appropriate setting.

To define the data section for an extra field, you need to use the Edit Field window (see Add a New Extra Field or see Modify an Existing Extra Field).

When you have displayed the Edit Field window, you can define the data section by using the Section setting:

  • Section—Use the Section setting to choose the data section in which the field will be stored. There are three options:
  • Configuration—The field will be stored in the configuration file. If you are adding a field that users will use to configure an item via a Form, you should select the Configuration option (as configuration fields are stored in the configuration data file). Other types of field should not use the Configuration section as changes to fields in this section cause the configuration data to be transferred from the main and standby server. This can slow down the system unnecessarily.
  • Data—The field will be stored in the data file. If you are adding a field that will change frequently, such as a field that stores a calculated value, you should select the Data option.
  • Dynamic—The field is not stored on disk, but is transferred from the Main server to the Standby server(s). You should use the Dynamic option for fields that are used for calculations that are not stored.

Define whether a Standard Custom Field is Shown on a Form

For standard custom fields that have their Section setting defined as Configuration (see Define the Data Section for a Standard Custom Field), you can choose to hide the field from view. This is useful when the custom field you have added is for configuration that does not change as a result of user action, for example, a field that is written to by automation.

To define whether a standard custom field is shown on a Form, you need to use the Edit Field window (see Add a New Extra Field or see Modify an Existing Extra Field).

When you have displayed the Edit Field window, you can define the visibility of the custom field by using the Show on Form setting:

  • Show on Form—Select the check box to make the field visible to users or clear the check box to hide the field from view.

When you have defined the Show on Form setting, you can continue to define the other field settings as required.

Define the Type of Value that is Stored in a Standard Custom Field

When you add an extra field, you need to specify the type of value that can be stored in the field so that it is appropriate for your requirements. To do this, you need to use the Type setting on the Edit Field window.

To access the Edit Field window, see Add a New Extra Field. You can also use the Edit Field window to modify the type of an existing custom field (see Modify an Existing Extra Field).

When you have displayed the Edit Field window, use the Type setting to choose the data type for the field:

  • Type—Choose from:
  • Word—A 16 bit integer
  • Long—A 32 bit integer
  • Byte—An 8 bit integer
  • Float—A single precision floating value (real value)
  • Double—A double precision floating value (real value)
  • Reference—A database reference
  • String—An alphanumeric value of a defined length
  • Boolean—A True/False value
  • Variant—Any data type (used by VB programs)
  • Time—A time stamp value.

When you have defined the Type setting, you can continue to define the other field settings as required.

Define the Type of Item with which an Extra Link Field can be Associated

When you add an extra link field, you need to specify the Target Type. This setting defines the type of item that can be selected in the link field when it is on a Form. For example, if you set the Target Type to CSCADAPackMPoint, you will only be able to use the link field to associate an item with a SCADA Pack Modbus point.

To define the target type, you need to use the Target Type setting on the Edit Field window. To access the Edit Field window, see Add a New Extra Field. You can also use the Edit Field window to modify the Target Type of an existing custom field (see Modify an Existing Extra Field).

When you have displayed the Edit Field window, use the Target Type setting to choose the type of database item that can be selected via the link field:

  • Target Type—Use the Target Type combo box to select the type of item that the link field will allow you to associate with the item. The Target Type options correspond to different types of database item.

When you have defined the Target Type setting, you can continue to define the other field settings as required.

Add a Hyperlink to the Pick Action Menu of a Link Field’s Target Item

An extra link field allows one database item to be associated with another database item. For example, if you add a link field to a Point Form, the field can be used to associate the point with another point or another type of database item. The item that contains the link field on its Form is referred to as the source item and the item that is selected in the link field is referred to as the target item.

By using the Pick Menu Prompt setting, you can add an extra option to the pick action menu of the source item. So, if you added a link field to the Point Form, the pick action menu for points would contain an extra option. The option that you create with the Pick Menu prompt acts as a hyperlink to the target item’s default display.

To add or modify the extra pick action option for a link field, you need to use the Edit Field window. To access the Edit Field window, see Add a New Extra Field. You can also use the Edit Field window to modify the Target Type of an existing custom field (see Modify an Existing Extra Field).

When you have displayed the Edit Field window, use the Pick Menu Prompt setting to add the extra pick action menu option and define the text for the option:

  • Pick Menu Prompt—Use the Pick Menu Prompt field to define the text that is shown on the pick action menu for the link. You can enter any valid string. If you leave the Pick Menu Prompt field blank, there is no additional hyperlink option on the pick action menu for the source item.

The pick menu will be available for the item on the Database Bar, Lists, and Mimics (if configured to do so).

When you have defined the Pick Menu Prompt setting, you can continue to define the other field settings as required.

Define the Options for a List Field’s Drop-Down List

When you add an extra list field, you need to specify the options that will be available via the list field’s drop-down menu. To do this, you need to use the Categories settings on the Edit Field window.

NOTE: List fields are often referred to as combo boxes or drop-down lists.

To access the Edit Field window, see Add a New Extra Field. You can also use the Edit Field window to modify the Target Type of an existing custom field (see Modify an Existing Extra Field). When you have displayed the Edit Field window, use the Categories setting to define the list options.

You can choose to:

  • Add a new category:
  1. Select the Add button in the Categories section. This adds a new category to the list of categories. The categories are the options that will be available from the list field.
    The new category is selected automatically, ready for you to enter its description.
  2. Enter the description of the new category. Giving the category a suitable description will help other users determine its purpose.

The first category that you add has 1 for its value, the second category that you add has 2 for its value, the third has 3 for its value and so on. If you remove a category, it does not affect the values of the remaining categories—the next category that you add will use the value that was freed by the removed category. For example, if there are three categories and you delete the second category and then add another category, the new category will have a value of 2. Even though it is the fourth category to be added, it does not have a value of 4; instead it uses the vacant value of 2 (made vacant by your removal of the second category).

The value 0 is reserved for a 'none' option which is added to the list of options that you define automatically.

If you want to change the value for the category, you can edit it (see below).

  • Edit an existing category:

For each category, you can edit the name and/or value.

  • To edit the name, access the Edit Field window for the relevant list field and left-click on the Description for the category that you want to rename. You need to left-click on the category once and then wait a short time (around a second)—a text entry cursor will appear in the Description. Type in the new description as required, using delete or backspace to remove characters if needed. Press the Enter key or select another part of the interface to confirm your entry.
  • To edit the value, access the Edit window for the relevant list field and double-click on the category that you want to edit. This will display the Value window which shows the existing value (Old value) and has a field for the new value. Enter the value you require in the New field then select the OK button to confirm your entry.
  • Remove a category:
  • Select the category you want to delete, and then select the Remove button.

When you have defined the Categories settings, you can continue to define the other field settings as required.

Define whether a Search Key Field can also be used as an OPC Tag

When you have added a search key field, you can define whether the search key can also be used as an OPC tag. If you enable the tag feature, it means that a new tag will be created for the search key field. This tag can be used as a reference instead of Group names and will be available for any item that has a Form containing the search key field.

NOTE: The Tag feature is designed for use with systems that need to obtain data via OPC, where one database cannot use the <group>.<item property> reference format.

Example:

A search key field named SiteLocation is added to the CDBPoint table. This means that points will have a SiteLocation search key field added to their Forms. The SiteLocation search key field has its Tag check box selected (tag feature enabled), so a search key tag is created for the field. The search key tag is named SiteLocation (same name as search key field).

The system contains 200 points. Every one of these points has a SiteLocation field as the points are in the CDBPoint table. This means that the search key tag provides access to 200 entries for the SiteLocation field, with each individual entry sharing its name with the entry made in the SiteLocation field on the Point Forms.

A point named CurrentInput has ‘West 646’ as its SiteLocation entry. In the Database Bar, the CurrentInput point is located in a Group named ‘West Area’ which is within a parent Group named ‘Main Group’.

If the tag feature was disabled for the search key field, the only way to reference the CurrentInput point in an animation would be to use the complete database reference:

"Main Group.West Area.CurrentInput"

However, as the tag feature is enabled, the CurrentInput point can be referenced by its search key tag:

".West 646.CurrentState"

To enable or disable the tag feature, you need to use the Tag setting on the Edit Field window. For information on accessing the Edit Field window, see Add a New Extra Field. You can also use the Edit Field window to modify the Target Type of an existing custom field (see Modify an Existing Extra Field).

When you have displayed the Edit Field window, use the Tag setting to enable or disable the tag feature:

  • Tag—Use the Tag check box to define whether the search key can also be used as an OPC tag. Select the check box to enable the tag feature for the selected search key field; clear it to disable the tag feature for that field.
  • If you clear the check box, the search key cannot be used as an OPC tag. Item references use the group names and item names.
  • If you select the check box, the search key can be used as an OPC tag. It shares its name with the Field Name entry for the search key field.

When you have defined the Tag setting, you can continue to define the other field settings as required.

Set the Permission Required to Set the Value of an Extra Field

By using the Permission setting for an extra field, you can help to ensure that only those users with appropriate security permissions can access the field.

For each custom field, you can define the permission required to set the value of that field. For example, if you add a list field and define its Permission setting as Configure, only users that log on via a User account that has the Configure permission will be able to select the options for the list field. Those users that log on via accounts without the Configure permission will not have access to the field’s options.

The Permission setting is available on the Edit Field window. To access the Edit Field window, see Add a New Extra Field. You can also use the Edit Field window to modify the Target Type of an existing custom field (see Modify an Existing Extra Field).

When you have displayed the Edit Field window, use the Permission setting to define which security permission is required to use the custom field:

  • Permission—Choose the required permission from the list of security permissions. For more information about the individual permission settings, see Allocating Security Permissions in the ClearSCADA Guide to Security.

When you have defined the Permission setting, you can continue to define the other field settings as required.

Define the Name of the View Status Information for an Extra Field

Each custom field that you add has its value shown on the View window for the relevant items (the items related to the Table setting for the new field). The View window, also referred to as the Status Display or View dialog box, shows a snapshot of the status of an item which includes some of its values. Next to each entry on the View window is a name that describes the source of the entry.

By using the Edit Field window, you can define the name that is shown in the View window for a new custom field.

To access the Edit Field window, see Add a New Extra Field. You can also use the Edit Field window to modify the Target Type of an existing custom field (see Modify an Existing Extra Field).

When you have displayed the Edit Field window, use the View Info Dialog Title setting to define the View window name for the field’s value:

  • View Info Dialog Title—Enter the name for the field value. The name that you enter will be shown adjacent to the field’s value in the relevant Value windows. For example, if you enter SiteLocation as the View Info Dialog Title entry for an extra field that uses the CDBPoint table, the View window for points will contain an entry named SiteLocation. The value defined for the SiteLocation field of the selected point will be shown next to the SiteLocation entry on the View window.

When you have defined the View Info Dialog Title setting, you can continue to define the other field settings as required.

Further Information

Choose the Database Table for an Extra Field.


Server Administration Guide - Create or Modify an Extra Label (Extra Database Fields)

Create or Modify an Extra Label

You can use ViewX on a server to create extra labels in the database. These labels are shown as text on Forms and are often used to provide a descriptive title for extra fields.

In this section, we explain how to use the Metadata window to:

  • Add an Extra Label
  • Modify an Extra Label.


Server Administration Guide - Add an Extra Label (Extra Database Fields)

Add an Extra Label

The Metadata window allows you to add custom labels as well as custom fields. The term label is used to describe the text that is shown on Forms, typically next to a field. For example, if you have added an extra field that allows users to specify the location of a hardware device, you could also add an extra label called ‘Hardware Location’ to the Form.

Usually, custom labels are configured to be placed next to custom fields, but you can add custom labels to any part of a Form as required.

To add an extra label:

  1. Display the Metadata Window.
  2. Select the Labels tab.
  3. Select the Add button to create a new label.
    The Edit Label window is displayed.
  4. Use the Edit Label window to define the settings for the new custom label:
  • Label—Enter the text that will be shown in the label. The text that you define here is what will be shown on the relevant Forms.
  • Table—Choose the database table with which the label will be associated. The table you choose affects where the label is shown. For example, if you select the CDBPoint table, the custom label will be shown on Point Forms.

The tables that are available are exactly the same as the tables that are available when creating or modifying an extra field. For more information, see Choose the Database Table for an Extra Field.

  • Row and Column—Use to define where the label will be positioned on the relevant Forms.

Many custom labels are added to a tab on a Form (the type of Form is dependent on the selection you make in the Table field). To make the label visible, you should define its position (which is usually adjacent to a corresponding custom field).

The position of an extra label is defined by using the Row and Column settings. Each tab on a Form is divided into a grid of 20 columns and 100 rows (you cannot see the columns or rows). The columns are numbered 1-20 from left to right and the rows are numbered 1-100 from top to bottom. The Column setting determines the horizontal position of the label and the Row setting determines the vertical position of the label.

NOTE: When you define the position of a new label, you should check that the position is not already in use by another label or field. Each field and label requires a unique position.

  5. When you have defined the Column and Row, select the OK button to confirm your settings for the new label.
    The Edit Label window is closed and the label is added to the database and will be displayed in the defined location on the relevant Forms. However, if the defined location is already in use by an existing field or label, the label will not be visible as it will be obscured by the existing label or field. In this situation, you will need to edit the location of the custom label—see Modify an Extra Label.


Server Administration Guide - Modify an Extra Label (Extra Database Fields)

Modify an Extra Label

You can use the Edit Label window to amend the settings of any custom field that is already in place. You can change any of the label settings, including the text that is shown for the label and the position of the label on the relevant Forms.

To modify an extra label:

  1. Display the Metadata Window.
  2. Select the Labels tab.
  3. Select the label that you want to edit.
  4. With the label highlighted, select the Edit button.
    The Edit Label window is displayed.
  5. Use the Edit Label window to make the required changes to the label. The settings that you can change are identical to those settings that are available when you add an extra label. For more information, see Add an Extra Label.
  6. When you have made the required changes, select the OK button to confirm the changes.


Server Administration Guide - Remove an Extra Configuration Field or Extra Label (Extra Database Fields)

Remove an Extra Configuration Field or Extra Label

You can use the Metadata window to quickly remove those extra fields and labels that are no longer required:

  1. Display the Metadata Window.
  2. Select the Fields tab if you want to delete an extra field or select the Labels tab if you want to delete an extra label.
  3. Select the field or label that you want to remove.
  4. Select the Delete option.
    A prompt is displayed.
  5. Select Yes to confirm that you want to remove the extra field or label.
    The field is removed.


Server Administration Guide - Extra Table Queries

Extra Table Queries

You can use the Extra Table Queries feature to create custom pick actions that provide access to specific Queries Lists. The pick actions are added to the pick action menu for the relevant type of items and can be selected from the Database Bar, Mimics, Lists etc.

The Extra Table Queries feature is useful as it allows you to provide fast access to lists containing specific information.

Example:

In this simple example of how the Extra Table Queries feature can be used, a custom pick action is added to database points. When selected for a specific database point, the custom pick action instructs ClearSCADA to display a list of the points that are in the same Group as the selected database point.

The Display All Points in Group pick action is configured by defining the following Extra Table Queries settings:

  • Index—2. The index is a number that is associated with the Extra Table Query. Each query has its own index number that is used to identify the query.
  • Table—CDBPoint. This is the table that contains the database points configuration. The pick action for the Extra Table Query will be associated with the database items in the CDBPoint table (all database points).
  • Name—Display All Points in Group. This is the name of the pick action option that will provide access to the List that is defined by the Extra Table Query. The option is available for the items within the selected Table (all database points).
  • Title—$FullName$. This sets the title of the Extra Table Queries display to the Full Name value of the selected database point.
  • Query—The following query defines the data that is included in the Extra Table Query:
SELECT * FROM CDBPoint WHERE ParentGroupId=$ParentGroupId$

The Query sets the Query list to select the items in the CDBPoint table that have ParentGroupId values that match the ParentGroupId of the selected point. The items are then displayed on a List.

When the Display All Points in Group pick action is selected from a database point's pick action menu, a Queries list is displayed. The list shows those points that have ParentGroupId values that match the ParentGroupId value of the selected point (so the List displays the points that are in the same Group as the selected point).

In the following sections, we explain how to create, edit and remove an extra table query:

  • Create an Extra Table Query
  • Modify an Extra Table Query
  • Delete an Extra Table Query.

For a further example that illustrates how the extra table query feature can be used, please see A Custom Pick Action to Display a List of Out of Service Points in the ClearSCADA Guide to Lists.


Server Administration Guide - Create an Extra Table Query (Extra Table Queries)

Create an Extra Table Query

To create an extra table query:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool)
  2. Expand the Database Configuration branch.
  3. Select the Extra Table Query branch to display the Extra Table Query section.
  4. Right-click on the background of the Extra Table Query section to display a context sensitive menu.
  5. Select the Add Query option.
    A new Query is added to the list.
  6. Double-click on the query to display the Table Query window.
  7. Use the Table Query window to define the settings for the new Query:
  1. Use the Index spin-box to select the index number for the new query. The index is a number that is associated with the query.

When you create a new query, ClearSCADA allocates the next available index number automatically. Usually, the allocated number is suitable. However, you may need to define a specific number if you are creating queries on a system that is to be merged with another system—you will need to define an index number that is not in use on either system.

ATTENTION: If you change the Index number, the data that is associated with that Index number is lost.

  2. Use the Table combo box to select the table to which the query will be applied. For more information on the various tables, see Working with the Database Schema in the ClearSCADA Guide to the Database.
  3. In the Name field, enter the name of the pick action option. The name that you enter will be shown on the pick action menu for the items in the relevant table. For example, if you add a query to the CDBPoint table and define its name as Display Current Day, a Display Current Day option added to the pick action menus for database points.

The name that you define should be relevant to the query and should indicate what data is displayed when the option is selected.

  4. In the Title field, enter the title for the Query window. When the pick action is selected, the Query will be displayed in a new window—the title of the new window matches the entry you make in the Title field.
  5. In the Query field, enter the SQL query that provides the data for the list.
  6. Select the OK button to confirm the query settings and close the Table Query window.
  7. Repeat steps 4-7 inclusive for each query that you want to add.

When you close the ClearSCADA Server Configuration Tool, you will be prompted to restart the ClearSCADA server (see Re-Start the ClearSCADA Server). When the server is restarted, the new settings will take effect.

NOTE: You can use the $ trip character in the Title, and Query fields. The $ trip character instructs the system to insert the relevant value for the defined field. For example, if you set the Title to 'Hourly Value for $FullName$', and then displayed the query list for a point named 'Input 1', the Title of the Query window would be 'Hourly Value for Input 1'.


Server Administration Guide - Modify an Extra Table Query (Extra Table Queries)

Modify an Extra Table Query

To modify an extra table query:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool)
  2. Expand the Database Configuration branch.
  3. Select the Extra Table Query branch to display the Extra Table Query section.
  4. Right-click on the Extra Table Query that you want to edit.
  5. Select the Modify option.
    The Modify Query window is displayed.
  6. Use the Modify Query window to alter the configuration of the query. The Modify Query window has the same settings as the Add Query window (see Create an Extra Table Query).


Server Administration Guide - Delete an Extra Table Query (Extra Table Queries)

Delete an Extra Table Query

To remove an extra table query:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool)
  2. Expand the Database Configuration branch.
  3. Select the Extra Table Query branch to display the Extra Table Query section.
  4. Right-click on the Extra Table Query that you want to remove.
  5. Select the Delete option.


Server Administration Guide - Historic Configuration Settings

Historic Configuration Settings

You can use the ClearSCADA Server Configuration Tool to define various historic settings that are applied to the entire system. The historic settings are allow you to configure many historic features including:

  • The amount of time for which historic data is retained
  • The amount of memory used to cache historic data
  • The auditing of configuration change data
  • Limitations on extended historic searches.

You can use the Server Configuration Tool to define the settings for a variety of features relating to the storage of historic data, Event Journal data, and configuration changes. The settings for each of the historic/Event Journal/Configuration Change features are organized into the following groups (which you can access via the Server Status Tool’s hierarchy):

  • Historic Configuration
  • Archiving Settings—For detailed information on archiving, see Archiving.
  • Settings for Configuration Changes Auditing—Use to enable, disable, and configure the system-wide settings for the records of configuration changes.
  • Event Journal Storage Settings—Use to enable, disable and configure the system-wide settings for the records of the Event Journal.
  • Historic Data Storage Settings—Use to Use to enable, disable and configure the system-wide settings for the records of historic data for database items.
  • Historic Files—Use to Enable or Disable Historic Files
  • Search Limits for Historic Data and the Event Journal
  • Historic Algorithms (Custom)
  • Historic Regions
  • Historic Views—Use to perform queries on processed historic data. For more information, see Historic Views.


Server Administration Guide - Archiving Settings (Historic Configuration Settings)

Archiving Settings

The Archiving settings that are available in the Historic Configuration section of the Server Configuration Tool are described in detail in Archiving.


Server Administration Guide - Settings for Configuration Changes Auditing (Historic Configuration Settings)

Settings for Configuration Changes Auditing

ClearSCADA includes a Configuration Changes Auditing feature which allows you to configure your system so that it keeps a detailed record of configuration changes. When the Configuration Change Auditing feature is enabled, the extended configuration change data is stored in Configuration Change files which are completely separate to the Event Journal files. They include detailed information about the configuration changes that take place on your system. This is useful if you need to investigate what changes were made (the Event Journal keeps a record of configuration changes, but does not record the details of each change).

The Configuration Changes Auditing feature is disabled by default. This is because, when enabled, the feature can affect system resources - potentially, it can require as many resources as the Event Journal. Before you enable the Configuration Changes Auditing feature, you should:

  • Consider whether you really need to have detailed records of configuration changes. If you do, you will need to enable the feature. To limit the effect of Configuration Changes Auditing on system performance, we recommend that you try and limit the types of configuration changes that are audited.
  • Use the Audited Origins settings to limit the types of configuration changes that are recorded (where possible). The fewer types of configuration changes that are recorded, the less impact the feature will have on system performance. We explain how to use the Audited Origins settings later in this section.

You can use the Configuration Changes Auditing settings in the Historic Configuration section of the Server Configuration Tool to enable/disable the feature and define its settings.

The Configuration Changes Auditing settings consist of two separate groups - the main Configuration Changes Auditing settings and a sub-group of settings called the Audited Origins.

The main Configuration Changes Auditing settings work in a similar way to the Event Journal Storage Settings. The only difference is that the time spans, cache size, flush time limit, and thresholds apply to the configuration change files instead of the Event Journal files.

The Auditing Origins settings allow you to choose which types of configuration changes are recorded. Each configuration change has an ‘origin’ which indicates the type of action or interface that caused the change to occur. These origins are categorized as:

  • .NET API—Changed made via a Third Party client that uses the .NET API interface.
  • Automation Interface—Changes made via the Automation interface.
  • Configuration Form—Changes that are caused by users altering the settings on configuration Forms. For example, if you display a Point Form and change the address of the point, the address change will be recorded and will have a Configuration Form origin.
  • Database Internal—Changes that ClearSCADA performs automatically in response to a change made by a user. For example, an outstation can contain points that have parent-child relationships. If a user reconfigures the parent point so that it is associated with a different outstation, ClearSCADA automatically associates the child point with the other outstation too. The user’s changes are associated with the Configuration Form origin, but the changes to the child point have the Database Internal origin.
  • DDK Interface—Changes that are made via a DDK Interface.
  • Driver Upload—Changes that are caused by configuration data being uploaded from a device. For example, a device could be configured on one system and then physically moved to another location and connected to a different system. Rather than configure the settings for the device again at the second system, the relevant driver can upload the existing configuration settings from the device and apply them to the database. These changes would be associated with the Driver Upload origin.
  • Import (Merge)—Changes that are caused by a database item being imported into a database that already contains a version of the same item.
  • Import (Non-default)—Changes that are caused by a database item that has non-default settings being imported into the database. (The database item does not already exist in the database).
  • Load Configuration—Changes that are caused by configuration data being loaded from the Main server.

For example, the Load Configuration origin applies to automatic configuration changes made to the Outstation Type setting on SCADAPack E-Series outstations. If an pre-version 5 SCADAPack E-Series outstation is imported into ClearSCADA, ClearSCADA automatically detects that it can only support SCADAPack ES. So ClearSCADA configures the Outstation Type setting for the outstation to SCADAPack ES automatically, and this change is recorded with a Load Configuration origin.

  • Logic—Changes that are caused by Logic programs. For example, an ST program could write to the configuration fields of a point - the changes written by the program would have the origin ‘Logic’.
  • Method Call—Changes that occur as a result of a method (action) being performed.
  • Object Conversion—Changes that are made as a result of a database item of one type being converted into a different type of database item.
  • OPCDA—Changes that are made either by:
  • Third Party applications that use the OPCDA interface

Or:

  • Using the OPC Data Bar to access a database item’s property, then using the Set Value action to change the value for that property.
  • OPCXMLDA—Changes made via Third Party applications that use the OPCXMLDA interface.
  • Reference Patch—Changes that are caused by a referenced item being deleted. When an item is deleted from the database, any items that reference the deleted items are updated. These updates are configuration changes with ‘Reference Patch’ origins.
  • SOAP Interface—Changes made via Third Party applications that use the SOAP interface.
  • SQL DML Statement—Changes that occur as a result of an UPDATE, INSERT, or DELETE statement being used to make changes to your ClearSCADA database. The UPDATE, INSERT and DELETE statements can be issued via a Third Party SQL based application such as SQL Server, or via QueryPad.
  • Standby Transfer—Changes that are caused by the Main server sending configuration updates to the Standby server.
  • Template Propagation—Changes that are caused by updates to the configuration of an item in a Group Template. The changes in the Group Template are applied automatically to the relevant Group Instances, and these alterations are classed as ‘Template Propagation’ changes.
  • Toggling Features—Changes that relate to a feature that has its own aggregate being enabled or disabled. For example, when the Alarm Limits feature is enabled at the server, an Alarm Limits tab (aggregate) appears on the Point Form. If the Alarm Limits feature is disabled, the Alarm Limits tab is no longer shown. So changes that are caused by enabling or disabling the Alarms Limits feature at the server are recorded as having a Features origin.
  • Updating Metadata—Changes that relate to user-created metadata fields.
  • ValueMap—Changes that relate to value maps which are used with Master devices and Slave outstations. When a Master device writes a value to a Slave, the Slave driver then updates the relevant value map item with the new value. If the new value is a configuration value, this change will cause a configuration change with a ValueMap origin to be logged.
  • Write Raw Config.—Changes that relate to alterations that have been saved on any of the graphical editors, such as Trends, Logic diagrams, Schedules, Mimics (any configuration display except Forms).

You can choose which types of configuration change are recorded on your system. Select the check boxes for those origins that correspond to changes you want to be recorded. Clear the appropriate check boxes for those changes you do not want to be recorded.

If you have enabled the Configuration Changes Auditing feature, you can view configuration change data by selecting the Display Properties Changes action for a database object or a field on a Form (see Display a List of Property Changes in the ClearSCADA Guide to Core Configuration).

You can also view configuration change data in a Queries List or via QueryPad (by editing the SQL of a List so that the list gets its data from the CDBConfigChanges table). Alternatively, you could create a Mimic that uses expressions to get data from those tables. You can also view statistical information about the Configuration Changes files on the Server Status Tool (see ConfigChangesSearches in the ClearSCADA Guide to the Server Status Tool).


Server Administration Guide - Event Journal Storage Settings (Historic Configuration Settings)

Event Journal Storage Settings

You can use the Event Journal section of the Historic Configuration settings (on the ClearSCADA Server Configuration Tool) to define the lifetimes, stream size, cache size etc., for Event Journal data. Event Journal data contains the event messages that are created and stored when system events such as users logging on, controls being issued etc.

You can use the Event Journal settings to:

  • Enable or Disable the Event Journal
  • Define the Define the Event Journal Life for Event Messages
  • Define the Archive Time for the Event Journal
  • Define the Future Messages Time for the Event Journal
  • Define the Stream Size for Maximum Performance of the Event Journal
  • Define the Cache Size, Flush Time Limit and Thresholds for the Event Journal.

To fully configure the server settings for the Event Journal, you should also use the Events Display Settings for the Event Journal (Events List).


Server Administration Guide - Enable or Disable the Event Journal (Historic Configuration Settings)

Enable or Disable the Event Journal

The Event Journal provides a record of the events on a system. This means that any occurrence that affects the status or configuration of an item is recorded in the Event Journal.

Typically, the Event Journal is enabled. However, some systems have no need for the Event Journal data, so the Event Journal is disabled.

To enable or disable the Event Journal:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Historic Configuration branch.
  3. Select Event Journal
  4. Either:
  • Select the Enabled check box in the Event Journal section to activate the Event Journal feature.

Or:

  • Clear the Enabled check box in the Event Journal section to de-activate the Event Journal feature.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have enabled or disabled the Event Journal feature, you can either proceed to configure other Event Journal Storage Settings or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.


Server Administration Guide - Define the Event Journal Life for Event Messages (Historic Configuration Settings)

Define the Event Journal Life for Event Messages

The Event Journal Life is the amount of time for which ClearSCADA stores event messages on-line. When this time expires, the event data is deleted from disk. The Event Journal Life is defined via the Keep On-line For field in the ClearSCADA Server Configuration Tool's Historic settings (in the Event Journal section).

Use the Keep On-line For setting to define the Event Journal Life.

During the Event Journal life, the event messages data can change as new event messages for that time period are reported. However, if the archiving feature is enabled, there will be a set time at which the event message data can no longer be changed (see Set Event Journal Data to be Archived).

When event journal data exceeds the defined lifetime, it is deleted from disk to allow space for the latest event journal messages. So, if the Event Journal Life is set to 1 week, event messages that are stored historically on Sunday will be kept on-line for 7 days—they will be deleted from memory on the following Sunday. The event messages may be archived to a CD, DVD, hard drive etc. within the 7 days, depending on the Archive After n Weeks setting (see Set Event Journal Data to be Archived).

To define the Event Journal Life:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch.
  3. Select Event Journal
  4. Select the Enabled check box in the Event Journal section (so that the event journal feature is enabled).
  5. In the Event Journal section, enter the amount of time (in weeks) for the Event Journal Life in the Keep on-line for n weeks field. When the defined Event Journal Life expires, the event messages are deleted.
  6. Either:
  • Proceed to Define the Archive Time for the Event Journal

Or:

  • Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define the Archive Time for the Event Journal (Historic Configuration Settings)

Define the Archive Time for the Event Journal

The archive time (Event Journal) is the amount of time between each archive of Event Journal data. When the defined time elapses, the Event Journal data is archived to another medium such as a back up disk.

You can define the archive time in the Event Journal section of the ClearSCADA Server Configuration Tool. It is set in the Archive after n weeks field and is described in detail in the Archiving section.


Server Administration Guide - Future Messages Time for the Event Journal (Historic Configuration Settings)

Future Messages Time for the Event Journal

Event Journal records that have a time stamp with a date and time in the future can be stored historically. Typically, event journal records with future dates and times relate forecasted data or data from a device that has different time settings, such as an outstation that has not had its clock set correctly.

You can use the ClearSCADA Server Configuration Tool to define the lifetime setting for future messages. The future messages lifetime setting defines the maximum amount of time in the future that is permitted for future Event Journal messages—any message that has a time stamp that is further in the future than the defined time is not stored historically. For example, if the current date is October 1st 2006 and the Future Message Life is set to 1 week, any message that has a time stamp between October 2nd and October 7th will be stored historically. A message that has a time stamp beyond October 7th will be lost as the date of the future data is further in the future than the defined Future Message Life.

You can define the Event Journal’s Future Life in the Event Journal settings in the Historic Configuration section of the ClearSCADA Server Configuration Tool:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Historic Configuration branch of the tree-structure.
  3. Select Event Journal to display the Event Journal settings.
  4. Select the Enabled check box (so that the Event Journal feature is enabled).
  5. Enter the amount of time (in weeks) for the future life in the Future Messages field. Any event data that has a time stamp that is before the expiry of the Future Data time will be stored historically. Event data that has a time stamp beyond the Future Messages limit will not be stored historically.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define the Stream Size for Maximum Performance of the Event Journal (Historic Configuration Settings)

Define the Stream Size for Maximum Performance of the Event Journal

If your system experiences slow performance when displaying and filtering events, you may need to adjust the Stream Size. The Stream Size setting allows you to control the amount of data that is included in each event data file.

ATTENTION: You should only change the Stream Size setting if your system is experiencing slow performance. If you adjust the Stream Size unnecessarily, you may introduce performance related issues on your system.

By default, ClearSCADA uses a Stream Size of 256 Objects, which means that each event data file will contain an hour’s worth of event data for a maximum of 256 database items. If the database contains more than 256 items, it will create extra files for the other database items (with each file containing the event data for a maximum of 256 items). For many systems, the Stream Size setting of 256 Objects is suitable.

However, if your system suffers from slow performance when displaying and filtering event data, you may need to adjust the Stream Size.

There are several possible causes of slow performance relating to the event data files:

  • Your system has a large database (over 100,000 items). The high number of database items can cause an excessive number of files.

In this situation, you may be able to improve performance by choosing a higher Stream Size. The higher Stream Size will set ClearSCADA to store event data for a higher number of items in each file. So instead of each event file storing 1 hour’s worth of event data for the default 256 items, the event files will store 1 hour’s worth of event data for 512, 1024, 2048, or 4096 items.

If you increase the Stream Size, each event file will contain the event data for a higher number of database items. This means that fewer event data files will be created, but each file will be larger in size (as a file now includes 1 hour’s worth of data for a higher number of items). If the files become too large (exceed 5MB), your system may experience slow performance.

  • Your system is logging a high number of events. On especially active systems, the volume of events being logged can cause the individual event data files to become large in size (we recommend that the size of the largest event data file should not exceed 5MB).

In this situation, you may be able to improve performance by choosing a lower Stream Size. The lower Stream Size will set ClearSCADA to store event data for a lower number of items in each file. So instead of each event file storing 1 hour’s worth of event data for the default 256 items, the event files will store 1 hour’s worth of event data for 128 or 64 items (depending on your choice).

While this may result in smaller event data files, there amount of event data files will increase. An excessive number of database files can also cause slow performance.

If your system experiences slow performance when displaying, searching, and filtering the Events List, you may need to change the Stream Size as follows:

  1. Run the ClearSCADA Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to Server Status).
  2. Navigate to the Historic section, then select Historian (see Historian in the ClearSCADA Guide to the Server Status Tool).
  3. Examine the Largest File Size entry for the Event row.
  • If it is over 5MB, you should consider reducing the Stream Size. Proceed to step 4.
  • If it is under 5MB, the slow performance of the Events List may be related to the amount of event files rather than the size of event files. Proceed to the step 4.
  4. Look at the number of Total Files for the Event row.
  5. Use the Largest File Size and Total Files to determine an appropriate method for improving performance:
  • If the Largest File Size is less than 5MB and the Total Files is less than 100,000, do not change the Stream Size. If your system is experiencing slow performance, it is unlikely to be as a result of the size or amount of historic files. Contact Schneider Electric for help with improving your system performance.
  • If the Largest File Size is less than 5MB and the Total Files is greater than 100,000, you should consider increasing the Stream Size (proceed to step 6).
  • If the Largest File Size is greater than 5MB and the Total Files is less than 100,000 you should consider decreasing the Stream Size (proceed to step 6).
  • If the Largest File Size is greater than 5MB and the Total Files is more than 100,000 your system is generating a large number of events. You can either look at ways of reducing the amount of events generated or upgrade your hardware so that it can provide the performance needed to store a high number of events. Do not adjust the Stream Size.

To reduce the number of events on your system, see Diagnose and Resolve the Server Load Problems in the ClearSCADA Guide to the Server Status Tool.

ATTENTION: If the Largest File Size is greater than 5MB and the Total Files is more than 100,000, you should investigate the cause of the events on your system and take measures to reduce the number of events being logged (or upgrade your hardware). You should not proceed with steps 6 onwards as changing the Stream Size may cause further performance issues.

  6. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  7. Expand the Historic Configuration branch.
  8. Select Event Journal.
  9. Check that the Event Journal is enabled (see Enable or Disable the Event Journal).
  10. Use the Stream Size combo box to set a higher or lower stream size as required.

ATTENTION: Changing the Stream Size can take a considerable amount of time and can result in a temporary loss of service to clients.

Higher stream sizes result in fewer but larger event data files; lower stream sizes result in a greater number of event data files, but with each event data file being smaller in size.

NOTE: The 0 - No Streams setting sets ClearSCADA to store the events for database items in a single file (which should only be used if your system has a small database and logs a low number of events).

  11. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have set the stream size, you can either proceed to configure other Historic Configuration settings (see Historic Configuration Settings) or you can continue with the server configuration.


Server Administration Guide - Define the Cache Size, Flush Time Limit and Thresholds for the Event Journal (Historic Configuration Settings)

Define the Cache Size, Flush Time Limit and Thresholds for the Event Journal

You can use the Cache Size, Flush Time Limit, Upper Threshold and Lower Threshold features to manage the amount of memory that can be used for the Event Journal cache. Used carefully, these settings can reduce the possibility of the server running out of memory when users are performing searches on Event Journal data.

The Event Journal cache is an amount of memory dedicated to the storage of event data. Event data is stored in the Event Journal cache when:

  • It is first reported to the system. New events are temporarily stored in the Event Journal cache for a short period (60 seconds by default, but this is adjusted automatically by ClearSCADA) before being written to disk. The process of writing events stored in the Event Journal cache to disk is called ‘flushing’.
  • It meets the search criteria set by a user currently working on the system (for example, a user who is using the Events List to search for events that occurred within a specific time frame).

New data being flushed to disk usually has a negligible impact on the performance of
a ClearSCADA system. Users searching event data, however, can affect system performance. This is because the Event Journal cache is used to store the event data that is currently being queried by users—if there are multiple users querying different event data, the events that match the criteria for those searches have to be loaded into the Event Journal cache (at the same time). This can cause the cache to become overloaded, and as a result, system performance becomes slower.

NOTE: If multiple users are querying the same event data, the Event Journal cache contains one copy of that data—the data is loaded into the cache and shared. However, if the users’ searches require different event data, the events for each separate search have to be loaded into the Event Journal cache.

By default, the server flushes as much Event Journal data as possible every 60 seconds. The duration of each flush is defined by the Flush Time Limit (1000 milliseconds by default). When a flush occurs, the server also monitors the amount of Event Journal data that remains unflushed. If this amount is higher than the Upper Threshold limit, the server automatically decreases the flush interval to 30 seconds so that the data is flushed more frequently. If the amount of unflushed data is still higher than the Upper Threshold, the server will decrease the flush interval to 15 seconds. The server can continue to decrease the flush interval until it reaches 1 second and will continue to adjust the interval according to the amount of unflushed data. Typically, the flush interval will remain at 60 seconds or will fluctuate between 60 seconds and 30 seconds or 30 seconds and 15 seconds depending on the amount of data being searched.

If the server monitors the unflushed data and detects that the amount of unflushed data is lower than the Lower Threshold, the server will increase the flush interval. This helps to ensure that the server's resources are not wasted on flushing the data too frequently. When the amount of unflushed Event Journal data is less than the Lower Threshold amount, the server will double the flush interval. If the unflushed data continues to be below the Lower Threshold amount, the server will double the flush interval again. The server can continue to double the flush interval until it reaches 60 seconds. If the unflushed data continues to be below the Lower Threshold amount, the server will continue to flush it once every 60 seconds.

On many systems, the default settings for the Cache Size, Flush Time Limit, Upper Threshold and Lower Threshold are appropriate and do not need to be altered. However, if memory usage is causing performance issues on your system, you may want to adjust the cache size, flush limit, and threshold settings.

To alter the Cache Size, Flush Time Limit, Upper Threshold and Lower Threshold for Event Journal data:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch.
  3. Select Event Journal.
  4. Select the Enabled check box in the Event Journal section (if it is not already selected). This activates the Event Journal.
  5. Enter the required Cache Size. For many systems, the default setting of 25 MB is appropriate. However, if your system is experiencing server load problems and the Cache Size needs to be adjusted, you can alter the Cache Size settings as required:
  • On 32 bit systems, the maximum combined size for the Event Journal Cache and the Historic Cache is 400MB (see Define the Cache Size, Flush Limit and Thresholds for Historic Data). If you wish, you can allocate 200MB to the Event Journal Cache and 200MB to the Historic cache, or you can set the caches to other sizes as long as they do not exceed 400MB in total.
  • On 64 bit systems, you can increase the Cache Size to any size as long as the server has that amount of RAM available.

If your system experiences performance issues when performing Event Journal searches, you may need to calculate a Cache Size that is appropriate to your system—see Slow Events List Performance due to the Event Journal Cache becoming Full in the ClearSCADA Guide to the Server Status Tool for more information.

If increasing the Cache Size does not resolve the performance issue, you may need to reduce the amount of events that are being logged—see Diagnose and Resolve the Server Load Problems in the ClearSCADA Guide to the Server Status Tool.

  6. Enter the required Flush Time Limit in milliseconds (between 50 and 30000 milliseconds). Remember that if you set the Flush Time Limit too low, there might be insufficient time for the flush to complete. Similarly, if you set the Flush Time Limit too high, the database might lock for extended periods while the flushing takes place. In both instances, these problems would only occur on busy systems.
  7. Set the Upper Threshold and Lower Threshold amounts as required (both are percentages of the total cache size). You need to set the Upper Threshold to a higher amount than the Lower Threshold (ClearSCADA will not allow you to apply an Upper Threshold that is a lower percentage than the Lower Threshold).

On many systems, the default settings of 20% and 10% are appropriate. We recommend that you do not change these amounts unless advised to do so by
Schneider Electric.

  8. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have defined the Cache Size, Flush Time Limit, Upper Threshold and Lower Threshold you can either proceed to configure other Historic Data or Event Journal settings or you can continue with the server configuration.

For information on the other Historic Configuration settings, refer to the list of features at the start of this section (see Historic Configuration Settings).

If you are unfamiliar with the server configuration process, we recommend that you proceed to define the Search Limits for Historic Data and the Event Journal.


Server Administration Guide - Historic Data Storage Settings (Historic Configuration Settings)

Historic Data Storage Settings

The Historic Data settings apply to the historic data for database items that support historic data storage (database points, master station accumulators and some driver-specific items). When enabled, the historic data feature creates historic files, with each historic file containing 1 week's worth of historic data for an individual item.

NOTE: Do not confuse the Historic Data settings with the Historic Files setting. The Historic Files setting allows you to enable or disable historic storage of reports and documents, for example, file upload reports and Crystal Reports reports (see Enable or Disable Historic Files).

The Historic Data settings are located in the Historic Configuration branch of the Server Configuration Tool:

You can use the Historic Data settings to:

  • Enable or disable historic data (see Enable or Disable Historic Data)
  • Define the Historic Life for Historic Data
  • Set the Define the Archive Time for Historic Data
  • Define the Future Data Life
  • Allow historic data to be manually validated (see Enable or Disable Manual Historic Data Validation)
  • Define whether Modified Data is Used when Processing Historic Data
  • Define the Cache Size, Flush Limit and Thresholds for Historic Data.


Server Administration Guide - Enable or Disable Historic Data (Historic Configuration Settings)

Enable or Disable Historic Data

The Historic Data feature allows data to be stored in the database as historic data—data that is no longer current, but can be searched and accessed. The historic data is useful for comparing values over periods of time and observing patterns in the data.

To allow ClearSCADA to store the previous values of database items, you need to enable the Historic Data feature. However, you should only enable Historic Data if you really need to use past values as storing historic data will place a demand on your system's resources.

When the Historic Data feature is enabled, the points, master station accumulators etc., can be configured to have their values stored historically in the database. The historic values of the items are stored for a defined amount of time (see Define the Historic Life for Historic Data). At the end of the defined time, the values are deleted or archived as required (see Archiving).

If your system is only designed to monitor the current values, you should disable the Historic Data feature so that system resources are conserved.

To enable or disable the Historic Data feature:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Historic Configuration branch.
  3. Select Historic Data.
  4. Either:
  • Select the Enabled check box in the Historic Data section to allow ClearSCADA to store values in the historic database.

Or:

  • Clear the Enabled check box in the Historic Data section if your system is not required to store data historically.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have enabled or disabled the historic data feature, you can either proceed to configure other Historic Configuration settings (see Historic Configuration Settings) or you can continue with the server configuration.

Further Information

Historic Configuration Settings.


Server Administration Guide - Define the Historic Life for Historic Data (Historic Configuration Settings)

Define the Historic Life for Historic Data

When the historic feature is enabled, certain database items such as points can be configured to have their data stored historically. This means that ClearSCADA keeps a record of the items' values over a period of time. The amount of time for which the historic values are stored is called the Historic Life. The Historic Life is defined via the Keep On-line For field in the ClearSCADA Server Configuration Tool's Historic Data section (in the Historic Configuration settings).

Use the Keep On-line For setting to define the Historic Life.

During the Historic Life, historic data can be altered (by ClearSCADA or manually). However, if the archiving feature is enabled, there is a set time at which the historic data can no longer be changed (see Define the Archive Time for Historic Data).

When historic data exceeds the defined lifetime, it is deleted from disk to allow space for the latest historic values. So, if the Historic Life is set to 1 week, data that is stored historically on Sunday will be kept on-line for 7 days—it will be deleted from memory on the following Sunday. It may be archived to a CD, DVD, hard disk etc., within the 7 days, depending on the Archive After n Weeks setting (see Set Historic Data to be Archived).

To define the Historic Life:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch of the tree-structure.
  3. Select Historic Data to display the Historic settings.
  4. Select the Enabled check box in the Historic Data section. This activates the historic data feature.
  5. In the Historic Data section, enter the amount of time (in weeks) for the Historic Life in the Keep on-line for n weeks field. When the defined Historic Life expires, the historic data is deleted.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Further Information

Historic Configuration Settings.


Server Administration Guide - Define the Archive Time for Historic Data (Historic Configuration Settings)

Define the Archive Time for Historic Data

The archive time defines the amount of time that has to pass before historic data is eligible for archiving. When historic data becomes eligible for archiving, it remains on-line for the remainder of the Historic Life, but is no longer writeable (it cannot change for the rest of the Historic Life).

You can define the archive time in the Historic settings of the ClearSCADA Server Configuration Tool. It is set in the Archive after n weeks field and is described in detail in the Archiving section.


Server Administration Guide - Define the Future Data Life (Historic Configuration Settings)

Define the Future Data Life

Data that is time stamped with a date or time in the future can be stored historically. Future time stamps are often a feature of forecasted data, but there are also other ways of getting data with future time stamps. For example, you can get future time stamps with data reported by a device that has different time settings, such as an outstation that has not had its clock set correctly.

You can use the ClearSCADA Server Configuration Tool to define the lifetime setting for future data. The Future Data setting defines the maximum amount of time in the future that is permitted for future data—any data that has a time stamp that is further in the future than the defined time is not stored historically. For example, if the current date is October 1st 2006 and the Future Data is set to 1 week, any data that has a time stamp between October 2nd and October 7th will be stored historically. Data that has a time stamp beyond October 7th will be rejected as the date of the future data is further in the future than the defined Future Data lifetime.

To define the Future Data lifetime for historic data:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Historic Configuration branch of the tree-structure.
  3. Select Historic Data.
  4. Check that the Enabled check box is selected so that the historic data feature is enabled.
  5. In the Historic Data section, enter the amount of time (in weeks) for the future life in the Future Data field. Any data that has a time stamp that is before the expiry of the Future Data lifetime will be stored historically (as long as the relevant database item is configured to have the Historic feature enabled via its Form).
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Further Information

Historic Configuration Settings.


Server Administration Guide - Enable or Disable Manual Historic Data Validation (Historic Configuration Settings)

Enable or Disable Manual Historic Data Validation

Historic data can be marked as invalid until it has been checked and validated by a user. By examining the historic values, users can check that the reported values are accurate before marking them as valid (validated historic values are active

The Historic Validation feature is designed for use with systems that are connected to unreliable devices, for example, unreliable outstations or sensors. You should only enable the feature if it is required as part of your company policy.

NOTE: You need to enable Historic Data to make use of manual historic data validation

To enable or disable the Historic Validation feature:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Historic Configuration branch.
  3. Select Historic Data.
  4. Check that the Historic Data feature is enabled (see Enable or Disable Historic Data). You can only use Historic Validation if Historic Data is enabled.
  5. Either:
  • Select the Allow Historic Data to be Manually Validated check box to activate the Historic Validation feature. When Historic Validation is enabled, historic values will need to be validated manually via the Validate Data action on a Historic Trend.
  • Clear the Allow Historic Data to be Manually Validated check box to de-activate the Historic Validation feature.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have enabled or disabled the historic validation feature, you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to Define whether Modified Data is Used when Processing Historic Data.


Server Administration Guide - Define whether Modified Data is Used when Processing Historic Data (Historic Configuration Settings)

Define whether Modified Data is Used when Processing Historic Data

There are 3 types of historic data:

  • Raw values—The values that are reported by plant etc. These are the values that ClearSCADA receives.
  • Processed values—Values that are calculated by ClearSCADA. These values are the result of a calculation that ClearSCADA performs on the raw values (and also modified values, if selected).
  • Modified values—Values that are created manually by a user.

When ClearSCADA processes historic data, it performs calculations on the raw values to create the engineering values. It can also include the modified values so that the engineering values are the results of calculations on both the raw values and the modified values. This depends on the Use modified data when processing historic data setting:

  • If the Use modified data when processing historic data check box is selected, the modified values are included in the processing.
  • If the Use modified data when processing historic data check box is clear, the modified data is excluded from the processing. The engineering values will be the results of calculations performed on the raw values only.

The Use modified data when processing historic data check box is selected by default.

To change the Use modified data when processing historic data setting:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Historic Configuration branch.
  3. Select Historic Data.
  4. Check that the Historic Data feature is enabled (see Enable or Disable Historic Data).
  5. Either:
  • Select the Use modified data when processing historic data check box to include modified values in the historic data processing.

Or:

  • Clear the Use modified data when processing historic data check box to exclude modified values from the historic data processing.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have selected or cleared the Use modified data when processing historic data setting, you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to Define the Cache Size, Flush Limit and Thresholds for Historic Data.


Server Administration Guide - Define the Cache Size, Flush Limit and Thresholds for Historic Data (Historic Configuration Settings)

Define the Cache Size, Flush Limit and Thresholds for Historic Data

When users on ClearSCADA clients perform searches on historic data, the section of historic data that is required for the search is loaded from disk into the cache on the ClearSCADA server. The search is then performed on the data in the cache. For example, when a user filters a point's Historic List for values that were reported in the last 2 hours, the file containing the point's historic data is loaded into memory.

If multiple users are performing searches on the same historic data, the same data in the cache is used—it does not contain separate versions of the historic data for each user's search. However, if multiple users are searching different historic data simultaneously, the cache can become overloaded and your system may experience slow performance.

You can use the Cache Size settings to define the size of the historic data cache for each type of historic data—Raw (unprocessed historic data), Modified (historic data that has been manually altered), Annotation (historic data that has an annotation), and Suppression (historic data for an item that was suppressed at the time the historic data was recorded). You can also define the Flush Time Limit, Upper Threshold and Lower Threshold features to limit the amount of cache memory that can be used to contain historic data files—this reduces the possibility of the server running out of memory when users are performing searches on historic data.

By default, the server flushes as much historic data as possible every 60 seconds. The duration of each flush is defined by the Flush Time Limit (1000 milliseconds by default). When a flush occurs, the server also monitors the amount of historic data that remains unflushed. If this amount is higher than the Upper Threshold limit, the server automatically decreases the flush interval to 30 seconds so that the data is flushed more frequently. If the amount of unflushed data is still higher than the Upper Threshold, the server will decrease the flush interval to 15 seconds. The server can continue to decrease the flush interval until it reaches 1 second and will continue to adjust the interval according to the amount of unflushed data. Typically, the flush interval will remain at 60 seconds or will fluctuate between 60 seconds and 30 seconds or 30 seconds and 15 seconds depending on the amount of data being searched.

If the server monitors the unflushed data and detects that the amount of unflushed data is lower than the Lower Threshold, the server will increase the flush interval. This helps to ensure that the server's resources are not wasted on flushing the data too frequently. When the amount of unflushed historic data is less than the Lower Threshold amount, the server will double the flush interval. If the unflushed data continues to be below the Lower Threshold amount, the server will double the flush interval again. The server can continue to double the flush interval until it reaches 60 seconds. If the unflushed data continues to be below the Lower Threshold amount, the server will continue to flush it once every 60 seconds.

On many systems, the default settings for the Cache Size, Flush Time Limit, Upper Threshold and Lower Threshold are appropriate and do not need to be altered. However, if memory usage is affecting the performance of your system, you may want to adjust these settings.

To alter the Cache Size, Flush Time Limit, Upper Threshold and Lower Threshold for Historic Data:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Historic Configuration branch.
  3. Select Historic Data.
  4. Check that the Enabled check box in the Historic Data box is selected (i.e. the Historic Data feature is enabled).
  5. Enter the required Cache Size in the Raw, Modified, Annotation and Suppression fields. For many systems, the default settings of 25 Raw, 5 Modified, 5 Annotation, and 5 Suppression are appropriate. However, if your system is experiencing slow performance due to the server load and the Cache Size needs to be adjusted, you can alter the Cache Size settings as required:
  • On 32 bit systems, the maximum combined size for the Historic Cache and the Event Journal cache should not exceed 400MB (see Define the Cache Size, Flush Time Limit and Thresholds for the Event Journal). If you wish, you can allocate 200MB to the Event Journal Cache and 200MB to the Historic cache, or you can set the caches to other sizes as long as they are 400MB or less in total.
  • On 64 bit systems, you can increase the Cache Size to any size as long as the server has that amount of RAM available.

To calculate the appropriate Historic Cache Size for your system, see Slow Performance of Historic Displays in the ClearSCADA Guide to the Server Status Tool.

If increasing the Cache Size does not improve performance to the required level, you may need to reduce the amount of events that are being logged—see Diagnose and Resolve the Server Load Problems in the ClearSCADA Guide to the Server Status Tool.

  6. Enter the required Flush Time Limit in milliseconds (between 50 and 60000 milliseconds). You need to set the Flush Time Limit so that there is sufficient time for the flush to complete, so be careful not to enter a limit that is too short. Similarly, if you set the Flush Time Limit too high, the database might lock for extended periods while the flushing takes place. In both instances, these issues would only occur on busy systems.
  7. Set the Upper Threshold and Lower Threshold amounts as required (both are percentages of the total cache size). The Upper Threshold has to be higher than the Lower Threshold (ClearSCADA will not allow you to apply an Upper Threshold that is lower than the Lower Threshold).

On many systems, the default settings of 20% and 10% are appropriate. We recommend that you do not change these amounts unless advised to do so by
Schneider Electric.

  8. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have defined the Flush Time Limit, Upper Threshold and Lower Threshold you can either proceed to configure other Historic settings or you can continue with the server configuration.

For information on the other Historic settings, refer to the list of features at the start of this section (see Historic Configuration Settings).

If you are unfamiliar with the server configuration process, we recommend that you proceed to Enable or Disable Historic Files.


Server Administration Guide - Enable or Disable Historic Files (Historic Configuration Settings)

Enable or Disable Historic Files

The Historic Files feature allows ClearSCADA to create a historic file that can be used for reports and other documents. For example, the historic files feature allows ClearSCADA to:

  • Provide historic storage of Crystal Reports
  • Provide historic storage of file upload reports

Each time the report, document etc. is generated, a new historic file is created.

You can use the Historic Files section of the Historic Configuration settings (ClearSCADA Server Configuration Tool) to enable or disable the Historic Files feature.

If the Historic Files feature is disabled, ClearSCADA cannot provide historic storage of reports, documents etc. For this reason, we recommend that the Historic Files feature is set to enabled.

You can disable the Historic Files feature if you do not require historic storage of reports etc. Disabling the Historic Files feature will improve the synchronization time, but only by a negligible amount.

To enable or disable the Historic Files feature:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch.
  3. Select Historic Files.
  4. Either:
  • Select the Enabled check box in the Historic Files section to allow ClearSCADA to create a historic file for reports, documents etc.

Or:

  • Clear the Enabled check box in the Historic Files section to stop ClearSCADA from creating a historic file for reports, documents etc.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have enabled or disabled the Historic Files feature, you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.


Server Administration Guide - Search Limits for Historic Data and the Event Journal (Historic Configuration Settings)

Search Limits for Historic Data and the Event Journal

You can use the ClearSCADA Server Configuration Tool to define the search limits for historic searches. This is useful as it allows you to define set limits on processor usage and the size of searches so that searches for historic data do not put a great demand on the server.

To define the search limits, you need to use the Search Limits section in the Historic settings (ClearSCADA Server Configuration Tool).

As with many of the other historic settings, the default settings for search limits are suitable for many systems. However, you may need to change the settings if you are experiencing slow responses to historic searches or other processes are 'freezing' during a historic search.

To define the search limit settings:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Historic Configuration branch.
  3. Select Search Limits.
  4. In the Search Limits section, define these settings:
  • CPU Usage—Define the percentage of processor use you want to allocate to historic query searches (via the Query spin box) and other searches such as OPC HDA searches (via the Search spin box).

If programs and other processes are experiencing 'freezing' during historic searches, you should reduce the CPU Usage amounts.

If your historic searches are slow and are taking longer than expected to return results, you may achieve better results by increasing the CPU Usage amounts. However, we recommend that you try to reduce the number of historic records involved in the search before you increase the CPU Usage settings.

We recommend that the CPU Usage should be below 90%.

ATTENTION: If you increase the CPU Usage above 90%, your system may experience issues with drivers and client connections. For this reason, do not increase the CPU Usage above 90% unless specifically instructed to do so by Schneider Electric engineers.

  • Timeout—Enter the amount of time (in seconds) that is permitted for historic query searches (via the field under the Query heading) and other searches such as OPC HDA searches (via the field under the Search heading).

If the historic search has not completed when the timeout expires, the historic search will be abandoned.

  • Maximum Records—Enter the maximum number of records that can be included in a single historic query. The default setting of 100,000 is appropriate for many systems.

The Maximum Records setting limits the number of records in a single historic query so that the system is not adversely affected by searches returning huge numbers of historic records. Queries can usually be structured more efficiently so that they filter for the required information more effectively (by reducing the number of historic files needed for the search).

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have defined the Search Limits, you can either proceed to configure other Historic settings or you can continue with the server configuration.

For information on the other Historic settings, refer to the list of features at the start of this section (see Historic Configuration Settings).

If you are unfamiliar with the server configuration process, we recommend that you proceed to Define which Columns are shown on the Event List.


Server Administration Guide - Events Display Settings for the Event Journal (Events List) (Historic Configuration Settings)

Events Display Settings for the Event Journal (Events List)

You can use the Events settings on the ClearSCADA Server Configuration Tool to:

  • Define which Columns are shown on the Event List.
    Use these settings to define which columns are shown on the Events List. Each column represents a different type of information.

By changing the columns, you can alter the Events List (that is available to all users) so that it only contains selected types of information.


Server Administration Guide - Define which Columns are shown on the Event List (Historic Configuration Settings)

Define which Columns are shown on the Event List

You can use the Events section of the ClearSCADA Server Configuration Tool to define which columns are included in the Event List. This is useful when you only want the Event List to display specific information.

To define which columns are shown on the Event List:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the System Configuration branch.
  3. Select Events to display the Events section.
  4. Use the column lists and the buttons to define which columns are included and the order in which they are displayed:
  5. Select a column from one of the lists.
  • The Available Columns list shows those columns that are not currently included on the Events List.
  • The Current Columns list shows those columns that are included on the Events List.
  6. Select the Add button to add the column to the Current Columns list or select the Remove button to add the column to remove the column from the Current Columns list and place it in the Available Columns list.
  7. Change the order of the columns on the Events List by selecting a column in the Current Columns list and then selecting the Move Up or Move Down button. The top column is shown on the left of the Events List and the bottom column is shown on the right, with the other columns being shown in order from left to right.
  8. Use the Fixed Columns spin box to choose the number of columns that cannot be resized on the Events List. For example, if the setting is 2, the first 2 columns will be fixed so that they cannot be resized.

NOTE: If you have made a mistake, you can set the columns back to their default settings by selecting the Reset button.

  9. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have set the Event List columns, you can either proceed to configure other Event Journal settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.


Server Administration Guide - Historic Algorithms (Custom) (Historic Configuration Settings)

Historic Algorithms (Custom)

You can use the Historic Algorithms settings to add, modify, and remove custom historic algorithms (historic calculations). The Historic Algorithms settings are located in the Database Configuration branch on the ClearSCADA Server Configuration Tool.

This section describes:

  • Algorithm Types

and explains how to:

  • Add a Historic Algorithm.
  • Modify a Historic Algorithm.
  • Remove a Historic Algorithm.


Server Administration Guide - Algorithm Types (Historic Configuration Settings)

Algorithm Types

Historic algorithms are calculations that can be applied to raw historic data. They are used to provide an overview of values or to provide specific statistics, for example, the average value of a point over a specified time period.

There are many different built-in historic algorithms that are available in ClearSCADA and you can also create your own custom historic algorithms.

For a list of the built-in algorithms, see Historic Algorithms (Custom).

There are two types of historic algorithm that you can create:

  • Accumulative Algorithms
  • Moving Algorithms.

Accumulative Algorithms

Accumulative algorithms are calculations that are performed on a set of values in the current sample. They are useful for calculating historic values at set times for a defined time period. For example, calculating the minimum value every hour for a day. The type of calculation that the algorithm represents is defined in the algorithm's configuration and can be:

  • Min—Calculates the minimum value during the sample.
  • Max—Calculates the maximum value during the sample.
  • Mean—Calculates the mean average value during the sample.
  • Integrator—Calculates the total value during the sample.
  • Rate of Change—Calculates the rate at which values are changing during the sample.
  • Runtime—Calculates the amount of time that an item, such as a point, remains in the same state.
  • Counter—Calculates accumulative values during the sample.

To calculate the historic value, ClearSCADA uses a sample. The sample is a set of values that are reported during a defined time. For example, to calculate the hourly average, ClearSCADA uses a sample of values that were reported during an hour period.

The start time of the sample is the first time on the X-Axis of a graph, or is defined in a Historic View which can be accessed by an SQL Query (see Historic Views). The start time is rounded down to the start of the resample time unit, for example, rounded down the start of the hour.

The end time of the sample is defined by the Reset Multiplier setting of the accumulative algorithm.

NOTE: ST programs can access the historic algorithms directly via the %H tag.

The rate at which the historic values are calculated is defined by the interval (the amount of time that elapses between each calculation). On historic graphs, it is defined in the trace configuration. If the historic algorithm is to be used by SQL Queries, the interval has to be defined in a Historic View which can be accessed by SQL Queries.

The Reset Multiplier setting defines the end time of a sample and is similar to a point's End of Period Reset setting. The Reset Multiplier is equal to n x the interval for the historic values.

Example:

For example, if a historic graph has a trace interval of 1M (1 minute) and the Reset Multiplier setting is 4, there are four 1 minute samples that form a 4 minute sample period.

A historic value is calculated after 1 minute based on the values reported during that minute.

A second historic value is reported after 2 minutes, based on the values reported in the first 2 minutes (both the first minute sample and the second minute sample). Similarly, the third value is based on the values in the first 3 minutes, and the fourth value is based on the values in minutes 1, 2, 3, and 4.

When the fourth value has been calculated, the sample is reset and the second sample period begins. The next historic value that is reported will only use the values in the second sample period—the values from the first sample are ignored.

Algorithm is used to calculate the historic value every minute.
Large green markers and red trace show average values calculated by algorithm
Small green markers show actual historic values reported during the minute intervals.
With the algorithm's Reset Multiplier set to 4 (4 x the interval of 1 minute), the sample period is reset after 4 minutes. The calculated values in the next 4 minutes do not use the values from the previous samples.

Moving Algorithms

Moving algorithms are calculations that use the values in the current sample and values from previous samples to provide historic values. They allow you to set the system to calculate a value based on a time period that is a different size to the interval. For example, you can use a moving algorithm to calculate the average hourly value every 30 minutes. The one hour algorithm sets the duration of the sample, and the interval of 30 minutes is set for the trace on a Graph (or in a Historic View which can be accessed by an SQL Query).

Moving algorithms can only be used to calculate sum or average values.

Example:

An 8 hour algorithm is used to calculate the average values. The average value for an 8 hour period is to be calculated once an hour. Every hour, the algorithm calculates an average value based on the values that have been reported during the previous 8 hours. For example, at 3pm, the algorithm calculates the average value based on the values that have been reported during the hours 7am-8am, 8am-9am, 9am-10am, 10am-11am, 11am-12 noon, 12 noon-1pm, 1pm-2pm, and 2pm-3pm. At 4pm, the algorithm calculates the average value based on the values that have been reported during the hours 8am-9am, 9am-10am, 10am-11am, 11am-12 noon, 12 noon-1pm, 1pm-2pm, 2pm-3pm, and 3pm-4pm.

This means that for every hour in the day there is an average value based on the previous 8 hours worth of data.

If an accumulative algorithm had been used to calculate the average value for 8 hours of data, the historic value would only be calculated 4 times a day—once every 8 hours.

Add a Historic Algorithm

You need to add a historic algorithm for each custom algorithm that is required on your system. Custom algorithms are needed when the default algorithms for traces on Historic Graphs are unsuitable for your needs.

To add a historic algorithm:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool)
  2. Expand the Database Configuration branch.
  3. Select Historic Algorithms.
  4. Right-click in the list of historic algorithms to display a context sensitive menu.
  5. Select the type of algorithm that you want to create:
  • Add Accumulative Algorithm—The algorithm only uses the values in the current sample to calculate the historic value (see Accumulative Algorithms).
  • Add Moving Algorithm—The algorithm uses the values in the current sample and the samples for a defined amount of time prior to the current sample to calculate the historic value (see Moving Algorithms)

If you selected Add Accumulative Algorithm, proceed to step 6.

If you selected Add Moving Algorithm, proceed to step 8.

  6. Use the Add Accumulative Algorithm window to define the settings for the algorithm:.
  • Name—Type in a suitable name for the algorithm. The name should indicate the purpose of the algorithm.
  • Description—Type in a short description of the algorithm. The description will allow other users to easily understand the purpose of the algorithm.
  • Calculation Method—Select the type of calculation that is provided by the algorithm. Choose from:
  • Min—Calculates the minimum value during the sample.
  • Max—Calculates the maximum value during the sample.
  • Mean—Calculates the mean average value during the sample.
  • Integrator—Calculates the total value during the sample.
  • Rate of Change—Calculates the rate at which values are changing during the sample.
  • Runtime—Calculates the amount of time that an item remains in the same state.
  • Counter—Calculates accumulative values during the sample.
  • States Counted—This setting is only available when the Calculation Method is set to Runtime or Counter. None, True, False, True And False.
  • Reset Multiplier—This setting defines the reset time for the sample. It is a multiplication of the interval, for example if the Reset Multiplier is set to 2 and the interval for the historic data is 1 hour, the end of the sample is set to 2 hours. After every 2 hours, the sample will be reset—the values in the previous sample will not be used in the calculation for the next historic value.
  7. Select the OK button to confirm the settings. Proceed to step 10. Ignore steps 8 and 9 as they only apply to moving algorithms.
  8. Use the Add Moving Algorithm window to define the settings for the new algorithm:
  • Name—The name for the algorithm. You should enter a name that is indicitive of the type of algorithm, so that users can easily understand the purpose of the algorithm when using a historic graph.
  • Description—Enter a short description of the algorithm. Again, this is to help users understand the purpose of the algorithm.
  • Calculation Type—Choose the type of calculation for the algorithm. This can be:
  • Average—A mean average calculation.
  • Sum—A total calculation.
  • Interval Type—Define the time units for the amount of time over which the algorithm will be applied. For example, if you want the algorithm to be used to calculate the average values for 6 days prior to the resample interval on a Graph, you need to set the Algorithm Type to Average, and the Algorithm Interval Type to Days. You would also need to set the Algorithm Interval Size to 6.
  • Interval Size—Defines the start time of the period for which the algorithm is applied. For example, if you enter 4 and the Algorithm Interval Type is set to Days, the start time of the period is 4 days prior to the current resample interval on a Graph. The algorithm value is calculated based on the historic values reported between the current resample interval and 4 days prior to the current resample interval.

Example:

A new algorithm named 6Day is created. It has a description setting of '6 Day Average', its Algorithm Type is Average, and it has an Algorithm Interval Type of Days and an Algorithm Interval Size of 6.

An engineer configures a historic graph. It shows a trace that represents the historic values of a point. When the engineer edits the Advanced Source Configuration for the trace, a list of algorithms is available—the list includes the 6Days algorithm (algorithm).

The engineer sets the trace to use the 6Day algorithm. This means that the trace represents the average value for the point, with the average calculation using the values from 6 days prior to the current resample interval. This means that each time a new average value is plotted for the trace, the values that are used to calculate the average value are those historic values that were reported between the time the value is plotted (the resample) and 6 days prior to the resample. So if the average value is plotted at 12:00 on April 12th 2004, the calculation for the average value is based on the values reported between 12:00 on April 6th 2004 and 12:00 on April 12th 2004.

  9. Select the OK button to confirm the settings and close the window.
  10. Repeat steps 4-6 inclusive for each new historic algorithm.
  11. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Modify a Historic Algorithm

You can edit a historic algorithm so that it has different settings. You will need to make alterations if the settings for a historic algorithm are inappropriate for your requirements, for example, if the historic algorithm is calculated based on the historic values from a larger period of time than required.

To make alterations to a historic algorithm:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Database Configuration branch on the tree-structure.
  3. Select Historic Algorithms.
  4. In the list, right-click on the historic algorithm that you want to alter.
  5. Select the Modify option to display the Modify Algorithm window.
  6. Adjust the settings as required. The settings are exactly the same as those on the Add Algorithm window (see Add a Historic Algorithm).
  7. Select the OK button to confirm the settings and close the Modify Algorithm window.
  8. Close the ClearSCADA Server Configuration Tool to apply the changes (or select another branch if further server configuration is required).

Now that you have modified the historic algorithm you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.

Remove a Historic Algorithm

You can use the Historic Algorithms section of the ClearSCADA Server Configuration Tool to remove any unwanted custom algorithms.

To remove a historic algorithm:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Database Configuration branch on the tree-structure.
  3. Select Historic Algorithms.
  4. In the list, right-click on the historic algorithm that you want to alter.
  5. Select the Delete option.
  6. Close the ClearSCADA Server Configuration Tool to apply the changes (or select another branch if further server configuration is required).

Now that you have modified the historic algorithm you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.


Server Administration Guide - Historic Regions (Historic Configuration Settings)

Historic Regions

Historic data and events are usually deleted from the system after a defined period of time (typically, they are archived before they are deleted). When the historic data and event messages are deleted, they are no longer available on-line (users will need to mount an archive to access the historic/event data).

By using the Historic Regions feature, you can set ClearSCADA to retain historic data and events that were logged within a specific time period (called the Historic Region). ClearSCADA will not delete historic or event data that was logged within the time span of a defined Historic Region.

Any historic or event data that was logged within a Historic Region is retained on-line. This means it is available to view on Historic Trends, Historic Lists and the Events List without having to mount an archive volume.

The Historic Regions feature also provides a navigational aid when using Groups and Lists—you can quickly access values that were logged in a named period of time (the Historic Region).

You can use the Historic Regions section on the ClearSCADA Server Configuration Tool to:

  • Create a Named Historic Region.
  • Modify a Named Historic Region.
  • Remove a Named Historic Region.

NOTE: You need to enable Historic Data to make use of Historic Regions (see Enable or Disable Historic Data).

Further Information

Define the Archiving Settings.


Server Administration Guide - Create a Named Historic Region (Historic Configuration Settings)

Create a Named Historic Region

Each Historic Region defines a time period and is allocated a name. The historic data and event messages that were logged during the defined time period are available on-line and will not be deleted.

When defining a Historic Region, you need to specify:

  • Name—A name for the Historic Region. Each Historic Region requires a unique name.
  • Start Time—The start of the time period that is represented by the Historic Region. This includes the date and time.
  • Duration—The length of the time period represented by the Historic Region. This is a time entry defined in the OPC standard format.

To create a Named historic region:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Database Configuration branch.
  3. Select Historic Regions.
  4. Right-click on the background of the list of historic regions, then select the Add option to display the Add Historic Region window.
  5. In the Name field, enter a unique name for the Historic Region. We recommend that the name is meaningful, as operators will use it to identify the historic region on Graphs and Historic/Event lists.
  6. Use the Start Time combo box to define the date and time at which the historic region begins. Only data that was logged after the defined start time and date will be included in the Historic Region.
  7. In the Duration field, enter the amount of time to be represented by the Historic Region. The entry has to be in the OPC standard format, for example, 2H for 2 hours. (For more information on the OPC formats, see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).

The Historic Region will include historic and event data that was logged after the Start Time and before the end of the Duration. For example, if the Start Time is 6/26/02 11:00 and the Duration is 1H, the Historic Region will include historic/event data that was logged between 11:00 and 12:00 on 26th June 2002.

  8. Select the OK button to close the Add Historic Region window.
    The Historic Region is added to the list of Historic Regions on the Historic Regions section.
  9. Close the ClearSCADA Server Configuration Tool to apply the changes (or select another branch if further server configuration is required).

When the historic region settings are applied, users will be able to use the region for:

  • Displaying the data for a specific Historic Region on a Graph
  • Filtering Historic Lists
  • Filtering Event Lists

Now that you have created a historic region, you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.


Server Administration Guide - Modify a Named Historic Region (Historic Configuration Settings)

Modify a Named Historic Region

You can change the settings of an existing Historic Region so that it has a different:

  • Name
  • Start Time
  • Duration

This is especially useful when you need to increase or reduce the amount of historic data included in a Historic Region.

To edit an existing named Historic Region:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Database Configuration branch.
  3. Select Historic Regions.
  4. Right-click on the background of the list of historic regions, then select the Modify option to display the Modify Historic Region window.
  5. Use the Modify Historic Region window to adjust the settings as required. The settings are identical to those on the Add Historic Region window (see Create a Named Historic Region).
  6. Select the OK button to close the Modify Historic Region window and confirm the changes.
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have modified a historic region, you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.


Server Administration Guide - Remove a Named Historic Region (Historic Configuration Settings)

Remove a Named Historic Region

You can use the Historic Regions section to remove any unwanted Historic Regions.

When you remove a Historic Region, the historic/event data that was stored during the time specified by the Historic Region is available for deletion.

The historic/event data is deleted when the ClearSCADA server checks for expired historic data. This can be:

  • Every day at midnight (Coordinated Universal Time)
  • When the ClearSCADA server is started
  • When the Historic Data or Event Journal life is modified (see Define the Archiving Settings).

To remove a Historic Region:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the Database Configuration branch.
  3. Select Historic Regions.
  4. Right-click on the background of the list of historic regions, then select the Delete option.
  5. Close the ClearSCADA Server Configuration Tool to apply the changes (or select another branch if further server configuration is required).

Now that you have deleted a historic region, you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.


Server Administration Guide - SQL Query Configuration Settings

SQL Query Configuration Settings

The Server Configuration Tool has SQL Query Configuration settings that you can use to:

  • Create, modify and remove Historic Views. Historic Views allow applications to access historic data logged at uniform intervals.
  • Create, modify and remove Linked ODBC Tables. These are external tables that can be searched within SQL queries in ClearSCADA.
  • Define the maximum number of rows and the maximum amount of memory permitted for a single result set (see Use the Parameters Settings to Define the SQL Query Row and Size Limit). You may need to adjust these settings if you have SQL Queries that need to be run on a regular basis and return large result sets that exceed the default limits.


Server Administration Guide - Historic Views (SQL Query Configuration Settings)

Historic Views

The Historic Views feature allows you to perform SQL Queries on processed historic data. It works by allowing you to create a separate table for a specific set of processed historic data—by configuring a Historic View, you instruct ClearSCADA to create a database table that contains calculated values for a specified time period. These Historic View tables can then be queried in the same way as any other database table.

Each Historic View is a separate table in the database and represents a type of calculation and a time period. The time period is defined by the Default Start Time and Default Length settings, but these only apply if the SQL query that requests data from the Historic View does not include its own time specifications (see Default Start Time and Length for Historic Views).

For example, let’s assume that you want to use a Third Party application to query a point’s calculated Minimum values over a period of one month. To achieve this, you would need to configure a Historic View to represents at least 1 month and to use the Minimum algorithm. Then, in the Third Party application, you could create an SQL Query that references both the point for which you want data and the Historic View you have created. The query would also specify the time period for which you want data, in this case, a period of one month. The resultset of your query would contain the minimum values for the point over the month period (the start and end time of the month period would depend on the other time configuration settings of the Historic View and the times specified in your query).

Your query may only return the calculated Minimum values, as each Historic View represents a single type of calculation. If you wanted to query a different type of calculated value for the point, you would need to create another Historic View.

In the following sections, we explain how to create, configure, and remove a Historic View:

  • Create a Historic View.
  • Modify a Historic View.
  • Remove a Historic View
  • Access the Values for a Historic View.

NOTE: You need to enable Historic Data to make use of Historic Views (see Enable or Disable Historic Data).


Server Administration Guide - Create a Historic View (SQL Query Configuration Settings)

Create a Historic View

ClearSCADA includes several default Historic Views that can be used to provide applications with access to historic data. However, you may need to create new Historic Views that provide either or both of the following:

  • A different type of calculated historic value.
  • A historic value that has been calculated over a different period of time.

For example, you may need to create a Historic View that provides monthly average values.

To create a Historic View:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the SQL Query Configuration branch of the tree-structure.
  3. Select Historic Views.
  4. Right-click on the background of the historic views list, then select the Add option to display the Add Historic View window.
  5. Enter the name of the Historic View in the Name field. We recommend that the name indicates the time span and type of calculation, for example, HisDailyAverage.

NOTE: The Name can only consist of alphanumeric characters as this will be the name of a table in the database.

  6. Use the Algorithm combo box to select the type of calculation that is to be performed on the values in the historic resultset (see Algorithms for Historic Views).
  7. Select the check boxes for those reasons that are to be included in the calculation.

Each raw value that is logged has a reason for logging. The reason can be:

  • CDR—The value was reported during current data retrieval (CDR).
  • Value Change—The value was reported as it has changed from its previous value.
  • State Change—The value was reported as there has been a change of state.
  • Report—The value was reported as a report has been generated.
  • End of Period—The value was reported for the end of period.
  • End of Period Reset—The value was reported for the end of period. It indicates that the period has been reset so the next value is likely to be lower.
  • Override—The value was reported as it is an override value.
  • Release—The value was reported as an override has been released.
  • Modified—The value was reported as it is a modified value (changed manually by a user).

When you choose to include a reason, those raw values that have that reason are used in the calculation for the historic view. The values that have reasons that you exclude from the view are not included in the calculation.

  8. Enter a suitable time interval in the Calculation Base Time field (see Calculation Base Time for Historic Views). This determines whether the start time of the historic resultset is rounded down to a second, minute, hour, day, or week.
  9. Define how often the algorithm calculation is performed in the Resample Interval field (see Resample Interval for Historic Views).
  10. Define the start of the historic resultset in the Default Start Time field (see Default Start Time and Length for Historic Views).
  11. Define the duration of the historic resultset in the Default Length field (see Default Start Time and Length for Historic Views).
  12. Use the Timezone combo box to choose the appropriate time settings. You can choose from:
  • UTC—Uses Coordinated Universal Time. The times of the values will be the UTC times of the values as they were reported. No time conversion takes place.
  • Local Time (No DST)—Uses the local time settings of the client or server that is requesting the historic data. The time of the values as they were reported is converted into the appropriate time for the local machine but Daylight Saving Time is not taken into account.

This is the appropriate setting for systems that span areas that use the same time settings, such as mainland Europe.

  • Local Time (Use DST)— Uses the local time settings of the client or server that is requesting the historic data. The time of the values as they were reported is converted into the appropriate time for the local machine and Daylight Saving Time is taken into account.

This is the appropriate setting for systems that span areas that use different time settings, for example, this setting would be suitable for a system that had clients in northern, southern, eastern, and western states of the USA.

For more information on time zone settings, see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.

  13. Select the OK button.
    The Add Historic View window is closed, and the new Historic View is added to the list of Historic Views on the Historic Views section.
  14. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Algorithms for Historic Views (SQL Query Configuration Settings)

Algorithms for Historic Views

Each Historic View has an Algorithm setting that allows you to associate the Historic View with one or more historic algorithms (calculations that are used to produce the values for the Historic View). For example, a Historic View can be configured to have an Average historic algorithm and a Sum historic algorithm. In the table of results produced for the Historic View, there will be an Average column that contains the average values that have been calculated for the Historic View and a Sum column that contains the sum total values that have been calculated for the Historic View.

ClearSCADA supports many of the algorithms that are defined in the OPC Historic Data Access specification and you can also use your own ‘custom’ historic algorithms.

For information on the built-in historic algorithms, see Built-In Historic Algorithms for Processed Historic Data in the ClearSCADA Guide to Trends.

For information on custom historic algorithms, see Historic Algorithms (Custom).


Server Administration Guide - Calculation Base Time for Historic Views (SQL Query Configuration Settings)

Calculation Base Time for Historic Views

The Calculation Base Time makes the historic resultset have a start time that begins at the start of a whole time unit (day, hour etc.). This works in a similar way to an offset, except that it rounds the time down to the nearest whole time unit, for example, the start of a day (00:00).

With Calculation Base Time, only suitable historic resultsets are used to provide the value(s) that are read by ClearSCADA or a Third Party application.

The example (below) explains how the Calculation Base Time can be used as part of a Historic View.

Example:

A user needs to use a Third Party report application to obtain the average daily value of a point named ‘pValve’ for the previous week. The report will then be compared to similar reports for other points. To make the reports cover values for the same time spans, a Historic View is created to represent an average calculation for a 1 week period. The Historic View is named ‘HisWeeklyAverage’ and is configured to have the following settings:

  • Algorithm—Average.
  • Calculation Base Time—D. This means that the algorithm only includes values reported from the start of the first day in the defined historic resultset. The Calculation Base Time is applied irrespective of any start times that may be specified in the Third Party application’s SQL query.
  • Resample—1D. This means that the algorithm will be used to produce 1 value for each day in the historic resultset.
  • Default Start—D-1W. This defines the default start time of the historic resultset as 1 week prior to the current day. However, this is ignored if there is a start time defined in the SQL query.
  • Default Length—1W. This defines the duration of the historic resultset as being 1 week. However, this value is ignored if there is a length defined in the SQL query.

The Third Party application uses the following SQL Query to request the values from the ‘HisWeeklyAverage’ Historic View:

SELECT
CDBPoint."FullName",
HisWeeklyAverage."Value", HisWeeklyAverage."Time"

FROM
"CDBPoint" CDBPoint,
"HisWeeklyAverage" HisWeeklyAverage

WHERE
CDBPoint. "Id" =HisWeeklyAverage. "Id" AND
HisWeeklyAverage."Time" >={ts '2010-01-25 02:00:00'} AND
HisWeeklyAverage."Time" <={ts '2010-02-02 02:00:00'} AND
CDBPoint."FullName" = 'pValve'

As the SQL Query defines a start time and an end time (in the WHERE clause), the Default Start and Default End settings of the Historic View are not applied. This means that the query will return values from the period 2010-01-25 02:00:00 to 2010-02-02 02:00:00.

The Historic View’s Calculation Base Time of 1D means that the ClearSCADA performs its calculation (algorithm) using the raw values reported from the start of the first day to the end of the last day in sample. So the calculation is performed using the values reported in the period 2010-01-25 00:00:00 to 2010-02-02 00:00:00.

The Historic View’s Resample setting defines when the calculation is performed. In this case, the calculation is performed once every day.

So the resultset of the query contains the average value of the ‘pValve’ point at:

2010-01-26 00:00:00 (midnight after the start time defined in the query)

2010-01-27 00:00:00

2010-01-28 00:00:00

2010-01-29 00:00:00

2010-01-30 00:00:00

2010-01-31 00:00:00

2010-02-01 00:00:00

2010-02-01 00:00:00

2010-02-02 00:00:00

There is no value for 2010-02-03 00:00:00 as this is after the end time that is defined in the query.


Server Administration Guide - Resample Interval for Historic Views (SQL Query Configuration Settings)

Resample Interval for Historic Views

The Resample Interval defines how often ClearSCADA calculates the historic values for the historic view. The historic values are the values that are available to Third Party applications and SQL Queries.

The time at which the values are calculated is dependent on the Calculation Base Time for Historic Views—the value is calculated at the start of each hour, day, week etc. in the historic resultset.

The resample interval has to be a fixed time interval. This means you can enter a specific number of seconds, minutes, hours, or days. You cannot enter a month or a year as both of these are variable time intervals (a month can be between 28 and 31 days and a year can be 365 or 366 days).

Example:

The historic resultset covers the historic values of a point between 00:00 Monday and 00:00 Tuesday.

The Resample is 1H (hourly).

ClearSCADA calculates the value that is read by the Third Party application every hour (on the hour)— 00:00 Monday, 01:00 Monday, 02:00 Monday, 03:00 Monday etc.


Server Administration Guide - Default Start Time and Length for Historic Views (SQL Query Configuration Settings)

Default Start Time and Length for Historic Views

The Default Start Time defines the start time for the historic resultset, but is only used when there is no start time defined in the SQL Query. If the SQL Query includes a start time, the Default Start Time of the Historic View is ignored.

The Default Length for historic views defines the default duration of the historic resultset. For example, if the Default Length is 2D, the historic resultset begins at the start time defined in the SQL Query or by the Default Start Time setting and ends after 2 days. The Default Length setting is only used if an end time is not specified in the SQL Query.

You should use the OPC standard time formats when entering the Default Start Time and Default Length. For example, a Default Start Time of D-1W sets the default start time for the historic resultset as 1 week ago and a Default Length of 1W sets the duration of the historic resultset to 1 week.

Examples:

Example 1 - SQL Query includes Start Time and End Time Constraints

An SQL Query is to read the values calculated by ClearSCADA for a Historic View. The SQL Query specifies which points’ data is to be read and also specifies a time range for the historic resultset (a start time and an end time).

SELECT
T1.ID, T1.NAME, T1.FULLNAME, T2.SUMMARY, T2.VALUE, T2.RECORDTIME, T2.QUALITY, T2.QUALITYDESC
FROM
CDBPOINT AS T1 INNER JOIN AVEHIS AS T2 ON T1.ID = T2.ID
WHERE
( T1.FULLNAME = 'New Analog Point' ) AND T2.RECORDTIME BETWEEN { TS '2008-08-01 00:00:00.00' } AND { TS '2008-09-01 00:00:00.00' }

This SQL Query specifies start and end times that cover the month of August and is used with a Historic View that has the following configuration:

  • Name—AVEHIS
  • Algorithm—Average. This defines the type of calculation that is performed.
  • Reason Filter—Every reason enabled. This sets the Query to include the point’s historic records for the defined time range.
  • Calculation Base Time—H. This sets the start time to be the beginning of an hour unit.
  • Resample Interval—1H. This defines how often the algorithm value is calculated, in this case, every hour.
  • Default Start Time—This is ignored as the SQL Query specifies a start time.
  • Default Length—This is ignored as the SQL Query specifies an end time.
  • Timezone—UTC. This sets the Historic View to use Universal Co-ordinated Time (UTC)(see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration).

The Historic View is used to calculate the average hourly values for the point specified in the SQL Query. The time constraints included in the SQL Query are used to define the start time and end time for the historic resultset. This means that the resultset covers the month of August.

Example 2 - SQL Query includes Start Time Constraint Only

A Third Party application uses an SQL Query to read the values calculated by ClearSCADA for a Historic View. The SQL Query specifies which points’ data is to be read and also specifies a start time for the historic resultset. It does not specify an end time.

SELECT
T1.ID, T1.NAME, T1.FULLNAME, T2.SUMMARY, T2.VALUE, T2.RECORDTIME, T2.QUALITY, T2.QUALITYDESC
FROM
CDBPOINT AS T1 INNER JOIN AVEHIS AS T2 ON T1.ID = T2.ID
WHERE
( T1.FULLNAME = 'New Analog Point' ) AND T2.RECORDTIME >= { TS '2008-08-01 00:00:00.00' }

This SQL Query only specifies a start time: 2008-08-01 00:00:00.00. This means that the Default Length of the Historic View is used to determine the end time. The Historic View has the following configuration:

  • Name—AVEHIS
  • Algorithm—Average. This defines the type of calculation that is performed.
  • Reason Filter—Every reason enabled. This sets the Query to include the point’s historic records for the defined time range.
  • Calculation Base Time—H. This sets the start time to be the beginning of an hour unit.
  • Resample Interval—1H. This defines how often the algorithm value is calculated, in this case, every hour.
  • Default Start Time—D-1D. This is ignored as the SQL Query specifies a start time.
  • Default Length—1D. This sets the end time of the historic resultset to 1 day after the start time (which is specified as 2008-08-01 00:00:00.00 in the SQL Query).
  • Timezone—UTC. This sets the Historic View to use Universal Co-ordinated Time (UTC) (see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration).

The Historic View is used to calculate the average hourly values for the point specified in the SQL Query. As the SQL Query includes a start time constraint, the Default Start Time of the Historic View is ignored. However, the Default Length of the Historic View is used to determine the duration of the historic resultset as the SQL Query does not include an end time. So the SQL Query reads the resultset values from 2008-08-01 00:00:00.00 to 2008-08-02 00:00:00.00 (1 day after the specified start time).

Example 3 - SQL Query does not include Time Constraints

A Third Party application uses an SQL Query to read the values calculated by ClearSCADA for a Historic View. The SQL Query specifies which points’ data is to be read but does not specify a time range for the historic resultset (a start time and a length).

SELECT
T1.ID, T1.NAME, T1.FULLNAME, T2.SUMMARY, T2.VALUE, T2.RECORDTIME, T2.QUALITY, T2.QUALITYDESC
FROM
CDBPOINT AS T1 INNER JOIN AVEHIS AS T2 ON T1.ID = T2.ID
WHERE

( T1.FULLNAME = 'New Analog Point' )

This SQL Query does not include a start time or an end time. This means that the Default Start Time and Default Length settings of the Historic View are used to determine the time range for the historic resultset. The Historic View has the following configuration:

  • Name—AveHis
  • Algorithm—Average. This defines the type of calculation that is performed.
  • Reason Filter—Every reason enabled. This sets the Query to include the point’s historic records for the defined time range.
  • Calculation Base Time—H. This sets the start time to be the beginning of an hour unit.
  • Resample Interval—1H. This defines how often the algorithm value is calculated, in this case, every hour.
  • Default Start Time—D-1D. This sets the default start time for the historic resultset as 00:00 yesterday.
  • Default Length—1D. This sets the default duration of the historic resultset as 1 day.
  • Timezone—UTC. This sets the Historic View to use Universal Co-ordinated Time (UTC) (see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration).

The Historic View is used to calculate the average hourly values for the point specified in the SQL Query. As the SQL Query does not include any time constraints, the Default Start Time and Default Length settings of the Historic View are used. This means that the average time is calculated for the time period beginning at the start of yesterday (D-1D) and ending at the start of today (1D).


Server Administration Guide - Modify a Historic View (SQL Query Configuration Settings)

Modify a Historic View

You can edit an existing Historic View so that it:

  • has a different name
  • represents a different type of calculation
  • includes or excludes different values (uses a different reason filter)
  • represents a calculation that is performed less or more frequently.
  • covers a different time span
  • uses different time zone settings.

Editing a Historic View allows you to make amendments to a Historic View (for example, change a Historic View from calculating an average value to calculating a total value), or to use an existing Historic View's configuration as the basis of a new Historic View.

To edit an existing Historic View:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the SQL Query Configuration branch.
  3. Select Historic Views.
  4. Right-click on the Historic View that you want to edit from the list of historic views, then select the Modify option.
  5. Use the Modify Historic View window to alter the settings. The various fields and combo boxes work in the same way as the corresponding settings on the Add Historic View window.

ATTENTION: Any SQL queries that use the previous name of the Historic View will need to be updated with the new name, otherwise they will no longer operate.

  6. Select the OK button to close the Historic View Properties window.
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have modified a historic view, you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.


Server Administration Guide - Remove a Historic View (SQL Query Configuration Settings)

Remove a Historic View

You can remove any Historic Views that are no longer needed. But before you delete a Historic View, you should first check that the Historic View is not needed by internal or external applications.

To remove a Historic View:

  1. Access the ClearSCADA Server Configuration Tool (see Run the Server Status Tool).
  2. Expand the SQL Query Configuration branch.
  3. Select Historic Views.
  4. Right-click on the Historic View that you want to edit from the list of historic views, then select the Delete option.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have deleted a historic view, you can either proceed to configure other Historic settings (see Historic Configuration Settings) or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Point State Alarms.


Server Administration Guide - Access the Values for a Historic View (SQL Query Configuration Settings)

Access the Values for a Historic View

You can access the values that are produced by a Historic View’s algorithms by querying the table for the Historic View. To do this, you can use an SQL Query or a query from another application such as Crystal Reports. In your SQL Query, you will need to use the Summary field to define the result columns that you want to query. For example, if you wanted to query the top 10 results in the Average and Sum result columns of a Historic View for a point with the ID of 23338, you would define the SQL Query as:

SELECT TOP(10) * FROM HistoricView1 WHERE Summary='AVERAGE' OR Summary='Sum' AND ID=23338.

Where: HistoricView1 is the name of the Historic View you want to query (as defined when the Historic View was configured, see Create a Historic View).


Server Administration Guide - Linked ODBC Tables (SQL Query Configuration Settings)

Linked ODBC Tables

The Server Configuration Tool provides access to Linked ODBC Tables settings that allow you to link an external ODBC database to ClearSCADA. By linking tables with ClearSCADA, you can use ViewX or WebX to query external ODBC database tables in the same way that you query ClearSCADA tables.

You can access the Linked ODBC Tables settings by expanding the SQL Query Configuration branch and selecting Linked ODBC Tables.

In this section, we explain how to:

  • Create a Link between an External ODBC Database and ClearSCADA
  • Modify an ODBC Table Link
  • Delete an ODBC Table Link.


Server Administration Guide - Create a Link between an External ODBC Database and ClearSCADA (SQL Query Configuration Settings)

Create a Link between an External ODBC Database and ClearSCADA

You can link external ODBC databases with ClearSCADA so that the external databases can also be queried via ViewX or WebX. For example, you can link an SQL Server database to ClearSCADA, then edit the SQL for a Queries List so that it queries just the ClearSCADA database, just the external database, or both the ClearSCADA database and the external database simultaneously.

You can link one or more external ODBC databases to ClearSCADA by using the Server Configuration Tool’s Linked ODBC Tables settings. These are located in the SQL Query Configuration branch.

To link an external ODBC database with ClearSCADA, you need to

  1. Use Windows to configure your operating system to recognize the external database. To do this, you need to use the Data Sources settings that are available via the Control Panel. When configuring the Data Sources settings, you can define various settings for accessing the external table, including passwords and a name for the external table. For more information, please refer to the Microsoft documentation for using the Data Sources tool.
  2. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool)
  3. Expand the SQL Query Configuration branch.
  4. Select the Linked ODBC Tables branch to display the Linked ODBC Tables section.
  5. Right-click on the background of the Linked ODBC Tables section to display a context sensitive menu.
  6. Select the Add Linked ODBC Table option to display the Add Linked ODBC Table window.
  7. Use the Add Linked ODBC Table to configure the link to the external database as follows:
  • Table Name—The name that will be used to identify the external database in ClearSCADA. This can be any alphanumeric string of your choosing - it does not have to correspond to any other setting or name, but has to be unique. You should avoid using punctuation characters such as apostrophes in the table name.
  • Connection String—The connection string that allows ClearSCADA to identify and access the external data source. The connection string syntax varies for each driver, with some drivers providing additional connection functionality. For information on the appropriate connection string for your external database, please refer to the documentation provided by the manufacturer of your database product.

The Connection String you enter has to be appropriate for the type of external database and consistent with the settings you made via the Data Sources settings (see step 1 of this procedure).

  • User Name—Use to define the user name of a user account in the external database. This user account will be used by ClearSCADA to attempt to gain access to the external database, and so should have sufficient access permissions to the database tables.

The User Name entry is only needed if security authentication is required and the User Name has not been included in the Connection String.

NOTE: If a User Name and Password is required, you should only include the User Name and Password once. Either include the User Name and Password in the Connection String or enter them separately in the User Name and Password fields. If you define the User Name and Password more than once, ClearSCADA will notify you of an error in the string.

  • Password—Use to define the password for the user account (above). The Password is only needed if security authentication is required and the Password has not been included in the Connection String.
  • Source Catalog—Use to define the catalog element of the external database hierarchy (if required).

The ODBC standard allows databases to be structured in a three tier hierarchy, with the catalog being the upper level, the schema being the middle level, and the individual tables being the lower level. The way in which Third Party drivers use this hierarchy varies, so you should refer to the documentation for your external database application for more information on what is the appropriate Source Catalog entry. For some drivers, a Source Catalog entry may not be required.

  • Source Schema—Use to define the schema element of the external database hierarchy (if required). As with the Source Catalog setting, the Source Schema is used differently by different drivers. For this reason, you should refer to the documentation for your external database application for more information on what is the appropriate Source Schema for your configuration. For some drivers, a Source Schema entry may not be required.
  • Source Table—Use to define the external database table that is to be made available for use with queries in ClearSCADA. Enter the name of the database table you require.
  8. Select the OK button to confirm your selections and close the Add Linked ODBC Table window.
    A new ODBC link is created and is added to the list of ODBC links shown in the Linked ODBC Tables settings. If you right-click on the ODBC link, a context sensitive menu is displayed; you can use the menu to Modify an ODBC Table Link or Delete an ODBC Table Link.
  9. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Example: ClearSCADA Link to an SQL Server Database Table

In this example, ClearSCADA is to be linked to a table in an external SQL Server database. The table is named 'QualityDCC' and the external SQL Server is configured as ‘ARX’ in the Windows settings. For security, the external SQL Server database uses Windows user accounts. To allow other applications, including ClearSCADA, to access its tables, the SQL Server database is configured to provide access to users that log on via a Windows user account with the User Id: Administrator and Password: ClearAccess.

The external database has a catalog named Build and uses the default schema for SQL Server which is dbo.

To begin with, a user logs on to the ClearSCADA server PC and accesses the Data Sources (ODBC) settings in Windows. Using the System DSN settings, the user creates a new data source of the type SQL Server. The Name of the data source is defined as ‘QualityDCC’, and the Server is set to the SQL server that stores the ‘QualityDCC’ database table. Next, the data source is set to use Windows authentication, and no other changes are made to the default Data Source configuration.

The user then accesses the Server Configuration Tool and navigates to the Linked ODBC Tables settings. They right-click on an empty part of the background of the Linked ODBC Tables settings and then select the Add Linked ODBC Table option from the context sensitive menu. This displays the Add Linked ODBC Table window, and the following settings are entered:

  • Table Name—ExternalQuality
  • Connection String—Driver=SQL Server; Server=ARX;
  • User Name—Administrator
  • Password—ClearAccess
  • Source Catalog—Build
  • Source Schema—dbo
  • Source Table—QualityDCC

The Table Name does not have to match the actual name of the external table - the Table Name is just the name that will be used for the external table in ClearSCADA.

The user selects the OK button to confirm the selections, then applies the changes to the server by right-clicking on the system and selecting Apply Changes.

The user then runs ViewX on the ClearSCADA server. They log on and display an Objects queries list with no filters. Next, they select the View menu, then the SQL option to display the SQL Query for the List. By default, the SQL Query is set to display data from the CDBObject table which is a table in the ClearSCADA database.

The user edits the SQL Query so that it states FROM CDBOBJECT JOIN QualityDCC USING (Id) then selects OK. This sets the SQL Query to take information from the CDBOBJECT table in ClearSCADA and also from the QualityDCC table in the external SQL Query database.

The Object List now shows the objects in the ClearSCADA database and the objects in the QualityDCC database table.


Server Administration Guide - Modify an ODBC Table Link (SQL Query Configuration Settings)

Modify an ODBC Table Link

If you need to change the configuration of an existing ODBC Table Link:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool)
  2. Expand the SQL Query Configuration branch.
  3. Select the Linked ODBC Tables branch to display the Linked ODBC Tables section.
  4. Right-click on the link that you want to edit, then select Modify from the context sensitive menu.
    The Modify Linked ODBC Table window is displayed.
  5. Use the settings on the Modify Linked ODBC Table window to change the configuration of the link. The settings work in exactly the same way as the corresponding settings on the Add Linked ODBC Table window (see Create a Link between an External ODBC Database and ClearSCADA)
  6. Select the OK button to confirm your selections and close the Add Linked ODBC Table window.
    The new linked table configuration is now in place.
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Delete an ODBC Table Link (SQL Query Configuration Settings)

Delete an ODBC Table Link

If you need to remove an existing ODBC Table Link:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool)
  2. Expand the SQL Query Configuration branch.
  3. Select the Linked ODBC Tables branch to display the Linked ODBC Tables section.
  4. Right-click on the link that you want to remove, then select Delete from the context sensitive menu.
    The Linked ODBC Table window is deleted.

As an alternative to step 4, you can select the table link that you want to remove, then press the Delete key.


Server Administration Guide - Use the Parameters Settings to Define the SQL Query Row and Size Limit (SQL Query Configuration Settings)

Use the Parameters Settings to Define the SQL Query Row and Size Limit

If you have SQL Queries that need to be executed on a regular basis and return result sets that exceed the SQL Query row and size limits, you have two options:

  • Use several SQL Queries that return smaller result sets. This is an effective solution but may be unsuitable for your requirements.
  • Change the SQL Query Row Limit and Size Limit. By changing the limits, you allow SQL Queries to return result sets that contain a larger number of rows and take up more memory. However, while increasing the limits may allow you to return larger SQL Queries, it may also have a negative impact on system performance. For this reason, you should only change the row and size limits if you are certain that you cannot achieve satisfactory results by using multiple SQL Queries.

If you need to change the SQL Query Row and Size limits, you should:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool)
  2. Expand the SQL Query Configuration branch.
  3. Select the Parameters branch to display the Parameters section.
  4. Use the Query Row Limit field to define the maximum number of rows that can be returned in the result set for a single SQL Query. The default amount is 1000000.

If you increase the Query Row Limit, you should also increase the Query Size Limit by a corresponding amount. You should maintain to maintain the ratio of these settings, for example, if you increase the Query Row Limit by 300% to 3000000, you should also increase the Query Size Limit by 300% to 150.

ATTENTION: Increasing the Query Row Limit may affect performance.

  5. Use the Query Size Limit field to define the maximum size, in megabytes, that can be used to store the result set of a single SQL Query. The default amount is 50mb.
  6. Usually, you will only need to increase the Query Size Limit if you have also increased the Query Row Limit (the Query Size Limit needs to be increased by the same percentage amount as the Query Row Limit, as mentioned in step 4).
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Point State Alarms

Point State Alarms

You can use the Point State Alarms feature to create alarm states that are not affected by other alarm states. This is useful as it allows you to create complex alarm response and clearing mechanisms. For example, by using the Point State Alarms feature, you can set up a point so that if it has a High alarm and then has a High High alarm, the High High alarm does not clear the High alarm—the two different alarm states are raised separately and have no affect on each other. If the Point State Alarms feature is not used, the High High alarm would replace the High alarm (a point can only have one alarm if the Point State Alarms feature is not used).

If you want to make use of the Point State Alarms feature, you need to use the ClearSCADA Server Configuration Tool to:

  • Define the number of point state alarms that are available for each type of point
  • Define a name for each point state alarm.

When you have defined the number and names for the point state alarms on the ClearSCADA Server Configuration Tool, an extra column is added to the Point Form for the relevant points. Users with the Configure permission can use the extra column of combo boxes to define which alarm is used for each of the point's states (except the Normal state). By doing this, it is possible to configure a pattern of alarms such as nested alarms.

Example:

A company want to have 2 separate teams of engineers to respond to different levels of alarms. High and Low alarms are to be responded to by the Alert team and an Emergency team will respond to any other alarms (Full Scale, High High, Low Low, and Zero Scale).

If the Point Alarm State feature is not used, a High or Low alarm for a point will be replaced automatically as soon as the point has a Full Scale, High High, Low Low, or Zero Scale alarm. This means there will be no alarm for the alert team to respond to for the point (as the Full Scale, High High, Low Low, or Zero Scale alarm will replace the High or Low alarm and will be dealt with by the Emergency team). Similarly, if the point's alarm state changes from Normal to High High, only 1 High High alarm will be raised. If the Point Alarm State feature is used, a High alarm and a High High alarm are raised if the point's alarm state changes from Normal to High High.

By using the Point Alarm State feature, the Full Scale, High High, Low Low, and Zero Scale alarms can be set to have no effect on High and Low alarms. This means that the Alert team can respond to the High and Low alarms without them being replaced on the system if there is a Full Scale, High High, Low Low, or Zero Scale alarm.

The ClearSCADA Server Configuration tool is used to create 2 point state alarms:

  • Emergency
  • Alert

The point state alarms are created for the CSCADAPackMAnalog table.

The ClearSCADA Server Configuration Tool is closed, the settings are applied, and the server is restarted. The state alarms are then setup on the other servers in the system.

In ViewX, the Form for a SCADAPack Modbus analog point is displayed. The Form has an extra column of combo boxes—the Alarm column. The combo boxes in the Alarm column contain 2 options: Emergency and Alert.

The Alarm combo boxes for the Full Scale, High High, Low Low, and Zero Scale alarms are set to Emergency. The Emergency team will respond to these alarms. The alarms will not affect the High and Low alarms.

The Alarm combo boxes for the High and Low alarms are set to Alert. The Alert team will respond to these alarms.

A High alarm is raised for the point. The Alert team investigate the cause of the alarm.

While the Alert team is investigating the High alarm, a High High alarm is raised for the point. The High High alarm is treated as a separate alarm and it is dealt with by the Emergency team—the High High alarm does not replace the High alarm on the system.

In the following sections, we explain how to add and remove point alarm states:

  • Adding a Point Alarm State
  • Removing a Point State Alarm.


Server Administration Guide - Adding a Point Alarm State (Point State Alarms)

Adding a Point Alarm State

To create a point alarm state:

  1. Display the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select the Point State Alarms branch.
  4. In the Point State Alarms section, double-click on the Table entry for the relevant type of point table. Each table represents a type of database point. There are descriptions for each table—use the description to determine which table is used for the type of point that is to use the point state alarms.

When you double-click on a table, the Point State Alarm Conditions window is displayed.

  5. Select the Multiple Alarms check box to enable the point state alarms feature for the selected type of points.
  6. Select the Add button to add a new point state alarm name to the list. It is selected automatically, ready for you to define its name.
  7. Enter a suitable name for the point state alarm. Remember that engineers will need to associate an alarm state with the point state alarm on the Point Form—the name that you enter should indicate the purpose of the alarm.
  8. Press the Enter key or select another part of the interface to confirm the selection.
  9. Repeat steps 6 to 8 inclusive for each point state alarm for the selected type of points.
  10. Select the OK button to confirm the selection and close the Point State Alarm Conditions window.
  11. Repeat this procedure for each point state alarm that you want to add.


Server Administration Guide - Removing a Point State Alarm (Point State Alarms)

Removing a Point State Alarm

If you want to delete a point state alarm:

  1. Display the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select the Point State Alarms branch.
  4. In the Point State Alarms section, double-click on the Table entry for the relevant type of point table. Each table represents a type of database point. There are descriptions for each table—use the description to determine which table is used for the type of point that is to use the point state alarms.

When you double-click on a table, the Point State Alarm Conditions window is displayed.

  5. Select the name of the point state alarm that you want to remove.
  6. Select the Remove button.
  7. Repeat steps 4 to 6 inclusive for each point state alarm for the selected type of points.
  8. Select the OK button to confirm the selection and close the Point State Alarm Conditions window.
  9. Repeat this procedure for each point state alarm that you want to remove.


Server Administration Guide - Point Quality Classifications

Point Quality Classifications

You can use the Quality Classifications feature to create point quality classifications. Each point in the database can be associated with one of the quality classifications that you create (by using the Quality Classification method for the point).

Usually, point quality classifications are used to indicate the reason for a point's data being of poor quality. For example, if a point is reporting bad quality data due to a failed component, the point could be associated with a 'Failed Plant' quality classification.

Example:

The Quality Classifications feature is used to add a 'Maintenance' classification.

During site maintenance, some points are associated with the 'Maintenance' classification. These points' values will be affected by the maintenance work. The points that are not affected by the maintenance work are not associated with the quality classification.

As the maintenance takes place, some points report values that are 'Bad' quality. By viewing the Quality Classification on the Mimics, the operators can determine which points are reporting values that are affected by maintenance work (and so are expected to report 'Bad' quality data temporarily), and which points are reporting values that relate to specific conditions at site.

This section explains how to:

  • Enable or Disable Point Quality Classifications
  • Add a Quality Classification
  • Remove a Quality Classification
  • Modify a Quality Classification.

When you have created a quality classification, the Quality Classification pick action becomes available for points. You can use this pick action to associate a point with one of the quality classifications you have created in the server configuration. When you have associated a point with a quality classification, the quality classification value for the point can be seen in the point’s Status display (View dialog) and added to Mimics etc.

You can use the Database Schema to find more information about the Quality Classification method (see Working with the Database Schema in the ClearSCADA Guide to the Database).


Server Administration Guide - Enable or Disable Point Quality Classifications (Point Quality Classifications)

Enable or Disable Point Quality Classifications

You can use the ClearSCADA Server Configuration Tool to define whether the Quality Classifications feature is enabled or disabled. You can only set a quality classification for a point if the Quality Classifications feature is enabled.

To enable or disable the Quality Classifications feature:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch.
  3. Select Quality Classifications.
  4. Right-click on the background of the quality classifications list display to access a context sensitive menu. The list will be empty if point quality classifications have not been set up on your system.
  5. Either:
  • Select the Enabled option to enable the Quality Classifications feature. A check mark is shown next to the option when the feature is enabled.
  • Deselect the Enabled option to disable the Quality Classifications feature.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have enabled or disabled the quality classifications feature, you can either proceed to configure quality classifications or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Alarm and Event Severities


Server Administration Guide - Add a Quality Classification (Point Quality Classifications)

Add a Quality Classification

You can use the ClearSCADA Server Configuration Tool to add up to 32 point quality classifications. When you have applied the point quality classifications to the database, users can associate them with the database points.

To add a quality classification and check that it is available for the database points:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch of the tree-structure.
  3. Select Quality Classifications.
  4. Right click on the background of the quality classifications list, then select the Add Quality Classification option from the context sensitive menu.
    A new quality classification is added to the list. It is selected automatically, ready for you to enter its name.
  5. Enter a description of the quality classification. Typically, the description will indicate a reason for an item being in a specific state, for example, you could name a quality classification 'Maintenance' and associate items with the 'Maintenance' quality when they are being repaired etc.
  6. Repeat steps 4 and 5 for each quality classification that you want to add.
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Users with Control permissions for points, can now use the Quality Classification pick action to associate a point with one of the quality classifications created in the server configuration. The quality classification value for the point can be seen in the point’s Status display (View dialog) and added to Mimics etc. For more information on permissions, see Permissions for Database Items in the ClearSCADA Guide to Security.

Now that you have added one or more quality classifications, you can either proceed to modify or remove quality classifications or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Alarm and Event Severities.


Server Administration Guide - Remove a Quality Classification (Point Quality Classifications)

Remove a Quality Classification

You can use the ClearSCADA Server Configuration Tool to remove any redundant quality classifications.

To remove quality classifications:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch of the tree-structure.
  3. Select Quality Classifications.
  4. Right-click on the quality classification that you want to remove.
  5. Select the Remove option from the context sensitive menu.
    The quality description is removed from the list.
  6. Repeat steps 4 and 5 until you have removed the unnecessary quality classifications.
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have added one or more quality classifications, you can either proceed to modify quality classifications or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Alarm and Event Severities.


Server Administration Guide - Modify a Quality Classification (Point Quality Classifications)

Modify a Quality Classification

You can use the ClearSCADA Server Configuration Tool to change a quality classification.

To modify a quality classification:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch of the tree-structure.
  3. Select Quality Classifications.
  4. Right-click on the quality classification that you want to change.
  5. Select the Modify option from the context sensitive menu.
    The quality description is selected so that you can alter its name.
  6. Type in the amendments to the point quality classification, then press the Enter key or select another part of the interface.
  7. Repeat steps 4 and 5 until you have modified those quality classifications that need to be changed.
  8. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have modified one or more quality classifications, you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Alarm and Event Severities.


Server Administration Guide - Alarm and Event Severities

Alarm and Event Severities

In ClearSCADA, alarms and events are associated with a specific severity level (sometimes referred to as a priority). The severity level usually indicates the importance of the alarm.

The default severities are Critical, High, Medium, and Low. These form a range—Critical alarms are usually regarded as the most important and Low alarms are the least important. You can change the names of these severity ranges if required.

The default severity range meets the OPC Alarm and Events standard, with a range from 1-1000:

1000 is Critical.
667-999 is High.
334-666 is Medium.
1-333 is Low.
0 is used to indicate no severity and is an extension defined by Schneider Electric. It is not part of the OPC standard.

You can change the severity range to suit the requirements of your system, for example, you can add new severities so that the entire range is divided into more than 5 severity ranges.

NOTE: The Severity settings have to be identical on both servers in a hot-standby system and identical on the 3 servers in a triple-standby system. The Severity settings also have to be identical on the 3 servers in a hot-standby pair with permanent standby system.

Further Information

OPC Foundation Standards: See www.opcfoundation.org

This section explains how to:

  1. Add a Severity Range
  2. Edit a Severity Range
  3. Remove a Severity Range.

The severities that you define are available for selection when configuring alarm and event ranges for points.


Server Administration Guide - Add a Severity Range (Alarm and Event Severities)

Add a Severity Range

You can use the ClearSCADA Server Configuration Tool to add a severity range. This is necessary when you need to create your own range of severities as the default severities are inappropriate for your requirments.

When you add a new severity, the range of the existing severities is altered to accommodate the new severity. Any alarms and/or events on your system are updated in accordance with the new range.

NOTE: The Severity settings have to be identical on both servers in a hot-standby system and identical on each of the 3 servers in a triple-standby system. They also need to be identical on each of the 3 servers in a hot-standby pair with permanent standby system.

To add a severity range:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch of the tree structure.
  3. Select Severities.
    The Severities section is shown.
  4. Right click on the background of the severities list to display a context sensitive menu, then select the Add Severity option.
    The Add Severity window is displayed.
  5. Use the Priority spin box to define the lowest value that is to be included in the severity range (see Define the Priority and Description for a Severity)
  6. Enter brief information about the severity range in the Description field (see Define the Priority and Description for a Severity).
  7. Use the Sound field to Associate a WAV Sound File with a Severity Range.
  8. Use the Colors section to define the colors that are used for the foreground of alarms in this severity. The foreground colors are applied on a variety of alarm displays such as the Alarms List and Alarm Banner (see Define the Foreground Colors for a Severity).
  9. Use the Background Colors section to define the colors that are used for the background of alarms in this severity. The background colors are applied on a variety of alarm displays such as the Alarms List and Alarm Banner (see Define the Background Colors for a Severity).
  10. Use the Alarm Analysis section to define the amount of time permitted between alarms in this severity range being raised and received, received and acknowledged, and received and cleared (see Define the Alarm Analysis Periods for a Severity)
  11. Use the Allowed User Actions section to define which alarm pick actions are available for the alarms in this severity range (see Define the Allowed Actions for a Severity).
  12. When you have defined the various settings for the severity, you can select the OK button to close the Add Severity window or the Modify Severity window. To apply the changes you have made, you will need to right-click on the system in the Server Status Tool, then select the Apply Changes option from the context sensitive menu.

Further Information

Edit a Severity Range

Remove a Severity Range.


Server Administration Guide - Define the Priority and Description for a Severity (Alarm and Event Severities)

Define the Priority and Description for a Severity

When you add or edit a severity, you can set a Priority and enter a Description. The Priority setting defines the lowest value that is to be included in the severity range, and usually, the Description is used to indicate the importance of the alarms and events that are in the severity range (but it is possible to enter any text of up to 31 characters).

To define the Priority and Description:

  1. Display the Add Severity window (see Add a Severity Range) or the Modify Severity window as appropriate (see Edit a Severity Range).
  2. Use the Priority spin box to define the lowest value that is to be included in the severity range. The severity range will begin at this number and will end at the number prior to that of the next highest severity.

The number that you enter has to be in the range 1-1000 and cannot be the same as any existing severity range.

For example, if you are using the default severity ranges and add a severity with a Priority of 100, the severity you have created will have a range that begins at 100 and ends at 333 (the value before the start of the Medium severity range, which is 334). The 'Low' severity range will now run from 1-99 and not 1-333. (For information on the default ranges, refer to the introduction of Alarm and Event Severities.

  3. Enter a description of the severity range in the Description field. The description usually indicates the importance of the alarms and events that are within the severity range, but can be any text of up to 31 characters.

The Description is shown on many displays, including the Alarm Banner and Alarm List.

When you have defined the Priority and/or Description, you can select the OK button to close the Add Severity window or the Modify Severity window. To apply the changes you have made, you will need to right-click on the system in the Server Status Tool, then select the Apply Changes option from the context sensitive menu.

Alternatively, you can use the Add Severity window or the Modify Severity window to define or change more severity configuration settings (see Add a Severity Range or see Edit a Severity Range).


Server Administration Guide - Associate a WAV Sound File with a Severity Range (Alarm and Event Severities)

Associate a WAV Sound File with a Severity Range

You can use the ClearSCADA Server Configuration Tool to associate a WAV sound file with any of the severity ranges. The sound file that you choose will be used instead of the default alarm bell sound when an alarm (of the relevant severity) is raised. This allows you to setup different sounds for each severity range so that operators can identify the severity of a new alarm by the type of sound that accompanies the alarm. For example, if you associate a WAV file named Siren.WAV with the highest severity range (Critical), then any critical alarm that is raised will be accompanied by the Siren.WAV sound rather than the standard Alarm Bell sound.

NOTE: The sound files can only be heard if the audible Alarm Bell is activated on the Alarm Banner.

To associate a WAV file with a severity range:

  1. Display the Add Severity window (see Add a Severity Range) or the Modify Severity window as appropriate (see Edit a Severity Range)
  2. Use the Select button feature of the Sound field to select the WAV file that you want to associate with the severity. The sound file will be used as the alarm bell sound for alarms of the selected severity.
  3. Select the OK button to confirm your choice and close the browse window.
  4. Select the OK button to confirm your selection and close the Modify Severity window or Add Severity window.
  5. Repeat steps 1-4 inclusive for each severity range as required.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Once the changes have been implemented, the sound files will be used whenever an alarm of the appropriate severity is raised.

Now that you have associated a severity with a sound file, you can either proceed to configure other severities or you can continue with the server configuration.


Server Administration Guide - Define the Foreground Colors for a Severity (Alarm and Event Severities)

Define the Foreground Colors for a Severity

When you add or modify a severity, you can define the color settings that are used for alarms that fall within the range for that severity. The color settings are applied on various displays, including the Alarms List and Alarms Banner.

There are two groups of color settings:

  • Colors (for foreground colors)
  • Background Colors

In this section, we explain how to set the foreground Colors. For information on setting the Background Colors, see Define the Background Colors for a Severity.

To define the foreground colors settings for a severity:

  1. Display the Add Severity window (see Add a Severity Range) or the Modify Severity window as appropriate (see Edit a Severity Range)
  2. Use the Colors settings to define the alarm state colors for alarms that are in the severity range. The colors you choose are used on various alarm displays, including the Alarm List, Alarm Banner, Mimics, Lists etc.

The colors that you define on the Severity Properties window are the alarm state color settings, and they are used on various alarm displays, including the Alarm Banner, Alarms List, Mimics, Lists etc.,. Any items that are in an alarm state will have their values displayed in the relevant alarm state color. (The colors that are associated with the other, non-alarm states of items only apply if the item is not in alarm).

  1. Choose which alarm state colors you want to change. The alarm states are:
  • Alarm List Unacknowledged—The color that is used to indicate unacknowledged alarms (within the selected severity range) on the Alarm List and Alarm Banner.
  • Alarm List Cleared—The color that is used to indicate cleared alarms (within the selected severity range) on the Alarm List and Alarm Banner.
  • Alarm List Acknowledged—The color that is used to indicate acknowledged alarms (within the selected severity range) on the Alarm List and Alarm Banner.
  • Object Unacknowledged—The color that is used to indicate unacknowledged alarms (within the selected severity range) on Mimics and Lists.
  • Object Cleared—The color that is used to indicate cleared alarms (within the selected severity range) on Mimics and Lists.
  • Object Acknowledged—The color that is used to indicate acknowledged alarms (within the selected severity range) on Mimics and Lists.
  • Object Acknowledged with Comment—The color that is used to indicate acknowledged alarms that have a comment (within the selected severity range) on Mimics and Lists.
  2. Use the Color button next to each alarm state to choose a foreground color from the color palette or to create a custom color see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration.
  3. Define whether the color is to flash on and off:
  • Select the Flash check box to enable color flashes on relevant alarm displays.
  • Clear the Flash check box to disable color flashes on the relevant alarm. The color will be static (will not flash).
  4. Define whether the alternative flash color is used:
  • Select the Alt Flash Color check box to allow the alternate color for the flash effect to be changed from white.
  • Clear the Alt Flash Color check box to set the alternate flash color to white.

If you selected the Alt Flash Color check box, use the adjacent color button to choose the alternate color. When you apply the changes, the alternative color will be used instead of white in a flashing effect. For example, if red is used for an Object Unacknowledged alarm state, the flash effect is enabled, and the Alt Flash Color is set to orange, the alarm messages etc. for the alarm will flash between red and orange.

If you did not select the Alt Flash Color check box, any flashing effects for the selected alarm state will use white as the alternative color. For example, If the Alt Flash Color check box is clear, the alarm messages etc. for the selected alarm state will flash between red and white.

NOTE: The Alt Flash Color feature is only available for the Alarm List Unacknowledged, Alarm List Cleared and Alarm List Acknowledged alarm states.

When you have defined the foreground Colors settings, you can select the OK button to close the Add Severity window or the Modify Severity window. To apply the changes you have made, you will need to right-click on the system in the Server Status Tool, then select the Apply Changes option from the context sensitive menu.

Alternatively, you can use the Add Severity window or the Modify Severity window to define or change more severity configuration settings (see Add a Severity Range or see Edit a Severity Range).


Server Administration Guide - Define the Background Colors for a Severity (Alarm and Event Severities)

Define the Background Colors for a Severity

When you add or modify an alarm severity, you can make changes to the Background Colors settings for that severity. The Background Colors settings allow you to:

  • Choose the method of coloring that is applied to alarms in the severity range, when those alarms are selected in the Alarm Banner or Alarms List
  • Define whether unacknowledged alarms in the severity range have a set background color when an alarm is selected
  • Define whether alarms in the severity range have a set background color when they have an alarm response message.

These settings are useful as they allow you to implement a standard color scheme for the background on alarm displays.

To define or change the Background Colors settings for an alarm severity:

  1. Display the Add Severity window (see Add a Severity Range) or display the Modify Severity window (see Edit a Severity Range).
  2. On the Add Severity window or Modify Severity window, scroll down to the Background Colors section.
  3. Use the Alarm Selected setting to define what color change effect is applied to indicate an alarm (in the range for this severity) is currently selected. There are two options available:
  • Swap Colors—This is the default setting. It works by swapping the foreground color with the background color when an alarm is selected on the Alarms List. Alarm Banner etc.,. For example, if the default color settings are in place and you select an alarm (in the range for this severity) on the Alarm Banner, the foreground color will swap with the background color. So the text for the selected alarm will change from red to gray and the background of the alarm will change from gray to red.
  • Set Background Color—If you choose the Set Background Color setting, you can select a specific color to be used for the background of a selected alarm. When you choose Set Background Color, a color button to the right of the combo box becomes available and you can use it to select a color from the color palette or create your own custom color see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration. When an alarm that is in the range for this severity is selected on the Alarm Banner or Alarms List, the background of the selected row will change color to the color you have defined.
    Alarm Banner showing a selected alarm. The selected alarm is associated with a severity range that has its background color set to magenta.

  4. Use the Alarm Can Acknowledge setting to set the background color for any alarms that have not yet been acknowledged (in the range for this severity).

By using the Alarm Can Acknowledge setting, you can set the background color of alarms that are in the range for this severity and have not already been acknowledged. This makes it easier for users to identify those alarms that they can acknowledge.

To choose a color for unacknowledged alarms (in the range for this severity), select the Background check box next to the Alarm Can Acknowledge text. This enables a background color for unacknowledged alarms. When you have selected the Background check box, you can use the adjacent Color button to choose a background color from the color palette or to create a custom color see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration. The Color button is only available if you have selected the Background check box.

If you do not select the Background check box, any unacknowledged alarms for this severity will not use a background color; the background of the alarms will be the same color as the background of the Alarm List or Alarm Banner.

The Alarm Can Acknowledge color is only applied for the severity you are configuring and is only shown if the alarm has not already been acknowledged. If the alarm has not been acknowledged and is currently selected, the Alarm Selected setting takes precedence, and so the background color may be different to the color you have selected for the Alarm Can Acknowledge setting. For more information, see Precedence for the Severity Background Colors.

  5. Use the Alarm Response Present—setting to define a background color for any alarms (in the range for the severity) with alarm responses.

Alarms can have alarm responses - short text strings that have been associated with the alarm, either by yourself or by another user. By using the Alarm Response Present setting, you can set the background color of alarms with responses (in the range for this severity). This makes it easier for users to identify those alarms that have response messages.

To choose a color for alarms that have responses (in the range for this severity), select the Background check box next to the Alarm Response Present text. This enables a background color for alarms with responses. When you have selected the Background check box, you can use the adjacent Color button to choose a background color from the color palette or to create a custom color see Using the Color Window to Define a Color in the ClearSCADA Guide to Core Configuration. The Color button is only available if you have selected the Background check box.

If you do not select the Background check box, any alarms with responses for this severity will not use a background color; the background of the alarms will be the same color as the background of the Alarm List or Alarm Banner.

The Alarm Response Present color is only applied for the severity you are configuring and is only shown if the alarm is not currently selected and has already been acknowledged. For more information, see Precedence for the Severity Background Colors.

When you have defined the Background Colors settings, you can select the OK button to close the Add Severity window or the Modify Severity window. To apply the changes you have made, you will need to right-click on the system in the Server Status Tool, then select the Apply Changes option from the context sensitive menu.

Alternatively, you can use the Add Severity window or the Modify Severity window to define or change more severity configuration settings (see Add a Severity Range or see Edit a Severity Range).

Precedence for the Severity Background Colors

There are three settings that you can use to define the background color for alarms that are in the range of a severity. The three settings, listed here in order of precedence, are:

  1. Alarm Selected. This is deemed as the most important setting and it takes priority over the Alarm Can Acknowledge and Alarm Response Present settings. So, if an alarm in the severity range is currently selected, the Alarm Selected background color is used, even if the alarm has not been acknowledged or has an alarm response.
  2. Alarm Can Acknowledge. The background color that you define for the Alarm Can Acknowledge setting is used when an alarm has not already been acknowledged and is not currently selected. If an unacknowledged alarm is currently selected, the background will be the color defined for the Alarm Selected setting (as the Alarm Selected setting takes precedence over the Alarm Can Acknowledge setting). However, the Alarm Can Acknowledge background color is used in precedence over the Alarm Response Present background color.
  3. Alarm Response Present. The background color that you define for the Alarm Response Present setting is only used when an alarm has a response message associated with it, is not currently selected and has already been acknowledged. This is because both the Alarm Selected and Alarm Can Acknowledge background colors are used in precedence over the Alarm Response Present setting.

So, if an alarm in the severity range is currently selected, the background color of the alarm will match that defined in the Alarm Selected setting (even if the alarm has not been acknowledged and/or has a response message).

If an alarm in the severity range is not currently selected, has not been acknowledged and has an alarm response message, the background color for the Alarm Can Acknowledge setting is used. The Alarm Response Present color is not used as the Alarm Can Acknowledge setting takes precedence.

If an alarm in the severity range is not currently selected, has been acknowledged, and has an alarm response message, the background color of the alarm matches that chosen for the Alarm Response Present setting.

Example:

An alarm is currently selected and it is unacknowledged and has an alarm response. The alarm is in a severity range that has been configured to have an Alarm Selected color of blue, Alarm Can Acknowledge color of orange, and an Alarm Response Present color of magenta.

A user selects the alarm. The background color for the alarm changes to blue because the alarm is currently selected and the Alarm Selected color takes precedence over the Alarm Can Acknowledge and Alarm Response Present colors.

The user selects a different alarm. The background color of the alarm the user selected originally changes from blue to orange. This is because the alarm is no longer selected and so the Alarm Can Acknowledge color does not apply. As the alarm has not been acknowledged, the alarm’s background is orange - the color defined for the Alarm Can Acknowledge setting.

The user accesses the Response action for the alarm and enters a comment. This means that the alarm now has a user response (and so the Alarm Response Present color can be applied).

The background color of the alarm remains orange, even though the alarm has a user response. This is because the alarm has not been acknowledged and the Alarm can Acknowledge color takes precedence over the Alarm Response Present color.

The user acknowledges the alarm. This means that the Alarm Can Acknowledge color can no longer be applied (as users cannot acknowledge an alarm that has already been acknowledged). As the alarm has a response comment, cannot be acknowledged and is not selected, the Alarm Response Present color is applied. The background of the alarm is magenta.)


Server Administration Guide - Define the Alarm Analysis Periods for a Severity (Alarm and Event Severities)

Define the Alarm Analysis Periods for a Severity

When you add or modify an alarm severity, you can make changes to the Alarm Analysis settings for that severity. The Alarm Analysis settings define the amount of time permitted for alarms in the severity range to be:

  • Received
  • Responded to
  • Cleared.

To change the Alarm Analysis settings for a severity:

  1. Display the Add Severity window (see Add a Severity Range) or display the Modify Severity window (see Edit a Severity Range).
  2. Use the Alarm Analysis fields to define the amount of permitted time for alarms being received, responded to, and cleared. There are 3 settings:
  • Maximum period between alarm occurring and being received—Enter the amount of time permitted between an alarm condition occurring and the alarm being received by the server. The amount of time has to be an OPC interval, for example, 10s for 10 seconds.

When an alarm situation occurs, an alarm is raised. The alarm is reported to the server. If the alarm is not reported to the server within the defined time, an event is logged in the event journal. This allows users to view those alarms that have not been reported to the server within the permitted time. Typically, these alarms are not reported due to slow dial in connections between clients and the server.

  • Maximum period between alarm being received and acknowledged—Enter the amount of time permitted between an alarm being reported and the alarm being acknowledged by a user. The amount of time has to be an OPC interval, for example, 5M for 5 minutes.

When an alarm situation occurs, an alarm is raised. The alarm is reported to the server. If a user does not acknowledge the alarm within the defined time, an event is logged in the event journal. This allows users to view those alarms that have not been acknowledged within the permitted time. Typically, these alarms do not have an Acknowledge response due to the slow reaction of operators, or operators not being on site at the time of alarm.

  • Maximum period between alarm occurring and being cleared—Enter the amount of time permitted between an alarm condition occurring and the alarm being cleared. The amount of time has to be an OPC interval, for example, 10s for 10 seconds.

When an alarm situation occurs, an alarm is raised. The alarm is reported to the server. If the conditions that caused the alarm to be raised are not cleared within the defined time, an event is logged in the event journal. This allows users to view those alarms that relate to conditions that have not been rectified within the permitted time. Typically, these alarms are due to the cause of the alarm not being dealt with, or the solution to the alarm condition taking longer than expected.

When you have defined the Alarm Analysis settings, you can select the OK button to close the Add Severity window or the Modify Severity window. To apply the changes you have made, you will need to right-click on the system in the Server Status Tool, then select the Apply Changes option from the context sensitive menu.

Alternatively, you can use the Add Severity window or the Modify Severity window to define or change more severity configuration settings (see Add a Severity Range or see Edit a Severity Range).


Server Administration Guide - Define the Allowed Actions for a Severity (Alarm and Event Severities)

Define the Allowed Actions for a Severity

When you add or modify an alarm severity, you can make changes to the Allowed User Actions for that severity. The Allowed User Actions settings define which alarm pick actions are accessible for alarms in the severity range that you are configuring.

To define the allowed actions for a severity:

  1. Display the Add Severity window (see Add a Severity Range) or display the Modify Severity window (see Edit a Severity Range).
  2. Use the Allowed Actions section to choose which alarm actions are provided for alarms of the severity range you are configuring. You can enable (select) or disable any of the following alarm response actions:
  • Alarm Acknowledge—Defines whether users can access the Acknowledge Alarms action for alarms of this severity. The Acknowledge Alarms action allows users to change the status of the alarm so that other users can see that the alarm has been seen by a user but the conditions that have caused the alarm are still in place.
  • Alarm Acknowledge with Comment—Defines whether users can access the Acknowledge with Comment action that works in the same way as the Acknowledge Alarm action except that it also prompts the user to enter a brief message.
  • Alarm Unacknowledge—Defines whether users can access the Unacknowledge Alarms action for alarms of this severity. The Unacknowledge Alarms action can only be used after an alarm has been acknowledged and it cancels the acknowledge state change so that the alarm is reverted to an unacknowledged state.
  • Alarm Unacknowledge with Comment—Defines whether users can access the Unacknowledge with Comment action that works in the same way as the Unacknowledge Alarm action except that it also prompts the user to enter a brief message.
  • Alarm Remove—Defines whether users can delete an alarm of this severity by using the Remove Alarms action.
  • Alarm Remove with Comment—Defines whether users can access the Remove with Comment action that works in the same way as the Remove Alarms action except that it also prompts the user to enter a brief message.
  • Alarm Response—Defines whether users can access the Alarm Response action for alarms of this severity. The Alarm Response action prompts users to enter a comment, but unlike the 'with Comment' action such as Alarm Remove with Comment, the Alarm Response action only adds a comment to the alarm; it does not change the state of the alarm.
  • Alarm Disable—Defines whether users can disable an alarm of this severity by using the Disable Alarms action.

Select the check boxes for those features that users are allowed to access and clear the check boxes for those features that users cannot access.

Typically, the Allowed User Actions settings are only altered from the default settings (all enabled) if there is a requirement for users to enter a comment when acknowledging, unacknowledging and removing alarms of this severity. If this is required, the Alarm Acknowledge, Alarm Unacknowledge, and Alarm Remove check boxes in the Allowed Actions section should be cleared while the 'with Comment' equivalent check boxes should be selected. This will mean that users are prompted to enter a comment whenever they acknowledge, unacknowledge or remove an alarm within severity range you are configuring.

When you have defined the Allowed User Actions, you can select the OK button to close the Add Severity window or the Modify Severity window. To apply the changes you have made, you will need to right-click on the system in the Server Status Tool, then select the Apply Changes option from the context sensitive menu.

Alternatively, you can use the Add Severity window or the Modify Severity window to define or change more severity configuration settings (see Add a Severity Range or see Edit a Severity Range).


Server Administration Guide - Edit a Severity Range (Alarm and Event Severities)

Edit a Severity Range

You can edit the settings of each severity range to suit your requirements.

Each severity range has:

  • A number that defines the lowest number in the severity range.
  • A description that provides a textual description of the range, for example, Low.
  • Colors for each of the alarm states that can be shown on an Alarm display such as the Alarm List and Alarm Banner.
  • An alternative flash color for each of the alarm states.
  • Colors for each of the alarm states that can be shown on non-Alarm specific displays such as Queries Lists and Mimics.
  • Settings that determine which alarm actions are available to users.

You can use the Modify Severity window to change any of the settings listed above as well as the Alarm Analysis settings. Typically, the settings are adjusted to incorporate additional severity ranges and to apply a custom color scheme for alarms.

NOTE: The Severity settings have to be identical on both servers in a hot-standby system and identical on the 3 servers in a triple-standby system. They also need to be identical on each of the 3 servers in a hot-standby pair with permanent standby system.

To edit a severity range, you need to:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch of the tree structure.
  3. Select Severities.
    The Severities section is shown. It contains a list of the severities in place on your system.
  4. Right click on the severity that you want to edit. This displays a context sensitive menu.
  5. Select the Modify option.
    The Modify Severity window is displayed.
  6. Use the Priority spin box to define the lowest value that is to be included in the severity range (see Define the Priority and Description for a Severity)
  7. Enter brief information about the severity range in the Description field (see Define the Priority and Description for a Severity).
  8. Use the Sound field to Associate a WAV Sound File with a Severity Range.
  9. Use the Colors section to define the colors that are used for the foreground of alarms in this severity. The foreground colors are applied on a variety of alarm displays such as the Alarms List and Alarm Banner (see Define the Foreground Colors for a Severity).
  10. Use the Background Colors section to define the colors that are used for the background of alarms in this severity. The background colors are applied on a variety of alarm displays such as the Alarms List and Alarm Banner (see Define the Background Colors for a Severity).
  11. Use the Alarm Analysis section to define the amount of time permitted between alarms in this severity range being raised and received, received and acknowledged, and received and cleared (see Define the Alarm Analysis Periods for a Severity)
  12. Use the Allowed User Actions section to define which alarm pick actions are available for the alarms in this severity range (see Define the Allowed Actions for a Severity).
  13. When you have defined the various settings for the severity, you can select the OK button to close the Add Severity window or the Modify Severity window. To apply the changes you have made, you will need to right-click on the system in the Server Status Tool, then select the Apply Changes option from the context sensitive menu.

Further Information

Add a Severity Range

Remove a Severity Range.


Server Administration Guide - Remove a Severity Range (Alarm and Event Severities)

Remove a Severity Range

You can use the ClearSCADA Server Configuration Tool to remove one or more severity ranges. If you remove the severity ranges, the default severities will be restored.

Whenever you remove a severity range, the alarms and events on your system are re-classified so that they correspond to the new range of severities. This means that the severity of the alarms and events may change in the Event List and Alarm Banner and Alarm List.

ATTENTION: When you remove a severity range, the severity range that is immediately below the deleted severity in the hierarchy is increased. For example, if you are using the default severities, and you delete the Medium severity, the Low severity range will cover the internal values 1-666 instead of 1-333.

To remove a severity range:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Database Configuration branch of the tree structure.
  3. Select Severities to display the Severities section.
  4. Right-click on the Severity that you want to remove from the list of severities.
  5. Select the Remove option from the context sensitive menu.
    The severity range is removed.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have removed a severity, you can either proceed to configure other severities or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Data Files Settings.


Server Administration Guide - Data Files Settings

Data Files Settings

You can use the Server Configuration Tool to define the Caching and Flushing settings for data files.

Data files are special types of file that are used to store the data for a variety of features, including Data Tables. The values within the data files are stored separately from the database.

When a Data Table is displayed, the data that is required for that grid is loaded from the relevant data file into memory. When the Data Table is closed, the data remains in memory until it is purged. If changes have been made to the data while it was in memory, the data is flushed to disk so that the changes are stored in the data files.

The amount of memory that can be allocated for use with data files is called the data file cache. By using the Server Configuration Tool, you can define the amount of memory for the data file cache. The system will use this limit to determine when older data files are to be purged from memory. For example, if the data files cache is set to 1Mb, the system will allow 1Mb worth of data files to be loaded into memory. When the amount of data files requested exceeds the 1Mb limit, the system will start to purge the oldest data files from memory to allow room for the latest requested data files. This means that it is possible to exceed the data cache limit—system performance will be slower if the limit is exceeded.

You can also use the Server Configuration Tool to configure the time limit for data file flushing. Flushing is the term used to describe the process of writing the changes made to the data file values in memory back to the data files on disk.

During flushing, the system checks the data used by the Data Tables for changes. If any changes have been made to the data while it has been stored in memory, the system will flush the changes from memory back to the data files on disk. This helps to keep the data files up to date and accurate. If the system is unable to complete the flushing process within the defined flushing limit, it will remember where the previous flushing process ended and continue from that position at the beginning of the next flush.

Typically, the default Caching and Flushing settings are appropriate. However, you may want to change the settings if:

  • Your system is experiencing slow performance as a result of the cache limit being consistently exceeded. You can view the cache status by accessing the status information for the Data File Cache (see Data File Cache in the ClearSCADA Guide to the Server Status Tool).
  • There are a high number of files that are waiting to be flushed (as the flush process is too infrequent or too short)
  • The flush process is taking a long time to complete.

To define the Data File Caching and Flushing settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select Data Files
  4. In the Data Files section, use the fields to define the caching and flushing settings as follows:
  • Cache Size—Enter the maximum amount of memory to be allocated for use with data files. When the Cache Size limit is reached, ClearSCADA will attempt to start to remove the oldest data file data from memory (the data file data will still be stored in the data files). Typically, the default setting of 100Mb is appropriate, but you may need to increase the amount of memory allocated to the Cache size if your system experiences slow performance due to the limit being consistently exceeded.
  • Flush Interval—Enter the amount of time, in seconds, between each flush. The default setting of 20 seconds is usually appropriate, but you may need to decrease this amount if a high number of files are not being flushed. Alternatively, you may need to increase this amount if the flushing causes slow performance (frequent flushing can cause high CPU usage).
  • Flush Time Limit—Enter the total amount of time, in seconds, permitted for the flushing process. If a flush is incomplete at the end of the defined time limit, the next flush will continue from the previous position. So, if at the end of the first flush, 75% of the files have been flushed, at the start of the next flush, the server will begin to flush the remaining 25% of the files.
  5. Right-click on the system icon in the tree-structure and select the Apply Changes option to apply the changes.

Further Information

Location of Data Files: see Locations of the Database Folders.


Server Administration Guide - Advanced Settings

Advanced Settings

The Advanced settings that are available in the Global Parameters section of the Server Configuration Tool are used to define a selection of connection and update features. For more information, see Connection and Update Settings.


Server Administration Guide - Connection and Update Settings

Connection and Update Settings

You can use the Advanced section of the ClearSCADA Server Configuration Tool's Global Parameters to alter the following connection and update settings:

  • Server Port—The port number that the server uses for its connection to ClearSCADA.
  • Send Buffer Size—Defines the amount of data that is sent and received within each network write operation. You may need to change this setting if your system has network problems.
  • Interest Update Rate—Defines how fast the server can check for changes to Mimics, Lists, Third Party clients etc. You may need to change this setting if client data is not being updated at a sufficient rate.
  • Socket Keep Alive—Defines whether the server can poll to check that there are no unnecessary open TCP/IP connections.When this feature is enabled, you can also define how often the server checks for a response to the poll and the amount of time the server waits before sending the next poll. You may need to change this setting if there are users with valid licenses that cannot log on successfully.
  • Template Transactions—Defines whether the server uses the Template Transactions feature which affects how configuration changes to items in Group Templates are propagated to Group Instances.

NOTE: The interest setting that defines when clients are updated with outstation status information is a feature on the Outstations section (see Outstation Settings).

NOTE: The connection settings for COM ports and TCP/IP connections are defined in the Channels section see Define the Settings for Channel Scanning Statistics Trends.


Server Administration Guide - Server Port (Connection and Update Settings)

Server Port

The Server Port setting defines the port number that is used for the server's connection to ClearSCADA. You need to enter the number of an available port.

You can check which ports are currently in use by accessing the Microsoft Windows Command Prompt and entering:

netstat

When you press the Enter key, a list of the TCP ports and the applications that are using them is displayed. You cannot use any of these port numbers—define a different port number for the server port.


Server Administration Guide - Send Buffer Size (Connection and Update Settings)

Send Buffer Size

The Send Buffer size defines the amount of data that is sent and received within each network write operation.

The default Send Buffer size of 8192 bytes is suitable for many systems. However, if there are network problems, the buffer size may need to be changed.

If you need to change the Send Buffer size, you will need to access the Advanced section of the Global Parameters branch on the ClearSCADA Server Configuration Tool. However, do not change the Send Buffer size unless specifically instructed to do so by Schneider Electric staff.

ATTENTION: Do not attempt to change the Send Buffer size without first consulting
Schneider Electric engineers. Changing the Send Buffer size without expert advice could result in inaccurate system operation.


Server Administration Guide - Interest Update Rate (Connection and Update Settings)

Interest Update Rate

The ClearSCADA server checks for changes to Third Party OPC clients and Mimics, Lists, etc. every 500 milliseconds by default. If your system needs to make use of faster updates, you will need to change the Interest Update Rate from 500 milliseconds to a lower number.

ATTENTION: Lowering the Interest Update Rate can have a significant effect on your system performance.

To alter the Interest Update Rate:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Advanced to display the Advanced section.
  4. Enter the required number of milliseconds in the Interest Update Rate field.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have configured the Interest Update Rate settings, you can either proceed to configure other advanced settings or you can continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Channel Settings.

NOTE: The Fast Update setting for Mimics does not allow Mimics to be updated faster than the Interest Update Rate. If the Mimic Fast Update setting is faster than the server's Interest Update Rate, the Mimic will be updated at the Interest Update Rate. The Fast Update setting is defined on the Options window for Mimics (select the Tools menu followed by Options in ViewX).


Server Administration Guide - Socket Keep Alive (Connection and Update Settings)

Socket Keep Alive

Each ClearSCADA server can send polls to other servers or clients that are connected to the server via a TCP/IP connection. The poll is a request for a response, and is used to check that there are no open connections that should be closed.

During normal operation, the ClearSCADA server has open connections to any other servers in the arrangement and each of the clients. If a client or server is shutdown, the TCP/IP connection to the ClearSCADA server should be closed. However, sometimes there may be conditions on the network that result in the TCP/IP connection remaining open even though the client or server has been shutdown. As each open connection uses a ClearSCADA license, this can result in users with valid licenses not being able to log on due to other connections remaining open (if the license limit has been reached).

The ClearSCADA server uses the Socket Keep Alive feature to check that the servers and clients at the other end of the TCP/IP connections are still using the connection. If the clients or other servers respond to a poll that is sent, the TCP/IP connection is being used and is intentionally open. If there is no response, the ClearSCADA server will send further polls (up to 5) to check that the connection is definitely not being used. If there are still no responses, the server will close the connection.

You can use the Socket Keep Alive settings to define whether the Send Poll feature is enabled or disabled.

If you enable the feature, you can also define:

  • How long the server waits between each poll.
  • How long the server waits before sending another poll (if there was no reply to the first poll).

To alter the Socket Keep Alive settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Advanced to display the Advanced section.
  4. Define the settings by using the check box and fields in the Socket Keep Alive box:
  • Send Poll—Select the check box to enable the feature or clear it to disable the feature. If you disable the feature, your system may have open connections to clients or servers that have shutdown which could result in licensed users being unable to log on (if the license limit has been reached).
  • Time between polls—Define the number of seconds between polls being sent to the client at the other end of the TCP/IP connection. The default setting of 300 is usually appropriate.

If there are system users that have valid licenses but are unable to log on, the Time between polls setting may be too slow. By decreasing the number of seconds, you can instruct the server to sends polls more quickly.

Before you decrease the Time between polls, you should assess your network, as lower Time between polls settings can result in increased traffic, which may have an impact on your network.

If you do need to change the Time between polls, we recommend that the value is no less than 60 seconds.

  • Interval—Define how often the server attempts to verify that the TCP/IP connection is being used. Typically, the default setting of 1 second is appropriate.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Now that you have defined the socket keep alive setting, you can either proceed to enable/disable Template Transactions, or you can proceed with other aspects of the server configuration.


Server Administration Guide - Template Transactions (Connection and Update Settings)

Template Transactions

ClearSCADA includes a Template Transactions feature that allows you to choose how Group Template and Group Instance updates are applied. The Template Transactions feature has two possible settings:

  • Disabled—When the Template Transactions feature is disabled, any configuration changes to the Group Template are propagated to the associated Group Instances. This propagation takes place in a single database operation and requires the database to be locked. This means that you cannot interact with your system while the updates are underway. On databases with low-medium numbers of Group Templates and Group Instances (less than 100), the update process should be complete in seconds.

On databases with large numbers of Group Templates and Group Instances (100+), the database may be locked for an extended period—users will be unable to continue working with the system while the updates are in progress.

Template Transactions are disabled by default to protect your system from potential ‘race conditions’ (for more information, see Enabled, below).

  • Enabled—When the Template Transactions feature is enabled, updates to Group Templates occur immediately, but the changes are propagated from the Group Templates to the Group Instances as a background operation. This means that users can continue to work with the system while the updates are in progress.

The Template Transactions feature is disabled by default as this means race conditions cannot occur. A race condition is where two or more tasks attempt to access the same resource at the same time with unpredictable results. For example, if a Group Instance has updates pending and a user changes the configuration of an item in the Group Instance, when the updates are applied, they may overwrite the changes made by the user.

Race conditions cannot occur when the Template Transactions feature is disabled as users can only work with the system after the updates have been applied. ClearSCADA uses a pending transactions count to determine if there are further updates to be applied, see Pending Transaction Count.

If you enable the Template Transactions feature, there is a chance that race conditions could occur. However, ClearSCADA has in-built safety measures to stop you from performing the majority of tasks that are likely to cause race conditions.

The built-in safety measures work by limiting the operations that are available to users for items that have updates pending. For more information, see Rules of the Template Transaction Feature.

Before you decide whether you want to enable or disable the Template Transactions feature, we recommend that you:

  1. Determine how many Group Templates and Group Instances are on your system.

If there are less than 100, it is unlikely that you will need to enable the Template Transactions feature as updates should only take seconds to complete. Proceed to Step 3.

If you have more than 100 and updates are causing extended periods of ‘database lockout’, you should consider enabling the Template Transactions feature. Proceed to Step 2.

  2. Familiarize yourself with the Rules of the Template Transaction Feature, Configuration Changes and Structure Changes, and Pending Transaction Count.
  3. Enable or Disable the Template Transaction Feature as required.


Server Administration Guide - Rules of the Template Transaction Feature (Connection and Update Settings)

Rules of the Template Transaction Feature

The Template Transaction feature is designed to block certain changes to items within Group Templates and Group Instances when updates are pending. This helps to avoid ‘race conditions’.

  • If the Template Transaction feature is enabled, you cannot:
  • Perform any configuration or structure changes to items in a Group Instance that has changes pending (this includes exporting an item in a Group Instance).

For more information on configuration changes and structure changes see Configuration Changes and Structure Changes.

  • Rename or move items within a Group Template that has configuration changes pending. If a Group Template only has structure changes pending, you can rename or move items within the Group Template as and when required.

NOTE: You can move items into or out of a Group Template that has configuration changes pending.

These two rules are true irrespective of your security permissions and are applied whenever the Pending Transaction Count for a Group Template or related Group Instances is above 0 (see Pending Transaction Count).

  • If the Template Transaction feature is disabled, the database is locked until the pending configuration and structure changes are complete, and so you cannot work with your system. This is the recommended setting for systems with moderate numbers of updates and Group Instances as it means 'race conditions' cannot occur. The Template Transaction feature is disabled by default.

Further Information

Configuration Changes and Structure Changes

Pending Transaction Count

Enable or Disable the Template Transaction Feature.

Configuration Changes and Structure Changes

When enabled, the Template Transaction feature can stop you from making configuration changes and changes to the structure of the database (see Rules of the Template Transaction Feature).

The operations that are referred to as Configuration Changes are:

  • Saving changes on Forms
  • Saving changes on documents such as Mimics, Logic programs, and Schedules
  • Writing to a property from Logic or another program
  • Enabling or disabling an aggregate from Logic or another program
  • Changing an item’s Security settings
  • Changing an item’s color palette
  • Removing Property Overrides from a Group Template.

The operations that are referred to as Structure Changes are:

  • Creating an item
  • Deleting an item
  • Renaming an item
  • Moving an item:
  • between Groups in the same Group Template
  • into a Group Template
  • out of a Group Template
  • between two different Group Templates
  • Converting an item
  • Changing the configuration of a 'nested' Group Instance so that it is associated with a different Group Template (a 'nested' Group Instance is a Group Instance that is located within another Group Instance)
  • Converting a 'nested' Group Instance into a Group Template (using the Convert menu option)
  • Converting a 'nested' Group Instance into a Group.

Further Information

Template Transactions

Rules of the Template Transaction Feature

Enable or Disable the Template Transaction Feature.

Pending Transaction Count

ClearSCADA uses a Pending Transaction Count to determine whether a Group Template or Group Instance has updates pending.

Whenever a change is made to an item in a Group Template, the pending transaction count for the Group Template increases by 1. The pending transaction count for every Group Instance that is associated with the Group Template also increases by 1 (as the change to the item in the Group Template will need to be propagated to the Group Instances). If any further changes are made to items in the Group Template before the first changes have been propagated, the pending transaction count increases from 1 to 2. When the changes have been propagated, the pending transaction counts return to 0.

If the Template Transaction feature is enabled, the rules of the Template Transaction feature will be enforced only on those Group Templates and Group Instances that have pending transaction counts above 0.

If the Template Transaction feature is disabled, the database is locked until the Group Templates and Group Instances have pending transaction counts of 0.

Example:

A Group Template named 'AT1' is associated with three Group Instances, ‘MXE10’, ‘MXE11’ and ‘MXE12’. There are no pending changes and so the pending transaction counts for the Group Template and the three Group Instances are 0. The Template Transaction feature is enabled.

A user changes the configuration of an item in the ‘AT1’ Group Template and saves the Form. This causes the pending transaction counts to rise as follows:

  • AT1 - 1
  • MXE10 - 1
  • MXE11 - 1
  • MXE12 - 1

As the pending transaction counts are above 0, the rules for the Template Transaction feature are applied (to the Group Templates, Group Instances and items nested within them).

ClearSCADA propagates the configuration change to MXE10. This causes the pending transaction count to change to:

  • AT1 - 1
  • MXE10 - 0
  • MXE11 - 1
  • MXE12 - 1

The MXE10 count goes back down to 0 as its pending changes have been applied. The count of the AT1 Group Template remains at 1 because the change to the item in the Group Template has not been propagated to the relevant Group Instances.

ClearSCADA propagates the configuration change to MXE11. This causes the pending transaction count to change to:

  • AT1 - 1
  • MXE10 - 0
  • MXE11 - 0
  • MXE12 - 1

Another configuration change is made to an item in the 'AT1' Group Template. This causes the pending transfer count for the Group Template and its associated Group Instances to increase by 1:

  • AT1 - 2
  • MXE10 - 1
  • MXE11 - 1
  • MXE12 - 2

The first configuration change is propagated to the ‘MXE12’ Group Instance. This causes the pending transfer count of the ‘MXE12’ Group Instance to decrease by 1, and also the pending transfer count of the ‘AT1’ Group Template to decrease by 1 (as the first change has been propagated to the dependent Group Instances):

  • AT1 - 1
  • MXE10 - 1
  • MXE11 - 1
  • MXE12 - 1

The transaction for the first configuration change is now complete. Next, ClearSCADA propagates the second configuration change to the MXE10 Group Instance which results in these pending transfer counts:

  • AT1 - 1
  • MXE10 - 0
  • MXE11 - 1
  • MXE12 - 1

ClearSCADA then propagates the second configuration change to the MXE11 Group Instance, which causes the pending transaction count to change to:

  • AT1 - 1
  • MXE10 - 0
  • MXE11 - 0
  • MXE12 - 1

Finally, ClearSCADA propagates the second configuration change to the MXE12 Group Instance and the pending transaction counts for the Group Template and the three Group Instances return to 0:

  • AT1 - 0
  • MXE10 - 0
  • MXE11 - 0
  • MXE12 - 0

With the pending transaction counts are back to 0, the Template Transaction rules are no longer applied and you can work freely with the items in the Group Template and Group Instances (depending on your security permissions). The Template Transaction rules will be re-applied to the Group Template, Group Instances and nested items as soon as the pending transfer counts for the Group Template or Group Instances rise above 0.


Server Administration Guide - Enable or Disable the Template Transaction Feature (Connection and Update Settings)

Enable or Disable the Template Transaction Feature

You can use the Server Configuration Tool to enable or disable the Template Transactions feature on a system. By default, the Template Transactions feature is disabled so that ‘race conditions’ are unlikely to occur—you are unable to work with the system while it propagates changes (usually, this takes a matter of seconds).

On systems that have a high number of Group Templates (100+), having the Template Transactions feature disabled may result in the database being locked for an extended amount of time. This is because the changes may have to be propagated to a large number of Group Instances and certain operations take longer to complete. By enabling the Template Transactions feature, you can set the propagations to run in the background, which means users can continue to work with the database. However, the Template Transactions will limit the tasks they can perform while changes are still pending.

If you enable the Template Transactions feature, it is possible that your system may experience ‘race conditions’. However, the Template Transactions rules are designed to prevent a wide range of potential ‘race condition’ related issues.

To enable or disable the Template Transactions feature:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Advanced to display the Advanced section.
  4. Use the Template Transactions check box to enable or disable the Template Transactions feature as required:
  • Select the Template Transactions check box to enable the feature.
  • Clear the Template Transactions check box to disable the feature.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Channel Settings

Channel Settings

You can use the Channels section of the ClearSCADA Server Configuration Tool to:

  1. Define the Settings for Channel Scanning Statistics Trends.
  2. Define how a PSTN Channel is Selected for Communications.
  3. Define the Settings for Modems.
  4. Define the Settings for COM Ports and TCP/IP Connections
  5. Define whether a Listen Port can be Shared.

The default settings are appropriate for many systems.


Server Administration Guide - Define the Settings for Channel Scanning Statistics Trends (Channel Settings)

Define the Settings for Channel Scanning Statistics Trends

ClearSCADA provides two default scanning statistic Trends for channels:

  • Scanning Duration Trend—Provides statistical information about the scan times for a channel.
  • Scanning Phase Trend—Provides statistical information about the percentage of time spent on each phase of a scan.

Both of these Trends are available from the context-sensitive menu for each channel (where applicable).

You can use the ClearSCADA Server Configuration Tool to define the X-Axis settings for the channel scanning statisticTrends. The settings that you define will be the default settings and will be in place for each channel scanning statistic Trend that is displayed.

To define the settings for the channel scanning statistics Trends:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Channels to display the Channels section.
  4. Use the fields in the Trends box to define the X-Axis settings:
  5. Enter the default amount of time shown on the X-Axis in the Interval field. The Interval has to be in the OPC interval time format, for example 15M for 15 minutes.

For more information on the OPC formats, see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.

  6. Define the start time of the X-Axis in the Offset field. The Offset has to be in the OPC interval time format, for example, M-20M for 20 minutes prior to the start of the current minute.
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished defining the Trends settings, you can either configure other Channels settings:

  • Define how a PSTN Channel is Selected for Communications.
  • Define the Settings for Modems.
  • Define the Settings for COM Ports and TCP/IP Connections.

Or:

  • Continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Driver Settings.

NOTE: If you want to check the effects of the Channel Trends settings, log on to ViewX, right-click on a channel that is in communications with one or more outstations, then select either the Display Scanning Duration Trend option or the Display Scanning Phase Trend option.This displays a Trend that has an X-Axis that covers the time period that you defined as the Interval, beginning from the time you defined as the Offset.


Server Administration Guide - Define how a PSTN Channel is Selected for Communications (Channel Settings)

Define how a PSTN Channel is Selected for Communications

You can use the ClearSCADA Server Configuration Tool to define how ClearSCADA determines which of the available PSTN channels are used for communications with a PSTN outstation.

There are two methods for deciding which PSTN channel is used to make a call to an outstation:

  • Use Channel with Fewest Total Calls—ClearSCADA will attempt to make a call to an outstation via all available channels. The load is distributed evenly between the available channels, and only those channels that have failed (if any) are not used.

The main advantage of the fewest total calls method is that all available channels are used regularly—ClearSCADA can detect the quality of calls on each channel on a regular basis.

A disadvantage of the fewest total calls method is that a channel that has a history of failing regularly will still be used (if it is available) even though it may not be as reliable as other available channels.

  • Use Channel with Highest Quality—ClearSCADA will call an outstation via the channel that has the highest quality factor (of the channels that are currently available).

When PSTN channels are created, they are allocated a quality factor. This is a number that is defined by the Quality Factor setting (in the Channels settings on the Server Configuration Tool).

If a PSTN channel is used for a successful call, its quality factor rises by 1 (up to the maximum limit, which is defined by the Quality Factor setting); if it is used for a failed call, its quality factor drops by 1 (it cannot drop below 1).

When ClearSCADA has to call an outstation or similar device via a PSTN channel, it uses the channels’ quality factor to determine which of the available channels should be used. To do this, it examines the quality factor of each available channel - the channel with the highest quality factor is deemed to be the most reliable channel and so is used. If there are multiple channels all with the same highest quality factor, ClearSCADA uses these channels in a ‘round robin’ sequence. This means that ClearSCADA uses a variety of ‘good’ channels rather than continuously using the same ‘good’ channel each time.

The Quality Factor setting is only available for use when you select the Use Channel with Highest Quality setting. By default, it is set to 5 which is regarded as suitable for many systems.

If you set a higher number for the Quality Factor, you raise the maximum number of consecutive failed calls that can occur before a different channel is used. Similarly, if you set a lower number for the Quality Factor, you lower the maximum number of consecutive failed calls that can occur before another channel is used.

NOTE: The current quality factor for a channel can also be reset to the Quality Factor that is defined in the server configuration. To do this, you need to use the ResetCallQualityFactor action for the PSTN Channel.

To define the method used for selecting PSTN channels:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Channels to access the Channels section.
  4. Use the option buttons in the PSTN section to choose the required method of PSTN channel selection:
  • Select the Use channel with fewest total calls option button to enable balanced load sharing. We recommend that you use this method unless there are known issues with the communication lines.
  • Select the Use channel with highest quality option button to set ClearSCADA to choose a channel based on its availability and quality factor. We recommend that you only use this method if there are known issues with the communication lines.

When you choose the Use channel with highest quality option, the Quality Factor field becomes available. In the Quality Factor field, enter the number that will be used as:

  • The quality factor that will be allocated to every new PSTN channel
  • The highest quality factor that any PSTN channel can have. Each PSTN channel has its own quality factor that rises and falls when it is used for good calls and failed calls respectively. But the quality factor of a channel cannot drop below 1 or rise above the amount you define in the Quality Factor field in the Server Configuration Tool’s Channels settings.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished defining how ClearSCADA should choose a PSTN channel, you can either configure other Channels settings:

  • Define the Settings for Modems.
  • Define the Settings for COM Ports and TCP/IP Connections.

Or:

  • Continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Driver Settings.


Server Administration Guide - Define the Settings for Modems (Channel Settings)

Define the Settings for Modems

You need to define 2 durations for modems:

  • Duration of BREAK Signal.
  • Duration of Post Hang-up Delay.


Server Administration Guide - Duration of BREAK Signal (Channel Settings)

Duration of BREAK Signal

For a modem to respond to instructions, it needs to be switched into 'Command' mode. ClearSCADA uses 2 methods to instruct a modem to switch into command mode:

  • ClearSCADA can send an escape sequence
  • ClearSCADA can send a BREAK signal

A BREAK signal is usually regarded as the more reliable method, and is sent by the relevant drivers to the modems.

The BREAK signals need to be of sufficient length. If the length (duration) is too short, the modem will not be able to detect the BREAK signal and so will not switch to command mode. If the duration is too long, there will be a unnecessary delay.

The Duration setting that you define applies to every PSTN channel on your system. The minimum duration is determined by the speed of the slowest PSTN channel.

NOTE: You can disable the sending of BREAK signals by setting the Duration to 0. This means that ClearSCADA will only use the escape sequence to instruct modems to switch to Command mode.

To change the duration of the BREAK signal:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Channels to access the Channels section.
  4. Use the upper Duration field in the PSTN box to define the length of the BREAK signal (in milliseconds).

The required duration of the BREAK signal can vary according to the models of modem being used. Typically, the default setting of 100 milliseconds is suitable, but you may need to increase this setting to nearer 200 milliseconds depending on the models of modem being used.

  5. If your modem cable is fully wired, you will also need to define the Duration of Post Hang-up Delay.

If your modem cable is not fully wired, you can apply the changes.

  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished defining the duration settings, you can either configure other Channels settings:

  • Define the Settings for Channel Scanning Statistics Trends.
  • Define how a PSTN Channel is Selected for Communications.
  • Define the Settings for COM Ports and TCP/IP Connections.

Or:

  • Continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Driver Settings.

Further Information

You can find more information about the CCITT recommendations for BREAK signal length at the Microsoft support website (www.support.microsoft.com). The BREAK signal information is included in Microsoft Knowledge Base Article - 119506.


Server Administration Guide - Duration of Post Hang-up Delay (Channel Settings)

Duration of Post Hang-up Delay

You can use the Channels section of the ClearSCADA Server Configuration Tool to define the duration of the delay between consecutive calls on a PSTN channel. A delay may be required when using network connected serial ports, such as a Comtrol DeviceMaster. With such setups, delays can be needed due to latency when reporting the reply from a modem to a hang-up command.

When a call has completed, the driver sends a hang-up command to the modem. The completion of the hang-up can be signalled in two ways - the reply from the modem and (with a fully wired cable) the carrier detect signal changing to Low. With a network connected serial port, there can be delay between the driver receiving the reply from the modem and the carrier detect signal change. This can cause a problem if there is another call pending when the first call completes, as the driver can start the new call and then receive the reply from the modem to the hang-up command. The reply from the modem is then mistakenly handled as being related to the new call, which causes the call attempt to fail with a 'No carrier' error.

To avoid this problem, you can define a delay that is applied after hanging up the modem (and so allow time for the modem reply to be received). The duration of this delay will vary depending on the amount of latency on your network, but can be between 200ms and 5000ms.

To define the duration of the delay:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Channels to access the Channels section.
  4. Use the lower Duration field in the PSTN box to define the duration of the post hang-up delay.
  5. Close the ClearSCADA Server Configuration Tool to apply the changes (or select another branch if further server configuration is required).

When you have finished defining the duration settings, you can either configure other Channels settings:

  • Define the Settings for Channel Scanning Statistics Trends.
  • Define how a PSTN Channel is Selected for Communications.
  • Define the Settings for COM Ports and TCP/IP Connections.

Or:

  • Continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Driver Settings.


Server Administration Guide - Define the Settings for COM Ports and TCP/IP Connections (Channel Settings)

Define the Settings for COM Ports and TCP/IP Connections

The COM port and TCP/IP connection settings define how ClearSCADA reacts to a driver being unable to assign to a COM port or TCP/IP socket. They also define the number of conditions that can cause a channel (that is associated with a port/socket) to be deemed as failed.

When ClearSCADA detects that a channel has failed, it raises an alarm (if configured to do so) and the channel de-assigns from the port or socket. After the specified time period, the driver attempts to re-assign the port or socket.

The default COM ports and TCP/IP Connections settings are usually appropriate, but you may need to change the settings if:

  • ClearSCADA is taking too long to re-assign to a COM port or TCP/IP socket that failed on the previous attempt
  • ClearSCADA is re-assigning the COM port or TCP/IP socket too quickly.
  • You only want a COM port to be deemed as failed when a specific number of consecutive read or write attempts have failed. This allows ClearSCADA to continue using a COM port when there are intermittent failures.
  • You only want a COM port or TCP/IP connection to be deemed as failed when a specific number of consecutive read or write timeouts have failed. This allows ClearSCADA to continue using a COM port or TCPIP connection when there are intermittent failures.

To change the COM port and TCP/IP settings, see the following sections:

  • Define the Period Between Retries to Assign to a Port/Socket
  • Define the Delay After Calling Comtrol’s Freeport Routine
  • Define the Maximum Number of Consecutive Failed Reads and Writes
  • Define the Maximum Number of Consecutive Read and Write Timeouts


Server Administration Guide - Define the Period Between Retries to Assign to a Port/Socket (Channel Settings)

Define the Period Between Retries to Assign to a Port/Socket

To define the settings for COM ports and TCP/IP connections:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Channels to display the Channels section.
  4. Use the Period Between Retries to Assign to a Port/Socket spin-box to define how long (in seconds) ClearSCADA will wait between attempts to assign to a COM port or TCP/IP socket that failed previously.

You may want to decrease the interval so that if a COM port or TCP/IP socket cannot be assigned, there is less delay before the driver attempts to re-assign it. We recommend that you set the interval to a minimum of 5 seconds.

If you increase the interval, the driver will wait for a longer period of time before attempting to re-assign a port or socket. This can result in a longer delay as the driver takes longer to assign a port or socket. However, it reduces the amount of time the driver spends repeatedly retrying to assign a port or socket.

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define the Delay After Calling Comtrol's Freeport Routine (Channel Settings)

Define the Delay After Calling Comtrol’s Freeport Routine

NOTE: The Delay After Calling Comtrol’s Freeport Routine setting is only relevant on systems where Comtrol DeviceMasters use the native (NS-Link) COM port drivers. If your system has Comtrol DeviceMasters that do not use the native COM port drivers, you do not need to use the Delay After Calling Comtrol’s Freeport Routine setting. Similarly, if your system does not use Comtrol DeviceMasters, you do not need to use this setting.

ClearSCADA supports the use of network connected serial ports (DeviceMasters). Typically, DeviceMasters are used to provide serial communications from the servers in a multi-server system, for example, to provide serial communications for the Main and Standby servers in a Hot-Standby architecture.

There are many different DeviceMasters available, each with ports that can be associated with one or more PCs. Some DeviceMasters have a single port, whereas others have 4, 8 or 16 ports. However, each port can only be used by one PC at any one time. So, in a multi-server architecture, the Main server is associated with one specific port on the DeviceMaster; the other server(s) cannot access this port, but can use the DeviceMaster’s other ports.

If a changeover occurs as a result of the Main server going offline or a network failure, the new Main server needs to establish communications. To do this, the new Main server has to connect (open) to the ports on the DeviceMaster that was used by the old Main server. If the old Main server was not shut down cleanly, the DeviceMaster can take around 2 minutes to release the port so that it can be re-used. This can delay the new Main server as it attempts to establish communications.

To improve the speed of the reassignment process, the ClearSCADA server that changes from Standby to Main sends the freeport instruction to the DeviceMaster. The instruction forces the DeviceMaster to free the relevant COM ports much more quickly. However, new attempts to open the ports will only succeed after the DeviceMaster has processed the Freeport command (which happens asynchronously). For this reason, ClearSCADA needs to apply a delay before it attempts to open the port on the DeviceMaster - the Delay After Calling Comtrol’s Freeport Routine setting defines this delay.

By using the Define the Delay After Calling Comtrol’s Freeport Routine setting, you can allow the DeviceMaster to complete its Freeport routine before ClearSCADA attempts to open the port. With an appropriate delay in place, ClearSCADA will be able to reassign the DeviceMaster’s COM ports successfully, so that the new Main server can access the COM ports it needs. If the delay is insufficient, the reassignment process may fail, meaning the new Main server will be unable to connect to the network until the next retry (retries are every 30 seconds by default).

The amount of delay required varies according to the type of network being used:

For LANs (Local Area Networks), a delay of 30ms is usually appropriate as routers are not used between the DeviceMaster and the ClearSCADA server.

For WANs (Wide Area Networks), where there is one or more routers between the ClearSCADA server and the DeviceMaster, longer delays of 250ms or more may be required. The default value for the Define the Delay After Calling Comtrol’s Freeport Routine setting is 250ms, which is usually appropriate for many LANs and WANs (although you may be able to improve the connection time by reducing the delay for LANs).

To define the Define the Delay After Calling Comtrol’s Freeport Routine setting:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Channels to display the Channels section.
  4. Use the Define the Delay After Calling Comtrol’s Freeport Routine spin-box to define the required delay. Remember that for a LAN, lower delays such as 30ms may be appropriate, whereas longer delays of 250ms or more may be needed for a WAN. As network speeds can vary significantly, you may need to experiment with the delay setting to determine the ideal delay for your set-up.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define the Maximum Number of Consecutive Failed Reads and Writes (Channel Settings)

Define the Maximum Number of Consecutive Failed Reads and Writes

You can use the Server Configuration Tool’s Channel settings to define the Maximum Number of Consecutive Failed Reads and the Maximum Number of Failed Writes. These settings provide a limit for consecutive failures of read and write operations, that when reached, will allow ClearSCADA to regard a serial channel as having failed.

NOTE: The Maximum Number of Consecutive Failed Reads and Maximum Number of Consecutive Failed Writes settings only apply to channels that are configured to have a connection type of Serial.

A failed read or failed write operation can occur as a result of:

  • Hardware failure (applies to both serial (COM) ports and network attached serial ports such as DeviceMaster).
  • Network fault (applies to network attached serial ports only).

Each channel is associated with a port. If there is a hardware error or network problem relating to the connection via the port, the operating system generates an error. ClearSCADA uses these errors to maintain an internal consecutive fail count, and if the maximum limit for the count is reached, the channel associated with the port is deemed to have failed.

There are two consecutive fail counts, one for read operations and one for write operations. The read consecutive fail count increments when there is an error in response to a read request from ClearSCADA, and the write consecutive fail count increments when there is an error in response to a write transmission from ClearSCADA. Both fail counts have a maximum limit (the Maximum Number of Consecutive Failed Reads and the Maximum Number of Failed Writes settings, respectively). If these limits are reached, the channel that is associated with the port is deemed to have failed and an
I/O Failure alarm is raised for the channel.

Once a consecutive fail count has started, ClearSCADA will continue to use the channel. For every failed consecutive attempt, the consecutive fail count increases by 1. If there is a good response (i.e. a non-error response), the count is reset to 0 and normal operations are resumed. However, if ClearSCADA’s further attempts to use the port result in failures, and the maximum consecutive failure limit is reached (it is 10 by default), ClearSCADA will deem the channel as failed and will de-assign from the port. At this stage, ClearSCADA raises an I/O Failure alarm.

ClearSCADA will then attempt to re-assign to the port after the re-establishment delay (30 seconds by default). Usually, if the hardware or network fault is transient, the delay before re-assigning the port is sufficient time for the hardware or network to recover. Upon being reassigned, normal communications can continue. But if the fault is not transient, the re-assign will also fail and the channel will remain as failed.

So, when you come to set the Maximum Number of Consecutive Failed Reads and Maximum Number of Failed Writes, you need to consider what local server hardware (including network attached serial ports) is being used. The default settings for both limits are 10, which means that it takes 10 consecutive read failures or 10 consecutive write failures for ClearSCADA to deem a channel as having failed.

Using your knowledge of your system, you need to judge whether the maximum number of consecutive failed reads and maximum number of failed writes are set so that there is an appropriate delay between a fault being detected and the channel being failed (and an I/O Failure alarm being raised as a result). When making your judgment, you will need to consider the polling rate, the reliability of the hardware and network, the configuration of the channel (retries etc.), and your own operational requirements. Remember that the Maximum Number of Consecutive Failed Reads and Maximum Number of Consecutive Failed Writes settings apply to each serial channel on the system, not just those for one specific driver.

In many cases, the default limits of 10 are appropriate. However, if you require channel failures to be reported more quickly, you may choose to reduce the limit. It is unlikely that you would ever need to increase the limits above the default amount as 10 consecutive hardware/network failures would usually indicate a genuine, persistent fault rather than an intermittent problem.

To change the Maximum Number of Consecutive Failed Reads or Maximum Number of Consecutive Failed Writes so that ClearSCADA is more/less tolerant of consecutive read/write failures:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Channels to display the Channels section.
  4. Use the Maximum Number of Consecutive Failed Reads spin-box to define how many consecutive failed attempts can be made by a driver to read data from a COM port. If the defined number is reached, the channel is deemed to have failed.

A read failure occurs if a driver is unable to read data from the COM port (the operating system reports an error).

If you have a COM port that fails intermittently, a Maximum number of consecutive failed reads setting that is too low may cause the driver to restart the channel unnecessarily.

If you raise the Maximum number of consecutive failed reads setting too high, the driver will take longer to recognize a COM port as having failed.

In many cases, the default setting of 10 is appropriate.

To monitor a channel for read failures, enable the IO logging category on the driver and use the driver log file to view the failures (see Display a Driver Log File).

  5. Use the Maximum Number of Consecutive Failed Writes spin-box to define how many consecutive failed attempts the driver can make to transmit data (write) via the COM port. If the number of consecutive failed writes reaches the defined amount, the channel is deemed to have failed. A write attempt can fail if the operating system reports an error when data is being written to a COM port.

If you have a COM port that fails intermittently, a Maximum number of consecutive failed writes setting that is too low may cause the driver to restart the channel unnecessarily.

If you raise the Maximum number of consecutive failed writes setting is too high, the driver will take longer than necessary to recognize a COM port as having failed.

In many cases, the default setting of 10 is appropriate.

  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define the Maximum Number of Consecutive Read and Write Timeouts (Channel Settings)

Define the Maximum Number of Consecutive Read and Write Timeouts

You can use the Server Configuration Tool’s Channel settings to define the Maximum Number of Consecutive Read Timeouts and the Maximum Number of Write Timeouts. These settings provide a limit for consecutive timeouts or late replies from a remote outstation. If the limit is reached, ClearSCADA deems the channel to have failed (but it will not fail the channel until that limit has been reached).

To set appropriate Maximum Number of Consecutive Read Timeouts and Maximum Number of Write Timeouts for your system, you need to have an understanding of:

  • How ClearSCADA Uses the Consecutive Read and Write Timeouts
  • Considerations when Setting the Maximum Consecutive Read/Write Timeouts.

You need to have a good understanding of your overall system, because the Maximum Number of Consecutive Read Timeouts and Maximum Number of Write Timeouts apply to each of the channels on your system. This means that you may need to compromise when applying your limits, as you will need to consider the overall effects of the limits, not just how they affect one particular driver or channel.

When you understand how the consecutive timeouts are used and are aware of the considerations you need to make, you can proceed to:

  • Change the Maximum Number of Consecutive Read/Write Timeouts.

How ClearSCADA Uses the Consecutive Read and Write Timeouts

In this section, we explain how ClearSCADA uses the Maximum Number of Consecutive Read Timeouts and the Maximum Number of Write Timeouts settings that are available on the Server Configuration Tool’s Channels settings:

The Maximum Number of Consecutive Read Timeouts and Maximum Number of Consecutive Write Timeouts settings are shown in the COM Ports/TCPIP Connections section of the Channels settings.

You need to understand how ClearSCADA uses these settings in order to apply suitable limits for your system. (You will also need to be aware of the Considerations when Setting the Maximum Consecutive Read/Write Timeouts).

Usually, when a driver in ClearSCADA sends a message to a remote outstation, it expects a reply from the outstation within a specific amount of time. To calculate the time period in which an outstation should respond, the driver performs a calculation that uses:

  • The time at which the message was sent.
  • The Standard Reply Delay setting of the channel (defined in the channel's configuration).

NOTE: The DNP3 driver does not use this setting. Instead, it uses Data Link and Application Fragment settings which you can define on the Form for a DNP3 Channel.

  • The transmission time of the message. The transmission time is a calculated estimate of the amount of time it should take to transmit the message to the outstation. The calculation to determine the transmission time is:

The driver also calculates an estimate of the amount of time it will take to send the reply. This calculation is based on the expected size of the response to the request.

Normally, the outstation will reply within the calculated time. However, if the outstation does not respond within the defined time, it could indicate a problem. Typically, the main reason for a reply time out is that the Standard Reply Delay (or DNP3 equivalent settings) is inappropriate. This is especially true during commissioning of a system.

To check if the delay setting(s) is suitable, you can view the I/O log files and see if the replies to the messages are being returned too late. If they are, you can adjust the delay settings as required. If the replies are not being sent too late, then you will need to investigate the cause of the problem, which could be related to the outstation hardware, the communications connection between the outstation and the server, or could be a local fault at the server (unlikely, but possible). Also, you will need to determine whether the fault is a permanent problem that needs to be addressed or is a temporary problem that will resolve itself, for example, an intermittent network failure.

If a message is sent from ClearSCADA but the operating system does not confirm that the message has been sent, there is a problem. ClearSCADA will timeout the message and this will count as a write timeout. Similarly, if a message is sent as expected but there is no reply from the outstation within the expected time, the message is timed out (this counts as a read timeout).

When a read fault occurs, ClearSCADA increases the internal consecutive read timeout count by 1. For each consecutive read timeout, ClearSCADA will increase the internal count by 1 until the Maximum Number of Consecutive Read Timeouts limits is reached. If the limit is reached, ClearSCADA will take the following action:

  • For channels with a Type setting of Network or TCPIP Listen, ClearSCADA deems the socket that is used by the outstation(s) to have failed and raises an I/O Timeout alarm. Only the socket and the outstation(s) that use that socket are failed, not the channel. ClearSCADA may still be able to communicate with other outstations via the channel.
  • For channels with a Type setting other than Network or TCP/IP Listen (Serial, TCP/IP etc.), ClearSCADA deems the channel to have failed. At this point, ClearSCADA raises an I/O Timeout alarm. It also de-assigns the channel then re-assigns it in case the fault was local to the server and can be solved by reassigning the port (that is associated with the channel). If the re-assign is successful, ClearSCADA will continue to use the channel; if it is unsuccessful, the channel is failed and will remain failed until the underlying network or hardware problem is resolved.

Similarly, when a write timeout occurs, ClearSCADA increases the internal consecutive write timeout count by 1. For each consecutive write timeout, ClearSCADA will increase the internal count by 1 until the Maximum Number of Write Timeouts limit is reached. Again, if the limit is reached, ClearSCADA will fail the socket or the channel, depending on the configuration of the channel (as described above).

If a read or write fault is detected but the internal count has not reached the Maximum Number of Consecutive Read Timeouts/Maximum Number of Write Timeouts limit, ClearSCADA continues to use the channel. This is because the fault that caused the read/write timeout failure may be an intermittent problem that could quickly resolve itself, and so the channel may be healthy. If subsequent, consecutive read or write messages timeout, then it is likely that there is a serious fault with the channel, the outstation(s), or a local fault at the server.

When you understand how ClearSCADA uses the consecutive timeout settings, you can proceed to:

  • Considerations when Setting the Maximum Consecutive Read/Write Timeouts.

Or if you are already familiar with the considerations you need to make, you can go ahead and change the limits:

  • Change the Maximum Number of Consecutive Read/Write Timeouts.

Considerations when Setting the Maximum Consecutive Read/Write Timeouts

When you configure the limits for the Maximum Number of Consecutive Read Timeouts and the Maximum Number of Write Timeouts, there are many factors you need to take into consideration:

  • The type of channel being used.

If your system uses network attached serial ports, it is possible that there may be transient faults on the network. To avoid intermittent network errors from causing excessive I/O Timeout alarms and unnecessary de-assignment and re-assignment of channels, you should allow for an appropriate amount of timeouts. The amount that is appropriate for your system will vary depending on other factors.

  • The number of outstations on your channels. The consecutive timeouts limits apply to all channels, so you may need to compromise when setting the limits. You need to consider the impact that the settings will have on all channels, in particular, the channel that is associated with the highest number of outstations.
  • The maximum number of retries per message (configured individually for each channel. Remember that you need to take all of the channels on your system into consideration). Each failed retry attempt will cause the relevant consecutive timeout to increase by 1, so you the timeout limits need to allow for retries as well as the original messages that are sent.
  • The way in which the outstations on your channels are polled. Different drivers use different polling methods. For example, one driver may send the messages for the first outstation before sending the messages for the second outstation; another driver may send the messages in sequence, so that the first messages for each outstation are sent to each of the outstations, then the second messages are sent to each outstation, then the third and so on.

You need to set the limits so that the channel can still be used if an appropriate percentage of the outstations on the channel are still healthy. For example, let’s say a channel is used to connect to 10 outstations. It is configured to have 5 retries and two transaction attempts and the consecutive read timeout limit is the default amount of 20. This means that if 1 outstation fails, it will increase the timeout count by 12 (the first attempt+5 retries x 2). So, if the first two outstations have failed, the channel will fail (as the consecutive read timeout limit will have been reached) and the remaining 8 outstations will not be contacted, even though the channel may be healthy.

  • The reliability of your communications. If you know there are intermittent communication faults, you may wish to change the limits so that ClearSCADA is more/less tolerant of them. (Depending on whether you want the channel to fail quickly for transient communication problems).
  • The reliability of your hardware. If you are using outstations that are known to have intermittent faults or unusual characteristics, you will need to bear these issues in mind when setting the consecutive timeouts. Depending on your requirements, you can set ClearSCADA to be more/less tolerant of consecutive faults.

Typically, you would look to increase the consecutive read and consecutive write timeouts if:

  • Your channels are incorrectly being deemed as failed (due to one or more outstations on a channel failing and causing the consecutive timeout limit to be reached).
  • Your channels have high values (above the default amounts) for the number of retries permitted. A high number of retries will affect the consecutive timeouts counts as if an outstation has failed, a higher number of messages will be sent to the failed outstation (more retries than the default amount).

You may want to reduce the consecutive read and write timeouts if:

  • ClearSCADA is taking too long to recognize channels as having failed
  • ClearSCADA is taking too long to recognize that outstations have failed over a network (Network channels only).

When you understand How ClearSCADA Uses the Consecutive Read and Write Timeouts, and know about the Considerations when Setting the Maximum Consecutive Read/Write Timeouts, you can proceed to:

  • Change the Maximum Number of Consecutive Read/Write Timeouts.

Change the Maximum Number of Consecutive Read/Write Timeouts

Before you change the Maximum Number of Consecutive Read/Write Timeouts, you should have an understanding of the information provided in these sections:

  • How ClearSCADA Uses the Consecutive Read and Write Timeouts
  • Considerations when Setting the Maximum Consecutive Read/Write Timeouts.

NOTE: The default setting for both of the consecutive timeouts settings is 20.

When you understand the consecutive timeouts and how they can affect your system, you can use the Server Configuration Tool to set suitable limits:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Channels to display the Channels section.
  4. Use the Maximum Number of Consecutive Read Timeouts spin-box to define the limit for ‘timed-out’ consecutive read messages. If this limit is reached, ClearSCADA will either detect that the channel has failed and then de-assign and re-assign the channel, or it will fail the socket and associated outstation(s) (depending on the type of channel being used). For more information, see How ClearSCADA Uses the Consecutive Read and Write Timeouts.
  5. Use the Maximum Number of Consecutive Write Timeouts spin-box spin-box to define the limit for ‘timed-out’ consecutive write messages. If this limit is reached, ClearSCADA will either fail the channel and de-assign, then re-assign the channel, or fail the socket and associated outstation(s) (depending on the type of channel being used). For more information, see How ClearSCADA Uses the Consecutive Read and Write Timeouts.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define whether a Listen Port can be Shared (Channel Settings)

Define whether a Listen Port can be Shared

Advanced drivers have channels that support the Listen Port feature, which allows network-connected outstations to initiate a connection to the server. The Listen Port settings in the Channel configuration allow you to define which port is used as the Listen Port (the Listen Port is the port on the ClearSCADA server that is used when an outstation on the channel attempts to initiate a connection).

By default, every channel that uses the Listen Port feature has to be configured to use a different Listen Port on the server—they cannot use the same port number. While this is fine for many systems, in some situations a Listen Port needs to be shared, for example, some devices have to use a fixed port number and so can only be set to use a Listen Port that has a specific port number. If there are multiple devices of the same type in use on the network, this can cause problems as the devices need to use the same Listen Port number. To help avoid this problem, ClearSCADA includes an Allow Channels On a Driver to Share the Same Listen Port feature.

When the Allow Channels On a Driver to Share the Same Listen Port feature is enabled, any outstation in the system can initiate a connection using a single port number. The channel that has the port number (used by the outstation) configured as its Listen Port will automatically check to see if the outstation is active on the channel. If the outstation is active, the channel will be used for the connection; if it is active on another channel, the connection will be automatically redirected to the appropriate channel. This means that multiple devices can use the same port number to initiate connections as ClearSCADA can route the connections to the appropriate channels as needed.

If you are working on a newly installed system, we recommend that you enable the Allow Channels On a Driver to Share the Same Listen Port feature. However, if you are working on a system that has been upgraded, you should leave the Allow Channels On a Driver to Share the Same Listen Port feature disabled (so that your upgraded system works in the same way as your old system).

NOTE: The Allow Channels on a Driver to Share the Same Listen Port setting only applies to TCP-based connections. UDP connections to the server have to use a unique port number.

You can enable or disable the Allow Channels On a Driver to Share the Same Listen Port feature in the Channels settings on the Server Configuration Tool:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree structure.
  3. Select Channels to display the Channels section.
  4. In the Network section, select or clear the Allow Channels on a Driver to Share the Same Listen Port check box to enable or disable the feature respectively.

If you enable the Allow Channels on a Driver to Share the Same Listen Port feature, any outstation on the system can initiate a connection by using a single port number (the Listen Port number). The channel that is configured to use the matching Listen Port number is either used for the connection or redirects the connection to the appropriate channel. This means that the outstations can use the same port number to connect into the ClearSCADA server.

If you disable the Allow Channels on a Driver to Share the Same Listen Port feature, each channel will need to define a unique Listen Port, which may mean extra configuration is required at your outstations (and you may have to compromise when using equipment with fixed port numbers for initiating connections).

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished defining the Allow Channels on a Driver to Share the Same Listen Port setting, you can either configure other Channels settings:

  • Define the Settings for Channel Scanning Statistics Trends.
  • Define how a PSTN Channel is Selected for Communications.
  • Define the Settings for Modems
  • Define the Settings for COM Ports and TCP/IP Connections.

Or:

  • Continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Driver Settings.

Further Information

Listen Port: Please refer to the ClearSCADA Guide to Advanced Drivers.


Server Administration Guide - Outstation Settings

Outstation Settings

You can use the Outstations section of the ClearSCADA Server Configuration Tool to:

  • Define the Default Promoted Dial Out Settings.
  • Define the Point Update Setting
  • Define the Time Zone for the Dial In Overactive Feature.


Server Administration Guide - Define the Default Promoted Dial Out Settings (Outstation Settings)

Define the Default Promoted Dial Out Settings

You can use the Outstations section display of the ClearSCADA Server Configuration Tool to change the default promoted outstation settings.

Some outstations can be promoted temporarily so that they are scanned in preference to other outstations. This is useful during times of important operation procedures, for example, when feedback is required following a control being issued.

The default promoted dial out settings define the amount of time between each dial out to a promoted outstation and the total amount of time each outstation is promoted. They also determine whether a One Shot data retrieval is performed as soon as an outstation is promoted, or whether the One Shot only occurs after the first interval.

When an operator uses the Promote Dial Out action for an outstation or outstation set, a Promoted Dial Out window is displayed. The operator can use the Promoted Dial Out window to define the amount of time for which the outstation will be promoted, and the amount of time between each dial out. The settings that you define on the Outstations section are the settings that are in place when any operator uses the Promote Dial Out action—the operators can change the settings for the individual outstation promotion action that they are performing, but they cannot alter the settings that are shown by default.

To change the default promoted outstation settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Outstations to display the Outstations section.
  4. Define the default start time for dialing out to a promoted outstation in the Offset field. The time you enter in the Offset field defines when the first dial out (attempt by the server to request data from an outstation) will occur. Subsequent dial-outs will take place at the time defined by the Interval.

You need to define the time in the OPC time interval format, for example, 25M for 25 minutes.

  5. Define the default amount of time between each dial out to a promoted outstation in the Interval field. A dial out is an attempt by the server to request data from an outstation.

You need to define the time in the OPC time interval format, for example, 25M for 25 minutes.

  6. Define the default maximum time for which an outstation is promoted in the Duration field.

You need to define the time in the OPC time interval format, for example, 3H for 3 hours.

  7. Define whether a One Shot is performed immediately on each promoted outstation by default. The One Shot is performed as soon as the outstation is promoted or whether there is a delay before the One Shot occurs (the delay is the Interval):
  • Select the Immediate One Shot check box to specify that a the first dial out occurs immediately when an outstation is promoted. This means that data is retrieved as quickly as possible, which is useful in emergency situations such as when flooding occurs.
  • Clear the Immediate One Shot check box to specify that the first dial out occurs after the end of the first interval when an outstation is promoted. This is useful when an outstation has dialled in and reported an alarm, which then triggers an alarm redirection action to promote the dial out of the same outstation.
  8. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When an outstation or outstation set is promoted, it uses the default settings that you have defined, unless the settings are changed by the user.

When you have finished defining the default Promoted Dial Out settings, you can either Define the Point Update Setting or continue with the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Points Settings.

Further Information

For more details on the OPC time format, see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.

For more information on scanning outstations (both direct outstations and PSTN outstations), see the ClearSCADA Guide to Advanced Drivers.


Server Administration Guide - Define the Point Update Setting (Outstation Settings)

Define the Point Update Setting

Each outstation has various statistics for the points that are associated with the outstation. These statistics are renewed whenever the points are updated. When the server is updated, it notifies the relevant clients about the changes to the outstation statistics. This allows the clients to display the latest data on Mimics, Lists etc.

You can use the Raise interest every n point setting on the ClearSCADA Server Configuration Tool to define when the clients are notified of changes. The Raise interest every n point setting defines how many point updates (on a single outstation) have to occur before the clients are notified of the changes to the outstation. The clients will only be notified of the changes when an outstation has been updated the defined number of times. This reduces the load on the system, as the Mimics, Lists etc. will update less frequently. This is especially useful when clients are displaying Mimics or Lists that show the data of many outstations simultaneously.

The lower the point update setting, the more often the server will update the Mimics, Lists etc. This can cause slower performance as there can be an excessive number of updates.

To define the point update settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Outstations
    The Outstations display is shown.
  4. In the Raise Interest Every n Point Updates, enter the number of point values that have to change before the server will notify the relevant clients of the change to an outstation's point statistics. The lower the value, the more updates will occur and the greater the system load will become. Higher values will result in the outstation point statistics being updated less frequently on client displays.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have defined the Raise interest every n point setting, you can either continue to Define the Time Zone for the Dial In Overactive Feature on the Outstations section, or you can continue with the rest of the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Points Settings.


Server Administration Guide - Define the Time Zone for the Dial In Overactive Feature (Outstation Settings)

Define the Time Zone for the Dial In Overactive Feature

The Dial In Overactive feature allows you to configure a PSTN outstation so that an alarm is raised if the outstation dials in too many times in a particular time period. For example, if an outstation dials in more than 5 times in a day. You can also use the Dial In Overactive feature to configure an outstation so that an event is logged if the outstation dials in too frequently. (For more information, see Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently in the ClearSCADA Guide to Advanced Drivers).

NOTE: The Dial In Overactive feature is only available for use by PSTN outstations that support dial ins.

Many of the Dial In Overactive configuration settings are defined on the Outstation Form. However, you need to use the Server Configuration Tool to define the time zone for the Dial In Overactive time periods that are configured on the outstations. For example, if the outstation is configured to have an interval of one day and is synchronized to midnight, you can use the Time Zone setting to define whether midnight is midnight UTC or midnight local time (see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration).

The time zone is defined in the Global Parameters>Outstations settings on the Server Configuration Tool.

To define the time zone for the dial in overactive feature:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Outstations
    The Outstations display is shown.
  4. In the Dial In Overactive section, use the Time Zone combo box to choose the required time zone settings.
    You can choose from:
  • Coordinated Universal Time (UTC)—The system will use UTC to calculate the actual time of the start and end of the time period.
  • Local Time without Daylight Saving Time—The system will use local time to calculate the actual time of the start and end of the time period. For example, if the local time zone is EST (Eastern Standard Time), the system will use EST (the time for the east coast of the United States of America) in its calculation to determine the start time and end time of the time period. No adjustments are made for Daylight Saving Time (DST).
  • Local Time with Daylight Saving Time—This works in the same way as the Local Time without Daylight Saving Time option except that Local Time with Daylight Saving Time instructs the system to automatically adjust the time to allow for Daylight Saving Time (DST) adjustments.

NOTE: Using DST means that during the transition to/from DST, the overactive dial-in period will be extended or shortened. For example, a period of one day will become 25 hours or 23 hours (assuming one hour adjustment).

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have defined the Time Zone setting, you can continue to Define the Default Promoted Dial Out Settings or Define the Point Update Setting on the Outstations section, or you can continue with the rest of the server configuration.

If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about Points Settings.


Server Administration Guide - Points Settings

Points Settings

You can use the Points section of the ClearSCADA Server Configuration Tool's Global Parameters to:

  • Define the Colors for Point Trend Graphs—You can use the Graphs settings to define the color for the alarm limits and background on each point's Trend Graph.
  • Define the Point Data Time Window—You can use the Time Window settings to specify the permittable range of time stamps. Point data that has time stamps outside of the specified time range is recognized as invalid.
  • Define the Maximum Outstation Clock Drift—You can use the Future Data settings to define the maximum permitted amount of clock drift.


Server Administration Guide - Define the Colors for Point Trend Graphs (Points Settings)

Define the Colors for Point Trend Graphs

Each point in the database has at least one default Trend Graph (points with Historic data have 2—one for current data and one for Historic data). Each of these Trend Graphs can be setup to display lines that indicate the alarm limits for the data that is shown on the Graph. You can use the ClearSCADA Server Configuration Tool to define the color of the alarm limits on Trend Graphs.

You can also use the ClearSCADA Server Configuration Tool to define the color of the background on Trend Graphs for points.

To define the colors for point Trend Graphs:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Points to display the Points section.
  4. Use the color buttons in the Graphs box to define the default settings:
  • Use the Alarm Limits color button to choose the default color for the alarm limits on Graphs. When you select the color button, the Color palette is displayed. You can use the color palette to select an existing color or create a custom color. The color that you choose is used by each Point Trend.
  • Use the Background color button to choose the default color for the background of Graphs. When you select the color button, the Color palette is displayed. You can use the color palette to select an existing color or create a custom color. The color that you choose is used by each Point Trend.

NOTE: For more information on the color palette, see Using the Color Window in the ClearSCADA Guide to Mimics.

  • Use the Use Client Default check box to set the graphs to use the default color schemes that are in place on each client PC. Select the check box to use the client color schemes, or clear it to use a custom color scheme (the color scheme you specify).
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

You can now continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you either:

  • Define some of the other Points settings:
  • Define the Point Data Time Window.
  • Define the Maximum Outstation Clock Drift.

or:

  • Proceed to define the other server configuration settings.


Server Administration Guide - Define the Point Data Time Window (Points Settings)

Define the Point Data Time Window

You can use the ClearSCADA Server Configuration Tool to define the permittable time windows for point values. The time window allows you to specify the time range of permittable time stamps of point data. Any point data with time stamps outside the defined range is regarded as invalid and is not used to update the point. A common cause of invalid time stamps is a faulty or incorrect clock in an outstation.

Any point data that has time stamps outside of the defined time window is not used—the point's data is not updated and the point's status changes to indicate that an invalid value has been reported.

You need to define the point data time window settings in accordance with your company policy, taking into consideration the system requirements and its equipment.

To define the time window for point values:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Points to display the Points section.
  4. Use the Time Window box settings to define the range of permittable time values:
  1. In the top From field, define the start of the time window. This is defined as n number of days prior to the current day. For example, if you wanted to define the time window as beginning 2 years ago, enter 730. The day that you define begins at 00:00.
  2. In the To field, define the end of the time window. This is a time in the future that allows points to have dates in the future due to faulty or inaccurate clocks in the outstations, PLCs etc.

The end of the time window is n number of hours in the future. The number of hours is based on hours from the current minute. For example, if you enter 10 hours in the future and the current time is 14:05, the end of the time window is 24:05.

NOTE: The bottom From field and the To field show the actual start time and end time of the time window. This is only updated when you apply the changes.

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

You can now continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you either:

  • Define some of the other Points settings:
  • Define the Colors for Point Trend Graphs.
  • Define the Maximum Outstation Clock Drift.

or:

  • Proceed to define the other server configuration settings.


Server Administration Guide - Define the Maximum Outstation Clock Drift (Points Settings)

Define the Maximum Outstation Clock Drift

The clocks in outstations and similar devices can drift due to environmental conditions. This can cause the outstations to no longer be synchronized with the ClearSCADA system.

You can use the Future Data settings to define the maximum permitted amount of clock drift. Any values that have time stamps in the future by more than the maximum clock drift amount of time are regarded as future values. These values cause the point status to change to indicate that the values have a timestamp that is in the future (this is shown on the Historic List for the point).

ClearSCADA indicates which data is marked as future data so that users can recognize that the time stamps for the relevant points are unreliable.

When defining the maximum clock drift, you need to consider:

  • The accuracy of the clocks in the outstations, PLCs etc. This will vary depending on the model of outstation, PLC etc.
  • How often the clocks are set—clocks that not set regularly are more likely to drift by a significant amount.

To define the maximum amount of clock drift permitted:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Points to display the Points section.
  4. Use the setting in the Future Data box to define the maximum clock drift:
  • Enter the permitted amount of clock drift in the Maximum allowed clock drift field. The data is marked as future data if it is in the future by more than the maximum allowed clock drift.
  • The lower the number of seconds, the more likely it is that data will be marked as future data, even though the clocks in the outstations, PLCs etc. may only have drifted by a small amount.
  • The higher the number in seconds, the more likely it is that data will not be marked as future data. This means that the data may not be marked as future data even though it is time stamped with a time that is significantly in the future.

You need to set the maximum allowed clock drift to a time that is suitable for your requirements.

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

You can now continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you either:

  • Define some of the other Points settings:
  • Define the Colors for Point Trend Graphs
  • Define the Point Data Time Window.

or:

  • Proceed to define the other server configuration settings.


Server Administration Guide - Alarms Settings

Alarms Settings

You can use the Alarms section of the ClearSCADA Server Configuration Tool to:

  • Define whether alarms and events are raised/logged on your system (see Enable/Disable Alarms and Events).
  • Define the cookie range for alarms on each server in a multi-server system (see Define the Cookie Range for Alarms). You need to configure each server to use a different range of cookies.
  • Define the availability and functionality of the Disable Alarms action (see Define the Disable Alarms Settings).
  • Enable or Disable the Alarm Response Feature
  • Enable or Disable the Area of Interest Feature
  • Define whether the Visible Time is used as the Active Alarm Time
  • Define Standard Alarm Acknowledgment Comments


Server Administration Guide - Enable/Disable Alarms and Events (Alarms Settings)

Enable/Disable Alarms and Events

You can use the ClearSCADA Server Configuration Tool to define whether the alarm and event feature is enabled or disabled on your system. Typically, you would enable the alarm and event feature so that alarms are raised when specific conditions occur and system events, such as the configuration of items being altered, are logged. However, you can disable the alarm and events feature if required, for example, if ClearSCADA is only being used as a data logging application.

To enable or disable the alarm and events feature:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select Alarms to display the Alarms section.
  4. Select or clear the Alarms and Events Enabled check box as required:
  • Select the Alarms and Events Enabled check box to allow ClearSCADA to raise alarms and log events on your system.

When the alarms and events feature is enabled, the OPC Alarm and Event interface can send alarms and event messages to clients. This means that:

  • Alarms are displayed in the various alarm interfaces, such as the Alarm Banner
  • Event messages are shown in the event message display in the taskbar
  • You can use the menus and context sensitive menus to gain access to the alarm displays and the various alarm response actions.
  • Clear the Alarms and Events Enabled check box to disable the alarm and events features on your system.

When the alarms and events feature is disabled, the OPC Alarm and Event interface cannot send alarms and event messages to clients. As a result of this:

  • Alarms are not displayed in the various alarm interfaces, such as the Alarm Banner
  • Event messages are not shown in the event message display in the taskbar
  • You cannot access the alarm displays and the various alarm response actions.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

If you enabled alarms and events, you can define the other Alarms settings:

  • If the server that you are configuring is part of a multi-server system (Hot Standby Pair, Triple Standby etc.), you need to configure the servers to use different cookie ranges.This is to stop the servers from allocating the same cookie to different alarms (see Define the Cookie Range for Alarms).
  • The Disable Alarms features are optional (see Define the Disable Alarms Settings).
  • The Alarm Response feature is optional (see Enable or Disable the Alarm Response Feature).

If you disabled the alarm and events feature, you can ignore the other Alarms settings.

You can now proceed with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to E-Mail Settings.


Server Administration Guide - Define the Cookie Range for Alarms (Alarms Settings)

Define the Cookie Range for Alarms

When an alarm is raised in ClearSCADA, the Main ClearSCADA server allocates a unique number to the alarm. This number is called a ‘cookie’ and it is used when users respond to alarms via:

  • E-mail
  • SMS
  • External applications that can be used to acknowledge an alarm, for example, the telephony system, Envox.

NOTE: ClearSCADA can identify alarms from responses made from ViewX or WebX clients without the need for alarm cookies.

A ClearSCADA system can have a maximum of 65535 alarms raised simultaneously. So, the range of alarm cookies is 1-65535, where 1 is initially assigned to the first alarm raised on the Main server, 2 to the second alarm, 3 to the third alarm and so on. If the maximum limit of 65535 is reached, ClearSCADA will try to remove the oldest acknowledged alarm so that it can re-use the cookie of that alarm. If there are no acknowledged alarms, ClearSCADA will attempt to remove the oldest text alarm. If there are no acknowledged alarms or text alarms, ClearSCADA will remove the oldest active alarm.

For example, if the alarm cookie limit is reached and a new alarm is raised, ClearSCADA will attempt to remove an old alarm. Let’s assume that there are 5 acknowledged alarms which have the cookies 3, 7, 9, 11, and 12. Of these alarms, the alarm with cookie 7 is the oldest. So ClearSCADA removes the alarm with cookie 7 (as it is the oldest acknowledged alarm) and then uses cookie 7 for the new alarm.

On a single server system, the default Cookie Range of Lowest Cookie ID: 1, Highest Cookie ID: 65535 is appropriate and should not be changed.

However, you should define unique Cookie Ranges for each server if:

  • Your system is a multi-server system which can have a Main-Main or Main-Main-Main situation (the servers do not have Go Isolated Standby as their Action on Isolated setting)

and

  • You want users to respond to alarms via e-mail, SMS or external applications.

If both of the above points apply to your system, you should configure the Cookie Ranges so that they are unique and do not overlap.

By defining Cookie Ranges that do not overlap, you can:

  • Stop user alarm responses (made via e-mail, SMS or external applications) from failing unnecessarily.
  • Stop user alarm responses from being applied to the wrong alarms. When external applications are used to acknowledge alarms, it is possible that a user’s response could be applied to a different alarm than intended. This can only happen following a Main-Main or Main-Main-Main situation and can be avoided by defining unique Cookie Ranges.

(Examples of the situations described above are included at the end of this section).

When defining the Cookie Range for servers in a multi-server system, you should allocate a suitable portion of the entire Cookie Range to each server (excluding Permanent Standby servers). You do not have to configure the servers to have equal shares of the available cookies. In fact, it is usually preferable to allocate the largest portion of available cookies to the server that will run as the Main server more often. For example, if you have a triple server system, where Server A is the principal Main server, with Server B as the preferred back up and Server C as a third back up, you could allocate 1-40000 to Server A, 40001-60000 to Server B, and 60001-65535 to Server C.

NOTE: Leave the default settings of Lowest Cookie ID: 1, Highest Cookie ID: 65535 in place for Permanent Standby servers. These servers only function as Standby servers and so cannot allocate cookies.

To define the cookie range for a server:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select Alarms to display the Alarms section.
  4. Select the Alarms and Events Enabled check box so that ClearSCADA can raise alarms and log events.
  5. Define the cookie range:
  • In the Lowest Cookie ID field, enter the lowest number that the server can allocate to an alarm. This number defines the start of the cookie range for the server you are configuring.
  • In the Highest Cookie ID field, enter the highest number that the server can allocate to an alarm. This number defines the end of the cookie range for the server you are configuring.

The server can only allocate cookies that are numbered within the specified range. For example, if you defined the lowest cookie as 1 and the highest cookie as 200, the server could only allocate cookies numbered 1-200 inclusive and so there could be a maximum of 200 alarms raised when the server is Main.

  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Examples:

Example 1: Preventing E-mail Alarm Responses from Failing Unnecessarily

In this example, we will begin by showing what can happen if two servers use the same cookie range, and a user responds to an alarm via E-mail during a Main-Main situation. Then we will show how the resulting situation can be avoided by using unique Cookie Ranges.

On a Hot-Standby Pair system, both Server A and Server B have the default Cookie Range of 1-65535 in place. When the servers start, Server A becomes the Main server and Server B becomes the standby server. Both servers have Duty mode enabled so that if a Main-Main situation occurs, ClearSCADA will attempt to merge the data from the two servers when the Main-Standby relationship is re-established.

Alarm conditions are detected and so Server A generates alarms. Server A allocates a unique cookie to each alarm, starting with cookie 1 for the first alarm, cookie 2 for the second alarm and so on. During this time, Server B is in Standby mode and so does not allocate cookies.

A network failure occurs between Server A and Server B, which causes a Main-Main situation (Server A and Server B are both acting as isolated Main servers). Server A continues to allocate cookies to alarms that are raised on Server A. However, as Server B is now a Main too, Server B also allocates cookies - to the alarms that are raised on Server B.

An alarm on Server B has the cookie 5. It is redirected to a user in the form of an e-mail. The user receives an e-mail relating to the alarm and the e-mail contains the alarm cookie (cookie 5) and the Condition Name and Object ID of the database item in alarm. To acknowledge the alarm, the user has to use a defined Acknowledgment Keyword in their reply to the e-mail.

As the user is creating the e-mail, the Main-Main situation is resolved. Server A and Server B arbitrate to determine which server is Main. Server A ‘wins’ and becomes the Main. The servers use Duty mode, so ClearSCADA attempts to merge the alarm data on Server A with the alarm data on Server B. Both servers have different alarms that use the same cookies. To rectify this, ClearSCADA examines the cookies on the ‘losing’ server, which in this case is Server B. ClearSCADA creates new cookies for every alarm on Server B that uses a cookie that is already in use on Server A.

So the alarm with cookie 5 on Server A retains its cookie, whereas the alarm with cookie 5 on Server B loses its cookie (a new cookie is generated for the Server B alarm).

The user then sends their e-mail response to the alarm. The e-mail contains the Alarm Acknowledgment keyword, the alarm cookie (5), and the Condition Name and Object ID of the item in alarm.

ClearSCADA receives the e-mail and processes it. It tries to match the alarm details in the e-mail to an alarm on the server. While ClearSCADA can find an alarm that has the defined Condition Name and Object ID, the cookie for that alarm does not match (as ClearSCADA removed cookie 5 from the alarm and replaced it with a new cookie as part of the merge process during arbitration). As ClearSCADA cannot locate an alarm that has the Object ID, Condition Name and cookie defined in the e-mail, the user’s e-mail response fails (even though the alarm that the user was trying to acknowledge still exists on the system).

This situation could have been avoided by allocating a unique Cookie Range to Server A and Server B. Let’s say that Server A had been configured to use the Cookie Range 1-40000 and Server B to use the Cookie Range 40001-65535. With these unique Cookie Ranges in place, the alarms that were raised on Server B during the Main-Main situation would have been allocated cookies 40001 onwards. So when the Main-Main situation was resolved, and the alarm data from the two servers was merged, ClearSCADA would not have needed to remove the cookies from Server B’s alarms (as their cookies would not conflict with the cookies allocated by Server A).

ClearSCADA would have been able to match the alarm details in the user’s e-mail response, as the cookie would not have changed on the server.

Example 2: Preventing External Application Alarm Responses from Being Applied to Different Alarms

In this example, we will begin by showing what can happen if two servers use the same cookie range and a Main-Main situation occurs. Then we will show how the resulting situation can be avoided by using unique Cookie Ranges.

On a Hot-Standby Pair system, both Server A and Server B have the default Cookie Range of 1-65535 in place. When the servers start, Server A becomes the Main server and Server B becomes the standby server. Both servers have Duty mode enabled so that if a Main-Main situation occurs, ClearSCADA will attempt to merge the data from the two servers when the Main-Standby relationship is re-established.

Alarm conditions are detected and so Server A generates alarms. Server A allocates a unique cookie to each alarm, starting with cookie 1 for the first alarm, cookie 2 for the second alarm and so on. During this time, Server B is in Standby mode and so does not allocate cookies.

A network failure occurs between Server A and Server B, which causes a Main-Main situation (Server A and Server B are both acting as isolated Main servers). Server A continues to allocate cookies to alarms that are raised on Server A. However, as Server B is now a Main too, Server B also allocates cookies - to the alarms that are raised on Server B.

So Server B starts allocating cookies to its alarms. For the first alarm, it uses cookie 1, the second alarm, cookie 2 and so on. Of course, the same cookie numbers are already in use on Server A.

An alarm on Server B has the cookie 14. It is redirected to a user. The user receives an email relating to the alarm and the email contains the alarm cookie. The user responds via a tool specifically developed for their system (for example, a telephony system such as Envox). The tool calls the AcceptAlarmsByCookie method for the database item that has the alarm with cookie 14.

As the user is responding, the Main-Main situation is resolved. Server A and Server B arbitrate to determine which server is Main. Server A ‘wins’ and becomes the Main. The servers use Duty mode, so ClearSCADA attempts to merge the alarm data on Server A with the alarm data on Server B. Both servers have different alarms that use the same cookies. To rectify this, ClearSCADA examines the cookies on the ‘losing’ server, which in this case is Server B. ClearSCADA creates new cookies for every alarm on Server B that uses a cookie that is already in use on Server A.

So the alarm with cookie 14 on Server A retains its cookie, whereas the alarm with cookie 14 on Server B loses its cookie (a new cookie is generated for the Server B alarm).

The user response to the alarm is received by the Main ClearSCADA server. The AcceptAlarmByCookie method is called for the alarm with cookie 14. So ClearSCADA acknowledges the alarm with cookie 14, which is the alarm from Server A, not the alarm from Server B (which now has a new cookie). So as a result of the two servers using the same Cookie Range, the user has acknowledged a different alarm than intended.

This situation could have been avoided by allocating a unique Cookie Range to Server A and Server B. Let’s say that Server A had been configured to use the Cookie Range 1-40000 and Server B to use the Cookie Range 40001-65535. With these unique Cookie Ranges in place, the alarms that were raised on Server B during the Main-Main situation would have been allocated cookies 40001 onwards. So when the Main-Main situation was resolved, and the alarm data from the two servers was merged, ClearSCADA would not have needed to remove the cookies from Server B’s alarms (as their cookies would not conflict with the cookies allocated by Server A).

The user’s response to the alarm, made via an external application, would be applied to the intended alarm, as the cookie for the alarm would be unique. There would be no alarms on Server A with that cookie.

When you have finished defining the Cookie Range settings, you can either Define the Disable Alarms Settings or continue with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about E-Mail Settings.

Further Information

Duty Mode: see Enable or Disable Duty Mode

System Architectures

Alarm Redirection: see Introduction to Alarm Redirection in the ClearSCADA Guide to Alarm Redirection

Acknowledging an Alarm via Email: see Use an E-Mail Action to Enable an Engineer to Acknowledge Alarms Remotely in the ClearSCADA Guide to Alarm Redirection

Acknowledging an Alarm By Cookie: see Trip Sequences Supported by Redirection Actions in the ClearSCADA Guide to Alarm Redirection.


Server Administration Guide - Define the Disable Alarms Settings (Alarms Settings)

Define the Disable Alarms Settings

You can use the ClearSCADA Server Configuration Tool to define whether alarms can be disabled.

An alarm can be inhibited for specific items or Groups in the database. When an item has its alarms disabled, there are no alarms raised for the item, even if it has values or states that corresponds to a defined alarm condition.

You can also use the ClearSCADA Server Configuration Tool to define whether alarms are disabled for:

  • An infinite amount of time. Alarms are not raised until the alarms are enabled for the item.
  • A pre-defined amount of time (defined by a system administrator). The alarms for the item will be de-activated for a specific amount of time. When the specified time has elapsed, alarms are automatically enabled for the item.
  • A variable amount of time (defined by an engineer or operator). The alarms for the item will be de-activated for an operator-defined amount of time. The operator can define any amount of time up to the Maximum Duration amount as defined on the Alarms section of the ClearSCADA Server Configuration Tool.

It is also possible to configure alarms so that they cannot be disabled.

NOTE: As an alternative to disabling alarms, you can use the Alarms Suppression feature to restrict certain active alarms so that they are not shown in the Alarms List and Alarm Banner (see Alarm Suppression in the ClearSCADA Guide to Alarms).

To define whether alarms can be disabled (and the amount of time for which they remain disabled):

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select Alarms to display the Alarms section (you need to use the settings in the Disable Alarms box).
  4. Select the Alarms and Events Enabled check box (at the top of the Alarms section) to allow ClearSCADA to raise alarms and log events.
  5. Use the Option combo box in the Disable Alarms section to define how the Disable Alarms feature works. Choose from:
  • Not Allowed (Always Enabled)—The Disable Alarms feature is deactivated. Alarms cannot be disabled. If you selected this option, skip steps 6 and 7 and proceed to step 8.
  • Infinite (No Timeout)—When alarms are disabled, they remain disabled until they are enabled by a user, Logic program etc. If you selected this option, skip steps 6 and 7 and proceed to step 8.
  • Fixed Duration—When alarms are disabled, they are disabled for a specified duration. You enter the duration in the Duration field (see step 6). When the duration expires, the alarms are enabled again. The alarms can also be enabled by a user or Logic program etc. during the Duration time period.
  • Variable Duration—When alarms are disabled, they are disabled for a specified duration (or up until the alarms are enabled by a user, Logic program etc.). The duration is defined by the operator when the alarms are disabled, although the default amount is defined in the Duration field in the Alarms section (see step 6). The operator cannot enter an amount of time that exceeds the Maximum Duration (see step 7).
  6. Enter the amount of time for which the alarms are disabled in the Duration field.
  • If you used the Option combo box to select Fixed Duration, the amount of time that you enter in the Duration field defines the timespan for which the alarms are disabled. For example, if you enter 1H, and an operator uses the Disable Alarms action on a point, alarms will not be raised for the point for 1 hour. The alarms will become active after 1 hour or when an operator uses the Enable Alarms action for the point.

If you defined a Fixed Duration, proceed to step 8.

  • If you used the Option combo box to select Variable Duration, the amount of time that you enter in the Duration field defines the default timespan for which alarms are disabled. The default time can be overridden by the operator when the alarms are disabled. However, the operator cannot disable the alarms for a greater amount of time than the defined Maximum Duration period (see step 7).

If you defined a Variable Duration, proceed to step 7.

  7. Enter the longest amount of time for which the alarms can be disabled in the Maximum Duration field. This setting is only available when the Option combo box is set to Variable Duration.

NOTE: If you enter 0 as the Maximum Duration, the alarms can be disabled for any amount of time that the operator specifies—there is no maximum duration.

  8. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished defining the Disable Alarm settings, you can proceed to define the availability of the alarm response feature (see Enable or Disable the Alarm Response Feature) or you can continue to define the other server configuration settings. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about E-Mail Settings.


Server Administration Guide - Enable or Disable the Alarm Response Feature (Alarms Settings)

Enable or Disable the Alarm Response Feature

You can use the ClearSCADA Server Configuration Tool to enable and disable the Alarm Response feature.

The Alarm Response feature allows users to associate a text string with each alarm. This is similar to the Acknowledge with Comment feature, except that the Alarm Response feature does not affect the state of the alarm (it does not acknowledge the alarm; it simply associates a response message with the alarm). The response message can be seen on the View status display, and in the Event Journal.

To enable or disable the Alarm Response feature:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch.
  3. Select Alarms.
  4. In the Alarm Response section, either:
  • Select the Enabled check box to allow users to associate a text string with each alarm.

Or:

  • Clear the Enabled check box to disable the Alarm Response feature. Users will not be able to associate a text string with each alarm.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished enabling/disabling the Alarm Response feature, you can proceed to define the availability of the alarm response feature Enable or Disable the Area of Interest Feature or you can continue to define the other server configuration settings. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about E-Mail Settings.


Server Administration Guide - Enable or Disable the Area of Interest Feature (Alarms Settings)

Enable or Disable the Area of Interest Feature

Each User account can be configured to have up to 4 Areas of Interest. These Areas determine which alarms are shown in the Alarm Banner and Alarm List for the user.

Every database item that can cause an alarm to be raised can be associated with an Area of Interest. When an alarm is raised for the item, the alarm will only be visible to those users that have access to the relevant Area of Interest. The Areas of Interest that can be accessed by a user are defined on the User Form, and each User account can be associated with up to 4 different Areas. For more information, see Define the Areas of Interest for a User.

The Area of Interest feature is only available (i.e. can only be configured on User Forms) if you enable it on the Alarms section of the System Configuration settings on the ClearSCADA Server Configuration Tool.

To enable or disable the Area of Interest feature:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch.
  3. Select Alarms.
  4. In the Area of Interest section, either:
  • Select the Enabled check box to allow user accounts to be configured to have Areas of Interest. Only those alarms that relate to a user's Areas of Interest will be shown in the Alarm Banner, Alarm List etc.

Or:

  • Clear the Enabled check box to disable the Area of Interest feature. User accounts will not be able to have Areas of Interest (and so the Alarm displays will show alarms for those items to which the logged on user has access).
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished enabling/disabling the Areas of Interest feature, you can proceed to Define Standard Alarm Acknowledgment Comments or you can continue to define the other server configuration settings. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about E-Mail Settings.


Server Administration Guide - Define whether the Visible Time is used as the Active Alarm Time (Alarms Settings)

Define whether the Visible Time is used as the Active Alarm Time

You can use the ClearSCADA Server Configuration Tool to enable and disable the Use Visible Time as Active Alarm Time feature.

The Use Visible Time as Active Alarm Time feature is designed for use on systems where alarms are suppressed (see Alarm Suppression in the ClearSCADA Guide to Alarms). It sets ClearSCADA to show formerly suppressed alarms near the top of the Alarm Banner and Alarms List.

By default, alarm displays such as the Alarm Banner and Alarms List show alarms according to the State, Severity and Time values of the alarm. This means that new alarms are usually displayed near the top of the Alarm Banner or Alarms List, where they are prominent.

When an alarm is suppressed, it is raised in the same way as any other alarm, but it is not shown on the various Alarm Displays. When a suppressed alarm becomes unsuppressed, it is shown on the Alarm Displays, but as this may be some time after the alarm was generated, it may not be shown at the top of the list. This can be a concern on systems with a high number of alarms, as when alarms become unsuppressed, they could be too far down the list of alarms to be noticed immediately.

To avoid such a situation, you can enable the Use Visible Time as Active Alarm Time feature. With Use Visible Time as Active Alarm Time enabled, ClearSCADA orders suppressed alarms according to the time at which they become unsuppressed, instead of the time at which they were generated. This means that when a suppressed alarm becomes unsuppressed, it is treated as a new alarm and is displayed near the top of the Alarm Banner and Alarms List.

For example, let’s say a point alarm was raised at 13/07/2010 10:50:48.249 but the point is suppressed and so the alarm is not shown on the alarm displays. At 14/07/2010 08:30:00.000, the point alarm becomes unsuppressed, and so it is added to the Alarm Banner and Alarms List - the alarm displays treat the alarm as if it had been generated at 14/07/2010 08:30:00.000 (the time it became unsuppressed), so it appears near the top of the list.

To define whether the Use Visible Time is as the Active Alarm Time feature is enabled:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch.
  3. Select Alarms.
  4. In the Use Visible Time as the Active Alarm Time section, either:
  • Select the Enabled check box to set ClearSCADA to order formerly suppressed alarms according to the time at which they became unsuppressed (instead of the time they were originally generated).

Or:

  • Clear the Enabled check box to configure ClearSCADA so that it orders suppressed alarms according to the time at which they were generated. This may cause suppressed alarms to appear some way down the list of alarms when they become unsuppressed.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define Standard Alarm Acknowledgment Comments (Alarms Settings)

Define Standard Alarm Acknowledgment Comments

When a user selects the Acknowledge with Comment action, they change the status of the alarm to indicate that it has been seen and is being dealt with, and they also leave a short message (comment). Typically, the comment provides a brief description of what is being done about the conditions that caused the alarm to be raised, or informs other users that they can ignore the alarm.

By default, there are no standard alarm acknowledgment comments. That means that any user that uses the Acknowledge with Comment action has to enter a comment using their own words. By using the Standard Alarm Acknowledgment Comments feature, you can configure standard comments that are available to users from a spin-box—users can choose to select one of the standard comments instead of entering their own comments. This is useful when you need your system to have consistent comments that are descriptive and indicitive of the alarm situation.

To define the Standard Alarm Acknowledgment Comments for your system:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch.
  3. Select Alarms.
  4. In the Alarm Acknowledgment Comments section:
  1. Select the Add button.
    A new comment is added to the list.
  2. Enter the text for the comment.
  3. Repeat steps i and ii for each comment that you want to be available for selection.

To remove one of the comments, select the comment in the list and then select the Remove button.

  4. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
    The comments you entered are now available for selection when a user selects the Acknowledge with Comment action.

When you have finished defining the Standard Alarm Acknowledgment Comments, you can continue to define the other server configuration settings. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about E-Mail Settings.


Server Administration Guide - Dictionary Settings

Dictionary Settings

You can use the ClearSCADA Server Configuration Tool to associate the server with a dictionary folder that contains dictionary files. This allows the server, ViewX and WebX clients to search the dictionary files for specific strings and replace them with 'translations'. This is useful for translating user-created strings into different languages and also for allowing for different terminology.

To substitute user-created strings with alternate strings, a dictionary folder is required. The dictionary folder has to be associated with a server, and is used to contain ‘dictionary files’ - files that have been configured to contain search strings and replacement strings.

In the following sections, we explain the Dictionaries feature and describe how to create dictionary files and associate the server with a dictionary folder:

  • Understanding the Dictionary Feature
  • Creating Dictionary Files for Translating System Information
  • Associating a System with Dictionary Files.

You should familiarize yourself with each of these sections before setting up your server to use the dictionary feature.

For information on configuring a string for translation (by prefixing it with the @ character), see Defining the Format of Displayed Values in the ClearSCADA Guide to Core Configuration.


Server Administration Guide - Understanding the Dictionary Feature (Dictionary Settings)

Understanding the Dictionary Feature

The dictionary feature allows user-created strings to be 'translated' i.e. replaced with alternate strings for a variety of features, including:

  • Mimics
  • Trends
  • Query Lists
  • Data Grids
  • Data Tables
  • Alarm Severities
  • Alarm List Column Entries
  • Point State Descriptions.

The Dictionary feature is often used for translating user-created strings into another language and replacing terminology (for example, terms that are not widely understood). It works by allowing system users to mark strings for translation with a @ prefix. Then, either a ClearSCADA server or client will search for that marked string in dictionary files. When the marked string is located, ClearSCADA will read the translation for the string, and then use the translation instead of the marked string on Mimics, Trends, Lists, etc.

The Dictionary works with many ClearSCADA features, but requires:

  • Dictionary files to be configured so that they contain user-created strings (search strings) and replacement strings (translations). There are three types of dictionary file, and ClearSCADA will search them in order:
  1. Country-specific file
  2. Region independent file
  3. Default dictionary file.

NOTE: ClearSCADA can only search the Country-specific file and Region independent file if the Locale of the logged on user and the dictionary files are the same (see Creating Dictionary Files for Translating System Information). The locale of the user is defined in the User account configuration and the locale of the dictionary files is defined in the name of the files.

  • Dictionary files to have names that indicate the language and region, for example, fr-CA.txt represents French language, Canadian region. This defines the Locale of the dictionary file.
  • The dictionary files to be configured so that there is a search string and replacement string on each line. Each string has to be enclosed in double quotes " " and there has to be one search string and its replacement string, separated by a comma, on each line. For example:

"low water level", "niveau bas d'eau"

  • Users to log on via User accounts that have the same Locale setting as the locale of the dictionary files. For example, if a user is logged on via a User account that is set to English (US) and the dictionary file is fr-CA.txt (for French language, Canadian region), the dictionary file is ignored.
  • Users to mark the strings that are to be ‘translated’ by the dictionary feature. To do this, users have to enter a @ character at the start of the string, for example, @water level.

When the Dictionary files are configured correctly, the search and replace process works like this:

  1. A user marks a string value for translation by adding a @ prefix.
  2. Depending on where the string appears, either the ClearSCADA server or the ClearSCADA client detects the marked string and begins the search.
  3. The server or client compares the locale of the user’s User account to the locale of the country-specific dictionary file. If the locales match, ClearSCADA searches for the marked string in the file. If the locales are different, ClearSCADA cannot search in the country-specific file and so proceeds to check the region-specific dictionary file (see step 5).
  4. If ClearSCADA is searching the country-specific file, it reads the search string entries in the file. If any of them match the marked string, ClearSCADA reads the replacement string. It then uses the replacement string in place of the marked string wherever applicable (on Mimics, Trends, Lists etc.), and the search and replace process ends.

If ClearSCADA cannot find the marked string in the country-specific file, it continues the search in the region-specific file (see step 5).

  5. ClearSCADA compares the locale of the user’s User account to the locale of the region-specific dictionary file. If the locales match, ClearSCADA searches for the marked string in the file. If the locales are different, ClearSCADA cannot search in the region-specific file and so proceeds to check the default dictionary file (see step 7).
  6. If ClearSCADA is searching the region-specific file, it reads the search string entries in the file. If any of them match the marked string, ClearSCADA reads the replacement string. It then uses the replacement string in place of the marked string wherever applicable (on Mimics, Trends, Lists etc.), and the search and replace process ends.

If ClearSCADA cannot find the marked string in the region-specific file, it continues the search in the default file (see step 7).

  7. ClearSCADA reads the search string entries in the default dictionary file. If any of them match the marked string, ClearSCADA reads the replacement string. It then uses the replacement string in place of the marked string wherever applicable (on Mimics, Trends, Lists etc.), and the search and replace process ends.

If ClearSCADA cannot find the marked string in the default dictionary file, it ends the search. ClearSCADA will continue to use the marked string in its current form, but will remove the @ prefix automatically.

Example:

A system user logs on via a User account that is set to the English (UK) locale and configures a text box on a Mimic to have the value:

@High Level

The server is associated with a dictionary folder that contains dictionary files named en-GB.txt, en.txt, and Default.txt. The @High Level string and its replacement are included in the en.txt file:

"High Level", "High Pressure".

This means that the client will replace the string High Level with the string High Pressure.

As the text box value string is prefixed with the @ character, the client will search for the @High Level string in the dictionary files and attempt to replace it with the 'translated' version. The client searches the dictionary file as its file name is set to represent UK English which matches the Locale setting of the user's User account. (For information on the dictionary file names, see Creating Dictionary Files for Translating System Information).

The client begins by searching in the country specific file (en-GB.txt). As the country specific file does not contain the search term, the client continues its search in the region independent file (en.txt). It locates the search term (High Level) and its 'translation' (High Pressure). The client automatically replaces the "High Level" string with "High Pressure" in the text box shown on the Mimic.

Further Information

ISO Standards: For information on ISO standards, please refer to www.iso.org


Server Administration Guide - Creating Dictionary Files for Translating System Information (Dictionary Settings)

Creating Dictionary Files for Translating System Information

If your system needs to use translated terms, you need to configure dictionary files so that they contain the original string (the string that is to be replaced) and the translation string (the string that is to replace the original string).

Each dictionary file is a simple text file that can be created in Notepad or any word processor application.

There are 3 types of dictionary file:

  1. Country specific file—The country specific file is the first dictionary file that ClearSCADA will use. The file has to be named according to the ISO standards 639-1 and 3166:
<language>-<REGION>.txt

NOTE: The language has to be in lower case with the region in upper case.

For example, if the file contains terms that are used to translate strings into US English, the file would be named en-US.txt. The file would contain the original terms and for each term would have an alternative term in US English.

  2. Region independent file—The region independent file is the second dictionary file that ClearSCADA will use. ClearSCADA will only search for a term in the region independent file if it was unable to locate the term in the country specific file. The region independent file has to be named according to the ISO 3166 standard:
<language>.txt

The region file includes terms that are applied to the variations of a particular language. For example, if the dictionary files are being used to translate terms for the variations of English (UK English, US English, Australian English etc.), the region independent file has to be named en.txt. This is because en is the code for the language into which the strings are being translated, in this case, English (the local variant of English is not relevant to the region independent file).

NOTE: The language has to be in lower case.

  3. Default file—The default dictionary file is the final dictionary file that ClearSCADA will use. ClearSCADA will only search for a term in the default dictionary file if that term has not been found in the country specific file or region independent file. The default dictionary file has to be named:
Default.txt

Each dictionary file should be configured to contain search terms and replacement terms. Terms should be enclosed in double quotes " " and separated by commas, with one search term and replacement term on each line. For example:

"falling temperature", "température tombant"
"rising temperature", "température montant"
"falling pressure", "pression tombant"
"rising pressure", "pression montant"

If you want to add comments to the dictionary file to provide information for other users, simply use a single quotation at the start of the comment, for example:

'This dictionary file translates the text box descriptions into French.

To create a dictionary file:

  1. Use Notepad or any Word Processor program to create a document. The document will be saved as a plain text file (.txt).
  2. In the document, define a base locale for the file if required. You only need to define a base locale if the language of the dictionary file you are creating is not currently supported by your version of ClearSCADA.

ClearSCADA currently supports several languages including English, Spanish, Dutch and Russian. You can see which languages are available on your system by selecting Tools>Options and then using the Locale combo box (the combo box contains a list of the available languages). You can also view the available languages by using the Locale combo box on the User Form for your User account.

If you want to create a dictionary file for a language that is not listed in the Locale combo box, you will need to define a base locale.

To define a base locale, enter the following in the dictionary file:

BASE_LOCALE("<language>-<REGION>")

Where <language>-<REGION> is the ClearSCADA supported language that will be used for the base elements of your system (menus, options etc.). The <language>-<REGION> has to be entered in the same format as a country specific file. For example, if you were creating a dictionary file for Afrikaans, you could have a base locale of US English. This would mean that the terms you specify in your Afrikaans dictionary file would be translated into Afrikaans and the base features of ClearSCADA such as menus and menu options would be displayed in US English. To put this into effect, you would need to define the following in your dictionary file for Afrikaans:

BASE_LOCALE("en-US")

When you create a dictionary file for a language that is not supported by ClearSCADA, you have to define a base locale for a language that is supported as well. The language of your dictionary file will be available for selection on the User Forms.

  3. In the document, enter the terms in their original format followed by the translated format:
"Original Term", "Translated Term"

Each term is enclosed in double quotes and the original and translated terms are separated by a comma. A new line is required for each term and its translation.

NOTE: If you want to add comments to the dictionary file to aid other users, use a single quotation to indicate the start of the comment, for example 'this is a comment to assist other users. There is no need to use an ending quotation mark.

  4. When you have entered the required terms and translations, save the file as a .txt file. The file has to follow the naming conventions:
language-REGION.txt
language.txt
Default.txt

Where language has to be in lower case and is the language code specified in the ISO 6391 standard, and REGION has to be in upper case and is the regional variant of the language as specified in the ISO 3166 standard.

You should store the dictionary files in a folder that is suitably named so that it is easy to identify when see Associating a System with Dictionary Files.

  5. Apply the changes to the server configuration by right-clicking on the system icon in the explorer section of the ClearSCADA Server Configuration Tool, then selecting the Apply Changes option.
  6. Re-start any ViewX or WebX clients so that they are set to search in the defined dictionaries folder.

NOTE: ClearSCADA will only use dictionary files that use the same language and region as the Locale of the currently logged on user's User account.


Server Administration Guide - Associating a System with Dictionary Files (Dictionary Settings)

Associating a System with Dictionary Files

For ClearSCADA to use the translated versions of the strings, you need to associate the server with a dictionary folder. To do this, use the Dictionaries section on the ClearSCADA Server Configuration Tool:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select the Dictionaries branch to display the Dictionaries section.
  4. Use the browse button next to the Dictionary field to define the location of the dictionaries folder (When you select the browse button, the Select Dictionaries Folder window is displayed. Use the Select Dictionaries Folder window to navigate to the required dictionary folder, then select the OK button to confirm your selection).

The ClearSCADA server and clients will refer to the selected dictionaries folder for translated strings. They will search in the directories folder for any user-created strings that are prefixed with the @ character. If a search string is located in the dictionary files, ClearSCADA will read the ‘translation’ for that string. It will then use the ‘translation string’ in place of the search string on Mimics, Trends, Lists, etc.

  5. Apply the changes to the server configuration by right-clicking on the system icon in the explorer section of the ClearSCADA Server Configuration Tool, then selecting the Apply Changes option.
  6. Re-start any ViewX or WebX clients so that they are set to search in the defined dictionaries folder.


Server Administration Guide - Driver Settings

Driver Settings

You can use the Drivers section of the ClearSCADA Server Configuration Tool to:

  • Define the Driver Request Timeouts (advanced drivers only)
  • Define the Scanner Command and Request Timeouts (advanced drivers only)
  • Define the PSTN Eavesdropping Timeout (advanced drivers only)
  • Define the Driver Start and Stop Timeouts (simple drivers and advanced drivers)
  • Enable or Disable Halting the Drivers if an Error Occurs (advanced drivers only)
  • Detecting a Change to the Server's Clock (advanced drivers only)
  • Define the Maximum Number of Secondary Point Updates (advanced drivers only)
  • Define the Value Map Scanning Interval (advanced drivers only)
  • Define the Server Poll Interval (simple drivers and advanced drivers)
  • Define the On Demand Direct Outstation Retry Period
  • Define the Maximum Batch Size for Server Updates
  • Define whether the Queue Parameter is Available.

Before you define the various timeout, update, and interval settings, we recommend that you familiarize yourself with the information in Understanding Request Timeouts.

ATTENTION: We recommend that you leave the Halt driver and display a dialog box when an error occurs check box cleared unless you are advised to enable the feature by a Schneider Electric engineer. This is because this feature can cause a driver to stop until a user responds to a diagnostics message on the ClearSCADA server. Users cannot respond to the diagnostics message from a client PC, and so the driver may be stopped for an extended length of time on systems with unmanned ClearSCADA servers.

For information on the various driver specific sections of the ClearSCADA Server Configuration Tool, such as Crystal Reports and DNP3, please refer to the relevant driver guide.


Server Administration Guide - Understanding Request Timeouts (Driver Settings)

Understanding Request Timeouts

When an action (Control, One Shot, etc.) is triggered, the relevant driver creates a request for the action.

  • If the request can be performed immediately, it will be completed straight away. Typically, requests that do not require any communication with an outstation or similar device are completed immediately.
  • If the request cannot be performed immediately, it is placed in a queue of pending requests. When a channel is available, the pending request with the highest priority becomes active and is passed to the channel's scanner to be performed.

By defining the request timeout, you can determine the maximum amount of time a request can be placed in the pending requests queue. If the request has not started within the defined timeout time, the request is aborted and removed from the queue. However, if the request is in progress, it is given an additional amount of time in which to complete. If the request has not completed at the end of the additional amount of time, ClearSCADA detects that the request is timed out and then fails the request.

Further Information

  • Define the Driver Request Timeouts
  • Define the Scanner Command and Request Timeouts


Server Administration Guide - Define the Driver Request Timeouts (Driver Settings)

Define the Driver Request Timeouts

NOTE: This section applies to advanced drivers only.

You can use the ClearSCADA Server Configuration Tool to define the maximum amount of time permitted for a driver to complete a request. By defining a maximum time, you allow the driver to abort a request that is taking too long to complete.

There are two driver request timeouts:

  • Request Timeout—The driver has to start to perform the request within this period. If the request is still pending after this period, the driver detects that the request has failed and then aborts it. However, if the request is active when the Request Timeout time expires, additional time is allowed for the request to complete. This additional amount of time is the Request Timeout Extension.
  • Request Timeout Extension—An additional amount of time that is added to the Request Timeout. The Request Timeout Extension is only used if the request is active at the time the Request Timeout expires. For example, if the Request Timeout is 600 seconds, and after 600 seconds the request is active (the driver is in the process of performing the request), the request is allowed an additional period to complete. The additional time period is the amount of time defined for the Request Timeout Extension. If the request has not completed after this extended period, the request is aborted and fails.

Typically, the default settings of 10 minutes, with a 5 minute extension are adequate. However, certain requests such as a file transfer or download configuration may take longer due to slow communication links, or very large files or outstations. For these types of request, you may need to increase the timeouts.

Requests that are aborted due to a timeout are logged in the Event Journal.

NOTE: Some drivers have their own timeout that is used instead of the Request Timeout (for specific requests that routinely take longer to complete). For more information, please refer to the relevant Driver Guide).

To define the limits for the two request timeouts:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers.
  4. In the Timeouts part of the Drivers section:
  • Define the maximum amount of time permitted for each request in the Request Timeout field. If the request is still pending at the end of this time, the driver detects that the request has failed and then aborts the request.
  • In the Request Timeout Extension field, define the additional amount of time permitted for an active request to complete. If the active request does not complete within the defined time, the driver detects that the request has failed and then aborts the request.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.


Server Administration Guide - Define the Scanner Command and Request Timeouts (Driver Settings)

Define the Scanner Command and Request Timeouts

NOTE: This section applies to advanced drivers only.

You can use the ClearSCADA Server Configuration Tool to define the length of the scanner command and request timeouts.

There are two scanner request timeouts:

  • Scanner Command Timeout—When a request becomes active, it is passed to the scanner of a channel to perform the request. The scanner also generates requests internally, for example to poll an outstation. Each request consists of a sequence of commands that are sent by the scanner to an outstation. The scanner periodically checks that at least one command has been sent (since the previous check). The frequency of this check is defined by the Scanner Command Timeout setting. If a command has not been sent since the previous check, the driver detects the request has failed and then aborts the request.

A new request is allowed double the Scanner Command Timeout for the first command to be sent. For example, if the Scanner Command Timeout is 30s, the first command for a new request has 60s to be sent.

  • Scanner Request Timeout—An active request that is passed to a scanner may be suspended within the scanner. Typically, this occurs when an outstation indicates that it will take some time to process a particular command. Suspending the active request allows the scanner to continue sending commands to other outstations, while waiting for a response.

If there is no response within a specified amount of time, the driver detects that the request has failed and then aborts the request. The amount of time permitted for a response is defined by the Scanner Request Timeout setting.

Typically, the default settings of 30 seconds and 3 minutes are adequate. However, the timeouts may need to be increased if there are slow devices or communication links. If a request is aborted because of a timeout, ClearSCADA logs an event in the event journal.

To define the limits for the two scanner timeouts:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers.
  4. In the Timeouts part of the Drivers section:
  • In the Scanner Command Timeout field, define how often the scanner will check that at least one command has been sent since the previous check.
  • In the Scanner Request Timeout field, define the amount of time permitted for a response to a suspended request.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.


Server Administration Guide - Define the PSTN Eavesdropping Timeout (Driver Settings)

Define the PSTN Eavesdropping Timeout

NOTE: This section applies to advanced drivers only.

You can use the ClearSCADA Server Configuration Tool to define the maximum period of inactivity during a PSTN call when a channel is in 'eavesdrop' mode. This is required as the end of a call may not be detected while 'eavesdropping'.

'Eavesdropping' is a feature that is typically used to test new servers. It allows a new server to monitor or 'eavesdrop' on the communications between an existing server and its outstations (or similar devices).

Normally, a driver detects the end of a call by using the carrier detect signal or by the modem sending a "NO CARRIER" message. However, when 'eavesdropping', the carrier detect signal is unavailable and if the call terminates unexpectedly, the "NO CARRIER" message is often 'lost' in a protocol message. By defining an eavesdropping timeout, you allow the driver to detect the end of a call, even if the "NO CARRIER" message was not detected. The driver will deem the call as ended if there is no activity by the end of the eavesdropping timeout or if it detects the start of another call.

To define the PSTN eavesdropping timeout:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers.
  4. In the Timeouts part of the Drivers section:
  • In the Eavesdrop PSTN Timeout field, enter the amount of time for the timeout. If the driver does not detect any activity during a PSTN call by the end of this time, it will deem the call as having ended.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.


Server Administration Guide - Define the Driver Start and Stop Timeouts (Driver Settings)

Define the Driver Start and Stop Timeouts

When a driver is commanded to start, it is expected to start and run within a certain amount of time, referred to as the Start/Stop Timeout. If the driver has not started within the Start/Stop Timeout, ClearSCADA will detect that the driver has failed and will attempt to start the driver by ‘retrying’ the start command continuously. The amount of time between these retry attempts, and the total number of attempts that will be made are determined by the Minimum Retry Timeout and Maximum Retry Timeout settings.

Similarly, if a driver is commanded to stop, it is expected to stop within the Start/Stop Timeout. If the driver has not stopped running within the Start/Stop Timeout, ClearSCADA will ‘kill’ the driver. The ‘kill’ command will stop the driver immediately, but in doing so, will stop the driver from gracefully terminating its connections to devices that are being scanned. This may result in a loss of data. To reduce the chances of data loss, we recommend that you set the Start/Stop Timeout so that it is large enough to allow adequate time for the driver to gracefully terminate communications with the devices it is scanning.

The Start/Stop Timeout, Minimum Retry Timeout and Maximum Retry Timeout settings are designed to help your system avoid the performance issues that can occur if a driver fails repeatedly. The timeouts allow ClearSCADA to wait before attempting to restart a failed driver. This delay means that the retry attempts place less demand on system resources, and so a driver that fails repeatedly has less impact on system performance.

You can use the Drivers section of the Server Configuration Tool to define the Start/Stop Timeout, Minimum Retry Timeout and Maximum Retry Timeout settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers.
  4. In the Start/Stop Timeouts part of the Drivers section:
  • Enter the amount of time permitted for the driver to start or stop in the Start/Stop Timeout field. The time you enter should be sufficient for the driver to start and stop running in normal circumstances i.e the timeout should only cause the server to terminate the start/stop driver process when there is a problem with the process. The default setting of 30 seconds is appropriate for many drivers.
  • Minimum Retry Timeout—Enter the minimum amount of time that ClearSCADA will wait before attempting to retry a failed driver for the first time. Remember that the amount you enter will only be applied for the first retry of a driver that has not started. Subsequent retries will calculate the delay that is 150% of the previous retry timeout of the previous retry timeout (up to the Maximum Retry Timeout amount).

The default setting of 30 seconds is appropriate for many drivers, but you may wish to increase it if a driver fails and causes performance issues. If you choose to increase the Minimum Retry Timeout, we recommend that you increase the amount by 30 seconds. This may reduce the impact of a failed driver on system performance.
We also recommend that you report driver failures to Schneider Electric.

  • Maximum Retry Timeout—Enter the maximum amount of time that ClearSCADA will wait before attempting to retry a failed driver. The amount you enter defines the upper limit for retry timeouts for failed drivers. If a driver has not started successfully within the Maximum Retry Timeout time, ClearSCADA will ‘kill’ the driver and will not make any further attempts to start it.

The default setting of 300 seconds is appropriate for many drivers, but you may wish to increase it if you want ClearSCADA to continue retrying the driver for an extended period.

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.

Example:

In this example, the Start/Stop Timeout is set to 60 seconds, the Minimum Retry Timeout is 30 seconds, and the Maximum Retry Timeout is 120 seconds. The server goes ‘Main’ just before 09:00:00.000 and so attempts to start its drivers. For the purpose of this example, we will focus on a single driver.

The following table shows when the server attempts to start the driver and how it uses the various timeouts to determine when it should attempt its ‘retries’:
Time stamp | Server/Driver Activity
09:00:00.000 | Server tries to start driver automatically. Driver expected to start within the Start/Stop Timeout of 60 seconds.
09:01:00.000 | Driver has not started. Server will wait Minimum Retry Timeout of 30 seconds then attempt to start the driver again.
09:01.30.000 | Server attempts to start the driver. Driver expected to start within the Start/Stop Timeout of 60 seconds.
09:02:30.000 | Driver has not started. Server will wait previous Minimum Retry Timeout + 50% of the previous Minimum Retry Timeout (so 45 seconds) before trying to start the driver.
09:03:15.000 | Server attempts to start the driver. Driver expected to start within the Start/Stop Timeout of 60 seconds.
09:04:15.000 | Driver has not started. Server will wait previous Minimum Retry Timeout + 50% of the previous Minimum Retry Timeout (so 67.5 seconds) before trying to start the driver.
09:05:22.500 | Server attempts to start the driver. Driver expected to start within the Start/Stop Timeout of 60 seconds.
09:06.22.500 | Driver has not started. Server will wait previous Minimum Retry Timeout + 50% of the previous Minimum Retry Timeout (so 98.5 seconds) before trying to start the driver.
09:08:05.000 | Server attempts to start the driver. Driver expected to start within the Start/Stop Timeout of 60 seconds.
09:09:05.000 | Driver has not started. The result of the previous Minimum Retry Timeout +50% of the previous Minimum Retry Timeout exceeds the defined Maximum Retry Timeout, so the server stops trying to start the driver. It ‘kills’ the driver.

Further Information

Start and Stop a Driver.


Server Administration Guide - Halting the Drivers if an Error Occurs (Driver Settings)

Halting the Drivers if an Error Occurs

NOTE: This section applies to advanced drivers only.

You can use the ClearSCADA Server Configuration Tool to set the drivers to pause when an error occurs. This is useful as it allows a driver to be examined while it is in the error state. If you enable this feature and a driver logs an error, it will halt and display a diagnostics message. The driver will only continue when the message has been acknowledged by a user.

ATTENTION: We recommend that you leave the Halt driver and display a dialog box when an error occurs check box cleared unless you are advised to enable the feature by a Schneider Electric engineer. This is because this feature can cause a driver to stop until a user responds to a diagnostics message on the ClearSCADA server. Users cannot respond to the diagnostics message from a client PC. This means that the driver may be stopped for an extended length of time on systems with unmanned ClearSCADA servers.

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers.
  4. Select the Halt driver and display a dialog box when an error occurs check box to enable the halt driver feature or clear it to disable the halt driver feature.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.


Server Administration Guide - Detecting a Change to the Server's Clock (Driver Settings)

Detecting a Change to the Server's Clock

NOTE: This section applies to advanced drivers only.

Drivers detect that the server's clock has changed by comparing the server's real-time clock (RTC) with the CPU ticker. If a difference is detected, it means that the clock has changed, and so the driver will update its internal timers accordingly. It will also set the outstation clocks to the new time.

The threshold on the difference between the RTC and the CPU ticker is defined by the Maximum Clock Jump setting. Any difference above this threshold is treated as a change to the clock.

The clocks in some servers can cause significant differences between the clock and ticker. These differences are referred to as jitter. To allow for the amount of jitter, you may need to increase the Maximum Clock Jump threshold.

The default setting of 50 milliseconds is often sufficient, but some servers may need a higher setting (possibly as high as 250ms).

To define the maximum permitted time difference between the server clock and CPU ticker:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers.
  4. In the Maximum Clock Jump field, enter the threshold for the difference between the RTC and the CPU ticker (that indicates the clock has changed).
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.


Server Administration Guide - Define the Maximum Number of Secondary Point Updates (Driver Settings)

Define the Maximum Number of Secondary Point Updates

NOTE: This section applies to advanced drivers only.

Some drivers may retrieve large blocks of secondary (logged) data from an outstation. Processing a large block can result in a high load on the server, so each driver divides the large block into smaller blocks, and then sends the smaller blocks to the server in turn, with a short delay between each block. The server is then able to process each small block without experiencing slow performance.

You can use the ClearSCADA Server Configuration Tool to define the maximum size of a block of point updates. By defining a suitable size, you can reduce the size of the blocks that are sent from the driver to the server, and as a result, allow the server to perform better (as the load on the server is distributed more evenly).

For many systems, the default setting of 250 updates per block is appropriate.

To define the maximum number of secondary point updates per block:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers.
  4. Enter the maximum number of point updates per block in the Maximum Number of Secondary Point Updates field.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.


Server Administration Guide - Define the Value Map Scanning Interval (Driver Settings)

Define the Value Map Scanning Interval

NOTE: This section applies to advanced drivers only.

Slave drivers uses value maps to map properties in the ClearSCADA database onto the points of the slave outstations. Periodically, a driver will scan the properties in the value maps and cache the values for the properties. When another server scans the slave outstations, the values for the slave outstations are taken from the driver's cache rather than the database.

You can use the ClearSCADA Server Configuration Tool to determine how often the drivers scan the value maps. The default setting for the value map scanning interval is 1000 milliseconds, which is usually suitable for many systems. However, you can change the value map scanning interval as required:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers to display the Drivers section.
  4. Define how often the drivers check for updates to the value maps in the Value Map Scanning Interval field. The interval between each check is measured in milliseconds.
  • If you lower the amount of milliseconds between each scan, there will be more database activity which may affect the performance of your system.
  • If you raise the amount of milliseconds between each scan, there may be slow update times as the drivers may not check for updates as frequently as required.

We recommend that you set the value map scanning interval no higher than 60000 and no lower than 500.

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.


Server Administration Guide - Define the Server Poll Interval (Driver Settings)

Define the Server Poll Interval

You can use the ClearSCADA Server Configuration Tool to define how often the drivers poll the server to check that it is still running. The amount of time you define for the Server Poll Interval determines how often the drivers will poll the server.

Typically, the server polling is of little concern as if the server shuts down correctly, the drivers will also be shutdown. However, if the server fails and the drivers remain running, the server polls allow the drivers to determine whether the server is still running.

By adjusting the server polls, you determine how quickly the drivers will be able to detect a server failure.

Typically, the default setting of 5000 milliseconds is appropriate for many systems.

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers to display the Drivers section.
  4. Define how often the drivers poll the server in the Server Poll Interval field. The interval between each check is measured in milliseconds.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the required driver(s) so that the new timeout(s) take effect (main server only). For more information, see Start and Stop a Driver.
  7. Repeat steps 2-6 inclusive for the other servers in the system, except permanent standby servers.


Server Administration Guide - Define the On Demand Direct Outstation Retry Period (Driver Settings)

Define the On Demand Direct Outstation Retry Period

The On Demand Direct Outstation Retry Period setting is designed to help drivers send requests to ‘On Demand’ direct outstations via an appropriate channel (either the direct connection or the outstation’s PSTN Fallback channel).

An ‘On Demand’ direct outstation is an outstation that has a direct, permanent physical connection to ClearSCADA, but this connection is not used continuously. Instead, the connection is used when required, for example, when data needs to be refreshed or controls need to be sent.

Normally, ClearSCADA sends a request to the ‘On Demand’ direct outstation via the direct channel. When the outstation responds, it communicates via the direct channel. ClearSCADA receives the response and then closes the connection. When the next request is due to be sent, ClearSCADA will re-open the direct channel connection.

If the connection via the direct channel fails at the first attempt, ClearSCADA will try to make the connection again (according to the Retries and Timeout settings in the outstation’s configuration). If the retries are successful, ClearSCADA will send the request, wait for a response, and then close the direct channel connection. Again, when the next request is due to be sent, ClearSCADA will re-open the direct channel connection.

If the retries are unsuccessful, and the direct outstation does not have a PSTN Fallback channel, the direct outstation is deemed to have failed. If the outstation does have a PSTN Fallback channel, ClearSCADA will attempt to connect via the designated PSTN channel. At this stage, the On Demand Direct Outstation Retry Period begins.

During the On Demand Direct Outstation Retry Period, ClearSCADA will send the request and any new requests via the PSTN Fallback channel. ClearSCADA will not even attempt to use the direct channel. This means that time and resources are not wasted on trying to connect via a direct channel that has recently been used in an unsuccessful communications attempt.

When the On Demand Direct Outstation Retry Period expires, ClearSCADA will attempt to send any new requests via the direct channel. Of course, if the connection via the direct channel fails again, ClearSCADA will go through the retries process and may have to re-start the On Demand Direct Outstation Retry Period and communicate via the PSTN Fallback channel.

You can use the Server Configuration Tool to define the duration of the On Demand Direct Outstation Retry Period. The default amount is 120 seconds, but you may need to adjust this setting for your system:

  • If your On Demand connections fail intermittently on a regular basis, you may benefit from lowering the On Demand Direct Outstation Retry Period amount. By reducing the amount, you can retry the On Demand connection more regularly, for example, every minute. As the intermittent failures are not usually related to hardware faults, retrying the On Demand connection more frequently is likely to result in successful communications via the direct connection.
  • If your On Demand connection is usually reliable, you may wish to increase the On Demand Direct Outstation Retry Period. This can be useful with reliable connections, as any failures probably relate to genuine faults such as hardware failure or failure of a communications device at the outstation (and so you need the PSTN fallback channel to be used). In this situation, you should set the On Demand Direct Outstation Retry Period to match the typical amount of time it takes to repair the hardware fault.

To set the On Demand Direct Outstation Retry Period:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers to display the Drivers section.
  4. Enter the required duration (in seconds) in the On Demand Direct Outstation Retry Period field.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the server or the relevant driver(s) for the On Demand Direct Outstation Retry Period to take effect. For more information, please refer to:
  • Start and Stop the System Server
  • Start and Stop a Driver.

NOTE: A driver will only use the On Demand Direct Outstation Retry Period setting when the outstation it is communicating with is configured as On Demand and has PSTN fallback.

Further Information

For more information on Direct outstations and PSTN Fallback, see the ClearSCADA Guide to Advanced Drivers.


Server Administration Guide - Define the Maximum Batch Size for Server Updates (Driver Settings)

Define the Maximum Batch Size for Server Updates

You can use the Maximum Batch Size for Server Updates setting to define the size limit for batched driver updates. By default, the limit is 1000 which is appropriate for many large systems (systems with around 400-500 channels).

The appropriate amount for the Maximum Batch Size for Server Updates setting should be determined according to the number of channels on a system, the general amount of system activity, and the Server Poll Interval setting. For systems with only a small number of relatively idle channels, you may wish to reduce the Maximum Batch Size for Server Updates setting. You may also want to reduce the setting if the Server Poll Interval setting is significantly larger than the default amount (see Define the Server Poll Interval).

Batched driver updates are used to send low priority updates such as communication statistics. Rather than send each low priority update to the server individually (which can cause a high load and slow performance), the updates are stored so that they can be sent at a later time, in small batches. The ClearSCADA server can then process the low priority updates at the same time, as the small batches mean there is less load on the server.

The batched updates sent to the ClearSCADA server when:

  • A background server poll occurs (defined by the Server Poll Interval setting, see Define the Server Poll Interval)
  • An update that is not low priority is sent to the server. As the update is not low-priority, it is not batched. However, any pending batched updates are sent at the same time as the non-batched update.
  • The number of individual updates that are pending exceeds the Maximum Batch Size for Server Updates setting.

If there is a delay between a driver sending an update and the driver’s communications statistics being refreshed, there are two possible causes: a high load on the server or the batched updates are not being sent as frequently as required.

This could be the result of:

  • The server being polled too infrequently (Server Poll Interval setting is too high)

Or:

  • The Maximum Batch Size for Server Updates being set too low (and so causing the driver to send lots of small batches to the server as they become full too quickly).

In this situation, you should consider increasing the Maximum Batch Size for Server Updates setting.

To set the Maximum Batch Size for Server Updates:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers to display the Drivers section.
  4. Enter the required limit in the Maximum Batch Size for Server Updates field.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.
  6. Re-start the server or the relevant driver(s) for the new batch size limit to take effect. For more information, please refer to:
  • Start and Stop the System Server
  • Start and Stop a Driver.


Server Administration Guide - Define whether the Queue Parameter is Available (Driver Settings)

Define whether the Queue Parameter is Available

You can use the Server Configuration Tool’s Allow Certain Requests to be Optionally Queued setting to control the availability of the Queue parameter on certain types of request. The Queue parameter is designed for use with PSTN outstations and Direct ‘On Demand’ outstations and allows users to postpone various types of request, including controls, Off Scan, On Scan, Configuration Download, and Tune Alarm Limits.

When you use the Queue parameter on a request, the request is saved on the ClearSCADA server and the relevant driver. Instead of being executed immediately, the request is queued so that it can be executed later as part of a ‘batch’ of queued requests (the queued requests will be executed the next time the outstation communicates with ClearSCADA). For example, using the Queue parameter may be useful when there is a cost involved with establishing connections to PSTN or Direct On Demand outstations—it may be less expensive to execute the requests as a group rather than establish a connection for each individual request.

The availability of the Queue parameter is controlled by the Allow Certain Requests to be Optionally Queued setting on the Server Configuration Tool. By default, the Allow Certain Requests to be Optionally Queued check box is clear (the option is disabled), and so the Queue parameter is unavailable in ViewX and WebX.

To define whether the Queue parameter is available:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Drivers to display the Drivers section.
  4. Use the Allow Certain Requests to be Optionally Queued check box to control the availability of the Queue Request feature:
  • If you have PSTN outstations or Direct ‘On Demand’ outstations and need to be able to delay requests, you should select the Allow Certain Requests to be Optionally Queued check box. This will mean that the Queue parameter is available; users will be able to queue certain types of requests.
  • If you do not have PSTN outstations or Direct ‘On Demand’ outstations, or have no need to stop requests from being executed immediately, you can disable the Allow Certain Requests to be Optionally Queued setting. This will mean that the Queue parameter is unavailable to users and so they cannot queue requests.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Further Information

Queuing a request: see Queue Check Box in the ClearSCADA Guide to Drivers.


Server Administration Guide - E-Mail Settings

E-Mail Settings

You need to define the e-mail settings for each server so that ClearSCADA can send and retrieve e-mails. The e-mail settings are required if your system is to use the alarm redirection via e-mail feature (see Introduction to Alarm Redirection in the ClearSCADA Guide to Alarm Redirection).

The Outgoing Mail (SMTP) e-mail settings also apply if the Crystal Reports driver is being used to interface with Crystal Reports version 2008 and the E-mail report exports using server SMTP settings check box is selected. The E-mail report exports using server SMTP settings check box is one of the settings in the Crystal Reports section of the ClearSCADA Server Configuration Tool (and is described in the ClearSCADA Guide to the Crystal Reports Driver).

To define the e-mail settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select E-Mail to display the E-Mail section.
  4. In the Outgoing Mail (SMTP) section, define these settings:
  • Server—Enter the node name or IP address of the mail server to which outgoing e-mail is sent.
  • Port—Enter the number of the port via which your mail server receives messages.
  • Timeout—Enter the number of milliseconds for which the outgoing server will wait
  • Server Requires Authentication—Select this check box if the mail server requires authentication to send outgoing mail; clear this check box if the mail server does not require authentication to send outgoing mail.
  • Account Name—If the mail server requires authentication for outgoing mail, enter the name of the mail server log in account in the Account Name field. This field is only available when the Server Requires Authentication check box is selected.
  • Password—If the mail server requires authentication for outgoing mail, enter the password for the mail server log in account in the Password field. This field is only available when the Server Requires Authentication check box is selected.
  • Name—Enter the name that is associated with outgoing e-mail. This is usually a server user name that corresponds to a setting at the server, and it is displayed in the From field in each message sent by ClearSCADA.
  • E-Mail Address—Enter the e-mail address that is associated with outgoing e-mail. This is usually a generic e-mail address for your organization, and it is displayed in the From field in each message sent by ClearSCADA.
  5. In the Incoming Mail (POP3) section, define these settings:
  • Enabled—Either:
  • Select the Enabled check box in the Incoming Mail section to allow ClearSCADA to check for incoming e-mail. This means that the acknowledge alarms via e-mail feature can be used.
  • Clear the Enabled check box to set ClearSCADA so that it does not check for incoming e-mail. This means alarms cannot be acknowledged via e-mail.
  • Server—Enter the node name or IP address of the mail server from which ClearSCADA retrieves incoming messages.
  • Port—Enter the port number of the port via which ClearSCADA retrieves messages from the mail server.
  • Account Name—Enter the account name required to retrieve mail from the (incoming) mail server. Each mail server requires an account name to retrieve incoming mail.
  • Password—Enter the password for the account (the account specified in the Account Name field).
  • Acknowledgment Keyword—Enter the keyword that has to be included in the subject line of any e-mails sent to ClearSCADA. If the keyword is not included in the subject line, the e-mail is ignored.

By defining a keyword, you configure ClearSCADA so that alarms cannot be acknowledged by auto response e-mails or unrecognized e-mails; to acknowledge an alarm via e-mail, a user has to manually enter the keyword in the subject line of the e-mail prior to sending the e-mail to ClearSCADA.

  6. Check for new mail every n seconds—Use to define the how often ClearSCADA checks for new mail. The default setting is 300 seconds, which is suitable for many systems.

If you wish to change the setting, please bear in mind that a setting that is too low may have a detrimental effect on system performance, and a setting that is too high may result in alarms not being acknowledged (via e-mail) within a suitable amount of time.

  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished defining the E-Mail settings, you can continue with the server configuration. If you are unfamiliar with the server configuration process, we suggest you proceed to learn about the Events List Settings.


Server Administration Guide - Events List Settings

Events List Settings

You can use the ClearSCADA Server Configuration Tool to define which columns are shown on the Events List (Event Journal).

The settings for the Events List columns are shown in the Events section of the Tool. To access the Events section:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch.
  3. Select the Events branch.

The Events settings are explained in Define which Columns are shown on the Event List.


Server Administration Guide - System Calls Settings

System Calls Settings

ClearSCADA allows you to trigger system calls (run executable files) via:

  • Logic programs (using the SYSTEM function)
  • Alarm Redirections (using the System Command action)
  • The Execute action (when performed on a System Command database item).

System calls are reliant on Windows user accounts—they can only be performed if the Windows user account used by the server has Read permissions for the executable files that are triggered by the system calls. The ClearSCADA server runs under the Windows user account named System. Although this is a high level user account, it does not provide permissions for network access or printer configuration. This means that you cannot use a system call to access another PC or a printer when the server is configured to use the System Windows user account. To resolve this, you can use the ClearSCADA Server Configuration Tool's System Calls settings to define another Windows user account for system calls. By associating the server's system calls with a different Windows user account (one with printer configuration permissions and network access permissions), you can setup ClearSCADA so that common system calls such as print are available.

To configure the System Calls settings on your server:

  1. Use Microsoft Windows to create a new Windows user account that has the privileges you require (printer configuration, network access etc.) You will need to define a Username, Password, and Domain. For more information, please refer to the documentation supplied with your operating system.
  2. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  3. Expand the System Configuration branch.
  4. Select System Calls.
  5. Enter the Username, Password, and Domain for the Microsoft Windows user in the appropriate fields. If you leave these fields blank, the server will use the 'System' Windows user which does not have network access or printing privileges.
  6. Use the General field to define the amount of time that is permitted for each system command. If the system command does not complete within the defined time period, ClearSCADA will detect that the command has failed. Typically, the default setting of 15 seconds is appropriate, but you may need to extend this amount if you know that one of your required system commands takes longer than this to complete.
  7. Close the ClearSCADA Server Configuration Tool to apply the changes (or select another branch if further server configuration is required).

ATTENTION: Do not use system calls to call interactive processes, such as running interactive programs like Microsoft Notepad. Interactive processes do not complete until the user closes the application and will stop any other system calls from executing.

You can use the Server Status Tool to view the current status of system calls—see Latest System Calls in the ClearSCADA Guide to the Server Status Tool and see Queued System Calls in the ClearSCADA Guide to the Server Status Tool.

Now that you have set the System Calls settings, you can proceed with the ClearSCADA Server configuration—see WebX Settings.


Server Administration Guide - WebX Settings

WebX Settings

The ClearSCADA server contains a WebX server that allows client PCs to access the ClearSCADA System via the internet or intranet.

The WebX server supports both standard http (non-secure) and https (secure). The WebX server can also generate XML which is then translated into HTML by the client's web browser. Alternatively, the server can translate the XML into HTML (for clients that do not support XML). We recommend that client-side translation is used wherever possible as this is likely to result in better performance.

To setup the WebX connections at the server, you need to define the WebX settings. The WebX settings specify the ports that are used by the WebX server, the security measures for the WebX connections, the locations of the stylesheets and images that are used by the WebX interface, and the settings for the Alarm List in WebX.

You can use the WebX settings to:

  1. Define the Ports settings for access via WebX.

ATTENTION: There are important security implications to consider when setting the Ports. For more information, see Define the Access Settings for WebX Clients in the ClearSCADA Guide to Security.

  2. Define the SSL settings for SSL certificates. Again, there are security implications to be considered when defining SSL settings, see Define the Access Settings for WebX Clients in the ClearSCADA Guide to Security.
  3. Define the Location of Stylesheets and Images
  4. Define the Alarms List Order and Background Settings
  5. Define the Cross-Database Hyperlinks Settings.


Server Administration Guide - Define the Location of Stylesheets and Images (WebX Settings)

Define the Location of Stylesheets and Images

You can create your own stylesheets so that the ClearSCADA web pages suit your requirements. For example, you may use different stylesheets so that the ClearSCADA web pages have a similar appearance to your company web pages. The images and JavaScript files that are used by the web pages has to be stored in the same location as the stylesheet.

To create your own stylesheets, you will need an understanding of the following languages:

  • XSLT (XML Stylesheet Language Transformation)
  • XML (Extensible Markup Language)
  • HTML (HyperText Markup Language)
  • JavaScript

You can use the default Schneider Electric stylesheet as a template for your own custom stylesheets or you can create new stylesheets as required.

To define the location of the stylesheets and images that are used by WebX:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select WebX to display the WebX section.
  4. Select the browse button next to the Folder field in the Stylesheets and Images section.
    A browse window is displayed.
  5. Use the browse window feature to locate and select the folder that contains the custom stylesheet, JavaScript, and images that are to be used instead of the present stylesheet, scripts, images etc.
  6. Select the OK button to confirm your selection and close the browse window.
  7. Select the Update folder without moving existing files check box.

NOTE: You should only clear this check box if you want the stylesheet that is currently in use to be moved to the specified location. When the files are moved to the new location, they will overwrite your custom stylesheets.

Now that you have defined the stylesheet and image settings, you can proceed with the configuration of the other WebX settings or you can right-click on the server icon and select the Apply Changes option to implement the changes.

You can now define other WebX Settings as required.


Server Administration Guide - Define the Alarms List Order and Background Settings (WebX Settings)

Define the Alarms List Order and Background Settings

You can use the WebX section of the Server Configuration Tool to define the default sort order and background color for the Alarms List in WebX:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select WebX to display the WebX section.
  4. In the Alarm List section, use the Sort Order combo box to select the order in which alarms will be sorted on the Alarm List in WebX. The default sort order is ordered by State first, then Severity, then Time.

The alarm states are ordered like this:

  • Unacknowledged Uncleared (Top)
  • Unacknowledged Cleared (Middle)
  • Acknowledged Uncleared (Bottom)

The order of the alarm severities corresponds to the numbers for the severities (high severities at the top, low severities at the bottom). For more information, see Alarm and Event Severities.

If the default settings are in place, it means that if two alarms are raised with the Unacknowledged Uncleared alarm, they will both appear high in the Alarms List. The severity of the alarms will determine which of the two alarms is listed highest. For example, if one alarm is Unacknowledged Uncleared and has a High severity and the other is Unacknowledged Uncleared and has a Low severity, the alarm with High severity will appear above the other alarm in the Alarms List. If both alarms have the same alarm state and alarm severity, they will be listed according to the time at which they were raised (the latest alarm will appear highest in the list).

You can change the sort order to any combination of the three sort types, for example, you can choose to sort the list by Time first, then State, then Severity if required.

  5. Use the Background color button to choose the background color that is used for the Alarms List in WebX. This color is only used if the Use Client Default check box is clear.
  6. Use the Use Client Default check box to define whether the background of the Alarms List uses the color specified for dialog boxes in the Windows operating system or uses the color that is defined by the Background color button setting (see previous step).
  • If you select the check box, the background color of the Alarms List will correspond to the dialog box color that is specified in your Windows operating system.
  • If you clear the check box, the Alarms List will use the background color that is specified for the Background button.
  7. Right-click on the server icon and select the Apply Changes option to implement the changes.


Server Administration Guide - Define the Cross-Database Hyperlinks Settings (WebX Settings)

Define the Cross-Database Hyperlinks Settings

Mimics can contain hyperlinks to displays on the local system and to displays in other databases. For example, you could display a Mimic that is stored on the system to which you are currently connected, and that Mimic could contain a hyperlink to a Crystal Report that is stored on a different system. In such a scenario case, the Crystal Report is the 'target' display for the hyperlink.

On ViewX clients, a hyperlink to another system will work as long as the ViewX client can connect to its local system and the other system (the client-server connections are healthy). However, on WebX clients, the hyperlinks can only be used if the server to which the WebX client is connected can identify and locate the 'target' display. To do this, the server needs to be configured to have appropriate Cross-Database Hyperlinks settings, so that it can match the system name in a hyperlink to the node name and port of the system that contains the ‘target’ display.

The Cross-Database Hyperlinks settings allow WebX users to use hyperlinks to the following types of display (stored on systems other than the system to which the WebX client is connected):

  • Mimics
  • Trends
  • X-Y Plots
  • Lists
  • Alarms Lists
  • Crystal Reports

To configure the Cross-Database Hyperlinks settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).

You need to configure the Cross-Database Hyperlinks settings on:

  • The server to which the WebX client connects. This is the 'local system' for the WebX client.
  • The servers that run the databases that contain the 'target' displays. This only applies if the 'target' displays have hyperlinks to items that are stored in other databases (either backlinks to the WebX client’s 'local system' or forward links to other displays stored on other systems).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select WebX to display the WebX section.
  4. In the Cross-Database Hyperlinks section, right-click on the list to display a context sensitive menu.
  5. Select the Add option to display the Add Hyperlink window.
  6. Configure the settings as follows:
  • System Name—Enter the name of the ‘target’ system (the name of the database that contains the displays to which the hyperlinks connect).
  • Node Name—Enter the name or IP address of the server that runs the 'target' system (the server that runs the database that contains the ‘target’ display).
  • Port Number—Enter the number of the non-secure web server port (XML) used by the ‘target’ system. This has to match the number configured in the Non-Secure field in the WebX settings for the ‘target’ system (see Define the Ports Settings for WebX Clients in the ClearSCADA Guide to Security).
  • Secure Port Number—Enter the number of the secure web server port (XML) used by the ‘target’ system. This has to match the number configured in the Secure field in the WebX settings for the ‘target’ system (see Define the Ports Settings for WebX Clients in the ClearSCADA Guide to Security).
  7. Select the OK button to confirm the hyperlink settings and close the Add Hyperlink window. The hyperlink settings you have defined are shown in the list in the Cross-Database Hyperlinks section.
  8. Repeat steps 4-7 inclusive for each system as appropriate.
  9. Put the changes you have made into effect by right-clicking on the system name and selecting the Apply Changes option from the context sensitive menu.

Example:

A Mimic named 'Pipeline 6' is created in ViewX on a system named 'ControlSiteA'.

The 'Pipeline 6' Mimic is configured to contain a hyperlink to a Mimic named 'Valve Controls' on another system called 'Site44'.

The node name of the server that runs the 'Site44' database is 'Pd16' and it uses port 82 for its non-secure, XML web connection and port 445 for its secure XML web connection (the web server ports are defined in the WebX settings on the Server Configuration Tool on the 'Site44' server).

A user logs on to a WebX client that connects to the ‘ControlSiteA’ server. The user displays the ‘Pipeline 6’ Mimic and selects the hyperlink to the ‘ValveControls’ Mimic that is stored in the database of the ‘Site44’ system. However, as the Cross-Database Hyperlinks settings have not been configured correctly on the ‘ControlSiteA’ server, the ‘ControlSiteA’ server cannot determine which system contains the ‘target’ display for the hyperlink. As a result, the ‘target’ display cannot be shown and a diagnostics message is displayed.

The Cross-Database Hyperlinks settings are reconfigured on the ‘ControlSiteA’ server. They are configured so that the System Name is Site 44, the Node Name is Pd16, the Port Number is 82 and the Secure Port Number is 445. These match the system name, node name and port settings (for the WebX server) of the ‘Site44’ server.

With the corrected Cross-Database Hyperlinks settings in place, the user re-displays the Mimic on the WebX client and selects the hyperlink to the ‘Valve Controls’ Mimic. As the ‘ControlSiteA’ server now has the correct Cross-Database Hyperlinks settings, it can use the information in the hyperlink to identify the location of the ‘target’ display as being the ‘Site44’ server. As a result, the ‘target’ display (the ‘Valve Controls’ Mimic) is displayed on the WebX client.


Server Administration Guide - Exclusive Control Settings

Exclusive Control Settings

You can use the ClearSCADA Server Configuration Tool to define which permissions are only available to a user with exclusive control. When a user has exclusive control of an item, other users have limited access to the item and its features.

The features that are available to a user with exclusive control are dependent on the settings that are defined on the Exclusive Control section of the ClearSCADA Server Configuration Tool. The permissions that are selected on the ClearSCADA Server Configuration Tool are only available to the user with exclusive control. For example, if the Edit Notes permission is selected, only the user with exclusive control of a point named 'Input Signal' will be able to edit the notes for the 'Input Signal' point (while the point is under exclusive control).

Exclusive control can be taken or released by a user. Users with the Manage Excl Ctrl security permission can take exclusive control from other users as required.

To define which permissions are reserved for a user with exclusive control (when exclusive control is taken):

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch.
  3. Select the Exclusive Control branch.
  4. Use the Enabled check box to enable and disable the exclusive control feature. If you select the check box, the exclusive control feature is available and users will be able to take, release, and manage exclusive control (depending on the permissions that are allocated to their user accounts). If you clear the check box, the exclusive control feature is not available.
  5. Select those permissions that you want to be reserved for use by the user with exclusive control. If an item is under exclusive control, the features that are made available via the selected permissions will only be available to the user with exclusive control (for that item). When the user releases exclusive control, the permissions will be returned to other users except those who cannot have the permissions (due to their user account configuration) for that item.

For information on the various permissions, see Permissions for Database Items in the ClearSCADA Guide to Security.

  6. Use the Available on Group Menus Only check box to define whether the exclusive control options (Take Exclusive Control, Release Exclusive Control etc.) are available on individual items or only on Group items. If you select the check box, users will only be able to use the exclusive control options on entire groups of items; if you clear the check box, users will be able to use the exclusive control options on individual items.
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

For more information on Exclusive Control and permissions, see Exclusive Control in the ClearSCADA Guide to Security.

When you have defined the exclusive control settings, you can continue with the server configuration as required.


Server Administration Guide - Locations of the Database Folders

Locations of the Database Folders

You can use the ClearSCADA Server Configuration Tool to change the locations of the various components of the database. This may be necessary due to the size of the files (the Historic Data and Event Journal in particular) causing slower performance.

You can relocate the:

  • Metadata (the configuration of any extra database fields)
  • Configuration and database structure
  • Current data
  • Permit data
  • Historic data
  • Event Journal data
  • Historic files
  • Data file directory (Data Files)
  • Archive Index
  • Configuration changes data.

The Locations feature is often used to set the Metadata, Configuration, (current) Data, Data Files and Archive Index to be stored on one drive, with the Historic data and Event Journal set to be stored on a second drive.

NOTE: The Historic Data and Event Journal parts of the database are usually much larger than the other parts and are often stored on a dedicated hard disk or RAID array.

To change the location of your database components:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select Location to display the Location section.

The Locations display allows you to define the locations for:

  • Metadata—This file contains the configuration of custom fields (see Extra Database Fields).
  • Configuration—This directory contains the files that store the configuration of your database items as well as the structure files that contain the database hierarchy information. The definitions of Crystal Reports are not stored in the Configuration files; they are stored in the Data Files location.

The number of configuration files on your system may increase over time as you add more items to the database. The number of configuration files is the same as the number of data files.

  • Data—This directory contains the files that store the current values of your database items, with the exception of Data Tables and latest generated Crystal Reports (which are stored in the Data Files location).

The number of data files on your system may increase over time as you add more items to the database. The number of data files is the same as the number of configuration files.

  • Permit—This folder contains the file that stores configuration permit data for your system.
  • Historic Data—This folder contains the historic data files relating to database points and includes annotations, modifications, and units.
  • Event Journal—This folder contains the Event Journal data files (a record of the events on your system)
  • Historic Files—This folder contains various time stamped historical data files, including Crystal Reports (the .rpt files), and upload reports.
  • Data Files—This folder contains data file directory information including details relating to Data Tables, Crystal Reports definition files, and the latest Crystal Reports data files as well as some other driver-specific files.
  • Archive Index—This file contains an index of the data archived by the server, including information about the archive volumes on which each section of archived data is stored. Each server has its own archive index file which needs to be backed up separately. For more information, (see Manage Your Archive Volumes).
  • Config. Changes—This folder contains the configuration changes files for your system (see Settings for Configuration Changes Auditing).

By default, the various database files are placed in these directories:

C:\Program Data\SchneiderElectric\ClearSCADA\Database

(The location above is for Windows Vista and Windows 2008 Server)

C:\Documents and Settings\All Users\Application Data\SchneiderElectric\ClearSCADA\Database

(The location above is for Windows XP and Windows 2003 Server).

NOTE: When a system is being upgraded, the locations that are already in place are used.

  4. Either:
  • Enter the new location for a database component in the corresponding field. For example, if you want to change the location of the Historic data, enter the new location in the Historic data field.

If the folder does not exist, ClearSCADA will create the folder (and any parent folders defined in the new location) automatically.

Or:

  1. Select the Browse button next to the field for the database component that you want to relocate. For example, if you want to change the location of the Historic data, select the browse button next the Historic data field.
    A browse window is displayed.
  2. Use the browse window to locate the folder that is to be the new location of the database component. If the folder does not already exist, you can use the browse window's New Folder button to create a new folder.
  3. Select the new location.
  4. Select the OK button to close the browse window and change the location for the selected database component.

NOTE: If you are copying a database file from another system, you may need to rename the file as older systems used a different naming convention. Older systems used ClearSCADA.dat for the configuration and ClearSCADAData.dat for the values. On new systems, ClearSCADA.dat has been replaced by ClearSCADAConfig.dat while ClearSCADAData.dat remains as ClearSCADAData.dat.

  5. Repeat step 4 for each database component that you want to re-locate.
  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have finished defining the locations, you can continue with the server configuration. If you are unfamiliar with the server configuration process, we suggest you proceed to learn about Logging and Monitoring.

Further Information

Data Tables: see Configuring Data Tables in the ClearSCADA Guide to Core Configuration.


Server Administration Guide - Logging and Monitoring

Logging and Monitoring

ClearSCADA consists of multiple applications. Each of these applications can produce log files that contain a record of the application's activity. The log files are useful when investigating unexpected situations on your system.

Each application in ClearSCADA has its own log file settings, and you can choose to enable or disable logging for each application as required. Typically, you would leave some logging enabled so that if an unexpected situation occurs, there is some information about what happened. However, you need to be selective when enabling logging as some logging options produce a large amount of output and should only be enabled in specific circumstances.

Some of the applications that form ClearSCADA also contain a Telnet server that allows them to be monitored in real time. This provides 'live' monitoring as opposed to the 'snapshot' of data that is provided in log files.

In this section, we explain:

  • Server Logging—provides logging for a ClearSCADA server.
  • Driver Logging—provides logging for an individual driver.
  • Communications Logging—provides logging of data transmitted and received via an individual channel.
  • Port Server Logging—provides logging for the port server.
  • Alarm and Event Printer Logging—provides logging for the alarm and event printer.
  • License Server Logging—provides logging for client licenses (information about requests, expires etc.)
  • Telnet Monitoring
  • Server Snapshot Log Files.

The log files and Telnet server for some applications can only be configured using a registry editor (see Using a Registry Editor to Change Server Log File Settings).

The location of the log files on a particular server can be changed at once by using the ClearSCADA Server Configuration Tool (see Move all New Log Files to a Different Location).

For information on the DBStartup log file which provides information about the startup process, see Access the DBStartup Log File.

NOTE: Many log files contain information that is only of use to expert users such as
Schneider Electric engineers. Normally, you will only be required to enable a particular type of logging and provide Schneider Electric with information from the log file (or the log file itself). If you are familiar with the particular protocol then you should understand the contents of the comms log files. However, the contents of the other files are designed to be analyzed by Schneider Electric engineers only.


Server Administration Guide - Server Logging (Logging and Monitoring)

Server Logging

Server log files provide information about activity at the server and can be used to help diagnose unexpected situations on your system, such as unrecognized client requests, errors caused by lack of disk space etc.

If you contact Schneider Electric for support, you may be asked to provide server log files. In the following sections, we explain how to configure your system for server logging and how to create and view server log files:

  • Define the Server Logging Settings
  • Enable or Disable Server Logging
  • Enable or Disable Exception Dumps
  • Define the Location of Server Log Files and Exception Dumps
  • Store New Log Files in One Folder
  • Filter the Content of the Server Log Files
  • Display a Server Log File.

For information on Snapshot log files, see Server Snapshot Log Files.


Server Administration Guide - Define the Server Logging Settings (Logging and Monitoring)

Define the Server Logging Settings

To define the server logging settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select Logging to display the Logging section.
  4. In the Server section, define these settings:
  • Enabled—Select the Enabled check box to enable server logging, or clear the Enabled check box to disable server logging.

We recommend that you enable the server logging feature so that there are records of any errors. You can use the Server Status Tool to control the contents of the server log files—this can limit the load caused by the logging. (see Filter the Content of the Server Log Files).

  • File Base—Use the File Base field to define the folder that will contain the server log files and the filename prefix for the files. The prefix is the name of the files (it cannot contain certain characters, see your operating system documentation for more details).

Either:

  • Type in the path and prefix

Or:

  • Use the browse button to locate the required folder, then type the prefix at the end of the path, for example, C:\TEMP\Serverlog
  • Maximum size of each file—Use this field to define the largest possible size for each server log file. The size is in kilobytes.

By limiting the size of individual log files, you can set ClearSCADA to only create log files that are a manageable size. For example, you can set the file size limit so that the files are a suitable size for viewing in Notepad and sending via e-mail.

  • Maximum number of files—Use to define the largest number of server log files that will be retained. When a new file is created, the oldest file is deleted.

Example:

The maximum number of files is set to 2. The system has two log files: db_001.log and db_002.log.

When the db_002.log file exceeds its size limit, a new file is generated. The oldest log file (db_001.log) is deleted to make room for the new file. The new file is named db_003.log.

When setting the Maximum number of files, you need to consider the amount of storage space that is available and the potential size of each log file. You should also consider how quickly the size of the log files is increasing, for example, if you have two 2MB files and it is logging 100K per minute, the log files will only contain 40 minutes' worth of information (each file covering 20 minutes).

  • Number of old files to keep—Use this field to define the number of sets of log files that can be stored.

Each time the server is started, the existing set of log files are renamed so that a new set of log files can be stored. The Number of old files to keep setting defines how many sets of log files the server can store. If the number of log file sets reaches the defined amount, any new sets of log files will use the space occupied by the oldest existing log files (the oldest sets of files are deleted). The existing files are renamed.

Example:

The number of old files to keep is set to 2. The server stores 3 log files:

DB_001.log (current)

DB_001.log_2 (previous)

DB_001.log_3 (one before previous)

The server is re-started and so a new log file needs to be created.

The server deletes the oldest file (DB_001.log_3) and renames the existing files:

DB_001.log is renamed so that it becomes DB_001.log_2.

DB_001.log_2 is renamed so that it becomes DB_001.log_3.

The new log file is stored as DB_001.log.

You should consider the amount of storage space that is available before you define the number of old files that are retained. You should also consider how often the server is re-started. For many systems, the default setting of 1 is adequate.

  • Telnet Port—Use this field to define the TCP/IP port for the server's Telnet server (see Telnet Monitoring).

If you use a fixed port for the Telnet server, you should enter the number of the port. You should use 'registered ports' in the range 1024 to 49151 inclusive (for more information, see http://www.iana.org/assignments/port-numbers).

If there is no port number specified (i.e. it has the default setting of 0), the operating system will allocate a new port each time the server is re-started—you will need to determine which port the operating system has allocated each time you need to monitor the server. You can view the port numbers that have been allocated by the operating system by examining the General/Information display of the ClearSCADA Server Status Tool (or Diagnostics web page on the web interface).

You also need to specify a Telnet Port when a firewall is being used—you need to specify the port so that it can be opened on the firewall.

For more information on Telnet, see Telnet Monitoring.

  5. In the Exception Dumps section, define these settings:
  • Enabled—Select the Enabled check box to activate the exception dumps feature (or clear it if you want to disable the feature). The exception dumps feature will be activated/deactivated on the ClearSCADA applications that are running on the server, including drivers.

The exception dumps feature allows diagnostic files to be created when there is an exception (application error). We recommend that you enable the exception dumps feature.

  • Location—Use the browse button next to the Location field to specify the folder that will contain the exception dump files.
  • Maximum Number of Files—Enter the maximum number of exception dump files that can be stored in the defined location. If the number of exception dumps exceeds the defined limit, the oldest exception dumps are deleted to make space for the new exception dumps.

We recommend that you use the default setting of 20 unless you are specifically advised to change the setting by Schneider Electric staff.

  • Maximum Size of All Files—Enter the maximum amount of disk space that can be used to store the exception dump files. If the exception dumps exceed the defined limit, the oldest exception dumps are deleted to make space for the new exception dumps.

We recommend that you use the default setting of 100 MB unless you are specifically advised to change the setting by Schneider Electric staff.

  • Dump Type—Choose the amount of data that is included in the exception dumps. You can choose between Normal and Full. We recommend that you set the Dump Type to Normal unless specifically advised to change the setting to Full by Schneider Electric staff. The Full setting can create large dump files that can take a considerable amount of time to generate.
  6. You can use the Move Log Files wizard to change the location of all of the log files on a server at once. This includes server logs, driver logs etc., and only applies to new log files—the Move Log Files wizard does not move existing files. This will save you time if you need to every log file, for example, if you are moving the log files to another disk.

If you want to move the new log files into a new location, use the Browse button to select the required location. New log files will be stored in the specified location. Any existing files will not be moved. If you want to move the existing files to a new location, you will need to stop the server then use Windows Explorer to relocate the files.

If you do want to leave the new log files in their current location, ignore the Move Log Files wizard and proceed to the next step. The new log files will be stored in the default locations or the locations that are already configured.

  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Enable or Disable Server Logging (Logging and Monitoring)

Enable or Disable Server Logging

You can use the ClearSCADA Server Configuration Tool to enable or disable the server logging feature. The server logging feature, when enabled, creates log files that contain information about the server's activities.

To enable or disable server logging, see Define the Server Logging Settings.


Server Administration Guide - Enable or Disable Exception Dumps (Logging and Monitoring)

Enable or Disable Exception Dumps

Exception dumps are files that contain diagnostic data relating to unexpected application crashes. They are extremely useful when attempting to determine the cause of serious application issues.

We recommend that you enable the exception dumps feature, see Define the Server Logging Settings.


Server Administration Guide - Define the Location of Server Log Files and Exception Dumps (Logging and Monitoring)

Define the Location of Server Log Files and Exception Dumps

You can use the ClearSCADA Server Configuration Tool to define the location of server log files and exception dumps. For more information, see Define the Server Logging Settings.


Server Administration Guide - Store New Log Files in One Folder (Logging and Monitoring)

Store New Log Files in One Folder

You can use the ClearSCADA Server Configuration Tool to set new log files (server log files, client log files, driver log files etc.) to be stored in the same location. This reduces the amount of time it takes to move log files to a different location, for example, when moving the log files to another disk. For more information, see Define the Server Logging Settings.


Server Administration Guide - Filter the Content of the Server Log Files (Logging and Monitoring)

Filter the Content of the Server Log Files

You can use the ClearSCADA Server Status Tool to control what data is included in the server log files. By enabling or disabling the various logging classes, you can control what information is included in the server log files. To do this, you need to access the General/Logging display on the ClearSCADA Server Status Tool.

To enable or disable the various logging classes:

  1. Run the Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).
  2. Expand the General folder and select Logging.

The Logging section lists the logging classes.

  3. Right-click on a class to display a context sensitive menu.
  4. Select:
  • Enable—To enable logging for a class. The enabled logging classes will have an effect on the load, which can become excessive depending on the operations being performed.
  • Disable—To disable logging for a class.
  • Enable All—To enable logging for all classes.
  • Default—To enable the default logging settings for the classes. We recommend that you use this option unless instructed to enable/disable logging for specific classes by Schneider Electric engineers.
  • Minimal—To enable the minimal suggested logging settings. Schneider Electric engineers may request you to select this option if there is an excessive load on your system.
  • Disable All—To disable logging for all classes.

We recommend that you select the Default setting. You can then use the log files to investigate unexpected occurrences, or you can pass the information in the log files on to Schneider Electric staff for analysis.

Further Information

Define the Server Logging Settings.

Display a Server Log File.


Server Administration Guide - Display a Server Log File (Logging and Monitoring)

Display a Server Log File

You can use server log files to investigate the cause of unusual server conditions. The server log files are filtered according to the logging settings for the classes in the General/Logging display of the ClearSCADA Status Tool (see Filter the Content of the Server Log Files).

Typically, you will be advised to display a log file by Schneider Electric staff so that they can assist you in diagnosing unexpected server conditions.

To display a server log file:

  1. Right-click on the ClearSCADA Server icon in the Windows taskbar to display a context sensitive menu.
  2. Select the option for the relevant log file, for example, View DB_611.Log.
    The server log file is displayed.

NOTE: You can use a Telnet client to monitor a server in realtime (see Telnet Monitoring).

Further Information

Define the Server Logging Settings.

Filter the Content of the Server Log Files.


Server Administration Guide - Driver Logging (Logging and Monitoring)

Driver Logging

Each driver can generate log files that contain information about the driver's activity. These log files can then be used to diagnose unexpected driver behavior.

To setup driver logging, you need to Define the Driver Logging Settings. When you have setup the driver logging, you can use the ClearSCADA Server Status Tool to Display a Driver Log File.

NOTE: You can also use a Telnet client to monitor a driver in realtime (see Telnet Monitoring).


Server Administration Guide - Define the Driver Logging Settings (Logging and Monitoring)

Define the Driver Logging Settings

You can use the ClearSCADA Status Tool to define the log file settings for simple drivers and any advanced drivers that are currently running.

To change the log file settings for an advanced driver that is not currently running, please contact customer support. This is because to change the log file settings for non-running advanced drivers, you will need to adjust the driver registry settings.

ATTENTION: Only change the driver registry settings with expert guidance from Schneider Electric customer support. Making incorrect changes could result in system instability or the driver not being able to run.

To change the logging settings for a simple driver or an advanced driver that is running:

  1. Run the Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).
  2. Select the Status option to display the ClearSCADA Server Status Tool.
  3. Expand the General folder then select Modules.

The Modules section lists the ClearSCADA drivers (some of which may not be installed on your system).

  4. Right-click on the driver for which you want to setup logging.
    A context sensitive menu is displayed.
  5. Select the Logging option.
    The Logging window for the driver is displayed.
  6. Use the Current Options tab to temporarily change the logging options for the driver. The driver will revert back to the default logging settings the next time it starts. You can change the logging options by selecting or deselecting them in the Options list or you can use the buttons as follows:
  • Typical—Selects the logging options that are usually required by the driver.
  • Select All—Selects the entire range of logging options for the driver. Normally, certain logging options should be disabled as they fill the log files very quickly. If you attempt to enable such a logging option, ClearSCADA will display a message prior to enabling the option.
  • Clear All—De-selects all of the logging options for the driver. By selecting the Clear All button, you empty the log file for the driver.
  • Make Default—This button sets the currently selected Options as the default options. These options will be used by default when the driver is restarted. If you select this button, the settings on the Current Options tab are copied to the Default Options tab.
  7. Use the Default Options tab to change the logging options that are used each time the driver starts. These options will become the current options the next time the driver starts.

As with the Current Options tab, you can select the various logging options manually from the Options list or you can select one of the buttons. The Make Current button works in a similar way to the Make Default button except that it copies the options on the Default Options tab to the Current Options tab.

  8. Use the Configuration tab to setup the logging for the driver:
  1. Select/clear the Enabled check box to enable/disable logging for the driver.
  2. Use the Browse button for the File Base field to set the location of the driver's log files.
  3. Define the Maximum size of each file to limit the possible size of each log file.
  4. Define the Maximum number of files to limit the amount of individual driver log files that can be stored simultaneously.
  5. Define the Number of old files to keep to limit the number of sets of driver log files that can be stored.
  6. Enter the number for the TCP/IP port in the Telnet Port field.

If you use a fixed port for the Telnet server, you should enter the number of the port. You should use 'registered ports' in the range 1024 to 49151 inclusive (for more information, see http://www.iana.org/assignments/port-numbers).

If you set the port number to 0, the operating system will allocate a new port each time the driver is re-started—you will need to determine which port the operating system has allocated each time you need to monitor a driver. You can view the port numbers that have been allocated by the operating system by examining the Telnet Port column in the Modules display of the ClearSCADA Server Status Tool (or Diagnostics web page on the web interface).

You also need to specify a Telnet Port when a firewall is being used—you need to specify the port so that it can be opened on the firewall.

For more information on Telnet, see Telnet Monitoring.

  7. Select the Apply button to apply the changes or select the OK button to apply the changes and close the Logging window.

Further Information

Display a Driver Log File.


Server Administration Guide - Define the Type of Information that is Included in Driver Log Files (Logging and Monitoring)

Define the Type of Information that is Included in Driver Log Files

You can use the Logging window to define the type of information that is included in the driver log files (see Define the Driver Logging Settings).


Server Administration Guide - Enable or Disable Logging for a Driver (Logging and Monitoring)

Enable or Disable Logging for a Driver

You can use the Logging window to enable or disable driver logging for a particular driver (see Define the Driver Logging Settings).


Server Administration Guide - Define the File Settings for Driver Logging (Logging and Monitoring)

Define the File Settings for Driver Logging

You can use the Logging window to define the file settings for driver log files, such as maximum size and maximum number (see Define the Driver Logging Settings).


Server Administration Guide - Display a Driver Log File (Logging and Monitoring)

Display a Driver Log File

You can use driver log files to diagnose unexpected driver behavior. You can only display a driver's log file if the driver has been setup for logging (see Driver Logging).

To display a driver log file:

  1. Run the Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).
  2. Expand the General folder then select Modules. The Modules section lists the ClearSCADA drivers (some of which may not be installed on your system).
  3. Right-click on the driver for which you want to display the log file.
    A context sensitive menu is displayed.
  4. Select the relevant View <Driver> option to display the log file, for example, select the View DriverDNP3_001.log option to display a log file for the DNP3 driver.

Further Information

Define the Driver Logging Settings.


Server Administration Guide - Communications Logging (Logging and Monitoring)

Communications Logging

Communications log files provide a record of communications between the drivers and the outstations and modems. They provide diagnostic information that can be used when investigating unexpected system activity.

There are 2 types of communications log file:

  • IO log files—Provide a complete log of communications between a driver and the outstations/modem, including data that was discarded by the driver.
  • Comms Log files—Provide a log of only the 'good' communications between a driver and the outstations/modem, filtering out any data that was discarded by the driver. The driver will discard data that is not a modem response or does not have the correct structure and checksum for the protocol.

Advanced drivers support both types of communication log. Simple drivers have a hybrid type of log file that are a combination of IO and communications—these hybrid types of log file are also referred to as 'comms logs'.

NOTE: If you contact Schneider Electric for assistance, you may be asked to create a communications log file.

There are separate log files for each channel. The names of the log files use the following format:

Driver<name> <port> <type>_<nnn>.log

Where Driver <name> is the name of the driver, <port> is the name of the port, <type> is the type of log file (IO or Comms), and <nnn> is a sequence number, such as 003. For example, DriverSCADAPackModbus COM1 IO_001.log

To maximize system performance, you should only enable communications logging on a channel when required. You should leave communications logging disabled at other times.

This section includes:

  • Enable or Disable I/O Logging on a Channel
  • Display a Channel's I/O Log File
  • Enable or Disable 'Normal' Communications Logging on a Channel
  • Understanding Communications Log Files
  • Communications Logging Status.


Server Administration Guide - Enable or Disable I/O Logging on a Channel (Logging and Monitoring)

Enable or Disable I/O Logging on a Channel

I/O log files can be very useful when attempting to diagnose the cause of unexpected communication problems. If you experience communications problems on your system, Schneider Electric support staff may request that you enable I/O logging and provide the resultant log file.

To maximize system performance, you should only enable I/O logging on a channel when required. You should disable I/O logging at other times.

When you have finished monitoring the communications, we advise that you disable the logging feature. This helps to ensure better system performance and that available disk space is optimized.

To enable or disable I/O logging on a channel:

  1. Run ViewX and log on.

NOTE: To enable or disable I/O logging for a channel, you need to log on via a user account that has the Diagnostics permission.

  2. Use the Database Bar to locate the required channel.

Alternatively, you can locate the channel in a List or on a Mimic that contains an animated representation of the channel (the Mimic item has to be associated with the channel's pick action menu).

  3. Right-click on the channel (select the channel if you are using a List or Mimic).
    A context sensitive menu is displayed.
  4. Either:
  1. Select the Enable IO Logging option.
    The Enable IO Logging window is displayed.
  2. Use the Enable IO Logging window to determine whether the IO logging continues until it is disabled manually:
  • Select the Persist check box to set IO logging so that it remains enabled until it is explicitly disabled. IO logging will remain enabled even after the driver stops or a changeover occurs.
  • Clear the Persist check box to temporarily enable IO logging—IO logging is enabled but will end when the driver stops or a changeover occurs.
  3. Select the OK button.
    An IO log file is generated. It contains details about the communications via the selected channel from the current time.

Or:

  • Select the Disable IO Logging option.
    The current log file will be closed and no further log files will be created (see Enable or Disable I/O Logging on a Channel).

When you have enabled logging for the channel, you can proceed to Display a Channel's I/O Log File.


Server Administration Guide - Display a Channel's I/O Log File (Logging and Monitoring)

Display a Channel's I/O Log File

When you have enabled I/O logging for a channel, you can display the I/O log file in Notepad or a similar text editor application.

NOTE: Only advanced drivers can have I/O and Comms log files. Simple drivers have a single type of log file (simple driver log files are similar to I/O log files).

To display a communications log file:

  1. Run the Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).
  2. On the Server Status ToolServer Status Tool, first expand the system and server, then expand the General folder and select the Modules option.
    The Modules status is displayed. This shows the drivers and their current status.
  3. Right-click on the relevant driver in the list, for example, the SCADAPack Modbus driver.
    A context sensitive menu is displayed.
  4. Select the View <driver name> <port> IO_<nnn>.log option, for example View DriverModbus COM1 IO_001.log.
    The selected log file is displayed in Notepad.

Or:

  1. Use Windows Explorer to locate the log file. If you are unsure as to where the file is located, see Locating the Log Files.
  2. Right-click on the log file, then select Open With, then choose Notepad from the list of applications.
    The selected log file is displayed in Notepad.

Further Information

Understanding Communications Log Files.


Server Administration Guide - Enable or Disable 'Normal' Communications Logging on a Channel (Logging and Monitoring)

Enable or Disable 'Normal' Communications Logging on a Channel

'Normal' communication log files store information about 'good' communications between the ClearSCADA server and the outstations and modems. This information is useful when investigating the possible causes of unexpected communications problems. If you experience communications problems on your system, Schneider Electric support staff may request that you enable communications logging and provide the resultant log file.

To maximize system performance, we advise that you only enable communication logging on a channel when required. You should leave it disabled at other times.

When you have finished logging the communications, we recommend that you disable the logging feature. This helps to ensure better system performance and that available disk space is optimized.

NOTE: Only advanced drivers can have I/O and Comms log files. Simple drivers have a single type of log file (simple driver log files are similar to I/O log files).

To enable or disable 'normal' communications logging for a channel:

  1. Run ViewX and log on.

NOTE: To create a 'normal' log for a channel, you will need to log on via a user account that has the Diagnostics permission.

  2. Use the Database Bar to locate the channel for which you want to generate a 'normal' log.

Alternatively, you can locate the channel in a List or on a Mimic that contains an animated representation of the channel (the Mimic item has to be associated with the channel's pick action menu).

  3. Right-click on the channel (select the channel if you are using a List or Mimic).
    A context sensitive menu is displayed.
  4. Either:
  1. Select the Enable Comms Logging option.
    The Enable Comms Logging window is displayed.
  2. Use the Enable Logging window to determine whether the logging continues until it is disabled manually:
  • Select the Persist check box to set communications logging so that it remains enabled until it is explicitly disabled. Communications logging will remain enabled even after the driver stops or a changeover occurs.
  • Clear the Persist check box to temporarily enable communications logging—communications logging is enabled but will end when the driver stops or a changeover occurs.
  3. Select the OK button.
    A log file is generated. It contains details about the communications via the selected channel from the current time.

Or:

  • Select the Disable Comms Logging option.
    No new log files are created for the channel, even if the Persist feature was enabled (see Enable or Disable I/O Logging on a Channel)

When you have enabled communications logging for the channel, you can proceed to Display a Channel's Comms Log File.


Server Administration Guide - Display a Channel's Comms Log File (Logging and Monitoring)

Display a Channel's Comms Log File

When you have enabled comms logging for a channel, you can display the comms log file in Notepad or a similar text editor application.

NOTE: Only advanced drivers can have I/O and Comms log files. Simple drivers have a single type of log file (simple driver log files are similar to I/O log files).

To display a communications log file:

  1. Run the Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).
  2. On the Server Status Tool, first expand the system and server, then expand the General folder and select the Modules option.
    The Modules status is displayed. This shows the drivers and their current status.
  3. Right-click on the relevant driver in the list, for example, the SCADAPack Modbus driver.
    A context sensitive menu is displayed.
  4. Select the View <driver name> <port> Comms_<nnn>.log option, for example View DriverSCADAPackModbus COM1 Comms_001.log.
    The selected log file for the driver is displayed in Notepad.

Or:

  1. Use Windows Explorer to locate the log file. If you are unsure as to where the file is located, see Locating the Log Files.
  2. Right-click on the log file, then select Open With, then choose Notepad from the list of applications.
    The selected log file is displayed in Notepad.

Further Information

Understanding Communications Log Files.


Server Administration Guide - Understanding Communications Log Files (Logging and Monitoring)

Understanding Communications Log Files

Each communications log file consists of two sections. The top section contains information about the channel's settings, for example, the parity and flow control. The bottom section contains the data packets and timestamps.

Top section contains channel settings
Bottom section contains packets of data

The packet entries that begin TX are the transmitted communication packets (the communications from the ClearSCADA driver to the outstations, PLCs etc. that are connected to the selected channel).

The packet entries that begin RX are the received communication packets (the communications from the outstations, PLCs etc.).

IO log files can contain a word after each TX or RX entry. The word describes the ClearSCADA server's response to the communication packet. The response can be:

  • Rx ACCEPTED—The packet was read successfully.
  • Rx REJECTED—The data was read but was discarded. Data is rejected if the packet is invalid, for example, if the data is in an unrecognized format.
  • Rx FAILED—ClearSCADA has recognized a packet as being correctly framed, but upon further investigation has detected a problem with the packet, for example, the checksum is invalid.
  • Rx PURGED—A partial packet was read, but a parity error or timeout occurred before it was completed, so the port was purged.
  • Tx PENDING—The driver is waiting to transmit the data because it is already transmitting data via the channel. This may occur when ClearSCADA is transmitting data and receives new data at the same time—the driver may need to reply to the new data immediately but cannot because it is already transmitting data via the channel. The reply to the new data is 'pending' and will be sent as soon as the channel is available.
  • Tx—The transmitted packets have no description after the TX.


Server Administration Guide - Communications Logging Status (Logging and Monitoring)

Communications Logging Status

You can use the following displays to view the communications logging status:

  • View windows for channels (see Communications Logging Status on Status Displays).
  • Mimics (see Communications Logging Status on Mimics).
  • Lists (see Communications Logging Status on Lists).

Communications Logging Status on Status Displays

On Status displays (also referred to as View windows or View dialogs), the logging status is indicated by these entries:

  • Comms Logging
  • IO Logging
  • Telnet

To access a View window, select the View Status option on the context sensitive menu for a channel (either in the Database Bar, on the Channels List, or on a Mimic that contains an animated representation of the channel.

The value for these entries is one of the following:

  • Enabled—Comms logging, IO logging, or Telnet monitoring is in progress. For Telnet, the status information also includes the number of the port on which Telnet is running.
  • Enabled (Persist)—Comms logging, IO logging, or Telnet monitoring is in progress and will continue after the system has been shutdown and re-booted and after a server changeover. For Telnet, the status information also includes the number of the port on which Telnet server is running.
  • Disabled—Comms logging, IO logging, or Telnet monitoring is de-activated.

Communications Logging Status on Mimics

Mimics can contain animated representations of a channel. The Mimic can be configured to indicate the channel's log status as a background color. If logging is enabled on the channel, the background is dark yellow/mustard (default settings).

If logging is disabled on the channel, the background color is white (default settings).

The change of color is a visual indication of logging being enabled. This can act as a reminder that logging needs to be disabled (it should only be enabled when you need to monitor communications).

To access a Mimic that contains an animated representation of a channel, you can:

  • Either:
  1. Use the Database Bar to locate the Mimic.
  2. Right-click on the Mimic.
    A context sensitive menu is displayed.
  3. Select the Display option.
    The Mimic is displayed.

Or:

  • Select a hyperlink to the required Mimic (if a hyperlink has been configured).

Communications Logging Status on Lists

The Channels List uses color to indicate the logging status of channels. The background color of each channel's row represents the logging status—if it is white, logging is disabled for the channel; if it is dark yellow/mustard, logging is enabled for the channel.

The change of color is a visual indication of logging being enabled. This can act as a reminder that logging needs to be disabled (it should only be enabled when you need to monitor communications).

For information on accessing Lists, see see Display a List in the ClearSCADA Guide to Lists.


Server Administration Guide - Port Server Logging (Logging and Monitoring)

Port Server Logging

For information on Port Server logging, please refer to:

  • Enable Logging for the Port Server
  • Access the Port Server's Log File
  • Changing the Content of the Port Server Log Files.


Server Administration Guide - Alarm and Event Printer Logging (Logging and Monitoring)

Alarm and Event Printer Logging

The Alarm and Event printer application allows alarms and events from an OPC alarm and event server, such as ClearSCADA, to be printed on a serial printer or similar device. You can enable logging on this application to monitor the activity of the application, and help diagnose any unexpected issues, such as complications with the serial port connection.

To enable or disable alarm and event printer logging, you need to configure the logging settings via a registry editor (see Using a Registry Editor to Change Server Log File Settings).

To display an alarm and event printer log file:

  1. Use Windows Explorer to locate the log file. The log file is stored at the location that is specified in the LogFileBase registry setting.

The location of the LogFileBase registry setting is:

HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\AEPrinter\LogFileBase

  2. Open the log file in a text editor program, for example, Microsoft Windows Notepad.


Server Administration Guide - License Server Logging (Logging and Monitoring)

License Server Logging

License server log files contain information about requests from the client to the license server. This includes information about requests for client licenses, allocation of client licenses, errors relating to connections, dongle errors and removals, client license expiries etc.

To enable or disable license logging, you need to configure the logging settings via a registry editor (see Using a Registry Editor to Change Server Log File Settings).

To display a license log file:

  1. Use Windows Explorer to locate the log file. The log file is stored at the location that is specified in the LogFileBase registry setting.

The location of the LogFileBase registry setting is:

HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\LicenseServer\
LogFileBase

(on 32 bit systems)

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Schneider Electric\ClearSCADA\
LicenseServer\LogFileBase

(on 64 bit systems)

  2. Open the log file in a text editor program, for example, Microsoft Windows Notepad.


Server Administration Guide - Using a Registry Editor to Change Server Log File Settings (Logging and Monitoring)

Using a Registry Editor to Change Server Log File Settings

You can use a registry editor such as Regedit to make changes to the log file settings (such as maximum number of files, location of files etc.). For some applications, such as port server, the only way to alter the log file settings is to use a registry editor.

To use a registry editor to change log file settings:

  1. Select the Start button on the Windows taskbar, then select the Run option to display the Run window.
  2. Enter the following text in the Open field and select OK to run the registry editor:
Regedit

  3. Use the Registry Editor to locate the registry settings at the relevant location:
  • Alarm and Events Printer—The registry settings are at:
HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\AEPrinter

  • Drivers—The registry settings are at:
HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\Driver<Driver Name>

For example:

HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\
DriverSCADAPackModbus

  • Channels—Communications logs use the same settings as the relevant driver. There are no registry settings for channel logs.
  • License Server—On 32 bit systems, the registry settings are at:
HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\LicenseServer

On 64 bit systems, the registry settings are at:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\
Schneider Electric\ClearSCADA\LicenseServer

  • Port Server—The registry settings are at: HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\PortServer
  • Server—The registry settings are at:
HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\DB

NOTE: For ViewX logging, ODBC Logging, and DB Client Logging, see Using a Registry Editor to Change Client Log File Settings in the ClearSCADA Guide to Client Administration.

  4. Define the registry settings:
  1. Right-click on a setting to display a context sensitive menu. The settings include:
  • LogEnable—Enter True, Yes, T, Y, or 1 to enable logging or enter False, No, F, N, or 0 to disable logging as required.
  • LogFileBase—Define the folder that will contain the log files and the filename prefix for the files. The prefix is the name of the files (it cannot contain certain characters, see your operating system documentation for more details).
  • LogMaxFiles—Enter the maximum amount of log files permitted for each set of log files. When a new log file is created, the oldest log file is deleted (to make way for the new file).
  • LogMaxSize—Enter the largest possible size for a log file. The size is in kilobytes.
  • LogOldFiles—Enter the number of sets of log files that can be stored for each instance of an application.

For many systems, the default setting of 1 is adequate.

  • LogTelnetPort—Enter the port number for the Telnet server (enter 0 if the port is to be assigned dynamically or enter the specific number of the port as required). The LogTelnetPort is only available for those applications that contain a Telnet server (see Telnet Monitoring).
  2. Select the Modify option to display the Edit window.
  3. Enter the required setting in the Value Data field (see step i for the required settings).
  4. Select the OK button to confirm the setting.
  5. Repeat the sub-procedure (i-iv) for each logging setting.


Server Administration Guide - Telnet Monitoring (Logging and Monitoring)

Telnet Monitoring

ATTENTION: On systems running on computers using Windows Vista, you need to enable the Telnet client manually. To do this, access the Windows Control Panel, then select Programs and Features. Next, select ‘Turn Windows Features On and Off’, then select the Telnet client.

Log files are useful for reviewing what has happened in the past, but are not a convenient way of monitoring in real time as you have to keep closing and reopening the log file. Many of the ClearSCADA applications contain a Telnet server that allows you to connect a Telnet client to monitor the application in real time. However, if there is a lot of activity the real time data can scroll past very quickly.

By using Telnet monitoring, you can monitor the application or channel in realtime. This means that you can view the latest information without having to close and re-open the log file.

The following applications contain a Telnet server:

  • Server
  • Drivers
  • Channels (each channel has its own Telnet server)
  • Port Server
  • Alarm and Event Printer
  • License server.

Further Information

Define the TCP/IP Port for Telnet Server

Enable or Disable the Telnet Server

Use a Telnet Client to Monitor an Application or Channel.


Server Administration Guide - Define the TCP/IP Port for Telnet Server (Logging and Monitoring)

Define the TCP/IP Port for Telnet Server

Each Telnet server has it's own unique TCP/IP port that can either be dynamically allocated by the operating system or can be pre-defined:

  • If you want the operating system to allocate the port dynamically, you should specify a port number of zero.
  • If you want to access the Telnet server through a firewall, you may have to specify the port number, so that the required port can be opened on the firewall. You should use 'registered ports' in the range 1024 to 49151 inclusive (for more information, see http://www.iana.org/assignments/port-numbers).

The Telnet port number for each driver is defined on the Configuration tab of the Logging window that is available via the Modules display of the ClearSCADA Server Status Tool (see Driver Logging). It can also be defined via the registry settings (see Using a Registry Editor to Change Server Log File Settings).

For the ClearSCADA Server, the port that is currently assigned to the Telnet server is shown on the Information display of the ClearSCADA Server Status Tool. For drivers, the port number is shown in the Telnet Port column on the Modules display of the ClearSCADA Server Status Tool.

To define the Telnet port for server monitoring:

  1. Run the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Log on (if required).
  3. Expand the required system and server
  4. Expand the System Configuration folder and then selecting the Logging option to display the Logging settings.
  5. In the Server section, enter the required port number in the Telnet Port field.
  6. Apply the changes to the server configuration by right-clicking on the system icon in the explorer section of the ClearSCADA Server Configuration Tool, then selecting the Apply Changes option.

Alternatively, you can set the Telnet Port via the registry settings (see Using a Registry Editor to Change Server Log File Settings).

For other types of monitoring, you need to define the Telnet port via the registry settings (see Using a Registry Editor to Change Server Log File Settings).


Server Administration Guide - Enable or Disable the Telnet Server (Logging and Monitoring)

Enable or Disable the Telnet Server

Each Telnet server is started automatically when the corresponding application starts (if logging is enabled). However, to monitor communications for a channel, you have to specifically enable or disable the Telnet server for that channel.

To enable or disable the Telnet server for a channel:

  1. In ViewX, log on via a User account that has the Diagnostics permission for the required channel and is configured to have the Operate ViewX feature enabled.
  2. In the Database Bar, right-click on the channel for which you want to enable or disable Telnet monitoring.
    A context sensitive menu is displayed.
  3. Select the Enable Telnet option to start the Telnet server for the channel or select the Disable Telnet option to stop the Telnet server for the channel.

If you select the Enable Telnet option, a prompt is displayed:

  1. Either:
  • Select the Persist check box to set the Telnet server to run until it is explicitly stopped. The Telnet server will remain running for the channel even after the relevant driver stops or a changeover occurs.

Or:

  • Clear the Persist check box to temporarily run the Telnet server for the channel—the Telnet server will start running but will stop when the relevant driver stops or a changeover occurs.
  2. Enter the TCP/IP port for the channel's Telnet server (or 0 if the port is to be assigned dynamically) in the Port field (see Define the TCP/IP Port for Telnet Server). Alternatively, you can use the > to display the number selection window which can be used to define the port number).

The View window provides information about the port that is currently being used (see Communications Logging Status on Status Displays).

  3. Select the OK button to confirm your selections and close the prompt.
    The Telnet server starts on the selected channel.

If you have enabled the Telnet server for a channel, you can now monitor the communications for the channel in real time.

Further Information

Enable or Disable Server Logging

Enable or Disable Logging for a Driver

Enable or Disable I/O Logging on a Channel

Enable or Disable 'Normal' Communications Logging on a Channel

Port Server Logging

Alarm and Event Printer Logging

License Server Logging.


Server Administration Guide - Use a Telnet Client to Monitor an Application or Channel (Logging and Monitoring)

Use a Telnet Client to Monitor an Application or Channel

When you have enabled a Telnet server (see Enable or Disable the Telnet Server), you can connect a Telnet client to the server to monitor the application or channel in real time.

To use a Telnet client to monitor the server:

  1. To monitor the local server, right-click on the ClearSCADA server icon in the Windows taskbar.
    A context sensitive menu is displayed.
  2. Select the Monitor option.
    The default Telnet client for the computer is run and is connected to the server.

To use a Telnet client to monitor a driver:

  1. Run the ClearSCADA Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to Server Status).
  2. On the Server Status Tool, first expand the system and server, then expand the General folder and select the Modules option.
    The Modules status is displayed. This shows the drivers and their current status.
  3. Right-click on the required driver, then select the Monitor option.
    The default Telnet client for the computer is run and is connected to the relevant driver

To manually connect a Telnet client to an application or channel:

  1. Access the command prompt by selecting the Start button in the Windows taskbar then selecting the Programs>Accessories>Command Prompt option.
  2. At the command prompt, enter the following:
telnet ( <name> | <IP address> ) <port>

Where <name> is the name of the PC on which the application is running (this is often the Main server), <IP address> is the address of the computer where the application is running (often the Main server), and <port> is the TCP/IP being used by the Telnet server. Do not include the angle brackets < >.

For example:

telnet 10.1.5.13 4132

For Telnet monitoring on a PC that has an IP address of 10.1.5.13 and has the Telnet port set to 4132.

NOTE: You can also use this technique to monitor a server or driver, for example, if you want to monitor a server or driver remotely.

  3. Press the Enter key.
    The default Telnet client for the computer is run and displays the relevant type of log data in realtime.

NOTE: You can also use this technique to access Telnet monitoring for server logging and driver logging if required.

When you have connected to a Telnet server, new information is displayed in the Telnet client in real time. You can use the following commands in the Telnet client:

  • M-Displays the menu of available options (these vary according to the application).

Follow the on-screen instructions to navigate through the menus and options.

When using the logging options, you can enable logging for an option by entering the relevant number. To disable logging for an option, you need to enter the negative of the number, for example, -3. For multiple options, use commas to separate each option in the list.

  • Q-Quits the Telnet client.
  • F-Freezes (pauses) the display in the Telnet client.
  • U-Unfreezes (continues) the display in the Telnet client (when the display is frozen).
  • P-Pauses the display in the Telnet client.
  • C-Continues the display in the Telnet client (when the log is paused).


Server Administration Guide - Server Snapshot Log Files (Logging and Monitoring)

Server Snapshot Log Files

ClearSCADA includes a snapshot feature which takes data from the Server Status Tool at regular intervals and stores the data in log files. The server snapshot log files are useful as they provide a history of the server status which Schneider Electric may be able to use for diagnostic purposes.

There can be a maximum of two server snapshot log files, each with a limit of 2MB. To begin with, your system will write the snapshot data to the files DBSnapshot_001.log and DBSnapshot_002.log. When the DBSnapshot_002.log file becomes full, a new snapshot log file called DBSnapshot_003.log is created for new data. The DBSnapshot_003.log file replaces the DBSnapshot_001.log file (there can only be 2 snapshot log files). Similarly, when the DBSnapshot_003.log file becomes full, a DBSnapshot_004.log file is created and the DBSnapshot_002.log file is deleted. This means that the two server snapshot log files should contain the most recent 4MB of sever snapshot data.

The server snapshot data is retrieved and stored in the snapshot log file(s) every 30 minutes.

To access a server snapshot log file, right-click on the server icon in the Windows taskbar and select the DBSnapshot_<Snapshot File Number>.log option (where <Snapshot File Number> is the number of the snapshot file, for example, 003 or 004). The log file will be displayed in a text editor program such as Microsoft Notepad.

The snapshot file contains data that was shown on the Server Status Tool at the time the snapshot was taken (every 30 mins, starting at the beginning of the hour).


Server Administration Guide - Locating the Log Files (Logging and Monitoring)

Locating the Log Files

Log files are stored in the locations specified in the LogFileBase registry setting for the relevant application. For example, the log files for the Port Server are stored in the location defined in the LogFileBase registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA\PortServer

For each application, you can use a registry editor to access the LogFileBase registry setting and view the current location of the log files.

For server logging, you can also discover the location of the server log files by performing these tasks:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool)
  2. Log on (if required)
  3. Expand the required system and server, then expand the System Configuration branch of the tree-structure.
  4. Select Logging to display the Logging settings.
  5. Examine the File Base entry in the Server section. The defined location is where the server log files are stored.
  6. Use Windows Explorer to locate the log files as required.

For driver logging, you can also discover the location of the driver log files by performing these tasks:

  1. Run the Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).
  2. Expand the required system and server, then expand the General branch of the tree-structure.
  3. Select Modules to display a list of the drivers.
  4. In the list, right-click on the required driver to display a context sensitive menu.
  5. Select the Logging option to display the Logging window.
  6. On the Configuration tab, examine the File Base entry. The defined location is where the driver log files are stored.
  7. Use Windows Explorer to locate the log files as required.

NOTE: Alternatively, you can run the Server Status Tool and select the Log Files option in the General branch. The FileBase column in the Log Files display shows the location of the server's log files.

Further Information

Move all New Log Files to a Different Location.


Server Administration Guide - Move all New Log Files to a Different Location (Logging and Monitoring)

Move all New Log Files to a Different Location

The ClearSCADA Server Configuration Tool contains a Move Log Files wizard which allows you to quickly change the location of new log files on a particular server (includes, server logs, drivers logs etc.). For example, you can use the ClearSCADA Server Configuration Tool to move new log files to a different disk.

When you use the Move Log Files wizard, only new log files will be stored in the location you specify. Any existing files will not be moved. If you want to move the existing files to a new location, you will need to stop the server then use Windows Explorer to relocate the files.

To change the location of new log files so that new log files are stored in a specific location:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Log on (if required)
  3. Expand the required system and server, then expand the System Configuration branch of the tree-structure.
  4. Select Logging to display the Logging settings.
  5. Select the Browse button in the Move Log Files section.
    A browse window is displayed.
  6. Use the browse window to locate the destination folder for the new logging files.
  7. Select the destination folder.
  8. Select the OK button to confirm your choice and close the browse window.
  9. Apply the changes to the server configuration by right-clicking on the system icon in the explorer section of the ClearSCADA Server Configuration Tool, then selecting the Apply Changes option.
  10. Re-Start the ClearSCADA Server to move allow the new log files to be stored in the specified location.


Server Administration Guide - Security Settings

Security Settings

You can use the Security settings to set up the security level and associated settings for your system. For more information, see Setting up System Security in the ClearSCADA Guide to Security.


Server Administration Guide - Partners Settings

Partners Settings

You can use the Partners settings to configure the architecture for your system. For more information, see System Architectures.


Server Administration Guide - Permission Restrictions Settings

Permission Restrictions Settings

You can use the Permission Restrictions settings to define which permissions are available or unavailable on ViewX and WebX clients, just ViewX clients, or just WebX clients. For more information, see Define whether any Permissions are Restricted in the ClearSCADA Guide to Security.


Server Administration Guide - Printer Settings

Printer Settings

In Microsoft® Windows®, users can only access those printers that are associated with their Windows user accounts. The ClearSCADA server runs as a service, so you need to specify a Windows user account in the ClearSCADA server configuration to allow the ClearSCADA server to access your printers.

To define the printer settings:

  1. Use Microsoft Windows to setup a user account that has access to the required printers and the Log on as a Service privilege. You need to log on to each server as this user to setup the printers.

ATTENTION: If the user is a local user, only the local printers will be accessible, even if you add a printer from another PC.

  2. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  3. Expand the System Configuration branch of the tree-structure.
  4. Select Printing to access the Printing section.
  5. In the Username field, enter the user name of the Microsoft Windows user account that is to be used to provide access to the printers.
  6. In the Domain field, enter the name of the domain with which the username is associated. Leave this field blank if the user account is local.
  7. In the Password field, enter the password for the Windows account. This has to correspond with the password that has been configured for the user account in Windows.
  8. Close the ClearSCADA Server Configuration Tool to apply the changes to the ClearSCADA server’s printer settings (or select another branch if further server configuration is required).
    The ClearSCADA Server can now access the printers that are associated with the defined Windows user account.
  9. Re-Start the ClearSCADA Server to allow Windows to apply the printer setting changes.

When you have defined the Printer settings, you can proceed with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about WebX Settings.


Server Administration Guide - Server Command Line Tool

Server Command Line Tool

You can use the built-in ClearSCADA server command line tool to run commands from the Windows command prompt. This can be useful if you need to access the ClearSCADA server commands from other programs or via remote access that limits you to using command lines. For example, you may want to run ClearSCADA server commands within batch files for Third Party software applications.

In this section, we explain how to:

  • Access the Server Command Line Tool
  • Use a Server Command Line Tool Option and Command.


Server Administration Guide - Access the Server Command Line Tool (Server Command Line Tool)

Access the Server Command Line Tool

To access the ClearSCADA Server Command Line Tool:

  1. Run the Microsoft Windows Command Prompt
  2. Run the SCXCMD.exe and display a list of commands by entering the following at the command prompt:
C:\Program Files\Schneider Electric\ClearSCADA\ScxCmd -?

NOTE: This example assumes that ClearSCADA is installed on drive C: in the Program Files directory. If you have installed ClearSCADA in a different location, you will need to define that different location in the command line (instead of C:).

The ClearSCADA Server Command Line Tool runs and displays a list of options and the available commands. There is a brief description of the purpose of each command. For example, the SHOWSTATE command has a description of 'show the current server state'.


Server Administration Guide - Use a Server Command Line Tool Option and Command (Server Command Line Tool)

Use a Server Command Line Tool Option and Command

The ClearSCADA Server Command Line Tool has several options that you may need to use before you can issue a ClearSCADA command (depending on the configuration of your system).

The options available are:

  • -s server [:port]

This allows you to connect to a specific server via a specific port. The 'server' part of the entry is the name of the server PC or the IP address of the server PC.

  • -u user

This allows you to log on to a system via a user account. This is required if access to the server features are restricted by user account permissions. The 'user' part of the entry is the name of the user account.

  • -p password

This allows you to define the password for a user account (when access to server features are restricted by user account permissions). The 'password' part of the entry is the password used to gain access via the user account.

If the name of a value for an option includes a space, you have to enclose the value in double quotes. Remember that if the options need to be used, they have to be defined before you enter the command.

You can display a list of the commands that are available by entering -h at the command prompt and pressing the Enter key. You can also display the list of commands by entering -? and pressing the Enter key. When you display the command list, you will see that the keyword for each command is shown along with a description of the command's function.

The commands are in uppercase and some commands have lower case components. The lower case indicates that you have to define a value for that part of the command. For example, the RESTART driver command requires that you enter the name of the driver to be restarted. So, to restart the Modbus driver, you would enter: RESTART Modbus.

For the SHOWDIAG command, there is a built-in help display that provides a list of the classes of diagnostic information you can display. Simply run the SHOWDIAG HELP command to access the list, then run the SHOWDIAG command followed by keyword for the class of diagnostic information you require, for example SHOWDIAG DAITEM for diagnostic information about OPC DA items.

To run a command in the ClearSCADA Server Command Line Tool:

  1. Access the Server Command Line Tool
  2. Enter any required options (as described earlier in this section).
  3. Enter the required command and any required values, such as the name of a driver.
  4. Press the Enter key.
    The command will run. If the command is successful, the expected result will occur (for example, the system time will be returned or a driver will restart). If ClearSCADA detects that the command has failed, a message is displayed providing information about the cause of the failure. I

Example:

ScxCMD -s ServerA:5481 -u "A Young" -p "ClearSCADA666" GETSYSTIME DB

This command performs the following:

Connects to the system via port 5481 on the server that is named ServerA.

Logs on to the server via the user account named A Young using the password ClearSCADA666

Performs the GETSYSTIME DB command which returns the system time. The system time is displayed in the Windows Command Prompt.


Server Administration Guide - Monitor the Available Disk Space

Monitor the Available Disk Space

We recommend that you configure your ClearSCADA system to monitor the free disk space in each of the servers. This will allow ClearSCADA to generate alarms if there is a low amount of disk space available.

If there is insufficient disk space available to store the database files, the server will enter Error Mode (the server icon will change color to magenta). When in Error mode, the server will continue to attempt to save the database files and historic data, and if disk space has become available, will be able to recover without loss of data. However, there is a risk that if the server unexpectedly shuts down while during Error mode, data could be lost. Similarly, data could be lost if both the disk space and memory become full, as the server may stop running.

For this reason, we strongly recommend that you create and configure performance monitor points to monitor the available disk space on each drive in each server. The alarm limits for the points should be setup to relate to a low amount of available disk space.

You will need to enable the LogicalDisk performance counters before you can proceed to set up a system to monitor the available disk space. To enable the LogicalDisk settings, enter the following at a command prompt:

diskperf -yv

Then restart Microsoft Windows before continuing with this section. If you need more information about accessing the command prompt, please refer to your Microsoft Windows documentation.

To set up a performance monitor point to monitor the amount of free disk space on a selected drive:

  1. Configure your system so that it is set up as described in the introduction to this section.
  2. Run ViewX on the server and Log on.
  3. Right-click on the Group or System that will contain the performance monitor point that monitors the free disk space.
    A context sensitive menu is displayed.
  4. Select the New option, then the Performance Monitor option, then the Scanner option.
    A new performance monitor scanner is added to the database. It is selected automatically, ready for you to define its name.
  5. Enter a suitable name for the performance monitor scanner (such as the name of one of the servers), and press the Enter key or select another part of the interface to confirm the name.
  6. Right-click on the Group or System that you selected in step 3.
    A context sensitive menu is displayed.
  7. Select the New option, then the Performance Monitor option, then the Analog Point option.
    A new performance monitor analog point is added to the database. It is selected automatically, ready for you to define its name.
  8. Enter a suitable name for the performance monitor analog point (such as the 'name' of one of the disks, for example, 'C Drive Free Space'), and press the Enter key or select another past of the interface to confirm the name.
  9. Right-click on the new performance monitor scanner.
    A context sensitive menu is displayed.
  10. Select the Properties option.
    The Performance Monitor Scanner Form is displayed.
  11. Select the In Service check box so that the performance monitor scanner is active.
  12. In the Node field, enter the node name of the server that you want to monitor the available disk space.
  13. Use the Severity combo box to define the importance of alarms relating to the scanner's status. We recommend that you set the Severity to a high level of importance. For more information on the severity levels, see Alarm and Event Severities.
  14. Use the Area of Interest field (if available) to associate the scanner with a specific are of interest. For more information, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.
  15. Use the Scan Rate field to define how often the disk space will be checked. We suggest that you define a scan rate time of 10 or 15 minutes.

You need to define the time in the OPC time format, for example, 10M for ten minutes. For more information, see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.

  16. Use the Always Update on Scan check box to define whether the points that are going to be associated with the scanner are updated each time there is a scan.

If the contents of the disk you are monitoring change frequently, we recommend that you clear the Always Update on Scan check box as the point will be updated automatically.

If the contents of the disk you are monitoring rarely change, we advise that you select the Always Update on Scan check box so that the point is updated on a regular basis.

  17. Select the Save button [image] to store the configuration.
  18. In the Database Bar, right-click on the performance monitor analog point that you added in step 9.
    A context sensitive menu is displayed.
  19. Select the Properties option.
    The Performance Monitor Analog Point Form is displayed.
  20. Select the Analog Point tab.
  21. Define the alarm limits. You should set the Full Scale, High-High, and High limits to 100 (for 100% disk space available), and use the Low and Low Low to define the settings that determine when an alarm is raised. We suggest that the first alarm is set to be raised when 10% disk space is available, and a higher priority alarm when 5% disk space is available.

For example:

  • Full Scale—100
  • High High—100
  • High—100
  • Low—10
  • Low Low—5
  • Zero Scale—0
  22. Use the Descriptions combo boxes to set appropriate descriptions for each alarm condition.
  23. Use the Severity combo boxes to define the importance of each alarm limit. We suggest that you use high importance alarms for the Low and Low Low limits.
  24. Enter % in the Units field (the units are percentages of the total amount of disk space).
  25. Select the Historic tab.
  26. Select the Enabled check box. This activates historic storage so that you can display the disk usage on Trend Graphs.
  27. Select the Performance Monitor tab.
  28. Select the In Service check box to so that the point is active.
  29. Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever a user requests that this point is disabled or enabled. For more information on this setting, see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration.
  30. Use the browse button for the Scanner field to locate and select the Performance Monitor Scanner that you created in step 5.
  31. Select the browse button next to the Tag field.
    A Reference window is displayed.
  32. Expand the LogicalDisk branch of the tree-structure.
  33. Expand the % Free Space branch.
  34. Select the branch that relates to the drive you want the point to represent, for example, C: for the C: drive.
  35. Select the OK button.
    The Reference window is closed.
  36. Leave the Multiplier field set to 1 as scaling is not required.
  37. Use the Update Value on Every Scan check box to specify whether the scanner is to update the value of this point within ClearSCADA every time the point' s source is scanned, regardless of whether the value has changed.

Select the check box if the value of the point is to be updated whenever its source is scanned. For example, you should select the Update Value on Every Scan check box if the point' s value is to trigger Logic program(s) whenever a scan occurs. Another common reason for selecting the Update Value on Every Scan check box is to allow ClearSCADA to use a recently retrieved value for a point that rarely has value changes.

Clear the Update Value on Every Scan check box if the value of the point is only to be updated within ClearSCADA if its value has changed from the last recorded value. The Update Value on Every Scan setting is often disabled when a point is associated with a value that often changes (as the frequent changes mean the point’s value is updated regularly, without the need for an update on every scan).

  38. Select the Save button [image] to store the configuration.
  39. Repeat the steps that relate to performance monitor point configuration for each drive that is to be scanned.
    The point(s) values represent the percentage of available disk space on the relevant drives.
  40. Repeat the entire procedure for each server.


Server Administration Guide - Create a Blank Database

Create a Blank Database

When you have installed ClearSCADA and configured the settings for the server(s), you need to create a blank database.

To create a blank database:

  1. Right-click on the ClearSCADA Server icon.
    A context sensitive menu is displayed.
  2. Select the Start Database option.
    A dialog box is displayed.
  3. Select the Start Database button to create a blank database.

ATTENTION: If this is not the first time that you have installed ClearSCADA on the server, selecting Start Database will delete any previous database.

When you have created a blank database, you can proceed to set up the client connections. For more information, see Welcome to the Client Administration Guide in the ClearSCADA Guide to Client Administration.


Server Administration Guide - File Upload Settings

File Upload Settings

You can use the ClearSCADA Server Configuration Tool to associate the file uploads feature with a Microsoft Windows user account. The network sharing settings for the Windows user account determine which areas of a network can be accessed for uploading files such as reports.

You can associate the file uploads feature with any Microsoft Windows user account that has the 'Log on as a Service' security privilege. However, the user account that you select has to have access to the files that are to be uploaded (by any driver on the server).

For more information on the Windows user account settings, please refer to your Microsoft Windows documentation.

To associate the file uploads feature with a Windows user account:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch.
  3. Select the File Upload branch.
  1. In the Username field, enter the user name for the Microsoft Windows user account that will be used to provide network access for uploading files.
  2. In the Password field, enter the password for the Microsoft Windows user account.
  3. In the Domain field, enter the name of the domain with which the Windows user name is associated. Leave this field blank if the user account is local.
  4. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes on the ClearSCADA server.
  5. Re-Start the ClearSCADA Server.
    The ClearSCADA Server can now access the files that are associated with the defined Windows user account.

When you have defined the File Uploads settings, you can proceed with the server configuration. If you are unfamiliar with the server configuration process, we recommend that you proceed to learn about the Locations of the Database Folders.


Server Administration Guide - Alarm and Event Printer Service

Alarm and Event Printer Service

The alarm and event printer service allows alarms and events to be printed out on a printer that is connected to a server or client PC via a serial port. Printing out alarm and event data was a common practice in the past when advanced filtering, sorting and printing capabilities like those available in ClearSCADA were not available. As ClearSCADA includes a wide range of advanced filtering, sorting, printing, and historic storage features, there is less need for printing out alarm and event data in the modern work place. However, we do support alarm and event printers for those users who still prefer to have a hard copy of the data.

If you want alarms and events to be printed out via a serial port connected printer, you need to configure the server or client PC to use the alarm and event printer service.

NOTE: The alarm and event printer service runs as a separate service and requires a server-side OPC license.

To configure a server or client to make use of the alarm and event printer service, you need to include it in the ClearSCADA installation and configure it by using the registry keys:

  1. Connect the printer to the server or client via a serial port.
  2. Include the Alarm and Event Printer service in the installation. To do this, you need to select the Alarm and Event Printer option during the installation process and set it to be installed on the local hard drive. If you have already installed ClearSCADA, you can customize the installation so that it includes the Alarm and Event Printer option (access the Windows Control Panel, select the Add or Remove Programs option, then select the Schneider Electric ClearSCADA option followed by the Change button. This will display the installation Wizard. Follow the steps of the Wizard, and when you come to the Custom Setup 'page', choose to install the Alarm and Events feature).
  3. In Windows, select the Start button, then the Run option, then enter regedit at the prompt and select the OK button to display the registry editor.
  4. Browse to the following registry:
HKEY_LOCAL_MACHINE\Software\Schneider Electric\ClearSCADA\AEPrinter

  5. Add a new key to the registry by right-clicking on the registry, selecting New from the context sensitive menu, then selecting the Key option.
  6. Enter a name for the new key. The name of the new key should be the name of the COM port to which the AE printer will be connected. You can also use the name of the registry key to specify:
  • Baud Rate—The speed of data transfer via the port, for example, 9600.
  • Number of Data Bits—The number of data bits used to transmit each byte of data. This is a number between 4 and 8 (inclusive), for example, 8.
  • Parity—The setting for the parity bit that can be used as a method of error checking. The parity can be:
  • N—For no parity
  • E—Even parity.
  • O—Odd parity.
  • M—Mark parity.
  • S—Space parity.
  • Number of Stop Bits—Defines the number of bits that are placed after each character in the transmitted data. This is either 1, 1.5, or 2.
  • Flow Control—Defines when and how data is transmitted. The flow control can be:
  • NONE—Flow control is not applied to the data.
  • XON XOFF—The operating system controls the flow of data by sending XON and XOFF signals to indicate whether the communications equipment can receive data.
  • HARDWARE—The communications equipment uses Request to Send (RTS) and Clear to Send (CTS) signals to control the flow of data (and the operating system is responsible for preventing data overruns).
  • TOGGLE—Microsoft Windows controls the flow of data by sending a Request to Send (RTS) signal to the receiver when the transmission buffer contains data.

For example:

COM12,9600,8,N,1,NONE

This would set the AE printer connection to use a COM port named COM12 using a baud rate of 9600, 8 databits, no parity, 1 stop bit and no flow control.

  7. Having created the key, you can add values to it by selecting the key in the tree-structure, then right-clicking in the display area on the right to display a context sensitive menu. Select the New option followed by the relevant value option from the menu to create a new value. You can then define an entry for the value.

You can use the values to define settings for the AE Printer. The names of the values have to match those shown in the table below. The values also have to be of the correct type and have a valid value.

Value Name

Value Type

Value Entry

System

STRING (REG_SZ)

The name of the system for the connection. This is the system that provides the alarms and events that will be printed out on the alarm and event printer.

TerminalWidth

DWORD (REG_DWORD)

The width of the terminal display or printer line, in characters. This is used to calculate appropriate word wrapping for lines that are shown on a terminal display or are printed out on the alarm and event printer.

The default is 0 (no terminal width is used).

Enabled

DWORD (REG_DWORD)

Use to enable or disable the connection between the Alarm and Event printer and the system. Enter 0 to disable the connection or 1 to enable the connection.

InitialRefresh

DWORD (REG_DWORD)

Use to define whether outstanding active Unacknowledged Uncleared alarms are printed out when the alarm and event printer first connects to the system.

Enable this feature by setting the value to 1. This means that any active alarms will be printed when the alarm and event printer connects to the system. On the printout, the following lines are printed before and after the outstanding active alarms respectively:

"*** Start of current system alarms"

"***End of current system alarms"

Any alarms and events that are raised after the time at which the alarm and event printer connected to the system will be printed out in sequence after the end of current system alarms message.

If you only want new system alarms to be printed out, set the value to 0. This means that any alarms that were already active when the alarm and event printer connected to the system will not be printed out.

FormatString

STRING (REG_SZ)

Use the FormatString to define the format of the output that is printed. You can use the following format characters in the string:

%* - Use to print a specified character if the output is an alarm. For example, %*# would set the system to print out "#" at the start of the output if the output is an alarm. If the output is not an alarm, the system prints out a space, so an event output is marked as " ".

%A - Use to print "Alarm" if the output is an alarm or "Event" if the output is an event. For example, %A would set the system to print out "Alarm" at the start of the output if the output is an alarm. If the output is an event, the system prints out "Event" at the start of the output.

%a - Use to print "A" if the output is an alarm or "E" if the output is an event. For example, %a would set the system to print out "A" at the start of the output if the output is an alarm. If the output is an event, the system prints out "E" at the start of the output.

%E0 or %E1 - Use to print out the alarm severity description for an alarm or event output and define any extra spacing. For example, if you enter %E1, the printer will print out the severity description for the alarms and events and will include padding so that the severity descriptions are evenly spaced. If you enter %E0, the system will print out the severity descriptions but will not include padding so the severity descriptions in the print out will not be evenly spaced.

%e0 or %e1 - This works in the same way as %E0 or %E1 except that it sets the system to print out a severity number instead of a severity description. As with the %E0 and %E0 values, the 0 and 1 define whether padding is applied to the numbers to provide even spacing (0 means no padding is applied, 1 means padding is applied).

%D - Use to print the date of the alarm or event in the form: DD-MMM-YYYY, where the month is in the form JAN, FEB, MAR, APR, etc.

%T- - Use to print the time of the alarm or event in the form: HH:MM:SS.

%S - Use to print the name of the database item to which the alarm relates (the name of the source).

%M - Use to print the message for the alarm or event.

%I - Use to print the unique cookie for the alarm or event.

%C0 or %C1 - Works in the same way as %E0 and %E1 except that it prints out the category description of the alarm event (with or without padding).

%> - Use to define a left-justification margin. If a terminal width is specified in the registry, the message is word wrapped and a new line is started at this margin.

%% - Print the % character

The default value for the FormatString key is:

"%**%**%A %E1 %D %T- %>%S,%M (%CO)"

The - and ( ) are included as extra formatting. You can add any string of characters to the FormatString key in addition to the format characters as required.

WrapOnChars

STRING (REG_SZ)

Use to specify which characters designate a valid position for a word wrap break at the end of a line. The default value is a space - " ".

EOLString

STRING (REG_SZ)

Use to specify the combination of carriage return and line feed that is required on the end of lines sent to the printer. C represents carriage return and L represents line feed. The default is "CL" which means a carriage return followed by a line feed.

UserName

STRING (REG_SZ)

The Username that is to be used by the connection in order to log on to ClearSCADA. The connection to ClearSCADA will only succeed if you enter a valid Username (the Guest user does not have access). Without a valid Username, the connection will fail.

Password

STRING (REG_SZ)

The Password that is to be used in conjunction with the Username in order to log on to ClearSCADA.

  8. When you have defined the values for the registry, you need to restart the ClearSCADA service for your changes to take effect:
  9. Run the ClearSCADA Service Manager.
  10. Select the AE Printer option.
  11. Select the Stop button and wait for the service to stop.
  12. Select the Start button to restart the AE Printer service.
    The changes you made to the AE Printer registry settings will take effect and your alarm and event printer service should be fully operational.


Server Administration Guide - Archiving

Archiving

The archiving feature allows you to store historic data and event messages on a variety of devices, including:

  • Removable hard disks
  • Removable flash technology, e.g. Compact Flash
  • CD-R and CD-RW devices
  • DVD devices such as DVD-R, DVD-RAM etc.

Archives are used to:

  • Provide long-term offline storage of historic data and event messages.
  • Allow multiple backup copies of data to be stored externally. For example, CD-Rs and DVDs can be stored in a fire safe. (This is limited to one archive per server, although the data on a server can be archived in groups).

You can access the historic data and events from the archives via Lists and Graphs.

NOTE: Restored historic data is only available on the server on which is it restored. In a Main-Standby setup, the restored data is only available on the Main or the Standby, depending on where the data was restored—the data is not restored across the link between servers.

Archives only store the data that was retrieved from the outstations, PLCs etc. Any data that has been manually modified is stored on-line and is not archived. However, when you access an archive, any modified data is used as normal.

For more information on modifying historic values, please refer to the ClearSCADA Guide to Trends.

This section explains how to:

  • Define the Archiving Settings
  • Define the Availability of the Mount Action
  • Define the Journal Batch Size Settings
  • Define the Configuration Changes Batch Size Settings.
  • Set Historic Data to be Archived
  • Set Event Journal Data to be Archived
  • Create and Configure Archive Items.
  • Archive Data Manually.
  • Setup Scheduled Archiving.
  • Make the Archived Data Available for Use.
  • Manage Your Archive Volumes
  • View an Archive Volume (see Manage Your Archive Volumes)
  • Export information about Archive Volumes (see Manage Your Archive Volumes)
  • Create Replacement Archive Volumes (see Manage Your Archive Volumes)
  • Create Duplicate Archive Volumes (see Manage Your Archive Volumes)
  • Delete Archive Volumes (see Manage Your Archive Volumes)
  • Use the Archives List.
  • Use the Archive Status Display.


Server Administration Guide - Define the Archiving Settings (Archiving)

Define the Archiving Settings

You need to use the archive settings to define the availability of the Mount action and also the size of the Journal batch and Configuration Changes batch.

NOTE: You can only use the archive settings if one or more of the following Historic Configuration changes are enabled: Historic Data, Event Journal, or Configuration Changes.

To define the archive settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch of the tree-structure.
  3. Select Archiving to display the Archiving section.
  4. Use the Allow New Volume to be Mounted without Dismounting Current Volume check box to Define the Availability of the Mount Action.
  5. Use the Journal Batch Size field to Define the Journal Batch Size Settings
  6. Use the Config.Changes Batch Size field to Define the Configuration Changes Batch Size Settings.
  7. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

When you have defined the archiving settings, you can proceed to:

  • Set Historic Data to be Archived
  • Set Event Journal Data to be Archived
  • Create and Configure Archive Items
  • Archive Data Manually
  • Setup Scheduled Archiving
  • Make the Archived Data Available for Use
  • Manage Your Archive Volumes
  • Use the Archives List
  • Use the Archive Status Display.


Server Administration Guide - Define the Availability of the Mount Action (Archiving)

Define the Availability of the Mount Action

Data that is eligible for archiving can be archived to an archive volume such as a CD, DVD or another hard drive. Before archiving to a volume can take place, the volume has to be mounted—ClearSCADA needs to be instructed that the volume is ready to be written to. To mount a volume, a user has to select the Mount action (see Archive Data Manually).

The Mount action is available for archive volumes by default. However, you can choose to limit the availability of the Mount action so that it is only available when a volume is not already mounted.

To define the availability of the Mount action:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Global Parameters branch of the tree-structure.
  3. Select Historic to display the Historic settings.
  4. In the Archiving section, use the Allow new volume to be mounted without dismounting the current volume check box to determine when the Mount action is available:
  • Select the check box to if you want the Mount action to be available for every archive volume, including those that have not been mounted.
  • Clear the check box to if you want the Mount action to only be available for volumes that are already mounted.
  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define the Journal Batch Size Settings (Archiving)

Define the Journal Batch Size Settings

You can use the Archiving section in the server's Historic Data settings to define the amount of records that can be archived in a single batch. Data is archived in batches of records and while the archive process is underway, the data cannot be accessed by other system activities as it is locked. For example, if the journal batch size is 200 and there are 10000 records, the archive process will lock the data, archive 200 records then unlock the data so that it can be access by other system activities. Then the next 200 records will be locked, archived and released and so on until the archive process is complete.

To define the journal batch size settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch.
  3. Select Archiving to display the Archiving settings.
  4. Set the required Journal Batch Size. Enter the number of records per batch (the default setting of 200 is usually appropriate).

If you increase the number of records, the archiving process will complete more quickly but any other system activities that require access to the data (such as SQL queries, driver updates etc.) will take longer to complete as the archiving process locks the data.

If you decrease the number of records, the archiving process will take a longer time to complete but will have less effect on other system activities that require access to the data.

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Server Administration Guide - Define the Configuration Changes Batch Size Settings (Archiving)

Define the Configuration Changes Batch Size Settings

You can use the Archiving section in the server's Historic Configuration settings to define the amount of configuration change records that can be archived in a single batch. Data is archived in batched of records and while the archive process is underway, the data cannot be accessed by other system activities as it is locked. For example, if the configuration changes batch size is 200 and there are 10000 records, the archive process will lock the data, archive 200 records then unlock the data so that it can be access by other system activities. Then the next 200 records will be locked, archived and released and so on until the archive process is complete.

To define the configuration changes batch size settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch.
  3. Select Archiving to display the Archiving settings.
  4. Set the required Config.Changes Batch Size. Enter the number of configuration change records per batch (the default setting of 200 is usually appropriate).

If you increase the number of records, the archiving process will complete more quickly but any other system activities that require access to the data (such as SQL queries, driver updates etc.) will take longer to complete as the archiving process locks the data.

If you decrease the number of records, the archiving process will take a longer time to complete but will have less effect on other system activities that require access to the data.

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Further Information

Settings for Configuration Changes Auditing.


Server Administration Guide - Set Historic Data to be Archived (Archiving)

Set Historic Data to be Archived

Historic data is stored on disk for the defined Historic Lifetime (see Define the Historic Life for Historic Data). During this time, the historic data can be altered (by having new values reported for the time period, values modified manually etc.) unless it is marked as eligible for archiving.

When historic data is marked as eligible for archiving, it can no longer be altered on the disk—the historic data cannot be written to; it can only be read. When historic data is marked as eligible for archiving, it can be archived to CD, DVD etc. (it has to be archived to CD, DVD etc. before the Historic Life expires). Data cannot be archived unless it has been marked as eligible for archiving i.e. is older than the defined ‘Archive After’ time.

To define when the historic data is made eligible for archiving:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch of the tree-structure.
  3. Select Historic Data to display the Historic Data settings.
  4. In the Historic Data section:
  1. If the Enabled check box is clear, select it to activate the Historic Data feature (if it is already selected, proceed to step ii).
  2. Use the Archive after n weeks check box to define whether historic data is eligible for archiving.
  • Select the check box to allow the historic data to be archived. The Archive after n weeks field becomes available. Proceed to step iii.

When historic data becomes eligible for archiving, it remains on the disk for the remainder of the historic life but it is no longer writeable (it cannot change for the remainder of the historic life).

The historic data can be written to a CD, DVD etc., but only after the Archive after n weeks time has passed (this applies to both manual and automatic archiving).

The archiving process can be triggered manually (see Archive Data Manually), or can be set to a schedule (see Setup Scheduled Archiving).

  • Clear the check box if you do not want the historic data to be archived. The Archive after n weeks field is unavailable. Proceed to step 5.
  3. In the Archive after n weeks field, enter the number of weeks that have to pass before the historic data is available for archiving. The time you define applies to both manual and automatic archiving - data can only be archived when it is older than the defined Archive after n weeks time.

The Archive after n weeks has to be less than the Keep on-line number of weeks.

We recommend that you carefully consider the requirements of your system before you define the Archive after n weeks period.

You should use a long period for:

  • Systems that have outstations, PLCs etc. that are out of communications for extended periods
  • Systems that have historic data from other sources, such as file upload or hand controlled data.

The long periods reduce the chance of data being lost. However, longer periods also mean that the data is not available for archiving as quickly as with shorter periods.

Use short periods on:

  • Systems that have outstations, PLCs etc. that are not expected be out of communications.

For example, a short period could be 1-2 weeks.

Short periods are useful for making data available for archiving more quickly (this reduces the chance of losing data as archiving can occur sooner). However, short periods mean that the writeable period is reduced and so any outstations, PLCs etc. that have been out of communications may only be able to report their data—if the data has a timestamp that is outside the writeable time period, the data that is being reported by the outstation, PLC etc. will not be stored.

For more information, see the example at the end of this section.

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Example:

The Keep On-Line for n Weeks period is set to 2 weeks.

The current time is Week 8: Wednesday 13:40:00, so only the data that was reported after midnight on Monday of Week 6 is included in the Keep on-line number of weeks period. The data from before midnight on Monday of Week 6 will have been deleted.

The Archive after n Weeks Period is set to 1 week.

The data that was reported between midnight on Monday of Week 6 and midnight on Monday of Week 7 is available for archiving.

The data reported between the start of week 7 and the current time are unavailable for archiving as this data is still writeable.


Server Administration Guide - Set Event Journal Data to be Archived (Archiving)

Set Event Journal Data to be Archived

Event Journal data is stored on disk for the defined Event Journal Lifetime (see Define the Event Journal Life for Event Messages). Event Journal data is stored on disk for the defined amount of time and is then deleted. During the Event Journal life, the Event Journal data can be altered (by having new values reported for the time period) unless it is marked as eligible for archiving.

When Event Journal data is marked as eligible for archiving, it can no longer be altered on the disk—the Event Journal data cannot be written to; it can only be read. When Event Journal data is marked as eligible for archiving, it can be archived to CD, DVD etc. (it has to be archived to CD, DVD etc. before the Event Journal Life expires).

To define when the Event Journal data is made eligible for archiving:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch of the tree-structure.
  3. Select Event Journal to display the Event Journal settings.
  4. In the Event Journal section:
  1. If the Enabled check box is clear, select it to activate the Event Journal feature (if it is already selected, proceed to step ii).
  2. Use the Archive after n weeks check box to define whether Event Journal data is eligible for archiving.
  • Select the check box to allow the Event Journal data to be archived.The Archive after n weeks field becomes available. Proceed to step iii.

When Event Journal data becomes eligible for archiving, it remains on the disk for the remainder of the Event Journal life but it is no longer writeable (it cannot change for the remainder of the Event Journal life).

The Event Journal data can be written to a CD, DVD etc., but only after the Archive after n weeks time has passed (this applies to both manual and automatic archiving).

The archiving process can be triggered manually (see Archive Data Manually), or can be set to a schedule (see Setup Scheduled Archiving).

  • Clear the check box if you do not want the Event Journal data to be archived. The Archive after n weeks field is unavailable. Proceed to step 5.
  3. In the Archive after n weeks field, enter the number of weeks that have to pass before the Event Journal data is available for archiving. The time you define applies to both manual and automatic archiving - data can only be archived when it is older than the defined Archive after n weeks time.

The Archive after n weeks has to be less than the Keep on-line number of weeks.

As with the Archive after n weeks setting for historic data, you need to consider the requirements of your system before you define the Archive after n weeks period for event messages. The same reasons for using short periods and long periods apply (see Set Historic Data to be Archived).

  5. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Further Information

Event Journal Storage Settings.


Server Administration Guide - Set Configuration Changes Auditing Data to be Archived (Archiving)

Set Configuration Changes Auditing Data to be Archived

Configuration changes data is stored on disk for a defined amount of time (see Settings for Configuration Changes Auditing). When the defined time expires, the configuration changes data is deleted from the disk. If you have not archived the configuration changes data, the data will be lost.

By archiving the configuration changes data, you can keep a permanent record of your configuration changes - the configuration changes are archived to other storage media such as CD, DVD, portable HDD before they are deleted.

Before you can manually trigger the archiving or configure a schedule for automatic archiving of the configuration changes, you need to configure the server so that configuration changes are eligible for archiving:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the Historic Configuration branch of the tree-structure.
  3. Select Configuration Changes to display the Configuration Changes Auditing settings.
  4. In the Configuration Changes Auditing section:
  1. If the Enabled check box is clear, select it to activate the Configuration Changes Auditing feature (if it is already selected, proceed to step ii).
  2. Use the Archive after n weeks check box to define whether configuration changes data is eligible for archiving.
  • Select the check box to allow the configuration changes data to be archived. The Archive after n weeks field becomes available. Proceed to step iii.

When configuration changes data becomes eligible for archiving, it remains on the disk for the remainder of the configuration changes life but it is no longer writeable (it cannot change for the remainder of the configuration changes life).

When the configuration changes data is eligible for archiving, it can be written to a CD, DVD etc. The archiving process can be triggered manually (see Archive Data Manually), or can be set to a schedule (see Setup Scheduled Archiving).

  • Clear the check box if you do not want the configuration changes data to be archived. The Archive after n weeks field is unavailable. Proceed to step 5.
  3. In the Archive after n weeks field, enter the number of weeks that have to pass before the configuration changes data is available for archiving. This has to be less than the Keep on-line number of weeks.

As with the Archive after n weeks setting for historic data, you need to consider the requirements of your system before you define the Archive after n weeks period for configuration changes. The same reasons for using short periods and long periods apply (see Set Historic Data to be Archived).

  4. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.

Further Information

Settings for Configuration Changes Auditing.


Server Administration Guide - Create and Configure Archive Items (Archiving)

Create and Configure Archive Items

You need to create and configure an archive database item for each archive that you want to create. The configuration of the archive item defines the:

  • Location of the data that is archived.
  • Importance of alarms and events that relate to the archive.
  • Details of the device used to write the data to the archive media.
  • Details of the archive media.

We recommend that you configure at least 1 archive for each server (especially with main-standby systems).

If you configure 1 archive per server, we recommend that you set the archive to store the root (system) Group of the server—this archives the data on the server.

If you configure multiple archives per server, we recommend that you create archives for each Group of items. If there are not archives for each Group of items, some data and/or events will not be archived.

To create and configure an archive that will allow the historic data and event messages to be archived:

  1. Run ViewX on a client PC (or on the server if the server is setup to be a client-server) and log on.
  2. Expand the system in the Database Bar.
  3. Right click on the Group that is to contain the archive.
    A context sensitive menu is displayed.
  4. Select the New option, then the Other option, then the Archive option.
    A new archive item is added to the tree-structure for the system. It is selected automatically, ready for you to define its name.
  5. Enter the name of the archive and press the Enter key to confirm.
  6. Right click on the archive.
    A context sensitive menu is displayed.
  7. Select the Properties option.
    The Archive Form is displayed.
  8. Use the In Service check box on the Archive tab to determine whether the archive is active.
  • Select the check box to activate the archive.
  • Clear the check box to de-activate the archive.
  9. Use the Severity combo box to choose the level of importance of any alarms or events that are raised or generated for the archive.

The available severities are defined on the Severities tab of the ClearSCADA Server Configuration Tool (see Alarm and Event Severities).

  10. If the Areas of Interest feature is enabled, use the Area of Interest browse button to select the area with which the archive is to be associated. For more information, see Enable or Disable the Area of Interest Feature.
  11. Use the Group field to determine what data is stored. You can choose to store the data for items in a specific Group, or you can choose to store the entire system by selecting the root Group.
  1. Use the browse button to access the browse reference window.
  2. Select the Group or System Group ($Root) that contains the data that you want to be archived.
  3. Select the OK button.
  12. For the Node combo box, either:
  • Select the server that is connected to (or contains) the device that will be used to write the historic data to the archive media. For example, if the data is to be archived to a CD-R that is in the CD-RW drive of a server named VTG, select VTG from the Node combo box.
  • Select the server that contains the data that is to be archived. This applies to multiple server systems (hot standby etc.), where you can archive the data stored on any of the servers.
  13. In the Path field, enter the drive and folder that is used to store the historic data on the archive media. For example, D:\Archive\.
  14. With the Volume Label field, you have a choice. You can either:
  • Enter the label of the archive media in the Volume Label field. Each volume has to have a unique label, which is used by ClearSCADA to confirm that it is writing to the correct CD-RW, DVD etc.

When you specify a Volume Label, the historic data will not be written to any other archive media, for example, it will not be written to an old disk that has been left in the drive accidentally.

If you enter a Volume Label, ClearSCADA will only write to a volume that has the exact same label. For example, let’s say you wanted ClearSCADA to write to a DVD on drive D:\, and the DVD is to be labelled SVRA WK12/02. After inserting the DVD into drive D:\, you would use Windows to name the DVD SVRA WK12/02 (you would define the name when the DVD is formatted). Then, in ClearSCADA, you would define the Path of the Archive item as D:\ and the Volume Label as SVRA WK12/02. ClearSCADA will then only write the archive to the DVD named SVRA WK12/02 (in drive D:\). If any other disk is inserted in drive D:\, ClearSCADA will deem the archive as failed.

Whenever you start using a new volume, for example when the previous volume is full, you have to re-configure the archive so that is has the label of the new volume.

Or:

  • Leave the Volume Label field blank. This means that ClearSCADA will write the data to the relevant drive, irrespective of what the drive may contain. For example, if the Path is D:\, ClearSCADA will write the data to drive D:\ without checking the content of drive D:\. This means that if a disk has been left in a drive by mistake, ClearSCADA will write the data to the wrong disk.

We advise that you adhere to a consistent volume labelling scheme as ClearSCADA stores the volume label. It is easier for operators to locate the necessary archives if they are suitably named and stored.

We recommend that you use volume labels that consists of the server name followed by a numerical indication of the archive number. For example, SVRA WK12/02 for an archive that is the backup of the SVRA server for week 12, 2002.

NOTE: You can use your operating system to label a volume.

  15. Select the Save button [image] to store the archive configuration.
    The archive is configured to store the historic data of the Group or System that you defined in the Archive's configuration. The archive will take place according to a schedule or when the Archive action is used.

NOTE: For archiving to a volume to take place, the volume has to be in the defined path and has to be accessible (ClearSCADA has to be able to write to the volume). When the volume is in place, ClearSCADA will mount the volume automatically (if required), prior to writing the data.

Further Information

Define the Archiving Settings.

Archive Data Manually.

Setup Scheduled Archiving.

Manage Your Archive Volumes.


Server Administration Guide - Archive Data Manually (Archiving)

Archive Data Manually

You can use the Archive action to instigate an archive. This allows you to archive data at any time, rather than only according to a defined schedule.

NOTE: You need to have created and configured an archive database item before you can archive data (see Create and Configure Archive Items).

To archive data manually:

  1. Check that the archive volume that is to store the archive data can be accessed by ClearSCADA (ClearSCADA needs to be able to write to the volume). If the archive volume has not already been mounted, ClearSCADA will mount the volume automatically, ready for the data writing process.
  2. Access the context sensitive menu for the archive by:
  • Right-clicking on the archive in the Database Bar.
  • Selecting part of a Mimic that has been configured to provide access to the archive's actions.
  • Selecting the archive on a List.

NOTE: To initiate the archiving process from a WebX client, you will need to configure a Mimic to provide access to the Archive action.

  3. Select the Archive option.
    The archive procedure begins. ClearSCADA writes the archive data to the archive volume in accordance with the Archive's configuration and the Historic global parameters set using the ClearSCADA Server Configuration Tool.

You can use the Archives List and Archives Status Display to view the status of the archive operation.

Further Information

Archives List.

Archive Status Display.


Server Administration Guide - Setup Scheduled Archiving (Archiving)

Setup Scheduled Archiving

You can associate each archive with a schedule so that data is archived automatically on a regular basis. This helps to ensure that the data on your system is archived regularly.

You can also use the same schedule with multiple archives, for example, you can use the same schedule for archiving the data of each of your servers.

To archive data according to a schedule:

  1. Create and configure an archive item (see Create and Configure Archive Items).
  2. Make sure that the archive volume is in place and can be accessed by ClearSCADA. To archive data, ClearSCADA will need to be able to write to the volume. If the volume has not already been mounted, ClearSCADA will mount the volume automatically prior to writing the archive data.
  3. In the Database Bar, right-click on the system or Group that is to contain the schedule.
    A context sensitive menu is displayed.
  4. Select the New option, then the Other option, then the Schedule option.
    A new schedule is added to the database. It is selected automatically, ready for you to enter its name.
  5. Enter the name of the schedule.
  6. Press the Enter key or select another part of the interface to confirm the name entry.
  7. Right-click on the schedule to display a context sensitive menu.
  8. Select the Properties option to display the Schedule Form.
  9. Select the Schedule tab.
  10. Select the In Service check box to enable the schedule.
  11. Choose the type of schedule from the Type combo box. Select from:
  • Daily
  • Weekly
  • Monthly
  • Yearly
  12. Configure the other schedule features as required (see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration), then select the Save button.
  13. In the Database Bar, right-click on the Schedule to display a context sensitive menu.
  14. Select the Edit option to display the Schedule Editor window.
  15. Drag the required archive item from the Database Bar into the list area of the Schedule Editor.
    The Add Action window is displayed.
  16. Use the Method combo box to select the Archive option, then select the OK button to confirm your selection and close the Add Action window.
    The archive is added to the list of actions.
  17. Double-click on the time-line at the position that represents the time at which the archive operation will begin.
    A diamond marker is displayed—it indicates the time at which the actions in the list of actions will occur.
  18. Repeat steps 16 and 17 for each archive that is to occur at the times on the time-line. You can add multiple times so that archiving occurs several times in each period.

NOTE: You can drag a diamond marker to a different time, or you can double-click on it to remove it.

  19. Select the Save button [image] to store the configuration.
    The archive(s) will occur at the times defined in the schedule.

Further Information

Archive Data Manually.


Server Administration Guide - Make the Archived Data Available for Use (Archiving)

Make the Archived Data Available for Use

You can make archived data available so that it can be viewed on Historic Trends and Historic Lists. This allows you to use the historic data that is no longer on-line. Making archived data available is referred to as mounting an archive.

System administrators can:

  • Provide access to an archive on behalf of another user (i.e. mount an archive for a low-level user so that user can access the archived data on a client).
  • Make an archive available for their own use.

Other users may also be able to make archived data available, depending on the privileges allocated to their user account.

To make archived data available:

  1. Check that the correct volume is available at the location (defined in the configuration of the archive database item).

NOTE: If you are making archived data available on a hot-standby server, you will need to know which server you are currently using. If you make the archived data available on the wrong server, the data will be unavailable to the clients that need to have access to it.

  2. Use ViewX or the WebX interface to access the archive item that represents the archive volume (the volume that contains the data you want to make available).

NOTE: You can access the archive item, or any other item provides access to the archive's ClearSCADA Object menu (pick action menu).

  3. Select or right-click on the archive item.
    A context sensitive menu is displayed.
  4. Select the Mount Volume option.
    ClearSCADA determines what data is on the archive volume and makes it available for on-line use.

NOTE: You can view the progress of an archive operation by displaying the Archives List or Archive status display and examining the StateDesc entry. For more information see Archives List and see Archive Status Display.

You can now view the historic data on Trends and Lists.

When you have finished using the historic data, proceed to step 5.

  5. Select or right-click on the archive item that contains the data that you made available in step 4.
    A context sensitive menu is displayed.
  6. Select the Dismount Volume option.
    The archived data is no longer available for use on Lists and Graphs and the archive volume can be removed.


Server Administration Guide - Manage Your Archive Volumes (Archiving)

Manage Your Archive Volumes

ClearSCADA includes an Archive Volumes Manager that you can use to:

  • View a list of the archive volumes used by this server
  • View a list of the contents of an individual archive volume
  • Export a list of the archive volumes used by the server to a comma separated value file on disk
  • Export a list of the contents of an individual archive volume
  • Create replacement archive volumes
  • Create duplicate archive volumes
  • Delete archive volumes

The Archive Volumes Manager provides information about the archive volumes used by the local server i.e. the server on which you access the Archive Volumes Manager. For other servers, you will need to use the Archive Volumes Manager on those servers.

To display the Archive Volumes Manager and make use of its features:

  1. On the server, right-click on the Server icon in the Windows Taskbar to display a context sensitive menu.
  2. Select the Archive Volumes option to display the Archive Volumes Manager.

The Archive Volumes Manager shows a list of the archive volumes used by the server on which you are working. For each archive volume, it shows the volume's label and the time period for which the volume was used. The time period is the time of the first archive to use the volume and the time of the last archive to use the volume. The times are useful for identifying which volume contains the data in which you are interested.

The Archive Volumes Manager has an Export button which you can use to export the information currently on display to a comma separated value format file (see Exporting Information from the Archive Volumes Manager).

When you first display the Archive Volumes Manager, it shows information about the archive volumes that had been used at the time you displayed the Archive Volumes Manager. If another archive is in progress while the Archive Volumes Manager is on display, you may need to select the Refresh button to update the Archive Volumes Manager with the latest information.

  3. Right-click on the archive volume in which you are interested to display a context sensitive menu.
  4. Select the option for the task that you wish to perform:
  • View Volume—Displays a list of the content of the archive volume. For more information, see Viewing an Archive Volume.
  • Export Volume—Allows you to export information about the data on the selected volume to a comma separated value format file. The comma separated value file can then be loaded into another application such as a spreadsheet where the data can be searched, printed etc. For more information, see Exporting Information from the Archive Volumes Manager.
  • Create Replacement Volume—Use to create a replacement volume (see Creating a Replacement Archive Volume)
  • Create Duplicate Volume—The Create Duplicate Volume allows you to create another copy of a volume. This is useful when you want to create backup copies for safe keeping. For more information, see Creating a Duplicate Archive Volume.
  • Delete Volume—Use to remove a volume from the server (see Deleting an Archive Volume).


Server Administration Guide - Viewing an Archive Volume (Archiving)

Viewing an Archive Volume

You can use the Archive Volumes Manager to view information about the content of the archive volumes used by the server on which you are working. This is useful when you are searching for the volume that contains certain data. By using the Volume window (accessed via the Archive Volumes Manager), you can view information about the content of each volume as required. When you have found the content that you require, you can then mount the relevant volume and display the archived data in a Trend, List etc.

When you display the Archive Volumes Manager, it displays a list of the archive volumes that have been used by the server on which you are working. You can display the Volume window for each volume in the list. The Volume window provides information about the content of the selected volume.

To display the Volume window:

  1. Access the Archive Volumes Manager (see Manage Your Archive Volumes)
  2. Right-click on the archive volume in which you are interested, then select the View Volume option from the context sensitive menu.
    The Volume window is displayed.

The Volume window contains a header and a list. The header, shown above the list, provides information about the amount of archived events and historic data that are still on-line. This information is useful when you are creating a replacement or duplicate volume as it indicates whether the data is still on-line. Using this information, you can determine whether the replacement or duplicate volume will contain the complete volume or only part of the volume.

The list provides information about the database items to which the archived data relates (Objects), the Type of data that is archived, and the time span covered by the archive volume (an archive volume accumulates data over time as each archive is performed).

There is also an Export button which allows you to export the data on display to a comma separated value format file (see Exporting Information from the Archive Volumes Manager)

For more information, see Manage Your Archive Volumes.


Server Administration Guide - Exporting Information from the Archive Volumes Manager (Archiving)

Exporting Information from the Archive Volumes Manager

You can export information from the Archive Volumes Manager and the Volume window to a comma separated value file. The comma separated value file can then be loaded into another application such as a spreadsheet, where it can be printed, searched etc. This is useful if you need to search for specific information in a large amount of archive volume data.

You can export information about:

  • The archive volumes shown in the Archive Volumes Manager
  • The content of an archive volume. The export can be set from the Volume Window or by right-clicking on the archive volume in the Archive Volumes Manager and selecting the Export Volume option.

To export the information shown on the Archive Volumes Manager, select the Export button on the Archive Volumes Manager and then use the Save window to define the name and destination for the comma separated value file. The exported file will contain the data shown in the Archive Volumes Manager window.

If you need to search through or print data about the content of a volume, you need to export the information for that specific volume. To do this, you need to display the Volume window for the required volume (see Viewing an Archive Volume), then select the Export button on the Volume window. Alternatively, you can right-click on the archive volume in the Archive Volumes Manager and then select the Export Volume option. You can then use the Save window to define the name and destination of the comma separated value file.

When you have created an export file (comma separated value file), you can load it into another application as required.


Server Administration Guide - Creating a Replacement Archive Volume (Archiving)

Creating a Replacement Archive Volume

If an archive volume has been lost, damaged or become corrupted, you can use the Create Replacement Volume feature to create another version of the archive volume. You can create a replacement archive volume by right-clicking on the required volume in the Archive Volume Manager and then selecting the Create Replacement Volume option.

If the data that was on the original archive volume is still on-line, you will be able to create a complete replacement archive volume. However, if only part of the data is still on-line, you will only be able to create a partial replacement archive volume.

If the data you need to include in a replacement volume is only partially available on-line, a message is displayed to inform you that some of the data on the original archive volume is no longer on-line and so cannot be included on the replacement volume. You can use the Volume window to see how much of the archive volume’s data is still on-line (see Viewing an Archive Volume).

When you select the Create Replacement Volume option, a browse window is displayed. Use the browse window to define the destination folder for the replacement volume, then select the OK button to confirm. ClearSCADA will then create a complete or partial replacement volume, depending on how much of the data is still available on-line. The server will also update its index of archive volumes to include the replacement volume instead of the original volume.


Server Administration Guide - Creating a Duplicate Archive Volume (Archiving)

Creating a Duplicate Archive Volume

You can use the Archive Volumes Manager to create a duplicate archive volume. This is useful when you need to create extra copies of an archive volume, for example, backup copies for storage in a fire safe. To create a duplicate archive volume, you need to right-click on the relevant volume in the Archive Volumes Manager and then select the Create Duplicate Volume option.

When you select the Create Duplicate Volume option, a browse window is displayed. Use the browse window to define the destination folder for the duplicate volume then select the OK button to confirm. ClearSCADA will then create a duplicate volume. It will not update the archive index as the new volume is simply a backup copy of an existing volume (the index will continue to reference the original volume).

If the data that was on the original archive volume is still on-line, the duplicate volume will be exactly the same as the original archive volume. However, if only part of the data on the original archive volume is still available on-line, the duplicate volume will not be an exact copy; it can only contain information that is still on-line.


Server Administration Guide - Deleting an Archive Volume (Archiving)

Deleting an Archive Volume

You can use the Archive Volumes Manager to delete an archive volume. The Delete Volume option is designed to be used when a volume has been lost or damaged and a replacement cannot be created as the data for that volume is no longer on-line. By using the Delete Volume option, you can inform ClearSCADA that a volume is no longer in existence or available.

Another use of the Delete Volume feature is that it allows you to ‘rewind’ the archive. For example, if you delete the most recent archive volume(s) and then perform another archive, the data that was on the deleted volume(s) will be archived again (provided it is still on-line). This is useful if you accidentally archive data to the wrong volume, for example, if you inserted the wrong DVD. In this case, you could delete the archive volume so that the server has no record of the DVD and then you could insert the correct DVD and perform another archive for the same data. As a result, the data would be archived onto the correct disk and the server would have a correct record of which volume contains the data.

To delete an archive volume, display the Archive Volumes Manager and right-click on the archive volume you want to remove, then select the Delete Volume option.


Server Administration Guide - Archives List (Archiving)

Archives List

The Archives List provides information about each archive's current status, including the current state which is useful for determining the progress of archive operations.

To display the Archives List:

  1. Either:
  • Display the Queries Bar, expand the Queries folder, then with a Ctrl key pressed double-click on the Archives icon.
    The Archives List is displayed. It is unfiltered. For information about the Archives List, refer to the details provided in step 3.
  • Display the Queries Bar, expand the Queries folder, then double-click on the Archives icon in the Queries Bar.
    The Filter window for the Archives List is displayed.

Or:

  • Select a hyperlink to the Archives List on a suitably configured Mimic.
    The Archives List is displayed. It may already have pre-defined filters applied. Proceed to the description of the List display that follows step 3.

Or:

  • Select a link from the Favorites List (only if the Archives List has been added to your Favorites).
    The Archives List is displayed. It may already have pre-defined filters applied. Proceed to the description of the List display that follows step 3.

Or:

  1. Select the Lists button on the web interface.
  2. Select the hyperlink to the Archives List.
  2. Use the Filter Columns window or Filter Columns/Sort Columns web page to define any constraints. (For more information on filters and sorting, please refer to the ClearSCADA Guide to Lists).
  3. Select the OK button (ViewX) or the Submit Query button (web interface) to display the Archives List.

NOTE: The Archives List for the web interface has a different appearance to the ViewX Archives List (shown above), but contains the same information.

The Archives List provides the following information for each archive (the names vary slightly for the web interface—the web interface column name is indicated after the / ):

  • Name/FullName—The defined name of the archive.
  • State/StateDesc—The current state of the archive. The possible states are:
  • Not Mounted—The archive device does not contain an archive volume.
  • Idle—There is an archive volume in the archive device but there is not an archive operation in progress.
  • Writing—An archive operation is in progress and the data is being written to the archive volume.
  • Writing <time> remaining—An archive operation is in progress and the data is being written to the archive volume. ClearSCADA calculates an estimate as to how long it will take to complete the operation and displays the time as part of the State Desc.
  • Scanning—ClearSCADA is scanning the archive volume to make data available.
  • Scanning <time> remaining—ClearSCADA is scanning the archive volume to make data available. An estimate as to how long the operation will take to complete is displayed as part of the StateDesc value.
  • Last Updated/DataTimeStamp—The time of the latest archive operation.
  • Quality/QualityDesc—Indicates the quality of the archive. The possible entries are:
  • Good—If an archive's Quality is Good, the archive is configured correctly.
  • Configuration Error—If an archive has a Configuration Error Quality, it means that ClearSCADA has detected there is a fault with the archive due to a incorrect archive configuration.
  • Not Connected—If an archive has a Not Connected Quality state, it means that ClearSCADA has detected a fault with the archive - either the Path or Node (or both) have not been configured.
  • Out of Service—If an archive has the Out of Service Quality, the archive is disabled. This means that the In Service check box is clear in the archive's configuration.
  • Volume Label—The name of the volume that is in the archive device. This is blank if the archive device does not contain an archive volume.
  • Free Space—The amount of unused storage space on the volume.
  • Type/TypeDesc—A description of the type of item, in this case, Archive.
  • Alarm View—A link to the Alarm View Mimic for the archive (as defined in the archive's configuration).

It also provides information on any extra fields (see Extra Database Fields).


Server Administration Guide - Archive Status Display (Archiving)

Archive Status Display

You can use the Archive Status Display (also referred to as the Archive View Window) to access information about the current status of an archive. This is useful for checking the progress of the archive operations.

To access the Archive Status Display:

  1. Either:
  • Access the context sensitive menu for the Archive by selecting (or right-clicking, depending on the interface feature) the archive on:
  • The Archives List (ViewX only).
  • The Archive database item in the Database Bar (ViewX only).
  • A Mimic that is configured to provide access to the archive's action menu. (ViewX and web interface).
  • A hyperlink to the archive on the Database page of the web interface.
  • The Alarms page of the web interface (only available for archives that are in alarm).

Or:

  • Select a hyperlink to the archive item from the Database web page on the web interface.
    This displays the status information—ignore step 2 and proceed to the description of the status information.
  2. Select the View Status option.
    The status information for the archive is displayed.

The Status Display varies in appearance according to the type of interface that you use to access the display. The archive status displays provide information about custom fields, combo boxes etc. as well as the following:

  • FullName—The identity of the archive, as defined when the archive database item was created.
  • Type—The type of database item, in this case, archive.
  • Last Modified—The date and time that the archive's configuration was last altered. It also indicates the user name of the engineer that altered the configuration and the number of times the configuration has been altered (the version number). This is only displayed if the archive's configuration has been altered.
  • Created—The date and time that the archive was added to the system. This is only displayed if the archive's configuration has not been altered.
  • Alarm State—The overall state of any alarms for the archive. This can be Normal (when the archive is not in alarm) or any of the alarm conditions (Unacknowledged Uncleared, Acknowledged Uncleared etc.). If multiple alarms have been raised, the alarm state will represent the alarm with the highest severity.
  • Archive Alarm—The current alarm status of the archive. This indicates whether alarms are enabled for the archive and whether any alarms are raised. The possible Archive Alarm settings are:
  • Enabled Inactive—The archive has the alarm feature enabled but has no alarms currently raised.
  • Enabled Active—The archive has the alarm feature enabled and is in an alarm state.
  • Enabled Active Fleeting—The archive has the alarm feature enabled and has a fleeting alarm currently raised.
  • Enabled Cleared—The archive has the alarm feature enabled and has a cleared alarm raised (the cleared alarm has not been acknowledged).
  • Enabled Acknowledged—The archive has the alarm feature enabled and has an uncleared alarm raised. The uncleared alarm has been acknowledged.
  • Disabled Inactive—The archive has the alarm feature disabled so that alarms cannot be displayed and is not in an alarm state.
  • Disabled Active—The archive has the alarm feature disabled but is in a state that corresponds to an active alarm i.e. if the alarm feature was enabled, an alarm would be raised.
  • Disabled Active Fleeting—The archive has the alarm feature disabled but is in a state that corresponds to an active fleeting alarm i.e. if the alarm feature was enabled, a fleeting alarm would be raised.
  • Disabled Cleared—The archive has the alarm feature disabled but is in a state that corresponds to an unacknowledged cleared alarm i.e. if the alarm feature was enabled, there would be an unacknowledged but cleared alarm.
  • Disabled Acknowledged—The archive has the alarm feature disabled but is in a state that corresponds to an acknowledged uncleared alarm i.e. if the alarm feature was enabled, there would be an acknowledged but uncleared alarm.
  • State—Indicates the current status of the archive. The possible entries are:
  • Idle
  • Not Mounted
  • Writing
  • Writing <time> remaining
  • Scanning
  • Scanning <time> remaining

These entries describe the same information as the StateDesc column on the Archives List (see Archives List).


Server Administration Guide - Compressing a Database

Compressing a Database

When an item is deleted from the database, some information about the item is retained. This occupies both disk space and memory. Over time, a large number of items may be deleted, especially when Groups or Templates containing items are deleted. To free up the space used by the deleted items, you can compress the database.

Each item in the database is allocated a unique identifier called an Object ID. The Object ID is used to associate historic data and Event Journal messages with an item in the database.

The Compress Database feature can be used on a live system with no effect on operational availability. The tasks performed by the Compress Database feature are:

  • Removes information about the deleted items
  • Removes online Event Journal records that are associated with the deleted items (archived Event Journal records are not compressed)
  • Removes configuration change records that are associated with the deleted items
  • Re-orders online Event Journal files into chronological order (this can significantly improve the speed of Event Journal searches).

ATTENTION: Compressing the database results in Event Journal records being re-ordered. This changes the Record ID, which while having no adverse affect on ClearSCADA, may cause issues with external applications that use the Event Journal and configuration change record IDs.

To compress a database:

  1. Make a backup of the database (see Back Up the Database). You may need to restore the database if there is a problem with the compression process.
  2. On the main server, right-click on the ClearSCADA icon in the task bar.
    A context sensitive menu is displayed.
  3. Select the Compress Database option.
    A log on prompt is displayed.
  4. Log on via a User account that has the System Admin permission for the System (Root Group).
  5. Choose to proceed with the compression or abort it:
  • If the effects of the compression are permittable, select the Yes button to begin the compression process.
  • If the effects of the compression are not permittable, select the No button to quit the compression process.

When you have compressed the database, the database file will be at its smallest possible size—the configuration relating to deleted items has been removed. The compression process also releases additional memory, although this is a small amount when compared to the amount of memory used by a running system.


Server Administration Guide - Server Emulation

Server Emulation

ClearSCADA includes a server emulation tool that allows you to choose a version of ClearSCADA for the server. This is useful when upgrading a system as it allows systems with a mixture of new and old clients to run documents such as Mimics and Trends (the documents are saved in a format that can be recognized by every client that is connected to the server). The server emulation means older clients can still access the documents that are created and altered on newer clients.

When using the server emulation feature, you need to set the server to emulate a version of the ClearSCADA software that is compatible with the oldest clients on your system (the clients that run the oldest version of ClearSCADA).

If a user attempts to display a document that has been saved in a version that is not supported by the client, the document display will show an 'unsupported file format' diagnostics message. This means that the document has been saved on a client that runs a later version of ClearSCADA. (The client showing the diagnostics message runs an older version of ClearSCADA than the the client on which the document was saved). You can rectify this problem by using the Save All Documents feature (see Converting Unsupported Files into Supported Files).

In this section, we explain:

  • Setting a Server to Emulate a Software Version
  • Converting Unsupported Files into Supported Files.


Server Administration Guide - Setting a Server to Emulate a Software Version (Server Emulation)

Setting a Server to Emulate a Software Version

To use the server emulation feature:

  1. Locate the client on your system that is running the oldest version of the ClearSCADA software. Look at the software version that is running on the client - this is the software version that has to be emulated by the server (to allow the clients to display the Mimics, Trends, and Logic programs etc.)

NOTE: If the server is part of a multi-server arrangement, you need to locate the client that is running the oldest version of the software on the entire system. For example, on a Main-Standby system, you need to investigate the software versions of each of the clients on both servers.

  2. Log on to the server.
  3. Display the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  4. Expand the System Configuration branch.
  5. Select Emulate Server Version.
  6. Select the Present a Different Server Version to Clients check box. This enables the server emulation feature so that you can choose the required version of software.
  7. Choose the version of ClearSCADA software that the server is to emulate from the combo box. The version you choose should be compatible with the version of the ClearSCADA software that is running on the client you located in step 1.
  8. Re-Start the ClearSCADA Server so that server automatically closes the connections to the clients and restarts them so that the clients can make use of the emulation feature. Alternatively, you can choose not to restart the server and restart each of the clients manually instead.


Server Administration Guide - Converting Unsupported Files into Supported Files (Server Emulation)

Converting Unsupported Files into Supported Files

If a user attempts to display a document that is incompatible with the user’s client, ClearSCADA displays an 'Unsupported File Format' message. This indicates that the client PC is running an older version of ClearSCADA than the client PC that was used to save the document. By using the Save All Documents feature you can save the document in a format that can be used by the user’s client (and other clients).

You can use the Save All Documents feature to save all documents in a format that is compatible with the ClearSCADA version that the server is emulating. This will allow your clients to display every Mimic, Trend, Logic program etc., as the version of ClearSCADA that the server is emulating should be compatible with every client.

To convert unsupported files into supported files:

  1. Check that the server is set to emulate the oldest version of ClearSCADA that is running on one of its clients (see Setting a Server to Emulate a Software Version).
  2. Log on to a client that is running a version of ClearSCADA that is the same version (or later) as the version running on the server. Typically, it is easiest to log on to the client that is running on the server itself.
  3. Locate the following file in the ClearSCADA software that is installed on the client:
SaveAllDocuments.exe

  4. Run the SaveAllDocuments.exe program.
    The Save All Documents program runs and the Save All Documents window is shown.
  5. Use the Save All Documents window to select the required system and choose which types of document are saved in a compatible format:
  • System—Choose the system which contains the latest version of the server and the files that are to be converted.
  • Username—Enter the user name for accessing the selected system.
  • Password—Enter the password for accessing the selected system.
  • Select the check boxes for the types of documents you want to convert:
  • Mimics
  • Graphs
  • Logic

If you want the Logic programs to run again after saving, you should also select the Recompile Logic Programs check box.

  6. Select the Go button.
    The documents are saved in a compatible version and the Save All Documents window is closed. Users should now be able to display the documents on the clients running the older version of the ClearSCADA software.

NOTE: During the save process, you can select the Abort button at any time to cancel the document conversion. If you abort the conversion, any documents that have not yet been converted will remain in their current format (and so may be unavailable on some clients)


Server Administration Guide - Back Up the Database

Back Up the Database

You can make a back up of your database at any time. When you have made a back up, you can use the back up files to restore your database to its original state (i.e. restore the data that has been lost or corrupted since the back up took place).

We recommend that you back up your database:

  • When making potentially harmful changes to your system, such as compressing a database or changing the server arrangement
  • Routinely, so that you can restore your database in the event of unexpected errors, such as server failures (when there is no redundancy) and human errors, for example, accidental deletions.

When making a back up, we also recommend that you make a back up of the 'ClearSCADA' registry key, as this contains information about the setup of your server at the time of back up.

For information on backing up and loading database files and the 'ClearSCADA' registry key, refer to the following sections:

  • Back Up Your Database Files
  • Back Up Server Settings
  • Load your Back Up Database Files.


Server Administration Guide - Back Up Your Database Files (Back Up the Database)

Back Up Your Database Files

To back up the database:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool).
  2. Expand the System Configuration branch.
  3. Select Location to display the Location settings, which show the names of the various database files. For more information on the locations, see Locations of the Database Folders.

To back up your system, you need to make copies of the files listed at the above locations. However, before you copy the files, you should consider what configuration and data you actually need to back up:

  • Configuration Only back up:
  • Copy the Metadata file, the Configuration file, and the Data Files (you should also copy the server settings, see below).
  • Configuration and Data back up:
  • Copy the Metadata file, the Data file, the Configuration file, and the Data Files, the Historic Files, and the Archive Index for each server (you should also copy the server settings, see below).
  • Full Back up:
  • Copy the Metadata file, the Data file, the Configuration file, and the Data Files, the Historic Files, the Archive Index for each server, the Event Journal, and the Historic Data (you should also copy the server settings, see below)

If you have the Archiving feature enabled, there is no real need to back up your historic data and Event Journal as these were already backed up when they were archived.

NOTE: Archiving does not include the most recent data (see Set Historic Data to be Archived).

The size of historic data and Event Journal files may mean it is impossible to copy the data to a single CD or DVD. In this situation, you would need to look at using alternative storage media such as a hard drive or a suitable software solution.

  4. For the files you wish to back up:
  1. Use Windows Explorer or a similar application to browse to the required file or folder.
  2. Make a copy of the file or folders.
  3. Save the copy in a different location, such as a removable disk or another server.

You now have a back up of the database. We also recommend that you Back Up Server Settings, which are stored in the registry.


Server Administration Guide - Back Up Server Settings (Back Up the Database)

Back Up Server Settings

When you make a back up of your database, we also recommend you make a back up of the server’s settings which are stored in one or more registry keys. The registry keys contain information about the server’s set up and are needed to help avoid configuration mis-matches if your back up files are loaded on to another server.

To make a back up of the server’s settings, you need to export the registry key(s):

  1. In Windows, select Start, then Run.
  2. At the prompt, enter:
Regedit

  3. Select the OK button to display the Registry Editor.
  4. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Schneider Electric\ClearSCADA
  5. Select the 'ClearSCADA' key in the tree-structure.
  6. Select the File menu, then the Export option to display the Export Registry File window.
  7. Browse to the location at which you want to store the back up registry file.
  8. Enter a name for the back up registry file in the File name field and set the Save as type combo box to Registration Files (*.reg)
  9. In the Export Range section, select the Selected branch option button (if it is already selected, skip this step).
  10. Select Save to make a back up of the registry key.
  11. If you are using a 64 bit server, repeat steps 4-10 inclusive, only this time browse to the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\
    Schneider Electric\ClearSCADA     key. (64 bit servers have two registry keys that need to be copied).

The back up files you have created will be used by Schneider Electric engineers if:

  • The settings need to be loaded onto a new server
  • The settings on the original server have been lost
  • The settings on the original server have unexpectedly changed.

ATTENTION: Please seek advice from Schneider Electric before attempting to restore a back up of the settings (see Load your Back Up Database Files). Changing the registry settings without expert guidance could have an unexpected effect on your system and could even stop a ClearSCADA server from running.


Server Administration Guide - Load your Back Up Database Files (Back Up the Database)

Load your Back Up Database Files

ATTENTION: Please seek advice from Schneider Electric before attempting to load back up settings. Changing the registry settings without expert guidance could have an unexpected effect on your system and could even stop a ClearSCADA server from running.

If you have created back up database files (see Back Up Your Database Files), you can load them on to the server on which they were created or onto another server. This is useful if your system has had corrupted data or data has been deleted mistakenly, as you can use the back up files to restore your system to a previous state.

Typically, you would use your back up files to restore configuration from a previous time (usually because configuration changes made at a later date have caused unexpected results). To do this, you only need to load the Metadata, Configuration, Data and Data Files back ups.

If you are restoring a back up onto a new server or a server that has lost the original data, you can also load the Historic Data, Event Journal and Historic Files. However, if the server already contains data, you should only load the Historic Data or Event Journal back up files if there is a known problem with the historic and event data on your system. This is because the Historic Data and Event Journal back up files will overwrite any existing historic and event files on your system, and so historic data or events recorded after the last time in the back up files may be lost. There is no risk of data loss when restoring Historic Files.

To load your back up files onto a server:

  1. On the server that is to load the back up files, use Windows Explorer to browse to your back up files.
  2. For each back up file that you want to load:
  1. Make a copy of the back up file
  2. Paste the copy into the location defined in the server’s configuration (see Locations of the Database Folders).


Server Administration Guide - Check the Integrity of your System

Check the Integrity of your System

ClearSCADA automatically runs integrity checks on your system every hour and during start up. The integrity checks test your system’s internal links are consistent and running correctly. Integrity failures are rare and are usually caused by an unexpected sequence of configuration events.

In the unusual event of an integrity failure, your database will stop running and the server icon in the Windows taskbar will change color to magenta, like this:

If ClearSCADA detects an integrity error, you should contact Schneider Electric for assistance. You will need to provide the latest server log files (right-click on the server icon and select the ViewDB options to access the server log files) and if an integrity failure warning dialog box has been displayed, you should provide details about its diagnostics message too. Schneider Electric will then use the information you provide to determine the cause of the problem.

If the log files have no record of the cause of the integrity check failure, Schneider Electric may ask you to run another integrity check on your system. This will create an updated server log file which can be used to diagnose the cause of the integrity failure.

To run an integrity check:

  1. Right-click on the server icon in the Windows taskbar
  2. Select the Check Integrity option from the context sensitive menu.
    This will display the Integrity Check dialog box.
  3. Use the Integrity Check dialog box to choose which integrity checks are to run. Schneider Electric will advise you which integrity checks to run. Typically, we request that you run each of the tests except Loaded Historic Granules, Foreign Keys, and Template Instances as these tests can take a considerable amount of time.
  4. Select the OK button to run the checks.
    If ClearSCADA has detected an integrity fault, a diagnostics message is displayed informing you to examine the log file. When this message is displayed, the cause of the integrity check has been logged in the server log file and can be used by Schneider Electric to diagnose the cause of the problem.
    Server Log file showing integrity check information.

  5. Send the server log file(s) to Schneider Electric.


Server Status Tool Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Server Status Tool Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Server Status Tool Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Server Status Tool Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Server Status Tool Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Server Status Tool Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to use the Server Status Tool to monitor your system and access statistics for diagnosis.

A list of the features covered in this Guide can be found in Welcome to the Server Status Guide.


Server Status Tool Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed to be used by server administrators and maintenance engineers who are responsible for diagnosing unexpected conditions on your ClearSCADA system.


Server Status Tool Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Server Status Tool Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to ViewX and WebX Clients.


Server Status Tool Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Server Status Tool Guide - Welcome to the Server Status Guide

Welcome to the Server Status Guide

Welcome to the ClearSCADA Guide to Server Status. This Guide explains how to access and use the Server Status Tool.

Designed to provide you with accurate system statistics, the Server Status Tool can be used to diagnose unexpected occurrences on your system. You can access the Server Status Tool on any ClearSCADA server.

If you are unfamiliar with the Server Status Tool, we recommend you refer to the following sections:

  • System Analysis
  • Working with the Server Status Tool
  • Run the Server Status Tool
  • Overview of the Server Status Tool
  • Save a SnapShot of the Status Data Currently on Display
  • Define when the Server Status Tool is Updated.

You should also familiarize yourself with Log Files and Log File Settings (see Logging and Monitoring in the ClearSCADA Guide to Server Administration).

If you are familiar with the Server Status Tool, you may prefer to skip the above sections and refer to information about a specific group of categories or an individual category:

  • General—Please refer to General System Status Information
  • Information
  • Modules
  • Locks
  • Log Files
  • Logging
  • Memory Usage
  • Threads.
  • Database—Please refer to Database Status Information
  • Alarm Redirections
  • Buffers
  • Data File Cache
  • Diagnostics
  • File Statistics
  • Indices
  • Interest
  • Latest System Calls
  • Queued System Calls
  • Reference Field Indices
  • Searches
  • Users
  • Server—Please refer to Server Status Information
  • Advise Threads
  • Advises
  • Clients
  • Connected Workstations
  • Link Threads
  • Links (Server)
  • Standby—Please refer to Standby Status Information
  • Counters
  • Historic Transfer
  • ICMP Polls
  • Links (Standby)
  • Polls
  • Historic—Please refer to Historic Status Information
  • Historian
  • Historic Searches
  • Journal Searches
  • Query Processor—Please refer to Query Processor Status Information
  • Latest Queries
  • Largest Queries
  • Longest Queries
  • OPC—Please refer to OPC Status Information
  • DA Groups
  • DA Items
  • HDA Items
  • XML-DA Items
  • XML-DA Subscriptions
  • Web—Please refer to WebX Status Information
  • Clients (WebX)
  • Cookies
  • Links (WebX)
  • Threads.


Server Status Tool Guide - System Analysis (Welcome to the Server Status Guide)

System Analysis

To help you assess your system, ClearSCADA includes a Server Status Tool which features a diverse range of statistical and diagnostic information. Using this information, you can check the status of your system and investigate unexpected conditions.

For many types of unexpected system behavior, you will need to contact Schneider Electric for assistance. However, you may be able to resolve some issues yourself, by altering the configuration of your system or by stopping external factors from affecting ClearSCADA.

If you contact Schneider Electric for assistance, our engineers may ask you to provide a log file, which is a file that provides a record of system activity.To provide a log file, you will need to use the Server Status Tool to enable logging for the relevant part of your system, for example, you may need to enable logging for a specific driver.

In the following sections, we explain how to access the Server Status Tool and use it to analyze your system, activate logging, and investigate (and in some cases, resolve) issues on your system:

  • Working with the Server Status Tool
  • Run the Server Status Tool
  • Overview of the Server Status Tool
  • Save a SnapShot of the Status Data Currently on Display
  • Define when the Server Status Tool is Updated.
  • Log Files and Logging Settings. These settings are also described in detail in the Server Administration Guide (see Logging and Monitoring in the ClearSCADA Guide to Server Administration).
  • Common System Problems.


Server Status Tool Guide - Working with the Server Status Tool

Working with the Server Status Tool

To help you monitor your system and investigate unexpected system behavior, ClearSCADA includes a Server Status Tool. Available on your ClearSCADA servers, the Server Status Tool provides detailed statistical and diagnostic information.

Using the information shown in the Server Status Tool, you can:

  • Monitor the current status of your system
  • Investigate any unexpected performance issues
  • Identify the cause of unexpected system behavior (you may also be able to resolve your issues completely by changing configuration settings or altering external factors that are affecting ClearSCADA)
  • Enable and disable logging for the various ClearSCADA components. If your system experiences issues that require expert analysis from Schneider Electric engineers, you may be asked to provide log files. The log files contain detailed information about your system’s activity.

In this section, we provide an Overview of the Server Status Tool and explain how to:

  • Run the Server Status Tool
  • Save a SnapShot of the Status Data Currently on Display
  • Define when the Server Status Tool is Updated.

When working with the Server Status Tool, you will also need to be familiar with the Server Status Categories.

NOTE: You can also use the OPC Data Bar to view status values, see Working with the OPC Data Bar in the ClearSCADA Guide to Core Configuration.


Server Status Tool Guide - Run the Server Status Tool (Working with the Server Status Tool)

Run the Server Status Tool

The Server Status Tool contains statistical and diagnostic information that you can use to assess your system and investigate unexpected system behavior.

In this section, we explain how to run the Server Status Tool on a ClearSCADA server. For information on accessing similar information from a WebX client, see Access Server Status Information from a WebX Client.

  1. On the ClearSCADA server, right-click on the ClearSCADA icon in the windows taskbar.
    A context sensitive menu is displayed.
  2. Select the Status option.
    The Server Status Tool is displayed. Depending on the way your system is configured, you may be able to browse the groups of categories immediately or you may be prompted to log on via your User account (use the same Username and Password that you would use to log on to ViewX)

Alternatively, you can select the Start button in the Windows taskbar, then select the Programs>Schneider Electric ClearSCADA>Server Status options to display the Server Status Tool.

If you are unfamiliar with the Server Status Tool, see Overview of the Server Status Tool.

If you are familiar with the ClearSCADA Status Tool, refer to the section you require:

  • General System Status Information
  • Database Status Information
  • Server Status Information
  • Standby Status Information
  • Historic Status Information
  • Query Processor Status Information
  • OPC Status Information
  • WebX Status Information
  • Common System Problems.


Server Status Tool Guide - Access Server Status Information from a WebX Client (Working with the Server Status Tool)

Access Server Status Information from a WebX Client

WebX clients provide access to the same server status information that is available on the Server Status Tool. In WebX, the server status information is shown on the Diagnostics page (which WebX users can access by selecting the Diagnostics toolbar button).

Unlike the Server Status Tool, WebX does not have a tree-structure of the server status categories. Instead, you can access each of the categories by selecting the hyperlinks at the top of each page, for example, to display status information about the server’s clients, you would select the Clients hyperlink in the Server row.

When you select a hyperlink for one of the server categories, the information for that category is displayed in a table on the web page.

For more details on the information that can be shown on the diagnostics page, please refer to the documentation for the corresponding section on the Server Status Tool:

  • General System Status Information
  • Database Status Information
  • Server Status Information
  • Standby Status Information
  • Historic Status Information
  • Query Processor Status Information
  • OPC Status Information
  • WebX Status Information

Further Information

WebX clients: see WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


Server Status Tool Guide - Overview of the Server Status Tool (Working with the Server Status Tool)

Overview of the Server Status Tool

The Server Status Tool provides statistical and diagnostic information about the ClearSCADA server and its connections to clients. You can use it to determine the current status of your system and investigate the cause of any issues relating to system performance or
behavior

The Server Status Tool consists of:

  • Server Status Explorer
  • Server Status Display
  • Server Status Menu.


Server Status Tool Guide - Server Status Explorer (Working with the Server Status Tool)

Server Status Explorer

The Server Status Explorer provides a tree-structure that groups the status information. The Server Status Explorer is shown on the left-hand side of the Server Status Tool window (the right-hand side of the window is called the Server Status Display, and is used to display the various status settings).

Server Status Explorer
Server Status Display

Each system is represented in the Server Status Explorer and can be expanded to reveal groups. Each group represents a specific type of information and contains categories of data.

You can use the + and - symbols to expand/collapse the hierarchy of systems, groups and categories as required. To display the data for a category, simply select the required category—the data is show in the Server Status Display.


Server Status Tool Guide - Server Status Display (Working with the Server Status Tool)

Server Status Display

The Server Status Display section contains the status information for the selected category. For example, if you use the Server Status Explorer to select the Logging category in the General group, the Locks information is shown in the Server Status Display section.

Server Status Display

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Server Status Tool Guide - Server Status Menu (Working with the Server Status Tool)

Server Status Menu

The Server Status Tool has a menu that contains options that you can use to:

  • Save a SnapShot of the Status Data Currently on Display
  • Exit the Server Status Tool
  • Define when the Server Status Tool is Updated
  • Display information about the version number of the Server Status Tool.

The Server Status Menu is displayed at the top of the Server Status Tool.

Server Status Menu

It contains the following options:

  • File—Use to access the following options:
  • Save Snapshot—Use to take a 'snap shot' of the status information that is currently displayed in the Server Status Display. The status information is stored in a text file (see Save a SnapShot of the Status Data Currently on Display).
  • Exit—Use to close the Server Status Tool.
  • View—Use to access the following options:
  • Refresh Now—Use to update the information shown in the Server Status Tool immediately.
  • Update Speed—Use to choose how frequently the information in the Server Status Tool is updated. Choose from the time options (in seconds) or select the Paused option to stop the Server Status Tool from updating (until the Paused option is deselected).

For more information, see Define when the Server Status Tool is Updated.

  • Help—Use to access information about the version of the Server Status Tool. The Help menu has a single option:
  • About Server Status—Displays information about the version number.


Server Status Tool Guide - Save a SnapShot of the Status Data Currently on Display (Working with the Server Status Tool)

Save a SnapShot of the Status Data Currently on Display

You can save a snapshot of the status data that is shown in the Server Status Display. The snapshot contains the status information that is currently shown in the Server Status Display and is stored as a text file.

Snapshot files are useful as they can easily be sent to other users via e-mail, allowing other users to view the status of the server on which you are working.

NOTE: The snapshot stores the status information that is shown in the Server Status Display when the Save Snapshot option is selected. It only contains the data for the category that is currently selected, for example, if you have the Locks category selected, the snapshot file will only contain the status values for Locks.

To save a snapshot of the status data:

  1. Display the Server Status Tool (see Run the Server Status Tool).
  2. Select the File menu.
  3. Select the Save Snapshot option.
    The Save As window is displayed.
  4. Use the Save As window to define a name and location for the text file that will contain the status data.
  5. Select the Save button to store the text file.


Server Status Tool Guide - Define when the Server Status Tool is Updated (Working with the Server Status Tool)

Define when the Server Status Tool is Updated

When you display the Server Status Tool, it contains the status data for the time at which the window was displayed. By default, the Server Status Tool is updated with the latest status data every second.

You can use the Server Status Tool menu to change the update setting so that the Server Status Tool is 'refreshed' with the latest data:

  • Immediately
  • Every second
  • Every 5 seconds
  • Every 10 seconds
  • Every 30 seconds.

You can also use the Paused option to stop the Server Status Tool from being updated until the Paused option is deselected.

To define when the Server Status Tool is displayed:

  1. Display the Server Status Tool (see Run the Server Status Tool).
  2. Select the View menu, then select the required option:
  • Refresh Now—To update the status information immediately
  • 1 Second—To update the status information every second
  • 5 Seconds—To update the status information every 5 seconds
  • 10 Seconds—To update the status information every 10 seconds
  • 30 Seconds—To update the status information every 30 seconds.


Server Status Tool Guide - Server Status Categories

Server Status Categories

The Server Status Tool provides status information that is organized into the following categories:

  • General—The General folder contains these categories:
  • Information
  • Modules
  • Locks
  • Log Files
  • Logging
  • Memory Usage
  • Threads
  • Database—The database folder contains these categories:
  • Alarm Redirections
  • Buffers
  • Data File Cache
  • Diagnostics
  • File Statistics
  • Indices
  • Interest
  • Latest System Calls
  • Queued System Calls
  • Reference Field Indices
  • Searches
  • Users
  • Server—The Server folder contains these categories:
  • Advise Threads
  • Advises
  • Clients
  • Connected Workstations
  • Link Threads
  • Links (Server)
  • Standby—The Standby folder contains these categories:
  • Counters
  • Historic Transfer
  • ICMP Polls
  • Links (Standby)
  • Polls
  • Historic—The Historic folder contains these categories:
  • Historian
  • Historic Searches
  • Journal Searches
  • Query Processor—The Query Processor folder contains these categories:
  • Latest Queries
  • Largest Queries
  • Longest Queries
  • OPC—The OPC folder contains these categories:
  • DA Groups
  • DA Items
  • HDA Items
  • XML-DA Items
  • XML-DA Subscriptions
  • WebX—The Web folder contains these categories:
  • Clients (WebX)
  • Cookies
  • Links (WebX)
  • Threads.

NOTE: If you select the Group folder for the status category, the first section of status information for that category is shown in the Server Status Display. For example, if you select the Group folder, the Server Status Display shows the Information status data.


Server Status Tool Guide - General System Status Information

General System Status Information

The Server Status Tool provides status information that is organized into groups of categories. The first of those groups is named General and it contains several sub-categories of status information.

The sub-categories are:

  • Information—provides information about the current status of the server's hardware and software
  • Modules—provides diagnostic information about each driver that is installed on your ClearSCADA server
  • Locks—provides diagnostic information about the software locks on your ClearSCADA server
  • Log Files—provides information about the log files for your ClearSCADA server’s database
  • Logging—provides information about the various types of logging on your ClearSCADA server
  • Memory Usage—provides information about how the memory on your ClearSCADA server is being used
  • Threads—provides information about the threads that are being used by your ClearSCADA server.

NOTE: If you select the General group folder, the Information category status information is shown in the Server Status Display. This is because when a group folder is selected in the Server Status Tool, the Server Status Display shows the status information for the first sub-category in the selected group.


Server Status Tool Guide - Information (General System Status Information)

Information

The Information category provides status information about the current status of the server's hardware and software.

The Information category provides a variety of information about the server, including:

  • The version of ClearSCADA that is running on the server
  • The current state of the server, for example, Main
  • The time that the server changed to its current state
  • The time that the server last became Main
  • The amount of available memory on the server
  • The amount of available paging file
  • The operating system that is being used
  • The server ports that are in use and the applications that are using them, for example, the WebX server
  • The number of ViewX clients and WebX clients that are connected to the server.


Server Status Tool Guide - Modules (General System Status Information)

Modules

The Modules category provides diagnostic information about each driver that is installed on your system.

The status information is categorized as:

  • Driver—The name of the driver, for example, SCADAPackModbus.
  • Status—The current status of the driver. This can be:
  • Running—The driver software is currently in operation.
  • Internal Driver—The driver software is part of the database but is implemented separately for specific requirements. Internal drivers cannot be started or stopped as they are not run—there is no process.
  • Starting—The driver is starting to run. If the status is consistently Starting, the driver software is not present—contact Schneider Electric for advice.
  • Stopping—The driver is attempting to stop.
  • Stopped—The driver is no longer running.
  • Stopped, No Config—The driver is not running due to there being no database items defined for that driver.
  • Failed—The driver software has failed (please report the failure to Schneider Electric).
  • No License—Your system does not have a valid license for the driver
  • Invalid Registration—ClearSCADA cannot find the .dll file for the driver or the .dll file is inaccessible or corrupt. Typically, this only occurs if the registry settings for the driver have been incorrectly changed (manually), or if a user deletes or renames some of the ClearSCADA components in the installation location.
  • Startup—The type of startup for the driver. If it is Automatic, the system starts the driver software whenever you start the server. If the Startup is Manual, you need to start the driver by using the Start or Re-start features (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).
  • Failure Count—The total number of times that the driver software has failed.
  • Objects—The number of database items that have been created for each driver. If the number is 0, the driver will not start automatically (even if the driver is set to start automatically). This is to help ensure system resources are only used by drivers that you need to run on your system.

For more information on starting and stopping a driver, see Start and Stop a Driver in the ClearSCADA Guide to Server Administration.

  • Telnet Port—The port that is used for Telnet monitoring for each driver.
  • Logging Options—The logging options vary according to the driver. They correspond with the entries on the Current Options section of the Logging window (see Logging and Monitoring in the ClearSCADA Guide to Server Administration).


Server Status Tool Guide - Locks (General System Status Information)

Locks

The Locks category provides status information about the software locks. Typically, you will only need to view the lock status when asked to do so by Schneider Electric engineers—the engineers may use the status information to diagnose performance issues such as latency.

The status information for each lock is categorized as:

  • Id—A unique number that ClearSCADA uses to identify the lock.
  • Name—The name that has been allocated to the lock. Typically, this indicates the software component to which the lock relates.
  • Type—Indicates the type of lock. The lock can be RW (which means there are multiple readers and no writers, or there are no readers and 1 writer) or CS (which means there is 1 reader or writer with exclusive access).
  • Status—Indicates whether the lock is active. The status can be Locked or Unlocked (unlocked is indicated by a - sign).


Server Status Tool Guide - Log Files (General System Status Information)

Log Files

The Log Files category displays the status of the latest log file for the database. This is useful when you need to determine whether a log file contains the latest logged data.

The status information for the log files is categorized as:

  • File Base—The location of the log file.
  • Curr File—The number of the latest log file.
  • File Size—The size of the latest log file.
  • Max Size—The largest permitted size for the log file The log file cannot exceed this size; when there is more data, an additional log file will be created.
  • Pend Msg—The number of messages waiting to be sent.
  • Telnet Port—The number of the port that has been allocated to Telnet.
  • Clients—Indicates whether the server has Telnet clients.
  • Last Message—A time stamp of the last message stored in the log file.


Server Status Tool Guide - Logging (General System Status Information)

Logging

You can use the Logging category to view the status of the various types of logging. The logging information indicates which log data is recorded for your system—the log data is used by Schneider Electric engineers to diagnose abnormal conditions.

You can also use the Logging category to enable or disable the logging for each logging class (by right-clicking on the class in the Logging category and selecting the Enable or Disable option as required). This is useful for reducing the amount of logging when there is a high load on the server—you can reduce the load by restricting the server logging to server errors only).

The logging status is categorized as:

  • Name—A description of the type of logging.
  • Class—Shows the class of logging. These class codes are the keywords that have to be entered when using the ClearSCADA Command Line Tool (see Server Command Line Tool in the ClearSCADA Guide to Server Administration).
  • Enabled—Indicates whether logging is enabled for the relevant class. This can be:
  • Yes—Logging is enabled for the class.
  • No—Logging is not enabled for the class.

For many systems, we recommend that you use the Default setting for the Logging status categories. The Default setting provides sufficient logging information for most types of condition, without having a significant impact on the performance of your system. You should only change the setting for a logging category if you are performing a specific type of investigation and have been advised to alter the setting by a Schneider Electric engineer. Some logging status categories are only designed to be used in specific circumstances as although they provide more information, they can have a considerable impact on system performance.


Server Status Tool Guide - Memory Usage (General System Status Information)

Memory Usage

You can use the Memory Usage category to view how the server's memory is being used.

Typically, the Memory Usage statistics are useful when there are abnormal conditions on systems that have large databases and are running out of memory. By examining the statistics, you can determine which areas of the system need to be tuned so that they use less memory. A common example of this is when historic data is being logged too frequently and so there is a large amount of historic data using up the server's memory (this may result in high Raw, Modified, and Annotation memory usage).By using the Memory Usage statistics, you can identify that historic data is using too much memory and you can then alter the historic cache settings and other configuration as required.

The memory statistics are categorized under these headings:

  • Source—The type of system component that is using the server's memory.
  • Usage—The amount of server memory used by each component.

There is also a total memory usage statistic.


Server Status Tool Guide - Threads (General System Status Information)

Threads

The Threads category provides status information about the threads that are in use by the server. Each thread is a separate execution path within a process. For example, the DB Event thread is an execution path within the ClearSCADA Database Server process. The threads allow the process to perform multiple tasks simultaneously.

The status of each thread is categorized as:

  • Id—The number that is used by ClearSCADA to identify the thread.
  • Desc—A description of the thread.
  • Exec Count—The number of times the thread has executed.
  • State—The current state of the thread.

If the State of the thread is Waiting, the thread is healthy.

If the State of the thread is consistently (i.e. for minutes or hours) any state except Waiting, there is a problem and you should contact Schneider Electric.

  • Run Time—The total amount of time that has elapsed since the thread started.
  • User Time—The total amount of time that the CPU has spent executing the thread in user mode.
  • Kernel Time—The amount of time the thread has spent in the operating system.


Server Status Tool Guide - Database Status Information

Database Status Information

The Server Status Tool provides status information that is organized into groups of categories, each of which contains sub-categories. The Database group contains the following sub-categories of status information:

  • Alarm Redirections
  • Buffers
  • Data File Cache
  • Diagnostics
  • File Statistics
  • Indices
  • Interest
  • Latest System Calls
  • Queued System Calls
  • Reference Field Indices
  • Searches
  • Users.


Server Status Tool Guide - Alarm Redirections (Database Status Information)

Alarm Redirections

The Alarm Redirections category provides status information for any alarm redirections that are in process.

WARNING

ALARM NOTIFICATIONS DURING SHUTDOWN

If the server is shut down while alarm redirections are in process, the pending alarm redirections will be lost. On lone server systems, this means that the intended recipients will not be notified. On multi-server systems, the alarm redirections will still be sent to the recipients, but from the Standby server that goes Main.

On a lone server system, the loss of pending alarm redirections can result in death, serious injury, or equipment damage.

The alarm redirection status information is categorized as:

  • Id—The number that ClearSCADA uses to identify the alarm redirection.
  • Trigger—The alarm condition that causes the alarm redirection to be sent. If the Trigger is Retry, it means the alarm redirection could not be sent, for example, with alarm redirection e-mails, Retry would mean that the e-mail could not be sent on the first attempt and so ClearSCADA is attempting to send it again (a retry).
  • Source—The full name of the database item for which the redirected alarm has been raised.

If the Trigger is Retry, the Source may show ‘Attempt n of n’. This means that the alarm redirection could not be sent successfully at the first attempt and so ClearSCADA is attempting to send it again. The numbers indicate the amount of retries attempted and the total number of retries that can be attempted.

  • Desc—The name of the action that determines where the alarm redirection is sent.
  • Low Severity—The severity level that defines the start of the severity range of the alarm redirection.
  • High Severity—The severity level that defines the end of the severity range of the alarm redirection.
  • Remaining Delay—The amount of time remaining before an alarm redirection is sent (alarm redirections can be configured to have a delay so that they are not sent immediately).
  • Abort—The alarm condition that causes the alarm redirection to be canceled. If the alarm state of the item in alarm state changes to the Abort state within the Remaining Delay, the alarm redirection will not be sent.
  • Unique Id—A unique number used to identify the alarm redirection.
  • Stby A—Indicates whether the alarm redirection has been sent to the Standby server that is recognized as Standby A in the server architecture. This will be:
  • Not Sent if the alarm redirection has not been sent or if there is no Standby server.
  • Sent if the alarm redirection has been sent to the Standby A server successfully
  • Sending if the alarm redirection is still in the process of being sent to the Standby A server.
  • Stby B—Indicates whether the alarm redirection has been sent to the Standby server that is recognized as Standby B in the server architecture. This will be:
  • Not Sent if the alarm redirection has not been sent or if there is no Standby server.
  • Sent if the alarm redirection has been sent to the Standby B server successfully
  • Sending if the alarm redirection is still in the process of being sent to the Standby B server.


Server Status Tool Guide - Buffers (Database Status Information)

Buffers

ClearSCADA uses internal buffers to help ensure that sufficient memory is available for performing critical tasks. The internal buffers are blocks of memory that are permanently allocated for use with frequent tasks.

Status information about the internal buffers is shown in the Buffers category on the Server Status Tool. Typically, this information is only used by Schneider Electric engineers when investigating potential memory issues on systems with large databases.

The buffers status information is categorized as:

  • Id—A number that is used internally to identify the buffer.
  • Desc—A description of the buffer. The descriptions fall into one of the following categories:
  • Object Fragment—These buffers are used for temporarily storing a fragment of a database item, such as a configuration change. They are sized to accommodate the largest fragment of a database item).
  • Object Config/Data/Dynamic—These buffers are used when saving the database.
  • Template Object Propagation/Template Aggregate Propagation—These buffers are used when information is being taken from a Group Template to be used in a Group Instance for that Template.
  • Standby Structure/Config/Data/Dynamic/Fragment—Used on the Main server to store data temporarily during the Main to Standby transfer process.
  • Standby Sink—Used by the Standby server(s) when receiving updates from the Main server.
  • ClearSCADA Request/Reply—Used when there are update requests made to the database.
  • ClearSCADA Import/Export—These buffers are used to store data during the import and export operations.
  • Temporary Storage—Used to store miscellaneous information (information that does not fall into any of the other buffer status categories) temporarily.
  • Size—The amount of memory used for the buffer.
  • Access Count—The total number of times the buffer has been used since the server started.
  • Status—Indicates the current status of the buffer, which can be:
  • OK—There are no detected problems with the buffer
  • **Recursive**—Multiple tasks attempted to use the buffer at the same time. This indicates a serious error and should be reported to Schneider Electric as soon as possible.


Server Status Tool Guide - Data File Cache (Database Status Information)

Data File Cache

The Data File Cache category shows statistical information about the data files that are used by Data Grids. The data that is used within Data Grids is stored in data files. When the data in the files is required, the relevant data files are loaded into memory. If changes are made to the data files while they are loaded in memory, ClearSCADA will attempt to flush these changes so that they are stored in the data files on disk.

The Data File Cache statistics are displayed under these categories:

  • Total Files Size—The total amount of memory being used by data files.
  • Maximum Cache Size—The maximum amount of memory permitted for use by data files.
  • Current Cache Size—The current amount of memory being used by data files.
  • Percentage Used—The percentage of the total cache currently being used by data files. This can exceed 100% as the size of data files loaded into memory can exceed the cache size.
  • Total Files—The total number of data files on the system.
  • Cached Files—The total number of data files loaded into memory.
  • Changed Files—The total number of data files that have been altered while in memory and are waiting to be flushed to the stored data files.


Server Status Tool Guide - Diagnostics (Database Status Information)

Diagnostics

The Diagnostics category provides statistical information about system activity. You can use this information to investigate the amount of system traffic.

The traffic status information is shown in rows, with each row representing a different type of Statistic. The rows are:

  • Events—The Events row shows the Total number of events that have occurred in the database, the Current number of events being processed, and the highest number of events that have been processed simultaneously (the Peak number of events).
  • Event Clients—The Event Clients row shows the Total number of clients that receive events from the server. It also shows the Current number of clients that are receiving events, and the highest number of clients that have been receiving events at the same time (the Peak number of events).
  • Data Interest Clients—The Data Interest Clients row shows the Total number of clients that receive interest references from the server (for more information on interest, see Interest). It also shows the Current number of clients that are receiving interest references, and the highest number of clients that have received interest references at the same time (the Peak number of events).
  • Config Interest Clients—The Config Interest Clients row shows the Total number of clients that are receiving configuration data from the server. It also shows the Current number of clients that are receiving configuration data, and the highest number of clients that have received configuration data at the same time (the Peak number of events).
  • Object Updates—Shows the Total number of items that have been updated via a client connection, the Current number of items being updated via a client connection, and the highest number of items that have been updated via a client connection at a single time (the Peak number of updates).
  • Object Sinks—The Object Sinks row shows the Total number of client connections that are used for updates, the Current number of client connections that are being used for updates, and the highest number of client connections that have been used for updates at a single time (the Peak number of object sinks).

The server uses an object sink to transfer the updates to the clients. This information can be used by Schneider Electric software engineers to determine the cause of unexpected performance and update issues.


Server Status Tool Guide - File Statistics (Database Status Information)

File Statistics

The File Statistics category provides status information about the database configuration and data files. It is especially useful for establishing whether the server is able to flush data to disk correctly (indicated by the Status value).

The file statistics information for the database is categorized as:

  • Id—Identifies the type of data that is in the database. The types of data are:
  • Metadata—Configuration data for any custom fields.
  • Structure—The database hierarchy and the relative position of database items in the hierarchy.
  • Config—Configuration data that defines how the system works. If your system has multiple configuration files (as the number of items on your system exceeds the limit of a single configuration file), there will be multiple Config entries - one for each configuration file. Each configuration file has a unique 8 character hexadecimal coded identifier, for example, file 1 is 00000001 and file 10 is 0000000a.
  • Data—Values for the items in the database. If your system has multiple data files there will be multiple Data entries - one for each data file. Each data file has a unique 8 character hexadecimal coded identifier, for example, file 1 is 00000001 and file 10 is 0000000a.
  • Archive—The Archive Index.
  • File—Only applicable to the Config and Data Ids, this shows the identification number of the configuration and data files.
  • Flush Pending—Indicates whether the data has been save on the server's hard disk. This is referred to as a 'flush'. The Flush entry is:
  • Yes—The data is due to be saved on the hard disk (it has not been saved yet).
  • No—The data has been flushed to the hard disk.
  • Last Save—The time stamp for the latest save of the data.
  • File Size—The size of the database file.
  • Save Time—The amount of time (in milliseconds) required to save the database to memory.
  • Flush Time—The amount of time (in milliseconds) required to save the memory image to disk.
  • Updates—The number of times that data has been 'flushed' i.e. saved to the hard disk.
  • Status—Indicates the state of each file. The possible states are:
  • Ok—The file or files are of the correct type and in the expected location.
  • Missing—The expected file or files cannot be found in the location specified in the Server Configuration Tool’s Locations settings. This is typically because the incorrect location has been set or the file or files have been deleted from the location.
  • Skipped—The database files are saved in a particular sequence: Metadata first, then the Structure, then the Config, and then the Data. If ClearSCADA is unable to save a file or files, any files that are to be saved subsequently in the sequence are skipped (ClearSCADA cannot save the subsequent files if it does not have the information in the earlier files).
  • Load Failed: Unsupported Version Number—The file(s) could not be loaded as the file is in an unrecognized format (its version number is not supported by the version of ClearSCADA you are running). This situation can occur when a system has been downgraded (and the files are not compatible with the older version of ClearSCADA).
  • Load Failed: Unsupported Major Version—The file(s) could not be loaded as the file is for a different version of ClearSCADA.
  • Load Failed: Unsupported Minor Version—The file(s) could not be loaded as the file is for the same version of ClearSCADA that you are running, but is for a different release.
  • Load Failed: Not a Config File—The configuration file could not be loaded because the file at the location is not a configuration file.
  • Load Failed: Not a Data File—The data file could not be loaded because the file at the location is not a data file.
  • Load Failed: Token Does Not Match—A batch of files has a unique token, and each of the files in the batch has to have that token. If ClearSCADA attempts to load a file that has a token that does not match that of the batch, the Load Failed: Token Does Not Match status is shown. This situation may occur on systems where synchronization has not completed properly.
  • Load Failed: File ID Does Not Match Filename—Each file has a unique identifier called the File ID which is contained within the file and also embedded in the filename. If the File ID in the file does not match the File ID embedded in the filename, the file cannot be loaded and the File ID Does Not Match Filename status is shown. This can occur when backup files have been manually renamed prior to being loaded back onto the system.

You may also see the following operating system messages as statuses:

  • Move existing file <name> to backup <location> failed
  • Move <name> to <location> failed
  • Create temporary file <name> failed
  • Write temporary file <name> failed
  • Flush temporary file <name> failed
  • Close temporary file <name> failed

Common causes of these types of failures include:

  • The files are set to read only so ClearSCADA cannot write to them
  • The disk being full.

For more information, please refer to the documentation supplied with your operating system.


Server Status Tool Guide - Indices (Database Status Information)

Indices

ClearSCADA database indices are used to provide faster access to specific areas of the database. For example, the point index contains the point data, so you can use it to search through the point data without having to also search through the rest of the database.

Information about the various indices is shown in the Indices category:

The status information for the database indices is shown under these headings:

  • Table—The table in the database to which the index applies.
  • Obj Count—The total number of database items in the index.
  • Access Count—The number of times the index has been used.
  • Total Time—The total CPU time used to search the index.
  • Avg Time—The average CPU time per search.
  • Avg Hit Rate—The average number of 'hits' per search. A 'hit' is a match. For example, if there is a search for analog points, ClearSCADA uses an index of every database point. The hit rate will be a percentage based on the number of matching records in the entire index. So, if there were 100 database points and 48 of them are analog points, the Avg Hit Rate is 48%.

The Indices status information can be used to evaluate the performance of
a ClearSCADA system. Typically, it is used by ClearSCADA engineers to determine whether the indices are appropriate.


Server Status Tool Guide - Interest (Database Status Information)

Interest

The Interest category provides status information about each database interest reference that is currently made between the server and the client(s). A database interest reference is made each time the server sends data to a client.

Each entry in the Interest category represents one interest reference i.e. one set of data that has been sent from the server to the client(s).

The status information is categorized as:

  • Id—The number that ClearSCADA uses to identify the database interest reference.
  • Type—The type of information that is being requested by the client. This can be Config for configuration data or Data for database values, such as 'live' values that are shown on a Mimic or Queries List.
  • Description—A description of the type of database interest reference, for example, SQL Query for a reference relating to a List, SCADAPackModbus for a reference relating to the SCADAPackModbus driver etc.
  • Update Count—The number of updates to the display to which the reference relates. For example, the number of times a Mimic has updated since being displayed.

A rapidly increasing number of updates indicates that the system is very busy, which in turn may indicate a high server load (see Diagnose Client Performance Problems).

  • Details—Information about the source of the data. This is either a reference to the database class that contains the configuration information or is one or more numbers—the numbers are only shown when the Type is Data and they indicate the Id numbers of the items for which data is being requested.


Server Status Tool Guide - Latest System Calls (Database Status Information)

Latest System Calls

The Latest System Calls category provides status information about the most recent system calls that have been executed.

Each entry in the Latest System Calls category represents one system call i.e. one system command that has been executed by ClearSCADA.

The status information is categorized as:

  • Id—The number that ClearSCADA uses to identify the system call reference.
  • State—The state of the system call. This can be:
  • Succeeded—The system call has executed. ClearSCADA executed the command successfully and as expected.
  • Executing—The system call is in the process of being executed.
  • Queued—The system call is waiting to be executed. It cannot be executed immediately as another system call is in process. The system call will continue to be queued until the time out period is reached, at which point it will become Timed Out and will be aborted. The time out period is defined in the System Calls section of the ClearSCADA Server Configuration Tool (see System Calls Settings in the ClearSCADA Guide to Server Administration).
  • Timed Out—The system call cannot be executed because it has been queued for the time out period (see System Calls Settings in the ClearSCADA Guide to Server Administration). This often occurs when another system call requires user action, for example, opening an application such as Notepad requires the user to close the application before the system call is deemed to have completed. So, if the Notepad window has not been closed, any other system calls will be queued and cannot be executed.
  • Failed—The system call cannot be executed. If you have a failed system call, you should check that the Windows user account being used to run the system call has Read access for the executable file (.exe) that is triggered by the system call. You should also check that the syntax and path defined for the system call (in the system call item's configuration) are correct.
  • Unknown—There has been an internal ClearSCADA error. Please contact Schneider Electric for assistance.
  • Command—The command that is performed when the system call is executed. This matches the command that is entered in the configuration of the corresponding System Call database item.
  • Add—The date and time at which the system call was queued.
  • Start—The date and time at which the execution process for the system call began.
  • End—The date and time at which the execution process for the system call completed.
  • Delay—The amount of time between the system call being added and the system call being executed.
  • Execution—The amount of time taken to complete the execution of the system call.


Server Status Tool Guide - Queued System Calls (Database Status Information)

Queued System Calls

The Queued System Calls category provides status information about the system calls that are waiting to be executed (they have been triggered to be executed, but cannot be executed immediately as other system calls are still in progress).

Each entry in the Queued System Calls category represents one system call i.e. one system command that is waiting to be executed by ClearSCADA.

The status information is categorized as:

  • Id—The number that ClearSCADA uses to identify the system call reference.
  • Command—The command that is performed when the system call is executed. This matches the command that is entered in the configuration of the corresponding System Call database item.
  • Time—The time at which the execute command was triggered for the system call.
  • Waiting—The amount of time the system call has been in the queue i.e. waiting to be executed.


Server Status Tool Guide - Reference Field Indices (Database Status Information)

Reference Field Indices

Many reference fields in the ClearSCADA database are indexed. The indices are used internally to provide a record of the references between database items (such as the references between Group Instances and their Group Templates). Indices also allow for faster queries of indexed fields, as the query can be performed on an index rather than the entire database.

The Reference Field Indices category on the Server Status Tool shows which fields are indexed, and provides information about the number of target and source fields and the names of each index.

The information in the Reference Field Indices category can be useful when investigating the cause of queries that are performing slower than expected—the slower return time may be due to the query being performed on reference fields that are not indexed.

The status information is categorized as:

  • Name—The name of the index.
  • Source Fields—The database fields that are included in the index. This information is useful as it allows you to see which database reference fields are included in the index.

When an indexed referenced is created or changed in any of the listed fields, the index is updated. This allows the index to have an up-to-date list of the relevant references.

  • Target Object Count—The total number of ‘target’ database items. A ‘target’ database item is an item that is referenced by a ‘source’ (the ‘source’ item has a field that references the ‘target’ database item).

For example, if a Group Instance refers to a Group Template, the Group Template is the ‘target’ and the Group Instance is the ‘source’. So, if there are 2 Group Templates and both templates are referenced by 6 Group Instances, the Target Object Count for the InstanceTemplateId index is 2.

  • Source Reference Count—The total number of database items that have a field that is:
  • included in the index

and

  • references another database.

For example, if a Group Instance refers to a Group Template, the Group Instance is the ‘source’ and the Group Template is the ‘target’. So, if there are 2 Group Templates and both templates are referenced by 6 Group Instances, the Source Reference Count for the InstanceTemplateId index is 12. This is because the Group Instances have fields that are included in the index and these fields reference one of the two Group Templates.

  • Memory Usage—The total amount of memory used to store the index.


Server Status Tool Guide - Searches (Database Status Information)

Searches

The Searches category contains information about the current search requests for data in the database. The searches information can be used to help determine the cause of slow client response.

If a client is slow to respond to a search, the cause may be:

  • An inappropriate search, for example, a search for every point in a huge database.
  • A network problem such as a failed connection between the client and server.
  • Lack of resources such as memory, CPU, etc., at the client or the server.

The Searches information allows you to determine if the latest search was completed quickly—if so, the search is suitable and the problem is being caused by a lack of resources or a network problem.

By examining the number of searches, you can determine the level of demand being placed on the server or client. If the number of searches is high and many of the searches are taking a long time to complete, there may be a high demand on the available resources. In this situation, we recommend that you contact
Schneider Electric.

The Searches category provides the following information for each search:

  • Id—The unique identifier of the search.
  • Desc—A description of the thread used for the search.
  • Req Table—The table that contains the data that is being requested for the search.
  • Index Table—The nearest indexed table in the hierarchy. Only a selected number of tables are indexed in the database structure. The Index Table value indicates the nearest indexed table to the requested table in the hierarchy. The Index Table is cannot be lower than the requested table in the hierarchy.
  • Total—The total number of records searched for the query.
  • Hit Count—The total number of records with data that matched the criteria for the query.
  • Time—The length of time taken to process the search.


Server Status Tool Guide - Users (Database Status Information)

Users

The Users category provides status information about the user accounts on a system.

The status information for the user accounts is categorized as:

  • Id—The number that is used by ClearSCADA to identify the user account.
  • Name—The name that has been allocated to the user account. For custom user accounts, the name is defined when the user account is configured. Other account names are defined within the ClearSCADA software, for example, Guest.
  • Enabled—Indicates whether the User account is Enabled or Disabled. A user account can be configured to be enabled (available for use) or disabled (the user account exists in the database but users cannot log on via the account) by using the Account Enabled setting on the User Form.
  • Links—The number of links that are being used by the client on which the user account is being used (is logged on).
  • Stby ViewX, Stby Web and Stby Other—The various Stby columns indicate the number of links between a system server and the client on which the user account is currently being used. The Stby ViewX columns indicate the number of links between a system server and ViewX clients, the Stby Web columns show the number of links between a system server and WebX clients, and the Stby Other columns display the number of links between a system server and any other type of client (i.e. non-ViewX and non-WebX client, such as a Third Party OPC client).

The numbers after each Stby column relate to a specific server in the server architecture. For example, Stby ViewX 4 relates to ViewX clients that have links to the server that is recognized as Standby 4 (which is a permanent standby - either Permanent Standby C or Permanent Standby D, depending on the server architecture).

Further Information

Server Architectures: see System Architectures in the ClearSCADA Guide to Server Administration.

User Account Configuration: see User Accounts in the ClearSCADA Guide to Security.


Server Status Tool Guide - Server Status Information

Server Status Information

The Server Status Tool provides status information that is organized into groups of categories, each of which contains sub-categories. The Server group provides status information about the server on which you are using the Server Status Tool and it contains the following sub-categories:

  • Advise Threads—provides status information about the links from the server to a client
  • Advises—provides status information about each server advise connection between the server and clients
  • Clients—provides status information about each client that is connected to the server. The number of clients varies according to the size of your ClearSCADA system
  • Connected Workstations—provides status information about each workstation that is connected to the server. A workstation is a client and is identified by its Workstation ID.
  • Link Threads—provides status information about each connection between the client(s) and the server
  • Links (Server)—provides status information about each link from a client to the server.


Server Status Tool Guide - Advise Threads (Server Status Information)

Advise Threads

The Advise Threads category provides status information about the threads that are used to service the Server Advises (links from the server to a client).

There is an entry for each advise thread, and the entries are categorized as:

  • Id—A unique number that is allocated by ClearSCADA to identify the thread.
  • ThreadId—A unique number that is allocated by the operating system to identify the thread.
  • Advises—Indicates the number of server advises that are serviced by the thread.

The number of threads varies according to the size of your system. For example, small systems may have 1 to 3 threads, whereas larger systems can have many more.

Typically, the Advise Threads information is used to detect possible connection problems (the number of threads can indicate this):

  • On a small system, if the number of threads gradually increases above 3 and continues to increase, this indicates that there may be a connection problem.
  • On a large system, if the number of threads increases to above 50 or 60, this indicates that there may be a connection problem (unless the system is a very large system).

If you suspect that there is a connection issue, please contact Schneider Electric.


Server Status Tool Guide - Advises (Server Status Information)

Advises

The Advises category provides status information about each server advise connection between the server and clients. The server advise connections are used to allow the server to send unsolicited messages to the clients.

The status information for each server advise connection is categorized under these headings:

  • Id—The identification number that has been allocated to the server to client connection by ClearSCADA.
  • Type—Indicates whether the advise connection is an Outbound connection (server to client) or an Inbound connection (client to server).
  • Remote Addr—The address of the remote (client) end of the server advise connection. The syntax for the address is:

<IP address>:<port>

For example, 10.1.5.7:5000

  • Local Addr—The address of the local (server) end of the server advise link. The syntax is the same as the syntax for the Target Addr.
  • Status—Indicates the present condition of the server advise connection. This can be:
  • Idle—The server advise is connected and is available for use (but is not currently being used)
  • Advise Pending—The server advise has an active Event queue and is in the process of being established. This status should only be displayed momentarily when the server advise connection is first established.
  • Connecting—The server advise is in the process of trying to connect to the client. If the server advise remains in this state, it means that the server advise is continuously trying to connect but is unsuccessful. This can be due to a network failure or a firewall being incorrectly configured (see the ClearSCADA Guide to Client Administration for more information).
  • Sending Events—The server advise is currently being used to send an unsolicited message to a client.
  • Closing—The server advise is in the process of closing down. This occurs as part of the shut down procedure when the client disconnects from the system.
  • Backoff—The amount of time that the server is waiting during the current backoff period. Under normal working conditions, the Backoff is 0.

On systems where the server connects to a client via a network, there is a greater possibility of the server being unable to connect to the required client due to abnormal conditions on the network. The Backoff feature stops the server from making excessive re-connection attempts that could cause further problems on the network.

If a server is unable to connect to a client due to abnormal network conditions, it will wait for a set amount of time before it attempts to reconnect. If the re-connection attempt is unsuccessful, the server will wait for a longer amount of time before making another re-connection attempt. This amount of time is called the Backoff period and it is double the amount of time of the previous connection delay. For example, if a connection attempt was made after a delay of 2 minutes and the connection was unsuccessful, there would be a backup delay of 4 minutes before the next re-connection attempt.

The maximum Backoff time is 8 minutes. If the re-connection cannot be made after 8 minutes, the server will continue to make re-connection attempts every 8 minutes.

  • Up Time—The amount of time for which the link has been connected, in the form hh:mm:ss (where h is hour, m is minute, and s is second).
  • Idle Time—The amount of time for which the link has been connected but not in use.
  • Links—The number of connections that are made via the server advise.
  • Evt Pend—The number of unsolicited updates waiting to be sent from the server to the client.
  • Evt Max—The maximum permitted number of unsolicited updates that can be sent from the server to the client.
  • Evt Sent—The total number of unsolicited updates that have been sent from the server to the client. This indicates the previous load on the connection.
  • Data Sent—The total amount of compressed data sent to the client. This is the actual amount of data transmitted across the network.
  • Content Sent—The total size of the data sent to the client before compressing.
  • % Compressed—The amount by which the data transmitted from the server to the client could be compressed. For example, 90% compression means that the actual transmitted data was compressed to 1/10 of its original size.

You should pay particular attention to the Status and Evt entries. If your system is working correctly, the Status is — and the Evt is 0.

You should also pay attention to the Backoff entry. If this shows anything other than 0, there may be abnormal network conditions that mean the server is unable to connect to the client successfully.

For more information, see Server to Client Link Problems.


Server Status Tool Guide - Clients (Server Status Information)

Clients

The Clients category provides status information about each client on the server. The number of clients varies according to the size of your system.

Typically, the Clients category is used to check that clients have valid licenses (they will be unable to connect to the server if they have invalid licenses). It is also used to determine which clients have a connection to the server.

The status information for each client is categorized under these headings:

  • Id—The identification number that has been allocated to the client by ClearSCADA.
  • Address—The IP address and session number of each client.

If the ViewX application is running on the client PC, the session number is 0.

If the ViewX application is running on the server and is being accessed by clients via Citrix, Microsoft Terminal Services or Remote Desktop, the session number is a unique number. The unique session number allows you to identify each client that is accessing the ViewX that is running on the server.

  • Count—The number of connections between the client and the server.
  • Up Time—The amount of time since the client connected to the server.
  • Licensed—Indicates whether the license being used is at the Client or Server. If the status is No, there isn't a valid license at the server or client.
  • Type—Indicates the type of client. This can be ViewX, OPC, Data Access (ODBC, SQL etc.), or Unknown (if the client is none of the other types).


Server Status Tool Guide - Connected Workstations (Server Status Information)

Connected Workstations

The Workstation Name feature allows a single client PC to be allocated a unique name called the Workstation ID. The Workstation ID is used to identify the client along with its IP address. It allows alarm responses to be restricted to a specific client PC (only users that log on to the client with the required Workstation ID can respond to the alarms).

You can use the Server Status Tool to view status information about the clients with Workstation IDs that are currently connected to the server. The status information is shown on the Connected Workstations section of the Server category.

The Connected Workstations status information is categorized as:

  • Name—The name of the connected work station. The workstation name is defined in the configuration of the client. For more information, see the ClearSCADA Guide to Client Administration.
  • Client Id—The unique identity of the client, which usually consists of a combination of the client’s IP address and the session ID.

If the ViewX application is running on the client PC, the session ID is 0. If the ViewX application is running on the server and is being accessed by clients via Citrix, Microsoft Terminal Services or Remote Desktop, the session ID is a unique number. The unique session ID allows you to identify each client that is accessing the ViewX that is running on the server.

  • Local—Indicates whether the named client (shown in the Name column) is connected to the server on which you are running the Server Status Tool. The entry will be either Yes or No.
  • Standby 0—If you are using the Server Status Tool on the server that is Main, the Standby 0 column indicates whether the named client is connected to the first or only Standby server (Yes or No).

If you are using the Server Status Tool on a Standby server, the entry is blank (“-”).

If your system does not have a Standby server, the entry is No.

  • Standby 1—If you are using the Server Status Tool on the server that is Main, the Standby 1 column indicates whether the named client is connected to the second Standby server (Yes or No). The second Standby server could be a Permanent Standby server, depending on your system architecture.

If you are using the Server Status Tool on a Standby server, the entry is blank (“-”).

If your system does not have a second Standby server, the entry is No.

  • Standby 2—If you are using the Server Status Tool on the server that is Main, the Standby 2 column indicates whether the named client is connected to the third Standby server (Yes or No). The third Standby server is a Permanent Standby server (it may be the first or second Permanent Standby server in your system, depending on the system architecture).

If you are using the Server Status Tool on a Standby server, the entry is blank (“-”).

If your a system does not have a third Standby server, the entry is No.

  • Standby 3—If you are using the Server Status Tool on the server that is Main, the Standby 3 column indicates whether the named client is connected to the fourth Standby server (Yes or No). The fourth Standby server is a Permanent Standby server (it may be the second or third Permanent Standby server in your system, depending on the system architecture).

If you are using the Server Status Tool on a Standby server, the entry is blank (“-”).

If your a system does not have a fourth Standby server, the entry is No.

  • Standby 4—If you are using the Server Status Tool on the server that is Main, the Standby 4 column indicates whether the named client is connected to the fifth Standby server (Yes or No). The fifth Standby server is a Permanent Standby server (it may be the third or fourth Permanent Standby server in your system, depending on the system architecture).

If you are using the Server Status Tool on a Standby server, the entry is blank (“-”).

If your a system does not have a fifth Standby server, the entry is No.


Server Status Tool Guide - Link Threads (Server Status Information)

Link Threads

The Link Threads category provides status information about each connection between the client(s) and the server.

The status information for each client is categorized under these headings:

  • Id—A unique number that is allocated by ClearSCADA to identify the thread.
  • ThreadId—A unique number that is allocated by the operating system to identify the thread.
  • Clients—Indicates the number of server clients that are serviced by the thread.
  • Requests—Indicates the number of requests that are being made via the thread.

The number of threads varies according to the size of your system.

You can use the Requests information to determine how busy the system is—if the number of requests is rapidly rising, then there may be an overload on the system and your system's performance will be affected. If your system appears to be suffering from slow performance, please contact Schneider Electric.


Server Status Tool Guide - Links (Server) (Server Status Information)

Links (Server)

The Server Links category provides status information about each link from a client to the server.

The status information is categorized as:

  • Id—A unique number that ClearSCADA uses to identify the link.
  • Source—The source address of the client that is using the link.
  • Client Version—The version number of the software that is installed on the client that uses the link.
  • Effective Link Version—The version of the client-server protocol that is used by the link. This can be affected by three factors:
  • The protocol version of the client that is connected to the link
  • The protocol version of the server
  • The protocol version that the server is emulating

The effective link version matches the lowest version of the three different version numbers. For example, if the client version is the lowest version number, the Effective Link Version will use the same version as the client.

  • Type—The type of communications that are sent via the link. These can be:
  • Client—The link is being used to send a request that relates to configuration and database management data that is not managed by the other types of ClearSCADA type link.
  • Standby—The link is being used to transfer a request from the main server to a standby server.
  • StandbySink—The link is being used to transfer a request from a standby server to the main server.
  • Driver—The link is being used to transfer a request made via one of the ClearSCADA drivers, such as the SCADAPackModbus driver.
  • OPCDA and OPCDAGroup—The link is being used to transfer requests for OPC current data such as values for animated Mimics etc.
  • OPCAE and OPCAEEventMgt—The link is being used to transfer requests for OPC Alarm and Event data.
  • OPCHDA—The link is being used to transfer a request for OPC historic data.
  • QPTABLE—The link is being used to transfer a request made by using an SQL query.
  • OPCAEBrowse—The link is being used to transfer a request made for the OPC alarm and event interface.
  • OPCHDABrowse—The link is being used to transfer a request for the OPC historic interface.
  • ClearSCADABrowse—The link is being used to transfer a request made for the ViewX interface.
  • Status—Indicates the present condition of the link. This can be:
  • Start
  • OnOpenWaitforDBlock
  • OnOpenWithDBlock
  • OnOpenNoDBlock
  • AddToThread
  • Idle
  • WaitForDBlock
  • Processing
  • SendingReply
  • RemoveFromThread
  • OnCloseWithDBlock
  • OnCloseNoDBlock
  • Close

Start, OnOpenWaitforDBlock, OnOpenWithDBlock, OnOpenNoDBlock, and AddToThread are phases in the connection sequence. When the link is not being used, it is Idle. If a request is made, for example, a request for data, the server link goes through the request phases of WaitForDBlock, Processing, and SendingReply before returning to the Idle state. When the link is being closed, it goes through the phases of the closing sequence: RemoveFromThread, OnCloseWithDBlock, OnCloseNoDBlock, and finally, Close.

Schneider Electric engineers can use this status information when investigating potential software issues relating to unresponsive clients.

  • Flags—Indicates the type of activity being undertaken by the link. The Flags status shows one of the following:
  • P—The link is being used to process a request
  • W—The link has been used to process a request and is waiting to send the reply
  • S—The link is being used to send the reply to a request.
  • Advise—Indicates whether the client has performed an advise on the link (Yes or No). Each client sends an advise to the server as part of the server-client connection establishment process.
  • Client—The unique identification number of the client advise. This can be used to match the server links information against data contained in the DBClient log files.
  • Curr Req—The unique code number used by Schneider Electric engineers to identify the type of request.
  • Requests—The total number of requests sent via the link.
  • Up Time—The amount of time for which the link has been connected.
  • Idle Time—The amount of time that has elapsed since the latest request.
  • Last Req—The code and duration of the most recent request. The code can be used by Schneider Electric engineers to determine the cause of impaired performance (when caused by excessive request times). The code is the same as the Curr Req.

This information is used in conjunction with the Longest Req code and time.

  • Longest Req—The code and duration of the longest request (this should be less than 1000mS). The code can be used by Schneider Electric engineers to determine the cause of impaired performance (when caused by excessive request times). The code is the same as the Curr Req.
  • Client Name—The name of the client application or process that is using the link, for example, the name of a driver or the name of a ViewX component (including the client on which it runs).
  • User Name—The name of the User account that is logged on to the client that is using the link. This can be a custom User account, a built-in User account, or an internal User account such as Driver. This provides an indication of which user is logged on to each client.
  • Locale—The Windows locale of the client that is using the link, for example, English (United Kingdom).
  • TZ Bias—The offset of the user’s time zone (in minutes) from UTC. This does not include any daylight saving time adjustments.
  • Licensed—Indicates whether the link has a valid license (Yes or No).
  • Workstation Name—The workstation name that has been given to the client (this is blank if a work station name has not been configured). The work station name is used with the Set Responsibility action (see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection).
  • Client ID—The unique identifier of the client (the client’s IP address) and a session number. The session number is 0 unless ViewX is running under Citrix, Microsoft Terminal Services or Remote Desktop, in which case, the number is a unique session number. The unique session number is used by the server when enforcing the license.
  • Data From Client—The total amount of compressed data received from the client. This is the actual amount of data transmitted across the network.
  • Data To Client—The total amount of compressed data sent to the client. This is the actual amount of data transmitted across the network.
  • Content From Client—The total size of the data received from the client (after the data has been decompressed).
  • Content To Client—The total size of the data sent to the client (after the data has been decompressed).
  • % Compression From Client—The amount by which the data transmitted from the client could be compressed. For example, 90% compression means that the actual transmitted data was compressed to 1/10 of its original size.
  • % Compression To Client—The amount by which the data transmitted from the server could be compressed. For example, 90% compression means that the actual transmitted data was compressed to 1/10 of its original size.
  • Memory Usage—The amount of memory used for the server link.

You should pay particular attention to the number of links in the Server Links category—there should not be an excessive number of links in comparison with the number of clients. You should also check that the Longest Req is generally less than 1000mS.

An excessive number of links or a Longest Req over 1000mS may indicate a high server load, see Diagnose Client Performance Problems.


Server Status Tool Guide - Standby Status Information

Standby Status Information

The Server Status Tool provides status information that is organized into groups of categories, each of which contains sub-categories. The Standby group provides status information about each back up server (standby server) in a multi-server system. The Standby group contains the following sub-categories:

  • Counters—provides performance statistics about each Main-Standby link
  • Historic Transfer—provides detailed information about the transfer of historic data from the main server to the standby server(s) in a multi-server system
  • ICMP Polls—shows the status of ICMP 'pings' between the main and standby servers
  • Links (Standby)—provides status information about the standby server(s) synchronization with the main server
  • Polls—use to see whether the server on which you are working can access the other server(s) and if so, what state it deems the other server(s) to be in.

NOTE: The sub-categories that are available to you will vary depending on whether you are using the Server Status Tool on the ‘Main’ server or on a ‘Standby’ server.


Server Status Tool Guide - Counters (Standby Status Information)

Counters

The Counters category provides performance statistics about each Main-Standby link.

  • Id—Indicates the index number of the standby server. For each standby server, there are three rows of data (First for the first synchronization, Total for all synchronisations, and Last for the latest synchronization).
  • Node Name—The IP address or Node Name of the standby server.
  • Reset—The time and date of the counter reset i.e. when the counter began.
  • Count—The number of synchronisations. This is 1 for the First and Last rows.
  • Time—The time taken for the synchronization pass (in seconds).
  • Metadata—The number of metadata field (custom field) configuration changes that have been transferred from the Main server to the Standby server.
  • Structure—The number of database structure changes that have been transferred from the Main server to the Standby server.
  • Agg—The number of aggregate configuration changes that have been transferred from the Main server to the Standby server.
  • Cfg—The number of configuration changes that have been transferred from the Main server to the Standby server.
  • Data—The number of data changes that have been transferred from the Main server to the Standby server during the synchronization. Data changes are alterations to the data that is stored on disk.
  • Dyn—The number of dynamic data changes that have been transferred from the Main server to the Standby server during the synchronization. Dynamic data changes are alterations to the data that are only available in memory (they are not stored to disk).
  • Int—The number of interest changes that have been transferred from the Main server to the Standby server.
  • Evt—The number of events that have been transferred from the Main server to the Standby server.
  • His File—The number of historic files that have been transferred from the Main server to the Standby server.
  • His Rec—The number of historic records that have been transferred from the Main server to the Standby server.
  • JnlFile—The number of Event Journal files that have been transferred from the Main server to the Standby server.
  • JnlRec—The number of Event Journal records that have been transferred from the Main server to the Standby server.

The Counters data is useful for monitoring the amount of data that is being transferred to the standby server(s). If your system is affected by slow performance, this may be caused by a high amount of configuration changes or historic data being transferred to the standby server.


Server Status Tool Guide - Historic Transfer (Standby Status Information)

Historic Transfer

The Historic Transfer category provides detailed information about the transfer of historic data from the main server to the standby server(s) in a multi-server system. It is particularly useful for checking the type and amount of historic data that is being transferred. Systems that transfer large amounts of historic data may have slower performance and could possibly be reconfigured to store and transfer historic data more efficiently.

The historic transfer status information is categorized as:

  • Id—Identifies the type of data and the server. This takes the form of a number followed by the data type.

The number is 0, 1, or 2 depending on the number of standby servers in your server arrangement:

  • The standby server in a Hot Standby Pair is 0.
  • The standby servers in a Triple Standby arrangement are 0 and 1.
  • The standby servers in a Hot Standby Pair with Permanent Standby are 0, 1, and 2.

The type of data is:

  • Event—ClearSCADA events that are stored in the Event Journal.
  • Raw—Historic data that has been received from points.
  • Modified—Historic data that has been modified by operators or engineers.
  • Annotation—Annotations that have been inserted by operators or engineers.
  • Node—The Internet Protocol (IP) address of the standby server.
  • Remote Life—The historic life time configured for the remote server. This is the amount of time for which historic data is stored on the remote server. The Remote Life matches the Keep On-line For setting on the other server in the server setup (not the server on which you are working).
  • Local Life—The historic life time configured for the local server. This is the amount of time for which historic data is stored on the local server. The Local Life matches the Keep On-line For setting on the server on which you are working.
  • Sync Life—The historic life time for synchronization. This indicates how much historic data is synchronized between the Main server and Standby server. The Sync Life matches the Archive After settings on the Main server and Standby server.
  • %Sync—Indicates the status of the historic data synchronization as a percentage (100% means that the synchronization is complete).
  • Record Size—The size (in bytes) of the records.
  • Total Stream—The number of streams used to transfer the directories for historic and event data. When the historic data and event data is transferred, it is separated into directories. Each directory requires approximately 1 stream.
  • Total File—The total number of files for the historic data. There is 1 file per granule (a period of time, for example, a week).
  • Total Record—The total number of historic records that are stored on the hard disk of the main server. If this number increases rapidly, there may be a high server load (see Check for High Load on a ClearSCADA Server).
  • Curr Data—The number of historic data records pending transfer from the main server to the standby server.
  • Curr Upd—The number of historic update records pending transfer from the main server to the standby server.
  • Curr Del—The amount of historic deletions pending on the standby server.


Server Status Tool Guide - ICMP Polls (Standby Status Information)

ICMP Polls

The ICMP Polls category shows the status of ICMP 'pings' between the main and standby servers. This information is useful when investigating the connections between the ClearSCADA servers—if the ICMP ‘pings’ are unsuccessful, this would indicate that ClearSCADA could not transmit the ‘pings’, which may be due to abnormal network conditions or because the other server is not running ClearSCADA.

The ICMP Polls category provides the following information:

  • Id—A unique identifier for the ICMP poll. This is used internally.
  • Address—The IP address or name of the computer that is being polled.
  • IP Addr—The IP address for the poll. This is the address to which the 'ping' is sent.
  • Status—Indicates the current state of the poll. This can be Healthy which means the poll is being sent correctly or Failed which means the poll could not be sent (there may be abnormal network conditions).
  • Poll—Indicates whether a poll is currently in progress. Usually, the Poll entry will be No as polls complete very quickly.
  • Good—The number of good, successful polls.
  • Bad—The number of bad, unsuccessful polls.
  • Ident—The identifier for the poll. This is used in conjunction with the sequence number of the poll to differentiate between each poll.
  • Seq—The sequence number of the poll. This is used in conjunction with the identifier number to differentiate between each poll.


Server Status Tool Guide - Links (Standby) (Standby Status Information)

Links (Standby)

The Standby Links category provides status information about the standby server(s) synchronization with the main server. This allows you to check that each standby server updates correctly.

The standby links status information is categorized as:

  • Id—A number that identifies the server in the server standby arrangement. This can be 0, 1, or 2 depending on the number of standby servers in your server arrangement:
  • The standby server in a Hot Standby Pair is 0.
  • The standby servers in a Triple Standby arrangement are 0 and 1.
  • The standby servers in a Hot Standby Pair with Permanent Standby or Triple Standby with Permanent Standby are 0, 1, and 2.
  • Node Name—The IP address of the standby server. The IP address is the address that has been assigned to the network card in the server.
  • IP Address—The Internet Protocol address of the standby server.
  • Port—The address for the port that is being used for data transfer between the Main server and the Standby server.
  • Xfer Flags—Provides information about the phases of the transfer between the Main and Standby servers. Each transfer phase is represented by a letter (or a - if the phase has not completed correctly).

The possible entries for the transfer phases are:

  • Phase 1:
  • M—Indicates that the link is a Main-Standby link.
  • D—Indicates that the link is a Duty Duty link.

There is one entry for Phase 1, so M or D (or - if there if phase 1 cannot complete correctly).

  • Phase 2:
  • 0—Indicates that there are no links available.
  • 1—Indicates that the Main link is available.
  • 2—Indicates that the Standby link is available.
  • 3—Indicates that both the Main link and the Standby link are available.
  • Phase 3:
  • R—Indicates that the link is running. While the link between the Main and Standby server is running, the Main server will try to update the Standby server continuously.
  • Phase 4:
  • A—Indicates that the transfer of aggregates has been successful.
  • Phase 5:
  • S—Indicates that the transfer of the database structure has been successful. The database structure is the hierarchy of group names, item names etc.
  • Phase 6:
  • C—Indicates that the transfer of configuration data has been successful. The configuration data includes Mimic objects, field entries on Forms etc.
  • Phase 7:
  • E—Indicates that the transfer of 'live' event data has been successful. The 'live' event data includes the information that is shown in the Alarm Banner and in the ad hoc Event List. This does not include historic events.
  • Phase 8:
  • V—Indicates that the Main server considers the Standby server to be valid. When a change is made, for example, a database item is renamed, the phase 8 status becomes invalid for a short time. The status should revert to V when the server is next updated.
  • Phase 9:
  • L—Indicates that the Main server has queried the historic life of the Standby server to determine how much historic data is available.
  • Phase 10:
  • H—Indicates that the historic data has been transferred successfully. Historic data includes historic data for points.
  • Phase 11:
  • J—Indicates that the historic event journal data has been transferred successfully. The historic event journal data is the data that is shown on Event Lists.
  • Phase 12:
  • K—Indicates that the historic files have been transferred successfully. The historic files are those that are generated for reports etc.
  • State—Indicates the state of the link between the Main server and the Standby server. The possible states are:
  • Start—The process for transferring data between the Main server and Standby server has begun.
  • Transfer Structure—The transfer of the database hierarchy is in progress.
  • Query Config CRCs—The Main server is using a Cyclic Redundancy Check to determine which database items need to be transferred. Only those database items that have been updated or modified are transferred.
  • Transfer Aggregates—The transfer of aggregates is in progress.
  • Enable Global Events—The Main server is in the process of recording the alarms and events that are occurring, so that they can be transferred later.
  • Transfer Objects—The transfer of database items is in progress.
  • Set Config Valid—The Main server is in the process of checking that the database changes are valid.
  • Transfer Global Events—The transfer of the alarms and events that have been recorded by the Main server is in progress.
  • Set Journal Stream Size—The Main server is in the process of checking that the Standby server's Event Journal has the same configuration of the Main server.
  • Query Historic Life—The Main server is in the process of checking the historic life of the Standby server to determine how much data is available.
  • Query Historic—The Main server is in the process of checking the historic data of the Standby server.
  • Transfer Historic—The transfer of historic data is in progress.
  • Query Journal—The Main server is in the process of checking the Event Journal of the Standby server.
  • Transfer Journal—The transfer of data from the Event Journal is in progress.
  • Query Files—The Main server is in the process of checking the data files used for generating reports etc.
  • Transfer Files—The transfer of data files (for reports etc.) is in progress.
  • Set Sync—The server's are being set as synchronized.
  • Idle—The Main server is waiting.

NOTE: The Main server continues to cycle through the various states, checking for updates as required. When changes are detected, the Main server will transfer the altered data.

  • Sync—Indicates whether the standby is fully synchronized with the main server.

If the Sync status is Yes, the standby server is synchronized with the main server.

If the Sync status is No, there is data pending transfer from the main server to the standby server.

  • Flags—Indicates the progress of the standby synchronization. As the synchronization progresses through its various stages, more letters are displayed. The letters (flags) indicate that the corresponding stage is complete.

The possible flags are:

  • M—Main Standby mode.
  • D—Duty Duty mode.
  • R—Standby transfer is running.
  • L—The link to the standby server is established.
  • S—The structure has been transferred to the standby.
  • C—The configuration data has been transferred to the standby.
  • H—The historic data has been transferred to the standby server.
  • J—The Event Journal data has been transferred to the standby server.

The letters are displayed in sequence (M or D first, then R, then L etc.). When J is displayed, the Sync status value should change to Yes.

  • % Cfg Sync—The percentage of configuration data that has been copied and transferred to the standby server. This percentage increases as the synchronization takes place, and the Pend Cfg number decreases.
  • % Data Sync—The percentage of database values and states that have been copied and transferred to the standby server. As the synchronization takes place, the % Data Sync percentage increases, and the Pend Data number decreases.
  • % Dyn Sync—The percentage of dynamic data that has been copied and transferred to the standby server. Dynamic data is data that is stored in the main server but is lost when the main server is shutdown, for example, statistical information such as counts.

As the synchronization takes place, the % Dyn Sync percentage increases, and the Pend Dyn number decreases.

  • Total Obj—The total number of database items in the main server's database that have changed since the main and standby servers were last synchronized. These items need to have their data copied and transferred to the standby server.
  • Pend Cfg—The remaining number of configuration data transfers.
  • Pend Data—The remaining number of database value transfers. Database values include the values and states of database items.
  • Pend Dyn—The remaining number of dynamic data transfers. Dynamic data is data that is stored in the main server but is lost when the main server is shutdown, for example, statistical information such as counts.
  • Pend GEvt—The number of global events (Alarm Banner updates, Event List updates etc.) that have occurred at the same time as the synchronization process.
  • GEvt Max—The maximum number of global events (Alarm Banner updates, Event List updates etc.) that can be stored on the Main server while the synchronization process is in progress.
  • % His Sync—The percentage of historic data that has been copied and transferred to the standby server. As this number increases, the Pend Record number decreases. As the synchronization takes place, the % His Sync percentage increases, and the Pend Record number decreases. If the % His Sync status appears to be stuck, the synchronization process may be unable to complete—see the Sync status for more information.
  • Total Record—The total number of historic/event records in the main server's database. A record is a single event, historic value, annotation, or modified value.
  • Total Bytes—The total size of the records.
  • Pend Record—The number of records that have changed in the main server's database since the last time the main server and standby server were synchronized. These records are waiting to be copied and transferred to the standby server.
  • Pend Bytes—The size of the records that are waiting to be copied and transferred to the standby server.
  • %His File Sync—The percentage of historic files that have been transferred.
  • Total His Files—The total number of historic files that are to be transferred.
  • Pend His Files—The number of historic files that are waiting to be transferred.
  • % Data File Sync—The percentage of non-historic files that have been transferred.
  • Total Data Files—The total number of non-historic files that are to be transferred.
  • Pend Data Files—The number of non-historic files that are waiting to be transferred.
  • Errors—The number of errors that have occurred during the transfer of data between the Main server and Standby server.
  • Last Error State—Provides technical information relating to the latest error. This information can be used by Schneider Electric engineers to determine the cause of the error.
  • Last Error Time—The time and date of the latest error.
  • Last Error—Provides technical information relating to the latest error. This information can be used by Schneider Electric engineers to determine the cause of the error.

As synchronization takes place, the % Cfg Sync, % Dyn Sync, % Data Sync, and % His Sync statuses increase as the synchronization nears completion. These statuses are described later in this section, and when they reach 100%, the Sync status changes to Yes to indicate that the standby servers are synchronized with the main server.

If the % Cfg Sync, % Dyn Sync, % Data Sync, and % His Sync statuses appear to be stuck at a specific percentage below 100%, the servers may be unable to synchronize correctly. To resolve this, you could try and shutdown and restart the standby server(s). For more information, see Start and Stop the System Server in the ClearSCADA Guide to Server Administration.

The speed of the synchronization process varies according to the size of the database, the amount of time that the database has been down (i.e. not running), and the communications path.


Server Status Tool Guide - Polls (Standby Status Information)

Polls

In multiple server systems such as Hot-Standby systems, each server monitors the other servers (up to 2 other servers). You can use the Polls category to see whether the server on which you are working can access the other server(s) and if so, what state it deems the other server(s) to be in. This is useful for checking that the Main and Standby servers can communicate with each other correctly and are able to arbitrate the correct Main and Standby status.

The information that is shown in the Polls category is used by the server as part of the Main-Standby arbitration process.

The standby polls status information is categorized as:

  • Id—The identifier of the path that is used to access the other server(s). There are two paths for each server, for example A1 and A2.
  • Node—The Internet Protocol (IP) address of the other server(s).
  • State—The state of the poll. The state can be:
  • Starting—The poll is beginning. It will attempt to communicate with the other servers.
  • On-line—The other server is on-line. This means that the other server can be contacted and is running ClearSCADA.
  • Offline Pinging—The other server is offline (it doesn't appear to have ClearSCADA running). The server on which you are working is attempting to make contact with ClearSCADA on the other server.
  • Offline—The other server is offline. It can be contacted, but it does not have ClearSCADA running.
  • Unreachable—The other server cannot be contacted.
  • Unreachable Polling—The other server cannot be contacted, but the server on which you are working is making another communications attempt.
  • Remote State—Indicates the status of the server(s). The status can be:
  • 0 Invalid—There is a problem that cannot be categorized by any of the other remote states.
  • 1 Configuration Lost—There are missing database modules (database items may be missing from the configuration).
  • 2 Invalid Configuration—The database is incomplete (following a partial Main-Standby transfer).
  • 3 No Configuration—There is a blank database.
  • 4 Check Configuration—This is a pseudo state to indicate that the database is being checked for completeness. It usually indicates that there is a conflict between the registry settings on the servers (the servers need to have the same registry settings i.e. same server configuration).
  • 5 Start A Unknown B Unknown—The server on which you are viewing the data has started running, and the other servers are in an unknown state (if there is only one other server, Server B will be regarded as Unknown).
  • 6 Start A Unknown B Fail—The server on which you are viewing the data is running, Server A is in an unknown state and server B has failed.
  • 7 Start A Unknown B Standby—The server on which you are viewing the data is running, Server A is in an unknown state and server B is the standby.
  • 8 Start A Unknown B Main—The server on which you are viewing the data is running, Server A is in an unknown state and server B is the main.
  • 9 Start A Fail B Unk—The server on which you are viewing the data is running, Server A has failed and server B is in an unknown state.
  • 10 Start A Standby B Unk—The server on which you are viewing the data is running, Server A is the standby, and server B is in an unknown state.
  • 11 Start A Main B Unk—The server on which you are viewing the data is running, Server A is the main, and server B is in an unknown state.
  • 12 Start A Fail B Fail—The server on which you are viewing the data is running, Server A has failed, and server B has failed.
  • 13 Standby To A, B Fail—The server on which you are viewing the data is the standby to Server A. Server B has failed.
  • 14 Standby To A, B Standby—The server on which you are viewing the data is the standby to Server A and Server B is also a Standby.
  • 15 Standby To A Failed, Arbitrate With B—The server on which you are viewing the data is a Standby to Server A which has failed. The server you are using is arbitrating with Server B to determine which server is Main (i.e. there is a main-main situation).
  • 16 Standby to A Failed, Lost To B, Wait for B—The server on which you are viewing the data is a Standby to Server A, which has failed. The server you are using has lost its remote state to Server B, and is waiting for a response from Server B.
  • 17 Standby To B, A Fail—The server on which you are viewing the data is a standby to Server B. Server A has failed.
  • 18 Standby To B, A Standby—The server on which you are viewing the data is the standby to Server B and Server A is also a Standby.
  • 19 Standby To B Failed, Arbitrate With A—The server on which you are viewing the data is a Standby to Server B which has failed. The server you are using is arbitrating with Server A to determine which server is Main (i.e. there is a main-main situation).
  • 20 Standby to B Failed, Lost To A, Wait for A—The server on which you are viewing the data is a Standby to Server B, which has failed. The server you are using has lost its remote state to Server A, and is waiting for a response from Server A.
  • 21 Main—The server on which you are viewing the data is a Main server.
  • 22 Shutdown—The server on which you are viewing the data is in the process of shutting down.
  • 23 Integrity Check Failed—The integrity check on the server you are using has failed. This usually indicates that you have not installed some of the required drivers.
  • 24 Main Rejected Standby—The Main server rejected the other server as a Standby server due to it having different registry settings (server configuration settings), drivers installed, or a different version of ClearSCADA.
  • 25 Invalid Metadata—The server on which you are viewing the data has invalid (see Extra Database Fields in the ClearSCADA Guide to Server Administration). Typically, this is caused by extra database fields having the same names as other fields.
  • 26 Save Database Fail—The server on which you are viewing the data cannot save the database (it cannot write the ClearSCADA.dat file).
  • 27 Save Journal Fail—The server on which you are viewing the data cannot save the Event Journal data.
  • 28 Save Database and Journal Fail—The server on which you are viewing the data cannot save the database (it cannot write the ClearSCADA.dat file) and cannot save the Event Journal data.
  • 29 Load Database Fail (Build Number)—The server on which you are viewing the data has been loaded with a version of the database that is a later version of ClearSCADA than the build you have installed.
  • Time Went Main—The time stamp for the time and date at which the server(s) last became the Main server. If the server has not been the Main server, the Time Went Main column is Never.
  • Xfer State—The state of the transfer activity. This indicates whether the Main standby server is transferring or is in transition. The possible transfer states are:
  • Stopped—The Main server is not transferring and is not waiting to start or stop.
  • Pend Start—The Main server is preparing to start the transfer process.
  • Running—The Main server is transferring data.
  • Pend Stop—The Main server is preparing to stop the transfer process.
  • Monitor State—The state of the monitor thread (connection):
  • Not Running—The monitor thread is not required and so is not running.
  • Connected—The monitor thread is being used and is connected to the other server(s).
  • Disconnected—The monitor thread is required but the connection cannot be made (this is often due to the server not running).
  • Polls—A count of the number of polls.
  • ICMPs—A count of the number of ICMP ‘pings’ (see see ICMP Polls for more information on ICMP polls).
  • Proxy Req—The number of update requests sent from a Standby server to the Main server.
  • Last Event—The most recent activity on the server. This can be:
  • 0 - Poll
  • 1 - Close
  • 2 - Start Xfer
  • 3 - Stop Xfer
  • 4 - Tx Proxy Req
  • 5 - Tx Proxy Trans
  • 6 - Tx Object Req
  • 7 - Tx LogOnOff Req

The Last Event is 0 - Poll indicates that the connection between the standby server and the Main server is idle. If there are clients connected to the standby server, the Last Event is likely to be a combination of 0 - Poll and any of the other Last Event statuses (except 1- Close) which indicate that the standby has requested the Main server to send data.

  • Event State—Indicates the status of the last event. This can be:
  • Complete—The last event was completed successfully.
  • Start—The last event was started but has not completed. This can indicate that the last event is being performed (in which case, the Event State should soon change to Complete) or abnormal conditions mean that the last event cannot be completed.
  • Event Time—The time stamp at which the last event occurred.
  • Status—A summary of the state of the remote server. The status can be:
  • Unknown—The state of the remote server cannot be determined at the present time
  • Unreachable—The remote server cannot be contacted
  • Offline—The remote server can be contacted, but is not running ClearSCADA
  • Reject—The remote server can be contacted and has ClearSCADA running, but does not recognize the server on which you are working
  • Main—The remote server is on-line and is the Main server
  • Standby—The remote server is on-line and is the Standby server
  • Other—The remote server is on-line and is not Main or Standby.
  • Not Running—The link monitor is not running.
  • Settings—Shows the configuration settings of the poll. This includes:
  • Conn Timeout—The number of seconds the server will wait for a connection to be made.
  • Req Timeout—The number of seconds the server will wait for a response to a request.
  • Compressed/Uncompressed—Indicates whether compression has been enabled for the poll.

The configuration of the poll is defined on the Partners section of the ClearSCADA Server Configuration Tool—see System Architectures in the ClearSCADA Guide to Server Administration.


Server Status Tool Guide - Historic Status Information

Historic Status Information

The Server Status Tool provides status information that is organized into groups of categories, each of which contains sub-categories. The Historic group provides status information about the historic and event data for the server on which you are working, including details of the historic and event searches currently active on clients that are connected to the server. The Historic group contains the following sub-categories:

  • ConfigChangesSearches—provides status information about the searches that are currently requesting data from the configuration changes auditing files.
  • Historian—provides status information about the historic data that is stored on the server
  • Historic Searches—provides information about the searches that are currently requesting historic data
  • Journal Searches—provides information about the searches that are currently requesting event data.


Server Status Tool Guide - ConfigChangesSearches (Historic Status Information)

ConfigChangesSearches

The ConfigChangesSearches category contains information about the searches that are currently requesting data from the Configuration Changes Auditing files. You can use the information to determine if a slow response to a Configuration Changes request is due to a large search or another factor such as abnormal network conditions.

The ConfigChanges Searches category displays the following information:

  • Id—A unique identifier for the search.
  • Desc—A description of the type of search, for example, Query for a search instigated via an SQL query.
  • Object Count—The number of database items for which data has been requested.
  • Object Ids—The unique database number(s) of the item(s) for which data has been requested.
  • Time Filter—The time span for the search. The search only includes records with time stamps within the defined range.
  • Streams—The number of streams searched and the total of streams available for searching. For more information on streams, see Define the Stream Size for Maximum Performance of the Event Journal in the ClearSCADA Guide to Server Administration.

Streams are used by the Event Journal and Configuration Changes Auditing features in the same way. The only difference is the content of the files; the Event Journal files contain a record of various types of activity on the system, whereas the Config Changes files contain more detailed records but only relating to configuration changes.

  • Records Hit—The number of records returned by the search. This is the number of records that match the search criteria and the total number of records that have been searched.
  • Time—The amount of time taken to complete the search.

If the Time Filter only covers a short amount of time and the Time value is high, the configuration of the search query may be incorrect or there may be an unusually high amount of data available for a short time period. We recommend that you attempt to retrieve the required data through a more filtered search. If you are unable to retrieve the date you require, please contact Schneider Electric.


Server Status Tool Guide - Historian (Historic Status Information)

Historian

The Historian category provides status information about the historic data that is being stored. The status information is useful for identifying which points, if any, are logging excess data.

The status for the historic data is categorized as:

  • Id—Indicates the type of historic data. The Id can be:
  • Event—ClearSCADA events that are stored in the Event Journal.
  • Raw—Historic data that has been received from points.
  • Modified—Historic data that has been modified by operators or engineers.
  • Annotation—Annotations that have been inserted by operators or engineers.
  • Suppression—Historic data that relates to suppressed alarms. A historic record is created whenever alarms are suppressed on a point (and also when alarms stop being suppressed on a point). For more information on alarm suppression, see Alarm Suppression in the ClearSCADA Guide to Alarms.
  • His Error—The number of errors per region of historic data. This should be 0. If your system has a number other than 0, this indicates abnormal conditions and you should contact Schneider Electric for assistance.
  • Total Memory Usage—The total amount of memory used to store the records and database information.
  • Record Size—The size (in bytes) of the records.
  • Total Stream—The number of streams used to transfer the directories for historic data. When the historic data is transferred, it is separated into directories. Each directory requires approximately 1 stream.
  • Total File—The total number of files for the historic data. There is 1 file per granule (a period of time, for example, a week).
  • Total Record—The total number of historic records that are stored on the hard disk. If this number increases rapidly, there may be a high server load (see Check for High Load on a ClearSCADA Server).
  • Total Data—The total size (in megabytes) of the historic data.
  • %Flush—The percentage of historic data that has not yet been saved to the hard disk.
  • Flush Record—The number of historic records that have not yet been saved to the hard disk.
  • Flush Data—Indicates the size (in Megabytes) of the data that has not yet been saved to the hard disk.
  • Read Count—The number of file read operations.
  • Write Count—The number of file write operations.
  • %Cache—The percentage of historic data that is stored in the cache. The cache is used to store data that is required by a historic display that is currently in use. For example, if the Event List for a specific item is displayed, the cache is used to store all of the historic data that could be shown on the Event List for that item.
  • Cache Record—The number of historic records that are stored in the cache.
  • Cache Data—The size (in Megabytes) of the historic data that is stored in the cache.
  • Loaded Files—The number of historic files that have been loaded.
  • Locked Files—The number of historic files that are locked in the database (cannot be accessed because they are currently secured for use elsewhere, for example, are being used for a Historic search).
  • Largest File—The size of the largest historic file.
  • Largest File Name—The name of the largest historic file.
  • Flush Error—Indicates the number of historic files that could not be written (‘flushed’) to disk. If this is anything other than 0, there is a problem, and the cause of the problem is indicated in the Error Code column.
  • Error Code—Shows the result of writing data to file on disk. The error code is an operating system error code and uses the syntax <error number> - > <error description>.
  • Error File—The names of the files that have not been written to disk successfully (if any).


Server Status Tool Guide - Historic Searches (Historic Status Information)

Historic Searches

The Historic Searches category contains information about the searches that are currently requesting historic data. You can use the information to determine if a slow response to a historic data request is due to a large search or another factor such as abnormal network conditions.

The Historic Searches category contains the following information:

  • Id—A unique identifier for the search. This is used internally.
  • Desc—A description of the function that is used for the search. This is used internally.
  • Total—The number of historic records that have been searched and have data that matches the criteria set for the search.
  • Time—The amount of time taken to process the search.


Server Status Tool Guide - Journal Searches (Historic Status Information)

Journal Searches

The Journal Searches category contains information about the searches that are currently requesting data from the Event Journal. You can use the information to determine if a slow response to an Event Journal request is due to a large search or another factor such as abnormal network conditions.

The Journal Searches category displays the following information:

  • Id—A unique identifier for the search.
  • Desc—A description of the type of search, for example, Query for a search instigated via an SQL query.
  • Object Count—The number of database items for which data has been requested.
  • Object Ids—The unique database number(s) of the item(s) for which data has been requested.
  • Time Filter—The time span for the search. The search only includes records with time stamps within the defined range.
  • Streams—The number of streams searched and the total of streams available for searching. For more information on streams, (see Define the Stream Size for Maximum Performance of the Event Journal in the ClearSCADA Guide to Server Administration).
  • Records Hit—The number of records returned by the search. This is the number of records that match the search criteria and the total number of records that have been searched.
  • Time—The amount of time taken to complete the search.

If the Time Filter only covers a short amount of time and the Time value is high, the configuration of the search query may be incorrect or there may be an unusually high amount of data available for a short time period. We recommend that you attempt to retrieve the required data through a more filtered search. If you are unable to retrieve the data you require, please contact Schneider Electric.


Server Status Tool Guide - Query Processor Status Information

Query Processor Status Information

The Server Status Tool provides status information that is organized into groups of categories, each of which contains sub-categories. The Query Processor group provides status information about the SQL searches made on clients that are connected to the server on which you are working. The Query Processor group contains the following sub-categories:

  • Latest Queries—shows a list of the most recent queries
  • Largest Queries—shows a list of the queries that required the most processor usage
  • Longest Queries—shows a list of the queries that took the longest amount of time to complete.


Server Status Tool Guide - Latest Queries (Query Processor Status Information)

Latest Queries

The Latest Queries category shows a list of the most recent queries. The columns provide information about each query including:

  • Id—The identifier number allocated to the query connection. The queries are numbered in order (according to the age of the query connection—the oldest connections have the lowest numbers).
  • Time—The time at which the data that is specified in the SQL query was requested.
  • Src—The number of different database tables being used by the connection.
  • SQL—Information about the latest error relating to the Query connection (if any)
  • Parse—The speed at which the parse operation is performed on the SQL query. The speed is in seconds.
  • Verify—The speed at which the verify operation is performed on the SQL query. The speed is in seconds.
  • Optimize—The speed at which the optimize operation is performed on the SQL query. The speed is in seconds.
  • Execute—The speed at which the execute operation is performed on the SQL query. This is performed after the Parse, Verify, and Optimize operations. The speed is in seconds.
  • Exec Count—The number of times the query was executed.
  • Rows—The number of rows returned by the query.
  • Access Paths—The type of optimization that has been used. When the SQL query is requesting a suitable amount of data, the Access Paths entry will be one of the following:
  • Non-Unique by Column
  • Unique by Column
  • Non-Unique by Value
  • Unique by Value

However, if the SQL query is requesting an excessive amount of data, the Access Paths may be:

  • Scan—Indicates an inefficient SQL query. It places a high load on the server as it does not define a time range or specific items in the database.
  • Range—Indicates an inefficient SQL query. It places a high load on the server as it defines a time range, but does not define specific items in the database.

NOTE: The Range status is suitable for SQL queries that request data from the Event Journal.

Schneider Electric staff may use this information when investigating abnormal conditions that may relate to the query processor. They may also use the statistics in the Largest Queries and Longest Queries categories.


Server Status Tool Guide - Largest Queries (Query Processor Status Information)

Largest Queries

The Largest Queries category shows a list of the queries that required the most processor usage. The columns provide information about each query including:

  • Id—The identifier number allocated to the query connection. The queries are numbered in order (according to the age of the query connection—the oldest connections have the lowest numbers).
  • Time—The time at which the data that is specified in the SQL query was requested.
  • Src—The number of different database tables being used by the connection.
  • SQL—Information about the latest error relating to the Query connection (if any)
  • Parse—The speed at which the parse operation is performed on the SQL query. The speed is in seconds.
  • Verify—The speed at which the verify operation is performed on the SQL query. The speed is in seconds.
  • Optimize—The speed at which the optimize operation is performed on the SQL query. The speed is in seconds.
  • Execute—The speed at which the execute operation is performed on the SQL query. This is performed after the Parse, Verify, and Optimize operations. The speed is in seconds.
  • Exec Count—The number of times the query was executed.
  • Rows—The number of rows returned by the query.
  • Access Paths—The type of optimization that has been used. When the SQL query is requesting a suitable amount of data, the Access Paths entry will be one of the following:
  • Non-Unique by Column
  • Unique by Column
  • Non-Unique by Value
  • Unique by Value

However, if the SQL query is requesting an excessive amount of data, the Access Paths may be:

  • Scan—Indicates an inefficient SQL query. It places a high load on the server as it does not define a time range or specific items in the database.
  • Range—Indicates an inefficient SQL query. It places a high load on the server as it defines a time range, but does not define specific items in the database.

NOTE: The Range status is suitable for SQL queries that request data from the Event Journal.

Schneider Electric staff may use this information when investigating abnormal conditions relating to the query processor. They may also use the statistics in the Latest Queries and Longest Queries categories


Server Status Tool Guide - Longest Queries (Query Processor Status Information)

Longest Queries

The Longest Queries category shows a list of the queries that took the longest amount of time to complete. The columns provide information about each query including:

  • Id—The identifier number allocated to the query connection. The queries are numbered in order (according to the age of the query connection—the oldest connections have the lowest numbers).
  • Time—The time at which the data that is specified in the SQL query was requested.
  • Src—The number of different database tables being used by the connection.
  • SQL—Information about the latest error relating to the Query connection (if any)
  • Parse—The speed at which the parse operation is performed on the SQL query. The speed is in seconds.
  • Verify—The speed at which the verify operation is performed on the SQL query. The speed is in seconds.
  • Optimize—The speed at which the optimize operation is performed on the SQL query. The speed is in seconds.
  • Execute—The speed at which the execute operation is performed on the SQL query. This is performed after the Parse, Verify, and Optimize operations. The speed is in seconds.
  • Exec Count—The number of times the query was executed.
  • Rows—The number of rows returned by the query.
  • Access Paths—The type of optimization that has been used. When the SQL query is requesting a suitable amount of data, the Access Paths entry will be one of the following:
  • Non-Unique by Column
  • Unique by Column
  • Non-Unique by Value
  • Unique by Value

However, if the SQL query is requesting an excessive amount of data, the Access Paths may be:

  • Scan—Indicates an inefficient SQL query. It places a high load on the server as it does not define a time range or specific items in the database.
  • Range—Indicates an inefficient SQL query. It places a high load on the server as it defines a time range, but does not define specific items in the database.

NOTE: The Range status is suitable for SQL queries that request data from the Event Journal.

Schneider Electric staff may use this information when investigating abnormal conditions relating to the query processor. They may also use may the statistics in the Latest Queries and Largest Queries categories.


Server Status Tool Guide - OPC Status Information

OPC Status Information

The Server Status Tool provides status information that is organized into groups of categories, each of which contains sub-categories. The OPC group provides status information about the OPC tags that are being used by clients connected to the server. For example, a client that is displaying a Mimic with ‘live’ values will reference an OPC tag for each value, and information about each of those tags is shown in the OPC group on the Server Status Tool (on the server to which the client is connected). The OPC group contains the following sub-categories:

  • DA Groups—provides status information about the DA Groups to which a client subscribes.
  • DA Items—provides status information about the OPC DA tags that are referenced on Mimics that are currently displayed. The Mimics are displayed on clients that are connected to the server.
  • HDA Items—provides status information about the traces that are shown on Trends and X-Y Plots. The traces are shown on displays that are currently being used on clients that are connected to the server.
  • XML-DA Items—provides status information about any XML DA tags referenced by Mimics that are currently displayed on WebX clients.
  • XML-DA Subscriptions—provides status information about XML-DA subscriptions. You can use this information to determine whether any Mimics currently displayed on WebX clients are being updated at a suitable rate.


Server Status Tool Guide - DA Groups (OPC Status Information)

DA Groups

The DA Groups category provides status information about the DA Groups to which a client subscribes. Each DA Group consists of items that the client is being used to monitor, for example, values on a Mimic.

The method used to subscribe to an DA Group varies according to the client application. For ViewX, there is an DA Group per Mimic, so a Mimic that contains an embedded Mimic will subscribe to 2 DA Groups.

The status information for the DA Groups is categorized under these headings:

  • Id—Indicates the identity number of the group. This number is generated by ClearSCADA.
  • Name—Indicates the name that has been allocated to the group. This includes the name of the System and the Mimic.
  • State—Indicates the number of clients that can access the group. The State entry can be:
  • Private—The group can be accessed by one client.
  • Public—The group can be accessed by every client.
  • Deleted—The group cannot be accessed. It is in the process of being deleted.
  • Total Clients—Indicates the number of clients that are connected to the group.
  • Active Clients—Indicates whether the server sends group data to the client when the group data changes. The Active Clients entry can be:
  • 0—The server does not send updated group data to the clients.
  • 1—The server sends updated group data to the clients.
  • Items—Indicates the number of database items that have values within the group.
  • Def Rate—Indicates the default rate at which the server sends the group data to the client.
  • Def Handle—Displays a client handle value. This is unique to the client and is generated by the client.
  • Def LCID—Displays the locale identity. This number corresponds to the locale as defined in the client's regional settings. For more information, please refer to your operating system documentation.
  • Def Bias—Indicates the amount of time that is added to, or subtracted from Greenwich Mean Time to calculate the local time for the client on which the Mimic is displayed.
  • Def DBand—The default deadband. This can only be 0.


Server Status Tool Guide - DA Items (OPC Status Information)

DA Items

The DA Items category provides status information about each OPC DA tag that is displayed on a Mimic. Each OPC DA tag represents a specific type of value for an item.

The status information for each OPC tag is categorized as:

  • Id—The Id is a number that ClearSCADA uses to identify each OPC tag and the item to which it relates.
  • Tag—Indicates the path of a database item that is shown on the Mimic and the name of the item's OPC tag to which the data in this row relates.
  • Canonical Datatype—Shows the original type of the OPC data that is being requested. This can be:
  • VT_BSTR—a string value
  • VT_BOOL—a Boolean value
  • VT_I1—a signed integer value (byte)
  • VT_I2—a signed integer value (short)
  • VT_I4—a signed integer value (long)
  • VT_UI1—an unsigned integer value (byte)
  • VT_UI2—an unsigned integer value (short)
  • VT_UI4—an unsigned integer value (long)
  • VT_R4—a single precision value (float)
  • VT_R8—a double precision value
  • VT_DATE—a date value.
  • Requested Datatype—Shows the data type that has been requested (some OPC clients can request data in a different type to that in which it stored in the ClearSCADA database, for example, a real value could be requested as a string).

The datatypes that can be requested are:

  • VT_EMPTY—A value has not been specified. This means that the client has not requested for the value to be converted from its original datatype. The datatype of the value that is returned will be the same as the value’s Canonical Datatype.
  • VT_I1—a char value (1 byte signed integer)
  • VT_I2—a short integer (2 byte signed integer)
  • VT_I4—a long integer (4 byte signed integer)
  • VT_R4—a float value (4 byte real)
  • VT_R8—a double value (8 byte real)
  • VT_CY—a currency (monetary) value
  • VT_DATE—a date and time value
  • VT_BSTR—a string value
  • VT_BOOL—a Boolean value (True =-1, False=0)
  • VT_UI1—a byte (1 byte unsigned int)
  • VT_UI2—an unsigned short (2 byte unsigned integer)
  • VT_UI4—unsigned long (4 byte unsigned integer)

NOTE: These datatypes can also be arrays, in which case, the datatype is appended with |VT_ARRAY, for example, VT_UI4|VT_ARRAY.

  • Value—Indicates the current value of the OPC tag that corresponds to the value on the Mimic.
  • Value Datatype—Shows the type of the OPC data after it has been converted into the requested datatype. The possible value data types are exactly the same as those for Canonical Datatype.
  • Quality—Indicates the current quality of the value. This provides an indication as to the reliability of the data. For more information, see the ClearSCADA Guide to ViewX and WebX Clients.
  • Time Stamp—Indicates the time at which the Value and Quality statuses were recorded.

You can use the DA Items status information to investigate Mimic Update Problems.


Server Status Tool Guide - HDA Items (OPC Status Information)

HDA Items

The HDA Items category provides status information for each trace that is shown on a Historic Graph or Historic Trend.

The status information for each trace is categorized as:

  • Id—The identity number that has been allocated to the trace by the ClearSCADA software.
  • Client—The number of the client handle that is allocated by the ClearSCADA software.
  • Name—The full name of the item from which the historic data originates.
  • Aggregate—The name of the database aggregate that generates the historic values. This can be:
  • Historic—The database aggregate that generates the historic data for points.
  • History—The database aggregate that generates the historic data for Time Profiles.
  • Forecasts—The database aggregate that generates the historic data for Forecasts.

You can use the HDA Items status information when investigating abnormal Trend updates.


Server Status Tool Guide - XML-DA Items (OPC Status Information)

XML-DA Items

The XML-DA Items category provides status information about each XML DA tag that is displayed on a Mimic (that is being viewed on a WebX client). Each XML DA tag represents a specific type of value for an item.

The status information for each XML-DA tag is categorized as:

  • Tag—Indicates the path of a database item that is shown on the Mimic and the name of the item's OPC tag to which the data in this row relates.
  • Subscription—Indicates the name of the subscription being used for retrieving data for the Mimic from the server. You can view status information about the subscriptions on the status display for XML-DA Subscriptions
  • Canonical Datatype—Shows the original type of the OPC data that is being requested. This can be:
  • VT_BSTR—a string value
  • VT_BOOL—a Boolean value
  • VT_I1—a signed integer value (byte)
  • VT_I2—a signed integer value (short)
  • VT_I4—a signed integer value (long)
  • VT_UI1—an unsigned integer value (byte)
  • VT_UI2—an unsigned integer value (short)
  • VT_UI4—an unsigned integer value (long)
  • VT_R4—a single precision value (float)
  • VT_R8—a double precision value
  • VT_DATE—a date value
  • VT_EMPTY—a null value.
  • Requested Datatype—Shows the data type that has been requested (some OPC clients can request data in a different type to that in which it stored in the ClearSCADA database, for example, a real value could be requested as a string).

The datatypes that can be requested are:

  • VT_EMPTY—A value has not been specified. This means that the client has not requested for the value to be converted from its original datatype. The datatype of the value that is returned will be the same as the value’s Canonical Datatype.
  • VT_I1—a char value (1 byte signed integer)
  • VT_I2—a short integer (2 byte signed integer)
  • VT_I4—a long integer (4 byte signed integer)
  • VT_R4—a float value (4 byte real)
  • VT_R8—a double value (8 byte real)
  • VT_CY—a currency (monetary) value
  • VT_DATE—a date and time value
  • VT_BSTR—a string value
  • VT_BOOL—a Boolean value (True =-1, False=0)
  • VT_UI1—a byte (1 byte unsigned int)
  • VT_UI2—an unsigned short (2 byte unsigned integer)
  • VT_UI4—unsigned long (4 byte unsigned integer)

NOTE: These datatypes can also be arrays, in which case, the datatype is appended with |VT_ARRAY, for example, VT_UI4|VT_ARRAY.

  • Value—Indicates the current value of the OPC tag that corresponds to the value on the Mimic.
  • Value Datatype—Shows the type of the OPC data after it has been converted for use. The possible data types are exactly the same as those for Canonical Datatype.
  • Quality—Indicates the current quality of the value. This provides an indication as to the reliability of the data. For more information, see the ClearSCADA Guide to ViewX and WebX Clients.
  • Time Stamp—Indicates the time at which the Value and Quality statuses were recorded.


Server Status Tool Guide - XML-DA Subscriptions (OPC Status Information)

XML-DA Subscriptions

You can use the XML-DA Subscriptions category to determine whether Mimics on WebX Clients are being updated within the required time.

The XML-DA Subscriptions category provides the following information:

  • Handle—A unique identifier that is used to identify the subscription internally.
  • Items—The number of items on the WebX Mimic.
  • Ping Rate—The maximum amount of time permitted between each 'ping' attempt to communicate with the WebX client. If the client is not updated within the Ping Rate time, the server assumes the client cannot be contacted and so frees some of its resources.

If a client is not updating within the Ping Rate time, the server and WebX client may be unable to communicate with each other. Alternatively, the ping time may be too small (the ping time is fixed for ClearSCADA, but may be user-defined in some other OPC based programs).

  • Last Refresh—A time stamp of the last update to the WebX Mimic.


Server Status Tool Guide - WebX Status Information

WebX Status Information

The Server Status Tool provides status information that is organized into groups of categories, each of which contains sub-categories. The WebX group provides status information about any WebX clients that are connected to the server and the cookies, links and threads that they use. The WebX group contains the following sub-categories:

  • Clients (WebX)—provides status information about each WebX client that is connected to the server
  • Cookies—provides status information about each WebX cookie that is currently in use
  • Links (WebX)—provides status information for the connections between the server and any WebX clients
  • Threads—provides status information about the threads that are used to service the WebX links (links between the server and the WebX clients).

Further Information

WebX: see WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


Server Status Tool Guide - Clients (WebX) (WebX Status Information)

Clients (WebX)

The Clients category in the WebX folder of the Server Status Tool provides status information about each WebX client that is connected to the server.

The status information for each WebX client is categorized under these headings:

  • Address—The IP address of each client.
  • Links—The number of links between the WebX client and the server.
  • Up Time—The amount of time since the WebX client connected to the server.
  • Licensed—Indicates whether the client has a valid license (Yes or No).

The number of clients varies according to the size of your system.

The Clients (WebX) category is often used to check that WebX clients have valid licenses (they will be unable to connect to the server if they have invalid licenses) and also to determine which WebX clients have a connection to the server.


Server Status Tool Guide - Cookies (WebX Status Information)

Cookies

The Cookies category provides status information about each WebX cookie that is currently in use.

The server sends a WebX cookie to a WebX client when a user logs on via a WebX client. The cookie will remain valid as long as the WebX client is active within a 30 minute period. If the WebX client is idle for 30 minutes, the WebX cookie expires and the user will need to log on again as the cookie will be invalid.

The status information for each WebX cookie is categorized as:

  • Cookie—A Globally Unique Identifier (GUID) that is generated by the server to identify the cookie.
  • User—The name of the User account that has been used to log on at the WebX client.
  • Address—The IP address of the WebX client.
  • Logons—The number of times the current User has simultaneously logged on to the WebX client. For example, if a user runs Internet Explorer and logs on to the WebX interface, then logs on again via a second Internet Explorer window, the Logons count will be 2 (the user is currently logged on via 2 browsers).
  • Last Accessed—The time at which the cookie was used to access the server. This is the time that the user logged on to the WebX client.


Server Status Tool Guide - Links (WebX) (WebX Status Information)

Links (WebX)

The Links category in the WebX folder on the Server Status Tool provides status information for the connections between the server and any WebX clients.

The status information for the WebX links is categorized as:

  • Id—The number that is used to identify the link between the server and the WebX client.
  • Source—The IP address of the WebX client that uses the link.
  • Type—Indicates whether the WebX client is using a HTML or XML connection.
  • Requests—The number of requests that the WebX client has made via the link.
  • Up Time—The number of seconds for which the link has been connected.
  • User Name—The name of the user account with which the link is associated. This is the user account that was 'logged on' to the WebX client when the link was used.
  • Mode—Indicates the tasks for which the link is being used.
    The Mode can be one of the following:
  • None—The link from the WebX client is being started.
  • Read—The server is reading data from the WebX client via the link or is waiting for a request from the client.
  • Write—The server is writing data to a WebX client via the link.
  • Unknown—The link is not in one of the recognized states. There may be a software error.
  • Action—Indicates which task is currently in process. The Action can be:
  • Idle—The server is waiting for a WebX client to send a request via the link.
  • Read—The server is using the link to read data from a WebX client.
  • Read Request—The server is using the link to read a request from a WebX client.
  • Read Header—The server is using the link to read the header part of a request from a WebX client.
  • Read Body—The server is using the link to read the body part of a request from a WebX client.
  • Process—The server is using the link as it processes the request from a WebX client.
  • Write—The server is using the link to reply to the request from a WebX client.
  • Unknown—The server is not using the link for one of the recognized actions (listed above). This may indicate a software error.
  • Req Time—The amount of time, in milliseconds, of the last request via the link.
  • Request Type—Indicates the type of data request, for example GET. It also provides information the data that was requested.
  • Long Time—The time, in milliseconds, of the longest request made via the link.
  • Longest Type—Indicates the type of the data request that took the longest amount of time to process via the link.
  • Licensed—Indicates whether the WebX link has a valid license (Yes or No).

You should pay particular attention to the number of links shown in the Links category, and the Long Time status value:

If the number of links is excessively high in comparison to the number of WebX clients (typically, there are between 1 and 3 links per WebX client), you should contact
Schneider Electric for assistance.

If the Long Time status value is more than 1000mS, there may be a high server load (see WebX Client Activity).


Server Status Tool Guide - Threads (WebX Status Information)

Threads

The Threads category provides status information about the threads that are used to service the WebX links (links between the server and the WebX clients).

The status information for the WebX threads is categorized as:

  • Id—The unique number allocated to the thread by ClearSCADA.
  • Clients—The number of client links via the thread.
  • ThreadId—A unique number that is allocated by the operating system to identify the thread.


Server Status Tool Guide - Log Files and Logging Settings

Log Files and Logging Settings

You can use the ClearSCADA Server Status Tool to access log files (records of system activity) and logging settings for many aspects of your system, including drivers, channels and communications.

You may need to use the log files when investigating abnormal conditions and reporting unexpected system behavior to Schneider Electric engineers. For this reason, you should familiarize yourself with the various logging features and the actions you will need to take to access relevant log files.

For information on log files, defining the log file settings, and accessing the various types of log files, please see Logging and Monitoring in the ClearSCADA Guide to Server Administration.


Server Status Tool Guide - Common System Problems

Common System Problems

Many abnormal system conditions need to be reported to Schneider Electric. However, there are some issues that you can diagnose, and possibly resolve, before you contact Schneider Electric, such as:

  • Client Performance Problems
  • Connection Problems - System Offline
  • Mimic Update Problems
  • SQL Query and List Problems
  • Historic Data Problems
  • WebX Server Connection Problems.


Server Status Tool Guide - Client Performance Problems (Common System Problems)

Client Performance Problems

Slow client performance can often be resolved without assistance from Schneider Electric.

Slow client performance can be caused by:

  • High load on the server (often caused by inappropriate configuration)
  • High load on the client
  • Network connection problems or an unsuitable network structure.

For detailed information on how to diagnose the cause of slow client performance and guidelines on how to resolve it, see Diagnose Client Performance Problems.


Server Status Tool Guide - Connection Problems - System Offline (Common System Problems)

Connection Problems - System Offline

If you run ViewX and the system is offline, you should:

  1. Right-click on the Server icon in the Windows taskbar. If the Start Database option is available, select it. Your database will start and the system should change status to on-line.

If the Start Database option is not available, proceed to step 2.

  2. Use the ClearSCADA Client application to check that the configuration of your client is correct (see ViewX Client - System Connections in the ClearSCADA Guide to Client Administration). If correcting the client configuration does not resolve the connection issue, proceed to step 3.
  3. Check the network connection by 'pinging' the server from the client. To do this, log on to the client PC, access the Command Prompt and enter:
Ping <IP address of server or name of server>

Do not enter the angle brackets.

If the network connection is working correctly, the server will reply. If there is no reply, there is a fault with your network.


Server Status Tool Guide - Mimic Update Problems (Common System Problems)

Mimic Update Problems

If a Mimic is not updating correctly, there may be:

  • Inappropriate configuration.
  • Communications error(s).
  • Software error(s).

You can use the DA Groups and DA Items tabs to check for inappropriate configuration—the tabs should show information for the values that are shown on the Mimic, and should update at the same time.

If the values on the Mimic do not correspond to the values in the DA Items category, you should check that the Mimic items have been configured correctly.

If the values on the Mimic correspond to those in the DA Items category, there may be communications or software failures.

If you are experiencing slow performance, but only with Mimics, you should contact Schneider Electric for advice. However, many aspects of ClearSCADA are affected by slow performance on the client, you should check for load problems and network issues (see Diagnose Client Performance Problems).


Server Status Tool Guide - SQL Query and List Problems (Common System Problems)

SQL Query and List Problems

You can use the Query Processor categories on the Server Status Tool to view the status of SQL queries. With this information, you can then determine if any of the SQL queries are causing performance issues. Inefficient SQL Queries can affect performance, for example, a poorly constructed SQL Query could cause a high load on the server.

For more information refer to:

  • Latest Queries
  • Largest Queries
  • Longest Queries.

If you suspect that an SQL query is the cause of slow performance, you should refer to the Inefficient SQL Queries section of Diagnose Client Performance Problems.

ATTENTION: If you experience performance issues while working with SQL Queries, in particular those that relate to the Event Journal, you should also check the size of the historic and event files for your database. For more information, see Historic Data Problems.


Server Status Tool Guide - Historic Data Problems (Common System Problems)

Historic Data Problems

You can use the ClearSCADA Status Tool to diagnose unexpected system behavior relating to:

  • Generation of Historic Records
  • Large Historic Data Files and Event Journal files (see Diagnose and Resolve the Server Load Problems)
  • Historic Trends
  • Synchronization of Historic Data in Multi-Server Systems
  • Slow Performance of Historic Displays.


Server Status Tool Guide - Generation of Historic Records (Common System Problems)

Generation of Historic Records

You can use the Historian category (see Historian) to view the status of all historic records.

You should pay particular attention to the His Error value, which should be 0. If it is not 0, there is a serious error and you should report the problem to Schneider Electric.

You should also examine the Total Record value. If this value increases rapidly, there may be a high server load (see Diagnose Client Performance Problems).


Server Status Tool Guide - Historic Trends (Common System Problems)

Historic Trends

You can use the HDA Items category to view the status of the traces on Historic Trends. This is useful if your Historic Trends are showing different data than expected, as you can use the status information to determine whether the Historic Trend has the correct configuration.

If the trace that you expect to be shown on the Historic Trend does not have an entry on the HDA Items category, the Historic Trend does not recognize the trace. This is an indication that the trace cannot be displayed possibly due to the Historic Trend having incorrect configuration.

If the trace that you expect to be shown on the Historic Trend has an entry in the HDA Items category, the Historic Trend recognizes the trace but is not displaying it, so there may be a software fault. Please contact Schneider Electric for assistance.


Server Status Tool Guide - Synchronization of Historic Data in Multi-Server Systems (Common System Problems)

Synchronization of Historic Data in Multi-Server Systems

You can use the Historic Transfer category to view the status of the synchronization of historic data in multi-server systems (see Historic Transfer).

If you have knowledge of the setup and expected performance of the link between the servers, you can use the statistics in the Historic Transfer category to determine whether the link is being used efficiently.

You should pay particular attention to the % Sync status value—if this is significantly below 100% (systems usually have between 90% and 100%), there may be a problem with the link between the servers. Please contact Schneider Electric for assistance.


Server Status Tool Guide - Slow Performance of Historic Displays (Common System Problems)

Slow Performance of Historic Displays

If your system is slowed down when displaying Trends that show historic data, you should check the historic configuration settings of the relevant points. The point configuration settings define the amount of historic data that is to be logged - if ClearSCADA is set to log an excessive amount of historic values, this may cause slow performance.

If the points are configured correctly, you should check for duplicated historic data. Although rare, it is possible for faulty outstations and faulty drivers to duplicate the historic data for points. This can cause slow performance when viewing historic data for points (on Trends and other displays) as the system has to process excessive amounts of historic data.

You can set your system to remove duplicated historic data by using the Start Historic Optimization method. This method can be configured to be performed upon user selection on a Mimic or according to a schedule.

To configure a Mimic so that it provides access to the Start Historic Optimization method:

  1. In ViewX, display a Mimic in Design mode or create a new Mimic and display it in Design mode.
  2. Create the Mimic object that is to act as the 'trigger' for the Start Historic Optimization method. When this object is selected (in Run mode), the system will remove duplicate historic data and sort the historic data so that it is optimized for use.
  3. Use the Pick Action Wizard to associate the Mimic object with a Method pick action. You need to define these settings:
  • Type of Pick Action—Method
  • Object—The Root Group of your system has to be the Object. The Start Historic Optimization method is only available to the Root Group.
  • Aggregate—Historian
  • Method—Start Historic Optimization.

The other settings are optional.

  4. Proceed through the steps of the Pick Action Wizard and select the Finish button when the configuration is complete.
  5. Save the Mimic.
    When the Mimic is displayed in Run mode, the Mimic object that you added in step 2 will trigger the 'Start Historic Optimization' method. The user will be prompted to enter a start time and an end time—these times define the range of historic values that will be optimized. The default settings are usually suitable.

To configure a schedule to trigger the Start Historic Optimization method at regular intervals:

  1. In ViewX, create a new Schedule.
  2. Add an Action on the Schedule. The Action has to have these settings:
  • Object—The Root Group of your system has to be the Object. The Start Historic Optimization method is only available to the Root Group.
  • Aggregate—Historian
  • Method—Start Historic Optimization.
  3. On the Schedule Editor, double-click on the times at which the Start Historic Optimization method is to be triggered.
  4. Save the Schedule.

The user can view the progress of the optimization process by viewing the Event List for the Root Group. The Event List logs the start of the optimization process, each instance of duplicated historic data (and what action the system took to remove the duplicate), and the end of the optimization process.

If you want to configure a Mimic to indicate that the historic optimization process is in place, you can animate a Mimic object so that it is associated with the OptimiseInProgress tag of the Root Group. The OptimiseInProcess tag is within the Root Group's Historian tags.

The OptimiseInProgress tag stores a Boolean value. When the historic optimization process is in progress, the tag stores a True value; when it is not in progress, the tag stores a False value.

Further Information

Configuring Mimic Animations: see Animations in the ClearSCADA Guide to Mimics.

Schedules: see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration.


Server Status Tool Guide - WebX Server Connection Problems (Common System Problems)

WebX Server Connection Problems

You can use the Information category to determine the status of the WebX server connection (see General System Status Information). The status for the connection between ClearSCADA and the WebX interface can be:

  • Web Server: Running on Port <number>—The WebX server is setup correctly. Any web connection difficulties are likely to be related to your Internet connection or network settings.
  • Secure Server: Running on Port <number>—The secure server is setup correctly. Any web connection difficulties are likely to be related to your Internet connection or network settings. However, you should also check that you have the correct Certificate and Private Key (see Define the Access Settings for WebX Clients in the ClearSCADA Guide to Security).
  • Port <number> already in use—The port is already in use by another internet application. You need to define a different port address for the web server or secure server (see Define the Access Settings for WebX Clients in the ClearSCADA Guide to Security).
  • Web Server Disabled—Access via the non-secure port is not possible due to the web server being disabled (see Define the Access Settings for WebX Clients in the ClearSCADA Guide to Security).
  • Secure Web Server Disabled—Access via the secure port is not possible due to the secure web server port being disabled (see Define the Access Settings for WebX Clients in the ClearSCADA Guide to Security).
  • Failed to Create Socket—There is an error with the operating system network, please contact Schneider Electric for advice.
  • Failed to Listen on Port <number>—There is an error with the operating system network, please contact Schneider Electric for advice.


Server Status Tool Guide - Diagnose Client Performance Problems (Common System Problems)

Diagnose Client Performance Problems

If a client interface cannot connect to a ClearSCADA server, or all client displays have slow performance or stall, your system may be experiencing:

  • High load on the server
  • High load on the client
  • Abnormal network conditions, such as failed connections or an unsuitable network structure.

To investigate the cause of your impaired client performance, you need to:

  • Check for High Load on a ClearSCADA Server.

If there is a high load on a ClearSCADA server, you need to:

  • Diagnose and Resolve the Server Load Problems.

If there is not a high load on the server, you need to:

  • Attempt to Resolve Client Load and/or Network Problems.


Server Status Tool Guide - Check for High Load on a ClearSCADA Server (Common System Problems)

Check for High Load on a ClearSCADA Server

You need to use the Links (Server) category to determine whether there is a high load on a ClearSCADA server. You can then proceed to diagnose the cause of the high load, or check for client load or abnormal network conditions.

To check for a high load on the server:

  1. On the ClearSCADA server, Run the Server Status Tool.
  2. Expand the hierarchy, then expand the Server group, then select the Links category.

The Links (server) category provides status information about each link that is used by the clients to send data to the ClearSCADA server.

  3. Use the Links information to determine if the cause is related to server loading:
  1. Examine the number of links. If the number is excessive in comparison with the number of clients that are connected to the server, there may be a server loading problem. However, the number of links is not the only indication of server loading problems (see next step).
  2. Examine the durations of the Longest Req entries. If the longest requests are 1000 ms or more, there may be a server loading problem. This is even more likely if there were an excessive number of links (see previous step).

If you suspect there is a server loading problem, due to either or both of the problems indicated in the above procedure, proceed to Diagnose and Resolve the Server Load Problems.

If there are no indications of a server loading problem, proceed to Attempt to Resolve Client Load and/or Network Problems.


Server Status Tool Guide - Diagnose and Resolve the Server Load Problems (Common System Problems)

Diagnose and Resolve the Server Load Problems

If you suspect that there is a high load on your server(s), you need to check for each of the possible causes:

  • Slow Events List Performance due to the Event Journal Cache becoming Full
  • Slow Historic Display Performance due to Cache Size or Volume of Historic Data
  • Excessive Number of Events
  • Excessive Number of Historic Records
  • Inefficient SQL Queries
  • Server to Client Link Problems
  • WebX Client Activity.

Each of the sections listed above contains a procedure that explains how to determine whether the high server load is caused by the relevant problem, for example, caused by WebX client activity. The sections also provide information on how to resolve any problems that you identify by analyzing the status information.

You should follow the procedure for each cause in turn. If, after finishing a procedure, the high server load is still in effect, return to this section and complete the procedure for another possible cause.

Slow Events List Performance due to the Event Journal Cache becoming Full

When users of your ClearSCADA system search the Events List, ClearSCADA loads the event data files required for the searches into the Event Journal Cache. On an efficient system, the event data files are loaded into the Event Journal Cache with no effect on system performance. However, if a system’s Event Journal Cache is unable to contain the event data files required for current searches, the performance of the Events List and Queries Lists can be affected and they will run noticeably slower.

If the Event Journal Cache becomes full, ClearSCADA has to remove some event data files from the cache to make space for the next files to be searched. The earliest event data files that were loaded into the cache are removed to make way for the latest event data files.

There are several potential causes for the Event Journal Cache to become full:

  • The size of the Event Journal Cache is insufficient for the type of searches being performed In ClearSCADA
  • The searches being performed in ClearSCADA are covering an inappropriate time span (and so require a large number of event data files or very large event data files to be loaded into the Event Journal Cache)
  • An excessive amount of events are being generated due to inappropriate or incorrect configuration

If your Events List is affected by slow performance, you need to determine the reason for the Event Journal Cache becoming full:

  1. Run an SQL query on the event data files to calculate the total number of event data files being generated each day:
  1. In ViewX, display any Queries List, then select the View menu, then the SQL option to display the List’s SQL Query.
  2. Remove the existing SQL Query and replace it with the following SQL:
SELECT {FN TIMESTAMPDIFF( SQL_TSI_DAY, StartTime, CURRENT_DATE) }, SUM(RecordCount)
FROM CDBEventFile
GROUP BY {FN TIMESTAMPDIFF( SQL_TSI_DAY, StartTime, CURRENT_DATE ) }
ORDER BY 1

  3. Select the OK button to run the new SQL Query.
    The Queries List displays a list containing 2 columns
    .

Each row represents a single day and the number shown indicates the actual day with 0 being today, 1 being yesterday (1 day in the past), 2 being 2 days in the past and so on. There are only rows for those days on which events were recorded.

The right-hand column contains the sum total of events that were generated on each of the days. For example, if the 0 row has a Sum of 54, it means that 54 events have been reported during the present day.

  4. Use the Sum totals to estimate the amount of events that are recorded in a 'normal' day. We will refer to this amount the 'average daily events total' (although it may not be a calculated average).
  2. Use the 'average daily events total' to calculate the required cache size:
  3. Multiply the 'average total' by 768 (the size of an individual event record in bytes). The result of this calculation is the amount of space needed in the Event Journal cache when a user searches 1 day’s worth of events. We will refer to this amount as the '1 day cache size'.
  4. Now that you know the size of cache that is required for a search of 1 day’s worth of events, consider the size of the Event Journal searches being performed by users on your system. If they are mostly performing searches on 1 day’s worth of data, you already know the required cache size; 2 day’s worth of data and you need to double the required cache size, a week’s data and you need to multiple the cache size by 7 (and so on).
  3. Compare the calculated required cache size to the actual cache size that is defined in the Server Configuration settings (see Define the Cache Size, Flush Time Limit and Thresholds for the Event Journal).
  4. You will probably see that the configured Cache Size is insufficient and needs to be increased.
  • On 32 bit systems, the total size of the Event Journal and Historic caches combined cannot exceed 400MB and so there is a limit to the amount by which you can increase the cache size (see Define the Cache Size, Flush Time Limit and Thresholds for the Event Journal).
  • On 64 bit systems, you can increase the Event Journal cache to any size as long as the server has the appropriate amount of RAM available. If there is insufficient RAM, you can upgrade the server to have increased RAM or proceed to step 5.

If increasing the Cache Size for the Event Journal does not improve performance, or you are unable to increase the Cache Size to the required amount, proceed to step 5.

  5. Check that your server hardware meets the system requirements (see System Server Requirements). You may need to upgrade your server or look at ways of reducing the size of your database.

If your server hardware meets the system requirements, proceed to step 6.

  6. If your system has a large database of over 100,000 database items or is recording a high volume of events, you may be able to improve performance by adjusting the Stream Size setting for the Event Journal (see Define the Stream Size for Maximum Performance of the Event Journal).

If changing the Stream Size does not improve performance, proceed to step 7.

  7. You need to reduce the number of events being recorded or reduce the size of the searches being performed (see Excessive Number of Events).

Slow Historic Display Performance due to Cache Size or Volume of Historic Data

Historic displays such as the Historic List and Historic Trends can suffer from slow performance when:

  • The amount of historic data required for the display is too large for the Historic cache
  • The volume of historic data is too great as the points’ historic data is being recorded too frequently
  • The server hardware is insufficient for the size of database and the amount of points with historic data.

If you are experiencing slow performance with historic displays, you should:

  1. Determine the number of historic records required for your search.
  • If you are displaying a Historic Trend, configure the Key to display the Count, then examine the Count entries. These are the total number of historic records for each point on the Trend. Add up the Count entries for each point shown on the Trend to determine the total number of historic records required for the Trend.
  • If you are displaying a Historic List, examine the Rows entry shown in the status bar at the bottom of the ViewX display. You will see that it states the number of rows currently on display and the total number of rows. The total number of rows is the total number of historic records required for the Historic List.
  2. Repeat step 1 on each unique Historic Search that is active on your system. You need to do this so that you can calculate the total number of historic data records required for all active historic searches on your database (i.e. you also need to determine how many historic records are needed by Historic Lists and Trends being used by other users). You only need to include those Historic Lists and Trends that are performing a unique Historic Search—if users are searching the same Historic Records, they will share the same set of records in the cache and so these records have to be counted only once.
  3. Calculate the total amount of historic records that are required for all active searches.
  4. Multiply the total amount of historic records by 32. 32 is the number of bytes per historic record. The result of this calculation is the amount of bytes required for the active Historic Searches.
  5. Compare the total amount of bytes required for the active Historic Searches to the Cache Size for Historic data.

If the Cache Size is sufficient, you may need to reduce the frequency with which historic values are recorded. Proceed to step 7.

If the Cache Size is insufficient, you may need to increase it.

  • On 32 bit systems, the total size of the Event Journal and Historic caches combined cannot exceed 400MB and so there is a limit to the amount by which you can increase the cache size (see Define the Cache Size, Flush Time Limit and Thresholds for the Event Journal).
  • On 64 bit systems, you can increase the Historic cache to any size as long as the server has the appropriate amount of RAM available. If there is insufficient RAM, you can upgrade the server to have increased RAM, lower the amount of historic data being recorded or reduce the size of the search being performed on your system.

If increasing the Historic Cache Size does not improve performance, or you are unable to increase the Cache Size to the required amount, proceed to step 6.

  6. Check that your server hardware meets the system requirements (see System Server Requirements). You may need to upgrade your server or look at ways of reducing the size of your database.

If your server hardware meets the system requirements, proceed to step 7.

  7. You need to reduce the number of historic values being recorded or reduce the size of the searches being performed (see Excessive Number of Historic Records).

Further Information

Trends: see Using Trends in the ClearSCADA Guide to Trends.

Excessive Number of Events

You can use the Diagnostics category and the Historian category to check the number of events that have been generated by the server. An excessive number of events can cause high load on a server.

The Diagnostics category provides status information about the OPC events which include system events and alarm related activities such as alarms being acknowledged or cleared.

The Historian category provides status information about the ClearSCADA events—these are the historic events that are stored on the hard disk and are shown on the Events List.

If you are experiencing slow performance of the Events List, you should first determine whether:

  • An appropriate cache size is in place
  • The Stream Size setting for Events is suitable
  • Your server has appropriate hardware for your requirements

For information on these settings and requirements, see Slow Events List Performance due to the Event Journal Cache becoming Full.

If the cache size, stream size, and server hardware are sufficient, you should investigate the number of event records being generated:

  1. Run the Server Status Tool.
  2. Expand the system, then the Database folder, then select the Diagnostics category.
  3. Examine the number of Events that have been processed.

If there are tens or hundreds of events being generated per second, there is a high load on the server. Typically, excessive numbers of events being generated is caused by inappropriate configuration. Proceed to step 6.

If the number of events is increasing at less than ten per second, the high load on the server is not being caused by an excessive number of OPC events. Proceed to step 4.

  4. Expand the Historic folder, then select the Historian category.
  5. Examine the Total Record entry for the Event data. This indicates the number of historic events that have been generated and stored on the hard disk.

If the number of historic events increases by tens or hundreds per second, there may be too many events being generated. Proceed to step 6.

If the number of historic events is not increasing, or is increasing at a rate slower than ten events per second, the number of historic events being generated is unlikely to affect the server load. Please refer back to Diagnose and Resolve the Server Load Problems.

  6. Run ViewX and log on.
  7. Display the Events List. You should filter it so that it shows the events that were generated during the time that the clients were experiencing slow performance. For further details, see Events Lists in the ClearSCADA Guide to Lists.
  8. Look at the Source entries to identify the database items for which excessive numbers of events have been generated.
  9. Look at the Message entries for the database items you identified as having excessive numbers of events. The Message describes the event that has been generated (which you can use to determine the cause of the event).
  10. Use the Source and Message information in conjunction with your knowledge of the system specification and configuration to determine whether you can alter the configuration to reduce the load. For example, you may be able to alter the configuration of a point so that there are fewer events generated for it.

Excessive numbers of events are often caused by automatic activities, such as:

  • Changes at plant being reported by the outstations, PLCs etc.
  • Scheduled activities
  • Logic programs being executed too frequently.

If altering the configuration would affect your system so that it would no longer meet your requirements, you may need to upgrade the server hardware. Please contact Schneider Electric for more advice.

Excessive Number of Historic Records

One potential cause of slow performance with Historic Lists and Historic Trends is that there is an excessive number of historic records. This can happen when historic data is recorded too frequently, causing the historic files to become large in size (over 5MB).

If you are experiencing slow performance of Historic Lists or Historic Trends, you should first determine whether an appropriate Historic cache size is in place and whether your server has appropriate hardware for your requirements (see Slow Historic Display Performance due to Cache Size or Volume of Historic Data). If the Historic cache size and server hardware are sufficient, you should investigate the number of historic records being generated:

  1. Run the Server Status Tool.
  2. Expand the Historic folder, then select the Historian category
  3. Look at the Raw row (which represents the raw historic data). Pay particular attention to the Largest File status—if it is 5MB or greater, it means that there is a large amount of historic data.
  4. Log on to ViewX and display any Queries List.
  5. Select the View menu, then the SQL option to display the List’s SQL Query.
  6. Remove the existing SQL Query and replace it with the following SQL:
SELECT TOP(10) SUM(RecordCount),F.ObjectId,O.FullName
FROM CDBHistoricFile AS F INNER JOIN CDBObject AS O ON (F.ObjectId = O.Id)
GROUP BY F.ObjectId
ORDER BY 1 DESC

NOTE: The TOP(10) part of the query instructs the List to display the ten points. If you wanted the list to show a greater or lesser number, you can change the number accordingly, for example, TOP(30) would return a List containing information about 30 points.

  7. Select the OK button to run the Query.
    The Queries List displays a list of the points that have the highest number of historic records.

Each row in the list represents 1 database point and provides a Sum total of the historic records for that point, the point’s unique ID (Object Id), and the point’s Name value (FullName) which shows the name and location of the point.

  8. Check the configuration of the points named in the list. These are the points that have the highest number of historic records and so will have their historic values recorded too frequently. You need to configure the points so that their historic values are recorded less often (this will reduce the number of historic records and in turn, the size of the historic files).

By changing the configuration of the points, you may have resolved the performance issues with your Historic Trends and Historic Lists. But the performance problems you experienced will continue until the Historic Life has expired (as the large historic files will still be in place). The Historic Life is defined in the Keep Online For field in the server’s Historic configuration (see Define the Historic Life for Historic Data).

When the Historic Life has expired, you may notice an improvement in the performance of your Historic Trends and Historic Lists. If your Historic Trends and Lists are still affected by slow performance, you should repeat steps 4-8 of this procedure, as there may be further points that are having their historic values recorded too frequently.

Further Information

Define an individual point’s Historic storage features: see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration.

Inefficient SQL Queries

SQL Queries can cause a high load on a server. In particular, SQL Queries that request a large amount of unfiltered historic data, for example, all historic data over a year.

You can use the Queries category to check the status of any SQL queries that are requesting data from the server.

To check the status of SQL Queries and attempt to resolve any SQL-related problems:

  1. Run the Server Status Tool.
  2. Expand the system, then the Query Processor folder, then select the Latest Queries category.
  3. Examine the entries in the Access Paths column.

Queries that are likely to cause high load on the server have the following Access Paths status:

  • <database table>=Scan
  • <database table>=Range

Where <database table> is the name of the table that contains the data requested by the query, for example, CDBEVENTJOURNAL.

The Scan status indicates that the query is poorly constructed and usually relates to an unfiltered query, for example, a query that requests historic data without specifying a time range or specific points.

The Range status also indicates that the query is poorly constructed and relates to a query that defines a time range but does not define specific database items. For example, a query for historic data could have a Range status as although it defines a specific time range, it does not define specific points. This means that the results of the query are based on the historic values of all points in the database.

NOTE: The Range status is suitable for Event Journal queries as the Event Journal is intended to show events for all items within a specified time range.

If there are queries with the Scan status or Range status (except for Event Journal queries), proceed to step 4.

If there are no queries with the Scan or Range statuses, the SQL queries are unlikely to be causing the high server load. Please refer back to Diagnose and Resolve the Server Load Problems.

  4. Identify the source of the query. This is often indicated in the code of the SQL query.
  5. Edit the SQL query (using the application in which the SQL query was created) so that:
  • A suitable time range is specified.
  • The query requests data for specific items, not for every item in the database.

WebX Client Activity

High server load can be caused by WebX client activity, including:

  • An excessive amount of activity on WebX clients.
  • An excessive number of links to WebX clients.
  • Large numbers of requests from external applications via the Simple Object Access Protocol (SOAP) interface.

To determine whether WebX activity is causing a high load on the server:

  1. Run the Server Status Tool.
  2. Expand the system, then the WebX folder, then select the Links category.
  3. Use the Links category to determine whether there is an excessive amount of WebX activity or an inappropriate number of WebX clients:
  • Examine the number of WebX links. There should be 2 or 3 links per WebX client. If there appears to be an excessive number of WebX links, contact Schneider Electric for advice.
  • Examine the Long Time entry for each link. If a link has a Long Time entry that is greater than 1000 ms, the WebX clients are probably causing a high server load. Proceed to step 4.

If there are an appropriate number of WebX links and they have the correct Long Time entries, refer back to Diagnose and Resolve the Server Load Problems.

  4. Reduce the load on the server that is caused by the WebX links by either:
  • Stopping external applications from accessing the system via the SOAP interface. These applications are the most common web-related cause of high load on the server.
  • Checking that users are not performing tasks that place an unnecessary demand on the system. For example, if a user requires information about Events within a specific time period, they should display a filtered Events List. An unfiltered Events List will place a large demand on the system.
  • Upgrading the server hardware so that it can manage more links to WebX clients.

Server to Client Link Problems

A high load on the ClearSCADA server can be caused by a problem with a server to client link. Each of these links is referred to as a server advise, and they allow a server to send data to the clients.

To detect and attempt to resolve a problem with a server to client link:

  1. Run the Server Status Tool.
  2. Expand the system, then expand the Server folder and select the Advises category.
  3. Use the Advises information to determine whether there are connection problems for data transfer from the server to the clients:
  • Examine the Status entry and Evt Pend entry for each advise.

When the server is communicating with the clients as expected, the Status entry for the server advise is — and the Evt Pend is 0. If either of these statuses change to another value for an extended amount of time (i.e. they do not change when the clients are supposed to have refreshed), there may be a communications problem.

If you suspect that there is a problem with a server advise, proceed to step 4.

If the server advises appear to be working correctly, please refer back to Diagnose and Resolve the Server Load Problems.

NOTE: The Status and Evt Pend may change for a short period when there are no communication problems. They should revert to the expected statuses when the clients are updated.

  4. If you suspect that there is a problem with the server advise:
  1. Examine the Backoff entry. If it is any value other than 0, there may be network conditions that are stopping the server from connecting with the client. Please re-establish your network.

If the network is functioning correctly or re-establishing the network does not reduce the high server load, proceed to the next step.

If the network is not functioning correctly, you need to contact your network administrator. The network may be structured inappropriately or may have bad connections.

  2. Re-start the client(s) to which the server is connected.

If re-starting the client(s) does not reduce the high server load, please contact Schneider Electric for assistance.


Server Status Tool Guide - Attempt to Resolve Client Load and/or Network Problems (Common System Problems)

Attempt to Resolve Client Load and/or Network Problems

If your client(s) experience slow performance and there does not appear to be a high load on the ClearSCADA server, you should:

  1. Check the amount of memory that is available on the client. There should be enough memory to run ClearSCADA and any other applications that are required.

The amount of memory that is needed will vary according to the requirements of your system.

If there appears to be insufficient memory available, you may need to increase the amount of memory available or close other applications—contact Schneider Electric for advice.

If there appears to be sufficient memory available, proceed to step 2.

  2. Contact your network administrator, as abnormal network conditions are the most likely cause of the slow performance issues. The network administrator needs to check for:
  • Network structure problems
  • Connection problems
  • Excessive network traffic
  • Insufficient bandwidth.


Client Administration Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Client Administration Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Client Administration Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Client Administration Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Client Administration Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Client Administration Guide - Document Scope (About the Guide)

Document Scope

This guide explains how ClearSCADA clients (ViewX, WebX, XML, and Third Party OPC) connect to your ClearSCADA system and provides information on client-specific settings and features.

For details on the subjects covered in this Guide, see Welcome to the Client Administration Guide.


Client Administration Guide - Intended Audience (About the Guide)

Intended Audience

The ClearSCADA Guide to Client Administration is designed to be used by administrator-level users who are responsible for the initial set-up of client connections and settings.

For information about the various ViewX and WebX features, you should refer to the ClearSCADA Guide to ViewX and WebX Clients.


Client Administration Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Client Administration Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Security

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Lists

ClearSCADA Guide to Trends

ClearSCADA Guide to Mimics

ClearSCADA Guide to Alarm Redirection.


Client Administration Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Client Administration Guide - Welcome to the Client Administration Guide

Welcome to the Client Administration Guide

Welcome to the ClearSCADA Guide to Client Administration. This guide is designed to help you understand how ClearSCADA clients (ViewX, WebX, XML, and Third Party OPC) connect to your ClearSCADA system and provides information on client specific settings and features.

The ClearSCADA Guide to Client Administration is aimed at administrator level users who are responsible for the initial set-up of client connections and settings. For information about the various ViewX and WebX features, you should refer to the ClearSCADA Guide to ViewX and WebX Clients.

In this guide, you will find information on:

  • ViewX Client - System Connections—Explains how ViewX clients communicate with the ClearSCADA server and describes how to set up the ViewX client - system connection, check its status, and investigate any connection issues. It also provides information regarding the use of firewalls.
  • ViewX Cache—Explains how ViewX clients use the ViewX cache, which stores documents in memory and in a folder on the client’s hard drive. The cache is used to improve performance when documents such as Mimics, Logic programs, and Trends are displayed.
  • ViewX Options—Explains how you can use the Options window in ViewX to define settings that only affect the ViewX client PC on which you are working. These settings allow you to change the default appearance of Mimics, Trends, the Alarm Banner and Lists, as well as define a variety of other client specific settings.
  • Multi-Head ViewX Clients—Describes how to configure your clients to make use of the Multi-Head feature, so that multiple monitors can be used for a single client.
  • ViewX Client - Third Party OPC Server Connections—Explains how to configure a connection between a ViewX client and a Third Party OPC server.
  • WebX and XML Client - System Connections—Explains how WebX and XML clients use Internet/Intranet connections to communicate with the ClearSCADA server. It explains how to set up the WebX or XML client - system connection, check its status, and investigate any connection problems. It also provides information regarding the use of firewalls.
  • Third Party OPC Client - System Connections—Explains how Third Party OPC client applications communicate with the ClearSCADA server. It also describes how to set up the Third Party OPC client - system connection, check its status, and investigate any connection problems. Information regarding the use of firewalls is also provided.
  • Third Party ODBC Client - System Connections—Explains how Third Party ODBC client applications communicate with the ClearSCADA server. It also describes how to set up the Third Party ODBC client - system connection, check its status, and investigate any connection problems. Information regarding the use of firewalls is also provided.
  • Citrix or Terminal Services Client - System Connections—Describes the types of connection you need to configure to allow remote desktop applications to access ClearSCADA without having ViewX installed locally.
  • Client Logging—Describes how to use the logging features for diagnostic purposes.
  • DCOM Issues—Explains how ClearSCADA uses Data Access Components to avoid the problems commonly associated with DCOM.

We also provide information on the Client PC Requirements.


Client Administration Guide - Client PC Requirements (Welcome to the Client Administration Guide)

Client PC Requirements

The following sections describe the recommended computer specifications for ClearSCADA clients:

  • Client PC Specifications
  • Screen Resolution
  • Operational Limitations - Client.

For information on the various default file locations for ClearSCADA files, please see File Locations (Default) in the ClearSCADA Guide to Server Administration.


Client Administration Guide - Client PC Specifications (Welcome to the Client Administration Guide)

Client PC Specifications

The minimum PC specifications we recommend for client computers are:
ViewX Client | WebX Client
2 GHz processor | 2 GHz processor
512MB RAM | 512MB RAM
High performance graphics card |
10MB free disk space | 10MB free disk space
Desktop class operating system (see Operating Systems in the ClearSCADA Guide to Server Administration). | Desktop class operating system (see Operating Systems in the ClearSCADA Guide to Server Administration)

For information on client-server, and server specifications, please see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Client Administration Guide - Screen Resolution (Welcome to the Client Administration Guide)

Screen Resolution

The minimum recommended screen resolution for ClearSCADA is 1024x768.


Client Administration Guide - Operational Limitations - Client (Welcome to the Client Administration Guide)

Operational Limitations - Client

ClearSCADA has a number of recommended operational limits. Expansion beyond the recommended limits is possible, but may result in a system that is unstable and unreliable. The recommended operational limits for ClearSCADA clients are:
Parameter | 32 Bit Limit | 64 Bit Limit | Notes
Minimum ViewX to Server link bandwidth | 128 Kbit per second | 128 Kbit per second | Exceeding these limits will cause slow performance in ViewX.
Maximum ViewX to Server Link latency | 150 ms | 150 ms | Exceeding these limits will cause slow performance in ViewX.
Minimum WebX to Server Link bandwidth | 64 Kbit per second | 64 Kbit per second |

For information on server operational limitations, please see Operational Limitations - Server in the ClearSCADA Guide to Server Administration.


Client Administration Guide - ViewX Client - System Connections

ViewX Client - System Connections

ViewX clients provide access to ClearSCADA’s configuration and operation features (although security permissions can be used to restrict access to them). Each ViewX client has two communication links to the ClearSCADA server, both of which are set up when you create a ViewX Client - System connection.

In the following sections, we describe how ViewX clients communicate with the ClearSCADA server and explain how to configure the connection and firewalls. We also provide information on checking the status of the connection.

  • Working with Single and Multiple Databases
  • Understanding Client - System and Server Advise Connections
  • Create a New ViewX Client - System Connection
  • Edit an Existing ViewX Client - System Connection
  • Check which Ports are Available on the Client
  • Check the Status of the Client - System and Server Advise Connections
  • Failed Client - System and Server Advise Connections
  • Change the Port for the Server’s Incoming Data
  • Firewall Settings for Client - System and Server Advise Connections.

NOTE: To avoid potential DCOM issues, ViewX clients use Data Access Components to communicate with the ClearSCADA server using the TCP/IP protocol. The Data Access Components are installed on the ViewX client automatically when you install ViewX. The Data Access Components only have to be installed separately on WebX and Third Party OPC clients.

Further Information

ViewX Cache

ViewX Options

Multi-Head ViewX Clients.


Client Administration Guide - Working with Single and Multiple Databases (ViewX Client - System Connections)

Working with Single and Multiple Databases

A ViewX client can be configured to access a single ClearSCADA database or multiple ClearSCADA databases. Each ClearSCADA database is independent and runs as a ClearSCADA system on
a ClearSCADA server (or on multiple ClearSCADA servers if used in a multi-server redundant architecture). This means you can use a single ViewX client to:

  • Display information from one or more ClearSCADA databases
  • Configure items in one or more ClearSCADA databases
  • Issue controls to items in one or more ClearSCADA databases.

For more information on single and multi-database setups, please refer to the following sections:

  • Single Database
  • Multiple Databases.


Client Administration Guide - Single Database (ViewX Client - System Connections)

Single Database

A ViewX client can be configured so that it connects to a single ClearSCADA database. The ClearSCADA database is stored on a ClearSCADA server and it contains the configuration and values for your individual ClearSCADA system.

To connect to a single database, a ViewX client needs to be configured as a ClearSCADA client via the ClearSCADA Client window (see Display the Client Configuration Window). A single connection is needed between the ViewX client and the ClearSCADA database. In a multi-server architecture such as a Hot Standby Pair, the ClearSCADA database may run on multiple servers, but it is still a single database—each server runs its own copy of the same ClearSCADA database and the copies are regularly synchronized so that they are the same.

When you log on to a ViewX client that is connected to a single database, you will see a system icon (also referred to as the 'Root') in the Database Bar. By expanding the system icon, you can reveal the hierarchical structure of your database. You can then use the Database Bar to explore the contents of your ClearSCADA database.

Server runs the database
User of ViewX client can access the information in the database via the Database Bar.

Using ViewX, you can access features for the items in the database. You can perform a wide range of tasks, including:

  • Create, delete, and organize items in the database
  • Create, remove and modify security settings for items in the database
  • Configure and display Mimics. The Mimics can be animated to display dynamic data that is stored in the database
  • Configure and display Trends that contain data sourced from items in the database
  • Configure the items stored in the database, including database points, reports etc.
  • Access information displays for any item in the database
  • Display an Alarms List that shows alarms for items in the database
  • Display the Events List for items in the database
  • Display Queries Lists for items in the database.

ViewX clients can also be configured to connect to Multiple Databases.


Client Administration Guide - Multiple Databases (ViewX Client - System Connections)

Multiple Databases

A ViewX client can be configured so that it connects to multiple ClearSCADA databases. Each of the ClearSCADA databases runs on a separate ClearSCADA server (or servers) and is completely independent of the other ClearSCADA databases.

Multiple databases are available on ViewX client

To connect to multiple databases, a ViewX client needs to be configured as a ClearSCADA client via the ClearSCADA Client window (see Display the Client Configuration Window). Connections are required for each ClearSCADA database that is to be available to the ViewX client. For example, if a ViewX client is to have access to 3 ClearSCADA databases, you have to configure 3 client connections on the ViewX client - 1 connection for each database.

NOTE: Do not confuse multi-server architectures with multiple databases. A multi-server architecture contains two or more servers that run the same database. In contrast, a ViewX client that accesses multiple databases is accessing several different databases, each of which may be running on a single or multi-server architecture.

If your ViewX client can access multiple ClearSCADA databases, when you log on to ViewX, you will be able to select whether you want to connect to a specific database or every available database.

Choose to connect to one database or every available database.

If you choose to connect ViewX to every available database, you will see each database represented by a system icon in the Database Bar.

If you choose to connect ViewX to a single database, you will only see the chosen database represented in the Database Bar:

By expanding the system icons, you can reveal the hierarchical structures of each of the available databases. You can then access the various information, editing and configuration displays for each database item as required. You can also access information from multiple databases on a single display, for example, Mimics can contain dynamic data from items in different databases.

With a ViewX client that connects to multiple databases, you can:

  • Create, delete, and organize items in any of the available databases
  • Create, remove and modify security settings for items in any of the available databases
  • Configure and display Mimics that are stored in any of the available databases. The Mimics can be animated to display dynamic data from any of the available databases and can display dynamic data from different databases simultaneously
  • Configure and display Trends that contain data sourced from items in any of the available databases. Trends can display data from different databases simultaneously
  • Configure the items stored in any of the available databases, including database points, reports etc.
  • Access information displays for any item in any of the available databases
  • Display an Alarms List that shows alarms relating to items in any available database. The Alarms List can display alarms for multiple systems simultaneously and can be filtered to show individual databases, Groups, items etc. too
  • Display the Events List for an individual database. Events Lists cannot display information from multiple databases simultaneously
  • Display Queries Lists for items stored on one of the available databases. Queries Lists cannot display information from multiple databases simultaneously.

If your ViewX client can access multiple databases, you will see additional options are displayed on those displays that can show information from more than one database simultaneously. You can use the additional options to choose whether the display shows information from a single database or from all databases that are available to the ViewX client. For example, on ViewX clients with access to multiple databases, the Filter window for the Alarms List has a Filter From field. You can use the Filter From field to filter the Alarms List to show alarms from each of the available databases or just one of the databases.

Further Information

Single Database.


Client Administration Guide - Understanding Client - System and Server Advise Connections (ViewX Client - System Connections)

Understanding Client - System and Server Advise Connections

A ViewX client connects to a ClearSCADA server via 2 types of connection:

  • The client - system connection which is established by the client and is used by the client to send requests to the server. The server also uses this connection to respond to the requests from the client.
  • The server advise connection which is established by the server after the client - system connection is established. The server uses the server advise connection to send unsolicited updates to the client, such as alarm data and updates for Mimics.

Using two connections has a major benefit—it reduces the overhead on network resources. As the server can send unsolicited updates to the client via the server advise connection, it means that the client does not have to continuously poll the server for updates. Obviously, this results in less traffic between the client and server which frees up network resources.

Both of the connections are established when ViewX is run on a client. The procedure for establishing the connections is:

  1. ViewX is run on the client.
  2. The client checks which of its incoming ports are available and then chooses one of the ports (the default range of incoming ports is 5500 to 5509, but these can be altered via the Sockets setting during the client configuration see Change the Range of Ports for the Client’s Incoming Data). The port that is chosen is the port that will be used to receive data via the server advise connection.
  3. The client transmits a message to the server via one of its available ports (the client chooses which one of its ports it uses automatically). The transmission is sent to the server’s incoming data port which is port 5481 by default (but this can be changed in the server configuration, see Configure the Main and Backup Connections in the ClearSCADA Guide to Server Administration).

ATTENTION: If the ports in the defined Sockets range are in use by other applications, the client will use another available port. If a firewall is in place between the client and server, this may cause the connection attempt to fail.

  4. When the server receives the transmission from the client, it admits the transmission and establishes the client - system connection. The transmission from the client contains information about the client’s incoming data port and the server uses this information to establish the server advise connection (it is the port chosen in step 2 of this procedure).
  5. The server transmits a message to the client’s incoming data port to establish the server advise connection.

When both the client-server and the server advise connections have been established, the system is shown as 'Online' in ViewX’s Database bar and you can begin to work on the client.

If you have run ViewX and the system remains 'Offline', ClearSCADA may have detected a problem with the client-server connection or the server advise connection. For more information, see Failed Client - System and Server Advise Connections.


Client Administration Guide - Create a New ViewX Client - System Connection (ViewX Client - System Connections)

Create a New ViewX Client - System Connection

You can use the ClearSCADA Client Applet to create a new ViewX client - system connection. You need to create a client - system connection for each outgoing ViewX client connection i.e. every connection that the client uses to send signals to the system server(s).

When you have created a new connection, you will need to configure it so that the client can use it to communicate with the system server(s).

To create a new ViewX client - server connection:

  1. Display the ClearSCADA Client Applet
  2. Select the Add button to display the ClearSCADA Client Configuration window (see Display the Client Configuration Window).
  3. Define the System Name and Type for a ViewX Client - System Connection
  4. Enable or Disable Client Licensing
  5. Define Whether the System is Visible in ViewX
  6. Define the Node Name for a Client - System Connection
  7. Define the Node Cost for a Client - System Connection
  8. Define the Client Compression Settings for a ViewX Client Connection
  9. Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection
  10. Define the TCP/IP Tuning Settings for a ViewX Client - System Connection
  11. Change the Range of Ports for the Client’s Incoming Data
  12. Associate a ViewX Client - System Connection with a Client License.

NOTE: Alternatively, you can create a connection by creating or editing a Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).


Client Administration Guide - Display the ClearSCADA Client Applet (ViewX Client - System Connections)

Display the ClearSCADA Client Applet

You can use the ClearSCADA Client applet to configure the settings at the client end of the connection.

To display the Client applet:

  • Select the Start menu button in Windows, then select the All Programs option followed by the Schneider Electric ClearSCADA option, then the Configure Connections option.
    The Client applet runs. It shows a list of the systems to which the client can connect (if it cannot currently connect to any systems, the list is empty), and several buttons that you can use to access the client connection configuration settings:

NOTE: On Windows Vista, a User Account Control prompt may appear - select Continue on the prompt to allow the ClearSCADA Client applet to run.

The Client applet contains the following buttons:

  • Add—Use to add a system to which the client can connect. You can use the Add button to add:
  • ViewX Client - System connections (see Create a New ViewX Client - System Connection)
  • ViewX Client - Third Party OPC Server connections (see Create a Connection between a ViewX Client and a Third Party OPC Server)
  • Third Party OPC Client - System Connections
  • Third Party ODBC Client - System Connections.

A client can connect to multiple systems (it can connect to a maximum of 60 servers).

  • Properties—Use to edit a system.
  • For ViewX clients, see Edit an Existing ViewX Client - System Connection.
  • For Third Party OPC Clients, see Third Party OPC Client - System Connections.
  • For Third Party ODBC Clients, see Third Party ODBC Client - System Connections.
  • Remove—Use to remove a system. If you remove a system, the clients are no longer able to access it.
  • Move Up and Move Down—Use to change the order of systems when multiple systems are available. The order in which the systems are shown in the Client Applet is the same order that is used when the systems are displayed in the Server Status Tool, Server Configuration Tool and also in the various Explorer Bars in ViewX, such as the Database Bar and OPC Data Bar.

The system at the top of the list is shown at the top of the various hierarchical displays, with the other systems following in order from top to bottom. You can change the order by selecting a system in the list, then using the Move Up button to promote the system or the Move Down to demote the system as required.

  • Enable or Disable—Use to enable or disable a connection to a system.
  • Set as Default—Use to define the default system when multiple systems are available.
  • TCP/IP Tuning—Use to define the port settings (see Define the TCP/IP Tuning Settings for a ViewX Client - System Connection)
  • Sockets—Use to define the range of sockets that the client uses to receive data from the server (you can define the sockets for each client-server connection). For more information, see Change the Range of Ports for the Client’s Incoming Data.
  • Licenses—Use to access the Client License window. The Client License window displays information about the current client license and allows you to associate the client with a different client license file if required (see Associate a ViewX Client - System Connection with a Client License)
  • Close—Use to close the Client applet.


Client Administration Guide - Display the Client Configuration Window (ViewX Client - System Connections)

Display the Client Configuration Window

To add or edit a connection between a client and a system, you need to use the Client Configuration window. This window contains the settings that allow you to define the properties of the client - system connection, including the type of connection and the node settings.

To display the Client Configuration window:

  1. Display the ClearSCADA Client Applet
  2. Either:
  • Select the Add button to create a new connection between the client and a system.
    The Client Configuration window is displayed.

Or:

  • In the list on the Client applet, select the connection for the system you want to edit, then select the Properties button.
    The Client Configuration window is displayed.
  3. Use the Client Configuration Window to define the client settings:

For ViewX clients, see:

  • Define the System Name and Type for a ViewX Client - System Connection
  • Enable or Disable Client Licensing
  • Define Whether the System is Visible in ViewX
  • Define the Workstation Name for the ViewX Client
  • Define the Node Name for a Client - System Connection
  • Define the Client Compression Settings for a ViewX Client Connection
  • Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection.

For Third Party OPC clients, see Third Party OPC Client - System Connections.

For Third Party ODBC clients, see Third Party ODBC Client - System Connections.

  4. Select the OK button to confirm your configuration selections.


Client Administration Guide - Define the System Name and Type for a ViewX Client - System Connection (ViewX Client - System Connections)

Define the System Name and Type for a ViewX Client - System Connection

Each system to which the client can connect needs to be named via the Client Configuration window. The System Name that is allocated is the name that will be used to label the system within ViewX on the client; it does not rename the system at the server or on any other client.

Typically, each system is given the same name on each of the clients, but you can choose to alter the names on a per client basis if required. For example, 2 clients can access the same database, but the name of the system could be different on each client (even though both clients access the same database).

Each connection to a system also needs to have a Type that defines which system data is available to the client.

To define the system name and type for a system on a ViewX client:

  1. Display the Client Configuration Window for the connection that you want to add or edit.
  2. Enter the name of the system in the System Name field. The name that you enter will be shown as the name of the system in ViewX on the client that you are configuring.
  3. Use the Type combo box to choose to the type of system to which the client will connect. This setting determines which features are available via the client and you can choose from:
  • ClearSCADA Server—Allows the client to access the ClearSCADA database, OPC data, OPC alarm and event data, and OPC historic data.
  • OPC Data Server—Allows the client to access OPC data.
  • OPC Alarm Server—Allows the client to access OPC alarm and event data.
  • OPC Historic Server—Allows the client to access OPC historic data.

For a ViewX client, you should select the ClearSCADA Server option as this setting provides access to the ClearSCADA database(s), OPC data, OPC alarm and event data, and OPC historic data. The other options only provide access to a specific type of OPC data.

If you require more than one type of OPC server and do not want to use the ClearSCADA Server functionality, you should configure separate systems for each type of OPC server.

NOTE: You can also define the System Name and Type settings by editing the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).

Further Information

Define the Node Name for a Client - System Connection

Define the Client Compression Settings for a ViewX Client Connection

Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection.


Client Administration Guide - Enable or Disable Client Licensing (ViewX Client - System Connections)

Enable or Disable Client Licensing

ClearSCADA systems can be licensed at the ViewX client(s) or at the server. There are certain factors you should consider when deciding where to enable licensing:

  • If the client is a work station that needs continuous access to the system, we recommend that you license at the client i.e. enable client licensing. When a client has licensing enabled, it can connect to any system to which it has a connection and a valid license. It can connect at any time and does not need to use a ‘floating license’ from the server (the server has a limited number of ‘floating licenses’ that it can allocate to clients). By using a client-side license, you stop the client from using any of the server’s ‘floating licenses’ which are designed to be allocated to clients that require occasional access.
  • Licensing at the client also reduces the amount of configuration required as a new client can have its license configured locally. With server-side licenses, adding a new client means that a license for the client needs to be configured on each individual server. Setting up these individual licenses can take considerable time and effort as servers are usually some distance apart.
  • If the client is a work station that only needs occasional access to the system, we recommend that you license at the server and disable client licensing. This will mean that the client will request a 'floating license' from the server when the client needs to connect with the system. If the server has a ‘floating license’ available, it will allow the client to access the system. However, if the server has its licenses in use by other client work stations, the client will be unable to connect to the system.

Ultimately, the type of license file that is supplied by Schneider Electric determines which of the licensing methods you need to use—you can only use client licensing if you are supplied with a client license file; you can only use server licensing if you are supplied with a server license file.

To enable or disable client licensing:

  1. Display the Client Configuration Window for the connection that you want to add or edit.
  2. Either:
  • Select the Use Client Licensing check box to enable client licensing for the selected client. The client will use its own license rather than request a ‘floating license’ from the server. This option should only be used with clients that are designed to access the system continuously.

Or:

  • Clear the Use Client Licensing check box to disable client licensing for the selected client. The client will request a ‘floating license’ from the server when it attempts to connect to the system. This option should only be used with clients that are designed to access the system occasionally.

When you have enabled or disabled client licensing for the client, you can proceed to define the other client configuration settings. However, before the client license feature can be used, you will need to associate the client with the client license file (see Associate a ViewX Client - System Connection with a Client License).

NOTE: You can also define the Use Client Licensing setting by editing the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).


Client Administration Guide - Define Whether the System is Visible in ViewX (ViewX Client - System Connections)

Define Whether the System is Visible in ViewX

You can configure a client - system connection so that although it is fully functional, it is ignored by ViewX. This is useful when Third Party OPC clients need to access the system via the client - system connection, but the system is not used by ViewX.

To define whether the system is visible in ViewX, you need to use the Visible in ViewX check box on the Client Configuration window:

  1. Display the Client Configuration Window
  2. Either:
  • Check the Visible in ViewX check box to set ViewX to connect to the system via the client - system connection. The system will be available in ViewX on the client, which means operators, engineers and administrators can use the client to interact with the system.
  • Clear the Visible in ViewX check box to stop ViewX from providing access to the system via the selected connection. If you clear the check box, the connection will be operational and can be used by other OPC client applications but will not be used by ViewX (ViewX will ignore the system on this connection).

NOTE: You can also define the Visible in ViewX setting by editing the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).

Further Information

Third Party OPC Client - System Connections.


Client Administration Guide - Define the Workstation Name for the ViewX Client (ViewX Client - System Connections)

Define the Workstation Name for the ViewX Client

You can use the Client Configuration window to define the Workstation Name for a ViewX client. The Workstation Name can be any string and is used to identify a ViewX client - system connection (you can define 1 workstation name for each connection between the client and a system).

The Workstation Name is optional and can be any string value. ClearSCADA uses the Workstation Name to identify a client when you use the Set Responsibility redirection action. For this reason, you only need to define a Workstation Name if the ViewX client is to have exclusive access to the Acknowledge Alarms action for an alarm (when used in conjunction with a Set Responsibility redirection action).

Set Responsibility redirection actions allow you to restrict access to an alarm’s Acknowledge Alarms action. Access can be limited to a specific User Account, User Group, or ViewX client. If the Acknowledge Alarms action for an alarm is only to be available to users who are logged on to a specific ViewX client, the following configuration is required:

  • The ViewX client that is to provide access to the Acknowledge Alarms action has to have a Workstation Name defined in its client configuration settings.
  • In the configuration of the Set Responsibility redirection action, the Workstation setting has to match the Workstation Name for the ViewX client (that is to have access to the Acknowledge Alarms action).

By defining a Workstation Name for a ViewX client, you allow it to be chosen as the Workstation for a Set Responsibility redirection action. If a Set Responsibility redirection action has a Workstation setting that matches the Workstation Name you define for your ViewX client, the alarm associated with the Set Responsibility redirection action can only be acknowledged on your ViewX client.

To define the Workstation Name of your ViewX client:

  1. Display the Client Configuration Window.
  2. Enter the required workstation name in the Workstation Name field. The Workstation Name can be any string.
  3. Select the OK button to apply the changes.

NOTE: You can also define the Workstation Name setting by editing the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).

Further Information

Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection.


Client Administration Guide - Define the Node Name for a Client - System Connection (ViewX Client - System Connections)

Define the Node Name for a Client - System Connection

A client PC can use the client - system connection to connect to a maximum of 4 servers in a single system. The number of servers to which a client needs to connect varies according to the architecture of the system, for example, a Hot-Standby system has 2 servers (Main and Standby) whereas a Triple Standby system with a Permanent Standby has 4 (the Main, Standby 1, Standby 2, and the Permanent Standby).

You need to use the Node settings on the Client Configuration window to define which servers the client can connect to via the client - server connection. There is a Node tab for each server.

The Node tabs should be used as follows:

  • Lone Server—Use the Node A tab to define the connection between the client and the server.
  • Hot-Standby Pair—Use the Node A tab to define the connection between the client and the first server, and the Node B tab to define the connection between the client and the second server.
  • Hot-Standby Pair with 1 Permanent Standby—Use the Node A tab to define the connection between the client and the first server, and the Node B tab to define the connection between the client and the second server. Use the Node C tab to define the connection between the client and the permanent standby server.
  • Hot-Standby Pair with 2 Permanent Standbys—Use the Node A tab to define the connection between the client and the first server, and the Node B tab to define the connection between the client and the second server. Use the Node C tab to define the connection between the client and the first permanent standby server, and the Node D tab to define the connection between the client and the second permanent standby server.
  • Hot-Standby Pair (Dual Ethernet)—Use the Node A and Node B tabs to define the connections between the client and one server (each Node tab defines the settings for a network card), and use the Node C and Node D tabs to define the connections between the client and the alternate server.

For Dual Ethernet arrangements, you have to define the Node Name as an IP address so that the client can differentiate between the network cards.

  • Triple Standby—Use the Node A tab to define the connection between the client and the first server. Use the Node B and Node C tabs to define the connections between the client and the second and third servers.
  • Triple Standby with Permanent Standby—Use the Node A tab to define the connection between the client and the first server. Use the Node B and Node C tabs to define the connections between the client and the second and third servers. For the Permanent Standby server, use the Node D tab.

To define the node settings for a client - system connection:

  1. Display the Client Configuration Window for the connection that you want to add or edit.
  2. Select the tab for the Node that you want to configure. We recommend that you use the Node tabs in order, for example, if you need to define 2 Nodes, use the Node A and Node B tab and ignore the Node C and Node D tab.
  3. Define the Node Name setting. You have to define the node name or IP address of the node (the server to which the client will connect). If you leave the Node Name setting blank, the system will use the IP Address of the computer on which you are configuring the client as the Node Name setting.

Enter the name or IP address of the server node:

Either:

  • Use the browse button next to the Node Name field to display a browse window. Use the browse window to select the computer (Node) that is the server, then select the OK button to confirm the selection.

Or:

  • In the Node Name field, type the name of the server or the server's IP address.

ATTENTION: For dual Ethernet arrangements, you have to enter the IP addresses for the nodes.

When you have defined the Node Name for the client - system connection, you will need to:

  • Define the Node Cost for a Client - System Connection
  • Define the Client Compression Settings for a ViewX Client Connection
  • Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection.

NOTE: You can also define the Node Name setting by editing the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).


Client Administration Guide - Define the Node Cost for a Client - System Connection (ViewX Client - System Connections)

Define the Node Cost for a Client - System Connection

Each client - system connection is allocated a cost number that is used by the system to determine the order of preference for the connections—the connection with the lowest cost is the preferred connection. Usually, the cost indicates the efficiency of the connection, with the more efficient connections having the lowest cost numbers.

When a client connects to a server, it automatically connects to the server that has the lowest Node Cost value and is available. This sets the client to use the most suitable route to the system. If there are two connections that have the same Node Cost, the client will connect to the server that is Main.

To define the Node Cost for a client - system connection, you need to have an appreciation of the type and efficiency of each connection:

  • If the connections are via a Local Area Network (LAN), you should set the Node Cost of each connection to the same amount. This means that a client only connects to the Main server.
  • If there are Wide Area Network (WAN) connections, you should set the Node Cost to indicate the amount of bandwidth that is available for the connection. The connections that provide the lowest amount of bandwidth are the least efficient and so should have the highest Node Cost values.

You can use any numbers to define the Node Costs, but the lowest number in your chosen range must be allocated to the connection that provides the most suitable route to the server. You can allocate subsequent numbers to the next most efficient connection (the least efficient connection will have the highest number in the range). For more information on how the Node Cost settings are used, please refer to the examples at the end of this section.

To define the Node Cost for a client - system connection:

the node settings for a client - system connection:

  1. Display the Client Configuration Window for the connection that you want to add or edit.
  2. Select the tab for the Node that you want to configure.
  3. Use the Node Cost field to define the cost. The cost is used to define the relative efficiency of each connection. You can enter any number, but remember that the number will be used as part of range and will be compared to the Node Cost numbers of any other connections
    .
  4. Select the OK button to confirm your selections and close the Client Configuration window.

NOTE: You can also define the Cost setting by editing the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).

Examples of Node Costs:

Hot-Standby Pair Connected via a Wide Area Network (WAN)

A system has a client connected to one server via a Local Area Network connection (LAN) and to the alternate server via a Wide Area Network connection (WAN). The LAN connection is the preferred connection as it is local and is not restricted by the available bandwidth.

In the diagram above, there are two clients. One client is connected to server A via a LAN and to server B via a WAN. The other client is connected to server B via a LAN and server A via a WAN.

For the client with a LAN connection to server A, the LAN connection has a cost of 2. The connection to server B has a cost of 3—the cost is higher as it is not the preferred connection. When the client is started, it will attempt to connect to server A via the LAN in preference to connecting to server B via the WAN.

For the client with a LAN connection to server B, the LAN connection has a cost of 2. The connection to server A has a cost of 3—the cost is higher as it is not the preferred connection. When the client is started, it will attempt to connect to server B via the LAN in preference to connecting to server A via the WAN.

Hot-Standby Pair with Permanent Standby Arrangement

A system has a client (Client A) connected to a permanent standby server (P.Standby 1) and a server (Server A) via a Local Area Network (LAN). The client is also connected to another server (Server B) via a Wide Area Network (WAN).

Another client (Client B) is connected to Server B and a different permanent standby server (P.Standby 2) via a LAN. Client B is also connected to Server A via a WAN.

For Client A, the preferred connection is to P.Standby 1 as this reduces the load on Server A. The connection to P.Standby 1 has the lowest cost (cost 1). The Server A connection has the next lowest cost as it should be used in preference to the WAN connection, but not in preference to the P.Standby 1 connection.

For Client B, the preferred connection is to P.Standby 2 as this reduces the load on Server B. The connection to the P.Standby 2 has the lowest cost (cost 1). The Server B connection has the next lowest cost as it should be used in preference to the WAN connection, but not in preference to the P.Standby 2 connection.

Dual Ethernet Hot-Standby Pair Arrangement

A Hot-Standby Pair arrangement has both servers connected via a dual Ethernet network. This provides redundancy in the event of a network failure.

The cost settings for the systems vary depending on the amount of bandwidth available.

For symmetrical networks (networks with the same amount of bandwidth available), the cost should be equal i.e. both connections should have the same cost settings.

For asymmetrical networks (where one network has more bandwidth available than the other), the network with the most bandwidth available should have the lowest cost setting.

The diagram below shows how the cost settings for an asymmetrical dual Ethernet network could be configured.

The network with a cost of 2 is used in preference to the network with a cost of 3.

Triple Standby Arrangement

The Cost settings for connections to servers in a triple standby arrangement are dependent on the types of connection.

For a triple standby arrangement where the clients connect to the servers via a Local Area Network (LAN), the cost settings for each system are the same. This sets the clients to only connect to the server that is Main.

If the clients are connected to Server A or B via a Wide Area Network (WAN), the WAN connection will have a higher cost than the other connections. As a result, the LAN connections are used in preference to the WAN connection.


Client Administration Guide - Define the Client Compression Settings for a ViewX Client Connection (ViewX Client - System Connections)

Define the Client Compression Settings for a ViewX Client Connection

You can use the Compress check box on the Client Configuration window to enable and disable data compression for the client - system connection.

The advantage of having compression enabled is that it reduces the amount of data that has to be sent, and so the data can be transferred more quickly. However, compression makes greater use of the processor and so there is an overhead on the server and client. For this reason, compression is usually only enabled on systems that are connected via slow networks (low bandwidth, typically less than 10Mb per second).

If you are aware that your system has clients with low bandwidth connections, you should also check that your Mimics, Lists and Trends are as simple as possible as complex documents require more data to be sent across the connection.

When using the Compress feature, you need to consider which servers in your system architecture are needed to compress and decompress the data (each server in your system has a Compress feature).

You can quantify the effects of the compression feature by examining the Server>Links statistics on the Server Status Tool see Links (Server) in the ClearSCADA Guide to the Server Status Tool.

To enable or disable the compression feature for a client:

  1. Display the Client Configuration Window.
  2. Select the Node tab for the required client - system connection.
  3. Select the Compress check box to enable the compression feature or clear it to disable the feature.
  4. Select the OK button to confirm your choice.

NOTE: You can also define the Compression setting by editing the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).


Client Administration Guide - Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection (ViewX Client - System Connections)

Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection

In this section, we explain how to use the Advanced Settings window to define the Port Number, Timeouts, and Poll Interval for each Node on a ViewX client - system connection. If you are configuring a Third Party OPC client - system connection or a Third Party ODBC client - system connection, you can use the Advanced Settings window in the same way as described here.

You can use the Advanced Settings window, accessed via the Client Configuration window, to change the port number for the connection as well as its timeout and interval settings. While it is unlikely that you will need to adjust the default timeout and interval settings, you may need to make adjustments on systems that are especially small or large. For example, on small systems you may choose to reduce the timeouts to improve response times and on some larger systems you may need to increase the default time settings.

The time settings you need to enter will vary according to the amount of network traffic and the capabilities of your network. As a general rule, you should set the timeouts to be slightly more than the worst-case scenario response time for your network.

To change the Port Number, Timeouts, or Poll Interval settings:

  1. Display the Client Configuration Window.
  2. Select the Node tab for the required client - system connection.
  3. Select the Advanced button to display the Advanced Settings window.
  4. Alter the settings as required:
  • Port—Enter the number of the port that the client uses for outgoing communications to the server. The port number has to match the port number shown for the 'Database Running on' status on the Info display of the ClearSCADA Server Status Tool (see General System Status Information in the ClearSCADA Guide to the Server Status Tool).
  • Connect Timeout—The amount of time, in milliseconds, in which the client can attempt to make a connection. If the client cannot establish a connection to the server within this time, ClearSCADA deems the connection to have failed.
  • Request Timeout—The amount of time, in milliseconds, in which the client can request data from a server. If the server has not responded by the end of this time, ClearSCADA deems that the request has failed.
  • Disconnect Timeout—The amount of time, in milliseconds, in which the client can attempt to terminate a connection to the server. If a disconnection has not occurred by the end of this time, the disconnection is deemed to have failed. The Disconnect Timeout is used when the network connection can be detected, but the client cannot disconnect from the system.
  • Poll Interval—The amount of time, in seconds, that can elapse between each update request sent from the client to the server. The latest data is requested in every poll.
  • Poll Timeout—The amount of time, in milliseconds, that the client will wait for a response to a poll request from the server. If the server does not respond within the defined time, the quality of the data that was requested changes from 'Good' to 'Bad'.
  5. Select the OK button to confirm the settings and close the Advanced Settings window.

NOTE: You can also define the Port and Connection settings by editing the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection).


Client Administration Guide - Define the TCP/IP Tuning Settings for a ViewX Client - System Connection (ViewX Client - System Connections)

Define the TCP/IP Tuning Settings for a ViewX Client - System Connection

In this section, we explain how to use the TCP/IP Tuning setting to determine how TCP/IP manages communications when a ViewX client - system connection has been lost.

NOTE: If you are configuring a Third Party OPC client - system connection or a Third Party ODBC client - system connection, you can use the TCP/IP Tuning setting in the same way as described in this section.

You can use the TCP/IP Tuning button on the Client Configuration window to access the Transmission Control Protocol/Internet Protocol settings. These settings determine how TCP manages the transmission of data over the client - system connection.

Transmission Control Protocol/Internet Protocol (TCP/IP) is used to set clients to send data to a server in a sequence. This means that server receives will receive data from the client in the same order and sequence in which it was originally sent.

By using the TCP/IP Tuning settings on the Client Configuration window, you can define:

  • How TCP/IP manages the communications when the client - system connection has been lost
  • The number of times TCP/IP will attempt to resend failed transmissions over a healthy, established client - system connection.

ATTENTION: You should only change the TCP/IP settings if you have been advised to do so by Schneider Electric staff. Changing the TCP/IP settings will affect every application on the client, not just ClearSCADA.

If the client is experiencing long timeouts or is unable to connect, you may be advised to change the TCP/IP settings by a member of Schneider Electric staff. If you are advised to change the settings, you should:

  1. Display the Client Configuration Window.
  2. Select the system that has the connection for which you want to define the TCP/IP Tuning settings.
  3. Select the TCP/IP Tuning button on the Client Configuration window to display the TCP/IP Tuning window.
  4. Enter the maximum number of times TCP will attempt to make a connection between the client and the server. If a connection is not made within the defined limit, TCP regards the connection as failed. TCP will make no further connection attempts.
  5. In the Maximum Data Retransmissions field, enter the maximum number of times TCP will attempt to re-transmit data that has not received an acknowledgment (in normal circumstances, the client will send data to the server, and the server will respond with an acknowledgment before sending any further data). If TCP has not received an acknowledgment within the defined limit, it will make no further attempts to send the data segment and will close the connection.
  6. Select the OK button to confirm or use the Default button to restore the default settings. You can also use the Cancel button to abort any changes you have made.


Client Administration Guide - Change the Range of Ports for the Client's Incoming Data (ViewX Client - System Connections)

Change the Range of Ports for the Client’s Incoming Data

In this section, we explain how to use the Sockets window to change the range of ports for the ViewX Client’s incoming data. If you need to change the range of ports for a Third Party OPC or Third Party ODBC client, you can use the Sockets window settings in exactly the same way as described here.

You can use the ClearSCADA Client applet to change the range of ports that can be used for the client’s incoming data (one of the ports in the range will be used to receive data via the server advise connection). By default, the range of ports is 5500 to 5509 inclusive which allows a maximum of ten client applications per client machine.

You may need to change this range if the ports 5500 to 5509 are already allocated to other applications or you need to increase or reduce the number of client applications permitted on the client.

To change the range of ports that can be used for the client’s incoming data:

  1. On the client PC, Display the ClearSCADA Client Applet
  2. Select the system that has the connection for which you want to alter the port settings.
  3. Select the Sockets button to display the Sockets window.
  4. Enter the new port range (lowest port number in the left-hand field, highest port number in the right-hand field).
  5. Select the OK button to confirm your selection and close the Sockets window.

Remember that if you are using a firewall between the client and server, you will need to configure the firewall to allow the server to send data to the client via the ports in the defined range.

Further Information

Check which Ports are Available on the Client


Client Administration Guide - Associate a ViewX Client - System Connection with a Client License (ViewX Client - System Connections)

Associate a ViewX Client - System Connection with a Client License

In this section, we explain how to use the Client Licensing window to associate a ViewX Client - System connection with a valid license file. For information on how to use this window to associate Third Party OPC and Third Party ODBC connections with client licenses, please refer to Associate a Third Party OPC Client - System with an OPC License and Associate a Third Party ODBC Client - System with a Data Access License.

If you have enabled client licensing (see Enable or Disable Client Licensing), you will need to associate the ViewX client - system connection with a client license file. Supplied with your system, the client license file defines:

  • The amount of time for which the client can connect to systems via the client - system connection. When this time period passes, the license expires and a new license will be required
  • The versions of ViewX to which the client can connect via the client - system connection
  • The number of ViewX systems to which the client can connect via the client - system connection
  • The number of OPC systems to which the client can connect via the client - system connection
  • The number of data access systems to which the client can connect via the client - system connection.

The settings for your client license are determined when you purchase ClearSCADA. If you contact the sales representative that sold the product to you, they will be able to provide additional detail about the specific limits of your license.

To associate your client license with a client - system connection:

  1. Display the Client Configuration Window.
  2. Select the connection with which you want to associate the client license.
  3. Select the Licenses button on the Client Configuration window to display the Client Licensing Window.
  4. Use the browse button next to the License File field to display a browse window.
  5. Use the browse window to locate the client license file that was supplied with your system, then select the OK button to confirm your selection.
    The client license file is now associated with your client - system connection and its details are shown in the Client Licensing window.
  6. Select the OK button to close the Client Licensing window.


Client Administration Guide - Edit an Existing ViewX Client - System Connection (ViewX Client - System Connections)

Edit an Existing ViewX Client - System Connection

You can use the ClearSCADA Client Applet to change the configuration of an existing ViewX client - system connection. This is useful when you need to alter the way the client - system connection works, for example, you may need to reconfigure the port settings to avoid clashes with other applications.

The settings for a ViewX client - system connection work in exactly the same way as when used during the initial configuration of the client - system connection.

To edit an existing ViewX client - server connection:

  1. Display the ClearSCADA Client Applet
  2. Select the client - system connection that you want to edit.
  3. Select the Edit button to display the ClearSCADA Client Configuration window (see Display the Client Configuration Window).
  4. Define the System Name and Type for a ViewX Client - System Connection
  5. Enable or Disable Client Licensing
  6. Define Whether the System is Visible in ViewX
  7. Define the Node Name for a Client - System Connection
  8. Define the Node Cost for a Client - System Connection
  9. Define the Client Compression Settings for a ViewX Client Connection
  10. Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection
  11. Define the TCP/IP Tuning Settings for a ViewX Client - System Connection
  12. Change the Range of Ports for the Client’s Incoming Data
  13. Associate a ViewX Client - System Connection with a Client License.

NOTE: Alternatively, you can edit the Systems.xml file manually (see Use the Systems.xml File to Set Up a ViewX Client Connection)


Client Administration Guide - Use the Systems.xml File to Set Up a ViewX Client Connection (ViewX Client - System Connections)

Use the Systems.xml File to Set Up a ViewX Client Connection

When you use the Client Configuration Applet to set up a client connection, the settings you put in place are stored in the systems.xml file and are used to set up the client connection. But you don’t have to use the Client Configuration Applet to put these settings in place - you can edit the systems.xml file manually.

The benefit of editing the systems.xml file manually is that it makes it easier and quicker to perform system administration on multiple clients - you can copy the file to other clients and quickly make adjustments without having to run the Client Configuration Applet on each client. However, you need to be careful because if you make an error in the file and the syntax cannot be recognized, every application that uses the systems.xml file will be unable to connect. For example, if a systems.xml file is edited incorrectly and then distributed to 20 clients, those clients will be unable to connect to the system as they will all be using a systems.xml file that is invalid. So if you are editing a systems.xml file, you need to check that it has valid syntax.

In this section, we explain:

  • Systems.xml File Location
  • Systems.xml File Syntax
  • Systems.xml File Attributes.

We also describe how to Configure ViewX Heads to Access Different Servers.


Client Administration Guide - Systems.xml File Location (ViewX Client - System Connections)

Systems.xml File Location

By default, the Systems.xml file is located at:

C:\Documents and Settings\All Users\Application Data\SchneiderElectric\ClearSCADA

(Windows XP)

Or:

C:\ProgramData\SchneiderElectric\ClearSCADA

(Windows Vista and Windows 7)

However, the Systems.xml file may have been moved to another location on your PC. If you cannot locate your Systems.xml file, you can find it by using the Search facility in Windows.


Client Administration Guide - Systems.xml File Syntax (ViewX Client - System Connections)

Systems.xml File Syntax

For correct syntax, the systems.xml file has to use this hierarchical order of elements:

<Systems>

<Default System>

<System>

<Server>

<opcdaclsid>

</opcdaclsid>

<opchdaclsid>

</opchdaclsid>

<opcaeclsid>

</opcaeclsid>

</Server>

</System>

</Systems>

Many of the elements have attributes that define the settings for the client connection (see Systems.xml File Attributes).


Client Administration Guide - Systems.xml File Attributes (ViewX Client - System Connections)

Systems.xml File Attributes

When you use the Client Configuration applet to configure a client - system connection, the settings you define are saved within the auto-generated Systems.xml file as attributes and values. If you create or edit a Systems.xml file manually, you can include the attributes in your file and also define their values.

Many of the elements in a Systems.xml file have attributes for which you can set values. The attributes correspond to the settings on the Client Configuration applet and the various displays you can access via the Client Configuration applet, such as the Advanced Settings window.

For each of the elements, you need to define or edit the attributes correctly:

  • <Systems>—The <Systems> element has no attributes.
  • <Default System>—Defines the name of the default system. If a system is not defined in the <System> attributes, the client will connect to the system specified as the Default System instead. The <Default System> corresponds to the Set as Default setting on the ClearSCADA Client Applet.

For the <Default System> element, you need to define the name of the default system in the following format:

<Default System="name of system" />

Where name of system is the name of the default system, for example, <Default System="Main" /> sets the default system to the system named Main.

  • <System>—Has attributes that correspond to the settings on the ClearSCADA Client Configuration window:
  • Name—The name of the system. This required string value corresponds to the System Name setting on the Client Configuration window (see Define the System Name and Type for a ViewX Client - System Connection).
  • Type—The type of system to which the client will connect. This required string value matches the Type setting on the ClearSCADA Client Configuration window and can be: ClearSCADA Server, OPC Data Server, OPC Historic Server, or OPC Alarm Server (see Define the System Name and Type for a ViewX Client - System Connection).
  • Enabled—Defines whether the system is online (enabled) or offline (disabled). This optional Boolean value corresponds to the Disable setting on the ClearSCADA Client Applet.
  • VisibleinViewX—Defines whether the client connection can be detected by ViewX. In some circumstances, you may want the client connection to only be available to Third Party OPC clients and not ViewX clients. This optional Boolean value corresponds to the Visible in ViewX setting on the Client Configuration window (see Define Whether the System is Visible in ViewX).
  • Clientlicensing—Defines whether the client uses client licensing. This optional Boolean value corresponds to the Use Client Licensing setting on the ClearSCADA Client Configuration window. When it is True, client licensing is enabled; when it is false, client licensing is disabled. For more information, see Enable or Disable Client Licensing.
  • WorkstationName—The workstation name of the client. This optional string value corresponds to the Workstation Name setting on the Client Configuration window (see Define the Workstation Name for the ViewX Client).
  • <Server>—Has attributes that correspond to the Node tab settings on the ClearSCADA Client Configuration window and the settings on the Advanced Settings window:
  • Name—This optional string allows you to define the name of the server node. This attribute corresponds to the Node Name setting (see Define the Node Name for a Client - System Connection).
  • Cost—This optional integer allows you to define the node cost (which is used by ClearSCADA to determine the order of preference for the client’s connections). This attribute corresponds to the Node Cost setting (see Define the Node Cost for a Client - System Connection).
  • Port—This optional integer allows you to define the number of the port that the client uses for outgoing communications to the system server. This attribute corruptions to the Port setting (see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection)
  • Compress—This optional Boolean allows you to define whether data compression is enabled (True) or disabled (False) for the client - system connection. This attribute corresponds to the Compress setting (see Define the Client Compression Settings for a ViewX Client Connection).
  • DisconnectTimeout—This optional integer allows you to define the amount of time, in milliseconds, in which the client can attempt to terminate a connection to the server. This attribute corresponds to the Disconnect Timeout setting (see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection).
  • ConnectTimeout—This optional integer allows you to define the amount of time, in milliseconds, in which the client can attempt to make a connection to the server. This attribute corresponds to the Connect Timeout setting (see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection).
  • RequestTimeout—This optional integer allows you to define the amount of time, in milliseconds, in which the client can request data from the server. This attribute corresponds to the Request Timeout setting (see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection).
  • PollInterval—This optional integer allows you to define the amount of time, in seconds, that can elapse between each update request sent from the client to the server. This attribute corresponds to the Poll Interval setting (see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection).
  • PollTimeout—This optional integer allows you to define the amount of time, in seconds, that the client will wait for a response to a poll request from the server. This attribute corresponds to the Poll Timeout setting (see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection).

When you use the ClearSCADA Client Configuration Tool to configure a connection, the resulting Systems.xml file contains auto-generated <opcdaclsid>, <opchdaclsid>, and <opcaeclsid> elements. These elements can allow Third Party OPC clients to connect to a system and can only be included as part of a ClearSCADA generated Systems.xml file. You cannot include them in manually edited Systems.xml files - you should use the ClearSCADA Client Configuration Tool to configure Third Party OPC Client connections (see Third Party OPC Client - System Connections).

Example: Systems.xml file for a ViewX Client with Connections to 2 Servers

The following example shows the contents of a valid Systems.xml file for a ViewX client that is connected to a single logical database called "Main". The logical database "MAIN" is implemented on two servers called "TAPC04" and "TAPC06" respectively:

<Systems>
<Default system="MAIN"/>
<System name="MAIN" type="ClearSCADA" enabled="true" visibleInViewX="true" clientLicensing="true" workstationName="CentralSite Area C PC3">
<Server name="TAPC04" cost="6" port="5481" compress="false" connectTimeout="30000" requestTimeout="120000" disconnectTimeout="30000" pollInterval="10" pollTimeout="15000">
</Server>
<Server name="TAPC06" cost="8" port="5481" compress="false" connectTimeout="30000" requestTimeout="120000" disconnectTimeout="30000" pollInterval="10" pollTimeout="15000">
</Server>
</System>
</Systems>


Client Administration Guide - Configure ViewX Heads to Access Different Servers (ViewX Client - System Connections)

Configure ViewX Heads to Access Different Servers

If you are using a ViewX client that has multiple heads (see Multi-Head ViewX Clients), you can configure each head to access a different server. To do this, you need to configure the heads to use different Systems.xml files. For example, if you have a client with two heads and you want Head 1 to access a system named "CPLX 1" and you want Head 2 to access a server named "CLPX 2", you need to create an additional XML file called "SystemsCPLX2.xml". Head 1 will use the default Systems.xml file and Head 2 will use the newly created SystemsCPLX2.xml file.

To configure each head to use different Systems.xml files, you need to amend the shortcuts for your heads (you should have a desktop shortcut for each head, as described in Multi-Head ViewX Clients). For each shortcut, you need to add:

/Systems:"<Filename>"

Where <Filename> is the full location and name of the Systems.xml file that is to be used by the head.

Example:

A shortcut is created for Head 1. The shortcut is configured to have the following Target:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /head:1

When selected, the shortcut will cause an instance of ViewX to run on Head 1. The Head 1 instance of ViewX will use the default Systems.xml file as no other Systems.xml file has been specified in the shortcut.

A shortcut is created for Head 2. The shortcut is configured to have the following Target:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /head:2 /Systems:"E:\SystemsCPLX2.xml"

When selected, this second shortcut will cause an instance of ViewX to run on Head 2. The Head 2 instance of ViewX will use the SystemsCPLX2.xml file that is defined in the Target instead of the default Systems.xml file.

Further Information

Use the Systems.xml File to Set Up a ViewX Client Connection.


Client Administration Guide - Check which Ports are Available on the Client (ViewX Client - System Connections)

Check which Ports are Available on the Client

You can use Microsoft Windows to access information about the ports being used by the applications on your client. This is useful if you suspect that multiple applications are attempting to use the same ports on your client.

When you have identified the ports that are being used by the active (running) programs on your client, you can define a more appropriate range of ports in the client’s Sockets settings. This will stop ViewX from attempting to use ports that are used by other programs.

NOTE: The default range of ports used by ViewX (5500 to 5509) are usually appropriate and rarely need to be changed. However, if you suspect another program is using these ports, you will need to check which ports are being used and then change the Sockets settings for the client if required.

To check which ports are being used by the non-ViewX programs that are currently running on your client:

  1. On the client PC, check that ViewX is not running (close it if it is).
  2. Run the command prompt in Windows
  3. Enter the following at the prompt:
netstat -n -a

  4. Press the Enter key.
    The command prompt displays a list of the ports that are currently in use.
  5. Examine the entries in the list. The entries that have a Proto of TCP and State of LISTENING are the local ports that are in use. You can see the actual port numbers by viewing the entries in the Local Address column: the last part of the address is the port number, for example, 0.0.0.0:445 means port 445 is in use.
  6. Make a note of the ports that are being used so that when you change the sockets settings, you can choose a range that is available.
  7. Use the ClearSCADA Client applet to change the port sockets used by ViewX on the client if required (see Change the Range of Ports for the Client’s Incoming Data).


Client Administration Guide - Check the Status of the Client - System and Server Advise Connections (ViewX Client - System Connections)

Check the Status of the Client - System and Server Advise Connections

You can use the Server Status Tool to examine the status of the client - system and server advise connections. By examining the current status of a connection, you can determine whether the connection is working as expected and you can see if the connection is currently being used for communications.

The Server Status Tool is available for use on the server PC. For more information on how to display it, see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool.

To view the status of a server advise connection (the connection the server uses to send unsolicited messages to a client), you need to view the Server>Advises status settings. The advises status settings provide various statistics and information about the server advise connection, including an indication of whether the connection has been established, and whether it is currently in use. For more information, see Advises in the ClearSCADA Guide to the Server Status Tool.

To view the status of a client - system connection (the connection the client uses to request data from the server, and the server uses to respond to requests from the client), you need to view the Server>Links status settings. The Server Links settings provide information about each client - system connection, including the amount and size of data sent from the client to the server and from the server to the client in response to the requests. For more information, see Links (Server) in the ClearSCADA Guide to the Server Status Tool.

Further Information

Failed Client - System and Server Advise Connections.


Client Administration Guide - Failed Client - System and Server Advise Connections (ViewX Client - System Connections)

Failed Client - System and Server Advise Connections

If the client - system connection or the server advise connection cannot be established, ViewX will show the system as being 'Offline'. Users will not be able to use the client to interact with your system.

The connections will only fail to establish if:

  • There is a network failure. You will need to investigate your network infrastructure and repair any faults.
  • A firewall is in place and is incorrectly configured. The firewall has to allow the client to send data to the server’s incoming port (5481 by default) and has to also allow the server to send data via the server advise connection (which uses one of the ports in the client’s Sockets range, 5500 to 5509 inclusive by default).

Further Information

Firewall Settings for Client - System and Server Advise Connections.


Client Administration Guide - Change the Port for the Server's Incoming Data (ViewX Client - System Connections)

Change the Port for the Server’s Incoming Data

By default, each ClearSCADA server uses Port 5481 to receive data from a client via the client - system connection. For many systems, this default setting is suitable. However, if Port 5481 on your server is unavailable, you will need to change the port setting so that ClearSCADA uses a different port for client to server communications.

To change the port used by the server to receive data from a client:

  1. Log on to the server and display the Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Access the Global Parameters>Advanced settings
  3. In the Server field, enter the number of the port that is going to be used instead of Port 5481. You have to enter a valid and available port number.
  4. Define the other settings for the server port if required (see Connection and Update Settings in the ClearSCADA Guide to Server Administration).
  5. Right-click on the system icon to display a context sensitive menu, then select the Apply Changes option.
    The new server port settings are put into effect.

ATTENTION: Remember that if you are using a firewall, you will need to reconfigure it so that it allows the newly defined server port to receive and send data via the client - system connection.


Client Administration Guide - Firewall Settings for Client - System and Server Advise Connections (ViewX Client - System Connections)

Firewall Settings for Client - System and Server Advise Connections

If you are configuring a firewall that will be used on a client - system connection, you should check that the firewall:

  • Allows the server to receive transmissions from the client via the client - system connection. If the default settings are in place, this means that the firewall has to allow the server to receive data via port 5481.
  • Allows the client to receive data via the server advise connection. The firewall has to be configured to allow incoming data via the ports defined in the client’s Sockets setting (see Change the Range of Ports for the Client’s Incoming Data). By default, this range is port 5500 to 5509.

The use of firewalls is the reason why ClearSCADA uses a default port range of 5500 to 5509. This range is rarely used by other applications and it also makes it easy for you to set up a firewall—if you configure the firewall to allow the ports 5500 to 5509 as well as the port for the server’s incoming data (5481 by default), the connections should be able to establish.

However, if you change the client’s socket range, you also need to reconfigure the firewall to allow the ports in the reconfigured range. If you do not reconfigure the firewall, the connection will be unable to establish.

If the defined range of ports are being used by another application and a firewall is not being used, there will be no problem with the connections—ClearSCADA will choose two available ports (one for the client - system connection and one for the incoming connection from the server advise). It is only when a firewall is used in this situation that a problem can arise.

In the unlikely event that a firewall is in place and another application is using the ports defined in the client’s sockets range, ClearSCADA will automatically use other available ports. This can cause problems as the firewall will may not be configured to allow connections via the ports being used by the client. To resolve this issue, we recommend that you Check which Ports are Available on the Client and then Change the Range of Ports for the Client’s Incoming Data.

For more details on configuring a firewall, please refer to the documentation supplied with your firewall product.

Further Information

Understanding Client - System and Server Advise Connections

Check which Ports are Available on the Client

Change the Range of Ports for the Client’s Incoming Data.


Client Administration Guide - ViewX Cache

ViewX Cache

The ViewX cache is an area of disk space on a client PC (see ViewX Cache Location). It is used to store local versions of ViewX documents such as Mimics, Trends and X-Y Plots. It is also used to store scripts on the client.

By storing documents locally, the system is able to minimize the amount of unnecessary traffic on the client - system connection. When a user logs on to the client and attempts to display a Mimic, Trend, X-Y Plot etc., ViewX compares the version of the display that is stored in the ViewX cache to the actual display that is stored on the server. If the display stored in the ViewX cache is identical to the original display on the server, ViewX uses the display in the cache. This means that the requested display does not have to be sent from the server to the client. However, if the display in the ViewX cache is different to the corresponding display on the server, ViewX will use the version that is on the server as this is the latest up-to-date version. The display will be sent from the server to the client and will be stored in the ViewX cache (it will replace the out of date version of the display that is already in the ViewX cache).

Example:

A user logs on to a client and attempts to display a Mimic named ‘Main Pipeline’. ViewX immediately compares the version of the ‘Main Pipeline’ Mimic in the ViewX cache to the actual ‘Main Pipeline’ Mimic that is stored on the server.

ViewX determines that the ‘Main Pipeline’ Mimic on the server has been updated more recently that the version that is stored in the ViewX cache on the client. As a result, the ‘Main Pipeline’ Mimic data from the server is sent to the client PC.

The client PC receives the updated ‘Main Pipeline’ Mimic and stores it in its ViewX Cache. It replaces the previous version of the ‘Main Pipeline’ Mimic automatically. ViewX then displays the new ‘Main Pipeline’ Mimic that is stored in the ViewX cache.

The user logs off and another user logs on via the same client an hour later. The new user attempts to display the ‘Main Pipeline’ Mimic. ViewX compares the version of the Mimic in the ViewX cache to the version that is stored on the server. There have been no changes to the server’s version of the Mimic during the last hour, the ‘Main Pipeline’ Mimic in the ViewX cache is identical to the ‘Main Pipeline’ Mimic on the server. As the local version of the Mimic is up to date, ViewX does not have to request an update from the server—the ‘Main Pipeline’ Mimic in the ViewX cache is up to date and is displayed on the client.

NOTE: ViewX also has an alarm sound cache that is used to store the .wav files that provide the sounds on audible alarms. The sound cache works in the same way as the ViewX cache, except that it only contains sound files and has its own directory (see ViewX Alarm Sound Cache Location).

Further Information

ViewX Cache Location

ViewX Alarm Sound Cache Location

ViewX Alarm Sounds: see Associate a WAV Sound File with a Severity Range in the ClearSCADA Guide to Server Administration.


Client Administration Guide - ViewX Cache Location (ViewX Cache)

ViewX Cache Location

The location of the ViewX cache varies according to the operating system that is installed on the client:

  • Windows XP and Windows Server 2003:
C:\Documents and Settings\All Users\Application Data\
Schneider Electric\ClearSCADA\ViewXCache

  • Windows Vista and Windows Server 2008:
C:\ProgramData\SchneiderElectric\ClearSCADA\ViewXCache


Client Administration Guide - ViewX Alarm Sound Cache Location (ViewX Cache)

ViewX Alarm Sound Cache Location

The location of the ViewX Alarm Sound cache varies according to the operating system that is installed on the client:

  • Windows XP and Windows Server 2003:
C:\Documents and Settings\All Users\Application Data\
Schneider Electric\ClearSCADA\ViewXAlarmSoundCache

  • Windows Vista and Windows Server 2008:
C:\ProgramData\SchneiderElectric\ClearSCADA\ViewXAlarmSoundCache


Client Administration Guide - ViewX Options

ViewX Options

By using the Options window, you can configure settings that only apply to the ViewX client on which you make the changes. This means that you can alter display settings such as fonts, screen mode, home page, sort orders etc., to suit your own preferences. You can also use the Options window to define other ViewX client specific settings, such as which features are available to the Guest user on that client and the amount of space allocated to the embedded Mimic cache.

When you access the Options window (see Display the ViewX Options Window), you will see that it consists of several tabs, each of which contains settings for various ViewX features:

  • General—Contains Guest User settings and Miscellaneous settings.

You can use the Guest User settings to define which features are available to the Guest user, the homepage that is displayed when the Guest user logs on, the locale for the Guest user and other general operation features such as the inactivity shutdown time and the format to be used when displaying the date for the Guest user.

For more information on the configuration of the Guest User settings, see Configuring the Guest and Web User Accounts in the ClearSCADA Guide to Security.

You can use the Miscellaneous settings to:

  • Define the Maximum Number of Windows that can be Displayed at Once
  • Define the ToolTip Delay
  • Define the Default Flash Rate for ViewX Documents
  • Define whether the Client Displays ViewX in Full Screen Mode by Default
  • Define whether the ViewX Client is a Restricted Workstation
  • Enable or Disable the On-Screen Keyboard
  • Add a Clock to the Status Bar on a ViewX Client
  • Set the ViewX Status Bar Clock to Use UTC
  • Define the Font Used on Status Displays on a ViewX Client
  • Define the Size of the Embedded Mimic Cache
  • Alarm Banner—Allows you to change the appearance of the Alarm Banner and alter the appearance and sound of the Alarm Bell. Remember, that the settings you apply only affect the Alarm Banner on the client PC you use to make the changes. For more information, see Set up the Alarms, Alarms Lists, and Alarm Banner Preferences in the ClearSCADA Guide to Alarms.
  • Lists—Allows you to change the appearance of SQL Query Lists. Remember, that the settings you apply only affect the Lists when they are displayed on the client PC you use to make the changes. For more information, see Specify the Preferred List Options on a ViewX Client in the ClearSCADA Guide to Lists.
  • Trends—Allows you to change the appearance of Trends. Remember, that the settings you apply only affect the Trends when they are displayed on the client PC you use to make the changes. For more information, see Define the Default Settings for New Trends in the ClearSCADA Guide to Trends.
  • Mimics—Allows you to define the default settings for new Mimics, enable and disable anti-aliasing, alter the update rates, and enable\disable custom menus and define their appearance. Remember, that the settings you apply only affect Mimics when they are displayed on the client PC you use to make the changes. For more information, see Defining the Default Mimic Properties for New Mimics in the ClearSCADA Guide to Mimics.


Client Administration Guide - Display the ViewX Options Window (ViewX Options)

Display the ViewX Options Window

To display the ViewX Options window:

  1. Log on to a ViewX client via a user account that has been configured to have the Configure Options permission (see Define the ViewX Configuration Settings for a User in the ClearSCADA Guide to Security).

NOTE: If you are using a multi-head ViewX client, you need to log on via head 1 (see Multi-Head ViewX Clients).

  2. Select the Tools menu, then the Options option to display the Options window.


Client Administration Guide - Miscellaneous Options for ViewX Clients (ViewX Options)

Miscellaneous Options for ViewX Clients

The Options window contains a General tab that contains a Miscellaneous section.

You can use the Miscellaneous settings to:

  • Define the Maximum Number of Windows that can be Displayed at Once
  • Define the ToolTip Delay
  • Define the Default Flash Rate for ViewX Documents
  • Define whether the Client Displays ViewX in Full Screen Mode by Default
  • Define whether the ViewX Client is a Restricted Workstation
  • Enable or Disable the On-Screen Keyboard
  • Add a Clock to the Status Bar on a ViewX Client
  • Set the ViewX Status Bar Clock to Use UTC
  • Define the Font Used on Status Displays on a ViewX Client
  • Define the Size of the Embedded Mimic Cache.

The changes you make to the Miscellaneous settings will only take effect on the ViewX client on which you make the changes.


Client Administration Guide - Define the Maximum Number of Windows that can be Displayed at Once (ViewX Options)

Define the Maximum Number of Windows that can be Displayed at Once

You can use the Options window to set a limit for the number of ViewX document windows that can be open at the same time. For example, if you set the limit to 3, any user that logs on to the client will only be able to display 3 documents at the same time. If the user tries to display additional documents, a message is displayed informing the user that they need to close a document before the new document can be displayed.

NOTE: ViewX documents are visual displays such as Mimics, Trends, X-Y Plots, Logic programs etc.

To define the maximum number of ViewX documents that can be displayed simultaneously on the client:

  1. Display the ViewX Options Window.
  2. Select the General tab.
  3. In the Miscellaneous section, use the Max Windows spin-box to set the maximum amount. If you set the maximum to 0, there is no limit—the client can display as many ViewX documents as requested.
  4. Select the OK button to apply the changes.
    A ViewX client showing the ‘too many windows open’ message. This client has a limit of 3 windows and the message is displayed when a user attempts to display a fourth window.


Client Administration Guide - Define the ToolTip Delay (ViewX Options)

Define the ToolTip Delay

You can use the Options window to change the amount of time it takes for a ToolTip to be displayed. The default setting is 10 seconds, which means that when the cursor is positioned over an item with a ToolTip, there is a 10 second delay before the ToolTip is displayed.

The ToolTip is only displayed after a delay. The delay is 10 seconds by default.

The speed of ToolTip displays has no effect on the system and is purely down to personal preference. If you find the default ToolTip delay to be too long or short, you can adjust it as required.

To change the ToolTip delay:

  1. Display the ViewX Options Window.
  2. Select the General tab.
  3. In the Miscellaneous section, use the Tooltip Delay spin-box to increase or decrease the delay in seconds. The shortest possible delay is 5 seconds and the longest delay is 60 seconds.
  4. Select the OK button to apply the changes.


Client Administration Guide - Define the Default Flash Rate for ViewX Documents (ViewX Options)

Define the Default Flash Rate for ViewX Documents

Many ViewX documents have flashing elements on display. For example, Mimics can contain flashing objects and Lists and the Alarm Banner can both show flashing entries (these entries usually relate to items in alarm). The flashing elements are designed to attract the attention of operators so that they are made aware of site conditions as soon as possible.

The speed at which the elements flash between colors is defined via the Flash Rate setting on the Options window. This setting determines whether the colors flash Fast (change every 0.5 seconds, Medium (change every 0.75 seconds), or Slow (change every second).

This button (shown on a Mimic) is animated to flash red then blue when an associated point is in alarm. The speed at which the button changes color from red to blue then back to red again is dependent on the Flash Rate setting as defined on the Options window.

Typically, you would set the Flash Rate setting according to your personal preference. However, on some systems, performance may be affected by the Flash Rate setting—if your PC has limited graphics hardware, fast and possibly medium Flash Rate settings may cause additional CPU usage. For this reason, we recommend that you choose the Slow Flash Rate setting on PCs with limited graphics capabilities.

NOTE: Mimic objects that have their Flash Mode property animated are also affected by the Flash Rate setting - it affects the speed of the animation. For example, if a Mimic object is animated to use the 2 color fast flashing effect and the Flash Rate setting is Slow, the speed of the 2 color fast flashing effect will be slower than when the Flash Rate is set to Medium or Fast.

To change the Flash Rate setting that is used for flashing effects on your ViewX client:

  1. Display the ViewX Options Window.
  2. Select the General tab.
  3. In the Miscellaneous section, use the Flash Rate combo box to set the amount of time between each stage in the flash sequence. You can choose from:
  • Fast (0.5 seconds)—Each stage of the flash sequence will last 0.5 seconds. For example, if a Mimic object is to flash between red and blue, it will be red for 0.5 seconds then blue for 0.5 seconds and will repeat this pattern.
  • Medium (0.75 seconds)—Each stage of the flash sequence will last 0.75 seconds.
  • Slow (1 second)—Each stage of the flash sequence will last 1 second. This is the recommended setting for ViewX clients that have limited graphics hardware.
  4. Select the OK button to apply the changes.


Client Administration Guide - Define whether the Client Displays ViewX in Full Screen Mode by Default (ViewX Options)

Define whether the Client Displays ViewX in Full Screen Mode by Default

You can use the Options window to set a client PC to display ViewX in full screen mode. Full screen mode is particularly useful when the client PC is primarily used for interacting ClearSCADA, as it means ViewX always starts at its maximum size.

Full screen mode only affects how ViewX is displayed when it first runs—ViewX will be displayed at its maximum size. If the user wants to change the display size, they can use the Window buttons to resize of even minimize the ViewX window as required. The full screen mode should not be confused with the restricted workstation feature, which restricts users to only accessing ViewX on that particular client PC.

In Full Screen Mode, ViewX is displayed at maximum size on the client when it is first run. Users can alter the ViewX window as needed by using the Minimize, Resize, and Close features of the window.
Minimize, Resize, and Close

To enable or disable full screen mode:

  1. Log on to the client PC via a user account that has the Configure Options permission (see Define the ViewX Configuration Settings for a User in the ClearSCADA Guide to Security).
  2. Display the ViewX Options Window
  3. In the Miscellaneous section, select the Start Full Screen check box to enable full screen mode or clear the check box to disable full screen mode.
  4. Select the OK button to apply the changes.


Client Administration Guide - Define whether the ViewX Client is a Restricted Workstation (ViewX Options)

Define whether the ViewX Client is a Restricted Workstation

You can use the Options window to set a ViewX client to be a restricted workstation; a client that only provides access to ViewX.

Restricted workstations are useful when you only want users to work with ViewX—they will not be able to use the client to access other applications on the PC, such as Windows programs.

If you set a ViewX client to function as a restricted workstation, the following rules are enforced:

  • Users that log on via the client can only access ViewX
  • ViewX runs in full screen mode and cannot be closed unless the ‘Can Close ViewX’ feature is enabled for the Guest user or the user account that was used to log on (see Define the General ViewX Settings for a User in the ClearSCADA Guide to Security)
  • The ViewX window cannot be resized.

To set a ViewX client to function as a restricted workstation:

  1. Display the ViewX Options Window.
  2. Select the General tab.
  3. In the Miscellaneous section, select the Restricted Workstation check box to set the ViewX client to function as a restricted workstation.
  4. Select the OK button to apply the changes.

If you are working on a restricted workstation and want to cancel the restricted workstation feature so that the ViewX client provides access to other applications on the client PC:

  1. Log on to the client PC via a user account that has the Configure Options permission (see Define the ViewX Configuration Settings for a User in the ClearSCADA Guide to Security).
  2. Display the ViewX Options Window
  3. In the Miscellaneous section, clear the Restricted Workstation check box to set the ViewX client to function as a normal, unrestricted workstation.
  4. Select the OK button to apply the changes.


Client Administration Guide - Enable or Disable the On-Screen Keyboard (ViewX Options)

Enable or Disable the On-Screen Keyboard

You can interact with ViewX from devices that do not have a keyboard such as touch-screen displays. This is made possible by ViewX’s own on-screen keyboard feature which provides users with a virtual keyboard - they can select letters, numbers etc., on the on-screen keyboard instead of using a physical keyboard.

By default, ViewX’s on-screen keyboard is disabled and so users have to interact with ViewX by using a keyboard and mouse.

To enable or disable ViewX’s on-screen keyboard:

  1. Display the ViewX Options Window.
  2. Select the General tab.
  3. In the Miscellaneous section, either:
  • Check the Enable On-Screen Keyboard check box to make the on-screen keyboard available for relevant displays. Users can now interact with ViewX via devices that do not have keyboards.

Or:

  • Clear the Enable On-Screen Keyboard check box to disable the on-screen keyboard feature. Users will need to use a keyboard to interact with ViewX.
  4. Select the OK button to apply the changes.

Further Information

Numeric Touch Screen Pad: see Use the Numeric Touch Screen Keypad in the ClearSCADA Guide to ViewX and WebX Clients.

QWERTY Touch Screen Pad: see Use the QWERTY Touch Screen Keypad n the ClearSCADA Guide to ViewX and WebX Clients.


Client Administration Guide - Add a Clock to the Status Bar on a ViewX Client (ViewX Options)

Add a Clock to the Status Bar on a ViewX Client

You can use the Options window to add a clock to the status bar on a ViewX client. The clock can display times in UTC or local time and it takes the time from the Windows operating system (with any formatting applied before it added to the status bar).

The ViewX status bar clock is particularly useful on ViewX clients that are set to display in Full Screen mode, where the Windows taskbar clock cannot be seen.

To add a clock to the status bar on a ViewX client:

  1. Log on to the client PC via a user account that has the Configure Options permission (see Define the ViewX Configuration Settings for a User in the ClearSCADA Guide to Security).
  2. Display the ViewX Options Window
  3. In the Miscellaneous section, enter the format for the time setting in the Clock Format field. The format has to comply with the ClearSCADA time format (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration). If you leave the field empty, the clock will not be displayed.
  4. Select the UTC check box to set the clock to display the time in Universal Co-ordinated Time (UTC) or clear it to display local time.
  5. Select the OK button to apply the changes.
    The clock is shown in the status bar in ViewX.

Further Information

Time Zone Settings: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Client Administration Guide - Set the ViewX Status Bar Clock to Use UTC (ViewX Options)

Set the ViewX Status Bar Clock to Use UTC

You can use the UTC setting in the Miscellaneous section of the Options window to set the ViewX status bar clock to use Universal Co-ordinated Time (UTC). For more information, see Add a Clock to the Status Bar on a ViewX Client.

Further Information

Time Zone Settings: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Client Administration Guide - Define the Font Used on Status Displays on a ViewX Client (ViewX Options)

Define the Font Used on Status Displays on a ViewX Client

You can use the Options window to change the style and size of lettering that is used on status displays (also referred to as View windows or View dialog boxes) in ViewX. This allows you to adjust the text displays to suit your own requirements and tastes, for example, you may wish to use a larger font to make it easier to read the information.

By default, ViewX uses the Tahoma font sized at 8 point.

To change the font style and size used on ViewX status displays:

  1. Display the ViewX Options Window.
  2. Select the General tab.
  3. In the Miscellaneous section, use the Status Display Font combo box to choose the style of font. When you select the combo box, you can see the list of available fonts and a preview of the appearance of the font.
  4. Use the spin-box next to the Status Display Font combo box to define the size, in points, of the Status display’s text. You can choose any size between 8 and 72.
    A status display (View window) showing its values in the Georgia font at size 20.

  5. Select the OK button to apply the changes.


Client Administration Guide - Define the Size of the Embedded Mimic Cache (ViewX Options)

Define the Size of the Embedded Mimic Cache

If you display a Mimic that contains an embedded Mimic, the embedded Mimic is loaded into memory on the client PC (into an area called the embedded Mimic cache). The file for the embedded Mimic can then be accessed locally by any Mimic that contains the embedded Mimic.

Example:

A Mimic named ‘Pipeline’ contains an embedded Mimic called ‘Tank 1’. A user logs on to a client named ‘VC1’ and displays the ‘Pipeline’ Mimic. The ‘Pipeline’ Mimic is loaded and the embedded ‘Tank 1’ Mimic is stored in the embedded Mimic cache.

‘Pipeline’ Mimic contains an embedded Mimic called ‘Tank 1’

The user then displays a Mimic named ‘Section A’. The ‘Section A’ Mimic also contains an embedded version of the ‘Tank 1’ Mimic. To maximize performance and efficiency, the ‘Section A’ Mimic loads the ‘Tank 1’ Mimic from the embedded Mimic cache rather than loading the ‘Tank 1’ Mimic from the server. This means that both the ‘Pipeline’ and ‘Section A’ Mimics use the same local file for the embedded ‘Tank 1’ Mimic instead of loading separate versions of the file from the server.

When you display a Mimic that contains embedded Mimics, the embedded Mimics are stored in the embedded Mimic cache. To help minimize potential loss of performance, ClearSCADA will attempt to remove unused embedded Mimics from the cache if the amount of memory being used reaches the defined cache limit. When the limit is reached, ClearSCADA will remove the embedded Mimic files for any embedded Mimics that are not currently on display, starting with the oldest files first. However, ClearSCADA can only remove the files for embedded Mimics that are not currently being displayed on Mimics.

Mimic performance issues can occur when the embedded Mimic cache is full and ClearSCADA cannot remove any embedded Mimic files as they are in use. In this situation, the Mimics on display may take a long time to load and respond. For example, imagine that a Mimic named ‘Pipeline’ has ten embedded Mimics and these embedded Mimic files are so large that they fill the embedded Mimic cache. The displays the ‘Pipeline’ Mimic then navigates to a Mimic named ‘Region 1’. The ‘Region 1’ Mimic contains six embedded Mimics, but as the embedded Mimic cache is full, ClearSCADA has to remove the embedded Mimic files that were used by the ‘Pipeline’ Mimic before it can display the ‘Region 1’ Mimic. The embedded Mimic files used by the ‘Region 1’ Mimic are then stored in the embedded Mimic cache. When the user navigates back to the ‘Pipeline’ Mimic, the embedded Mimics used by that Mimic are no longer in the embedded Mimic cache and so they have to be reloaded and the embedded Mimics used by the ‘Region 1’ Mimic have to be removed. This additional processing means that the Mimics are slower to load, meaning the embedded Mimic cache offers no benefit. To resolve this situation, you need to adjust the defined embedded Mimic cache limit.

We recommend that you only change the embedded cache size if specifically advised to do so by a Schneider Electric engineer. The engineer will usually recommend that you begin by increasing the embedded Mimic cache size from 1000 to around 2000. If this does not resolve the performance issues, the next step would be to increase the embedded Mimic cache size from 2000 to 5000. If this still does not improve performance, the final step would be to increase the embedded Mimic cache size from 5000 to around 10000. The embedded Mimic cache size should not increase beyond 10000 as this could result in around 200MB of actual memory being used (the embedded Mimic files can use up to 20 times more physical memory when loaded and so exceeding 10000 can cause other performance issues, especially if DBServer is running on the same PC).

When making changes to the size of the embedded Mimic cache, you can examine the effects by using the View feature for the embedded Mimic (available on the Options window). This allows you to see whether embedded Mimic files are being loaded in and out of the cache.

If you have been advised to change the embedded Mimic cache size, you will need to use the Options window to make the alterations:

  1. Display the ViewX Options Window.
  2. Select the General tab.
  3. In the Miscellaneous section, use the Embedded Mimic Cache Size (KB) spin-box to increase the cache size as advised. Unless there are specific memory limitations, you would not be advised to reduce the cache size below the default setting of 1000 KB.
  4. Select the OK button to apply the changes.

You can view information about the embedded Mimic cache by selecting the View button that is next to the spin-box. This displays the Embedded Mimic Cache window which provides the following information:

  • Name—The name of the embedded Mimic. The name includes the parent Group.
  • Compressed Size—The size of the embedded Mimic file as stored in the ClearSCADA database. When stored in the database, files are compressed so that they are smaller and the database can store greater numbers of files.
  • Mimic Size—The size of the embedded Mimic file before it is compressed. The size of the embedded Mimic file will be larger than both the Compressed Size and the Mimic Size when it is loaded into memory as there is additional processing involved.
  • Loaded—The date and time that the embedded Mimic file was last added to the cache.
  • Last Accessed—The data and time that the embedded Mimic file was last used on a Mimic on display.
  • Reference Count—The number of times the embedded Mimic file is displayed on the Mimics that are currently open on the client PC.


Client Administration Guide - Alarm Banner Options (ViewX Options)

Alarm Banner Options

You can use the Options window to change the way the Alarm Banner and Alarm Bell appear and sound on your ViewX client. For more information, please see Set up the Alarms, Alarms Lists, and Alarm Banner Preferences in the ClearSCADA Guide to Alarms.


Client Administration Guide - Lists Options (ViewX Options)

Lists Options

You can use the Options window to change the way SQL Lists appear on your ViewX client. For more information, please see Specify the Preferred List Options on a ViewX Client in the ClearSCADA Guide to Lists.


Client Administration Guide - Trends Options (ViewX Options)

Trends Options

You can use the Options window to change the way Trends appear on your ViewX client. For more information, please see Define the Default Settings for New Trends in the ClearSCADA Guide to Trends.


Client Administration Guide - Mimics Options (ViewX Options)

Mimics Options

You can use the Options window to define the default settings for new Mimics, enable and disable anti-aliasing, alter the update rates, and enable\disable custom menus and define their appearance. For more information, please see Defining the Default Mimic Properties for New Mimics in the ClearSCADA Guide to Mimics.


Client Administration Guide - ViewX Command Line Tool

ViewX Command Line Tool

You can use the ViewX command line tool options to pre-set the settings for ViewX. Depending on the commands you apply, you can restrict or enhance the features that are available on a ViewX client.

Many of the command line tool options are designed for use with multi-head clients, as they can allow you to configure:

  • Multi-head clients to log you on to Heads 2, 3, 4 or 5 automatically when you log on to Head 1.
  • Each head on a multi-head client to show a specified display, for example, Head 1 can be configured to show a fully featured ViewX while Head 2 shows only the Alarms List and Head 3 shows a specific Mimic.
  • A head to provide ‘minimal’ functionality, which consists of a restricted menu, a full screen display and no navigation features other than those incorporated into the design of Mimics and other displays.

However, the ViewX command line tool options can also be used on single head clients.

The ViewX commands are:

  • /? —Use to Display ViewX Commands Information.
  • /Register —Use to Restore ClearSCADA Registry Settings with a ViewX Command.
  • /Head:<n> —Use to run a ViewX session on a specific head (see Use a ViewX Command to Run a ViewX Session on a Specified Head).
  • /NavigateOnHead:<n> —Use to show a defined display on a specific head (see Use a ViewX Command to Display ViewX Documents on a Specified Head). The specified head(s) will be started automatically if not already running.
  • /LogOnHead:<n> —Use to log on to one or more specific heads. This command is useful for setting up Heads 2-5 for automatic log on when a user logs on to Head 1 (see Use a ViewX Command to Log On to Specified Heads Automatically). The specified head(s) will be started automatically if not already running.
  • /Systems —Use to specify the Systems.xml file to be used by a client (see Use a ViewX Command to Specify the Systems XML File for a ViewX Client).
  • /Minimal —Use to run a ViewX session with limited functionality on a specific head (see Set a ViewX Client to Provide Minimal Functionality). The /Minimal command is useful for displaying full screen Alarms Lists (see Use a ViewX Command to Display a Full Screen Alarms List), full screen Mimics (see Use a ViewX Command to Display a Full Screen Mimic) and other full screen documents (see Use a ViewX Command to Display a Full Screen Document).

You can enter these commands at a Windows command prompt or you can configure desktop shortcuts that include the commands as part of their Target.

NOTE: You can use combinations of ViewX commands: precede each command with the / character and separate the commands with a space. For example, /Head: 2 /NavigateOnHead:1.


Client Administration Guide - Display ViewX Commands Information (ViewX Command Line Tool)

Display ViewX Commands Information

You can use the /? command to display a Command Line Options dialog box that shows the ViewX commands (switches) that are available. The Command Line Options dialog box lists the ViewX commands, the syntax for arguments for those commands, and also provides several examples of valid commands.

To display the ViewX Commands:

  1. In Microsoft Windows, run the Command Prompt.
  2. When the prompt is displayed, use the change directory command to locate your ViewX application. For example, if your command prompt shows Documents and Settings\<Your Windows ID> when you first display it, you need to enter:
cd <the location of your ViewX application>

Do not include the angle brackets. For example, cd C:/Program Files/Schneider Electric/ClearSCADA

  3. Press the Enter key. The command prompt should change to show the location of your ViewX application.
  4. When the prompt shows the location of your ViewX application, enter:
ViewX/?

  5. Press the Enter key to display the display the Command Line Options dialog box.

NOTE: Alternatively, you can enter the location of your ViewX application and add the suffix of ViewX.exe /? as the Target of a desktop shortcut. You can then use the desktop shortcut to display the Command Line Options dialog box. There has to be a space between ViewX.exe and /?. For more information on desktop shortcuts, please refer to the documentation supplied with your Windows operating system.


Client Administration Guide - Restore ClearSCADA Registry Settings with a ViewX Command (ViewX Command Line Tool)

Restore ClearSCADA Registry Settings with a ViewX Command

You can use the /register ViewX command to restore registry settings. This is useful if Windows’ regedit has been used to alter registry settings incorrectly (which may cause ‘Class Not Registered’ errors if you are using the Automation interface). By using /register, you may be able to correct the errors.

When you use /register, ClearSCADA is able to repair many (but not all) incorrect registry settings relating to ClearSCADA.

To use /register:

  1. In Microsoft Windows, run the Command Prompt.
  2. When the prompt is displayed, use the change directory command to locate your ViewX application. For example, if your command prompt shows Documents and Settings\<Your Windows ID> when you first display it, you need to enter:
cd <the location of your ViewX application>

Do not include the angle brackets. For example, cd C:/Program Files/Schneider Electric/ClearSCADA

  3. Press the Enter key. The command prompt should change to show the location of your ViewX application.
  4. When the prompt shows the location of your ViewX application, enter:
/register

  5. Press the Enter key.
    ClearSCADA will attempt to restore the ClearSCADA related registry settings.

NOTE: Alternatively, you can enter the location of your ViewX application and add the suffix of ViewX.exe /register as the Target of a desktop shortcut. You can then use the desktop shortcut to run the /register command. There has to be a space between ViewX.exe and /register. For more information on desktop shortcuts, please refer to the documentation supplied with your Windows operating system.


Client Administration Guide - Use a ViewX Command to Run a ViewX Session on a Specified Head (ViewX Command Line Tool)

Use a ViewX Command to Run a ViewX Session on a Specified Head

You can use the /Head:<n> ViewX command to run a ViewX session on a specific head (monitor). This is useful on multi-head systems where you want to run a separate ViewX session on each of the monitors connected to a client.

Usually, the /Head:<n> ViewX command is used as part of the Target for a desktop shortcut. This makes it easier to run the ViewX sessions as you only need to double-click the shortcuts. However, you can enter the /Head:<n> at a command prompt if you wish.

NOTE: In this section, we assume that you have already set up your client PC to run as a multi-head client. For information on how to configure your client to use multiple heads (monitors), please refer to the documentation for your operating system.

To use a ViewX command to run another ViewX session on a specified head:

  1. Using Windows Explorer, browse to the location of your ViewX.exe file, for example, C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe
  2. Right-click on the ViewX.exe file to display a context-sensitive menu.
  3. Select the Create Shortcut option to create a shortcut to ViewX. The shortcut item is added to the list of files in the ClearSCADA folder.
  4. Right-click on the shortcut item and select the Properties option from the context-sensitive menu.
    The Shortcut Properties dialog box is displayed.
  5. Modify the Target field by adding the following string to the end of the existing link:
/head:<number>

Where the <number> is the number of the head to be associated with the instance of ViewX that runs when you run it from the shortcut. Do not enter the angle brackets <>.

For example, the target should be similar to:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /Head:2

NOTE: The head is specified with the <n> argument, where n is between 1 and 5. Specifying no argument is equivalent to /Head:1.

  6. Select the OK button to confirm the target and close the dialog box.
  7. In Windows Explorer, double click on the shortcut and verify that ViewX runs as expected.

NOTE: The Tools>Options features are unavailable on Head 2.

  8. Move the shortcut to your desktop.
  9. Repeat this procedure for each head as required.

Further Information

Multi-Head ViewX Clients.


Client Administration Guide - Use a ViewX Command to Display ViewX Documents on a Specified Head (ViewX Command Line Tool)

Use a ViewX Command to Display ViewX Documents on a Specified Head

The NavigateOnHead: <n> command allows you to set almost any document to be shown on another head. For example, you may want to configure a ViewX shortcut that, when executed, causes a ViewX session on Head 2 to display a specific Trend.

The ‘documents’ that can be defined as the target display (the display that is shown on a specific head) include:

  • Mimics
  • Trends
  • Alarms Lists
  • Lists
  • Logic Programs
  • Schedules
  • Reports
  • X-Y Plots
  • Time Profiles
  • Script Libraries
  • Calendars
  • Value Maps
  • Alarm Action Rosters
  • Alarm Action Calendars
  • Data Grids
  • Data Tables
  • Crystal Reports.

However, some displays, such as ad-hoc Lists and Trends cannot be used at target displays for the NavigateOnHead: <n> command.

NOTE: In this section, we assume that you have already set up your client PC to run as a multi-head client. For information on how to configure your client to use multiple heads (monitors), please refer to the documentation for your operating system.

To use a ViewX command to run another ViewX session on a specified head:

  1. Using Windows Explorer, browse to the location of your ViewX.exe file, for example, C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe
  2. Right-click on the ViewX.exe file to display a context-sensitive menu.
  3. Select the Create Shortcut option to create a shortcut to ViewX. The shortcut item is added to the list of files in the ClearSCADA folder.
  4. Right-click on the shortcut item and select the Properties option from the context-sensitive menu.
    The Shortcut Properties dialog box is displayed.
  5. Modify the Target field by adding the following string to the end of the existing link:
/NavigateOnHead:<Number> "<Target Display>"

Where:

  • <Number> is the number of the head on which the target display (and ViewX session) will be shown. Do not enter the angle brackets <>.
  • <Target Display> is an absolute reference to the display that you want to be shown when the command is executed. The <Target Display> has to include the name of the system and the database class, and you should not include the angle brackets < >.

For example, if the target display was a Trend called Trend1, the Target entry would need to be similar to:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /NavigateOnHead:2 "SCX:///Main/CGraph/Trend1"

For more information on locating the absolute reference for ‘documents’ including Alarms Lists, Lists, and Mimics, see Locating the Absolute Address of a Display in the ClearSCADA Guide to Mimics.

NOTE: The head is specified with the <n> argument, where n is between 1 and 5. Specifying no argument is equivalent to NavigateOnHead:1.

  6. Select the OK button to confirm the target and close the dialog box.
  7. In Windows Explorer, double click on the shortcut and verify that ViewX runs as expected.

NOTE: The Tools>Options features are unavailable on Head 2.

  8. Move the shortcut to your desktop.

Alternatively, you can enter /NavigateOnHead:<Number> "<Target Display>" at the Windows command prompt (substituting the <Number> for the Head number and <Target Display> for the address of the display to be shown. Again, do not include the angle brackets. You will need to use the prompt to locate the directory that contains the ViewX.exe first, then enter ViewX.exe /NavigateOnHead:<Number> "<Target Display>".

Further Information

Multi-Head ViewX Clients

Use a ViewX Command to Display a Full Screen Alarms List

Use a ViewX Command to Display a Full Screen Mimic


Client Administration Guide - Use a ViewX Command to Log On to Specified Heads Automatically (ViewX Command Line Tool)

Use a ViewX Command to Log On to Specified Heads Automatically

Multi-head clients are usually set up so that a separate ViewX session is shown on each monitor (head). With the default settings in place, any user that wants to work on the client will need to log on to each ViewX session individually. However, by using the /LogOnHead: <n,n> command line option, you can set the heads so that when you log on to Head 1, you also log on to one or more of the client’s heads automatically.

Log on to Head 1...
...and you are logged on to the other heads automatically.
Head 1
Head 2
Head 3
Client PC

You can use the LogOnHead:<n,n> command via the command prompt in Windows or use it as part of the Target for a desktop shortcut. The LogOnHead:<n,n> command will only apply when you run ViewX via a command that includes the LogOnHead:<n,n> command.

To create a desktop shortcut that, when executed, will allow you to log on to Head 1 and automatically log on to other heads:

  1. Using Windows Explorer, browse to the location of your ViewX.exe file, for example, C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe
  2. Right-click on the ViewX.exe file to display a context-sensitive menu.
  3. Select the Create Shortcut option to create a shortcut to ViewX. The shortcut item is added to the list of files in the ClearSCADA folder.
  4. Right-click on the shortcut item and select the Properties option from the context-sensitive menu.
    The Shortcut Properties dialog box is displayed.
  5. Modify the Target field by adding the following string to the end of the existing link:
Head:1 /LogOnHead:<Head Number, Head Number,>

Where:

  • Head:1 sets ViewX to run on Head 1 when the desktop shortcut is used. When the user logs on to Head 1, ViewX sessions will automatically run on the other heads (that are specified by the <Head Number>)
  • <Head Number> is the number of a head that will automatically log on when a user logs on to Head 1. You can include up to 4 heads (Head 2, Head 3, Head 4, and Head 5) as required; simply separate the head numbers with a comma. Do not include the angle brackets.

For example, on a Windows XP ViewX client that has ViewX installed in Program Files on drive C, the Target would need to be:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /Head:1
/LogOnHead:2,3,4

  6. Select the OK button to confirm the target and close the dialog box.
  7. In Windows Explorer, double click on the shortcut and verify that ViewX runs as expected.
  8. Move the shortcut to your desktop.

Alternatively, you can enter /Head:1 /LogOnHead: <n> at the Windows command prompt. You will need to use the prompt to locate the directory that contains the ViewX.exe first, then enter ViewX.exe /Head:1 /LogOnHead: <n>,<n> (where <n>, <n> is the Head numbers. Do not include the angle brackets).

Further Information

Multi-Head ViewX Clients


Client Administration Guide - Use a ViewX Command to Specify the Systems XML File for a ViewX Client (ViewX Command Line Tool)

Use a ViewX Command to Specify the Systems XML File for a ViewX Client

You can use the /Systems command to associate a ViewX client with a Systems.xml file. Systems.xml files can be used to set up a ViewX client connection (as an alternative to using the Client Configuration Applet).

For more information, see Use the Systems.xml File to Set Up a ViewX Client Connection.


Client Administration Guide - Set a ViewX Client to Provide Minimal Functionality (ViewX Command Line Tool)

Set a ViewX Client to Provide Minimal Functionality

You can set a ViewX client to only provide limited functionality. Minimal mode is designed for use with multi-head clients, where one head only provides an Alarms List or Overview Mimic and other heads provide a greater range of functionality. For example, a two-head client may use Head 1 for a fully-featured ViewX session, with Head 2 running a minimal ViewX session so that it only shows the Alarm Banner.

In this setup, Head 1 runs a fully featured ViewX, while Head 2 runs a minimal ViewX session that only displays a full-screen Alarm Banner.
Client PC
Head 1
Head 2

A ViewX session that runs in Minimal mode can only display one document at a time, such as one Alarms List or one Mimic. It has a very restricted menu and no navigation bars.

Usually, the /minimal command is used in conjunction with another command such as the NavigateonHead command. This allows one or more heads to run in Minimal mode while at least one head runs with a fully featured ViewX.

To create a desktop shortcut that, when executed, will run ViewX in Minimal mode on a specific head:

  1. Using Windows Explorer, browse to the location of your ViewX.exe file, for example, C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe
  2. Right-click on the ViewX.exe file to display a context-sensitive menu.
  3. Select the Create Shortcut option to create a shortcut to ViewX. The shortcut item is added to the list of files in the ClearSCADA folder.
  4. Right-click on the shortcut item and select the Properties option from the context-sensitive menu.
    The Shortcut Properties dialog box is displayed.
  5. Modify the Target field by adding the following string to the end of the existing link:
Head:<Head Number> /Minimal

Where:

  • <Head Number> is the number of a head that will be set to run in Minimal mode. Do not include the angle brackets.

For example, on a Windows XP ViewX client that has ViewX installed on drive C, the Target could be:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /Head:2
/minimal

When the desktop shortcut is used, it will run a minimal ViewX session on Head 2.

You can set a minimalised ViewX session to show the minimal interface only or you can configure it to show the minimal interface plus a particular display. For example, you can set a minimalised ViewX session to only show the Alarms List or only show a Mimic. To do this, you need to add the address of the display at the end of the Target.

The syntax that is required to define a Target display for a shortcut (or for a command at the command prompt) is the same as when configuring hyperlinks on Mimics. For more information, see Hyperlinks in the ClearSCADA Guide to Mimics.

  6. Select the OK button to confirm the target and close the dialog box.
  7. In Windows Explorer, double click on the shortcut and verify that ViewX runs as expected.
  8. Move the shortcut to your desktop.

Alternatively, you can enter /Head:<Head Number> /Minimal at the Windows command prompt. You will need to use the prompt to locate the directory that contains the ViewX.exe first, then enter ViewX.exe /Head:<n> /Minimal (where <n> is the Head number on which the minimalised ViewX will appear. Do not include the angle brackets).

Further Information

Multi-Head ViewX Clients

Example:

A client has two heads and runs the Windows XP operating system. ViewX is installed in the Program Files directory on the C: drive of the client.

A user logs on to Windows and uses Windows Explorer to browse to the ViewX.exe file (in this case, the file is located at C:/Program Files\Schneider Electric\ClearSCADA\). The user then right-clicks on the ViewX.exe file and selects the Create Shortcut option to create a new desktop shortcut (in the same location as the ViewX.exe file. The desktop shortcut, when executed, will cause ViewX to run. As no specific head information has been defined, ViewX will run on Head 1 by default.

The user then right-clicks on the desktop shortcut and selects Properties to display the Shortcut Properties dialog box. Using the dialog box, the user changes the Target to:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /head:2 /navigateonhead:1 /minimal "SCX:///*/AlarmList/"

Where:

  • "C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" is the full address of the ViewX.exe file.
  • /head 2: defines an instruction for running ViewX on Head 2.
  • /navigateonhead:1 configures the heads so that whenever a display is accessed from Head 2, it is displayed on Head 1. For example, if a user selects the Display Alarm View action for an alarm shown on Head 2, the relevant Alarm View Mimic will be shown on a ViewX session running on Head 1. If there is no ViewX session running on Head 1, a new, fully featured ViewX session will run on Head 1 automatically. If a minimal ViewX session is already running on Head 1, the selected display will be shown in the minimalised ViewX session.
  • /minimal sets Head 2 to run a minimalised ViewX session.
  • "SCX:///*/AlarmList/" sets the minimalised ViewX session on Head 2 to only display the Alarms List (which will include alarms from every available system, as the asterisk * represents available systems).

The user then saves the new desktop shortcut, renames it to ViewX Head 2 and moves it to the desktop of Head 1. It is placed next to the default ViewX shortcut. The user renames the default ViewX shortcut to ViewX Head 1. (The Target of the default ViewX shortcut is ViewX.exe, which means it will cause a fully featured ViewX session to run on Head 1.)

The user double-clicks on the ViewX Head 1 shortcut and a fully featured ViewX session runs on Head 1. The user then double-clicks on the Head 2 shortcut and a ViewX session runs on Head 2. The Head 2 ViewX session has the minimal set of features and only shows the Alarm Banner.

The user right-clicks on an alarm in the Alarms List on Head 2 and selects the Display Alarm View action. The Mimic that is defined as the Alarm View for the item in alarm is displayed on Head 1.


Client Administration Guide - Use a ViewX Command to Display a Full Screen Alarms List (ViewX Command Line Tool)

Use a ViewX Command to Display a Full Screen Alarms List

You can use the /Minimal ViewX command to display ViewX in minimal mode - a mode that shows a single display at full screen size and provides minimal functionality. A common use for this feature is to have one ViewX head dedicated to displaying the Alarm List at full screen size.

To set the Alarm List as a full size display, your ViewX command needs to use the following syntax:

"<Address of ViewX.exe>" /Head:<head number> /minimal "SCX:///*/AlarmList/"
Where:
  • <Address of ViewX.exe> is the location of the ViewX.exe file on your PC, for example, "C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe". Do not include the angle brackets.
  • <Head Number> is the number of the head (monitor) on which the full screen Alarm List will be displayed, for example, /Head: 2. Again, do not include the angle brackets.

If you do not include the /Head command, the full screen Mimic will be displayed on Head 1 by default.

  • /minimal sets ViewX to use Minimal mode, which removes certain parts of the interface from the display.
  • "SCX:///*/AlarmList/" is the address of the Alarm List display. The * character is a wildcard that represents every available system (so the Alarms List will be the Alarms List for each system to which you have access). If you required an Alarms List that only showed the alarms for a specific system, you could enter the name of the system instead of the asterisk * character.

Example:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /head:2 /minimal "SCX:///*/AlarmList/"

NOTE: Your ViewX command can also incorporate other ViewX commands as required, for example, you could include a /NavigateOnHead command as well as the /Head and /Minimal commands.

For more information on using the /Minimal command, see Set a ViewX Client to Provide Minimal Functionality.


Client Administration Guide - Use a ViewX Command to Display a Full Screen Mimic (ViewX Command Line Tool)

Use a ViewX Command to Display a Full Screen Mimic

You can use the /Minimal ViewX command to display ViewX in minimal mode - a mode that shows a single display at full screen size and provides minimal functionality. A common use for this feature is to have one ViewX head dedicated to displaying an Overview Mimic at full screen size.

To set a Mimic as a full size display, your ViewX command needs to use the following syntax:

"<Address of ViewX.exe>" /Head:<head number> /minimal "<Address of Mimic>"
Where:
  • <Address of ViewX.exe> is the location of the ViewX.exe file on your PC, for example, "C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe". Do not include the angle brackets.
  • <Head Number> is the number of the head (monitor) on which the full screen Mimic will be displayed, for example, /Head: 2. Again, do not include the angle brackets.

If you do not include the /Head command, the full screen Mimic will be displayed on Head 1 by default.

  • "<Address of Mimic" is the absolute address of the required Mimic, for example, "SCX:///Main/CMimic/Overview Plant 1". Do not include the angle brackets.

Example:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /Head:2 /Minimal "SCX:///Main/CMimic/Plant Overview"

NOTE: Your ViewX command can also incorporate other ViewX commands as required, for example, you could include a /NavigateOnHead command as well as the /Head and /Minimal commands.

For more information on using the /Minimal command, see Set a ViewX Client to Provide Minimal Functionality.


Client Administration Guide - Use a ViewX Command to Display a Full Screen Document (ViewX Command Line Tool)

Use a ViewX Command to Display a Full Screen Document

You can use the /Minimal ViewX command to display any ViewX document as a full screen display. This includes Mimics, Trends, Schedules, X-Y Plots and Reports. For more information, see Set a ViewX Client to Provide Minimal Functionality.


Client Administration Guide - Multi-Head ViewX Clients

Multi-Head ViewX Clients

ClearSCADA supports multi-head displays which means you can use multiple instances of the ViewX client application on a single client. Each instance of ViewX runs on a ‘head’, and each ‘head’ can be placed in any position on any screen available. Typically, each head is displayed on a different monitor, for example, a dual head setup has one client that runs two ViewX applications, with each application running on a separate monitor.

...the other monitor shows ‘head 2’ which is another instance of ViewX running on the same client.
One monitor shows ‘Head 1’ which is an instance of ViewX running on a client.
The client PC runs two ViewX applications at the same time.

Multi-head displays are a useful feature as they allow a user to view different displays at the same time. For example, a user on a two head system could have one head showing an alarm Mimic, with the other head used for the user’s operational duties. The user could perform their tasks on one head while using the other head for viewing the alarm Mimic.

When setting up multi-head clients, you need to be aware of the following:

  • Head-specific settings (toolbar positions, navigator sizes, alarm banner sizes, alarm banner/list column order/widths) are stored independently per head, for both the guest user and database users.
  • Global settings (i.e. those configured via Tools>Options) can only be modified from Head 1. This allows settings to be retained when multiple instances of ViewX are closed.
  • ViewX log files are named according to the head from which they were generated i.e. ViewX_Head<n>_<xxx>.log.
  • DBClient log files for ViewX are named according to the head from which they were generated i.e. DBClient_ViewX_Head<n>_<xxx>.log.
  • The Alarm Bell can be configured to sound on one head only (audible alarms will only be generated on one instance of ViewX).
  • Only one instance of ViewX is allowed per ‘head’.

To configure ViewX to run on multiple heads on a single client:

  1. Log on to the client PC.
  2. Use the client’s operating system to configure the computer and monitors to provide multi-head functionality. For more information, please refer to the documentation for the operating system.
  3. Using Windows Explorer, browse to:
"C:\Program Files\Schneider Electric\ClearSCADA"

  4. Locate the ViewX.exe file and right-click on it to display a context-sensitive menu.
  5. Select the Create Shortcut option to create a shortcut to ViewX. The shortcut item is added to the list of files in the ClearSCADA folder.
  6. Right-click on the shortcut item and select the Properties option from the context-sensitive menu.
    The Shortcut Properties dialog box is displayed.
  7. Modify the Target field by adding the following string to the link:
/head:<number>

Where the <number> is the number of the head to be associated with the instance of ViewX that runs when you run it from the shortcut. Do not enter the angle brackets <>.

For example, the target should be similar to:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /head:2

NOTE: The head is specified with the /head:<n> argument, where n is between 1 and 5. Specifying no argument is equivalent to /head:1.

  8. Select the OK button to confirm the target and close the dialog box.
  9. In Windows Explorer, double click on the shortcut and verify that ViewX runs as expected.

NOTE: The Tools>Options features are unavailable on Head 2.

  10. Repeat this procedure for each head as required.

You can use ViewX command line options to:

  • Configure a Head to Show a Full Screen Alarm Banner
  • Set Multiple Heads to Log On Automatically when a User Logs on to Head 1
  • Configure a Head to Provide Limited Access to ViewX Features
  • Configure a Head to Navigate to Another Head
  • Configure a Head to Show a Specific Display on Startup.


Client Administration Guide - Configure a Head to Show a Full Screen Alarm Banner (Multi-Head ViewX Clients)

Configure a Head to Show a Full Screen Alarm Banner

You can use the Head ViewX command to configure a ViewX head so that it shows a full screen Alarm Banner when it first runs. This is useful when you have a multi-head system where one of the heads is dedicated to presenting alarm information.

To configure a head to show a full screen Alarm Banner, you need to use the Head command with the address of the Alarm Banner, which is:

"<Address of ViewX.exe>" /Head:<head number> /minimal "SCX:///*/AlarmList"

Where:

  • <Address of ViewX.exe> is the location of the ViewX.exe file on your PC, for example, "C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe". Do not include the angle brackets.
  • <Head Number> is the number of the head (monitor) on which the full screen Alarm List will be displayed, for example, /Head: 2. Again, do not include the angle brackets. If you do not include the /Head command, the full screen Alarm Banner will be displayed on Head 1 by default.
  • /minimal sets ViewX to use Minimal mode, which removes certain parts of the interface from the display.
  • "ClearSCADA:///*/AlarmList/" is the address of the Alarm List display. The * character is a wildcard that represents every available system (so the Alarms List will be the Alarms List for each system to which you have access). If you required an Alarms List that only showed the alarms for a specific system, you could enter the name of the system instead of the asterisk * character.

For example:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /Head:2 /minimal "SCX:///*/AlarmList"

If required, you can also use the NavigateOnHead command to set a head to show a specific display, such as the Alarm Banner (see Configure a Head to Show a Specific Display on Startup).

For further information, see Use a ViewX Command to Display a Full Screen Alarms List.


Client Administration Guide - Set Multiple Heads to Log On Automatically when a User Logs on to Head 1 (Multi-Head ViewX Clients)

Set Multiple Heads to Log On Automatically when a User Logs on to Head 1

You can use the LogOnHead ViewX command to configure a ViewX head so that when you log on to Head 1, you are automatically logged on to one or more of the other heads. This means you do not have to log on to each head separately.

For more information, (see Use a ViewX Command to Log On to Specified Heads Automatically).


Client Administration Guide - Configure a Head to Provide Limited Access to ViewX Features (Multi-Head ViewX Clients)

Configure a Head to Provide Limited Access to ViewX Features

You can use the Minimal ViewX command to configure a ViewX head so that it uses a restricted interface that only provides access to a limited set of menu options and features. This is useful when a head is only used for information purposes while another is used for user-system interaction.

For more information, see Set a ViewX Client to Provide Minimal Functionality.


Client Administration Guide - Configure a Head to Navigate to Another Head (Multi-Head ViewX Clients)

Configure a Head to Navigate to Another Head

You can use the NavigateOnHead ViewX command to configure a ViewX head so that when it is used to access another display, the other display is shown on a different head. For example, you can configure ViewX heads so that if you select the Display Alarm View Mimic action for an alarm shown on Head 2, the corresponding Mimic is displayed on Head 1.

To achieve this, you need to use the NavigateOnHead ViewX command followed by the address of the display that is to be shown, for example:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /NavigateOnHead:2 "SCX:///*/AlarmList"

For more information, see Use a ViewX Command to Display ViewX Documents on a Specified Head.


Client Administration Guide - Configure a Head to Show a Specific Display on Startup (Multi-Head ViewX Clients)

Configure a Head to Show a Specific Display on Startup

You can use the Head ViewX command to configure a ViewX head so that it shows a specific display when it first runs. This is useful when you have a multi-head system where one of the heads is dedicated to showing one particular display, such as an Overview Mimic or a Mimic that contains a live webcam feed.

To configure a head to show a specific display on startup, you need to use the Head command and also specify the display that is to be shown, for example:

"C:\Program Files\Schneider Electric\ClearSCADA\ViewX.exe" /Head:2 "SCX:///CMimic/.Overview"

For more information, see Use a ViewX Command to Display ViewX Documents on a Specified Head.


Client Administration Guide - ViewX Client - Third Party OPC Server Connections

ViewX Client - Third Party OPC Server Connections

As ClearSCADA supports OPC standards, a ViewX client can be configured to connect to a Third Party OPC server, such as a Kepware OPC server or a Matrikon OPC server. This means a ViewX client can be used to connect to ClearSCADA and many other OPC based systems—all that is required is a suitable connection for each server.

In this section, we explain how to:

  • Create a Connection between a ViewX Client and a Third Party OPC Server
  • Edit an Existing ViewX Client - Third Party OPC Server Connection
  • Investigate problems relating to Failed ViewX Client - Third Party OPC Server Connections.


Client Administration Guide - Create a Connection between a ViewX Client and a Third Party OPC Server (ViewX Client - Third Party OPC Server Connections)

Create a Connection between a ViewX Client and a Third Party OPC Server

To create a connection between a ViewX client and a Third Party OPC server:

  1. On the ViewX client, use the Windows Start menu to access ClearSCADA’s Configure Connections option and run the ClearSCADA Client applet.
  2. Select the Add button to display the ClearSCADA Client Configuration window.
  3. Define a name for the system in the System Name field. The name that you enter will be the name that is shown for the system in the OPC Data Bar in ViewX.
  4. Use the Type combo box to define the type of OPC server to which the ViewX client is to be connected. You need to choose the option that matches the type of OPC server being used, for example, if the ViewX client is to be connected to an OPC Historic server, you need to choose the OPC Historic option. If you are unsure which type of OPC server is used, we recommend that you choose the OPC Data Server option (as many OPC servers are OPC data servers; OPC alarm servers and OPC historic servers are less common).
  5. Leave the default setting for the Use Client Licensing check box in place (it has no effect on ViewX client - Third Party OPC server connections).
  6. Use the Visible in ViewX check box to define whether the OPC server will be visible in ViewX (shown in the OPC Data Bar).
  • Select the Visible in ViewX check box to set ViewX to connect to the Third Party OPC server via the connection. The OPC server will be available in ViewX (via the OPC Data Bar or OPC Historic Data Bar), which means operators, engineers and administrators can use the client to interact with the OPC server.
  • Clear the Visible in ViewX check box to stop ViewX from providing access to the OPC server via the selected connection. If you clear the check box, the connection will be operational and can be used by other OPC applications on the ViewX client but will not be used by ViewX itself.
  7. Use the Node tabs to define which Third Party OPC servers can be connected to via the connection. Each Node tab represents one Third Party OPC server, with the Class Identifier setting being used to choose the appropriate OPC server.

The Class Identifier is provided by the Third Party OPC server during its installation. You just need to select the appropriate Class Identifier for each Node.

For example, if the ViewX client is to connect to 2 Third Party OPC servers via the connection, you would use the Node A tab and Node B tabs. On the Node A tab, you would use the browse feature of the Class Identifier field to choose the class identifier of the first OPC server (the class identifier consists of the Name of the OPC server and its unique Class Id code). On the Node B tab, you would use the Class Identifier field to choose the class identifier of the second OPC server.

  8. Select the OK button to confirm your selections and close the ClearSCADA Client Configuration window.
  9. Select the Close button on the ClearSCADA Client applet.
    When you run ViewX, the connection between ViewX and the Third Party OPC server will be available. If you have configured the connection to have the Visible in ViewX setting enabled, you will be able to browse to the OPC server via the OPC Data Bar or the OPC Historic Data Bar, depending on the type of OPC server.

NOTE: If ViewX was running while you were configuring the ViewX - Third Party OPC server connection, you will need to exit ViewX then run it again before you can access the Third Party OPC server.


Client Administration Guide - Edit an Existing ViewX Client - Third Party OPC Server Connection (ViewX Client - Third Party OPC Server Connections)

Edit an Existing ViewX Client - Third Party OPC Server Connection

You can use the ClearSCADA Client Applet to change the configuration of an existing ViewX client - Third Party OPC server connection. This is useful when you need to alter the way the client - OPC server connection works, for example, you may need to rectify a mistake such as having selected the wrong Type of OPC server.

To edit an existing ViewX client - Third Party OPC server connection:

  1. On the ViewX client, use the Windows Start menu to access ClearSCADA’s Configure Connections option and run the ClearSCADA Client applet..
  2. Select the ViewX - Third Party OPC server connection that you want to edit.
  3. Select the Edit button to display the ClearSCADA Client Configuration window.
  4. Use the ClearSCADA Client Configuration window to change the System Name, Type, Visible in ViewX and Node settings as required. For more information on these settings, see Create a Connection between a ViewX Client and a Third Party OPC Server.


Client Administration Guide - Failed ViewX Client - Third Party OPC Server Connections (ViewX Client - Third Party OPC Server Connections)

Failed ViewX Client - Third Party OPC Server Connections

If the ViewX client - Third Party OPC connection cannot be established, you will be unable to access the OPC server’s data in ViewX. In this situation, we recommend that you check:

  • The OPC server installation. If the Third Party OPC server has not been installed correctly, ViewX will be unable to connect to it (and the Class Identifier may be unavailable during the configuration of the connection).
  • The network. If you are using a ViewX client to connect to a remote OPC server, a network problem could cause connection issues. You will need to investigate your network infrastructure and repair any faults.
  • Firewalls. Firewalls can interfere with ViewX to OPC Server connections, particularly when remote OPC servers are used. You will need to use the documentation for your particular operating system to investigate any potential firewall issues.

Your OPC server may provide diagnostic tools that you can use to investigate connection problems. For more information, please refer to the documentation supplied with your Third Party OPC server.


Client Administration Guide - WebX and XML Client - System Connections

WebX and XML Client - System Connections

ClearSCADA supports remote access via WebX clients and Third Party XML clients. WebX clients are client PCs that run the WebX application supplied by Schneider Electric and Third Party XML clients are client PCs that are running an XML application not supplied by
Schneider Electric. Both types of client provide remote access to your system by connecting, via Internet or Intranet, to a web server that is installed on the ClearSCADA server.

WebX clients and Third Party XML clients can be used at any location where Internet/Intranet access is provided and are easy to set up.

However, there are some limitations with WebX and XML clients:

  • For security reasons, WebX and XML clients cannot be used to perform configuration tasks.
  • WebX and XML clients can place a high demand on network resources as their ActiveX Controls poll the ClearSCADA server for data continuously
  • XML clients use the Web Guest user account to access the system. This means that the Web Guest user account has to be configured to provide the permissions that are required by XML client users to perform their tasks. For more information on Guest User accounts, see Configuring the Guest and Web User Accounts in the ClearSCADA Guide to Security.

NOTE: WebX also uses the Web Guest user account, but you can create User accounts for each WebX user via ViewX. If a WebX user does not log on via a specific user account, ViewX automatically logs them on via the Web Guest user account.

In the following sections, we describe how WebX/XML client - system connections work and explain how to connect to ClearSCADA via WebX/XML:

  • Understanding WebX and XML Client - System Connections
  • Connect to the System via a WebX Client or XML Client
  • Configure a Firewall for a WebX or XML Client - System Connection
  • Failed WebX Client or XML Client - System Connections.


Client Administration Guide - Understanding WebX and XML Client - System Connections (WebX and XML Client - System Connections)

Understanding WebX and XML Client - System Connections

The ClearSCADA server contains a web server that allows client PCs to access ClearSCADA via the Internet or Intranet. The configuration of the web server, configured via the Server Configuration Tool, defines:

  • The ports that are used by the web server to communicate with WebX clients and Third Party XML clients. By default, port 80 is used for non-secure XML and port 443 is used for secure XML. To support older versions of Internet Explorer there are settings for HTML which are: port 81 for non-secure HTML and port 444 is for secure HTML
  • The SSL (Secure Socket Layer) certificate and key which encrypt communications between the web server and the WebX clients and XML clients (for added security)
  • The location of the stylesheets and images that determine the appearance of the WebX interface
  • The sort order and color of the Alarm List when displayed in WebX.

For more information on these settings, see WebX Settings in the ClearSCADA Guide to Server Administration.

To connect to the web server, a client PC has to use a web browser application such as Internet Explorer. There is no need for any other configuration on the client PC—as long as the client PC has a healthy connection to the Internet/Intranet, it can connect to the web server that is running on the ClearSCADA server. To establish the connection, the user has to enter the address of the web server (and possibly the port number, depending on the configuration of your system) in the Address field of the web browser application.

When the connection between the WebX client or XML client and web server is established, the web browser launches an ActiveX Control that communicates with the ClearSCADA web server. For users accessing the system via WebX, a log on page or a homepage such as a Mimic is shown.

As the user of the WebX or XML client accesses various displays such as Mimics and Trends, the ActiveX Control sends requests to the server via the WebX and XML client - system connection. These requests are used to retrieve the data and updates required for the displays on the client.

Normally, if a web browser is inactive, the browser will automatically close down its connection. To avoid the automatic connection closure, ClearSCADA uses the ActiveX Control to continuously poll the ClearSCADA server for updates. This updates the WebX and XML clients with the latest data so that the connections between the server and the WebX and XML clients remain active (and so do not close automatically). However, as the ActiveX Control has to poll the ClearSCADA server for updates, it means that there is a greater demand for bandwidth—the WebX and XML clients are constantly requesting data to keep the connection open, even if the information on display has not been updated on the server.

The communications transmitted between the web server and the WebX and XML clients can be encrypted by using the SSL features of the ClearSCADA server (see WebX Settings in the ClearSCADA Guide to Server Administration). When these settings are in place, the WebX and XML - system connection can support secure (encrypted) and non-secure connections:

If a user accesses the system via a WebX or XML client that uses a http:// connection, the data that is transmitted and sent is non-secure, even if the web server is configured to utilize SSL.

If a user accesses the system via a WebX or XML client that uses a https:// connection, the data that is transmitted and sent is secure (encrypted). For this reason, those responsible for configuring the home pages and favorites of lower level users need to take care—if operators use http connections to access the system, the communications between the client and the system will not be secure.

NOTE: The web server can generate XML which is then translated into HTML by the WebX client's web browser. Alternatively, the server can translate the XML into HTML (for clients that do not support XML). We recommend that client-side translation is used wherever possible as this ensures the best performance.

Now that you understand how the connections are used, you can proceed to Connect to the System via a WebX Client or XML Client.


Client Administration Guide - Connect to the System via a WebX Client or XML Client (WebX and XML Client - System Connections)

Connect to the System via a WebX Client or XML Client

To open a connection between a WebX or XML client and the web server, all you need to do is run a web browser on the client PC and enter the address of the web server in the Address field:

Enter the IP address or name of the server in the web browser’s address field to connect to your system via a WebX or XML client. If your web server does not use the default ports (80 or 443), you need to add:<port number> after the address, where <port number> is the port being used by the web server.

If your web server uses the default port numbers, the address entered in the web browser can use the following formats:

  • WebX clients:
http://<server name>
http://<server IP address>
https://<server name>
https://<server IP address>

  • Third Party XML clients:
http://<server name>:<XML Port>/webservices/OPC
http://<server IP address>:<XML Port>/webservices/OPC
https://<server name>:<XML Port>/webservices/OPC
https://<server IP address>:<XML Port>/webservices/OPC

Where:

  • http: addresses are non-secure connections
  • https: addresses are secure connections that make use of the SSL settings i.e. are encrypted
  • <server name> is the name of the ClearSCADA server that is running the web server, for example, MainSys (do not include the angle brackets <>)
  • <IP address> is the Internet Protocol address of the ClearSCADA server PC, for example, 10.1.5.15. (Do not include the angle brackets <>)
  • <XML Port> is the number of the port used by the Third Party XML client.

On Third Party XML clients, you have to include the port number in the address field (they also require /webservices/OPC as a suffix). On WebX clients, you do not need to define the port number unless the web server is configured to use ports other than 80 and 443 (or 81 and 444). If different port numbers are used by the web server, you also have to include the port number in the address, for example:

http://<server name>:<port number>
http://<server IP address>:<port number>
https://<server name>:<port number>

https://<server IP address>:<port number>

Where:

  • <port number> is the number of the port that is being used by the web server instead of port 80 or port 443. As before, do not include the angle brackets <>.

When you have entered a valid address, press the Enter key or select the Go button in the web browser to access your system. When the connection is established, the web browser will display a log on page or a homepage (typically a homepage Mimic).

If the connection cannot be established, a connection failure message is displayed (see Failed WebX Client or XML Client - System Connections).


Client Administration Guide - Failed WebX Client or XML Client - System Connections (WebX and XML Client - System Connections)

Failed WebX Client or XML Client - System Connections

If you attempt to access your system from a WebX or XML client and it is unable to establish a connection, the web browser application that you are using will display a ‘connection failed’ message.

If your web browser displays a connection failed message, it may be because:

  • The user of the WebX or XML client has entered an incorrect port number in the Address field on the browser (if the default ports are not used).
  • The network connection between the client PC and server PC is unavailable. This may be due to failed hardware or a temporary loss of connection. If you suspect that there is no network connection, please contact your network administrator.
  • There is a firewall blocking the connection between the client PC and the server PC. If a firewall is being used between a WebX or XML client and the web server, you need to configure it to allow the ports that are being used by the web server (80, 81, 443, 444 by default). For more information on configuring your firewall, please refer to the manufacturers’ documentation supplied with the firewall software or hardware.
  • A Third Party web server on the ClearSCADA server is using the ports that the ClearSCADA web server is configured to use. For example, if the Apache web server is installed on the ClearSCADA server and is using port 80, it will stop the ClearSCADA web server from using port 80. In this situation, there are two possible solutions:
  • You can reconfigure the ClearSCADA server so that the ClearSCADA web server uses different ports for the connection with WebX clients

Or

  • You can reconfigure the Third Party web server to use different ports.


Client Administration Guide - Configure a Firewall for a WebX or XML Client - System Connection (WebX and XML Client - System Connections)

Configure a Firewall for a WebX or XML Client - System Connection

If your system uses a firewall between the WebX or XML client and the ClearSCADA server, you need to configure it so that it allows communications via the port used by the web server. If the default settings are in place, this means that the firewall has to allow ports 80, 81, 443, and 444. If the default ports are not used, you will need to configure the firewall to allow the ports used by your system.

You can see which ports are being used by the web server on your system by examining the:

  • General>Information data shown on the Server Status Tool (see Information in the ClearSCADA Guide to the Server Status Tool).
  • System Configuration>WebX settings on the Server Configuration Tool (see Define the Access Settings for WebX Clients in the ClearSCADA Guide to Security).

For more information, please refer to the manufacturers’ documentation supplied with your firewall.


Client Administration Guide - Third Party OPC Client - System Connections

Third Party OPC Client - System Connections

You can use a Third Party OPC client application to access your ClearSCADA system. To do this, you need to install the Data Access components of ClearSCADA on the same PC as the Third Party OPC client application. You will also need to configure the Third Party application so that it can make a connection to the Data Access components (as the Data Access components handle the communications to the ClearSCADA server).

Communications between the ClearSCADA server and the Data Access components installed on the OPC client work in exactly the same way as communications between a ViewX client and a ClearSCADA server—there is one link that is used for client to server messages and server responses and a server advise link for unsolicited messages from the server. For more information, see Understanding Client - System and Server Advise Connections.

To allow a Third Party OPC client to access the ClearSCADA system, the Data Access components have to be:

  • Installed on the Third Party OPC client PC
  • Able to access a valid connection to ClearSCADA on the OPC client PC
  • Associated with a valid OPC license.

To connect a Third Party OPC client to the server:

  1. Check that the ClearSCADA Client connections are configured correctly (see Configure the Third Party OPC Client - System Connection). A full ViewX connection is not required - a Data Access connection can be used to provide an OPC only connection.
  2. Check that you have a valid OPC license by examining the License Details display (right-click on the server icon in the Windows taskbar then select the License Details option).

Further Information

Configure the Third Party OPC Client - System Connection.


Client Administration Guide - Install Data Access Components on a Third Party OPC Client (Third Party OPC Client - System Connections)

Install Data Access Components on a Third Party OPC Client

A Third Party OPC client can only connect to a ClearSCADA server if it has the ClearSCADA Data Components installed. Once installed, the Data Components will handle the communications between the Third Party OPC client and the ClearSCADA server.

By installing the Data Access Components, you allow the Third Party OPC client to communicate with the ClearSCADA server using TCP/IP protocol. This means that DCOM is not used and so the problems commonly associated with DCOM on OPC systems are avoided (see DCOM Issues).

NOTE: The Third Party OPC client also needs to have a valid ClearSCADA connection (see Configure the Third Party OPC Client - System Connection) and OPC license.

To install the ClearSCADA Data Access components on a Third Party OPC client PC:

  1. Log on to the PC that runs the Third Party OPC client application.
  2. Run the Setup.exe file that was supplied by Schneider Electric. This Microsoft Installer file initiates the ClearSCADA installation and is downloaded or supplied on digital media when you purchase your system. For more information, please contact your system administrator.

When you run the Setup.exe file, the ClearSCADA Setup Wizard runs.

  3. On the first page of the Wizard, select the Next button.
  4. On the second page of the Wizard, read the license agreement, select the ‘I acknowledge the terms in the License Agreement’ button, then select the Next button.
  5. On the third page of the Wizard, enter your user name and organization, then press the Next button.
  6. On the fourth page of the Wizard, select the Custom button.
  7. On the fifth page of the Wizard, select the Data Access branch and then choose either the Entire Feature will be Installed on Local Hard Drive or Will be Installed on Local Hard Drive options.
  8. Select the Next button, and on the sixth page, define a Super User account if required (check the Disable Super User account check box if you do not require a Super User). For more information, see Configure the Super User Account in the ClearSCADA Guide to Security.
  9. Select the Next button.
    The Data Access components installation process begins. When the process is complete, the Wizard displays a ‘Completing’ page.
  10. On the ‘Completing’ page of the Wizard, select the Finish button.

Now that you have installed the Data Access components on the Third Party OPC client PC, you need to Configure the Third Party OPC Client - System Connection and Associate a Third Party OPC Client - System with an OPC License.


Client Administration Guide - Configure the Third Party OPC Client - System Connection (Third Party OPC Client - System Connections)

Configure the Third Party OPC Client - System Connection

When you have installed the Data Access components on the Third Party OPC client PC (see Install Data Access Components on a Third Party OPC Client), you can use the ClearSCADA Client applet to create a connection between the Third Party OPC client and the ClearSCADA server. This connection will allow the OPC client to communicate with ClearSCADA.

To configure the Third Party OPC client - system connection:

  1. On the Third Party OPC client PC, use the Windows Start menu to access ClearSCADA’s Configure Connections option and run the ClearSCADA Client applet.
  2. When the ClearSCADA Client applet runs, select the Add button to display the ClearSCADA Client Configuration window.
  3. Use the ClearSCADA Client Configuration window to create a new connection. The configuration you need to define is exactly the same as that for a ViewX - System connection, with these settings available:
  • System Name—see Define the System Name and Type for a ViewX Client - System Connection
  • Type—You need to select ClearSCADA Server (see Define the System Name and Type for a ViewX Client - System Connection)
  • Use Client Licensing—see Enable or Disable Client Licensing
  • Visible in ViewX—see Define Whether the System is Visible in ViewX
  • Node Name—see Define the Node Name for a Client - System Connection
  • Node Cost—see Define the Node Cost for a Client - System Connection
  • Compress—see Define the Client Compression Settings for a ViewX Client Connection
  • Advanced—see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection.
  4. When you have defined the connection settings, select the OK button to apply them. The Client Configuration window is closed and the new connection is added to the list on the ClearSCADA Client applet.
  5. If you need to adjust the Transmission Control Protocol/Internet Protocol settings, select the TCP/IP Tuning button to display the TCP/IP Tuning Parameters window. This feature works in exactly the same way as when configuring a ViewX - System connection. For more information, see Define the TCP/IP Tuning Settings for a ViewX Client - System Connection.
  6. If you need to adjust the range of ports that the port will use for the server advise connection, select the Sockets button. Again, this feature works in exactly the same way as when configuring a ViewX - System connection. For more information, see Change the Range of Ports for the Client’s Incoming Data.
  7. Select the Licenses button to display the Client Licensing window. You will use this window to associate the Third Party OPC client with an OPC license (see Associate a Third Party OPC Client - System with an OPC License).


Client Administration Guide - Associate a Third Party OPC Client - System with an OPC License (Third Party OPC Client - System Connections)

Associate a Third Party OPC Client - System with an OPC License

Third Party OPC client connections require a license in order to connect to ClearSCADA. There are 2 types of licensing available:

  • Client licensing—The Third Party client is associated with an OPC license file provided by Schneider Electric. The content of the license file defines:
  • The amount of time for which the client can connect to systems via the Third Party OPC client - system connection. When this time period passes, the license expires and a new license will be required
  • The versions of ClearSCADA to which the OPC client can connect via the Third Party OPC client - system connection
  • The number of ClearSCADA systems to which the OPC client can connect.

If a client license is to be used, the client licensing feature needs to be enabled for the connection (see Configure the Third Party OPC Client - System Connection) and you will need to associate the client with a license file. If the license file is invalid or missing, the client will attempt to use server licensing instead.

The settings for your client license are determined when you purchase ClearSCADA. If you contact the sales representative that sold the product to you, they will be able to provide additional detail about the specific limits of your license.

  • Server licensing—The Third Party client uses one of the server’s licenses. Each server is allocated a pre-determined amount of OPC licenses which can be used by clients. For example, if a server has 20 licenses, it can allow up to 20 clients to connect to ClearSCADA using one of the server licenses. Each client that is not using an OPC client license uses one of the available server OPC licenses. If there are no available server OPC licenses, OPC clients without client licenses will not be able to connect (until some of the server’s licenses become available again).

If an OPC client has a client license, this is used in preference to a server license. If the client license file is missing or corrupt, a server license will be used instead (even if the client licensing feature is enabled).

If the client licensing feature is disabled, server licenses are the only licenses that can be used.

If you have enabled client licensing, you will need to associate the Third Party OPC client - system connection with a client license file:

  1. Use the Windows Start menu to access ClearSCADA’s Configure Connections option and run the ClearSCADA Client applet.
  2. Select the Third Party OPC Client - System connection in the list of connections.
  3. Select the Licenses button to display the Client Licensing window.
  4. Use the browse button next to the License File field to browse to the .lic license file supplied by your ClearSCADA vendor. Select the .lic file, then select the OK button to close the browse window and confirm your selection.

You will see that the details of the license are shown in the fields on the Client Licensing window. Your Third Party OPC client will be counted against the OPC Systems limit. So, if your license has an OPC Systems limit of 10 and this is the first Third Party OPC client - system connection you have associated with the license, you will be able to use the license for a further 9 OPC client - system connections.

  5. Select the Apply button to instigate the license settings.
  6. Select the OK button to confirm your choices and close the Client Licensing window.
  7. Select the Close button to exit the ClearSCADA Client applet.
  8. Use your Third Party OPC application to connect to the Local Server. You will need to connect the Third Party OPC application to the following ClearSCADA server ProgIDs:
  • Serck.SCXV6OPCDA.<System Name>.<Server Name>
  • Serck.SCXV6OPCAE.<System Name>.<Server Name>
  • Serck.SCXV6OPCHDA.<System Name>.<Server Name>

Where <System Name> is the name of the system as defined in the client connection configuration and <Server Name> is the name of the server used in the client connection.

Serck.SCXV6OPCDA.<System Name>.<Server Name> provides a connection to the current data, Serck.SCXV6OPCAE.<System Name>.<Server Name> provides a connection to alarm and event data, and Serck.SCXV6OPCHDA.<System Name>.<Server Name> provides a connection to historic data.

Depending on your Third Party OPC Client, you may need to select these connections manually. For further information, please refer to the documentation supplied with your OPC client application.

If your Third Party OPC client supports OPC Private Credentials Security (IOPCSecurityPrivate) then you will need to configure a username and password for the Third Party OPC client in ClearSCADA. The username and password should provide an appropriate level of security, for example, if you need to issue controls via the Third Party OPC application, your user account will need the Control permission for the relevant database items. For more information on the security settings and user accounts, see the ClearSCADA Guide to Security.

NOTE: ClearSCADA does not support Windows Access Token Security (IOPCSecurityNT). Only connections using IOPCSecurityPrivate security can log on via a user account and password; other connections, including IOPCSecurityNT connections will access ClearSCADA via the Guest user account. For this reason, if your Third Party OPC client does not support IOPCSecurityPrivate security, you may need to alter the configuration of the Guest account. The Guest user account will need the relevant permissions required to perform activities via the Third Party OPC client.

If the connection has been correctly configured (see Configure the Third Party OPC Client - System Connection), and the network is healthy, you should now be able to browse to your ClearSCADA system from the Third Party OPC client application.

Further Information

Check the Status of a Third Party OPC Client - System Connection.


Client Administration Guide - Check the Status of a Third Party OPC Client - System Connection (Third Party OPC Client - System Connections)

Check the Status of a Third Party OPC Client - System Connection

Typically, you would use the Third Party OPC client application to monitor the status of the its connection to ClearSCADA. Many Third Party OPC applications include connection status tools (for more information, please refer to the documentation supplied with your OPC product).

However, you can also view the status of the Third Party OPC client - system connection in ClearSCADA by using the Server Status Tool which is available for use on the server PC. For more information on how to display it, see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool.

To view the status of a Third Party OPC client - system connection, you need to view the Server>Links status settings. The Server Links settings provide information about every client - system connection including the Third Party OPC client - system connections. The information provided includes the amount and size of data sent from the Third Party OPC client to the server and from the server to the Third Party OPC client in response to the requests. For more information, see Links (Server) in the ClearSCADA Guide to the Server Status Tool.

Further Information

Failed Third Party OPC Client - System Connections


Client Administration Guide - Failed Third Party OPC Client - System Connections (Third Party OPC Client - System Connections)

Failed Third Party OPC Client - System Connections

If the Third Party OPC client - system connection cannot be established, you will be unable to connect to ClearSCADA from the Third Party OPC client application.

A connection may fail to establish if:

  • There is a network failure. You will need to investigate your network infrastructure and repair any faults.
  • A firewall is in place and is incorrectly configured. The firewall has to allow the OPC client to send data to the ClearSCADA server’s incoming port (5481 by default). It also has to allow the ClearSCADA server to send data via the server advise connection (which uses one of the ports in the OPC client’s Sockets range, 5500 to 5509 inclusive by default).

The Third Party OPC Client - system connection works in the same way as a ViewX - system except that it uses a different license and it requires Data Access components to be installed on the OPC client PC. As such, the firewall rules for Third Party OPC client - system connections are the same as those for ViewX - system connections. For more information, see Firewall Settings for Client - System and Server Advise Connections.


Client Administration Guide - Firewall Settings for Third Party OPC Client - System Connections (Third Party OPC Client - System Connections)

Firewall Settings for Third Party OPC Client - System Connections

The firewall rules for Third Party OPC client - system connections are the same as those for ViewX - system connections. For more information, see Firewall Settings for Client - System and Server Advise Connections.


Client Administration Guide - Third Party ODBC Client - System Connections

Third Party ODBC Client - System Connections

You can use data from the ClearSCADA database in Third Party ODBC client applications such as Crystal Reports and Microsoft Excel. The data can be used in reports, spread sheets, other databases etc.

To use a Third Party ODBC client application to access your ClearSCADA system, you need to install the Data Access components of ClearSCADA on the same computer as the Third Party ODBC client application(s). This is because the Third Party ODBC applications need to use the Data Access components to connect to a ClearSCADA database.

We refer to computers that run Third Party ODBC applications and have Data Access components installed as Third Party ODBC Clients
.

Communications between the ClearSCADA server and the Data Access components installed on the ODBC client work in a similar way as communications between a ViewX client and
a ClearSCADA server. The only difference is that with an ODBC client, there is a single link that is used for client to server messages and server responses. There is no server advise link for unsolicited messages from the server. For more information, see Understanding Client - System and Server Advise Connections.

To allow a Third Party ODBC client to access the ClearSCADA system, the Data Access components have to be:

  • Installed on the computer that runs the Third Party ODBC application(s)
  • Able to access a valid connection to ClearSCADA on the ODBC client PC
  • Associated with a valid Data Access license.

To connect a computer that runs Third Party ODBC applications to the server:

  1. Check that the ClearSCADA Client connections are configured correctly (see Configure a Third Party ODBC Client - System Connection). A full ViewX connection is not required - a Data Access connection can be used instead.
  2. Check that you have a valid Data Access license by examining the License Details display (right-click on the server icon in the Windows taskbar then select the License Details option).

Further Information

Configure a Third Party ODBC Client - System Connection.


Client Administration Guide - Install Data Access Components on a Third Party ODBC Client (Third Party ODBC Client - System Connections)

Install Data Access Components on a Third Party ODBC Client

A Third Party ODBC client can only connect to a ClearSCADA server if it has the ClearSCADA Data Components installed. Once installed, the Data Components will handle the communications between the Third Party ODBC applications and the ClearSCADA server.

By installing the Data Access components, you allow the Third Party ODBC applications to access the ClearSCADA database on the ClearSCADA server using the TCP/IP protocol. This means that DCOM is not used and so the problems commonly associated with DCOM systems are avoided (see DCOM Issues).

NOTE: The Third Party ODBC client has to have a valid ClearSCADA connection (see Configure a Third Party ODBC Client - System Connection) and Data Access license (see Associate a Third Party ODBC Client - System with a Data Access License).

To install the ClearSCADA Data Access components on a computer that runs Third Party ODBC application(s):

  1. Log on to the PC that runs the Third Party application(s).
  2. Run the Setup.exe file that was supplied by Schneider Electric. This Microsoft Installer file initiates the ClearSCADA installation and is downloaded or supplied on digital media when you purchase your system. For more information, please contact your system administrator. When you run the setup.exe file, the ClearSCADA Setup Wizard runs.
  3. On the first page of the Wizard, select the Next button.
  4. On the second page of the Wizard, read the license agreement, select the ‘I acknowledge the terms in the License Agreement’ button, then select the Next button.
  5. On the third page of the Wizard, enter your user name and organization, then press the Next button.
  6. On the fourth page of the Wizard, select the Custom button.
  7. On the fifth page of the Wizard, select the Data Access branch and then choose either the Entire Feature will be Installed on Local Hard Drive or Will be Installed on Local Hard Drive options.
  8. Select the Next button, and on the sixth page, define a Super User account if required (check the Disable Super User account check box if you do not require a Super User). For more information, see Configure the Super User Account in the ClearSCADA Guide to Security.
  9. Select the Next button.
    The Data Access components installation process begins. When the process is complete, the Wizard displays a ‘Completing’ page.
  10. On the ‘Completing’ page of the Wizard, select the Finish button.

Now that you have installed the Data Access components on the computer that is running Third Party ODBC applications, you need to Configure a Third Party ODBC Client - System Connection and Associate a Third Party ODBC Client - System with a Data Access License.


Client Administration Guide - Configure a Third Party ODBC Client - System Connection (Third Party ODBC Client - System Connections)

Configure a Third Party ODBC Client - System Connection

After installing the Data Access components, you need to create a connection between the ClearSCADA server and the computer that is running the Third Party application(s). The connection will allow the Third Party application(s) to access the ClearSCADA database using ODBC.

To configure the Third Party ODBC client - system connection, you need to:

  1. Configure the Connection for the ClearSCADA Client
  2. Access the ODBC Data Source Administrator Tool:
  • If you are using 32-bit Windows, see Access the ODBC Data Source Administrator Tool
  • If you are using 64-bit Windows, see 64-Bit Applications on 64-Bit Windows.
  3. Configure the ODBC DSN Settings.

Further Information

Install Data Access Components on a Third Party ODBC Client


Client Administration Guide - Configure the Connection for the ClearSCADA Client (Third Party ODBC Client - System Connections)

Configure the Connection for the ClearSCADA Client

The first step when setting up a Third Party ODBC Client connection is to configure the connection for the ClearSCADA client:

  1. Log on to Windows on the PC that is running the Third Party application(s).
  2. Run the ClearSCADA Client applet (see Display the ClearSCADA Client Applet). On Windows Vista, Windows 7, Windows Server 2008 R1 and Windows Server 2008 R2, a User Account Control prompt may appear - select Continue on the prompt to allow the ClearSCADA Client applet to run.
  3. When the ClearSCADA Client applet runs, select the Add button to display the ClearSCADA Client Configuration window.
  4. Use the ClearSCADA Client Configuration window to create a new connection. The configuration you need to define is exactly the same as that for a ViewX - System connection, with these settings available:
  • System Name—see Define the System Name and Type for a ViewX Client - System Connection
  • Type—You need to select ClearSCADA Server (see Define the System Name and Type for a ViewX Client - System Connection)
  • Use Client Licensing—see Enable or Disable Client Licensing
  • Visible in ViewX—see Define Whether the System is Visible in ViewX
  • Node Name—see Define the Node Name for a Client - System Connection
  • Node Cost—see Define the Node Cost for a Client - System Connection
  • Compress—see Define the Client Compression Settings for a ViewX Client Connection
  • Advanced—see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection.
  5. When you have defined the connection settings, select the OK button to apply them. The Client Configuration window is closed and the new connection is added to the list on the ClearSCADA Client applet.
  6. If you need to adjust the Transmission Control Protocol/Internet Protocol settings, select the TCP/IP Tuning button to display the TCP/IP Tuning Parameters window. This feature works in exactly the same way as when configuring a ViewX - System connection. For more information, see Define the TCP/IP Tuning Settings for a ViewX Client - System Connection.
  7. Select the Licenses button to display the Client Licensing window. Use this window to associate the Third Party ODBC client with a data access license (see Associate a Third Party ODBC Client - System with a Data Access License).
  8. Close the ClearSCADA Client Applet.

Next, you need to access the ODBC Data Source Administrator Tool.

  • If you are using 32-bit Windows, see Access the ODBC Data Source Administrator Tool.
  • If you are using 64-bit Windows, see 64-Bit Applications on 64-Bit Windows.


Client Administration Guide - Access the ODBC Data Source Administrator Tool (Third Party ODBC Client - System Connections)

Access the ODBC Data Source Administrator Tool

To set up ODBC Access, you need to use the ODBC Data Source Administrator Tool. The location of the ODBC Data Source Administrator Tool varies according to the Third Party application you are running and whether it is 32-bit or 64-bit. In the following sections, we explain how to access the ODBC Data Source Administrator for:

  • All Applications on 32-Bit Windows
  • 32-Bit Applications on 64-Bit Windows
  • 64-Bit Applications on 64-Bit Windows

All Applications on 32-Bit Windows

If you are using a 32-bit Windows system, you need to use the ODBC Data Source Administrator Tool to set up ODBC access.

To access the ODBC Data Source Administrator Tool on a 32-Bit PC:

Either:

  • Run Data Sources (ODBC) from the Administrative Tools section of the Windows Control Panel

or:

  • In Windows, execute the following command:
%WINDIR%\System32\odbcad32.exe

This command will cause the ODBC Data Source Administrator Tool to run.

For information on how to execute a command in Windows, please refer to your Windows documentation.

You can now use the ODBC Data Source Administrator Tool to set up ODBC access (see Configure the ODBC DSN Settings).

32-Bit Applications on 64-Bit Windows

64-bit PCs have two ODBC Data Source Administrator Tools - one for 32-bit applications and one for 64-bit applications. If you are using a 32-bit application on a 64-bit PC, you need to use the 32-bit ODBC Data Source Administrator Tool to set up ODBC access.

You can use Microsoft Windows Explorer to access the 32-bit ODBC Data Source Administrator Tool:

  • In Windows, execute the following command:
%WINDIR%\SysWOW64\odbcad32.exe

This command will cause the 32-Bit ODBC Data Source Administrator Tool to run.

For information on how to execute a command in Windows, please refer to your Windows documentation.

You can now use the ODBC Data Source Administrator Tool to set up ODBC access (see Configure the ODBC DSN Settings).

Further Information

64-Bit Applications on 64-Bit Windows.

64-Bit Applications on 64-Bit Windows

64-bit PCs have two ODBC Data Source Administrator Tools - one for 32-bit applications and one for 64-bit applications. If you are using a 64-bit application such as Excel 2010 x64, you need to use the 64-bit ODBC Data Source Administrator Tool to set up ODBC access.

To access the 64-bit ODBC Data Source Administrator Tool:

Either:

  • Run Data Sources (ODBC) from the Administrative Tools section of the Windows Control Panel

or:

  • In Windows, execute the following command:
%WINDIR%\System32\odbcad32.exe

This command will cause the 64-Bit ODBC Data Source Administrator Tool to run.

For information on how to execute a command in Windows, please refer to your Windows documentation.

You can now use the ODBC Data Source Administrator Tool to set up ODBC access (see Configure the ODBC DSN Settings).

Further Information

Access the ODBC Data Source Administrator Tool

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Client Administration Guide - Configure the ODBC DSN Settings (Third Party ODBC Client - System Connections)

Configure the ODBC DSN Settings

When you have run the ODBC Data Source Administrator Tool (64-bit or 32-bit as appropriate), you can use its settings to configure ODBC access:

  1. Select the System DSN tab.

NOTE: Alternatively, you can setup the ODBC access via the User DSN tab, but this will only allow one specific user to access the ClearSCADA database via ODBC. The System DSN settings can be used to provide users with access to the ClearSCADA database via ODBC.

NOTE: If you create a user DSN on a computer running 64-Bit Windows, you need to be aware that there are differences between the ODBC Administrator Tools: The 32-bit version of the tool shows 32-bit system DSNs, 32-bit user DSNs, and 64-bit user DSNs, whereas the 64-bit version shows 64-bit system DSNs, 32-bit user DSNs, and 64-bit user DSNs.

  2. Select the Add button to display the Create New Data Source window.
  3. Select Schneider Electric ClearSCADA Driver then select the Finish button.
    The ODBC ClearSCADA Setup window is displayed.
  4. Use the ODBC Setup window to define these settings:
  • Name—Define the name for the DSN. This can be any name of your choosing. For more information, see Define the Name for the Data Source.
  • System—Use to choose the ClearSCADA system to which your Third Party ODBC Client will connect via the connection (see Define the ClearSCADA System to which the Data Source will Connect).
  • Login Timeout—Use the Login Timeout field to define the amount of time that the system will wait for a user to log on (see Define the Log On Timeout for the ODBC Connection)
  • Local Time—Use to define whether the ODBC driver converts the time values from ClearSCADA into Local Time or continues to use their UTC times (see Define whether ClearSCADA Converts Time Stamps to Local Time).
  • Return 1-Jan-1601 as NULL—Use to define whether ClearSCADA reports time and date values that have not yet been set as 1-Jan-1601 00:00:00 or as null (see Define whether ClearSCADA reports 1-Jan-1601 00:00:00 as Null)
  • User Name—Use to define the name of the ODBC Client user account that provides full access to ClearSCADA. We recommend that you leave the User Name blank, so that ClearSCADA User accounts are required to access the ClearSCADA database. For more information, see Define the Login Settings for a Data Source.
  • Password—You can use the Password setting to define the password that is used in conjunction with the ODBC Client User Name (see above). We recommend that you leave the Password blank, so that ClearSCADA User accounts are required to access the ClearSCADA database. For more information, see Define the Login Settings for a Data Source.
  • Allow Anonymous—Use to define whether Guest users on the ODBC Client can access the ClearSCADA database. We recommend that you clear the check box so that Guest users do not have access to ClearSCADA via ODBC. For more information, see Define the Login Settings for a Data Source.
  5. Select the OK button to confirm the settings and close the ODBC Schneider Electric ClearSCADA Setup window.
  6. Select the OK button to close the ODBC Data Source Administrator window.

NOTE: You can delete a System DSN by selecting it in the list on the System DSN tab and selecting the Remove button. You can also alter the System DSN configuration by selecting the System DSN in the list and selecting the Configure button.

To test that you have configured the data access connection correctly, we suggest that you set your Third Party ODBC application to issue an SQL query on the ClearSCADA server (refer to your Third Party ODBC application documentation for more details). An example query that would work from within MSQuery using SQL-92 standard language is:

'SELECT Name FROM CDBUser'

If the Third Party ODBC client connection has been installed and configured correctly, this will return a resultset containing the names of every user in the ClearSCADA database.

Further Information

Time Zones: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.

Define the Name for the Data Source

When you create a connection between a ClearSCADA system and a Third Party ODBC Client, you need to specify a name for the data source. You will be able to use the name you enter to identify the connection.

You can enter any name, but we recommend that the name you use makes it easy for other users to identify the connection too.

To define the Data Source Name (DSN), display the ODBC Setup window (see Configure the ODBC DSN Settings), then enter the required DSN in the Name field.

Define the Log On Timeout for the ODBC Connection

You can use the Login Timeout setting on the ODBC Setup window to define the default amount of time permitted for a successful connection. If the Third Party ODBC client cannot connect to the ClearSCADA server via the ODBC connection within the Login Timeout, the connection is deemed to have failed.

The Login Timeout is the default amount of time permitted for the connection. However, the Third Party ODBC client can have its own connection timeout settings that take precedence over the Login Timeout on the ODBC Setup window.

To define the Login Timeout, display the ODBC Setup window (see Configure the ODBC DSN Settings), then enter the appropriate amount of time (in seconds) in the Login Timeout field. The default setting is 15 seconds, which is appropriate for many ODBC clients.

Define the ClearSCADA System to which the Data Source will Connect

When you create a connection between a ClearSCADA system and a Third Party ODBC Client, you need to choose which ClearSCADA system is to be associated with that connection. Each DSN connection can only be used to connect an ODBC Client with 1 ClearSCADA system. If you need to connect the ODBC Client to multiple ClearSCADA systems, you will need to create a separate DSN for each ClearSCADA system.

To associate a ClearSCADA system with a DSN, display the ODBC Setup window (see Configure the ODBC DSN Settings), then use the System combo box to select the system that is to be accessed.

Define whether ClearSCADA Converts Time Stamps to Local Time

Time stamps from the ClearSCADA server use UTC (Co-ordinated Universal Time), but you can configure your DSN connection so that ClearSCADA converts the times, dates and time stamps from UTC to Local Time. Local time is the local time zone, with Daylight Saving Time where applicable, on the client on which you are configuring the DSN.

If you enable Local Time conversion, the conversion is applied in both directions - UTC times, dates, and time stamps from ClearSCADA are converted into local time at the client, and queries from the client to ClearSCADA are converted from the client’s local time to UTC.

ClearSCADA will convert any dates/time stamps in SQL queries from local time to UTC (before passing the query to the ClearSCADA server). The following date/time stamp formats are supported:

{d 'YYYY-MM-DD'}
{ts 'YYYY-MM-DD HH:MM:SS.sss'}
DATE 'YYYY-MM-DD'
TIMESTAMP 'YYYY-MM-DD HH:MM:SS.sss'

You can use the Local Time check box on the ODBC Setup window to define whether times, dates, and time stamps are converted from UTC into Local Time/Local Time into UTC:

  1. Display the ODBC Setup window (see Configure the ODBC DSN Settings)
  2. Use the Local Time check box to define your preference:
  • Select (check) the Local Time check box to enable Local Time conversion for the DSN connection. When the client sends a query to ClearSCADA, ClearSCADA will convert the dates and time stamps from the client’s local time into UTC. Similarly, when the client receives data from ClearSCADA, the client will convert the dates and time stamps from UTC into local time.
  • Clear the Local Time check box if time conversion is not to be used. Dates and time stamps will be in UTC.

Define whether ClearSCADA reports 1-Jan-1601 00:00:00 as Null

In ClearSCADA, the default date and time value for items that have not yet had their date and time value set is 1-Jan-1601 00:00:00. For example, a new database point that has not had its date and time set will have a date and time value of 1-Jan-1601 00:00:00.

Some ODBC clients do not support dates as far back as 1-Jan-1601 00:00:00. For example, SQL Server 2005 does not support time stamps as far back as 1-Jan-1601 00:00:00, and so it experiences problems if the ClearSCADA contains items with the default date and time setting. By using the Return 1-Jan-1601 as NULL check box, you can avoid such problems—you can set ClearSCADA to report 1-Jan-1601 00:00:00 as null. The null value can be recognized by those ODBC clients that do not support the default 1-Jan-1601 00:00:00 date and time value.

To define whether ClearSCADA reports 1-Jan-1601 00:00:00 as null, you need to display the ODBC Setup window (see Configure the ODBC DSN Settings), then use the Return 1-Jan-1601 as NULL check box:

  • Select the Return 1-Jan-1601 as NULL check box to configure ClearSCADA to return a null value for any time that has yet to be set. For example, if there is a new database point that has not had its time set, it will have a null value instead of the default 1-Jan-1601 00:00:00 value.
  • Clear the Return 1-Jan-1601 as NULL check box if you are certain that your ODBC client supports 1-Jan-1601 00:00:00.

Define the Login Settings for a Data Source

To access the ClearSCADA database, ODBC clients have to log on via a User account. This can be any ClearSCADA user account, including the Guest user, or can be a pre-defined user that is configured for the system DSN.

  • If you use a pre-defined user account, the log in details do not have to be entered each time the system DSN is used to access the ClearSCADA database. (The username and password defined in the DSN setup are used automatically).
  • If you do not use a pre-defined user account, each time the system DSN is used to access the ClearSCADA database, you will be prompted to log on.

For security reasons, we recommend that you configure your ODBC connection so that it does not use the Username and Password settings. If you leave these settings blank, users on the ODBC Client will have to enter a username and password each time the system DSN is used to access the ClearSCADA database. This gives your system added security.

However, if required, you can set up your system DSN so that it uses a defined username and password; there is no need to log on each time the system DSN is used. To configure this (less secure) set up for the system DSN:

  1. Display the ODBC Setup window (see Configure the ODBC DSN Settings).
  2. Use the Login fields and check box to determine the security for the System DSN:
  • Use the Username and Password fields to define the user credentials for logging in. The user credentials will be used for the DSN (unless there are other user credentials defined by the Third Party ODBC application, in which case, they override the DSN settings). This means that anyone with access to the DSN can access the ClearSCADA database without needing their own ClearSCADA user account.

If you leave the Username and Password settings empty (blank), you will be prompted to log on when you access the ClearSCADA database via the DSN. The only exception to this rule is if you leave the Username and Password settings empty and also check the Allow Anonymous check box, as this will allow the DSN to access the ClearSCADA database via the Guest user account.

  • Use the Allow anonymous check box to define whether the DSN can access the ClearSCADA database via the Guest user account (anonymous log on).
  • If you check the Allow anonymous check box and leave the Username and Password fields blank, the DSN can access the ClearSCADA database via the Guest user account.
  • If you clear (uncheck) the Allow anonymous check box, the DSN can only access the ClearSCADA database if a user logs on manually or if a Username and Password are defined for the DSN (either in the DSN setup or in the Third Party ODBC application).

For security reasons, we recommend that you leave the Username and Password settings empty (blank) and clear the Allow Anonymous check box. This will configure the ODBC connection so that any user with access to the DSN has to provide log on details in order to access the ClearSCADA database.

Further Information

Login Timeout: see Define the Log On Timeout for the ODBC Connection.


Client Administration Guide - Associate a Third Party ODBC Client - System with a Data Access License (Third Party ODBC Client - System Connections)

Associate a Third Party ODBC Client - System with a Data Access License

Third Party ODBC client connections require a license in order to connect to ClearSCADA. There are 2 types of licensing available:

  • Client licensing—The Third Party client is associated with a license file provided by Schneider Electric. The content of the license file defines:
  • The amount of time for which the client can connect to systems via the Third Party ODBC client - system connection. When this time period passes, the license expires and a new license will be required
  • The versions of ClearSCADA to which the ODBC client can connect via the Third Party ODBC client - system connection
  • The number of ClearSCADA systems to which the ODBC client can connect.

If a client license is to be used, the client licensing feature needs to be enabled for the connection (see Configure a Third Party ODBC Client - System Connection) and you will need to associate the client with a license file. If the license file is invalid or missing, the client will attempt to use server licensing instead.

The settings for your client license are determined when you purchase ClearSCADA. If you contact the sales representative that sold the product to you, they will be able to provide additional detail about the specific limits of your license.

  • Server licensing—The Third Party client uses one of the server’s licenses. Each server is allocated a pre-determined amount of data access licenses which can be used by clients. For example, if a server has 20 licenses, it can allow up to 20 clients to connect to ClearSCADA using one of the server licenses. Each client that is not using client licensing uses one of the available server licenses. If there are no available server licenses, clients without client licenses will not be able to connect (until some of the server’s licenses become available again).

If a client has a client license, this is used in preference to a server license. If the client license file is missing or corrupt, a server license will be used instead (even if the client licensing feature is enabled).

If the client licensing feature is disabled, server licenses are the only licenses that can be used.

If you have enabled client licensing, you will need to associate the Third Party ODBC client - system connection with a client license file:

  1. Access the ClearSCADA Client Configuration window (see Display the ClearSCADA Client Applet).
  2. Select the Third Party ODBC client - system connection in the list of connections.
  3. Select the Licenses button to display the Client Licensing window.
  4. Use the browse button next to the License File field to browse to the .lic license file supplied by your ClearSCADA vendor. Select the .lic file, then select the OK button to close the browse window and confirm your selection.

You will see that the details of the license are shown in the fields on the Client Licensing window. Your Third Party ODBC client will be counted against the Data Access Systems limit. So, if your license has a Data Access Systems limit of 10 and this is the first Third Party ODBC client - system connection you have associated with the license, you will be able to use the license for a further 9 Third Party ODBC client - system connections.

  5. Select the Apply button to instigate the license settings.
  6. Select the OK button to confirm your choices and close the Client Licensing window.
  7. Select the Close button to exit the ClearSCADA Client applet.

If the connection has been correctly configured (see Configure a Third Party ODBC Client - System Connection), and the network is healthy, you should now be able to browse to your ClearSCADA system from the Third Party ODBC client application.

Further Information

Check the Status of a Third Party ODBC Client - System Connection.


Client Administration Guide - Check the Status of a Third Party ODBC Client - System Connection (Third Party ODBC Client - System Connections)

Check the Status of a Third Party ODBC Client - System Connection

Typically, you would use the Third Party ODBC client application to monitor the status of the its connection to ClearSCADA. Many ODBC applications include connection status tools (for more information, please refer to the documentation supplied with your ODBC product).

However, you can also view the status of the Third Party ODBC client - system connection in ClearSCADA by using the Server Status Tool which is available for use on the server PC. For more information on how to display it, see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool.

To view the status of a Third Party ODBC client - system connection, you need to view the Server>Links status settings. The Server Links settings provide information about every client - system connection including the Third Party ODBC client - system connections. The information provided includes the amount and size of data sent from the Third Party ODBC client to the server and from the server to the Third Party ODBC client in response to the requests. For more information, see Links (Server) in the ClearSCADA Guide to the Server Status Tool.

Further Information

Failed Third Party ODBC Client - System Connections


Client Administration Guide - Failed Third Party ODBC Client - System Connections (Third Party ODBC Client - System Connections)

Failed Third Party ODBC Client - System Connections

If the Third Party ODBC client - system connection cannot be established, you will be unable to connect to ClearSCADA from the Third Party ODBC client application.

The connection may fail to establish if:

  • There is a network failure. You will need to investigate your network infrastructure and repair any faults.
  • A firewall is in place and is incorrectly configured. The firewall has to allow the ODBC client to send data to the ClearSCADA server’s incoming port (5481 by default). It also has to allow the ClearSCADA server to send data via the server advise connection (which uses one of the ports in the ODBC client’s Sockets range, 5500 to 5509 inclusive by default).

The Third Party ODBC Client - system connection works in the same way as a ViewX - system except that it uses a different license and it requires Data Access components (to be installed on the computer that is running the Third Party ODBC applications). The firewall rules for Third Party ODBC Client - System connections are the same as those for ViewX - system connections. For more information, see Firewall Settings for Client - System and Server Advise Connections.


Client Administration Guide - Firewall Settings for Third Party ODBC Client - System Connections (Third Party ODBC Client - System Connections)

Firewall Settings for Third Party ODBC Client - System Connections

The firewall rules for Third Party ODBC client - system connections are the same as those for ViewX - system connections. For more information, see Firewall Settings for Client - System and Server Advise Connections.


Client Administration Guide - Citrix or Terminal Services Client - System Connections

Citrix or Terminal Services Client - System Connections

ClearSCADA supports the Citrix XenApp 5 and Microsoft Terminal Services remote desktop applications. With these applications, you can allow Citrix/Terminal Services clients to have access to the features of ViewX without having ViewX installed locally.

To access ClearSCADA, a Citrix/Terminal Services client connects to ViewX, which has to be running on the Citrix/Terminal Services server. The Citrix/Terminal Services server creates a separate ‘instance’ of ViewX for each Citrix/Terminal Services client, but only needs to run one ViewX application. The separate ‘instances’ of ViewX allow each Citrix/Terminal Services client to interact with ClearSCADA independently, in the same way as if they were running ViewX locally.

For a Citrix/Terminal Services client to be able to access ClearSCADA, the Citrix/Terminal Services server has to have ViewX installed and has to be set up to connect with the ClearSCADA server (). You also need to configure a ViewX connection for each instance of ViewX that will run on the Citrix/Terminal Services server.

To configure a ViewX connection for an ‘instance’ used by a Citrix/Terminal Services client, you need to:

  1. Access the ClearSCADA Client Configuration window on the Citrix/Terminal Services server (see Display the Client Configuration Window).
  2. Add and configure a new ViewX connection for each instance of ViewX that will need to run on the Citrix/Terminal Services server. The configuration of these ViewX connections is the same as when configuring a connection between the ClearSCADA server and a ViewX client (see ViewX Client - System Connections).

When you have created the required connections, your Citrix/Terminal Services clients will be able to access the ViewX features without having ViewX installed locally. (They will use an ‘instance’ of ViewX that is running on the Citrix/Terminal Services server).

You can check the status of the connections, and troubleshoot any connection problems in the same way as you would for a ViewX connection (see ViewX Client - System Connections).

Further Informationsee Citrix or Terminal Services Client - System Connections

Citrix and Terminal Services: see ClearSCADA on Citrix and Terminal Services in the ClearSCADA Guide to Server Administration.


Client Administration Guide - Client Logging

Client Logging

ClearSCADA includes client-side logging features that provide diagnostic data for client activity. The information included in the log files can be useful when investigating connection problems, issues with initialization, etc.

There are three types of log files available for clients:

  • DB Client log files—Contain low-level information about the connections between the client and the server.
  • ViewX log files—Contain information about user activity in ViewX on the client.
  • ODBC log files—Contain information about the ODBC requests made by Third Party applications.

In this section, we explain how to:

  • Enable, disable, and edit the client log file settings (see Using a Registry Editor to Change Client Log File Settings)
  • Access DB Client log files (see DB Client Logging)
  • Access ViewX log files (see ViewX Logging)
  • Access ODBC log files (see ODBC Logging).


Client Administration Guide - Using a Registry Editor to Change Client Log File Settings (Client Logging)

Using a Registry Editor to Change Client Log File Settings

You can use a registry editor such as Regedit to edit the client log file settings and enable or disable the three types of client logging. The log file settings include the maximum number of files, location of files etc.

To use a registry editor to change log file settings:

  1. Select the Start button on the Windows taskbar, then select the Run option to display the Run window.
  2. Enter the following text in the Open field and select OK to run the registry editor:
Regedit

  3. Use the Registry Editor to locate the registry settings at the relevant location:
  • DB Client—The registry settings are at:
HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\DBClient

Or:

HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\DBClientNamed
  • ODBC—The registry settings are at:
HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\DBOdbc

  • OLE DB—The registry settings are at:
HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\OLEDB
  • ViewX—The registry settings are at:
HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\ViewX

NOTE: For information on the location of the registry settings for server-side logging, see Logging and Monitoring in the ClearSCADA Guide to Server Administration.

  4. Define the registry settings:
  1. Right-click on a setting to display a context sensitive menu. The settings include:
  • LogEnable—Enter True, Yes, T, Y, or 1 to enable logging or enter False, No, F, N, or 0 to disable logging as required.
  • LogFileBase—Define the folder that will contain the log files and the filename prefix for the files. The prefix is the name of the files (it cannot contain certain characters, see your operating system documentation for more details).
  • LogMaxFiles—Enter the maximum amount of log files permitted for each set of log files. When a new log file is created, the oldest log file is deleted (to make way for the new file).
  • LogMaxSize—Enter the largest possible size for a log file. The size is in kilobytes.
  • LogOldFiles—Enter the number of sets of log files that can be stored for each instance of an application (each Process ID for ODBC and Client logs or each head for ViewX logs).

For many systems, the default setting of 1 is adequate.

  2. Select the Modify option to display the Edit window.
  3. Enter the required setting in the Value Data field (see step i for the required settings).
  4. Select the OK button to confirm the setting.

Repeat the sub-procedure (i-iv) for each logging setting.


Client Administration Guide - DB Client Logging (Client Logging)

DB Client Logging

DB Client log files contain low level information about the connections between the client(s) and the ClearSCADA server. This includes information about each request made by the client and the responses received by the client. DB Client log files are useful when investigating problems with client-server connections.

There are two groups of DB Client log files:

  • Named—The log file is from a named ClearSCADA program. Named DB Client files use the following file name convention:
DBClient_<program name>_nnn.log

Where:

  • <program name> is the name of the ClearSCADA program that created the file, for example, ViewX_Head1. The angle brackets <> are not included.
  • nnn is the number of the log file, for example, 001 is the first log file, 002 is the second log file, 003 is the third log file and so on.
  • Anonymous—The log file is from a Third Party client. Anonymous DB Client files use the following file name convention:
DBClientxxxx_nnn.log

Where:

  • xxxx is the process Id as a 4 digit hexadecimal value.
  • nnn is the number of the log file, for example, 001 is the first log file, 002 is the second log file, 003 is the third log file and so on.

To enable or disable client logging, you need to configure the logging settings via a registry editor (see Using a Registry Editor to Change Client Log File Settings)

To display a client log file:

  1. Use Windows Explorer to locate the log file. The log files are stored at the location that is specified in the LogFileBase registry setting.

The location of the LogFileBase registry setting is:

HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\DBClient\LogFileBase

  2. Open the log file in a text editor program, for example, Microsoft Windows Notepad.


Client Administration Guide - ViewX Logging (Client Logging)

ViewX Logging

ViewX log files contain information about each head on a client (each instance of the ViewX application). This includes information about the documents on display, logging on, initialization at start-up etc.

To enable or disable ViewX logging, you need to configure the logging settings via a registry editor (see Using a Registry Editor to Change Client Log File Settings)

To display a ViewX log file:

  1. Use Windows Explorer to locate the log file. The log files are stored at the location that is specified in the LogFileBase registry setting.

The location of the LogFileBase registry setting is:

HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\ViewX\LogFileBase

Open the log file in a text editor program, for example, Microsoft Windows Notepad.


Client Administration Guide - ODBC Logging (Client Logging)

ODBC Logging

Each application that uses ODBC to access the database generates a separate set of log files. The log files are stored on the computer on which the application is running. Each log file has a name that includes the process ID of the application (in hexadecimal). The process ID part of the file name is used to indicate the application to which the log file relates. For example, an application with a process ID 03B0 could produce a log file named 'DBOdbc03B0_001.log'.

If you require ODBC logging, you need to define the ODBC logging settings. Typically, you will need to do this on a client PC by editing the registry settings.

In this section, we explain how to: Change the Registry Settings for ODBC Logging on a Client.


Client Administration Guide - Change the Registry Settings for ODBC Logging on a Client (Client Logging)

Change the Registry Settings for ODBC Logging on a Client

To enable ODBC logging on a client PC, you need to change the registry settings. By doing this, you setup the client PC to generate log files relating to its ODBC applications that access ClearSCADA 6 databases.

To change the registry settings for ODBC logging on a client PC:

  1. Select the Start button on the Windows taskbar, then select the Run option to display the Run window.
  2. Enter the following text in the Open field and select OK to run the registry editor:
Regedit

  3. Use the Registry Editor to locate the registry settings at:
HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\DBOdbc

  4. Define the registry settings:
  1. Right-click on a setting to display a context sensitive menu. The settings include:
  • LogEnable—Enter True, Yes, T, Y, or 1 to enable the ODBC logging or enter False, No, F, N, or 0 to disable the ODBC logging as required.
  • LogFileBase—Enter the location of the log files, for example, C:\TEMP\ODBClog. The location is the name of the folder that will contain the ODBC log files and the filename prefix for the files. The prefix is the name of the files (it cannot contain certain characters, see your operating system documentation for more details).
  • LogMaxFiles—Enter the largest number of ODBC log files in each set of ODBC log files. When a new ODBC log file is created, the oldest ODBC log file is deleted (to make way for the new file).
  • LogMaxSize—Enter the largest possible size for an ODBC log file. The size is in kilobytes. By limiting the size of individual log files, you can make the files more manageable, for example you can limit their size so that they are suitable for viewing in Notepad and sending via e-mail.

Example:

The server is running the Crystal Reports driver which uses ODBC to access the database. The Crystal Reports driver has a process ID of 03B0.

The maximum number of files is set to 2, and there are already 2 files: DBOdbc03B0_001.log and DBOdbc03B0_002.log

When the DBOdbc03B0_002.log has reached its maximum size, a third log file is created—DBOdbc03B0_003.log. To make room for the new file, the oldest log file (DBOdbc03B0_001.log) is deleted.

  • LogOldFiles—Enter the number of sets of log files that can be stored for each instance of an application (each Process ID). For many systems, the default setting of 1 is adequate.

If the number of log file sets reaches the defined amount for a Process ID, any new sets of log files will use the space occupied by the oldest existing log files (the oldest sets of files are deleted). The existing files are renamed.

The renaming of ODBC log files works in the same way as the renaming of other log files such as server log files, with the oldest set of files being deleted and the other file names incrementing by one (see Server Logging in the ClearSCADA Guide to Server Administration).

  2. Select the Modify option to display the Edit window.
  3. Enter the required setting in the Value Data field (see step i for the required settings).
  4. Select the OK button to confirm the setting.
  5. Repeat the sub-procedure (i-iv) for each ODBC logging setting.

Further Information

Display an ODBC Log File.


Client Administration Guide - Display an ODBC Log File (Client Logging)

Display an ODBC Log File

To display an ODBC log file, you need to:

  1. Use Windows Explorer to locate the ODBC log file. The log files are stored at the location that is specified in the LogFileBase registry setting.

The location of the LogFileBase registry setting is:

HKEY_CURRENT_USER\SOFTWARE\Schneider Electric\ClearSCADA\DBObdc\LogFileBase

  2. Open the ODBC log file in a text editor program, for example, Microsoft Windows Notepad.


Client Administration Guide - Enable or Disable ODBC Logging (Client Logging)

Enable or Disable ODBC Logging

To enable or disable ODBC logging, you need to change the registry settings. For more information, see Change the Registry Settings for ODBC Logging on a Client.


Client Administration Guide - Define the File Settings for ODBC Logging (Client Logging)

Define the File Settings for ODBC Logging

To define the file settings such as maximum file size and maximum number of files for ODBC logging, you need to change the registry settings. For more information, see Change the Registry Settings for ODBC Logging on a Client.


Client Administration Guide - Define the Location of ODBC Log Files (Client Logging)

Define the Location of ODBC Log Files

To define the location of the ODBC log files, you need to change the registry settings. For more information, see Change the Registry Settings for ODBC Logging on a Client.


Client Administration Guide - DCOM Issues

DCOM Issues

Many OPC systems use Distributed Component Object Model (DCOM) for communications over a network. Unfortunately, OPC systems can be affected by several problems when DCOM is used, such as:

  • Timeouts
  • Security
  • Reliability issues.

Although ClearSCADA uses OPC-based technology, it is unaffected by the problems commonly associated with DCOM. This is because the ClearSCADA server is an in-process COM server—it uses data access components to act as the transport mechanism between the server and clients.

Data access components (dbclient.dll) are installed on the clients and use standard Windows TCP/IP sockets. This avoids the problems caused by DCOM as it means that OPC messages are transported between the ClearSCADA server and clients via the TCP/IP socket that is controlled by ClearSCADA.

By installing Data Access Components on client PCs, you set the client PCs so that:

  • There is only one way of accessing the ClearSCADA server (via the Data Access Components).
  • Access to the server is logged in the Event List and can be tracked
  • ClearSCADA has control over the TCP/IP sockets, so it is easy to adjust timeouts and security settings to meet the requirements for your system.

To set up your system so that it is not affected by DCOM related issues, we strongly recommend that you:

  • Install any Third Party OPC server applications on the same PC as the ClearSCADA server. If the OPC server and ClearSCADA server are installed on the same computer, ClearSCADA can communicate with the OPC server locally and so will not be subject to any DCOM issues.

If you cannot install a Third Party OPC application on the same PC as the ClearSCADA server, you will need to configure DCOM. If the OPC server in ClearSCADA is set to run in Synchronous mode, DCOM on the Third Party OPC server needs to be configured to allow the incoming communications from the ClearSCADA server. If the OPC server in ClearSCADA is set to run in either of the Asynchronous modes, DCOM on the Third Party OPC server needs to be configured to allow incoming communications from the ClearSCADA server and also outgoing communications to the ClearSCADA server.

Again, this can be difficult to implement and for further information on configuring DCOM you should refer to your Microsoft Windows documentation.

For more information on Synchronous and Asynchronous modes, please refer to the ClearSCADA Guide to the OPC Driver.


Security Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Security Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Security Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Security Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Security Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Security Guide - Document Scope (About the Guide)

Document Scope

This guide explains the concept of ClearSCADA security, including User accounts, User Groups, and permissions. It also describes the various security settings and provides information on configuring the security features for your system.

For more information about the security-related concepts and settings that are covered in this Guide, see Welcome to the Security Guide.


Security Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for system administrators and engineers who are responsible for managing and configuring the various security features, such as User accounts and User Groups.


Security Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Security Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Alarms

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Mimics

ClearSCADA Guide to Logic

ClearSCADA Guide to Lists

ClearSCADA Guide to Drivers

ClearSCADA Guide to the Pager Driver

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


Security Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Security Guide - Welcome to the Security Guide

Welcome to the Security Guide

Welcome to the Security Guide. Here you will find information on setting up the security features of your system, including:

  • Understanding ClearSCADA Security
  • Setting up System Security
  • User Accounts
  • User Groups
  • Allocating Security Permissions
  • Actions Associated with Users and User Groups
  • Users List
  • Exclusive Control
  • Recommended Security Settings.


Security Guide - Understanding ClearSCADA Security (Welcome to the Security Guide)

Understanding ClearSCADA Security

The security features are designed to:

  • Help protect your system from unauthorized users
  • Restrict user access to items and features so that users only make use of those features for which they have been suitably trained
  • Allocate security permissions quickly and with minimal effort.

The main points to consider when preparing yourself to set up the security for your system are:

  • Security can be enabled or disabled for a system via the Server Configuration Tool. You can also use the Server Configuration Tool to configure the default settings that will apply to every new user account (they can be changed for each user account individually via the User Form). For more information, see Security Settings at the Server.
  • Once security is enabled, it restricts access to your system by using permissions and user accounts (see Understanding User Accounts).
  • Security permissions can be denied to every ViewX and WebX user, every ViewX user, and/or every WebX user from the Server Configuration Tool. These settings override the security settings of user accounts. So, if you configure a user account to have the Configure permission, that user will only have the Configure permission if Configure is not denied in the Permission Restrictions settings. For more information, see Security Settings at the Server.
  • To access the system, a user has to log on via a user account (or be logged on automatically via the Guest or Web user accounts). The permissions that are allocated to those accounts for each database item determine which features you can access. For more information, see Understanding User Accounts.
  • Each database item has its own security settings that define which user accounts and User Groups can access the item, and which features are available. This is called the Access Control List (ACL) for the item (see Understanding the Access Control List (ACL)).
  • Each user account can be denied access to certain features in ViewX (see ViewX Specific Security Features).
  • Third Party applications that access ClearSCADA will use a configured user account or the Guest or Web user account, depending on whether client security is supported by the Third Party application (see Security for Third Party Applications).


Security Guide - Security Settings at the Server (Welcome to the Security Guide)

Security Settings at the Server

Security is applied by the ClearSCADA servers to every client that accesses the system (ViewX, WebX, Third Party OPC applications etc.). For example, a user that accesses the system via a Third Party OPC client is subject to the same restrictions as when accessing the system via ViewX.

As security is applied by the server(s), you need to access the Security section on the Server Configuration Tool to enable or disable security for your system. Security is enabled by default (see Define the Level of System Security).

When you first run the Server Configuration Tool, you are automatically logged on via the Guest user account (unless your system has already been configured to have user accounts in which case you will be requested to log on). The Guest user has full access permissions by default.

The Security section of the Server Configuration Tool also allows you to define:

  • Whether security is enabled
  • The default settings for new user accounts. These settings are applied to each new user account on your system but can be altered as required (via the User Form).
  • Which permissions are available.

For more information on configuring these settings, see Setting up System Security.

The Server Configuration Tool also provides access to the Permission Restrictions settings. The Permission Restrictions settings allow you to stop certain permissions from being available to every ViewX user, every WebX user, or every system user (ViewX users and WebX users). The Permission Restrictions settings override the other security settings. For example, if the Configure permission is restricted for ViewX users and you log on to ViewX via a user account with Configure permissions, you will not be able to configure any database items. Even though your user account has the Configure permission, it is limited by the Permission Restrictions settings. To perform any action on your system, your user account needs the relevant permission (and the permission has to be unrestricted).

For more information on permission restrictions, see Setting up System Security.


Security Guide - Understanding User Accounts (Welcome to the Security Guide)

Understanding User Accounts

User accounts are designed to help protect your system from unauthorized access and to restrict the features that are available to different users. For example, you can configure a user account so that it allows the user of that account to view alarms but does not allow them to interact with the alarms.

Users are required to log on via a configured user account or are logged on automatically via a built-in user account. The security settings for each database item define which features (for each item) are available to the user account.

When you first install ClearSCADA, the only user accounts that exist are the two Built-In User Accounts, Guest and Web. When a user accesses ViewX without logging on, they automatically use the Guest user account; if a user accesses WebX without logging on, they use the Web user account.

As you set up your system security, you will create ‘authenticated’ user accounts, which are referred to as Configured User Accounts. Typically, you will need to create an ‘authenticated’ user account for each user.

Every item in the database has its own security settings. By configuring the security settings, you can control which user accounts have access to the various features of a database item (or group of database items if you configure the security settings of a Group). You do this by granting ‘permissions’ to each user account as required. For example, you could configure the security settings of a point so that one user account has the permissions required to configure the point and respond to its alarms, whereas another user account only has the permissions to view the point. You can find out more about the various permissions in Allocating Security Permissions.

Every database item has security settings that allow you to specify which user accounts have access to the item...
...and also which of the item’s features are available to each user account (via allocated permissions).

You can grant each user account its own permissions for each individual database item, or group of database items. By default, if a user account has the permissions for a Group item, it also has the same permissions for the items within that Group. However, you can reconfigure the security settings for items in the Group so that access is restricted as required.

You can also associate a user account with a User Group. When a user account is part of a User Group, it means the user of that account is granted the permissions of the user account and the permissions of the User Group (see Understanding User Groups).

When you first install ClearSCADA, the only User Group that exists is the ‘Everyone’ User Group, which is a built-in User Group (see Built-In User Groups). No matter which user account you use to access ClearSCADA, you are automatically given the permissions that have been allocated to the ‘Everyone’ User Group.

When a user interacts with ViewX or WebX, ClearSCADA assesses the user account that is being used to determine which features and items are available to that user:

  • In ViewX:

If the user is not logged on via a configured user account, it means they are logged on automatically via the built-in Guest account.

A user logged on via the Guest account has the permissions that are allocated to:

  • The ‘Everyone’ built-in User Group
  • The Guest user account

If the user is logged on via a configured user account, they have the permissions that are allocated to:

  • The configured user account they are using
  • The ‘Everyone’ built-in User Group
  • Any configured User Groups of which their user account is a member.
  • In WebX:

If the user is not logged on via a configured user account, it means they are logged on automatically via the built-in Web account.

A user logged on via the Web account has the permissions that are allocated to:

  • The ‘Everyone’ built-in User Group
  • The Web user account

If the user is logged on via a configured user account, they have the permissions that are allocated to:

  • The configured user account they are using
  • The ‘Everyone’ built-in User Group
  • Any configured User Groups of which their user account is a member.

NOTE: You can also restrict access to certain features via the User Form for each user account. Changing the configuration of a user account does not affect the permissions, but can stop a user from being able to access certain features (even if they do have the necessary permissions).

Built-In User Accounts

If you use the system without logging on via a user-created ‘configured’ user account, ClearSCADA logs you on automatically via one of the two built-in user accounts:

  • Guest—The Guest user account is the default user account for access via ViewX, OPC, ODBC, and Automation.
  • Web—The Web user account is the default user account for access via any Internet based interface, for example WebX.

NOTE: Third Party applications that do not support client security will have the same access permissions as those you have allocated to the Guest user account.

The features that you can access via the Guest and Web user accounts are restricted by permissions. The security settings for each item in the database will define which of that item's features are available to the Guest and Web users. In ViewX, the configuration of the Guest user account can apply further restrictions (see Configuring the Guest and Web User Accounts).

When you first install ClearSCADA, the Guest user account has full access permissions and the Web user has read-only permissions. You can reconfigure the security settings on your system so that they provide different permissions as required. But remember that when a user accesses ClearSCADA via the Guest or Web user account, they also have the permissions that have been allocated to the built-in ‘Everyone’ User Group (see Built-In User Groups).

Both the Guest and Web user accounts are ‘unauthenticated’ accounts; they are built-in user accounts that have no corresponding User database item.

NOTE: If you use the USERNAME() expression function, it will return GUEST if the current user is not currently logged on. This is true irrespective of whether the client is ViewX or WebX.

Configured User Accounts

Configured user accounts are custom user accounts that you configure on your system. Typically, you would create a configured user account for each system user.

Each configured user account is represented in the database by a User database item. In the configuration of the User item, you can define various settings for the user account, including a username and password (the user name is the name you give to the User item). When a user logs on to the system via the user account, they will need to enter the correct username and password.

When a user logs on via user account, they can only access those features that are made available to their user account. A configured user account has the following permissions:

  • The permissions allocated to the built-in ‘Everyone’ User Group
  • The permissions allocated to any configured User Groups of which the user account is a member (see Understanding User Groups). The permissions are allocated to the User Groups on a per item basis in the Security settings of each database item.
  • The permissions allocated to the configured user account itself. The permissions are allocated to the User Groups on a per item basis in the Security settings of each database item.

You can also restrict access to certain features via the User Form for each user account. Changing the configuration of a user account does not affect the permissions, but can result in a user being able to access certain features (even if they do have the necessary permissions).

To create and configure a ‘configured’ user account, see Creating a User Account.

NOTE: If a user accesses the system without logging on via a configured user account, they are logged on automatically via one of the Built-In User Accounts.

Further Information

User Accounts for System Users

User Accounts for Third Party Applications

Permissions for Working with User Accounts and User Groups

Creating a User Account

User Account Permissions

Logging On and Off via a User Account

Changing the Password for a User Account.


Security Guide - Understanding User Groups (Welcome to the Security Guide)

Understanding User Groups

User Groups are database items that represent a collection of user accounts. They are designed to make it easier to allocate permissions to multiple user accounts.

When you create a User Group, it does not represent any particular user accounts; it is simply a database object to which you can apply permissions. However, when you configure a user account to be a ‘member’ of the User Group, the person who logs on via the user account is granted:

  • The security permissions that have been allocated to the User Group

and

  • The security permissions that have been allocated to their user account.

Of course, the user also has the permissions that have been allocated to the ‘Everyone’ User Group as these apply to every user account. They also have the permissions of the Guest user or the Web user, depending on whether they are logged on via ViewX or WebX.

When you associate user accounts with a User Group, that User Group becomes a single item that represents all of its ‘members’.

Typically, you would create a User Group to represent a group of users. By granting permissions to the User Group, you could reduce the need to configure permissions for individual user accounts.

For example, let’s say you have a team of 20 operators who all need the same low level permissions. Rather than configure the permissions for each of the 20 user accounts individually, you could create an ‘Operators’ User Group. You could then associate the 20 user accounts with the ‘Operators’ User Group, and apply the permissions to the User Group rather than the individual user accounts. Working this way, you could allocate the permissions in a single action - by allocating the permissions to the ‘Operators’ User Group, you set the 20 operators to have the relevant permissions. This is achieved without having to allocate the permissions to each individual user account (the 20 user accounts have their own permissions plus the permissions of their User Groups).

So, by creating a User Group and allocating permissions to it, you can make these permissions available to every user account that is associated with that User Group. By using User Groups you can save a considerable amount of time, especially if you need to allocate permissions to a large number of user accounts.

When you first install ClearSCADA, the only User Group that exists is the built-in ‘Everyone’ User Group (see Built-In User Groups). By default, the ‘Everyone’ User Group has limited access to database features - it only has the View, Browse and View Alarms permissions. As every user account is associated with the ‘Everyone’ User Group, this means that every user has access to the View, Browse and View Alarms permissions by default.

For information on creating Configured User Groups.

Built-In User Groups

ClearSCADA has a single built-in User Group named 'Everyone'. The 'Everyone' User Group is associated with every user account and it has restricted permissions by default (it only has the Read, Browse and View Alarms permissions).

The permissions that are allocated to the ‘Everyone’ User Group are also available to every user account on the system. For example, if you access the Security window for a point and set the Everyone User Group to have the Tune Limits permission, it means that every user will be able to tune the limits of the point.

The permissions that are allocated to the Everyone User Group are also made available to every user account automatically.

By default, the Everyone User Group is restricted to read-only permissions so that every user can view the database. To allow your system users greater access to items and features, you should create ‘configured’ User Groups and user accounts. You can then apply the required permissions to groups of users or individual user accounts as required.

For more information on User Groups, see Configured User Groups and see User Groups.

Configured User Groups

To reduce the amount of time and effort required to allocate permissions to user accounts, you can create configured User Groups. These are custom User Groups that can be associated with any of your Configured User Accounts.

When you have created a User Group, you can allocate permissions to the User Group instead of individual user accounts. When a user logs on via a user account that is a member of a User Group, that user is granted:

  • The permissions allocated to the ‘Everyone’ User Group
  • The permissions allocated to the User Group with which the user account is associated
  • The permissions allocated to the user account.

Each user account can be a member of up to 4 User Groups.

Further Information

Create a User Group

Associate a User Group with a User Account.


Security Guide - Understanding the Access Control List (ACL) (Welcome to the Security Guide)

Understanding the Access Control List (ACL)

Security in ClearSCADA is applied on a per database item basis. Each item in the database has its own security settings that define:

  • Which user accounts (and User Groups) can access the item
  • Which of the item's features are available to the user accounts and User Groups (this can be set individually for each user account and User Group).

The security settings that define which user accounts and User Groups can access an item, and which permissions they have are referred to as an Access Control List (ACL).

The ACL for each item is defined using the Security window (see Allocating Security Permissions). You can use it to define which user accounts and User Groups can access the item, and which permissions are allocated to them for the item.

The ACL for an item is shown at the top of the Security window.
Use the Permissions check boxes to change the access permissions for the ACL.
Use the Add button to add user accounts and User Groups to the ACL.

For example, you can use the Security window for a point to allocate Read, Browse, Control, Override/Release, Acknowledge Alarms, and View Alarms permissions to a User Group named 'Operators' and use the same window to allocate all permissions to a user account named 'System Manager'. When the 'System Manager' user logs on, they will have access to all features for the point, but users that are members of the 'Operators' User Group will only be able to view, control, override/release override, and view and acknowledge alarms for the point.

By default, there is a single ACL for the root Group (the system), and this provides full access to all users. By configuring ACLs for database items and Groups, you can restrict access to the database items and their features.

Any item that does not have its own ACL configured (for example, a new item) will automatically inherit the ACL of its parent Group. If you want to configure an item so that it has a different ACL to that of its parent, you have to clear the Inherit Permissions from Parent check box on the Security window. The Inherit Permissions from Parent check box is selected by default, as items have the same security settings as their parent Group or the System group when they are first created.

To configure an independent ACL for an item or Group, you have to clear the Inherit Permissions from Parent check box for that item or Group. Then you can use the Permissions check boxes to configure the ACL as required.

When configuring the security permissions for a Group, you can choose whether the ACL overrides the ACLs for the items in the Group by using the Remove Explicit Permissions on Descendants feature. When you select the Remove Explicit Permissions on Descendants check box, the ACLs of the items in the Group are removed, causing the items to inherit their security permissions from the Group.

In ViewX, the user account configuration can be used to further limit access to features. For example, you can stop a user account from having access to configuration features irrespective of the security settings for database items (see ViewX Specific Security Features).


Security Guide - ViewX Specific Security Features (Welcome to the Security Guide)

ViewX Specific Security Features

Individual user accounts can be denied access to certain features of ViewX. You can use ViewX specific settings on the User Form to:

  • Define the General ViewX Settings for a User
  • Define the Operational ViewX Settings for a User
  • Define the ViewX Configuration Settings for a User.

By using the User Form, you can restrict access to certain features in ViewX irrespective of the other security settings. For example, if you configure a user's user account to have the Configure Database option clear (disabled), that user will not have access to any Forms, even if the security settings for individual items provide the Configure permission. If a feature is disabled for a user via their User Form, they cannot access that feature in ViewX (the ViewX tab settings on the User Form have no effect on any of the other interfaces).


Security Guide - Security for Third Party Applications (Welcome to the Security Guide)

Security for Third Party Applications

ViewX and WebX are not the only ways to access your system—ClearSCADA can be accessed via Third Party applications, for example, OPC clients. To help secure your system, the ClearSCADA security settings are applied to every client. So, if a user is restricted to having read only permissions for a point in ClearSCADA, the user will also be limited to read only permissions if the user accesses the point via OPC or any other Third Party application.

Third Party applications that do not support client security are given the same access permissions that you have allocated to the Guest user account (see Guest User Account).

NOTE: User Groups and user accounts are only applicable if the Security setting is enabled. You can enable Security by using the Server Configuration Tool (see Define the Level of System Security).


Security Guide - Setting up System Security

Setting up System Security

You can use the Server Configuration Tool to define security settings that apply to your system, for example, you can use it to enable the Windows User Authentication feature. When you have defined the required security settings in the Server Configuration Tool, you can proceed to configure the user accounts and User Groups and apply the permissions that form the basis of ClearSCADA security.

To configure the server Security settings, we recommend that you follow these steps:

  1. You are going to need to use the Server Configuration Tool to define some of the security settings, for example, the Security Level and the settings for a Super user account. But the Server Configuration Tool has its own security settings to help prevent unauthorized access, so before you can use it, you need to be aware of Security for the Server Configuration Tool.
  2. Use the Server Configuration Tool to Define the Level of System Security
  3. Use the Server Configuration Tool to Define the Default Security Settings for New User Accounts
  4. Use the Server Configuration Tool to Configure the Super User Account
  5. Use the Server Configuration Tool to Define whether any Permissions are Restricted.
  6. Use the Server Configuration Tool to Define the Access Settings for WebX Clients.
  7. Use the Server Configuration Tool to enable or disable Windows Authentication, define the domain, and configure a cache password expiry (see Using Windows User Authentication with ClearSCADA).

When you have configured the Security settings at the server, you can proceed to set up security features in ViewX. For more information, see:

  • User Accounts
  • User Groups
  • Allocating Security Permissions.


Security Guide - Security for the Server Configuration Tool (Setting up System Security)

Security for the Server Configuration Tool

The Server Configuration Tool has its own security settings. To use the Server Configuration Tool, you need to access the tool via a user account that has the System Admin permission for the System Group (root Group of the system).

When you first access the Server Configuration Tool, you are logged on via the Guest user account automatically. However, if the Guest user account does not have the System Admin permission for the System Group, you will be prompted to log on when you access the Server Configuration Tool. You have to log on via a user account that has the System Admin permission for the System Group.


Security Guide - Define the Level of System Security (Setting up System Security)

Define the Level of System Security

You can use the Server Configuration Tool to define the level of system security. The level that you choose enforces several security settings, including minimum password length, password retries etc. You can also use the Security Level setting to disable the security feature completely if required.

When you enable the security feature by choosing any security level other than None, users access the system via user accounts and you can allocate permissions for each database item. You can also group the user accounts into User Groups.

If you disable the security feature by choosing a security level of None, there are no user accounts and every user can access the features for every item.

To define the security level for your system:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric
    ClearSCADA     option, then the Server Configuration option.
  2. Log on to the Server Configuration via a user account if prompted to do so (see Security for the Server Configuration Tool).
  3. Expand the required system and node.
  4. Expand the System Configuration branch.
  5. Select the Security branch.
  6. Use the Security Level combo box to choose the security level:
  • None—Disables the security feature.
  • Weak—Enables the security feature and enforces low level security measures. You can see the low level security settings in the grayed out fields on the Security section of the Server Configuration Tool.
  • Medium—Enables the security feature and enforces medium level security measures. You can see the medium level security settings in the grayed out fields on the Security section of the Server Configuration Tool.
  • Strong—Enables the security feature and enforces high level (strong) security measures. You can see the high level security settings in the grayed out fields on the Security section of the Server Configuration Tool.
  • Custom—Enables the security feature and allows you to specify your own security settings.

If you select the Custom option, you can proceed to:

  1. Define the Default Security Settings for New User Accounts
  2. Configure the Super User Account
  3. Define whether any Permissions are Restricted.

If you select the Weak, Medium, or Strong options, you can proceed to:

  1. Configure the Super User Account
  2. Define whether any Permissions are Restricted.
  7. Apply the changes by right-clicking on the system icon in the explorer section of the Server Configuration Tool and selecting the Apply Changes option.
  8. Confirm the changes by selecting the Yes button at the prompt.
  9. Repeat this process for each server in the system (as required).


Security Guide - Define the Default Security Settings for New User Accounts (Setting up System Security)

Define the Default Security Settings for New User Accounts

If you have set the Security Level to Custom, you can use the Server Configuration Tool to define the default security settings for new user accounts. This means you can specify how often users have to change their passwords, how much time can expire before an inactive user is logged off automatically etc.

The default settings that you specify on the Server Configuration Tool are put into effect automatically for every new user account. You can then use the User Form to adjust the settings for the individual user accounts as required (see Configuring the Guest and Web User Accounts).

To define the default security settings:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric ClearSCADA option, then the Server Configuration option.
  2. Log on to the Server Configuration via a user account if prompted to do so (see Security for the Server Configuration Tool).
  3. Expand the required system and node.
  4. Expand the System Configuration branch.
  5. Select the Security section.
  6. Define the default user account settings:
  • Minimum Username Length—Enter the least number of characters permitted in a user account name. We recommend a minimum password length of at least 6 characters for greater security.
  • Minimum Password Length—Enter the least number of characters permitted in a user account password. We recommend a minimum password length of at least 6 characters for greater security.

NOTE: The Minimum Password Length setting only applies to new accounts; it does not affect existing passwords.

  • Minimum Password Strength—Choose the strength for passwords. The strength determines what kinds of characters are required in a password. Choose from:
  • Weak—The password can contain any characters.
  • Medium—The password has to contain a combination of upper and lower case characters.
  • Strong—The password has to contain a combination of upper and lower case characters and digits.
  • Very Strong—The password has to contain a combination of upper and lower case characters, digits, and punctuation characters such as commas.

NOTE: The Minimum Password Strength setting only applies to new accounts; it does not affect existing passwords.

  • Allowed Failed Logons—Define the number of log on attempts that are permitted. If a user does not enter the correct Username and Password within the defined number of attempts, the system will disable the relevant user account. The user will be unable to log on via that account until a system administrator has re-enabled the user account by enabling the Security feature on the User Form (see Creating a User Account).
  • Password Dictionary Size—Enter the default number of passwords that are stored in the password dictionary for every user account.

When a user creates a password, it is stored in the password dictionary. When the Password Expiry time has elapsed, the account user needs to enter a new password. The new password cannot be the same as any of the passwords in the password dictionary.

For more information on the Password Dictionary, please refer to Creating a User Account.

  • Users Must Have Passwords—Select this check box to enforce passwords; every user account will require a password. If you clear this check box, passwords are not required and users will only need a user name in order to log on.
  • Users Can Change Passwords—Select this check box to allow users to change the passwords for their user accounts; clear it to stop users from being able to change their passwords.
  • Password is Pre-expired—Select this check box to set ClearSCADA to prompt each user to change their user account password the first time they log on; clear it to make each user log on using the password defined in their user account configuration (they are not prompted to change their password). For more information on the Pre-expired feature, see Define the Password for a User.
  • Passwords Expire After n Days—Enter the default number of days that can elapse before a new password needs to be created for each user account. By setting a password expiry time, you increase system security as passwords are regularly changed so there is less chance of an unauthorized user accessing the system.
  • Inactivity Logout—Enter the number of minutes that can elapse before an inactive user is logged off. This default setting is designed to help protect your system from unauthorized users that may attempt to gain access via unmanned workstations. If a user is inactive for the Inactivity Logout time, their user account will be logged off automatically. So, if a user leaves their workstation unmanned for the Inactivity Logout time, any users that attempt to use the workstation will need to log on.
  • Allow Per-User Configuration—Use this check box to define whether individual user accounts can have different settings to the default settings you are applying via the Server Configuration Tool. If you select this check box, each user account will have the Security tab available—the Security tab settings allow the user account to have security settings that are different to the default settings you are defining via the Server Configuration Tool. If you clear the check box, every user account will use the default settings (so will have the same number of characters per password, same failed log in attempt limits etc.)
  • Voicemail PIN Length—Enter the number of characters required for PIN numbers. PIN numbers for voicemail are required to have the defined number of characters. For example, if you enter 7, voicemail PIN numbers require exactly 7 digits.
  7. Apply the changes you have made by right-clicking on the system icon in the explorer section of the Server Configuration Tool, then selecting the Apply Changes option. When prompted to confirm the changes, select the Yes button to put the changes into effect.
  8. Repeat steps 3 to 7 inclusive for each system as required.

When you have set the default password and timeout settings, we suggest you proceed to:

  1. Configure the Super User Account
  2. Define whether any Permissions are Restricted.


Security Guide - Configure the Super User Account (Setting up System Security)

Configure the Super User Account

The Super user account is a special user account that has access to every feature and setting. We recommend that you configure a Super user account for your system, in case there are unexpected access problems caused by incorrect security configuration. By logging on via the Super user account, you can cancel or change any incorrect settings that may be preventing access to system features.

As the Super user account has access to all system features, you should keep its Username and Password secure at all times.

The Super user account is enabled during the installation process. If the Super user account is disabled on your system, you can enable it by running the installer program again. The installer program is included on the ClearSCADA CD/DVD/Download and is named Setup.exe

When the installer program runs, you will need to select the type of installation and choose which parts of the software you want to install. When you have done this, you will be prompted to enter the Super User details, including:

  • Username
  • Password
  • Confirm Password

We strongly recommend that you enable a Super User, but if required, you can disable the Super User.

ATTENTION: Schneider Electric is not responsible for the physical security of your system PCs. Physical security is the responsibility of the customer. You should take action to protect your system PCs from unauthorized access, as any user with sufficient permissions to run the ClearSCADA installer will be able to enable the Super User account. By using the Super User account, they will have full access to your system.

You can use the Server Configuration Tool to change the settings for the Super user account. To re-configure the Super user account:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric
    ClearSCADA     option, then the Server Configuration option.
  2. Log on to the Server Configuration via a user account if prompted to do so (see Security for the Server Configuration Tool).
  3. Expand the required system and node.
  4. Expand the System Configuration branch.
  5. Select the Security section.
  6. Select the Change button in the Super-User section to display the Change Super-User window.
  7. Use the Change Super-User window to alter the Super User settings:
  • Current Username—Enter the Username for the Super User. This is the Username that is already in place (either the Username that was entered during the installation process or the Username that was previously defined for the Super User via the Change Super-User window).
  • Current Password—Enter the password for the Super User. This is the password that is already in place (either the password that was entered during the installation process or the password that was previously defined for the Super User via the Change Super-User window).
  • New Username—Enter the new Username for the Super User. This will replace the current Username.
  • New Password—Enter the new password for the Super User. This will replace the current password.
  • Confirm Password—Re-enter the new password to confirm it as the new password. You have to enter the same password as you entered in the New Password field.
  • Disable Super User Account—Use this check box to disable the Super User feature if required. We recommend that you enable a Super user account. Select this check box to disable the Super User feature or leave it clear to enable the Super User feature.
  8. Select the OK button to confirm your entries and close the Change Super User window.
  9. Apply the changes you have made by right-clicking on the system icon in the explorer section of the Server Configuration Tool, then selecting the Apply Changes option.


Security Guide - Define whether any Permissions are Restricted (Setting up System Security)

Define whether any Permissions are Restricted

You can use the Permission Restrictions settings on the Server Configuration Tool to control access on a system-wide basis. For example, you can remove the Acknowledge Alarms permission for every client.

The Permission Restrictions settings are grouped as follows:

  • Server Denied Permissions—The permissions in this group apply to every client that connects to the server (ViewX clients, WebX clients, the Automation interface etc.).
  • ViewX User Denied Permissions—The permissions in this group only apply to ViewX clients. Any changes you make will not affect WebX clients, the Automation interface etc.
  • WebX User Denied Permissions—The permissions in this group only apply to WebX clients. Any changes you make will not affect ViewX clients, the Automation interface etc.
  • Standard Pick Menu Denied Permissions—The permissions in this group apply to the options in the standard pick action menu for database items. They apply to the standard pick action menu on ViewX and WebX. However, the permissions only apply to the standard pick menu options; they have no effect on custom pick action menu options or server methods called from scripts.

By setting the Permission Restrictions, you can make certain features unavailable to all users, or unavailable to users of certain types of interface. You can also restrict access to standard pick action menu options on all interfaces. For example, if you want all WebX users to be unable to acknowledge alarms, you can use the Permission Restrictions settings to remove the Acknowledge Alarms permission for all WebX users, irrespective of the permissions allocated to their individual user accounts.

The main advantages of using the Permission Restrictions settings are that they allow you to:

  • Deny permissions to all users or to all ViewX or WebX users without having to alter the configuration of their individual user accounts.
  • Specify different types of access according to the type of interface being used. In ViewX, the configuration of a user's user account defines which features are available to that user in both ViewX and WebX. By using the Permission Restriction settings, you can allow a user to have certain permissions when using ViewX, but deny access to certain features when using WebX (every user will be denied access when using WebX).
  • Deny access to the various standard pick action menu options for each of the client interfaces.

If you do not configure the Permission Restrictions settings, WebX users will have the same permissions when using WebX as they have when using ViewX (they will log on to WebX via their ViewX user account).

NOTE: The Permission Restriction settings override other security settings. So, if you have enabled the Configure permission in a ViewX user account, but you have also selected the Configure check box for ViewX in the Permission Restrictions, that user will be unable to configure database items. Users can only access features for which their user accounts provide sufficient permissions and that are not restricted via the Permission Restriction settings.

To configure the Permission Restrictions settings:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric ClearSCADA option, then the Server Configuration option.
  2. Log on to the Server Configuration via a user account if prompted to do so (see Security for the Server Configuration Tool).
  3. Expand the required system and node.
  4. Expand the System Configuration branch.
  5. Select Permission Restrictions
  6. In the Server Denied Permissions section, select the check boxes for those permissions that are to be denied on each type of client that accesses the system, including ViewX and WebX clients. Be careful when denying permissions as you may accidentally prevent other users from being able to work with your ClearSCADA system.
  7. In the ViewX User Denied Permissions section, select the check boxes for those permissions that are to be denied on ViewX clients. For example, if you select the Exclusive Control permission, every ViewX user will be unable to access the Exclusive Control features, even if their user accounts allow them to use Exclusive Control features.
  8. In the WebX User Denied Permissions section, select the check boxes for those permissions that are to be denied on WebX clients. For example, if you select the Control permission, WebX users will be unable to issue controls from WebX even if their user accounts allow them to issue controls.
  9. In the Standard Pick Menu Denied Permissions section, select the check boxes for those permissions that are to be denied for standard pick action menu options. The permissions you select will affect the standard pick action menu on ViewX and WebX. For example, if you select the Acknowledge Alarms permission, the Acknowledge Alarms action will be unavailable via the standard pick action menu on both ViewX and WebX.
  10. Right-click on the system icon in the Server Configuration Tool and select the Apply Changes option from the context sensitive menu.
  11. Re-start the server.
  12. Repeat this procedure for each system as required.

NOTE: You cannot restrict the Read, Browse, Security, or System Admin permissions (as incorrect use of these permissions could result in users being unable to access key features or view the database). However, you can assign or deny the Read, Browse, Security and System Admin permissions on a per item basis via each item’s Security window.

Further Information

For information on the various permissions: see Permissions for Database Items.


Security Guide - Using Windows User Authentication with ClearSCADA (Setting up System Security)

Using Windows User Authentication with ClearSCADA

By using the Windows User Authentication feature, you can associate ClearSCADA user accounts with Microsoft Windows user accounts. When enabled and set up correctly, Windows User Authentication allows you to:

  • Disable a ClearSCADA user account by disabling the corresponding Windows user account
  • Manage the password of a ClearSCADA user account by managing the corresponding Windows user account.

The main benefit of using Windows User Authentication is that it can reduce the amount of time and effort it takes for IT staff to restrict

. access via ClearSCADA user accounts. It also means they can manage password related settings through Windows rather than ClearSCADA. However, using Windows Authentication can cause minor delays (milliseconds) with connections and ClearSCADA user account response times.

The Windows User Authentication feature requires that the Windows user accounts have the same names as the ClearSCADA user accounts. For example, for a ClearSCADA user account named 'P Edwards' to use Windows Authentication, there needs to be a corresponding Windows user profile called 'P Edwards' (there are also configuration settings that need to be put in place in ClearSCADA, which we will explain later in this section).

So if you are setting up ClearSCADA security for the first time, it makes sense to create ClearSCADA users that match your Windows users. If you already have a system in place and want to start using Windows User Authentication, you will need to either rename the Windows user profiles so that they match the names of the corresponding ClearSCADA user accounts, or rename the ClearSCADA user accounts to match the names of the corresponding Windows user profiles.

By default, Windows User Authentication is disabled.

If you wish to enable Windows User Authentication, you will need to use the Server Configuration Tool to:

  1. Enable Windows User Authentication and Define the Domain Name
  2. Define the Cache Password Expiry for Windows User Authentication
  3. Configure ClearSCADA User Accounts to use Windows User Authentication.

If you have Windows User Authentication enabled and want to disable it, you will need to use the Server Configuration Tool to:

  • Disable Windows User Authentication.

NOTE: The Windows User Authentication feature can only authenticate user accounts in trusted domains.


Security Guide - Enable Windows User Authentication and Define the Domain Name (Setting up System Security)

Enable Windows User Authentication and Define the Domain Name

If you enable the Windows User Authentication feature, the user accounts in ClearSCADA can be associated with corresponding user profiles in Microsoft Windows. This association means that you can disable ClearSCADA users by disabling Windows users. You can also use Windows to manage the passwords of ClearSCADA users.

When you have enabled the Windows User Authentication feature, you also need to define the Windows Domain Name. ClearSCADA needs the Windows Domain Name so that it can identify and communicate with the Windows Server that contains the Windows User Profiles, passwords etc.

To enable Windows Authentication and define the Windows Domain Name:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric
    ClearSCADA     option, then the Server Configuration option.
  2. Log on to the Server Configuration via a ClearSCADA user account (if prompted to do so). The user account has to have suitable permissions for accessing the Server Configuration Tool (see Security for the Server Configuration Tool).
  3. Expand the System Configuration branch
  4. Select Security
  5. In the Windows User Authentication section, select the Enabled check box.
  6. In the Windows Domain Name field, enter the name of the Windows Server Domain that stores your Windows User Profiles and passwords. This is the domain to which ClearSCADA will connect when verifying the log on details against the Windows User Profiles. For this reason, the ClearSCADA server needs a valid network connection to the domain.
  7. Right-click on the system icon in the Server Configuration Tool and select the Apply Changes option from the context sensitive menu.

You have now enabled the Windows User Authentication feature. If a user attempts to log on to ClearSCADA via a user account that is configured to use Windows User Authentication, that account will be verified against the corresponding Windows User Profile. The user will only be logged on if the ClearSCADA user account and the password they have entered matches the name and password of a Windows User Profile. However, if a user attempts to log on via a user account that is not configured to use Windows User Authentication, they only need to enter a user name and password that is valid in ClearSCADA.

ClearSCADA uses the defined Windows Domain Name to communicate with the Windows Server that contains the Windows User Profiles.

The Windows User Authentication process is now ready to use. It will apply to every ClearSCADA user account that is configured to use Windows User Authentication and will use the default Cache Password Expiry setting. You can change the Cache Password Expiry setting as required (see Define the Cache Password Expiry for Windows User Authentication).

NOTE: The Windows User Authentication feature can only authenticate user accounts in trusted domains.

Further Information

  • Define the Cache Password Expiry for Windows User Authentication
  • Configure ClearSCADA User Accounts to use Windows User Authentication
  • Disable Windows User Authentication.


Security Guide - Define the Cache Password Expiry for Windows User Authentication (Setting up System Security)

Define the Cache Password Expiry for Windows User Authentication

The Cache Password Expiry setting is designed to help you avoid slight delays when logging on. The delays may occur when using Windows User Authentication as the log on details in ClearSCADA have to be compared to the corresponding Windows User Profile, which requires ClearSCADA to communicate with the Windows Server. Depending on the speed of your network connections and the PCs being used, this can cause a short delay as ClearSCADA has to negotiate encryption and the Windows Server has to check the user details and password match those of the corresponding User Profile in Windows. Typically, such delays are a matter of milliseconds.

With Windows User Authentication, every connection from ClearSCADA to the Windows Server has to be verified. Communicating with the Windows Server for every connection can introduce unnecessary delays, so to avoid these delays, ClearSCADA uses a cache.

ClearSCADA uses the password cache like this:

  1. User logs on to ClearSCADA
  2. ClearSCADA communicates with the Windows Server to check that the user name and password match those in the corresponding Windows User Profile.
  3. If the user name and password match, the Windows Server verifies the log on and the user is granted access to ClearSCADA.
  4. ClearSCADA stores the verified user details locally in its password cache. The details are stored for a defined amount of time (the Cache Password Expiry time).
  5. It is still within the Cache Password Expiry time. The ClearSCADA user works with the system. When they display Mimics, Lists, etc., new connections are made. As the connections are made within the Cache Password Expiry time, the user name and password for the connections is checked against the details in the cache (which have already been verified). This means ClearSCADA can avoid unnecessary delays as it does not have to communicate with the Windows Server.

NOTE: Any changes that are made to a user account are only applied within ClearSCADA after the Cache Password Expiry time has elapsed.

  6. The Cache Password Expiry time is reached. ClearSCADA clears the cached password for the logged on user (the cache will still contain the passwords of other users that logged on at a later time).
  7. For the next connection that is made, ClearSCADA repeats this process starting from Step 2. This continues until the user logs off.

For added security, the verified user details and password are only stored in the cache for a set amount of time, defined by the Cache Password Expiry setting. This is because if ClearSCADA only used the cached details until the user logged off, any changes to the user account would not be applied until the user logged off. For example, if an IT administrator wanted to disable a user account through Windows, and that user was already logged on, the account would not be disabled until the user logged off. The Cache Password Expiry feature means ClearSCADA can avoids this situation by clearing the cache at regular intervals.

By default, the Cache Password Expiry is 150 seconds. You may need to increase this amount if you are experiencing small delays when logging on or displaying Mimics, Lists, etc. However, if you do increase the Cache Password Expiry time, you need to be aware that any changes to user accounts will not take effect until after the expiry time has elapsed.

If the user account changes you make in Windows are taking too long to be applied to the corresponding ClearSCADA user accounts, you may need to reduce the Cache Password Expiry time.

To change the Cache Password Expiry time:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric
    ClearSCADA     option, then the Server Configuration option.
  2. Log on to the Server Configuration via a ClearSCADA user account (if prompted to do so). The user account has to have suitable permissions for accessing the Server Configuration Tool (see Security for the Server Configuration Tool).
  3. Expand the System Configuration branch
  4. Select Security
  5. In the Windows User Authentication section, select the Enabled check box (if it is not already selected). If the check box is clear, the Windows User Authentication feature is disabled and you will not be able to define the Cache Password Expiry time.
  6. In the Cache Password Expiry field, enter the required number of seconds. The default amount is 150.
  7. Right-click on the system icon in the Server Configuration Tool and select the Apply Changes option from the context sensitive menu.

When you have enabled the Windows User Authentication feature, defined the Windows Domain and Cache Password Expiry settings, the Windows User Authentication process is ready to use. It is applied to every ClearSCADA user account that is configured to use Windows User Authentication.

NOTE: The Windows User Authentication feature can only authenticate user accounts in trusted domains.

Further Information

Enable Windows User Authentication and Define the Domain Name

Configure ClearSCADA User Accounts to use Windows User Authentication

Disable Windows User Authentication.


Security Guide - Disable Windows User Authentication (Setting up System Security)

Disable Windows User Authentication

You can disable Windows User Authentication on your system at any time by clearing the Enabled check box in the Windows User Authentication settings. When you disable Windows User Authentication, every aspect of ClearSCADA user account management has to be undertaken within ClearSCADA.

To disable Windows User Authentication:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric
    ClearSCADA     option, then the Server Configuration option.
  2. Log on to the Server Configuration via a ClearSCADA user account (if prompted to do so). The user account has to have suitable permissions for accessing the Server Configuration Tool (see Security for the Server Configuration Tool).
  3. Expand the System Configuration branch
  4. Select Security
  5. In the Windows User Authentication section, clear the Enabled check box.
  6. Right-click on the system icon in the Server Configuration Tool and select the Apply Changes option from the context sensitive menu.

Further Information

Enable Windows User Authentication and Define the Domain Name.


Security Guide - Configure ClearSCADA User Accounts to use Windows User Authentication (Setting up System Security)

Configure ClearSCADA User Accounts to use Windows User Authentication

If you want to be able to manage ClearSCADA user accounts in Windows, you need to configure the ClearSCADA user accounts to use the Authenticate via Windows feature. For more information, see Define whether a User is Associated with a Windows User Profile.


Security Guide - Define the Access Settings for WebX Clients (Setting up System Security)

Define the Access Settings for WebX Clients

You can access ClearSCADA via an Intranet or Internet by using WebX clients. Each WebX client connects to a ClearSCADA server via non-secure or secure web ports, depending on how you configure your ClearSCADA server.

Before you configure a ClearSCADA server to provide access to WebX clients, we recommend that you learn about the security implications of using WebX. The following section describes the security implications of using non secure and secure ports for web access:

  • Using Secure Web Ports with a Trusted SSL Certificate

When you are familiar with the security implications, you can proceed to:

  • Define the Ports Settings for WebX Clients
  • Define the SSL Settings for WebX Clients.

For information on the other WebX settings, see WebX Settings in the ClearSCADA Guide to Server Administration.


Security Guide - Using Secure Web Ports with a Trusted SSL Certificate (Setting up System Security)

Using Secure Web Ports with a Trusted SSL Certificate

Your ClearSCADA system can be accessed via the Internet or a company Intranet. To provide this functionality, ClearSCADA uses web ports.

There are two sets of web ports:

  • Non-secure web ports—These ports allow a WebX client to access ClearSCADA via the standard http protocol.

The standard http protocol is not encrypted. The communications traffic between the client and server can be seen by anybody who has physical access to the network and appropriate network monitoring tools.

  • Secure web ports—These ports allow a WebX client to access ClearSCADA via the secure https protocol.

The standard https protocol is encrypted. If somebody is monitoring the network, they will be unable to see the content of the traffic between the client and server.

When a web browser accesses a web server via the secure sockets protocol (https), the web browser will request the server's SSL certificate. The web browser uses the information in the certificate to:

  • Check that the web browser is communicating with the correct web server
  • Establish a secure encrypted connection to that web server.

If an administrative user has not already configured an SSL certificate in the web server, ClearSCADA will automatically create a top-level non-trusted SSL certificate for that web server.

If the default, server generated non-trusted SSL certificate is used, the WebX client will display warning messages when users access the system. The exact warning message depends on the browsers, but typically might be “There is a problem with this web site’s security certificate”. Some users may find these warning messages distracting, although they do not affect their ability to interact with your ClearSCADA system.

If a trusted SSL certificate is used, the WebX client is able to verify that it is connecting to the expected server, and so there are no warning messages shown when a WebX client accesses the secure web server ports.

We recommend that you purchase trusted SSL certificates for your web servers so that users do not receive distracting warning messages. We also recommend you review your security options and establish appropriate security for your web server.

Recommended security:

  • Purchase and install a web server certificate
  • Turn off "Allow logon on HTTP port"

Maximum security:

  • Purchase and install a web server certificate
  • Turn off "Allow logon on HTTP port"
  • Disable HTTP port(s).

Not recommended:

  • Use the default server generated non-trusted web server certificate
  • Turn on "Allow logon on HTTP port"

To configure the web port settings, you need to use the Server Configuration Tool’s WebX settings.

To enable, disable or specify non-secure and secure ports for WebX: see Define the Ports Settings for WebX Clients.

To configure the SSL certificate settings for WebX: see Define the SSL Settings for WebX Clients.

For information on the other WebX settings, see WebX Settings in the ClearSCADA Guide to Server Administration.


Security Guide - Define the Ports Settings for WebX Clients (Setting up System Security)

Define the Ports Settings for WebX Clients

You can use the WebX section of the Server Configuration Tool to define the port settings for the WebX server. The settings allow you to enable or disable the secure port and non-secure port and also define whether WebX users can log on and shut down the system.

To define the ports settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select WebX to display the WebX section.
  4. Define whether the non-secure (http) web server port is available for use by using the Non-secure settings in the Ports section:

Either:

  1. Select the Enabled check box for the Non-Secure port to enable the WebX server. This will provide unsecure access—the data in the traffic between the ClearSCADA server and the WebX client is not encrypted and may be susceptible to unauthorized access.
  2. Enter the number of the port used for the XML WebX server in the XML field. The default setting is 80, but this is often used by other web servers (for example, Microsoft IIS) and so you may need to change it. You should change it to an available port (typically, the high port numbers are available).
  3. Enter the number of the port used for the HTML WebX server in the HTML field. The default setting is 81. If you need to change the port number (due to it already being in use), you should change it to an available port (typically, the high port numbers are available).
  4. Use the Allow Logon check box to define whether users can log on to the ClearSCADA system via a WebX client that uses an unsecure connection. Select the Allow Logon check box to allow logging on via an unsecure connection, or clear it to restrict logging on to WebX clients with secure connections.

Or:

  • Clear the Enabled check box for the Non-Secure to disable the WebX server.

NOTE: For maximum security, we recommend that you disable the Non-Secure ports and also disable (clear) the Allow Logon check box (see Using Secure Web Ports with a Trusted SSL Certificate).

  5. Define whether the secure (https) WebX server port is available for use by using the Secure settings in the Ports section:

Either:

  1. Select the Enabled check box for the Secure port to enable the WebX server. This will provide secure access—the data in the traffic between the ClearSCADA server and the WebX clients is encrypted and is not susceptible to unauthorized access.

To provide secure access, ClearSCADA generates a top-level non-trusted SSL certificate. This certificate may cause a warning message to be displayed, which can be distracting to some users. You can stop the warning message from appearing by using a trusted SSL certificate (see Define the SSL Settings for WebX Clients).

  2. Enter the number of the port used for the XML WebX server in the XML field. The default setting is 445, but this is often used by other web servers and so you may need to change it. You should change it to an available port (typically, the high port numbers are available).
  3. Enter the number of the port used for the HTML WebX server in the HTML field. The default setting is 444. If you need to change the port number (due to it already being in use), you should change it to an available port (typically, the high port numbers are available).

There is no standard alternative port address—we recommend that you refer to the Internet Engineering Task Force web site at http://www.IETF.org/rfc and search for RFC 1700 for details about which port numbers are available.

Or:

  • Clear the Enabled check box for the Secure to disable the WebX server.

NOTE: If you disable both the Non-Secure and Secure ports, the WebX server will be unavailable to WebX clients.

  6. Use the Allow shutdown check box to define whether users can shutdown the ClearSCADA server via the WebX interface:
  • Select the Allow shutdown check box to allow users to shutdown the ClearSCADA server via WebX (by selecting the Shutdown button on the Diagnostics page).
  • Clear the Allow shutdown check box to stop users from being able to shut down the ClearSCADA server via WebX (the Shutdown button on the Diagnostics page will be unavailable).

When you have defined the Ports settings, you can proceed with the configuration of the other WebX settings or you can right-click on the server icon and select the Apply Changes option to implement the changes.

Further Information

Setting up WebX: see WebX Settings in the ClearSCADA Guide to Server Administration.


Security Guide - Define the SSL Settings for WebX Clients (Setting up System Security)

Define the SSL Settings for WebX Clients

You can use the Server Configuration Tool to configure the Secure Sockets Layer (SSL) settings. SSL sets the client-server communications to be encrypted and so is recommended for secure communications, particularly on systems that use Internet connections.

Secure Socket Layers require a public key certificate file and a private key file. The certificate is used to detect that the connection is an authorized and secure connection, whereas the private key file is used for encrypting and decrypting data between the WebX server and the WebX clients.

ClearSCADA generates a public key certificate and a private key file automatically. However, although the certificate is secure, it is not a verified file. This means that there will be warnings when a browser connects to the secure WebX server. To avoid the connection warnings etc., that are associated with unverified certificates, you should generate a certificate signing request and send it to a Public Key Provider such as Verisign. The Public Key Provider will then issue you with a verified public key certificate generated by ClearSCADA.

To define the SSL settings:

  1. Access the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Expand the System Configuration branch of the tree-structure.
  3. Select WebX to display the WebX section.
  4. In the SSL section, select the Generate button to display the Certificate Signing Request window.
  5. Enter the requested information:
  • Common Name—The node name of the WebX server.
  • Organization—The name of the business you represent or work for.
  • Organization Unit—The department in which you work.
  • City/Locality—The name of the city or town where the organization is based.
  • State/Province—The area of the country where the organization is based.
  • Country/Region—The country or region where the organization is based. Select the country from the combo-list.
  6. Select the OK button to confirm your entries and display a save as window.
  7. Use the Save As window to define the name and location of the certificate request file that is generated.
  8. Select the OK button to confirm the name and location and to generate and save the request file.
  9. Send the request file to a Public Key Provider such as Verisign. You can e-mail the file or may be able to send it by some other means, for example, upload it via the Internet.

When you have sent the file, the Public Key Provider will respond by sending you a verified certificate file.

  10. Select the browse button next to the Certificate field.
    A browse window is displayed.
  11. Use the browse window to locate and select the certificate file that you have received from the Public Key Provider, then select OK.
  12. Use the Format combo box that is adjacent to the Certificate field to define the whether the Certificate file is:
  • DER—Distinguished Encoding Rules format.
  • PEM—Privacy Enhanced Mail format.

The format of the Certificate file is defined when it is generated.

  13. Check that the Private Key field shows a valid private key file (such as the one included in ClearSCADA) and that the Format matches the format of the actual file. The file included with ClearSCADA should have the Format set to PEM (Private Enhanced Mail).

Now that you have defined the SSL settings, you can proceed with the configuration of the other WebX settings or you can right-click on the server icon and select the Apply Changes option to implement the changes.

Further Information

Using Secure Web Ports with a Trusted SSL Certificate.

Setting up WebX: see WebX Settings in the ClearSCADA Guide to Server Administration.


Security Guide - User Accounts

User Accounts

User accounts are a key part of the ClearSCADA system security mechanism. They allow individual users to be allocated a configurable identity that can provide/restrict access to system features.

In the following sections, we explain the concept of user accounts and describe how to set up user accounts on your system:

  • Overview of User Account Security
  • Guest User Account
  • Web User Account
  • User Accounts for System Users
  • User Accounts for Third Party Applications
  • Permissions for Working with User Accounts and User Groups
  • Creating a User Account
  • User Account Permissions
  • Configuring the Guest and Web User Accounts.

You can also modify, move, rename or delete a User in the same way as you can alter or remove any other database item. For more information, see Organizing and Configuring Your Database in the ClearSCADA Guide to Core Configuration.

NOTE: You can create, modify, copy, move, rename, import or delete a user account. To do this, you have to be logged on via a user account that has the Configure and Security permission for the user account or the Group that contains the user account (see Permissions for Working with User Accounts and User Groups).


Security Guide - Overview of User Account Security (User Accounts)

Overview of User Account Security

ClearSCADA has 2 security mechanisms: user accounts and database item permissions. Typically, each system user is allocated a user account. The features that are available to the user depend on the configuration of their user account and the security settings of each item in the database.

To access a feature, a user has to have been allocated suitable permissions via the database item's security settings.

When a user accesses ClearSCADA, they either log on manually or are logged on automatically using one of the following:

  • A ‘configured’ user account—A user account that has been created manually and configured to have a username and password.
  • The built-in Guest user account—The default account that is used when users access ClearSCADA via ViewX, OPC, ODBC and Automation without logging on.
  • The built-in Web user account—The default account that is used when users access ClearSCADA via a web interface (such as WebX) without logging on.

‘Configured’ user accounts are regarded as a more secure way of accessing your system as they require manual entry of a user name and password (see User Accounts for System Users).

The items and features that a user can access are determined by:

  • The permissions allocated to the ‘Everyone’ User Group
  • The permissions allocated to any User Group of which the user account is a member
  • The permissions allocated to the individual user account
  • The configuration of the individual user account.

For more information, see Understanding User Accounts.

NOTE: User Groups and user accounts are only applicable if Security is enabled. You can enable Security by using the Server Configuration Tool (see Define the Level of System Security).

Further Information

User Accounts for System Users

User Accounts for Third Party Applications

Permissions for Working with User Accounts and User Groups

Creating a User Account

User Account Permissions

Configuring the Guest and Web User Accounts

Logging On and Off via a User Account

Changing the Password for a User Account.


Security Guide - Guest User Account (User Accounts)

Guest User Account

The Guest user account is a built-in user account. It is used whenever a user accesses ClearSCADA via ViewX without logging on. By default, the Guest user has full access permissions. This is necessary as you will need full access permissions in order to create your own User Groups and user accounts. You can then reduce the permissions of the Guest user at a later stage.

In some situations, the Guest user may need specific permissions. For example, some Third Party applications that do not support client security use the Guest user to access ClearSCADA. They require the Guest user account to have at least the Read permission so that they can access system data.

For more information on how the Guest user account is used, see Built-In User Accounts.

For information on configuring the Guest user account, see Configuring the Guest and Web User Accounts.

For information on allocating security permissions to the Guest user account, see Allocating Security Permissions.


Security Guide - Web User Account (User Accounts)

Web User Account

The Web user account is a built-in user account. It is used whenever a user accesses ClearSCADA via a web interface such as WebX without logging on. By default, the Web user has read-only permissions.

In some situations, the Web user may need specific permissions. For example, you may decide that web users need to be able to interact with alarms. To make this possible, you will need to configure the Web user account.

For more information on how the Web user account is used, see Built-In User Accounts.

For information on configuring the Web user account, see Configuring the Guest and Web User Accounts.

For information on allocating security permissions to the Web user account, see Allocating Security Permissions.


Security Guide - Super User Account (User Accounts)

Super User Account

During installation, you can choose to enable or disable the Super user account. The Super user account is a special user account that has access to all ClearSCADA features. As the Super user account has no restrictions, you should only allow authorized personnel access to the Super User’s username and password.

The Super user account is designed to be used when the security features have been configured incorrectly. For example, if your system is incorrectly configured to stop users from having access to the security features, there is no way any user can log on and make security changes, even the user that incorrectly configured the security settings. By using the Super user account, you can avoid this situation—the Super user account can access all features and so can be used to correct poorly configured security settings.

For information on configuring the Super user account, see Configure the Super User Account.


Security Guide - User Accounts for System Users (User Accounts)

User Accounts for System Users

To restrict access to the system, you can create user accounts and allocate them to the system users. Each user account has its own user name and password which are used to restrict access to the system—only users that have the correct user name and password can log on via a user account. Users that are unable to log on to the system via a user account can only use the Guest user account (see Guest User Account).

ClearSCADA user accounts can also be associated with Windows User Profiles. This allows network administrators to manage ClearSCADA user accounts by making changes to the corresponding Windows User Profiles. For example, a network administrator can disable a Windows User Profile and this will disable the corresponding ClearSCADA user account. For information on associating Windows User Profiles with ClearSCADA user accounts, see Using Windows User Authentication with ClearSCADA.

Every database item has its own security settings that allow you to define access permissions for each of the user accounts. A user can only access an item's features if the item's security settings grant the relevant permissions to their user account. For example, if a user account is set up to only have the Read and Browse permissions, the user that logs on via that account will only be able to look at information in the system; they will not have the permissions to operate or configure any of the system items.

In ViewX, additional restrictions can be enforced by configuring the individual user accounts. By configuring a user account, you can deny access to specific ViewX features irrespective of the security settings for individual items. For example, a user account can be configured to deny access to the configuration features in ViewX—the user of the account will be unable to access any configuration features, even if their user account has been allocated the Configure permission for an item.

In ViewX, you can only access a feature for an item if you are logged on via a user account that provides access to the feature and has the relevant permission for the required item.

For information on configuring a user account, see Creating a User Account.

For information on allocating security permissions to a user account, see Allocating Security Permissions.

NOTE: ClearSCADA user accounts can also be associated with Windows User Profiles see Configure ClearSCADA User Accounts to use Windows User Authentication.


Security Guide - User Accounts for Third Party Applications (User Accounts)

User Accounts for Third Party Applications

Third Party applications such as OPC client applications also access the ClearSCADA system via a user account. The type of access that is permitted for Third Party applications is dependent on whether the Third Party application supports client security:

  • If the Third Party application supports client security, the Third Party application will use a standard ClearSCADA user account. The user of the Third Party application will be prompted to log on via a ClearSCADA user account when the Third Party application accesses the ClearSCADA database. The security settings of the ClearSCADA user account apply regardless of the type of data access—when a user logs on via a Third Party application, the same user permissions are applied as when the user logs on via ViewX or WebX.
  • If the Third Party application does not support client security, it will use the Guest user account when it accesses the ClearSCADA system. Typically, the Guest user is set up to provide read only access. This is usually suitable for Third Party applications as they are often used for retrieving data for reports etc. The read only access also means that unauthorized users are unable to access control and configuration features in ClearSCADA.

For information on setting up the Guest user account, see Configuring the Guest and Web User Accounts.

For information on setting up user accounts that can be used by Third Party applications that support client security, see Creating a User Account.


Security Guide - Permissions for Working with User Accounts and User Groups (User Accounts)

Permissions for Working with User Accounts and User Groups

Access to system features and database items is controlled via user accounts and User Groups. When you are working with user accounts and User Groups, you need to log on via a user account that has Security and Configure permissions for the User, User Group, or target Group depending on what you are trying to achieve:

  • Create a User or User Group—you have to log on via a user account that has the Configure and Security permissions for the target Group (the Group that will contain the new User or User Group).
  • Copy a User or User Group—you have to log on via a user account that has the Configure and Security permissions for the target Group (the Group that will contain the copy of the User or User Group).
  • Import a User or User Group—you have to log on via a user account that has the Configure and Security permissions for the target Group (the Group that will contain the imported User or User Group).
  • Move a User or User Group—you have to log on via a user account that has the Configure and Security permissions for the User or User Group item and the target Group (the Group that will contain the moved User or User Group).
  • Delete a User or User Group—you have to log on via a user account that has the Configure and Security permissions for the User or User Group item.
  • Modify a User or User Group—you have to log on via a user account that has the Configure and Security permissions for the User or User Group item.
  • Rename a User or User Group—you have to log on via a user account that has the Configure and Security permissions for the User or User Group item.


Security Guide - Creating a User Account (User Accounts)

Creating a User Account

To restrict access to the system, you can create user accounts and allocate them to the system users. Each user account can then be configured to provide or restrict access to various features. user accounts are used when accessing ClearSCADA via a ViewX, WebX, or Third Party application that supports client security.

To create a user account, you have to be logged on via a user account that has the Configure and Security permissions for the system or Group. In ViewX, you will also need the Configure Database setting enabled on your user account (set via the User Form for the user account).

NOTE: If the Guest user account has the Configure and Security permissions and Configure Database setting enabled, you do not need to log on. When you first install ClearSCADA, the Guest user account has all permissions. For information on configuring the Guest user account, see Configuring the Guest and Web User Accounts

To create a new user account:

  1. Create a User Database Item.

NOTE: New user accounts use the settings for the Guest account as their default settings. For information on configuring the Guest user account, see Configuring the Guest and Web User Accounts.

  2. Display the User Form
  3. Use the Identification tab to define the Help View Mimic for the user account (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  4. Use the User Methods tab to associate the user account with up to 4 custom actions (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  5. Use the General tab to:
  • Define the Severity of Events Associated with a User
  • Define the Area of Interest for Events Logged for the User's Actions
  • Define whether a User can Access the System via ViewX, WebX or Phone
  • Define whether a User is Associated with a Windows User Profile
  • Define the Password for a User
  • Define the Homepage Settings for a User
  • Enable or Disable the Confirm Actions Feature for a User
  • Define the Time Range for a User's Event List
  • Define whether the User can Respond to Group Alarms Simultaneously
  • Define whether a User can Only Work with Items under their Exclusive Control
  • Associate a User with a User Group
  • Define the Regional Settings for a User
  • Define the Areas of Interest for a User
  6. Use the Security tab to Define the Security Settings for a User
  7. Use the ViewX tab to Define the General ViewX Settings for a User:
  • Define the Operational ViewX Settings for a User
  • Define the ViewX Configuration Settings for a User
  • Define the Alarm Banner and Alarm List Settings for a User
  • Define the Default Alarm Filter Settings for a User
  • Define Which Explorer Bars are Available to a User
  • Define Which Toolbars are Available to a User
  8. Use the Contact Information tab to Define the E-Mail, Pager, and Voicemail Contact Settings for a User
  9. Save the Form.

When you have configured a user account, you will need to define its access permissions (see Allocating Security Permissions). After setting the permissions, you can allocate the user account to a system user—you will need to inform the user of their username, password, ID, and PIN.


Security Guide - Create a User Database Item (User Accounts)

Create a User Database Item

Each user account is represented in the database by a User database item that stores the specific settings for the account. The configuration of a user account defines settings such as e-mail contact addresses, interface features, homepage settings etc.

Before you can define the configuration settings for a user account, you need to create a User database item.

To create a User database item:

  1. In the Database Bar, right-click on the Group or system that is to contain the user account.
    A context sensitive menu is displayed.
  2. Select the New option, then the Other option, then the User option.
    A new user account is created. It is selected automatically, ready for you to define its name.
  3. Enter a suitable name for the user account. The name that you enter will be the user name for that account. Typically, the user name is the name of a member of staff.

NOTE: If the user account is to be associated with a Windows User Profile, you need to give it exactly the same name as the relevant Windows User Profile. For more information, see Using Windows User Authentication with ClearSCADA.

When you have created a user account, you can define its configuration settings by using its configuration Form (see Display the User Form).

You can also move, rename, copy or delete the user account in the same way as you would move, rename, copy or delete any other type of database item. To do this, you will need to log on via a user account that has both the Configure and Security permissions for the Group that contains the new User. Similarly, if you import a User database item, you need to log on via an account that has Configure and Security permissions for the Group that is to contain the imported User.

For more information on renaming, copying, deleting, moving and importing database items, see Organizing and Configuring Your Database in the ClearSCADA Guide to Core Configuration.


Security Guide - Display the User Form (User Accounts)

Display the User Form

Each user account has its own configuration Form that you can use to define the settings for the user account.

To display the User Form:

  • In the Database Bar, right-click on the User item that you want to configure, then select the Properties option from the context sensitive menu.

Alternatively, you can double-click on the User item or select the Properties option from any display that provides access to the User's context sensitive menu.

The User Form consists of several tabs, each of which contains groups of settings. The Identification and User Methods tabs are common to many database items.

For more information on the Identification details, see Defining Identification Details in the ClearSCADA Guide to Core Configuration.

For more information on the User Methods details, see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration.

The General, ViewX, Security and Contact Information tabs contain settings that are specific to Users. They can be used to:

  1. Enable or Disable a User Account
  2. Define the Severity of Events Associated with a User
  3. Define the Area of Interest for Events Logged for the User's Actions
  4. Define whether a User can Access the System via ViewX, WebX or Phone
  5. Define whether a User is Associated with a Windows User Profile
  6. Define the Password for a User
  7. Define the Homepage Settings for a User
  8. Enable or Disable the Confirm Actions Feature for a User
  9. Define the Time Range for a User's Event List
  10. Define whether the User can Respond to Group Alarms Simultaneously
  11. Define whether a User can Only Work with Items under their Exclusive Control
  12. Associate a User with a User Group
  13. Define the Regional Settings for a User
  14. Define the Areas of Interest for a User
  15. Define the Security Settings for a User
  16. Define the General ViewX Settings for a User
  17. Define the Operational ViewX Settings for a User
  18. Define the ViewX Configuration Settings for a User
  19. Define the Alarm Banner and Alarm List Settings for a User
  20. Define the Default Alarm Filter Settings for a User
  21. Define Which Explorer Bars are Available to a User
  22. Define Which Toolbars are Available to a User
  23. Define the E-Mail, Pager, and Voicemail Contact Settings for a User.

NOTE: Some User configuration settings are optional - you do not need to configure every setting for a User account to function.

When you have finished defining the settings for the user account, you need to store the changes you have made by selecting the Save toolbar button or selecting the Save option on the File menu (or by using the Ctrl+S shortcut).

Further Information

Using the Options window to configure the Guest User Account (see Configuring the Guest and Web User Accounts).


Security Guide - Enable or Disable a User Account (User Accounts)

Enable or Disable a User Account

You can use the User Form to enable or disable a user account. Only enabled user accounts can be used to log on to the system. If a user account is disabled (either manually via the configuration or automatically following an excessive number of failed log on attempts), users will not be able to log on via the account until the Account Enabled check box is selected again.

NOTE: Disabled user accounts cannot receive alarm redirections or pager messages.

To enable or disable a user account:

  1. Display the User Form
  2. Select the General tab.
  3. Either:
  • Enable the user account by selecting the Account Enabled check box.

Or:

  • Disable the user account by clearing the Account Enabled check box.
  4. Save the Form to store the changes.

To configure other User settings, see Creating a User Account.


Security Guide - Define the Severity of Events Associated with a User (User Accounts)

Define the Severity of Events Associated with a User

You can use the User Form to set the severity level for any actions (that are associated with the user account) that cause an event to be logged. For example, if the Severity is set to High, and a user logs on via the user account and changes the configuration of a point, the event that is logged due to the configuration changes will have a High severity level.

To define the Severity of events associated with a User:

  1. Display the User Form
  2. Select the General tab.
  3. Use the Severity combo box to set the severity level.

The Severity combo box has a list of options that correspond to the severity range defined on your system (via the Server Configuration Tool). The default severity options are:

  • None—No events are logged for the actions performed by the user. We recommend that you do not select None and use Critical, High, Medium or Low instead as this will provide a record of user activity.
  • Critical—Events are logged for actions performed by the user. The events have Critical severity (the highest severity level).
  • High—Events are logged for actions performed by the user. The events have High severity (the second highest severity level).
  • Medium—Events are logged for actions performed by the user. The events have Medium severity (the third highest severity level).
  • Low—Events are logged for actions performed by the user. The events have Low severity (the lowest severity level).

These options are the default severity options and may have been replaced by an alternative range on your system. If you are unsure about the severity settings, contact a system administrator for advice.

To configure other User settings, see Creating a User Account.


Security Guide - Define the Area of Interest for Events Logged for the User's Actions (User Accounts)

Define the Area of Interest for Events Logged for the User's Actions

Each user account can be associated with up to 4 Areas of Interest. A user can only view the alarms and events that are associated with the items in their Areas of Interest.

You can use the User Form to specify which Area of Interest is to be associated with the events that are raised as a result of the user's actions. Only those users that have access to the Area of Interest that you select will be able to view the events generated by the user's actions. For example, if you configure a user named G Parker and set the Area of Interest field for events to 'Zone A', only those users that have access to 'Zone A' will be able to view the events that are generated when G Parker performs actions, responds to alarms etc.

You can set a user's Area of Interest for events to any of the Areas of Interest that are defined for the user (see Define the Areas of Interest for a User). Alternatively, you can leave the field empty, which will allow the events for the user’s actions to be viewed by every user.

NOTE: The Areas of Interest field is only available on the User Form if the Areas of Interest feature has been enabled on the server (see Enable or Disable the Area of Interest Feature in the ClearSCADA Guide to Server Administration).

To choose the Area of Interest that will be associated with the events that are logged as a result of the user's actions:

  1. Display the User Form
  2. Select the General tab.
  3. Use the browse feature of the Area of Interest field toward the top of the tab to select the required Area of Interest. You can choose from any of the available Areas of Interest or leave the Area of Interest field empty. If you leave the field empty, all users will be able to view the events that are generated as a result of the user's actions. If you choose an Area of Interest, only those users that have access to the selected Area of Interest will be able to view the events that are generated as a result of the user's actions (performing controls, responding to alarms etc.).

Further Information

Define the Areas of Interest for a User.


Security Guide - Define whether a User can Access the System via ViewX, WebX or Phone (User Accounts)

Define whether a User can Access the System via ViewX, WebX or Phone

You can use the Access Type setting on the User Form to determine which of the 3 system interfaces are available to users that log on via that account. The 3 types of system interface are:

  • ViewX—A standard ViewX, OPC, ODBC, .NET or Automation client
  • WebX—A WebX client that interacts with the system via a web browser or SOAP (Simple Object Access Protocol).
  • Phone—The system can be accessed via telephone. This is made possible via touch-tone dialing (when used with Envox).

To specify which of these interfaces are available to a user account:

  1. Display the User Form
  2. Select the General tab.
  3. Define the Access Type settings for the user account:
  • Select the boxes for the interfaces you want to make available to the user account.
  • Clear the boxes for the interfaces that are to be unavailable to the user account. Users that log on via the account will not be able to log on using the de-selected types of interface.

To configure other User settings, see Creating a User Account.


Security Guide - Define whether a User is Associated with a Windows User Profile (User Accounts)

Define whether a User is Associated with a Windows User Profile

If the Windows Authentication feature is enabled at the ClearSCADA server, each ClearSCADA user account can be associated with a Windows User Profile. This allows Windows network administrators to disable ClearSCADA user accounts and manage user account passwords without accessing ClearSCADA - they apply changes to the Windows User Profiles and these changes are automatically applied to the associated ClearSCADA user accounts.

For a ClearSCADA user account to be associated with a Windows User Profile, the following criteria has to be met:

  • The Windows Authentication feature has to be enabled and ClearSCADA has to be able to connect with the Windows Server (the domain name has to be correct and the network connections has to be healthy). For more information, see Using Windows User Authentication with ClearSCADA.
  • The ClearSCADA user account has to have the same name as a Windows User Profile. For example, a ClearSCADA user account named 'S Wilkins' can only be associated with a Windows User Profile named ‘S Wilkins'. The names of the ClearSCADA user accounts have to match those of the Windows User Profiles (and vise-versa).
  • Each ClearSCADA user account that is to be associated with a Windows User Profile has to be configured to have the Authenticate via Windows feature enabled.

To configure a user account so that it makes use of the Authenticate via Windows feature:

  1. Display the User Form
  2. Select the General tab.
  3. Use the Authenticate via Windows check box to define whether the user account is associated with a Windows User Profile:
  • If you select the check box, the user account will automatically be associated with a Windows User Profile that has the same name as the ClearSCADA user account. If such a Windows User Profile does not exist in your network, the ClearSCADA user account will be unable to log on to ClearSCADA (as the user account and password have to be verified against a corresponding Windows User Profile).
  • If you clear the check box, the user account is not associated with a Windows User Profile. It can only be disabled, enabled, and have its password settings changed from within ClearSCADA.
  4. Save the User Form to apply the changes.

To configure other User settings, see Creating a User Account.

Further Information

Using Windows User Authentication with ClearSCADA.


Security Guide - Define the Password for a User (User Accounts)

Define the Password for a User

Each user account can be configured to have a password for security. When a user account has a password, it can only be used to log on to the system if the user enters the appropriate password. This makes it more difficult for unauthorized users to gain access to the system.

NOTE: You can only define the Password for a ClearSCADA user account if the Authenticate via Windows setting is clear on the User Form. If the Authenticate via Windows setting is selected (enabled), the password for the user account has to be configured for the corresponding Windows User Profile. For more information, see Using Windows User Authentication with ClearSCADA.

To define the password settings for a user account:

  1. Display the User Form
  2. Select the General tab and scroll down to the Password settings.
  3. Select the browse button next to the Password field to display the Change Password window.

NOTE: The password settings are affected by the Security settings that are defined on the Server Configuration Tool. For more information, see Define the Default Security Settings for New User Accounts.

  4. On the Change Password window, enter the current password in the Old Password field (if required), then enter the new password in the New Password field and in the Confirm Password field. The entries in the New Password field and the Confirm Password field have to be identical.
  5. Select the OK button to apply the new password and close the Change Password window.
  6. Use the Pre-expired check box to define whether the user of this account is prompted to create a new password the first time they log on via this account. If you select the Pre-expired check box, the user will be prompted to create a new password; if you leave the Pre-expired check box clear, the user will not be prompted to create a new password when they log on, and they will have to use the password defined in the configuration of the user account.

The Pre-expired feature is designed to make users create their own passwords when they are first allocated a user account. As the users create their own passwords, it means the person who originally created the user accounts does not know other users’ passwords. For example, an administrator creates a user account for John Taylor and configures a password for the account. The password is only designed to be temporary and should be changed by John Taylor when he first logs on. The administrator selects the Pre-expired check box so that John Taylor is prompted to create a new password when he first logs on. The password that John Taylor enters replaces the temporary password that was defined by the administrator during the configuration of the account. If the administrator did not select the Pre-expired check box during the configuration, John Taylor would have had to log on using the same password that was defined by the administrator.

The Pre-expired feature is useful when a user has forgotten a password and requires a new one - an administrator can reconfigure the account with a new password and select the Pre-expired box. When the user logs on, they are prompted to enter a new password that is not known to the administrator and overrides the temporary password defined by the administrator. The Pre-expired feature is also useful when creating new user accounts for the same reason.

To configure other User settings, see Creating a User Account.


Security Guide - Define the Homepage Settings for a User (User Accounts)

Define the Homepage Settings for a User

A 'homepage' Mimic or Trend can be associated with each user account. The homepage item that is associated with a user’s account is displayed whenever:

  • The user logs on to the default system via a user account that has:
  • The Multi Document Interface setting disabled

or:

  • Has both the Multi Document Interface setting and the Show Homepage at Logon setting enabled).

In multi-system setups, the homepage setting only applies to user accounts when they are logged on to the default system. Homepage Mimics and Trends are only displayed when you log on to All Systems or specifically log on to the system that is configured as the default system.

  • The user logs on to all systems (in a multi-system setup)
  • The user is logged on to the default system or All Systems and selects the Home toolbar button.

NOTE: The homepage for Guest ViewX client users is defined on the General tab of the Options window (select the Tools menu, then the Options option). The homepage for Guest WebX client users is defined as the 'Default View' on the Group tab of the System Form (right-click on a system item, then select Properties to display the Form).

You can use the User Form to define the 'homepage' settings:

  1. Display the User Form
  2. Select the General tab.
  3. Use the browse button feature next to the Homepage field to select an appropriate 'homepage' display. You can choose any Mimic or Trend.

If the user account has the Multi Document Interface option enabled (on the ViewX tab) and you want the 'homepage' to be displayed when a user logs on via the account:

  1. Select the ViewX tab.
  2. Use the Show Homepage at Logon setting to define whether the 'homepage' display is shown in the ViewX Application window or WebX Client window when a user logs on via the user account:
  • Select the box if the homepage is to be shown when a user logs on via the account
  • Clear the box if the homepage is not to be shown whenever a user logs on via the account.

If the user account does not have the Multi Document Interface option enabled, the 'homepage' will be shown when a user logs on via the account irrespective of the Show Homepage at Logon setting.

To configure other User settings, see Creating a User Account.

Further Information

Multi Document Interface: see Define the General ViewX Settings for a User.


Security Guide - Enable or Disable the Confirm Actions Feature for a User (User Accounts)

Enable or Disable the Confirm Actions Feature for a User

You can configure a user's user account so that every time the user performs an action a prompt is displayed. The user then has to use the prompt to confirm the action before the system will execute it. For example, if the Confirm Actions check box is selected for a user account and the user of that account performs an Override action, they will be prompted to confirm the Override before the Override actually takes place. The system will only execute the Override action after the user has used the prompt to confirm that the action is to be performed.

NOTE: To enable or disable the Confirm Actions feature for the Guest User, see Define the Client Specific Settings for the Guest User.

To enable or disable the Confirm Actions feature for a user account:

  1. Display the User Form
  2. Select the General tab.
  3. Use the Confirm Actions check box to define whether the user that logs on via this account has to confirm each action. If you select the check box, when the user initiates an action such as an override, the user will be prompted to confirm the action before it takes place.

If you clear the check box, the action will occur as soon as the user selects the option for the relevant action (the action will occur as soon as the system can process the action).

NOTE: The Confirm Actions setting on the User Form only takes effect if the Confirm settings for the relevant actions are set to one of the Per User options. The Confirm settings are available on the Form of each database item (there is a Confirm option for each action that can be performed for the item).

To configure other User settings, see Creating a User Account.


Security Guide - Define the Time Range for a User's Event List (User Accounts)

Define the Time Range for a User's Event List

When a user accesses an Event List, the List only includes those events that have been logged during a specific time range. This time range can be adjusted on a per-user basis via the User Form.

To use the User Form to adjust the default time range for that user's Event List displays:

  1. Display the User Form
  2. Select the General tab.
  3. Use the Event List Range fields to define the time range for the Event List. When the user that logs on via this account accesses an Event List, the Event List will initially include those events that were logged within the range defined in the Event List Range fields.

Enter the time range using the OPC relative time format, for example, H-24H to start the range at 24 hours prior to the start of the current hour. Alternatively, you can use the browse buttons to access the Offset window which allows you to construct the time entry (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).

To configure other User settings, see Creating a User Account.


Security Guide - Define whether the User can Respond to Group Alarms Simultaneously (User Accounts)

Define whether the User can Respond to Group Alarms Simultaneously

The configuration of your User account determines whether you can respond to the alarms for items in a Group simultaneously:

  • If the Allow Group Alarm Operations feature is enabled, you can Acknowledge, Unacknowledge, Enable, Disable, and Remove the alarms for items in that Group in a single action (as long as your user account has the required permissions). This reduces the amount of time required to respond to every alarm in a Group but also increases the chances of alarms for individual items being accidentally acknowledged, unacknowledged, removed etc., as only one action is required.
  • If the Allow Group Alarm Operations feature is disabled, you can only perform alarm related operations such as Acknowledge Alarm on individual items.

To define whether the User can respond to the alarms in a Group simultaneously:

  1. Display the User Form
  2. Select the General tab.
  3. Either:
  • Select the Allow Group Alarm Operations check box to allow the user account to access the alarm actions for a Group as well as the individual items in the Group.
  • Clear the Allow Group Alarm Operations check box to deny the user account access to the alarm actions for a Group. This means that the user has to respond to each alarm individually.
    Select or clear the Allow Group Alarm Operations check box to allow/deny access to Group alarm actions.

To configure other User settings, see Creating a User Account.


Security Guide - Define whether a User can Only Work with Items under their Exclusive Control (User Accounts)

Define whether a User can Only Work with Items under their Exclusive Control

Typically, the Exclusive Control feature is used to restrict access to an item's features; only the user that has exclusive control of the item can access its features (For more information, see Exclusive Control).

By default, when a user has exclusive control of an item, they can access the features for the item and can also access the features of other items that are not under exclusive control. Other users cannot access the items that are under the user's exclusive control. However, you can use the settings on the User Form to restrict users so that they only have access to their exclusively controlled items; they will not be able to access items that are not under their exclusive control.

Example:

A user account is configured to have the Exclusive Control Only setting enabled. The user account is named 'C Price'. The 'C Price' user is set up to have exclusive control of 3 points: 'Input Pipe 1', 'Input Pipe 2', and 'Output Pipe'.

A user account is configured to have the Exclusive Control Only setting disabled. The user account is named 'S Teale'. The 'S Teale' user is set up to have exclusive control of 3 points: 'Sensor 1', 'Sensor 2', 'Valve Control'.

The 'C Price' user can only access features for the 'Input Pipe 1', 'Input Pipe 2', and 'Output Pipe' points. They cannot access any other database item as their user account is configured to restrict them to only having access to the items for which they have exclusive control.

The 'S Teale' user can access features for the 'Sensor 1', 'Sensor 2', and 'Valve Control' points and any other items that are not under the exclusive control of another user. So, the 'S Teale' user cannot access the 'Input Pipe 1', 'Input Pipe 2', and 'Output Pipe' points as they are under the exclusive control of 'C Price'.

The other items in the database are not under exclusive control and so can be accessed by the S Teale user.
Not under exclusive control
S Teale cannot access the items that are under exclusive control of C Price
C Price can only access those items under the exclusive control of C Price.

To define whether a user can only work with items that are under their exclusive control:

  1. Display the User Form
  2. Select the General tab.
  3. Either:
  • Select the Exclusive Control Only check box to configure the user account so that it only provides access to those items that are under its exclusive control.

Or:

  • Clear the Exclusive Control Only check box to configure the user account so that it can provide access to any database items that are not under the exclusive control of another user.

To configure other User settings, see Creating a User Account.


Security Guide - Associate a User with a User Group (User Accounts)

Associate a User with a User Group

Each user account can be associated with up to 4 User Groups. This associates the user account with other user accounts that have the same security permissions. For example, a User Group could be created for engineers at a particular site. As the engineers require the same access permissions, their user accounts are associated with a User Group named 'Engineers'. When the security permissions are allocated for the items in the database, the administrator or engineer that is setting up the security can allocate the permissions to all of the engineers at once by allocating the permissions to the 'Engineers' User Group instead of each individual user account. This reduces the amount of time it takes to allocate security permissions.

If you have not yet configured any User Groups, you will not be able to associate the user account with a User Group at this stage. When you have created one or more User Groups, you can return to the user account configuration and associate the account with a User Group.

If your system already contains User Groups that have been configured correctly, you will be able to associate a user account with them.

To associate a user account with a User Group:

  1. Display the User Form
  2. Select the General tab.
  3. Use the User Groups fields to associate the user account with up to 4 User Groups.

For more information on User Groups see User Groups.

To configure other User settings, see Creating a User Account.


Security Guide - Define the Regional Settings for a User (User Accounts)

Define the Regional Settings for a User

The regional settings determine which language, time format, date format and calendar are used when displaying information to the user. The regional settings are on a per user basis and are configured on the User Form.

NOTE: To define the regional settings for the Guest user, see Define the Client Specific Settings for the Guest User.

To define the regional settings for a user account:

  1. Display the User Form.
  2. Select the General tab.
  3. Define the Regional Settings:
  • Locale—Use to choose the language in which your system interface is displayed for the selected user account. You can only choose from the languages that are installed (English UK, US and Australia by default - others are available in language packs).
  • Calendar—Use to choose the calendar that is used for time and dates for the selected user account. You can choose from:
  • Gregorian—The Gregorian calendar has 12 months in a year with leap years every 4 years. This calendar setting is appropriate for many systems.
  • Persian—The Persian calendar is a solar calendar used predominantly in Iran.
  • Date Format—Use to define the format of dates and times that are shown to the user. For information on entering dates and times, see Defining the Format of Displayed Values in the ClearSCADA Guide to Core Configuration.
  • Display Times in UTC—Use this check box to define whether times are displayed in Universal Coordinated Time or local time for the selected user account. Select the check box to display times in UTC or clear it to display times in local time (based on the time zone and daylight saving time settings for the client or server).

To configure other User settings, see Creating a User Account.

Further Information

Time Zone Settings: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Security Guide - Define the Areas of Interest for a User (User Accounts)

Define the Areas of Interest for a User

Each user account can be associated with up to 4 Areas of Interest. These Areas determine which alarms are shown in the Alarm Banner and Alarm List for the user. They also define which events can be viewed—the user will only be able to view the events that are associated with the Areas of Interest to which the user has access (see Define the Area of Interest for Events Logged for the User's Actions)

Every database item that can cause an alarm to be raised can be associated with an Area of Interest. When an alarm is raised for the item, the alarm will only be visible to those users that have access to the relevant Area of Interest. Similarly, events are associated with an Area of Interest—users can only view the events that are associated with the Areas of Interest to which they have access.

The Areas of Interest that can be accessed by a user are defined on the User Form, and each user account can be associated with up to 4 different Areas.

NOTE: The Areas of Interest section will only be visible on the User Form if the Areas of Interest feature has been enabled on the server (see Enable or Disable the Area of Interest Feature in the ClearSCADA Guide to Server Administration).

Example:

The user account A Smith is configured to have access to an Area of Interest named 'Coventry'. The user that logs on via the A Smith account will only be shown the alarms that have been raised for items that are associated with the 'Coventry' Area.

A point named 'AI Sensor' is configured to be associated with the 'Coventry' Area of Interest. When an alarm is raised for the point, the alarm is shown on the Alarm Banner and Alarm List for the A Smith user.

A user logs on via a user account that is configured to be associated with an Area named 'Sydney'. The user cannot see the alarm for the 'AI Sensor' point as that alarm is only visible to users that have access to the 'Coventry' Area of Interest.

To define the Areas of Interest for a user account:

  1. Display the User Form.
  2. Select the General tab.
  3. Use the Areas of Interest section to define the Areas of Interest for the user account:
  • Use the browse button for each Area field to select an Area. Any user that logs on via the user account will be able to see and respond to the alarms for items that are associated with the selected Areas (or are associated with sub-Areas within the chosen Area).

The first time you configure the Areas of Interest for a User, the Area 1 setting is set to World by default. The World Area is the highest Area in the hierarchy and provides access to alarms. If you only want the user account to be associated with specific Areas, you need to change the Area 1 setting so that the user account is not associated with the World Area (otherwise, the user will be able to view alarms irrespective of your choices for Area 2, Area 3, and Area 4).

For more information on Areas of Interest, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

To configure other User settings, see Creating a User Account.


Security Guide - Define the Security Settings for a User (User Accounts)

Define the Security Settings for a User

If the server configuration is set to allow per-user configuration (see Define the Default Security Settings for New User Accounts), the User Form contains a Security tab. You can use the Security tab to define security settings for the individual user account.

To define the security settings for a user account:

  1. Display the User Form.
  2. Select the Security tab. This tab is only available if the Allow Per-User Configuration feature is enabled in the server configuration (see Define the Default Security Settings for New User Accounts).
  3. Define the security settings as follows:
  • Enabled—Select this check box to enable the security features for the user account; clear it to disable the security features for the user account. If you disable the security features, the user account will use the default security settings that are applied at the server (see Define the Default Security Settings for New User Accounts). If you enable the security settings for the User, you will be able to apply specific security settings that only apply to the user account you are currently configuring.
  • Minimum Password Length—Define the least number of characters permitted in a password for this user account.
  • Minimum Password Strength—Choose the password strength. The password strength determines which characters are required in the password:
  • Weak—The password can contain any characters.
  • Medium—The password has to contain a combination of upper and lower case characters.
  • Strong—The password has to contain a combination of upper and lower case characters and digits.
  • Very Strong—The password has to contain a combination of upper and lower case characters, digits, and punctuation characters such as commas.
  • Allowed Failed Logons—Define the number of log on attempts that are permitted. If a user does not enter the correct Username and Password within the defined number of attempts, the system will disable the user account. Users will be unable to log on via the account until a system administrator has re-enabled the user account by enabling the account (see Enable or Disable a User Account).
  • Password Dictionary Size—Define the number of passwords that are stored in the password dictionary.

When you create a password, it is stored in the password dictionary. When the Password Expires After time has elapsed, you need to enter a new password. The new password cannot be the same as any of the passwords in the password dictionary.

For example, if you set the Password Dictionary Size to 3, the password dictionary would store the 3 previous passwords. If the Password Expires After time was 10 days, each password expires after 10 days.

For the first 10 days, the password is London. After 10 days, a new password is required. The new password cannot be London (as London is stored in the password dictionary). The new password is set to Canberra.

After another 10 days (20 days since the first password was created), another password is required. The new password cannot be London or Canberra. The new password is set to Ottawa.

After another 10 days (30 days since the first password was created), another new password is required. The new password cannot be London, Canberra, or Ottawa. The new password is set to Dublin.

After another 10 days (40 days since the first password was created), another password is required. The new password cannot be Canberra, Ottawa, or Dublin. It can be set to London again as only the 3 latest passwords are stored in the password dictionary. (The oldest password is removed from the password dictionary when a new password is created).

  • Must Have Password—Define whether the user account requires a password. If you select the check box, the user account has to have a password; if you clear it, the user account does not need a password.
  • Can Change Password—Define whether the user of the user account can change their own password. If you select the check box, the user will be able to alter their own password via the Change Password action. (The Change Password action is available on the pick action menu for the user account and also when you select the File menu then the Change Password option).
  • Password Expires After—Define the valid duration of a password. When the amount of time that you define has passed, a new password has to be configured for the user account. This feature is designed to provide additional security by making users change passwords regularly.

Enter a time in the OPC time interval format, for example, 4W for 4 weeks. Alternatively, you can use the browse buttons to display the Interval window which allows you to construct the time entry (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration).

  • Inactivity Logout—Define the amount of time the user logged on via the user account can be inactive. If the user does not interact with the system within the defined time, the user account is logged off. This feature is designed to stop clients that are unmanned for an extended period of time from being accessed by unauthorized users.

Enter a time in the OPC time interval format, for example, 2H for 2 hours. Alternatively, you can use the browse buttons to display the Interval window which allows you to construct the time entry (see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration). The time period you define begins when a user logs on via the user account.

To configure other User settings, see Creating a User Account.


Security Guide - Define the General ViewX Settings for a User (User Accounts)

Define the General ViewX Settings for a User

NOTE: The General settings allow you to restrict access to features in ViewX only. These settings have no effect on the user account when logging on via other types of client.

The General interface settings allow you to define whether the user can view multiple displays at once, double-click to access editors, toggle full screen mode, double-click to show an item's properties, define the inactivity logout time, and to close ViewX.

For each setting, selecting the check box enables the feature and clearing the check box disables the feature.

To define the General interface settings for a user account:

  1. Display the User Form
  2. Select the ViewX tab.
  3. Define the General settings:
  • Multi Document Interface—Select this check box to allow the user of the account to simultaneously display multiple Mimics, Graphs, Logic diagrams etc. Clear the check box to limit the user to accessing one 'document' at a time.
  • Double Click Edits Documents—Select this check box to allow the user of the account to be able to display Trends, Mimics and Logic programs in Design mode by double-clicking on the relevant database item in the Database Bar.

If you clear this check box, Trends, Mimics and Logic programs will be shown in Run mode when the user double-clicks on the relevant item.

  • Can Toggle Full Screen—Select this check box to allow the user of the account to be able to switch the interface between full screen mode and normal mode.

If you clear the check box, the interface will be shown in normal mode for the user of the account.

  • Show Homepage at Logon—This feature is only available when the Multi-Document Interface feature is enabled.
  • Select this check box to make the Homepage for this user account display whenever a user logs on (via the user account). The Homepage for the user account is defined on the General tab (see Define the Homepage Settings for a User).
  • Clear the check box to stop the Homepage from being displayed whenever a user logs on via this account.
  • Double-click Shows Properties—Select this check box to allow the user of the account to access the properties (Form) of a database item by double-clicking on the item in the Database Bar.

If you clear this check box, the user will only be able to access the Properties by right-clicking on the relevant item in the Database Bar and selecting the Properties option from the pick action menu. Double-clicking on the item will display the View window (also referred to as the Status Display) for the item.

  • Can Close ViewX—Select this check box to allow the user (that logs on via the account) to close the ViewX application. Clear the check box to configure the user so that they are unable to close ViewX.
  • Inactivity Logout—Use this field to define the amount of time the user will remain logged on if no user activity is detected. For example, a setting of 11W 6D 8H means that if no activity is detected for this user account within 11 weeks, 6 days, and 8 hours, the user will be logged off automatically.

Typically, the Inactivity Logout is either set to a much lower time period so that there is less opportunity for unauthorized users to access the system (when a logged on user has left a work station unmanned), or is left to the default setting as the work stations are secured physically (locked rooms etc.).

You should enter the Inactivity Logout time in the OPC time interval format. Alternatively, use the browse button to display the Interval window which you can use to construct the time entry. For more information, see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.

To configure other User settings, see Creating a User Account.


Security Guide - Define the Operational ViewX Settings for a User (User Accounts)

Define the Operational ViewX Settings for a User

NOTE: The Operational settings allow you to restrict access to features in ViewX only. These settings have no effect on the user account when logging on via other types of client.

The Operational interface settings allow you to define whether the user can execute methods on items in the database and view system alarms and events. They also allow you to define the location of the Operator Document Store for the user account (the Operator Document Store is a special folder that allows operators to edit and save Trends).

To define the Operational interface settings for a user account:

  1. Display the User Form.
  2. Select the ViewX tab.
  3. Define the Operational settings:
  • Operate—Select this check box if the user is allowed to execute methods (perform actions) on items in the database. For example, select this check box if the user is to have access to actions such as Hand Control and Override.

If you select the Operate check box, the user of this account will only be able to execute methods on items in the Database Bar if the security settings for the individual items also allow the user to execute methods.

If you clear the Operate check box, the user of this account will not be able to execute methods in ViewX, even if the security settings of an individual item provides access to its methods.

  • View Alarms—Select this check box to allow the user of the account to view the system alarms in the Alarm Banner and Alarm List. If you clear this check box, the user will not be able to display the Alarm Banner or Alarm List.
  • View Events—Select this check box to allow the user of the account to view the system events in the Event List. If you clear this check box, the user will not be able to display the Event List (Event Journal).

NOTE: User accounts need appropriate permissions for database items as well as having the features enabled on the User Form. For example, if you want a user account to provide access to the alarms for a point, the user account has to have the View Alarms permission in the point's security settings and the View Alarms setting has to be selected in the User configuration.

  • Operator Document Store—Use the browse button to select the personal Operator Document Store to which the user of this account has access.

Operator Document Stores are special groups that can contain documents such as Trends. What is special about these groups is that they allow users that do not have the Configure permission to access the Edit and Save features for the items in the group. This means that operators can alter the configuration of a Trend to suit their needs and then save it in their Operator Document Store.

Each user account can be associated with a maximum of 6 Operator Document Stores:

  • 1 X Global Document Store—This is the Operator Document Store that is configured for the 'Root' Group (system) and is shared by all users of the system.
  • 4 X User Group Document Stores—Each User Group can be associated with a Document Store. As each User can be a member of up to 4 User Groups, this means the User can be associated with up to 4 User Group Document Stores (one for each User Group), as well as the Document Stores for the individual User and the Global Document Store.

The Document Store for a User Group is configured via the User Group Form (see Define the Operator Document Store for a User Group).

  • 1 X user account Document Store—Each user account can be associated with its own personal Document Store that is not shared with any other user account. The personal Document Stores are configured via the User Form.

To configure other User settings, see Creating a User Account.


Security Guide - Define the ViewX Configuration Settings for a User (User Accounts)

Define the ViewX Configuration Settings for a User

NOTE: The Configuration settings allow you to restrict access to features in ViewX only. These settings do not affect the user account when logging on via other types of client.

The Configuration interface settings include the ability to alter the configuration of items in the database, edit visual displays such as Trends, alter the ViewX options, and create file based Mimics and Trends.

To define the Configuration settings for a user:

  1. Display the User Form.
  2. Select the ViewX tab.
  3. Define the Configuration settings:
  • View Configuration—Select this check box to allow the user of this account to view the configuration of database items by accessing their Forms. The Forms will be 'grayed out' so that the user can only view the information unless the Configure Database check box is also enabled.

Clear the check box to stop the user from being able to display the properties for database items.

  • Configure Documents—Select this check box to allow the user of this account to edit the documents of database items such as Trends, Mimics, Logic programs, GrapheX charts etc.

Clear the check box to stop the user from being able to configure the documents.

  • Configure Options—Select this check box to allow the user of this account to alter the ViewX options that are available via the Tools menu.

Clear the check box to stop the user from being able to alter the ViewX options.

  • Configure Database—Select this check box to allow the user of this account to use Forms to edit the properties of items in the database such as points, outstations, channels etc.

Clear the check box to stop the user from being able to configure the items.

  • Configure Local Files—Select this check box to allow the user of this account to configure file based Graphs and Mimics.

Clear the check box to stop the user from being able to configure file based displays.

NOTE: For the user account to have access to the configuration features, it has to have the configuration features enabled and also has to have sufficient permissions for the relevant database items. For example, if you want the user account to be able to configure a Mimic, the user account has to have the Configure permission in the Mimic's security settings as well as the Configure Documents check box selected in the user account configuration.

To configure other User settings, see Creating a User Account.


Security Guide - Define the Alarm Banner and Alarm List Settings for a User (User Accounts)

Define the Alarm Banner and Alarm List Settings for a User

You can use the User Form to define the Alarm Banner and Alarm List settings for a user account. These settings determine whether a user that logs on via a specific user account can select more than one alarm simultaneously, disable the alarm bell, reposition, resize and remove the Alarm Banner. It also allows you to specify the default position of the Alarm Banner, the minimum number of rows that can be shown in the Alarm Banner, and the default setting for the Alarm Bell for that specific user.

To define the Alarm Banner and Alarm List settings for a user account:

  1. Display the User Form.
  2. Select the ViewX tab.
  3. Use the Alarm Banner/List settings as follows:
  • Select Multiple Alarms—Select this check box to allow the user of the account to select more than one alarm simultaneously (in the Alarm Banner or Alarm List).

Clear the check box to restrict the user of the account to selecting one alarm at a a time.

  • Allow Bell Disable—Select this check box to allow the user of the account to disable the audible alarm bell via the Disable Bell option. (The Disable Bell option can be accessed by right-clicking on the Alarm Bell Button).

If you clear this check box, the user of the account will be unable to access the Disable Bell option.

  • Can Move Banner—Select this check box to allow the user of the account to reposition the Alarm Banner. If you clear the check box, the Alarm Banner is in a set position when the user is logged on.
  • Can Resize Banner—Select this check box to allow the user of the account to alter the dimensions of the Alarm Banner. If you clear the check box, the Alarm Banner is shown at a set size when the user is logged on.
  • Minimum Banner Rows—Enter the least number of rows that can be shown in the Alarm Banner. Each alarm requires 1 row.
  • Disable Bell by Default—Select this check box to set the alarm bell to be disabled by default whenever a user logs on via this account. If you clear this check box, the alarm bell will be active by default (it will sound when an alarm is raised unless the user selects the Disable Bell option).
  • Display Banner at Top—Select this check box to display the Alarm Banner at the top of the ViewX interface by default whenever a user logs on via this account.

If you clear this check box, the Alarm Banner will be displayed at the bottom of the ViewX interface whenever a user logs on via this account.

The Display Banner at Top check box is only available when the Can Move Banner check box is clear.

  • Can Remove Banner—Select this check box to allow the user of the account to close the Alarm Banner. If you clear the check box, the Alarm Banner is shown when a user logs on via this account, and the user cannot remove the Alarm Banner.
  • Can Filter Alarm Banner—Select this check box to allow the user of the account to filter the Alarm Banner so that it only shows alarms that match certain criteria. If you clear the check box, the user cannot filter the Alarm Banner. For more information, see Alarm Banner in the ClearSCADA Guide to Alarms.
  • Banner Filter Timeout—Use this field to define the amount of time an Alarm Banner filter defined by this user can be in place. When the defined Banner Filter Timeout time expires, the user’s configured Alarm Banner filter is no longer applied; the default Alarm Banner filter is applied instead.

To define the Banner Filter Timeout, you can enter the amount of time using the UTC time interval format, or you can select the field’s browse button to display the Interval window. You can then use the settings on the Interval window to define the timeout period.

If you define the timeout as 0, any Alarm Banner filter that the user of this account defines will not expire; the filter will apply until the user resets it manually or logs off.

Further Information

OPC Time Formats: see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.

Interval Window:see Interval Window in the ClearSCADA Guide to Core Configuration.

To configure other User settings, see Creating a User Account.


Security Guide - Define the Default Alarm Filter Settings for a User (User Accounts)

Define the Default Alarm Filter Settings for a User

Every user account has an Alarm Filter String setting that allows you to define the default filter for the various alarm displays. The default filter is applied to the alarm displays automatically whenever the user logs on.

For example, a user account named ‘M Draper’ could be configured to have an Alarm Filter String that restricted the alarm displays to only showing alarms that are High priority. When the ‘M Draper’ user logs on, the Alarm Banner and Alarms Lists are automatically filtered so that they only show High priority alarms. Other alarms are hidden. However, ‘M Draper’ can change the filters to show the other alarms as required. The Alarm Filter String only defines the default filter that is in place when the relevant user logs on.

The Alarm Filter String feature is especially useful on systems where the severities are configured to represent a functional area rather than a priority level. For example, some systems have severity ranges configured to represent specific types of alarm, such as alarms relating to flooding. If there are a group of users who are only interested in ‘flooding’ alarms, then their user accounts can be configured so that the various alarm displays only show ‘flooding’ alarms when they log on. This means that, as soon as they log on, they are only presented with alarms that are relevant to their areas of responsibility.

To define the default Alarm Filter String for a user account:

  1. Display the User Form.
  2. Select the ViewX tab.
  3. Define the Default Alarm Filter by entering an Alarm Filter String:

The clauses that you can use in the string and the required format for the string are almost the same as those used with hyperlinks to filtered Alarms Lists (see Creating a Hyperlink to an Alarms List in the ClearSCADA Guide to Mimics). The only difference is that the System cannot be used in the Alarm Filter String for a User (as the string only applies to the system on which the user account is used).

Examples:

Source="Critical 3.*"&MinSeverity="1"&MaxSeverity="333"&MinSeverity="668"
&MaxSeverity="1000"

The string above sets the default filter to limit the alarm displays to showing alarms that are:

  • Generated for items in the Group named "Critical 3"
  • Within the Severity range 1-333 or within the Severity range 668-1000.
AOI="Test Area"&Source="CookieTest.*"&MinSeverity="1"
&MaxSeverity="334"&MinSeverity="668"&MaxSeverity="1000"
&Categories="Archiving;Callback"&AlarmState="Unacknowledged"&Assigned="True"

The string above sets the default filter to limit the alarm displays to showing alarms that meet all of the following criteria:

  • Generated for items that are stored in the Area of Interest named "Test Area", and in the Group named 'CookieTest'
  • Within the Severity ranges 1-334 or 668-1000
  • Associated with the categories Archiving or Callback
  • Are currently Unacknowledged
  • Are assigned to the user (the user that logs on via this user account).
MAIN.AOI="Test Area"&MAIN.Source="~Test.*"&MAIN.MinSeverity="1"
&MAIN.MaxSeverity="334"&MAIN.MinSeverity="667"&MAIN.MaxSeverity="1000"
&MAIN.Categories="Archiving;Callback;"&MAIN.AlarmState="Unacknowledged"&MAIN.Assigned="True"

The string above, while being valid for a Mimic hyperlink to a filtered Alarms List, is invalid for a user account alarm filter string. This is because it includes a system (in this case, MAIN). If the alarm filter string for a user account includes a system, it will cause a configuration error for the user account. The reason for this is that a user account can only be used on a single system, and so the alarm filter string can only be applied to the system on which the user account is stored. For an alarm filter string, references to the system need to be removed:

AOI="Test Area"&Source="CookieTest.*"&MinSeverity="1"
&MaxSeverity="334"&MinSeverity="668"&MaxSeverity="1000"
&Categories="Archiving;Callback"&AlarmState="Unacknowledged"&Assigned="True"

To configure other User settings, see Creating a User Account.

Further Information

Default Alarm Filters: see Specify a Default Alarm Filter in the ClearSCADA Guide to Alarms.

Alarm Filter Syntax:see Alarm Filter String Syntax in the ClearSCADA Guide to Alarms.


Security Guide - Define Which Explorer Bars are Available to a User (User Accounts)

Define Which Explorer Bars are Available to a User

You can configure a user account so that users that log on via the account can only access certain Explorer Bars. For example, you can choose to limit a user account so that it only has access to the Queries Bar and cannot access the Database Bar or OPC Bars. This is useful when there are users that only require limited access to the system, for example, there may be management level users that only require access to the current data on the system and so only need to use the Queries Bar.

To define which Explorer Bars are available to a user account:

  1. Display the User Form.
  2. Select the ViewX tab.
  3. Select the check box for each Explorer Bar that you want to be made available to the user that logs on via this account.

The Explorer Bars are:

  • Database—Provides access to the system's database items.
  • OPC Data—Provides access to the OPC tags for the system's database items.
  • Favorites—Provides access to the user's selected favorite displays.
  • Queries—Provides access to SQL Query lists.
  • OPC Historic—Provides access to the OPC Historic tags for the system's database items.
  • Operator Documents—Provides access to the documents that are included in the operator document store for the user. For more information on Operator Document Stores, please refer to the ClearSCADA Guide to ViewX and WebX Clients.
  • Areas of Interest—Provides access to the Areas of Interest hierarchy that you can use to create and re-organize a hierarchy of Areas. For more information, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

Clear the check box for each explorer bar that you want to be unavailable to the user that logs on via this account.

To configure other User settings, see Creating a User Account.


Security Guide - Define Which Toolbars are Available to a User (User Accounts)

Define Which Toolbars are Available to a User

You can define which toolbars are available to a user by configuring the Toolbar settings on the User Form. The toolbar settings allow you to define which toolbars are available to the user.

To define which toolbars are available to a user account:

  1. Display the User Form.
  2. Select the ViewX tab.
  3. Define the Toolbars settings by selecting the check boxes for those toolbars that you want the user of this account to be able to display. Clear the check boxes for the Toolbars that are to be unavailable to the user. Select or clear the following check boxes:
  • Operate—Provides access to the Operate toolbar (which includes data access buttons such as Database, OPC, Queries, and Favorites).
  • File—Provides access to the File toolbar (which includes the Save button, Cut, Copy, Paste etc.)
  • Navigate—Provides access to the Navigate toolbar (which includes the Zoom tools).
  • Mimic—Provides access to the Mimic Editing toolbar (which includes the Insert tools such as Insert Image).
  • Alignment—Provides access to the Mimic Alignment toolbar (which includes the Bring Forward and Send Backward buttons).
  • Debug—Provides access to the Debug toolbar (which contains the script debugging tools).

To configure other User settings, see Creating a User Account.


Security Guide - Define the E-Mail, Pager, and Voicemail Contact Settings for a User (User Accounts)

Define the E-Mail, Pager, and Voicemail Contact Settings for a User

Each user can be contacted via e-mail, pager, and voicemail. This is useful for sending information and alerting individual users.

Users can only be contacted via e-mail, pager, and voicemail if the Contact Information settings have been configured in their user accounts. The Contact Information settings define the e-mail address, pager ID and service, and voicemail number, ID and PIN for the user.

WARNING

aLARM NOTIFICATION SENT TO USER GROUPS AND USER ROSTERS

You can use the Alarm Redirection feature to redirect alarms to a User Group or User Roster. However, alarms can only be redirected successfully if all of the users in the recipient User Group or User Roster are configured to use the same e-mail or pager contact number (1, 2, 3, or 4). For more information on Alarm Redirection, see Understand Alarm Redirection in the ClearSCADA Guide to Alarm Redirection.

Failure to redirect alarms to User Groups or User Rosters successfully can result in death, serious injury, or equipment damage.

To define the contact information settings for a user account:

  1. Display the User Form.
  2. Select the Contact Information tab.
  3. Define the e-mail contact settings in the E-Mail Contact section:
  1. In the E-Mail Contact field, enter an e-mail address that can be used to contact the user of this account.
  2. Select the Send Using Plain Text Only check box to enforce plain text only e-mails for this user account. Alternatively, clear the check box to allow HTML e-mails.
  3. Repeat steps i and ii for up to 4 e-mail addresses.
  4. Use the Pager Contact section to define the Pager ID and Pager Service:
  1. In the Pager Contact field, enter the pager ID for the pager. Each pager has a unique ID, for example, the phone number of the user's mobile telephone.

NOTE: You need to include the + prefix and the country code for the mobile telephone number, otherwise ClearSCADA will not be able to match the number in SMS messages to the Pager ID. Do not enter the international dialing code, for example, enter '+447901987654' and not '00447901987654'.

  2. Use the browse button feature of the Pager Service field to select an appropriate pager service. You can only select a pager service if a pager service item has been added to the database (see the Pagers Guide).
  3. Use the SMS Commands check box to define whether the user is authorized to execute actions in SMS commands (received via the device that is associated with the Pager ID).
  • If the SMS Commands check box is selected, the user can execute actions in SMS Commands (received on the device with the corresponding Pager ID). However, the user also requires the relevant security permissions for the action (see Permissions for Database Items).
  • If the SMS Commands check box is clear, the user cannot execute actions in SMS commands received via the corresponding pager device.
  4. Repeat steps i-iii for up to four pagers.
  5. Use the Voicemail section to define the voicemail settings. The voicemail feature is designed for use with automated answering systems such as Envox. It allows users to respond to alarms via telephone.

Define the voicemail settings as follows:

  • Voicemail Number—Enter the number that is used to access the voicemail service for this user account. The voicemail number is not used by ClearSCADA but is stored in the database so that it can be sent to other software, such as Envox, in an e-mail message (alarm redirection). The Third Party software can then use the number in the e-mail to contact the user's telephone.
  • User ID—Enter the user identity for the voicemail feature of this user account. The User ID works in much the same way as the Username that is used when logging on to ClearSCADA, except that the User ID is only used when logging on via a telephone. The user will enter the User ID by using the key pad on their telephone.
  • PIN—Use the browse button feature of the PIN field to display the Change PIN window. You can then use the Change PIN window to define the new Personal Identity Number (PIN) for the voicemail account for this user.

The PIN works in much the same way as the Password that is used when logging on to ClearSCADA, except that the PIN is only used when logging on via a telephone. The user will enter the PIN by using the key pad on their telephone.

NOTE: The Voicemail settings are only available if the Phone Access Type is enabled (see Define whether a User can Access the System via ViewX, WebX or Phone).

To configure other User settings, see Creating a User Account.

Further Information

For information on Rejected SMS Messages and other SMS Command failures, see the ClearSCADA Guide to the Pager Driver.


Security Guide - User Account Permissions (User Accounts)

User Account Permissions

You can allocate and restrict access to the settings for any user account in the same way that you can allocate and restrict access to any other database item.

NOTE: If you have created a user account and that user account does not appear to have access to the features for which it has permissions, select the Permission Restrictions settings. Permission Restrictions override other security settings. To access a feature, your user account has to have the relevant permission. Also, the relevant permission should not be restricted by the Permission Restrictions settings at the server (see Permissions for Working with User Accounts and User Groups).

For more information, please refer to Allocating Security Permissions.


Security Guide - Configuring the Guest and Web User Accounts (User Accounts)

Configuring the Guest and Web User Accounts

ClearSCADA has 2 guest user accounts that are used automatically whenever a user accesses the system without logging on. The Guest user account is used as the default account for ViewX clients and the Web user account is used as the default account for WebX clients.

You can configure the Guest and Web user accounts so that you can control what information and features are available to users that access the system without logging on. This is useful as it allows you to restrict the features that are available to unauthorized users.

To configure the Guest user account, you need to use 2 displays - the System Form and the Options window. The settings that you put in place on both displays should correspond so that there is no conflict between the settings. The settings on the System Form apply to every client whereas the settings on the Option window only apply to the client that is being configured (all heads on a multi-head client).

To configure the Guest user account, you need to:

  1. Define the Global Settings for All Guest and Web User Accounts
  2. Define the Client Specific Settings for the Guest User.

To configure the Web user account, you only need to:

  • Define the Global Settings for All Guest and Web User Accounts.

NOTE: To configure the Guest User and Web user accounts, your own user account has to have the Configure permission for the System.


Security Guide - Define the Global Settings for All Guest and Web User Accounts (User Accounts)

Define the Global Settings for All Guest and Web User Accounts

To configure the Guest and Web user accounts:

  1. Display the System Form by right-clicking on the system in the Database Bar, then selecting the Properties option from the pop-up menu. Alternatively, you can select the Properties option for the System from another display, such as a Mimic that contains a context sensitive menu for the System.
  2. On the System Form, select the Guest User tab.
  3. Use the Guest User tab to configure the general Guest and Web user account settings. You will see that the settings are similar to those found on the User Form. The settings on the Guest User tab work in exactly the same way as the corresponding settings on the User Form, except that they apply to the Guest User and Web user accounts and so are the settings that are in place for anyone that accesses the system without logging on.

The settings are:

  • Severity—see Define the Severity of Events Associated with a User. This setting applies to ViewX and WebX.
  • Confirm Actions—see Enable or Disable the Confirm Actions Feature for a User. This setting only applies to WebX.
  • Event List Range—see Define the Time Range for a User's Event List. This setting applies to ViewX and WebX.
  • Allow Group Alarm Operations—see Define whether the User can Respond to Group Alarms Simultaneously. This setting applies to ViewX and WebX.
  • SMS Commands—see Define the E-Mail, Pager, and Voicemail Contact Settings for a User.
  • Exclusive Control Only—see Define whether a User can Only Work with Items under their Exclusive Control. This setting applies to ViewX and WebX.
  • Locale—see Define the Regional Settings for a User. This setting applies to ViewX and WebX.
  • Calendar—see Define the Regional Settings for a User. This setting applies to ViewX and WebX.
  • Date Format—see Define the Regional Settings for a User. This setting applies to ViewX and WebX but has to match the settings defined for the client (see Define the Client Specific Settings for the Guest User).
  • Display Times in UTC—see Define the Regional Settings for a User. This setting applies to ViewX and WebX.
  • Default Alarm Filter—see Define the Default Alarm Filter Settings for a User. This setting applies to ViewX only.
  • Areas of Interest—see Define the Areas of Interest for a User. This setting applies to ViewX and WebX.
  4. After configuring the settings on the Guest User tab, save the Form.

You have now completed the configuration of the Web user account and the general configuration of the Guest user account (the configuration that applies to the Guest user on every client).

There are additional settings that can be applied to the Guest user account for each client. These settings only apply to the client on which they are set—they have no effect on other clients. To configure these additional settings, proceed with Define the Client Specific Settings for the Guest User.

If you have no need to configure any client-specific settings for the Guest user account, you can proceed to define access permissions. For more information, see Allocating Security Permissions.

NOTE: If you have created a Web user account or Guest user account and that user account does not appear to have access to the features for which it has permissions, select the Permission Restrictions settings. Permission Restrictions override other security settings. To access a feature, your user account has to have the relevant permission. Also, that permission should not be restricted by the Permission Restrictions settings at the server (see Permissions for Working with User Accounts and User Groups).

Further Information

Time Zone Settings: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Security Guide - Define the Client Specific Settings for the Guest User (User Accounts)

Define the Client Specific Settings for the Guest User

You can use the Options window to define whether the Guest user can access specific features from the client PC. The settings you put in place only apply to the client PC on which they are made and have no effect on the Guest user account when used on any other client or server.

NOTE: On multi-head clients, the Options window is only available on the main head although the settings that are defined apply to all of the heads.

To define the client specific settings for the Guest user account:

  1. In ViewX, select the Tools menu, then select Options to display the Options window.
  2. On the General tab, use the Guest User section to configure the local Guest User settings for this particular client:
  1. Select the Edit button next to Features to display the Features window.
  2. Use the Features window to define which features are available to the Guest User. The settings on the Features window work in the same way as the corresponding settings on the User Form except that they apply to the Guest user account and so can be used by anybody that has access to the client.

The groups of feature settings are:

  • General—see Define the General ViewX Settings for a User.
  • Operational—see Define the Operational ViewX Settings for a User.
  • Configuration—see Define the ViewX Configuration Settings for a User.
  • Alarm Banner/List—see Define the Alarm Banner and Alarm List Settings for a User.
  • Explorer Bars—see Define Which Explorer Bars are Available to a User.
  • Toolbars—see Define Which Toolbars are Available to a User.
  3. Select the OK button to confirm your choices and close the window, or select Cancel to discard your selections and close the window.
  4. On the Options window, use the Homepage setting to select the Homepage display for the Guest User. This works in the same way as the Homepage setting on the User Form except that it only applies to the Guest user account on this client (see Define the Homepage Settings for a User).
  5. Use the Locale, Date Format, and Display Times in UTC settings to define the regional settings for the Guest User on this client only. These settings have to be set so that they are compatible with the Regional Settings on the Root Group Form (see Define the Global Settings for All Guest and Web User Accounts).
  6. Use the Confirm Actions setting to define whether the Guest user has to confirm methods before they are performed by the system. This setting works in the same way as the Confirm Actions setting on the User Form (see Enable or Disable the Confirm Actions Feature for a User).
  7. Use the Inactivity Logout setting to define the amount of time for which a user can remain inactive while logged on to this client via the Guest user account. If the user is inactive for the defined amount of minutes, ViewX shuts down.
  8. Select the OK button to confirm your choices and close the Options window.

NOTE: On multi-head clients, the changes you have made will only come into effect when you restart the heads.

When you have configured the Guest user account, you will need to define its access permissions. For more information, see Allocating Security Permissions.

Further Information

Time Zone Settings: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Security Guide - Logging On and Off via a User Account (User Accounts)

Logging On and Off via a User Account

User accounts are designed to make it difficult for unauthorized users from gaining access to your system. By logging on via a suitably configured user account, each system user is provided with access to the features and settings that are relevant to their role.

Each user account can be configured to have a password for added security. The password can be changed at regular intervals to decrease the chances of unauthorized users from gaining access to your system.

To log on via a user account, you need to enter a Username and Password (where appropriate).

For information about logging on in ViewX, see Log On to ViewX in the ClearSCADA Guide to ViewX and WebX Clients.

In WebX, you can log on and off by selecting the Log On or Log Off options shown in the banner (see Log On to a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients).

For logging on and off via a Third Party OPC application, refer to the documentation for the application.

No matter which interface you use to access ClearSCADA, you will be prompted to enter a Username and a Password (though the password may not be required, depending on how your user account has been configured). To log on, simply enter the username and password that have been allocated to your account.

If you access the system without logging on via a user account, you will be logged on via the Guest or Web user account automatically (depending on the type of interface you are using). Your access to the system will be defined by the permissions that have been allocated to the Guest or Web user account.


Security Guide - Changing the Password for a User Account (User Accounts)

Changing the Password for a User Account

Depending on the permissions allocated to your user account (and the features made available via your user account's configuration), you can change your password and/or the password of other users. This is useful when other users have forgotten their passwords and so need them resetting. We also recommend that you change passwords on a regular basis. Changing passwords regularly means that if an unauthorized user discovers a password, there is a limited time period in which it will be valid and so they have less opportunity to log on.

In this section, we explain:

  • Changing the Password of Another User's Account
  • Changing the Password of Your Own User Account.


Security Guide - Changing the Password of Another User's Account (User Accounts)

Changing the Password of Another User's Account

If you have sufficient permissions, you can change the password of another user’s account in ClearSCADA. This is only true if the user account is not configured to use the Authenticate via Windows feature.

If the user account is configured to use the Authenticate via Windows feature, the password for the user account can only be changed by making the change to the corresponding Windows User Profile. For more information, (see Using Windows User Authentication with ClearSCADA).

To change the password of another user's user account in ClearSCADA:

  1. Log on via a user account that provides access to the configuration features for the user account that you want to change (i.e has the Configure and Security permissions for the user account). For more details, see Logging On and Off via a User Account.
  2. In the Database Bar, right-click on the User that you want to change.
    A context sensitive menu is displayed.
  3. Select the Change Password option to display the Change Password window.
  1. Enter the new password for the user account in the New Password field.
  2. Enter the new password for the user account in the Confirm Password field. The password has to be identical to the password you entered in the New Password field (so you can be sure you entered the password correctly).
  3. Select the OK button to confirm the changes or select the Cancel button to abort the Change Password procedure.

As an alternative to steps 2 and 3, you can:

  1. Display the User Form for the user account you want to change (see Display the User Form).
  2. On the General tab, use the Password settings to define the new password for the user account.
  3. Save the Form.


Security Guide - Changing the Password of Your Own User Account (User Accounts)

Changing the Password of Your Own User Account

To change the password of your own user account you need to log on via the account and then access the Change Password window in ViewX or the Change Password page in WebX.

On the Change Password window/page, you can enter your existing password and the new password you require. You will also need to confirm the new password by entering it again.

Further Information

Change your Password when logged on to a ViewX client: see System Security in the ClearSCADA Guide to ViewX and WebX Clients.

Change your Password when logged on to a WebX client: see System Security in the ClearSCADA Guide to ViewX and WebX Clients.


Security Guide - User Groups

User Groups

User Groups are special items that can be used to form collections of user accounts. This is useful when several user accounts need to have the same security permissions—the security permissions can be allocated to the User Group instead of each individual user account (when a person logs on, they are given the permissions of the Everyone User Group, the permissions of their user account, and the permissions of any User Groups of which their user account is a member). By allowing you to allocate security permissions to multiple user accounts simultaneously, User Groups significantly reduce the amount of time and effort required to set up your system security.

For more information on how User Groups affect system security, see Understanding User Groups.

To learn how to create and configure User Groups and how to associate user accounts with them, see the following sections:

  • Create a User Group
  • Define the Operator Document Store for a User Group
  • Associate a User Group with a User Account
  • View the Members of a User Group.

You can also modify, move, rename or delete a User Group in the same way as you can alter or remove any other database item. For more information, see Organizing and Configuring Your Database in the ClearSCADA Guide to Core Configuration.

NOTE: To create, modify, copy, move, import, rename or delete a User Group, you have to be logged on via a user account that has the Configure and Security permission for the User Group or Group that will contain the User Group (see Permissions for Working with User Accounts and User Groups).


Security Guide - Create a User Group (User Groups)

Create a User Group

If several user accounts on your system require the same access permissions, you should associate them with a User Group. You can then allocate permissions to all of the user accounts associated with the User Group at once (rather than allocate permissions to each account individually).

When a user account is associated with a User Group, it means the user who logs on via that account is granted:

  • The permissions of the ‘Everyone’ User Group
  • The permissions of the user account
  • The permissions of the User Group(s) of which the user account is a member.

NOTE: To create a User Group, you have to log on with a user account that has the Configure and Security permissions for the Group that is to contain the User Group item (see Permissions for Working with User Accounts and User Groups).

To create a User Group:

  1. In the Database Bar, right-click on the Group or system that is to contain the User Group.
    A context sensitive menu is displayed.
  2. Select the New option, then the Other option, then the User Group option.
    A new User Group is created. It is selected automatically, ready for you to define its name.
  3. Enter a suitable name for the User Group. We recommend that the name should be indicitive of the types of user accounts with which the User Group will be associated.

You have now created a User Group. It can be associated with any of the user accounts on your system (see Associate a User Group with a User Account). You can also configure it so that it is associated with User Methods (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration) and an Operator Document Store (see Define the Operator Document Store for a User Group).

When you have configured the User Group, you will need to define its access permissions. You can define the access permissions for any User Group including the Everyone User Group, on the Security window for each database item. For more information, see Allocating Security Permissions.

You can also move, rename, copy or delete the User Group in the same way as you would move, rename, copy or delete any other type of database item. To do this, you will need to log on via a user account that has both the Configure and Security permissions for the Group that contains the new User Group. Similarly, if you import a User Group database item, you need to log on via an account that has Configure and Security permissions for the Group that is to contain the imported User Group.

For more information on renaming, copying, deleting, moving and importing database items, see Organizing and Configuring Your Database in the ClearSCADA Guide to Core Configuration.


Security Guide - Define the Operator Document Store for a User Group (User Groups)

Define the Operator Document Store for a User Group

You can associate each User Group with an Operator Document Store. The Operator Document Store that you choose will be available to the members of the User Group and can be used to store documents such as Trends (users that do not have the permissions to edit and save Trends will be able to edit and save the Trends in the Operator Document Store).

For more information on operator document stores, please refer to the ClearSCADA Guide to ViewX and WebX Clients.

To define the Operator Document Store for a User Group:

  1. Display the User Group Form.
  • In the Database Bar, right-click on the User Group item that you want to configure, then select the Properties option from the context sensitive menu.

Alternatively, you can double-click on the User Group item or select the Properties option from any display that provides access to the User Group's context sensitive menu.

  2. Select the User Group tab.
  3. Use the browse button feature of the Operator Document Store field to select the operator document store for the User Group.

Operator Document Stores are special groups that can contain documents such as Trends. What is special about these groups is that they allow users that do not have the Configure permission to access the Edit and Save features for the items in the group. This means that operators can alter the configuration of a Trend to suit their needs and then save it in their Operator Document Store.

When you select an operator document store for the User Group, the user accounts that are members of the User Group will be able to edit and configure the documents in the selected store. Each user will also be able to edit and configure the documents that are in the store that is defined in the configuration of their individual user accounts.

  4. Save the Form.

NOTE: For information on the Identification settings, see Defining Identification Details in the ClearSCADA Guide to Core Configuration. For information on the User Method settings, see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration.

You can now associate user accounts with the User Group as required (see Associate a User Group with a User Account).


Security Guide - Associate a User Group with a User Account (User Groups)

Associate a User Group with a User Account

When you have created User Groups, you need to associate them with user accounts. The user accounts that are associated with a User Group become members of the User Group. When a user logs on via a user account that is a member of a User Group, the user is granted:

  • The permissions of the Everyone User Group
  • The permissions of the user account
  • The permissions of any User Group of which the user account is a member.

To associate a user account with a User Group, you need to display the Form for the relevant user account. On the User Form, use the User Group fields on the General tab to associate the user account with the user Form.

Use the User Group fields to associate the user account with a User Group.

You can associate each user account with up to 4 User Groups.

For more information, see Associate a User with a User Group.


Security Guide - View the Members of a User Group (User Groups)

View the Members of a User Group

It can be useful to find out which user accounts are associated with the User Groups on your system. This is especially true on large systems that have many User Groups. Once you know which user accounts are associated with the various User Groups, you can determine what effect any changes to the User Groups might have on your system.

A user account that is associated with a User Group is referred to as a ‘member’ of that User Group. For example, if a user account named 'L King' is associated with a User Group named 'Control St.4', ‘L King’ is a member of ‘Control St.4’. Each user account can be associated with up to four User Groups.

You can view a list of a User Group’s members by selecting the Display Users action. This action is available from the context sensitive menu for User Groups (you can only access it if you have the Read permission).

When you select the Display Users action, the Users List is displayed with a filter already in place. The filter restricts the Users List so that it only shows those Users that are associated with the User Group you chose (the Users have the User Group defined in their User Group 1, User Group 2, User Group 3, or User Group 4 configuration settings).

To view a list of a User Group’s members:

  1. Log on to ViewX or WebX via a user account that has the Read permission for the User Group in which you are interested.
  2. Access the pick action menu for the User Group (see Display the Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).
  3. From the pick action menu, select Display Users.
    The Users List is displayed. It is filtered automatically so that it only includes those Users that have the selected User Group as their User Group 1, User Group 2, User Group 3, or User Group 4 setting.

There are alternative ways of viewing the members of a User Group, for example, you could filter the Users List manually, view the User Group settings on each User Form, or use the Display References action. But the easiest and quickest way of accessing the User Group members information is to use a User Group’s Display Users action.


Security Guide - Allocating Security Permissions

Allocating Security Permissions

You can allocate permissions to each user account and User Group. Every item in the database can have its own set of permissions, or can be set to inherit the permissions that have been set for a parent Group or a Group Instance. The default setting for every new database item is for that item to inherit the security permissions of its parent Group (the Group that contains the item, which is the System group if the item is not within a Group folder).

The permissions determine whether a user can access the features for an item, including configuration features, alarms, and controls. By allocating different permissions to different users and User Groups, you can restrict system activities. For example, you can restrict the configuration of security settings so that only users with system administration knowledge or training can access the Security window.

The permissions that you allocate on the Security window for a database item define which of the item's features are available to the defined users and User Groups.

In ViewX, it is possible for a user to have the permission to access a feature for a database item but still be unable to access the feature. This is because in ViewX a user can only access an item's feature if the item's security settings grant the relevant permissions to the user and the ViewX feature is enabled for the User. For example, if you allocate a Mimic's Configure permission to a user, in ViewX that user will be unable to configure the Mimic unless the configuration of the user account has the Configure Documents feature enabled. For more information, see User Accounts.

A similar situation can occur when the Permission Restrictions settings are in place. The Permission Restriction settings override other security features and allow you to prevent just ViewX users, just WebX users, or all system users from having access to certain features irrespective of their user account permissions. To access a feature, your user account has to have the relevant permission and that permission has to be unrestricted by the server’s Permission Restrictions settings (see Permissions for Working with User Accounts and User Groups).

To allocate the security permissions for an item, you need to log on via a user account that has the Security permission for the item. Of course, the Security feature also has to be enabled on your system.

In this section, you will learn about:

  • Accessing the Security Window for a Database Item
  • Working with the Security Window
  • Allocating Permissions to a User Group or User Account
  • Removing Permissions from a User Group or User Account
  • Permissions for Database Items.

NOTE: When you are allocating permissions, remember that the permissions that are allocated to the Guest user are available to anyone. Also, the permissions that you allocate to the Everyone User Group are allocated to every user account automatically (apart from the Guest user account). Those permissions that you allocate to the Web User are allocated to anyone that access the system via WebX. We advise that you set the Guest, Everyone, and Web permissions to either Read and Browse only or to provide no access to your system. You can then provide access to users by creating your own user accounts and User Groups.


Security Guide - Accessing the Security Window for a Database Item (Allocating Security Permissions)

Accessing the Security Window for a Database Item

Each database item has its own security settings or inherits the security settings from a parent Group (except the 'Root' Group which has its own security settings). The security settings for a database item are referred to as its Access Control List or ACL (see Understanding the Access Control List (ACL)).

Each item has its own ACL that you can view and amend (if you have the Security permission for the item) via the Security window. To display an item's security window:

  1. In the Database bar, right-click on the item for which you want to define the security settings.
    A context sensitive menu is displayed.
  2. Select the Security option to display the Security window for the selected item. If the Security option is not available, your user account does not have the required permissions to alter the item's security settings.

For information on the Security window, see Working with the Security Window.


Security Guide - Working with the Security Window (Allocating Security Permissions)

Working with the Security Window

When you have displayed the Security window for an item (see Accessing the Security Window for a Database Item), you can use its settings to define the security features for the selected item.

The Security window has the following settings:

  • Name—At the very top of the Security window, the name of the database item to which the security settings apply is displayed. For example, on the system item, the name is $Root (the system root).
  • Inherit Permissions from Parent—This check box is selected by default on new database items. When selected, it means that the ACL for the database item is removed, forcing the database item to use the security permissions that are allocated to its parent Group (the Group that contains the item, which may be the System group). If you want the database item to have its own security settings and not inherit those of the parent group, you need to clear this check box. Clearing the check box makes the permission check boxes at the bottom of the Security page become available for use. You can use the Permission check boxes to define the ACL for the database item.
  • Remove Explicit Permissions on Descendants—This check box is only available on Group items and it allows you to specify whether the ACLs of the items in the Group are deleted and replaced with the same permissions that you configure for the Group.

If you select the check box, the items in the Group have their ACLs deleted which forces them to inherit the ACL of the Group.

If you clear the check box, the item's 'children' will retain their individual ACLs and may not inherit the security settings of the Group.

  • User Groups and User Accounts—Below the Remove Explicit Permissions on Descendants check box is a display area that shows the user accounts and User Groups that have permissions to access the selected item. The display shows the ACL—the name of the user account or User Group, the location of the account or User Group in the database, and its permissions.

If you select one of the user accounts or User Groups, you will see that the Permissions check boxes at the bottom of the Security window change to show which permissions have been allocated to the account or User Group.

  • Permissions—The Permissions check boxes show which of the database item's features are available for the selected user or User Group.

The availability of the permissions shown is dependent on the Permission Restrictions settings (see Define whether any Permissions are Restricted). By default, the Unacknowledge Alarms and Assign Alarm Responsibility permissions are restricted and so are not available.

The selected check boxes indicate the permissions that have been allocated; the blank check boxes indicate the permissions that the user account or User Group have not been allocated.

Each user account has the permissions for the 'Everyone' User Group, the User Groups of which the account is a member, and the permissions allocated to the user account itself. The only exception to this rule is the Guest user account which is not a member of the Everyone User Group.

For more information on the individual permissions, see Permissions for Database Items.

Example:

A user account named 'T Daley' is a member of 2 User Groups (the 'Control Management' User Group and the 'Emergency Engineers' User Group).

A point is configured to have the following security settings:

The Everyone User Group has the Read, Browse and View Alarms permissions.

The Control Management User Group is allocated the Disable Controls, Switch Line, Diagnostics, Exclusive Control, Manage Excl.Ctrl, and System Admin permissions.

The Emergency Engineers User Group is allocated the Configure and Read permissions.

The T Daley user is allocated the Read and Security permissions.

This means that the T Daley user has the following permissions for the point:

Read, Browse, and View Alarms (provided by the Everyone User Group), Disable Controls, Switch Line, Diagnostics, Exclusive Control, Manage Excl.Ctrl, System Admin (provided by the Control Management User Group), Configure (provided by the Emergency Engineers User Group) and Security (allocated to the T Daley user account). The T Daley user account does not have any of the other permissions such as Control, Override/Release, and Acknowledge Alarms as they are not allocated to the user account or any of its User Groups.

  • Add—Use this button to display the Add Permissions window. You can use the Add Permissions window to add a user or User Group to the ACL. When a user account or User Group is shown on the Security window, you can allocate its permissions.

For more information, see Allocating Permissions to a User Group or User Account.

  • Remove—Use to remove a user account from the ACL. When you remove a user or User Group from the ACL, that user or User Group will not have access to the selected item (unless it is a member of a User Group that remains in the list).

For more information, see Removing Permissions from a User Group or User Account.


Security Guide - Allocating Permissions to a User Group or User Account (Allocating Security Permissions)

Allocating Permissions to a User Group or User Account

To control access to an item's features and data, you need to allocate permissions to the various User Groups and user accounts on your system. You can allocate permissions via the Security window.

To allocate permissions to a User Group or user account:

  1. In the Database bar, right-click on the database item for which you want to define the security settings. The permissions you allocate to the User Group or user account will define which features for the selected database item are available for the user or User Group.
    A context sensitive menu is displayed.
  2. Select the Security option to display the Security window.

If the user account or User Group for which you want to allocate permissions is already listed on the Security window, proceed to step 6.

If the user account or User Group is not listed on the Security window, proceed to step 3.

  3. Select the Add button to display the Add Permission window.
  4. Select the User Group that you want to add to the list on the Security window. If you want to add an individual user account to the list rather than a User Group, select the Display Users check box, then select the appropriate user account.
  5. Select the OK button to confirm your choice and close the Add Permission window.
    The selected User Group or user account is added to the list on the Security window.
  6. Select the User Group or user account for which you want to configure the security permissions from the list on the Security window.
    The Permissions check boxes indicate which permissions are currently in place for the selected User Group or user account.
  7. Define the permissions settings (see Permissions for Database Items):
  • Select the check boxes for the permissions that you want to allocate to the User Group or user account.
  • Clear the check boxes for those permissions that you do not want to be allocated to the User Group or user account.

NOTE: The permissions shown in the Security window vary, according to whether any permissions have been denied.

  8. Repeat this procedure for each user account or User Group as required.
  9. Select the OK button on the Security window to confirm your selections.

NOTE: When you change permissions, certain menu options will remain visible to users even if they do not have the permissions to use them. If the users attempt to use such options, an Access Denied message box is displayed. If the users log off and then log on again, those options to which they do not have access will no longer be displayed.


Security Guide - Removing Permissions from a User Group or User Account (Allocating Security Permissions)

Removing Permissions from a User Group or User Account

To control access to an item's features and data, you need to allocate permissions to the various User Groups and user accounts on your system. You can allocate permissions via the Security window.

Depending on your system requirements, you may need to remove some User Groups or user accounts from the permissions for certain database items. For example, if you want to stop some items from being viewed via the Guest user account on a WebX client, you need to remove the Web user from the security settings for the database items.

To remove permissions from a User Group or user account:

  1. In the Database bar, right-click on the database item for which you want to define the security settings.
    A context sensitive menu is displayed.
  2. Select the Security option to display the Security window.
  3. Select the User Group or user account for which you want to remove the security permissions from the list on the Security window.
  4. Select the Remove button.
    The User Group or user account is removed from the list. The User Group or user account will now have no access to the selected database item.
  5. Select the OK button on the Security window to confirm your selections.

NOTE: If you remove the permissions for a user account, that user account will still be able to access the item if it is part of a User Group that has access permissions. This applies to every User Group, including the default 'Everyone' User Group. For example, if the 'Everyone' User Group provides access to a point, every user account (apart from the Guest user) will have access to the point, even if you have removed the individual user accounts from the point's security settings. To deny access to an item, you need to remove the 'Everyone' User Group from its security settings.

NOTE: When you change permissions, certain menu options will remain visible to users even if they do not have the permissions to use them. If the users attempt to use such options, an Access Denied message box is displayed. If the users log off and then log on again, those options to which they do not have access will no longer be displayed.


Security Guide - Permissions for Database Items (Allocating Security Permissions)

Permissions for Database Items

Each user account and User Group has permissions that define which features can be accessed when a user logs on. The permissions are applied to each database item separately, for example, a user may have access to controls on one point but not on another.

In ViewX, the permissions that you allocate to a user account only take effect if that user account has been configured to have the corresponding ViewX features enabled. The ViewX features for each user account are enabled or disabled on the User Form (see Creating a User Account). For example, if you access the security settings for a Mimic, you can allocate the Configure permission to a user account. The user of the account has the Configure permission that allows access to the Mimic configuration features. However, the user will only be able to configure the Mimic in ViewX if the user account also has the Configure Documents feature enabled. To access ViewX features such as the configuration options, user accounts need to have the permissions for a database item and the relevant ViewX features enabled on their User Forms.

The permissions for each item are set via the item's Security window. You can use the Security window to define which user accounts have access to the item, and which features are available to those accounts.

Permissions

NOTE: The permissions shown in the Security window vary, according to whether any permissions have been denied.

When you set the access permissions for a Group, the same permissions may also be inherited by the items within that Group:

  • If the items in the Group have not already had permissions allocated and have the Inherit Permissions from Parent check box selected (the default), they will inherit the permissions of the Group. If the Inherit Permissions from Parent check box is clear, the items in the Group will continue to use their own individual ACLs.
  • If you select the Remove Explicit Permissions on Descendants check box on the Group's Security window, the Group's permissions will replace the permissions of the items in the Group automatically. If you clear the Remove Explicit Permissions on Descendants check box, the items in the Group will continue to use their own individual ACLs.

You can alter the permissions of each item in a Group as required (items in Groups can have different permissions to the 'parent' Group).

Access permissions for Group Templates and Group Instances work differently—Group Instances do not inherit the permissions from their Group Template; the permissions for Group Instances are set via the security settings for the Group Instance.

NOTE: When you change permissions, certain menu options will remain visible to users even if they do not have the permissions to use them. If the users attempt to use such options, an Access Denied message box is displayed. If the users log off and then log on again, those options to which they do not have access will no longer be displayed.

To allocate a permission, select the appropriate check box. If you want to deny a permission, clear its check box.

The security permissions for each database item are categorized as follows:

  • Read
  • Browse
  • Control
  • Override/Release
  • Acknowledge Alarms
  • View Alarms
  • Remove Alarms
  • Manual Redirection
  • Unacknowledge Alarms
  • Assign Alarm Responsibility
  • Edit Notes
  • Retrieve Data
  • Promote
  • Tune Limits
  • Annotate History
  • Modify History
  • Validate History
  • Disable Points
  • Disable Alarms
  • Disable Controls
  • Off/On Scan
  • Switch Line
  • Diagnostics
  • Cancel Request
  • Exclusive Control
  • Manage Excl.Ctrl
  • Configure
  • Security
  • System Admin.

Read

Availability: Is available to any User or User Group with the Security permission for the selected item. The Read permission cannot be restricted (you can only stop Users and User Groups from accessing the read settings by denying them the Read permission for database items on a per item basis).

The Read permission defines whether the User or User Group can read the item’s data.

If this permission is disabled, the item’s values will not be available to the User or User Group. Disabling the Read permission causes every other permission to be disabled automatically—the other permissions require the User to have the Read permission.

Browse

Availability: Is available to any User or User Group with Security permission for the selected item. The Browse permission cannot be restricted (you can only stop Users and User Groups from accessing the browse settings by denying them the Browse permission for database items on a per item basis).

The Browse permission defines whether the user or User Group can view the selected database item in the various navigation explorer bars (Database bar, OPC bar etc.).

Control

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Control permission defines whether the user account or User Group has access to the Control actions. There are many different control actions, including Control, Initialize, Set Forecast, Remove Forecast, Send Message, Generate Report, Print Report, and Export Report.

The Control actions perform a specific control on a database item. The control varies according to the type of database item and the plant with which it is associated.

Override/Release

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Override/Release permission defines whether the user account or User Group has access to the Override and Release Override actions for a point (except in BMS, where the Override and Release Override actions apply to different type of database item).

Although this permission is available for every database item, it is only relevant to database points as they are the only items that can have their values overridden.

The Override action sets a point to have a specific value. The value remains in place until the Release Override action is used.

Acknowledge Alarms

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Acknowledge Alarms permission defines whether the user account or User Group has access to the acknowledge alarm features such as the Acknowledge Alarms pick action for a database item. The acknowledge alarm features are used to acknowledge an alarm and are available via several displays including the Alarm List and Alarm Banner. The Acknowledge Alarms permission also applies to e-mail and voice alarm acknowledgment features and the Set Alarm Response feature.

View Alarms

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The View Alarms permission defines whether the user account or User Group is shown the alarms for a database item. The View Alarms permission works in conjunction with the Acknowledge Alarms permission, and we recommend that user accounts with the Acknowledge Alarms permission also have the View Alarms permission.

Remove Alarms

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Remove Alarms permission defines whether a user account or User Group has access to the Remove Alarms action for a database item. It also applies to the Remove with Comment action. For more information, see Remove an Alarm in the ClearSCADA Guide to Alarms and see Remove an Alarm with Comment in the ClearSCADA Guide to Alarms.

Manual Redirection

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Manual Redirection permission defines whether a user account or User Group has access to the Redirect Alarm action for a database item. For more information, see Redirect an Alarm in the ClearSCADA Guide to Alarms.

Unacknowledge Alarms

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted). By default, the Unacknowledge Alarms permission is restricted on a per server basis.

The Unacknowledge Alarms permission defines whether a user account or User Group has access to the Unacknowledge Alarms action for a database item. When available, this action can be used to undo an Acknowledge Alarm action that has been performed on an alarm that has not been cleared. It also applies to the Unacknowledge with Comment action.

For more information, see Unacknowledge an Alarm in the ClearSCADA Guide to Alarms and see Unacknowledge an Alarm with Comment in the ClearSCADA Guide to Alarms.

Assign Alarm Responsibility

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted). By default, the Assign Alarm Responsibility permission is restricted on a per server basis.

The Assign Alarm Responsibility permission defines whether a user account or User Group can access the various Responsibility methods that are available for Set Responsibility Action items. For more information on Set Responsibility Action items and their Responsibility methods, see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection.

Edit Notes

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Edit Notes permission defines whether a user account or User Group can create new notes or alter existing notes for a database item. For more information, see Notes in the ClearSCADA Guide to ViewX and WebX Clients.

Retrieve Data

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Retrieve Data permission defines whether the user or User Group can access the actions that allow the ClearSCADA server to request data from an outstation, PLC etc. For example, if this permission is enabled on a PSTN outstation for the selected user, the user can access the One Shot action.

For more information, see One Shot in the ClearSCADA Guide to Drivers.

Promote

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Promote permission defines whether the user or User Group can promote an outstation, PLC etc. so that is scanned in preference to other devices. This is dependent on the configuration and the supported features of the outstation or PLC.

To promote a device, you need access to the Promote Scanning action.

The Promote permission also provides access to the Promote Dial Out action.

Tune Limits

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Tune Alarm Limits permission defines whether the user or User Group can access the Tune Alarm Limits action. They can use the Tune Limits action to alter the alarm limits of a point (this is dependent on the configuration of the point).

Although this permission is available for every database item, it is only relevant to database points that have limits.

Annotate History

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Annotate History permission defines whether the user or User Group can insert, modify, and delete annotations for the historic data that is shown on a point's Historic Trend. Although this permission is available for every database item, it is only relevant to database points and accumulators.

Modify History

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Modify History permission defines whether the user or User Group can alter the historic data that is shown on a point's Historic Trend. It also defines whether the user or User Group can insert historic values on a Historic Trend for the selected point. Although this permission is available for every database item, it is only relevant to database points and accumulators.

Validate History

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Validate History permission defines whether the user or User Group can use the Validate Data action to confirm that a point's historic data has been checked and is correct. Although this permission is available for every database item, it is only relevant to database points and accumulators.

Disable Points

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Disable Points permission defines whether the user or User Group can enable and disable a point via the Enable Point and Disable Point actions. When a point is enabled, it is 'live' and is updated with new values as appropriate to its configuration; when a point is disabled, it is not updated. It is often useful to be able to disable points under certain circumstances, for example, during maintenance.

Although this permission is available for every database item, it is only relevant to database points and pulse actions.

Disable Alarms

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Disable Alarms permission defines whether the user or User Group can stop alarms being raised for the selected item. Alarms are turned off via the Disable Alarms action.

Disable Controls

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Disable Controls permission defines whether the user or User Group can stop controls being sent to a point. The control feature is turned off via the Disable Controls action. This permission is available for every database item but is only relevant to database points and pulse actions.

Off/On Scan

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Off/On Scan permission defines whether the user or User Group can access the Off/On Scan actions for outstations and points. The Off/On Scan actions are only available for outstations and points on certain drivers, for example, they are available on DNP3 outstations and points.

Switch Line

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Switch Line permission defines whether the user or User Group can instruct an outstation or PLC to switch communications to an alternate channel. Communication channels are switched via the Switch Line action.

This permission is available for every database item but is only relevant to shared outstations, shared outstation sets, switched outstation sets, and some simple channels (for example, Modbus).

Diagnostics

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Diagnostics permission defines whether the user or User Group can access the statistics and monitoring features for an item, for example, the Enable IO Logging action for a channel.

Cancel Request

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Cancel Request permission defines whether the user or User Group can cancel requests (related to a specific item) that are queued.

If the Cancel Request permission is enabled (selected), users can access the Cancel Queued Request action for requests that have been queued by any user.

If the Cancel Request permission is disabled, a user can only access the Cancel Queued Request action for requests they have queued themselves; they cannot cancel requests that have been queued by other users.

For further information on the Cancel Queued Request action, see Cancel Queued Request in the ClearSCADA Guide to Drivers.

Exclusive Control

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Exclusive Control permission defines whether the user or User Group can take exclusive control of an item. When an item is under exclusive control, some of the features for the item are only available to the user with exclusive control.

Please refer to Exclusive Control for more information.

Manage Excl.Ctrl

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Manage Excl. Ctrl permission defines whether the user or User Group can take exclusive control away from another user.

Configure

Availability: Can be restricted via the Permission Restrictions settings (see Define whether any Permissions are Restricted).

The Configure permission defines whether the user or User Group can alter the configuration of the selected item. To configure a user or User Group, the user needs to have Configure and Security permissions for the user or User Group that is to be configured.

Security

Availability: Is available to any User or User Group with the Security permission for the selected item. The Security permission cannot be restricted (you can only stop Users and User Groups from having access to the security settings by denying them the Security permission for database items on a per item basis).

The Security permission defines whether the user or User Group can access and alter the security settings of the selected item. The Security permission is used in conjunction with the Configure permission. When working with user accounts, User Groups, and Groups that contain user accounts and User Groups, the following rules apply:

  • To configure, delete, rename, modify, or convert a User Group or user account, you need to have the Configure and Security permissions for that User Group or user account.
  • To create, copy, or import a User Group or user account, you need to have the Configure and Security permissions for the Group or system that is to contain the new User Group or account.
  • To move a User Group or user account, you need to have the Configure and Security permissions for both the User Group or user account and the target Group or system (the Group or system to where the Group is being moved).

NOTE: These rules also apply to Groups that contain user accounts and User Groups.

System Admin

Availability: Is available to any User or User Group with Security permission for the selected item. The System Admin permission cannot be restricted (you can only stop Users and User Groups from having access to the system admin settings by denying them the System Admin permission for database items on a per item basis).

The System Admin permission defines whether the user or User Group can access the archiving feature for the selected item and the shutdown, configure, and manage server features for the root Group. For example, by accessing the security settings for the system (root) and disabling the System Admin permission for a user account, you stop that user from having access to the server configuration tool and server status displays.

NOTE: In ViewX, a user account only has access to an item or feature if the user account has the relevant security permissions and the corresponding features enabled in the user account configuration (see Creating a User Account).


Security Guide - Actions Associated with Users and User Groups

Actions Associated with Users and User Groups

User and User Group database items provide access to a variety of actions, some of which are designed specifically for use with Users and User Groups. In this section, we describe the purpose of these ‘User/User Group-specific’ pick actions, which include:

  • Notify User
  • Reset Profile
  • Clear Password Dictionary
  • Display Users.

NOTE: Users and User Groups may also have additional pick actions that are specific to a particular driver. These pick actions are described in the documentation for the relevant driver. For example, if your system has the Pager Driver installed, a User may have access to the Send Pager Message action which is described in detail in the ClearSCADA Guide to the Pager Driver.


Security Guide - Notify User (Actions Associated with Users and User Groups)

Notify User

Associated with: Users

Security permission required to access this pick action: Control

You can use the Notify User action to send a message to any other logged-on ViewX User. When you send a message, the message is displayed in a pop-up display on the recipient’s ViewX client.

The messages you send to other logged on Users are recorded in the Events List and are logged.

For more information on using the Notify User action, see Send a Message to a User on another ViewX Client in the ClearSCADA Guide to ViewX and WebX Clients.


Security Guide - Reset Profile (Actions Associated with Users and User Groups)

Reset Profile

Associated with: Users

Security permission required to access this pick action: Security

For each user account, ClearSCADA keeps a ‘profile’ of settings which include the Favorites for that user, Toolbar positions, last active Explorer Bar, and the size of the Explorer Bar and Alarm Banner. By using the Reset Profile action, you can clear a user’s profile so that the default settings are re-applied.

Typically, you would not need to use the Reset Profile action. However, in rare circumstances, logging on via a particular user account may cause a problem due to a corrupt User profile. For example, while extremely unusual, it is possible that logging on via a user account that has a corrupt profile could cause ViewX to ‘freeze’. In this situation, another user should log on and use the Reset User Profile action on the user account that causes the ‘freeze’ to occur. This will clear the data from the profile and allow the user to log on successfully.

To access the Reset Profile action for a user account:

  1. Log on via a user account that:
  • Is not the user account that is encountering log on difficulties.
  • Has sufficient permissions to access the Reset User Profile action (for the user account that cannot log on correctly).
  2. Browse to the User that cannot log on correctly. There are many ways you can access the User, for example, you can browse to the User in the Database Explorer Bar or you can display a Users List and access the User from the list. You may also have Mimics that provide access to the pick action menu for the User.
  3. Select the Reset Profile action from the User’s context sensitive menu (object menu).
    The User’s profile data is reset to the default settings. This will clear the profile data for the User so that the user account can be used to log on successfully again.


Security Guide - Clear Password Dictionary (Actions Associated with Users and User Groups)

Clear Password Dictionary

Associated with: Users

Security permission required to access this pick action: Security

Availability: This pick action is only available when the password dictionary for a user account contains passwords (i.e. the user account’s password has been changed more than once).

You can use the Clear Password Dictionary action to remove any passwords currently stored in the password dictionary for a user account. You can then re-use any of the passwords that were in the password dictionary.

If you have user accounts that have passwords (and the Password Size is greater than 0), ClearSCADA will create a dictionary of passwords for each User. The password dictionary contains a limited number of the passwords that have been used for the user account, and is used to help ensure that new passwords are different to recently used passwords.

For example, if a user account has a password of ‘RCDENG1006’ and this is changed to ‘RCDENG1117’, the old password - ‘RCDENG1006’ - is added to the password dictionary. If the user of that account then attempts to change the password back to ‘RCDENG1006’, ClearSCADA will refer to the password dictionary, detect that the password was recently used, and stop the user from applying that password. The user is prompted to choose another password.

When the password dictionary is full (reaches the defined Password Size for the user account), the next password will replace the oldest password in the password dictionary. The oldest password can then be used as a password for the user account again (ClearSCADA only stops the use of passwords that are stored in the password dictionary).

To access the Clear Password Dictionary action for a user account:

  1. Log on via a user account that has the Control permission for the user account for which you want to empty the password dictionary.
  2. Browse to the User that has the password dictionary that you want to empty. There are many ways you can access the User, for example, you can browse to the User in the Database Explorer Bar or you can display a Users List and access the User from the list. You may also have Mimics that provide access to the pick action menu for the User.
  3. Select the Clear Password Dictionary action from the User’s context sensitive menu (object menu).
    The User’s password dictionary is cleared of passwords. Any passwords that were in the password dictionary can now be re-used for the user account.

Further Information

Password and Password Dictionary Configuration Settings: Define the Security Settings for a User.


Security Guide - Display Users (Actions Associated with Users and User Groups)

Display Users

Associated with: User Groups

Permission required to access this pick action: Read

You can use the Display Users action to display a Users List that is filtered to show only those Users that are members of the selected User Group. For more information, see View the Members of a User Group.


Security Guide - Users List

Users List

You can use ViewX or WebX to display the Users List. The Users List is an SQL based Queries List that contains information about some or all of the user accounts on your system (depending on the filtering that is applied).

The Users List is useful when you need to view and compare information for user accounts, for example, if you need to find out when the user accounts in a specific Group need to have new passwords configured.

In this section, we explain how to Display the Users List and describe the Users List Headings. For more information on using Queries Lists, please refer to the ClearSCADA Guide to Lists.


Security Guide - Display the Users List (Users List)

Display the Users List

You can use the Users List to view information about the user accounts on your system.

NOTE: The Users List can be filtered so that it only provides information about users with specific attributes.

To display the Users List:

In ViewX:

  1. Log on to ViewX via a user account that has access to the Operate toolbar permitted (via the User Form).
  2. Select the Queries button on the Operate Toolbar to switch the Explorer Bar to the Queries Bar.

NOTE: As an alternative to steps 1 and 2, you can select the View menu, then the Explorer Bar option, then the Queries option.

  3. Expand the system icon in the Queries Bar.
  4. Expand the Queries folder.
  5. Double-click on the Users icon or right-click on it and select the List option.
    The Filter Columns window is displayed.
  6. Use the Filter Columns window to apply any filtering as required. For more information on using the Filter Columns window, please refer to the ClearSCADA Guide to Lists.
  7. Select the OK button to confirm the filter selection.
    The Queries List is displayed.

Alternatively, log on to ViewX and select a link to the Users List from an appropriately configured Mimic.

In WebX:

  1. Log on to WebX.
  2. Select the Lists option to display the Lists page.
  3. Select the Users hyperlink.
    The Filter Columns window is displayed.
  4. Use the Filter Columns window to apply any filtering as required. For more information on using the Filter Columns window, please refer to the ClearSCADA Guide to Lists.
  5. Select the OK button to confirm the filter selection.
    The Queries List is displayed.


Security Guide - Users List Headings (Users List)

Users List Headings

The Users List provides information about the users on your system.

NOTE: The Users List can be filtered so that it only provides information about users with specific attributes.

When you display the Users List (see Display the Users List), you can view the following categories of information:

  • Name—The name of the user account (including the parent Group). This is defined during the creation of the user account or when a user account is renamed.
  • Password Expiry Time—The time and date at which the user account's password becomes invalid. When the date and time is reached, a new password has to be configured for the user account.
  • User Group 1—The name of a User Group of which the user account is a member. This is blank if the user account is not a member of a User Group.
  • User Group 2—The name of a User Group of which the user account is a member. This is blank if the user account is not a member of a User Group.
  • User Group 3—The name of a User Group of which the user account is a member. This is blank if the user account is not a member of a User Group.
  • User Group 4—The name of a User Group of which the user account is a member. This is blank if the user account is not a member of a User Group.
  • Type—Shows the type of database item (User).

By right-clicking on any User in the list, you can access the context sensitive menu for that specific User.


Security Guide - Exclusive Control

Exclusive Control

The exclusive control feature allows a user to take control of a database item or group of database items. When an item is under exclusive control, other users cannot access certain features for the item (or cannot access any of the item's features at all depending on the configuration). Only the user with exclusive control of the item can access those features that have been reserved for the user with exclusive control.

Exclusive control is often used to allow maintenance engineers to work on a system. During maintenance, the engineer will raise many test alarms, and by using Exclusive Control, can ‘hide’ these alarms from other users. This is useful as it means users only see ‘real’ alarms and so do not try to respond to the alarms that have been caused by maintenance work.

Another common use of the Exclusive Control feature is to allow a regional control room to control certain Groups at specific times.

In this section, we describe:

  • Enabling and Configuring the Exclusive Control Feature
  • Disabling the Exclusive Control Feature
  • Taking Exclusive Control
  • Releasing Exclusive Control
  • Assigning Exclusive Control to Another User
  • Removing Exclusive Control from Another User
  • Excluding an Item from Exclusive Control
  • Displaying a List of Items Under Exclusive Control
  • Displaying a List of Items Not Under Exclusive Control
  • Exclusive Control Actions.

NOTE: You can configure a user account so that the user of that account can only access items that are under their exclusive control (see Define whether a User can Only Work with Items under their Exclusive Control).


Security Guide - Enabling and Configuring the Exclusive Control Feature (Exclusive Control)

Enabling and Configuring the Exclusive Control Feature

You can only make use of the exclusive control feature after it has been enabled and configured to meet your requirements. You can use the Server Configuration Tool to enable (and disable) the exclusive control feature and choose the permissions to which it applies.

To enable and configure the exclusive control feature:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric
    ClearSCADA     option, then the Server Configuration option.
  2. Log on to the Server Configuration via a user account if prompted to do so (see Security for the Server Configuration Tool).
  3. Expand the required system and node.
  4. Expand the System Configuration branch.
  5. Select Exclusive Control.
    The Exclusive Control section is displayed.
  6. Select the Enabled check box to activate the exclusive control feature.
  7. Use the Available on Group Menus Only check box to define whether the exclusive control options (Take Exclusive Control, Release Exclusive Control etc.) are available on every item or only on Group items. If you select the check box, users will only be able to use the exclusive control options on entire groups of items; if you clear the check box, users will be able to use the exclusive control options on individual items.
  8. Select the check boxes for those features that you want to stop other users being able to use on an item that is under exclusive control. For example, if you select the Disable Alarms check box, when a point is under the exclusive control of a user, other users cannot disable the alarms for that point.

The features that relate to the check boxes you leave cleared will be available to those users that have sufficient permissions, even for items that are under exclusive control. For example, if the Override/Release check box is cleared and a point is under the exclusive control of a user, every other user will still be able to use the Override and Release Override actions for that point.

  9. Repeat steps 3 to 8 inclusive for each node in the system.
  10. When you have made the changes to the server configuration, close the Server Configuration Tool and select the Yes button at the save changes prompt.


Security Guide - Disabling the Exclusive Control Feature (Exclusive Control)

Disabling the Exclusive Control Feature

If you do not want the Exclusive Control feature to be available on your system, disable it by completing the steps in this procedure:

  1. Either:
  • On the server, display the Server Configuration Tool by right-clicking on the
    ClearSCADA icon in the system tray, then selecting the Configuration option.

or:

  • Select the Start menu, then the Programs option, then the Schneider Electric
    ClearSCADA     option, then the Server Configuration option.
  2. Log on to the Server Configuration via a user account if prompted to do so (see Security for the Server Configuration Tool).
  3. Expand the required system and node.
  4. Expand the System Configuration branch.
  5. Select Exclusive Control.
    The Exclusive Control section is displayed
  6. Clear the Enabled check box to deactivate the exclusive control feature.
  7. Repeat steps 3-6 inclusive for each node in the system.
  8. When you have made the changes to the server configuration, close the Server Configuration Tool and select the Yes button at the save changes prompt.


Security Guide - Taking Exclusive Control (Exclusive Control)

Taking Exclusive Control

To take exclusive control of an item or a Group of items, you have to log on via a user account that has the Exclusive Control permission for the item(s) you want to control. Also, exclusive control has to be enabled on your system (via the Server Configuration Tool).

When you take exclusive control of an item, other users cannot use those features that have been reserved for the use of the user with exclusive control. The features are selected on the Exclusive Control section of the Server Configuration Tool.

If you take exclusive control of a Group or Group Instance, you may also take exclusive control of the items within the Group or Group Instance. This is dependent on the permissions of your user account.

The Manage Exclusive Control (Manage Excl Ctrl) permission allows you to take exclusive control away from other users.

The Exclusive Control and Manage Excl. Ctrl permissions are allocated via the item's Security window.

If your user account does not have the Manage Excl. Ctrl permission and you want to take control of a Group, you may not be allocated exclusive control of the items in the Group. For example, if another user has exclusive control of an item in a Group, when you take exclusive control of the Group, the other user will retain exclusive control of the item. You will have exclusive control of every item in the Group except the item that is controlled by the other user.

If you take complete exclusive control, you take exclusive control of every item in a Group or Group Instance. You can only take complete exclusive control if the items in the Group are available i.e. there are no items in the Group already under exclusive control.

If you take partial exclusive control, you take exclusive control of all items except those that are already under the exclusive control of other users. The Take Partial Control option is only available when one or more items in the Group are under the exclusive control of another user.

To take exclusive control of a database item:

  1. Access the context sensitive menu of the item for which you want to take exclusive control (see Display the Object Menu in the ClearSCADA Guide to ViewX Clients and WebX Clients).
  2. Select one of these options:
  • Take Complete Exclusive Control —The item is now under your control and other users cannot access those features that have been reserved for use by the user with exclusive control. If you took control of a Group or Group Instance, you may also have exclusive control of the items in the Group (this is dependent on your user account's permissions and the configuration of the items).
  • Take Partial Exclusive Control —This allows you to take control of all items in a Group or Group Instance except those that are already under the exclusive control of another user.

NOTE: If the exclusive control options are unavailable, the Exclusive Control feature may be disabled on your system (via the Server Configuration Tool) or your user account may not have the Exclusive Control permission for the selected item.

To make the database item available to other users (with sufficient permissions), you need to release the exclusive control (see Releasing Exclusive Control).


Security Guide - Releasing Exclusive Control (Exclusive Control)

Releasing Exclusive Control

When you have exclusive control of an item, other users cannot access the reserved features for the item under exclusive control. The reserved features are those features that have been reserved for use by the user with exclusive control.

To relinquish your exclusive control so that other users (with sufficient permissions) can view and respond to the item's alarms you need to use the Release Exclusive Control action:

  1. Access the context sensitive menu of the item for which you want to take exclusive control (see Display the Object Menu in the ClearSCADA Guide to ViewX Clients and WebX Clients).
  2. Select the Release Exclusive Control option. The item is no longer under your exclusive control. Every user with sufficient permissions can access the item's features.

NOTE: If you log off while items are still under your exclusive control, the exclusive control is released automatically so that other users can access the items.

You can also release the exclusive control of another user, see Removing Exclusive Control from Another User.


Security Guide - Assigning Exclusive Control to Another User (Exclusive Control)

Assigning Exclusive Control to Another User

If your user account has the Manage Exclusive Control permission, you can assign exclusive control of a database item to another user. To do this, you need to call the Assign Exclusive Control method directly via:

  • Logic program

Or:

  • Method Pick Action (a Mimic item that is configured to have a pick action that references the Assign Exclusive Control method).

In both cases, the Assign Exclusive Control method has to be referenced. The name of the user who will be assigned exclusive control has to be defined as the parameter for the Assign Exclusive Control method.

Using Logic:

If you are using a Logic program, the Assign Exclusive Control method needs to be called in the same way as you would call any other method. It also requires that you define the name of the user account that is to be assigned exclusive control.

For example, if you were using an ST program to assign exclusive control of a point named ‘A1Point’ to a user account named ‘PWithe’, your ST Program would need to include:

METHOD
AssignExCtrlPoint AT %M(PSTNOS.PSTN.A1Point.AssignExclusiveControl):STRING;
END_METHOD

AssignExCtrlPoint( 'PWithe' );

Where:

  • AssignExCtrlPoint is the name defined for the variable
  • PSTNOS.PSTN.A1Point.RemoveExclusiveControl is a reference to the Remove Exclusive Control method for the A1Point (the point is stored in a Group named ‘PSTN’ which is stored within a parent Group named ‘PSTNOS’).
  • ‘PWithe’ is the name of the user account that is to be assigned exclusive control of the point.

Using a Method Pick Action:

If you are using a method pick action on a Mimic, you can use the Pick Action Wizard to associate a Mimic object with the Assign Exclusive Control method of a database item.

Select the database item that is to be under exclusive control
Select the Assign Exclusive Control method.

On the next page of the Pick Action Wizard, the user that is to be assigned the exclusive control has to be defined as a parameter for the Method Pick Action.

Define the parameter for the Method Pick Action. This should be the user name of the user that is to be assigned exclusive control.

When the relevant Mimic item is selected, the Assign Exclusive Control action is performed. The item you selected on the Pick Action Wizard will be assigned to the user defined in the parameter. That user will have exclusive control of the item until the exclusive control is released, taken by another user (with sufficient permissions), or the user logs off.

Further Information

Method Pick Actions: see Creating a Method Pick Action in the ClearSCADA Guide to Mimics.

Calling a Method in Logic: see Executing Methods on Database Items in the ClearSCADA Guide to Logic.


Security Guide - Removing Exclusive Control from Another User (Exclusive Control)

Removing Exclusive Control from Another User

If your user account has the Manage Excl. Ctrl permission for an item that is under the exclusive control of another user, you can remove the other user's exclusive control. For example, if a user has exclusive control of a point, and your user account has the Manage Excl. Ctrl permission for that point, you can use the Release Exclusive Control method to remove exclusive control from the other user.

The Remove Exclusive Control method can be accessed directly via:

  • Logic
  • Method Pick Action (a Mimic item that is configured to have a pick action that references the Remove Exclusive Control method).

In both cases, the Remove Exclusive Control method has to be referenced and has to specify which database item is to have its exclusive control released (removed).

Using Logic:

If you are using a Logic program, the Remove Exclusive Control method needs to be called in the same way as you would call any other method. It also requires that you define the name of the user account that currently has Exclusive Control of the item as the parameter for the method.

For example, let’s say that you were using an ST Program to remove a user’s exclusive control of a point named ‘A1Point’. The user is logged on via a user account named ‘PWithe’ and the ‘A1Point’ is stored within a ‘PSTN’ Group which is within a ‘PSTNOS’ parent Group. To remove exclusive control of the point, you would need to reference the Remove Exclusive Control method and define the ‘PWithe’ user account as the method’s parameter:

METHOD
RemoveExCtrlPoint AT %M(PSTNOS.PSTN.A1Point.RemoveExclusiveControl):STRING;
END_METHOD
RemoveExCtrlPoint( 'PWithe' );

Where:

  • RemoveExCtrlPoint is the name defined for the variable
  • PSTNOS.PSTN.A1Point.RemoveExclusiveControl is a reference to the Remove Exclusive Control method for the A1Point.
  • ‘PWithe’ is the name of the user account that currently has exclusive control of the point. This is the User from which Exclusive Control will be removed.

Using a Method Pick Action:

If you are using a method pick action on a Mimic, you can use the Pick Action Wizard to associate a Mimic object with the Remove Exclusive Control method of a database item.

Select the database item that is to be under exclusive control
Select the Remove Exclusive Control method.

On the next page of the Pick Action Wizard, you need to define the user account from which the exclusive control is to be removed (this is the user account that currently has exclusive control of the item). The User name is included as a parameter for the Method Pick Action.

Define the parameter for the Method Pick Action. This should be the user name of the user from which exclusive control will be removed.

When the relevant Mimic item is selected, the Remove Exclusive Control action is performed. Exclusive control of the item you selected on the Pick Action Wizard will be removed (from the user that you defined in the method’s parameter).

Further Information

Method Pick Actions: see Creating a Method Pick Action in the ClearSCADA Guide to Mimics.

Calling a Method in Logic: see Executing Methods on Database Items in the ClearSCADA Guide to Logic.


Security Guide - Excluding an Item from Exclusive Control (Exclusive Control)

Excluding an Item from Exclusive Control

You can use a database item's configuration Form to stop that item from being included in any Exclusive Control activity. This means that all exclusive control features are unavailable for the item and have no effect on the item, even if the Exclusive Control feature is enabled at the server.

This is useful when you need to take exclusive control of some, but not all, of the items in a Group—it can be quicker to exclude specific items then take exclusive control of the Group than to take exclusive control of each item individually.

Example:

A Group named 'West Site' contains 30 items, one of which is a point named 'Pipeline Valve 12'. A user named 'I Taylor' needs to take exclusive control of every item in the Group except the 'Pipeline Valve 12' point as this needs to be used by another user on site.

I Taylor re-configures the 'Pipeline Valve 12' so that it is set to be excluded from exclusive control and then takes exclusive control of the 'West Site' Group—I Taylor is granted exclusive control of every item in the 'West Site' Group except the 'Pipeline Valve 12' point. This is much quicker than taking exclusive control of every item in the 'West Site' Group individually (with the exception of the 'Pipeline Valve 12' point).

To exclude an item from exclusive control, select the Exclude from Exclusive Control check box on the Identification tab of the item's configuration Form. Clear the check box if you want to cancel the exclusion so that the item is included in exclusive control activity again.

Select or clear the check box as required.


Security Guide - Displaying a List of Items Under Exclusive Control (Exclusive Control)

Displaying a List of Items Under Exclusive Control

You can use the Display Objects Under Exclusive Control action to display a list of the database items in a Group or Group Instance that are currently under exclusive control. This information is useful if you need to investigate problems, as some information (such as alarm data for specific items) may only be available to the user with exclusive control of those items.

To display a list of items under the exclusive control of another user:

  1. Access the context sensitive menu of the item for which you want to take exclusive control (see Display the Object Menu in the ClearSCADA Guide to ViewX Clients and WebX Clients).
  2. Select the Display Objects Under Exclusive Control option.
    A list is displayed. The list contains information about each database item that is in the selected Group or Group Instance and is currently under the exclusive control of a user. The list shows the name of the item and the name of the user account that has exclusive control of the item.

The list only includes those items for which your user account has the Read permission and that are under exclusive control. There may be other database items in the Group or Group Instance that are under exclusive control but are not shown in the list (due to your user account not having the Read permission for those items).

You can also display a list of database items that are not under exclusive control (see Displaying a List of Items Not Under Exclusive Control).


Security Guide - Displaying a List of Items Not Under Exclusive Control (Exclusive Control)

Displaying a List of Items Not Under Exclusive Control

You can use the Display Objects Not Under Exclusive Control action to display a list of the database items in a Group or Group Instance that are not currently under exclusive control.

To display a list of items not under the exclusive control of another user:

  1. Access the context sensitive menu of the item for which you want to take exclusive control (see Display the Object Menu in the ClearSCADA Guide to ViewX Clients and WebX Clients).
  2. Select the Display Objects Not Under Exclusive Control option.
    A list is displayed. The list contains information about each database item that is in the selected Group or Group Instance and is not currently under the exclusive control of a user. The list shows the name of the item.

The list only includes those items for which your user account has the Read permission and that are not under exclusive control. There may be other database items in the Group or Group Instance that are not under exclusive control but are not shown in the list (due to your user account not having the Read permission for those items).

You can also display a list of database items that are under exclusive control (see Displaying a List of Items Under Exclusive Control).


Security Guide - Exclusive Control Actions (Exclusive Control)

Exclusive Control Actions

Depending on the permissions of your user account, you can use the object menus for database items to access the following Exclusive Control actions:

  • Display Objects Not Under Exclusive Control
  • Display Objects Under Exclusive Control
  • Take Complete Exclusive Control
  • Take Partial Exclusive Control
  • Release Exclusive Control

You can also use Logic and Method Pick Actions to access the following Exclusive Control methods:

  • Assign Exclusive Control
  • Remove Exclusive Control.


Security Guide - Assign Exclusive Control (Exclusive Control)

Assign Exclusive Control

Associated with: Every database item

Security permission required to access this pick action: Manage Exclusive Control.

This method can only be accessed via Logic programs and Method Pick Actions. It allows you to allocate exclusive control of an item to another user.

For more information, see Assigning Exclusive Control to Another User.


Security Guide - Display Objects Not Under Exclusive Control (Exclusive Control)

Display Objects Not Under Exclusive Control

Associated with: Groups and Group Instances

There are no specific security permissions required to access this option. However, it is only available if there are database items currently under Exclusive Control within the Group or Group Instance you have selected.

The Display Objects Not Under Exclusive Control action allows you to view a list of the items in a Group or Group Instance that are not currently under Exclusive Control. For more information, see Displaying a List of Items Not Under Exclusive Control.


Security Guide - Display Objects Under Exclusive Control (Exclusive Control)

Display Objects Under Exclusive Control

Associated with: Groups and Group Instances

There are no specific security permissions required to access this option. However, it is only available if there are database items currently under Exclusive Control within the Group or Group Instance you have selected.

The Display Objects Under Exclusive Control action allows you to view a list of the items in a Group or Group Instance that are currently under Exclusive Control. For more information, see Displaying a List of Items Under Exclusive Control.


Security Guide - Take Complete Exclusive Control (Exclusive Control)

Take Complete Exclusive Control

Associated with: Every database item

Security permission required to access this pick action: Manage Exclusive Control.

The Take Complete Exclusive Control action allows you to take exclusive control of an item or a group of items. When you take exclusive control of an item, other users cannot access the reserved features for the item (until the exclusive control is released, either by you or by another user with the Manage Exclusive Control permission).

Take Complete Exclusive Control is available on an item’s context sensitive menu when all of the following conditions are true:

  • The Exclusive Control feature is enabled in the server configuration. If the Groups Only option is disabled in the server configuration, the Take Complete Exclusive Control action is available for every item; if the Available on Group Menus Only option is enabled, Take Complete Exclusive Control is only available for Group items.
  • The item does not have the Exclude from Exclusive Control option selected on its Form. For more information, refer to the configuration section for the type of database item for which you are trying to take exclusive control.
  • You are logged on via a custom user account (i.e. an account other than the Super User or Guest account).
  • The item is not already under exclusive control.

If the item for which you want to take complete exclusive control is a Group, the Take Complete Exclusive Control action is only available if all of the conditions above are true and all of the items in the Group are either under your exclusive control or not under exclusive control at all. If any of the items in the Group are under the exclusive control of another user, the Take Partial Exclusive Control action is made available instead of the Take Complete Exclusive Control action.

Further Information

Taking Exclusive Control

Take Partial Exclusive Control.


Security Guide - Take Partial Exclusive Control (Exclusive Control)

Take Partial Exclusive Control

Associated with: Groups that contain items that are already under the Exclusive Control of another user.

Security permission required to access this pick action: Manage Exclusive Control.

The Take Partial Exclusive Control action allows you to take exclusive control of every item in a Group except those that are already under the exclusive control of another user. When you take exclusive control of an item, other users cannot access the reserved features for the item (until the exclusive control is released, either by you or by another user with the Manage Exclusive Control permission).

Take Partial Exclusive Control is available on a Group’s context sensitive menu when all of the following conditions are true:

  • The Exclusive Control feature is enabled in the server configuration.
  • The Group does not have the Exclude from Exclusive Control option selected on its Form. For more information, refer to see Configure the Properties of the Root or System Group in the ClearSCADA Guide to Core Configuration.
  • You are logged on via a custom user account (i.e. an account other than the Super User or Guest account).
  • The Group is not already under exclusive control.
  • At least one of the items in the Group is under the exclusive control of another user. If the items in the Group are not under the exclusive control of another user, the Take Complete Exclusive Control action is made available instead of the Take Partial Exclusive Control action.

Further Information

Taking Exclusive Control.

Take Complete Exclusive Control.


Security Guide - Release Exclusive Control (Exclusive Control)

Release Exclusive Control

Associated with: Every database item

Security permission required to access this pick action: Manage Exclusive Control.

The Release Exclusive Control action allows you to relinquish your exclusive control of an item. For example, if you have exclusive control of a point, you can use the Release Exclusive Control action to remove your exclusive control. This allows other users to access the features of the point that were previously reserved for your use.

For further information, see Releasing Exclusive Control.


Security Guide - Remove Exclusive Control (Exclusive Control)

Remove Exclusive Control

Associated with: Every database item

Security permission required to access this pick action: Manage Exclusive Control.

This method can only be accessed via Logic programs and Method Pick Actions. It allows you to remove exclusive control of an item from another user.

For more information, see Removing Exclusive Control from Another User.


Security Guide - Recommended Security Settings

Recommended Security Settings

When you first install ClearSCADA, the Security feature is enabled by default. However, the default values for the various security-related settings are intentionally set at a low level. This is so that an administrator can gain access to the many features that are needed during the setting up of a system.

To help protect your system against unauthorized users and also from accidental changes made by inexperienced users, you should configure the security settings to meet your own requirements.

While each system and organization is different, there are some common actions you can take to improve the security of your system:

  • Check the Version of your ClearSCADA Software
  • Use Secure Web Ports with a Trusted SSL Certificate
  • Disable the Allow Shutdown Web Setting
  • Use Appropriate Windows User Accounts
  • Use Server Side Security Features
  • Use Server Side Permission Restrictions
  • Use DMZ Servers instead of Permanent Standby Servers
  • Organize your Users and User Groups
  • Configure User Accounts Appropriately.


Security Guide - Check the Version of your ClearSCADA Software (Recommended Security Settings)

Check the Version of your ClearSCADA Software

The latest ClearSCADA software includes the most up-to-date security features designed to help protect your system from unauthorized access.

To check that you have the latest version of the ClearSCADA server software, ClearSCADA client software and ClearSCADA service pack:

  1. Log on to the ClearSCADA Server Administration Tool on your ClearSCADA server.
  2. Select the Help menu, then choose the About option.
    Information about the ClearSCADA software is displayed in a dialog box.

NOTE: The image shown above is for illustration purposes only. Later versions of ClearSCADA may be available.

The About dialog contains contact details for Technical Support and Application information. The Application information includes details of the product label and version.

  • The product label is:

ClearSCADA <Year>R<Release Number>.<Service Pack>[ <Hot Fix> ]

For example:

ClearSCADA 2009 R2.14 is ClearSCADA 2009 Release 2, Service Pack 1, Hot Fix 4.

ClearSCADA 2010 R1 is the first release of ClearSCADA 2010.

  • The product version consists of four numbers:
  • <Major>—This number represents the version of the product and is set to 6.
  • <Minor>— The release number.
  • <Build>—A number that represents the amount of days that have elapsed since 1-Jan-2000 (when the build was requested).
  • <Revision>—Represents the build number within a specific day. This is usually 1 as it is uncommon for there to be multiple builds within the same day.
  3. Compare your version of the ClearSCADA software to the latest ClearSCADA software. Information about the very latest ClearSCADA server software is available at:

www.ClearSCADA.com

  4. Log on to ViewX or WebX on one of your ClearSCADA clients.
  5. Access the version information.

In ViewX:

  • Select the Help menu, then choose the About option to display an About dialog box. The About dialog box provides information about the software version (it uses the same format as the About dialog box for the server software).

In WebX:

  • Select the Diagnostics menu to display the Diagnostics page.
    The version information is shown at the top of the Diagnostics page.
  6. Again, compare your version of the software to the latest ClearSCADA software (see step 3).

If you discover that a newer version of the software is available, please contact your vendor for more information.

For the optimal security, we recommend that you upgrade the latest version of the ClearSCADA software with the latest service pack. However, if you choose not to upgrade, you should at least install the latest service pack for your existing version of ClearSCADA.


Security Guide - Use Secure Web Ports with a Trusted SSL Certificate (Recommended Security Settings)

Use Secure Web Ports with a Trusted SSL Certificate

Your ClearSCADA system can be accessed via the Internet or a company Intranet. To provide this functionality, ClearSCADA uses web ports.

There are two sets of web ports:

  • Non-secure web ports—These ports allow a WebX client to access ClearSCADA via the standard http protocol.

The standard http protocol is not encrypted. The communications traffic between the client and server can be seen by anybody who has physical access to the network and appropriate network monitoring tools.

  • Secure web ports—These ports allow a WebX client to access ClearSCADA via the secure https protocol.

The standard https protocol is encrypted. If somebody is monitoring the network, they will be unable to see the content of the traffic between the client and server.

When a web browser accesses a web server via the secure sockets protocol (https), the web browser will request the server's SSL certificate. The web browser uses the information in the certificate to:

  • check that the web browser is communicating with the correct web server
  • establish a secure encrypted connection to that web server.

If an administrative user has not already configured an SSL certificate in the web server, ClearSCADA will automatically create a top-level non-trusted SSL certificate for that web server.

If the default, server generated non-trusted SSL certificate is used, the WebX client will display warning messages when users access the system. The exact warning message depends on the browsers, but typically might be “There is a problem with this web site’s security certificate”. Some users may find these warning messages distracting, although they do not affect their ability to interact with your ClearSCADA system.

If a trusted SSL certificate is used, the WebX client is able to verify that it is connecting to the expected server, and so there are no warning messages shown when a WebX client accesses the secure web server ports.

We recommend that you purchase trusted SSL certificates for your web servers as this will mean that users do not receive distracting warning messages. We also recommend you review your security options and establish appropriate security for your web server.

Recommended security:

  • Purchase and install a web server certificate
  • Turn off "Allow logon on HTTP port"

Maximum security:

  • Purchase and install a web server certificate
  • Turn off "Allow logon on HTTP port"
  • Disable HTTP port(s).

We recommend that you do not :

  • Use the default server generated non-trusted web server certificate
  • Turn on " Allow logon on HTTP port"

For more information on the Server Configuration Tool’s WebX settings see WebX Settings in the ClearSCADA Guide to Server Administration.


Security Guide - Disable the Allow Shutdown Web Setting (Recommended Security Settings)

Disable the Allow Shutdown Web Setting

The ClearSCADA Server Configuration Tool has an Allow Shutdown setting for WebX clients. The setting defines whether WebX users can shut down your system remotely.

If your system is using non-secure ports, having the Allow Shutdown setting enabled can pose a potential security risk—it could be possible for an unauthorized user to gain access to your system via the non-secure ports, and then shut down your system.

For this reason, we recommend that you disable the Allow Shutdown setting for WebX clients, especially if your system uses non-secure web ports.

If your WebX users have to be able to shut down your system for operational purposes, you will need to enable the Allow Shutdown setting. In this scenario, we strongly recommend that you configure your system so that it can only use secure (https) web ports.

To disable or enable the Allow Shutdown setting, you need to use the Server Configuration Tool’s WebX settings (see WebX Settings in the ClearSCADA Guide to Server Administration).

NOTE: For maximum security, we recommend that your system uses secure web ports (see Use Secure Web Ports with a Trusted SSL Certificate).


Security Guide - Use Appropriate Windows User Accounts (Recommended Security Settings)

Use Appropriate Windows User Accounts

To provide the following features, ClearSCADA has to interact with Windows via a Windows user account:

  • System Calls
  • Printing
  • File Upload
  • Performance Monitoring.

In Windows, access to these features requires the use of a Windows user account that has suitable permissions and in some cases, is part of a specific Windows user group. So, if ClearSCADA is to make use of one or more of these features, it has to be running under a Windows user account that has the required Windows permissions. For example, in ClearSCADA you can print a Mimic. But the Mimic will only print if the ClearSCADA client is running on a PC that is currently logged on to Windows via a Windows user account that has the permission to print.

So when you are setting up ClearSCADA servers and clients, you should consider the permissions that are allocated to the Windows user accounts under which ClearSCADA will run.

For maximum security, we recommend that you configure the Windows user accounts so that they only provide access to the programs, files, printers and PCs that are actually needed. For example, if you need ClearSCADA users to be able to execute system calls on one specific program, use a Windows user account that only provides access to that program. This will mean that your ClearSCADA server and clients can only access the programs, printers, files and PCs that are needed as part of your operational requirements.

On PCs where the system calls, printing, file upload and performance monitoring features will only be used locally, you can use a local Windows account. You will need to set the local Windows account to have suitable permissions in Windows.

On PCs where ClearSCADA will use the system calls, printing, file upload and performance monitoring features over a network, you will need to use a domain Windows user account. You will need to set the domain Windows user account to have suitable permissions in Windows.

For more information on configuring Windows user accounts and Windows user account permissions, please refer to your Windows documentation.


Security Guide - Use Server Side Security Features (Recommended Security Settings)

Use Server Side Security Features

The Server Configuration Tool has Security settings that allow you to define certain security features that apply on a system-wide basis (i.e. they apply for every connection made to that server).

By adjusting the Security settings from their default values, you can improve the security of your system. In particular, you should:

  • Set the Security Level to Strong or Custom
  • Disable the Super User Account


Security Guide - Set the Security Level to Strong or Custom (Recommended Security Settings)

Set the Security Level to Strong or Custom

ClearSCADA has a Security Level setting that is used to enforce certain user account related settings, including the minimum password length, the number of permitted password entry attempts, and whether users can change their own passwords.

When you first install ClearSCADA, the Weak Security Level is in place, by default. This is to provide easy access to ViewX and WebX during the initial stages of setting up your system. To help protect your system from unauthorized use, we recommend that you change the Security Level to a Custom setting and configure password lengths etc., to suit your requirements.

Alternatively, you may wish to use the Strong setting which is a built-in high security level. By setting the Security Level setting to Strong, you can improve the security on your system as users will need to frequently change their passwords and use longer, more complex passwords.

However, when choosing a Strong Security Level for your system, you need to consider the implications - your system may be more secure from unauthorized users, but user accounts will need more management as passwords need to be changed frequently, and there is a stronger chance that users will forget their log on details (especially if passwords have to include letters and numbers).

For more information on configuring the Security Level setting (see Define the Level of System Security in the ClearSCADA Guide to Security).


Security Guide - Disable the Super User Account (Recommended Security Settings)

Disable the Super User Account

During the installation process, you are presented with the option of setting up a Super User account. Designed to be used when incorrect security configuration stops users from accessing the system, the Super User account has access to every database item and feature.

While the Super User account can be useful, it does pose a security risk to your system - if an unauthorized user were to discover the user name and password for the Super User, they would have access to your entire system. For this reason, we recommend that once your system has been set up and is running, you disable the Super User account.

NOTE: If a user encounters difficulties when trying to access the system at a later date, the Super User can be enabled again and used to alter the security settings.

To disable the Super User account, you can use the Change Super-User dialog box. For more information, see Configure the Super User Account in the ClearSCADA Guide to Security.


Security Guide - Use Server Side Permission Restrictions (Recommended Security Settings)

Use Server Side Permission Restrictions

You can use the Server Configuration Tool to deny access to certain features from:

  • Every client that is connected to the server
  • Every ViewX client that is connected to the server
  • Every WebX client that is connected to the server
  • The standard pick menu for database items.

By restricting access to permissions on a system-wide basis in this way, you can make your system more secure by limiting which features are available to clients. For example, you may decide that you want your operator level users to be able to issue a control when they log on via ViewX, but not when they log on via WebX. To enforce this, you would select the Control check box in the ViewX user denied permissions settings and clear the Control check box in the WebX user denied permissions settings.

To use the server side permission restrictions effectively, you need to consider the working procedures for your operators, engineers and administrators. Taking into account their expected duties, you can restrict their access so that when they log on they can only use the features they need.

By default, there are no permissions restricted at the server. For improved security, we recommend that you restrict the permissions in accordance with your operational requirements.

For more information on configuring the server side permission restrictions, see Use Server Side Permission Restrictions. in the ClearSCADA Guide to Security.


Security Guide - Use DMZ Servers instead of Permanent Standby Servers (Recommended Security Settings)

Use DMZ Servers instead of Permanent Standby Servers

If your system architecture has permanent standby servers that are only used to read data from ClearSCADA, you can improve your security by replacing them with De-Militarized Zone servers (DMZ servers).

DMZ servers can run outside a firewall and have a single, read-only connection to ClearSCADA. The read only connection means that it is impossible for the ClearSCADA software on the DMZ server to write to the ClearSCADA database.

However, vulnerabilities in the operating system that runs on the DMZ server can potentially expose your system to unauthorized access. To avoid this, you can use your DMZ server outside a firewall—the firewall can be set to help protect your system against unauthorized access via the operating system.

The table below shows the benefits of using a DMZ server outside a firewall in comparison to a DMZ server without a firewall or a read-only permanent standby server.
 | ClearSCADA software can read from ClearSCADA database | ClearSCADA software can write to ClearSCADA database | Protection against misuse of ClearSCADA software on Server | Protection against Operating System Vulnerabilities
Permanent Standby Server (used as a Read Only server) | Yes | Yes | ClearSCADA user accounts Windows user accounts | No
DMZ Server (no firewall) | Yes | No | ClearSCADA on DMZ server cannot write to the ClearSCADA database. ClearSCADA user accounts Windows user accounts | No
DMZ Server (outside a firewall) | Yes | No | ClearSCADA on DMZ server cannot write to the ClearSCADA database. ClearSCADA user accounts Windows user accounts | Yes. Firewall can be set to help protect against non-ClearSCADA vulnerabilities.

For maximum security, we recommend that instead of read-only servers, you use DMZ servers that run outside a firewall.

If your requirements mean it is impractical to use a firewall, we still recommend that you use a DMZ server instead of a read-only server. Using DMZ servers means you have the added protection of the single, read-only connection between the ClearSCADA software on the DMZ servers and the ClearSCADA database.

Even without a firewall, a DMZ server offers greater protection than a permanent standby server. (due to it having no write connection to ClearSCADA).

To configure a server as a DMZ server, see De-Militarized Zone (DMZ) Permanent Standby Servers in the ClearSCADA Guide to Server Administration.


Security Guide - Organize your Users and User Groups (Recommended Security Settings)

Organize your Users and User Groups

As User accounts and User Groups are a key element of ClearSCADA security, it is important that you try to protect them from unauthorized use. By restricting access to the individual Users and User Groups, you reduce the chance of a user being able to change the access permissions of their own user account or that of other system users.

We recommend that you store your Users and User Groups in a single Group folder. You can then configure the security settings for the Group folder so that the folder and its contents can only be accessed by a select few members of staff.

If you place Users and User Groups in a single Group, you can restrict access to them by using the security settings of the Group. By restricting access to the Group in this way, only high-level, administrative users can access the Group and the Users and User Groups within it.


Security Guide - Configure User Accounts Appropriately (Recommended Security Settings)

Configure User Accounts Appropriately

ClearSCADA’s security feature can act as an effective security tool, helping to protect your system from being accessed by unauthorized users. But its effectiveness is dependent on the appropriate configuration of user accounts.

To access your system via a user account, a user needs to know the user name and password allocated to that user account. But the protection offered by user accounts does not end there - a user account can be denied access to items and features by its own configuration and the security settings of each database item (in addition to the system-wide security settings made at the server).

For more effective security, you should configure the settings for each user account. Ideally, you should configure a user account so that it only allows the user of that account to access the features and items they need to perform their expected duties. For security purposes, the settings you should pay particular attention to are:

  • Access Type—Allows you to define whether the user can access ClearSCADA via ViewX, WebX and Pager/SMS (Phone). For more information, see Define whether a User can Access the System via ViewX, WebX or Phone in the ClearSCADA Guide to Security.
  • User Group—Allows you to associate a user account with up to 4 User Groups. The user account will have its own permissions plus those that are allocated to the User Group(s).
  • The Operational settings on the ViewX tab—You can use the check boxes to control which operator level features are available to the user.
  • The Configuration settings on the ViewX tab—You can use the check boxes to control which configuration features are available to the user.
  • The Alarm Banner/List settings on the ViewX tab—You can use the check boxes to control which alarm features are available to the user.
  • The Explorer Bars settings on the ViewX tab—You can use the check boxes to control which explorer bars (navigation hierarchies, such as the Database Bar) are available to the user.
  • The Toolbars settings on the ViewX tab—You can use the check boxes to control which toolbars are available to the user.
  • The user-specific security settings that are on the Security tab (only available if the Allow per User option is enabled at the server). You can use the Security settings to define the password length, password strength, password expiry etc., for the user account.

By configuring each user account so that it only has access to the features and items that are relevant to the user of that account, you help to protect your system from:

  • Inappropriate changes made by users who are not trained in certain aspects of ClearSCADA. If a user can only access the features that are relevant to their role and which they have been trained to use, there is less chance of ClearSCADA being misused.
  • Unauthorized access to high-level features via low-level user accounts. For example, let’s say your system has a high number of user accounts that are restricted to operational settings only. This means that even if an unauthorized user gains access via one of those accounts, the user is restricted from performing potentially damaging actions due to the configuration settings of the account.

Further Information

User Accounts: see User Accounts in the ClearSCADA Guide to Security.

User Groups: see User Groups in the ClearSCADA Guide to Security.


Database Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Database Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Database Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Database Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Database Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Database Guide - Document Scope (About the Guide)

Document Scope

This guide provides information about the structure of the ClearSCADA database and explains how to use the Database Schema to view database tables.

For details on the subjects covered in this Guide, see Welcome to the Guide to the Database.


Database Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed to help users understand the structure of the ClearSCADA database. The information it contains may be useful to engineers who are responsible for configuring:

  • Mimics (animations, pick action menus, embedded Lists etc.)
  • Trends (trace source)
  • Reports
  • Logic programs (Function Block Diagrams, Structured Text programs etc.)
  • The Alarm Banner (extra columns etc.)
  • Extra fields in the database
  • External applications to access the database (via ODBC, OPC, SOAP, or Automation).


Database Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Database Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Expressions

ClearSCADA Guide to ViewX and WebX.


Database Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Database Guide - Welcome to the Guide to the Database

Welcome to the Guide to the Database

The ClearSCADA Guide to the Database provides information about the structure of the ClearSCADA database. It also explains how to use the ClearSCADA Database Schema to locate specific information about the database tables.

You may need to access the information when:

  • Creating Mimics (for animations, pick action menus, embedded Lists etc.)
  • Creating Graphs (trace source)
  • Creating Reports
  • Creating Logic programs (function block diagrams, structured text programs etc.)
  • Customizing the Alarm Banner (adding extra columns etc.)
  • Adding or modifying extra fields in the database
  • Using external applications to access the database (via ODBC, OPC, SOAP, or Automation).

If you are unfamiliar with the structure of the database and how the ClearSCADA Database Schema works, we suggest that you:

  1. Familiarize yourself with the structure of the database (see Understanding the Database).
  2. Learn how to use the ClearSCADA Database Schema to view information about different tables (see Working with the Database Schema).


Database Guide - Understanding the Database

Understanding the Database

This section provides an overview of the various aspects of the database, including:

  • Database Table Hierarchy.
  • Tables.
  • Classes.
  • Fields.
  • Aggregates.
  • Sections.
  • Methods.

You need to understand the database table hierarchy and structure before you can fully appreciate the information that is provided by the ClearSCADA Database Schema (see Working with the Database Schema).


Database Guide - Database Table Hierarchy (Understanding the Database)

Database Table Hierarchy

The ClearSCADA database consists of Classes that contain a collection of Fields, Aggregates, and Methods. The classes are structured in a hierarchy that define parent-child relationships between the classes i.e. a class can be derived from another class.

Each parent class is referred to as a base class, and each child class is referred to as a sub-class. Each sub-class inherits every one of its parent classes.

Example:

The CDBPoint table inherits the CAlarmObject and CDBObject tables. The CAlarmObject table inherits the CDBObject table.


Database Guide - Tables (Understanding the Database)

Tables

The database consists of many tables. Each table is made up from a class and every one of its base classes (parent classes). A table contains the Fields, Aggregates, and Methods from the classes that form the table.

All classes (except aggregates) are derived from one class— CDBObject.

Example:

The diagram (below) shows the CDBObject class and some of its sub-classes (CAlarmObject, CAdvSet). It also shows some of the sub-classes of the CAlarmObject class (CDBPoint, CAdvChannel, and CAdvOutstation).

The CDBPoint table is made up from the CDBPoint class and its base classes. This means that the CDBPoint table includes the CAlarmObject class and the CDBObject class.

Similarly, the tables for the CAdvChannel and CAdvOutstation classes also include the CAlarmObject and CDBObject classes as they are derived from those classes.

The table for the CAdvSet class includes the CAdvSet class and the CDBObject class.

The table for the CDBObject class only includes the CDBObject class as it has no base classes.

You can use the ClearSCADA Database Schema to determine the relationships between the classes in each table (see Working with the Database Schema).


Database Guide - Classes (Understanding the Database)

Classes

Each class consists of a collection of Fields, Aggregates, and Methods.

There are 2 types of class:

  • Creatable Class—An object of this class can be created in the database.
  • Non-Creatable Class—An intermediate class.

Each class except CDBObject and CAggregate (the roots of the class hierarchy) has a base class.The base class is the parent class of the class.

The classes that are base-classes also have sub-classes. The sub-classes are the child classes of the selected class.

You can use the ClearSCADA Database Schema to display information about each class (see Working with the Database Schema).


Database Guide - Fields (Understanding the Database)

Fields

Each class can contain two categories of field—Configuration fields and Data fields. The Configuration fields store the data that defines the setup of each database item, and the Data fields store the values for the database items.

Both the Configuration fields and the Data fields can be any of the following field types:

  • String
  • StlString
  • Color
  • Reference
  • Unsigned Byte
  • Signed Word
  • Unsigned Word
  • Signed Long
  • Unsigned Long
  • Boolean
  • Float
  • Double
  • Time

The types of field (listed above) are described in more detail in the Class Information section (you can use the ClearSCADA Database Schema to display information about each field that is in a class).

Aggregates and Alarm Conditions also provide access to additional fields. For aggregates, the fields can be configuration fields or data fields but alarm conditions can only provide access to data fields. Many of the fields for alarm conditions are read-only and relate to specific alarm data, but there are 2 notable exceptions: Disabled and Accepted (see Alarm Conditions Section).


Database Guide - Aggregates (Understanding the Database)

Aggregates

An aggregate is a special type of class that acts as an extension of another class. Unlike other classes, aggregate classes derive from the CAggregate class (rather than the CDBObject class).

Each aggregate has its own name, Fields, and Methods and is used to store a set of data. For example, the CGenericModbusOSPSTN table includes the PSTN aggregate—the PSTN aggregate groups specific configuration for a PSTN outstation's communication settings.

The PSTN aggregate contains configuration data. The data is shown as the PSTN tab on the Generic Modbus PSTN Outstation Form.

NOTE: Aggregates cannot contain other aggregates.

Each aggregate can be either fixed or optional and single or multi-type:

  • Fixed/Optional:
  • A Fixed aggregate exists for every database item of the relevant type.
  • An Optional aggregate can be enabled or disabled on each database item as required.
  • Single/Multi-Type:
  • A Single aggregate is fixed as the same class (for example, the Redirection aggregate on an item with alarms is fixed as the CAlarmRedirectionList class).
  • A Multi-Type aggregate allows a choice of classes (for example, the Connection aggregate on a channel provides multiple types of classes).

You may need to include aggregates in expressions for animations and Logic programs. For example, you may need to include an aggregate in an expression that uses a historic calculation tag (see OPC Historic Aggregates (Algorithms) in the ClearSCADA Guide to Expressions).

You can use the ClearSCADA Database Schema to display information about the aggregates for each class (see Working with the Database Schema).


Database Guide - Alarm Conditions (Understanding the Database)

Alarm Conditions

Alarm conditions are special extensions that relate to alarm data. The alarm conditions are of the CAlarm class and so, like aggregates, provide access to additional Fields and Methods. However, alarm conditions are only used to store alarm related data and provide access to alarm related methods. The methods for alarm conditions only apply to the alarm conditions, not the entire class.

As alarm conditions are of the CAlarm class, they provide access to the fields and methods of the CAlarm class. Many of the fields relate to alarm data and are read-only, but there are two notable exceptions:

  • Acknowledged—Determines whether the alarm has been acknowledged. OPC applications can be used to write a True value to this field. When a True value is written to this field, ClearSCADA sets the alarm condition to acknowledged.
  • Disabled—Determines whether the alarm condition is enabled or disabled. OPC applications can be used to write a True value of False value to this field. When a True value is written to this field, ClearSCADA sets the alarm condition to enabled and when a False value is written to this field, ClearSCADA sets the alarm condition to disabled.

The methods for alarm conditions are related to alarm controls, such as Acknowledge Alarm, Remove Alarm etc.

You can use the ClearSCADA Database Schema to access information about the alarm conditions for each class (see Class Information).


Database Guide - Sections (Understanding the Database)

Sections

The information in the database is organized into 3 sections:

  • Configuration—This section contains the configuration for the database items. There are usually infrequent changes to the data in this section after the initial configuration has been setup. The configuration data is stored in 3 different types of file:
  • ClearSCADAMetadata.xml—Contains any custom fields created by users (metadata)
  • ClearSCADAConfigStr—Contains the structure of the database
  • ClearSCADAConfig<nnnn>—These numbered files contain the configuration data for a set of database items. Each file can contain the configuration data for up to 16384 items. The file ClearSCADAConfig0001 contains the data for the first 16384 database items created (database item number 0 to database item number 16383), the file ClearSCADAConfig0002 contains the data for items 16384 to 32767 and so on.
  • Data—This section contains the values for the items in the database. There are frequent changes to this section as the values are updated regularly. The values are stored to disk in files that are numbered in the same way as the ClearSCADAConfig<nnnn> files. For example, the file ClearSCADAData0001 contains the values for the database items that have their configuration stored in the ClearSCADAConfig0001 file.
  • Dynamic Data—This section contains the values for the items in the database that are not stored to disk, for example, the 'state' of a channel. Dynamic data does not persist after the system is shutdown. Dynamic data is not stored to disk.

NOTE: The file names for the configuration and data sections are variable and so, on your system, may have been changed from the default names shown above.

You can use the ClearSCADA Database Schema to access information about the data that each class stores in the configuration and data sections (see Class Information).


Database Guide - Methods (Understanding the Database)

Methods

There are 2 types of method:

  • Action methods
  • Calculation methods

Action methods are used to perform an action, such as acknowledge an alarm or override the value of a database point. Many action methods are available as pick actions in ViewX or WebX. Those action methods that are not available as pick actions can only be accessed 'programmatically' i.e. via Mimic scripting, automation, SOAP etc.

Calculation methods are used to calculate a value rather than perform an action. For example, calculation methods can be used in expressions on Mimics to return a calculated value. Calculation methods do not appear as pick actions in ViewX or WebX.

Each method has a unique name in its database table and may have arguments. The arguments (also referred to as parameters) are used to pass information to the system when the method is executed. For example, the Control method on an output point has an argument to specify the value to which the point is set.

For calculation methods, the last argument is the value that is returned by the method. When you use the Database Schema to view a calculation method, the last argument of the calculation method has a [retval] prefix.

You can use the ClearSCADA Database Schema to access information about the methods that are associated with each class (see Class Information).


Database Guide - Working with the Database Schema

Working with the Database Schema

The ClearSCADA Database Schema is a web based display that provides information about the various classes in the database. Each class has its own page that contains details about:

  • Base Class—The class that is immediately above the selected class in the database hierarchy.
  • Sub-Classes—The classes that are immediately below the selected class in the database hierarchy.

It also provides details about the various fields, aggregates, and methods that are contained within the class.

This section explains how to use the ClearSCADA Database Schema and describes some of the potential entries.

To familiarize yourself with the ClearSCADA Database Schema, you should:

  1. Access the Database Schema.
  2. Either:
  • Display Information about a Creatable Class.

Or:

  • Display Information about All Classes.
  3. Learn how to Display a List of All Database Items in a Specific Class.


Database Guide - Access the Database Schema (Working with the Database Schema)

Access the Database Schema

You need to use Internet Explorer to access the ClearSCADA Database Schema. You can then use the ClearSCADA Database Schema to locate information about the classes.

To access the ClearSCADA Database Schema:

  1. Run Internet Explorer on any PC in the network.
  2. In the Address field, overwrite any existing address with:
http://<server name>:<web server port>/Schema

Where <server name> is the name of one of your servers and <web server port> is the port number that is defined in the WebX section of the ClearSCADA Server Configuration Tool (see Define the Access Settings for WebX Clients in the ClearSCADA Guide to Security).

Do not enter the angle brackets <>.

Alternatively, if you are using the server PC and it uses port 80 for the web server's port, you can enter:

http://localhost/Schema

  3. Press the Enter key or select the Go button.
    The ClearSCADA Database Schema is displayed.


Database Guide - Display Information about a Creatable Class (Working with the Database Schema)

Display Information about a Creatable Class

To display information about a creatable class, you need to access the Creatable Classes page. This is the first page that is displayed when you Access the Database Schema. It lists the classes of item that you can create in the database.

The Creatable Classes page has a hyperlink for each class of database item. If you select a hyperlink, the information for the relevant class of item is displayed (see Class Information). The information is shown in a table, and is categorized.

There is also a link to List All Classes. When you select this link, a list of every class, not just the creatable classes is shown (see Display Information about All Classes).

Further Information

Creatable Classes: see Classes.


Database Guide - Display Information about All Classes (Working with the Database Schema)

Display Information about All Classes

You can use the ClearSCADA Database Schema to display information about every class, not just those classes that are creatable. By displaying the All Classes 'page', you can:

  • Access information about a specific class (either a creatable class or a non-creatable class).
  • Determine the structure of the database tables in your system. By observing the Base Class and Sub-Classes, you can determine how the tables in your database relate to one another.

To display information about all classes:

  1. Access the Database Schema.
  2. Select the List All Classes hyperlink.
    The All Classes 'page' is displayed.

You can select a hyperlink for each class of item. This displays information about the relevant class.


Database Guide - Class Information (Working with the Database Schema)

Class Information

The ClearSCADA Database Schema provides information about each class. The information is categorized under these headings:

  • Category Section
  • Base Class and Sub-Classes Section
  • Aggregates Section
  • Alarm Conditions Section
  • Configuration Fields and Data Fields Section
  • Methods Section.

For each section, there is a table that categorizes the information.


Database Guide - Category Section (Working with the Database Schema)

Category Section

The classes are grouped into categories, for example, the 'Internal' category contains every class for internal points.

In ViewX, the options on the New <item> context sensitive menu correspond to the various categories.


Database Guide - Base Class and Sub-Classes Section (Working with the Database Schema)

Base Class and Sub-Classes Section

The Base Class is the class from which the class is derived i.e. it is the parent class.

Each Base Class entry is a hyperlink to the information for the Base Class.

For example, if you are viewing the CPointDigital class, the Base Class is CSimplePoint—the CSimplePoint is the next branch up from the CPointDigital class in the database hierarchy.

By selecting the Base Class hyperlink, you can view the information for the classes that are higher up in the database hierarchy. This allows you to determine how a class relates to the rest of the classes.

You can view the classes that are lower down in the database hierarchy by selecting one of the Sub-Classes.

Further Information

Classes.


Database Guide - Aggregates Section (Working with the Database Schema)

Aggregates Section

The Aggregates section shows information about the Aggregates of the class. For example, the Aggregates section for the CGenericModbusOSPSTN class shows information about the aggregates of the CGenericModbusOSPSTN database class.

For each aggregate of the class, the following information is shown:

  • Name—The name of the aggregate.
  • Fixed—Each aggregate can be fixed or optional (i.e. can be enabled or disabled).

If the aggregate is fixed, every item of that class has the aggregate.

If the aggregate is optional, then the aggregate can be enabled or disabled for each individual item of the class.

  • Class(es)—Shows the class(es) of the aggregate. For single class aggregates there is one class, and for multiple class aggregates there are several classes (see Aggregates).

Example:

The CSCADAPackMOSDirect class contains the Network aggregate and the PSTN aggregate.

The Classes of the Network aggregate are CSingleNetwork (Single Network) and CDualNetwork (Dual Network).

The Class of the PSTN aggregate is CSCADAPackMPSTN.


Database Guide - Alarm Conditions Section (Working with the Database Schema)

Alarm Conditions Section

The Alarm Conditions section shows information about the Alarm Conditions of the class. For example, the Alarm Conditions section for the CPointAlg class shows information about the alarm conditions that are available to analog points.

For each alarm condition of the class, the following information is shown:

  • Name—The name of the alarm condition. This indicates the type of alarm.
  • Category—Indicates the category for the alarm condition. The category is used internally to group alarm conditions according to their type. In effect, the category acts as a description of the type of alarm that the alarm condition represents. For example, the alarm condition named Digital has a category of Point State. This indicates that the Digital alarm condition relates to the state of a digital point.
  • Sub Conditions—Displays the conditions that can cause the alarm to be raised.

As the Alarm Conditions are of the CAlarm class, they also provide access to the Fields and Methods for the CAlarm class.


Database Guide - Configuration Fields and Data Fields Section (Working with the Database Schema)

Configuration Fields and Data Fields Section

There are two sections that show information about the Fields:

  • Configuration Fields—The Configuration Fields section shows the configuration fields of the class.
  • Data Fields—The Data Fields section shows the data fields of the class i.e. the fields that contain the values that are stored for the items.

The following information is shown for each field:

  • Name—The name of the field.
  • Display Name—The localized name of the field. This is the name that is used in ViewX for column headings in Lists and in List filter and List sorting displays etc.
  • Type—The category of field.

The possible types are:

  • String—The field contains a string of characters with a fixed maximum length. The number in brackets that follows the String entry in the Type column indicates the maximum number of characters permitted (including the NULL terminator).
  • StlString—The field contains a string of characters with no maximum length. The number in brackets after StlString represents a guideline number. This number is only used by standards that have a value for a length limit (such as ODBC), even though the number is not actually the maximum length.
  • Color—The field contains a color value. The color is an Red Green Blue (RGB) 32 Bit integer value.
  • Reference—The field contains the object ID of another item in the database or -1 if it is unused. The class in brackets shows the type of database item that is referenced. This field is a 32-bit unsigned integer.
  • Unsigned Byte—The field contains an 8-bit unsigned integer value.
  • Signed Word—The field contains a 16-bit signed integer value.
  • Unsigned Word—The field contains a 16 bit unsigned integer value.
  • Signed Long—The field contains a 32-bit signed integer value.
  • Unsigned Long—The field contains a 32-bit unsigned integer value.
  • Boolean—The field contains a True/False value.
  • Signed Float—The field contains an IEEE single precision 32-bit real value (floating point value).
  • Signed Double—The field contains an IEEE 64-bit double precision real value (floating point value).
  • Time—The field contains a timestamp value.
  • Variant—The field contains any type of value (database items may have different types of value in Variant fields, for example, one point may have a signed float value and another point may have an integer value).
  • OPC Property—Each field is allocated an OPC property that is shown as a hexadecimal number. The properties are either standard OPC properties or vendor specific properties allocated by Schneider Electric.

The properties allocated by Schneider Electric start at 3505000.

  • Description—A localized description of the field. This is the description that is used in ViewX for ToolTips on Forms, List column headings, OPC Data Explorer etc.
  • Notes—The Notes entries provide additional information about the field.

The possible types of entry for Notes are:

  • Read Only—The field is read-only and cannot be written to.
  • Dynamic Enumeration—The field can be any option within the range of options, and the range of options varies according to the individual database item.
  • Enumeration—This information is only available for numeric fields and string fields.

For numeric fields, the Enumeration is set to one of a set range of options. It has to be one of the options that are listed after the Enumeration entry. The numbers that follow the options indicate the numeric values that correspond to the option.

For example, Enumeration: None (0), Log List (1), Demand List (2) indicates that the options are the values 0, 1, and 2 and these correspond to the options None, Log List, and Demand List respectively.

For string fields, the Enumeration is the actual string value.

  • Enumeration (Bitmask)—This information only applies to integer fields. It is similar to the Enumeration information (above) except that the numbers in brackets indicate a bit of the mask (0 to 'n').
  • Range—The value of the field has to be within a range, for example, is between 0 and 100.
  • Interval—The field contains a value that defines a time interval, for example 10 seconds.

Further Information

Fields.


Database Guide - Methods Section (Working with the Database Schema)

Methods Section

The Methods section shows each of the Methods of the class.

The following information is shown for each method:

  • Name—The name of the method.
  • Descriptions—A localized description of the method.
  • Arguments—Shows the name, type, and localized description of each of the method arguments (or 'None' if there are no arguments).

When you use the Database Schema to view a calculation method, the last argument of the calculation method has a [retval] prefix.

Further Information

Methods.


Database Guide - Display a List of All Database Items in a Specific Class (Working with the Database Schema)

Display a List of All Database Items in a Specific Class

You can use the ClearSCADA Database Schema to link to the Web interface's displays for database items. The list shows the values of each of the fields for the items of the specified class.

To display a list of the database items in a specific class:

  1. Access the Database Schema.
  2. Display information about the required class. For more information, see:
  • Display Information about a Creatable Class.
  • Display Information about All Classes.
  3. Select the List All <Item Type> hyperlink. For example, for the CMimic class, you could select the List All CMimic Objects hyperlink.

When you select a suitable hyperlink, a Filter dialog is displayed. You can use the Filter window to restrict the List so that only certain items are included. The Filter dialog works in the same way as the Filter dialog for Queries Lists (for more information, see the ClearSCADA Guide to Lists).

When you have selected the OK or Cancel button on the Filter Columns window, the list of items is displayed.

The list of items is the result of an SQL Query (this may be filtered or unfiltered, depending on any settings made via the Filter Columns window).

Further Information

Class Information.


Drivers Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Drivers Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Drivers Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Drivers Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Drivers Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Drivers Guide - Document Scope (About the Guide)

Document Scope

This guide provides general information about the types of driver that you can install with ClearSCADA. It explains the basic driver components and describes the types of communications that ClearSCADA supports. Information is provided on how to install the drivers and configure the connection properties that enable ClearSCADA to communicate with devices using those drivers.

The guide also describes the various pick actions and status attributes that are supported by many of the drivers.

For more information, see Welcome to the ClearSCADA Guide to Drivers.


Drivers Guide - Intended Audience (About the Guide)

Intended Audience

The information in this guide is intended for users that need to perform any of the following tasks:

  • Operate and control plant using the drivers supported by ClearSCADA
  • Check an item’s status
  • Configure a channel’s connection properties
  • Install a driver.


Drivers Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Drivers Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Lists

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Security

ClearSCADA Server Automation Technical Reference online Help.


Drivers Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Drivers Guide - Welcome to the ClearSCADA Guide to Drivers

Welcome to the ClearSCADA Guide to Drivers

Welcome to the ClearSCADA Guide to Drivers. ClearSCADA is a feature-rich expandible SCADA system. It comprises ‘core’ software that provides the core server-client functionality and ‘driver’ software that enables ClearSCADA to interface with third-party hardware and software using a wide range of protocols.

For each device with which you want ClearSCADA to communicate using a specific protocol, you need to install the relevant driver. This section summarizes the Types of Driver that you can install on a ClearSCADA system and explains to which guides you should refer for information on those drivers.

It also provides information on the Driver Components you might need to configure in order to represent the devices on your system, and explains the type of communications your system might use (see Master-Slave Communications, and see Direct and PSTN Communications).

The rest of this guide provides information on:

  • How to Set up the Drivers on a New ClearSCADA System
  • How to Add a New Driver to an Existing ClearSCADA System
  • How to Configure a Channel’s Connection Properties
  • Actions that are Common to Many Drivers
  • Status Attributes that are Common to Many Drivers.


Drivers Guide - Types of Driver (Welcome to the ClearSCADA Guide to Drivers)

Types of Driver

Most of the drivers that you can install in ClearSCADA are termed either Simple Driver s or Advanced Driver s, depending on the data-handling ability of the devices with which ClearSCADA is to interface using such a driver. Those advanced drivers that communicate using an open protocol may additionally have one or more Extension Driver s that provide optional application-specific functionality.

A few drivers do not adhere to the simple- or advanced-driver architecture and functionality. Such drivers are termed Stand-Alone Driver s.

In some cases, more than one ClearSCADA driver supports communications via a particular protocol. Where more than one driver can be used, the driver-specific documentation summarizes which driver suits a particular application or system setup.

Be aware that drivers are licensed separately to the core product.

Most drivers enable ClearSCADA to be the SCADA Master. Some drivers enable ClearSCADA to act as an outstation or similar slave device and report a subset of data from the ClearSCADA database to another SCADA Master. For more information, see Master-Slave Communications.


Drivers Guide - Simple Driver (Welcome to the ClearSCADA Guide to Drivers)

Simple Driver

Simple drivers:

  • Enable ClearSCADA to communicate with PLCs and other devices using a permanent direct connection, such as a cable, network, or continuous radio signal (see Systems with Direct Communications).
  • Enable ClearSCADA to poll (scan) those devices for current data (the present state or value of a point at the time that the ClearSCADA server requests such data).
  • Typically use Scanners to poll those devices for data. Each scanner scans a block of points for data.
  • Tend to support a channel/server, scanner, and point architecture (see Driver Components).

For general information on configuring the simple drivers on your system, see the rest of this guide and the ClearSCADA Guide to Simple Drivers.

For driver-specific information, see the relevant driver guide.


Drivers Guide - Advanced Driver (Welcome to the ClearSCADA Guide to Drivers)

Advanced Driver

Advanced drivers:

  • Enable ClearSCADA to communicate with outstations and other devices using a permanent direct connection, such as a cable, network, or continuous radio signal, and/or a dial-up modem to enable communication via the telephone network (PSTN) (see Direct and PSTN Communications).
  • Enable ClearSCADA to poll (scan) those devices for current data (the present state or value of a point) and/or logged data (time stamped data that is stored in the outstation).
  • Tend to support other protocol-specific features, such as file transfer or application program management.
  • Can support downloading of configuration from ClearSCADA to the outstation (via the Download Configuration pick action).
  • Have the ability to support Extension Driver s.
  • Tend to support a channel, set, outstation, and point architecture (see Driver Components).

The way in which each advanced driver scans devices for data differs per driver—for an understanding of each driver’s scanning regime, see the information in the relevant driver guide, and the scanning sections within the ClearSCADA Guide to Advanced Drivers.

Outstations on many advanced drivers have the ability to filter historic data before passing it to the ClearSCADA server, so enabling ClearSCADA to store only those point values that are of interest. (In order for point values to be stored historically in the ClearSCADA database, historic data storage has to be enabled for the relevant point(s) (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).)

For general information on configuring the advanced drivers on your system, see the rest of this guide and the ClearSCADA Guide to Advanced Drivers. For driver-specific information, see the relevant driver guide.


Drivers Guide - Extension Driver (Welcome to the ClearSCADA Guide to Drivers)

Extension Driver

Where a driver communicates using an open protocol, the different devices that can communicate using that protocol may support extra functionality to the core protocol. To enable ClearSCADA to communicate with such devices, some drivers support Extension Drivers—drivers that provide additional vendor-specific functionality, depending on the devices with which the driver is to communicate.

If the devices with which you want ClearSCADA to communicate use an extension driver, you need to ensure that both the extension driver and its ‘parent’ driver are installed.

Be aware that some extension drivers are licensed separately to their ‘parent’ driver.

Where a separate guide exists for an extension driver, you typically use that guide in conjunction with the guide for its ‘parent’ driver.


Drivers Guide - Stand-Alone Driver (Welcome to the ClearSCADA Guide to Drivers)

Stand-Alone Driver

Stand-Alone drivers are those drivers that tend not to adhere to the simple or advanced driver model. Such drivers include the Crystal Reports driver.

For information on such drivers, see the relevant driver guide and the rest of this guide.


Drivers Guide - Driver Components (Welcome to the ClearSCADA Guide to Drivers)

Driver Components

This section summarizes the various components that many drivers support and the types of device that those components represent. The components comprise:

  • Channels
  • Scanners
  • Outstations and Outstation Sets
  • Points and Pulse Actions.

For other components not listed above, see the relevant driver guide.


Drivers Guide - Channels (Welcome to the ClearSCADA Guide to Drivers)

Channels

The ClearSCADA server runs drivers, many of which communicate with outstations and similar devices via Channels. Depending on the system setup, a channel will use one of these types of communication:

  • Direct—Allows the ClearSCADA server to communicate with outstations (or similar devices) via a ‘permanent’ connection, via, for example, a cable link, radio link, or microwave link (see Systems with Direct Communications).
  • PSTN—Allows the ClearSCADA server to communicate with outstations or similar devices via the telephone network (see Systems with PSTN Communications).

For PSTN communications, the ClearSCADA server and outstations are connected to dial-up modems. The modems connect to the telephone network.

Each channel is represented in the ClearSCADA database by a Channel database item. You need to add and configure the type of channel that corresponds to the type of protocol and communications being used by your system. You can perform actions on channels via pick action menus (also referred to as context sensitive menus).

Channels are represented by channel database items.

Further Information

For information on configuring specific types of channel, see the relevant driver guide.

For general information on configuring channels, see the following:

  • Simple Driver Channels: see Configuring Channels on Simple Drivers in the ClearSCADA Guide to Simple Drivers
  • Advanced Driver Channels: see Configuring a Channel in the ClearSCADA Guide to Advanced Drivers
  • Configure a Channel’s Connection Properties.

Actions Associated with Channels on Simple Drivers.

Actions Associated with Channels on Advanced Drivers.


Drivers Guide - Scanners (Welcome to the ClearSCADA Guide to Drivers)

Scanners

Many Simple Drivers use Scanners to define how points are scanned (polled) for data using a particular protocol. For more information, see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers.

As with other database items, you can perform actions on scanners via pick action menus (also referred to as context sensitive menus). For more information, see Actions Associated with Scanners on Simple Drivers.


Drivers Guide - Outstations and Outstation Sets (Welcome to the ClearSCADA Guide to Drivers)

Outstations and Outstation Sets

Outstations, PLCs and other similar devices are enclosed units that typically contain I/O cards, communications equipment, and a power supply. The I/O cards contain inputs and outputs that correspond to the connections to plant.

The devices receive signals from the measuring instruments at the plant and then send the data to the ClearSCADA server upon request. They can also receive controls from the ClearSCADA server. The controls from the ClearSCADA server are processed and, if required, are sent to control instruments to operate plant. The ClearSCADA server requests data from the devices at regular intervals and stores the data it receives in the ClearSCADA database.

With Advanced Drivers, each outstation (or other similar device) is represented in the ClearSCADA database by an Outstation item. You need to add and configure the type of outstation that corresponds to the type of protocol, communications, and device with which ClearSCADA is to communicate.

Outstations, PLCs, data loggers, and so on, are represented by outstation items in the database.

In the ClearSCADA database, you group outstations into Outstation Sets. A Direct Outstation Set contains outstations that use the same protocol and share the same direct Channels. A PSTN Outstation Set contains outstations that communicate using a dial-up modem and that, for example, are in the same geographical region.

You can perform actions on outstations and outstation sets via pick action menus (also referred to as context sensitive menus).

Each outstation contains inputs and/or outputs. The inputs are used to receive data from plant, whereas the outputs are used to send controls to plant. Each input and output corresponds to a Point in the database, with one or more points being used to represent each item of plant (see Points and Pulse Actions).

NOTE: Simple drivers tend to support a channel/server, scanner, and point architecture. For more information on the database items that you need to configure for such an architecture, see the relevant sections in this guide and in the ClearSCADA Guide to Simple Drivers.

Further Information

For information on configuring specific types of outstation set and outstation, see the relevant driver guide.

For general information on outstation sets, outstations and their configuration, see the ClearSCADA Guide to Advanced Drivers.

Actions Associated with Outstation Sets on Advanced Drivers

Actions Associated with Outstations on Advanced Drivers.


Drivers Guide - Points and Pulse Actions (Welcome to the ClearSCADA Guide to Drivers)

Points and Pulse Actions

ClearSCADA uses Points to represent the inputs and outputs in an outstation or similar device. In the database, the values that the outstations receive from plant are stored in input points and the values (controls, and so on) that are sent from ClearSCADA to the plant are stored in output points.

For each input and output, you need to add and configure the type of point that corresponds to the type of protocol and data that ClearSCADA is to read or write from plant.

You configure Pulse Actions to represent those items of plant that you only want to control for brief periods of time (as opposed to output points for those items for which the controlled state is to be maintained).

By performing actions on points and pulse actions, you can interact with the plant. For example, by controlling the state of a digital output point that represents a valve, you could open or close the valve.

The following tables show examples of how points are used in some industries:

Oil, Gas and Petrochemical Pipelines
Digital Input Points | Analog Input Points | Digital Output Points | Analog Output Points | Counters
Valve status | Flow level | Valve open/close | Variable valve position | Flow meters
Pump status | Pressure level | Pump start/stop |  |
PIG detection | Density level | PIG launch |  |
Local/Remote Mode | Temperature | Pipeline shutdown |  |
Leak Detected | Tank level indicator |  |  |
Pipe shut-in status | Mass flow rate |  |  |
Batch launched | Leak size |  |  |
Batch arrived | Leak location |  |  |
 | Batch size |  |  |
 | Flow profile |  |  |
 | Pressure profile |  |  |
 | Temperature profile |  |  |
 | Pipeline efficiency |  |  |
 | Instrument accuracy |  |  |
Entries in italics are generated by third party Leak Detection software. ClearSCADA uses computed digital input points and computed analog input points to represent these items.

Oil and Gas Gathering and Production
Digital Input Points | Analog Input Points | Digital Output Points | Analog Output Points | Counters
Valve status | Inlet/Outlet pressure | Valve open/close | Variable valve position | Flow meters
PIG detection | Temperature level | PIG launch |  |
 | Pressure level |  |  |
 | Flow rate |  |  |
 | Energy flow rate |  |  |
 | Gross calorific value |  |  |
 | Mass flow rate |  |  |

Water Treatment
Digital Input Points | Analog Input Points | Digital Output Points | Analog Output Points | Counters
Valve status | Inlet tank level |  |  | Flow meters
Pump status | Inlet flow rate |  |  |
Air blower status | Turbidity level |  |  |
Centrifuge status | Chlorine level |  |  |
Power supply status | pH level |  |  |
 | Clean/dirty tank level |  |  |
 | Sludge tank level |  |  |
 | Carbon level/ dosage |  |  |
 | Aluminum level |  |  |
 | Sulfuric acid level/dosage |  |  |
 | Phosphoric acid level/dosage |  |  |
 | Lime level/ dosage |  |  |

Flood Forecasting and Environment
Digital Input Points | Analog Input Points | Digital Output Points | Analog Output Points | Counters
Penstock status | Weir level |  |  |
Valve status | Rain gauge |  |  |
Pump status | River level |  |  |
Intruder alarm | River temperature |  |  |
Power supply status |  |  |  |

Power Generation and Distribution
Digital Input Points | Analog Input Points | Digital Output Points | Analog Output Points | Counters
Phase indication | Input/output voltages |  |  |
 | Input/output current |  |  |

Further Information

For information on configuring specific types of point and pulse action, see the relevant driver guide.

For general information on points, pulse actions and their configuration, see the ClearSCADA Guide to Core Point Configuration.

Actions Associated with Points.

Actions Associated with Pulse Actions.


Drivers Guide - Master-Slave Communications (Welcome to the ClearSCADA Guide to Drivers)

Master-Slave Communications

Most drivers enable ClearSCADA to be the SCADA Master. When the ClearSCADA server is the master, ClearSCADA initiates and controls the transmissions to and from the other devices on the system. (The exception to this being any outstation that has the ability to send unsolicited messages to ClearSCADA, to inform the server of any new alarms that have been generated at that outstation.) When ClearSCADA is the master, any sensors or control devices are represented by points in the ClearSCADA database. The driver-specific documentation specifies which type(s) of point are supported by each driver and explains how to configure those points. For general information on points, see the ClearSCADA Guide to Core Point Configuration.

Some drivers enable ClearSCADA to be a Slave. When ClearSCADA is a slave, the server acts like an outstation and reports any changes to another SCADA master. The SCADA master may be another ClearSCADA server, or a third-party server. When ClearSCADA is a slave, any ‘point’ data is mapped into a simple block of memory in the driver, using a Value Map or Filtered Value Map (see Configuring Value Maps in the ClearSCADA Guide to Core Configuration). The driver-specific documentation specifies which type(s) of Value Map and/or Filtered Value Map a particular slave driver supports.

If a ClearSCADA driver is a slave driver, the word ‘Slave’ is included in the driver name. Drivers that do not include the word ‘Slave’ in their name typically enable ClearSCADA to be the SCADA Master.

With any ClearSCADA driver, refer to the driver-specific documentation for information on which database items you need to configure in ClearSCADA, in order for ClearSCADA to be either the SCADA Master or a Slave.

Be aware that it is possible for ClearSCADA to be both a SCADA Master and a Slave, if both master and slave ClearSCADA drivers are installed on a system.

The diagrams in the remainder of this section demonstrate each of the above setups:

  • ClearSCADA Configured as a SCADA Master
  • ClearSCADA Configured as a SCADA Slave
  • ClearSCADA Configured as both a SCADA Master and a SCADA Slave.

Be aware that these diagrams are very simplified versions of each system—a ClearSCADA system typically comprises one or more servers (of which one will be ‘Main’) and multiple ViewX and/or WebX clients (user workstations). For more information, see Understanding Your System in the ClearSCADA Guide to ViewX and WebX clients. For more information on server setups, see System Architectures in the ClearSCADA Guide to Server Administration.

Further Information

Set up the Drivers on a New ClearSCADA System.

Add a New Driver to an Existing ClearSCADA System.


Drivers Guide - ClearSCADA Configured as a SCADA Master (Welcome to the ClearSCADA Guide to Drivers)

ClearSCADA Configured as a SCADA Master

With most ClearSCADA drivers, ClearSCADA is the SCADA Master. With such a setup, the ClearSCADA server retrieves the data from its outstations, PLCs and other devices using the appropriate protocol.

For each protocol that ClearSCADA is to use to retrieve data and/or control plant, you need to install the appropriate ClearSCADA driver on your system. You can run any number of ClearSCADA drivers on your system, however for optimum performance, we advise that you only install those drivers that you require.

In order for ClearSCADA to retrieve data and control plant using a protocol that is recognized by the devices on your system, you need to install the appropriate master driver(s).


Drivers Guide - ClearSCADA Configured as a SCADA Slave (Welcome to the ClearSCADA Guide to Drivers)

ClearSCADA Configured as a SCADA Slave

Where a third-party server uses a particular protocol to retrieve data from ClearSCADA, the ClearSCADA system acts as a Slave outstation. For this scenario, you need to install and run the appropriate ClearSCADA slave driver on your ClearSCADA system.

In order for a third-party server (or another ClearSCADA server) to retrieve data from and/or control points on the local ClearSCADA server, you need to install the appropriate slave driver(s) on your system.

This setup can also be used to enable one ClearSCADA system to communicate with another ClearSCADA system, in a hierarchical structure.


Drivers Guide - ClearSCADA Configured as both a SCADA Master and a SCADA Slave (Welcome to the ClearSCADA Guide to Drivers)

ClearSCADA Configured as both a SCADA Master and a SCADA Slave

On some systems, ClearSCADA is both a SCADA Master and a Slave outstation. Installation of the appropriate ClearSCADA Slave driver enables a third-party server to use a particular protocol to obtain data from ClearSCADA. Additionally, installation of the appropriate ClearSCADA (master) driver(s) enables the ClearSCADA server to use the appropriate protocol(s) to retrieve data from and/or control points on outstations and/or PLCs.

This type of system setup might be required, for instance, if a system has a hierarchical structure whereby ClearSCADA and/or a third-party server provides control and monitoring features for different subsets of data.

Install the appropriate slave driver to enable another server to obtain data from ClearSCADA...
...and install the appropriate master driver(s), to enable ClearSCADA to retrieve data and control plant via the outstations or slave sources on your system.


Drivers Guide - Direct and PSTN Communications (Welcome to the ClearSCADA Guide to Drivers)

Direct and PSTN Communications

This section explains the concepts of the basic types of communications that your ClearSCADA system might use—one system uses direct communications and another system uses a telephone network for communications.

Most systems are structured to meet the needs of your organization and so they may differ to the architectures described in this section. By learning about the following types of system, you can begin to familiarize yourself with ClearSCADA and how it works as part of a Supervisory Control and Data Acquisition (SCADA) system:

  • Systems with Direct Communications
  • Systems with PSTN Communications.


Drivers Guide - Systems with Direct Communications (Welcome to the ClearSCADA Guide to Drivers)

Systems with Direct Communications

Most drivers enable ClearSCADA to communicate with outstations and other devices using a permanent direct communications connection.

To understand the basic concepts of a system with direct communications, you need to appreciate the role of each part of the system. This section explains the basics, beginning with the client PC on which you interact with ClearSCADA.

ClearSCADA Client PCs have network connections to a ClearSCADA server. The ClearSCADA Server stores the database and communicates with equipment such as outstations and PLCs. The outstations communicate with the instruments that monitor and control plant. The client PCs interact with plant via the ClearSCADA server and the outstations (see Outstations and Outstation Sets).

NOTE: The term ‘outstation’ is used throughout much of the ClearSCADA documentation as a generic term for devices, such as outstations, RTUs, PLCs, and Data Loggers, that obtain data from measuring instruments or sensors.

Your client PC can either run ViewX (see ViewX Client in the ClearSCADA Guide to ViewX and WebX Clients) or use WebX in a browser (see WebX Client in the ClearSCADA Guide to ViewX and WebX Clients). It uses ViewX or WebX to interact with the ClearSCADA system. When you perform an action or issue a control from a client, the control data is sent from your PC to the ClearSCADA server. Depending on the type of action, the ClearSCADA server either performs the action within the database or sends the data to the outstations.

With direct communications, the ClearSCADA server communicates with the outstations via direct channels (see Channels). This means that there is a continuous connection between the ClearSCADA server and the outstations (see Outstations and Outstation Sets). The direct connections can use cables that are physically attached to the ClearSCADA server and the outstations, or they can be some other form of communications media, such as radio.

Most instruments report a signal to an outstation continuously. The outstation stores a sample from the signal which is then sent to the ClearSCADA server upon request. The ClearSCADA server processes the signal and stores the values in the database.

When an outstation receives a control, it processes the data and sends a signal to an instrument that is connected to the plant. The instrument then operates the plant—for example, a signal could instruct an instrument to close a valve or activate a power on/off switch. (On some systems, the instruments are the plant.)

The database uses points to correspond to the inputs and outputs on an outstation. The inputs receive data from the plant and the outputs send data to the plant. Any values sent to or received from an outstation are stored within the corresponding point item in the database (see Points and Pulse Actions).

NOTE: On most systems, ClearSCADA will be configured to instigate communications with any direct outstations whenever required. On some systems, the communications availability might be restricted on some direct outstations. For example, communications might be limited to Incoming Only (whereby the outstation instigates all communications with ClearSCADA), or Periodic (whereby communications with the outstation is only available for a limited period). For more information, see Specify the Availability of Communications Between the Outstation and ClearSCADA in the ClearSCADA Guide to Advanced Drivers.


Drivers Guide - Systems with PSTN Communications (Welcome to the ClearSCADA Guide to Drivers)

Systems with PSTN Communications

Many Advanced Drivers and some Stand-Alone Drivers enable ClearSCADA to communicate with outstations and other devices using a dial-up modem to enable communication via the telephone network. In some cases, outstations that usually use a permanent direct communications connection can ‘fall back’ to using a dial-up modem should ClearSCADA detect that the direct channel(s) have failed (see Outstation Types and Communications Set-ups in the ClearSCADA Guide to Advanced Drivers).

To understand the basic concepts of systems that use Public Switched Telephone Network (PSTN) communications, you need to appreciate the role of each part of the system. In this section, we will explain the basics, beginning with the client PC on which you interact with ClearSCADA.

ClearSCADA Client PCs have network connections to a ClearSCADA server that stores the database. The ClearSCADA Server communicates with the outstations via PSTN. The outstations communicate with the instruments that monitor and control plant. So, the client PCs interact with plant via the ClearSCADA server and the outstations (see Outstations and Outstation Sets).

NOTE: The term ‘outstation’ is used throughout much of the ClearSCADA documentation as a generic term for devices, such as outstations, RTUs, PLCs, and Data Loggers, that obtain data from measuring instruments or sensors.

Your client PC can either run ViewX (see ViewX Client in the ClearSCADA Guide to ViewX and WebX Clients), or use WebX in a browser (see WebX Client in the ClearSCADA Guide to ViewX and WebX Clients). It uses ViewX or WebX to interact with the ClearSCADA system. When you request an action or issue a control from a client, the control data is sent from your PC to the ClearSCADA server. Depending on the type of action, the ClearSCADA server either performs the action within the database or establishes a PSTN connection with the relevant outstation. When the PSTN connection is established, the ClearSCADA server sends the data to the relevant outstation(s).

With PSTN communications, the ClearSCADA server communicates with the outstations via PSTN channels (see Channels and see Outstations and Outstation Sets). This means that the ClearSCADA server and the outstations use dial-up modems to communicate via a telephone network.

A communication connection is only made when the dial up process is initiated, either from the ClearSCADA server or from the outstation. This means that there is not a continuous communications connection—the outstations and ClearSCADA server can only communicate when a successful dial up has occurred.

As the outstations in a PSTN-based arrangement are not in continuous communications with the ClearSCADA server, they store data so that it can be reported when a connection is established.

When there is no connection between the ClearSCADA Server and the outstations, the outstations store the data from plant.
When a connection is made, the outstations can report to the ClearSCADA Server via the telephone network. Similarly, the ClearSCADA server can send data to the outstations.
Connection is scheduled or made upon request.
No connection as communications are not scheduled or requested manually.

When an outstation receives a control, it processes the data and sends a signal to the instrument that is connected to the plant. The instrument then controls the plant, for example, a signal could instruct a valve to close or could activate a power on/off switch. (On some systems, the instruments are the plant.)

Typically, the instruments continuously report measurements to the outstations. The outstation stores the measurements until a communications connection is established (either by the outstation or by the ClearSCADA server). The measurement is then sent to the ClearSCADA server where it is processed and stored in the database.

The database uses points to represent each outstation’s inputs and outputs. The inputs receive the signals from the plant, and the outputs send data to the plant. Any values sent to or received from an outstation are stored within the corresponding database point (see Points and Pulse Actions).

Further Information

For more information, see Retrieving Data from PSTN Outstations in the ClearSCADA Guide to Advanced Drivers.


Drivers Guide - Set up the Drivers on a New ClearSCADA System

Set up the Drivers on a New ClearSCADA System

This section is for system administrators that are installing drivers on a new ClearSCADA system. This section is specific to driver installation—for information on installing and setting up other aspects of ClearSCADA, see the ClearSCADA Guide to Server Administration, the ClearSCADA Guide to Client Administration, and the ClearSCADA Guide to Core Configuration.

To install and configure the drivers on a new ClearSCADA system:

  1. Ensure that your system has a valid license for each driver that you want to run. (Use the License Details window to check whether a valid driver license exists—see Server License Settings in the ClearSCADA Guide to Server Administration.)
  2. Use the ClearSCADA Installation Wizard to select the driver component(s) that you need to install (see Install a Driver in ClearSCADA).
  3. Use the ClearSCADA Server Configuration Tool to Specify the Common Driver Settings.
  4. Configure any driver-specific server settings. (Not all drivers have server settings that are driver-specific—the relevant driver guide will summaries any settings that do exist.)
  5. Add the various driver-specific items—channels, points, and so on—to your system and configure those items in the database (see the relevant driver guide and, if applicable, see Configure a Channel’s Connection Properties).

If relevant, consider using the Automation Interface to import existing system configuration from another source, such as a database spreadsheet.

Also consider using Group Templates and Group Instances to replicate like areas of database configuration (see Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration).

Remember that by default, ClearSCADA does not store point data historically—if you want ClearSCADA to store data historically for a particular point, you need to enable Historic on the configuration Form for that point (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

  6. If required, specify the alarm conditions for which any point types are to have Multiple Point State Alarms. (For information on this feature, see Multiple Point State Alarms in the ClearSCADA Guide to Core Point Configuration. For information on setting up multiple point state alarms, see Point State Alarms in the ClearSCADA Guide to Server Administration.)
  7. Set up the required security for the newly added driver items (see the ClearSCADA Guide to Security).

(Remember that security permissions are assigned on a per item/per group basis, whereas access to the various features and functions is assigned on a per user/per user group basis.)

Further Information

Database Configuration: see Organizing and Configuring Your Database in the ClearSCADA Guide to Core Configuration.

Automation Interface: see the online Server Automation technical reference.


Drivers Guide - Install a Driver in ClearSCADA (Set up the Drivers on a New ClearSCADA System)

Install a Driver in ClearSCADA

On each of the servers on your system (including permanent standby servers), you need to install the driver-specific Server component(s). You use the ClearSCADA Installation Wizard to specify the driver component(s) that you want to install.

On a Hot-Standby system, you should install the new driver on the standby server(s) first, followed by the server that is running as the main server. This enables the system to be ‘live’ for as much time as possible during the installation process. (A standby server can have more drivers installed than the main server and still be able to synchronize with the main. However, a main server that has more drivers installed than the standby server(s) will not be able to synchronize with those server(s) and as such, the system would need to be down for longer.)

To install the relevant driver components on each server using the ClearSCADA Installation Wizard:

  1. Ensure that the server is shut down (see Stop the ClearSCADA Server in the ClearSCADA Guide to Server Administration).
  2. Run the ClearSCADA Installation Wizard.
  3. Expand the Server branch of the tree that is displayed in the Setup window.
    Expand the Server branch...
    ...in order to display a list of the driver components that you can install on your system.

  4. Within the Server branch, either:
  • Choose to install the component that represents the driver that you want to install.
    (For instance, install the DNP3 server component, if your servers are to run the DNP3 driver.)

Or:

  • To install an Extension Driver, expand the entry that represents the extension driver’s ‘parent’ driver, then choose to install both the extension driver component and the ‘parent’ driver component.

As with any ClearSCADA component that you want to install, you click on the icon that represents that component, to display a set of options. You then choose to either install just that component, or the entire feature (the component and any ‘child’ components).

Any icon that displays a red cross indicates a component that will not be installed.

  5. With a few drivers, you need to install other component(s) in addition to the above component(s). Where such components are required, the driver-specific documentation summarizes such requirements.
  6. Repeat steps 4 and 5 for any other drivers that you want to install.
  7. Restart the server (see Start the ClearSCADA Server in the ClearSCADA Guide to Server Administration).
  8. Repeat the above steps on the other servers on your system. (On a Hot-Standby system, once you have installed the new driver(s) on a standby server, bring that server back online and synchronize it with the main server. Repeat the above steps with any other standby servers, then perform a manual changeover to upgrade one of the standby servers to main. Following this, install the driver(s) on the machine that was previously main, then bring that server back online.)

Further Information

System Architectures in the ClearSCADA Guide to Server Administration.

Synchronization Process for Multi Server Architectures in the ClearSCADA Guide to Server Administration.

Perform a Manual Changeover on a Multi-Server System in the ClearSCADA Guide to Server Administration.


Drivers Guide - Use the ClearSCADA Server Configuration Tool to Specify the Common Driver Settings (Set up the Drivers on a New ClearSCADA System)

Use the ClearSCADA Server Configuration Tool to Specify the Common Driver Settings

ClearSCADA is supplied with a set of defaults, which determine the way in which the system functions, and the way in which data is processed and displayed. This includes various settings that affect the drivers that you install on your system. Some of these settings affect multiple drivers, whereas other settings are driver-specific. If required, many of these settings can be changed from the defaults.

Settings that affect more than one driver should be specified on each server when
a ClearSCADA system is first installed. This section summarizes the driver-related server settings that apply to multiple drivers. The settings are configured using the ClearSCADA Server Configuration Tool. For information on using the tool, see Working with the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration.

You can use the ClearSCADA Server Configuration Tool to specify:

  • The Channels settings (see Channel Settings in the ClearSCADA Guide to Server Administration).
  • The Drivers settings, including various timeouts and the Value Map scanning interval (see Driver Settings in the ClearSCADA Guide to Server Administration).

The Drivers section also includes the setting that controls whether users can postpone certain pick action requests on PSTN and direct ‘On Demand’ outstations. If the feature is enabled, a Queue check box is displayed on certain pick action windows (see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations).

  • The Historic Data settings, including the amount of time for which any historic data is retained online (see Historic Data Storage Settings in the ClearSCADA Guide to Server Administration).
  • The Outstations settings, including the default dial out promotion settings (see Outstation Settings in the ClearSCADA Guide to Server Administration).
  • The Points settings, including the window for valid time stamps (see Points Settings in the ClearSCADA Guide to Server Administration).

In addition to the above, several drivers have driver-specific server settings. You configure these settings on the relevant <Driver Name> section. Each of the <Driver Name> sections are located within the Global Parameters branch of the ClearSCADA Server Configuration Tool. Not all drivers have server settings that are driver-specific—the relevant driver guide will summaries any settings that do exist.


Drivers Guide - Add a New Driver to an Existing ClearSCADA System

Add a New Driver to an Existing ClearSCADA System

This section is for system administrators that are installing a new driver on a system on which other drivers are already installed.

When adding a new driver to an existing ClearSCADA system, you need to:

  1. Ensure that your system has a valid license for the new driver. (Use the License Details window to check whether a valid driver license exists—see Server License Settings in the ClearSCADA Guide to Server Administration.)
  2. Use the ClearSCADA Installation Wizard to select the driver component(s) that you need to install (see Install a Driver in ClearSCADA).

Remember that if you are installing an Extension Driver, you also need to ensure that its ‘parent’ driver is installed and suitably licensed.

  3. Configure any driver-specific server settings for the new driver. (Not all drivers have server settings that are driver-specific—the relevant driver guide will summaries any settings that do exist.)
  4. Add the various driver-specific items—channels, points, and so on—to your system and configure those items in the database (see the relevant driver guide and, if applicable, see Configure a Channel’s Connection Properties).

(Remember that by default, ClearSCADA does not store point data historically—if you want ClearSCADA to store data historically for a particular point, you need to enable Historic on the configuration Form for that point (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).)

  5. If required, specify the alarm conditions for which any new point types are to have Multiple Point State Alarms. (For information on this feature, see Multiple Point State Alarms in the ClearSCADA Guide to Core Point Configuration. For information on setting up multiple point state alarms, see Point State Alarms in the ClearSCADA Guide to Server Administration.)
  6. Set up the required security for the newly added driver items (see the ClearSCADA Guide to Security).

(Remember that security permissions are assigned on a per item/per group basis, whereas access to the various features and functions is assigned on a per user/per user group basis.)

Further Information

Set up the Drivers on a New ClearSCADA System.


Drivers Guide - Configure a Channel's Connection Properties

Configure a Channel’s Connection Properties

Many of the drivers that you can install in ClearSCADA use Channels. You use the Channel database items to represent the communication lines through which information is passed between the ClearSCADA server and the devices with which ClearSCADA communicates using each driver’s protocol.

The channels on many drivers can be used to represent Serial communications (see Configure a Channel’s Serial Connection Properties).

The name of the tab on which you configure a channel’s connection properties varies, depending on the type of driver and channel.

Channels on some drivers provide a choice of Connection Type, enabling you to select the type of communications that the channel represents (see Configure a Channel’s Connection Type).

With many connection types, you need to specify a series of connection-specific properties on the channel’s configuration Form. The actual tab on which you configure the connection properties varies, depending on the type of channel and driver. Such properties might be available, for example, on a Connection, Primary Port, and/or Secondary Port tab. The latter tabs are only available on simple driver channels that support communication using either of two ports (Primary and Secondary)—see Enable or Disable a Secondary Port in the ClearSCADA Guide to Simple Drivers.

The rest of this section explains how to:

  • Configure a Channel’s Connection Type
  • Configure a Channel’s Serial Connection Properties
  • Configure a Channel’s Remote Serial Connection Properties
  • Configure a Channel’s TCP/IP Connection Properties
  • Configure a Channel’s Network Connection Properties.


Drivers Guide - Configure a Channel's Connection Type (Configure a Channel's Connection Properties)

Configure a Channel’s Connection Type

With a channel that can represent one of several types of communications, you need to specify the required type using the Connection Type field. The field is displayed at the top of the relevant tab on the channel’s configuration Form:

The actual Connection Type options vary, depending on the type of channel. They typically comprise a combination of these options:

  • Serial—Select this option if the channel is to represent an RS-232 or RS-485 type connection between ClearSCADA and your communications equipment.

If a channel has a Serial connection, you need to Configure a Channel’s Serial Connection Properties.

  • Remote Serial—ClearSCADA includes an application called a ‘Port Server’ that can provide remote access to serial ports, or allow modem or port sharing (see Set up a Port Server in the ClearSCADA Guide to Server Administration). In order to provide any of the above, port server software has to be installed on the relevant ClearSCADA server or remote PC.

If you are using a port server to:

  • Provide ClearSCADA with exclusive access to a remote computer’s serial ports
  • Allow modem sharing (PSTN channels)
  • Allow port sharing (Direct channels)

use a channel with a Remote Serial connection to communicate via the ClearSCADA server or remote PC that is running the port server software. Use a Remote Serial connection for a Dynamically Assigned Port setup.

If a channel has a Remote Serial connection, you need to Configure a Channel’s Remote Serial Connection Properties.

  • TCP/IP—Use a channel with a TCP/IP connection to provide a point-to-point connection to a single network-connected device, such as a network attached serial converter. You can use a TCP/IP connection to:
  • Provide a point-to-point TCP/IP connection to a protocol converter device, such as a network-to-serial device, or a radio base station.
  • Use ClearSCADA with a Static Port Server port (see Port Server on Remote Computer for Remote Access to Serial Ports in the ClearSCADA Guide to Server Administration).
  • Provide a point-to-point TCP/IP connection to another device, such as a relay-type device.
  • Provide a one-to-one TCP/IP connection to a single outstation. You might use a TCP/IP connection, for example, to connect ClearSCADA to an outstation which itself is a router to other outstations.

If an advanced driver channel has a TCP/IP connection, you need to Configure a Channel’s TCP/IP Connection Properties. (Channels that represent TCP/IP communications on simple drivers typically have no other TCP/IP connection-specific properties.)

  • Network—Use an advanced driver channel with a Network connection to communicate with multiple network-connected devices.

Network channels typically comprise a series of point-to-point connections (usually one per outstation) that are independent of each other. ClearSCADA scans the outstations sequentially, in the same way as a multidrop serial channel scans its outstations. Where several outstations have the same IP address, their network connections can be merged so that they use a single connection.

If a channel has a Network connection, you need to Configure a Channel’s Network Connection Properties.

Networking does not apply to PSTN outstations.

  • None—This option is only available for simple driver channels that support communication using either of two ports. The option is available from the Channel Form’s Secondary Port tab. Select this option if the secondary port is not used.

For any connection types that are not listed above, see the relevant driver guide.


Drivers Guide - Configure a Channel's Serial Connection Properties (Configure a Channel's Connection Properties)

Configure a Channel’s Serial Connection Properties

For a channel to represent a Serial connection, ensure that the channel’s Connection Type field (if displayed) is set to ‘Serial’. (The Connection Type field is only displayed for channels that support a choice of connection types—see Configure a Channel’s Connection Type.)

Configure the required connection properties using the fields that are displayed on the rest of the tab. Channels that represent Serial connections have a combination of these fields:

  • Port—Use to define the physical port to which the line represented by the channel is connected. For example, COM1.

Select the browse button to display a Reference browse window and then select the required port from the window.

If you are using an advanced driver channel to eavesdrop both Rx and Tx communications on a system, you need to enter both ports in this field. Ensure that you specify the Rx port first, using the format <Rx port>, <Tx port>. For example COM1,COM2 where COM1 is the receiving port, and COM2 the transmitting port. For more information on eavesdropping, see Using Eavesdropping to Test a New Server’s Configuration in the ClearSCADA Guide to Advanced Drivers.

  • Baud Rate—Use to define the speed of data transfer to be used by the channel. This has to match the Baud Rate that is supported by your communications equipment.

Specify a baud rate that corresponds with the baud rate of the communications equipment that is connected to the selected port. Either use the combo box to select a baud rate from the supplied list, or enter the required rate directly in the field. If the operating system, serial port drivers and hardware cannot implement the specified baud rate, the operating system or serial port hardware (UART) may automatically use the nearest supported baud rate to that specified.

  • Data Bits—Select the number of bits that is used to transmit and receive each byte of data. This has to match the Data Bits configuration of your communications equipment (see Data Bits and Stop Bits).
  • Parity—Use to define how the Parity bit is set when Parity error checking is supported. This has to match the Parity setting of your communications equipment (see Parity).
  • Stop Bits—Select the number of stop bits in each byte. The number of Stop Bits defines the number of bits that are placed between each character in the transmitted and received data. This setting has to match the Stop Bits configuration of your communications equipment (see Data Bits and Stop Bits).
  • Flow Control—Use to select the type of Flow Control that is supported by your communications equipment. Flow Control is a feature that allows a 'receiving' device to temporarily stop the 'sending' device from transmitting any more data (see Flow Control).
  • Pre-message RTS Delay—Applies to Manual Flow Control only. Use to define the amount of time (in milliseconds) that ClearSCADA waits between instructing the operating system to assert the RTS signal and transmitting the data (see Flow Control).
  • Abort Pre-message Delay if CTS Raised—Applies to Manual Flow Control only. Does not apply to channels on simple drivers. Use this field to define whether ClearSCADA is to abort the Pre-message RTS Delay when the 'receiving' communications equipment asserts the CTS signal (see Flow Control).
  • Post-message RTS Delay—Applies to Manual Flow Control only. Does not apply to channels on simple drivers. Use this field to define the amount of time (in milliseconds) that ClearSCADA waits between sending the message data and instructing the operating system to lower the RTS signal (see Flow Control).

For further information on the settings required for your communications equipment, see the manufacturer’s documentation.


Drivers Guide - Configure a Channel's Remote Serial Connection Properties (Configure a Channel's Connection Properties)

Configure a Channel’s Remote Serial Connection Properties

For a channel to represent a Remote Serial connection, ensure that the channel’s Connection Type field (if displayed) is set to ‘Remote Serial’. (The Connection Type field is only displayed for channels that support a choice of connection types—see Configure a Channel’s Connection Type.)

Configure the required connection properties using the fields that are displayed on the rest of the tab. Channels that represent Remote Serial connections have a combination of these fields:

  • Node Name—Use to specify the name of the port server host (the ClearSCADA server or remote machine that is running the Port Server application software).

To specify the current main server, enter localhost.

To specify a remote machine, use the browse button adjacent to the field to display a Reference browse window. Select the remote machine from the window.

  • Port—Enter the name of the port to which the channel is connected on the machine that is running the Port Server application software. For example, COM1.
  • Shared—Select this check box for the Port Server software to:
  • Allow multiple PSTN channels to share a single dial-up modem (see Port Server for Modem Sharing in the ClearSCADA Guide to Server Administration).
  • Allow multiple direct channels to share a single port (see Port Server for Port Sharing in the ClearSCADA Guide to Server Administration). Port sharing is only supported by some drivers.

Ensure that the check box is clear if the port is to be used by this channel only.

  • Baud Rate—Use to define the speed of data transfer to be used by the channel. This has to match the Baud Rate that is supported by your communications equipment.

Specify a baud rate that corresponds with the baud rate of the communications equipment that is connected to the selected port. Either use the combo box to select a baud rate from the supplied list, or enter the required rate directly in the field. If the operating system, serial port drivers and hardware cannot implement the specified baud rate, the operating system or serial port hardware (UART) may automatically use the nearest supported baud rate to that specified.

  • Data Bits—Select the number of bits that is used to transmit and receive each byte of data. This has to match the Data Bits configuration of your communications equipment (see Data Bits and Stop Bits).
  • Parity—Use to define how the Parity bit is set when Parity error checking is supported. This has to match the Parity setting of your communications equipment (see Parity).
  • Stop Bits—Select the number of stop bits in each byte. The number of Stop Bits defines the number of bits that are placed between each character in the transmitted and received data. This setting has to match the Stop Bits configuration of your communications equipment (see Data Bits and Stop Bits).
  • Flow Control—Use to select the type of Flow Control that is supported by your communications equipment. Flow Control is a feature that allows a 'receiving' device to temporarily stop the 'sending' device from transmitting any more data (see Flow Control).
  • Pre-message RTS Delay—Applies to Manual Flow Control only. Use to define the amount of time (in milliseconds) that ClearSCADA waits between instructing the operating system to assert the RTS signal and transmitting the data (see Flow Control).

For further information on the settings required for your communications equipment, see the manufacturer’s documentation.


Drivers Guide - Configure a Channel's TCP/IP Connection Properties (Configure a Channel's Connection Properties)

Configure a Channel’s TCP/IP Connection Properties

For a channel to represent a TCP/IP connection, ensure that the channel’s Connection Type field (if displayed) is set to ‘TCP/IP’. (The Connection Type field is only displayed for channels that support a choice of connection types—see Configure a Channel’s Connection Type.)

For channels on advanced drivers, you need to configure the required connection properties using the fields that are displayed on the rest of the tab. (TCP/IP channels on simple drivers typically have no further fields on the Primary Port or Secondary Port tabs.)

Advanced driver channels that represent TCP/IP connections have a combination of these fields:

  • TCP/IP Type—Use the combo box to select the required type of connection used to communicate with the remote device:
  • TCP—The connection uses Transmission Control Protocol (TCP), a connection-orientated transport protocol.
  • UDP—The connection uses User Datagram Protocol (UDP), a connectionless transport protocol.
  • Host Address—Enter the IP address or Node name of the device with which the ClearSCADA server is to communicate. Use the browse button to display a Reference browse window and select the required host from the window.
  • Port—Enter the IP port of the device with which the ClearSCADA server is to communicate.

For any TCP/IP connection fields not listed above, see the relevant driver guide.

For further information on the settings required for your communications equipment, see the manufacturer’s documentation.


Drivers Guide - Configure a Channel's Network Connection Properties (Configure a Channel's Connection Properties)

Configure a Channel’s Network Connection Properties

This option only applies to channels on advanced drivers.

For a channel to represent a Network connection, ensure that the channel’s Connection Type field (if displayed) is set to ‘Network’. (The Connection Type field is only displayed for channels that support a choice of connection types—see Configure a Channel’s Connection Type.)

Configure the required connection properties using the fields that are displayed on the rest of the tab. Channels that represent Network connections have a combination of these fields:

  • TCP/IP Type—Use the combo box to select the protocol used to communicate with the outstations or PLCs on this channel:
  • TCP—The connection uses Transmission Control Protocol (TCP), a connection-orientated transport protocol.
  • UDP—The connection uses User Datagram Protocol (UDP), a connectionless transport protocol.

You also need to configure the host address and the port number of each advanced driver outstation that communicates using this channel. Configure these details on the Form for each outstation (see Define an Outstation’s Network Properties in the ClearSCADA Guide to Advanced Drivers).

  • Merge Connections—Select this check box to merge the network connections of outstations that have the same address, so that they use a single connection. This reduces the total number of connections that need to be made to an outstation.

Merge connections if the channel has devices that:

  • Act as ‘routers’ to forward messages to and from other outstations that are connected to those routers.
  • Consist of several logical devices that share a single address, each of which is configured as a separate outstation in the ClearSCADA database.

If the TCP/IP Type is set to UDP and the Listen Port feature is enabled (see below), select the Merge Connections check box for the network connections to be grouped together, regardless of address.

Ensure that the Merge Connections check box is clear if network connections are not to be grouped together.

Use the Listen Port feature for network-connected outstations that can initiate a connection to the ClearSCADA server—for instance, those supported by the DNP3 driver (see Specify the Availability of Communications Between the Outstation and ClearSCADA in the ClearSCADA Guide to Advanced Drivers). The driver-specific documentation will state if an outstation does support this feature.

  • Enabled—Select this check box if the network-connected outstations that are using this channel can initiate a connection to the server. If the network connection between the outstation and server breaks, the server will attempt to reconnect at its retry interval. Additionally, some types of outstation will also try to make a connection to the server if, for instance, an alarm condition is breached. Both the outstation and server will continue to try to make a connection until one of them succeeds.

Leave the check box clear if the network-connected outstations using this channel are not capable of initiating a connection to the server.

  • Port—Enter the IP port on which the server will listen for connections. Typically, this should be a port number between 1024 and 49151 inclusive, depending on the protocol and the number of ports being used on your system. The port number has to be unique per system.

If your system setup requires multiple channels to use the number, ensure that the Network check box is selected within the Channels section of the ClearSCADA Server Configuration Tool. The check box enables the channels on a driver to share the same listen port (see Define whether a Listen Port can be Shared in the ClearSCADA Guide to Server Administration). To allow multiple channels to share the same port, enable the Listen Port feature on one channel and disable it on all of the other channels that need to use the same port number. The channel on which the Listen Port feature is enabled will forward the connection to the appropriate channel, whenever it receives messages intended for one of the other channels.

On some protocols, specific port numbers are registered with the IANA (Internet Assigned Numbers Authority). The driver-specific documentation lists those port numbers.

Generally, the well known ports below 1024 should only be used where a particular port number has been allocated to the protocol used by the channel. (Port numbers below 1024 are usually reserved for standard protocols such as web, e-mail, and telnet.)

ATTENTION: When the TCP/IP Type is UDP, we advise that you check http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx and http://support.microsoft.com/kb/953230. These articles indicate whether you should restrict the UDP ports that Windows DNS processes can use, to avoid DNS.exe randomly selecting one of the UDP ports that is used by a network-connected ClearSCADA channel.

  • Accept Connection from any Host—Use this check box to specify whether the channel is to accept a connection from a host without validating that host’s IP address.

Select the check box if the channel is a slave channel on which validation of a host’s IP address is not required. (A slave channel enables another device to scan ClearSCADA.)

Ensure that the check box is clear if the channel is a master channel or slave channel on which validation of a host’s IP address is required. A Master channel typically validates a host’s IP address before accepting a connection. (ClearSCADA uses master channel(s) to scan and obtain information from outstations or other data sources.)

A channel that validates a device’s IP address only accepts that device’s connections if the device’s IP address matches the IP address of a network outstation on that channel. (Validation is a security feature designed to make it harder for one device to impersonate another device.)

Regardless of the setting of the Accept Connection from any Host check box, each driver will still verify the source of a connection, based on the content of the messages that it receives via that connection.

For further information on the settings required for your communications equipment, see the manufacturer’s documentation.


Drivers Guide - Data Bits and Stop Bits (Configure a Channel's Connection Properties)

Data Bits and Stop Bits

When ClearSCADA passes data to the operating system, it provides the operating system with information about the port configuration. The operating system is responsible for sending the data with the correct start, stop, and parity bits.

The operating system sends:

  • A Start bit, consisting of 1 bit
  • Data bits, consisting of up to 8 bits
  • Stop bits, consisting of 1 bit, 1.5 bits, or 2 bits
  • A parity bit (only if parity is in use), consisting of 1 bit (see Parity).

Usually, each byte is 10 bits or 11 bits in size, depending on whether the parity bit is used. The Start and Parity bits are always 1 bit in size, but the Data Bits and Stop Bits can be configured to be larger in size.

Your communications equipment supports specific sizes for Data Bits and Stop Bits (most equipment supports 7 or 8 Data Bits and 1 Stop Bit). For the operating system to send messages containing bytes of the correct size, you need to configure the channels in your database to have Data Bits and Stop Bits settings that match those of your equipment.

Example:

Communications equipment is connected to a PC running ClearSCADA via a serial connection. A channel is configured to represent this connection.

The communications equipment supports Data Bits of 8 bits and Stop Bits of 1 bit and does not support a Parity bit. This means that it can only successfully receive messages that have bytes consisting of:

  • 1 Start bit
  • 8 Data Bits
  • 1 Stop Bit

So that ClearSCADA sends messages with data of 10 bits (where the Start bit is 1 bit, the Data bits are 8 bits, and the Stop bit is 1 bit), the channel is configured to have these settings:

  • Data Bits—8 Bits
  • Stop Bits—1 bit.


Drivers Guide - Parity (Configure a Channel's Connection Properties)

Parity

Parity is a method of error checking that is supported by some communications equipment. When supported, the ‘sending’ operating system adds an extra bit (the Parity bit) to each byte of data that it sends to the ‘receiving’ operating system.

Each byte of data contains:

  • A Start bit
  • Data bits
  • Parity bit
  • Stop bits.

Before the data is sent from the PC running ClearSCADA, the PC's operating system sets the Parity bit. The setting that is applied varies according to the Parity configuration setting of the channel (which has to match the configuration supported by the communications equipment):

  • None—Parity checking is not used.
  • Even—The Parity bit is set to 1 if the number of 1s in the Data Bits is an odd number (so that the total number of 1s, including the Parity bit, form an even number). For more information, see Even.
  • Odd—The Parity bit is set to 1 if the number of 1s in the Data Bits is an even number (so that the total number of 1s, including the Parity bit, form an odd number). For more information, see Odd.
  • Mark—Sets the Parity bit to 1. For more information, see Mark.
  • Space—Sets the Parity bit to 0. For more information, see Space.

When the operating system has set the Parity bit, it transmits the data via the relevant Port (defined in the channel's configuration). When the intermediate device that relays the message receives the data, it performs a calculation to determine whether the setting for the Parity bit is consistent with its configuration. If it is not consistent, the data is rejected and a parity error is generated.

The Parity bit check allows the communications equipment to determine whether the received data is valid, and varies according to the Parity configuration of the channel and communications equipment.


Drivers Guide - Even (Configure a Channel's Connection Properties)

Even

If the channel and communications equipment are configured to support Even Parity, the ‘receiving’ communications equipment expects the total numbers of bits that it receives in each transmission to comprise an even number.

The Parity bit is set to 1 if the number of 1s in the Data Bits is an odd number, so resulting in an even total (Parity bit + Data Bits).

The Parity bit is set to 0 if the number of 1s in the Data Bits is an even number, so retaining an even total.

In each case, the communications equipment checks that the sum total of the Data Bits including the Parity bit is an even number.

If the total number of bits including the Parity bit is even, it means that the data is complete and valid. The communications equipment will then pass the message to the ‘receiving’ application.

If the total number of bits including the Parity bit is odd, it means that the data has become corrupted during transit. The communications equipment will disregard the data and will not pass the message on to the ‘receiving’ application. If ClearSCADA is the ‘sending’ application and it does not receive a reply, it will time out the message. If repeated attempts to send the message continue to time out, ClearSCADA will generate an alarm.

However, in some instances, the communications equipment is not expected to reply even if the message was received correctly. In these situations, further diagnostics of the communications network and device are required.


Drivers Guide - Odd (Configure a Channel's Connection Properties)

Odd

This Parity setting works in the same way as the Even setting, except that the communications equipment expects the Data Bits total to be an odd number.


Drivers Guide - Mark (Configure a Channel's Connection Properties)

Mark

If the channel and communications equipment are configured to use Mark Parity, the communications equipment expects the Parity bit to be set to 1 in all data transmissions.

If the Parity bit is set to 1, the communications equipment will transmit the message to the ‘receiving’ application.

If the Parity bit is not set to 1, it means that the data has probably been corrupted during transit. The ‘receiving’ communications equipment will disregard the data and will not reply to the message. If ClearSCADA is the ‘sending’ application and it does not receive a reply, it will time out the message. If repeated attempts to send the message continue to time out, ClearSCADA will generate an alarm.

However, in some instances, the ‘receiving’ communications equipment is not expected to reply even if the message was received correctly. In these situations, further diagnostics of the communications network and device are required.


Drivers Guide - Space (Configure a Channel's Connection Properties)

Space

This Parity setting works in the same way as the Mark setting, except that the communications equipment expects the Parity bit to be set to 0.


Drivers Guide - Flow Control (Configure a Channel's Connection Properties)

Flow Control

Most communications equipment supports a feature called Flow Control that allows the equipment to stop receiving data for an amount of time. The purpose of this is to allow the communications equipment to temporarily suspend incoming messages so that it has time to process the data it has received.

Flow Control works by allowing the 'receiving' communications equipment to indicate when it is ready to receive new data. The operating system can only send the message if the 'receiving' communications equipment is ready for new data.

If the 'receiving' communications equipment is busy processing data that it has already received, it will use Flow Control to inform the 'sending' equipment that it cannot accept any new data. Any messages that are sent during this time are stored in the operating system’s transmission buffer, where they will remain until the 'receiving' communications equipment is ready to receive new data again. At this point, the data in the transmission buffer will be sent to the 'receiving' communications equipment. If the transmission buffer becomes full, any new messages that are sent will be disregarded, and after the defined number of retries, will fail.

During this process, the Flow Control setting is used to determine:

  • Which application raises the RTS line that is used by the 'sending' communications equipment to transmit the messages. The RTS line can be raised by the operating system.
  • Whether the 'receiving' communications equipment is ready to receive new data
  • Whether the 'sending' communications equipment is sending data (or is about to send data).

As with many channel connection settings, the Flow Control setting of each channel has to match the Flow Control configuration of your communications device. The possible Flow Control options are:

  • None (if Flow Control is not required). The ‘sending’ communications equipment or modem assumes that the ‘receiving’ equipment or modem can receive data at all times.
  • Software (XON/XOFF)
  • Hardware (RTS/CTS)
  • RTS Toggle
  • Manual.

If you choose Manual, you can also define the RTS/CTS Delay settings:

  • Pre-message RTS Delay—The amount of time (in milliseconds) that separates the assertion of the RTS signal and the transmission of data.

The Pre-message RTS Delay should match the amount of time it takes for your 'receiving' communications equipment to prepare for incoming data.

  • Abort Pre-message Delay if CTS Raised—This setting only applies if an advanced driver channel is set to have a Connection Type of Serial (see Configure a Channel’s Connection Type).

Select this check box if ClearSCADA is to abort the Pre-Message RTS Delay when the 'receiving' communications equipment asserts the Clear to Send (CTS) signal.

If a Pre-message RTS Delay is required at all times (even when a CTS signal has been sent), make sure that the check box is clear.

  • Post-message RTS Delay—This setting only applies if an advanced driver channel is set to have a Connection Type of Serial (see Configure a Channel’s Connection Type).

The Post-message RTS Delay is the amount of time (in milliseconds) that ClearSCADA waits between sending the message data and instructing the operating system to lower the RTS signal.

The Post-message RTS Delay should match the amount of time it takes for your 'sending' communications equipment to complete the data receival process.

NOTE: When configuring the RTS Delays for a channel, you need to have a good understanding of how long it takes your communications equipment to prepare for sending data. The RTS Delay settings you configure for the channel need to match the actual 'warm up' times of your communications equipment.


Drivers Guide - Software (XON/XOFF) (Configure a Channel's Connection Properties)

Software (XON/XOFF)

When the Software (XON/XOFF) Flow Control setting is selected, the Flow Control is managed by software in the 'receiving' communications equipment. The software monitors the amount of incoming data and when a certain threshold is reached, it sends an XOFF signal to the 'sending' communications equipment.

When the 'sending' communications equipment receives the XOFF signal, it stops transmitting data to the 'receiving' communications equipment.

When the 'receiving' communications equipment has processed the data in its buffer, and is ready to receive new data, it sends an XON signal to the 'sending' communications equipment.

From the moment the 'sending' communications equipment receives the 'XON' signal, it can be used to transmit data to the 'receiving' communications equipment again.

The XON and XOFF signals are transmitted via the data connection between the 'sending' communications equipment and 'receiving' communications equipment.


Drivers Guide - Hardware (RTS/CTS) (Configure a Channel's Connection Properties)

Hardware (RTS/CTS)

When the Hardware (RTS/CTS) Flow Control setting is selected, the Flow Control is managed by the communications equipment, which uses two additional wired Request To Send/Clear To Send connections to signal the flow control status. These RTS/CTS connections are used specifically for signalling the Flow Control status.

With RTS/CTS Flow Control, each device asserts RTS when it can receive data. The RTS lines are wired into the CTS lines, so when one device asserts the RTS line, the other device detects that the CTS line has been asserted. When a device detects that the CTS line has been asserted, it knows that it can send data. If the CTS line is lowered (because the other device has lowered RTS, possibly because of a full buffer), the device stops sending data.


Drivers Guide - RTS Toggle (Configure a Channel's Connection Properties)

RTS Toggle

When the RTS Toggle Flow Control setting is selected, the Flow Control is managed by the operating system of the PC on which ClearSCADA is running.

With RTS Toggle Flow Control, messages from ClearSCADA are passed to the operating system. The operating then raises an RTS line by asserting a Request to Send (RTS) signal to the 'receiving' communications equipment. The operating system will then send the data.

When the transmission buffer is empty, it turns off the RTS signal.


Drivers Guide - Manual (Configure a Channel's Connection Properties)

Manual

When the Manual Flow Control setting selected, the Flow Control is managed by the relevant ClearSCADA driver. When the driver is ready to send a message, it instructs the operating system to raise the RTS signal. The RTS signal informs the 'receiving' communications equipment that data is about to be sent.

After instructing the operating system to raise an RTS connection, the ClearSCADA driver waits for the Pre-message RTS Delay time. The delay allows the 'receiving' communications equipment time to prepare itself to receive the actual data.

On an advanced driver channel, if the Abort Pre-message Delay if CTS Raised setting is enabled, ClearSCADA will abort the Pre-message RTS Delay timer when it detects that CTS has been asserted. The data will then be transmitted.

Following sending the data to the operating system, an advanced ClearSCADA driver waits for the Post-message RTS Delay time before instructing the operating system to lower the RTS signal. This delay allows the 'receiving' equipment time to finish processing the data. If the device is just one part of a chain of devices, the Post-message RTS Delay time may be the delay required for the device to finish forwarding the data to a downstream device.

When the Post-message RTS Delay time has expired, the ClearSCADA driver instructs the operating system to lower the RTS signal. (On simple driver channels, the driver instructs the operating system to lower the RTS signal when its transmission buffer is empty.)

NOTE: The Abort Pre-message Delay if CTS Raised and Post-message RTS Delay properties only apply to Serial connections on advanced driver channels. They do not apply to Remote Serial connections.


Drivers Guide - Actions that are Common to Many Drivers

Actions that are Common to Many Drivers

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section covers actions that are commonly supported by items on many drivers in ClearSCADA. It includes:

  • Actions Associated with Servers on Simple Drivers
  • Actions Associated with Channels on Simple Drivers
  • Actions Associated with Scanners on Simple Drivers
  • Actions Associated with Slave Sources on Simple Drivers
  • Actions Associated with Channels on Advanced Drivers
  • Actions Associated with Outstation Sets on Advanced Drivers
  • Actions Associated with Outstations on Advanced Drivers
  • Actions Associated with Slave Outstations on Advanced Drivers
  • Actions Associated with Points
  • Actions Associated with Pulse Actions
  • Alphabetical List of Actions.

Be aware that some pick actions on your system might:

  • Require confirmation of your user password before being executed
  • Be configured to display a Notes window, providing further information about the selected action.

For more information, see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

NOTE: On items with which alarms can be associated, several methods are available to enable higher-level users to control alarm redirections via, for example, scripting. Such methods include CancelRedirections, ClearAlarmResponsibility, RestartRedirections, SetAlarmResponsibleUser, and SetAlarmResponsibleWorkstation. These are methods, not pick actions. For further information, see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection, and see CancelRedirections and RestartRedirections Methods in the ClearSCADA Guide to Alarm Redirection.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Use a Schedule to Trigger Pick Actions on a Regular Basis: see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration.

Use an Alarm Redirection to Trigger Pick Actions Under Particular Conditions: see Introduction to Alarm Redirection in the ClearSCADA Guide to Alarm Redirection.


Drivers Guide - Optionally Queue Pick Action Requests on PSTN and 'On Demand' Outstations (Actions that are Common to Many Drivers)

Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations

In order to perform some pick actions, such as a point Control, the ClearSCADA server needs to be in communications with the outstation.

When such a pick action is requested for an item on a direct outstation on which communications is set to ‘Always’ and not ‘On Demand’, ClearSCADA will immediately send that request to the outstation. If ClearSCADA has detected that the outstation’s direct line(s) have failed and the outstation has PSTN fallback enabled, ClearSCADA will execute a One Shot call to the outstation. The One Shot call sends the request to the outstation via PSTN.

With direct or PSTN outstations on which communications is set to ‘Incoming Only’ or ‘Periodic’, if such a pick action is requested outside of the available communications period, ClearSCADA will automatically queue that request until communications is next established. (If the pick action is requested during a ‘Periodic’ outstation’s available communications period, but that outstation’s direct line(s) are down, ClearSCADA will execute a One Shot call to the outstation. This will only occur if the outstation has PSTN fallback enabled and the direct line(s) are down during the availability period.)

With a PSTN outstation, if a call is in progress at the time, ClearSCADA will immediately send the request to the outstation. If a call is not in progress, ClearSCADA will execute a One Shot call to that outstation in order to send the request to the outstation.

With PSTN outstations and ‘On Demand’ outstations, it may be preferable to queue certain requests rather than have ClearSCADA contact the outstation as soon as such a request is triggered. The same applies to direct outstations on which PSTN fallback is enabled and ClearSCADA has detected that the direct channels have failed. You might want to queue requests, for example, if a cost is involved in establishing a connection to an outstation. If the ability to queue requests is required, the feature must be enabled on each server on your system (see Define whether the Queue Parameter is Available in the ClearSCADA Guide to Server Administration). When enabled, a Queue check box is displayed on some pick action windows:

Use the Queue check box to specify whether ClearSCADA is to queue a pick action request, or make an immediate attempt to contact the outstation and execute that request (see Queue Check Box).

You can ascertain whether any pick action requests are currently queued by looking at the individual database item or outstation’s Status display (see Queued Request).

ClearSCADA will send any queued requests to the outstation the next time that it is in contact with that outstation (with the exception of any requests that are superseded or canceled).

Further Information

Direct and PSTN Communications.

‘Incoming Only’ and ‘Periodic’ communications: see Specify the Availability of Communications Between the Outstation and ClearSCADA in the ClearSCADA Guide to Advanced Drivers.

Cancel Queued Request.


Drivers Guide - Queue Check Box (Actions that are Common to Many Drivers)

Queue Check Box

A Queue check box may be displayed on some pick action windows:

The Queue check box is only displayed:

  • If the ability to optionally queue requests is enabled on your system (see Define whether the Queue Parameter is Available in the ClearSCADA Guide to Server Administration). (The feature is disabled on most systems by default.)
  • For some pick actions on items on PSTN outstations, ‘On Demand’ outstations, and direct outstations on which PSTN fallback is enabled. The check box only applies to certain pick actions that require ClearSCADA to be in communications with such an outstation in order to perform the requested action.

With a pick action window in which the Queue check box is displayed:

  • Leave the Queue check box clear if you want ClearSCADA to send the request immediately.

If ClearSCADA is not currently communicating with the outstation, it will send a One Shot or Open Connection request to the outstation. This also applies to an outstation for which the Communications Availability is set to ‘Periodic’, if the request is made during the outstation’s availability period.

If the request is made outside of a ‘Periodic’ outstation’s availability period, leave the check box clear for ClearSCADA to send the request to the outstation at the start of the next availability period.

  • Select the Queue check box for ClearSCADA to queue the request if it is not currently in communications with the outstation.

If ClearSCADA is not currently communicating with the outstation, it will queue the request until:

  • ClearSCADA is next in contact with the outstation (for instance, via a scheduled One Shot or Open Connection request to retrieve data from the outstation, or through the outstation dialing in to ClearSCADA).

In the case of an outstation for which the Communications Availability is set to ‘Periodic’, select the Queue check box for a request that is made outside of the outstation’s availability period, if you want ClearSCADA to continue to queue that request into the outstation’s next availability period. (ClearSCADA will only send the request to the outstation at the next availability period if another pick action is triggered, which is not queued and which requires ClearSCADA to establish communications with the outstation.)

  • Another pick action is triggered, which is not queued and which requires ClearSCADA to establish communications with the outstation.
  • The same pick action is requested again on the same database item, but for a different option or value. If this happens, ClearSCADA will cancel the original request, providing it is still queued, and replace it with the new request. (For example, a queued request to control an analog point to 32.00 would be superseded if the same pick action was used again to control the same point to another value, such as 34.00.) An entry is added to the Events List whenever a queued pick action is superseded by another. The entry lists the trigger time of both requests.

or:

  • The Cancel Queued Request pick action is used to cancel the request.

If ClearSCADA is communicating with the outstation at the time that the pick action is triggered, ClearSCADA will immediately send the request to the outstation, regardless of the Queue check box’s setting.

(Be aware that any queued requests for an item will be deleted automatically should the item’s configuration become invalid.)

Further Information

Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations.


Drivers Guide - Actions Associated with Servers on Simple Drivers (Actions that are Common to Many Drivers)

Actions Associated with Servers on Simple Drivers

The servers on simple drivers support a combination of these actions:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Disable Alarms
  • Display Scanners
  • Enable Alarms
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Remove Alarms
  • Remove with Comment
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any server-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Channels on Simple Drivers (Actions that are Common to Many Drivers)

Actions Associated with Channels on Simple Drivers

The channels on simple drivers support a combination of these actions:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Disable Alarms
  • Disable Comms Logging
  • Disable Telnet
  • Display Scanners
  • Display Sources—(Slave Channels only)
  • Enable Alarms
  • Enable Comms Logging
  • Enable Telnet
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Remove Alarms
  • Remove with Comment
  • Reset Serial Port Statistics
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: Some simple driver channels support two lines and therefore also support the Switch Line pick action. Whenever the Switch Line pick action is supported, its functionality is summarized in the relevant driver-specific guide.
Most simple driver channels only support single connections and for such channels, any attempts to trigger the ‘Switch Line’ pick action or method in ClearSCADA will have no effect and will be ignored.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any channel-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Scanners on Simple Drivers (Actions that are Common to Many Drivers)

Actions Associated with Scanners on Simple Drivers

The scanners on simple drivers support a combination of these actions:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Cancel Refresh
  • Disable Alarms
  • Display Points
  • Enable Alarms
  • Refresh
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Remove Alarms
  • Remove with Comment
  • Reset Point Statistics
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any scanner-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Slave Sources on Simple Drivers (Actions that are Common to Many Drivers)

Actions Associated with Slave Sources on Simple Drivers

The sources on simple drivers support a combination of these actions:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Disable Alarms
  • Enable Alarms
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Remove Alarms
  • Remove with Comment
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any source-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Channels on Advanced Drivers (Actions that are Common to Many Drivers)

Actions Associated with Channels on Advanced Drivers

The channels on advanced drivers support a combination of these actions:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Disable Alarms
  • Disable Comms Logging
  • Disable IO Logging
  • Disable Telnet
  • Enable Alarms
  • Enable Comms Logging
  • Enable IO Logging
  • Enable Telnet
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Remove Alarms
  • Remove with Comment
  • Reset Call Statistics—(PSTN channels only)
  • Reset Outgoing Call Quality Factor—(PSTN channels that are selected for use by call quality factor)
  • Reset Serial Port Statistics—(Channels that have Serial connections)
  • Reset Statistics
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any channel-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Outstation Sets on Advanced Drivers (Actions that are Common to Many Drivers)

Actions Associated with Outstation Sets on Advanced Drivers

The outstation sets on advanced drivers support a combination of these actions:

  • Cancel Promoted Dial Out
  • Disable Switching—(Shared or Switched sets only)
  • Display Outstations
  • Enable Switching—(Shared or Switched sets only)
  • One Shot
  • Promote Dial Out
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Switch Line—(Shared or Switched sets only)
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled).

NOTE: The options Delete Interface Event, Log Interface Event, and Modify Interface Event are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any outstation set-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Outstations on Advanced Drivers (Actions that are Common to Many Drivers)

Actions Associated with Outstations on Advanced Drivers

NOTE: Slave outstations support a subset of these actions (see Actions Associated with Slave Outstations on Advanced Drivers).

The outstations on advanced drivers support a combination of these actions:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Cancel Promoted Dial Out—(PSTN outstations or outstations with PSTN fallback)
  • Cancel Promoted Scanning—(Direct or Shared outstations)
  • Cancel Queued Request—(Outstations on which pick actions are queued)
  • Close Line—(PSTN outstations or outstations with PSTN fallback)
  • Disable Alarms
  • Disable Switching—(Shared outstations only)
  • Display Points
  • Display Pulse Actions—(Outstations that have pulse actions)
  • Download Configuration—(Outstations on drivers that support download from ClearSCADA)
  • Enable Alarms
  • Enable Switching—(Shared outstations only)
  • Extend Line—(PSTN outstations or outstations with PSTN fallback)
  • Fallback—(Direct or Shared outstations on which PSTN fallback is enabled)
  • One Shot—(PSTN outstations or outstations with PSTN fallback)
  • Open Line—(PSTN outstations or outstations with PSTN fallback)
  • Preferred Channel—(PSTN outstations or outstations with PSTN fallback)
  • Promote Dial Out—(PSTN outstations or outstations with PSTN fallback)
  • Promote Scanning—(Direct or Shared outstations on which promotion is enabled)
  • Refresh—(If supported by the driver)
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Remove Alarms
  • Remove with Comment
  • Reset Call Statistics—(PSTN outstations or outstations with PSTN fallback)
  • Reset Comms Statistics
  • Reset Outstation—(Outstations that support reset commands from the server)
  • Reset Point Statistics
  • Switch Line—(Shared outstations only)
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any outstation-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Slave Outstations on Advanced Drivers (Actions that are Common to Many Drivers)

Actions Associated with Slave Outstations on Advanced Drivers

With most advanced driver setups, ClearSCADA is the SCADA master. Some drivers support slave functionality, whereby the ClearSCADA system acts as an outstation or similar device and reports any data changes back to its SCADA master (see Master-Slave Communications). On systems on which ClearSCADA is a slave, the Slave outstations support a combination of these actions:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Cancel Promoted Dial Out—(PSTN Slave outstations)
  • Close Line—(PSTN Slave outstations)
  • Disable Alarms
  • Enable Alarms
  • Extend Line—(PSTN Slave outstations)
  • One Shot—(PSTN Slave outstations)
  • Open Line—(PSTN Slave outstations)
  • Preferred Channel—(PSTN Slave outstations)
  • Promote Dial Out—(PSTN Slave outstations)
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Remove Alarms
  • Remove with Comment
  • Reset Call Statistics—(PSTN Slave outstations)
  • Reset Comms Statistics
  • Reset Point Statistics
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any slave outstation-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Points (Actions that are Common to Many Drivers)

Actions Associated with Points

NOTE: The actions supported by Pulse Actions are listed separately (see Actions Associated with Pulse Actions).

Points support a combination of these actions:

  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Cancel Control—(Output points on simple drivers)
  • Cancel Queued Request—(Output points on advanced drivers)
  • Control—(Output points only)
  • Disable Alarms
  • Disable Controls—(Output points only)
  • Disable Point
  • Enable Alarms
  • Enable Controls—(Output points only)
  • Enable Point
  • Initialize—(Counter-type points that support this feature)
  • Override
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Release Override
  • Remove Alarms
  • Remove with Comment
  • Reset Process Count
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Tune Alarm Limits—(Analog and Counter-type points that support this feature)
  • Tune M/S Alarm Limits—(Analog points that use Master Station Alarm Limits)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

NOTE: With points on which Historic is enabled, further options are available from the Historic aggregate in the Edit Action, Edit Method, and Pick Action Configuration windows. These options—Annotate, Insert Value, Load Data File, Load Data Value, Load Data Values, Modify Value, Optimize Data, and Processed Value—are methods, not pick actions, and are purely for use with the Automation Interface. For more information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any point-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Actions Associated with Pulse Actions (Actions that are Common to Many Drivers)

Actions Associated with Pulse Actions

Pulse actions support a combination of these actions:

  • Abort Pulse
  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Cancel Control—(Pulse Actions on simple drivers)
  • Cancel Queued Request—(Pulse Actions on advanced drivers)
  • Control
  • Disable Alarms
  • Disable Controls
  • Disable Point
  • Enable Alarms
  • Enable Controls
  • Enable Point
  • Inching—(Pulse actions that support user-definable control periods)
  • Release Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Remove Alarms
  • Remove with Comment
  • Take Complete Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Take Partial Exclusive Control—(Systems on which Exclusive Control is enabled)
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

NOTE: The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are also available from the Edit Action, Edit Method, and Pick Action Configuration windows. These options are methods, not pick actions, and are purely for use with the Automation Interface. For information, see the database Schema.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

For information on any pulse-specific actions that are not listed above, see the relevant driver guide.


Drivers Guide - Alphabetical List of Actions (Actions that are Common to Many Drivers)

Alphabetical List of Actions

The subsections within this section summaries the actions that are commonly supported by items on many drivers. The subsections are arranged in alphabetical order, by pick action name.

You can also display a list of the actions that are commonly supported by a particular driver item, such as a channel, or scanner (see Actions that are Common to Many Drivers).

Be aware that many of these actions are only displayed for an item that is In Service and has valid configuration. Additionally, your User Account has to be allocated the relevant security permissions for the database item—the permission that applies to each pick action is mentioned alongside the description of that pick action. For more information, see Allocating Security Permissions in the ClearSCADA Guide to Security.

On some systems, certain permissions may be denied on a system-wide, ViewX user, or WebX user basis, regardless of the permissions that are allocated to your User Account (see Define whether any Permissions are Restricted in the ClearSCADA Guide to Security). On systems on which the Exclusive Control feature is used, some permissions might be denied to other users while an item or area of the system is under Exclusive Control (see Exclusive Control in the ClearSCADA Guide to Security). On systems that use Alarm Redirection, the ability to acknowledge specific alarms might be restricted to a particular User, User Group, or ViewX workstation (see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection). Any of these may result in various pick actions not being available for selection.

If you believe that a particular pick action should be available, but is not displayed for an item, check the item’s configuration, and Status display (see Status Attributes that are Common to Many Drivers).

Where a pick action request requires further user input before being executed, a pick action window is displayed. Use the window to specify the required information, then select the OK button to confirm the details and execute the request. With text entry fields on some pick action windows, an on-screen keypad may be displayed to enable you to specify the field’s value on-screen, rather than by using a traditional keyboard. The keypad is only displayed on ViewX workstations on which the On-Screen Keyboard feature enabled. For more information, see Use the Numeric Touch Screen Keypad in the ClearSCADA Guide to ViewX and WebX Clients, and see Use the QWERTY Touch Screen Keypad in the ClearSCADA Guide to ViewX and WebX Clients. On some systems, users can choose to postpone certain requests on PSTN and direct ‘On Demand’ outstations. On such systems, an additional Queue check box is displayed on the relevant pick action windows—see Queue Check Box.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. A note is included with the relevant pick action whenever this naming convention differs. Refer to the Database Schema for argument naming conventions not covered in this section.

These pick actions are common to items on many drivers:

  • Abort Pulse
  • Acknowledge Alarms
  • Acknowledge with Comment
  • Alarm Response
  • Cancel Control
  • Cancel Promoted Dial Out
  • Cancel Promoted Scanning
  • Cancel Queued Request
  • Cancel Refresh
  • Close Line
  • Control
  • Disable Alarms
  • Disable Comms Logging
  • Disable Controls
  • Disable IO Logging
  • Disable Point
  • Disable Switching
  • Disable Telnet
  • Display Outstations
  • Display Points
  • Display Pulse Actions
  • Display Scanners
  • Display Sources
  • Download Configuration
  • Enable Alarms
  • Enable Comms Logging
  • Enable Controls
  • Enable IO Logging
  • Enable Point
  • Enable Switching
  • Enable Telnet
  • Extend Line
  • Fallback
  • Inching
  • Initialize
  • One Shot
  • Open Line
  • Override
  • Preferred Channel
  • Promote Dial Out
  • Promote Scanning
  • Refresh
  • Release Exclusive Control
  • Release Override
  • Remove Alarms
  • Remove with Comment
  • Reset Call Statistics
  • Reset Comms Statistics
  • Reset Outgoing Call Quality Factor
  • Reset Outstation
  • Reset Point Statistics
  • Reset Process Count
  • Reset Serial Port Statistics
  • Reset Statistics
  • Switch Line
  • Take Complete Exclusive Control
  • Take Partial Exclusive Control
  • Tune Alarm Limits
  • Tune M/S Alarm Limits
  • Unacknowledge Alarms
  • Unacknowledge with Comment.

Some further options available from the Edit Action, Edit Method, and Pick Action Configuration windows are methods, not pick actions:

  • The options Delete Interface Event, Log Interface Event, Modify Interface Event, Refresh Alarms, and Reprioritize Alarms are methods that are purely for use with the Automation Interface. For information, see the database Schema.
  • With points on which Historic is enabled, further options are available from the Historic aggregate on the above mentioned windows. The options Annotate, Insert Value, Load Data File, Load Data Value, Load Data Values, Modify Value, Optimize Data, and Processed Value are methods that are purely for use with the Automation Interface. For more information, see the database Schema.
  • On items with which alarms can be associated, several methods are available to enable higher-level users to control alarm redirections via, for example, scripting. Such methods include CancelRedirections, ClearAlarmResponsibility, RestartRedirections, SetAlarmResponsibleUser, and SetAlarmResponsibleWorkstation. For further information, see Set Responsibility Action in the ClearSCADA Guide to Alarm Redirection, and see CancelRedirections and RestartRedirections Methods in the ClearSCADA Guide to Alarm Redirection.

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.


Drivers Guide - Abort Pulse (Actions that are Common to Many Drivers)

Abort Pulse

Associated with: Pulse actions

Security permission required to access this pick action: Control

This pick action is only available on a pulse action if an Inching or Control action is currently active or awaiting execution on a pulse action (as indicates by the pulse action’s Control Active status attribute, and the Point Action system color).

Use the Abort Pulse pick action to abort the currently active pulse control.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Abort.


Drivers Guide - Cancel Control (Actions that are Common to Many Drivers)

Cancel Control

Associated with: Output points and pulse actions on simple drivers

Security permission required to access this pick action: Control

This pick action is only available on a point or pulse action when a Control request is presently active, or is awaiting execution.

Use the Cancel Control pick action to cancel the currently active control.

Also see Abort Pulse.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name ControlCancel.


Drivers Guide - Cancel Promoted Dial Out (Actions that are Common to Many Drivers)

Cancel Promoted Dial Out

Associated with: Outstation sets; PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

Security permission required to access this pick action: Promote

This pick action is only available if the rate at which ClearSCADA is dialing out to an outstation is currently promoted (see Promote Dial Out).

Use the pick action to terminate the current promotion. Once executed, ClearSCADA reverts to dialing the outstation at its usual rate.


Drivers Guide - Cancel Promoted Scanning (Actions that are Common to Many Drivers)

Cancel Promoted Scanning

Associated with: Direct or Shared outstations

Security permission required to access this pick action: Promote

This pick action is only available if the rate at which an outstation is being scanned is currently promoted (see Promote Scanning).

Use the pick action to terminate the current promotion. Once executed, ClearSCADA reverts to scanning the outstation at its usual scan rate.


Drivers Guide - Cancel Queued Request (Actions that are Common to Many Drivers)

Cancel Queued Request

Associated with: Outstations, points and pulse actions on which pick action(s) are currently queued

Security permission required to cancel requests queued by other users: Cancel Request (This permission is disabled on most systems by default. It is typically denied on a per server basis.)

With some types of outstation, ClearSCADA queues certain pick action requests automatically if it is not in communications with the outstation when the request is triggered. With some other types of outstation, your system may be configured to provide the option to queue such requests if required (see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations).

You can ascertain whether any pick actions are currently queued by viewing an individual item or outstation’s Status display. The Status display will include a Queued Request status attribute for each request that is currently queued.

If any queued requests are longer required, use the Cancel Queued Request pick action to cancel the request(s).

If your User Account is not assigned the Cancel Request security permission (the default on most systems), you will only be able to cancel pick action requests that you triggered, providing those requests are still queued. This includes any pick actions that ClearSCADA has queued automatically because it was not in communications with the outstation when you triggered the requests.

If your User Account is assigned the Cancel Request security permission, you will be able to cancel any queued pick actions, including pick actions requested by other users.

Select the pick action to display the Cancel Queued Request window.

To cancel a specific pick action, use the Request combo box to display a list of currently queued requests, then select the pick action request that is no longer required.

With an outstation, the list includes any requests that are currently queued for any of the outstation’s ‘dependants’ (such as points and pulse actions) in addition to the outstation itself. For dependants, the lists includes the full database path of the item with which each queued request is associated.

Select ‘All’ to cancel any requests that are currently queued on the point, pulse action, or outstation. With an outstation, selecting ‘All’ will result in ClearSCADA canceling the queued requests on that outstation’s ‘dependants’ in addition to any requests that are currently queued for the outstation itself. Unless your User Account is assigned the Cancel Request security permission, you will only be able to use the ‘All’ option to cancel the queued pick actions that you triggered; pick actions triggered by other users will remain queued.


Drivers Guide - Cancel Refresh (Actions that are Common to Many Drivers)

Cancel Refresh

Associated with: Scanners; outstations on simple drivers

Security permission required to access this pick action: Retrieve Data

Use this pick action to cancel a current request to Refresh a scanner’s data.

The Cancel Refresh pick action provides additional functionality on some drivers—the driver-specific documentation explains such additional functionality where it applies to a particular driver.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name RefreshCancel.


Drivers Guide - Close Line (Actions that are Common to Many Drivers)

Close Line

Associated with: PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

WARNING

unexpected behavior of application

Use the Close Line pick action with care. Always check an outstation’s current activity, before deciding whether to use this pick action.

To check whether an outstation is currently processing a request, look at its entry in the Outstations List’s Current Request column. You can also check an outstation’s current activity via, for example, the Events List or the outstation’s Status display.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

The Close Line pick action is available on an outstation providing that:

  • ClearSCADA is in communication with that outstation via PSTN
  • Your User Account is allocated the Retrieve Data security permission for that outstation.

Use the Close Line pick action to end the current telephone call between ClearSCADA and the outstation. You can use this pick action to end calls that have been instigated by either the outstation or ClearSCADA.

When the Close Line pick action is executed, ClearSCADA completes any outstanding read response, then ends the call. Any actions that are otherwise in progress, or are outstanding, are canceled.

Also see One Shot, and see Open Line.


Drivers Guide - Control (Actions that are Common to Many Drivers)

Control

Associated with: Output points and pulse actions

Use this pick action to control the device that is represented by an output point or pulse action. (Be aware that with points on simple drivers, you typically have to enable the features on the configuration Form’s Control tab, in order for that point to become an output point.)

The Control pick action is available on a point or pulse action providing that:

  • Your User Account is allocated the Control security permission for that point or pulse action.
  • The Disable Controls has not been used to prevent users from issuing controls on that point or pulse action.

Select the Control pick action to display the Control window.

Specify the required value in the Value field. Depending on the type of point, you may be offered a combo list of point values, or need to specify a value within a particular range. The range or values from which you can choose are determined by the point’s configuration.

With analog and counter-type points, you need to specify a value within the range of values that are configured for that point.
With a digital point or pulse action, you select a value from the list of values that are configured for the point.

Depending on the type of point, ClearSCADA will attempt to execute either a ‘maintained’ control (via an output point), or a ‘pulsed’ control (via a pulse action). A maintained control upholds the new point state until it is altered by a further control. A pulsed control changes the state of a point for a defined period of time (as specified on the Pulse Action Form). (Some pulse actions also support ‘inching’, whereby you specify the time period for which to control the device when you trigger the Inching, rather than the Control, pick action.)

With points on PSTN or ‘On Demand’ outstations, the Control window may display a Queue check box. Use the check box to indicate whether ClearSCADA is to perform the request immediately, or queue the request if ClearSCADA is not currently in communications with the outstation (see Queue Check Box).

The Point Action system color indicates that an action, such as a control, is currently in progress on a point or pulse action.

The Control Alarm status attribute indicates the success, or otherwise, of the point’s last control request.

Be aware that triggering a Control action on a point on a PSTN outstation will result in ClearSCADA executing a One Shot call to that outstation (the call might be postponed if the pick action request is queued). When a One Shot is triggered, ClearSCADA will establish communications with the outstation and then perform the requested control. Once the control has completed, ClearSCADA will perform a normal data poll sequence on the outstation, before ending the call. If the line is already open—for instance as the result of an Open Line request—ClearSCADA will send the control straight away (as communications are already established).

Also see Cancel Control.


Drivers Guide - Disable Comms Logging (Actions that are Common to Many Drivers)

Disable Comms Logging

Associated with: Channels

Security permission required to access this pick action: Diagnostics

Use this pick action to disable any comms logging that is presently enabled on a channel (see Enable Comms Logging).

NOTE: If using this pick action with the Automation Interface, you need to specify the method name DisableLogging.


Drivers Guide - Disable Controls (Actions that are Common to Many Drivers)

Disable Controls

Associated with: Output points and pulse actions

Security permission required to access this pick action: Disable Controls

Use the Disable Controls pick action to prevent operators from being able to send controls to a point or pulse action via the usually available pick actions. You might want to use the Disable Controls pick action, for instance, if ClearSCADA has detected a known problem with the plant with which a point is associated. When used, actions such as Control and Inching are no longer available for selection on that point.

Once the detected problem has been rectified, use the Enable Controls pick action to give users access to the control pick actions once again.

The Control Disabled system color and Controls status attribute indicate when controls are disabled on a point or pulse action.


Drivers Guide - Disable IO Logging (Actions that are Common to Many Drivers)

Disable IO Logging

Associated with: Channels on advanced drivers

Security permission required to access this pick action: Diagnostics

Use this pick action to disable any I/O logging that is presently enabled on a channel (see Enable IO Logging).


Drivers Guide - Disable Point (Actions that are Common to Many Drivers)

Disable Point

Associated with: Points and pulse actions

Security permission required to access this pick action: Disable Points

Use the Disable Point pick action to take a point or pick action Out of Service.

You might want to disable a point, for example, if ClearSCADA has detected a known problem with that point, and then re-enable the point once the problem has been rectified.

The Disable Point pick action clears the point’s In Service property, so that the point is no longer active.

Use the Enable Point pick action to place the point back In Service.

An entry is logged in the Event Journal whenever either pick action is used. The message indicates whether the point has been enabled or disabled.

Be aware that disabling a point that is a ‘parent’ point effectively puts any derived points that calculate their values from that point Out of Service (although their configuration will remain unchanged).

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Disable.


Drivers Guide - Disable Switching (Actions that are Common to Many Drivers)

Disable Switching

Associated with: Shared or Switched outstation sets; Shared outstations that are ‘Independent’

Security permission required to access this pick action: Switch Line

On Switched or Shared sets, ClearSCADA automatically switches communications to the other of two direct channels should it detect that communications via the presently used channel has failed (see Direct - Dual Channel in the ClearSCADA Guide to Advanced Drivers).

If required, use the Disable Switching pick action to temporarily stop communications from switching to the channel that is not presently in use. Use the pick action, for instance, if maintenance needs to be carried out on the unused channel. Once any maintenance is complete, use the Enable Switching pick action to re-enable line switching.

Should ClearSCADA detect that communications via the presently used channel has failed while switching is disabled, communications will fall back to PSTN (if such communications are supported and enabled).

The Switching Disabled system color, and the Switching status attribute indicate when switching is inhibited on a set or outstation.


Drivers Guide - Disable Telnet (Actions that are Common to Many Drivers)

Disable Telnet

Associated with: Channels

Security permission required to access this pick action: Diagnostics

Use the Disable Telnet pick action to cease any real time Telnet monitoring that is currently in force on a channel. For more information, see Enable Telnet.


Drivers Guide - Display Outstations (Actions that are Common to Many Drivers)

Display Outstations

Associated with: Outstation sets

Security permission required to access this pick action: Read

Use this pick action to display a Queries List of the outstations that are associated with the selected outstation set.

NOTE: The Display Outstations pick action is not a method and therefore cannot be used with the automation interface.


Drivers Guide - Display Points (Actions that are Common to Many Drivers)

Display Points

Associated with: Scanners and outstations

Security permission required to access this pick action: Read

Use this pick action to display a Queries List of the points that are associated with the selected scanner or outstation.

NOTE: The Display Points pick action is not a method and therefore cannot be used with the automation interface.


Drivers Guide - Display Pulse Actions (Actions that are Common to Many Drivers)

Display Pulse Actions

Associated with: Outstations that have pulse actions

Security permission required to access this pick action: Read

Use this pick action to display a Queries List of the pulse actions that are associated with the selected outstation.

NOTE: The Display Pulse Actions pick action is not a method and therefore cannot be used with the automation interface.


Drivers Guide - Display Scanners (Actions that are Common to Many Drivers)

Display Scanners

Associated with: Servers and channels on simple drivers

Security permission required to access this pick action: Read

Use this pick action to display a Queries List of the scanners that are associated with the selected server or channel.

NOTE: The Display Scanners pick action is not a method and therefore cannot be used with the automation interface.


Drivers Guide - Display Sources (Actions that are Common to Many Drivers)

Display Sources

Associated with: Slave channels on simple drivers

Security permission required to access this pick action: Read

Use this pick action to display a Queries List of the Slave Sources that are associated with the slave channel.

NOTE: The Display Sources pick action is not a method and therefore cannot be used with the automation interface.


Drivers Guide - Download Configuration (Actions that are Common to Many Drivers)

Download Configuration

Associated with: Outstations on drivers that support configuration downloads

Security permission required to access this pick action: Configure

WARNING

unexpected behavior of application

Do not make further configuration changes to an outstation or any of its dependants while a download is in progress to that outstation. Performing such changes may result in partially updated or corrupt configuration being downloaded to the outstation, or configuration changes not being flagged for download.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

Use this pick action to download the configuration that is associated with an outstation, from the ClearSCADA database to that outstation (see Downloading Configuration Changes in the ClearSCADA Guide to Core Configuration).

The Download Config Alarm status attribute indicates the success, or otherwise, of the last Download Configuration request to the outstation.

The Download Configuration Required system color indicates when configuration changes have been made in ClearSCADA, which have not yet been downloaded to the relevant outstation.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name DownloadConfig.


Drivers Guide - Enable Comms Logging (Actions that are Common to Many Drivers)

Enable Comms Logging

Associated with: Channels

Security permission required to access this pick action: Diagnostics

Use this pick action to log the ‘good’ communications on a channel (see Enable or Disable 'Normal' Communications Logging on a Channel in the ClearSCADA Guide to Server Administration).

Comms Logging on a channel is not enabled by default. Before enabling such logging, ensure that enough disk space is available to store the log files that will be produced.

The Logging system color indicates that Communications, I/O Logging, or Telnet monitoring are enabled on a channel. The Comms Logging status attribute indicates the channel’s current Comms Logging status.

For more information, see Communications Logging in the ClearSCADA Guide to Server Administration.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name EnableLogging.

Also see Disable Comms Logging.


Drivers Guide - Enable Controls (Actions that are Common to Many Drivers)

Enable Controls

Associated with: Output points and pulse actions

Use this pick action to allow presently inhibited control actions to become available for selection on a point or pulse action.

The Enable Controls pick action is only available on a point or pulse action if:

  • The Disable Controls pick action has been used to prevent access to control options on that point or pulse action.
  • Your User Account is allocated the Disable Controls security permission for that point or pulse action.

Also see Control, and see Inching.


Drivers Guide - Enable IO Logging (Actions that are Common to Many Drivers)

Enable IO Logging

Associated with: Channels on advanced drivers

Security permission required to access this pick action: Diagnostics

Use this pick action to enable I/O logging on a channel. When enabled, ClearSCADA logs the communications that occur on the channel, including any data that is discarded by the driver (see Enable or Disable I/O Logging on a Channel in the ClearSCADA Guide to Server Administration).

IO Logging on a channel (not to be confused with the I/O Logging option on a driver) is not enabled by default. Before enabling such logging, ensure that enough disk space is available to store the log files that will be produced.

The Logging system color indicates that Communications, I/O Logging, or Telnet monitoring are enabled on a channel. The IO Logging status attribute indicates the channel’s current I/O Logging status.

For more information, see Communications Logging in the ClearSCADA Guide to Server Administration.


Drivers Guide - Enable Point (Actions that are Common to Many Drivers)

Enable Point

Associated with: Points and pulse actions

Use this pick action to place a point In Service. Triggering the action changes the point or pulse action’s configuration so that its In Service property is enabled. Providing that the devices on which the point is dependant (such as its scanner, or outstation and set) are also In Service and have valid configuration, the point will become active.

The Enable Point pick action is only available for a point:

  • That is not In Service
  • For which your User Account is allocated the Disable Points security permission.

Also see Disable Point.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Enable.


Drivers Guide - Enable Switching (Actions that are Common to Many Drivers)

Enable Switching

Associated with: Shared or Switched outstation sets; Shared outstations that are ‘Independent’

This pick action is only displayed for a set or outstation on which:

  • The Disable Switching pick action has been used to temporarily disable any line switching.
  • Your User Account is allocated the Switch Line security permission.

Use the Enable Switching pick action to re-enable line switching.

Also see Switch Line.


Drivers Guide - Enable Telnet (Actions that are Common to Many Drivers)

Enable Telnet

Associated with: Channels

Security permission required to access this pick action: Diagnostics

In ClearSCADA, each channel has its own Telnet server, which you can use to monitor the channel’s communications in real time. Whenever monitoring is required, use the Enable Telnet pick action to start the channel’s Telnet server (see Enable or Disable the Telnet Server in the ClearSCADA Guide to Server Administration). Once monitoring is no longer required, use the Disable Telnet pick action to stop the Telnet server.

The Logging system color indicates that Communications, I/O Logging, or Telnet monitoring are enabled on a channel. The Telnet status attribute indicates the current status of the channel’s Telnet server.

For more information, see Telnet Monitoring in the ClearSCADA Guide to Server Administration.


Drivers Guide - Extend Line (Actions that are Common to Many Drivers)

Extend Line

Associated with: PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

This pick action is only available on an outstation:

  • That supports call extensions
  • For which your User Account is allocated the Retrieve Data security permission.

Use the Extend Line pick action to reset a PSTN call that is in progress, if that call is otherwise likely to terminate before ClearSCADA has finished retrieving the outstation’s data. ClearSCADA re-applies the outstation’s Maximum Call Length from the instant that the Extend Line action is executed. For more information, see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers.

Also see One Shot, and see Open Line.


Drivers Guide - Fallback (Actions that are Common to Many Drivers)

Fallback

Associated with: Direct or Shared outstations that can fallback to PSTN

WARNING

Unexpected Behavior of Application

Use the Fallback pick action with care. Always check an outstation’s current activity before deciding whether to use this action.

To check whether an outstation is currently processing a request, look at its entry in the Outstations List’s Current Request column. You can also check an outstation’s current activity via, for example, the Events List or the outstation’s Status display.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

With an outstation on which PSTN fallback is available, communications will automatically ‘fall back’ to using an available PSTN channel, should ClearSCADA detect that the direct communications has failed (see Direct - PSTN Fallback in the ClearSCADA Guide to Advanced Drivers). Similarly, if an outstation is configured to accept Download Configuration via PSTN, communications will automatically switch to PSTN for the duration of a download (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers).

In addition, you can use the Fallback pick action to change the type of communications being used for the outstation at any time (for instance, if maintenance work needs performing on the direct channel(s)).

The Fallback pick action is only available on an outstation on which:

  • PSTN fallback is supported and enabled (see Direct - PSTN Fallback in the ClearSCADA Guide to Advanced Drivers)
  • Your User Account is allocated the Switch Line security permission.

Select the Fallback pick action to display the Fallback window. Select the required option from the Action combo box. Depending on the type of communications that ClearSCADA is currently using to communicate with the outstation, one of these options will be available for selection:.

  • Fallback to PSTN—Select this option for ClearSCADA to cease multidrop communications with the outstation, and make the outstation available for PSTN calls.

When this option is selected, ClearSCADA will complete any outstanding read response, then end communications with the outstation via the currently used direct channel.

Use suitable pick action, such as One Shot or Open Line, to communicate with the outstation via PSTN. (Should ClearSCADA be unsuccessful in its attempt(s) to connect to the outstation via PSTN, the outstation’s State will change to Failed, Multidrop Stopped.)

  • Return to Multidrop—Select this option for ClearSCADA to end any current PSTN call to the outstation, and make the outstation available for multidrop communications. If a PSTN call is in progress, ClearSCADA will complete any outstanding read response, then end the call. Any other actions that are otherwise in progress, or are outstanding, will be canceled. ClearSCADA will then include the outstation in its direct communications scanning regime, typically performing an Establishment Phase scan of the outstation once multidrop communications are re-established.


Drivers Guide - Inching (Actions that are Common to Many Drivers)

Inching

Associated with: Pulse actions that support user-definable control periods

With pulse actions on some drivers, you can use:

  • The Inching pick action to control plant for a user-defined duration
  • The Control pick action to control plant for a pre-configured duration. (The duration is that specified on the Pulse Action tab of the Pulse Action Form.)

Be aware that triggering an Inching or Control action on a point on a PSTN outstation will result in ClearSCADA executing a One Shot call to that outstation.

The Inching pick action is only available on a pulse action on which:

  • Inching is supported and, if applicable, enabled
  • Controls are enabled
  • Your User Account is assigned the Control permission.

Select the Inching pick action to display the Inching window.

(The Inching functionality differs for pulse actions on some drivers—the driver-specific documentation explains any such differences.)

For pulse actions on most drivers, these fields are displayed:

  • Action—Use to specify the pulse’s action. For one-action pulses, this field is for information only; for two- or three-action pulses, use the combo box to select the required action.

The name of each action in the Action field corresponds to the description that has been assigned to that action, in the Actions section of the Pulse Action Form.

  • Duration—Use to specify the amount of time for which the pulse control is to last. You need to specify a time that is within the range, or less than or equal to the maximum duration that is specified on the Pulse Action Form.

The Point Action system color indicates when an inching action is currently active. The pulse action’s Control Active status attribute also indicates whether an inching action is currently ongoing.

The pulse action’s Control Alarm status attribute indicates the success, or otherwise, of the latest Inching or Control action.


Drivers Guide - Initialize (Actions that are Common to Many Drivers)

Initialize

Associated with: Counter-type points that support this feature

The Initialize pick action is only available on counter-type points on which:

  • Initialization is supported and, if applicable, enabled
  • Your User Account is allocated the Control security permission for the point.

Counter-type points accumulate their values over time. Use the Initialize pick action to reset such a point’s value back to a particular value, in order to start the accumulation process from that value.

With counter-type points on many drivers, you use the pick action to reset the point’s value back to a default that is defined in the outstation. The value is typically zero.

With some counter-type points, you can specify the value to which the point is to be initialized. With such points, you select the Initialize pick action to display the Initialize window and specify the required value in that window.

The initialize option varies on some drivers—the driver-specific documentation explains any differences that apply to a particular driver.


Drivers Guide - One Shot (Actions that are Common to Many Drivers)

One Shot

Associated with: Outstation sets; PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

Security permission required to access this pick action: Retrieve Data

When ClearSCADA executes a One Shot call, the server dials out to an outstation, retrieves its data, and then terminates the call. Use the One Shot pick action to instigate such a call. The pick action is typically associated with a Schedule, so that the One Shot calls occur automatically on a regular basis, without the need for user intervention. However, you can also use the One Shot pick action manually whenever required.

When a One Shot call is triggered on an outstation, ClearSCADA dials out to that individual outstation to retrieve its data.

When a One Shot call is triggered on an outstation set, if multiple PSTN channels are available, then multiple calls will run in parallel, as ClearSCADA will dial out to as many outstations as possible simultaneously. For example, if a set contains two outstations and two PSTN channels are available, ClearSCADA will dial both outstations at the same time. If there are three outstations in a set and only two PSTN channels available, then once the first call has completed, ClearSCADA will dial the third outstation. In each case, if there are more outstations then there are PSTN channels available, the server will dial the outstation with the lowest address first; once it has received the data from that outstation, it will terminate the call and dial the outstation that has the next lowest address, and so on. The telephone number that is used to contact each outstation is specified on the PSTN tab of the Outstation Form.

If the Preferred Channel pick action has been used to specify a particular channel, ClearSCADA will attempt to use that channel to dial out to the outstation(s) in preference to other PSTN channels.

Should an outstation have a large amount of data to report, the call will terminate once the outstation’s Maximum Call Length is reached, regardless of whether all of the data has been retrieved. With some types of outstation, you can use the Extend Line pick action to extend the length of such a call, in order to retrieve all of the data.

Whenever an action is triggered that requires ClearSCADA to exchange information with a PSTN outstation, ClearSCADA will automatically instigate a One Shot call to that outstation. Such actions include, for example, Control or Inching actions on points or pulse actions that are on a PSTN outstation. In such circumstances, ClearSCADA executes the actions, retrieves the data and then terminates the call.

For more information on PSTN communications, see PSTN Outstations and Communications in the ClearSCADA Guide to Advanced Drivers, and see Retrieving Data from PSTN Outstations in the ClearSCADA Guide to Advanced Drivers.

Use an outstation’s status attributes to ascertain information about the calls to that outstation (see Status Attributes Associated with Outstations on Advanced Drivers).

Also see Open Line, and see Promote Dial Out.


Drivers Guide - Open Line (Actions that are Common to Many Drivers)

Open Line

Associated with: PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

Security permission required to access this pick action: Retrieve Data

With systems on which telephone call duration costs do not apply, an Open Line call is sometimes used instead of a One Shot call. Use the Open Line pick action to instigate such a call.

With an Open Line call, ClearSCADA maintains communications with the outstation for a specified time, even if the server has retrieved the outstation’s data before that length of time is reached. The time for which the line remains open is specified on the PSTN tab of the Outstation Form (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers).

If supported by the outstation type, you can use the Extend Line pick action to extend the call.


Drivers Guide - Override (Actions that are Common to Many Drivers)

Override

Associated with: Points on which the Override feature is supported and enabled

Use the Override pick action to temporarily override a point’s value. You might want to use this action, for example, to specify a suitable value if ClearSCADA has detected a known fault that is causing an incorrect value to be reported. Once the detected fault has been corrected, use the Release Override action to revert back to using the point’s actual value—the value that is being reported by the outstation or scanner.

The Override pick action is only available on a point on which:

  • The Override feature is enabled (see the ClearSCADA Guide to Core Point Configuration).
  • Your User Account is allocated the Override/Release security permission.

Most drivers support master station overrides, whereby you override the value at the server.

Select the Override pick action to display the Override window.

Specify the required override value in the Value field. Depending on the type of point, you may be offered a combo list of point values, or need to specify a value within a particular range. The range or values from which you can choose are determined by the point’s configuration.

With analog and counter-type points, you need to specify a value within the range of values that are configured for that point.
With a digital point, you select a value from the list of values that are configured for the point.

Whenever a point is overridden:

  • An entry is logged in the Event Journal.
  • The point’s Override status attribute indicates that an override is in force.
  • The point’s color on displays such as Queries Lists indicates whether the override is:
  • A Master Station Override
  • A Parent Point Override.


Drivers Guide - Preferred Channel (Actions that are Common to Many Drivers)

Preferred Channel

Associated with: PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

Security permission required to access this pick action: Diagnostics

With PSTN communications, the association between an outstation and channel is only made during run time. If you want the ClearSCADA server to contact an outstation via a particular PSTN channel in preference to any other PSTN channels, use the Preferred Channel pick action to specify the channel.

If the channel is available for use when ClearSCADA attempts to contact the outstation via PSTN, the server will use that channel. If the preferred channel is not available, the server will use whichever PSTN channel is available at the time.

Select the Preferred Channel pick action to display the Preferred Channel window.

Use the Channel combo box to select the name of the PSTN channel that ClearSCADA is to use in preference to other PSTN channels, when contacting this outstation.

The combo list displays the full names of the PSTN channels that:

  • Are compatible with the outstation (use the same protocol)
  • Use the same PSTN Connection Type as the outstation (see PSTN Connection Types in the ClearSCADA Guide to Advanced Drivers)
  • Are configured as Dial Out Only, or Dial In and Out (see Defining PSTN Settings for a Channel in the ClearSCADA Guide to Advanced Drivers)
  • Have valid configuration
  • Are In Service.

Whenever a preferred PSTN channel is specified, you can use the outstation’s Preferred Channel status attribute to ascertain the name of that channel.

To allow ClearSCADA to use any available PSTN channel, rather than a specific channel, use the Preferred Channel pick action to specify the channel as None.


Drivers Guide - Promote Dial Out (Actions that are Common to Many Drivers)

Promote Dial Out

Associated with: Outstation sets; PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

This pick action is only available for an outstation or set on which:

  • The Promote Dial Out feature is enabled (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers, and see Defining Communication Settings in the ClearSCADA Guide to Advanced Drivers).
  • Your User Account is allocated the Promote security permission.

Use the Promote Dial Out pick action to temporarily increase the rate at which ClearSCADA retrieves data from one or more outstations (see Temporarily Increasing the Frequency with which an Outstation is Called in the ClearSCADA Guide to Advanced Drivers). When this pick action is used on an outstation, ClearSCADA sends One Shot requests to that particular outstation at a promoted rate, for the duration of the promotion. When executed on a set, ClearSCADA sends One Shot requests at a promoted rate to each of the outstations on that set. For more information on the order in which ClearSCADA contacts the outstations in a set, see One Shot.

Select the pick action to display the Promote Dial Out window.

Use the fields and check box to specify the required promotion:

  • Interval—Specify the frequency with which ClearSCADA sends One Shot requests to the outstation(s) while the promotion is in force. Enter the required interval, in the OPC Time Format.
  • Duration—Specify the total period for which dial-outs are promoted. Enter the required duration in the OPC Time Format.
  • One Shot Immediately—Select this check box for ClearSCADA to send a One Shot request to the outstation as soon as the Promote Dial Out request is executed.

Ensure that the check box is clear if ClearSCADA is to wait for the Offset to expire before sending the first One Shot request.

  • Offset—Specify the offset between ‘now’ and the time that ClearSCADA is to send its first, or next, One Shot call to the outstation (depending on the One Shot Immediately setting). Enter the required offset in the OPC Relative Time Format.

Example:

The Promote Dial Out pick action is triggered on a particular outstation. The action that is requested uses the settings that are displayed in the window shown above. This results in ClearSCADA sending a One Shot call 15 minutes after the promotion was requested, followed by further One Shot calls at 15-minute intervals, until the one-hour duration has elapsed. As such, the action results in a total of four One shot calls being sent to the outstation.

If the ‘One Shot Immediately’ check box had been selected, ClearSCADA would have sent a One Shot call as soon as ‘OK’ was selected on the Promote Dial Out window. This would have been followed by another One Shot call 15 minutes later, with further One Shot calls being sent at 15-minute intervals, until the one-hour duration had elapsed, so resulting in a total of five One-Shot calls.

The Promoted Dial Out defaults for the outstations on your system are specified using the ClearSCADA Server Configuration Tool (see Define the Default Promoted Dial Out Settings in the ClearSCADA Guide to Server Administration.

The Dial Out Promoted status attribute indicates whether dial-outs are promoted on a set or outstation.

Also see Cancel Promoted Dial Out.


Drivers Guide - Promote Scanning (Actions that are Common to Many Drivers)

Promote Scanning

Associated with: Direct or Shared outstations

The Promote Scanning pick action is only available on an outstation on which:

  • Scanning promotion is supported and enabled (see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers).
  • Your User Account is allocated the Promote security permission.

Many direct outstations can automatically be given scanning preference whenever any of their points are displayed on a client (see Define Whether an Outstation is Promoted While its Points are on Display in the ClearSCADA Guide to Advanced Drivers).

If required, you can also use the Promote Scanning pick action to temporarily increase the rate at which ClearSCADA scans an outstation for data.

Select the Promote Scanning pick action to display the Promote Scanning window.

In the Duration field, specify the period for which the promotion is to last. Enter the duration in the OPC Time Format—for example, 1M (for one minute). Once this interval elapses, ClearSCADA reverts to scanning the outstation at its usual rate.

The Scanning status attribute indicates if scanning is promoted on an outstation.

Also see Cancel Promoted Scanning.


Drivers Guide - Refresh (Actions that are Common to Many Drivers)

Refresh

Associated with: Scanners; outstations that support this feature

Security permission required to access this pick action: Retrieve Data

ClearSCADA typically scans devices for data on a scheduled basis. If required, you can use the Refresh pick action to scan a device on demand. Select the Refresh pick action to request a current data update of the points on a particular outstation or scanner. Depending on the protocol, a Refresh either:

  • Triggers an immediate scan of the outstation or scanner—The Refresh action completes once ClearSCADA has scanned each of the points on the outstation or scanner and has processed that data. This is the most common type of Refresh action. It typically applies to scanners on simple drivers, and to outstations on many advanced drivers.

The Source Refresh system color indicates when a Refresh is in progress.

If required, use the Cancel Refresh pick action to cease such a refresh.

  • Marks each point on the scanner or outstation as having data to report—The Refresh action completes immediately. In the next scan of the outstation or scanner, ClearSCADA retrieves current data from each of the points on that device, regardless of whether that data has changed since the last retrieval. This type of Refresh action applies to outstations on some advanced drivers.

The Refresh pick action is only available on an outstation that communicates via PSTN while that outstation is on line (for instance, during an Open Line call). When a call is not in progress, use the One Shot pick action to contact the outstation and ‘refresh’ that outstation’s data.

Do not confuse this Refresh pick action with the Refresh menu options or buttons that are available for various ClearSCADA displays, such as:

  • Status Displays—see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.
  • Lists—see Refresh the Data on a List other than an Alarms List in the ClearSCADA Guide to Lists.
  • ClearSCADA Server Status Tool—see Server Status Menu in the ClearSCADA Guide to the Server Status Tool.
  • Archive Volumes Manager—see Archiving in the ClearSCADA Guide to Server Administration.


Drivers Guide - Release Override (Actions that are Common to Many Drivers)

Release Override

Associated with: Points on which the Override feature is supported and enabled

Security permission required to access this pick action: Override/Release

Use this pick action to release an Override that is currently in force. (A point’s Override status attribute indicates whether a point’s value is currently overridden.)

An entry is logged in the Event Journal whenever an override is released.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Release.


Drivers Guide - Reset Call Statistics (Actions that are Common to Many Drivers)

Reset Call Statistics

Associated with: PSTN channels on advanced drivers; PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

Security permission required to access this pick action: Diagnostics

Use this pick action to reset the statistics about the number of Incoming Calls and Outgoing Calls that have been transmitted via a particular channel, or to and from a particular outstation.


Drivers Guide - Reset Comms Statistics (Actions that are Common to Many Drivers)

Reset Comms Statistics

Associated with: Outstations, including Slave outstations

Security permission required to access this pick action: Diagnostics

Use this pick action to reset an outstation’s Comms Statistics.


Drivers Guide - Reset Outgoing Call Quality Factor (Actions that are Common to Many Drivers)

Reset Outgoing Call Quality Factor

Associated with: PSTN channels that are chosen due to their higher quality factor, rather than the fewest total calls

Security permission required to access this pick action: Diagnostics

Use this pick action to reset a PSTN channel’s Outgoing Call Quality Factor.

The pick action is only available if:

  • The method used for determining which channel is to call a PSTN outstation is set to Use channel with highest quality (see Define how a PSTN Channel is Selected for Communications in the ClearSCADA Guide to Server Administration)
  • The channel’s Dial In/Out function is set to an option other than ‘Dial In Only’. (The option is specified on the Channel’s configuration Form.)


Drivers Guide - Reset Outstation (Actions that are Common to Many Drivers)

Reset Outstation

Associated with: Outstations on drivers that support this feature

Security permission required to access this pick action: Diagnostics

CAUTION

loss of communication

Use the Reset Outstation pick action with care. The affects of resetting an outstation vary, depending on the type of outstation. Many outstations support a Cold Reset, which is equivalent to power cycling the outstation. This typically results in any output points being reset to initial values, and any programs running in the outstation being restarted. The outstation will also be offline for a time.

Failure to follow these instructions can result in equipment damage.

Use the Reset Outstation pick action to reset an outstation. The type of reset that is performed depends on the protocol—refer to the outstation’s product documentation for information. With outstations that support more than one type of reset, a window is displayed, offering a set of reset options. The driver-specific documentation explains any such options where they exist.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Reset.


Drivers Guide - Reset Point Statistics (Actions that are Common to Many Drivers)

Reset Point Statistics

Associated with: Scanners; outstations, including Slave outstations

Use this pick action to reset the point statistics and/or process counts on the points on a scanner or outstation. The pick action is available if your User Account is allocated the Diagnostics security permission for the scanner or outstation and its dependants.

Select the pick action to display the Reset Point Statistics window.

Use the window’s check boxes to specify the statistics that ClearSCADA is to reset:

  • Point Statistics—Select this check box to reset the scanner or outstation’s Point Statistics.

Ensure that the check box is clear if you do not want to reset the Point Statistics.

  • Individual Point Process Counts—Select this check box to reset the Process Count of each point that is associated with the scanner or outstation. This is the equivalent of executing the Reset Process Count pick action on each of those points.

Ensure that the check box is clear if you do not want to reset every point’s Process Count.


Drivers Guide - Reset Process Count (Actions that are Common to Many Drivers)

Reset Process Count

Associated with: Points

Security permission required to access this pick action: Diagnostics

Use this pick action to reset an individual point’s Process Count statistics.

(To reset the Process Count on all of the points on a particular set or scanner, use the Reset Point Statistics pick action.)


Drivers Guide - Reset Serial Port Statistics (Actions that are Common to Many Drivers)

Reset Serial Port Statistics

Associated with: Channels that have a Serial connection

Security permission required to access this pick action: Diagnostics

Use this pick action to reset a channel’s Serial Port Statistics.


Drivers Guide - Reset Statistics (Actions that are Common to Many Drivers)

Reset Statistics

Associated with: Channels on advanced drivers

Security permission required to access this pick action: Diagnostics

Use this pick action to reset a channel’s statistics. The pick action typically resets a channel’s Comms Statistics and Message Count. Channels on some advanced drivers support other statistics that this pick action resets. The driver-specific documentation lists any such driver-specific channel attributes where this applies.


Drivers Guide - Switch Line (Actions that are Common to Many Drivers)

Switch Line

Associated with: Shared or Switched outstation sets; Shared outstations (other than those for which communications is fixed on one channel)

Security permission required to access this pick action: Switch Line

NOTE: Some simple driver channels support two lines and therefore also support the Switch Line pick action. Whenever the Switch Line pick action is supported, its functionality is summarized in the relevant driver-specific guide.
Most simple driver channels only support single connections and for such channels, any attempts to trigger the ‘Switch Line’ pick action or method in ClearSCADA will have no effect and will be ignored.

Shared and Switched outstations can communicate with ClearSCADA via either of two direct channels. With outstations on a Switched outstation set, all of the outstations have to use the same channel (see Switched Dual Channel in the ClearSCADA Guide to Advanced Drivers). With outstations on a Shared outstation set, communications can be ‘shared’ between the channels, so that some outstations use one channel, and other outstations use the other channel (see Shared Outstations in the ClearSCADA Guide to Advanced Drivers). The Balance status attribute indicates the percentage of outstations that are communicating via each line on a Shared outstation set.

With either setup, should ClearSCADA detect that communications on one channel (line) has failed, communications will usually switch to the other channel automatically. The exceptions to this are:

  • Any Shared outstations for which communications is fixed on a particular line, or on which Heartbeating is used and this indicates that the other channel has also failed.
  • Outstations in a Switched set, for which the other channel was last reported to be in a failed state.

If ClearSCADA detects that communications on both lines has failed:

  • With Shared outstations on which Line Hunting is used, the driver will keep switching the line to test each line in turn, until one or both lines become healthy again.
  • With Shared outstations on which Line Hunting is not enabled, the driver will switch once, away from the failed line that the outstations were using (if Heartbeating is used, the switch will only occur if the other channel is okay).
  • With outstations in Switched sets, automatic switching will cease.

With Shared outstations and both Shared and Switched outstation sets, you can use the Switch Line pick action to force switching to continue, or to force outstation(s) to use a particular line. Use the pick action on a set to force each of the outstations on that set to switch (other than any fixed outstations); use the pick action on a Shared outstation to change communications on that outstation only (or, if the outstation is configured as a Group Master, the communications of both that outstation and its Group Slaves).

Select the Switch Line pick action to display the Switch Line window.

Select the required option from the combo box:

  • Toggle Line—Switches communications to the channel (line) that is not presently being used. The lines are specified on the Outstation Set Form.
  • Line A: <Full name of channel>—Switches communications to the channel that is designated Line A (as specified on the Outstation Set Form).
  • Line B: <Full name of channel>—Switches communications to the channel that is designated Line B (as specified on the Outstation Set Form).
  • Preferred Line—ClearSCADA checks whether the channel being used is the one that is designated as the Preferred Line. If not, communications is switched to the Preferred Line.

With a Shared outstation that is configured as Independent, the Preferred Line is specified on that outstation’s Form (see Define a Shared Outstation’s Switching Capabilities in the ClearSCADA Guide to Advanced Drivers).

With a Shared outstation that is configured as a Group Slave, the Preferred Line is specified on the Group Master’s Outstation Form.

When using this pick action on a Shared Set, be aware that there may be a delay between individual outstations switching channels. Such a delay is specified on the Shared Set Form.

With both Switched and Shared outstations, should ClearSCADA detect that communications has failed on the chosen channel, it will automatically switch communications back to the other channel. With Switched Sets, ClearSCADA might need to detect that a specified number of outstations has failed before communications are switched back—such a requirement is specified on the Switched Set Form. This requirement does not apply should ClearSCADA detect that the channel itself has failed (for example, by detecting a COM port failure). In such circumstances, ClearSCADA will automatically switch communications back to the other channel, regardless of the number of outstations that it has detected as failed. Automatic switching of outstations in Switched Sets will not occur if the other channel was last reported to be in a failed state. With such a situation, use the Switch Line pick action to switch the outstations to the other channel once that channel is known to be healthy. (A channel’s state only updates when an attempt is made to communicate via that channel.) This also applies if ClearSCADA detect that both channels used by a Switched set have failed: once both channels are believed to be healthy, use the Switch Line pick action to switch the outstations to each of those channels. This will update each channel’s State in the database, allowing automatic switching to occur should the channel in use be detected as failed in future. For more information, see Switched Dual Channel in the ClearSCADA Guide to Advanced Drivers.

Further Information

Defining Channel Settings for a Switched Set in the ClearSCADA Guide to Advanced Drivers.

Defining Channel Settings for a Shared Set in the ClearSCADA Guide to Advanced Drivers.

Line Hunting: see Hunt for a Healthy Line if ClearSCADA Detects that both Lines have Failed in the ClearSCADA Guide to Advanced Drivers.

Heartbeating: see Poll Outstations on the Other Channel in the ClearSCADA Guide to Advanced Drivers.

Disable Switching.

Enable Switching.


Drivers Guide - Tune Alarm Limits (Actions that are Common to Many Drivers)

Tune Alarm Limits

Associated with: Analog and Counter-type points that support this feature

This pick action is only available on a point on which:

  • The Tune Limits feature is enabled
  • Your User Account is allocated the Tune Limits security permission
  • The point’s alarm limits are not configured to vary in value according to Time Profiles. (With points on some drivers, you can associate individual limits with Time Profiles. Any limits that are assigned Time Profiles will not be displayed in the Tune Alarm Limits window. If all of a point’s limits are assigned Time Profiles, the Tune Alarm Limits pick action will not be available for that point.)

Use the Tune Alarm Limits action to temporarily alter a point’s alarm limits during exceptional circumstances. For instance, in bad weather conditions when a flood situation is known to exist, you might want to tune a point’s limits to stop unnecessary alarms from being raised.

Select the Tune Alarm Limits pick action to display the Tune Alarm Limits window.

The window indicates the limits that are currently in force. The number of limits varies, depending on the type of point. For analog points, the point’s full range (Zero Scale to Full Scale) is displayed in parentheses on the right-hand side of the window.

Select the check boxes of those limit(s) that you want to tune and then specify the required temporary limits in the adjacent fields. Ensure that you specify values that are within the range that is configured for the point.

Tuning does not change the values of the alarm limits on the point’s configuration Form.

When tuning is in force:

  • An entry is logged in the Event Journal, listing the temporary limits. (Any limits that are profile-controlled, and therefore not tuned, are indicated by the word ‘Profile’.)
  • An additional Alarm Limits status attribute is included on the point’s Status display.
  • ClearSCADA downloads the tuned configuration to the outstation on which the point is located (providing configuration downloads are supported).
  • ClearSCADA compares any change in point value to the temporarily tuned limits, rather than the limits that are configured on the point’s configuration Form. Events and/or alarms are only generated if they exceed the tuned limits and take into account any Hysteresis or Persistence settings.

To remove any tuning, display the Tune Alarm Limits window and clear all of the check boxes. An entry will be logged in the Event Journal, stating that the Alarm Limits have been returned to their configured defaults.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name TuneLimits.

Also see Tune M/S Alarm Limits.

Further Information

Specify any Alarm Limit Profiles in the ClearSCADA Guide to Core Point Configuration.


Drivers Guide - Tune M/S Alarm Limits (Actions that are Common to Many Drivers)

Tune M/S Alarm Limits

Associated with: Analog points that are configured to use Master Station Alarm Limits

Use the Tune M/S Alarm Limits pick action to tune an analog point’s ‘master station’ alarm limits, as opposed to the point’s ‘standard’ alarm limits. The pick action is only available on an analog point on which:

  • Master Station Alarm Limits are used (see Master Station Alarm Limits in the ClearSCADA Guide to Core Point Configuration)
  • The Tune Limits feature is enabled for the Master Station Alarm Limits
  • Your User Account is allocated the Tune Limits security permission.

You tune an analog point’s ‘master station’ alarm limits in a similar way to its ‘standard’ alarm limits (see Tune Alarm Limits). Unlike ‘standard’ tuning, ClearSCADA does not download any tuned ‘master station’ alarm limits to the outstation, as ‘master station’ alarm limits are used purely by the ClearSCADA server.

When you select the Tune M/S Alarm Limits pick action, the Tune M/S Alarm Limits window is displayed. The number and description of the fields that are displayed in the window varies, depending on the point’s configuration (the number of ‘master station’ alarm limits is configurable on a per-point basis).

The window indicates the limits that are currently in force. The point’s full range (Zero Scale to Full Scale) is displayed in parentheses on the right-hand side of the window.

Select the check boxes of those limit(s) that you want to tune and then specify the required temporary limits in the adjacent fields. Ensure that you specify values that are within the range that is configured for the point.

Tuning does not change the values of the alarm limits on the point’s configuration Form.

When tuning is in force:

  • An entry is logged in the Event Journal, listing the temporary limits.
  • An additional M/S Alarm Limits status attribute is included on the point’s Status display.
  • ClearSCADA compares any change in point value to the temporarily tuned limits, rather than the limits that are configured on the point’s configuration Form. Events and/or alarms are only generated if they exceed the tuned limits and take into account any Hysteresis or Persistence settings.

To remove any tuning, display the Tune M/S Alarm Limits window and clear all of the check boxes. An entry will be logged in the Event Journal, stating that the Master Station Alarm Limits have been returned to their configured defaults.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name TuneLimits. Ensure that you specify that the method is associated with the CPointAGLimits class (the Master Station Alarm Limits aggregate).


Drivers Guide - Status Attributes that are Common to Many Drivers

Status Attributes that are Common to Many Drivers

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For general information on working with Status displays, see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

This section explains those status attributes that are common to many drivers.

For a list of the attributes that are common to a particular driver item (such as a channel, or point), go to the section for that item:

  • Status Attributes Associated with Servers on Simple Drivers
  • Status Attributes Associated with Channels on Simple Drivers
  • Status Attributes Associated with Scanners on Simple Drivers
  • Status Attributes Associated with Slave Sources on Simple Drivers
  • Status Attributes Associated with Channels on Advanced Drivers
  • Status Attributes Associated with Outstation Sets on Advanced Drivers
  • Status Attributes Associated with Outstations on Advanced Drivers
  • Status Attributes Associated with Slave Outstations on Advanced Drivers
  • Status Attributes Associated with Points
  • Status Attributes Associated with Pulse Actions.

Attributes are also listed alphabetically by status attribute name (see Alphabetical List of Status Attributes).

Be aware that some status attributes are only displayed once ClearSCADA has been in communications with a device and has been able to retrieve the relevant information.

Some drivers support additional driver-specific attributes—for attributes not listed in this guide or the ClearSCADA Guide to ViewX and WebX Clients, see the relevant driver guide.


Drivers Guide - Status Attributes Associated with Servers on Simple Drivers (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Servers on Simple Drivers

The servers on simple drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New servers only)
  • Last Modified
  • Exclusive Control User—(Only servers that are under Exclusive Control)
  • Alarm State
  • Alarm Last Updated
  • State Alarm
  • Source
  • State
  • Last Updated
  • Quality.

For information on server status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Channels on Simple Drivers (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Channels on Simple Drivers

The channels on simple drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New channels only)
  • Last Modified
  • Exclusive Control User—(Only channels that are under Exclusive Control)
  • Alarm State
  • Alarm Last Updated
  • State Alarm
  • Source
  • State
  • Last Updated
  • Quality
  • Comms Logging
  • Telnet.

For information on channel status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Scanners on Simple Drivers (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Scanners on Simple Drivers

The scanners on simple drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New scanners only)
  • Last Modified
  • Exclusive Control User—(Only scanners that are under Exclusive Control)
  • Alarm State
  • Alarm Last Updated
  • State Alarm
  • Source Name
  • Source
  • State
  • Last Updated
  • Quality
  • Point Statistics
  • Comms Statistics.

For information on scanner status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Slave Sources on Simple Drivers (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Slave Sources on Simple Drivers

The sources on simple Slave drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New Slave sources only)
  • Last Modified
  • Exclusive Control User—(Only Slave sources that are under Exclusive Control)
  • Alarm State
  • Alarm Last Updated
  • State Alarm
  • Source Name
  • Source
  • State
  • Comms Statistics.

For information on source status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Channels on Advanced Drivers (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Channels on Advanced Drivers

The channels on advanced drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New channels only)
  • Last Modified
  • Exclusive Control User—(Only channels that are under Exclusive Control)
  • Alarm State
  • Alarm Last Updated
  • Scan Status Alarm—(Channels on some advanced drivers)
  • State Alarm
  • Source
  • State
  • Last Updated
  • Quality
  • IO Logging
  • Serial Port Statistics—(Channels with serial connections only)
  • Comms Logging
  • Telnet
  • Comms Statistics
  • Message Count
  • Scan Quality—(Direct channels only)
  • Incoming Calls—(PSTN channels only)
  • Outgoing Calls—(PSTN channels only)
  • Outgoing Call Quality Factor—(PSTN channels that are selected for use by their call quality factor).

For information on channel status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Outstation Sets on Advanced Drivers (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Outstation Sets on Advanced Drivers

The outstation sets on advanced drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New sets only)
  • Last Modified
  • Exclusive Control User—(Only sets that are under Exclusive Control)
  • Quality
  • Dial Out Promoted—(Only sets on which PSTN Dial Out is enabled)
  • Switching—(Shared and Switched sets only)
  • Balance—(Shared sets only)
  • Current Channel—(Switched sets only).

For information on outstation set status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Outstations on Advanced Drivers (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Outstations on Advanced Drivers

NOTE: Slave outstations have a subset of these attributes (see Status Attributes Associated with Slave Outstations on Advanced Drivers).

The outstations on advanced drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New outstations only)
  • Last Modified
  • Exclusive Control User—(Only outstations that are under Exclusive Control)
  • Queued Request—(Outstations on which pick action requests are queued)
  • Alarm State
  • Alarm Last Updated
  • Dial In Overactive Alarm—(Outstations on which Dial In Overactive is enabled)
  • Comms State Alarm
  • Channel State Alarm
  • Protocol Alarm—(Displayed when supported by the driver)
  • Download Config Alarm—(Displayed when supported by the driver)
  • Source Name
  • Source
  • Network—(Network-connected outstations only)
  • State
  • Last Updated
  • Quality
  • Current Channel
  • Scanning—(Direct outstations, displayed only while scanning is promoted)
  • Comms Statistics
  • Last Polled
  • Point Statistics
  • Telephone Number—(PSTN outstations, or outstations on which PSTN fallback is enabled)
  • Preferred Channel—(Outstations for which a preferred PSTN channel is specified)
  • Incoming Calls—(PSTN outstations, or outstations that support PSTN fallback)
  • Last Good Incoming Call—(PSTN outstations, or outstations that support PSTN fallback)
  • Last Incoming Call Lost Comms—(PSTN outstations, or outstations that support PSTN fallback)
  • Outgoing Calls—(PSTN outstations, or outstations that support PSTN fallback)
  • Last Good Outgoing Call—(PSTN outstations, or outstations that support PSTN fallback)
  • Last Outgoing Call Lost Comms—(PSTN outstations, or outstations that support PSTN fallback)
  • Last Outgoing Call Not Established—(PSTN outstations, or outstations that support PSTN fallback)
  • Dial In Overactive—(Outstations on which the Dial Out feature is enabled)
  • Dial Out Promoted—(Outstations on which the Dial Out feature is enabled)
  • Switching—(Shared outstations that are ‘Independent’).

For information on outstation status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Slave Outstations on Advanced Drivers (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Slave Outstations on Advanced Drivers

With most advanced driver setups, ClearSCADA is the SCADA master. However, some drivers support slave functionality, whereby the ClearSCADA system acts as an outstation or similar device and reports any data changes back to its SCADA master (see Master-Slave Communications).

On systems on which ClearSCADA is a slave, the driver’s Slave outstations support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New Slave outstations only)
  • Last Modified
  • Exclusive Control User—(Only Slave outstations that are under Exclusive Control)
  • Alarm State
  • Alarm Last Updated
  • Comms State Alarm
  • Channel State Alarm
  • Protocol Alarm—(Displayed when supported by the driver)
  • Source Name
  • Source
  • Network—(Network connected Slave outstations only)
  • State
  • Last Updated
  • Quality
  • Current Channel
  • Comms Statistics
  • Last Polled
  • Point Statistics
  • Telephone Number—(PSTN Slave outstations only)
  • Preferred Channel—(Slave outstations for which a preferred PSTN channel is specified)
  • Incoming Calls—(PSTN Slave outstations only)
  • Outgoing Calls—(PSTN Slave outstations only).

For information on slave outstation status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Points (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Points

NOTE: Pulse actions have a subset of these attributes (see Status Attributes Associated with Pulse Actions).

Points on many drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New points only)
  • Last Modified
  • Exclusive Control User—(Only points that are under Exclusive Control)
  • Queued Request—(Output points for which pick action requests are queued)
  • Alarm State
  • Alarm Last Updated
  • No Change Alarm—(Points on which the No Change feature is enabled)
  • Control Alarm—(Output points only)
  • State Alarm
  • Source Name
  • Source
  • Parent Point—(Points that have a parent point)
  • Current Value
  • Current State
  • Last Updated
  • Current Quality
  • Override—(Where supported and enabled for a point)
  • Put Aside Value—(Only displayed while an Override is in force)
  • Put Aside State—(Only displayed while an Override is in force)
  • Put Aside Last Updated—(Only displayed while an Override is in force)
  • Put Aside Quality—(Only displayed while an Override is in force)
  • Previous Update Value
  • Previous Update State
  • Previously Updated
  • Previous Update Quality
  • Previous State
  • State Change Value
  • Last Changed State
  • State Change Quality
  • Process Count
  • Logged Value—(Points that have logged data)
  • Logged State—(Points that have logged data)
  • Logged Time—(Points that have logged data)
  • Logged Quality—(Points that have logged data)
  • Controls—(Output points only)
  • Alarm Limits—(Analog and Counter-type points for which the limits are currently tuned)
  • Current M/S State—(Analog points on which Master Station Alarm Limits are used)
  • M/S Alarm Limits—(Analog points on which one or more of the Master Station Alarm Limits are tuned).

For information on point status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Status Attributes Associated with Pulse Actions (Status Attributes that are Common to Many Drivers)

Status Attributes Associated with Pulse Actions

Pulse actions on several drivers support a combination of these status attributes:

  • Id
  • Full Name
  • Type
  • Created—(New pulse actions only)
  • Last Modified
  • Exclusive Control User—(Only pulse actions that are under Exclusive Control)
  • Queued Request—(Pulse actions for which pick action requests are queued)
  • Alarm State
  • Alarm Last Updated
  • Control Alarm
  • Source Name
  • Source
  • Current Quality
  • Control Active—(Pulse actions on advanced drivers only)
  • Last Control—(Pulse actions on advanced drivers only)
  • Last Pulse Action—(Pulse actions on advanced drivers only)
  • Controls.

For information on pulse action status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Alphabetical List of Status Attributes (Status Attributes that are Common to Many Drivers)

Alphabetical List of Status Attributes

The subsections within this section summarize the status attributes that are common to items on many drivers. Be aware that some attributes are only displayed once ClearSCADA has been in communications with a device and has been able to retrieve the relevant information.

The subsections within this section are arranged in alphabetical order, by status attribute name.

You can also display a list of the status attributes that are commonly associated with a particular driver item, such as a channel, or scanner (see Status Attributes that are Common to Many Drivers).

For information on accessing an item’s Status display, see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

These status attributes are common to items on many drivers:

  • Alarm Last Updated
  • Alarm Limits
  • Alarm State
  • Balance
  • Channel State Alarm
  • Comms Logging
  • Comms State Alarm
  • Comms Statistics
  • Control Active
  • Control Alarm
  • Controls
  • Created
  • Current Channel
  • Current M/S State
  • Current Quality
  • Current State
  • Current Value
  • Dial In Overactive
  • Dial In Overactive Alarm
  • Dial Out Promoted
  • Download Config Alarm
  • Exclusive Control User
  • Full Name
  • Id
  • Incoming Calls
  • IO Logging
  • Last Changed State
  • Last Control
  • Last Good Incoming Call
  • Last Good Outgoing Call
  • Last Incoming Call Lost Comms
  • Last Modified
  • Last Outgoing Call Lost Comms
  • Last Outgoing Call Not Established
  • Last Polled
  • Last Pulse Action
  • Last Updated
  • Logged Quality
  • Logged State
  • Logged Time
  • Logged Value
  • Message Count
  • M/S Alarm Limits
  • Network
  • No Change Alarm
  • Outgoing Call Quality Factor
  • Outgoing Calls
  • Override
  • Parent Point
  • Point Statistics
  • Preferred Channel
  • Previous State
  • Previous Update Quality
  • Previous Update State
  • Previous Update Value
  • Previously Updated
  • Process Count
  • Protocol Alarm
  • Put Aside Last Updated
  • Put Aside Quality
  • Put Aside State
  • Put Aside Value
  • Quality
  • Queued Request
  • Scan Quality
  • Scan Status Alarm
  • Scanning
  • Serial Port Statistics
  • Source
  • Source Name
  • State
  • State Alarm
  • State Change Quality
  • State Change Value
  • Switching
  • Telephone Number
  • Telnet
  • Type.

For information on any status attributes that are not listed above, see the driver-specific documentation.


Drivers Guide - Alarm Limits (Status Attributes that are Common to Many Drivers)

Alarm Limits

Associated with: Analog and Counter-type points for which alarm limits are currently tuned

This status attribute is only displayed for points on which:

  • The Tune Limits feature is supported and enabled
  • One or more alarm limits are currently tuned (see Tune Alarm Limits).

The attribute lists:

  • The values to which the alarm limits are temporarily tuned.
  • The name of the user that was logged onto the workstation when the tuning occurred
  • The date and time that the tuning occurred.

Example:

Tuned to HH:95.00 H:80.00 L:25.00 LL:10.00 by RGrosso at 29/Nov/2007 14:09:22.648

With points on some drivers, you can associate individual limits with Time Profiles. Profile-controlled limits cannot be tuned. If any limits are tuned on a point on which other limits are profile-controlled, the Alarm Limits status attribute indicates which of those limits are profile-controlled.

Example:

Tuned to HH:95.00 H:Profile L:25.00 LL:10.00 by RGrosso at 29/Nov/2007 14:09:22.648

Also see M/S Alarm Limits.


Drivers Guide - Balance (Status Attributes that are Common to Many Drivers)

Balance

Associated with: Shared outstation sets

The outstations in a Shared set do not have to use the same channel as each other (see Shared Outstations in the ClearSCADA Guide to Advanced Drivers).

The Balance status attribute indicates the percentage of outstations that are communicating via each channel in a set. (Channels are defined as Line A or Line B on the Outstation Set Form (see Defining Channel Settings for a Shared Set in the ClearSCADA Guide to Advanced Drivers).

Example:

A particular Shared Outstation Set contains 12 outstations. The set’s Balance attribute displays the following:

Line A: 50% Line B: 25% No multidrop comms: 25%
(Indicating that 6 of the set’s outstations are communicating via the channel that is defined as Line A; 3 outstations are communicating via Line B; and the remaining 3 outstations are not active on either channel (presumably because they are not In Service, or have configuration that ClearSCADA deems is invalid).)


Drivers Guide - Channel State Alarm (Status Attributes that are Common to Many Drivers)

Channel State Alarm

Associated with: Outstations, including Slave outstations

This status attribute indicates whether the channel via which the outstation is communicating, or attempting to communicate, is healthy.

Possible states: Displays one of the Standard Alarm States.

If this attribute indicates that ClearSCADA has detected a problem, look at other status attributes, such as the outstation’s Comms State Alarm, State, and Quality attributes, and the channel’s status attributes, to ascertain the cause. Event Journal messages should also provide further clarification.

For further information on resolving communications problems, see Troubleshooting in the ClearSCADA Guide to Advanced Drivers.


Drivers Guide - Comms Logging (Status Attributes that are Common to Many Drivers)

Comms Logging

Associated with: Channels

This status attribute indicates whether ClearSCADA is logging the ‘good’ communications on a channel (see Communications Logging Status in the ClearSCADA Guide to Server Administration). Also see Communications Logging in the ClearSCADA Guide to Server Administration.

Further Information

Enable Comms Logging.

Disable Comms Logging.


Drivers Guide - Comms State Alarm (Status Attributes that are Common to Many Drivers)

Comms State Alarm

Associated with: Outstations, including Slave outstations

This status attribute indicates whether communications between the driver and the outstation is healthy.

Possible States: Displays one of the Standard Alarm States.

If this attribute displays an alarm condition, but the outstation’s Channel State Alarm attribute indicates a healthy channel, this suggests that ClearSCADA has detected a problem with the outstation, rather than the channel.

Also see State.

For information on resolving communications problems, see Troubleshooting in the ClearSCADA Guide to Advanced Drivers.


Drivers Guide - Comms Statistics (Status Attributes that are Common to Many Drivers)

Comms Statistics

Associated with: Scanners; Slave sources; most channels on advanced drivers; outstations; Slave outstations

This status attribute displays statistics about the communications with or via a particular item. The information that the attribute displays varies, depending on the type of item with which the attribute is associated.

With a scanner on a simple driver, the statistics that are displayed vary, depending on the type of scanner—see the driver-specific documentation for details.

With a Slave source on a simple driver, the Comms Statistics status attribute displays the number of times that the SCADA master has successfully or unsuccessfully read data from that source.

Example:

10 good reads, 2 bad reads

With a channel on an advanced driver, the Comms Statistics status attribute displays the time period for which the various channel statistics apply. If the Reset Statistics pick action has been used to reset the channel’s statistics, two Comms Statistics entries are displayed—the lower entry lists the time period for which the previous set of statistics applies, the upper entry lists the date and time at which the current statistics commenced.

On a channel on which non-continuous polling is used, the Communication Statistics Updates fields on the Channel Form’s Scan Parameters tab specify when the statistics are updated (see Defining the Communication Statistics Update Rate in the ClearSCADA Guide to Advanced Drivers).

Example:

Comms. Statistics Since 17/Mar/2008 09:24:46.116

Comms. Statistics Between 05/Dec/2007 10:12:05.296 and 17/Mar/2008 09:24:46.116

The actual statistics to which the time periods apply are listed below each Comms Statistics entry. Such statistics include a channel’s Message Count.

NOTE: Direct channels on some advanced drivers support a Scan Statistics status attribute, rather than the Comms Statistics status attribute. The driver-specific documentation lists any such driver-specific channel attributes where this applies.

With an outstation on an advanced driver, the Comms Statistics status attribute displays information about the success, or otherwise, of the communications between the ClearSCADA server and that particular outstation.

The attribute displays the number of:

  • Good Messages—A count of the pairs of messages and corresponding replies that have been transmitted successfully between the outstation and ClearSCADA since the statistics were last reset. Each pairing of original transmission and corresponding reply (providing both are successful) count as one good message.
  • Unsolicited Messages—Messages that the outstation has sent to the server to inform ClearSCADA of alarms or other data that is awaiting retrieval from the outstation.

Not all outstations support transmission of unsolicited messages.

  • Bad Messages—Validly framed messages that either contained unrecognized content (content that was not correct for the request), or that rejected requests such as Control actions.
  • No Replies—Messages for which the expected reply was not received within the necessary time period.
  • Errors—Any errors reported in response to transmitted messages. For instance, reports of messages being corrupt (typically check sum errors, indicating that a packet has become corrupt during transmission).
  • Polls—The number of times that ClearSCADA has polled (scanned) the outstation for data. A poll can comprise one or more messages and is used to collect primary (current) and secondary (logged, time stamped) data. Other actions (such as controls) are not included in this count.

If the Reset Comms Statistics pick action has been used to reset the statistics on an outstation, two Comms Statistics entries are displayed—the lower entry lists the previous communications statistics, the upper entry is ‘live’ and logs the communications statistics since the pick action was last used.

Example:

56 good messages, 5 unsolicited messages, 3 bad messages, 4 no replies, 0 errors, 54 polls since 18/Oct/2007 11:03:25:217

13560 good messages, 55 unsolicited messages, 13 bad messages, 34 no replies, 0 errors, 13547 polls between 05/Oct/2007 09:57:29.642 and 18/Oct/2007 11:03:25:217

(To ascertain similar statistics for all of the outstations on a particular channel, as opposed to the statistics for a single outstation, look at the channel’s Message Count status attribute.)

With a Slave outstation on an advanced driver, the Comms Statistics status attribute displays information about the success, or otherwise, of the communications between the Slave outstation (ClearSCADA) and its SCADA master.

The attribute displays the number of:

  • Good Messages—A count of the pairs of valid messages and corresponding replies that have been transmitted successfully between the Slave outstation (ClearSCADA) and its SCADA master since the statistics were last reset. Each pairing of original transmission and corresponding reply (providing both are successful) count as one good message.
  • Unsolicited Messages—Messages transmitted between the Slave outstation (ClearSCADA) and its SCADA master in response to, and including, requests for that data from the SCADA master.

With a Slave outstation, the Comms Statistics attribute will typically indicate many more unsolicited messages than solicited messages, as each poll from the SCADA master is an unsolicited message. Only messages that the Slave outstation sends to its SCADA master to inform it that the Slave has alarms or other data awaiting retrieval are treated as solicited messages.

  • Bad Messages—Validly framed messages that either contained unrecognized content (content that was not correct for the request), or that rejected requests such as Control actions.
  • No Replies—Messages for which the expected reply was not received within the necessary time period.
  • Errors—Any errors reported in response to transmitted messages. For instance, reports of messages being corrupt (typically check sum errors, indicating that a packet has become corrupt during transmission).
  • Polls—This count is not used on Slave outstations.

Again, if the Reset Comms Statistics pick action has been used to reset the statistics on a Slave outstation, two Comms Statistics entries are displayed—the lower entry lists the previous communications statistics, the upper entry is ‘live’ and logs the communications statistics since the pick action was last used.


Drivers Guide - Control Active (Status Attributes that are Common to Many Drivers)

Control Active

Associated with: Pulse actions on advanced drivers

This status attribute indicates whether a Control or Inching action is currently in progress on a pulse action.

Possible states:

  • True
  • False.

Also see Last Pulse Action, and see Last Control.


Drivers Guide - Control Alarm (Status Attributes that are Common to Many Drivers)

Control Alarm

Associated with: Output points; pulse actions

This status attribute indicates the success, or otherwise, of the last control activated on this point or pulse action. (Controls are triggered using the Control or Inching pick actions.)

Possible states: Displays one of the Standard Alarm States.

Also see Controls.


Drivers Guide - Controls (Status Attributes that are Common to Many Drivers)

Controls

Associated with: Output points; pulse actions

This status attribute indicates whether controls are currently Enabled or Disabled on a point.

Also see Control Alarm.

Further Information

Disable Controls.

Enable Controls.


Drivers Guide - Current Channel (Status Attributes that are Common to Many Drivers)

Current Channel

Associated with: Switched sets; outstations; Slave outstations

This status attribute displays the name and location of the channel with which the outstation or set is currently communicating. This comprises the given name of the channel (as specified on the Outstation Set Form), including the full path to that channel in the database. Dot separators separate the various elements of the path (the hierarchy of groups within which the channel resides).

With outstations that are communicating via PSTN, the attribute is only displayed while a dial in or dial out call is in progress.

Example:

Western Region.Area 1.Channel 12.
(Indicating that the channel via which an outstation is currently communicating is ‘Channel 12’. The channel is located in the group ‘Area 1’, which itself is located in the ‘Western Region’ group.)


Drivers Guide - Current M/S State (Status Attributes that are Common to Many Drivers)

Current M/S State

Associated with: Analog points on which Master Station Alarm Limits are used

This attribute is displayed in place of the Current State for analog points on which Master Station Alarm Limits are used (see Master Station Alarm Limits in the ClearSCADA Guide to Core Point Configuration).

Use the attribute in conjunction with other attributes to assess the reliability of the point’s data.

(The possible states for a point are specified on a per-point basis, on the corresponding Point Form.)

Also see M/S Alarm Limits.


Drivers Guide - Current Quality (Status Attributes that are Common to Many Drivers)

Current Quality

Associated with: Points; pulse actions

Points have several Quality attributes.

The Current Quality status attribute indicates the reliability of a point’s Current Value and/or Current State, or the reliability of a pulse’s actions.

For a comprehensive list of quality values, see Quality.

Also see Previous Update Quality.


Drivers Guide - Current State (Status Attributes that are Common to Many Drivers)

Current State

Associated with: Points

This status attribute displays a point’s current state (rather than its Current Value).

Use the attribute in conjunction with other attributes, such as Current Quality to assess the reliability of the point’s data.

(The possible states for a point are specified on a per-point basis, on the corresponding Point Form.)

Also see Previous Update State, and see Current M/S State.


Drivers Guide - Current Value (Status Attributes that are Common to Many Drivers)

Current Value

Associated with: Points

This status attribute displays a point’s current value (rather than its Current State).

Use the attribute in conjunction with other attributes, such as Current Quality to assess the reliability of the point’s data.

(The possible values for a point are specified on a per-point basis, on the corresponding Point Form.)

Also see Previous Update Value.


Drivers Guide - Dial In Overactive (Status Attributes that are Common to Many Drivers)

Dial In Overactive

Associated with: PSTN outstations or outstations on which PSTN fallback is enabled

This status attribute is only displayed for outstations on which the Dial In Overactive feature is supported and enabled (see Define Dial In Overactive Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers).

The attribute lists the number of incoming calls that the ClearSCADA server has received from this outstation since the start of the dial-in period. The attribute also indicates how many incoming calls the outstation can instigate in total before it is deemed to be dialing in too often.

The statistics reset automatically at the end of the dial-in period. (The period is specified on the PSTN tab of the Outstation Form).

Example:

3 incoming call(s) since 27/Nov/2007 00:00:00.000 (maximum 10 calls)
(Indicating that an outstation has completed 3 incoming calls to the server during the current dial-in period. The outstation can make a maximum of 10 calls per dial-in period before it is deemed to be dialing in too often.)

Also see Dial In Overactive Alarm.


Drivers Guide - Dial In Overactive Alarm (Status Attributes that are Common to Many Drivers)

Dial In Overactive Alarm

Associated with: PSTN outstations or outstations on which PSTN fallback is enabled

This status attribute is only displayed for outstations on which the Dial In Overactive feature is enabled (see Define Dial In Overactive Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers).

The status attribute indicates whether the outstation is currently overactive and dialing in too often. The attribute automatically reverts to Enabled Inactive at the end of each dial-in period. (The period is specified on the PSTN tab of the Outstation Form).

Possible states: Displays one of the Standard Alarm States.

An alarm condition indicates that the outstation is deemed to be dialing in to the server too often. Refer to the Dial In Overactive attribute for the maximum number of calls that the outstation is expected to instigate, compared to the actual number of calls that have occurred so far.


Drivers Guide - Dial Out Promoted (Status Attributes that are Common to Many Drivers)

Dial Out Promoted

Associated with: Outstation sets; PSTN outstations or outstations on which PSTN fallback is enabled

This status attribute is only displayed if the Promote Dial Out feature is enabled for an outstation or outstation set (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers, or for sets, see Defining Communication Settings in the ClearSCADA Guide to Advanced Drivers).

The attribute indicates whether retrieval of data is currently promoted (occurring at a more frequent rate than usual) on the outstation or set.

Possible states:

  • Yes
  • No.

Further Information

Promote Dial Out.

Cancel Promoted Dial Out.


Drivers Guide - Download Config Alarm (Status Attributes that are Common to Many Drivers)

Download Config Alarm

Associated with: Outstations that support downloading of configuration from ClearSCADA

This status attribute indicates whether the last request to Download Configuration to an outstation completed successfully.

Possible states: Displays one of the Standard Alarm States.


Drivers Guide - Incoming Calls (Status Attributes that are Common to Many Drivers)

Incoming Calls

Associated with: PSTN channels; PSTN outstations, including Slave PSTN outstations; outstations, including Slave outstations, on which PSTN fallback is enabled

This status attribute displays summary information about the incoming calls on a particular channel, or sent by a particular outstation, since the call statistics were last reset.

Example:

6 call(s) (0 terminated unexpectedly, 0 did not establish) of duration 54S since 05/Nov/2007 10:08:59.875

If the Reset Call Statistics pick action has been used to reset the statistics, two entries are displayed—the lower entry lists the previous statistics, the upper entry is ‘live’ and logs the call statistics since the pick action was last used:

Example:

No calls since 23/Nov/2007 08:07:47.266

124 call(s) (0 terminated unexpectedly, 0 did not establish) of duration 19M 24S between 09/Apr/2007 13:41:32.290 and 23/Nov/2007 08:07:47.266

Also see Outgoing Calls.

With an outstation, you can use the Incoming Calls attribute in conjunction with these attributes:

  • Last Good Incoming Call
  • Last Incoming Call Lost Comms.


Drivers Guide - IO Logging (Status Attributes that are Common to Many Drivers)

IO Logging

Associated with: Channels on advanced drivers

This status attribute indicates whether ClearSCADA is logging the communications on a channel, including data that was discarded by the driver (see Communications Logging Status in the ClearSCADA Guide to Server Administration).

For more information, see Communications Logging in the ClearSCADA Guide to Server Administration.

Possible states:

  • Enabled
  • Disabled.

Further Information

Enable IO Logging.

Disable IO Logging.


Drivers Guide - Last Changed State (Status Attributes that are Common to Many Drivers)

Last Changed State

Associated with: Points that are, or have been, In Service

This status attribute displays the date and time at which a point’s state changed from its Previous State to its Current State.

Use the attribute in conjunction with the State Change Quality status attribute.

Example:

02/Nov/2007 13:28:12.743


Drivers Guide - Last Control (Status Attributes that are Common to Many Drivers)

Last Control

Associated with: Pulse actions on advanced drivers

This status attribute displays the date and time of the last control to be executed on a pulse action.

Example:

28/Nov/2007 14:02:18.529

Also see Last Pulse Action, and see Control Active.


Drivers Guide - Last Good Incoming Call (Status Attributes that are Common to Many Drivers)

Last Good Incoming Call

Associated with: PSTN outstations or outstations on which PSTN fallback is enabled

This attribute displays the date and time of the last successful call that the outstation made to ClearSCADA. The attribute displays the time at which the call commenced.

The information is updated whenever an incoming call completes successfully.

Example:

20/Mar/2008 12:41:08.140

Also see the Incoming Calls attribute, which provides a summary of the incoming calls since the statistics were last reset.


Drivers Guide - Last Good Outgoing Call (Status Attributes that are Common to Many Drivers)

Last Good Outgoing Call

Associated with: PSTN outstations or outstations on which PSTN fallback is enabled

This attribute displays the date and time of the last call to be sent successfully from ClearSCADA to the outstation. The attribute is only displayed once such a call has been made.

Example:

20/Mar/2008 16:48:05.971

Also see the Outgoing Calls attribute, which provides a summary of the outgoing calls since the statistics were last reset.


Drivers Guide - Last Incoming Call Lost Comms (Status Attributes that are Common to Many Drivers)

Last Incoming Call Lost Comms

Associated with: PSTN outstations or outstations on which PSTN fallback is enabled

This attribute displays the date and time of the last incoming call for which communications were established, but which then terminated unexpectedly. The attribute is only displayed once such a call has occurred.

Example:

20/Mar/2008 12:41:08.140

Also see the Incoming Calls attribute, which provides a summary of the incoming calls since the statistics were last reset.


Drivers Guide - Last Outgoing Call Lost Comms (Status Attributes that are Common to Many Drivers)

Last Outgoing Call Lost Comms

Associated with: PSTN outstations or outstations on which PSTN fallback is enabled

This attribute displays the date and time of the last outgoing call for which communications were established, but which then terminated unexpectedly. The attribute is only displayed once such a call has occurred.

Example:

20/Mar/2008 16:48:05.971

Also see the Outgoing Calls attribute, which provides a summary of the outgoing calls since the statistics were last reset.


Drivers Guide - Last Outgoing Call Not Established (Status Attributes that are Common to Many Drivers)

Last Outgoing Call Not Established

Associated with: PSTN outstations or outstations on which PSTN fallback is enabled

This attribute displays the date and time of the last outgoing call for which communications could not be established with the outstation. The attribute is only displayed once such a call has occurred.

Example:

20/Mar/2008 16:53:21.732

Also see the Outgoing Calls attribute, which provides a summary of the outgoing calls since the statistics were last reset.


Drivers Guide - Last Polled (Status Attributes that are Common to Many Drivers)

Last Polled

Associated with: Outstations, including Slave outstations

This status attribute displays the date and time that the server last polled (scanned) the outstation.

(With a Slave outstation, this is the last time that the Slave’s SCADA master scanned the Slave (the ClearSCADA server) for data. The SCADA master might be another ClearSCADA server or a third-party server.)

Example:

19/Nov/2007 09:11:34.361

For new outstations that have not yet gone ‘live’, the Last Polled attribute displays the value ‘Never’.


Drivers Guide - Last Pulse Action (Status Attributes that are Common to Many Drivers)

Last Pulse Action

Associated with: Pulse actions on advanced drivers

This status attribute displays the last action to be executed successfully on a pulse action. The action’s description is that which is specified on the Pulse Action Form (see Define the Actions that a Pulse Undertakes in the ClearSCADA Guide to Core Point Configuration).

Also see Control Active, and see Last Control.


Drivers Guide - Last Updated (Status Attributes that are Common to Many Drivers)

Last Updated

Associated with: Driver items other than Slave sources, outstation sets, and pulse actions

This status attribute indicates the date and time at which the item’s data was last updated in the database.

Example:

19/Nov/2007 08:22:35.140


Drivers Guide - Logged Quality (Status Attributes that are Common to Many Drivers)

Logged Quality

Associated with: Points that have logged data

This status attribute indicates the reliability of the latest logged (time stamped) data to be retrieved for a point.

If logged data is retrieved for the point, this attribute is updated whenever new logged data is retrieved, regardless of whether ClearSCADA actually stores that data historically.

For a comprehensive list of quality values, see Quality.

Use the status attribute in conjunction with the Logged State, Logged Time, and Logged Value status attributes for comprehensive information about the status of a point’s logged data.


Drivers Guide - Logged State (Status Attributes that are Common to Many Drivers)

Logged State

Associated with: Points that have logged data

This status attribute indicates the latest logged (time stamped) point state to be retrieved for a point.

If logged data is retrieved for the point, this attribute is updated whenever new logged data is retrieved, regardless of whether ClearSCADA actually stores that data historically. ClearSCADA only logs the data historically if the Historic feature is enabled for the point and the data meets the historic storage criteria (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

Use this status attribute in conjunction with the Logged Quality, Logged Time, and Logged Value status attributes for comprehensive information about the status of a point’s logged data.


Drivers Guide - Logged Time (Status Attributes that are Common to Many Drivers)

Logged Time

Associated with: Points that have logged data

This status attribute indicates the date and time of the latest logged (time stamped) data to be retrieved for a point.

If logged data is retrieved for the point, this attribute is updated whenever new logged data is retrieved, regardless of whether ClearSCADA actually stores that data historically. (The time indicates the time stamp that was reported with the data, not the time that ClearSCADA stores any such data historically.)

Use this status attribute in conjunction with the Logged Quality, Logged State, and Logged Value status attributes for comprehensive information about the status of a point’s logged data.


Drivers Guide - Logged Value (Status Attributes that are Common to Many Drivers)

Logged Value

Associated with: Points that have logged data

This status attribute indicates the latest logged (time stamped) point value to be retrieved for a point.

If logged data is retrieved for the point, this attribute is updated whenever new logged data is retrieved, regardless of whether ClearSCADA actually stores that data historically. ClearSCADA only logs the data historically if the Historic feature is enabled for the point and the data meets the historic storage criteria (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

Use the Logged Value status attribute in conjunction with the Logged Quality, Logged State, and Logged Time status attributes for comprehensive information about the status of a point’s logged data.


Drivers Guide - Message Count (Status Attributes that are Common to Many Drivers)

Message Count

Associated with: Channels on advanced drivers

This status attribute displays statistics about the success, or otherwise, of communications messages (‘data packets’) transmitted over a particular channel.

The attribute displays the number of:

  • Messages—A count of the messages that ClearSCADA has received and/or transmitted via the channel since the statistics were last reset, regardless of whether those messages were received successfully by the intended target communications equipment. The message count includes, if applicable, any unsolicited messages received from outstations on the channel, and any messages that ClearSCADA has broadcast to multiple outstations.
  • Replies—Messages that ClearSCADA has received in response to messages that it has sent via this channel. This includes any negative replies.
  • Unsolicited—Messages that outstations have sent to ClearSCADA via this channel, in order to report that they have alarms or other data awaiting retrieval.
  • Timeouts—Transmission timeouts and/or the number of times that no reply has been received from an outstation or other device in response to a transmitted message.
  • Errors—Any errors reported by the outstations or other devices, in response to messages transmitted via this channel. For instance, any reports of messages being corrupt.

If the Reset Statistics pick action has been used to reset the count, two entries are displayed—the lower entry lists the previous Message Count, the upper entry is ‘live’ and lists the Message Count since the pick action was last used. The period to which each Message Count applies is indicated by the channel’s Comms Statistics attribute.

Example:

15 messages, 13 replies, 0 unsolicited, 2 timeouts, 0 errors

13564254 messages, 13562911 replies, 55 unsolicited, 382 timeouts, 0 errors

Use the Message Count status attribute in conjunction with the channel’s Comms Statistics attribute to ascertain the time period for which each set of statistics applies.

To ascertain which of the above statistics might relate to a particular outstation on the channel, look at that outstation’s Comms Statistics status attribute. (Be aware that the outstation’s attribute statistics do not take into account which channel(s) were used to communicate with that outstation.)


Drivers Guide - M/S Alarm Limits (Status Attributes that are Common to Many Drivers)

M/S Alarm Limits

Associated with: Analog Points for which Master Station alarm limits are currently tuned

This status attribute is only displayed for analog points on which:

  • Master Station Alarm Limits are used (see Master Station Alarm Limits in the ClearSCADA Guide to Core Point Configuration)
  • The Tune Limits feature is supported and enabled on those Master Station alarm limits
  • One or more Master Station alarm limits are currently tuned (see Tune M/S Alarm Limits).

The attribute lists:

  • The values to which the Master Station alarm limits are temporarily tuned (the actual number of limits is configurable on a per point basis)
  • The name of the user that was logged onto the workstation when the tuning occurred
  • The date and time that the tuning occurred.

Example:

Tuned to 95.00 90.00 87.00 80.00 20.00 15.00 10.00 5.00 by PMalin at 02/Jun/2008 14:44:47.063
(For an analog points that has four High and four Low master station alarm limits configured.)

Also see Alarm Limits.


Drivers Guide - Network (Status Attributes that are Common to Many Drivers)

Network

Associated with: Network-connected outstations and Slave outstations

The Network status attribute displays the outstation’s host address and port number, separated by a colon.

If a Dual Network is used, two entries are displayed—one for Network A and another for Network B.

The settings are as per those specified on the Network tab of the outstation’s configuration Form (see Define an Outstation’s Network Properties in the ClearSCADA Guide to Advanced Drivers).


Drivers Guide - No Change Alarm (Status Attributes that are Common to Many Drivers)

No Change Alarm

Associated with: Points on which the No Change feature is enabled

Many types of point support ClearSCADA’s No Change feature (see Detect Whether a Point Value has Stopped Changing in the ClearSCADA Guide to Core Point Configuration). When this feature is enabled, the No Change Alarm status attribute indicates whether the point’s value has stopped changing.

Possible states: Displays one of the Standard Alarm States.


Drivers Guide - Outgoing Call Quality Factor (Status Attributes that are Common to Many Drivers)

Outgoing Call Quality Factor

Associated with: PSTN channels that are chosen due to their higher quality factor, rather than the fewest total calls

This status attribute is only displayed if:

  • The method used for determining which channel is to call a PSTN outstation is set to Use channel with highest quality (see Define how a PSTN Channel is Selected for Communications in the ClearSCADA Guide to Server Administration)
  • The channel’s Dial In/Out function is set to an option other than ‘Dial In Only’. (The option is specified on the Channel’s configuration Form.)

The status attribute indicates the channel’s current call quality factor and the date and time at which that quality factor was last updated (the date and time of the last outgoing call via the channel).

Example:

5 last updated at 06/Jul/2009 16:25:04.832


Drivers Guide - Outgoing Calls (Status Attributes that are Common to Many Drivers)

Outgoing Calls

Associated with: PSTN channels; PSTN outstations, including Slave PSTN outstations; Outstations, including Slave outstations, on which PSTN fallback is enabled

This status attribute displays summary information about the outgoing calls on a particular channel, or from a particular outstation, since the call statistics were last reset.

Example:

40 call(s) (2 terminated unexpectedly, 0 did not establish) of duration 22M 11S since 05/Nov/2007 10:08:59.875

If the Reset Call Statistics pick action has been used to reset the statistics, two entries are displayed—the lower entry lists the previous statistics, the upper entry is ‘live’ and logs the call statistics since the pick action was last used:

Example:

No calls since 23/Nov/2007 08:07:47.266

1634 call(s) (8 terminated unexpectedly, 1 did not establish) of duration 15H 6M 11S between 09/Apr/2004 13:41:32.290 and 23/Nov/2007 08:07:47.266

Also see Incoming Calls.

With an outstation, you can use the Outgoing Calls attribute in conjunction with these attributes:

  • Last Good Outgoing Call
  • Last Outgoing Call Lost Comms
  • Last Outgoing Call Not Established.


Drivers Guide - Override (Status Attributes that are Common to Many Drivers)

Override

Associated with: Points on which the Override feature is supported and enabled

The Override status attribute indicates whether a point’s value is currently overridden at the Master Station (ClearSCADA server).

When overridden, the attribute also displays the name of the user that was logged on to the node (workstation) from which the override was triggered, at the time that the override request was made.

The attribute displays None when no override is in force.

Example:

Overridden at Master Station by JDJefferson
(Indicating that a point is currently overridden at the server. The logged on user at the time that the override came into force was ‘JDJefferson’.)

While a local override is in force, the point value and state that were ‘put aside’ in favor of the locally overridden value are indicated by the Put Aside Value and Put Aside State status attributes, respectively.

Also see Put Aside Last Updated, and see Put Aside Quality.

Further Information

Set an Override.

Release Override.


Drivers Guide - Parent Point (Status Attributes that are Common to Many Drivers)

Parent Point

Associated with: Derived Points (points that have a ‘parent’ point)

Some drivers support ‘derived’ points—points that calculate their value from the value of another point (the derived point’s Parent point).

This status attribute displays the name and location of the derived point’s parent point. This comprises the given name of the parent point (as specified on the derived point’s configuration Form), including the full path to that point in the database. Dot separators separate the various elements of the path (the hierarchy of groups within which the parent point resides).

Example:

Western Region.Area 1.Switch 5.
(Indicating that a derived point’s parent point is ‘Switch 5’. The parent point is located in the group ‘Area 1’, which itself is located in the ‘Western Region’ group.)


Drivers Guide - Point Statistics (Status Attributes that are Common to Many Drivers)

Point Statistics

Associated with: Scanners; outstations; Slave outstations

This status attribute displays statistics about an outstation’s or scanner’s point data. The attribute lists the number of point updates, historic records, point alarms and events that ClearSCADA has retrieved from the outstation or scanner since the statistics were last reset.

Example:

24 updates, 26 historic, 0 alarms, 3 events since 11/Nov/2007 11:57:49.111

Also see Comms Statistics.

Further Information

Reset Point Statistics.


Drivers Guide - Preferred Channel (Status Attributes that are Common to Many Drivers)

Preferred Channel

Associated with: PSTN outstations or outstations with PSTN fallback; Slave PSTN outstations

This status attribute is only displayed for outstations on which the Preferred Channel pick action has been used to specify a specific PSTN channel.

The attribute displays the full name of the channel, including its path in the database.

Example:

Eastern Region.Area 1.Channel 34
(Indicating that the PSTN channel that ClearSCADA uses to contact the outstation in preference to any other PSTN channels, is named ‘Channel 34’. The channel is located in the ‘Area 1’ group, which is itself located within the ‘Eastern Region’ group.)


Drivers Guide - Previous State (Status Attributes that are Common to Many Drivers)

Previous State

Associated with: Points that are, or have been, In Service

This attribute indicates the point state that applied prior to the state changing to its Current State. A point’s Previous State differs from its Current State.

Example:

Current State High
Previous State High High

Use the Last Changed State attribute to ascertain when the state change occurred.


Drivers Guide - Previous Update Quality (Status Attributes that are Common to Many Drivers)

Previous Update Quality

Associated with: Points that are, or have been, In Service

This status attribute indicates the reliability of a point’s data at the time that it was Previously Updated (as opposed to its Current Quality).

For a comprehensive list of quality values, see Quality.

Use the attribute in conjunction with the Previous Update State and Previous Update Value status attributes.


Drivers Guide - Previous Update State (Status Attributes that are Common to Many Drivers)

Previous Update State

Associated with: Points that are, or have been, In Service

This status attribute displays a point’s state at the time that it was Previously Updated in ClearSCADA (as opposed to its Current State).

The Previous Update State might be the same as the point’s Current State if, for example, the last update was due to the point’s value changing significantly, but that change did not result in the point crossing a state boundary. A Refresh action might also result in the Previous Update State being identical to the Current State.

Use the attribute in conjunction with other status attributes, such as Previous Update Quality to assess the reliability of the data.

Also see Previous Update Value.

Use the Previous State attribute to determine the last state the point was in before the state changed to its Current State.


Drivers Guide - Previous Update Value (Status Attributes that are Common to Many Drivers)

Previous Update Value

Associated with: Points that are, or have been, In Service

This status attribute displays a point’s value at the time that it was Previously Updated in ClearSCADA (as opposed to its Current Value).

The Previous Update Value might be the same as the Current Value if the point’s value has not changed since the last data retrieval.

A driver typically polls and retrieves a point’s data at the rate it is configured to do so, but only sends point updates to the ClearSCADA server if that point’s value has changed. In such circumstances, the Previous Update Value and Current Value will differ. The exception to this is if another activity requires the point’s value to be passed to the server, regardless of whether that point value has changed. Such an activity would include, for example:

  • A Refresh action
  • A Scan Group’s interval expiring (Scan Groups apply to points on direct outstations on some advanced drivers)
  • On start-up or re-establishment of communications with the device on which the point is located
  • A Logged Value updating the Current Value (this applies to points that have logged (time stamped) data).

Any of the above activities can result in the point’s Previous Update Value being identical to the Current Value.

Use the attribute in conjunction with other status attributes, such as Previous Update Quality to assess the reliability of the data.

Also see Previous Update State.


Drivers Guide - Previously Updated (Status Attributes that are Common to Many Drivers)

Previously Updated

Associated with: Points that are, or have been, In Service

This status attribute displays the date and time that a point’s value and/or state were previously updated.

Use the attribute in conjunction with the Previous Update State, Previous Update Value, and Previous Update Quality status attributes for comprehensive information on the point data at the time of the previous update (as opposed to its Current State and Current Value).


Drivers Guide - Process Count (Status Attributes that are Common to Many Drivers)

Process Count

Associated with: Points

This status attribute displays the number of times that a point’s data has been updated in the database since the statistics were last reset.

Example:

Updated 96 times since 18/Nov/2007 11:21:43.075

Further Information

Reset Process Count.


Drivers Guide - Protocol Alarm (Status Attributes that are Common to Many Drivers)

Protocol Alarm

Associated with: Outstations, including Slave outstations that support reporting of protocol problems

This status attribute is only displayed for outstations that can report whether there is a problem with the protocol that is being used to communicate with the outstation.

Possible states: Displays one of the Standard Alarm States.

An entry is logged in the Event Journal if a protocol alarm is raised. The message includes further information about the alarm.


Drivers Guide - Put Aside Last Updated (Status Attributes that are Common to Many Drivers)

Put Aside Last Updated

Associated with: Points for which a local Override is currently in force

This status attribute displays the last update time of the point data that was ‘put aside’ when the current local Override came into force.

Use the attribute in conjunction with the Put Aside State, Put Aside Value, and Put Aside Quality status attributes to ascertain further information about the point data that was ‘put aside’.


Drivers Guide - Put Aside Quality (Status Attributes that are Common to Many Drivers)

Put Aside Quality

Associated with: Points for which a local Override is currently in force

This status attribute indicates the reliability of the point data that was ‘put aside’ at the time that the current local Override came into force.

For a comprehensive list of quality values, see Quality.

Use the status attribute in conjunction with the Put Aside State, Put Aside Value, and Put Aside Last Updated attributes to ascertain further information about the point data that was ‘put aside’.


Drivers Guide - Put Aside State (Status Attributes that are Common to Many Drivers)

Put Aside State

Associated with: Points for which a local Override is currently in force

This status attribute displays the point state that was ‘put aside’ at the time that the current local Override came into force.

Use the attribute in conjunction with the Put Aside Value, Put Aside Quality, and Put Aside Last Updated status attributes to ascertain further information about the point data that was ‘put aside’.


Drivers Guide - Put Aside Value (Status Attributes that are Common to Many Drivers)

Put Aside Value

Associated with: Points for which a local Override is currently in force

This status attribute displays the point value that was ‘put aside’ at the time that the current local Override came into force.

Use the attribute in conjunction with the Put Aside State, Put Aside Quality, and Put Aside Last Updated status attributes to ascertain further information about the point data that was ‘put aside’.


Drivers Guide - Quality (Status Attributes that are Common to Many Drivers)

Quality

Associated with: Most driver items

This status attribute indicates the ‘quality’ or reliability of an item’s data.

Possible Quality values vary, depending on the protocol, the type of item and its current State, but might include:

  • Good—The quality of the data is good.
  • High: Engineering Units Exceeded—Applies to analog points only. The point is over range (the point’s value exceeds the specified Full Scale limit).
  • Low: Engineering Units Exceeded—Applies to analog points only. The point is over range (the point’s value exceeds the specified Zero Scale limit).
  • Local Override—Applies to points only. A local Override is in force on the point. A local override is generated from the ClearSCADA server.
  • Sub-Normal—The value is derived from more than one source, but data is not available from the required minimum number of sources. For example, if GPS data is normally retrieved from three satellites and one of those satellites is not reporting any data, the values reported to ClearSCADA might be assigned the Sub-Normal Quality flag.
  • Last Usable Value—Applies to points on devices that rely on their own point values being updated by one or more external sources. This Quality value indicates that the point value should be deemed to be ‘stale’, in so far as the external source(s) have not updated the device’s value within the expected time period. Unlike the Last Known Value Quality, this Quality occurs when ClearSCADA is still able to communicate with the device.
  • Last Known Value—The data is that for the last known value of the item. For instance, a point that has been re-activated after being disabled (see Enable Point) might indicate a Last Known Value Quality until ClearSCADA has retrieved its current value from the outstation or scanner. This Quality value might also indicate that ClearSCADA has detected a communications error, but the previous known data value is available.
  • Waiting for Initial Data—This state indicates that data has not yet been retrieved for the item. This state can occur, for example, after a new point has been added to the database and placed In Service, but the driver has not yet retrieved any data for that point.
  • Uncertain—The quality of the item’s data is uncertain, as the last attempt to communicate with the device on which the item is located was unsuccessful.
  • Sensor Not Accurate—The device with which the point is associated is reporting that its sensor (point) values are not accurate. If this Quality value is displayed, recalibrate the device.
  • Out of Service—The item, or a device (such as an outstation) on which it is dependant, is not In Service. For more information, see Placing an Item In Service in the ClearSCADA Guide to Core Configuration.
  • Sensor Failure—Applies to points on drivers that are able to report sensor or similar instrument failure to ClearSCADA. The sensor with which the point is associated has been reported as failed.
  • Comm Failure—The device on which the item is located is not responding to requests from the server. ClearSCADA therefore deems communications with that device to have failed.
  • Device Failure—ClearSCADA has detected that the item, or a device on which it is dependant, has failed.
  • Configuration Error—An item that has invalid configuration has a Quality attribute of Configuration Error or Not Connected, depending on the specific configuration error(s). If the item has invalid configuration, display the item’s Form and correct the configuration as necessary (see Mandatory Configuration and Invalid Configuration Messages in the ClearSCADA Guide to Core Configuration).
  • Not Connected—An item’s configuration is incomplete. The device with which it is associated (for instance, the server with which a scanner is associated) is yet to be specified.
  • Bad—The quality of the data is deemed to be bad. No specific reason for this quality has been reported, or the reason reported by the device is not one of the standard OPC Quality flags. Other status attributes might clarify the reason for this quality.

Points have several ‘Quality’ attributes, including Current Quality and State Change Quality.

Channels on some advanced drivers have a Scan Quality attribute in addition to a Quality attribute (the latter indicating the quality of the channel itself, as opposed to the scanning undertaken on the channel).


Drivers Guide - Queued Request (Status Attributes that are Common to Many Drivers)

Queued Request

Associated with: PSTN outstations; direct outstations for which the communications availability is ‘Incoming Only’ or ‘Periodic’; direct outstations with PSTN fallback enabled; output points on advanced drivers; pulse actions on advanced drivers

With some types of outstation, ClearSCADA queues certain pick action requests automatically if it is not in communications with the outstation when the request is triggered. With some other types of outstation, your system may be configured to provide the option to queue such requests if required (see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations).

The Queued Request status attribute is displayed whenever a pick action request is queued and awaiting execution.

One Queued Request status attribute entry is displayed per queued request.

On a point or pulse action’s Status display, the attribute indicates the type of pick action that is queued and the value of that requested action (if applicable). The attribute also indicates the user that requested the pick action and the time and date that the request was made.

Example:

Control to 45.00 requested by RJones (Mar/17/2010 09:53:54.704)

(Indicating that the queued request is for a ‘Control’ pick action, which is being used to change a point’s value to 45.00.)

An outstation’s Status display lists requests that are currently queued on any of the outstation’s ‘dependants’ (such as points and pulse actions) as well as any queued outstation requests. For dependants, the entry includes the full path and name of the item to which the queued request relates.

Example:

"NW.Region 1.Analog Output Point 2" - Control to 45.00 requested by RJones (Mar/17/2010 09:53:54.704)

"NW.Region 1.Digital Output Point 3" - Control Start requested by CGrosso (Mar/17/2010 11:26:10.018)

"NW.Region 1.Pulse 1" - Pulse Close requested by AVandaal (Mar/17/2010 10:14:59.393)

(Indicating that two point controls and one pulse action are waiting to be executed when ClearSCADA is next in communications with the outstation. The first queued request is that for the same ‘Control’ pick action shown in the previous example. For dependants, each entry includes the full path of the database item to which the queued request relates.)

ClearSCADA executes any queued requests when it is next in communication with the outstation. The exceptions to this are any requests that are superseded by another request, or canceled using the Cancel Queued Request pick action.


Drivers Guide - Scan Quality (Status Attributes that are Common to Many Drivers)

Scan Quality

Associated with: Direct channels on many advanced drivers

This status attribute is displayed once a channel has been used to transmit data. The attribute indicates the quality of the most recent scan undertaken via the channel.

For a comprehensive list of quality values, see Quality.


Drivers Guide - Scan Status Alarm (Status Attributes that are Common to Many Drivers)

Scan Status Alarm

Associated with: Channels on some advanced drivers

This status attribute indicates whether the latest scan that ClearSCADA undertook via the channel, was completed within the parameters configured for such a scan.

Possible states: Displays one of the Standard Alarm States.


Drivers Guide - Scanning (Status Attributes that are Common to Many Drivers)

Scanning

Associated with: Direct outstations that support scanning promotion

The Scanning attribute is only displayed while ClearSCADA is scanning an outstation at an increased (‘promoted’) rate (see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers). The attribute indicates the reason for the scanning promotion.

Possible states:

  • Promoted by Displaying Points—Scanning promotion is due to one or more of the outstation’s points being on display on a client (workstation).
  • Promoted by Control—Scanning is promoted as a result of a Control or Inching action being executed on a point or pulse action.
  • Promoted by Method—Scanning promotion has been triggered by the Promote Scanning action or method.


Drivers Guide - Serial Port Statistics (Status Attributes that are Common to Many Drivers)

Serial Port Statistics

Associated with: Channels on advanced drivers, providing that those channels have a Serial connection

This status attribute is only displayed if ClearSCADA has detected an error on the port. The attribute displays the number of:

  • Parity errors—Data bits that became corrupt during transmission
  • Framing errors—Data for which the Start or Stop Bits have become lost or corrupt during transmission
  • Overruns—Data that was sent faster than it could be received, potentially resulting in loss of data. (If this occurs on a regular basis, check that the correct type of Flow Control is specified on the Channel Form.)
  • Unintended Breaks in transmission.

If the Reset Serial Port Statistics pick action has been used to reset the statistics, up to two entries are displayed—the lower entry lists the previous Serial Port Statistics, the upper entry is ‘live’ and logs the Serial Port Statistics since the pick action was last used. The upper entry is only displayed if further errors have been detected on the port.

Example:

0 parity errors, 0 framing errors, 0 overruns, 1 breaks since 07/Mar/2008 08:50:06.712

3 parity errors, 0 framing errors, 0 overruns, 2 breaks between 05/Apr/2005 15:31:50.843 and 07/Mar/2008 08:50:06.712

For more information on data bits, parity, stop bits, and flow control, see Configure a Channel’s Serial Connection Properties.


Drivers Guide - Source (Status Attributes that are Common to Many Drivers)

Source

Associated with: Driver items other than outstation sets

The Source status attribute indicates the location at which an item’s data source resides on the device that ClearSCADA is scanning for data. The information shown varies, depending on the type of item and the driver with which it is associated. For further information, see the driver-specific documentation.

A Source attribute displays the value Undefined if an item’s configuration is incomplete, in so far as the device with which the item is associated has not yet been specified. For example, the outstation on which a point is located has not been specified.


Drivers Guide - Source Name (Status Attributes that are Common to Many Drivers)

Source Name

Associated with: Scanners; Slave sources; outstations; Slave outstations; points; pulse actions

This attribute displays the name and location of an item’s data source in the ClearSCADA database. The Source Name comprises the given name of the data source, plus the full path to that item in the database. Dot separators separate the various elements of the path (the hierarchy of groups within which the data source resides).

Example:

Eastern Region.Area 1.Scanner 33
(Indicating that the data source is a scanner named ‘Scanner 33’. The scanner is within the ‘Area 1’ group, which itself is located within the ‘Eastern Region’ group.)

Also see Source.


Drivers Guide - State (Status Attributes that are Common to Many Drivers)

State

Associated with: Driver items other than outstation sets, points, and pulse actions

(Points have several ‘State’ status attributes, including Current State and Previous State.)

The State status attribute indicates the present state of the item. The possible values vary, depending on the type of item.

A server might be in one of these states:

  • Online—ClearSCADA is able to communicate successfully with the server.
  • Offline—The server has not yet attempted communications with a remote device. This state is typically fleeting, after which it is replaced by either the Online or Failed state.
  • Not In Service—The server is not In Service. As such, the server and any items in the database that are dependent on that server, are not active. (If the item’s configuration indicates that it is In Service, this state indicates that the server’s configuration is incomplete and that the item therefore behaves as if it is not In Service.)
  • Uninitialized—Displayed if the driver is not running. Also seen on new servers, until the driver has updated the state of the server with its true state.
  • Failed—ClearSCADA’s attempts to communicate with the server have been unsuccessful, therefore ClearSCADA deems the connection or server to have failed. If available, the State attribute includes additional information to clarify the reason for the failure. The item’s Quality status attribute might also provide further clarification.

A channel on a simple driver might be in one of these states:

  • Online—ClearSCADA is able to communicate successfully with the channel.
  • Offline—The channel has not yet been used to communicate with a remote device. This state is typically fleeting, after which it is replaced by either the Online or Failed state.
  • Not In Service—The channel is not In Service and is therefore not active. (If the item’s configuration indicates that it is In Service, this state indicates that the channel’s configuration is incomplete and that the item therefore behaves as if it is not In Service. The item’s Quality status attribute should provide further clarification.)
  • Uninitialized—Displayed if the driver is not running. Also seen on new channels, until the driver has updated the state of the channel with its true state.
  • Failed—ClearSCADA’s attempts to communicate via the channel have been unsuccessful, therefore ClearSCADA deems the channel to have failed. If available, the State attribute includes additional information to clarify the reason for the failure.

A scanner might be in one of these states:

  • Online—ClearSCADA is able to communicate successfully with the scanner.
  • Offline—The scanner has not yet attempted communications with a remote device. This state is typically fleeting, after which it is replaced by either the Online or Failed state. The Offline state also occurs if the scanner or its channel are not In Service, or if ClearSCADA has detected that the scanner’s channel has failed. The scanner’s Quality status attribute should provide further clarification.
  • Uninitialized—Only displayed for a new scanner with which ClearSCADA is yet to attempt communications. This state typically indicates that the scanner’s configuration is incomplete—for instance that the server with which the scanner is associated is yet to be specified.
  • Failed—ClearSCADA’s attempts to communicate with the scanner have been unsuccessful, therefore ClearSCADA deems the scanner to have failed. If available, the State attribute includes additional information to clarify the reason for the failure. The item’s Quality status attribute should also provide further clarification.

For more information on the checks to undertake should a scanner on your system not be in a healthy state, see Troubleshooting in the ClearSCADA Guide to Simple Drivers.

A Slave source might be in one of these states:

  • Online—ClearSCADA is able to communicate successfully with the Slave source.
  • Offline—This state occurs if the Slave source and/or its channel are not In Service, or if ClearSCADA has detected that the Slave source’s channel has failed.
  • Uninitialized—Only displayed for a new Slave source with which ClearSCADA is yet to attempt communications. This state typically indicates that the source’s configuration is incomplete—for instance that the channel with which the source is associated is yet to be specified.

A channel on an advanced driver might be in one of these states:

  • Active—Applies to PSTN channels only. This state indicates that a call is being established, or is in progress on the channel.
  • Healthy—ClearSCADA is able to communicate successfully with at least one remote device on the channel.
  • Start Delayed—This state indicates that the channel is waiting for the Start Delay period to elapse before starting up. The Start Delay is specified on the Channel Form’s Channel tab (see Defining General Channel Communication Settings in the ClearSCADA Guide to Advanced Drivers).
  • Disconnected—ClearSCADA is unable to communicate via this channel. This might be for any of a number of reasons, such as:
  • The channel’s configuration is incomplete—for instance, that the telephone number to which a PSTN channel’s dial-up modem is connected has not been specified (see Checking for Invalid Configuration in the ClearSCADA Guide to Core Configuration).
  • The channel is not In Service (in which case, the channel will typically display an ‘Out of Service’ Quality).
  • Failed—Either communications with multiple remote devices on the channel have been detected as failed, or the channel cannot connect to its device (for instance, the COM port). To ascertain further information about the reason for this state, look at the item’s other status attributes, or use the Display Alarms pick action to display the channel’s Alarms List.

An outstation might be in one of these states:

  • Healthy, Multidrop—ClearSCADA is communicating successfully with the outstation. With outstations on Shared outstation sets that use Heartbeat polling, this state indicates that both direct lines are healthy. With outstations on Switched sets, or on Shared sets that do not use Heartbeat polling, this state indicates that communications via the currently used line are healthy; additionally communications via the other line were healthy the last time that the outstation communicated via that channel (if at all). (To check the current state of the channel that is not in use, look at the state of the channel, rather than the outstation.)
  • Healthy, A Failed—ClearSCADA is able to communicate successfully with the outstation via the second of two channels. ClearSCADA’s most recent attempts to communicate via the channel designated as Line A were unsuccessful. As such, ClearSCADA deems Line A to have failed. (The channels are designated Line A or Line B on the Outstation Set Form.)
  • Healthy, B Failed—ClearSCADA is able to communicate successfully with the outstation via the first of two channels. ClearSCADA’s most recent attempts to communicate via the channel designated as Line B were unsuccessful. As such, ClearSCADA deems Line B to have failed. (The channels are designated Line A or Line B on the Outstation Set Form.)
  • Healthy, PSTN—Applies to both PSTN outstations and direct outstations that use PSTN as a fallback means of communication. ClearSCADA is communicating successfully with the outstation via a PSTN channel.
  • PSTN Available—Applies to PSTN outstations only. ClearSCADA is not currently in communications with the outstation, however PSTN comms is available when required.
  • PSTN Available, Multidrop Stopped—Applies to direct outstations that use PSTN fallback. PSTN communications is available. Direct communications with the outstation have stopped. This state occurs when the Fallback pick action has been used to force ClearSCADA to communicate with the outstation via PSTN, rather than via its direct channel(s).
  • PSTN Available, Multidrop Failed—Applies to direct outstations that use PSTN fallback. ClearSCADA is unable to communicate with the outstation via its direct line(s), but PSTN communications are available when required.
  • PSTN Available (Incoming Only)—Applies to PSTN outstations only. ClearSCADA is not currently in communications with the outstation, however incoming PSTN comms is available when required. For more information, see Define Dial In Line Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers.
  • PSTN Available (Outgoing Only)—Applies to PSTN outstations only. ClearSCADA is not currently in communications with the outstation, however outgoing PSTN comms is available when required. For more information, see Define Dial In Line Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers.
  • Dialing—ClearSCADA is in the process of calling the outstation via PSTN. This state applies to both PSTN outstations and direct outstations that use PSTN as a fallback means of communication.
  • Retry Dialing Pending—A previous attempt to communicate with the outstation via PSTN was unsuccessful. ClearSCADA is currently waiting before dialing the outstation again (the time that the server waits is specified on the PSTN tab of the Outstation Form). This state applies to both PSTN outstations and direct outstations that use PSTN as a fallback means of communication.
  • Connecting—ClearSCADA is in the process of establishing communications with the outstation, via one of its direct channel(s).
  • Parent Outstation Failed—Applies to remote outstations only. Some protocols support a Parent - Remote setup, whereby ClearSCADA is able to communicate with remote outstations via a ‘parent’ outstation. The Parent Outstation Failed state indicates that ClearSCADA’s latest attempts to communicate with the remote’s parent outstation have been unsuccessful. As such, ClearSCADA deems the parent outstation to have failed. By implication, communications between ClearSCADA and the remote outstation have therefore also been unsuccessful; however, communications between the parent and remote outstation may still be okay.
  • All Channels Failed—ClearSCADA is unable to communicate with the outstation via any of the channels that it should be able to use to contact that outstation. (Therefore the true state of the outstation is unknown.)
  • Disconnected—ClearSCADA is unable to communicate with this outstation. This might be for any of a number of reasons, such as:
  • The configuration of the outstation and/or its associated set and/or channel is invalid (see Checking for Invalid Configuration in the ClearSCADA Guide to Core Configuration).
  • The outstation and/or its associated set and/or channel are not In Service. (The item that is not In Service will typically display an ‘Out of Service’ Quality.)
  • Disconnected (Unavailable)—Applies to outstations for which communications availability is set to ‘Periodic’. With such outstations, communications are only available for a limited period of time (see Specify the Availability of Communications Between the Outstation and ClearSCADA in the ClearSCADA Guide to Advanced Drivers). The state indicates that it is not possible for ClearSCADA to communicate with the outstation, as it is outside of the outstation’s available period.

With direct outstations for which communications availability is set to ‘Periodic’ but not ‘On Demand’, the state indicates that ClearSCADA is not currently in communications with the outstation, as it is outside of the outstation’s availability period.

With ‘On Demand’ outstations, the state indicates that it would not be possible for ClearSCADA to initiate a connection to the outstation, if required, as it is outside of the outstation’s availability period. This also applies to PSTN outstations for which communications availability is set to ‘Periodic’ and for which the PSTN channels are ‘Dial Out Only’.

  • Failed, Multidrop Stopped—Applies to direct outstations that use PSTN fallback. This state occurs when the Fallback pick action has been used to force ClearSCADA to communicate with the outstation via PSTN, rather than via its direct channel(s), following which ClearSCADA’s attempts to connect to the outstation via PSTN were unsuccessful. As such, ClearSCADA deems PSTN communications to have failed. (With such a situation, ClearSCADA does not automatically switch the outstation back to multidrop. If appropriate, use the Fallback pick action to switch to multidrop communications.)
  • Failed—ClearSCADA’s attempts to communicate with the outstation have been unsuccessful. As such, ClearSCADA deems the outstation to have failed. If available, the State attribute includes additional information to clarify the reason for the failure. The item’s Quality status attribute might also provide further clarification.

For more information on the checks to undertake should an outstation on your system not be in a healthy state, see Troubleshooting in the ClearSCADA Guide to Advanced Drivers. The section includes a list of diagnostic messages that might be displayed should ClearSCADA detect a communications problem.

A Slave outstation might be in one of these states:

  • Healthy, Multidrop—The Slave outstation (ClearSCADA) is communicating successfully with the SCADA master. With Slave outstations on Switched sets, this state indicates that communications via the currently used line are healthy; additionally communications via the other line were healthy the last time that the Slave outstation communicated via that channel (if at all). (To check the current state of the channel that is not in use, look at the state of the channel, rather than the Slave outstation.)
  • Healthy, A Failed—The Slave outstation (ClearSCADA) is able to communicate successfully with the SCADA master via the second of two channels. ClearSCADA’s most recent attempts to communicate via the channel designated as Line A were unsuccessful. As such, ClearSCADA deems Line A to have failed. (The channels are designated Line A or Line B on the Slave Outstation Set Form.)
  • Healthy, B Failed—The Slave outstation (ClearSCADA) is able to communicate successfully with the SCADA master via the first of two channels. ClearSCADA’s most recent attempts to communicate via the channel designated as Line B were unsuccessful. As such, ClearSCADA deems Line B to have failed. (The channels are designated Line A or Line B on the Slave Outstation Set Form.)
  • PSTN Available—Applies to Slave PSTN outstations only. The Slave outstation (ClearSCADA) is not currently in communications with the SCADA master, however PSTN comms is available when required.
  • Dialing—Applies to Slave PSTN outstations only. The Slave outstation (ClearSCADA) is in the process of calling the SCADA master via PSTN.
  • Retry Dialing Pending—Applies to Slave PSTN outstations only. A previous attempt to communicate with the SCADA master via PSTN was unsuccessful. The Slave outstation (ClearSCADA) is currently waiting before dialing the SCADA master again (the time that the Slave waits is specified on the PSTN tab of the Slave Outstation Form).
  • Connecting—The Slave outstation (ClearSCADA) is in the process of establishing communications with the SCADA master, via one of its direct channel(s).
  • All Channels Failed—The Slave outstation (ClearSCADA) is unable to communicate with the SCADA master via any of the channels that it should be able to use to contact that master.
  • Disconnected—ClearSCADA is unable to communicate with the SCADA master via this Slave outstation. This might be for any of a number of reasons, such as:
  • The configuration of the Slave outstation and/or any associated set and/or channel is invalid (see Checking for Invalid Configuration in the ClearSCADA Guide to Core Configuration).
  • The Slave outstation and/or any associated set and/or channel are not In Service. (The item that is not In Service will typically display an ‘Out of Service’ Quality.)
  • Failed—The Slave outstation (ClearSCADA)’s attempts to communicate with the SCADA Master have been unsuccessful. For example, ClearSCADA’s attempts to send unsolicited data might have been unsuccessful, or the TCP/IP connection might have failed. As such, the Slave outstation is deemed to have failed. If available, the State attribute includes additional information to clarify the reason for the failure. The item’s Quality status attribute might also provide further clarification.


Drivers Guide - State Alarm (Status Attributes that are Common to Many Drivers)

State Alarm

Associated with: Servers; channels; scanners; Slave sources; some Slave outstations; points

(Outstations on advanced drivers have several state alarm status attributes, including a Comms State Alarm and a Channel State Alarm.)

The State Alarm status attribute indicates the latest alarm activity associated with an item’s state. The attribute indicates the state’s present alarm status, along with the date and time that the status occurred.

Example:

Enabled Cleared at 02/Nov/2007 14:29:17.928
(Indicating that alarm feature that is associated with the item’s state is enabled (so allowing alarms to be raised if an alarm situation occurs). It also indicates that the most recently raised alarm cleared at the above specified date and time, but has not yet been acknowledged.)

With most types of database item, a single alarm is used to raise awareness of any problem that ClearSCADA has detected with that item. The severity of the alarm is typically specified on the <Item Type> tab of the item’s configuration Form.

With points, separate severities can be specified for each possible point state or limit. These are typically specified on the <Point Type> tab of each point’s configuration Form.

If any of the points on your system are configured to have Multiple Point State Alarms, an extra field is displayed on the <Point Type> tab. On the point’s Status display, a separate State Alarm status attribute is displayed for each possible ‘Point State’ alarm condition, instead of a single State Alarm status attribute. For more information, see Multiple Point State Alarms in the ClearSCADA Guide to Core Point Configuration.

Possible States: Displays one of the Standard Alarm States.

Also see Alarm State in the ClearSCADA Guide to ViewX and WebX Clients.


Drivers Guide - State Change Quality (Status Attributes that are Common to Many Drivers)

State Change Quality

Associated with: Points that are, or have been, In Service

This status attribute indicates the reliability of the value that last caused a point to change state.

Use the attribute in conjunction with the Last Changed State and State Change Value status attributes.

For a comprehensive list of quality values, see Quality.


Drivers Guide - State Change Value (Status Attributes that are Common to Many Drivers)

State Change Value

Associated with: Points that are, or have been, In Service

This status attribute displays the value that last caused a point to change state.

Use the attribute in conjunction with the Last Changed State and State Change Quality status attributes.


Drivers Guide - Switching (Status Attributes that are Common to Many Drivers)

Switching

Associated with: Shared and Switched outstation sets; Shared outstations that are ‘Independent’

This status attribute indicates whether switching of outstations from one channel to another is Enabled or Disabled.

With Switched outstation sets, you can specify the number of outstations that ClearSCADA needs to detect as having failed on a channel, before the set switches lines (see Defining Channel Settings for a Switched Set in the ClearSCADA Guide to Advanced Drivers).

Further Information

Disable Switching.

Enable Switching.

Switch Line.


Drivers Guide - Telephone Number (Status Attributes that are Common to Many Drivers)

Telephone Number

Associated with: PSTN outstations, including Slave PSTN outstations; outstations, including Slave outstations, on which PSTN fallback is enabled

This status attribute displays the telephone number of the site at which an outstation is located. The telephone number is that which is specified on the PSTN tab of the outstation’s configuration Form.


Drivers Guide - Telnet (Status Attributes that are Common to Many Drivers)

Telnet

Associated with: Channels

The Telnet status attribute displays the current state of a channel’s Telnet server (see Communications Logging Status in the ClearSCADA Guide to Server Administration, and see Telnet Monitoring in the ClearSCADA Guide to Server Administration).

Further Information

Enable Telnet.

Disable Telnet.


Simple Drivers Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Simple Drivers Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Simple Drivers Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Simple Drivers Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Simple Drivers Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Simple Drivers Guide - Document Scope (About the Guide)

Document Scope

This guide explains those aspects of configuration that are common to many simple drivers. It also explains the order in which you should perform simple driver configuration.

Other sections in this guide provide information to assist with diagnosing any problems that ClearSCADA has detected on simple driver items.

For more information, see Introduction to Simple Drivers.


Simple Drivers Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers that are tasked with configuring simple driver features and items.

The guide is also intended for engineers and system administrators investigating any faults that ClearSCADA has detected on simple driver items.


Simple Drivers Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Simple Drivers Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Drivers

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to Security.


Simple Drivers Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Simple Drivers Guide - Introduction to Simple Drivers

Introduction to Simple Drivers

The simple drivers that are supported by ClearSCADA allow the ClearSCADA server to either:

  • Communicate with various third-party devices, including PLCs and loggers
  • Retrieve calculated values, such as those produced within logic programs in remote PLCs, so that they can be displayed within ClearSCADA or used for further calculations

or:

  • Monitor various aspects of the system (for example, free disk space).

Each driver provides extra features in the ClearSCADA database to present the data from those devices and, where supported, to set point values or send controls to plant (see Driver Composition).

The Simple Driver documentation explains how to configure the features that are common to many simple drivers (see Add a Driver-Specific Item to the Database and see Tabs That are Common to Many Configuration Forms). It also explains the order that the configuration should take (see Configuration Order).

Use this documentation alongside the ClearSCADA Guide to Drivers and the driver-specific documentation for a comprehensive understanding of the configuration associated with your drivers.

You can use the core ClearSCADA features, such as Lists, Actions, and Mimics, with simple driver items. For more information on the core database items, please refer to the general documentation (the non-driver specific documentation).

For aspects of configuration that are common to most types of database item (for instance, saving configuration changes, and renaming, copying, and deleting database items), see the ClearSCADA Guide to Core Configuration.

If additional fields have been added to any Forms specifically for your system, you will also need to refer to the system-specific documentation that explains those fields. For information on adding such fields, see Extra Database Fields in the ClearSCADA Guide to Server Administration.

The Simple Driver documentation also explains features that are of interest to system administrators and engineers when diagnosing any abnormal conditions that ClearSCADA has detected. For information, see the following sections:

  • System Analysis
  • Troubleshooting.


Simple Drivers Guide - Driver Composition (Introduction to Simple Drivers)

Driver Composition

Simple drivers comprise of either two or three layers of functionality. Each layer is represented by a different database item, which differs depending on the driver.

Layers of functionality may include:

  • A Channel or Server
  • Scanners
  • Points and Pulse Actions.

See the driver-specific documentation for details of the layers used by specific drivers.


Simple Drivers Guide - Channel or Server (Introduction to Simple Drivers)

Channel or Server

This layer exists for those simple drivers that require additional connection information in order to successfully monitor or control items on your system.

NOTE: To display channel or server details in List format from the Queries Bar, filter the constraints on the Channels List.


Simple Drivers Guide - Scanners (Introduction to Simple Drivers)

Scanners

You can attach multiple scanners to each channel or server on a simple driver. The primary function of the scanners is to scan points for data that has changed since the previous scan, and to report that data to ClearSCADA.

Scanners are referred to by different names in some simple drivers, but their primary functionality is the same. For the purposes of this document, the term ‘Scanner’ is used throughout to represent such devices. See the driver-specific documentation for the term used to refer to the scanner on a particular driver.

NOTE: To display scanner details in List format from the Queries Bar, filter the constraints on the Point Sources List.


Simple Drivers Guide - Points and Pulse Actions (Introduction to Simple Drivers)

Points and Pulse Actions

You can associate multiple points with each scanner.

ClearSCADA uses points to represent the calculated values, measuring instruments or control devices that are connected to the scanners on your system.

Depending on the driver, points can take the form of ‘virtual’ points such as calculated values, or physical points.


Simple Drivers Guide - Configuration Order (Introduction to Simple Drivers)

Configuration Order

For each simple driver, you need to configure:

  1. If applicable to the drivers that you are using, either:
  • Channels to define the communications connections between the scanner and a PLC or other remote device (see Configuring Channels on Simple Drivers).

Or:

  • Servers to define the device on which the points are located.
  2. Scanners to define the rate at which data is scanned and, if applicable, when the data is scanned, and the type of communications connection used (see Configuring Scanners on Simple Drivers).
  3. Points to represent the calculated values, measuring instruments, or control devices that are associated with each scanner. The type of point that you can configure varies, depending on the driver (see Points on Simple Drivers).
  4. Pulse actions to carry out controls on plant for only brief periods of time. Pulse actions are supported by several simple drivers (see Defining Pulse Action Details in the ClearSCADA Guide to Core Point Configuration).

To minimize the time taken to configure the required simple driver items, configure them in the order given above.

By default, an item is not ‘In Service’ when you first create a database entry for it. In order for the ClearSCADA server to communicate with an item, you have to put the item In Service (online), and ensure that it has saved, valid configuration (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration). ClearSCADA will generally prompt you for any mandatory settings that an item requires, as you configure it.

NOTE: If you later take a scanner out of service, its dependants (points, pulse actions, and so on) become out of service.
Similarly, if you later take a channel out of service, its scanners and their dependants (points, pulse action, and so on) also become out of service.
In each case, this does not affect the configuration of these items.

Be aware that users need to be assigned the Configure Database feature to enable them to configure items in the database (see Database Security in the ClearSCADA Guide to Core Configuration).


Simple Drivers Guide - Add a Driver-Specific Item to the Database (Introduction to Simple Drivers)

Add a Driver-Specific Item to the Database

To add a driver-specific channel, set, outstation, point, or pulse action to your system (preferably in that order—see Configuration Order):

  1. Display the Database Bar.

(The Database Bar is an Explorer Bar (see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).)

  2. Right-click on the Group or System to which you want to add an item.
    A context sensitive menu is displayed.
  3. Select the New option.
    A further menu is displayed.
  4. Select the <Driver> option for the driver to which you want to add an item. For example, Modbus.
    A further menu is displayed.

If the driver that you require is not installed on your system or not displayed on the menu, contact a system administrator.

  • Select the type of item that you want to add to the system, for example Analog Point.
    An item of the selected type is added to the database and displayed on the tree-structure. It is automatically selected, ready for you to define its name.
  5. Enter the required name for the item.
  6. Select another part of the interface, or press the Enter key to confirm the entry.

You then need to display the Form to configure the item (see Display a Form in the ClearSCADA Guide to Core Configuration).


Simple Drivers Guide - Tabs That are Common to Many Configuration Forms (Introduction to Simple Drivers)

Tabs That are Common to Many Configuration Forms

Much of the driver-specific configuration on simple drivers is undertaken using a series of configuration Forms. These Forms have a series of ‘tabs’ or ‘pages’ on which you specify different aspects of configuration.

The Forms often have a combination of these tabs, which are common to many configuration Forms:

  • Identification—Use to optionally define a Help View and to indicate whether the item is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for the item (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with alarms for the item (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the item (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).

In addition, the Forms include one or more tabs for specifying item- or driver-specific configuration. For information on configuring the properties on such tabs, see the relevant driver-specific documentation (for example, for information on the Source tab of the Modbus Source Form, see the ClearSCADA Guide to the Modbus Slave Driver).

For aspects of configuration that are common to most types of database item, see the ClearSCADA Guide to Core Configuration.


Simple Drivers Guide - Configuring Simple Driver Server Settings

Configuring Simple Driver Server Settings

This section explains the procedure that a system administrator should undertake to check that any driver-specific settings are correctly configured on each server when a ClearSCADA system is first installed. Such settings are configured using the ClearSCADA Server Configuration Tool. (For information on the driver installation process, see Set up the Drivers on a New ClearSCADA System in the ClearSCADA Guide to Drivers, or see Add a New Driver to an Existing ClearSCADA System in the ClearSCADA Guide to Drivers.)

Only some simple drivers have driver-specific settings. Any driver-specific settings are in addition to the Drivers global parameters (see Driver Settings in the ClearSCADA Guide to Server Administration). Any driver-specific settings are specified on the appropriate section of the ClearSCADA Server Configuration tool and are explained in the relevant driver guide.

For drivers that have driver-specific settings, use this section in conjunction with the driver-specific documentation. For non-driver-specific aspects of server configuration, see the ClearSCADA Guide to Server Administration.

NOTE: Ensure that you repeat any configuration changes that you make on each of the servers on your system (other than any Permanent Standby servers, which do not run the drivers).

To configure any driver-specific settings:

  1. Run the ClearSCADA Server Configuration tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Ensure that the next-level entries are visible within the Global Parameters option in the Server Configuration tree structure.
  3. Within the Global Parameters tree-structure, select the name of the driver used on your system. (A separate driver entry is only included if that driver is installed and its server settings differ to those of other drivers.)
    The appropriate driver section is shown.

Example:

Selecting the Performance Monitor driver entry within the Global Parameters tree structure...
...results in the Performance Monitor driver section being shown.

  4. Refer to the appropriate ClearSCADA driver guide for information on configuring the settings for that driver.

(For features displayed in the ‘Drivers’ section of the tool, see Driver Settings in the ClearSCADA Guide to Server Administration.)

As you configure the settings, the driver entry in the hierarchical list changes color to indicate that changes are being made to the driver configuration.

  5. Right-click on the server (‘node’) entry in the hierarchical list in the ClearSCADA Server Configuration Tool.
    A context-sensitive menu is displayed.
  6. Select the Apply Changes option.
    The changes are applied to the server configuration.

Example:

Right-click on the server node to display a context-sensitive menu...
...from which you select the Apply Changes option, to apply the changes to the server configuration.

  7. If the server is currently running as the main server, restart the driver for the changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).

For some configuration changes, you may also need to restart the server, in order for those changes to take effect—the driver-specific documentation indicates whether a server restart is required.

  8. Repeat the above steps for any other drivers that have driver-specific settings on your system.
  9. Repeat the above steps on all servers that are not permanent standby servers on your system.


Simple Drivers Guide - Configuring Channels on Simple Drivers

Configuring Channels on Simple Drivers

Many simple drivers use Channels. Channels are the communications lines through which information is passed between the ClearSCADA server and the scanners, outstations or PLCs and so on, on your system.

Simple drivers tend to use Direct channels. Direct channels are used by devices that are permanently connected to the ClearSCADA server via, for example, a cable, network, or a continuous radio signal.

Before you configure a channel in ClearSCADA, ensure that you carry out any necessary Preparation so that you can specify the appropriate properties for the channel in the ClearSCADA database.

Use the fields on the appropriate Channel Form to configure a channel on your system.

Each Channel Form has a series of tabs.

Use the Channel tab to define the basic communication properties for the channel (see Configure the Basic Channel Properties).

Use the Port or Connection tab(s) to define the connection properties for each port that the channel uses. The fields on the tab(s) vary, depending on the connection type. When a choice of connection types is available, a Connection Type field is displayed at the top of the tab (see Configure a Channel’s Connection Type in the ClearSCADA Guide to Drivers). If no Connection Type field is displayed, the channel typically uses a serial connection (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers). Primary and Secondary Port or Connection tabs are available for those channels that support communication using either of two ports (see Enable or Disable a Secondary Port).

For information on fields on the other tabs, see Tabs That are Common to Many Configuration Forms.

For information on the minimal amount of configuration that you can undertake to produce a functional channel in ClearSCADA, see Minimum Configuration.

For information on the connection types that a particular channel supports, and any configuration fields not described in the sections referenced above, see the ClearSCADA driver-specific documentation.

For further information on the settings required for your communications equipment, see the manufacturer’s documentation.


Simple Drivers Guide - Preparation (Configuring Channels on Simple Drivers)

Preparation

To configure a channel, you need to know the type of connection that the channel uses (such as Serial or Network), and the settings that are used for that type of connection.

Often these settings are fixed, according to the type of communications equipment being used. Refer to the documentation associated with the communications equipment for these settings—you need to configure each channel to have the same settings as the communications equipment for the device(s) with which the channel is associated.

Where any settings are not fixed, you need to be aware of which settings are being used for the communications equipment on your system. The engineers that configure the PLCs, outstations and so on, should create a list of the settings that they have configured. If you have access to such a list, you can use it to define those requirements.

You also need to establish which features are required for each channel. You can configure each channel to use a variety of features, including alarm redirection. However, many of these features are optional and do not affect the success of communications. The optional features include:

  • Alarm view
  • Alarm redirection
  • User methods.

If the features listed above are not configured, they are not used for the selected channel (they will be left blank).


Simple Drivers Guide - Minimum Configuration (Configuring Channels on Simple Drivers)

Minimum Configuration

As a minimum, for any type of channel, you have to configure these connection-specific properties:

  • Serial Connection—the port to which the channel is connected.
  • Network Connection—the TCP/IP type (where this is not pre-determined by the type of channel).

For any type of channel, you have to put the channel In Service, and save the configuration if you want the channel to be functional (online).

This will provide a functional channel that uses default configuration settings.


Simple Drivers Guide - Configure the Basic Channel Properties (Configuring Channels on Simple Drivers)

Configure the Basic Channel Properties

Use the fields on the Channel tab of the appropriate Channel Form to configure the basic communication properties for a channel.

The following fields are displayed for channels on many simple drivers:

  • In Service—Use to specify whether the channel is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

NOTE: If you later take a channel out of service, its scanners and their dependants (such as points and/or pulse actions) also become out of service. This does not affect the configuration of these items.

  • Severity—Use the combo box to define the priority of any alarms or events that are associated with the channel (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Channel tab. Use the field to specify the area with which any of the Channel’s alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Number of Retries—Enter the number of times that the ClearSCADA server will attempt to request data from each scanner that is using this channel.

If a scanner does not respond to the ClearSCADA server’s initial data request, the server makes a further request (referred to as a ‘retry’). The server can repeat a data request up to the defined number of Retries.

If the scanner does not report its data within the defined number of retries, the ClearSCADA server will regard the scanner as having failed.

Enter the required number of retries.

  • Timeout—Enter the number of milliseconds that the server is to wait before attempting a ‘retry’. This delay is used to stop a retry from occurring immediately (as an immediate retry is likely to be unsuccessful for the same reason as the previous attempt).

The default setting of 5000 milliseconds is suitable for most systems.


Simple Drivers Guide - Enable or Disable a Secondary Port (Configuring Channels on Simple Drivers)

Enable or Disable a Secondary Port

If a channel supports communication using either of two ports (Primary and Secondary), by default the secondary port is disabled when you first create the channel in the database.

If the secondary port is used by the channel, you can enable it by either choosing the relevant Connection Type (see Configure a Channel’s Connection Type in the ClearSCADA Guide to Drivers), or selecting the Enabled check box on the Secondary Port or Secondary Connection tab (the name of the actual tab varies, depending on the type of channel).

If the secondary port is not used by the channel on your system, ensure that the port configuration is disabled. The way that you do this varies, depending whether the channel can communicate using more than one type of communications connection. To disable a secondary port, you either:

  • Ensure that the Connection Type field on the Secondary Port or Secondary Connection tab is set to ‘None’. This field is available if the channel supports more than one type of communications connection.

or:

  • Ensure that the Enabled check box on the Secondary Port or Secondary Connection tab is clear. This check box is available if a channel can use only one type of communications connection.


Simple Drivers Guide - Configuring Scanners on Simple Drivers

Configuring Scanners on Simple Drivers

A Scanner is logical functionality that runs within ClearSCADA. Each scanner scans one or more physical or ‘virtual’ points, using a particular protocol. For instance a Modbus scanner can be used to scan a register range within a Modbus PLC.

On a ClearSCADA system, you typically use separate scanners to scan different points at different times, and so monitor or control the states or values of those points.

The type of data that ClearSCADA obtains from each scanner and processes for use online varies, depending on the type of data that the scanner supports. For example, many scanners support current data—the present state or value of a point when the ClearSCADA server requests current data from the scanner.

This section explains how to configure properties that are common to many types of scanner.

Before you configure a scanner in ClearSCADA, ensure that you carry out any necessary Preparation so that you can specify the appropriate properties for the scanner in the ClearSCADA database.

You configure a scanner’s properties using the fields on the appropriate Scanner Form.

For many scanners on simple drivers, the Scanner Form has a combination of these tabs: Identification, User Methods, Alarm, Redirection, and Scanner.

This section explains features on the Scanner tab that are common to scanners on many simple drivers.

Use the fields on the Scanner tab to:

  • Define Common Scanner Properties
  • Define any type-specific information for a scanner (see the driver-specific documentation)
  • Define the Scan Rate
  • Define Whether a Scanner is Promoted While its Points are on Display
  • Define Whether a Scanner is Used to Trigger Logic.

For information on the fields on the other tabs mentioned above, see Tabs That are Common to Many Configuration Forms.

The Forms for some types of scanner also include one or more driver-specific tabs. For information on such tabs, see the driver-specific documentation.

NOTE: To display scanner details in List format from the Queries Bar, filter the constraints on the Point Sources List.


Simple Drivers Guide - Preparation (Configuring Scanners on Simple Drivers)

Preparation

Before you can successfully configure a scanner, you will need either:

  • To have configured the Channel or Server with which the scanner is to be associated (see Configuring Channels on Simple Drivers).

Or:

  • The name of the device (for example, the Node) on which the scanner is to scan data (see the driver-specific documentation).

You will also need to be aware of the significance of the scanner’s alarms and events in relation to the rest of your system—this will determine the priority that you allocate to each scanner.

You will need to establish which features are required for each scanner. You can configure each scanner to use a variety of features, including alarm redirection. Many of these features are optional and do not affect the success of communications. Optional features include:

  • Alarm view
  • Alarm redirection
  • User methods.

If the features listed above are not configured, they are not used for the scanner (they will be left blank).


Simple Drivers Guide - Define Common Scanner Properties (Configuring Scanners on Simple Drivers)

Define Common Scanner Properties

Use the fields on the Scanner tab of the appropriate Scanner Form to define the driver-specific properties for a scanner.

The following fields are displayed for scanners on many simple drivers:

  • In Service—Use to specify whether the scanner is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

NOTE: If you later take a scanner out of service, its dependants (points, pulse actions, and so on) become out of service. This does not affect the configuration of these items.

  • Severity—Use the combo box to define the priority of any alarms or events that are associated with the scanner (see Defining Severities in the ClearSCADA Guide to Core Configuration).

  • Area of Interest—If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed toward the top of the Scanner tab. Use the field to specify the area with which any of the Scanner’s alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.


Simple Drivers Guide - Define the Scan Rate (Configuring Scanners on Simple Drivers)

Define the Scan Rate

On simple drivers, you need to specify the scan rate—the frequency with which the scanner scans its points for data that has changed. Some simple drivers additionally support scan offsets, which determine at what times these scans take place. Such offsets are synchronized with the system clock when the driver is first started and whenever it is subsequently restarted.

Many simple drivers also support scan promotion, whereby the scan rate can be temporarily increased. Typically, the increase is in reaction to an event, such as one or more associated points being displayed on a client (see Define Whether a Scanner is Promoted While its Points are on Display).

This section explains the type of Scan Rate, Offset, and Promotion fields that are available for simple drivers. The fields that are available differ, depending on the driver, but will include a combination of these fields:

  • Scan Rate—Specify the frequency with which the scanner scans its points for data that has changed. Enter the rate in the OPC Time Format, for example 30S for a 30- second scan rate. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required rate.

Example:

A Modbus scanner is configured with a scan rate of 30S. Every 30 seconds, the scanner sends a scan request to a Modbus PLC. In response to that request, the PLC reports any data changes to the scanner.

  • Offset—Use this field to specify the actual time at which a scan takes place. Scan times are synchronized with the server’s system clock whenever the driver is restarted. The offset is used in conjunction with the scan rate to determine when each scan occurs.

Enter the offset in the OPC Relative Time Format. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required value.

It is advisable that the scan rate and offset are fully divisible, so that scan times occur at readily recognizable times.

Example:

A scanner has this configuration:

Scan Rate: 15S
Scan Offset: M (‘the beginning of the current minute’)

The driver is started as the system clock shows a time of 14:19:25.

Using the scanner configuration, ClearSCADA determines that the scanner should start its first scan at 14:19:30 (30 seconds past the beginning of the current minute (as the first 15-second interval after the beginning of the current minute is already in the past)).

The next scan occurs at 14:19:45 (15 seconds after the first scan, as specified by the Scan Rate property). Thereafter, scans occur at 15 second intervals (on the minute, and at 15, 30, and 45 seconds after each minute).

  • Normal Scan Rate—Enter the frequency with which the scanner usually scans for data changes. If the rate at which scanning occurs is increased whenever the associated points are displayed on a client, this scan rate is temporarily replaced by the Promoted Scan Rate (see below).

Enter the Normal Scan Rate interval in the OPC Time Format, for example 30S for 30 seconds. It is advisable to specify a full division of a minute or hour, and so on, so that scan times are consistent (for example, at 15- or 30-second intervals).

You can enter the value directly in the Normal Scan Rate field, or use the Interval Window (accessed via the field’s browse button) to specify the required rate.

  • Normal Scan Offset—Use this field to specify the actual time at which a normal scan takes place. Scan times are synchronized with the server’s system clock whenever the driver is restarted. The offset is used in conjunction with the scan rate to determine when each scan occurs.

Enter the offset in the OPC Relative Time Format. You can enter the value directly in the Normal Scan Offset field, or use the Offset Window (accessed via the field’s browse button) to specify the required value.

It is advisable that the scan rate and offset are fully divisible, so that scan times occur at readily recognizable times.

Example:

A scanner has this configuration:

Normal Scan Rate: 30S
Normal Scan Offset: M (‘the beginning of the current minute’)

The driver is started as the system clock shows a time of 14:17:23.

Using the scanner configuration, ClearSCADA determines that the scanner should start its first scan at 14:17:30 (30 seconds past the beginning of the current minute).

The next scan occurs at 14:18:00 (30 seconds after the first scan, as specified by the Normal Scan Rate property).

Thereafter, scans occur at 30 second intervals (at 30 seconds after each minute, and on each minute).

  • Promoted Scan Rate—Use this field if the rate at which scanning usually occurs is to be temporarily increased whenever the associated points are displayed on a client. Such promotion is specified using the Promote when Displaying Points check box (see Define Whether a Scanner is Promoted While its Points are on Display).

Use the Promoted Scan Rate field to specify the rate at which the scanner scans for data changes while the associated points are displayed on a client.

Enter the interval in the OPC Time Format, for example 5S for five seconds. It is advisable to specify a full division of a minute or hour, and so on, so that scan times are consistent (for example, at 5- or 10-second intervals).

You can enter the value directly in the Promoted Scan Rate field, or use the Interval Window (accessed via the field’s browse button) to specify the required rate.

  • Promoted Scan Offset—Use this field to specify the actual time at which a promoted scan takes place. Scan times are synchronized with the server’s system clock whenever the driver is restarted. The offset is used in conjunction with the scan rate to determine when each scan occurs.

Enter the offset in the OPC Relative Time Format. You can enter the value directly in the Promoted Scan Offset field, or use the Offset Window (accessed via the field’s browse button) to specify the required value.

It is advisable that the scan rate and offset are fully divisible, so that scan times occur at readily recognizable times.

Example:

A scanner that scans points on an RTU has this configuration:

Normal Scan Rate: 30S
Normal Scan Offset: M + 5S (‘five seconds past the beginning of the current minute’)
Promoted Scan Rate: 10S
Promoted Scan Offset: M + 5S

Promotion occurs whenever any of the points that are being scanned are displayed on a client.

Normal scans occur at five seconds past the minute, and at 35 seconds past the minute.

At 14:18:26 a Mimic is displayed, which includes three of the points that the scanner is monitoring. The Mimic remains on display until 14:20:13.

During this time, the scan rate of the scanner increases to every ten seconds (scanning the RTU at 14:18:35, 14:18:45, 14:18:55, and so on).

Once the Mimic is closed, and points are no longer displayed on a client, the scanner resumes scanning at the Normal Scan Rate, scanning its RTU at five seconds past the minute, and at 35 seconds past the minute.


Simple Drivers Guide - Define Whether a Scanner is Promoted While its Points are on Display (Configuring Scanners on Simple Drivers)

Define Whether a Scanner is Promoted While its Points are on Display

This feature applies to many scanners on simple drivers—see the driver-specific documentation to see whether this feature applies to the scanners on your system.

Where this feature is supported, you can give a scanner scanning preference whenever any of its points are displayed on a client. For example, when a Mimic is displayed that shows one or more of the scanner’s points.

Clear the Promote when Displaying Points check box if you do not want the server to give scanning preference to a scanner when its points are displayed on a client.

Select the Promote when Displaying Points check box if you want the ClearSCADA server to give scanning preference to a scanner whenever any of its points are displayed on a client.

Specify the rate at which data is scanned during a promotion window, using the Promoted Scan Rate and, where applicable, the Promoted Scan Offset fields on the Scanner tab (see Define the Scan Rate).

ATTENTION: If this feature is enabled for many scanners, and points for many of those scanners are displayed at the same time, this could have an adverse affect on the system, and may result in the intended promotion not being achieved.


Simple Drivers Guide - Define Whether a Scanner is Used to Trigger Logic (Configuring Scanners on Simple Drivers)

Define Whether a Scanner is Used to Trigger Logic

The scanners on many simple drivers can be used to trigger logic programs within ClearSCADA. Where this feature is supported, you can use the Always Update on Scan check box to define whether the scanner is to be used in this way. The check box is displayed on the Scanner tab of the Scanner Form:

  • Always Update on Scan—Select the check box if you want to use the scanner’s updates as a trigger for a Logic program.

Clear the check box for the scanner only to be updated whenever any of its data changes. Scanners updated in this way cannot be used to trigger Logic programs.

The Always Update on Scan feature has no effect on the scanning and updating of point data on the system.


Simple Drivers Guide - Points on Simple Drivers

Points on Simple Drivers

ClearSCADA uses Points to represent the calculated values, measuring instruments or control devices that are connected to the scanners on your system. The type of point differs, depending on the type of calculation, measuring instrument or control device that the point represents.

The point types that are supported by simple drivers differ, depending on the driver—for a list of supported points, see the driver-specific documentation.

Before you configure a point in ClearSCADA, ensure that you carry out any necessary Preparation so that you can specify the appropriate properties for the point in the ClearSCADA database.

You configure the points required on your system using the appropriate Point Forms (see Create and Configure a Point in the ClearSCADA Guide to Core Point Configuration).

Each Point Form has several tabs (see Tabs on Point Forms). Use the tabs to define different aspects of point configuration.

This guide explains features that are common to many points on simple drivers, including how to:

  • Configure Common Point Properties
  • Scale Analog Values for use in ClearSCADA.

For information on configuring the properties that appear on the <Point Type>, <Driver Type>, or Control tabs of the Point Form, see the appropriate driver documentation, along with the ClearSCADA Guide to Core Point Configuration. The specific driver guides explain the point types and properties that are driver-specific. The ClearSCADA Guide to Core Point Configuration cover aspects of point configuration that are common to many drivers.

For information on other tabs, see Tabs on Point Forms.

For information on the minimal amount of configuration that you can undertake to produce a functional point in ClearSCADA, see Minimum Configuration.


Simple Drivers Guide - Preparation (Points on Simple Drivers)

Preparation

Before you can successfully configure the points on a simple driver, the scanner(s) to which the points are attached have to exist in the database (see Configuring Scanners on Simple Drivers).

You will need to know the unique identifier for the point, and the format in which the point data is to be displayed within ClearSCADA.

If you are configuring a point that uses digital-type processing, you will need to know what the states of the point represent.

If you are configuring a point that uses analog-type processing, you will need to know the type of scaling that is required to convert the raw input value into an engineering value that ClearSCADA can process, and the range of the point. This information is typically recorded by the engineer that sets up the device.

You need to be aware of the significance of the point’s alarms and events in relation to the entire system—this will determine the priority that you allocate to the point.

If supported by the scanner and point type, and required on your system, you will need to know whether the scanner is to log historic data for the point, and if so, the type of data or changes that are to be logged.

You will need to establish which features are required for each point. You can configure each point to use a variety of features, including alarm redirection. Many of these features are optional and do not affect the success of point communications. Optional features include:

  • Alarm view
  • Alarm redirection
  • User methods.

If the features listed above are not configured, they are not used for the point (they will be left blank).

If you do not have access to the required information to enable you to configure the points on your system, please contact a system administrator.


Simple Drivers Guide - Tabs on Point Forms (Points on Simple Drivers)

Tabs on Point Forms

Point Forms have several ‘tabs’ or ‘pages’ for configuring different aspects of point data. For many points on simple drivers, these tabs are available:

  • Identification—Use to optionally define a Help View and to indicate whether a point is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for a point (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with any point alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for a point (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • <Point Type> (see the driver-specific documentation, and also see the ClearSCADA Guide to Core Point Configuration).
  • Historic—Use to define any historic data storage properties for a point (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration). This tab is only displayed for points that can support historic data.
  • <Driver Type>—Use to define any point- or driver-specific properties. See the driver-specific documentation and also, as applicable:
  • Configure Common Point Properties
  • How to Scale Analog Values for use in ClearSCADA.

In addition, on drivers that support controls (outputs), a Control tab is displayed. You define whether a point is an input or an output by using an Enabled check box on this tab. For information on configuring the properties on the Control tab, see the driver-specific documentation for any driver-specific fields, and also, as appropriate:

  • see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration.
  • see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration.
  • see Define the Control Settings for a String Point in the ClearSCADA Guide to Core Point Configuration.
  • see Define the Control Settings for a Time Point in the ClearSCADA Guide to Core Point Configuration.


Simple Drivers Guide - Minimum Configuration (Points on Simple Drivers)

Minimum Configuration

For each point, as a minimum you have to specify these features on the appropriately named <Driver Type> tab, then ensure that the point is In Service and save the configuration:

  • The Scanner or other device to which the point is attached.

If you want point data to be stored historically, you also have to:

  • Enable and configure logging on the Historic tab, if data is to be stored historically in the server database.


Simple Drivers Guide - Configure Common Point Properties (Points on Simple Drivers)

Configure Common Point Properties

Use the fields at the top of the <Driver Type> tab to define these properties:

  • In Service—Use to specify whether the point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point that is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Scanner—Use to specify the scanner that scans the point’s data. Select the browse button to display a Reference browse window, and select the scanner from the window.


Simple Drivers Guide - Scale Analog Values for use in ClearSCADA (Points on Simple Drivers)

Scale Analog Values for use in ClearSCADA

Many simple drivers that support analog points also support scaling of the raw analog values into ‘engineering’ values that can be used within the ClearSCADA database. Scaling allows the raw signal values from plant to be scaled into more appropriate values for use within ClearSCADA and vice versa.

You typically configure scaling on the <Driver Type> tab of the appropriate Analog Point Form. This section explains the scaling properties that exist for analog points on many simple drivers. The driver-specific documentation mentions whether scaling is supported, or whether scaling properties differ, for the analog points on a particular driver.

Where supported by a driver, you use the fields within the Scaling section of the <Driver Type> tab to specify whether scaling of raw input values is required:

  • Enabled—Select this check box if the raw input values are to be scaled for use in ClearSCADA, or vice versa for any output values. Use the fields in the rest of the Scaling section to define the scaling that is required—the range of raw signal values is scaled to the range of values specified in the Alarm Limits section of the Analog Point tab, when a value is used in ClearSCADA, and vice versa whenever ClearSCADA sets an analog value on a device.

Clear the Enabled check box if scaling is not required. The raw input signals are used directly in ClearSCADA, without any scaling adjustment. (In other words, the Raw Full Scale and the Raw Zero Scale of the input value are identical to the Full Scale and Zero Scale settings specified in the Alarm Limits section of the Analog Point tab.) The other fields in the Scaling section are ‘grayed out’ and unavailable for use.

  • Raw Full Scale—Applies when Scaling is enabled. Enter the highest acceptable raw data value for the point (the full scale of the instrument or control device that this point represents).

For analog points on many simple drivers, you need to enter the appropriate value within the range 1 to 65535 (the driver-specific documentation mentions if this range differs).

When used in ClearSCADA, the driver scales the Raw Full Scale value to the value that is specified in the Full Scale Limit field on the Analog Point tab.

  • Raw Zero Scale—Applies when Scaling is enabled. Enter the lowest acceptable raw data value for the point (the zero scale of the instrument or control device that this point represents).

For analog points on many simple drivers, you need to enter the appropriate value within the range 0 to 65534 (the driver-specific documentation mentions if this range differs).

When used in ClearSCADA, the driver scales the Raw Zero Scale value to the value that is specified in the Zero Scale Limit field on the Analog Point tab.

Example:

An Analog point has a raw scale of 0 to 4095 (12-bit). This is to correspond in ClearSCADA to an engineering scale of 0 to 10.

On the Form for the point, Scaling is enabled and configured with the raw value range:

In the Alarm Limits section of the Form, the engineering scale values are specified, along with any limits that indicate notable changes in operating condition:

As such, the Full Scale engineering value of 10 corresponds to the Raw Full Scale value of 4095 and the Zero Scale engineering value of 0 corresponds to the Raw Zero Scale value of 0.

The usual operating range of the plant is defined by the Normal state, which in engineering terms is when the value is between 2 and 8. This corresponds to a raw operating range of 819 to 3276.

Therefore, from normal operating conditions, if the raw value rises to 3276 or above, when that value is reported to the server, ClearSCADA will raise an alarm, as the value has exceeded the High Limit of 8 (which corresponds to the raw value of 3276).

Similarly, if the raw value continues to rise until it reaches 3685.5 or above, ClearSCADA will raise an alarm to indicate that the corresponding engineering value has exceeded the High High Limit of 9 (the engineering equivalent of 3685.5).


Simple Drivers Guide - System Analysis

System Analysis

This section is for system administrators and high-level engineers who need to use statistical and diagnostic information to assess the state of the ClearSCADA system. This section applies to most simple drivers. For driver-specific information, see the individual driver guides. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

During system analysis, you might need to:

  • Adjust the Configuration of any Points that Cause a High Load
  • Use Driver Log File Options that are Common to Many Simple Drivers.

Additionally, if a scanner is not communicating with the server when it should be, see Troubleshooting.

NOTE: When troubleshooting on a ClearSCADA system, always check the Events List for diagnostic messages. These may help to identify the cause of any abnormal conditions that ClearSCADA has detected.


Simple Drivers Guide - Adjust the Configuration of any Points that Cause a High Load (System Analysis)

Adjust the Configuration of any Points that Cause a High Load

A possible cause of deficient performance on a ClearSCADA system is that of inadequate client performance (see Diagnose Client Performance Problems in the ClearSCADA Guide to the Server Status Tool). One of the causes of inadequate performance is high load on the server.

You can use the statistics that are displayed in Lists and Status displays to identify any scanners that are causing a high loading on the ClearSCADA system.

For those scanners that have a high load, use the Points List to identify the point(s) that are causing the high load.

High load is typically caused by a point updating at too frequent a rate.

Where a point on a simple driver is causing a high load:

  1. If many points on a scanner are causing a high load, you might need to:
  • Adjust the Scan Rate of the scanner.

Or:

  • Move those points onto a separate scanner, and set that scanner to have a lower scan rate.
  2. If historic data is being logged for a point, you might need to decrease the frequency with which that data is logged.
  3. If point values are logged if they change significantly, you might need to increase the Significant Change deadband—the amount by which the point value has to change in order for the value to be updated in the ClearSCADA database. If need be, adjust the value in the Deadband field on the Point Form. Significant Change is supported by several simple drivers.
  4. If fluctuating changes of state are raising and clearing alarms, you might want to increase the Hysteresis—the amount by which an analog point’s value has to decrease below a high limit, or increase above a low limit, for an alarm to be cleared.
  5. If momentary changes in state are causing a high load, you might want to increase the Persistence setting for a digital point. Adjust this setting using the Persistence field on the relevant Point Form. Be aware that a sudden increase in momentary changes in state might indicate an abnormal condition elsewhere. Ensure that the hardware, plant, and instrumentation are checked at a suitable time to make sure that no underlying hardware problem that is causing the sudden increase. Persistence is supported by many simple drivers.
  6. If none of the above checks and configuration changes have cleared the high load caused by the point, check the following equipment for any faults:
  1. Hardware
  2. Plant
  3. Instrumentation.


Simple Drivers Guide - Driver Log File Options that are Common to Many Simple Drivers (System Analysis)

Driver Log File Options that are Common to Many Simple Drivers

Driver Logging can be used to help diagnose abnormal conditions relating to driver activity. Driver logging can also be used for assessing potential problems. The log files that are produced provide useful diagnostic information about specific aspects of the system. For instance, the Points logging option provides diagnostic information about the points on a particular driver.

Should you need to contact Schneider Electric for assistance with resolving a problem that ClearSCADA has detected, you might be asked to provide log files to help in assessing the cause of the problem. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

This section explains the driver logging options that are common to many simple drivers.

Those driver logging options that are typically required for investigating abnormal conditions are enabled by default. We suggest that the logging options are left at this default unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

For information on any driver logging options that are not listed below, see the driver-specific documentation.

These driver log file options are common to many simple drivers:

  • Application—Logs general information about the driver.
  • Errors—Logs any errors detected during driver operation. For example, unexpected communications interruptions, or a loss of connection to the ClearSCADA database.
  • Point Source—Logs information about the scanner(s) on a driver.
  • Server—This option is available for several simple drivers. The option logs information about the channel or server. For example, the assigning of ports, or connection to a remote server.
  • Browse Requests—This option is available for several simple drivers. The option logs information about use of some of the browse options on configuration Forms. For example, the Tag browser on a Point Form, and the Comm Port browser on a Channel Form.
  • DBServer Requests—Logs information related to requests from users (and so from the server)
  • DBServer Calls—Logs information about the low-level interface from driver to server.

Further Information

Log files and log file settings: see Logging and Monitoring in the ClearSCADA Guide to Server Administration.

Displaying Log files: see Display a Driver Log File in the ClearSCADA Guide to Server Administration.

Types of log file supported by ClearSCADA: see Logging and Monitoring in the ClearSCADA Guide to Server Administration.


Simple Drivers Guide - Troubleshooting

Troubleshooting

Use the charts in this section if you have a scanner on your system that should be, but is not, healthy (online). The charts guide you through a series of checks to assess why the scanner might be in the failed state.

In each case, start with CHART 1: Basic Checks for Scanners that are in a Failed State. This chart will guide you through some basic checks. If these checks do not solve the abnormal condition that ClearSCADA has detected, you will be directed to carry out further checks on other charts.

If ClearSCADA has detected an abnormal condition associated with a scanner on a simple driver, we recommend turning on the log file options for that driver (see Driver Log File Options that are Common to Many Simple Drivers).

After the abnormal condition has re-occurred, send the log files to Schneider Electric. You may be asked to turn on different logging options and reproduce the abnormal condition, if the condition cannot be diagnosed from the initial logs.

For further information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool, and the driver-specific documentation.

NOTE: When troubleshooting on a ClearSCADA system, always check the Events List for diagnostic messages. These may help to identify the cause of any abnormal conditions that ClearSCADA has detected.

NOTE: To display channel or server details in List format from the Queries Bar, filter the constraints on the Channels List.
To display scanner details in List format from the Queries Bar, filter the constraints on the Point Sources List.


Simple Drivers Guide - CHART 1: Basic Checks for Scanners that are in a Failed State (Troubleshooting)

CHART 1: Basic Checks for Scanners that are in a Failed State

Further Information

CHART 2a: Scanners using Serial Communications.


Simple Drivers Guide - CHART 2a: Scanners using Serial Communications (Troubleshooting)

CHART 2a: Scanners using Serial Communications

Further Information

CHART 1: Basic Checks for Scanners that are in a Failed State.

CHART 2b.


Simple Drivers Guide - CHART 2b (Troubleshooting)

CHART 2b

Further Information

CHART 2a: Scanners using Serial Communications.


DDE Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


DDE Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


DDE Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


DDE Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


DDE Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


DDE Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure ClearSCADA to use the Dynamic Data Exchange (DDE) protocol to communicate with third-party devices. It also describes the various DDE driver features that can be used for diagnosing DDE-related issues.

For more details, see Introduction to the DDE Driver.


DDE Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed to be used by engineers who are responsible for configuring database items to make use of the features of the DDE driver. It can also be used by system administrators for diagnosing communication issues relating to the DDE protocol.


DDE Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

NOTE: The DDE driver is incompatible with Windows 7.

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Specifications in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


DDE Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration


DDE Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


DDE Driver Guide - Introduction to the DDE Driver

Introduction to the DDE Driver

Dynamic Data Exchange (DDE) is a commonly used communications protocol that enables data exchange between servers and clients, regardless of the product manufacturer.

ClearSCADA can use the DDE protocol to communicate with third-party devices, such as Siemens® S5 PLCs. The ClearSCADA DDE Driver provides a ClearSCADA system with the additional functionality required to communicate with devices using the DDE protocol.

The DDE documentation explains how to configure DDE-specific features and items within the ClearSCADA database (see Configuring DDE Devices in ClearSCADA). In order to configure such items successfully, you need to be familiar with DDE Components and Terminology.

The documentation also explains driver-specific aspects that may be of interest to System Administrators and engineers when investigating unexpected system behavior (see DDE Specific Status Display Attributes).

NOTE: There are no driver-specific pick actions for items on the DDE driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


DDE Driver Guide - DDE Components and Terminology (Introduction to the DDE Driver)

DDE Components and Terminology

This section summarizes the DDE components and terms with which you need to be familiar, in order to configure the DDE-specific properties in ClearSCADA. They comprise:

  • Service
  • Topic
  • Item.

You specify each DDE component as an alphanumeric text string on the appropriate configuration Form. Each string can comprise any combination of standard alphanumeric characters, up to 255 characters long.

You need to specify each string in a format that the DDE server can interpret. Refer to the documentation provided with the DDE provider for details.


DDE Driver Guide - Service (Introduction to the DDE Driver)

Service

A Service is a DDE provider. This is typically a software application, such as Excel®, that allows data transfer using the DDE protocol. An application typically provides one Service, although some applications may provide multiple Services.

You specify the Service on the DDE Server Form (see Configure the General DDE Properties).


DDE Driver Guide - Topic (Introduction to the DDE Driver)

Topic

A Topic is a logical grouping of data items within a given Service. For example, an Excel® Work sheet.

You specify a Topic on the appropriate DDE Scanner Form (see Configure the DDE Properties).


DDE Driver Guide - Item (Introduction to the DDE Driver)

Item

An Item is a single data value within a DDE Topic. For example, a single cell within an Excel® Work sheet.

You specify an Item on the corresponding DDE Point Form (see Configure Common Properties on the DDE Tab).


DDE Driver Guide - Configuring DDE Devices in ClearSCADA (Introduction to the DDE Driver)

Configuring DDE Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database reference the devices and plant that you are trying to monitor on your system. This section summarizes the database items that you need to configure in order to read and write to data on other servers, using the DDE protocol.

To communicate with other servers using the DDE protocol, the DDE Driver has to be installed and running on the ClearSCADA servers on your system. The driver is represented by the DDE Client component in the ClearSCADA Installation Wizard’s Setup window. The component is located within the Server branch of the tree that is displayed in the window (see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers).

When you configure DDE items in the ClearSCADA database, many of the settings for those items need to correspond to the settings on the relevant DDE servers on your system. You need to have access to, or a list of, these settings before you can configure the DDE database items successfully.

For instance, you need to know the read and write mechanisms that are supported by the DDE servers on your system, and the user names and passwords that allow the required level of access to the data if the DDE servers run on different machines to the ClearSCADA database. You also need to be familiar with DDE Components and Terminology.

You also need to be aware of which optional features are required for each DDE item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with DDE database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each DDE device, you need to configure:

  1. DDE Servers to specify the servers on which data is to be scanned, along with any access and security properties required to communicate with those servers.

You need to configure one DDE Server item in the database for each server with which you want to communicate using the DDE protocol (see Configuring a DDE Server).

  2. DDE Scanners to specify which nodes are to be scanned and the rates at which the data is to be retrieved.

You need to configure a minimum of one DDE Scanner per DDE Server. You can attach multiple scanners to the same server. For instance, you might configure different scanner to have different scan rates or offsets, in order to retrieve some data at different intervals or times to other data.

For more information, see Configuring a DDE Scanner.

  3. DDE Points to represent the measuring instruments and control devices on the servers that are communicating using the DDE protocol.

For more information, see Points Used on DDE Scanners.

To minimize the time that it takes to configure the required DDE items, you may want to configure them in the order listed above, as the Scanner configuration requires that you specify a server, and point configuration requires that you specify a scanner, and so on.


DDE Driver Guide - Configuring a DDE Server

Configuring a DDE Server

For every server with which you want ClearSCADA to communicate using the DDE protocol, you need to configure a DDE Server in the ClearSCADA database. In order to configure each DDE Server successfully, you need to ascertain the required settings for that Server (see Preparation). You can then use the fields on the DDE Server Form to configure the DDE server in the ClearSCADA database.

The Form has several tabs.

Use the fields on the DDE tab to:

  • Configure the General DDE Properties
  • Specify NetDDE Properties.

For information on the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


DDE Driver Guide - Preparation (Configuring a DDE Server)

Preparation

You need to add a DDE Server for each server on your system with which you want to communicate using the DDE protocol.

To configure a DDE Server, you need to know the DDE Service name used by the server, and the name of the node on which it is located if it is not on the same PC as the ClearSCADA database. You also need to know the read and write mechanisms that are supported by the server, along with the user name(s), password(s), and domain(s) that allow the required access to the data if ClearSCADA is to access the server remotely.

You also need to establish which features are required for each DDE server. You can configure each server to use a variety of features, including alarm redirection. However, many of these features are optional and have no effect on the success of communications. The optional features include:

  • Alarm view
  • Alarm redirection
  • User methods.

If the features listed above are not configured, they are not used for the selected server (they will be left blank).


DDE Driver Guide - Configure the General DDE Properties (Configuring a DDE Server)

Configure the General DDE Properties

Use the fields toward the top of the DDE tab to specify the general communication properties of the DDE server.

  • In Service—Use to specify whether the DDE server is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

NOTE: If you later take the server out of service, its scanners and their dependants (such as points) also become out of service. This does not affect the configuration of these items.

  • Severity—Use to define the severity of any alarms or events that are associated with the DDE server (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—This field is displayed if the Area of Interest feature is enabled on your system. Use the field to specify the Area of Interest with which any of the DDE server’s alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Read Mode—DDE servers can support either of two read mechanisms. Use this combo box to specify which read mechanism is supported by the server to which you want to connect. Choose from Asynchronous or Synchronous.
  • Timeout—Use to specify the length of time that the driver is to wait for a response when attempting to communicate with a DDE server. If no response is received by the time specified in this field, ClearSCADA times out the request and marks the points (and scanner, if this caused the timeout) as invalid.

Specify the required time in the OPC Time Format, for example 0.5S for half a second.

If ClearSCADA is to access a DDE server remotely, via a network, you need to increase the timeout from the default of 0.5S.

  • Service—Use to specify the name of the DDE Service with which this server is to connect. Specify the service as an alphanumeric text string, in a format that is readable by the DDE provider.

Example:

L2FDLSS
(for an S5 PLC DDE service)

\\NODE1\NDDE$
(for a Windows® NetDDE service)


DDE Driver Guide - Specify NetDDE Properties (Configuring a DDE Server)

Specify NetDDE Properties

The DDE server with which ClearSCADA communicates can reside on the same or another node to the server(s) on which the ClearSCADA database resides.

Use the fields within the NetDDE section of the DDE tab to specify whether the DDE server is on the same node as the ClearSCADA database, or is a NetDDE server that is to be accessed remotely via a network.

Where ClearSCADA is to access a remote NetDDE server, you need to specify the user name, password, and domain of a user that has a valid logon to both machines (the ClearSCADA server and the DDE server).

  • Enabled—Select this check box if the DDE server is located on another node (computer) to the server(s) on which the ClearSCADA database resides. Use the other fields in the NetDDE section of the tab to specify the settings that allow ClearSCADA to access the remote NetDDE server via the network.

Clear the Enabled check box if the DDE server is located locally, on the computer on which the ClearSCADA database resides. The other fields within the NetDDE section are ‘grayed out’ and unavailable for use.

  • Username—Applies when ClearSCADA is to access a NetDDE server remotely, via a network. Specify a user name that allows suitable access to the NetDDE server via the network connection. You need to specify the name of a user whose privileges allow the required read/write access to data on the NetDDE server. Enter the user password in the field below.
  • Password—Applies when ClearSCADA is to access a NetDDE server remotely, via a network. Specify the password that, when used in conjunction with the Username specified above, allows the required access via the network connection.
  • Domain—Applies when ClearSCADA is to access a NetDDE server remotely, via a network. Specify the domain of the user that enables ClearSCADA to log on to the remote NetDDE server.


DDE Driver Guide - Configuring a DDE Scanner

Configuring a DDE Scanner

A DDE Scanner is logical functionality that runs within ClearSCADA and scans for data on a DDE server (any server connected to the ClearSCADA network, with which ClearSCADA communicates using the DDE protocol).

You can attach multiple scanners to each DDE server on your system. By specifying different scan rates and offsets, you can enable the DDE driver to scan certain data at different intervals and times to other data on the same server.

Configure scanner features using the fields on the DDE Scanner Form.

The Form has several tabs.

Use the fields on the DDE tab to specify the scan properties, such as the scan rate and offset, and the DDE Topic with which ClearSCADA is to exchange data (see Configure the DDE Properties).

For fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional DDE Scanner in ClearSCADA, see Minimum Configuration.


DDE Driver Guide - Minimum Configuration (Configuring a DDE Scanner)

Minimum Configuration

For a DDE scanner to become functional (online), you need to specify:

  • The server on which it is to scan data
  • The DDE Topic with which ClearSCADA is to exchange data.

You also need to put the scanner In Service, and save the configuration.

These are the minimum requirements and, when configured, will result in a functional scanner that uses the default configuration settings.


DDE Driver Guide - Configure the DDE Properties (Configuring a DDE Scanner)

Configure the DDE Properties

Use the fields on the DDE tab to define the driver-specific properties of a scanner. Many of these fields are common to many scanners (see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the DDE driver are described below.

  • Server—Use the browse button to select the name of the server on which the DDE scanner is to scan data.
  • Topic—Use to specify the DDE Topic with which the driver is to exchange data. Specify the Topic as an alphanumeric text string.

Example:

STATION1


DDE Driver Guide - Points Used on DDE Scanners

Points Used on DDE Scanners

DDE scanners read and write to data on DDE servers. You need to map the data on each DDE server to suitable DDE points within the ClearSCADA database, to enable ClearSCADA to handle the data in a similar way to other point data on the system (for instance, in order to monitor state changes, raise alarms, or execute controls).

The DDE driver can support any of the point types that are listed below. You need to configure those point types that present the DDE node data in a suitable format within the ClearSCADA database.

Where a point type is specific to the DDE Driver, a short description is given below. For descriptions of other point types, see the ClearSCADA Guide to Core Point Configuration.

For information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

For information on configuring fields on the DDE tab, see Configure Common Properties on the DDE Tab. For analog points, also see Configuring Analog Points.

For information on configuring fields on the <Point Type> tab, see the references below:

  • Analog Point—see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.
  • Digital Point—see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.
  • String Point—a point for which the source is a text string, rather than a numeric value (see Configuring String Points).
  • Time Point—a point for which the source is a time value (see Configuring Time Points).

For fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


DDE Driver Guide - Configure Common Properties on the DDE Tab (Points Used on DDE Scanners)

Configure Common Properties on the DDE Tab

Use the fields at the top of the DDE tab to configure the common properties for each point. Some of the fields are common to points on many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to points on the DDE driver are explained below.

  • Item—In DDE terminology, a ‘point’ value on a DDE server is referred to as an Item. Use the Item field to specify the item of data that you want to monitor or control from ClearSCADA, using this point. Specify the Item as an alphanumeric text string.

Example:

DW53


DDE Driver Guide - Configuring Analog Points

Configuring Analog Points

The DDE driver supports Analog Input and Analog Output points.

The points are used to map ‘point’ data on DDE servers into ClearSCADA in a format that it can understand, and vice versa.

Configure the properties of each analog point using the fields on the DDE Analog Point Form.

This section covers configuration of analog-specific properties on the DDE tab of the Form.

Use the fields on the DDE tab to:

  • Configure Common Properties on the DDE Tab
  • Configure Scaling Properties (see Scale Analog Values for use in ClearSCADA in the ClearSCADA Guide to Simple Drivers)
  • Configure Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration)
  • Use Persistence to Stop Fleeting Changes in Value from Changing the Point State
  • Define the Historic Data Storage Properties.

For information on the fields on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

If the point is an output point, you also need to enable and configure the properties on the Control tab—for information, see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


DDE Driver Guide - Use Persistence to Stop Fleeting Changes in Value from Changing the Point State (Configuring Analog Points)

Use Persistence to Stop Fleeting Changes in Value from Changing the Point State

On the DDE tab, you can use Persistence to stop a change in value from affecting the point state until the point has been in that state for a specified time. This means the server does not have to process momentary changes of state or report those changes (see the example, below).

Use these fields in the Persistence section of the tab to define any persistence properties. In each instance, the persistence time begins whenever the point value drops below or rises above a state limit (by default, High-High, Low, and so on).

If, within the persistence time, the point value crosses a further limit in the same direction (that is, still continuing away from the Normal state, or still continuing toward the Normal state), the persistence period does not restart as it crosses the further limit. If the point value remains within the new state as the original persistence time elapses, the outstation updates the point state.

If the point value crosses back over a limit before the persistence time has elapsed, the point does not change state, and a new persistence time starts for the point value traveling in the new direction.

  • Away From Normal—Define the amount of time before the server updates the point state when the point value is moving away from the Normal State (toward Zero Scale or Full Scale).
  • Toward Normal—Define the amount of time before the server updates the point state when the point value is moving toward the Normal State (away from Zero Scale or Full Scale).

Example:

An analog point has this configuration:

Low Alarm Limit = 5.0
High Alarm Limit = 10.0
High-High Alarm Limit = 15.0

The Persistence properties are:

At 12:00:00 the point value is 8.0 (Normal).

At 12:00:10 the point value increases to 12.0, which is above the High limit.

At 12:00:20 the value of the point is still 12.0

At 12:00:30 the value of the point is still 12.0, so the point state changes to High as it has been 20 seconds since the value crossed the High Alarm Limit from the Normal state.

At 12:00:40 the value of the point further increases to 15.0 (the High-High Limit).

At 12:00:50 the point value is 15.0 (High-High).

At 12:01:00 the point value is still 15.0, so the point state changes to High-High as it has been 20 seconds since the value crossed the High-High Alarm Limit from the High State.

At 12:01:10 the point value decreases to 11.0, which is below the High-High Limit.

At 12:01:20 the point value is still 11.0

At 12:01:30 the point value is still 11.0

At 12:01:40 the point value is still 11.0, so the point changes state to High, as it has been 30 seconds since the value crossed the High-High Alarm Limit back toward the Normal State.

NOTE: Persistence does not apply where an analog point state becomes under range or over range (below Zero Scale, or above Full Scale), as these states are reported immediately.


DDE Driver Guide - Define the Historic Data Storage Properties (Configuring Analog Points)

Define the Historic Data Storage Properties

Use the fields within the Historic Data Filter section of the DDE tab to specify the type of data that ClearSCADA is to store historically for an analog point.

NOTE: Use the Historic Data Filter section in conjunction with the Historic tab, which defines whether the server stores values historically for the point, and whether any unnecessary data is filtered out to reduce storage requirements (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

The ClearSCADA server retrieves and processes the current data values from the DDE server(s) that it monitors. Use the check box within the Historic Data Filter section to specify the type of retrieved data that ClearSCADA is to store historically for a particular analog point:

  • State Change—Select this check box for ClearSCADA to store point state changes historically. Point state changes are stored historically in addition to current data values.

Clear the check box if you do not require ClearSCADA to store point state changes historically. ClearSCADA will then only store current value changes historically.

For example, you may wish to clear the State Change check box if Persistence is being used (see Use Persistence to Stop Fleeting Changes in Value from Changing the Point State) and the point data is to be displayed as a Historic Trend. By storing only current values historically, ClearSCADA will use any Persistence settings for alarm processing, but will only store current data values historically. As a result, ClearSCADA will only display those current values on any Historic Trends for the point.

If you had enabled historic storage of State Changes, two entries would have been stored in the Event Journal whenever a state change occurred—one entry for when the current value changed and another entry when the persistence time had elapsed and a state change occurred.)


DDE Driver Guide - Configuring String Points

Configuring String Points

Use DDE String points to map text strings on DDE servers into ClearSCADA.

Configure the properties of each String point using the fields on the DDE String Point Form.

For information on the String Point tab on the String Point Form, see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on the DDE tab, see Configure Common Properties on the DDE Tab.

For information on the Control tab on the Form, see Define the Control Settings for a String Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


DDE Driver Guide - Configuring Time Points

Configuring Time Points

Use DDE Time points to map time values on DDE servers into ClearSCADA.

Configure the properties of each Time point using the fields on the DDE Time Point Form.

For information on the Time Point tab on the Time Point Form, see Defining Time Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on the DDE tab, see Configure Common Properties on the DDE Tab.

For information on the Control tab on the Form, see Define the Control Settings for a Time Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


DDE Driver Guide - Configuring Digital Points

Configuring Digital Points

The DDE driver supports Digital Input points and Digital Output points.

The points are used to map ‘point’ data on DDE servers into ClearSCADA in a format that it can understand, and vice versa.

Configure the properties of each digital point using the fields on the DDE Digital Point Form.

This section covers configuration of digital-specific properties on the DDE tab of the Form.

Use the fields on the DDE tab to:

  • Configure Common Properties on the DDE Tab
  • Use Persistence to Stop Fleeting Changes in Value from Changing the Point State.

For information on the fields on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

If the point is an output point, you also need to enable and configure the properties on the Control tab—for information, see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


DDE Driver Guide - Use Persistence to Stop Fleeting Changes in Value from Changing the Point State (Configuring Digital Points)

Use Persistence to Stop Fleeting Changes in Value from Changing the Point State

Use the Persistence field near the top of the DDE tab to stop a change in value from affecting the point state until the point has been in that state for a specified time. This allows the driver to ignore fleeting changes in point value. It also stops ClearSCADA raising change of state alarms and logging change of state events when a point value is fluctuating.

When the point changes value, any change of point state is delayed until the point remains in the new state for a specified amount of time. If the point does not remain in the new state for the required amount of time, no change in point state is recorded.

If, within the persistence time, the value of a multi-bit point continues to increase or decrease in the same direction, the persistence period does not restart as the value crosses to a further state. If the point value remains within the new state as the original persistence time elapses, the outstation updates the point state.

If the value of a multi-bit point reverses its direction of travel before the persistence time has elapsed (for instance, it starts to increase when it was previously decreasing), the point does not change state, and a new persistence time starts for the point value traveling in the new direction.

  • Persistence—Use this field to specify the period, in seconds, that a point needs to remain in a new state before the DDE driver updates the ClearSCADA database with a change of value.


DDE Driver Guide - DDE Specific Status Display Attributes

DDE Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each DDE Analog point provides information about the present state of the individual point.

Use this section if you need information on the status of any DDE database items on your system.

This section covers those attributes that are DDE-specific, and includes:

  • DDE Server Status Attributes
  • DDE Scanner Status Attributes
  • DDE Point Status Attributes
  • Alphabetical List of DDE Specific Status Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Items on Many Drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


DDE Driver Guide - DDE Server Status Attributes (DDE Specific Status Display Attributes)

DDE Server Status Attributes

This status attribute is specific to DDE servers:

  • Source.


DDE Driver Guide - DDE Scanner Status Attributes (DDE Specific Status Display Attributes)

DDE Scanner Status Attributes

These status attributes are specific to DDE scanners:

  • Comms Statistics
  • Error Statistics
  • Source.


DDE Driver Guide - DDE Point Status Attributes (DDE Specific Status Display Attributes)

DDE Point Status Attributes

This status attribute is specific to DDE points:

  • Source.


DDE Driver Guide - Alphabetical List of DDE Specific Status Attributes (DDE Specific Status Display Attributes)

Alphabetical List of DDE Specific Status Attributes

This section lists those Status attributes that are specific to items on the DDE driver. The attributes are listed in alphabetical order and comprise:

  • Comms Statistics
  • Error Statistics
  • Source.


DDE Driver Guide - Comms Statistics (DDE Specific Status Display Attributes)

Comms Statistics

Associated with: DDE scanners

This status attribute shows the number of:

  • Reads—Read operations performed by the scanner
  • Read items—Data values read by the scanner
  • Writes—Write operations performed by the scanner

since the scanner was last restarted.

Example:

12 reads, 35 read items, 3 writes

Use the Error Statistics attribute to ascertain whether any of the above operations generated errors.


DDE Driver Guide - Error Statistics (DDE Specific Status Display Attributes)

Error Statistics

Associated with: DDE scanners

The Error Statistics attribute shows the number of errors generated during any of the read and write operations that are summarized by the Comms Statistics attribute.

The Error Statistics indicate the number of occurrences of each of the following, since the scanner was last restarted:

  • Read errors—The number of errors generated when attempting to read items.
  • Write errors—The number of errors reported from write operations.
  • Unknown item errors—The number of write completion messages that have been received for ‘unknown’ controls (controls that have not been sent by the ClearSCADA server).

Example:

0 read errors, 2 write errors, 0 unknown item errors


DDE Driver Guide - Source (DDE Specific Status Display Attributes)

Source

Associated with: DDE servers, scanners, and points

The Source attribute indicates the location at which the item resides.

This attribute is common to many Status displays, but the information shown varies, depending on the driver and the type of item:
DDE Item | Source Attribute
Server | Format | <Service>
 | Example: | L2FDLSS (for an S5 PLC DDE Service)
Scanner | Format | <Service>|<Topic>
 | Example: | L2FDLSS|STATION1 (for the Topic STATION1 running on the Service L2FDLSS)
Point | Format | <Service>|<Topic>!<Item>
 | Example: | L2FDLSS|STATION1!DW53 (for an Item DW53. Topic and Service as examples above)


DF1 Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


DF1 Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


DF1 Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


DF1 Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


DF1 Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


DF1 Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure your ClearSCADA system to communicate with Allen-BradleyTM PLCs using the DF1 protocol. It also explains how to use the diagnostic features of the DF1 driver.

For more information on the subjects covered in this Guide, see Introduction to the DF1 Driver.


DF1 Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed to be used by engineers who are responsible for configuring ClearSCADA to communicate with Allen-BradleyTM PLCs. It can also be used by system administrators when diagnosing any unexpected conditions relating to the DF1 driver.


DF1 Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


DF1 Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


DF1 Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


DF1 Driver Guide - Introduction to the DF1 Driver

Introduction to the DF1 Driver

The DF1 Driver provides extra functionality to allow a ClearSCADA system to be populated with data from, and control points on, Allen-BradleyTM PLCs. The driver allows ClearSCADA to communicate with such PLCs using the DF1 protocol.

ClearSCADA is able to communicate with Allen-Bradley PLCs using one of several ClearSCADA drivers. Which driver you use depends on your system set-up and the type(s) of Allen-Bradley PLC with which ClearSCADA is to communicate. Use the DF1 Driver to communicate with Allen-Bradley PLCs, where those PLCs are restricted to using serial communications and where RSLinxTM is not available.

For information on the other ClearSCADA drivers that can be used to communicate with Allen-Bradley PLCs, please contact your Schneider Electric agent.

The DF1 documentation explains how to configure the DF1-specific features and items within the ClearSCADA database (see Configuring DF1 Devices in ClearSCADA).

It also explains driver-specific aspects that may be of interest to system administrators and engineers when investigating any unexpected system behavior (see DF1 Specific Status Display Attributes).

For DF1 information not covered by this guide, see the Allen-Bradley DF1 documentation.

For PLC information not covered by this guide, see the Allen-Bradley documentation supplied with Allen-Bradley PLCs.

NOTE: There are no driver-specific pick actions for items on the DF1 driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


DF1 Driver Guide - Configuring DF1 Devices in ClearSCADA (Introduction to the DF1 Driver)

Configuring DF1 Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, control devices, and measuring instruments on your system. This section summarizes the database items that you need to configure in order to read and write data to Allen-Bradley PLCs using the DF1 protocol.

To communicate with Allen-Bradley PLCs using DF1, the DF1 Driver has to be installed and running on the ClearSCADA servers on your system. The driver is represented by the Allen-Bradley DF1 component in the ClearSCADA Installation Wizard’s Setup window. The component is located within the Server branch of the tree that is displayed in the window (see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers.)

When you configure DF1 items in the ClearSCADA database, many of the settings for those items need to correspond to the settings on the Allen-Bradley PLCs on your system. Some settings are either fixed (incorporated into the design of the Allen-Bradley PLC), or are configured by an engineer. You need to have access to, or an understanding of, these settings before you can configure the DF1 database items successfully.

For instance, you need to know the type(s) of Allen-Bradley PLC that the DF1 driver is to scan, and the identification numbers of the files in which the point data resides.

You also need to be aware of which optional features are required for each DF1 item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with DF1 database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each DF1 device, you need to configure:

  1. DF1 Channel(s) to represent the communication connections between each Allen-Bradley PLC and the ClearSCADA server (see Configuring a DF1 Channel).

You need to configure a separate DF1 channel for each separate communications channel that is available to the DF1 driver on your system.

  2. At least one DF1 Scanner for each Allen-Bradley PLC that the DF1 driver is to scan (see Configuring a DF1 Scanner).

Configure a scanner for each group of points that you want to scan at a different frequency, or that have a different data type.

  3. A DF1 Point for each separate item of data that is to be read from or written to in an Allen-Bradley PLC (see Points Used on DF1 Scanners).

You can associate multiple points with each DF1 Scanner.

To minimize the time that it takes to configure the DF1 items, you may want to configure them in the order listed above, as Scanner configuration requires that you specify a Channel, and Point configuration requires that you specify a Scanner, and so on.


DF1 Driver Guide - Configuring a DF1 Channel

Configuring a DF1 Channel

A DF1 Channel provides ClearSCADA with additional connection information so that the server can communicate successfully with Allen-Bradley PLCs using the DF1 protocol.

Specify the properties for a channel using the fields on the DF1 Channel Form.

The Form has several tabs (see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers).

Use the Channel tab to:

  • Configure the Basic Channel Properties
  • Configure the DF1 Communication Properties.

DF1 Channels use RS-232/RS-485 serial communications. Use the fields on the Connection tab to specify the required properties for a channel’s serial connection (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

For fields on the other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


DF1 Driver Guide - Basic Channel Properties (Configuring a DF1 Channel)

Basic Channel Properties

Use the fields at the top of the Channel tab to specify whether a channel is functional, and the severity of any alarms and events that are associated with the channel. For more information, see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers.


DF1 Driver Guide - Configure the DF1 Communication Properties (Configuring a DF1 Channel)

Configure the DF1 Communication Properties

Use the fields toward the bottom of the Channel tab to specify the channel’s communication properties. The Number of Retries and Timeout fields are common to channels on many simple drivers—for information, see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers. The fields that are DF1-specific are explained below.

  • Node ID—Use to specify the DF1 node ID of this master.
  • Duplex—Use to specify whether the channel uses a Full-Duplex or Half-Duplex serial link. Select the option that applies to the DF1 port on each PLC on the channel.

ATTENTION: You need to configure the PLCs on the channel to use the same Duplex setting. If a PLC and its channel have different Duplex settings, communications may be delayed or intermittent or ClearSCADA may deem the scanner to have failed.

  • Checksum—Use to specify the type of error checking that is to be used for communications via this channel. Specify either CRC (Cyclic Redundancy Check) or BCC (Block-Check Character), as applicable.


DF1 Driver Guide - Configuring a DF1 Scanner

Configuring a DF1 Scanner

A DF1 Scanner is logical functionality that runs within ClearSCADA and scans for data on an Allen-Bradley PLC.

Configure the Scanner properties using the fields on the DF1 Scanner Form.

The Form has several tabs (see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers).

This section covers fields on the Scanner tab that are specific to the DF1 driver (see Configure the Scanner Properties). For fields on the other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional DF1 Scanner in ClearSCADA, see Minimum Configuration.


DF1 Driver Guide - Minimum Configuration (Configuring a DF1 Scanner)

Minimum Configuration

For a DF1 scanner to be functional (online), you need to specify:

  • The channel through which the scanner communicates
  • The PLC type
  • The ID of the DF1 node.

You also need to put the scanner In Service and save the configuration.

These are the minimum requirements and, when configured, will result in a scanner that uses the default configuration settings.


DF1 Driver Guide - Configure the Scanner Properties (Configuring a DF1 Scanner)

Configure the Scanner Properties

Use the fields on the Scanner tab of the DF1 Scanner Form to define the general and DF1-specific properties for a scanner. Many of the fields on this tab are common to many scanners (see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the DF1 driver are described below.

  • Channel—Use to specify the channel through which the scanner transmits data. Use the browse button to display a Reference Browse window. From the window, select the channel that the scanner uses to communicate with an Allen-Bradley PLC.
  • PLC Type—Use this combo box to specify the type of Allen-Bradley PLC that the DF1 scanner is to scan.

Select the Generic option if the PLC-type with which ClearSCADA is to communicate is not listed separately. The Generic option offers a basic Read/Write command that is supported by many Allen-Bradley PLCs. Be aware that selecting the Generic option may limit the support for any additional functionality that would otherwise be available from one of the other options.

  • Node ID—Use to specify the ID of the scanned slave’s DF1 node.


DF1 Driver Guide - Points Used on DF1 Scanners

Points Used on DF1 Scanners

DF1 Scanners can support Analog points and Digital points.

You configure the DF1 points on your system by using the appropriate DF1 Point Form. The Forms have several tabs (see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers).

For information on configuring properties on the DF1 tab, see the rest of this section, which explains how to Configure General Point Properties on the DF1 Tab. For analog points, also see Configuring Analog Points; for digital points, also see Configuring Digital Points.

For information on configuring properties on the <Point Type> tab, see the appropriate reference below:

  • Analog Point—see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.
  • Digital Point—see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on the other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

For general information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.


DF1 Driver Guide - Configure General Point Properties on the DF1 Tab (Points Used on DF1 Scanners)

Configure General Point Properties on the DF1 Tab

Use the fields at the top of the DF1 tab to configure the general properties for a point. Some of these fields are common to points on many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to points on the DF1 driver are explained below.

  • File Number—Use to specify the number of the file from which ClearSCADA is to read or write data.
  • Data Type—Use to specify the format of the data that is to be read or written to. The options are Binary, Integer and Float. (The Float option only applies to Analog points.)

The configuration of the file within each PLC determines both the data type and how each ‘point’ interprets any data that it receives in a Read packet.

Select the option that corresponds to the data file’s configuration. This sets ClearSCADA to transmit any point data to the PLC in the required format. It also defines how ClearSCADA handles any point data that it retrieves from that data file in the PLC.

  • Address—Use to specify the address of the data, within the file that is specified above.


DF1 Driver Guide - Configuring Analog Points

Configuring Analog Points

The DF1 driver supports Analog Input and Analog Output points.

Configure the properties of each analog point using the fields on the DF1 Analog Point Form.

This section covers configuration of properties on the DF1 tab of the Form.

Use the DF1 tab to:

  • Configure General Point Properties
  • Configure Scaling Properties (see Scale Analog Values for use in ClearSCADA in the ClearSCADA Guide to Simple Drivers)
  • Configure Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration).

For information on the fields on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


DF1 Driver Guide - General Point Properties (Configuring Analog Points)

General Point Properties

Use the fields at the top of the DF1 tab to configure the general point properties. The properties are common to points on the DF1 driver—for information, see Configure General Point Properties on the DF1 Tab.


DF1 Driver Guide - Configuring Digital Points

Configuring Digital Points

The DF1 driver supports multi-bit Digital Input and Digital Output points.

Configure the properties of each digital point using the fields on the DF1 Digital Point Form.

This section covers configuration of properties on the DF1 tab of the Form. Use the DF1 tab to Configure the DF1 Point Properties.

For information on the fields on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


DF1 Driver Guide - Configure the DF1 Point Properties (Configuring Digital Points)

Configure the DF1 Point Properties

Use the fields on the DF1 tab to configure the DF1-specific properties for a digital point. Many of the fields on the tab are common to points on the DF1 driver—for information on these fields, see Configure General Point Properties on the DF1 Tab. Fields that are specific to DF1 digital points are explained below.

  • Offset—Enter the lowest (starting) bit of the point. With a multi-bit point, you need to consider that all bits are consecutive in the file (for example, a 2-bit digital might use bits 5 and 6, where bit 5 would be the starting bit).

The range is 0 to 15.

  • Persistence—Specify the time that the DF1 driver waits before it reports a change of state. Enter the time in seconds. This allows the driver to ignore fleeting changes in point state.


DF1 Driver Guide - DF1 Specific Status Display Attributes

DF1 Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each DF1 Digital point provides information about the present state of the individual point.

Use this section if you need information on the status of any DF1 database items on your system.

This section covers those attributes that are DF1-specific and includes:

  • DF1 Channel Status Attributes
  • DF1 Point Status Attributes
  • DF1 Scanner Status Attributes
  • Alphabetical List of DF1 Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


DF1 Driver Guide - DF1 Channel Status Attributes (DF1 Specific Status Display Attributes)

DF1 Channel Status Attributes

This status attribute is specific to DF1 channels:

  • Primary Assign.

NOTE: Three further status attributes—Primary Eavesdrop Tx Assign, Secondary Assign, and Secondary Eavesdrop Tx Assign—are not used by the DF1 driver.


DF1 Driver Guide - DF1 Point Status Attributes (DF1 Specific Status Display Attributes)

DF1 Point Status Attributes

This status attribute is specific to DF1 points:

  • Source.


DF1 Driver Guide - DF1 Scanner Status Attributes (DF1 Specific Status Display Attributes)

DF1 Scanner Status Attributes

These status attributes are specific to DF1 scanners:

  • Source
  • Comms Statistics.


DF1 Driver Guide - Alphabetical List of DF1 Specific Status Display Attributes (DF1 Specific Status Display Attributes)

Alphabetical List of DF1 Specific Status Display Attributes

This section lists those status attributes that are specific to items on the DF1 driver. The attributes are listed in alphabetical order and comprise:

  • Comms Statistics
  • Primary Assign
  • Source.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.


DF1 Driver Guide - Comms Statistics (DF1 Specific Status Display Attributes)

Comms Statistics

Associated with: DF1 scanners

This status attribute shows the number of:

  • Good Reads—Successful read operations
  • Good Writes—Successful write operations
  • Timeouts—Requests that did not receive a response within the expected time and therefore timed out. (The actual Timeout period is specified on the Channel Form.)
  • Checksum Errors—Errors returned due to invalid data transmissions. (The type of Checksum error checking used is specified on the Channel Form (see Configure the DF1 Communication Properties).)
  • Unknown Errors—Any other errors
  • Exceptions—Errors returned in response to the receipt of unsupported function codes.

that have been detected on a scanner since that scanner was last restarted.

Example:

48 good reads, 26 good writes, 0 timeouts, 0 checksum errors, 0 unknown errors, 2 exceptions


DF1 Driver Guide - Primary Assign (DF1 Specific Status Display Attributes)

Primary Assign

Associated with: DF1 channels

This attribute indicates whether the assignment of a DF1 channel to its serial line has failed. The line configuration is defined on the Connection tab of the Channel Form (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

Possible States: Displays one of the Standard Alarm States.


DF1 Driver Guide - Source (DF1 Specific Status Display Attributes)

Source

Associated with: Many DF1-specific items

The Source attribute is common to many Status Displays. The attribute indicates the location at which the item, for example the point, resides. The information shown varies, depending on the type of item.

For DF1 Scanners, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> <Node ID (this Master)>:
<PLC Type>,<Node ID (Slave)>

Example:

COM1:9600:8N1 7:Generic,14
(For a DF1 Scanner that is being used to scan generic Allen-Bradley PLCs via a DF1 slave that has the node ID 14. The DF1 node ID of this master is 7. The scanner uses a channel that has these settings: the channel communicates via port COM1, uses a 9600 baud rate, has 8 data bits, no parity (N) and 1 stop bit.)

For DF1 Analog Points, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> <Node ID (this Master)>:
<PLC Type>,<Node ID (Slave)>:<File Number>-<Address> <Data Type>

Example:

COM1:9600:8N1 7:Generic,14:12-8 Float
(For a DF1 analog point that is being used to scan floating-point data at address 8 within file number 12, on an Allen-Bradley PLC. The DF1 node IDs and communication details are as per the scanner example, above.)

For DF1 Digital Points, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> <Node ID (this Master)>:
<PLC Type>,<Node ID (Slave)>:<File Number>-<Address>.<Offset> <Data Type>

Example:

COM1:9600:8N1 7:Generic,14:22-6.2 Binary
(For a DF1 digital point that is being used to scan binary data at address 6, offset 2, within file number 22, on an Allen-Bradley PLC. The DF1 node IDs and communication details are as per the scanner example, above.)


Hilscher Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Hilscher Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Hilscher Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Hilscher Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Hilscher Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Hilscher Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure ClearSCADA to communicate with HilscherTM products that use PROFIBUS-FMS®, PROFIBUS-DP®, and DeviceNetTM. It also explains how to use the driver features for fault finding on the system.

For more information about the subjects covered in this Guide, see Introduction to the Hilscher Driver.


Hilscher Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by engineers who are responsible for configuring ClearSCADA to communicate with HilscherTM products. System administrators can also use this guide when investigating unexpected conditions related to the Hilscher driver.


Hilscher Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Hilscher Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration


Hilscher Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Hilscher Driver Guide - Introduction to the Hilscher Driver

Introduction to the Hilscher Driver

HilscherTM produce various products designed for use with fieldbus technology and for communications using one of several industrial fieldbus networks.

The ClearSCADA Hilscher driver enables ClearSCADA to transmit data to and from Hilscher devices, where those devices use one of the following fieldbus control networks:

  • PROFIBUS®—The ClearSCADA Hilscher driver enables ClearSCADA to communicate with Hilscher devices that are using either of these PROFIBUS protocols:
  • PROFIBUS-FMS (Fieldbus Messaging Specification) is a multi-master, peer-to-peer protocol and widely acknowledged international networking standard.
  • PROFIBUS-DP (Decentralized Peripherals) is a slave-master protocol. Where the ClearSCADA Hilscher driver communicates with a Hilscher device that uses PROFIBUS-DP, the Hilscher card is the master.
  • DeviceNetTM—DeviceNet utilizes Control Area Network (CAN) technology for data transmission and Common Industrial Protocol (CIPTM) for the upper layers of the network. It also allows for power on the network.

The Hilscher Driver documentation explains how to configure Hilscher-specific features and items within the ClearSCADA database (see Configuring ClearSCADA to Communicate with Hilscher Devices).

It also explains driver-specific aspects that may be of interest to System Administrators and engineers when investigating any unexpected system behavior (see Hilscher Specific Status Display Attributes).

For Hilscher, PROFIBUS, or DeviceNet information not covered by this guide, see the relevant Hilscher or fieldbus documentation.

NOTE: There are no driver-specific pick actions for items on the Hilscher driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


Hilscher Driver Guide - Configuring ClearSCADA to Communicate with Hilscher Devices (Introduction to the Hilscher Driver)

Configuring ClearSCADA to Communicate with Hilscher Devices

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, control devices, and measuring instruments on your system. This section summarizes the database items that you need to configure in order to read and write data to Hilscher devices.

In order to communicate with Hilscher devices, the Hilscher Driver has to be installed and running on the ClearSCADA servers on your system.

When you configure Hilscher items in the ClearSCADA database, many of the settings for those items need to correspond to the settings on the Hilscher devices on your system. Some settings are either fixed (incorporated into the design of the Hilscher device), or are configured by an engineer. You need to have access to, or an understanding of, these settings before you can configure the Hilscher database items successfully.

For instance, you need to know the location of the point data that you want ClearSCADA to scan on each Hilscher board or FMS device.

You also need to be aware of which optional features are required for each Hilscher item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with Hilscher database items, including Lists, Actions, and Mimics. See the core documentation for details.

The order and items that you configure in the ClearSCADA database varies, depending whether you want to configure ClearSCADA to communicate with:

  • ClearSCADA Configuration for Hilscher Devices on PROFIBUS-FMS Systems
  • ClearSCADA Configuration for Hilscher Devices on DeviceNet or PROFIBUS-DP Systems.


Hilscher Driver Guide - ClearSCADA Configuration for Hilscher Devices on PROFIBUS-FMS Systems (Introduction to the Hilscher Driver)

ClearSCADA Configuration for Hilscher Devices on PROFIBUS-FMS Systems

In order for ClearSCADA to communicate with Hilscher devices on a PROFIBUS-FMS system, you need to configure:

  1. A Hilscher Board for each I/O board through which you want to scan an FMS device (see Configuring a Hilscher Board).
  2. A Hilscher Profibus FMS Scanner for each type of data that you want to scan at a different location or different scan rate on an FMS device (see Configuring a Hilscher Scanner).
  3. A Hilscher Profibus Point for each measuring instrument or control device that you want ClearSCADA to monitor or control on an FMS device.

Choose from:

  • Hilscher Profibus FMS Analog Point (for analog input or output data)
  • Hilscher Profibus FMS Digital Point (for digital input or output data).

For more information, see Points Used on Hilscher Scanners.


Hilscher Driver Guide - ClearSCADA Configuration for Hilscher Devices on DeviceNet or PROFIBUS-DP Systems (Introduction to the Hilscher Driver)

ClearSCADA Configuration for Hilscher Devices on DeviceNet or PROFIBUS-DP Systems

In order for ClearSCADA to communicate with Hilscher devices on a DeviceNet or PROFIBUS-DP system, you need to configure:

  1. A Hilscher Board for each card that you want to scan on a Hilscher device (see Configuring a Hilscher Board).
  2. A Hilscher IO Image Scanner for each type of data that you want to scan at a different location or different scan rate on a Hilscher device (see Configuring a Hilscher Scanner).
  3. A Hilscher IO Image Point for each measuring instrument or control device that you want ClearSCADA to monitor or control on a Hilscher device.

Choose from:

  • Hilscher IO Image Analog Point (for analog input or output data)
  • Hilscher IO Image Digital Point (for digital input or output data).

For more information, see Points Used on Hilscher Scanners.


Hilscher Driver Guide - Configuring a Hilscher Board

Configuring a Hilscher Board

On a DeviceNet or PROFIBUS-DP system, you need to configure a Hilscher Board in the ClearSCADA database for each physical Hilscher board that you want ClearSCADA to scan on your system.

On a PROFIBUS-FMS system, you need to configure a Hilscher Board in the ClearSCADA database for each I/O board through which ClearSCADA is to scan FMS devices.

In either case, specify the properties for a board using the Hilscher Board Form.

The Form has several tabs.

Use the Board tab to Configure the Basic Board Properties.

For fields on the other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers. (These tabs have no driver-specific configuration settings.)


Hilscher Driver Guide - Configure the Basic Board Properties (Configuring a Hilscher Board)

Configure the Basic Board Properties

Use the fields on the Board tab to specify the basic communication properties of a board. Many of the fields on this tab are common to boards and channels on many simple drivers—for more information, see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers. Fields that are specific to the Hilscher driver are explained below.

  • Board Number—Use to specify the index of the Hilscher board in the ClearSCADA server.

Enter the required number, in the range 0 to 3.


Hilscher Driver Guide - Configuring a Hilscher Scanner

Configuring a Hilscher Scanner

A Hilscher Scanner is logical functionality that runs within ClearSCADA and scans for data on a Hilscher device.

The Hilscher driver provides several types of Hilscher scanner—you create and configure the type of scanner that is appropriate to the type of fieldbus used on your system. Choose from:

  • Hilscher IO Image Scanner—Use to scan Hilscher cards on systems that use DeviceNet or PROFIBUS-DP fieldbuses. For more information, see Configure the Properties of an IO Image Scanner.
  • Hilscher Profibus FMS Scanner—Use to scan FMS devices on systems that use PROFIBUS-FMS fieldbuses. For more information, see Configure the Properties of a Profibus FMS Scanner.

The Form for each type of Scanner has several tabs. For information on the fields on the Scanner tab, see the appropriate reference above.

There are no driver-specific properties on any of the other tabs—for information on these tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Hilscher Driver Guide - Configure the Basic Scanner Properties (Configuring a Hilscher Scanner)

Configure the Basic Scanner Properties

Use the fields on the Scanner tab of the appropriate Hilscher Scanner Form to define the general and Hilscher-specific properties for a Scanner. Many of the fields on this tab are common to scanners on many simple drivers—for information, see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers.

Fields that are common to Scanner on the Hilscher driver are described below. For fields that are not shown here, see the appropriate scanner-specific section within this guide.

  • Board—Use to specify the Hilscher Board to which this Scanner is attached. Use the browse button to display a Reference browse window and select the required Board from the window.
  • Big Endian—Use to define which byte is the most significant in multi-byte data.

Select the check box if the lowest (first) address of a multi-byte value has the most significant address (‘big-endian’).

Example:

A Scanner is configured to use big-endian addressing.

An analog point on the Scanner is configured to read from address 3. The analog point’s data is 2 bytes long.

The point’s value is read as:
Address | Binary | Hexadecimal
3 | 00100000 | 0x20
4 | 00000000 | 0x00

This gives a raw point value of 8192
(00100000 00000000 (binary), or 0x2000 (hex)).

Clear the check box if the highest (last) address holds the most significant byte (‘little-endian’).

Example:

A Scanner is configured to use little-endian addressing.

An analog point on the Scanner is configured to read from address 3. The analog point’s data is 2 bytes long.

The point’s value is read as:
Address | Binary | Hexadecimal
3 | 00100000 | 0x20
4 | 00000000 | 0x00

This gives a raw point value of 32
(00000000 00100000 (binary), or 0x0020 (hex)).


Hilscher Driver Guide - Configure the Properties of an IO Image Scanner (Configuring a Hilscher Scanner)

Configure the Properties of an IO Image Scanner

You use a Hilscher IO Image Scanner to scan a Hilscher card on a system that uses DeviceNet or PROFIBUS-DP fieldbuses.

The fields on the Scanner tab of the Hilscher IO Image Scanner Form are common to scanners on the Hilscher driver—for information, see Configure the Basic Scanner Properties.

If the Scanner is to scan a PROFIBUS-DP card that is set to ‘Bus synchronous and host controlled’, you need to set an appropriate Scan Rate. This is because such a card needs to be scanned frequently—if it is scanned less frequently than every 100ms, the devices on the bus may report a Bus Error whenever the bus appears to be inactive. By setting the scanner to scan the card more frequently than every 100ms, the bus stays active. (A card that is set as ‘Bus synchronous and host controlled’ only scans a bus when its host requests data from that card. In this case, the host is ClearSCADA).


Hilscher Driver Guide - Configure the Properties of a Profibus FMS Scanner (Configuring a Hilscher Scanner)

Configure the Properties of a Profibus FMS Scanner

You use a Hilscher Profibus FMS Scanner to scan an FMS device on a system that uses PROFIBUS-FMS fieldbuses.

In addition to the fields at the top of the Scanner tab that allow you to Configure the Basic Scanner Properties, the Scanner tab on the Hilscher Profibus FMS Scanner Form has these fields:

  • Communications Reference—Use to specify the communications reference of the FMS device.
  • Object Index—Use to specify the index of the FMS object that the scanner is to scan.
  • Default—Select this check box if the scanner is to use the default object type information from the FMS device, in order to correctly scan the object.

Clear the check box to specify the object type information in ClearSCADA. Use the Object Data Type, Data Start, and Data Length fields (see below) to specify the type and amount of data that the scanner is to scan.

  • Object Data Type—Use this combo box to specify the type of data that is being scanned. Choose from:
  • Data Start—Use to specify the starting index array of the data that is to be scanned.
  • Data Length—Use to specify the number of elements that are to be scanned. The Data Length has to be large enough to allow the scanner to scan all of the required ‘point’ data.


Hilscher Driver Guide - Points Used on Hilscher Scanners

Points Used on Hilscher Scanners

Hilscher Scanners can support Analog points and Digital points.

You configure the Hilscher points on your system by using the appropriate Hilscher Point Form (for instance, if your system uses PROFIBUS-FMS and you want to scan analog-type data, you would create and configure a Hilscher Profibus FMS Analog Point). For more information on which type of point you need to create and configure, see Configuring ClearSCADA to Communicate with Hilscher Devices.

Each Point Form has several tabs. For information on configuring properties on the Hilscher tab on each Form, see Configuring Analog Points, or see Configuring Digital Points, as appropriate.

For information on configuring properties on the <Point Type> tab, see the appropriate reference below:

  • Analog Point—see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.
  • Digital Point—see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on the other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

For general information on creating a point and displaying a Point Form, see Create and Configure a Point in the ClearSCADA Guide to Core Point Configuration.


Hilscher Driver Guide - Configuring Analog Points

Configuring Analog Points

The Hilscher driver supports Analog Input and Analog Output points.

Configure the properties for each analog point using the appropriate Point Form. Choose from:

  • Hilscher IO Image Analog Point—Represents analog data on Hilscher devices that are on a DeviceNet or PROFIBUS-DP network.
  • Hilscher Profibus FMS Analog Point—Represents analog data on Hilscher devices that are on a PROFIBUS-FMS network.

This section covers configuration of properties on the Hilscher tab of each Form. Use the Hilscher tab to:

  • Configure the General Point Properties
  • Configure Point Scaling
  • Define Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration).

For information on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

If the point is an output point, you also need to enable and configure the properties on the Control tab—for information, see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


Hilscher Driver Guide - Configure the General Point Properties (Configuring Analog Points)

Configure the General Point Properties

Use the fields at the top of the Hilscher tab to configure the general point properties. Some of these fields are common to points on many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to points on the Hilscher driver are explained below.

  • Scanner—Use to specify the Scanner that scans the point’s data. Select the browse button to display a Reference browse window. For a Hilscher IO Image Analog point, select the appropriate Hilscher IO Image Scanner; for a Hilscher Profibus FMS Analog point, select the appropriate Hilscher Profibus FMS Scanner.
  • Address—Use to specify the address of the point on the Hilscher card. This is the address of the point within the Hilscher card’s memory.

With a Hilscher IO Image Scanner, ClearSCADA scans the whole card, and extracts the data from the relevant address(es) on that card.

With a Hilscher Profibus FMS Scanner, ClearSCADA scans a specified number of elements within a data array on a device (see Configure the Properties of a Profibus FMS Scanner). The point Address is an offset from the Scanner’s Data Start index. The Address and Data Size combination that you specify on the Point Form needs to be within the range that the Scanner is configured to scan.

  • Data Size—Use the combo box to specify the size of the raw value, in bytes. Choose 1, 2 or 4 bytes, as appropriate.

Example:

On a particular ClearSCADA system, a Hilscher Profibus FMS Scanner is given this configuration:

Object Data Type:INT16 (16-bit integer)
Data Start:3
Data Length:;12 (bytes)

So the Scanner scans elements 3 to 14 on the FMS device (that is associated with the Scanner).

An Analog Point that uses the above Scanner is given this configuration:

Address::4
Data Size:2

To obtain the value of this point, ClearSCADA extracts the data for elements 6 and 7 from the scanned FMS device.


Hilscher Driver Guide - Configure Point Scaling (Configuring Analog Points)

Configure Point Scaling

Use the fields within the Scaling section of the Hilscher tab to specify the range of raw input signal values for an analog point, or the scaling factor for a calculated analog value.

The Hilscher driver uses these values in calculations to convert raw input signal values into engineering values.

  • Enabled—Select this check box if the input value at the Hilscher device needs to be scaled for use by ClearSCADA, and vice versa for output values. Use the Raw Full Scale and Raw Zero Scale fields to define the scaling that is required. As the point source can be a floating-point number, the range of the scaling supports the full possible range of a double-precision floating-point number (+/- 1.7976931348623147e+308).

Clear the Enabled check box if scaling is not required for the point.

  • Raw Full scale—Applies when Scaling is enabled. Enter the highest acceptable raw data value for the point.
  • Raw Zero Scale—Applies when Scaling is enabled. Enter the lowest acceptable raw data value for the point.


Hilscher Driver Guide - Configuring Digital Points

Configuring Digital Points

The Hilscher driver supports 1-, 2-, and 3-bit Digital Input and Digital Output points.

Configure the properties for each digital point using the appropriate Point Form. Choose from:

  • Hilscher IO Image Digital Point—Represents digital data on Hilscher devices that are on a DeviceNet or PROFIBUS-DP network.
  • Hilscher Profibus FMS Digital Point—Represents digital data on Hilscher devices that are on a PROFIBUS-FMS network.

This section covers configuration of properties on the Hilscher tab of each Form. Use the Hilscher tab to Configure the Hilscher Point Properties.

For information on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

If the point is an output point, you also need to enable and configure the properties on the Control tab—for information, see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


Hilscher Driver Guide - Configure the Hilscher Point Properties (Configuring Digital Points)

Configure the Hilscher Point Properties

Use the fields at the top of the Hilscher tab to configure the general point properties. Some of these fields are common to points on many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to points on the Hilscher driver are explained below.

  • Scanner—Use to specify the Scanner that scans the point’s data. Select the browse button to display a Reference browse window. For a Hilscher IO Image Digital point, select the appropriate Hilscher IO Image Scanner; for a Hilscher Profibus FMS Digital point, select the appropriate Hilscher Profibus FMS Scanner.
  • Address—Use to specify the address of the point on the Hilscher card. For multi-byte points, this is the lowest (starting) byte. This is the address of the point within the Hilscher card’s memory.

With a Hilscher IO Image Scanner, ClearSCADA scans the whole card, and extracts the data from the relevant address(es) on that card.

With a Hilscher Profibus FMS Scanner, ClearSCADA scans a specified number of elements within a data array on a device (see Configure the Properties of a Profibus FMS Scanner). The point Address is an offset from the Scanner’s Data Start index.

  • Offset—Use to specify the starting bit of the data within the specified byte. Enter the required offset, in the range 0 to 7.

An example at the end of this section shows how the Address and Offset are used by ClearSCADA (see below).

  • Persistence—Specify the time that the Hilscher driver waits before it reports a change of state. Enter the time in seconds. This allows the driver to ignore fleeting changes in point state.

Example:

On a particular ClearSCADA system, a Hilscher Profibus FMS Scanner is given this configuration:

Object Data Type:BOOL (Boolean data)
Data Start:3
Data Length:;12

Thus, the Scanner scans elements 3 to 14 on the FMS device with which the Scanner is associated.

A Digital Point that uses the above Scanner is given this configuration:

Number of Bits:2
Address::4
Offset:3 (indicating that the starting bit is the third bit in the above Address)

To obtain the value of this point from the above scanned range, ClearSCADA extracts the data from the 3rd bit within element 6 through to the 3rd bit in element 7.


Hilscher Driver Guide - Hilscher Specific Status Display Attributes

Hilscher Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for a Hilscher IO Image Analog Point provides information about the present state of the individual point.

Many of the attributes on Hilscher Status displays are common to many drivers, however, the information displayed by the Source attribute differs, depending on the driver and the type of item to which the attribute refers.

This section describes the Source attribute information that is displayed for items on the Hilscher driver (see Hilscher Source Attribute).

NOTE: The Status attributes Primary Assign, Primary Eavesdrop Tx Assign, Secondary Assign, and Secondary Eavesdrop Tx Assign are not used by the Hilscher driver and can be ignored.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Items on Many Drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Hilscher Driver Guide - Hilscher Source Attribute (Hilscher Specific Status Display Attributes)

Hilscher Source Attribute

Associated with: Hilscher Boards, Hilscher Scanners, and Hilscher Points

The Source attribute indicates the location at which an item resides.

The attribute is common to many Status displays, but the information shown varies, depending on the driver and the type of item. For items on the Hilscher driver, this information is displayed:
Hilscher Item | Source Attribute
Board | Format | Board <Number>
 | Example: | Board 2 (For a Hilscher card with a board number of 2.)
IO Image Scanner | Format | Board <Number>
 | Example: | Board 2 (For a Hilscher IO Image Scanner that is configured to scan Board number 2.)
IO Image Analog Point | Format | Board <Number>:<Point Type>.<Address>.<Data Size>
 | Example: | Board 2:AG IN.4.2 (For a Hilscher IO Image Analog point on Board number 2. The point starts at byte address 4 and is 2 bytes long. AG IN indicates that the point is an input point (an output point is indicated by AG OUT).)
IO Image Digital Point | Format | Board <Number>:<Point Type>.<Address>.<Offset>
 | Example: | Board 2:DG3 IN.5.4 (For a Hilscher 3-bit IO Image Digital point on Board number 2. The point starts at byte address 5, bit offset 4. DGn IN indicates that the point is an input point (an output point is indicated by DGn OUT, where n is the number of bits).)
Profibus FMS Scanner | Format | Board <Number>: <Communications Reference>, Object <Object Index>
 | Example: | Board 3: 15, Object 100 (For a Hilscher Profibus FMS Scanner that is configured to scan Board number 3. The FMS device has a comms reference of 15 and the object being scanned has an Object Index of 100.)
Profibus FMS Analog Point | Format | Board <Number>: <Communications Reference>, Object <Object Index>: <Point Type>.<Address>.<Data Size>
 | Example: | Board 3: 15, Object 100: AG OUT.8.4 (For a Hilscher Profibus FMS Analog point on Board 3. The point starts at byte address 8 and is 4 bytes long. AG OUT indicates that the point is an output point (an input point is indicated by AG IN). Scanner details as per the above example.)
Profibus FMS Digital Point | Format | Board <Number>: <Communications Reference>, Object <Object Index>: <Point Type>.<Address>.<Offset>
 | Example: | Board 3: 15, Object 100: DG1 OUT.12.7 (For a Hilscher 1-bit Profibus FMS Digital point on Board number 3. The point starts at byte address 12, bit offset 7. DGn OUT indicates that the point is an output point (an input point is indicated by DGn IN, where n is the number of bits).)


Mitsubishi Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Mitsubishi Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Mitsubishi Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Mitsubishi Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Mitsubishi Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Mitsubishi Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s Mitsubishi driver. The Mitsubishi driver enables ClearSCADA to communicate with slave devices and PLCs using the Mitsubishi MELSEC A protocol.

For more details on the information included in this guide, see Introduction to the Mitsubishi Driver.

NOTE: For information on how to configure ClearSCADA to act as a Mitsubishi MELSEC A PLC and report any data changes back to its Master, see the ClearSCADA Guide to the Mitsubishi Slave Driver.


Mitsubishi Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring Mitsubishi items and features in the ClearSCADA database.

The guide also contains information of use to maintenance engineers.


Mitsubishi Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Mitsubishi Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


Mitsubishi Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Mitsubishi Driver Guide - Introduction to the Mitsubishi Driver

Introduction to the Mitsubishi Driver

The Mitsubishi Driver provides extra functionality to allow a ClearSCADA system to be populated with data from, and control points on, Mitsubishi Slaves or Mitsubishi PLCs. The driver allows ClearSCADA to communicate with:

  • Mitsubishi Slaves
  • The MELSEC A range of MitsubishiTM PLCs
    (using Transmission Control Protocol Format 1)
  • Third-party PLCs that communicate using the Mitsubishi MELSEC A protocol.

The ClearSCADA Mitsubishi documentation explains how to configure Mitsubishi-specific features and items within the ClearSCADA database (see Configuring Mitsubishi Devices in ClearSCADA and see Mitsubishi Data Address Ranges).

It also explains the driver-specific status attributes. These attributes may be useful to system administrators and engineers when investigating unexpected system behavior (relating to the driver) (see Mitsubishi Specific Status Display Attributes).

NOTE: There are no driver-specific pick actions for items on the Mitsubishi driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

ClearSCADA communicates with Mitsubishi PLCs using Transmission Control Protocol Format 1 (see The Transmission Control Protocol Supported by ClearSCADA).

For PLC information not covered by this guide, see the Mitsubishi documentation supplied with Mitsubishi PLCs.

For information on configuring ClearSCADA so that it can communicate as a Mitsubishi Slave, see the ClearSCADA Guide to the Mitsubishi Slave Driver.


Mitsubishi Driver Guide - The Transmission Control Protocol Supported by ClearSCADA (Introduction to the Mitsubishi Driver)

The Transmission Control Protocol Supported by ClearSCADA

Each MELSEC A PLC can use one of four Transmission Control Protocol formats to communicate with its Mitsubishi Master, via RS-232.

ClearSCADA communicates with MELSEC A PLCs using Transmission Control Protocol Format 1.

For ClearSCADA to communicate with MELSEC A PLCs, set the Mode Setting switch on each PLC to indicate Protocol 1 (typically switch setting 1).

For more information, see the Mitsubishi documentation supplied with MELSEC A PLCs.


Mitsubishi Driver Guide - Mitsubishi Data Address Ranges (Introduction to the Mitsubishi Driver)

Mitsubishi Data Address Ranges

Mitsubishi MELSEC A PLCs store device (point) data in areas of memory known as Device memory, Buffer memory, and Register memory. You use the Device field on the Mitsubishi Scanner Form to define the area of memory that a particular scanner is to scan. You then use further fields on the Mitsubishi Scanner Form to define the particular address range that is to be scanned within that area of memory, and fields on the Mitsubishi Point Forms to define the particular address(es) that are associated with each point.

Mitsubishi MELSEC A PLCs allocate device (point) data in Words or Bits, depending on the area of memory in which it the data is located in the PLC. You need to be aware of which unit (Word or Bit) is associated with each area of memory, in order to configure the location of the point data correctly within the ClearSCADA database. (Be aware that ClearSCADA retrieves a minimum of one Word of data, regardless of the PLC memory area in which the source data is located.)

The table below lists the areas of memory in each type of PLC. It also indicates whether the data in each area is allocated in Bits or Words, and the ranges that are associated with each area of memory.
Memory Allocation in Mitsubishi MELSEC A PLCs
Device | ACPU Range | AnACPU Range | Addressing Convention | Unit
Link Relay B | B0000 to B03FF | B000000 to B000FFF | Hexadecimal | Bit
Counter (Present Value) C | CN000 to CN255 | CN00000 to CN01023 | Decimal | Word
Data Register D | D0000 to D1023 | D000000 to D006143 | Decimal | Word
Special Register D | D9000 to D9255 | D009000 to D009255 | Decimal | Word
Annunciator F | F0000 to F0255 | F000000 to F002047 | Decimal | Bit
Latch Relay L | L0000 to L2047 | L000000 to L008191 | Decimal | Bit
Internal Relay M | M0000 to M2047 | M000000 to M008191 | Decimal | Bit
Special Relay M | M9000 to M9255 | M009000 to M009255 | Decimal | Bit
File Register R | R0000 to R8191 | R000000 to R008191 | Decimal | Word
Step Relay S | S0000 to S2047 | S000000 to S008191 | Decimal | Bit
Timer (Present Value) T | TN000 to TN255 | TN00000 to TN02047 | Decimal | Word
Link Register W | W0000 to W03FF | W000000 to W000FFF | Hexadecimal | Word
Input X | X0000 to X07FF | X000000 to X0007FF | Hexadecimal | Bit
Output Y | Y0000 to Y07FF | Y000000 to Y0007FF | Hexadecimal | Bit

In addition to the above, ClearSCADA can also read and write to the Buffer memory in a MELSEC A PLC. For details of the address allocations for Buffer memory, see the Mitsubishi documentation supplied with the MELSEC A PLCs.

For examples showing how to specify and display PLC memory address ranges within ClearSCADA, see Configuration Examples.

Further Information

Configuring a Mitsubishi Scanner

Configuring Analog Points

Configuring Digital Points.


Mitsubishi Driver Guide - Configuring Mitsubishi Devices in ClearSCADA (Introduction to the Mitsubishi Driver)

Configuring Mitsubishi Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, control devices, and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the Mitsubishi devices on your system.

You can only configure database items to represent any Mitsubishi devices if the Mitsubishi Driver is installed and running on the ClearSCADA servers on your system.

When you configure Mitsubishi items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant Mitsubishi devices on your system. Some settings are either fixed (incorporated into the design of the Mitsubishi Slave or PLC), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the Mitsubishi devices on your system before you can configure the Mitsubishi database items successfully.

For instance, you need to know the type(s) of MELSEC A PLC that the Mitsubishi driver is to scan. You also need to know the area(s) of memory in which data is located in those PLCs (see Mitsubishi Data Address Ranges).

You also need to be aware of which optional features are required for each Mitsubishi item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with Mitsubishi database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each Mitsubishi device, you need to configure:

  1. Mitsubishi Channel(s) to represent the communication connections between each Mitsubishi Slave or PLC and the ClearSCADA server (see Configuring a Mitsubishi Channel).

You need to configure a separate Mitsubishi channel for each separate communications channel that is available to the Mitsubishi driver on your system.

  2. At least one Mitsubishi Scanner for each Mitsubishi Slave or Mitsubishi PLC that the driver is to scan (see Configuring a Mitsubishi Scanner).

Configure a scanner for each memory address range that you want to scan on a Slave or PLC, or each group of points that you want to scan at a different frequency or time offset.

  3. A Mitsubishi Point for each separate item of data that is to be read from or written to in a block of memory (see Points Used on Mitsubishi Scanners).

(Mitsubishi PLCs use areas of memory known as Device memory, Buffer memory, and Register memory to store data (see Mitsubishi Data Address Ranges). Settings used by the Mitsubishi driver determine the location of the data within those areas of memory.)

You can associate multiple points with each Mitsubishi Scanner.

To minimize the time that it takes to configure the required Mitsubishi items, you may want to configure them in the order listed above, as Scanner configuration requires you to specify a channel, and Point configuration requires that you specify a scanner, etc.


Mitsubishi Driver Guide - Configuring a Mitsubishi Channel

Configuring a Mitsubishi Channel

A Mitsubishi Channel provides ClearSCADA with additional connection information so that the server can communicate successfully with Mitsubishi PLCs and Mitsubishi Slaves.

Specify the properties for a channel using the fields on the Mitsubishi Channel Form.

The Form has several tabs (see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers).

Use the Channel tab to Configure the Basic Channel Properties.

Mitsubishi Channels use RS-232/RS-485 serial communications. Use the fields on the Connection tab of the Form to specify the required properties for a channel’s serial connection (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

For fields on the other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Mitsubishi Driver Guide - Configure the Basic Channel Properties (Configuring a Mitsubishi Channel)

Configure the Basic Channel Properties

Use the fields on the Channel tab to specify the basic communication properties of a channel. Some of the fields on this tab are common to channels on many simple drivers—for more information, see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers. Fields that are specific to the Mitsubishi driver are explained below.

  • Node ID—Use to specify the Mitsubishi node ID of this master.


Mitsubishi Driver Guide - Configuring a Mitsubishi Scanner

Configuring a Mitsubishi Scanner

A Mitsubishi Scanner is logical functionality that runs within ClearSCADA and scans for data on a Mitsubishi PLC or a Mitsubishi Slave.

Configure the Scanner properties using the fields on the Mitsubishi Scanner Form.

The Form has several tabs (see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers).

This section covers fields on the Scanner tab that are specific to the Mitsubishi driver (see Configure the Scanner Properties). For fields on the other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Mitsubishi Driver Guide - Configure the Scanner Properties (Configuring a Mitsubishi Scanner)

Configure the Scanner Properties

Use the fields on the Scanner tab of the Mitsubishi Scanner Form to define the general and Mitsubishi-specific properties for a scanner. Many of the fields on this tab are common to many scanners (see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the Mitsubishi driver are described below.

  • Channel—Use to specify the channel through which the scanner transmits data. Use the browse button to display a Reference Browse window. From the window, select the channel that the scanner uses to communicate with a Mitsubishi PLC or Mitsubishi Slave.
  • PLC Type—Use this combo box to specify the type of PLC that the Mitsubishi scanner is to scan.

The mode of addressing varies with the type of Mitsubishi Slave or PLC (see Mitsubishi Data Address Ranges).

  • Node ID—Use to specify the ID of the scanned slave’s Mitsubishi node.
  • Device—Use to specify the type of data that is to be scanned. The option that you specify determines the area of memory that the scanner scans on the Mitsubishi Slave or PLC.
  • Data Address—Use to specify the address from which the scanner is to start scanning data, within the address range that is allocated to the specified Device.

For Word Devices, specify the offset into the device, in multiples of 16-bit Words.

For Bit Devices, specify the offset into the device, in Bits.

For information on Device address ranges and the unit that each Device supports, see Mitsubishi Data Address Ranges.

  • Data Length—Use to specify the number of addresses that are to be scanned in the PLC. The addresses are scanned as a block, starting at the Data Address specified above. You need to set the Data Length so that it encompasses each of the point locations that you want to scan using this scanner. (You specify the individual point locations within this range, using the Word Offset and Bit Offset fields on the individual Point Forms.)

Example:

A scanner has this configuration:

PLC Type: ACPU
Device: Input X
Data Address: 64
Data Length: 2

This results in the scanner scanning 32 points from Input X device address X00040 to Input X device address X0005F.

For further examples showing how you might configure the Device, Data Address, and Data Length properties, see Configuration Examples.


Mitsubishi Driver Guide - Points Used on Mitsubishi Scanners

Points Used on Mitsubishi Scanners

Mitsubishi Scanners can support analog points and digital points.

You configure the Mitsubishi points on your system by using the appropriate Mitsubishi Point Form. The Forms have several tabs (see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers).

For information on configuring properties on the Mitsubishi tab, see Configuring Analog Points, or see Configuring Digital Points, as appropriate.

For information on configuring properties on the <Point Type> tab, see the appropriate reference below:

  • Analog Point—see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.
  • Digital Point—see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on the other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

For general information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.


Mitsubishi Driver Guide - Configuring Analog Points

Configuring Analog Points

The Mitsubishi driver supports Analog Input and Analog Output points.

Configure the properties for each analog point using the fields on the Mitsubishi Analog Point Form.

This section covers configuration of Mitsubishi-specific properties on the Mitsubishi tab of the Form.

Use the Mitsubishi tab to:

  • Configure the Mitsubishi Point Properties
  • Configure Scaling Properties (see Scale Analog Values for use in ClearSCADA in the ClearSCADA Guide to Simple Drivers)
  • Configure Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration).

For information on the fields on the Analog tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


Mitsubishi Driver Guide - Configure the Mitsubishi Point Properties (Configuring Analog Points)

Configure the Mitsubishi Point Properties

Use the fields at the top of the Mitsubishi tab to configure the Mitsubishi-specific point properties. Some of these properties are common to points on many simple drivers—for information, see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers. Properties that are specific to analog points on the Mitsubishi driver are explained below.

  • Word Offset—Use to specify the location of the point data, within the Device address range configured for the scanner. This is the offset into the device, in multiples of 16-bit Words. Specify the value as an offset from the Data Address that is defined on the Scanner Form (see Configure the Scanner Properties). The lowest acceptable offset is zero.

Example:

The Data Address for a Scanner is configured as 10.
The data for an analog point that is attached to the scanner starts at address 12 and so the analog’s Word Offset is configured as 2.

For a further example showing how you might configure a Word Offset in conjunction with other properties, see Scan a Link Register.

  • Data Type—Specify how analog data is represented in the Slave. Choose from:
  • UINT—Unsigned 16-bit data.
  • DINT—Signed 32-bit data.
  • UDINT—Unsigned 32-bit data.
  • REAL—IEEE 32-bit single-precision floating point value.
  • INT—Signed 16-bit data.
  • DOUBLE—IEEE 64-bit double-precision floating point value.

When defining the Data Type, check that the Word Offset you have specified is appropriate (the Word you have specified indicates the first Word (or Bit) of a multi-Word point).

For an example showing how you might configure the Data Type in conjunction with other configuration properties, see Scan a Link Register.

NOTE: If the Word Offset and Data Type are inappropriate, a diagnostic message is generated.

  • Swap Registers—Applies to DINT, UDINT, REAL, and DOUBLE Data Types. As this data comprises two or four 16-bit Words, you can use this check box to specify the order in which the Words of data are presented in ClearSCADA, and hence the value that they represent.

Clear the Swap Registers check box if the data in the Words is not to be swapped for use within ClearSCADA. For multi-Word data, the highest numbered address contains the most significant Word.

Select the Swap Registers check box if the Word values are to be swapped for use within ClearSCADA. For multi-Word data, the lowest numbered address contains the most significant Word.

Example 1:

An analog value has a DINT data type, and is located at addresses 16 to 17 within a block of scanned data in a PLC. The Words are not swapped.

The present value of the analog is:

Word 16 = 1
Word 17 = 0

As the Words are not swapped, this results in the analog point being given a value of 1 within ClearSCADA.

If the configuration was such that the Words were swapped, this would result in the analog point being given a value of 65536 within ClearSCADA.

Example 2:

A DOUBLE (64-bit double precision floating point) obtains its data from the Mitsubishi Link Registers W030A to W030D.

The registers are not swapped, therefore register W030D contains the most significant Word.

(If the registers were swapped, register W030A would contain the most significant Word, and register W030D the least significant.)


Mitsubishi Driver Guide - Configuring Digital Points

Configuring Digital Points

The Mitsubishi driver supports multi-bit Digital Input and Digital Output points.

Configure the properties for each digital point using the fields on the Mitsubishi Digital Point Form.

This section covers configuration of properties on the Mitsubishi tab of the Form. Use the Mitsubishi tab to Configure the Mitsubishi Point Properties.

For information on the fields on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


Mitsubishi Driver Guide - Configure the Mitsubishi Point Properties (Configuring Digital Points)

Configure the Mitsubishi Point Properties

Use the fields on the Mitsubishi tab to configure the Mitsubishi-specific properties for a digital point. Many of the fields on the tab are common to points on many simple drivers—for information, see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers.

  • Word Offset—Use to specify the location of the point data, within the Device address range configured for the scanner. This is the offset into the device, in multiples of 16-bit Words. Specify the value as an offset from the Data Address that is defined on the Scanner Form (see Configure the Scanner Properties). The lowest acceptable offset is zero.

Example:

The Data Address for a Scanner is configured as 8.
The data for a digital point that is attached to the scanner starts at address 14 and so the digital’s Word Offset is configured as 6.
(The Bit Offset field (see below) is used to specify the starting bit within the Word.)

For a further example showing how you might configure a Word Offset in conjunction with other configuration properties, see Scan an Internal Relay.

An ‘invalid configuration’ message is generated if the specified Word Offset results in the data location occurring outside of the address range (that is specified for the Scanner).

  • Bit Offset—Enter the lowest (starting) bit of the point. With a multi-bit point, the bits have to be consecutive within the file (for example, a 2-bit digital might use bits 5 and 6, where bit 5 would be the starting bit).

The range is 0 to 15.

For an example showing how you might configure a Bit Offset in conjunction with other configuration properties, see Scan an Internal Relay.

  • Persistence—Specify the time that the Mitsubishi driver waits before it reports a change of state. Enter the time in seconds. This allows the driver to ignore fleeting changes in point state.


Mitsubishi Driver Guide - Configuration Examples

Configuration Examples

This section includes examples of ClearSCADA configuration that might be used to allow the ClearSCADA Mitsubishi driver to transmit data to and from Mitsubishi MELSEC A PLCs.

The examples refer to specific address ranges within each PLC—for more information on the type of data and the corresponding address ranges within each type of PLC, see Mitsubishi Data Address Ranges.

The address range with which a channel, scanner or point is associated is displayed as part of the Source status attribute. The Source attribute is displayed on the associated List and Status display for each item (see Mitsubishi Specific Status Display Attributes).

Use the examples as an aid when configuring your ClearSCADA system. The examples in this section include:

  • Scan a Link Register
  • Scan an Internal Relay.


Mitsubishi Driver Guide - Scan a Link Register (Configuration Examples)

Scan a Link Register

This example demonstrates how ClearSCADA might be configured to scan Link Register data on a Mitsubishi MELSEC A PLC.

In the example, a Mitsubishi Scanner is used to scan the address range W0003 to W000A in Link Register W. The example demonstrates how an analog point might be used to represent data that resides at addresses W0004 and W0005 in that Link Register.

Example:

A scanner scans several Link Registers on a Mitsubishi PLC. Within ClearSCADA, the Scanner has this configuration (the PLC type is set to ACPU):

This configuration determines that the scanner scans the Link Register W device range W0003 to W000A within the PLC (Link Registers have hexadecimal notation in the PLC).

An analog point is to represent the data that is located at W0004 and W0005 within the above address range. Within ClearSCADA, the analog point has this configuration:

In order to read the value of this point, the scanner extracts all of the bits from Link Register addresses W0004 and W0005. (Each Link Register is one 16-bit Word and the analog point comprises two Words (as DINT data = 32-bits).)

Operators can confirm the address range that the scanner is scanning by looking at the Source attribute on, for example, a List:

They can also use the point’s Source attribute to confirm the type of data and address of the Link Register with which the individual analog point is associated:


Mitsubishi Driver Guide - Scan an Internal Relay (Configuration Examples)

Scan an Internal Relay

This example demonstrates how ClearSCADA might be configured to scan Internal Relay data on a Mitsubishi MELSEC A PLC.

In the example, a Mitsubishi Scanner is used to scan the address range M0010 to M0021 in Internal Relay M. The example demonstrates how a digital point might be used to represent 2 bits of data that reside at address M0014 in that Internal Relay.

Example:

A scanner scans several Internal Relays on a Mitsubishi PLC. Within ClearSCADA, the Scanner has this configuration (the PLC type is set to ACPU):

This configuration determines that the scanner scans the Internal Relay M Device range M0010 to M0021 within the PLC (Internal Relays have decimal notation in the PLC).

Within this address range, a 2-bit digital point is to represent the data that is located at address M0014, starting at the fourth bit within that Word, and continuing to the fifth bit. (Each Internal Relay comprises 16 bits of data.) Within ClearSCADA, the 2-bit digital point has this configuration:

In order to read the value of this point, the scanner extracts the data from bits 4 and 5 of Internal Relay M Device M0014.

Operators can confirm the address range that the scanner is scanning by looking at the Source attribute on, for example, a List (to display scanner details in List format from the Queries Bar, you filter the constraints on the Point Sources List):

They can also use the point’s Source attribute to confirm the type of data and address of the Link Register with which the individual digital point is associated:


Mitsubishi Driver Guide - Mitsubishi Specific Status Display Attributes

Mitsubishi Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each Mitsubishi Scanner provides information about the present state of the individual scanner.

Use this section if you need information on the status of any Mitsubishi database items on your system.

This section covers those attributes that are Mitsubishi-specific and includes:

  • Mitsubishi Channel Status Attributes
  • Mitsubishi Point Status Attributes
  • Mitsubishi Scanner Status Attributes
  • Alphabetical List of Mitsubishi Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Mitsubishi Driver Guide - Mitsubishi Channel Status Attributes (Mitsubishi Specific Status Display Attributes)

Mitsubishi Channel Status Attributes

This status attribute is specific to Mitsubishi channels:

  • Primary Assign.

NOTE: Three further status attributes—Primary Eavesdrop Tx Assign, Secondary Assign, and Secondary Eavesdrop Tx Assign—are not used by the Mitsubishi driver.


Mitsubishi Driver Guide - Mitsubishi Point Status Attributes (Mitsubishi Specific Status Display Attributes)

Mitsubishi Point Status Attributes

This status attribute is specific to Mitsubishi points:

  • Source.


Mitsubishi Driver Guide - Mitsubishi Scanner Status Attributes (Mitsubishi Specific Status Display Attributes)

Mitsubishi Scanner Status Attributes

These status attributes are specific to Mitsubishi scanners:

  • Source
  • Comms Statistics.


Mitsubishi Driver Guide - Alphabetical List of Mitsubishi Specific Status Display Attributes (Mitsubishi Specific Status Display Attributes)

Alphabetical List of Mitsubishi Specific Status Display Attributes

This section lists those status attributes that are specific to items on the Mitsubishi driver. The attributes are listed in alphabetical order and comprise:

  • Comms Statistics
  • Primary Assign
  • Source.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.


Mitsubishi Driver Guide - Comms Statistics (Mitsubishi Specific Status Display Attributes)

Comms Statistics

Associated with: Mitsubishi scanners

This status attribute shows the number of:

  • Good Reads—Successful read operations
  • Good Writes—Successful write operations
  • NACKS—Transmissions that were expected to, but did not receive, an acknowledgment
  • Timeouts—Requests that did not receive a response within the expected time and therefore timed out. (The actual Timeout period is specified on the Channel Form.)
  • Checksum Errors—Errors returned due to invalid data transmissions.
  • Unknown Errors—Any errors that cannot be categorized as Good Reads, Good Writes, NACKS, Timeouts, Checksum Errors, or Exceptions errors.
  • Exceptions—Errors returned in response to the receipt of unsupported function codes that have been detected on a scanner since that scanner was last restarted.

Example:

75 good reads, 50 good writes, 0 NACKs, 2 timeouts, 0 checksum errors, 0 unknown errors, 0 exceptions


Mitsubishi Driver Guide - Primary Assign (Mitsubishi Specific Status Display Attributes)

Primary Assign

Associated with: Mitsubishi channels

The Primary Assign attribute indicates whether the assignment of a Mitsubishi channel to its serial line has failed. The line is defined on the Connection tab of the Channel Form (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

Possible States: Displays one of the Standard Alarm States.


Mitsubishi Driver Guide - Source (Mitsubishi Specific Status Display Attributes)

Source

Associated with: Many Mitsubishi-specific items

The Source attribute is common to many Status Displays. The attribute indicates the location at which the item, for example the point, resides. The information shown varies, depending on the type of item.

For Mitsubishi Scanners, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>:PLC <Node ID (Slave)>,
Device <Device Type> - <start of scanned address range>-<end of scanned address range>

Example:

COM6:9600:8N1:PLC 77, Device Buffer - 00016-0001A
(For a Mitsubishi Scanner that is being used to scan a range of five Words in a Buffer device, from Data Address 22 (00016 in hexadecimal) to 26 (0001A in hexadecimal). The scanner uses a channel that has these settings: the channel communicates via port COM6, uses a 9600 baud rate, has 8 data bits, no parity (N) and 1 stop bit.)

For Mitsubishi Analog Points, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>:PLC <Node ID (Slave)>,
Device <Device Type> - AG <start of scanned address range>-<end of scanned address range> (<Data Type>)

Example:

COM6:9600:8N1:PLC 77, Device Buffer - AG 00018-00019 (DINT)
(For an analog point that represents signed 32-bit (DINT) data in a Buffer device. The data is located at Word Offset 2 and is associated with the Scanner that is shown in the example above. Thus, the analog data is at addresses 24 and 25 (as the location = scanner Data Address 22 + Word Offset 2 and the Data Type is DINT). The addresses 24 and 25 are shown in their hexadecimal format of 00018 and 00019. Channel communication details are as the scanner example, above.)

For Mitsubishi Digital Points, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>:PLC <Node ID (Slave)>,
Device <Device Type> - AG <start of scanned address range>-<end of scanned address range> (<Data Type>)

Example:

COM6:9600:8N1:PLC 77, Device Buffer - DG 00017 (bit offset 2, 2 bits)
(For a 2-bit digital point that represents data in a Buffer device. The data is located at Word Offset 1, Bit Offset 2 and is associated with the Scanner that is shown in the example above. Thus, the digital data is located in the third and fourth bits of address 23 (which is shown in its hexadecimal format of 00017). Channel communication details are as the scanner example, above.)

The Source attribute displays the type of Mitsubishi point using these abbreviations:
Abbreviation | Point Type
AG | Analog point
DG | Digital point

NOTE: Be aware that the device address in the Source attribute is displayed in decimal for some memory areas and in hexadecimal for others. This addressing convention follows the convention used for MELSEC A PLCs (see Mitsubishi Data Address Ranges).


Mitsubishi Slave Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Mitsubishi Slave Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Mitsubishi Slave Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Mitsubishi Slave Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Mitsubishi Slave Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Mitsubishi Slave Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s Mitsubishi Slave driver. The Mitsubishi Slave driver enables ClearSCADA to act as a Mitsubishi MELSEC A PLC and report any data changes back to another Master (using the Mitsubishi MELSEC A protocol).

For more details on the information included in this guide, see Introduction to the Mitsubishi Slave Driver.

NOTE: For information on how to configure ClearSCADA to communicate with slave devices and PLCs using the Mitsubishi MELSEC A protocol, see the ClearSCADA Guide to the Mitsubishi Driver.


Mitsubishi Slave Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring Mitsubishi Slave items and features in the ClearSCADA database.

The guide also contains information of use to maintenance engineers.


Mitsubishi Slave Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R1 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Mitsubishi Slave Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


Mitsubishi Slave Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Mitsubishi Slave Driver Guide - Introduction to the Mitsubishi Slave Driver

Introduction to the Mitsubishi Slave Driver

The Mitsubishi Slave Driver allows a ClearSCADA system to act as a MitsubishiTM MELSECTM A PLC and report any data changes back to its Master. The Slave transmits any changes to its database, or sets values or states in its database, upon request from its Master.

The Slave can obtain its data directly from plant, from calculated values, or from any item in the ClearSCADA database. Its Master can be another ClearSCADA server, or a third party server that is using the Mitsubishi MELSEC A protocol.

The Mitsubishi Slave Driver provides extra functionality within a ClearSCADA server for transmitting data or controlling points. A Mitsubishi Slave uses Value Maps for mapping point properties into memory, so that they can be accessed by the Mitsubishi MELSEC A protocol.

The Mitsubishi Slave documentation explains how to configure Mitsubishi Slave-specific features and items within the ClearSCADA database (see The Transmission Protocol Supported by ClearSCADA and see Configuring Mitsubishi Slave Devices in ClearSCADA).

It also explains driver-specific aspects that may be of interest to system administrators and engineers when investigating unexpected behavior (relating to the Mitsubishi Slave driver) (see Mitsubishi Slave-Specific Status Display Attributes).

NOTE: There are no driver-specific pick actions for items on the Mitsubishi Slave driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


Mitsubishi Slave Driver Guide - The Transmission Protocol Supported by ClearSCADA (Introduction to the Mitsubishi Slave Driver)

The Transmission Protocol Supported by ClearSCADA

Mitsubishi MELSEC A PLCs can use one of four Transmission Control Protocol formats to communicate with a Mitsubishi Master.

The Mitsubishi Slave driver allows ClearSCADA to communicate with its Master using Transmission Control Protocol Format 1.


Mitsubishi Slave Driver Guide - Configuring Mitsubishi Slave Devices in ClearSCADA (Introduction to the Mitsubishi Slave Driver)

Configuring Mitsubishi Slave Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the devices on your system. This section summarizes the database items that you need to configure to represent the Mitsubishi Slave devices on your system.

To function as a Mitsubishi Slave, the Mitsubishi Slave Driver has to be installed and running on the ClearSCADA servers on your system. The Mitsubishi Slave driver allows ClearSCADA to act as a MitsubishiTM MELSECTM A PLC, and use the Mitsubishi MELSEC A protocol to talk to a Mitsubishi Master (for example, another server).

When you configure Mitsubishi Slave items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant Mitsubishi Master on your system. Some settings are either fixed (incorporated into the design of the Mitsubishi Master), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the Mitsubishi Master on your system before you can configure the Mitsubishi Slave database items successfully.

For instance, you need to know the type(s) of Mitsubishi device (point) data that ClearSCADA is to report to the Mitsubishi Master, and how the communications to that Master are structured or grouped. You also need to be aware of The Transmission Protocol Supported by ClearSCADA.

You also need to be aware of which optional features are required for each Mitsubishi Slave item. These features include:

  • Alarm views
  • Alarm redirections
  • User methods.

You can also use core ClearSCADA features with Mitsubishi Slave database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each Mitsubishi Slave device, you need to configure:

  1. Mitsubishi Slave Channel(s) to represent the communication connection(s) between the Slave and its Master (see Configuring a Mitsubishi Slave Channel).
  2. Value Maps for mapping ‘point’ properties into memory so that they can be accessed by the Slave’s Master (see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).

A Mitsubishi Slave Source (see below) maps to BIT Value Maps for Bit Device data and to WORD Value Maps for Word Device data.

  3. A Mitsubishi Slave Source to specify which Value Map(s)—blocks of data—are to be scanned by a particular Master device (see Configuring a Mitsubishi Slave Source).

Configure a separate Source for each block of data that is to be scanned separately to other data by, for example, a different Master scanner.

To save time, we recommend that you configure Mitsubishi Slave items in the order listed above. This is because Source configuration requires you to specify a Channel and the Value Maps that hold the Source’s ‘point’ data.


Mitsubishi Slave Driver Guide - Configuring a Mitsubishi Slave Channel

Configuring a Mitsubishi Slave Channel

Mitsubishi Slave Channels are used to provide ClearSCADA with additional connection information, so that the ClearSCADA server can successfully communicate with its Master, using the Mitsubishi MELSEC A protocol.

Specify the features for each channel by using the fields on the Mitsubishi Slave Channel Form.

The Mitsubishi Slave Channel Form has several tabs.

Use the fields on the Channel tab to Configure the Basic Channel Properties.

Mitsubishi Slave Channels use RS-232/RS-485 serial communications. Use the fields on the Connection tab of the Form to specify the required properties for a Slave Channel’s serial connection (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

For information on the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Mitsubishi Slave Driver Guide - Basic Channel Properties (Configuring a Mitsubishi Slave Channel)

Basic Channel Properties

Use the fields on the Channel tab of the Mitsubishi Slave Channel Form to specify the basic communication properties of a channel. The fields on this tab are common to channels on many simple drivers—for information, see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers.


Mitsubishi Slave Driver Guide - Configuring a Mitsubishi Slave Source

Configuring a Mitsubishi Slave Source

The Mitsubishi Slave driver uses Source database items to represent groups of data. For example, a Source item can represent a block of registers that are scanned by a particular Master.

The configuration of each Source defines the location of the data that is:

  • Reported by the Slave to its Master
  • Updated by the Slave following a request from its Master.

You can configure one Source per Slave address (emulated PLC) per channel.

Before configuring a Mitsubishi Slave Source in ClearSCADA, you need to perform the necessary Preparation. When you have prepared your system appropriately, you can configure each Source by using the fields on the Mitsubishi Slave Source Form.

The Mitsubishi Slave Source Form has several tabs. This section explains the fields on the Source tab. Use the fields on the Source tab to:

  • Configure the Basic Source Properties
  • Map to Bit Device Data
  • Map to Word Device Data.

For information on the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Mitsubishi Slave Driver Guide - Preparation (Configuring a Mitsubishi Slave Source)

Preparation

Before you can successfully configure a Mitsubishi Slave Source, you will need to have configured:

  • The channel that is being used to transmit the Mitsubishi data (see Configuring a Mitsubishi Slave Channel)
  • The Value Maps that define where the data is located (see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).

A Mitsubishi Slave Source can map to:

  • BIT Value Maps (to represent the equivalent of MELSEC A PLC Bit Device data)
  • WORD Value Maps (to represent the equivalent of MELSEC A PLC Word Device data).


Mitsubishi Slave Driver Guide - Configure the Basic Source Properties (Configuring a Mitsubishi Slave Source)

Configure the Basic Source Properties

Use the fields at the top of the Source tab to define the basic Source properties:

  • In Service—Use to specify whether the Source is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Channel—Use to define the channel that is to transmit data changes from, and request local controls at, this Source.

Use the browse button to display a Reference Browse window. Select the required channel from the window.

  • Node ID—Use to specify the Mitsubishi node ID of this Slave. You can configure one Source per node ID per channel.
  • PLC Type—Use this combo box to specify the type of MELSEC A PLC that this Source is to emulate.

The mode of addressing varies with the type of PLC that is being emulated. Choose from:

  • ACPU—Supports five character addressing.
  • AnACPU—Supports seven character addressing.


Mitsubishi Slave Driver Guide - Map to Bit Device Data (Configuring a Mitsubishi Slave Source)

Map to Bit Device Data

You can only configure the Bit Device settings for the source if the BIT Value Maps that store the Slave’s data exist on your system.

If the required BIT Value Maps do not exist on your system, you will need to create them (see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).

When your system has the required BIT Value Maps, you can define the Bit Device settings. Use the fields in the Bit Device section of the Source tab to specify which BIT Value Maps store the Bit Device data for this Source.

Use the browse button next to each field to display a Reference browse window and select the required BIT Value Map from the window.

Leave the fields blank for any Map types that are not used by this Source.

Each field and associated Value Map represents a different type of data within a MELSEC A PLC. The entries within the Bit Device section of the tab emulate the areas of memory in a MELSEC PLC in which device (point) data is allocated on a per-Bit basis.

For an example of how you might use a BIT Value Map to represent MELSEC A PLC device data and how you might map that data to a Mitsubishi Slave Source, see Example Configuration.


Mitsubishi Slave Driver Guide - Map to Word Device Data (Configuring a Mitsubishi Slave Source)

Map to Word Device Data

You can only configure the Word Device settings for the source if the WORD Value Maps that store the Slave’s data exist on your system.

If the required WORD Value Maps do not exist on your system, you will need to create them (see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).

When your system has the required WORD Value Maps, you can define the Word Device settings. Use the fields in the Word Device section of the Source tab to specify which WORD Value Maps store the Word Device data for this Source.

Use the browse button adjacent to each field to display a Reference browse window and select the required WORD Value Map from the window.

Leave the fields blank for any Map types that are not used by this Source.

Each field and associated Value Map represents a different type of data within a MELSEC A PLC. The entries within the Word Device section of the tab emulate the areas of memory in a MELSEC PLC in which device (point) data is allocated on a per 16-Bit Word basis.

For an example of how you might use a WORD Value Map to represent MELSEC A PLC device data and how you might map that data to a Mitsubishi Slave Source, see Example Configuration.


Mitsubishi Slave Driver Guide - Example Configuration

Example Configuration

This example shows how ClearSCADA might be configured to act as a Mitsubishi MELSEC A PLC, in order to report its data to a Master, using the Mitsubishi MELSEC A protocol.

Example:

A ClearSCADA system is to emulate a MELSEC A AnACPU PLC. The ClearSCADA database is to be configured so that ClearSCADA can transmit data for the following devices to its Mitsubishi Master:

  • Inputs X000001 and X000003
  • Link Registers W00000B and W00000C.

Within ClearSCADA, a Mitsubishi Slave Channel is suitably configured to transmit data to the Mitsubishi Master.

A Mitsubishi Slave Source is configured to emulate an AnACPU PLC and to use the above channel. In this particular example, the Source is assigned the Mitsubishi Node ID of 6.

In a MELSEC A PLC, Input X data is allocated in Bits. Within ClearSCADA, a BIT Value Map is configured to emulate the Input X memory area. As ClearSCADA is to transmit data for Inputs X00001 and X00003, addresses 1 and 3 of the BIT Value Map are populated with the database items that represent those Inputs. (Address 1 of the BIT Value Map is the equivalent of Mitsubishi address 000001, and address 3 is the equivalent of Mitsubishi address 000003.)

The database items that will appear as MELSEC A PLC Inputs to the Mitsubishi Master, are attached to a BIT Value Map. They populate the BIT Value Map addresses that are the equivalent of MELSEC A PLC addresses 000001 and 000003.

For the BIT Value Map to represent Input X data, the Value Map (named ‘PLC 6 Inputs’) is specified as the Input X Map property on the Mitsubishi Slave Source Form.

This means that:

  • ClearSCADA transmits the BIT Value Map data as Input X data
  • The entries that populate the BIT Value Map emulate MELSEC A PLC addresses X00001 and X00003.

Link Register data is allocated in Words in a MELSEC A PLC.

In ClearSCADA, a WORD Value Map is configured to emulate the Link Register memory area. As ClearSCADA is to transmit data for Link Registers W00000B and W00000C, addresses 11 and 12 of the WORD Value Map are populated with the database items that represent those Link Registers. (11 is the decimal equivalent of Mitsubishi hexadecimal address 00000B, and 12 is the decimal equivalent of Mitsubishi hexadecimal address 00000C.)

The database items that will appear as MELSEC A PLC Link Registers to the Mitsubishi Master, are attached to a WORD Value Map. They populate the WORD Value Map addresses that are the decimal equivalent of MELSEC A PLC addresses 00000B and 00000C.

For the WORD Value Map to represent Link Register data, the Value Map (named ‘PLC 6 Link Registers’) is specified as the Link Register W Map property on the Mitsubishi Slave Source Form.

This means that:

  • ClearSCADA transmits the WORD Value Map data as Link Register W data
  • The entries that populate the WORD Value Map emulate MELSEC A PLC addresses W00000B and W00000C.

Further Information

Configuring a Mitsubishi Slave Channel.

Configuring a Mitsubishi Slave Source.

Configuring BIT Value Maps and WORD Value Maps: see Configuring Value Maps in the ClearSCADA Guide to Core Configuration.


Mitsubishi Slave Driver Guide - Mitsubishi Slave-Specific Status Display Attributes

Mitsubishi Slave-Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each Mitsubishi Slave Source provides information about the present state of the individual Source.

Use this section if you need information on the status of any Mitsubishi Slave database items on your system.

This section covers those attributes that are Mitsubishi Slave-specific and includes:

  • Mitsubishi Slave Channel Attributes
  • Mitsubishi Slave Source Attributes
  • Alphabetical List of Mitsubishi Slave Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Mitsubishi Slave Driver Guide - Mitsubishi Slave Channel Attributes (Mitsubishi Slave-Specific Status Display Attributes)

Mitsubishi Slave Channel Attributes

These status attributes are specific to Mitsubishi Slave channels:

  • Primary Assign
  • Source.

NOTE: Three further status attributes, Primary Eavesdrop Tx Assign, Secondary Assign, and Secondary Eavesdrop Tx Assign are not used by the Mitsubishi Slave driver.


Mitsubishi Slave Driver Guide - Mitsubishi Slave Source Attributes (Mitsubishi Slave-Specific Status Display Attributes)

Mitsubishi Slave Source Attributes

This status attribute is specific to Mitsubishi Slave sources:

  • Source.


Mitsubishi Slave Driver Guide - Alphabetical List of Mitsubishi Slave Specific Status Display Attributes (Mitsubishi Slave-Specific Status Display Attributes)

Alphabetical List of Mitsubishi Slave Specific Status Display Attributes

This section lists those status attributes that are specific to items on the Mitsubishi Slave driver. The attributes are listed in alphabetical order and comprise:

  • Primary Assign
  • Source.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.


Mitsubishi Slave Driver Guide - Primary Assign (Mitsubishi Slave-Specific Status Display Attributes)

Primary Assign

Associated with: Mitsubishi Slave channels

This attribute indicates whether the assignment of a Slave channel to its primary line has failed. The line is defined on the Connection tab of the Channel Form (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

Possible States: Displays one of the Standard Alarm States.


Mitsubishi Slave Driver Guide - Source (Mitsubishi Slave-Specific Status Display Attributes)

Source

Associated with: Mitsubishi Slave channels and Mitsubishi Slave sources

The Source attribute is common to many Status Displays. The attribute indicates the location at which the item, for example the source, resides.

The information shown varies, depending on the type of item.

For Slave channels, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>

Example:

COM5:9600:8N1
(For a Slave channel communicating via port COM5, using a baud rate of 9600, with 8 data bits, no parity (N), and 1 stop bit.)

For Slave sources, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>:PLC ID <Node ID (Slave)>

Example:

COM5:9600:8N1:PLC ID 105
(For a Slave source that has a Mitsubishi node ID of 105. The properties of the channel that the source uses to communicate with its Master are explained in the example above.)


Modbus Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Modbus Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Modbus Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Modbus Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Modbus Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Modbus Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s Modbus driver. The Modbus driver enables ClearSCADA to communicate with slave devices and PLCs using the Modbus protocol.

For more details on the information included in this guide, see Introduction to the Modbus Driver.

NOTE: For information on how to configure ClearSCADA to act as a Modbus PLC and report any data changes back to its Master, see the ClearSCADA Guide to the Modbus Slave Driver.


Modbus Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring Modbus items and features in the ClearSCADA database.

The guide also contains information for:

  • Operators and engineers who use the Modbus driver to monitor and control plant
  • Maintenance engineers.


Modbus Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Modbus Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


Modbus Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Modbus Driver Guide - Introduction to the Modbus Driver

Introduction to the Modbus Driver

The Modbus Driver allows a ClearSCADA system to be populated with data from, and control points on, Modbus Slaves or Modbus PLCs. The driver provides extra functionality within the server for retrieving data from, or controlling points on, Modbus devices. For example, Modbus PLCs use registers to store point data. Properties used by the Modbus driver determine the location of the data within those registers (see Modbus Register Ranges). Function codes supported by the Modbus driver determine how it reads or writes data to those registers (see Modbus Function Codes Supported by the ClearSCADA Modbus Driver).

The Modbus documentation explains how to configure Modbus-specific features and items within the ClearSCADA database, with sections on:

  • Configuring Modbus Devices in ClearSCADA
  • Typical Scenarios
  • Configuration Examples.

It also explains driver-specific features that are of interest to operators, such as:

  • Using Modbus Specific Pick Actions.

and driver-specific aspects that may be of interest to system administrators and engineers when diagnosing unexpected system behavior:

  • Modbus Specific Status Display Attributes
  • Troubleshooting.

ClearSCADA can communicate with Modbus devices using one of several drivers—for information on which driver is appropriate for your system requirements, see Which Driver?.


Modbus Driver Guide - Modbus Function Codes Supported by the ClearSCADA Modbus Driver (Introduction to the Modbus Driver)

Modbus Function Codes Supported by the ClearSCADA Modbus Driver

The ClearSCADA Modbus Driver supports several Modbus function codes, enabling it to read and write data on Modbus devices. The function codes that the ClearSCADA Modbus driver supports are:
Modbus Function Code | Functionality
FC1 | Read output coils
FC2 | Read input discretes
FC3 | Read multiple holding registers
FC4 | Read input registers
FC5 | Write coil
FC6 | Write single register
FC15 | Write multiple coils
FC16 | Write multiple registers
FC65 | Read S600 flow computer single-precision registers
FC67 | Read S600 flow computer double-precision registers

An exception error is generated if an unsupported function code is received by a Modbus device (see Modbus Exception Errors).


Modbus Driver Guide - Which Driver? (Introduction to the Modbus Driver)

Which Driver?

ClearSCADA is able to communicate with Modbus devices using one of several ClearSCADA drivers. Which driver you use depends on your system set-up and configuration requirements. This section briefly summarizes the different options that are available.

The drivers that you can use to communicate with Modbus devices include:

  • ClearSCADA Modbus Driver
  • ClearSCADA SCADAPack Modbus Driver.


Modbus Driver Guide - ClearSCADA Modbus Driver (Introduction to the Modbus Driver)

ClearSCADA Modbus Driver

The Modbus Driver can communicate with Modbus Slaves and Modbus PLCs using either:

  • Modbus RTU over a serial or TCP connection
  • Modbus TCP over TCP.

With the Modbus driver, you configure Scanners to determine which data gets polled at which frequency—the points on a Scanner are all polled at the same rate.

If your system has a simple configuration and the above functionality fulfills your system requirements, you can use either the ClearSCADA Modbus Driver, or the ClearSCADA SCADAPack Modbus Driver to communicate with the Modbus devices on your system.

Refer to the rest of this guide for information on configuring Modbus Driver-specific items and features within ClearSCADA.


Modbus Driver Guide - ClearSCADA SCADAPack Modbus Driver (Introduction to the Modbus Driver)

ClearSCADA SCADAPack Modbus Driver

The SCADAPack Modbus Driver enables ClearSCADA to communicate with Schneider Electric’s range of SCADAPack RTUs, using the Modbus protocol. The driver supports standard Modbus communications options, but also includes additional functionality that is required to support specific features in the SCADAPack RTUs. For example, DLOG time-stamped historic data, which the SCADAPack Modbus driver can retrieve from each SCADAPack RTU and store in the ClearSCADA database.

The SCADAPack Modbus driver also provides additional functionality for ‘generic’ Modbus devices, as well as SCADAPack devices, including PSTN support (whereby Modbus devices can be dialled from ClearSCADA and vice versa). The SCADAPack Modbus Driver can communicate with Modbus devices using any of the following communication mechanisms (the ClearSCADA Modbus Driver also supports those marked *):

  • Modbus ASCII over a serial, TCP or UDP connection
  • Modbus RTU over a serial*, TCP* or UDP connection
  • Modbus TCP over a TCP*, or UDP connection.

With the SCADAPack Modbus driver, you assign each point an Address and a Retrieval Interval. The Retrieval Interval determines the frequency with which ClearSCADA polls a Modbus device for point data. Reads are blocked together for Retrieval Intervals that coincide for points within the same register range (for instance, Input Registers), to determine the most efficient polls automatically.

If your system is to communicate with SCADAPack RTUs, or requires any of the additional functionality listed above, use the ClearSCADA SCADAPack Modbus Driver to communicate with the Modbus devices on your system—for further information on configuring items on the SCADAPack Modbus driver, see the ClearSCADA Guide to the SCADAPack Modbus Driver. If, however, the ClearSCADA Modbus Driver fulfills your system requirements, either driver can be used.


Modbus Driver Guide - Configuring Modbus Devices in ClearSCADA (Introduction to the Modbus Driver)

Configuring Modbus Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, control devices, and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the Modbus devices on your system.

In order to represent any Modbus devices, the Modbus Driver has to be installed and running on the ClearSCADA servers on your system. The driver is represented by the Modbus RTU component in the ClearSCADA Installation Wizard’s Setup window. The component is located within the Server branch of the tree that is displayed in the window (see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers).

When you configure Modbus items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant Modbus devices on your system. Some settings are either fixed (incorporated into the design of the Modbus Slave or PLC), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the Modbus devices on your system before you can configure the Modbus database items successfully.

For instance, you need to know the type(s) of communications available for the scanners on your system, and how those communications are structured or grouped.

You also need to be aware of which optional features are required for each Modbus item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with Modbus database items, including Lists, Actions, and Mimics. For actions that are specific to the Modbus driver, see Using Modbus Specific Pick Actions. For further information on actions and details on Lists and Mimics, see the core documentation.

For each Modbus device, you need to configure:

  1. Modbus Channel(s) to represent the communication connections between a Modbus PLC or Modbus Slave and the ClearSCADA server (see Configuring a Modbus Channel).

You need to configure a separate Modbus channel for each separate communications channel that is available to the Modbus driver on your system.

Check that the channel configuration corresponds to the type of communications being used in each instance (Serial or Modbus TCP).

  2. At least one Modbus Scanner for each Modbus device that you want to scan.

Configure a scanner for each register range that you want to scan on a device, or each group of points that you want to scan at a different frequency or time offset.

We recommend that you configure separate scanners to scan different blocks of registers in a range, if those blocks are some distance apart. This is more efficient than having one scanner scan a large range that includes many unused registers.

For further information, see Configuring a Modbus Scanner.

  3. A Modbus Point to represent each item of data that is derived from the content of a Modbus register.

A register can, for example, store the values of analog or digital measuring instruments or control devices that are connected to the Modbus PLC or Slave that is scanned by a particular Scanner (see Points Used on Modbus Scanners).

To minimize the time that it takes to configure the required Modbus items, you may want to configure them in the order listed above, as Scanner configuration requires you to specify a channel, and Point configuration requires that you specify a scanner, and so on.


Modbus Driver Guide - Modbus Register Ranges (Introduction to the Modbus Driver)

Modbus Register Ranges

Modbus PLCs use registers to store point data. There are many registers in a Modbus PLC. The registers are divided into blocks of 65536. ClearSCADA addresses each block of Modbus registers using the range 0 - 65535. The data stored in each block depends on the type of Modbus PLC.

The person that programmed and set up each Modbus PLC should have a list of the registers and values used. Use this information to determine the Register block and location on the Scanner Form, and the Word (and, where applicable, the bit) offset on each Point Form. This determines which data is scanned by each scanner.

Remember that registers comprise 16 bits (1 Word), whereas discretes and output coils comprise 1-bit values.

The first digit within each register range is used within ClearSCADA to define the type of data (as defined by the ‘Location’ field on the Scanner Form).

Example:

Modbus addressing can start at 0 or 1 (as specified on the Modbus Scanner Form—see Configure the Scan Properties).

ClearSCADA addressing starts at 0. In this example, the Modbus registers start at address 1. Hence, for example, the Modbus register range 1-65535 maps to addresses 0-65536 within ClearSCADA.

The first digit within each Modbus register range defines the type of data (‘Location’) within ClearSCADA. In this example, the digit 0 represents Output Coils, 1 represents Input Discretes, 3 represents Input Registers, 4 represents Holding Registers, and so on.

Thus a Location of ‘Holding Registers’ and Data Address of 6 within ClearSCADA represents Modbus register 400007 (the 7th register within the block that stores 16-bit I/O values).
Modbus Register Range | Modbus RTU Master | Location Digit
1 – 65536 | Output Coils (with a ClearSCADA range of 0 - 65535) (For example, digital input points and digital output points.) | 0
100001 – 165536 | Input Discretes (with a ClearSCADA range of 0 - 65535) (For example, digital input points.) | 1
300001 – 365536 | Input Registers (with a ClearSCADA range of 0 - 65535) (For example, digital input points and analog input points.) | 3
400001 – 465536 | Holding Registers (with a ClearSCADA range of 0 - 65535) (For example, digital input points, digital output points, analog inputs, and analog output points.) | 4
400001 – 465536 | S600 Flow Computer 32-bit Float (with a ClearSCADA range of 0 - 65535) (For example, analog input points.) | 65
400001 – 465536 | S600 Flow Computer 64-bit Float (with a ClearSCADA range of 0 - 65535) (For example, analog input points.) | 67

The address information forms part of the Source status attribute that you can view for each Modbus point in ClearSCADA (see Source).

For examples of how to configure ClearSCADA to fulfill Modbus scanning requirements, see Configuration Examples.

If the addressing on the Modbus PLCs on your system uses a greater number of digits than those indicated here, omit the extra zero(s) at the start of each address, then configure the properties within ClearSCADA in the usual way.


Modbus Driver Guide - Typical Scenarios (Introduction to the Modbus Driver)

Typical Scenarios

This section gives some typical scenarios in which Modbus devices could be used within a ClearSCADA system. These scenarios are designed to act as a guide when configuring your own ClearSCADA system to communicate with Modbus devices—they do not indicate all possible scenarios in which the Modbus protocol may be used.

Scenarios in which you would use a Modbus driver include:

  • Modbus Master Communicating with one or more Modbus Devices
  • Dual-Purpose Modbus Master/Modbus Slave.


Modbus Driver Guide - Modbus Master Communicating with one or more Modbus Devices (Introduction to the Modbus Driver)

Modbus Master Communicating with one or more Modbus Devices

Where ClearSCADA retrieves data from Modbus PLCs, or third-party devices that are communicating using the Modbus protocol, the ClearSCADA system acts as a Modbus Master.

For this scenario, the Modbus driver has to be running on your system, and you need to configure the required number of Modbus channels, Modbus scanners, and Modbus points within ClearSCADA.

For further information, see Configuring Modbus Devices in ClearSCADA.


Modbus Driver Guide - Dual-Purpose Modbus Master/Modbus Slave (Introduction to the Modbus Driver)

Dual-Purpose Modbus Master/Modbus Slave

Where a third-party server uses the Modbus protocol to obtain data from ClearSCADA, and ClearSCADA uses the Modbus protocol to obtain its data from a PLC, ClearSCADA becomes dual-purpose, with regard to Modbus functionality. When communicating with the third-party server, ClearSCADA acts as a Modbus Slave, and when communicating with the PLC, ClearSCADA acts as a Modbus Master.

In this scenario, you need to configure both a Modbus Master, and a Modbus Slave configuration suite. You also need to check that ClearSCADA is running both the Modbus driver and the Modbus Slave driver.

To configure ClearSCADA so that it can communicate as a Master, see Configuring Modbus Devices in ClearSCADA.

To configure ClearSCADA so that it can communicate as a Slave, see the ClearSCADA Guide to the Modbus Slave Driver.


Modbus Driver Guide - Configuring a Modbus Channel

Configuring a Modbus Channel

Modbus channels are used to provide ClearSCADA with additional connection information, so that the server can successfully communicate with Modbus PLCs and Modbus Slaves.

Specify the features for each channel by using the fields on the Modbus Channel Form.

The Form has several tabs. This section explains the driver-specific fields on the:

  • Channel tab (see Configure the Channel Properties)
  • Primary Port and Secondary Port tabs (see Primary and Secondary Port Properties).

For information on common fields on these tabs, see Configuring Channels on Simple Drivers in the ClearSCADA Guide to Simple Drivers.

For information on the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Modbus Driver Guide - Configure the Channel Properties (Configuring a Modbus Channel)

Configure the Channel Properties

Use the fields on the Channel tab to define the general properties for a channel. Many of the fields on this tab are common to channels on many simple drivers (see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to Modbus channels are explained below:

  • Switch After n scanners have failed—Where a channel can use either the primary or secondary port, communications can be swapped to the other line. This is useful if an unexpected problem occurs with communications on the line that is currently in use.

Use the Switch After n scanners have failed field to specify how many scanners on the channel have to fail before the server automatically switches lines. When the server switches lines, it attempts to re-establish communications with each of the scanners that are using the channel.


Modbus Driver Guide - Primary and Secondary Port Properties (Configuring a Modbus Channel)

Primary and Secondary Port Properties

Modbus channels are able to use either one or two communication ports, depending on your system setup. Communications can be either Serial or TCP/IP. Where Network communications are used, Modbus channels use Modbus Transmission Control Protocol (TCP).

Use the Connection Type field on the Primary Port and Secondary Port tabs to specify how many ports are available for a channel, and the type of connection that is used. Where a Serial connection is specified, you need to specify the properties for that connection. For further information, see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers.

For an example that uses a channel with a Modbus TCP connection, see Use Modbus RTU to Communicate via a Terminal Server.


Modbus Driver Guide - Configuring a Modbus Scanner

Configuring a Modbus Scanner

A Modbus Scanner is logical functionality that runs within ClearSCADA and scans for data on a Modbus PLC or a Modbus Slave.

Configure a scanner for:

  • Each register range that you want to scan on a device
  • Each group of points that you want to scan at a different frequency or time offset.

We recommend that you configure separate scanners to scan different blocks of registers in a range, if those blocks are some distance apart. This is more efficient than having one scanner scan a large range that includes many unused registers.

You can configure a Scanner’s properties using the fields on the Modbus Scanner Form. The Form has several tabs:

  • Use the fields on the Scanner tab to specify the scan properties, such as the scan rate and the type of data to be scanned (see Configure the Scanner Properties).
  • Use the fields on the Primary Port and Secondary Port tabs to specify how many ports are available for the scanner, and the type of connection used (see Configure the Primary and Secondary Port Properties).
  • For fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional Modbus Scanner in ClearSCADA, see Minimum Configuration.

For examples showing how to configure a scanner to fulfill Modbus scanning requirements, see Configuration Examples.


Modbus Driver Guide - Minimum Configuration (Configuring a Modbus Scanner)

Minimum Configuration

As a minimum, for a Modbus scanner to become functional (online), you need to:

  • Specify the channel through which the scanner communicates
  • If the Primary or Secondary ports are used for network communications, you have to specify the Host Address.

You also need to put the scanner In Service, and save the configuration.

This will result in a functional scanner that uses the default configuration settings.


Modbus Driver Guide - Configure the Scanner Properties (Configuring a Modbus Scanner)

Configure the Scanner Properties

Use the fields on the Scanner tab to define the driver-specific properties for a scanner. Some of these fields are common to many scanners—see Define Common Scanner Properties in the ClearSCADA Guide to Simple Drivers for information. Those fields that are specific to scanners on the Modbus driver are described below.

Use the fields on the tab to:

  • Configure the General Scanner Properties
  • Configure the Scan Properties.


Modbus Driver Guide - Configure the General Scanner Properties (Configuring a Modbus Scanner)

Configure the General Scanner Properties

Use the fields toward the top of the Scanner tab to define the general scanner properties. Some of these fields are common to many scanners (see Define Common Scanner Properties in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the Modbus driver are described below.

  • Channel—Specify the channel through which the scanner sends and receives data. Use the browse button to display a Reference Browse window. From the window, select the channel that the scanner uses to communicate with the Modbus device.
  • Device Address—Specify the address of the Modbus Slave or Modbus PLC that is to respond to any requests for data changes or control actions. The address has to be in the range 0 to 255.


Modbus Driver Guide - Configure the Scan Properties (Configuring a Modbus Scanner)

Configure the Scan Properties

Use these fields on the Scanner tab to define properties such as the scan rate, scan offset, and the type of data that is to be scanned.

You can also specify whether the scan rate is increased whenever any of the associated points are displayed on a client (see Define Whether a Scanner is Promoted While its Points are on Display in the ClearSCADA Guide to Simple Drivers).

For information on fields that are available for many scanners, see Define the Scan Rate in the ClearSCADA Guide to Simple Drivers. Fields that are specific to Modbus scanners are explained below:

Modbus PLCs use registers to store point data (see Modbus Register Ranges). Use the properties below to determine which block of registers are scanned by this scanner. (We recommend that you configure separate scanners to scan different blocks of registers in a range, if those blocks are some distance apart. This is more efficient than having one scanner scan a large range that includes many unused registers.)

Should an attempt be made to scan for data on registers outside of a remote device’s supported range, an exception error will occur—see Modbus Exception Errors.

  • Data Address—Specify the position in the Modbus register from which the scanner is to start scanning data. Enter the register address, within the range 0 to 65535.
  • Data Length—Enter the number of registers that are to be scanned. The registers are scanned as a block, starting with the register specified in the Data Address field, above.

To allow for the fact that some Modbus devices can only transmit up to 125 data words, ClearSCADA automatically splits any requests for large amounts of data into multiple requests, so that the maximum amount of data transmitted in each message is as follows:
Data Type | Maximum Data Length per Message
Output Coils | 2000
Input Discretes | 2000
Holding Registers | 125
Input Registers | 125
S600 Flow Computer 32-bit Float | 125
S600 Flow Computer 64-bit Double | 125

ATTENTION: Some Modbus devices can only transmit messages that have a total message length (including overhead) of 255 bytes or less. With Modbus devices that have a 255 bytes or less limit, you need to set a Data Length that takes into account the maximum message size that the device can handle. This means you may need to specify a smaller Data Length than those listed above.

  • Location—Specify the register range by specifying the size and type of data to be scanned. Each data type corresponds to the first digit in a Modbus register range (see Modbus Register Ranges). Choose from:
  • Output Coils—Discrete single-bit output values. Configuration on the Point Form determines the position of the bit within each 16-bit Word (see Configuring Analog Points, or see Configuring Digital Points, as appropriate).
  • Input Discretes—Discrete single-bit input values. Configuration on the Point Form determines the position of the bit within each 16-bit Word.
  • Holding Registers—16-bit registers that store output values.
  • Input Registers—16-bit registers that store input values.
  • S600 Flow Computer 32bit Float—IEEE 32-bit single-precision floating point values on an S600 Flow Computer.
  • S600 Flow Computer 64bit Double—IEEE 64-bit double-precision floating point values.

Example:

A scanner has this configuration:

Data Address: 10
Data Length: 15
Location: Input Discretes

This results in the scanner scanning registers 10 to 25, within the Input Discrete register range. As Input Discretes are in the Modbus register range 100001 to 165536, and the scanner is scanning a block of 15 registers, starting with the 10th register, this results in the scanner scanning Modbus address range 100011 to 100026, with each register within the Input Discrete range comprising a one-bit value.

Another scanner has this configuration:

Data Address: 1000
Data Length: 5
Location: Input Registers

In this case, the scanner scans registers 1000 to 1005 within the Input Register block. As Input Registers are in the Modbus register range 300001 to 365536, this results in the scanner scanning Modbus address range 301001 to 301006, with each register within the range comprising 16 bits (that is, the scanner scans 5 Words of data).

(For more information on addressing, see Modbus Register Ranges.)

  • Always Update on Scan—Use this check box to indicate whether you want to use the scanner’s updates as a trigger for a Logic program (see Define Whether a Scanner is Used to Trigger Logic in the ClearSCADA Guide to Simple Drivers).
  • Use TCP Transaction ID—Select this check box if the transaction ID component of Modbus/TCP data packets is used to check for duplicate packets. Duplicate packets might occur, for example, if a request times out and the driver resends the request and then receives responses to both the original request and the resent request. Should duplicate packets occur, the driver resends the request or, if duplicate packets still occur, fails the scanner.

Clear the check box if the Modbus device does not support checking for duplicate data packets.

  • Complete Control on Acknowledge—Select this check box for the driver to process an acknowledge exception response as if it were a successful control completion response. Select this check box if a scanner scans a device that responds to a register write command with an exception response acknowledgment, rather than the usual Modbus write acknowledge response.

Clear the Complete Control on Acknowledge check box for a scanner that scans a device that responds to a register write command with a conventional Modbus write acknowledge response. The check box is clear by default.

  • Device Class—Only applies if the scanner’s Primary Port and/or Secondary Port are configured to use a ‘Network’ Connection Type (see Configure the Primary and Secondary Port Properties). Use the Device Class combo box to specify the conformance level of the MODBUS/TCP device. The conformance level determines which function codes are supported.

Choose from:

  • Class 0—Supports function codes FC3 and FC16.
  • Class 1—Supports FC1, FC2, FC3, FC4, FC5, FC6 and FC16.
  • Class 2—Supports FC1, FC2, FC3, FC4, FC5, FC6, FC15 and FC16.
  • All—Supports FC1, FC2, FC3, FC4, FC5, FC6, FC15, FC16, FC65 and FC67.

For information on the functionality with which each function code is associated, see Modbus Function Codes Supported by the ClearSCADA Modbus Driver.

  • Address Base—Use this combo box to specify the starting base for the address that is included in the Source attribute for this scanner and its points. Specify whether the Modbus addressing starts at 0 or 1.

The address base is purely for use in ClearSCADA and has no effect on the scanned data address. For more information, see Modbus Register Ranges.


Modbus Driver Guide - Configure the Primary and Secondary Port Properties (Configuring a Modbus Scanner)

Configure the Primary and Secondary Port Properties

Use the fields on the Primary Port and Secondary Port tabs to specify how many ports are available to a scanner, the port number, communications protocol, and the address of the Modbus device that is to be scanned.

  • Connection Type—Specify the type of connection for which each port is used. Choose from:
  • None—The port is not used.
  • Network—The port is used to communicate with network connected devices.
  • Host Address—Displayed if the Connection Type is set to ‘Network’. Use the field to specify the address of the PLC or other Modbus device.

On a single network system, enter the IP address of the device, or the Node name (if supported). On a dual network system, enter the IP address.

  • Port—Displayed if the Connection Type is set to ‘Network’. Use the field to specify the TCP/IP port number or remote network device with which the scanner is to communicate.
  • Communications Type—Use to specify the type of Modbus protocol that the scanner is to use. Specify Modbus TCP or Modbus RTU, as appropriate.

For an example of scanner configuration that uses Network communications and the Modbus RTU protocol, see Use Modbus RTU to Communicate via a Terminal Server.


Modbus Driver Guide - Points Used on Modbus Scanners

Points Used on Modbus Scanners

Modbus Scanners can support the point types that are listed below.

You configure the Modbus points on your system using the Modbus Analog Point Form, or the Modbus Digital Point Form, as appropriate. The Forms have several tabs (see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers).

For information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

For information on configuring fields on the Modbus tab, see Configuring Analog Points, or see Configuring Digital Points.

For information on configuring fields on the <Point Type> tab, see the appropriate reference below:

  • Analog Point—see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.
  • Digital Point—see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

On Modbus PLCs, point data is stored in registers (see Modbus Register Ranges). You specify the register block that each scanner scans, using fields on the Scanner Form (see Configure the Scanner Properties). You define the Word offset, and where applicable, the bit offset of the point data within the register block, using fields on the Modbus tab of the Point Forms. This determines the location of the points that are to be scanned by each scanner.


Modbus Driver Guide - Configuring Analog Points

Configuring Analog Points

The Modbus driver supports Analog Input and Analog Output points.

Analog points can be physical points that exist on Modbus PLCs, or calculated values that reside within Modbus registers.

Configure the properties for each analog point using the fields on the Modbus Analog Point Form.

This section covers configuration of properties on the Modbus tab of the Form.

Use the Modbus tab to:

  • Configure the Modbus Point Properties
  • Configure Scaling Properties (see Scale Analog Values for use in ClearSCADA in the ClearSCADA Guide to Simple Drivers)
  • Configure Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration).

For information on the fields on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

For examples showing how to configure analog points to fulfill Modbus scanning requirements, see Configuration Examples.


Modbus Driver Guide - Configure the Modbus Point Properties (Configuring Analog Points)

Configure the Modbus Point Properties

Use the fields at the top of the Modbus tab to configure the Modbus-specific point properties. Some of these fields are common to many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to the Modbus driver are explained below:

  • Word Offset—Specify the location of the point data within the Modbus register. The lowest acceptable offset is zero (see the example below).

Example:

A scanner scans several analog points on a Modbus PLC.

The scanner has this configuration:

Data Address: 10
Data Length: 12
Location: Input Registers

One of the analog points has this configuration:

Word Offset: 7

The analog data is stored as a 16-bit value.

The configuration determines that the scanner scans registers 10 to 22 within the PLC. Within this block of registers, the analog point given above is located at register 16. (Each register is one Word.)

If the analog data was stored as a 32-bit value (see Data Type, below), the above configuration would indicate that the analog point is located at registers 16 to 17.

  • Data Type—Specify how analog data is represented in the Slave. Choose from:
  • UINT—Unsigned 16-bit data. Each UNIT comprises 1 Modbus register.
  • DINT—Signed 32-bit data. Each DINT comprises 2 Modbus registers.
  • UDINT—Unsigned 32-bit data. Each UDINT comprises 2 Modbus registers.
  • REAL—IEEE 32-bit single-precision floating point value. Each REAL comprises 2 Modbus registers.
  • INT—Signed 16-bit data. Each INT comprises 1 Modbus register.
  • DOUBLE—IEEE 64-bit double-precision floating point value. Each DOUBLE comprises 4 Modbus registers.

The Data Type you choose affects the number of registers, which you need to consider when setting the Word Offset field (above). You need to set the Word Offset to indicate the first Word (or register) of a multi-register point.

  • Swap Registers—Applies to DINT, UDINT, REAL, and DOUBLE Data Types. As this data comprises two or four 16-bit Words, you can use this check box to specify the order in which the Words of data are presented in ClearSCADA, and hence the value that they represent.

Clear the check box if you do not want the data in the registers to be swapped for use in ClearSCADA. For multi-register data, the highest numbered register contains the most significant Word.

Select the check box if the Word values are to be swapped for use within ClearSCADA. For multi-register data, the lowest numbered register contains the most significant Word.

Example 1:

An analog value has a DINT data type, and is located at registers 16 to 17 in a PLC. The Registers are not swapped.

The present value of the analog is:

Word 16 = 1
Word 17 = 0

As the registers are not swapped, this results in the analog point being given a value of 1 within ClearSCADA.

If the configuration was such that the registers were swapped, this would result in the analog point being given a value of 65535 within ClearSCADA.

Example 2:

A DOUBLE (64-bit double precision floating point) obtains its data from Modbus registers 40010 to 40013. The registers are not swapped, therefore register 40013 contains the most significant Word. (If the registers were swapped, register 40010 would contain the most significant Word, and register 40013 the least significant.)


Modbus Driver Guide - Configuring Digital Points

Configuring Digital Points

The Modbus driver supports Digital Input and Digital Output points.

Digital points can be physical points that exist on Modbus PLCs, or calculated states that reside within Modbus registers.

Configure the properties for each digital point using the fields on the Modbus Digital Point Form.

This section covers configuration of properties on the Modbus tab of the Form (see Configure the Modbus Point Properties).

For information on the fields on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

For examples showing how to configure digital points to fulfill Modbus scanning requirements, see Configuration Examples.


Modbus Driver Guide - Configure the Modbus Point Properties (Configuring Digital Points)

Configure the Modbus Point Properties

Use the fields on the Modbus tab to define the Modbus-specific properties for a digital point. For information on those fields that are common to many simple drivers, see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers. Fields that are specific to the Modbus driver are described below.

  • Word Offset—Specify the location of the point data within the scanner’s register range. The lowest acceptable offset is zero.
  • Bit Offset—Enter the lowest (starting) bit of the point. With a multi-bit point, you need to have the bits consecutive (for example, a 2-bit digital might use bits 5 and 6, where bit 5 would be the starting bit). The bits of a multi-bit point have to reside consecutively in the same Word in a register range—bits for one point cannot continue into another Word.

The range is 0-15.

Example:

A scanner scans several analog and digital points on a Modbus PLC.

The scanner has this configuration:

Data Address: 10
Data Length: 12
Location: Holding Registers

One of the digital points has this configuration:

Number of Bits:2
Word Offset: 5
Bit Offset: 4

The configuration determines that the scanner scans registers 10 to 22 within the PLC. Within this block of registers, the digital point given above is located at register 14, starting at the fourth bit within that register, and continuing to the fifth bit. (Each register is one 16-bit Word.)

In order to read the value of this point, the scanner extracts bits 4 and 5 of register 14.

  • Persistence—Specify the time that the driver waits before it reports a change of state. Enter the time in seconds.


Modbus Driver Guide - Configuration Examples

Configuration Examples

This section includes examples of ClearSCADA configuration that might be used to allow the ClearSCADA Modbus driver to transmit data to and from Modbus PLCs.

The examples refer to Modbus Register range addressing—for more information on Modbus address ranges, and a sample table of such addressing, see Modbus Register Ranges.

The Modbus address with which a channel, scanner, or point is associated is displayed as part of the Source status attribute. The Source attribute is displayed on the associated List and Status display for each item (see Modbus Specific Status Display Attributes).

Use the examples as an aid when configuring your ClearSCADA system. The examples in this section include:

  • A Modbus Scanner Configured to Scan Four Input Registers
  • A Modbus Analog Input Configured to Present Data in UINT Format
  • A Modbus Analog Input Configured to Present Data in DINT Format
  • A Modbus Digital Input Configured to Contain Input Register Data
  • A Modbus Scanner Configured to Scan a Block of Output Coils
  • A Modbus Digital Input Configured to Contain Output Coil Data
  • Sample System Requirement and Solution
  • Use Modbus RTU to Communicate via a Terminal Server.


Modbus Driver Guide - A Modbus Scanner Configured to Scan Four Input Registers (Configuration Examples)

A Modbus Scanner Configured to Scan Four Input Registers

This example demonstrates how you might configure a Modbus Scanner, in order for it to scan four Input Registers on a Modbus PLC.

Example:

A Modbus scanner is to scan Input Registers in the range 300003 to 300006. The addressing at the Modbus PLC starts at 1.

Within ClearSCADA, the Modbus Scanner is configured as follows:

Data Address:2
(A starting address of 300003 indicates that the first data address is the third register in the Input Register range. As the Modbus addressing starts at 1 and ClearSCADA addressing starts at 0, a Data Address of 2 maps to the third register in the range.)

Data Length:4
(As the range 300003 to 300006 is 4 registers long.)

Address Base:1
(As the Modbus addressing for this particular PLC starts at 1.)

Location:Input Registers

The Source attribute for the scanner confirms that the scanner is configured to scan Input Registers 300003 to 300006:

MODBUS/TCP-8 502:Device 5, Input Registers - 3:00003-3:00006
(3:00003-3:00006 indicates a Modbus address range of 300003 to 300006—a range that contains Input Registers in this particular PLC)


Modbus Driver Guide - A Modbus Analog Input Configured to Present Data in UINT Format (Configuration Examples)

A Modbus Analog Input Configured to Present Data in UINT Format

This example demonstrates how you might configure a Modbus Analog point to represent Input Register data from a Modbus PLC. The analog point is to present the data in UINT format in ClearSCADA.

Example:

Within ClearSCADA, an analog Input point is to contain data from the second Word in the Input Register range 300003 to 300006. The point is to present the data in unsigned 16-bit format.

The configuration of the Modbus scanner with which the point is associated is detailed in an earlier example (see A Modbus Scanner Configured to Scan Four Input Registers). The addressing at the Modbus PLC starts at 1.

Within ClearSCADA, the Modbus Analog Input Point is configured as follows:

Word Offset:1
(As the point is to retrieve data from the second Word in the scanned address range (the first Word being 0).)

Data Type:UINT
(UINT specifies that the data is to be presented in unsigned 16-bit format.)

The Source attribute for the point confirms that the point is to contain data from the second Word in the Input Register range 300003 to 300006:

MODBUS/TCP-8 502:Device 5, Input Registers - AG 3:00004 (UINT)
(3:00004 indicates the Modbus address 300004, which contains Input Registers in this particular PLC. The point is to present the data in unsigned 16-bit format.)


Modbus Driver Guide - A Modbus Analog Input Configured to Present Data in DINT Format (Configuration Examples)

A Modbus Analog Input Configured to Present Data in DINT Format

This example demonstrates how you might configure a Modbus Analog point to represent Input Register data from a Modbus PLC. The analog point is to present the data in DINT format in ClearSCADA.

Example:

Within ClearSCADA, an analog input point is to contain data from the third Word in the Input Register range 300003 to 300006. The point is to present the data in signed 32-bit format.

The configuration of the Modbus scanner with which the point is associated is detailed in an earlier example (see A Modbus Scanner Configured to Scan Four Input Registers). The addressing at the Modbus PLC starts at 1.

Within ClearSCADA, the Modbus Analog Input Point is configured as follows:

Word Offset:2
(As the point is to retrieve data from the third Word in the scanned address range (the first Word being 0).)

Data Type:DINT
(DINT specifies that the data is to be presented in signed 32-bit format.)

The Source attribute for the point confirms that the point is to contain data from the third Word in the Input Register range 300003 to 300006:

MODBUS/TCP-8 502:Device 5, Input Registers - AG 3:00005-3:00006 (DINT)
(3:00005-3:00006 indicates the Modbus address 300005 to 300005, which contains Input Registers in this particular PLC (the point has 32-bits of data—the equivalent of 2 Words, and therefore 2 Registers). The point is to present the data in signed 32-bit format.)


Modbus Driver Guide - A Modbus Digital Input Configured to Contain Input Register Data (Configuration Examples)

A Modbus Digital Input Configured to Contain Input Register Data

This example demonstrates how you might configure a Modbus Digital point to represent Input Register Data from a Modbus PLC.

Example:

Within ClearSCADA, a 1-bit digital Input point is to contain data from the 9th bit of the third Word in the Input Register range 300003 to 300006. (An Input Register is 16-bits, or one Word, long.)

The configuration of the Modbus scanner with which the point is associated is detailed in an earlier example (see A Modbus Scanner Configured to Scan Four Input Registers). The addressing at the Modbus PLC starts at 1.

Within ClearSCADA, the Modbus Digital Input Point is configured as follows:

Number of Bits:1

Word Offset:2
(As the point is to retrieve data from the third Word in the scanned address range (the first Word being 0).)

Bit Offset:8
(The 9th bit in the above Word (the first Bit being 0).)

The Source attribute for the point confirms that the point is configured to contain data from the 9th bit of the third Word in the Input Register range 300003 to 300006:

MODBUS/TCP-8 502:Device 5, Input Registers - DG 3:00005 (bit offset 8, 1 bits)
(3:00005 indicates the Modbus address 300005, which contains Input Registers in this particular PLC. The point is to contain 1-bit of data from 9th bit (bit offset 8) in this register.)


Modbus Driver Guide - A Modbus Scanner Configured to Scan a Block of Output Coils (Configuration Examples)

A Modbus Scanner Configured to Scan a Block of Output Coils

This example demonstrates how you might configure a Modbus Scanner, so that it scans a block of Output Coils in a Modbus PLC.

Example:

A Modbus scanner is to scan Output Coils in the range 00006 to 00105. The addressing at the Modbus PLC starts at 1.

Within ClearSCADA, the Modbus Scanner is configured as follows:

Data Address:5
(A starting address of 00006 indicates that the first data address is the 6th coil in the Output Coils range. As the Modbus addressing starts at 1 and ClearSCADA addressing starts at 0, a Data Address of 5 maps to the 6th Output Coil in the range.)

Data Length:100
(As the range 00006 to 00105 is 100 coils long.)

Address Base:1
(As the Modbus addressing for this particular PLC starts at 1.)

Location:Output Coils

The Source attribute for the scanner confirms that the scanner is configured to scan Output Coils 00006 to 00105:

MODBUS/TCP-8 502:Device 5, Output Coils - 0:00006-0:00105
(0:00006-0:00105 indicates a Modbus address range of 00006 to 00105—a range that contains Output Coils in this particular PLC)


Modbus Driver Guide - A Modbus Digital Input Configured to Contain Output Coil Data (Configuration Examples)

A Modbus Digital Input Configured to Contain Output Coil Data

This example demonstrates how you might configure a Modbus Digital point to represent Output Coil data from a Modbus PLC.

Example:

Within ClearSCADA, a 1-bit digital Input point is to contain data from the 9th bit of the third Word in the Output Coil range 00006 to 00105. (An Output Coil contains 1-bit of data.)

The configuration of the Modbus scanner with which the point is associated is detailed in an earlier example (see A Modbus Scanner Configured to Scan a Block of Output Coils). The addressing at the Modbus PLC starts at 1.

Within ClearSCADA, the Modbus Digital Input Point is configured as follows:

Number of Bits:1

Word Offset:2
(As the point is to retrieve data from the third Word in the scanned address range (the first Word being 0). Each Output Coil contains 1-bit of data, therefore a Word Offset of 2 offsets the scanned address range for this point by 32 (as one Word = 16 bits, or 16 Output Coils).)

Bit Offset:8
(The 9th bit in the above Word (the first Bit being 0). Used in conjunction with the Word Offset, this property indicates that the point is to contain data from the 41st Output Coil in the scanned data range.)

The Source attribute for the point confirms that the point is configured to contain data from the 9th bit of the third Word in the Input Register range 00006 to 00105:

MODBUS/TCP-8 502:Device 5, Output Coils - DG 0:00046
(0:00046 indicates the Modbus address 00046, which contains Output Coils in this particular PLC. As the scanner with which the point is associated scans data starting at Data Address 00006, the 46 indicates that the point is to contain data from 9th bit on the third Word of the scanned address range ((2 x 16)(Word Offset) + 8 (Bit Offset) + 1(Address Base) + 5 (scanner starting Data Address) = 46.)


Modbus Driver Guide - Sample System Requirement and Solution (Configuration Examples)

Sample System Requirement and Solution

This example includes a sample system requirement, and the resulting ClearSCADA configuration required to fulfill such a requirement.

The example builds on the concepts that are detailed in the previous Configuration Examples in this section.

Example:

Requirement:

The Modbus driver on a ClearSCADA system is required to scan the following points on a Modbus PLC:

Four analog points, comprising one at each of these locations:

  • 3:00005 (INT)
  • 3:00010 (DINT)
  • 3:00100(REAL)
  • 4:00011 (UINT).

Five digital points, comprising one at each of these locations:

  • 3:00012 bit offset 5
  • 1:00005
  • 0:00006
  • 1:00009
  • 1:00025.

Solution:

To fulfill the above requirement, five Modbus Scanners are needed to scan these data ranges:

  • 0:00006
  • 1:00005 to 1:00025
  • 3:00005 to 3:00012
  • 3:00100 to 3:00101
  • 4:00011

(The two ranges within the 3: range are scanned separately to avoid needlessly scanning 88 unused registers in between the required ranges.)

These Modbus Scanners are configured within ClearSCADA:
Configuration Field on Modbus Scanner Form | Required Scanner Range
 | 0:00006 | 1:00005 to 1:00025 | 3:00005 to 3:00012 | 3:00100 to 3:00101 | 4:00011
(Scanner) Name | Output Coils | Input Discretes | Input Registers Low | Input Registers High | Holding Registers
Data Address | 5 | 4 | 4 | 99 | 10
Data Length | 1 | 21 | 8 | 2 | 1
Location | Output Coils | Input Discretes | Input Registers | Input Registers | Holding Registers
Address Base | 1 | 1 | 1 | 1 | 1

These Modbus Analog Points are configured within ClearSCADA:
Configuration Field on Modbus Analog Point Form | Required Analog Point Data
 | 3:00005 (UINT) | 3:00010 (DINT) | 3:00100 (REAL) | 4:00011 (UINT)
Scanner (with which the point is associated) | Input Registers Low | Input Registers Low | Input Registers High | Holding Registers
Word Offset | 0 | 5 | 0 | 0
Data Type | UINT | DINT | REAL | UINT

These Modbus Digital Points are configured within ClearSCADA:
Configuration Field on Modbus Digital Point Form | Required Digital Point Data
 | 0:00006 | 1:00005 | 1:00009 | 1:00025 | 3:00012 Bit Offset 5
Number of Bits | 1 | 1 | 1 | 1 | 1
Scanner (with which the point is associated) | Output Coils | Input Discretes | Input Discretes | Input Discretes | Input Registers Low
Word Offset | 0 | 0 | 0 | 1 | 7
Bit Offset | 0 | 0 | 4 | 4 | 5


Modbus Driver Guide - Use Modbus RTU to Communicate via a Terminal Server (Configuration Examples)

Use Modbus RTU to Communicate via a Terminal Server

In this example, ClearSCADA is configured to use Modbus RTU (the Modbus serial protocol) to communicate with a Modbus Slave device that is connected serially to a terminal server.

The Modbus Slave device is connected to ClearSCADA via a remote serial port, rather than directly to the local ClearSCADA computer. The terminal server is connected to ClearSCADA via an Ethernet link.

Example:

A Modbus Scanner is to scan addresses 30001 to 30010 inclusive on a Slave device’s Input registers.

Within ClearSCADA, a Modbus Channel is configured as follows:

Primary Port Connection Type: TCP/IP

Within ClearSCADA, a Modbus Scanner is configured as follows:

On the Scanner tab of the Modbus Scanner Form:

Channel: Configured to reference the Modbus Channel indicated above

Device Address: Configured with the Modbus Slave’s address number

Data Address: 1 (the start of the scan block is 30000 + 1 = 30001)

Data Length: 9 (the end of the scan block is 30000 + 1 + 9 = 30010)

Location: Input Registers (the scanner scans registers in the 30000 address range)

On the Primary Port tab of the Modbus Scanner Form:

Connection Type: Network

Host Address: Configured with the IP address of the terminal server

Port: Configured with the identifier of the TCP port at the terminal server that is used for the Modbus serial communications port. (The Port number is not the serial communications port number.)

Communications Type: Modbus RTU (as the Modbus driver uses the Modbus serial protocol, but communicates initially via an Ethernet communications link). (If the driver was using direct Ethernet communications to talk to a Modbus PLC, the Communications Type would be configured as Modbus TCP.)

Modbus points are configured as required (see earlier in this section for Configuration Examples).


Modbus Driver Guide - Using Modbus Specific Pick Actions

Using Modbus Specific Pick Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section covers those actions that are specific to the Modbus driver (see Actions Associated with Modbus Channels).

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


Modbus Driver Guide - Actions Associated with Modbus Channels (Using Modbus Specific Pick Actions)

Actions Associated with Modbus Channels

Associated with: Modbus channels that can use either of two lines

Security permission required to access this pick action: Switch Line

If communications on one line fail, a Modbus channel automatically switches to use the other line. If communications on both lines fail, automatic switching ceases until communications recover. You can use the Switch Line pick action to force line switching to continue, or force the channel to use a particular line.

When you select the Switch Line pick action, the Switch Line window is displayed.

Use the combo box to select the required type of switching.

Choose from:

  • Toggle Line—This option forces the channel to use the other line to the one that it is presently using. In other words, if the channel is using the primary line, it switches to the secondary line, and vice versa.
  • Primary—The channel is to transmit data using its primary line. The primary line is the line that has been designated using the Primary Port tab on the Channel Form.
  • Secondary—The channel is to transmit data using its secondary line. The secondary line is the line that has been designated using the Secondary Port tab on the Channel Form.


Modbus Driver Guide - Modbus Specific Status Display Attributes

Modbus Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each Modbus Scanner provides information about the present state of the individual scanner.

This section covers those attributes that are Modbus driver-specific, and includes:

  • Modbus Channel Status Attributes
  • Modbus Scanner Attributes
  • Modbus Point Attributes
  • Alphabetical List of Modbus Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Modbus Driver Guide - Modbus Channel Status Attributes (Modbus Specific Status Display Attributes)

Modbus Channel Status Attributes

These status attributes are specific to Modbus channels:

  • Primary Assign
  • Secondary Assign
  • Source.

NOTE: Two further status attributes, Primary Eavesdrop Tx Assign, and Secondary Eavesdrop Tx Assign are not used by the Modbus driver.


Modbus Driver Guide - Modbus Scanner Attributes (Modbus Specific Status Display Attributes)

Modbus Scanner Attributes

These status attributes are specific to Modbus scanners:

  • Current Path
  • Source
  • Comms Statistics.


Modbus Driver Guide - Modbus Point Attributes (Modbus Specific Status Display Attributes)

Modbus Point Attributes

This status attribute is specific to Modbus points:

  • Source.


Modbus Driver Guide - Alphabetical List of Modbus Specific Status Display Attributes (Modbus Specific Status Display Attributes)

Alphabetical List of Modbus Specific Status Display Attributes

This section lists those status attributes that are specific to items on the Modbus driver. The attributes are listed in alphabetical order and comprise:

  • Comms Statistics
  • Current Path
  • Primary Assign
  • Secondary Assign
  • Source.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.


Modbus Driver Guide - Comms Statistics (Modbus Specific Status Display Attributes)

Comms Statistics

Associated with: Modbus scanners

This status attribute shows the number and type of errors that have been detected on a scanner since that scanner was last restarted:

  • Reads—Successful read operations
  • Writes—Successful write operations
  • Timeouts—Requests that did not receive a response within the expected time and therefore timed out. (The actual Timeout period is specified on the Channel Form.)
  • Exceptions—Exception errors returned by the remote device. Exceptions can be returned for various reasons. When an exception is received by the ClearSCADA Modbus driver, ClearSCADA sets the scanner to ‘Failed’. The alarm that is raised indicates the reason for the failure (see Modbus Exception Errors).
  • CRCs—Cyclic Redundancy Check (CRC) errors
  • Unknown—Any other errors.

Example:

45 reads, 23 writes, 0 timeouts, 2 exceptions, 0 CRCs, 0 unknown


Modbus Driver Guide - Current Path (Modbus Specific Status Display Attributes)

Current Path

Associated with: Modbus scanners

For network connected channels, this attribute displays the address of the PLC or Modbus device to which the scanner is connected.

For serial comms, this attribute displays the Serial Port.

Example:

10.1.5.30
for a network connected scanner communicating with a device that has an IP address of 10.1.5.30.


Modbus Driver Guide - Primary Assign (Modbus Specific Status Display Attributes)

Primary Assign

Associated with: Modbus channels

This attribute indicates whether the assignment of a channel to its primary line has failed. The line is that which is defined on the Primary tab of the Channel Form.

Possible States: Displays one of the Standard Alarm States.


Modbus Driver Guide - Secondary Assign (Modbus Specific Status Display Attributes)

Secondary Assign

Associated with: Modbus channels

This attribute indicates whether the assignment of a channel to its secondary line has failed. The line is that which is defined on the Secondary tab of the Channel Form.

Possible States: Displays one of the Standard Alarm States.


Modbus Driver Guide - Source (Modbus Specific Status Display Attributes)

Source

Associated with: Many Modbus-specific items

The Source attribute is common to many Status Displays. The attribute indicates the location at which the item, for example the point, resides.

The information shown varies, depending on the type of item.

The examples below assume that Modbus addressing starts at 1, rather than 0. (For examples and explanations as to how Modbus addressing is configured in ClearSCADA, see Configuration Examples.)

For scanners that are using TCP/IP communications, information is displayed in this format:

MODBUS/TCP-<Host Address> <Port>: Device <Address>, <Location> - <Location Digit>:<Address>
(For an address range, two location digits and addresses are shown.)

Example:

MODBUS/TCP-10.1.5.30 502:Device 5, Input Registers - 3:00003-3:00006
(For a scanner that has a Device Address of 5, and is used to retrieve data from the input registers at addresses 300003 to 300006. The scanner is using TCP/IP networked communications, to communicate with Host Address 10.1.5.30, via Port 502.)

For scanners that are using serial communications, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>-<Host Address> <Port>: Device <Address>, <Location> - <Location Digit>:<Address>
(For an address range, two location digits and addresses are shown.)

Example:

COM1:9600:8N1-8 502:Device 5, Output Coils - 0:00003-0:00006
(For a scanner that has a Device Address of 5, and is used to retrieve or send data to the output coils at addresses 00003 to 00006. The scanner communicates with Host Address 8, via Port 502, using a channel that has these properties: the channel communicates via port COM1 using a baud rate of 9600, with 8 data bits, no parity (N), and 1 stop bit.)

For points that are on scanners which are communicating using TCP/IP communications, information is displayed in this format:

MODBUS/TCP-<Host Address> <Port>: Device <Address>, <Location> - <Point Type> <Location Digit>:<ClearSCADA address> (<Data Type (for analog points only)>)
(For an address range, two location digits and addresses are shown.)

Example:

MODBUS/TCP-10.1.5.30 502:Device 5, Input Registers - AG 3:00010 (UINT)
(For an analog point that represents the unsigned 16-bit (UINT) data from input register address 30010. The device address and communications details are as per the scanner example, above.)

MODBUS/TCP-10.1.5.30 502:Device 5, Holding Registers - AG 4:00009-4:00010 (REAL)
(For an analog point that is used for passing IEEE floating point values (REAL) to the holding registers at addresses 400009 and 400010.The device address and communications details are as per the scanner example, above.)

For points that are on scanners which are communicating using serial communications, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>-<Host Address> <Port>: Device <Address>, <Location>:<Point Type> <Location Digit>:<ClearSCADA address> (<Data Type (for analog points only)>)
(For an address range, two location digits and addresses are shown.)

Example:

COM1:9600:8N1-8 502:Device 5, Output Coils - DG 0:00043
(For a digital point that represents output coil address 00043. The point is located on the Modbus scanner that has a Device Address of 5. The device address and communications details are as per the scanner example, above.)

The Source attribute displays the type of Modbus point using these abbreviations:
Abbreviation | Point Type
DG | Digital point
AG | Analog point


Modbus Driver Guide - Troubleshooting

Troubleshooting

Modbus channels use either Serial or Modbus TCP communications. In either case, if you have a Modbus scanner on your system that should be, but is not, healthy (online), use the charts within the Troubleshooting section in the ClearSCADA Guide to Simple Drivers to solve the problem (see Troubleshooting in the ClearSCADA Guide to Simple Drivers).

If a scanner uses Modbus TCP to communicate with the ClearSCADA server (with a Communications Type of either Modbus TCP or Modbus RTU), and performing the checks given in CHART 1 within that Troubleshooting section has not solved the problem, see CHART 2: Scanners Using Modbus TCP in this Guide.

NOTE: When troubleshooting on a ClearSCADA system, check the Events List for diagnostics messages. The messages may help you to identify the cause of any problems.

NOTE: To display scanner details in List format from the Queries Bar, filter the constraints on the Point Sources List.

For information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool, and the driver-specific documentation.


Modbus Driver Guide - CHART 2: Scanners Using Modbus TCP (Troubleshooting)

CHART 2: Scanners Using Modbus TCP

(For the chart from which this chart continues, see CHART 1: Basic Checks for Scanners that are in a Failed State in the ClearSCADA Guide to Simple Drivers.)

Further Information

Modbus Exception Errors.


Modbus Driver Guide - Modbus Exception Errors (Troubleshooting)

Modbus Exception Errors

A remote Modbus device might return an exception error for various reasons. Should an exception occur, ClearSCADA will set the affected Modbus scanner to ‘Failed’. The alarm that is raised will indicate the reason for the failure. With the Modbus driver, an exception might be generated if any of the following occur:

  • Illegal Function—Triggered if a function code is invalid or not supported by the remote device. Such an exception might also occur if the remote device is in the wrong state to process a function code.

For information on the function codes supported by ClearSCADA, see Modbus Function Codes Supported by the ClearSCADA Modbus Driver.

  • Illegal Data Address—Triggered if the address specified in the request is outside of the range supported by the remote device. Such an exception might occur, for instance, should a ‘Read Input Registers’ request be sent with a start register lower than the start range supported by the device, or should the request be for a larger number of registers than that supported by the device.

For more information on register ranges, see Modbus Register Ranges.

  • Illegal Data Value—Triggered if the remainder of a request is invalid.
  • Slave Device Failure—Triggered if there is a problem with the remote device.
  • Slave Device Busy—Triggered if the remote device cannot process the request at the time of receipt.
  • Memory Parity Error—Returned if supported by a function code, should a memory parity error occur.

A Modbus scanner’s Comms Statistics status attribute indicates if any exception errors have occurred since that scanner was last restarted.


Modbus SLAVE Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Modbus SLAVE Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Modbus SLAVE Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Modbus SLAVE Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Modbus SLAVE Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Modbus SLAVE Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s Modbus Slave driver. The Modbus Slave driver enables ClearSCADA to act as a Modbus PLC and report any data changes back to its Master, using the Modbus protocol.

For more details on the information included in this guide, see Introduction to the Modbus Slave Driver.

NOTE: For information on how to configure ClearSCADA to communicate with slave devices and PLCs using the Modbus protocol, see the ClearSCADA Guide to the Modbus Driver.


Modbus SLAVE Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring Modbus Slave items and features in the ClearSCADA database.

The guide also contains information for maintenance engineers.


Modbus SLAVE Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Modbus SLAVE Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


Modbus SLAVE Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Modbus SLAVE Driver Guide - Introduction to the Modbus Slave Driver

Introduction to the Modbus Slave Driver

The Modbus Slave Driver allows a ClearSCADA system to act as a Modbus PLC and report any data changes back to its Master. The Slave transmits any changes to its database, or sets values or states in its database, upon request from its Master.

The Slave can obtain its data directly from plant, from calculated values, or from any item in the ClearSCADA database. Its Master can be another ClearSCADA server, or a third party server that is using the Modbus protocol.

The Modbus Slave Driver provides extra functionality within a ClearSCADA server for transmitting data or controlling points. A Modbus Slave uses Value Maps for mapping point properties into memory, so that they can be accessed by the Modbus protocol.

The Modbus Slave documentation explains how to configure Modbus Slave-specific features and items within the ClearSCADA database—see, as applicable:

  • Configuring Modbus Slave Devices in ClearSCADA
  • Using Value Maps to Represent Modbus Data Address Ranges
  • Modbus Function Codes Supported by the ClearSCADA Modbus Slave Driver
  • Typical Scenarios.

It also explains driver-specific aspects that are of interest to system administrators and engineers when investigating unexpected system behavior (relating to the Modbus Slave driver):

  • Modbus Slave-Specific Status Display Attributes.

NOTE: There are no driver-specific pick actions for items on the Modbus Slave driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


Modbus SLAVE Driver Guide - Configuring Modbus Slave Devices in ClearSCADA (Introduction to the Modbus Slave Driver)

Configuring Modbus Slave Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the devices on your system. This section summarizes the database items that you need to configure to represent the Modbus Slave devices on your system.

To function as a Modbus Slave, the Modbus Slave Driver has to be installed and running on the ClearSCADA servers on your system. The Modbus Slave driver allows ClearSCADA to act as a Modbus PLC, and use the Modbus protocol to talk to a Modbus Master (for example, another server). The driver is represented by the Modbus RTU Slave component in the ClearSCADA Installation Wizard’s Setup window. The component is located within the Server branch of the tree that is displayed in the window (see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers).

When you configure Modbus Slave items in the ClearSCADA database, many of the properties for those items need to correspond to the properties of the relevant Modbus Master on your system. Some properties are either fixed (incorporated into the design of the Modbus Master), or are configured by an engineer. You need to have access to, or an understanding of, the properties of the Modbus Master on your system before you can configure the Modbus Slave database items successfully.

For instance, you need to know the type(s) of communications available for the Modbus channels on your system, and how those communications are structured or grouped.

You also need to be aware of which optional features are required for each Modbus Slave item. These features include:

  • Alarm views
  • Alarm redirections
  • User methods.

You can also use core ClearSCADA features with Modbus Slave database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each Modbus Slave device, you need to configure:

  1. Modbus Slave Channel(s) to represent the communication connections between the Slave and its Master (see Configuring a Modbus Slave Channel).
  2. Value Map(s) for mapping ‘point’ properties into memory so that they can be accessed by the Slave’s Master (see Using Value Maps to Represent Modbus Data Address Ranges, and see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).
  3. Modbus Slave Source(s) to specify which Value Maps—blocks of data—are to be scanned by a particular Master device (see Configure the Basic Source Properties). Configure a separate Source for each block of data that is to be scanned separately to other data, for example, by a different Master scanner.

To minimize the time that it takes to configure the required Modbus Slave items, you may want to configure them in the order listed above, as, for example, Source configuration requires you to specify a channel and the Value Maps that hold the Source’s ‘point’ data.


Modbus SLAVE Driver Guide - Using Value Maps to Represent Modbus Data Address Ranges (Introduction to the Modbus Slave Driver)

Using Value Maps to Represent Modbus Data Address Ranges

The Modbus Slave driver allows a ClearSCADA system to act as a Modbus PLC and report any data changes back to its Master. To facilitate this, the ClearSCADA server uses Value Maps to map ‘point’ properties into memory, so that they can be accessed by the Modbus protocol.

You need to configure a separate Value Map for each type of Modbus data—Input Register, Holding Register, Discrete, and Coil—that ClearSCADA is to map to memory. You then need to specify which type of Modbus data each Value Map represents, by assigning each Value Map as an Input Register, Holding Register, Discrete, or Coil Map, on the Modbus Slave Source Form (see Specify the Value Maps that Store the Source Data). This sets the addresses that are populated in each Value Map to appear as Modbus Register, Discrete, or Coil addresses to the Modbus Master.

The table below indicates which type of Value Map you need to configure to represent each type of Modbus data. It also indicates the Modbus address ranges that each Value Map might represent, once that Value Map has been assigned as representing a particular type of Modbus data. (Modbus addressing can start at 0 or 1—the table below indicates the Modbus equivalent for Modbus addressing that starts at 1.)
Modbus Slave Memory Allocation
Type of Data | Type of Value Map | Value Map Address Range | Equivalent Modbus Address Range
Input Register | WORD Value Map | 0 onwards | 300001 to 365536
Holding Register | WORD Value Map | 0 onwards | 400001 to 465536
Discrete | BIT Value Map | 0 onwards | 100001 to 165536
Coil | BIT Value Map | 0 onwards | 1 to 65536

Thus, to represent Modbus Holding Register 400010, you would populate address 9 of a WORD Value Map with the database item that represents that Holding Register. You would then specify the WORD Value Map as the Holding Register Map property on the Modbus Slave Source Form.

For a more detailed example of how you might use a Value Map to emulate Modbus data, see Example Configuration.


Modbus SLAVE Driver Guide - Modbus Function Codes Supported by the ClearSCADA Modbus Slave Driver (Introduction to the Modbus Slave Driver)

Modbus Function Codes Supported by the ClearSCADA Modbus Slave Driver

The ClearSCADA Modbus Slave Driver supports several Modbus function codes, enabling it to read and write data using the Modbus protocol. The function codes that the ClearSCADA Modbus Slave driver supports are:
Modbus Function Code | Functionality
FC1 | Read output coils
FC2 | Read input discretes
FC3 | Read multiple holding registers
FC4 | Read input registers
FC5 | Write coil
FC6 | Write single register
FC15 | Write multiple coils
FC16 | Write multiple registers


Modbus SLAVE Driver Guide - Typical Scenarios (Introduction to the Modbus Slave Driver)

Typical Scenarios

This sections gives some typical scenarios in which Modbus devices could be used within a ClearSCADA system. These scenarios are designed to act as a guide when you are configuring your own ClearSCADA system to communicate with Modbus devices—they are not designed to provide details of the many possible scenarios in which the Modbus protocol many be used.

Scenarios in which you would use a Modbus Slave driver include:

  • Third-Party Server with a Modbus Slave
  • Dual-Purpose Modbus Master/Modbus Slave.


Modbus SLAVE Driver Guide - Third-Party Server with a Modbus Slave (Introduction to the Modbus Slave Driver)

Third-Party Server with a Modbus Slave

Where a third-party server uses the Modbus protocol to retrieve data from ClearSCADA, the ClearSCADA system acts as a Slave PLC.

For this scenario, ClearSCADA needs to run the Modbus Slave driver, and you need to configure suitable Slave items in the ClearSCADA database (see Configuring Modbus Slave Devices in ClearSCADA).

The Modbus Slave indexes into the Value Maps to extract the value(s) that are requested by the third-party server.


Modbus SLAVE Driver Guide - Dual-Purpose Modbus Master/Modbus Slave (Introduction to the Modbus Slave Driver)

Dual-Purpose Modbus Master/Modbus Slave

Where a third-party server uses the Modbus protocol to obtain data from ClearSCADA, and ClearSCADA uses the Modbus protocol to obtain its data from a PLC, ClearSCADA becomes dual-purpose, with regard to Modbus functionality. When communicating with the third-party server, ClearSCADA acts as a Modbus Slave, and when communicating with the PLC, ClearSCADA acts as a Modbus Master.

In this scenario, you need to configure both a Modbus Slave and a Modbus Master configuration suite. You also need to check that ClearSCADA is running both the Modbus Slave driver and the Modbus driver.

To configure ClearSCADA so that it can communicate as a Slave, see Configuring Modbus Slave Devices in ClearSCADA.

To configure ClearSCADA so that it can communicate as a Master, see the ClearSCADA Guide to the Modbus Driver.


Modbus SLAVE Driver Guide - Configuring a Modbus Slave Channel

Configuring a Modbus Slave Channel

Modbus Slave channels are used to provide ClearSCADA with additional connection information. They allow the ClearSCADA server to use the Modbus protocol to communicate with its Master.

Specify the features for each Slave channel by using the fields on the Modbus Slave Channel Form.

The Modbus Slave Channel Form has several tabs.

This section shows the default properties on the Channel tab (see Channel Properties). It also explains the options that are available on the Connection tab of the Form (see Connection Properties).

For information on common fields, and the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Modbus SLAVE Driver Guide - Channel Properties (Configuring a Modbus Slave Channel)

Channel Properties

Use the fields on the Channel tab to define the general properties for a Modbus Slave channel:

The fields on this tab are common to channels on many simple drivers. For further information, see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers.


Modbus SLAVE Driver Guide - Connection Properties (Configuring a Modbus Slave Channel)

Connection Properties

Use the Connection Type field on a Modbus Slave Channel’s Connection tab to specify the type of channel connection that is to be used.

Modbus Slave channels are able to communicate using either Serial or TCP/IP connection, depending on your system setup.

For information on configuring a Serial connection, see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers.

For information on configuring a TCP/IP connection, see Configure a Modbus Slave Channel’s TCP/IP Connection Properties.


Modbus SLAVE Driver Guide - Configure a Modbus Slave Channel's TCP/IP Connection Properties (Configuring a Modbus Slave Channel)

Configure a Modbus Slave Channel’s TCP/IP Connection Properties

For a Modbus Slave channel to communicate using Modbus Transmission Control Protocol (TCP), set the channel’s Connection Type to TCP/IP.

Use the rest of the fields on the Connection tab to define the required connection properties:

  • Port—The TCP port on which the Modbus Slave channel accepts connections. Modbus Slave channels communicate via port 502.
  • Idle Connection Timeout—Use to specify the maximum time that an idle connection is kept open. The connection is dropped once the timeout is exceeded. Specify the required timeout in the OPC Time Format.

Leave at the default of zero if no timeout is required.


Modbus SLAVE Driver Guide - Configuring a Modbus Slave Source

Configuring a Modbus Slave Source

The Modbus Slave driver uses Source database items to represent groups of data. For example, a Source item can represent a block of registers that are scanned by a particular Master.

The configuration of each Source defines the location of the data that is:

  • Reported by the Slave to its Master
  • Updated by the Slave following a request from its Master.

You can configure one Source per device per Slave channel.

Before configuring a Modbus Slave Source in ClearSCADA, you need to undertake the necessary Preparation.

Configure each Source by using the fields on the Modbus Slave Source Form.

The Modbus Slave Source Form has several tabs. This section explains the fields on the Source tab.

Use the fields on the Source tab to:

  • Specify the Slave channel through which data is transmitted (see Configure the Basic Source Properties)
  • Specify the Value Maps that Store the Source Data.

For information on the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Modbus SLAVE Driver Guide - Preparation (Configuring a Modbus Slave Source)

Preparation

Before you can successfully configure a Modbus Slave Source, you will need to have configured:

  • The Slave channel that is being used to transmit the Modbus data (see Configuring a Modbus Slave Channel)
  • The Value Maps that define where the data is located (see Using Value Maps to Represent Modbus Data Address Ranges in this guide, and see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).


Modbus SLAVE Driver Guide - Configure the Basic Source Properties (Configuring a Modbus Slave Source)

Configure the Basic Source Properties

Use the fields at the top of the Source tab to specify whether the source is functional, the channel that is used to transmit the source data, and the address of the device that is to scan this source for Modbus data:

  • In Service—Use to specify whether the source is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Channel—Use to define the channel that is to transmit data changes from, and request local controls at, this source. Use the browse button to display a Reference Browse window. Select the required Modbus Slave channel from the window.
  • Address—Specify the address of the Master. This is the device that is to scan the source for data, and to which the source will respond. Enter the required address, in the range 0 to 255.

You can configure one Source per device address per channel.


Modbus SLAVE Driver Guide - Specify the Value Maps that Store the Source Data (Configuring a Modbus Slave Source)

Specify the Value Maps that Store the Source Data

Modbus Slaves use Value Maps to store ‘point’ data. Each Source within a Slave can store data using a different set of Value Maps.

The Value Maps that are required for the Slave need to have been created and suitably configured on your system (see Using Value Maps to Represent Modbus Data Address Ranges in this guide, and see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).

Use these Map fields on the Source tab to define the Value Maps that are used by a particular Source:

  • Input Register Map—Specify the Value Map that is used to store calculated 16-bit input values. Use the browse button to display a Reference browse window, and select the required WORD Value Map from the window.
  • Holding Register Map—Specify the Value Map that is used to store calculated 16-bit output values. Use the browse button to display a Reference browse window, and select the required WORD Value Map from the window.
  • Discrete Map—Specify the Value Map that is used to store discrete single-bit input values. Use the browse button to display a Reference browse window, and select the required BIT Value Map from the window.
  • Coil Map—Specify the Value Map that is used to store discrete single-bit output values. Use the browse button to display a Reference browse window, and select the required BIT Value Map from the window.

Leave the fields blank for any Map types that are not used by this Source.

Each field and associated Value Map represents a different type of data within a Modbus PLC. For instance, if a Value Map is specified in the Input Register Map field, above, the entries that populate the Value Map would emulate Input Register data in a Modbus PLC. For more information, see Using Value Maps to Represent Modbus Data Address Ranges.

For an example of how you might use a Value Map to represent Modbus data and how you might map that data to a Modbus Slave Source, see Example Configuration.


Modbus SLAVE Driver Guide - Example Configuration

Example Configuration

This example shows how ClearSCADA might be configured to act as a Modbus PLC, in order to report its data to a Modbus Master, using the Modbus protocol.

Example:

A ClearSCADA system is to emulate a Modbus PLC. The Modbus addressing starts at 1 (ClearSCADA addressing starts at zero.) The ClearSCADA database is to be configured so that ClearSCADA can transmit data for the following items to its Modbus Master:

  • Input Registers 300001 and 300006
  • Coils 5 and 9.

Within ClearSCADA, a Modbus Slave Channel is suitably configured to transmit data to the Modbus Master.

A Modbus Slave Source is configured to emulate a Modbus PLC and to use the above channel. In this particular example, the Source is assigned the Modbus address 19.

In a Modbus PLC, Input Register data is allocated in Words. Within ClearSCADA, a WORD Value Map is configured to emulate the Input Register memory area. As ClearSCADA is to transmit data for Input Registers 300001 and 300006, addresses 0 and 5 of the WORD Value Map are populated with the database items that represent those Input Registers. (WORD Value Map address 0 is the equivalent of Modbus address 1, and WORD Value Map address 5 is the equivalent of Modbus address 6.)

The database items that will appear as Modbus PLC Input Registers to the Modbus Master, are attached to a WORD Value Map. They populate the WORD Value Map addresses that are the equivalent of Modbus PLC addresses 00001 and 00006.

In order for the WORD Value Map to represent Input Register data, the Value Map (named ‘PLC 19 Input Registers’) is specified as the Input Register Map property on the Modbus Slave Source Form.

This sets ClearSCADA to transmit the WORD Value Map data as Input Register data. It also means that the entries that populate the WORD Value Map emulate Modbus PLC addresses 300001 and 300006.

In a Modbus PLC, Coil data is allocated in Bits.

Within ClearSCADA, a BIT Value Map is configured to emulate the Coil memory area. As ClearSCADA is to transmit data for Coils 5 and 9, addresses 4 and 8 of the BIT Value Map are populated with the database items that represent those Coils.(Where Modbus addressing starts at 1, BIT Value Map address 4 represents Modbus address 5, and BIT Value Map address 8 represents Modbus address 9.)

The database items that will appear as Modbus PLC Coils to the Modbus Master, are attached to a BIT Value Map. They populate the BIT Value Map addresses that are the equivalent of Modbus PLC addresses 00005 and 00009.

In order for the BIT Value Map to represent Coil data, the Value Map (named ‘PLC 19 Coils’) is specified at the Coil Map property on the Modbus Slave Source Form.

This sets ClearSCADA to transmit the BIT Value Map data as Coil data, and means that the entries that populate the BIT Value Map emulate Modbus PLC addresses 5 and 9.

Further Information

Configuring a Modbus Slave Channel.

Configuring a Modbus Slave Source.

Using Value Maps to Represent Modbus Data Address Ranges.

Configuring BIT Value Maps and WORD Value Maps: see Configuring Value Maps in the ClearSCADA Guide to Core Configuration.


Modbus SLAVE Driver Guide - Modbus Slave-Specific Status Display Attributes

Modbus Slave-Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each Modbus Slave Channel provides information about the present state of the individual channel.

This section covers those attributes that are Modbus Slave driver-specific, and includes:

  • Modbus Slave Channel Status Attributes
  • Modbus Slave Source Attributes
  • Alphabetical List of Modbus Slave-Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Modbus SLAVE Driver Guide - Modbus Slave Channel Status Attributes (Modbus Slave-Specific Status Display Attributes)

Modbus Slave Channel Status Attributes

These status attributes are specific to Modbus Slave channels:

  • Primary Assign
  • Source.

NOTE: Three further status attributes, Primary Eavesdrop Tx Assign, Secondary Assign, and Secondary Eavesdrop Tx Assign are not used by the Modbus Slave driver.


Modbus SLAVE Driver Guide - Modbus Slave Source Attributes (Modbus Slave-Specific Status Display Attributes)

Modbus Slave Source Attributes

This status attribute is specific to Modbus Slave sources:

  • Source.


Modbus SLAVE Driver Guide - Alphabetical List of Modbus Slave-Specific Status Display Attributes (Modbus Slave-Specific Status Display Attributes)

Alphabetical List of Modbus Slave-Specific Status Display Attributes

This section lists those status attributes that are specific to items on the Modbus Slave driver. The attributes are listed in alphabetical order and comprise:

  • Primary Assign
  • Source.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.


Modbus SLAVE Driver Guide - Primary Assign (Modbus Slave-Specific Status Display Attributes)

Primary Assign

Associated with: Modbus Slave Channels

This attribute indicates whether the assignment of a Slave channel to its primary line has failed. The line is defined on the Connection tab of the Channel Form.

Possible States: Displays one of the Standard Alarm States.


Modbus SLAVE Driver Guide - Source (Modbus Slave-Specific Status Display Attributes)

Source

Associated with: Modbus Slave Channels and Modbus Slave Sources

The Source attribute is common to many Status Displays. The attribute indicates the location at which the item, for example the source, resides.

The information shown varies, depending on the type of item.

For Slave channels that are using Serial communications, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>

Example:

COM1:9600:8N1
(For a Slave channel communicating via port COM1, using a baud rate of 9600, with 8 data bits, no parity (N), and 1 stop bit.)

For Slave channels that are using TCP/IP communications, the source attribute displays TCP.

For a Modbus Slave Source, communicating on a channel that is using Serial communications, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits>:Device <Device Address>

Example:

COM1:9600:8N1:Device 2
(For a source scanning a device that has an address of 2. The source communicates with the device using a channel on port COM1. The channel uses a baud rate of 9600, with 8 data bits, no parity (N), and 1 stop bit.)

For a Modbus Slave Source, communicating on a channel that is using TCP communications, information is displayed in this format:

TCP:Device <Device Address>

Example:

TCP:Device 3
(For a source scanning a device that has an address of 3.)


NTP Monitor Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


NTP Monitor Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


NTP Monitor Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


NTP Monitor Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


NTP Monitor Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


NTP Monitor Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure ClearSCADA’s NTP Driver to monitor a Network Time Protocol (NTP) server. It also provides information on NTP stratum ranking and the NTP driver’s diagnostic features.

For more information about the subjects covered in this Guide, see Introduction to the NTP Monitor Driver.


NTP Monitor Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by engineers who are responsible for configuring NTP-related settings. It can also be used by system administrators who can use the NTP driver’s diagnostic features for fault finding.


NTP Monitor Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems] in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements] in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


NTP Monitor Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


NTP Monitor Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


NTP Monitor Driver Guide - Introduction to the NTP Monitor Driver

Introduction to the NTP Monitor Driver

The Network Time Protocol (NTP) is an Internet protocol that is used for synchronizing the system clocks on computer systems. The ClearSCADA NTP Monitor Driver monitors the accuracy of such synchronization.

We recommend that you run NTP, or an equivalent time synchronization mechanism, on your ClearSCADA system. This will synchronize the system clocks of the computers on your system.

If required, on systems that are running NTP, you can also run the ClearSCADA NTP Monitor Driver and configure NTP Monitor items in the database to enable you to assess the accuracy with which those system clocks are being synchronized.

This Guide to the NTP Monitor Driver explains:

  • How to configure NTP Monitor-specific features and items in the ClearSCADA database (see Configuring NTP Monitor Devices in ClearSCADA).
  • The stratum ranking that affects the accuracy with which system clocks are synchronized (see Understanding NTP Stratum Ranking and how this Affects Clock Accuracy).
  • NTP Monitor-specific aspects that may be of interest to system administrators and engineers when investigating unexpected system behavior (see NTP Monitor Specific Status Display Attributes).

NOTE: There are no driver-specific pick actions for items on the NTP Monitor driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

NOTE: On the Modules tab of the ClearSCADA Server Status Tool, this particular driver is listed as the NTP driver. The logging options that are available to the driver are common to many simple drivers—for information, see Driver Log File Options that are Common to Many Simple Drivers in the ClearSCADA Guide to Simple Drivers.

For information on running NTP (as oppose to the NTP Monitor driver) and on synchronizing system clocks using NTP, see the NTP web site (http://www.ntp.org).


NTP Monitor Driver Guide - Understanding NTP Stratum Ranking and how this Affects Clock Accuracy (Introduction to the NTP Monitor Driver)

Understanding NTP Stratum Ranking and how this Affects Clock Accuracy

The NTP protocol uses strata to indicate the expected accuracy of system clocks. The device that has the most accuracy is the ‘reference’ clock—the clock with which the other devices on the system, such as workstations and servers, synchronize their time.

A machine’s time can be synchronized directly with the ‘reference’ clock, or via another machine (an ‘NTP Server’) which either synchronizes its own clock directly with the ‘reference’ clock, or with the clock of another NTP server. Each level of synchronization is assigned a different stratum number. The lower the stratum number or level, the higher the accuracy of the system clock(s) at that level. Additionally, each clock’s accuracy is also affected by the stability of the ‘reference’ clock itself, and the particular network path(s) that are used for the NTP time synchronization.

In summary:

  • Stratum 0 refers to the ‘reference’ clock itself—typically an atomic clock, GPS clock, or radio clock.
  • Stratum 1 refers to any machine that synchronizes its system clock directly with the ‘reference’ clock that resides at Stratum 0. For example, a server that has a GPS unit plugged into one of its serial ports.
  • Stratum 2 refers to any machine that synchronizes its system clock with the clock on a Stratum 1 server.
  • Stratum 3 refers to any machine that synchronizes its system clock with the clock on a Stratum 2 server, and so on.

The furthest possible level is Stratum 16. A machine at this level is deemed to not have a synchronized time source.

A machine that has just started up will initially be at Stratum 16, until it synchronizes its clock with an NTP server (or directly with the ‘reference’ clock). Once synchronized, its stratum will update to indicate its new level. (Should synchronization be unsuccessful, the machine will remain at Stratum 16.)

With machines that are configured to synchronize their system clocks via one of several NTP time sources, the stratum level can vary, depending which source is used. Such machines synchronize with whichever NTP time source has the lower Stratum level (and therefore the highest time accuracy). If both time sources are at the same Stratum level, the machine will synchronize its clock with whichever NTP device it is able to communicate with first.

Be aware that whenever a machine synchronizes its time and that synchronization causes its clock to update its time by a significant amount, that machine will indicate Stratum 16 and attempt to further re-synchronize its time. On ClearSCADA systems on which the NTP Monitor driver is being used to monitor a machine’s stratum and a stratum of 16 is configured to raise an alarm, such a situation will result in ‘false positives’—an alarm will be raised due to the machine synchronizing its clock successfully if, in doing so, that synchronization causes the clock’s time to change significantly.


NTP Monitor Driver Guide - Configuring NTP Monitor Devices in ClearSCADA (Introduction to the NTP Monitor Driver)

Configuring NTP Monitor Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, measuring instruments, and control devices on your system. This section summarizes the database items that you need to configure to represent the NTP Monitor devices on your system.

To represent any NTP Monitor devices, the NTP Monitor Driver has to be installed and running on the ClearSCADA servers on your system. (As with most other ClearSCADA drivers, the NTP Monitor Driver requires a valid license in order to run on ClearSCADA.)

To configure NTP Monitor items successfully in the ClearSCADA database, you need to be aware of the NTP devices that are running on your system. For instance, you need to know the location of each NTP server on your system, and the NTP ‘tag’ that each point is to monitor on those server(s).

You also need to be aware of which optional features are required for each NTP Monitor item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with NTP Monitor database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each NTP Monitor device, you need to configure:

  1. NTP Monitor Scanner(s) to specify which NTP server(s) are to be scanned and the rates at which NTP data is to be retrieved (see Configuring an NTP Monitor Scanner).

If required, you can assign more than one scanner to each NTP server.

  2. NTP Monitor Points to represent the items of NTP data that you want ClearSCADA to monitor (see Points Used on NTP Monitor Scanners).

To minimize the time that it takes to configure the required NTP Monitor items, you may want to configure them in the order listed above, as point configuration requires you to specify a scanner.


NTP Monitor Driver Guide - Configuring an NTP Monitor Scanner

Configuring an NTP Monitor Scanner

An NTP Monitor Scanner is logical functionality that runs within ClearSCADA and scans for NTP data on an NTP Server. An NTP server might be the ‘reference’ clock itself, or a machine that synchronizes its own clock with the ‘reference’ clock (see Understanding NTP Stratum Ranking and how this Affects Clock Accuracy).

Configure the NTP Monitor Scanner properties using the fields on the NTP Monitor Scanner Form.

The Form has several tabs. This section covers fields on the Scanner tab that are specific to the NTP Monitor driver (see Configure the Scanner Properties).

For fields on the other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


NTP Monitor Driver Guide - Configure the Scanner Properties (Configuring an NTP Monitor Scanner)

Configure the Scanner Properties

Use the fields on the Scanner tab of the NTP Monitor Scanner Form to define the general and NTP-specific properties of a scanner.

Many of the fields on this tab are common to scanners on many drivers (see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the NTP Monitor driver are described below.

  • NTP Server—Use to specify the name or IP address of the NTP server that this scanner is to monitor.

Select the browse button to display a Reference browse window, and then select the required entry from the window.

  • Timeout—Use to specify the maximum amount of time that the scanner should wait for the NTP server to reply to a poll. Should this time be exceeded, the scanner will attempt to resend the message up to the number of times that is specified in the Retries field (see below).

Enter the timeout in the OPC Time Format, for example 0.1S for 100 milliseconds.

  • Retries—Specify the number of times that the scanner should attempt to resend a message to the server, should the server not respond to the scanner’s initial message.

If the NTP server does not respond to the final attempt to send the message, ClearSCADA will deem that the scanner has failed. (The Scanner will then try to re-establish communications with the NTP Server at the specified Scan Rate.)


NTP Monitor Driver Guide - Points Used on NTP Monitor Scanners

Points Used on NTP Monitor Scanners

For each item of NTP data that you want ClearSCADA to monitor, you need to configure one point of the appropriate type in the ClearSCADA database. NTP Monitor Scanners support these NTP Monitor point types:

  • Analog Point
  • Digital Point
  • String Point
  • Time Point.

You configure each point that you require using the appropriate NTP Monitor Point Form (for example, the NTP Monitor Analog Point Form).

Each Form has several tabs.

Use the fields on the NTP Monitor tab to Configure the NTP Monitor Point Properties.

Use the fields on the <Point Type> tab (for example, the Digital Point tab) to configure the point states or limits, trend and format properties, and so on. The fields on the <Point Type> tab are common to points on many drivers—see the appropriate section in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


NTP Monitor Driver Guide - Configure the NTP Monitor Point Properties (Points Used on NTP Monitor Scanners)

Configure the NTP Monitor Point Properties

Use the fields on the NTP Monitor tab of each NTP Monitor <Point Type> Form to configure these properties:

  • In Service—Use to specify whether the point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration]).

  • Scanner—Use to specify the NTP Monitor Scanner with which the point is associated. Select the browse button to display a Reference browse window, and select the required scanner from the window.
  • Tag—Within NTP terminology, ‘point’ values on NTP servers are referred to as tags. Use the Tag field to specify the item of data that this point is to monitor on the NTP server.

Select the browse button to display a Reference browse window. Select the required NTP tag from the window.

  • Update Value on Every Scan—Use this check box to specify whether the scanner is to update the value of this point within ClearSCADA every time the point’s source is scanned, regardless of whether the value has changed.

Select the check box if the value of the point is to be updated whenever its source is scanned. Ensure the check box is selected if, for instance, the point’s value is to trigger Logic program(s) whenever a scan occurs, or if the point value rarely changes and you want to ensure that ClearSCADA is using a recently retrieved value.

Ensure that the check box is clear if the value of the point is only to be updated within ClearSCADA if its value has changed from the last recorded value. A point that is associated with an attribute that regularly changes, for instance, need only be updated if such a change has occurred.

The NTP Monitor tab on the NTP Monitor Analog Point Form also includes this field:

  • Multiplier—Use this field to specify what calculation the driver is to perform on the raw analog value, for use within ClearSCADA. The driver multiplies the raw value by this multiplier before passing the value to ClearSCADA.

Leave at the default of 1 if the raw value is to be used in ClearSCADA without further calculation.


NTP Monitor Driver Guide - Configuring Analog Points

Configuring Analog Points

NTP Monitor Scanners support analog input points.

You need to configure one analog point in the ClearSCADA database for each point that monitors analog-type data on an NTP device.

You might, for instance, use an analog point to monitor an NTP server’s stratum (see Understanding NTP Stratum Ranking and how this Affects Clock Accuracy). (To monitor the stratum, you would configure the point to retrieve the device’s System.stratum tag.)

Configure an analog point’s properties using the fields on the NTP Monitor Analog Point Form.

The Form has several tabs.

The fields on the Analog Point tab are common to analog points on many drivers (see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration).

Use the fields on the NTP Monitor tab to Configure the NTP Monitor Point Properties.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


NTP Monitor Driver Guide - Configuring Digital Points

Configuring Digital Points

NTP Monitor Scanners support digital input points.

You need to configure one digital point in the ClearSCADA database for each point that monitors digital-type data on an NTP device.

Configure the digital point’s properties using the fields on the NTP Monitor Digital Point Form.

The Form has several tabs.

The fields on the Digital Point tab are common to digital points on many drivers (see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration).

Use the fields on the NTP Monitor tab to Configure the NTP Monitor Point Properties.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


NTP Monitor Driver Guide - Configuring String Points

Configuring String Points

NTP Monitor Scanners support string points.

You need to configure one string point in the ClearSCADA database for each point that monitors string-type data on an NTP device.

You might, for instance, use a string point to:

  • Retrieve the version of NTP that is running on an NTP server (by monitoring its System.version tag)
  • Identify the server or reference clock with which the machine is synchronizing (by monitoring the System.refid tag).

Configure a string point’s properties using the fields on the NTP Monitor String Point Form.

The Form has several tabs.

The fields on the String Point tab are common to string points on several drivers (see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration).

Use the fields on the NTP Monitor tab to Configure the NTP Monitor Point Properties.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


NTP Monitor Driver Guide - Configuring Time Points

Configuring Time Points

NTP Monitor Scanners support time points.

You need to configure one time point in the ClearSCADA database for each point that monitors time data on an NTP device.

You might, for instance, use a time point to display the NTP device’s present time (by monitoring that device’s System.clock tag).

Configure a time point’s properties using the fields on the NTP Monitor Time Point Form.

The Form has several tabs.

The fields on the Time Point tab are common to time points on several drivers (see Defining Time Point Details in the ClearSCADA Guide to Core Point Configuration).

Use the fields on the NTP Monitor tab to Configure the NTP Monitor Point Properties.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


NTP Monitor Driver Guide - NTP Monitor Specific Status Display Attributes

NTP Monitor Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each NTP Monitor Scanner provides information about the present state of the individual scanner.

Many of the attributes on NTP Monitor Status displays are common to many drivers, however the information displayed by the Source attribute differs, depending on the driver and the type of item with which the attribute is associated.

This section describes the Source attribute information that is displayed for items on the NTP Monitor driver (see Source).

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Items on Many Drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


NTP Monitor Driver Guide - Source (NTP Monitor Specific Status Display Attributes)

Source

Associated with: NTP Monitor scanners and points

The Source attribute is common to many Status displays. The attribute indicates the location at which the item resides. The information shown varies depending on the type of item.

For NTP Monitor Scanners, information is displayed in this format:

Node <NTP Server>

Example:

Node SVR1
(Indicating that the NTP device that an NTP Monitor Scanner is monitoring is the node (workstation) SVR1.)

For NTP Monitor Points, information is displayed in this format:

Node <NTP Server>:<Tag>

Example:

Node SVR1:System.stratum
(For an NTP Monitor analog point that is monitoring the stratum level of node (workstation) SVR1.)


ODBC Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


ODBC Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


ODBC Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


ODBC Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


ODBC Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


ODBC Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to use the ClearSCADA ODBC driver so that point data can be transferred from another database into the ClearSCADA database. It includes information on configuring ODBC-specific features and items, using ODBC-specific actions, and using ODBC-specific status information for diagnostics.

For more details on the subjects covered in this guide, see Introduction to the ODBC Driver.


ODBC Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for all levels of user:

  • Engineers who are responsible for configuring ODBC-specific features and items
  • Operators who use ODBC-specific actions while performing their duties
  • System administrators who use ODBC-specific status information when fault-finding unexpected behavior relating to the ODBC driver.


ODBC Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


ODBC Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Security

ClearSCADA Guide to the Database.


ODBC Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


ODBC Driver Guide - Introduction to the ODBC Driver

Introduction to the ODBC Driver

This guide explains features that are specific to the ClearSCADA ODBC Driver. This driver has been produced by Schneider Electric to run on the servers on a ClearSCADA system, and should not be confused with the WindowsTM ODBC driver that is often supplied with WindowsTM software. In this guide, the ClearSCADA ODBC driver is generally referred to as the ODBC driver.

The ClearSCADA ODBC Driver allows point data to be transferred from another database into the ClearSCADA database, using Open DataBase Connectivity (ODBC) data transfer standards (see Using ODBC to Access the ClearSCADA Database). The driver performs the necessary conversions to enable the data to be transferred between the source and destination databases. This is dependent on:

  • ClearSCADA running the ClearSCADA ODBC Driver
  • The other application and its database management system being ODBC-compliant
  • The other application and its database management system running their own WindowsTM ODBC driver.

ODBC can be used to transfer data between a ClearSCADA database and, for example, Oracle, Access, Excel, dBase or an SQL server.

In ClearSCADA, you can write an ODBC Query using SQL that allows a block of data to be located and retrieved from the other application’s database. As with other ODBC drivers, ClearSCADA’s ODBC driver converts that query into a request that can be recognized by the other application’s database management system. The other application can then perform the requested data transfer.

You use OBDC points in ClearSCADA to extract data from the data table that is produced as a result of the ODBC query request.

Given the required Write access privileges, you can also replace or insert an individual value within another application’s database, by sending a point control to that application. Within ClearSCADA, you enter the SQL Query code that defines the location of the data in the other application’s database and the specifies the data that is to be replaced or inserted. The actual value that is to be sent to the other application’s database, is specified when the control is requested.

The ODBC documentation explains how to configure ODBC-specific features and items in the ClearSCADA database (see Configuration Order). It also explains the driver-specific features that are of interest to operators, such as:

  • Using ODBC Specific Actions

and driver-specific aspects that may be of interest to system administrators and engineers when investigating unexpected system behavior:

  • ODBC Specific Status Display Attributes.

Use the documentation along with the ClearSCADA Guide to Simple Drivers and the core documentation when configuring ODBC features on your system.

NOTE: For other applications to access the ClearSCADA database using ODBC, the appropriate Data Access components have to be installed as part of the ClearSCADA installation process. For more information, see Third Party ODBC Client - System Connections in the ClearSCADA Guide to Client Administration.

For information on exporting Crystal Reports in ODBC format, see the ClearSCADA Crystal Reports documentation.


ODBC Driver Guide - Configuration Order (Introduction to the ODBC Driver)

Configuration Order

To transfer data from another database into the ClearSCADA database (using ODBC data transfer standards), the ODBC Driver has to be installed and running on the ClearSCADA servers on your system. The driver is represented by the ODBC Client component in the ClearSCADA Installation Wizard’s Setup window. The component is located within the Server branch of the tree that is displayed in the window (see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers).

When you configure the ODBC items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant database. You need to have access to, or an understanding of, the relevant settings before you can configure the ODBC database items successfully. For instance, you need to know the DSN for the database from which ClearSCADA is to retrieve data, and any user name and password needed to allow the required access to that database.

You also need to be aware of which optional features are required for each ODBC item. These include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with ODBC items, including Lists, Actions, and Mimics. For actions that are specific to the ODBC driver, see Using ODBC Specific Actions. For further information on actions and details on Lists and Mimics, see the core documentation.

NOTE: Before you can successfully transfer data to or from another database using ODBC data transfer standards, you need to check that a suitable System Data Source Name (DSN) exists for that database. For further information, refer to your WindowsTM documentation.

For each application with which you want ClearSCADA to extract or transfer point data, you need to configure:

  1. An ODBC Connection to specify the System Data Source Name (DSN) for that application (see Configuring an ODBC Connection).

The System DSN stores information about how to connect to that data provider.

  2. An ODBC Query for each different data transfer request to that application (see Configuring an ODBC Query).

You can associate more than one Query with each ODBC Connection.

  3. An appropriate ODBC Point (Analog, Digital, or String) for each separate item of data that is to be extracted following the data transfer process (see Points Used for ODBC Data Transfer).

You can associate multiple points with each ODBC Query.


ODBC Driver Guide - Using ODBC to Access the ClearSCADA Database (Introduction to the ODBC Driver)

Using ODBC to Access the ClearSCADA Database

A system only needs to run the ClearSCADA ODBC driver in order for ClearSCADA to transfer data to and from another database, using ODBC.

It is also possible for other applications to use ODBC to access the ClearSCADA database. This section summarizes the requirements that enable other applications to access the ClearSCADA database in this way.

In order for other applications to access the ClearSCADA database using ODBC, you need only install the appropriate Data Access components of ClearSCADA on the client computer (the computer that is running the application that is to access ClearSCADA using ODBC). (If the client computer is to run as a full ClearSCADA client, as well as run the other applications that are to access ClearSCADA using ODBC, you also need to install the appropriate ClearSCADA Client components.)

Where applications do not have a separate user account, access is via ClearSCADA’s Guest User account (see Configuring the Guest and Web User Accounts in the ClearSCADA Guide to Security).

The ODBC data access interface can be used to access Historic Pseudo tables within ClearSCADA. For information on the fields that these tables contain, see the database Schema. For information on the database Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database. You can also use ODBC to access the data in 'custom' tables, such as Data Grids. For information on using Data Grids, see Configuring Data Grids in the ClearSCADA Guide to Core Configuration.

You can enable logging to monitor any unexpected system behavior when ODBC is used to access to the ClearSCADA database. For more information, see ODBC Logging in the ClearSCADA Guide to Client Administration.

NOTE: For information on the SQL Queries that have been used to request data from ClearSCADA, view the various Queries categories in the ClearSCADA Server Status Tool’s Query Processor folder (see Server Status Categories in the ClearSCADA Guide to the Server Status Tool).


ODBC Driver Guide - Configuring an ODBC Connection

Configuring an ODBC Connection

ClearSCADA can use ODBC data transfer standards to transfer data to other applications. But for ClearSCADA to be able to do this, you need to create and configure an ODBC Connection for each application.

Before configuring an ODBC Connection, you need to check that any necessary Preparation has been completed. You can then create ODBC Connection database items and use the ODBC Connection Form to configure them appropriately. (The Form has several tabs, each containing various settings.)

This section explains the fields on the Connection tab of the Form (see Configure the Connection Properties).

For information on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For aspects of connection configuration that are common to many types of database item, see the ClearSCADA Guide to Core Configuration.

For information on the minimal amount of configuration that you can undertake to produce a functional ODBC Connection, see Minimum Configuration.


ODBC Driver Guide - Preparation (Configuring an ODBC Connection)

Preparation

To configure an ODBC Connection, you need to know the System Data Source Name (DSN) for the other system’s server, along with the user name and password that allows the required access to the data on that server. For further information, refer to your WindowsTM documentation.

You also need to establish which features are required for each ODBC connection. You can configure each connection to use a variety of features, including alarm redirection. However, many of these features are optional and do not affect the success of communications. The optional features include:

  • Alarm View
  • Alarm Redirection
  • User Methods.

If the features listed above are not configured, they are not used for the selected connection (they will be left blank).


ODBC Driver Guide - Minimum Configuration (Configuring an ODBC Connection)

Minimum Configuration

For an ODBC Connection to become functional (online), you need to:

  • Specify the Data Source Name (DSN) for the server from which ClearSCADA is to retrieve data
  • If access to the DSN is password protected, specify a suitable user name and password to enable a connection.

You also need to put the connection In Service and save the configuration.

These are the minimum requirements and, when defined, will result in a functional connection that uses the default configuration settings.


ODBC Driver Guide - Configure the Connection Properties (Configuring an ODBC Connection)

Configure the Connection Properties

Use the fields on the Connection tab to define the access properties of the connection to the other application’s database.

  • In Service—Use to specify whether the ODBC connection is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

NOTE: If you later take the connection out of service, its Queries and their dependants (points) also become out of service. This does not affect the configuration of these items.

  • Severity—Use to define the severity of any alarms or events that are associated with the ODBC connection (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • DSN—Specify the Data Source Name (DSN) for the database from which ClearSCADA is to retrieve data. Use the browse button to select a Reference browse window and select the required DSN from the window. The DSN has to be a System DSN. To assist in selecting the right type of DSN, the entries in the Reference browse window are limited to System DSNs.
  • User Name—If access to the other application’s database is password protected, specify the user name that, used in conjunction with the Password given below, gives the required access.
  • Password—If access to the other application’s database is password protected, specify the password that, used in conjunction with the above User Name, gives the required access.

NOTE: If you have a requirement for inserting or replacing data values in the other application’s database, you need to specify a user name and password that has Read and Write privileges (for the other application’s database).

NOTE: If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed just below the Severity field. Use the Area of Interest field to specify the area with which any ODBC Connection alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).


ODBC Driver Guide - Configuring an ODBC Query

Configuring an ODBC Query

For each separate request for data transfer between applications using ODBC standards, you need to configure an ODBC Query within ClearSCADA.

The ODBC Driver converts each query into a request that the other application’s database management system recognizes and to which it can respond and carry out the requested data transfer. (For example, a request to retrieve a particular block of data.)

You can configure more than one ODBC Query for each application with which you want ClearSCADA to transfer data.

Before configuring an ODBC Query, check that any necessary Preparation has been completed. You can then use the fields on the ODBC Query Form to configure the ODBC Query database items on your system.

The Form has several tabs.

This section explains the fields on the Query tab of the Form (see Configure the Query Properties).

For information on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For aspects of connection configuration that are common to many types of database item, see the ClearSCADA Guide to Core Configuration.

For information on the minimal amount of configuration that you can undertake to produce a functional ODBC Query, see Minimum Configuration.


ODBC Driver Guide - Preparation (Configuring an ODBC Query)

Preparation

Before you can successfully configure an ODBC Query, you will need to have configured the ODBC Connection that specifies the application to which the Query relates (see Configuring an ODBC Connection).

You also need to be aware of the significance of the Query’s alarms and events in relation to the rest of your system—this will determine the severity that you allocate to each Query.


ODBC Driver Guide - Minimum Configuration (Configuring an ODBC Query)

Minimum Configuration

For an ODBC Query to become functional (online), you need to:

  • Specify the ODBC Connection that ClearSCADA uses to send the Query to the other application
  • Enter the SQL program code that specifies the data that is to be transferred between the two databases, and how that data is to be handled (for example, whether it is to be retrieved).

You also need to put the query In Service and save the configuration.

These are the minimum requirements and, when defined, will result in a functional query that uses the default configuration settings.


ODBC Driver Guide - Configure the Query Properties (Configuring an ODBC Query)

Configure the Query Properties

Use the fields on the Query tab to define the request for data transfer, how often that request is sent to the other application, and the connection used to access that application:

  • In Service—Use to specify whether the ODBC Query is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

NOTE: If you later take the Query out of service, its dependants (points) also become out of service. This does not affect the configuration of these items.

  • Severity—Use to define the severity of any alarms or events that are associated with the ODBC Query (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Connection—Use to specify the ODBC Connection that determines to which application this Query is sent. Use the browse button to display a Reference browse window and select the required Connection from the window.
  • Scan Rate—Specify the frequency with which this data request is sent to the other application. Enter the rate in the OPC Time Format, for example 30S for a 30-second scan rate. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required rate.
  • Query—Enter the SQL code that defines the data transfer mechanism that is required (for instance, which block of data is to be retrieved from the other database).

For an example of SQL query code, see Data Retrieval Examples. Full guidance on using SQL is outside the scope of this guide. We advise that any SQL Queries are written by engineers who have the appropriate experience and knowledge of the SQL language.

Each Query is executed on system or driver start-up, and thereafter at the specified Scan Rate interval, or whenever a Refresh is requested (for example, by an operator selecting the Refresh pick action for a Query).

Whenever a Query is executed, the data that is sent to ClearSCADA as a result of that query is stored in a results table, internally within the ODBC driver. You then use ODBC points (see Points Used for ODBC Data Transfer) to extract particular data values from that table.

NOTE: If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed just below the Severity field. Use the Area of Interest field to specify the area with which any ODBC Query alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).


ODBC Driver Guide - Points Used for ODBC Data Transfer

Points Used for ODBC Data Transfer

To transfer data to or from another database using ODBC, you need to configure an ODBC Query. The Query is used to extract the required block of data from the other database and store the data in a results table (see Configuring an ODBC Query). You then need to configure ODBC points of the appropriate type to extract individual data values from, or replace or insert individual data values into, the results table that is produced following the execution of the ODBC Query.

You configure the properties of each point using the fields on the appropriate ODBC Point Form. The ODBC driver supports the point types that are listed below. You need to configure those point types that present the extracted data in a suitable format within the ClearSCADA database.

  • Analog Point—see Configuring Analog Points.
  • Digital Point—see Configuring Digital Points.
  • String Point—see Configuring String Points.

For general information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

For information on the minimal amount of configuration that you can undertake to produce a functional ODBC point, see Minimum Configuration.

The rest of this section explains how to:

  • Configure SQL Query Lookup Properties on an ODBC Point Form.
  • Use an SQL Query to Insert or Update Data in Another Database
  • Configure the Background Logging Properties of Analog and Digital Points
  • Configure the Historic Data Storage Properties.


ODBC Driver Guide - Minimum Configuration (Points Used for ODBC Data Transfer)

Minimum Configuration

For an ODBC point to become functional (online), you need to specify:

  • The ODBC Query with which the point is associated
  • The required Lookup Method
  • For a point that is to retrieve data using the Row & Column Lookup Method:
  • The Row index for the point’s value
  • The Column index for the point’s value
  • For a point that is to retrieve data using the Value Lookup Method:
  • The Column index to search for the Lookup value
  • The Lookup Value
  • The Value column
  • For a point that is to update or insert data into another database, you need to define the properties and specify the SQL Query code on the Query tab.

You also need to put the point In Service and save the configuration.

These are the minimum requirements and, when defined, will result in a functional point that uses the default configuration settings.


ODBC Driver Guide - Configure SQL Query Lookup Properties (Points Used for ODBC Data Transfer)

Configure SQL Query Lookup Properties

Use these fields on the ODBC tab to specify general and SQL Query Lookup properties of a point. The fields at the top of the tab are common to points on many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers).

Fields that are specific to the ODBC driver are explained below:

  • Query—Specify the ODBC Query with which this point is associated. Use the browse button to display a Reference browse window and select the required Query from the window.
  • Lookup Method—Specify the method that the ODBC driver uses to extract a block of data from the other applications’ database.

Choose from:

  • Row & Column—To extract data from a specific row and column (see Row and Column Lookup).
  • Value Lookup—To extract data by referencing a specific value, such as a point name or ID (see Value Lookup).


ODBC Driver Guide - Row and Column Lookup (Points Used for ODBC Data Transfer)

Row and Column Lookup

Use the fields in the Row and Column Lookup section of the ODBC tab to specify the row and column from which you want to extract data. The fields are available for use when you specify a Row & Column Lookup Method (see Configure SQL Query Lookup Properties).

  • Row—Specify the row index that identifies the point’s location within the query’s results table. The row index has to be in the range specified in the SQL Query (for which the point is to extract data).
  • Column—Specify the column index that identifies the point’s location within the query’s results table. The column index has to be in the range specified in the SQL Query (for which the point is to extract data).

For an example of how a point might be configured to extract data from an ODBC Query results table using the Row & Column Lookup Method, see Query an Oracle Database using the Row & Column Lookup Method.


ODBC Driver Guide - Value Lookup (Points Used for ODBC Data Transfer)

Value Lookup

Use the fields within the Column Match Lookup section of the ODBC tab to specify the requirements for extracting data by reference to a specific value, such as a point name or ID. The fields are available for use when you specify a Value Lookup Method (see Configure SQL Query Lookup Properties).

  • Lookup Column—Specify the column index that identifies the point’s location within the query’s results table. The column index has to be in the range specified in the SQL Query (for which the point is to extract data).
  • Lookup Value—Specify the value within the Lookup Column, that indicates the row within which the point data is located. The Lookup Value may be, for example, the point name or ID.
  • Value Column—Specify the column from which the point’s value is extracted.
  • Timestamp Column—Specify the column from which the point’s time stamp is extracted, if you want to retrieve a time stamp with each data value. Enter a value of zero if you have no requirement for a time stamp to be retrieved with each data value. You should also enter a value of zero if the other database does not support time stamp information.

NOTE: If the source database includes historic data, you can set a point to be updated with all matching values from that database. To do this, you need to use the Timestamp Column field to specify the column from which the point’s time stamp is extracted.

  • Quality Column—Specify the column from which the point’s quality is extracted, if you want to retrieve the quality of each data value. Enter a value of zero if you have no requirement for quality details to be retrieved with each data value. You should also enter a value of zero if the other database does not support quality information.
  • Use All Results—If the source database includes historic data, select this check box to update a point with all matching values, in order of time stamp. If you select the Use All Results check box, you also need to define the Timestamp Column (above). The Timestamp Column setting allows you to specify the location of the time stamps in the query’s results table.

Clear the Use All Results check box if the source database includes only current data, or if you want to update a point with just the latest matching value. The point value only updates in the ClearSCADA database whenever it differs from the previously retrieved value.

For an example of how a point might be configured to extract data from an ODBC Query results table using the Value Lookup Method, see Query an Oracle Database using the Value Lookup Method.


ODBC Driver Guide - Use an SQL Query to Insert or Update Data in Another Database (Points Used for ODBC Data Transfer)

Use an SQL Query to Insert or Update Data in Another Database

To update or insert a value into another database using ODBC data transfer methods, you need to send a point control to the other database. The point control executes an SQL statement that specifies the location at which the point value, and optionally the associated time stamp, are to be updated or inserted within the other database.

For a control to be sent to another database in this way:

  • The other database has to support Write privileges.
  • ClearSCADA has to have Write as well as Read access to the required location within the other database. You specify this access by entering a suitable User Name and Password on the associated ODBC Connection Form (see Configure the Connection Properties).
  • The relevant ODBC point(s) need to be enabled for control in ClearSCADA. You can do this by using the Enabled check box on the Query tab of the corresponding ODBC Point Form.
  • For an analog point, you need to specify the control range, using the fields on the Query tab of the corresponding ODBC Point Form (see Define the Query Properties).
  • For a digital point, you need to enable and configure the required control action(s), using the fields on the Query tab of the corresponding ODBC Point Form (see Define the Query Properties).
  • For any ODBC point type for which the control feature is enabled, you need to specify the SQL Query that the control is to execute. Enter the required code using the Query field on the Query tab of the corresponding ODBC Point Form.

Example:

An Oracle database includes the following database table:

Table Name: SCADADATA
ValueId | Value | Time
1 | 3.5 | 10:15
2 | 4.7 | 10:15
3 | 12.3 | 10:15

An ODBC Analog point is used to update the value and time stamp for the row where ValueId = 3. To do this, the analog point is configured to use this SQL query command on the Query tab of the OBDC Analog Point Form:

At 10:26, an operator selects the Control pick action for the ODBC Analog point, and specifies a value of 10.4 in the Control window that is displayed. When the control is executed, the data in ValueId row 3 of the Oracle database is updated to display a value of 10.4 with a Time of 10:26.


ODBC Driver Guide - Configure the Background Logging Properties of Analog and Digital Points (Points Used for ODBC Data Transfer)

Configure the Background Logging Properties of Analog and Digital Points

The functionality of the ODBC tab’s Background Logging section differs, depending on the type of point. This section explains the Background Logging functionality that applies to ODBC analog and digital points. For information on the Background Logging functionality that applies to ODBC string points, see Configure the Background Logging Properties of String Points.

When ClearSCADA stores analog or digital point values historically, as per the settings specified on the point’s Historic tab, the server typically only stores point changes—if a point does not change, no history is recorded during that period. If an ODBC analog or digital point’s value or state tends to change infrequently and that point’s data is used, for example, in a data export program, or is displayed on a Historic Trend, consider configuring ClearSCADA to store that point’s values historically at a defined interval, regardless of whether the point has changed. You specify such requirements using the fields in the Background Logging section of the ODBC tab:

  • Enabled—Clear this check box if:
  • The point’s SQL Query Lookup Method is set to ‘Value Lookup’ and the Use All Results check box is selected in the Column Match Lookup section of the tab (see Value Lookup). (Background Logging cannot be used with a point for which the source database includes historic data.)
  • ClearSCADA is only to store point changes historically, as per the settings configured on the point’s Historic tab (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

or:

  • ClearSCADA is not to store data historically for this point.

Select the Enabled check box if the driver is to store point values historically at a defined interval, regardless of whether the point’s value changes.

If you select this Enabled check box, you should check that:

  • Historic is Enabled on the Historic tab.
  • Ideally, Compression on the Historic tab is set to either apply to No Data, or Current Data Only. (If Compression is configured to apply to All Data, set the Significant Change deadband to 0.)
  • The Timed Report check box is selected within the Historic Data Filter section of the ODBC tab (see Configure the Historic Data Storage Properties).
  • Interval—Use to specify the frequency with which ClearSCADA stores point values historically, regardless of whether they have changed.

Enter the required Interval in the OPC Time Format, for example 15M for ClearSCADA to store the point’s value historically at 15-minute intervals.

  • Offset—Use to specify the Background Logging start time—the amount of time that occurs before ClearSCADA logs the first point value historically. You need to define the time value and time unit from which the start time is to be offset from the present time. Specify the Offset in the OPC Relative Time Format. For example, specify H for ClearSCADA to start storing point values historically at the start of the present hour, and thereafter at the intervals specified in the Interval field, above.


ODBC Driver Guide - Configure the Historic Data Storage Properties (Points Used for ODBC Data Transfer)

Configure the Historic Data Storage Properties

This section applies to ODBC Analog and Digital points.

Use the fields within the Historic Data Filter section of the ODBC tab to specify the type of data that ClearSCADA is to store historically for the point.

NOTE: Use the Historic Data Filter section in conjunction with the Historic tab, which defines whether the server stores values historically for the point, and whether any unnecessary data is filtered out to reduce storage requirements (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

The ClearSCADA server retrieves and processes the current data values from the devices that it monitors. Use the check boxes within the Historic Data Filter section to specify the type of retrieved data that ClearSCADA is to store historically for a particular point:

  • Current Data—Select this check box to set the server to store the point’s current values historically.

Clear the check box if you have no requirement for ClearSCADA to store the point’s current values historically.

  • Timed Report—Select this check box if Background Logging is enabled for the point (see Configure the Background Logging Properties of Analog and Digital Points). ClearSCADA will regularly store the point’s value historically, regardless of whether that value has changed.

Clear the check box if Background Logging is not used for this point.

If neither check box is selected, regardless of whether historic is enabled on the point’s Historic tab, ClearSCADA will not store retrieved point values historically.


ODBC Driver Guide - Configuring Analog Points

Configuring Analog Points

Add and configure an ODBC Analog point for each item of analog-type data that you want to transfer between a ClearSCADA system and another application, using ODBC data transfer standards.

Configure the properties of each analog point using the fields on the ODBC Analog Point Form. The Form has several tabs.

Use the fields on the ODBC tab to:

  • Configure SQL Query Lookup Properties
  • Configure the Background Logging Properties (see Configure the Background Logging Properties of Analog and Digital Points)
  • Configure the Historic Data Storage Properties.

Use the fields on the Query tab of the Form to:

  • Define the Query Properties.

For information on the fields on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on other tabs on the Form, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


ODBC Driver Guide - Define the Query Properties (Configuring Analog Points)

Define the Query Properties

Use the fields on the Query tab to specify whether a point can be used to update or insert values into another database, using an SQL Query command.

Select the Enabled check box if the point is to be used to update or insert values in another database. Use the Maximum, Minimum, Severity, and Confirm fields to define the properties of the control. The fields are often displayed on the Control tab of points on other drivers—for further information, see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration.

Use the Query field to enter the SQL Query code that specifies the data that is to be updated or inserted into the other database, and the location into which the data is to be transferred (see Use an SQL Query to Insert or Update Data in Another Database).

Operators with the required permissions can then use the Control pick action to update the point data in the other database.

Clear the Enabled check box if you want to make the Control pick action unavailable for the point. With the check box cleared, the point is unable to update or insert values in another database.


ODBC Driver Guide - Configuring Digital Points

Configuring Digital Points

Add and configure an ODBC Digital point for each item of digital-type data that you want to transfer between a ClearSCADA system and another application, using ODBC data transfer standards.

Configure the properties of each digital point using the fields on the ODBC Digital Point Form. The Form has several tabs.

Use the fields on the ODBC tab to:

  • Configure SQL Query Lookup Properties
  • Configure the Background Logging Properties (see Configure the Background Logging Properties of Analog and Digital Points)
  • Configure the Historic Data Storage Properties.

Use the fields on the Query tab to:

  • Define the Query Properties.

For information on the fields on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on other tabs on the Form, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


ODBC Driver Guide - Define the Query Properties (Configuring Digital Points)

Define the Query Properties

Use the fields on the Query tab to specify whether a point can be used to update or insert values into another database, using an SQL Query command.

Select the Enabled check box if the point is to be used to update or insert values in another database. Use the Actions section of the tab to define the properties of the control. The fields within this section are typically displayed on the Control tab for digital points on other drivers—for further information, see Define the Output Actions in the ClearSCADA Guide to Core Point Configuration.

Use the Query field to enter the SQL Query code that specifies the data that is to be updated or inserted into the other database, and the location into which the data is to be transferred (see Use an SQL Query to Insert or Update Data in Another Database).

Operators with the required permissions can then use the Control pick action to update the point data in the other database.

Clear the Enabled check box to make the Control pick action unavailable for the point. The point will be unable to update or insert values in another database.


ODBC Driver Guide - Configuring String Points

Configuring String Points

Add and configure an ODBC String point for each text string data value that you want to transfer between a ClearSCADA system and another application, using ODBC data transfer standards.

Configure the properties of each string point using the fields on the ODBC String Point Form.

Use the fields on the ODBC tab to:

  • Configure SQL Query Lookup Properties
  • Configure the Background Logging Properties (see Configure the Background Logging Properties of String Points).

Use the fields on the Query tab to:

  • Define the Query Properties.

For information on the fields on the String Point tab, see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on other tabs on the Form, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


ODBC Driver Guide - Define the Query Properties (Configuring String Points)

Define the Query Properties

Use the fields on the Query tab to specify whether a point can be used to update or insert values into another database, using an SQL Query command:

Select the Enabled check box if the point is to be used to update or insert values in another database. Use the Severity and Confirm fields to define the properties of the control. The fields are often displayed on the Control tab of points on other drivers—for further information, see Define the Control Settings for a String Point in the ClearSCADA Guide to Core Point Configuration.

Use the Query field to enter the SQL Query code that specifies the data that is to be updated or inserted into the other database, and the location into which the data is to be transferred (see Use an SQL Query to Insert or Update Data in Another Database).

Operators with the required permissions can then use the Control pick action to update the point data in the other database.

Clear the Enabled check box to set the point so that it cannot be used to update or insert values in another database. The other fields on the Query tab appear ‘grayed out’ and are unavailable for use.


ODBC Driver Guide - Configure the Background Logging Properties of String Points (Configuring String Points)

Configure the Background Logging Properties of String Points

Use the fields within the Background Logging section of a string point’s ODBC tab to specify whether ClearSCADA is to regularly update the string’s value in the ClearSCADA database, regardless of whether that value has changed.

  • Enabled—Clear this check box if ClearSCADA is only to update the string’s value in the ClearSCADA database whenever that value changes. The other fields in the Background Logging section are ‘grayed out’ and unavailable for use.

Select the Enabled check box if ClearSCADA is to regularly update the string’s value, regardless of whether that value has changed. This provides confidence that ClearSCADA is continuing to retrieve the string’s data from the other application’s database. When this check box is selected, users can monitor the string’s Last Updated status attribute to ascertain when ClearSCADA last updated the point’s value. Use the rest of the fields within the Background Logging section to specify how often ClearSCADA updates the point’s data when that value is not changing. (With a string point for which the value is changing, ClearSCADA scans the other application’s database and updates the string’s value in the ClearSCADA database at the Scan Rate specified on the ODBC Query Form (see Configure the Query Properties).)

  • Interval—Use to specify the frequency with which ClearSCADA updates the point’s value, regardless of whether that value has changed.

Enter the required Interval in the OPC Time Format, for example 15M for ClearSCADA to update the point’s value at 15-minute intervals.

  • Offset—Use to specify the Background Logging start time—the amount of time that occurs before ClearSCADA first updates the point’s value, regardless of whether that value has changed. You need to define the time value and time unit from which the start time is to be offset from the present time. Specify the Offset in the OPC Relative Time Format. For example, specify H for ClearSCADA to start updating the point’s value at the start of the present hour, and thereafter at the intervals specified in the Interval field, above.

NOTE: Background Logging is used to apply additional functionality to ODBC analog and digital points—see Configure the Background Logging Properties of Analog and Digital Points.


ODBC Driver Guide - Data Retrieval Examples

Data Retrieval Examples

This section includes examples that demonstrate:

  • How an ODBC Query might be configured to retrieve a block of data from another database
  • How the points associated with that Query might be configured to retrieve specific values from that block of data.

The examples included in this section are:

  • Query an Oracle Database using the Row & Column Lookup Method
  • Query an Oracle Database using the Value Lookup Method.


ODBC Driver Guide - Query an Oracle Database using the Row & Column Lookup Method (Data Retrieval Examples)

Query an Oracle Database using the Row & Column Lookup Method

This example demonstrates how ClearSCADA might be configured to query data in an Oracle database, using the Row & Column Lookup Method.

Example:

An Oracle database includes the following database table:

Table Name: SCADADATA
ValueId | Value | PrevValue | State
1 | 10 | 15 | Low
5 | 21 | 20 | Normal
2 | 17 | 19 | Low
10 | 99 | 90 | High

Within ClearSCADA, an ODBC Query is configured to:

  • Retrieve the ValueId and Value columns of data from the SCADADATA table
  • Sort the retrieved data by ascending ValueId column order.

To do this, the ODBC Query is configured to use this SQL query request:

This request returns the following results table to the ClearSCADA ODBC driver:
ValueId | Value
1 | 10
2 | 17
5 | 21
10 | 99

Within ClearSCADA, an ODBC Analog point is configured to return the value from the row ValueId 5. To do this, the point is configured to use a Row & Column Lookup Method with these settings:

This results in the ODBC Analog point having a value of 21.


ODBC Driver Guide - Query an Oracle Database using the Value Lookup Method (Data Retrieval Examples)

Query an Oracle Database using the Value Lookup Method

This example demonstrates how ClearSCADA might be configured to query data in an Oracle database, using the Value Lookup Method.

Example:

An Oracle database includes the following database table:

Table Name: SCADADATA
ValueId | Value | Time
1 | 2.5 | 10:00
2 | 3.7 | 10:00
3 | 11.3 | 10:00
3 | 11.4 | 09:00
3 | 10.2 | 08:00

Within ClearSCADA, an ODBC Query is configured to retrieve the ValueId, Value and Time columns of data from the SCADADATA table.

To do this, the ODBC Query is configured to use this SQL query request:

Within ClearSCADA, an ODBC Analog point is configured to return data from the rows in the ValueId column that have a value of 3. To do this, the point is configured to use a Value Lookup Method with these settings:

As the Use All Results check box is selected, this results in the ODBC Analog Point being given the values of 10.2, 11.4, and then 11.3 respectively. (These are the values retrieved, in ascending time stamp order, from the entries in Lookup Column 1 (‘ValueId’) that have a Lookup Value of 3. The point values are retrieved from column 2 (as Value Column = 2) and the time stamps from column 3 (as Timestamp Column = 3).)


ODBC Driver Guide - Using ODBC Specific Actions

Using ODBC Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see the ClearSCADA Guide to ViewX and WebX Clients).

This section explains the Display Queries and Refresh actions, which are ODBC driver-specific.

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


ODBC Driver Guide - Display Queries (Using ODBC Specific Actions)

Display Queries

Associated with: ODBC Connections

Security permission required to access this pick action: Read

Use this pick action to display a Queries List of the ODBC Query items that are associated with the selected ODBC Connection. Use the List to ascertain the current status of each query. As with any ClearSCADA Queries List, place the cursor over a List heading to display a ToolTip that provides more information about the entries in that particular column.

NOTE: The Display Queries pick action is not a method and therefore cannot be used with the automation interface.


ODBC Driver Guide - Refresh (Using ODBC Specific Actions)

Refresh

Associated with: ODBC Queries

Security permission required to access this pick action: Retrieve Data

Use the Refresh pick action to request an immediate update of the data that an ODBC Query is configured to retrieve.

With point data that is:

  • retrieved using the Row & Column Lookup Method
  • retrieved using the Value Lookup method, but for which time stamps are not extracted (as determined by the Point Form’s Timestamp Column property having a value of zero)

this pick action works in the same way as the Refresh pick action for items on other drivers (see Refresh in the ClearSCADA Guide to Drivers).

With point data that is retrieved using the Value Lookup method and for which time stamps are extracted, each point will retain the time stamp that is extracted from the results table’s Timestamp column. (For such points, the Point Form’s Timestamp Column defines the location of the column that contains the point’s time stamps.)

Further Information

Row and Column Lookup

Value Lookup.


ODBC Driver Guide - ODBC Specific Status Display Attributes

ODBC Specific Status Display Attributes

Every item in the ClearSCADA Database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each ODBC Query provides information about the present state of that query.

Use this section if you need information on the status of any ODBC driver database items on your system.

This section describes those attributes that are ODBC driver-specific and includes:

  • ODBC Connection Status Attributes
  • ODBC Query Status Attributes
  • ODBC Point Status Attributes
  • Alphabetical List of ODBC Specific Status Display Attributes.

NOTE: For information on the current status of the ODBC Queries that use a particular ODBC Connection, consider using the Display Queries pick action. This will display a List of the ODBC Queries on that ODBC Connection.

Further Information

Working with Status displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


ODBC Driver Guide - ODBC Connection Status Attributes (ODBC Specific Status Display Attributes)

ODBC Connection Status Attributes

These status attributes are specific to ODBC Connections:

  • Source
  • State.


ODBC Driver Guide - ODBC Query Status Attributes (ODBC Specific Status Display Attributes)

ODBC Query Status Attributes

These status attributes are specific to ODBC Queries:

  • Comms Statistics
  • Source
  • State.


ODBC Driver Guide - ODBC Point Status Attributes (ODBC Specific Status Display Attributes)

ODBC Point Status Attributes

This status attribute is specific to ODBC points:

  • Source.


ODBC Driver Guide - Alphabetical List of ODBC Specific Status Display Attributes (ODBC Specific Status Display Attributes)

Alphabetical List of ODBC Specific Status Display Attributes

This section lists those status attributes that are specific to items on the ODBC driver. The attributes comprise:

  • Comms Statistics
  • Source
  • State.


ODBC Driver Guide - Comms Statistics (ODBC Specific Status Display Attributes)

Comms Statistics

Associated with: ODBC Queries

This status attribute shows the number of read operations performed by the selected ODBC Query since the driver was last started, or the ODBC Query enabled.

Example:

42 reads


ODBC Driver Guide - Source (ODBC Specific Status Display Attributes)

Source

Associated with: ODBC Connections, ODBC Queries, ODBC points

The Source attribute indicates the location at which the item resides.

This attribute is common to many Status displays, but the information shown varies, depending on the driver and the type of item.

For ODBC Connections and ODBC Queries, information is displayed in this format:

<Data Source Name>

Example:

CRSS
(where CRSS is the Data Source Name (DSN) of an SQL server)

For ODBC points, the format in which information is displayed varies, depending on the look up method:

For a point that uses a Row & Column method, information is displayed in this format:

<Data Source Name>:<Row number>,<Column number>

Example:

CRSS:1,4
(for a point that is used to extract data from row 1, column 4, of the results table produced by an SQL query that is extracting data from an SQL server with the DSN ‘CRSS’.)

For a point that uses a Value Lookup method, information is displayed in this format:

<Data Source Name>:LOOKUP <Lookup Column>(<Lookup Value>).<Value Column>, <Quality Column>,<Timestamp Column>,<Use All Results>

Example:

CRSS:LOOKUP 1(5).2,0,3,All
(for a point that uses a ‘Value Lookup’ method to extract data from Lookup Column 1, Lookup Value 5, Value Column 2, Quality Column 0, and Timestamp Column 3. The source database includes historic data, and the ‘All’ attribute indicates that all matching values are retrieved, in time stamp order. The zero Quality Column entry indicates that quality details are not retrieved for the values. The Data Source is as per the previous example.)


ODBC Driver Guide - State (ODBC Specific Status Display Attributes)

State

Associated with: ODBC Connections, ODBC Queries

This attribute indicates the present state of the ODBC Connection or ODBC Query.

The attribute indicates whether there is a problem with the Connection or Query configuration in relation to the database that it is trying to access.

For an ODBC Connection, the possible states are: Online, Not In Service, Uninitialized, Failed

Where the state is ‘Uninitialized’, this indicates that the ODBC driver is not running. (Additionally, the Quality attribute will display the state ‘Device Failure’.)

Where the state is ‘Failed’, the attribute includes a description that indicates the reason for the failure. ClearSCADA receives the descriptions from the WindowsTM ODBC Navigator.

Example:

Failed - [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

(This error indicates that the configured Data Source does not exist.)

For an ODBC Query, the possible states are: Online, Offline, Uninitialized, Failed

Where the state is ‘Offline’, use the State attribute in conjunction with the Quality attribute to assess the reason for the Query being offline (for example, the Quality attribute might indicate that the Query is not connected or is out of service).

Where the state is ‘Uninitialized’, this indicates that the ODBC driver is not running. Additionally, the Quality attribute will display the state ‘Device Failure’.

Where the state is ‘Failed’, the attribute includes a description that indicates the reason for the failure.


OPC Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


OPC Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


OPC Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


OPC Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


OPC Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


OPC Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure OPC-specific features and items in the ClearSCADA database (see Configuring OPC Devices in ClearSCADA). It also provides information on using OPC-specific features for fault finding and diagnostics.

For more information on the subjects covered in this guide, see Introduction to the OPC Driver.


OPC Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for use by engineers who are responsible for the configuration of OPC-specific items and features in ClearSCADA. It can also be used by system administrators when investigating unexpected behavior relating to the OPC driver.


OPC Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


OPC Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


OPC Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


OPC Driver Guide - Introduction to the OPC Driver

Introduction to the OPC Driver

The OPC standards are a series of standard specifications aimed at allowing inter operability between different SCADA systems. ClearSCADA uses these standards to allow transfer of data between the ClearSCADA server and third-party applications.

The OPC driver is used to read and write to data on other servers, including ClearSCADA or third-party servers, using the OPC protocol. The driver takes into account any OPC private security settings, designed to limit access to configuration properties on many OPC servers.

The OPC documentation explains how to configure OPC-specific features and items within the ClearSCADA database (see Configuring OPC Devices in ClearSCADA).

It also explains driver-specific aspects that are of interest to System Administrators and engineers when investigating unexpected system behavior relating to the OPC driver (see OPC Registration and Server Browsing, and see OPC Specific Status Display Attributes.)

NOTE: There are no driver-specific pick actions for items on the OPC driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

ClearSCADA is able to read and write to data on other servers using one of several OPC standards and one of several ClearSCADA drivers—for information on which driver is appropriate for your system requirements, see Which Driver?.

Further Information

OPC Foundation Standards: see www.opcfoundation.org

OPC Time Formats used in ClearSCADA: see Using OPC Time Formats in the ClearSCADA Guide to Core Configuration.


OPC Driver Guide - Which Driver? (Introduction to the OPC Driver)

Which Driver?

ClearSCADA is able to read and/or write to data on other servers using one of several OPC standards. Whether you choose to use the ClearSCADA OPC Driver, or the ClearSCADA OPC XML-DA Driver, depends to some extent on your system setup. OPC DA is more efficient in terms of network bandwidth than OPC XML-DA. However, OPC DA is based on DCOM and can be problematic to set up when the driver and target OPC DA server are on opposite sides of a firewall. OPC XML-DA uses standard web protocol and is much more firewall friendly. If network bandwidth is important, use the ClearSCADA OPC Driver to communicate using OPC DA; if easy setup is important, use the ClearSCADA OPC XML-DA Driver to communicate using OPC XML-DA.


OPC Driver Guide - OPC Registration and Server Browsing (Introduction to the OPC Driver)

OPC Registration and Server Browsing

OPC Servers support a registration mechanism to put the appropriate entries into the ClearSCADA registry. Registration occurs automatically whenever an application that supports the OPC protocol is installed. This section of the guide provides information for administrator level users should registration not appear to have occurred as expected, or should ClearSCADA not be able to access an OPC server.

ClearSCADA can communicate with three types of OPC server—In Process, Local, and Remote (see Configuring the OPC Server Properties). In Process servers are registered using RegSvr32; Local (executable) servers are registered through the /RegServer command line option; Remote servers need registering on both the server and client machines. Registration on ClearSCADA systems is done through the ClearSCADA Control Panel applet.

The OPCEnum service is installed automatically when you install ClearSCADA as a server. The OPCEnum service offers an effective method of locating remote OPC servers, provided that the service is also available on the remote devices.

When searching for remote OPC servers, ClearSCADA will initially use the OPCEnum service. The ClearSCADA OPC Driver will attempt to connect to the OPCEnum service on the remote machine. If the OPCEnum service is not available on the remote machine(s), ClearSCADA will revert to using the Category Manager to browse for OPC servers.

This feature was introduced by the OPC foundation during the OPC DA 2 specification. Previously, a server included an extra OPC key under its Class Identifier (CLSID) to indicate that it was an OPC server. New servers should register themselves using both mechanisms—that is, using the Category Manager and using the OPC key under the CLSID.

Some very old servers only use the OPC key technique and as such, are not visible to ClearSCADA (run OLE View in ‘Expert’ mode to see the OPC categories that are listed in the ‘Grouped By Component Category’ section). Old OPC servers that are not visible to ClearSCADA need upgrading if ClearSCADA is to communicate with them using the OPC protocol.


OPC Driver Guide - Configuring OPC Devices in ClearSCADA (Introduction to the OPC Driver)

Configuring OPC Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database reference the devices and plant that you are trying to monitor on your system. This section summarizes the database items that you need to configure in order to read and write to data on other servers, using the OPC protocol.

In order to communicate with other servers using the OPC protocol, the OPC Driver has to be installed and running on the ClearSCADA servers on your system. The driver is represented by the OPC Client component in the ClearSCADA Installation Wizard’s Setup window. The component is located within the Server branch of the tree that is displayed in the window (see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers).

When you configure OPC items in the ClearSCADA database, many of the settings for those items need to correspond to the settings on the relevant OPC servers on your system. You need to have access to, or a list of, these settings before you can configure the OPC database items successfully.

For instance, you need to know the read and write mechanisms that are supported by the OPC servers on your system, and the user names and passwords that allow the required level of access to the data on those servers.

You also need to be aware of which optional features are required for each OPC item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with OPC database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each OPC device, you need to configure:

  1. OPC Server(s) to specify the servers on which data is to be scanned, along with any access and security settings required to communicate with those servers.

You need to configure one OPC Server item in the database for each server with which you want to communicate using the OPC protocol (see Configuring an OPC Server).

  2. OPC Scanner(s) to specify which nodes are to be scanned and the rates at which the data is to be retrieved.

You need to configure a minimum of one OPC Scanner per OPC Server. You can attach multiple scanners to the same server. For instance, you might configure different scanner to have different scan rates or offsets, in order to retrieve some data at different intervals or times to other data.

For more information, see Configuring an OPC Scanner.

  3. OPC Points to represent the measuring instruments and control devices on the servers that are communicating using the OPC protocol.

For more information, see Points Used on OPC Scanners .

To minimize the time that it takes to configure the required OPC items, you may want to configure them in the order listed above, as the Scanner configuration requires that you specify a server, and point configuration requires that you specify a scanner, and so on.


OPC Driver Guide - Configuring an OPC Server

Configuring an OPC Server

For every server with which you want ClearSCADA to communicate using the OPC protocol, you need to configure an OPC Server in the ClearSCADA database.

Before configuring an OPC Server in the database, carry out any necessary Preparation. Then use the fields on the OPC Server Form to configure the OPC server database items on your system.

The Form has several tabs. Use the fields on the Server tab to define the connection properties that are required for successful communications with the node on which the OPC data is located (see Configuring the OPC Server Properties).

For information on the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional OPC Server in ClearSCADA, see Minimum Configuration.


OPC Driver Guide - Preparation (Configuring an OPC Server)

Preparation

You need to add an OPC Server for each server on your system with which you want to communicate using the OPC protocol.

To configure an OPC Server, you need to know the type of connection required to access the server, and the name of the node on which it is located if it is not on the same PC as the ClearSCADA database. You also need to know the read and write mechanisms that are supported by the server, along with the user name(s) and password(s) that allow the required access to the data on that server.

You also need to establish which features are required for each OPC server. You can configure each server to use a variety of features, including alarm redirection. However, many of these features are optional and have no effect on the success of communications. The optional features include:

  • Alarm view
  • Alarm Redirection
  • User methods.

If the features listed above are not configured, they are not used for the selected server (they will be left blank).


OPC Driver Guide - Minimum Configuration (Configuring an OPC Server)

Minimum Configuration

For the OPC server to be functional (online), you have to specify:

  • The OPC Program ID that identifies the OPC server with which ClearSCADA is to communicate.
  • For Remote Server connections, the name of the node on which the OPC data is located, and the domain name, user name and password that are required to access the server.
  • For Local Server connections, the domain name, user name and password that are required to access the data on that server.
  • For servers that use OPC security to limit data access, the user name and password that allow the required data access.

You also need to put the server In Service, and save the configuration.

The minimum configuration listed above will provide a functional OPC server that uses the default configuration.


OPC Driver Guide - Configuring the OPC Server Properties (Configuring an OPC Server)

Configuring the OPC Server Properties

Use the fields on the Server tab of the OPC Server Form to define the connection properties of the server:

  • In Service—Use this check box to specify whether the OPC server is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

NOTE: If you take the server out of service, its scanners and their dependants (such as points) also become out of service. This does not affect the configuration of the dependant items.

  • Connection Type—Specify the type of connection that is to be used between the OPC server and the node on which the OPC data is located:
  • In Process—The OPC server is located on the computer on which the ClearSCADA database resides. Access to the server is via a direction connection, using a dynamic-linked library file (DLL) that is loaded into the executing process.

Select this option if you want ClearSCADA to scan another ClearSCADA server via OPC. The ClearSCADA OPC Server is implemented as an in-process dynamic-linked library. Running the ClearSCADA OPC Server in-process minimizes the communications overhead between the OPC client driver and the target ClearSCADA server.

Enter the required OPC Program ID in the OPC Server Name field below.

  • Local Server—The OPC server is located locally, on the computer on which the ClearSCADA database resides. The OPC server runs as a separate executable (EXE), and as such requires a separate connection to access that server.

You typically use this option to enable ClearSCADA to communicate with a third-party OPC server.

Enter the Domain Name, User Name and Password for that connection, in the fields below.

  • Remote Server—The OPC server is located on another node (computer) to the server(s) on which the ClearSCADA database resides. The OPC server runs as a separate executable (EXE) on the other computer.

Select this option to enable ClearSCADA to communicate with a third-party OPC server that is located on another node to the ClearSCADA server(s).

Specify the name of the node, along with the Domain Name, User Name and Password required to connect to that node, in the fields below.

  • OPC Server Node—Use when a Remote Server connection is specified, to specify the node (computer or workstation connected to the ClearSCADA network) on which the OPC server resides. Use the browse button to display a Reference browse window and select the required node from the window.
  • Domain Name—Applies if the connection type is Local Server or Remote Server. Enter the WindowsTM domain name that is used for authenticating users when connecting to the OPC server.
  • User Name—Applies if the connection type is Local Server or Remote Server. Enter the WindowsTM user name that is to be used for the OPC connection. This has to be the name of a user whose privileges allow the required read/write access to data on the OPC server. Enter the corresponding password in the field below.
  • Password—Applies if the connection type is Local Server or Remote Server. Enter the WindowsTM password that is to be used for the OPC connection.
  • OPC Server Name—Specify the OPC Program ID that is to be used for the OPC connection. Use the browse button to display a Reference browse window, and select the required ID from the window.
  • Use Private Security—Some OPC servers support Private Security, whereby you have to log onto the server in order to access the data. Use this check box to define whether OPC Private Security is used on the OPC server with which you want to connect.

Select the check box to enable security, and define the user name and password in the fields below. The OPC driver will attempt to log on to the OPC server using the private security interface, and the user name and password given below. The ClearSCADA OPC server supports private security and maps any private security logon requests directly onto ClearSCADA user accounts. Therefore you need to select the Use Private Security check box and provide a suitable ClearSCADA user name and password, if any of the data that ClearSCADA is to access is hidden from the Guest User.

Example:

On a ClearSCADA system that is using OPC to monitor server statuses, either configure the Everyone user to have Read access to the database, or use private security on the OPC server(s) and specify a ClearSCADA user that has Read privilege.

Clear the check box if the OPC server does not support Private Security.

  • Private Security User Name—Available if the Use Private Security check box is enabled. Use this field to specify the Private Security user name that is required to access data on the OPC server. Enter the corresponding password in the field below.
  • Private Security Password—Available if the Use Private Security check box is enabled. Use this field to specify the password that is to required to access data on the OPC server.
  • Read Mode—OPC servers can support any of three Read mechanisms, as defined in the OPC standards. Use this combo box to specify which OPC Read mechanism is supported by the OPC server to which you want to connect. The options are:
  • Asynchronous V1—This is the preferred option to use if the OPC server only supports version 1.0 of the OPC-DA standard.
  • Asynchronous V2—This is the preferred option to use if the OPC server supports version 2.0 of the OPC-DA standard.
  • Synchronous—Select this option if neither of the above options are supported by the OPC server.

Asynchronous read modes use a 'subscribe' method to register items of interest with the OPC server. This method is more complex than the Synchronous read mode, but very efficient. The Synchronous read mode uses a 'polling' method to collect the data from the OPC server and as such, can be less efficient than the Asynchronous methods.

(In the absence of information on an OPC server, we suggest you test out the Read Mode options in the following order: Asynchronous V2, Asynchronous V1, and then Synchronous. We recommend using the first option that works correctly.)

  • Synchronous Write—Use this check box to define the OPC Write mechanism that is supported by the OPC server with which you want to connect.

Select the check box if the server supports synchronous writing of data.

Clear the check box if the server supports asynchronous writing of data.

  • Ignore Server Timestamps—Use this check box to define whether OPC data is time stamped according to its receipt time or occurrence time.

Clear the check box is clear if ClearSCADA is to use the time stamps that the OPC server has provided.

Select the check box if ClearSCADA is to time stamp OPC data on receipt—any time stamps provided by the OPC server are ignored. You need to select the Ignore Server Timestamps check box if you want ClearSCADA to store OPC analog data historically at defined intervals, using ClearSCADA’s Background Logging feature (see Define the Background Logging Properties). You might also want to select the check box so that ClearSCADA can time stamp the data if, for example, the time stamps provided by the OPC server are significantly behind or ahead of the current time.

  • Severity—Use to define the severity of any alarms or events that are associated with the OPC server (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Server tab. Use the field to specify the area with which any of the Server’s alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.


OPC Driver Guide - Configuring an OPC Scanner

Configuring an OPC Scanner

An OPC Scanner is logical functionality that runs within ClearSCADA and scans for data on an OPC server (any server connected to the ClearSCADA network, with which ClearSCADA communicates using the OPC protocol).

You can attach multiple scanners to each OPC server on your system. By specifying different scan rates and offsets, you can enable the OPC driver to scan certain data at different intervals and times to other data on the same server.

Configure scanner features using the fields on the OPC Scanner Form.

The Form has several tabs.

Use the fields on the Scanner tab to specify the scan properties, such as the scan rate and offset (see Configure the Scanner Properties).

For fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional OPC Scanner in ClearSCADA, see Minimum Configuration.


OPC Driver Guide - Minimum Configuration (Configuring an OPC Scanner)

Minimum Configuration

As a minimum, for an OPC scanner to become functional (online), you need to specify the server on which it is to scan data.

You also need to put the scanner In Service, and save the configuration.

This will result in a functional scanner that uses the default configuration settings.


OPC Driver Guide - Configure the Scanner Properties (Configuring an OPC Scanner)

Configure the Scanner Properties

Use the fields on the Scanner tab to define the driver-specific properties of a scanner. Many of these fields are common to various scanners (see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the OPC driver are described below.

  • Server—Use the browse button to select the name of the server on which the OPC scanner is to scan data.


OPC Driver Guide - Points Used on OPC Scanners

Points Used on OPC Scanners

OPC Scanners read and write to data on OPC servers. You need to map the data on each OPC server to suitable OPC points within the ClearSCADA database, to enable ClearSCADA to handle the data in a similar way to other point data on the system (for instance, in order to monitor state changes, raise alarms, or execute controls).

The OPC driver can support any of the point types that are listed below. You need to configure those point types that present the OPC node data in a suitable format within the ClearSCADA database.

Where a point type is specific to the OPC Driver, a short description is given below. For descriptions of other point types, see the ClearSCADA Guide to Core Point Configuration.

For information on creating a point and displaying a Point Form, see Create and Configure a Point in the ClearSCADA Guide to Core Point Configuration.

For information on configuring fields on the OPC tab, see the rest of this section, which explains how to:

  • Configure General Properties on the OPC Tab
  • Specify the Source Value of a Point
  • Retrieve Configuration Properties From an OPC Data Source.

For analog points, also see Configuring Analog Points.

For digital points, also see Configuring Digital Points.

For information on configuring fields on the <Point Type> tab, see the references below:

  • Analog Point—see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.
  • Digital Point—see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.
  • String Point—a point for which the source is a text string, rather than a numeric value (see Configuring String Points).
  • Time Point—a point for which the source is a time value (see Configuring Time Points).

For fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC Driver Guide - Configure General Properties on the OPC Tab (Points Used on OPC Scanners)

Configure General Properties on the OPC Tab

Use the fields at the top of the OPC tab to configure the general point properties of each point. Some of these fields are common to many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to points on the OPC driver are explained below.

  • Tag Name—Within OPC terminology, ‘point’ values on OPC servers are referred to as tags. Use the Tag Name field to specify the item of data that you want to monitor in ClearSCADA, for example a particular analog tag. Select the browse button to display a Reference browse window, and select the required OPC tag from the window.


OPC Driver Guide - Specify the Source Value of a Point (Points Used on OPC Scanners)

Specify the Source Value of a Point

Use the fields within the Value section of the OPC tab to specify the type of source value that is used to derive the value of the point in the ClearSCADA database. ClearSCADA processes the point data differently, according to the type of source value that it represents.

  • Value Source—Use this combo box to specify the type of source value from which ClearSCADA is to read or write data. Choose from:
  • Single Value—The source value is a single data value.

For Digital points, specify this option if the lowest bit to which ClearSCADA is to read or write is the first or only bit within an individual value. (If the lowest bit to which ClearSCADA is to read or write is a bit other than bit zero, specify the Bit Offset within Single Value option.)

  • Array Element—The source value is an element within a data array. Use the Array Element field (below) to specify the actual element from which ClearSCADA is to read or write data.

For Digital points, specify this option if the lowest bit to which ClearSCADA is to read or write is the first bit of an element within the array. (If the lowest bit to which ClearSCADA is to read or write is another bit within an element, specify the Bit Offset within Single Value option.)

  • Bit Offset within Single Value—Applies to Digital points only. Specify this option when the lowest bit to which ClearSCADA is to read or write is not the first bit in the source value. Use the Bit Offset field (below) to specify the actual bit from which ClearSCADA is to read or write data.
  • Bit Offset within Array Element—Applies to Digital points only. Specify this option when the lowest bit to which ClearSCADA is to read or write is not the first bit in an array element. Use the Array Element field (below) to specify the actual element, and the Bit Offset field to specify the actual bit within that element.
  • Array Element—Applies if the Value Source is set to Array Element. Specify the actual element within the data array, which is used to derive the value for the point.
  • Bit Offset—Displayed on the OPC tab of Digital points only. Use this field to denote the offset into the source value that is to be retrieved for the database point (the lowest bit being bit zero).

You only need to specify a Bit Offset when the Value Source is Bit Offset within Single Value or Bit Offset within Array Element.

Example:

The Source of a 3-bit OPC Digital point is a 16-bit Value, of which the Digital Point comprises bits 3 to 5. In order for ClearSCADA to retrieve the point’s value from the correct location in the point source, the Digital point is given this configuration:

Value Source:Bit offset within single value
Bit Offset:3 (as 3 is the lowest, or starting bit, of the point value that comprises
bits 3, 4, and 5)


OPC Driver Guide - Retrieve Configuration Properties From an OPC Data Source (Points Used on OPC Scanners)

Retrieve Configuration Properties From an OPC Data Source

When a similar point property exists in an OPC data source, the OPC driver can retrieve the value of that property directly from the OPC data source. For example, for an OPC analog point, the driver can retrieve the values of the Full Scale and Zero Scale properties from the OPC data source for that point. Retrieving the value of a configuration property in this way avoids the need for engineers to specify the property manually within the ClearSCADA database.

The OPC driver retrieves the values of any point properties that are enabled for retrieval, when it first connects to the specified OPC data source.

Use the Configuration Properties section of the OPC tab to specify which property values the OPC driver is to retrieve for an analog or digital point, and the IDs that identify each of those properties in the OPC data source.

For each configuration property, either:

  • Select the corresponding check box if the OPC driver is to retrieve the property value from the OPC data source. Specify the property ID in the adjacent field.
  • Clear the check box for any property for which the OPC driver is unable to retrieve a value. For example, when the OPC data source does not have a corresponding configuration property.

The configuration properties that the driver can retrieve vary, depending on the point type. For analog points, see Define which Configuration Properties are Retrieved from an OPC Source. For digital points, see Define which Configuration Properties are Retrieved from an OPC Source.

Select the check box for the OPC driver to retrieve the property value from the data source...
...then specify the property ID of the corresponding parameter in the OPC data source.

Further Information

Retrieve the Value of a Search Key 1 Field.


OPC Driver Guide - Retrieve the Value of a Search Key 1 Field (Points Used on OPC Scanners)

Retrieve the Value of a Search Key 1 Field

A System Administrator can add additional configuration fields to Forms when a ClearSCADA system is first set up. The fields are set on a per database basis and can be added if additional configuration properties or point values need displaying, which are specific to your system or application.

Where an additional configuration field is required to display information in alphanumeric text format, this is added to the ClearSCADA database in the form of a Search Key field.

If your system has been configured to display an extra configuration field on each Point Form and that field has been set up using Search Key 1, you can use the Search Key 1 check box on an OPC Point Form to specify whether to retrieve the value of the Search Key 1 field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Search Key 1 parameter in the OPC data source (see Retrieve Configuration Properties From an OPC Data Source).

Search Keys are configured using the Metadata window in ViewX (see Extra Database Fields in the ClearSCADA Guide to Server Administration).

For the Search Key 1 field to appear on the Point Form, Search Key 1 has to be configured to reference the CDBPoint database table. This reference is made using the Metadata window. Search Key fields that reference this table appear as fields on an additional Point tab on the Point Configuration Form for each point on the system. Each Search Key field is given the size, position and (if applicable) label that is specified for that field in the Metadata window.


OPC Driver Guide - Configuring Analog Points

Configuring Analog Points

The OPC driver supports Analog Input and Analog Output points.

The points are used to map ‘point’ data on OPA servers into ClearSCADA in a format that it can understand, and vice versa.

Configure the properties of each analog point using the fields on the OPC Analog Point Form.

This section covers configuration of analog-specific properties on the OPC tab of the Form.

Use the fields on the OPC tab to:

  • Configure General Properties on the OPC Tab
  • Specify the Source Value of a Point
  • Configure Point Scaling (see Scale Analog Values for use in ClearSCADA in the ClearSCADA Guide to Simple Drivers)
  • Define Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration)
  • Prevent Fleeting Changes in Value from Changing the Point State
  • Define the Background Logging Properties
  • Define the Historic Data Storage Properties
  • Define which Configuration Properties are Retrieved from an OPC Source.

For information on the fields on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC Driver Guide - Prevent Fleeting Changes in Value from Changing the Point State (Configuring Analog Points)

Prevent Fleeting Changes in Value from Changing the Point State

On the OPC tab, you can use Persistence properties to prevent a change in value from affecting the point state until the point has been in that state for a specified time. This prevents the server from processing momentary changes of state and reporting those changes (see the example, below).

Use these fields within the Persistence section of the tab to define any persistence properties. In each instance, the persistence time begins whenever the point value drops below or rises above a state limit (by default, High-High, Low, and so on).

If, within the persistence time, the point value crosses a further limit in the same direction (that is, still continuing away from the Normal state, or still continuing toward the Normal state), the persistence period does not restart as it crosses the further limit. If the point value remains within the new state as the original persistence time elapses, the outstation updates the point state.

If the point value crosses back over a limit before the persistence time has elapsed, the point does not change state, and a new persistence time starts for the point value traveling in the new direction.

  • Away From Normal—Define the amount of time before the server updates the point state when the point value is moving away from the Normal State (toward Zero Scale or Full Scale).
  • Toward Normal—Define the amount of time before the server updates the point state when the point value is moving toward the Normal State (away from Zero Scale or Full Scale).

Example:

An analog point has this configuration:

Low Alarm Limit = 5.0
High Alarm Limit = 10.0
High-High Alarm Limit = 15.0

The Persistence properties are:

At 12:00:00 the point value is 8.0 (Normal).

At 12:00:10 the point value increases to 12.0, which is above the High limit.

At 12:00:20 the value of the point is still 12.0

At 12:00:30 the value of the point is still 12.0, so the point state changes to High as it has been 20 seconds since the value crossed the High Alarm Limit from the Normal state.

At 12:00:40 the value of the point further increases to 15.0 (the High-High Limit).

At 12:00:50 the point value is 15.0 (High-High).

At 12:01:00 the point value is still 15.0, so the point state changes to High-High as it has been 20 seconds since the value crossed the High-High Alarm Limit from the High State.

At 12:01:10 the point value decreases to 11.0, which is below the High-High Limit.

At 12:01:20 the point value is still 11.0

At 12:01:30 the point value is still 11.0

At 12:01:40 the point value is still 11.0, so the point changes state to High, as it has been 30 seconds since the value crossed the High-High Alarm Limit back toward the Normal State.

NOTE: Persistence does not apply when an analog point state becomes under range or over range (below Zero Scale, or above Full Scale), as these states are reported immediately.


OPC Driver Guide - Define the Background Logging Properties (Configuring Analog Points)

Define the Background Logging Properties

When ClearSCADA stores point values historically, as per the settings specified on the point’s Historic tab, the server typically only stores point changes—if a point does not change, no history is recorded during that period. If an OPC analog point’s value tends to change infrequently and that point’s data is used, for example, in a data export program, or is displayed on a Historic Trend, consider configuring ClearSCADA to store that point’s values historically at a defined interval, regardless of whether the point has changed. You specify such requirements using the fields in the Background Logging section of the OPC tab:

  • Enabled—Clear this check box if:
  • ClearSCADA is only to store point changes historically, as per the settings configured on the Historic tab (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration)

or:

  • ClearSCADA is not to store data historically for this point.

Select the Enabled check box if the driver is to store point values historically at a defined interval, regardless of whether the point’s value changes.

If you select this Enabled check box, you should also:

  • Select the Ignore Server Timestamps check box on the OPC Server Form (see Configuring the OPC Server Properties). This causes a unique time stamp to be assigned to each point value that ClearSCADA stores historically.
  • Set Historic to Enabled on the Point Form’s Historic tab.
  • Set Compression on the Historic tab to either apply to No Data, or Current Data Only. (You can also configure Compression to apply to All Data, but if you do this, you also need to set the Significant Change deadband to 0.)
  • The Timed Report check box is selected within the Historic Data Filter section of the Point Form’s OPC tab (see Define the Historic Data Storage Properties).
  • Interval—Use to specify the frequency with which ClearSCADA stores point values historically, regardless of whether they have changed.

Enter the required Interval in the OPC Time Format, for example 15M for ClearSCADA to store the point’s value historically at 15-minute intervals.

  • Offset—Use to specify the Background Logging start time—the amount of time that occurs before ClearSCADA logs the first point value historically. You need to define the time value and time unit from which the start time is to be offset from the present time. Specify the Offset in the OPC Relative Time Format. For example, specify H for ClearSCADA to start storing point values historically at the start of the present hour, and thereafter at the intervals specified in the Interval field, above.


OPC Driver Guide - Define the Historic Data Storage Properties (Configuring Analog Points)

Define the Historic Data Storage Properties

Use the fields within the Historic Data Filter section of the OPC tab to specify the type of data that ClearSCADA is to store historically for an analog point.

NOTE: Use the Historic Data Filter section in conjunction with the settings on the Historic tab. The Historic tab settings define whether the server stores values historically for the point, and whether any unnecessary data is filtered out to reduce storage requirements (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

The ClearSCADA server retrieves and processes the current data values from the OPC server(s) that it monitors. Use the check boxes within the Historic Data Filter section to specify the type of retrieved data that ClearSCADA is to store historically for a particular analog point:

  • Current Data—Select this check box to set ClearSCADA to store the point’s current values historically.

Clear the check box if you have no need for ClearSCADA to store the point’s values historically.

  • Timed Report—Select this check box if Background Logging is enabled for the point (see Define the Background Logging Properties). ClearSCADA will regularly stores the point’s value historically, regardless of whether the value has changed.

Clear the check box if Background Logging is not used for this point.

If neither of the check boxes above is selected, regardless of whether historic is enabled on the point’s Historic tab, ClearSCADA will not store retrieved point values historically.


OPC Driver Guide - Define which Configuration Properties are Retrieved from an OPC Source (Configuring Analog Points)

Define which Configuration Properties are Retrieved from an OPC Source

When a similar point property exists in an OPC data source, the OPC driver can retrieve the value of that property directly from the OPC data source. Retrieving the value of a configuration property in this way avoids the need for engineers to specify the property manually within the ClearSCADA database.

Use the Configuration Properties section of the OPC tab to specify which property values the OPC driver is to retrieve for an analog point, and the IDs that identify each of those properties in the OPC data source. For further information on using this section of the tab, see Retrieve Configuration Properties From an OPC Data Source.

For an analog point, you can specify whether the OPC driver is to retrieve the values for any of these properties:.

  • Search Key 1—If your system has been configured to display an extra configuration field on each Point Form and that field has been set up using Search Key 1, you can use the Search Key 1 check box on the OPC Analog Point Form to specify whether to retrieve the value of the Search Key 1 field from the OPC data source.

If selected, use the adjacent field to specify the property ID of the Search Key 1 parameter in the OPC data source. For more information on Search Key 1, see Retrieve the Value of a Search Key 1 Field.

  • Units—Use the check box to specify whether to retrieve the value of the Units field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Units parameter in the OPC data source.
  • Full Scale—Use the check box to specify whether to retrieve the value of the Full Scale field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Full Scale parameter in the OPC data source.
  • Zero Scale—Use the check box to specify whether to retrieve the value of the Zero Scale field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Zero Scale parameter in the OPC data source.
  • High High Limit—Use the check box to specify whether to retrieve the value of the High High Limit field from the OPC data source. If selected, use the adjacent field to specify the property ID of the High High Limit parameter in the OPC data source.
  • High Limit—Use the check box to specify whether to retrieve the value of the High Limit field from the OPC data source. If selected, use the adjacent field to specify the property ID of the High Limit parameter in the OPC data source.
  • Low Limit—Use the check box to specify whether to retrieve the value of the Low Limit field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Low Limit parameter in the OPC data source.
  • Low Low Limit—Use the check box to specify whether to retrieve the value of the Low Low Limit field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Low Low Limit parameter in the OPC data source.


OPC Driver Guide - Configuring Digital Points

Configuring Digital Points

The OPC driver supports Digital Input points and Digital Output points.

The points are used to map ‘point’ data on OPA servers into ClearSCADA in a format that it can understand, and vice versa.

Configure the properties of each digital point using the fields on the OPC Digital Point Form.

This section covers configuration of digital-specific properties on the OPC tab of the Form.

Use the fields on the OPC tab to:

  • Configure General Properties on the OPC Tab
  • Prevent Fleeting Changes in Value from Changing the Point State
  • Specify the Source Value of a Point
  • Define which Configuration Properties are Retrieved from an OPC Source.

For information on the fields on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC Driver Guide - Prevent Fleeting Changes in Value from Changing the Point State (Configuring Digital Points)

Prevent Fleeting Changes in Value from Changing the Point State

Use the Persistence field near the top of the OPC tab to prevent a change in value from affecting the point state until the point has been in that state for a specified time. This allows the driver to ignore fleeting changes in point value, and prevents ClearSCADA raising change of state alarms and logging change of state events when a point value is fluctuating.

When the point changes value, any change of point state is delayed until the point remains in the new state for a specified amount of time. If the point does not remain in the new state for the required amount of time, no change in point state is recorded.

  • Persistence—Use this field to specify the period, in seconds, that a point needs to remain in a new state before the OPC driver updates the ClearSCADA database with a change of value.


OPC Driver Guide - Define which Configuration Properties are Retrieved from an OPC Source (Configuring Digital Points)

Define which Configuration Properties are Retrieved from an OPC Source

When a similar point property exists in an OPC data source, the OPC driver can retrieve the value of that property directly from the OPC data source. Retrieving the value of a configuration property in this way avoids the need for engineers to specify the property manually within the ClearSCADA database.

Use the Configuration Properties section of the OPC tab to specify which property values the OPC driver is to retrieve for a digital point, and the IDs that identify each of those properties in the OPC data source. For further information on using this section of the tab, see Retrieve Configuration Properties From an OPC Data Source.

For a digital point, you can specify whether the OPC driver is to retrieve the values for any of these properties:

  • Search Key 1—If your system has been configured to display an extra configuration field on each Point Form and that field has been set up using Search Key 1, you can use the Search Key 1 check box on the OPC Digital Point Form to specify whether to retrieve the value of the Search Key 1 field from the OPC data source.

If selected, use the adjacent field to specify the property ID of the Search Key 1 parameter in the OPC data source. For more information on Search Key 1, see Retrieve the Value of a Search Key 1 Field.

  • State 0 Description—Use the check box to specify whether to retrieve the value of the State 0 Description field from the OPC data source. If selected, use the adjacent field to specify the property ID of the State 0 Description parameter in the OPC data source.
  • State 1 Description—Use the check box to specify whether to retrieve the value of the State 1 Description field from the OPC data source. If selected, use the adjacent field to specify the property ID of the State 1 Description parameter in the OPC data source.


OPC Driver Guide - Configuring String Points

Configuring String Points

Use OPC String points to map text strings on OPC servers into ClearSCADA.

Configure the properties of each String point using the fields on the OPC String Point Form.

For information the String Point tab on the String Point Form, see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the Control tab, see Define the Control Settings for a String Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on the OPC tab, see Configure General Properties on the OPC Tab, and see Specify the Source Value of a Point.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC Driver Guide - Configuring Time Points

Configuring Time Points

Use OPC Time points to map time values on OPC servers into ClearSCADA.

Configure the properties of each Time point using the fields on the OPC Time Point Form.

For information the Time Point tab on the Time Point Form, see Defining Time Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the Control tab, see Define the Control Settings for a Time Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on the OPC tab, see Configure General Properties on the OPC Tab, and see Specify the Source Value of a Point.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC Driver Guide - OPC Specific Status Display Attributes

OPC Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each OPC Server provides information about the present state of the individual server.

Use this section if you need information on the status of any OPC database items on your system.

This section covers those attributes that are OPC-specific, and includes:

  • OPC Server Status Attributes
  • OPC Scanner Status Attributes
  • OPC Point Status Attributes
  • Alphabetical List of OPC Specific Status Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


OPC Driver Guide - OPC Server Status Attributes (OPC Specific Status Display Attributes)

OPC Server Status Attributes

This status attribute is specific to OPC servers:

  • Source.


OPC Driver Guide - OPC Scanner Status Attributes (OPC Specific Status Display Attributes)

OPC Scanner Status Attributes

These status attributes are specific to OPC scanners:

  • Comms Statistics
  • Error Statistics
  • Source.


OPC Driver Guide - OPC Point Status Attributes (OPC Specific Status Display Attributes)

OPC Point Status Attributes

This status attribute is specific to OPC points:

  • Source.


OPC Driver Guide - Alphabetical List of OPC Specific Status Attributes (OPC Specific Status Display Attributes)

Alphabetical List of OPC Specific Status Attributes

This section lists those Status attributes that are specific to items on the OPC driver. The attributes are listed in alphabetical order and comprise:

  • Comms Statistics
  • Error Statistics
  • Source.


OPC Driver Guide - Comms Statistics (OPC Specific Status Display Attributes)

Comms Statistics

Associated with: OPC scanners

This status attribute indicates the number of:

  • Reads—Read operations performed by the scanner
  • Read items—Tags that have been read by the scanner
  • Writes—Write operations performed by the scanner

since that scanner was last restarted.

Example:

5 reads, 25 read items, 4 writes

Use the Error Statistics attribute to ascertain whether any of the above operations generated errors.


OPC Driver Guide - Error Statistics (OPC Specific Status Display Attributes)

Error Statistics

Associated with: OPC scanners

The Error Statistics attribute shows the number of errors generated during any of the read, conversion, or write operations that are summarized by the Comms Statistics attribute.

The Error Statistics indicate the number of occurrences of each of the following, since the scanner was last restarted:

  • Read errors—The number of errors generated when attempting to read items. For example, if the client OPC driver issues a read for an item, but the target OPC server returns an error.
  • Write errors—The number of errors reported from write operations.
  • Conversion errors—The number of conversion errors. A conversion error is generated if, for example, the target OPC server reports a value that is not compatible with the target point type.
  • Unknown item errors—The number of write completion messages that have been received for ‘unknown’ controls—controls that have not been sent by the ClearSCADA server.

Example:

0 read errors, 2 write errors, 3 conversion errors, 0 unknown item errors


OPC Driver Guide - Source (OPC Specific Status Display Attributes)

Source

Associated with: OPC servers, scanners, and points

The Source attribute for an OPC server or scanner varies, depending on the type of server.

For a Remote server or scanner, information is displayed in this format:

<OPC Server Node>.<OPC Program ID>

For a connection type that is ‘In Process’ or on a local server, information is displayed in this format:

<OPC Program ID>

Example:

PC305.SchneiderElectric.ClearSCADAOPCDA2PC305
(for a remote server (node PC305) running OPC program ID SchneiderElectric.ClearSCADAOPCDA2PC305)

The Source attribute for a point varies, depending on the type of server:

For a point on a remote server, information is displayed in this format:

<OPC Server Node>.<OPC Program ID>:<Tag Name>

For a point on a server with a connection type that is ‘In Process’ or on a local server, information is displayed in this format:

<OPC Program ID>:<Tag Name>

Example:

SchneiderElectric.ClearSCADAOPCDA2PC307:Western Site.Main CPU Usage

for a point monitoring the Main CPU Usage on the Western Site. The point resides on a local OPC server, which is running OPC Program ID SchneiderElectric.ClearSCADAOPCDA2PC307.


OPC XML-DA Client Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


OPC XML-DA Client Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


OPC XML-DA Client Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


OPC XML-DA Client Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


OPC XML-DA Client Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


OPC XML-DA Client Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure OPC XML-DA Client specific features and items in the ClearSCADA database. It also describes how to use the OPC XML-DA Client specific statistics and diagnostics.

For more details on the subjects covered in this guide, see Introduction to the OPC XML-DA Client Driver.


OPC XML-DA Client Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by engineers who are responsible for configuring OPC XML-DA Client-specific items and features. It can also be used by system administrators when investigating any unexpected behavior relating to the OPC XML-DA Client.


OPC XML-DA Client Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


OPC XML-DA Client Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to ViewX and WebX Clients.


OPC XML-DA Client Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


OPC XML-DA Client Driver Guide - Introduction to the OPC XML-DA Client Driver

Introduction to the OPC XML-DA Client Driver

The OPC standards are a series of standard specifications aimed at allowing inter operability between different SCADA systems. ClearSCADA uses these standards to allow transfer of data between the ClearSCADA server and third-party applications.

The OPC eXtensible Markup Language Data Access (XML-DA) standard is specifically aimed at facilitating the transmission of plant data over the internet (see Which Driver?).

ClearSCADA’s OPC XML-DA Client driver is used to read and/or write to data on XML-DA servers, including ClearSCADA or third-party servers, using the OPC XML-DA protocol. The driver enables ClearSCADA to communicate with servers that comply with OPC XML-DA version 1 or 2. The driver takes into account any security settings, designed to limit access to configuration properties on many OPC servers.

The OPC XML-DA documentation explains how to configure OPC XML-DA specific features and items within the ClearSCADA database (see Configuring OPC XML-DA Devices in ClearSCADA).

It also explains driver-specific aspects that may be of interest to system administrators and engineers when investigating unexpected system behavior (relating to the OPC XML-DA Driver). For more information, see OPC XML-DA Specific Status Display Attributes, and see OPC XML-DA Specific Driver Log File Options.

NOTE: There are no driver-specific pick actions for items on the OPC XML-DA Client driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

OPC Foundation Standards: see www.opcfoundation.org


OPC XML-DA Client Driver Guide - Which Driver? (Introduction to the OPC XML-DA Client Driver)

Which Driver?

ClearSCADA is able to read and/or write to data on other servers using one of several OPC standards. Whether you choose to use the ClearSCADA OPC Driver, or the ClearSCADA OPC XML-DA Driver, depends to some extent on your system setup. OPC DA is more efficient in terms of network bandwidth than OPC XML-DA. However, OPC DA is based on DCOM and can be difficult to set up when the driver and target OPC DA server are on opposite sides of a firewall. OPC XML-DA uses standard web protocol and is much more firewall friendly.

To choose the right driver for your requirements, you need to consider whether you place more significance on efficient use of network bandwidth or ease of setup:

  • If efficient use of network bandwidth is of greater importance to you than ease of setup, use the ClearSCADA OPC Driver to communicate using OPC DA.
  • If you regard ease of setup as more beneficial than efficient use of network bandwidth, use the ClearSCADA OPC XML-DA Driver to communicate using OPC XML-DA.


OPC XML-DA Client Driver Guide - Configuring OPC XML-DA Devices in ClearSCADA (Introduction to the OPC XML-DA Client Driver)

Configuring OPC XML-DA Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database reference the devices and plant that you are trying to monitor on your system. This section summarizes the database items that you need to configure in order to read and write to data on other servers, using the OPC XML-DA protocol.

To communicate with other servers using the OPC XML-DA protocol, the OPC XML-DA Client Driver has to be installed and running on the ClearSCADA servers on your system.

When you configure OPC XML-DA items in the ClearSCADA database, many of the settings for those items need to correspond to the settings on the relevant OPC XML-DA servers on your system. You need to have access to, or a list of, these settings before you can configure the OPC XML-DA database items successfully.

For instance, you need to know the read mechanism that is supported by the OPC XML-DA servers on your system, and the user names and passwords that allow the required level of access to the data on those servers.

You also need to be aware of which optional features are required for each OPC XML-DA item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with OPC XML-DA database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each OPC XML-DA device, you need to configure:

  1. OPC XML-DA Server(s) to specify the servers on which data is to be scanned, along with any access and security settings required to communicate with those servers.

You need to configure one OPC XML-DA Server item in the database for each server with which you want to communicate using the OPC XML-DA protocol (see Configuring an OPC XML-DA Server).

  2. OPC XML-DA Scanner(s) to specify which nodes are to be scanned and the rates at which the data is to be retrieved.

You need to configure a minimum of one OPC XML-DA Scanner per OPC XML-DA Server. You can attach multiple scanners to the same server. For instance, you might configure different scanner to have different scan rates or offsets, in order to retrieve some data at different intervals or times to other data.

For more information, see Configuring an OPC XML-DA Scanner.

  3. OPC XML-DA Points to represent the measuring instruments and control devices on the servers that are communicating using the OPC XML-DA protocol.

For more information, see Points Used on OPX XML-DA Scanners.

To minimize the time that it takes to configure the required OPC XML-DA items, you may want to configure them in the order listed above, as the scanner configuration requires that you specify a server, and point configuration requires that you specify a scanner, and so on.


OPC XML-DA Client Driver Guide - Configuring an OPC XML-DA Server

Configuring an OPC XML-DA Server

For every server with which you want ClearSCADA to communicate using the OPC XML-DA protocol, you need to configure an OPC XML-DA Server in the ClearSCADA database.

Before configuring an OPC XML-DA Server in the database, carry out any necessary Preparation. Then use the fields on the OPC XML-DA Server Form to configure the OPC XML-DA Server database item(s) on your system.

The Form has several tabs. Use the fields on the Server tab to define the connection properties that are required for successful communications with the node on which the OPC data is located (see Configure the OPC XML-DA Server Properties).

For information on the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional OPC XML-DA Server in ClearSCADA, see Minimum Configuration.


OPC XML-DA Client Driver Guide - Preparation (Configuring an OPC XML-DA Server)

Preparation

You need to add an OPC XML-DA Server for each server on your system with which you want ClearSCADA to communicate using the OPC XML-DA protocol.

To configure an OPC XML-DA Server, you need to know the location of the node on which the OPC data is located. You also need to know the read mechanism that is supported by the server, along with the user name(s) and password(s) that allow the required access to the data on that server.

You also need to establish which features are required for each OPC XML-DA server. You can configure each server to use a variety of features, including alarm redirection. However, many of these features are optional and have no effect on communications. The optional features include:

  • Alarm view
  • Alarm Redirection
  • User methods.

If the features listed above are not configured, they are not used for the selected server (they will be left blank).


OPC XML-DA Client Driver Guide - Minimum Configuration (Configuring an OPC XML-DA Server)

Minimum Configuration

For an OPC XML-DA Server to be functional (online), you need to specify the following settings (as a minimum):

  • The URL of the OPC XML-DA server (the node on which the OPC data is located)
  • The user name and password that are required to access the data on that server.

You also need to put the server In Service and save the configuration.

This will provide a functional OPC server that uses the default configuration.


OPC XML-DA Client Driver Guide - Configure the OPC XML-DA Server Properties (Configuring an OPC XML-DA Server)

Configure the OPC XML-DA Server Properties

Use the fields on the Server tab to configure an OPC XML-DA server’s connection properties:

  • In Service—Use to specify whether the OPC XML-DA server is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

NOTE: If you take the server out of service, its scanners and their dependants (such as points) also become out of service. This does not affect the configuration of the dependant items.

  • OPC Server URL—Enter the URL of the OPC XML-DA server that is to be interrogated.

Example:

http://XMLDASERVER/xmlda/

  • User Name—Reserved for future use. Leave blank.
  • Password—Reserved for future use. Leave blank.
  • Read Mode—Use this combo box to define how ClearSCADA is to interrogate the XML-DA server for data. Choose from:
  • Read (Basic Poll)—The driver periodically reads the points in a block.
  • Subscription (Basic Poll)—Only supported by some servers. The server is made aware of the tags that need to be polled. The driver periodically requests the server to transmit any data changes for those tags.

When supported by a server, Subscription (Basic Poll) mode is more bandwidth efficient than Read (Basic Poll) mode.

  • Severity—Use to define the severity of any alarms or events that are associated with the OPC XML-DA server (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Server tab. Use the field to specify the area with which any of the server’s alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.


OPC XML-DA Client Driver Guide - Configuring an OPC XML-DA Scanner

Configuring an OPC XML-DA Scanner

An OPC XML-DA Scanner is a logical grouping of XML tags that the OPC XML-DA driver scans at the same interval.

You can attach multiple scanners to each OPC XML-DA Server on your system. By specifying different scan rates and offsets, you can enable the OPC XML-DA Client driver to scan certain data at different intervals and times to other data on the same XML-DA server.

Configure the scanner’s properties using the fields on the OPC XML-DA Scanner Form.

The Form has several tabs.

Use the fields on the Scanner tab to specify the scan properties, such as the scan rate and offset (see Configure the Scanner Properties).

For fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional OPC XML-DA scanner in ClearSCADA, see Minimum Configuration.


OPC XML-DA Client Driver Guide - Minimum Configuration (Configuring an OPC XML-DA Scanner)

Minimum Configuration

For an OPC XML-DA scanner to become functional (online), you need to:

  • Specify the server on which it is to scan data
  • Put the scanner In Service and save the configuration.

This is the minimum configuration requirement and will result in a functional scanner that uses the default settings.


OPC XML-DA Client Driver Guide - Configure the Scanner Properties (Configuring an OPC XML-DA Scanner)

Configure the Scanner Properties

Use the fields on the Scanner tab to define the driver-specific properties of a scanner. Some of these fields are common to many scanners (see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the OPC XML-DA Client driver are described below.

  • Server—Use the browse button to select the name of the server on which the OPC XML-DA scanner is to scan data.


OPC XML-DA Client Driver Guide - Points Used on OPX XML-DA Scanners

Points Used on OPX XML-DA Scanners

OPC XML-DA Scanners read and write to data on OPC XML-DA servers. You need to map the data on each OPC XML-DA server to suitable OPC XML-DA Points within the ClearSCADA database, to enable ClearSCADA to handle the data in a similar way to other point data on the system (for instance, in order to monitor state changes, raise alarms, or execute controls).

The OPC XML-DA Client driver can support any of the point types that are listed below. You need to configure those point types that present the OPC XML-DA node data in a suitable format within the ClearSCADA database.

For information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

For information on configuring fields on the OPC XML-DA tab, see the rest of this section, which explains how to:

  • Configure Common Point Properties on the OPC XML-DA Tab
  • Retrieve Configuration Properties from an OPC Data Source.

For analog points, also see Configuring Analog Points.

For digital points, also see Configuring Digital Points.

For information on configuring fields on the <Point Type> tab, see the references below:

  • Analog Point—see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.
  • Digital Point—see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.
  • String Point—see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration.
  • Time Point—see Defining Time Point Details in the ClearSCADA Guide to Core Point Configuration.

For each point, use the Enabled check box on the Control tab to specify whether a particular point is used as an Input point to retrieve data, or as an Output point to write data to an OPC XML-DA server. For information on the Control tab, see the ClearSCADA Guide to Core Point Configuration.

For fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC XML-DA Client Driver Guide - Configure Common Point Properties on the OPC XML-DA Tab (Points Used on OPX XML-DA Scanners)

Configure Common Point Properties on the OPC XML-DA Tab

Use the fields at the top of the OPC XML-DA tab to configure the general point properties of each point. Some of these fields are common to many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to points on the OPC XML-DA Client driver are explained below:

  • Tag Name—Within OPC terminology, ‘point’ values on OPC XML-DA servers are referred to as tags.

Use the Tag Name field to specify the item of data that you want to monitor in ClearSCADA, for example a particular analog tag. Select the browse button to display a Reference browse window and then select the required OPC tag from the window.

Example:

Points.Overflow Monitor.Level

(Where a dot separator (.) indicates each hierarchical level that is used to specify the location of the tag data on the XML-DA server.)


OPC XML-DA Client Driver Guide - Retrieve Configuration Properties from an OPC Data Source (Points Used on OPX XML-DA Scanners)

Retrieve Configuration Properties from an OPC Data Source

When a similar point property exists in an OPC data source, the OPC XML-DA Client driver can retrieve the value of that property directly from the OPC data source. For example, for an OPC XML-DA analog point, the driver can retrieve the values of the Full Scale and Zero Scale properties from the OPC data source for that point. Retrieving the value of a configuration property in this way avoids the need for engineers to specify the property manually within the ClearSCADA database.

The OPC XML-DA Client driver retrieves the values of any point properties that are enabled for retrieval, when it first connects to the specified OPC data source.

Use the Configuration Properties section of the OPC XML-DA tab to specify which property values the OPC XML-DA Client driver is to retrieve for an analog or digital point, and the IDs that identify each of those properties in the OPC data source.

For each configuration property, either:

  • Select the corresponding check box if the OPC XML-DA Client driver is to retrieve the property value from the OPC data source. Specify the property ID in the adjacent field.
  • Clear the check box for any property for which the OPC XML-DA Client driver is unable to retrieve a value. For example, clear the check box for a property if the OPC data source does not have a correlating configuration property.

The configuration properties that the driver can retrieve vary, depending on the point type. For analog points, see Define which Configuration Properties are Retrieved from an OPC Source. For digital points, see Define which Configuration Properties are Retrieved from an OPC Source.

Select the check box for the OPC XML-DA Client driver to retrieve the property value from the data source...
...then specify the property ID of the corresponding parameter in the OPC data source.

Further Information

Retrieve the Value of a Search Key 1 Field.


OPC XML-DA Client Driver Guide - Retrieve the Value of a Search Key 1 Field (Points Used on OPX XML-DA Scanners)

Retrieve the Value of a Search Key 1 Field

A system administrator can add additional configuration fields to Forms when a ClearSCADA system is first set up. The fields are set on a per database basis and can be added if additional configuration properties or point values need displaying, which are specific to your system or application.

Where an additional configuration field is required to display information in alphanumeric text format, this is added to the ClearSCADA database in the form of a Search Key field.

If your system has been configured to display an extra configuration field on each Point Form and that field has been set up using Search Key 1, you can use the Search Key 1 check box on an OPC XML-DA Point Form to specify whether to retrieve the value of the Search Key 1 field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Search Key 1 parameter in the OPC data source (see Retrieve Configuration Properties from an OPC Data Source).

Search Keys are configured using the Metadata window in ViewX (see Extra Database Fields in the ClearSCADA Guide to Server Administration).

For the Search Key 1 field to appear on the Point Form, Search Key 1 has to be configured to reference the CDBPoint database table. This reference is made using the Metadata window. Search Key fields that reference this table appear as fields on an additional Point tab on the Point Configuration Form for each point on the system. Each Search Key field is given the size, position and (if applicable) label that is specified for that field in the Metadata window.


OPC XML-DA Client Driver Guide - Configuring Analog Points

Configuring Analog Points

Use OPC XML-DA Analog Points to map analog ‘point’ data on OPC XML-DA servers into ClearSCADA in a format that it can understand, and vice versa.

Configure the properties of each Analog point using the fields on the OPC XML-DA Analog Point Form.

This section covers configuration of the analog-specific properties on the OPC XML-DA tab of the Form.

Use the OPC XML-DA tab to:

  • Configure Common Point Properties on the OPC XML-DA Tab
  • Configure Point Scaling (see Scale Analog Values for use in ClearSCADA in the ClearSCADA Guide to Simple Drivers)
  • Configure Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration)
  • Define which Configuration Properties are Retrieved from an OPC Source.

For information the Analog Point tab on the Analog Point Form, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the Control tab, see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC XML-DA Client Driver Guide - Define which Configuration Properties are Retrieved from an OPC Source (Configuring Analog Points)

Define which Configuration Properties are Retrieved from an OPC Source

When a similar point property exists in an OPC data source, the OPC XML-DA Client driver can retrieve the value of that property directly from the OPC data source. Retrieving the value of a configuration property in this way avoids the need for engineers to specify the property manually within the ClearSCADA database.

Use the Configuration Properties section of the OPC XML-DA tab to specify which property values the OPC XML-DA Client driver is to retrieve for an analog point, and the IDs that identify each of those properties in the OPC data source. For further information on using this section of the tab, see Retrieve Configuration Properties from an OPC Data Source.

For an analog point, you can specify whether the OPC XML-DA Client driver is to retrieve the values for any of these properties:

  • Search Key 1—If your system has been configured to display an extra configuration field on each Point Form and that field has been set up using Search Key 1, you can use the Search Key 1 check box on the OPC XML-DA Analog Point Form to specify whether to retrieve the value of the Search Key 1 field from the OPC data source.

If selected, use the adjacent field to specify the property ID of the Search Key 1 parameter in the OPC data source. For more information on Search Key 1, see Retrieve the Value of a Search Key 1 Field.

  • Units—Use the check box to specify whether to retrieve the value of the Units field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Units parameter in the OPC data source.
  • Full Scale—Use the check box to specify whether to retrieve the value of the Full Scale field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Full Scale parameter in the OPC data source.
  • Zero Scale—Use the check box to specify whether to retrieve the value of the Zero Scale field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Zero Scale parameter in the OPC data source.
  • High High Limit—Use the check box to specify whether to retrieve the value of the High High Limit field from the OPC data source. If selected, use the adjacent field to specify the property ID of the High High Limit parameter in the OPC data source.
  • High Limit—Use the check box to specify whether to retrieve the value of the High Limit field from the OPC data source. If selected, use the adjacent field to specify the property ID of the High Limit parameter in the OPC data source.
  • Low Limit—Use the check box to specify whether to retrieve the value of the Low Limit field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Low Limit parameter in the OPC data source.
  • Low Low Limit—Use the check box to specify whether to retrieve the value of the Low Low Limit field from the OPC data source. If selected, use the adjacent field to specify the property ID of the Low Low Limit parameter in the OPC data source.


OPC XML-DA Client Driver Guide - Configuring Digital Points

Configuring Digital Points

Use OPC XML-DA Digital Points to map digital ‘point’ data on OPC XML-DA servers into ClearSCADA in a format that it can understand, and vice versa.

Configure the properties of each Digital point using the fields on the OPC XML-DA Digital Point Form.

This section covers configuration of the digital-specific properties on the OPC XML-DA tab of the Form.

Use the OPC XML-DA tab to:

  • Configure Common Point Properties on the OPC XML-DA Tab
  • Define which Configuration Properties are Retrieved from an OPC Source.

For information the Digital Point tab on the Digital Point Form, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the Control tab, see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC XML-DA Client Driver Guide - Define which Configuration Properties are Retrieved from an OPC Source (Configuring Digital Points)

Define which Configuration Properties are Retrieved from an OPC Source

When a similar point property exists in an OPC data source, the OPC XML-DA Client driver can retrieve the value of that property directly from the OPC data source. Retrieving the value of a configuration property in this way avoids the need for engineers to specify the property manually within the ClearSCADA database.

Use the Configuration Properties section of the OPC XML-DA tab to specify which property values the OPC XML-DA Client driver is to retrieve for a digital point, and the IDs that identify each of those properties in the OPC data source. For further information on using this section of the tab, see Retrieve Configuration Properties from an OPC Data Source.

For a digital point, you can specify whether the OPC XML-DA Client driver is to retrieve the values for any of these properties:

  • Search Key 1—If your system has been configured to display an extra configuration field on each Point Form and that field has been set up using Search Key 1, you can use the Search Key 1 check box on the OPC XML-DA Digital Point Form to specify whether to retrieve the value of the Search Key 1 field from the OPC data source.

If selected, use the adjacent field to specify the property ID of the Search Key 1 parameter in the OPC data source. For more information on Search Key 1, see Retrieve the Value of a Search Key 1 Field.

  • State 0 Description—Use the check box to specify whether to retrieve the value of the State 0 Description field from the OPC data source. If selected, use the adjacent field to specify the property ID of the State 0 Description parameter in the OPC data source.
  • State 1 Description—Use the check box to specify whether to retrieve the value of the State 1 Description field from the OPC data source. If selected, use the adjacent field to specify the property ID of the State 1 Description parameter in the OPC data source.


OPC XML-DA Client Driver Guide - Configuring String Points

Configuring String Points

Use OPC XML-DA String Points to map text strings on OPC XML-DA servers into ClearSCADA.

Configure the properties of each String point using the fields on the OPC XML-DA String Point Form.

For information the String Point tab on the String Point Form, see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on the OPC XML-DA tab, see Configure Common Point Properties on the OPC XML-DA Tab.

For information on the Control tab, see Define the Control Settings for a String Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC XML-DA Client Driver Guide - Configuring Time Points

Configuring Time Points

Use OPC XML-DA Time Points to map time values on OPC XML-DA servers into ClearSCADA.

Configure the properties of each Time point using the fields on the OPC XML-DA Time Point Form.

For information the Time Point tab on the Time Point Form, see Defining Time Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on the OPC XML-DA tab, see Configure Common Point Properties on the OPC XML-DA Tab.

For information on the Control tab, see Define the Control Settings for a Time Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


OPC XML-DA Client Driver Guide - OPC XML-DA Specific Status Display Attributes

OPC XML-DA Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each point provides information about the present state of the individual point.

Use this section if you need information on the status of any OPC XML-DA database items on your system.

This section explains those attributes that are OPC XML-DA specific:

  • OPC XML-DA Server Status Attributes
  • OPC XML-DA Scanner Status Attributes
  • OPC XML-DA Point Status Attributes
  • Alphabetical List of OPC XML-DA Specific Status Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


OPC XML-DA Client Driver Guide - OPC XML-DA Server Status Attributes (OPC XML-DA Specific Status Display Attributes)

OPC XML-DA Server Status Attributes

This status attribute is specific to OPC XML-DA servers:

  • Source.


OPC XML-DA Client Driver Guide - OPC XML-DA Scanner Status Attributes (OPC XML-DA Specific Status Display Attributes)

OPC XML-DA Scanner Status Attributes

These status attributes are specific to OPC XML-DA scanners:

  • Comms Statistics
  • Error Statistics
  • Source.


OPC XML-DA Client Driver Guide - OPC XML-DA Point Status Attributes (OPC XML-DA Specific Status Display Attributes)

OPC XML-DA Point Status Attributes

This status attribute is specific to OPC XML-DA points:

  • Source.


OPC XML-DA Client Driver Guide - Alphabetical List of OPC XML-DA Specific Status Attributes (OPC XML-DA Specific Status Display Attributes)

Alphabetical List of OPC XML-DA Specific Status Attributes

This section lists those status attributes that are specific to items on the OPC XML-DA Client driver. The attributes comprise:

  • Comms Statistics
  • Error Statistics
  • Source.


OPC XML-DA Client Driver Guide - Comms Statistics (OPC XML-DA Specific Status Display Attributes)

Comms Statistics

Associated with: OPC XML-DA scanners

This attribute indicates the number of:

  • Reads—Read operations performed by the scanner
  • Read Items—Tags that have been read by the scanner
  • Writes—Write operations performed by the scanner
  • Connection Closes—Connection closures received from the server

since the scanner was last restarted.

Example:

42 reads, 30 read items, 12 writes, 0 connection closes

Use the Error Statistics attribute to ascertain whether any of the read or write operations listed above generated errors.


OPC XML-DA Client Driver Guide - Error Statistics (OPC XML-DA Specific Status Display Attributes)

Error Statistics

Associated with: OPC XML-DA scanners

The Error Statistics attribute shows the number of errors generated during any of the read or write operations that are summarized by the Comms Statistics attribute.

The Error Statistics indicate the number of occurrences of each of the following since the scanner was last restarted:

  • Read Errors—The number of errors generated when attempting to read items. For example, if the OPC XML-DA Client driver issues a read for the item, but the target OPC XML-DA server returns an error.
  • Write Errors—The number of errors reported from write operations.
  • Unknown Item Errors—The number of write completion messages that have been received for ‘unknown’ controls (controls that have not been sent by the ClearSCADA server).

Example:

2 read errors, 2 write errors, 0 unknown item errors


OPC XML-DA Client Driver Guide - Source (OPC XML-DA Specific Status Display Attributes)

Source

Associated with: OPC XML-DA servers, scanners, and points

The Source attribute is common to many Status Displays. The attribute indicates the location at which the item resides. The information shown varies, depending on the item.

For an OPC XML-DA server, or an OPC XML-DA scanner, information is displayed in this format:

<OPC Server URL>

Example:

http://XMLDASERVER/xmlda/

For an OPC XML-DA point, information is displayed in this format:

<OPC Server URL>:<Tag Name>

Example:

http://XMLDASERVER/xmlda/:Points.Alarm
(for a point with the Tag Name ‘Points.Alarm’, on the OPC server that has the URL http://XMLDASERVER/xmlda/.)


OPC XML-DA Client Driver Guide - OPC XML-DA Specific Driver Log File Options

OPC XML-DA Specific Driver Log File Options

This section is designed for use by system administrators and high-level engineers when assessing the state of the ClearSCADA system. It contains information on those driver logging options that are specific to the OPC XML-DA Client driver, and should be used in conjunction with the generic simple driver documentation (see System Analysis in the ClearSCADA Guide to Simple Drivers).

These driver logging options are specific to the OPC XML-DA Client driver:

  • Raw Data—Logs the raw TCP/IP data that is sent to, and received from, the target OPC XML-DA server.
  • XML Data—Logs the XML-DA SOAP requests to, and responses from, the target OPC XML-DA server.

(Simple Object Access Protocol (SOAP) is a communications protocol that enables the database items created using one system to invoke actions on the items that have been created using another system.)

For more information on driver logging, and for information on the other driver logging options that are available to the OPC XML-DA Client driver, see Driver Log File Options that are Common to Many Simple Drivers in the ClearSCADA Guide to Simple Drivers.


Performance Monitor Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Performance Monitor Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Performance Monitor Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Performance Monitor Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Performance Monitor Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Performance Monitor Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure Windows Performance Monitor-specific features and items in the ClearSCADA database. It also describes how to use driver-specific features for diagnostics.

For more information on the subjects covered in this Guide, see Introduction to the Performance Monitor Driver.


Performance Monitor Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by engineers who are responsible for the configuration of Performance Monitor items and features in ClearSCADA. It can also be used by system administrators when investigating the cause of unexpected behavior relating to the Performance Monitor driver.


Performance Monitor Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Performance Monitor Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


Performance Monitor Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Performance Monitor Driver Guide - Introduction to the Performance Monitor Driver

Introduction to the Performance Monitor Driver

The Performance Monitor driver (sometimes referred to as NTMon) uses Performance Monitor scanners in conjunction with Performance Monitor points to monitor various aspects of performance on a ClearSCADA system.

Each Performance Monitor scanner defines which computer is scanned and how often the scans occur.

Each Performance Monitor point defines which particular aspect of system performance (for example, CPU Usage) is monitored.

A wide variety of performance attributes can be monitored. The attributes that you can monitor vary, depending on the version of Windows® that is running on each PC, and the system setup.

The Performance Monitor documentation explains how to configure Performance Monitor-specific features and items within the ClearSCADA database (see Configure Performance Monitor Devices in ClearSCADA).

It also explains the driver-specific aspects that can be used by System Administrators and engineers when investigating unexpected system behavior (relating to the Performance Monitor driver). For more information on the statistics and diagnostics that are available, see Performance Monitor Specific Status Display Attributes.

NOTE: There are no driver-specific pick actions for items on the Performance Monitor driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

NOTE: To access the driver log file options for the Performance Monitor driver, you select the NTMon driver entry in the Modules section of the ClearSCADA Server Status Tool. (For more information on driver log file options, see Define the Driver Logging Settings in the ClearSCADA Guide to Server Administration.)


Performance Monitor Driver Guide - Configure Performance Monitor Devices in ClearSCADA (Introduction to the Performance Monitor Driver)

Configure Performance Monitor Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database reference the devices and attributes that you are trying to monitor on your system. This section summarizes the database items that you need to configure in order to monitor aspects of system performance.

In order to monitor system performance, the Performance Monitor Driver has to be installed and running on the ClearSCADA servers on your system. When the driver is first installed, a System Administrator needs to define the server settings for the driver (see Configuring Performance Monitor Server Settings).

When you configure Performance Monitor items in the ClearSCADA database, many of the settings for those items need to correspond to the settings on the relevant nodes (computers or workstations) on your system. You need to have access to, or a list of, these settings before you can configure the Performance Monitor database items successfully.

For instance, you need to know the node names of the computers on your system, and the aspects of system performance that need to be monitored on each node.

You also need to be aware of which optional features are required for each Performance Monitor item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with Performance Monitor database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each device that ClearSCADA is to scan for performance data, you need to configure:

  1. At least one Performance Monitor Scanner per node (computer or workstation) (see Configuring a Performance Monitor Scanner). (For the driver to scan performance data at different rates on the same node, configure one scanner per required scan rate on that node.)
  2. One Performance Monitor Analog Point per item of system performance that the driver is to monitor on a node (see Configuring Analog Points).

To minimize the time that it takes to configure the required Performance Monitor items, you may want to configure them in the order listed above, as the Point configuration requires that you specify a scanner, and so on.

You may also be able to use a Group Template to reduce the amount of effort and time required to configure the Performance Monitor items for your system. You can create a ‘Performance Monitor’ Group Template that contains a scanner and appropriately configured analog points, and then use that ‘model’ configuration as the basis for Group Instances. You would create a Group Instance that references the ‘Performance Monitor’ Group Template for each node that is to have its performance monitored. For further information, see Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration.


Performance Monitor Driver Guide - Access Data on Machines Running a Version of Windows that has Tightened Security (Introduction to the Performance Monitor Driver)

Access Data on Machines Running a Version of Windows that has Tightened Security

Recent versions of Microsoft Windows®, such as Windows Vista, Windows Server 2008, and Windows 7, have tighter security than earlier versions of Windows®. As a result, access to performance data is restricted to users that are members of a suitable user group, such as the ‘Performance Monitor Users’ group in Windows Vista.

For the driver to access and monitor performance data on machines that are running a version of Windows that has tightened security:

  • On each of the target nodes (workstations) on which ClearSCADA is to monitor performance data, either create a suitable Windows user account, or modify an existing suitable account so that it provides the necessary access.

To access performance data on remote node(s), the driver needs to use a suitable Domain user account. (A remote node is another computer or workstation that is connected to the same network as the local ClearSCADA server.)

To access performance data on the local machine (the machine on which you are configuring the server settings), the driver can use a suitable local Windows user account (one that has been configured directly on that PC) or a Domain user account.

In each case, the user account has to be a member of the relevant user group (such as the ‘Performance Monitor Users’ group on Windows Vista).

  • If ClearSCADA is to monitor data on remote nodes, set the ‘Remote Registry’ service to start up automatically on those remote nodes.
  • On the ClearSCADA Server(s):
  • Configure the security properties to allow the Windows user account to ‘Log in as a Service’
  • Use the Performance Monitor section of the ClearSCADA Server Configuration Tool to specify the user account details (see Configuring Performance Monitor Server Settings)
  • Create suitable Performance Monitor Scanner(s) and analog points to monitor the required data (see Configure Performance Monitor Devices in ClearSCADA).

For further information on local and domain user accounts, Windows security settings, and the ‘Remote Registry’ service, refer to the documentation supplied with your operating system.


Performance Monitor Driver Guide - Monitor Performance Data on Remote Nodes (Introduction to the Performance Monitor Driver)

Monitor Performance Data on Remote Nodes

You can use the Performance Monitor driver to gather performance statistics locally, from the server on which the ClearSCADA database resides, or from remote nodes.

This section provides further information about using the Performance Monitor driver to gather data from remote nodes (other computers or workstations that are connected to the ClearSCADA network).

For the driver to gather data from remote nodes, you need to use the Performance Monitor section of the ClearSCADA Server Configuration Tool to specify:

  • the network Domain on which the remote nodes are located
  • the Username and Password of a suitable user account on that network domain. The user account has to provide suitable access to the remote nodes and properties that the Performance Monitor driver is to monitor.

For further information, see Configuring Performance Monitor Server Settings.

Due to the way Windows® works, the ‘System’ account, which is used by many services such as ClearSCADA, does not have permission to access the network. Therefore either a new domain user account needs to be created, or a suitable existing account be modified and used to provide the necessary access.

On the ClearSCADA Server(s), configure the security properties so that they allow the domain user account to ‘Log in as a Service’.

On each of the client (target) nodes on which ClearSCADA is to monitor statistics:

  • configure the security properties so that the domain user account has appropriate access rights
  • configure any further settings that are required if the nodes are running a version of Windows that has tightened security (see Access Data on Machines Running a Version of Windows that has Tightened Security).

Further Information

For an example that demonstrates how you might configure ClearSCADA to monitor performance statistics on remote nodes, see Example Configuration.


Performance Monitor Driver Guide - Configuring Performance Monitor Server Settings

Configuring Performance Monitor Server Settings

Some driver-specific settings need configuring on the server by a system administrator when a ClearSCADA system is first installed. These settings are configured using the ClearSCADA Server Configuration tool.

For information on how to access the ClearSCADA Server Configuration tool, and for general information on server settings, see Configuring Simple Driver Server Settings in the ClearSCADA Guide to Simple Drivers.

The rest of this section explains the settings that are specific to the Performance Monitor section of the Tool.

To monitor data on machines that are running a version of Windows® that has tightened security (such as Windows Vista, Windows 2008, or Window 7), you need to use the fields within the Performance Monitor section to specify a suitable Windows user account. A suitable user account is required to enable the Performance Monitor driver to monitor performance data locally (on the machine on which you are configuring the settings) or remotely. The user account has to be a member of the relevant user group (for instance, the ‘Performance Monitor Users’ group in Windows Vista.) For more information on this and other requirements to enable ClearSCADA to access performance data on such machines, see Access Data on Machines Running a Version of Windows that has Tightened Security.

To monitor data on machines that are running an earlier supported version of Windows (such as Windows 2003 or Windows XP), you can leave the fields clear for the driver to monitor performance data locally. With the fields clear, the driver will attempt to monitor performance data using the same Windows user account as the ClearSCADA server (the local ‘System’ account, by default).To monitor performance data on remote nodes (other computers or workstations that are connected to the ClearSCADA network), you need to need to specify the network domain, and any user name and password settings that will enable the driver to connect successfully to those machines and access the performance data. For more information, see Monitor Performance Data on Remote Nodes.

ATTENTION: If you make changes on a server, you will also need to configure the same changes on the other servers in the system architecture (with the exception of permanent standby servers).

The User fields shown below are located within the Performance Monitor section of the ClearSCADA Server Configuration tool:

  • Username—To monitor data locally or remotely on a machine that is running a version of Windows that has tightened security (such as Windows Vista), specify the user name of a suitable Windows user account. The user account has to provide suitable access to the node(s) and properties that the Performance Monitor driver is to monitor (see Access Data on Machines Running a Version of Windows that has Tightened Security).

To monitor performance data remotely on machines that are running an earlier supported version of Windows, use the field to specify the name of a suitable domain user account (see Monitor Performance Data on Remote Nodes).

To monitor data locally on a machine that is running an earlier supported version of Windows, use this field to enter the user name of a suitable local Windows user account if required, or leave the field blank. If the field is left blank, the Performance Monitor driver will attempt to access the performance data using the same Windows user account as the ClearSCADA server (the local ‘System’ account, by default).

  • Password—Specify the password of the user account for which you specified the Username in the field above.

To monitor data locally on a machine running a version of Windows that does not have tightened security, you can leave this field blank (unless you have entered a Username in the field above).

  • Domain—To monitor performance data remotely, specify the network domain on which the Windows user account is registered. The domain has to be the one on which the computers or workstations that you want to monitor are located. (A domain is a subdivision of a network, within which a group of computers share a common directory, security information and user accounts.)

To monitor performance data on the local machine:

  • If the driver accesses performance monitor data via a Domain user account, specify the name of that Domain
  • If the driver accesses performance monitor data via a local user account, you can either specify the workstation name or leave the Domain field blank.
  • Leave the Domain field blank if the local machine is running a version of Windows that does not have tightened security and the driver is using the same Windows account as the ClearSCADA server (the local ‘System’ account, by default). (The Performance Monitor driver uses the same Windows user account as the ClearSCADA server when the Username, Password, and Domain fields are left blank.)

You will need to restart the driver for any changes to come into effect (see Configuring Simple Driver Server Settings in the ClearSCADA Guide to Simple Drivers).

NOTE: If a user with insufficient privileges is specified in the fields above, a diagnostics message(s) is displayed, and either the affected scanners or points will display a Quality of ‘Bad’, or the driver will refuse to start and the Quality attribute will display ‘Device Failure’. (You can view Quality attributes in a Status display or on a List.) If this occurs, either adjust the user’s access privileges so that they are suitable, or specify the user name and password for a user that already has the necessary privileges.


Performance Monitor Driver Guide - Configuring a Performance Monitor Scanner

Configuring a Performance Monitor Scanner

A Performance Monitor Scanner is logical functionality that runs within ClearSCADA and monitors aspect(s) of system performance on a node (any computer or workstation) that is connected to the ClearSCADA network.

Example:

A Performance Monitor Scanner, ‘Disk Scan’, is configured to scan a server, and monitor the number of available bytes of memory, and the percentage of free space on the hard disk. An alarm is raised if memory usage or disk usage goes over a particular percentage.

You need to configure a separate Performance Monitor Scanner for every node (computer or workstation) that you want to monitor. To scan performance data at different rates on the same node, configure one Performance Monitor Scanner per required scan rate on that node.

Configure the Scanner features using the fields on the Performance Monitor Scanner Form.

The Form has several tabs.

Use the fields on the Scanner tab to specify the scan properties, such as the scan rate and offset (see Configure the Scanner Properties).

For fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional Performance Monitor Scanner in ClearSCADA, see Minimum Configuration.


Performance Monitor Driver Guide - Minimum Configuration (Configuring a Performance Monitor Scanner)

Minimum Configuration

For a Performance Monitor scanner to become functional (online), you need to specify the node on which it is to scan performance data (as a minimum).

You also need to put the scanner In Service, and save the configuration.

This will result in a functional scanner that uses the default configuration settings.


Performance Monitor Driver Guide - Configure the Scanner Properties (Configuring a Performance Monitor Scanner)

Configure the Scanner Properties

Use the fields on the Scanner tab to define the driver-specific properties of a scanner. Some of these fields are common to many scanners (for information, see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the Performance Monitor driver are described below.

  • Node—Use to specify the computer or workstation on which the performance data (the data that the scanner is to monitor) is located.

In a Main/Standby setup, leave the field blank if the scanner is to monitor data on whichever server is Main.

Please be aware that you will need to use the ClearSCADA Server Configuration Tool to specify the user account for accessing the node if:

  • The scanner is to monitor data on a remote node (another computer or workstation that is connected to the ClearSCADA network)
  • The scanner is to monitor data on a machine that is running a version of Windows that has tightened security

For more information on specifying the user account for accessing the node (see Configuring Performance Monitor Server Settings).


Performance Monitor Driver Guide - Configuring Analog Points

Configuring Analog Points

The Performance Monitor driver uses Performance Monitor Analog Input points to reference the individual system performance attributes that it is to monitor, and to define how that performance data is to be managed within ClearSCADA.

Example:

Two Performance Monitor Analog points monitor aspects of performance on a ClearSCADA server.

One analog point monitors the available bytes of memory on the server, and raises an alarm if this drops below a certain percentage.

Another analog point monitors the available disk space on the server, and is configured to raise an alarm when the disk containing the historic data reaches 75% full. The alarm indicates that the amount of historic data being stored is too great and may need to be reduced (for example, by reducing the data’s life time, or re-configuring some points to store less historic data).

Configure a separate Performance Monitor Analog point for each performance attribute that you want to monitor on a particular node.

Configure the properties of each analog point using the fields on the Performance Monitor Analog Point Form.

The Form contains several tabs.

This section covers configuration of properties on the Performance Monitor tab of the Form (see Configure the Performance Monitor Properties).

For information on the fields on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

Further Information

For more information on configuring Performance Monitor points to monitor the free disk space on each of the servers on a ClearSCADA system, see Monitor the Available Disk Space in the ClearSCADA Guide to Server Administration.


Performance Monitor Driver Guide - Configure the Performance Monitor Properties (Configuring Analog Points)

Configure the Performance Monitor Properties

Use the fields on the Performance Monitor tab to define the driver-specific properties of an analog point. For information on those fields that are common to points on many simple drivers, see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers. Fields that are specific to analog points on the Performance Monitor driver are described below.

  • Tag—Use to specify the particular aspect of system performance that this analog point is to represent within ClearSCADA. Select the browse button to display a Reference browse window, and select the required attribute from the window.

Use the properties on the various tabs of the Analog Point Form to define how the performance data is to be managed within ClearSCADA.

  • Multiplier—Use this field to specify what calculation the driver is to perform on the raw performance value, for use within ClearSCADA.

Leave the value at the default of 1 if the raw value is to be used within ClearSCADA without further processing.

Example:

A Performance Monitor Analog Point is configured to monitor a server’s Memory Usage. The Memory Usage is in bytes on the server. This is to be represented in kilobytes within ClearSCADA, therefore a Multiplier of 0.0009765625 (the decimal equivalent of 1/1024) is used to convert the raw value from bytes to kilobytes.

  • Update Value on Every Scan—Use this check box to specify whether the scanner is to update the value of this point in ClearSCADA every time the point’s source is scanned, regardless of whether the value has changed.

Select the check box if the value of the point is to be updated whenever its source is scanned. Select the check box if, for example, the point’s value is to trigger Logic program(s) whenever a scan occurs, or if the point value rarely changes and you want ClearSCADA to use a recently retrieved value.

Clear the check box if the value of the point is only to be updated in ClearSCADA if its value has changed from the last recorded value. A point that is associated with an attribute that regularly changes, for example, need only be updated if such a change has occurred.


Performance Monitor Driver Guide - Example Configuration

Example Configuration

This example demonstrates how ClearSCADA might be configured to gather statistics from remote PCs. To access such data on remote machines, the Performance Monitor driver needs to log onto those machines using a suitable domain user account (see Configuring Performance Monitor Server Settings, and see Monitor Performance Data on Remote Nodes).

Example:

The Performance Monitor driver on a ClearSCADA system is used to monitor various statistics on the ClearSCADA client machines.

As the machines are in the same network domain as the server, a Domain account is created, which allows the ClearSCADA server to access each machine. (If the machines were in different domains, separate accounts would need creating for each domain. If suitable account(s) already exist on a system, these can be modified and used, instead of creating new accounts.)

On the ClearSCADA server(s), the security properties are configured to allow the Domain account user to ‘Log in as a Service’.

On each of the client (target) machines on which statistics are to be monitored, the security properties are configured to give the Domain account user access to the relevant performance data. (If the target machines were running a version of Windows® that has tightened security, the machines’ ‘Remote Registry’ would also need to be set to start up automatically (see Access Data on Machines Running a Version of Windows that has Tightened Security).)

The ClearSCADA Server Configuration tool is run. The details of the above Domain account are specified on the Performance Monitor section of the tool:

The Performance Monitor driver is restarted.

One Performance Monitor Scanner is added to the ClearSCADA database for each machine that the ClearSCADA server is to monitor. The Node field on each Performance Monitor Scanner Form is configured to reference the machine that each Scanner is to monitor.

The Node field on each Scanner Form is used to specify the PC that the scanner is to monitor.

A set of Performance Monitor Analog points are added to the ClearSCADA database—one point per statistic that is to be monitored on a PC. The configuration of each point is suitably adjusted. In the figure below, for instance, an Analog point is used to monitor the available bytes on the machine PC12. The Multiplier is used to convert the bytes into kilobytes.

Operators are then able to view the statistics using, for example, a List:

Further Information

Configuring a Performance Monitor Scanner.

Configuring Performance Monitor Points: see Configuring Analog Points.

For information on using the Performance Monitor driver to monitor the available disk space on a ClearSCADA server, see Monitor the Available Disk Space in the ClearSCADA Guide to Server Administration.


Performance Monitor Driver Guide - Performance Monitor Specific Status Display Attributes

Performance Monitor Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selection item.

For instance, the Status display for each Performance Monitor Scanner provides information about the present state of the individual scanner.

Many of the attributes on Performance Monitor Status displays are common to many drivers.

This section describes those attributes that are specific to the Performance Monitor driver. The attributes comprise:

  • Comms Statistics
  • Source.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Performance Monitor Driver Guide - Comms Statistics (Performance Monitor Specific Status Display Attributes)

Comms Statistics

Associated with: Performance Monitor Scanners

This status attribute indicates the number of:

  • Good Reads—Successful read operations
  • Bad Reads—Unsuccessful read operations

since that scanner was last restarted.

Example:

234 good reads, 6 bad reads


Performance Monitor Driver Guide - Source (Performance Monitor Specific Status Display Attributes)

Source

Associated with: Performance Monitor Scanners and Analog points

The Source attribute is common to many Status displays. The attribute indicates the location at which the item, for example the point, resides. The information shown varies depending on the type of item.

The Source attribute for a Performance Monitor scanner displays information in this format:

<Node Name or Mode>

Example:

Node PC45

for a scanner associated with local node PC45 (the node on which the ClearSCADA database resides).

The Source attribute for a Performance Monitor analog point displays information in this format:

<Node Name or Mode>:<Tag>

Example:

Node PC303: Memory\Available Bytes

for an analog point that is used to monitor the available bytes of memory on the local node PC303.

NOTE: The text ‘Main Mode’ is displayed in place of the node name if the Node field is left blank on the Scanner Form. This indicates that the point monitors data on whichever server is Main.


PLC Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


PLC Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


PLC Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


PLC Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


PLC Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


PLC Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure ClearSCADA to communicate with devices using the PLC driver. The driver enables ClearSCADA to communicate with devices using a range of protocols (see Protocols Supported by the PLC Driver). The configuration process requires you to define settings in ClearSCADA and also in the KEPServerEX software application.

The guide also provides information about PLC driver-specific statistics which can be used for diagnostics.

For more details on the subjects covered in this guide, see Introduction to the PLC Driver.


PLC Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed to be used by engineers who are responsible for configuring ClearSCADA to communicate with devices by using the PLC driver. It can also be used by system administrators when investigating unexpected behavior relating to the PLC driver.


PLC Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


PLC Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

KEPServerEX online Help.


PLC Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


PLC Driver Guide - Introduction to the PLC Driver

Introduction to the PLC Driver

ClearSCADA’s PLC Driver enables ClearSCADA to communicate with devices using a wide range of protocols (see Protocols Supported by the PLC Driver). To use any of these protocols, the ClearSCADA servers on your system need to run the PLC Driver. Whenever this component is installed on a server, the KEPServerEX application is also installed. KEPServerEX is started automatically by ClearSCADA when required, and remains running until ClearSCADA is shut down. KEPServerEX provides the ‘gateway’ to the various protocols that are supported by the PLC driver.

Example:

The diagram below shows how the PLC driver can be used to enable ClearSCADA to communicate with a Modbus PLC using the Modbus ASCII Serial protocol.

This guide provides information on how to configure ClearSCADA to communicate with devices using the PLC driver. The configuration is split between KEPServerEX and ClearSCADA. For further information, see the following sections:

  • Using KEPServerEX with ClearSCADA
  • Configuring Devices on the PLC Driver
  • Example Configuration.

The guide also explains PLC driver-specific aspects that may be of interest to system administrators and engineers when investigating unexpected system behavior (see PLC Specific Status Display Attributes).

NOTE: There are no driver-specific pick actions for items on the PLC driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


PLC Driver Guide - Protocols Supported by the PLC Driver

Protocols Supported by the PLC Driver

The PLC driver can be used to enable ClearSCADA to communicate with third-party devices using any of these protocols:
Allen-Bradley DH+ Allen-Bradley Ethernet Allen-Bradley Unsolicited Ethernet | Analog Devices
Aromat Aromat Ethernet | AutomationDirect EBC AutomationDirect ECOM
BUSWARE Ethernet | Contrex Contrex M-Series
ControlLogix Ethernet | Cutler-Hammer
DDE Client | DF1
Direct-NET | EtherTRAK
Fuji Flex | GE CCM GE Ethernet GE Ethernet Global Data GE Focas 1 Ethernet
GESNP GESNPX | Hilscher Universal
Honeywell UDC | IA Super SEL
Idec | IOtech PointScan 100
K Sequence | KraussMaffei MC4 Ethernet
Micro-DCI | Mitsubishi-Ethernet Mitsubishi FX Mitsubishi FX Net Mitsubishi Serial
Modbus Ascii Serial Modbus Ethernet Modbus Plus Modbus Serial Modbus Unsolicited Serial | ODBC Client
Omron FINS Ethernet Omron Host Link | Optimization OptiLogic
Partlow ASCII | Philips P8/PC20
SattBus SattBus Ethernet | Scanivalve Ethernet
Siemens S5 Siemens S5 (3964R) Siemens S7-MPI Siemens S7-200 Siemens TCP/IP Ethernet Siemens TCP/IP Unsolicited Ethernet | Simatic 505 Simatic 505 Ethernet
Simulator | SquareD
Thermo Westronics Ethernet Thermo Westronics Serial | TIWAY Host Adapter
Toshiba Toshiba Ethernet | Toyopuc Ethernet PC3/PC2
Uni-Telway | User Configurable
WAGO Ethernet | Yaskawa Memobus Plus Yaskawa MP Series Ethernet
Yokogawa Darwin Yokogawa Darwin Serial Yokogawa DX Yokogawa DX Serial Yokogawa DXP | ---

Further Information

Configuring Devices on the PLC Driver.


PLC Driver Guide - Using KEPServerEX with ClearSCADA

Using KEPServerEX with ClearSCADA

This section explains how to:

  • Run the KEPServerEX Application
  • Display the KEPServerEX Interface
  • Set up the KEPServerEX Exit Option
  • Save the KEPServerEX Configuration as a Project
  • Set up a Default Project
  • Copy the KEPServerEX Configuration to each ClearSCADA Server.


PLC Driver Guide - Run the KEPServerEX Application (Using KEPServerEX with ClearSCADA)

Run the KEPServerEX Application

Whenever ClearSCADA’s PLC driver component is installed on a server, the KEPServerEX application is also installed. ClearSCADA starts the KEPServerEX application automatically when required.

Be aware that ClearSCADA only runs drivers for which one or more driver-specific items exist in the ClearSCADA database. As such, on a system in which the PLC driver is newly installed, you will need to add a PLC scanner or point to the ClearSCADA database in order for both the PLC driver and KEPServerEX to run.

Further Information

Display the KEPServerEX Interface.

Set up the KEPServerEX Exit Option.


PLC Driver Guide - Display the KEPServerEX Interface (Using KEPServerEX with ClearSCADA)

Display the KEPServerEX Interface

To display the KEPServerEX configuration interface, double-click on the [image] KEPServerEX icon in the Windows taskbar. (If the icon is not displayed, ensure that at least one PLC driver-specific item exists in the ClearSCADA database—the PLC driver and KEPServerEX only run automatically when such an item exists.)

Further Information

Configure Channels, Devices and Tags in KEPServerEX.


PLC Driver Guide - Set up the KEPServerEX Exit Option (Using KEPServerEX with ClearSCADA)

Set up the KEPServerEX Exit Option

Once started by ClearSCADA, the KEPServerEX application typically remains running until ClearSCADA is shut down.

By default, KEPServerEX’s Exit option is set to ‘Ask to save (with timeout)’, with a Timeout of 10 seconds. When left at this default, whenever ClearSCADA attempts to shut KEPServerEX down, KEPServerEX will prompt to save any changes to the configuration. If it does not receive a confirmation within the Timeout period, KEPServerEX will shut down without saving any changes. We therefore recommend that you change KEPServerEX’s Exit option to ‘Auto save (if possible)’.

To do this:

  1. Display the KEPServerEX Interface.
  2. Select the Tools menu.
    A drop-down menu is displayed.
  3. Select Options.
    The Options window is displayed.
  4. Specify the required Exit option on the General tab.


PLC Driver Guide - Save the KEPServerEX Configuration as a Project (Using KEPServerEX with ClearSCADA)

Save the KEPServerEX Configuration as a Project

When you Configure Channels, Devices and Tags in KEPServerEX, you need to save that configuration as a project and store that project in a suitable location on the server.

To do this:

  1. Display the KEPServerEX Interface.
  2. Select the File menu.
    A drop-down menu is displayed.
  3. Select the Save As option.
    The Save As window is displayed.
  4. Specify a suitable name and location for the project file.

Copy the project file to each of the other ClearSCADA servers on your system (other than any Permanent Standby servers)—see Copy the KEPServerEX Configuration to each ClearSCADA Server.

We recommend that you Set up a Default Project on the KEPServerEX application on each server so that it specifies the relevant project file and location.


PLC Driver Guide - Set up a Default Project (Using KEPServerEX with ClearSCADA)

Set up a Default Project

You need to Save the KEPServerEX Configuration as a Project and copy that project file to other ClearSCADA servers on your system (see Copy the KEPServerEX Configuration to each ClearSCADA Server).

We recommend that you set the Default project on the KEPServerEX application on each server so that it specifies the relevant project file and location.

To do this:

  1. Display the KEPServerEX Interface.
  2. Select the Tools menu.
    A drop-down menu is displayed.
  3. Select Options.
    The Options window is displayed.
  4. Specify the Default Project on the General tab.


PLC Driver Guide - Copy the KEPServerEX Configuration to each ClearSCADA Server (Using KEPServerEX with ClearSCADA)

Copy the KEPServerEX Configuration to each ClearSCADA Server

The KEPServerEX Configuration is saved as a project file (see Save the KEPServerEX Configuration as a Project), which needs to be the same on each server on your system.

If you make changes to the KEPServerEX configuration, you need to:

  1. Copy the project file that contains the configuration changes
  2. Place a copy of the project file on each of the other ClearSCADA servers (with the exception of Permanent Standby servers). The project file name and location needs to be the same on each ClearSCADA server.

We recommend that you Set up a Default Project on the KEPServerEX application on each server. The Default Project settings require you to specify a project file and location, which makes it easier for you to keep the name and address of the project file consistent on your ClearSCADA servers.


PLC Driver Guide - Configuring Devices on the PLC Driver

Configuring Devices on the PLC Driver

On a ClearSCADA system, you configure the entries in the database so that they correspond to the plant, control devices, and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the devices with which ClearSCADA is to communicate using the PLC driver.

To communicate with such devices, the PLC Driver has to be installed and running on the ClearSCADA servers on your system. Whenever this driver is installed on a server, the KEPServerEX application is also installed.

With the PLC Driver, you configure the Channels, Devices, and Tags that you require using KEPServerEX (see Configure Channels, Devices and Tags in KEPServerEX). After configuring the required items using KEPServerEX, you need to Copy the KEPServerEX Configuration to each ClearSCADA Server.

In ClearSCADA, you can then configure the PLC Scanners and Points that you require (see Configure Scanners and Points in ClearSCADA). As part of this configuration, you associate each point with the corresponding Tag that has been configured using KEPServerEX.

NOTE: ClearSCADA only runs drivers for which one or more driver-specific items exist in the ClearSCADA database. On a system on which the PLC Driver is newly installed, you will need to add a PLC scanner or point to the ClearSCADA database in order for both the PLC Driver and KEPServerEX to run.

Further Information

Using KEPServerEX with ClearSCADA.


PLC Driver Guide - Configure Channels, Devices and Tags in KEPServerEX (Configuring Devices on the PLC Driver)

Configure Channels, Devices and Tags in KEPServerEX

With the PLC Driver, you configure the Channels, Devices, and Tags that you require using KEPServerEX. Many of the settings for these items need to correspond to the settings of the actual communications media, PLCs or other devices on your system. Some settings are either fixed (incorporated into the design of the device), or are configured by an engineer. You need to have access to, or an understanding of, the settings that are used on your system in order to configure the KEPServerEX database items successfully.

In KEPServerEX you need to configure:

  1. One Channel per communications medium that the server is to use to communicate with a device using the PLC driver.
  2. A Device to represent each PLC or other device with which the server is to communicate.
  3. A Tag for each item of data that the server is to read or write on each Device.

The configuration that you need to undertake using KEPServerEX varies, depending on the protocol that ClearSCADA is to use to communicate with the devices on your system. See the KEPServerEX online Help for information on the protocol-specific configuration that is required.

In summary, to add and configure a Channel in KEPServerEX:

  1. Display the KEPServerEX Interface.
  2. In the left-hand pane, right-click on the location in the tree-structure where you want to add a channel.
    A context sensitive menu is displayed.
  3. Select the New Channel option.
  4. Refer to the KEPServerEX online Help for information on configuring a channel for the required protocol.

If you require statistics for a channel, you need to Enable Diagnostics on that channel. This will provides you with useful information, such as the number of successful and unsuccessful reads and writes on a channel.

To add and configure a Device in KEPServerEX:

  1. Display the KEPServerEX Interface.
  2. In the left-hand pane, right-click on the Channel with which the Device is associated.
    A context sensitive menu is displayed.
  3. Select the New Device option.
  4. Refer to the KEPServerEX online Help for information on configuring a device for the required protocol.

To add and configure a Tag in KEPServerEX:

  1. Display the KEPServerEX Interface.
  2. In the left-hand pane, right-click on the Device for which you want to add a Tag.
    A context sensitive menu is displayed.
  3. Select the New Tag option.
  4. Refer to the KEPServerEX online Help for information on configuring the Tag.

When you have added and configured a channel, device and tag in KEPServerEX, you can test the configuration. To do this:

  • Use KEPServerEX’s OPC Quick Client to verify that the communications are configured correctly and that point values can be read from or written to as expected (see the KEPServerEX online Help for information).

When the communications are configured correctly, you need to:

  1. Save the KEPServerEX Configuration as a Project in a suitable location on the server.
  2. Set up a Default Project on the KEPServerEX application.
  3. Copy the project file to the other ClearSCADA servers on your system (with the exception of Permanent Standby servers). For further information, see Copy the KEPServerEX Configuration to each ClearSCADA Server.

When the KEPServerEX configuration is complete, you can configure the required scanners and points in the ClearSCADA database (see Configure Scanners and Points in ClearSCADA).

Further Information

Protocols Supported by the PLC Driver.

Using KEPServerEX with ClearSCADA.


PLC Driver Guide - Configure Scanners and Points in ClearSCADA (Configuring Devices on the PLC Driver)

Configure Scanners and Points in ClearSCADA

Once you have configured the necessary Channels, Devices, and Tags using KEPServerEX, you need to configure the required PLC Scanners and Points in the ClearSCADA database:

  1. Configure one PLC Scanner per different rate at which you want ClearSCADA to scan device(s) using the PLC driver (see Configuring a PLC Scanner).

If required, a Scanner can define the scan rate for point(s) on multiple Devices.

  2. Configure one PLC Point to represent each item of data that ClearSCADA is to read or write on a device using the PLC driver (see Points on PLC Scanners).

You also need to be aware of which optional features are required for each PLC item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with PLC database items, including Lists, Actions, and Mimics. See the core documentation for details.

Further Information

Configure Channels, Devices and Tags in KEPServerEX.

For an example that demonstrates how ClearSCADA might be configured to communicate with third-party devices using the PLC driver, see Example Configuration.


PLC Driver Guide - Configuring a PLC Scanner

Configuring a PLC Scanner

A PLC Scanner is logical functionality that runs within ClearSCADA and scans for data on a device with which ClearSCADA communicates using a protocol supported by the PLC driver.

You can configure multiple PLC scanners on your system. By specifying different scan rates, you can enable the PLC driver to scan certain data at different intervals to other data on the same device.

If required, you can assign the same scanner to scan point(s) on multiple Devices.

Configure each scanner’s properties using the fields on the PLC Scanner Form.

The Form has several tabs.

Use the Scanner tab to:

  • Configure the Basic Scanner Properties (see Define Common Scanner Properties in the ClearSCADA Guide to Simple Drivers)
  • Specify the Scan Rate (see Define the Scan Rate in the ClearSCADA Guide to Simple Drivers)
  • Specify Whether Data is Time Stamped According to its Receipt or Occurrence Time.

The properties on the other tabs are common to scanners on many simple drivers—see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


PLC Driver Guide - Specify Whether Data is Time Stamped According to its Receipt or Occurrence Time (Configuring a PLC Scanner)

Specify Whether Data is Time Stamped According to its Receipt or Occurrence Time

Use the Ignore PLC Timestamps check box toward the bottom of the Scanner tab to specify whether data is time stamped according to its receipt time or occurrence time.

Clear the check box if ClearSCADA is to use the time stamps provided by the device that the PLC Scanner scans.

Select the check box if ClearSCADA is to time stamp the data upon receipt—any time stamps provided by the scanned device are ignored. You need to select the Ignore PLC Timestamps check box if you want ClearSCADA to store PLC analog data historically at defined intervals, using ClearSCADA’s Background Logging feature (see Define the Background Logging Properties). You might also want ClearSCADA to time stamp the data if, for example, the time stamps provided by the scanned device are significantly behind or ahead of the current time.


PLC Driver Guide - Points on PLC Scanners

Points on PLC Scanners

The PLC driver enables ClearSCADA to read and/or write to data on third-party devices using any of the Protocols Supported by the PLC Driver. For each item of data that ClearSCADA is to read or write using one of these protocols, you need to:

  1. Configure a suitable Tag in KEPServerEX (see Configure Channels, Devices and Tags in KEPServerEX).

Each Tag is used to specify the location of the data that ClearSCADA is to read or write on a device, the type of data, and how KEPServerEX processes that data.

  2. Configure a suitable PLC Point in ClearSCADA.
  3. Associate each PLC Point with the appropriate KEPServerEX Tag.

This section summarizes how to configure PLC Points in ClearSCADA. The PLC driver supports these point types:

  • PLC Analog Point (see Configuring Analog Points)
  • PLC Digital Point (see Configuring Digital Points)
  • PLC String Point (see Configuring String Points)
  • PLC Time Point (see Configuring Time Points).

For each item of data to which ClearSCADA is to read or write using the PLC driver, configure a point of the type that presents that data in a suitable format in the ClearSCADA database.

For information on creating a point and displaying the Point Form, see Create and Configure a Point in the ClearSCADA Guide to Core Point Configuration.

Use the fields on each PLC Point Form to configure a point’s properties. Each Form has several tabs.

For information on configuring fields on the <Point Type> tab, see the references above.

Use the PLC tab to:

  • Configure the Common Point Properties (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers)
  • Specify the Tag with Which the Point is Associated.

For analog points, also see Configuring Analog Points.

For digital points, also see Configuring Digital Points.

The fields on the other tabs are common to points on many simple drivers—see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional PLC Point in ClearSCADA, see Minimum Configuration.


PLC Driver Guide - Minimum Configuration (Points on PLC Scanners)

Minimum Configuration

For a PLC Point to be functional (online), you need to specify these settings (as a minimum), and then put the point In Service and save the configuration:

  • The PLC Scanner that defines the rate at which ClearSCADA will scan a device for the point’s data
  • The Tag that defines the location of the data from which the PLC Point derives its value. (The Tag itself is configured using the KEPServerEX interface.)

With a PLC Digital Point, you should also:

  • Specify the starting bit of the source from which the point derives its value (PLC tab).

If ClearSCADA is to write to data on a device, you will need to enable the Control feature on the PLC point that represents that data in the ClearSCADA database. For information on the Control tab, see the ClearSCADA Guide to Core Point Configuration.

If you want the ClearSCADA server to store a point’s data historically, you need to:

  • Enable and configure logging on the Historic tab
  • With an analog point, you should also check that the appropriate option is selected on the PLC tab’s ‘Historic Data Filter’ section.


PLC Driver Guide - Specify the Tag with Which the Point is Associated (Points on PLC Scanners)

Specify the Tag with Which the Point is Associated

Use the Tag Name field on the PLC tab to specify the Tag with which a point is associated:

The Tag defines the location of the data with which the point is associated, along with properties that specify how KEPServerEX processes that data. You configure each Tag using KEPServerEX (see Configure Channels, Devices and Tags in KEPServerEX).

When specifying the Tag to associate with the point, you need to choose a Tag that has an appropriate Data Type for the point. A Tag’s Data Type varies, depending on the format of the data that it represents (see the relevant point configuration section in this guide for more information).

To specify a Tag, use the browse button adjacent to the Tag Name field to display a Reference browse window. Select the required Tag from the window.


PLC Driver Guide - Configuring Analog Points

Configuring Analog Points

For each data source that can be in one of a range of values, and for which ClearSCADA reads or writes data using the PLC driver, you need to configure a PLC Analog Point in the ClearSCADA database.

Configure the point’s properties using the fields on the PLC Analog Point Form. The Form has several tabs.

Use the PLC tab to:

  • Configure the Common Point Properties (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers)
  • Specify the Tag with Which the Point is Associated

The Tag has to be assigned (or default to) an appropriate Data Type, such as Short, Word, Long, Dword, Float, Double, BCD, or LBCD.

  • Configure Point Scaling (see Scale Analog Values for use in ClearSCADA in the ClearSCADA Guide to Simple Drivers)
  • Define Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration)
  • Use Persistence to Stop Fleeting Changes in Value from Changing the Point State
  • Define the Background Logging Properties
  • Define the Historic Data Storage Properties.

For information on the fields on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

The fields on other tabs are common to points on many drivers—see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


PLC Driver Guide - Use Persistence to Stop Fleeting Changes in Value from Changing the Point State (Configuring Analog Points)

Use Persistence to Stop Fleeting Changes in Value from Changing the Point State

On the PLC tab, you can use Persistence properties to stop a change in value from affecting the point state until the point has been in that state for a specified time. This stops the server from processing momentary changes of state and reporting those changes (see the example, below).

Use these fields within the Persistence section of the tab to define any persistence properties. In each instance, the persistence time begins whenever the point value drops below or rises above a state limit (by default, High-High, Low, and so on).

If, within the persistence time, the point value crosses a further limit in the same direction (that is, still continuing away from the Normal state, or still continuing toward the Normal state), the persistence period does not restart as it crosses the further limit. If the point value remains within the new state as the original persistence time elapses, the outstation updates the point state.

If the point value crosses back over a limit before the persistence time has elapsed, the point does not change state, and a new persistence time starts for the point value traveling in the new direction.

  • Away From Normal—Define the amount of time before the server updates the point state when the point value is moving away from the Normal State (toward Zero Scale or Full Scale).
  • Toward Normal—Define the amount of time before the server updates the point state when the point value is moving toward the Normal State (away from Zero Scale or Full Scale).

Example:

An analog point has this configuration:

Low Alarm Limit = 5.0
High Alarm Limit = 10.0
High-High Alarm Limit = 15.0

The Persistence properties are:

At 12:00:00 the point value is 8.0 (Normal).

At 12:00:10 the point value increases to 12.0, which is above the High limit.

At 12:00:20 the value of the point is still 12.0

At 12:00:30 the value of the point is still 12.0, so the point state changes to High as it has been 20 seconds since the value crossed the High Alarm Limit from the Normal state.

At 12:00:40 the value of the point further increases to 15.0 (the High-High Limit).

At 12:00:50 the point value is 15.0 (High-High).

At 12:01:00 the point value is still 15.0, so the point state changes to High-High as it has been 20 seconds since the value crossed the High-High Alarm Limit from the High State.

At 12:01:10 the point value decreases to 11.0, which is below the High-High Limit.

At 12:01:20 the point value is still 11.0

At 12:01:30 the point value is still 11.0

At 12:01:40 the point value is still 11.0, so the point changes state to High, as it has been 30 seconds since the value crossed the High-High Alarm Limit back toward the Normal State.

NOTE: Persistence does not apply where an analog point state becomes under range or over range (below Zero Scale, or above Full Scale), as these states are reported immediately.


PLC Driver Guide - Define the Background Logging Properties (Configuring Analog Points)

Define the Background Logging Properties

When ClearSCADA stores point values historically, as per the settings specified on the point’s Historic tab, the server typically only stores point changes—if a point does not change, no history is recorded during that period.

If a PLC analog point’s value tends to change infrequently and that point’s data is used, for example, in a data export program, or is displayed on a Historic Trend, consider configuring ClearSCADA to store that point’s values historically at a defined interval, regardless of whether the point has changed. You specify such requirements using the fields in the Background Logging section of the PLC tab:

  • Enabled—Clear this check box if:
  • ClearSCADA is only to store point changes historically, as per the settings configured on the Historic tab (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

or:

  • ClearSCADA is not to store data historically for this point.

Select the Enabled check box if the driver is to store point values historically at a defined interval, regardless of whether the point’s value changes.

If you select the Enabled check box, also:

  • Select the Ignore Server Timestamps check box on the PLC Scanner Form (see Specify Whether Data is Time Stamped According to its Receipt or Occurrence Time). This sets ClearSCADA to assign a unique time stamp to each point value that ClearSCADA stores historically.
  • Activate the Historic feature by selecting Enabled on the Historic tab.
  • Set Compression on the Historic tab to either apply to No Data, or Current Data Only. (If Compression is configured to apply to All Data, ensure that the Significant Change deadband is set to 0.)
  • Select the Timed Report check box in the Historic Data Filter section of the PLC tab (see Define the Historic Data Storage Properties).
  • Interval—Use to specify the frequency with which ClearSCADA stores point values historically, regardless of whether they have changed.

Enter the required Interval in the OPC Time Format, for example 15M for ClearSCADA to store the point’s value historically at 15-minute intervals.

  • Offset—Use to specify the Background Logging start time—the amount of time that occurs before ClearSCADA logs the first point value historically. Specify the start time as an offset from the present time, in the OPC Relative Time Format. For example, specify H for ClearSCADA to start storing point values historically at the start of the present hour, and thereafter at the intervals specified in the Interval field, above.


PLC Driver Guide - Define the Historic Data Storage Properties (Configuring Analog Points)

Define the Historic Data Storage Properties

Use the fields within the Historic Data Filter section of the PLC tab to specify the type of data that ClearSCADA is to store historically for an analog point.

NOTE: Use the Historic Data Filter section in conjunction with the Historic tab settings. The settings on the Historic tab define whether the server stores values historically for the point, and whether any unnecessary data is filtered out to reduce storage requirements (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

The ClearSCADA server retrieves and processes the current data values from the devices that it monitors. Use the check boxes within the Historic Data Filter section to specify the type of retrieved data that ClearSCADA is to store historically for a particular analog point:

  • Current Data—Select this check box for ClearSCADA to store the point’s current values historically.

Clear the check box if you have no requirement for ClearSCADA to store current values historically.

  • Timed Report—Select this check box if Background Logging is enabled for the point (see Define the Background Logging Properties). ClearSCADA regularly stores point values historically, regardless of whether those values have changed.

Clear the check box if Background Logging is not used for this point.

If neither of the check boxes above is selected, regardless of whether historic is enabled on the point’s Historic tab, ClearSCADA will not store retrieved point values historically.


PLC Driver Guide - Configuring Digital Points

Configuring Digital Points

For each source value that can be in one of a set number of states, and for which ClearSCADA reads or writes data using the PLC driver, you need to configure a PLC Digital Point in the ClearSCADA database.

Configure the point’s properties using the fields on the PLC Digital Point Form. The Form has several tabs.

Use the PLC tab to:

  • Configure the Common Point Properties (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers)
  • Specify the Tag with Which the Point is Associated.

The Tag has to be assigned (or default to) an appropriate Data Type, such as Boolean, Char, or Byte.

  • Use Persistence to Stop Fleeting Changes in Value from Changing the Point State
  • Specify the Starting Bit of the Source from Which the Point Derives its Value.

For information on the fields on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

The fields on other tabs are common to points on many drivers—see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


PLC Driver Guide - Use Persistence to Stop Fleeting Changes in Value from Changing the Point State (Configuring Digital Points)

Use Persistence to Stop Fleeting Changes in Value from Changing the Point State

Use the Persistence field on the PLC tab to stop a change in value from affecting the point state until the point has been in that state for a specified time. This allows the driver to ignore fleeting changes in point value, and stops ClearSCADA raising change of state alarms and logging change of state events when a point value is fluctuating.

When the point changes value, any change of point state is delayed until the point remains in the new state for a specified amount of time. If the point does not remain in the new state for the required amount of time, no change in point state is recorded.

  • Persistence—Use this field to specify the period, in seconds, that a point needs to remain in a new state before the PLC driver updates the ClearSCADA database with a change of value.


PLC Driver Guide - Specify the Starting Bit of the Source from Which the Point Derives its Value (Configuring Digital Points)

Specify the Starting Bit of the Source from Which the Point Derives its Value

Use the fields within the Value section of the PLC tab to specify the type of source value that is used to derive the value of the point in the ClearSCADA database. ClearSCADA processes the data differently, according to the type of source value.

  • Value Source—Use this combo box to specify the type of source value from which ClearSCADA is to read or write data. Choose from:
  • Single Value—The source value is a single data value. Specify this option if the lowest bit to which ClearSCADA is to read or write is the first or only bit within an individual value.
  • Bit Offset within Single Value—The lowest bit to which ClearSCADA is to read or write data is not the first bit in the source value. Use the Bit Offset field (below) to specify the required bit.
  • Bit Offset—Only applies if the Value Source is set to Bit Offset within Single Value. Use the Bit Offset field to specify the offset into the source value that denotes the location of the lowest bit to which ClearSCADA is to read or write data. (Bit zero being the lowest bit in the source value.)

(Use the Number of Bits spin box on the Digital Point tab to specify the number of consecutive bits that the point spans (see Define the Number of Bits for a Digital Point in the ClearSCADA Guide to Core Point Configuration).)


PLC Driver Guide - Configuring String Points

Configuring String Points

To represent a string value on a device with which ClearSCADA communicates using the PLC driver, you need to configure a PLC String Point in the ClearSCADA database.

Configure the point’s properties using the fields on the PLC String Point Form. The Form has several tabs.

Use the PLC tab to:

  • Configure the Common Point Properties (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers)
  • Specify the Tag with Which the Point is Associated.

The Tag has to be assigned, or default to, a ‘String’ Data Type.

For information on the String Point tab, see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration.

The fields on other tabs are common to points on many drivers—see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


PLC Driver Guide - Configuring Time Points

Configuring Time Points

To represent a time value on a device with which ClearSCADA communicates using the PLC driver, you need to configure a PLC Time Point in the ClearSCADA database. You might use a PLC Time Point, for example, in conjunction with one of KEPServerEX’s System Tags, to provide general feedback on a device’s current date and/or time settings.

Configure the point’s properties using the fields on the PLC Time Point Form. The Form has several tabs.

Use the PLC tab to:

  • Configure the Common Point Properties (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers)
  • Specify the Tag with Which the Point is Associated.

The Tag has to be assigned (or default to) a Date, or Time Data Type.

For information on the Time Point tab, see Defining Time Point Details in the ClearSCADA Guide to Core Point Configuration.

The fields on other tabs are common to points on many drivers—see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


PLC Driver Guide - Example Configuration

Example Configuration

This section demonstrates how the PLC driver might be used to enable ClearSCADA to communicate with third-party devices using the Modbus ASCII protocol—one of the protocols that is supported by this driver (see Protocols Supported by the PLC Driver).

Use the example as a guide when configuring your own system to use the PLC driver. Similar steps should be undertaken regardless of the required communications protocol.

Example:

A particular ClearSCADA system is to communicate with various PLCs using Modbus ASCII. The PLC driver is used to enable ClearSCADA to communicate with those devices using this protocol.

The KEPServerEX configuration wizards are used to add suitable Channels, Devices, and Tags.

The configuration wizard for each Channel requires the communications protocol—in this case, Modbus ASCII Serial—to be specified when the channel is added to the system.

The configuration wizard for each Device that is added to such a channel is automatically restricted to display only those type(s) of device that are supported by that channel’s protocol.

The configuration wizard for the channel requires you to specify a communications protocol (such as Modbus ASCII Serial).
The configuration wizard for any devices that are added to the channel is restricted to offer only those configuration options and device models that are supported by that protocol.

The configuration wizard for each Tag is restricted to those configuration options that apply to the device and communications protocol with which the Tag is associated.

KEPServerEX’s OPC Quick Client is used to confirm that the communications is valid and that data can be written and read as expected.

The KEPServerEX configuration is saved and copied to the other servers on the system (except Permanent Standby servers).

In ClearSCADA, PLC Scanners are added to the database to specify the rates at which data is scanned on the PLCs.

PLC points are added to the ClearSCADA database—one point for each item of data that is read or written to on each Modbus PLC. Each point is assigned a PLC Scanner. Each point is also associated with the KEPServerEX Tag that defines the location of the data that the point represents:

The browse button next to the Tag Name field is used to display a Reference browse window...
...from which the relevant KEPServerEX Tag is selected.

Further Information

Protocols Supported by the PLC Driver.

Using KEPServerEX with ClearSCADA.

Configuring Devices on the PLC Driver.

Configure Channels, Devices and Tags in KEPServerEX.

Configuring a PLC Scanner.

Points on PLC Scanners.


PLC Driver Guide - PLC Specific Status Display Attributes

PLC Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for a PLC point provides information about the present state of that point.

Use this section if you need information on the status of any PLC database items on your system. This section covers those attributes that are PLC-specific:

  • PLC Scanner Status Attributes
  • PLC Point Status Attributes.

You can also display statistics for each Channel in KEPServerEX. To do this, you must first set the channel to log statistics by setting the channel’s Properties to Enable Diagnostics. When diagnostics are enabled, you can then view the channel’s statistics by right-clicking on the channel in KEPServerEX and selecting the Diagnostics option from the context sensitive menu. For more information, see the KEPServerEX online Help.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Items on Many Drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


PLC Driver Guide - PLC Scanner Status Attributes (PLC Specific Status Display Attributes)

PLC Scanner Status Attributes

These status attributes are specific to PLC scanners:

  • Comms Statistics
  • Error Statistics.


PLC Driver Guide - PLC Point Status Attributes (PLC Specific Status Display Attributes)

PLC Point Status Attributes

This status attribute is specific to PLC points:

  • Source.


PLC Driver Guide - Alphabetical List of PLC Specific Status Attributes (PLC Specific Status Display Attributes)

Alphabetical List of PLC Specific Status Attributes

This section lists the Status attributes that are specific to items on the PLC driver. The attributes comprise:

  • Comms Statistics
  • Error Statistics
  • Source.

NOTE: In addition to the status statistics in ClearSCADA, you can display statistics for each Channel in KEPServerEX. In order to log statistics, the channel’s Properties must be set to Enable Diagnostics. To view the statistics, right-click on the channel in KEPServerEX and select the Diagnostics option from the context sensitive menu. For more information, see the KEPServerEX online Help.


PLC Driver Guide - Comms Statistics (PLC Specific Status Display Attributes)

Comms Statistics

Associated with: PLC scanners

This attribute indicates the number of:

  • Reads—Read operations performed by the scanner
  • Read items—Tags that have been read by the scanner
  • Writes—Write operations performed by the scanner

since the scanner was last restarted.

Example:

5 reads, 14 read items, 2 writes

Use the Error Statistics attribute to ascertain whether any of the above operations generated errors.


PLC Driver Guide - Error Statistics (PLC Specific Status Display Attributes)

Error Statistics

Associated with: PLC scanners

The Error Statistics attribute shows the number of errors generated during any of the read, conversion, or write operations that are summarized by the Comms Statistics attribute.

The Error Statistics indicate the number of occurrences of each of the following, since the scanner was last restarted:

  • Read errors—The number of errors generated when attempting to read items. For example, if the PLC driver issues a read for an item, but the target device returns an error.
  • Write errors—The number of errors reported from write operations.
  • Conversion errors—The number of conversion errors. A conversion error is generated if, for example, the target device reports a value that is not compatible with the target point type.
  • Unknown item errors—The number of write completion messages that have been received for ‘unknown’ controls—controls that have not been sent by the ClearSCADA server.

Example:

2 read errors, 0 write errors, 0 conversion errors, 0 unknown item errors


PLC Driver Guide - Source (PLC Specific Status Display Attributes)

Source

Associated with: PLC points

The Source attribute is common to many Status displays. The information shown varies depending on the type of item. For points, the attribute shows the location of the point’s data source.

For points on the PLC driver, the information is displayed in this format:

:<Channel name>.<Device name>.<Tag name>

The Channel, Device, and Tag are each configured using KEPServerEX. The association of a point with a particular Tag is specified using the Tag Name field on the point’s Form in ClearSCADA (see Specify the Tag with Which the Point is Associated).

Example:

:Channel_4.Device_6.Word_1
(For a point that derives its value from the Tag ‘Word_1’, on ‘Device_6’. KEPServerEX communicates with the device using the channel named ‘Channel_4’.)


SDI-12 Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SDI-12 Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


SDI-12 Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


SDI-12 Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


SDI-12 Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SDI-12 Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s SDI-12 driver. The SDI-12 driver enables ClearSCADA to read data from intelligent sensors using the SDI-12 protocol.

For more details on the information included in this guide, see Introduction to the SDI-12 Driver.


SDI-12 Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring SDI-12 items and features in the ClearSCADA database.

The guide also contains information for maintenance engineers.


SDI-12 Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


SDI-12 Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


SDI-12 Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


SDI-12 Driver Guide - Introduction to the SDI-12 Driver

Introduction to the SDI-12 Driver

SDI-12 is an open protocol that can be used for communicating with micro-processor based sensors.

The ClearSCADA SDI-12 driver enables ClearSCADA to become an SDI-12 data recorder and read data from intelligent sensors, using the SDI-12 protocol. The ClearSCADA SDI-12 driver communicates with the sensors using serial communications.

This guide explains how to configure SDI-12 specific features and items within the ClearSCADA database (see Configuring SDI-12 Devices in ClearSCADA).

It also explains driver-specific aspects that may be of interest to System Administrators and engineers when investigating any unexpected system behavior (see SDI-12 Specific Status Display Attributes).

For SDI-12 information not covered by this guide, see the documentation supplied with your SDI-12 sensors, or see the SDI-12 web site (www.sdi-12.org).

NOTE: There are no driver-specific pick actions for items on the SDI-12 driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


SDI-12 Driver Guide - Configuring SDI-12 Devices in ClearSCADA (Introduction to the SDI-12 Driver)

Configuring SDI-12 Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, control devices, and measuring instruments on your system. This section summarizes the database items that you need to configure in order to read data on SDI-12 devices.

In order to communicate using the SDI-12 protocol, the SDI-12 Driver has to be installed and running on the ClearSCADA servers on your system.

When you configure SDI-12 items in the ClearSCADA database, many of the settings for those items need to correspond to the settings on the SDI-12 devices on your system. Some settings are either fixed (incorporated into the design of the sensor), or are configured by an engineer. You need to have access to, or an understanding of, these settings before you can configure the SDI-12 database items successfully.

For instance, you need to know the type of SDI-12 command that you want ClearSCADA to use in order to read the data on each sensor.

You also need to be aware of which optional features are required for each SDI-12 item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with SDI-12 database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each SDI-12 device, you need to configure:

  1. SDI-12 Channel(s) to represent the communication connections between each SDI-12 sensor and the ClearSCADA server (see Configuring an SDI-12 Channel).

You need to configure a separate SDI-12 channel for each separate communications channel that is available to the SDI-12 driver on your system.

Each channel has to use an RS-232 to SDI-12 adapter.

  2. At least one SDI-12 Scanner for each SDI-12 sensor that you want to scan. (Configure a scanner for each group of points that you want to scan at a different frequency or time offset.) For further information, see Configuring an SDI-12 Scanner.
  3. An SDI-12 Analog Point to represent each item of data that is to be read on an SDI-12 sensor.

To minimize the time that it takes to configure the required SDI-12 items, you may want to configure them in the order listed above, as Scanner configuration requires you to specify a channel, and Point configuration requires that you specify a scanner, etc.


SDI-12 Driver Guide - Configuring an SDI-12 Channel

Configuring an SDI-12 Channel

You need to configure an SDI-12 Channel for every SDI-12 bus over which ClearSCADA will extract sensor data (using the SDI-12 protocol). To do this, you need to add SDI-12 Channel items to the ClearSCADA database and then use the SDI-12 Channel Form to define the appropriate settings.

The SDI-12 Channel Form has several tabs:

  • Use the fields on the Channel tab to configure the basic channel properties (see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers).
  • Use the fields on the Connection tab to specify the properties of the serial connection that the SDI-12 driver uses to communicate with the SDI-12 devices on this channel (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

For information on the properties on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

There are no driver-specific fields on the SDI-12 Channel Form.

ATTENTION: Each channel has to use an RS-232 to SDI-12 adapter. These are available from various suppliers. A list of companies that supply SDI-12 products is included on the SDI-12 web site, www.sdi-12.org.


SDI-12 Driver Guide - Configuring an SDI-12 Scanner

Configuring an SDI-12 Scanner

An SDI-12 Scanner is logical functionality that runs in ClearSCADA and scans for data on an intelligent sensor, using the SDI-12 protocol.

You need to create and configure one scanner per sensor.

You can attach multiple SDI-12 Scanners to each sensor on your system. By specifying different scan rates and offsets, you can enable the SDI-12 driver to scan certain data at different intervals and times to other data on the same sensor.

You configure the scanner features using the fields on the SDI-12 Scanner Form.

The Form has several tabs. The Scanner tab includes several SDI-12 specific fields. You use the Scanner tab to:

  • Configure the General Scanner Properties
  • Configure the Sensor Properties
  • Configure the Scan Properties.

For information on the fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional SDI-12 Scanner in ClearSCADA, see Minimum Configuration.


SDI-12 Driver Guide - Minimum Configuration (Configuring an SDI-12 Scanner)

Minimum Configuration

For an SDI-12 Scanner to be functional (on-line), you need to:

  • Specify the channel through which the scanner communicates
  • Specify the scanner’s sensor ID
  • The Data Length.

You also have to put the scanner In Service and save the configuration.

These are the minimum requirements and, when specified, will result in a scanner that uses the default configuration settings.


SDI-12 Driver Guide - Configure the General Scanner Properties (Configuring an SDI-12 Scanner)

Configure the General Scanner Properties

Use the fields at the top of the Scanner tab to define the general scanner properties. Some of these fields are common to many scanners (see Define Common Scanner Properties in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the SDI-12 driver are described below.

  • Channel—Specify the channel through which the scanner sends and receives data. Use the browse button to display a Reference browse window. From the window, select the channel that the scanner uses.


SDI-12 Driver Guide - Configure the Sensor Properties (Configuring an SDI-12 Scanner)

Configure the Sensor Properties

Use these fields on the Scanner tab of the SDI-12 Scanner Form to configure the sensor properties:

  • Sensor ID—Specify the single-character device address that applies to the sensor that this scanner is to scan.

Sensors on an SDI-12 bus typically have addresses or IDs within the range 0 to 9. Some types of sensor also support the address ranges A to Z and/or a to z, for use on buses that have more than 10 sensors.

  • Command Type—Use this combo box to specify the type of command that the scanner is to use in order to extract data from the sensor. Be aware that some sensors may not support all of the listed command types—see the documentation supplied with the sensor for information on the command types that the sensor supports.

Choose from:

  • Measurement—The scanner issues a ‘Start Measurement’ command to the sensor, followed by one or more ‘Send Data’ commands, in order to retrieve the required number of measurements from the sensor.

The sensor may enforce a delay before the scanner can send its first ‘Send Data’ message. This is determined by the sensor’s response to the scanner’s ‘Start Measurement’ command.

  • Measurement with CRC—This command is similar to the Measurement command above, but with an additional cyclical redundancy check (CRC) number. The sensor appends a CRC number to each reply that it sends in response to a ‘Send Data’ command. The CRC number relates to the data that is included in the transmission. The driver decodes the number to verify that the data received from the sensor is valid (has not become corrupted during transfer).

The sensor may enforce a delay before the scanner can send its first ‘Send Data’ message. This is determined by the sensor’s response to the scanner’s ‘Start Measurement and Request CRC’ command.

  • Concurrent Measurement—To retrieve the required number of measurements from the sensor, the scanner issues a ‘Start Concurrent Measurement’ command to the sensor, followed by one or more ‘Send Data’ commands.

The sensor may enforce a delay before the scanner can send its first ‘Send Data’ message. This is determined by the sensor’s response to the scanner’s ‘Start Concurrent Measurement’ command.

  • Concurrent Measurement with CRC—This command is similar to the Concurrent Measurement command above, but with an additional cyclical redundancy check (CRC) number. The sensor appends a CRC number to each reply that it sends in response to a ‘Send Data’ command. The number relates to the data that is included in the transmission. The driver decodes the number to verify that the data received from the sensor is valid (has not become corrupted during transfer).

The sensor may enforce a delay before the scanner can send its first ‘Send Data’ message. This is determined by the sensor’s response to the scanner’s ‘Start Concurrent Measurement and Request CRC’ command.

  • Continuous Measurements—The scanner issues a ‘Continuous Measurements’ command to the sensor. The sensor immediately returns any measurements to the scanner, in response to this command.
  • Continuous Measurements with CRC—This command is similar to the Continuous Measurements command above, but with an additional cyclical redundancy check (CRC) number. The sensor appends a CRC number to the reply that it sends to the scanner. The number relates to the data that is included in the transmission. The driver decodes the number to verify that the data received from the sensor is valid (has not become corrupted during transfer).
  • Verification—The scanner issues a ‘Start Verification’ command to the sensor, followed by one or more ‘Send Data’ commands, in order to retrieve the required number of measurements from the sensor.

The sensor may enforce a delay between issuing the ‘Start Verification’ and ‘Send Data’ messages.

Verification data might include information such as ROM signatures, RAM test results, or the results of other diagnostics in the sensor.

  • Command Number—Applicable if the Command Type is a command other than ‘Verification’. Use this field to specify the command number that the scanner is to use in order to extract data from the sensor. The command number and its functionality varies, depending on the type of sensor from which the scanner is to extract data.

Refer to the documentation provided with the sensor for further information, and then specify the required command number, in the range 0 to 9.

  • Data Length—Use to specify the maximum number of measurements that the sensor is to take in response to each command from this scanner. Use this property to reduce the communications overhead should the scanner only be required to retrieve some, but not all, of a sensor’s measurement readings.

Example:

An SDI-12 Scanner includes this configuration:

Command Type:Measurement
Data Length:5

The sensor that the scanner is scanning can return up to 9 measurement readings in response to each Measurement command. However, in this particular case, the scanner is only required to retrieve the first 5 readings, and hence the Data Length is set to 5. This reduces the communications overhead, as multiple ‘Send Data’ messages might otherwise have been required to retrieve all 9 readings.

The maximum number of measurements that a sensor can make in response to a command varies, depending on the type of sensor and the Command Type. Refer to the documentation provided with the sensor for information on how many measurement readings the sensor can make and the order in which it takes those readings. The maximum number of readings that can be specified in this field are listed below:

Command Type | Maximum Data Length
Measurement/Measurement with CRC | 9*
Concurrent Measurement/Concurrent Measurement with CRC | 99*
Continuous Measurements/Continuous Measurements with CRC | Varies, depending on the sensor
Verification | 9*

* Be aware that this value may be further limited by the type of sensor and the number of measurements that it can take.

For each measurement that a scanner is to extract, a corresponding SDI-12 Analog Point needs to exist in the ClearSCADA database (see Configuring an SDI-12 Analog Point). Each point has to be associated with the relevant SDI-12 Scanner. (Should more points be associated with a particular scanner than are specified in that scanner’s Data Length field, a ‘Point does not fall within range of scanner’ message will be displayed at the bottom of the Point Form.)


SDI-12 Driver Guide - Scan Properties (Configuring an SDI-12 Scanner)

Scan Properties

Use the fields at the bottom of the Scanner tab to configure the scan properties. The properties are common to many scanners (see Configuring Scanners on Simple Drivers in the ClearSCADA Guide to Simple Drivers).


SDI-12 Driver Guide - Configuring an SDI-12 Analog Point

Configuring an SDI-12 Analog Point

The SDI-12 driver uses SDI-12 Analog Points to reference the individual items of data (measurements) that are to be extracted from an SDI-12 sensor.

You need to create and configure one SDI-12 Analog Point for each measurement that ClearSCADA is to extract using the SDI-12 protocol.

Configure the properties of each analog point using the fields on the SDI-12 Analog Point Form.

The Form has several tabs. This section covers configuration of properties on the SDI-12 tab of the Form. Use the SDI-12 tab to:

  • Configure the SDI-12 Properties
  • Define the Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration).

For information on configuring the properties on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the properties on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

For basic information on creating and configuring a point, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

ATTENTION: A ‘Point does not fall within range of scanner’ message is displayed at the bottom of the Point Form should more points be assigned to a scanner than are specified in that scanner’s Data Length field (see Configure the Sensor Properties).


SDI-12 Driver Guide - Configure the SDI-12 Properties (Configuring an SDI-12 Analog Point)

Configure the SDI-12 Properties

Use the fields at the top of the SDI-12 tab to configure the SDI-12 specific point properties. Some of these properties are common to points on many simple drivers—for information, see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers. Properties that are specific to analog points on the SDI-12 driver are explained below.

  • Measurement Offset—Use to specify the location of this particular measurement, as an offset into the data that the scanner is to extract from the sensor. The range varies, depending on the number of sensor readings that the scanner is configured to scan. Thus, you need to specify the required offset from within the range:

0 to (Scanner’s Data Length - 1)

where 0 is the first measurement, 1 is the second measurement, and so on.

(The Data Length is specified on the SDI-12 Scanner Form (see Configure the Sensor Properties).)

Example:

An SDI-12 Scanner includes this configuration:

Command Type: Measurement
Data Length: 3

Three SDI-12 Analog Points are configured in the ClearSCADA database and are associated with the scanner. Each analog point is given a different Measurement Offset, to represent the three separate readings that the scanner retrieves from the sensor.

Thus, the analog point that represents the first reading is given a Measurement Offset of 0, the analog point that represents the second reading is given a Measurement Offset of 1, and the analog point that represents the third reading is given a Measurement Offset of 2.


SDI-12 Driver Guide - SDI-12 Specific Status Display Attributes

SDI-12 Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for an SDI-12 Analog Point provides information about the present state of the individual point.

Use this section if you need information on the status of any SDI-12 database items on your system.

This section covers those attributes that are SDI-12 specific and includes:

  • SDI-12 Channel Status Attributes
  • SDI-12 Scanner Status Attributes
  • SDI-12 Point Status Attributes
  • Alphabetical List of SDI-12 Specific Status Display Attributes.

Further Information

Working with Status displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


SDI-12 Driver Guide - SDI-12 Channel Status Attributes (SDI-12 Specific Status Display Attributes)

SDI-12 Channel Status Attributes

This Status attribute is specific to SDI-12 channels:

  • Primary Assign.

NOTE: Three further Status attributes—Primary Eavesdrop Tx Assign, Secondary Assign, and Secondary Eavesdrop Tx Assign—are not used by the SDI-12 driver.


SDI-12 Driver Guide - SDI-12 Scanner Status Attributes (SDI-12 Specific Status Display Attributes)

SDI-12 Scanner Status Attributes

This Status attribute is specific to SDI-12 scanners:

  • Source.


SDI-12 Driver Guide - SDI-12 Point Status Attributes (SDI-12 Specific Status Display Attributes)

SDI-12 Point Status Attributes

This Status attribute is specific to SDI-12 analog points:

  • Source.


SDI-12 Driver Guide - Alphabetical List of SDI-12 Specific Status Display Attributes (SDI-12 Specific Status Display Attributes)

Alphabetical List of SDI-12 Specific Status Display Attributes

This section lists those Status attributes that are specific to items on the SDI-12 driver. The attributes are listed in alphabetical order and comprise:

  • Primary Assign
  • Source.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.


SDI-12 Driver Guide - Primary Assign (SDI-12 Specific Status Display Attributes)

Primary Assign

Associated with: SDI-12 Channels

This attribute indicates whether the assignment of an SDI-12 channel to its serial line has failed. The line configuration is defined on the Channel Form (see Configuring an SDI-12 Channel).

Possible States: Displays one of the Standard Alarm States.


SDI-12 Driver Guide - Source (SDI-12 Specific Status Display Attributes)

Source

Associated with: Many SDI-12 items

The Source attribute is common to many Status Displays. The attribute indicates the location at which the item, for example the point, resides. The information shown varies, depending on the type of item.

For SDI-12 Scanners, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Flow Control><Stop Bits>: Sensor <ID>, <Command Type> (<Command/Command Number>) - <Data Length> Measurements

(For many commands, the <Command Number> is excluded if it is zero.)

Example:

COM1:1200:7E1:Sensor 3, Concurrent Measurement with CRC (aCC2!) - 4 Measurements

(For a scanner that is scanning 4 concurrent measurements on sensor number 3. A cyclical redundancy check (CRC) is used to verify that the data received from the sensor is valid. Command Number 2 is used to retrieve the data from the sensor. The scanner uses the channel that communicates via the comms port COM1, at 1200 baud, with 7 data bits, even parity, and 1 stop bit.)

For SDI-12 Analog Points, information is displayed in this format:

<Port>:<Baud Rate>:<Data Bits><Flow Control><Stop Bits>: Sensor <ID>, <Command Type> (<Command/Command Number>):AG <Measurement Offset>

(For many commands, the <Command Number> is excluded if it is zero.)

Example:

COM1:1200:7E1:Sensor 3, Concurrent Measurement with CRC (aCC2!): AG 2

(For the third analog (AG) that the scanner is scanning in a series of concurrent measurements. (The first analog would have an offset of 0, and the second analog an offset of 1.) Scanner details as per the example above.)

In keeping with SDI-12 terminology, the Source attribute uses the following codes to indicate the type of command that is being used to extract the measurements:
Code | Type of Command
aM! | Start Measurement
aMC! | Start Measurement and Request CRC (Cyclical Redundancy Check)
aC! | Start Concurrent Measurement
aCC! | Start Concurrent Measurement and Request CRC
aR! | Continuous Measurements
aRC! | Continuous Measurements and Request CRC
aV! | Start Verification

For more information on any of these commands, see Configure the Sensor Properties.


Simatic S7 Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Simatic S7 Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Simatic S7 Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Simatic S7 Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Simatic S7 Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Simatic S7 Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure a ClearSCADA system to communicate the Simatic S7-200, S7-300, and S7-400 series of PLCs.

For information on the subjects covered in this Guide, see Introduction to the Simatic S7 Driver.


Simatic S7 Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by engineers who are responsible for configuring the Simatic S7-specific features and items within the ClearSCADA database. It can also be used by system administrators for investigating unexpected activity relating to the Simatic driver.


Simatic S7 Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Simatic S7 Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


Simatic S7 Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Simatic S7 Driver Guide - Introduction to the Simatic S7 Driver

Introduction to the Simatic S7 Driver

The Simatic S7 Driver allows a ClearSCADA system to be populated with data from, and control points on, the Simatic S7-200, S7-300, and S7-400 series of PLCs. The driver provides extra functionality within the server for communicating with such PLCs.

ClearSCADA communicates with Simatic S7 PLCs using either serial or TCP communications (see Communicating with Simatic S7 PLCs).

The Simatic S7 documentation explains how to configure Simatic S7-specific features and items within the ClearSCADA database (see Configuring Simatic S7 Devices in ClearSCADA).

The documentation also explains driver-specific aspects that may be of interest to system administrators and engineers when investigating any unexpected system behavior (see Simatic S7 Specific Status Display Attributes).

NOTE: There are no driver-specific pick actions for items on the Simatic S7 driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


Simatic S7 Driver Guide - Configuring Simatic S7 Devices in ClearSCADA (Introduction to the Simatic S7 Driver)

Configuring Simatic S7 Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, control devices, and measuring instruments on your system. This section summarizes the database items that you need to configure in order to read and write data to the Simatic S7-200, S7-300, and S7-400 series of PLCs.

In order to communicate with Simatic S7 PLCs, the Simatic S7 Driver has to be installed and running on the ClearSCADA servers on your system.

When you configure Simatic S7 items in the ClearSCADA database, many of the settings for those items need to correspond to the settings on the Simatic S7 PLCs on your system. Some settings are either fixed (incorporated into the design of the PLC), or are configured by an engineer. You need to have access to, or an understanding of, these settings before you can configure the Simatic S7 database items successfully.

For instance, you need to know the location of the point data that you want ClearSCADA to scan on each Simatic S7 PLC.

You also need to be aware of which optional features are required for each Simatic S7 item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with Simatic S7 database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each Simatic S7 device, you need to configure:

  1. Simatic S7 Channel(s) to represent the communication connections between the Simatic S7-200, S7-300, or S7-400 series of PLC(s) and the ClearSCADA server (see Configuring a Simatic S7 Channel).

For Serial Communications, you need to configure one channel per adapter.

For TCP Communications, configure one channel to be used by all Simatic NET-connected PLCs.

  2. At least one Simatic S7 Scanner for each PLC that the Simatic S7 driver is to scan (see Configuring a Simatic S7 Scanner).

Configure a scanner for each group of points that you want to scan at a different frequency, or that reside in a different area of memory on a PLC.

  3. A Simatic S7 Point for each separate item of data that is to be read from or written to in a Simatic S7-200, S7-300 or S7-400 PLC (see Points Used on Simatic S7 Scanners).

You can associate multiple points with each Simatic S7 Scanner.

To minimize the time that it takes to configure the Simatic S7 items, you may want to configure them in the order listed above, as Scanner configuration requires that you specify a Channel, and Point configuration requires that you specify a Scanner, and so on.


Simatic S7 Driver Guide - Configuring a Simatic S7 Channel

Configuring a Simatic S7 Channel

Simatic S7 channels are used to provide ClearSCADA with additional connection information, so that the server can successfully communicate with Simatic S7 PLCs (see Communicating with Simatic S7 PLCs).

Specify the features for each channel by using the fields on the Simatic S7 Channel Form.

The Form has several tabs. This section explains the driver-specific fields on the:

  • Channel tab (see Configure the Channel Properties)
  • Primary Connection and Secondary Connection tabs (see Configure the Connection Properties).

For information on configuring the properties on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.


Simatic S7 Driver Guide - Configure the Channel Properties (Configuring a Simatic S7 Channel)

Configure the Channel Properties

Use the fields on the Channel tab to define a channel’s general properties. Some of the fields on this tab are common to channels on many simple drivers (see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to Simatic S7 channels are explained below:

  • Switch After n scanners have failed—Where a channel can use either the primary or secondary connection port, communications can be swapped from one line to the other. So if ClearSCADA detects a problem on the line that is currently being used, it can switch to the other line and then attempt to re-establish communications with the scanners.

Use the Switch After n scanners have failed field to specify how many scanners on the channel have to fail before the server automatically switches lines.


Simatic S7 Driver Guide - Communicating with Simatic S7 PLCs (Configuring a Simatic S7 Channel)

Communicating with Simatic S7 PLCs

ClearSCADA can communicate with Simatic S7 PLCs using either of the following communication methods:

  • Serial Communications
  • TCP Communications.


Simatic S7 Driver Guide - Serial Communications (Configuring a Simatic S7 Channel)

Serial Communications

For serial communications, ClearSCADA uses channel(s) that have:

  • An MPI via serial adapter Connection Type, in order to communicate with the Simatic S7-300 or S7-400 series of PLCs.
  • A PPI via serial adapter Connection Type, in order to communicate with the Simatic S7-200 series of PLCs.

For information on configuring either of the above Connection Types, see Configure the Connection Properties.

MPI

The serial adapter for use with an MPI connection is called an HMI Adapter. The Siemens order number for this type of adapter is 6ES7 972-0CA11-0XA0.

Use this type of adapter to enable ClearSCADA to communicate with the Simatic S7-300 and S7-400 series of PLCs.

PPI

The serial adapter for use with a PPI connection is called a PPI Cable, RS232. The Siemens order number for this type of adapter is 6ES7 901-3CB30-0XA0.

Use this type of adapter to allow ClearSCADA to communicate with the Simatic S7-200 series of PLCs.

To enable the ClearSCADA Simatic S7 driver to communicate with a Simatic S7-200 series PLC, you need to set the PPI adapter to ‘Freeport’ mode. You do this by setting a DIP switch on the adapter.


Simatic S7 Driver Guide - TCP Communications (Configuring a Simatic S7 Channel)

TCP Communications

For TCP communications, ClearSCADA:

  • Uses channel(s) that have an ISO over TCP/IP Connection Type (see Configure the Connection Properties).
  • Communicates use the following Simatic Industrial Ethernet modules:
  • CP243 for the Simatic S7-200 series of PLCs
  • CP343 for the Simatic S7-300 series of PLCs
  • CP443 for the Simatic S7-400 series of PLCs.


Simatic S7 Driver Guide - Configure the Connection Properties (Configuring a Simatic S7 Channel)

Configure the Connection Properties

Simatic S7 channels are able to use either one or two communication ports, depending on the system setup. Communications can be either MPI via serial adapter, PPI via serial adapter, or ISO over TCP/IP (see Communicating with Simatic S7 PLCs).

MPI is a Multi Point Interface communications protocol that enables the data server (ClearSCADA) to communicate with multiple Simatic S7-300, and/or Simatic S7-400 series PLCs via a serial connection.

PPI enables ClearSCADA to communicate with multiple Simatic S7-200 series PLCs via a serial connection.

ISO over TCP/IP enables ClearSCADA to communicate with multiple Simatic S7-200, S7-300, and/or Simatic S7-400 series PLCs via ethernet.

Use the Connection Type field on the Simatic S7 Channel Form’s Primary Connection and Secondary Connection tabs to specify how many ports are available for a channel and the type of connection used:

No other fields are displayed on the tab if the Connection Type is None, or ISO over TCP/IP. (Select ‘None’ on the Secondary Connection tab if the secondary communication port is not used.)

If the Connection Type is MPI via serial adapter or PPI via serial adapter, these fields are displayed at the top of the relevant Connection tab:

These fields are common to serial-connection channels on many drivers—for information on the fields, see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers.

In addition to the above, other fields are displayed on the Primary Connection and Secondary Connection tabs. These vary, depending on the type of adapter that is specified.

If the Connection Type is MPI via serial adapter, fields are displayed to allow you to:

  • Configure the MPI Station Parameters
  • Configure the Network Parameters.

If the Connection Type is PPI via serial adapter, a field is displayed to allow you to:

  • Configure the PPI Station Parameters.


Simatic S7 Driver Guide - Configure the PPI Station Parameters (Configuring a Simatic S7 Channel)

Configure the PPI Station Parameters

When the Connection Type is set to PPI via serial adapter, use this field on the Connection tab(s) to configure the Station Parameters:

  • Address—Use to specify the address that the adapter is using.


Simatic S7 Driver Guide - Configure the MPI Station Parameters (Configuring a Simatic S7 Channel)

Configure the MPI Station Parameters

When the Connection Type is set to MPI via serial adapter, use these fields on the Connection tab(s) to configure the Station Parameters:

  • PG/PC is the only master on the bus—Select this check box if the Simatic S7 adapter is the only master on the bus that this channel is using.

Clear the check box if there are other masters as well as the Simatic S7 adapter on the bus.

  • Address—Use to specify the address that the server or adapter is using.


Simatic S7 Driver Guide - Configure the Network Parameters (Configuring a Simatic S7 Channel)

Configure the Network Parameters

When the Connection Type is set to MPI via serial adapter, use these fields on the Connection tab(s) to configure the Network Parameters:

  • Transmission Rate—Use this combo box to specify the rate at which the channel transmits data on the network. Choose from 19.2Kbps, 187.5Kbps, and 1.5Mbps.
  • Highest Station Address—Use this combo box to specify the highest permitted station address on the network. Choose from 15, 31, 63, and 126.


Simatic S7 Driver Guide - Configuring a Simatic S7 Scanner

Configuring a Simatic S7 Scanner

A Simatic S7 Scanner is logical functionality that runs within ClearSCADA and scans for data on a Simatic S7-200, S7-300, or S7-400 series PLC.

Configure the Scanner features using the fields on the Simatic S7 Scanner Form.

The Form has several tabs.

Use the fields on the Scanner tab to Configure the Scanner Properties.

Use the fields on the Primary Connection and Secondary Connection tabs to specify the network connection properties, should the scanner use ISO over TCP communications (see Configure the Connection Properties).

For fields on other tabs, see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional Simatic S7 Scanner in ClearSCADA, see Minimum Configuration.


Simatic S7 Driver Guide - Minimum Configuration (Configuring a Simatic S7 Scanner)

Minimum Configuration

For a Simatic S7 scanner to become functional (online), you need to:

  • Specify the Channel through which the scanner communicates
  • Specify the address of the PLC that the scanner is to scan
  • Specify the PLC Type
  • Specify the Data Length
  • Specify the Host Address (only If the scanner is to use ISO over TCP communications).

You also need to put the scanner In Service and save the configuration.

These are the minimum requirements and, when specified, will result in a functional scanner that uses the default configuration settings.


Simatic S7 Driver Guide - Configure the Scanner Properties (Configuring a Simatic S7 Scanner)

Configure the Scanner Properties

Use the fields on the Scanner tab to:

  • Configure the General Scanner Properties
  • Configure the Scan Properties.


Simatic S7 Driver Guide - Configure the General Scanner Properties (Configuring a Simatic S7 Scanner)

Configure the General Scanner Properties

Use the fields toward the top of the Scanner tab to define the general scanner properties. Some of these fields are common to many scanners (see Define Common Scanner Properties in the ClearSCADA Guide to Simple Drivers). Those fields that are specific to scanners on the Simatic S7 driver are described below.

  • Channel—Specify the channel through which the scanner sends and receives data. Use the browse button to display a Reference Browse window. From the window, select the channel that the scanner uses to communicate with the Simatic S7-200, S7-300, or S7-400 series PLC.
  • PLC Address—Only applies to Scanners on Channels that have an MPI via serial adapter, or PPI via serial adapter Connection Type (see Configure the Connection Properties).

Use the PLC Address field to specify the address of the PLC that is to respond to any requests for data changes or control actions. The PLC Address has to be lower than the Highest Station Address on the channel (see Configure the Network Parameters).


Simatic S7 Driver Guide - Configure the Scan Properties (Configuring a Simatic S7 Scanner)

Configure the Scan Properties

Use these fields on the Scanner tab to define properties such as the scan rate, scan offset, and the type of data that is to be scanned.

You can also specify whether the scan rate is increased whenever any of the associated points are displayed on a client (see Define Whether a Scanner is Promoted While its Points are on Display in the ClearSCADA Guide to Simple Drivers).

For information on fields that are available for many scanners, see Define the Scan Rate in the ClearSCADA Guide to Simple Drivers. Fields that are specific to Simatic S7 scanners are explained below:

  • PLC Type—Use this combo box to specify the series of Simatic S7 PLC that the Scanner is to scan. Choose S7-200, S7-300, or S7-400, as appropriate.

(Remember that for serial communications the associated Channel’s Connection Type also varies, depending on the type of PLC—for more information, see Communicating with Simatic S7 PLCs.)

  • Area—Use this combo box to specify the area of memory that the Scanner is to scan in the Simatic S7-200, S7-300, or S7-400 series PLC. The entries that you can choose from vary, depending on the PLC Type, but include a combination of the following:
  • Input Register—The read-only memory area for physical inputs. This area can include both digital and analog input data.
  • Output Register—The read/write memory area for physical outputs. This area can include both digital and analog output data.
  • Data Block—The write-only memory area for the variables that are used in the PLC’s internal logic programs.
  • Flags/Markers—The memory area for flag data. Applies to Simatic S7-300 and S7-400 series PLCs only.
  • Timers—The memory area for timer data. Applies to Simatic S7-300 and S7-400 series PLCs only.
  • Counters—The memory area for counter data. Applies to Simatic S7-300 and S7-400 series PLCs only.
  • Analog Inputs—The read-only memory area for analog inputs. Applies to Simatic S7-200 series PLCs only.
  • Analog Outputs—The read/write memory area for analog outputs. Applies to Simatic S7-200 series PLCs only.
  • IEC Timers—The memory area for timer data that is used in IEC programs. Applies to Simatic S7-200 series PLCs only.
  • IEC Counters—The memory area for counter data that is used in IEC programs. Applies to Simatic S7-200 series PLCs only.
  • Special Memory—The memory area used storing for PLC status information. Applies to Simatic S7-200 series PLCs only.
  • Data Block Number—Applies if the Area of memory that is being scanned is merely specified as a Data Block (see above). Use this field to specify the number of the block of data that is to be scanned.

The size of the Data Block memory area varies, depending on the model of PLC—for more information, see the documentation supplied with the Simatic S7 PLC.

  • Data Address—Specify the position in the Simatic S7 register from which the scanner is to start scanning data, from within the specified memory Area (see above). This is the number of bytes offset into the Area.

Be aware that the size of each memory area varies, depending on the model of PLC.

  • Data Length—Enter the number of registers that are to be scanned. The registers each comprise one byte (8 bits) and are scanned as a block, starting with the register specified in the Data Address field, above.

Be aware that the size of each memory area, and therefore the number of registers, varies, depending on the model of PLC— for more information, see the documentation supplied with the Simatic S7 PLC.

  • Promote when Displaying Points—Use this check box to specify whether you want the ClearSCADA server to give scanning preference to a scanner whenever any of its points are displayed on a client.

For more information, see Define Whether a Scanner is Promoted While its Points are on Display in the ClearSCADA Guide to Simple Drivers.

  • Always Update on Scan—Use this check box to indicate whether you want to use the scanner’s updates as a trigger for a Logic program (see Define Whether a Scanner is Used to Trigger Logic in the ClearSCADA Guide to Simple Drivers).


Simatic S7 Driver Guide - Configure the Connection Properties (Configuring a Simatic S7 Scanner)

Configure the Connection Properties

Use the fields on the Primary Connection and Secondary Connection tabs to specify whether the scanner scans data on a remote network device:

  • Connection Type—Specify whether the scanner uses any ports to communicate with a device using ISO over TCP. Choose from:
  • None—The port is not used.

Select the ‘None’ option on both Connection tabs if the scanner uses an MPI or PPI serial connection to communicate with the Simatic S7 PLC.

  • Network—The port is used to communicate with a Simatic S7 PLC, using ISO over TCP.
  • Host Address—Displayed if the Connection Type is set to ‘Network’. Use the field to specify the IP address of the PLC or other device.
  • Port—Displayed if the Connection Type is set to ‘Network’. Specify the number of the TCP/IP port on the remote network device, through which the scanner is to communicate with a Simatic S7 PLC.

The default is 102—the port number that is registered for ISO over TCP use with the IANA (Internet Assigned Numbers Authority).

Additionally, when the Connection Type is set to ‘Network’, and the PLC Type is ‘S7-300’ or ‘S7-400’, the Connection tab(s) display a CPU Settings section, which you use to Configure the CPU Properties.


Simatic S7 Driver Guide - Configure the CPU Properties (Configuring a Simatic S7 Scanner)

Configure the CPU Properties

A CPU Settings section is displayed on the relevant Connection tab(s) when the PLC Type is set to S7-300 or S7-400.

Use the fields within the CPU Settings section to specify the rack and slot number of the Central Processing Unit (CPU). The section is displayed whenever the scanner is configured to use a ‘Network’ Connection Type (see Configure the Connection Properties).

  • Rack—Use to specify the number of the rack in which the CPU resides.
  • Slot—Use to specify the number of the slot in which the CPU resides.


Simatic S7 Driver Guide - Points Used on Simatic S7 Scanners

Points Used on Simatic S7 Scanners

Simatic S7 Scanners can support the Analog Points and Digital Points.

You configure the Simatic S7 points on your system using the Simatic S7 Analog Point Form, or the Simatic S7 Digital Point Form, as appropriate.

Each Form has several tabs.

You define the Area of memory that each Scanner is to scan using the relevant fields on the Scanner Form (see Configure the Scan Properties). You then define the location of the specific items of data with which each point is associated and the Scanner that is to scan that data, using properties on the Simatic S7 tab on each Point Form.

For information on configuring properties on the Simatic S7 tab, see Configuring Analog Points, or see Configuring Digital Points.

For information on configuring properties on the <Point Type> tab, see the appropriate reference below:

  • Analog Point—see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration
  • Digital Point—see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

Use the Enabled check box on the Control tab to specify whether a particular point is used as an Input point or an Output point. An Input point is used to retrieve data from a read-only memory area on a Simatic S7 PLC, whereas an Output point is used to write data to a read/write memory area:

  • For ClearSCADA to read data from a read-only memory area (such as an Input Register or Analog Inputs area), you need to clear the Enabled check box on the Point Form’s Control tab. This sets the point to be an Input point and makes the Control tab settings unavailable.
  • For ClearSCADA to write data to an Output Register, Analog Output, Flag/Marker, Special Memory or Data Block, you need to select the Enabled check box on the Point Form’s Control tab. You also need to configure the settings on the Control tab.

For information on configuring properties on the Control tab, see:

  • Analog Point—see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration
  • Digital Point—see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration.

For properties on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.

For information on creating a point and displaying a Point Form, see Create and Configure a Point in the ClearSCADA Guide to Core Point Configuration.


Simatic S7 Driver Guide - Configuring Analog Points

Configuring Analog Points

The Simatic S7 driver supports Analog points.

Analog points can be physical points that exist on Simatic S7 PLCs, or calculated values that reside within Simatic S7 registers.

Configure the properties for each analog point using the fields on the Simatic S7 Analog Point Form.

This section covers configuration of properties on the Simatic S7 tab of the Form.

Use the Simatic S7 tab to:

  • Configure the Simatic S7 Point Properties
  • Configure Scaling Properties (see Scale Analog Values for use in ClearSCADA in the ClearSCADA Guide to Simple Drivers)
  • Configure Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration).

For information on the fields on the Analog Point tab, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on the Control tab, see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


Simatic S7 Driver Guide - Configure the Simatic S7 Point Properties (Configuring Analog Points)

Configure the Simatic S7 Point Properties

Use the fields at the top of the Simatic S7 tab to configure the Simatic S7-specific point properties. Some of these fields are common to many simple drivers (see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers). Fields that are specific to analog points on the Simatic S7 driver are explained below:

  • Data Address—Specify the address of the register in which the point data is located. The specified address has to be located in the block of registers that the Scanner is configured to scan (see Configure the Scan Properties).

Example:

A scanner scans several analog points on a Simatic S7 PLC.

The scanner has this configuration:

Area: Input Register
Data Address: 10
Data Length: 12

One of the analog points has this configuration:

Data Address: 11
Data Type: INT (the data is stored as a 16-bit value)

The configuration determines that the scanner scans Input Registers 10 to 21 within the PLC. Within this block of registers, the data for the above analog point is located at registers 11 and 12. (As each register is one byte, the analog data comprises two consecutive registers, starting at register address 11.)

  • Data Type—Specify the format of the raw analog data.

Choose from:

  • UBYTE—Unsigned 8-bit data. Each UBYTE comprises one Simatic S7 register.
  • BYTE—Signed 8-bit data. Each BYTE comprises one Simatic S7 register.
  • UINT—Unsigned 16-bit data. Each UINT comprises two Simatic S7 registers.
  • INT—Signed 16-bit data. Each INT comprises two Simatic S7 registers.
  • UDINT—Unsigned 32-bit data. Each UDINT comprises four Simatic S7 registers.
  • DINT—Signed 32-bit data. Each DINT comprises four Simatic S7 registers.
  • REAL—IEEE 32-bit single-precision floating point value. Each REAL comprises four Simatic S7 registers.

The byte specified in the Data Address field, above, has to indicate the first byte (or register) of a multi-register point.

  • Swap Registers—Applies to Data Types other than UBYTE and BYTE. As this data comprises two or four 8-bit bytes, you can use this check box to specify the order in which the bytes of data are presented in ClearSCADA, and therefore the value that they represent.

Clear the check box if you do not want the data in the registers to be swapped for use in ClearSCADA. For multi-register data, the highest numbered register contains the most significant byte.

Select the check box if the byte values are to be swapped for use in ClearSCADA. For multi-register data, the lowest numbered register contains the most significant byte.

Example:

An analog value has a DINT data type, and is located at registers 16 to 19 in a PLC. The Registers are not swapped.

The present value of the analog is:

Byte 16 = 1
Byte 17 = 0
Byte 18 = 0
Byte 19 = 0

As the registers are not swapped, this results in the analog point being given a value of 1 within ClearSCADA.

If the configuration was such that the registers were swapped, this would result in the analog point being given a value of 2147483648 within ClearSCADA.


Simatic S7 Driver Guide - Configuring Digital Points

Configuring Digital Points

The Simatic S7 driver supports 1-, 2-, and 3-bit Digital points.

Digital points can be physical points that exist on Simatic S7 PLCs, or calculated states that reside within Simatic S7 registers.

Configure the properties for each Digital Point using the fields on the Simatic S7 Digital Point Form.

This section covers configuration of properties on the Simatic S7 tab of the Form (see Configure the Simatic S7 Point Properties).

For information on the fields on the Digital Point tab, see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on the Control tab, see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers.


Simatic S7 Driver Guide - Configure the Simatic S7 Point Properties (Configuring Digital Points)

Configure the Simatic S7 Point Properties

Use the fields on the Simatic S7 tab to define the Simatic S7-specific properties for a digital point. For information on those fields that are common to many simple drivers, see Configure Common Point Properties in the ClearSCADA Guide to Simple Drivers. Fields that are specific to digital points on the Simatic S7 driver are described below:

  • Data Address—Specify the address of the register in which the point data is located. The specified address has to be located in the block of registers that the Scanner is configured to scan (see Configure the Scan Properties).
  • Bit Offset—Enter the lowest (starting) bit of the point data within the above register. Each register comprises one 8-bit byte. Specify the starting bit as an offset, in the range 0 to 7.

With a multi-bit point, the bits are consecutive. (For example, a 2-bit digital might use bits 5 and 6, where bit 5 would be the starting bit.) The bits of a multi-bit point have to reside consecutively in the same byte in a register range—bits for one point cannot continue into another byte.

An example at the end of this section shows how the Data Address and Bit Offset are used.

  • Persistence—Specify the time that the driver waits before it reports a change of state. Enter the time in seconds.

Example:

A scanner scans several digital points on a Simatic S7 PLC.

The scanner has this configuration:

Area: Input Register
Data Address: 10
Data Length: 14

One of the digital points has this configuration:

Number of Bits:2
Data Address: 11
Bit Offset: 5

The configuration determines that the scanner scans registers 10 to 23 within the PLC. In this block of registers, the digital point detailed above is located at register 11, starting at the sixth bit within that register, and continuing to the seventh bit.

To read the value of this point, the scanner extracts bits 6 and 7 of register 11.


Simatic S7 Driver Guide - Simatic S7 Specific Status Display Attributes

Simatic S7 Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each Simatic S7 Analog Point provides information about the present state of the individual point.

Use this section if you need information on the status of any Simatic S7 database items on your system.

This section covers those status attributes that are Simatic S7-specific and includes:

  • Simatic S7 Channel Status Attributes
  • Simatic S7 Point Status Attributes
  • Simatic S7 Scanner Status Attributes
  • Alphabetical List of Simatic S7 Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Simatic S7 Driver Guide - Simatic S7 Channel Status Attributes (Simatic S7 Specific Status Display Attributes)

Simatic S7 Channel Status Attributes

These status attributes are specific to Simatic S7 channels:

  • Primary Assign
  • Secondary Assign
  • Source.

NOTE: Two further status attributes—Primary Eavesdrop Tx Assign, and Secondary Eavesdrop Tx Assign—are not used by the Simatic S7 driver.


Simatic S7 Driver Guide - Simatic S7 Scanner Status Attributes (Simatic S7 Specific Status Display Attributes)

Simatic S7 Scanner Status Attributes

These status attributes are specific to Simatic S7 scanners:

  • Source
  • Current Path
  • Comms Statistics.


Simatic S7 Driver Guide - Simatic S7 Point Status Attributes (Simatic S7 Specific Status Display Attributes)

Simatic S7 Point Status Attributes

This status attribute is specific to Simatic S7 points:

  • Source.


Simatic S7 Driver Guide - Alphabetical List of Simatic S7 Specific Status Display Attributes (Simatic S7 Specific Status Display Attributes)

Alphabetical List of Simatic S7 Specific Status Display Attributes

This section lists those status attributes that are specific to items on the Simatic S7 driver. The attributes are listed in alphabetical order and comprise:

  • Comms Statistics
  • Current Path
  • Primary Assign
  • Secondary Assign
  • Source.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.


Simatic S7 Driver Guide - Comms Statistics (Simatic S7 Specific Status Display Attributes)

Comms Statistics

Associated with: Simatic S7 scanners

This status attribute shows the number of:

  • Reads—Successful read operations
  • Writes—Successful write operations
  • Timeouts—Requests that did not receive a response within the expected time and therefore timed out. (The actual Timeout period is specified on the Channel Form.)
  • CRCs—Cyclic Redundancy Check (CRC) errors
  • Unknown—Any other errors

that have been detected on a scanner since that scanner was last restarted.

Example:

245 reads, 67 writes, 3 timeouts, 2 CRCs, 0 unknown


Simatic S7 Driver Guide - Current Path (Simatic S7 Specific Status Display Attributes)

Current Path

Associated with: Simatic S7 scanners

This status attribute displays the path that the scanner is using. The information that is displayed varies, depending on the type of connection.

With a scanner that uses an MPI or PPI serial connection to communicate with a Simatic S7 device, the Current Path attribute indicates which port the channel is using.

With a scanner that communicates using ISO over TCP, the Current Path attribute displays the Host Address of the remote network device.


Simatic S7 Driver Guide - Primary Assign (Simatic S7 Specific Status Display Attributes)

Primary Assign

Associated with: Simatic S7 channels

The Primary Assign attribute indicates whether ClearSCADA has detected a problem with the assignment of a Simatic S7 channel to its primary serial line has failed. The line is defined on the Primary Connection tab of the Channel Form (see Configure the Connection Properties).

Possible States: Displays one of the Standard Alarm States.


Simatic S7 Driver Guide - Secondary Assign (Simatic S7 Specific Status Display Attributes)

Secondary Assign

Associated with: Simatic S7 channels

The Secondary Assign attribute indicates whether ClearSCADA has detected a problem with the assignment of a Simatic S7 channel to its secondary serial line. The line is defined on the Secondary Connection tab of the Channel Form (see Configure the Connection Properties).

Possible States: Displays one of the Standard Alarm States.


Simatic S7 Driver Guide - Source (Simatic S7 Specific Status Display Attributes)

Source

Associated with: Simatic S7 channels, sources, Analog points and Digital points

The Source attribute is common to many Status displays. The attribute indicates the location at which the item, for example the point, resides. The information shown varies, depending on the type of item. For items on the Simatic S7 driver, this information is displayed:

Simatic S7 Item

Source Attribute

Channel
(ISO comms)

Format

<Channel Comms>

Example:

SIMATICS7/TCP

Channel
(MPI comms)

Format

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> (MPI <Address>)

Example:

COM1:19200:8O1 (MPI 17)
(For a Simatic S7 channel with an MPI via serial adapter connection. The server is using station address 17 and is communicating via port COM1, at 19200 baud, using 8 bits, Odd parity, and 1 stop bit.)

Channel
(PPI comms)

Format

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> (PPI <Address>)

Example:

COM1:9600:8E1 (PPI 12)
(For a Simatic S7 channel with a PPI via serial adapter connection. The server is using station address 12 and is communicating via port COM1, at 9600 baud, using 8 bits, Even parity, and 1 stop bit.)

Scanner

(on a channel that uses MPI or PPI comms)

Format

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> (MPI or PPI <Address>):PLC <Address>, <Area> - <Memory Area><starting Data Address>-<Memory Area><ending Data Address>

Example:

COM1:19200:8O1 (MPI 17):PLC 4, Input Register - I2-I7

(For a Simatic S7 scanner on a channel that has an MPI via serial adapter connection. The scanner is configured to scan registers I2 to I7 within the Input Register memory area, in the PLC that has an address of 4. To scan these Input Registers, the scanner is configured to have a Data Address of 2 and a Data Length of 6. (Channel configuration is as per example above.))

Scanner (on a channel that uses ISO comms)

Format

<Channel Comms>-<Host Address> <Port>:Device <Address>, <Area> - <Memory Area><starting Data Address>-<Memory Area><ending Data Address>

Example:

SIMATICS7/TCP-MYPC5 COM1:Device 22, Output Register - Q3-Q6

(For a Simatic S7 scanner on a channel that communicates using ISO over TCP/IP. The scanner is configured to scan registers Q3 to Q6 within the Output Register memory area, in the remote device that has an address of 22. To scan these Output Registers, the scanner is configured to have a Data Address of 3 and a Data Length of 4. (Channel configuration is as per the first example above.))

Analog Point

Format

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> (MPI <Address>):PLC <Address>, <Area> - AG <Memory Area><Data Size><Data Address> (<Data Type>)

Example:

COM1:19200:8O1 (MPI 17):PLC 4, Input Register - AG IW3 (UINT)
(For a Simatic S7 analog point that represents two-byte UINT input data. The data starts at register address 3. (The scanner configuration is as per the example above.))

Digital Point

Format

<Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> (MPI <Address>):PLC <Address>, <Area> - DG <Memory Area><Data Address>.<Bit Offset>

Example:

COM1:19200:8O1 (MPI 17):PLC 4, Input Register - DG I2.7
(For a Simatic S7 digital point that represents the data at Data Address I2, bit offset 7. (The scanner configuration is as per the example above.))

For a multi-bit digital point, the Source attribute takes the form:

COM1:19200:8O1 (MPI 17):PLC 4, Input Register - DG I2.6-7
(indicating both the starting and ending bit offsets).

With a channel that can use either of two ports, the Source attribute displays the source information for the Primary Connection port, followed by the source information for the Secondary Connection port.

Similarly, with a scanner on a channel that can use either of two ports, the Source attribute lists the source information for the channel’s Primary then Secondary Connection ports, followed by the scanner-specific source information. If the scanner communicates with a device using ISO over TCP and can use either of two network ports to do so, both sets of scanner port details follow on from the channel’s source details.

In keeping with Simatic terminology, the Source attribute uses the following abbreviations to indicate the area of memory with which an item is associated:
Abbreviation | Memory Area
I | Input Register
Q | Output Register
F | Flags/Markers
T | Timers
C | Counters
AI | Analog Inputs
AQ | Analog Outputs
T | IEC Timers
C | IEC Counters
V | Data Block
SM | Special Memory

and the following abbreviations to indicate the size of the data that each point represents:
Abbreviation | Data Size
B | One byte
W | Two bytes
D | Four bytes


Trio Diagnostics Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Trio Diagnostics Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Trio Diagnostics Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Trio Diagnostics Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Trio Diagnostics Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Trio Diagnostics Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure Trio Diagnostics specific features and items in the ClearSCADA database. It also provides information about Trio Diagnostics terminology and driver-specific statistics which can be used for diagnostics.

For more information about the subjects covered in this guide, see Introduction to the Trio Diagnostics Driver.


Trio Diagnostics Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by engineers who are responsible for configuring Trio Diagnostics features and items in the ClearSCADA database. It can also be used by system administrators when investigating the cause of unexpected behavior relating to the Trio Diagnostics driver.


Trio Diagnostics Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Trio Diagnostics Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Simple Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration.


Trio Diagnostics Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Trio Diagnostics Driver Guide - Introduction to the Trio Diagnostics Driver

Introduction to the Trio Diagnostics Driver

ClearSCADA’s Trio Diagnostics driver provides additional functionality to enable ClearSCADA to communicate with a network of Trio Datacom radios. ClearSCADA communicates with each radio network via a single Trio Datacom ‘base’ radio (see Supported System Setups). The ‘base’ radio might be any of several radio products, such as a Trio Datacom base station, or a Trio Datacom remote data radio unit.

The driver enables ClearSCADA to interrogate each Trio Datacom radio on the radio network for diagnostics data. The type of diagnostics data that ClearSCADA can retrieve from each radio varies, depending on the radio series (see Trio Datacom Radio Series Supported by the Trio Diagnostics Driver) and the type of radio unit.

The ClearSCADA Trio Diagnostics driver documentation explains how to configure Trio Diagnostics specific features and items in the ClearSCADA database (see Configure ClearSCADA to Retrieve Trio Datacom Radio Diagnostics).

The guide also provides information about:

  • Trio Diagnostics Terminology of which you might need to be aware.
  • Driver-specific aspects that may be of interest to system administrators and engineers when investigating unexpected system behavior (relating to the driver) (see Trio Diagnostics Specific Status Display Attributes).

For any Trio Diagnostics information not included in this guide, see the documentation supplied with your Trio Datacom radio equipment.

NOTE: There are no driver-specific pick actions for items on the Trio Diagnostics driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


Trio Diagnostics Driver Guide - Trio Diagnostics Terminology (Introduction to the Trio Diagnostics Driver)

Trio Diagnostics Terminology

This section summarizes the Trio Diagnostics terms with which you might need to be familiar, in order to configure the Trio Diagnostics specific properties in ClearSCADA. These terms include:

  • PIC
  • SID.


Trio Diagnostics Driver Guide - PIC (Introduction to the Trio Diagnostics Driver)

PIC

Each parameter (item of data) in a Trio Datacom radio is identified by its Parameter Identifier Code (PIC). The diagnostics parameters that can be retrieved from each Trio Datacom radio vary, depending on the radio series and type of radio unit (for example, a base station).

In the ClearSCADA database, you configure a Trio Diagnostics Point of the appropriate type for each item of diagnostics data that ClearSCADA is to retrieve from a Trio Datacom radio. You then use the Parameter field on each Trio Diagnostics Point Form to specify the PIC for which ClearSCADA is to retrieve diagnostics. The PIC identifies the diagnostics parameter that each database point represents. For more information, see Configure the Common Trio Diagnostics Point Properties.

With D Series radios, the diagnostics parameters are retrieved using Trio Diagnostics Analog points.


Trio Diagnostics Driver Guide - SID (Introduction to the Trio Diagnostics Driver)

SID

Many of the series of Trio Datacom radios with which ClearSCADA can communicate provide SID support.

The Stream Identifier code (also known as the Stream ID or SID code) provides the addressing mechanism for data stream routing on radio networks that use multiple message streams. The SID code identifies the message stream that is used by a particular Trio Datacom radio on such a radio network.

ClearSCADA provides two configuration properties related to SID support:

  • The Send SID check box on the Trio Diagnostics Channel Form (see Specify Whether to Include the Stream Identifier in each Data Packet)
  • The Stream ID field on each Trio Diagnostics Radio Form (see Specify the Stream on which the Radio is to Transmit Messages).

For further information on SID codes and multistream functionality, see the documentation supplied with your Trio Datacom radio equipment.


Trio Diagnostics Driver Guide - Trio Datacom Radio Series Supported by the Trio Diagnostics Driver (Introduction to the Trio Diagnostics Driver)

Trio Datacom Radio Series Supported by the Trio Diagnostics Driver

You can use ClearSCADA’s Trio Diagnostics driver to retrieve diagnostics data from several series of Trio Datacom radio. The type of diagnostics data that ClearSCADA can retrieve from each radio varies, depending on the radio series and the type of radio unit.

The Trio Diagnostics driver provides support for retrieving diagnostics data from the following series of Trio Datacom radio:

Trio Datacom Radio

Comments

D Series

D Series radios are capable of providing feedback on fewer diagnostics parameters than other radio series supported by the Trio Diagnostics driver. Each of the diagnostics parameters can be retrieved using a Trio Diagnostics Analog point.

D Series radios provide a subset of other features supported by later series of Trio Datacom radios.

E Series

The E, J, K, and M Series of Trio Datacom radios use a diagnostics protocol that provides additional functionality to D Series radios.

The actual items of diagnostics data that can be retrieved from each radio vary, depending on the radio series and type of unit (for example, a base station, repeater station, or remote data radio).

J Series

K Series

M Series

Further Information

Supported System Setups.


Trio Diagnostics Driver Guide - Supported System Setups (Introduction to the Trio Diagnostics Driver)

Supported System Setups

The Trio Diagnostics driver enables ClearSCADA to retrieve diagnostics data from various types of Trio Datacom radio (see Trio Datacom Radio Series Supported by the Trio Diagnostics Driver). The driver enables ClearSCADA to communicate with network(s) of Trio Datacom radios, via one or more Trio Datacom ‘base’ radios. A ‘base’ radio might be any of several radio products, such as a Trio Datacom base station, or a Trio Datacom remote data radio unit. Each ‘base’ radio provides the communications link with other remote Trio Datacom radios.

Depending on the radio series and system setup, ClearSCADA can communicate with a Trio Datacom ‘base’ radio using a direct serial connection (such as RS-232) or a TCP/IP connection. The latter connection type can be used to enable the ClearSCADA server to connect directly to a J Series ‘base’ radio, or connect to a Terminal Server or similar device, which itself provides a serial connection to the Trio Datacom radio. With the latter setup, no Terminal Server database item is needed to represent the Terminal Server or similar device in the ClearSCADA database, as that device is merely providing a communications path to the ‘base’ radio; however the Trio Diagnostics Channel database item has to be configured to represent the communications link between ClearSCADA and the Terminal Server.

When the Trio Diagnostics driver sends a request for data to a ‘base’ radio, the ‘base’ radio responds by either sending information about its own diagnostics back to ClearSCADA, or by forwarding the request onto the relevant remote Trio Datacom radio unit. Each data request and corresponding reply includes the serial number of the relevant radio, to identify the radio with which each message is associated.

Further Information

Configuring a Trio Diagnostics Channel.

Configuring a Trio Diagnostics Radio.


Trio Diagnostics Driver Guide - Configure ClearSCADA to Retrieve Trio Datacom Radio Diagnostics (Introduction to the Trio Diagnostics Driver)

Configure ClearSCADA to Retrieve Trio Datacom Radio Diagnostics

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the devices and parameters that you want to monitor on your system. This section summarizes the database items that you need to configure on your system in order for ClearSCADA to retrieve diagnostics data from Trio Datacom radios.

ClearSCADA can only retrieve diagnostics from Trio Datacom radios if the Trio Diagnostics Driver is installed and running on the ClearSCADA servers on your system. Similarly, you can only configure the required database items if the Trio Diagnostics Driver is installed and running on the ClearSCADA servers.

When you configure Trio Diagnostics items in the ClearSCADA database, many of the settings of those items need to correspond to the settings of the relevant Trio Datacom devices on your system. Some settings are either fixed (incorporated into the design of the Trio Datacom radio) or are configured by an engineer. You need to have access to, or an understanding of, the settings of the Trio Datacom devices on your system before you can configure the Trio Diagnostics database items successfully.

For instance, you need to know the serial number of each Trio Datacom radio and be familiar with Trio Diagnostics Terminology.

You also need to be aware of which optional features are required for each Trio Diagnostics database item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with Trio Diagnostics database items, including Lists, Actions, and Mimics. See the core documentation for details.

In the ClearSCADA database, you need to configure:

  1. One Trio Diagnostics Channel for each communication connection between the ClearSCADA server and a Trio Datacom ‘base’ radio (see Configuring a Trio Diagnostics Channel).
  2. At least one Trio Diagnostics Radio for each Trio Datacom radio from which ClearSCADA is to retrieve diagnostics data (see Configuring a Trio Diagnostics Radio).

If some diagnostics data needs retrieving more frequently that other diagnostics data on the same radio, use more than one Trio Diagnostics Radio item to represent the same radio unit (see Configuring a Trio Diagnostics Radio).

  3. One Trio Diagnostics Point of the appropriate type for each item of diagnostics data that ClearSCADA is to retrieve from a Trio Datacom radio (see Points Used on Trio Diagnostics Radios). (With D Series radios, the available diagnostics parameters are retrieved using Trio Diagnostics Analog points.)

To minimize the time that it takes to configure the Trio Diagnostics items, you may want to configure them in the order listed above, as Radio configuration requires that you specify a Channel, and Point configuration requires that you specify a Radio, and so on.


Trio Diagnostics Driver Guide - Configuring a Trio Diagnostics Channel

Configuring a Trio Diagnostics Channel

In the ClearSCADA database, you use a Trio Diagnostics Channel database item to define the communication properties between ClearSCADA and a Trio Datacom ‘base’ radio. The ‘base’ radio provides the communications path to the other Trio Datacom radios on the network.

You need to configure one Trio Diagnostics Channel item for each ‘base’ radio that is connected to the ClearSCADA server. (If the ‘base’ radio is connected to a Terminal Server or similar device, which itself is connected to ClearSCADA, use the Trio Diagnostics Channel database item to specify the type of communications between ClearSCADA and the Terminal Server.)

Depending on your system setup and the radio series, ClearSCADA can communicate with a Trio Datacom ‘base’ radio using either a Direct Serial, or TCP/IP connection (see Supported System Setups).

You specify the properties of each channel using the fields on the Trio Diagnostics Channel Form. The Form has several tabs.

Use the fields on the Channel tab to:

  • Specify the common channel properties (see Configure the Basic Channel Properties in the ClearSCADA Guide to Simple Drivers)
  • Specify the Controller Address.
  • Specify Whether to Include the Stream Identifier in each Data Packet.

Use the fields on the Connection tab to:

  • Specify the Connection Type (see Configure a Channel’s Connection Type in the ClearSCADA Guide to Drivers). Each Trio Diagnostics Channel can have either a Serial or TCP/IP Connection Type.

With a channel that has a Serial Connection Type, use the rest of the fields on the tab to:

  • Configure the Serial Properties (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

With a channel that has a TCP/IP Connection Type, use the rest of the fields on the tab to:

  • Configure the basic TCP/IP Properties (see Configure a Channel’s TCP/IP Connection Properties in the ClearSCADA Guide to Drivers)
  • Specify the Local TCP/IP Port
  • Specify the TCP ‘Keep Alive’ Interval.

The properties on the other tabs are common to many types of database item (see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers).


Trio Diagnostics Driver Guide - Specify the Controller Address (Configuring a Trio Diagnostics Channel)

Specify the Controller Address

On radio networks on which multiple diagnostics software applications are active, each diagnostics application has to be assigned a different controller address. The controller address is used to identify the diagnostics application with which communications are associated and so avoid impacting on system performance.

Use the Controller Address field on the Channel tab to identify the controller address of the diagnostics software application for which this channel provides communications.

Leave at the default of 1 if ClearSCADA is the only diagnostics software application in use on the radio network.

If multiple diagnostics software applications are active on your radio network, use the Controller Address field to specify the address that identifies ClearSCADA as the diagnostics application that is interrogating the radios via this channel. Specify the required controller address in the range 1 to 999 inclusive. The address is included in the messages transmitted via the channel.


Trio Diagnostics Driver Guide - Specify Whether to Include the Stream Identifier in each Data Packet (Configuring a Trio Diagnostics Channel)

Specify Whether to Include the Stream Identifier in each Data Packet

Trio Datacom radios are capable of communicating via one of multiple message streams. Of the Trio Datacom radio series with which ClearSCADA can communicate, radios other than D Series can use a Stream Identifier (SID) code to identify the particular message stream that is being used.

Select the Send SID check box on the Channel tab if the radio port that ClearSCADA uses to communicate with the ‘base’ Trio Datacom radio is one of the following:

  • The System or Diagnostics/Programming port on an E, K, or M Series radio
  • The eDiags (Ethernet) port on a J Series radio with which ClearSCADA communicates using TCP/IP
  • A Serial port that is configured as a Trunk port.

With such communications, use the Stream ID field on each Trio Diagnostics Radio Form to specify the actual message stream used by each radio (see Specify the Stream on which the Radio is to Transmit Messages).

Clear the Send SID check box if:

  • The ‘base’ radio is a D Series radio

or:

  • The radio port that ClearSCADA uses to communicate with the ‘base’ radio is a Serial port that is configured as a User port.


Trio Diagnostics Driver Guide - Specify the Local TCP/IP Port (Configuring a Trio Diagnostics Channel)

Specify the Local TCP/IP Port

This section applies when a Trio Diagnostics channel has a TCP/IP Connection Type and is used for communicating with a network of radios via a Trio Datacom J Series ‘base’ radio.

Use the Local Port field to specify the IP port on which the server listens for replies from any radios that communicate via this channel.

The port on which the radios reply is typically specified as part of each radio’s firmware configuration.

If the channel communicates with the J Series ‘base’ radio using the radio’s eDiags port, use the Local Port field to specify the Controller IP Port that is configured in the ‘base’ radio.

If communications is via a Terminal Server or similar device and that device sends replies to a fixed port number, specify that port number in the Local Port field.

If communications is via a Terminal Server or similar device that uses an ephemeral port rather than a fixed port number, leave the Local Port at the default of 0 (zero). An ephemeral port is a short-lived temporarily assigned TCP/IP port that is only valid for the duration of the connection. The Windows® operating system will select a suitable port number. ClearSCADA includes the port number in any requests that it sends to the radios that use this channel, to indicate the port to which replies have to be sent.


Trio Diagnostics Driver Guide - Specify the TCP 'Keep Alive' Interval (Configuring a Trio Diagnostics Channel)

Specify the TCP ‘Keep Alive’ Interval

This section applies when a Trio Diagnostics channel has a TCP/IP Connection Type and the channel’s TCP/IP Type is set to TCP.

Use the Keep Alive Time field to specify the frequency with which ClearSCADA transmits test messages across the active TCP socket. The test messages are sent to check that the link remains active.

Enter the time in the OPC Time Format.

If communications with the ‘base’ radio is via a Terminal Server or similar device, be aware that the connection may still close due to an application level timeout in that device (as the Keep Alive Time only works at the TCP level).

Specify a Keep Alive Time of 0 (zero) if such a timer is not required.


Trio Diagnostics Driver Guide - Configuring a Trio Diagnostics Radio

Configuring a Trio Diagnostics Radio

The Trio Diagnostics driver enables ClearSCADA to communicate with a network of Trio Datacom radios, via one or more Trio Datacom ‘base’ radios. Each ‘base’ radio is connected to the ClearSCADA server and provides the communications path to the other Trio Datacom radios on the radio network (see Supported System Setups).

You need to configure at least one Trio Diagnostics Radio database item for each Trio Datacom radio from which ClearSCADA is to retrieve diagnostics data.

If some diagnostics data needs retrieving more frequently than other diagnostics data on the same radio unit, configure two or more Trio Diagnostics Radios to represent the same radio unit: one per required scan rate.

If multiple Trio Diagnostics Radio database items are to represent the same radio unit:

  • Assign the same Unit Serial Number to each radio database item
  • Use each radio database item to specify a different set of scan rates
  • Associate the points that represent the various items of diagnostics data on the radio with the correct radio database item (the one that defines the required scan rate from that particular item of diagnostics data). For more information, see Points Used on Trio Diagnostics Radios.

You specify the properties of each radio using the fields on the Trio Diagnostics Radio Form. The Form has several tabs, including a Radio tab. The Radio tab contains radio-specific properties and properties that are common to Scanner database items on other simple drivers. For this reason, some of the references below refer to the ‘Configuring Scanners’ section in the ClearSCADA Guide to Simple Drivers.

Use the fields on the Radio tab to:

  • Specify whether the radio is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration)
  • Specify the Channel with which the Radio is Associated
  • Specify the Serial Number of the Radio Unit
  • Specify the Stream on which the Radio is to Transmit Messages
  • Specify the Protocol Version
  • Specify the severity of any alarms or events that are associated with the radio (see Defining Severities in the ClearSCADA Guide to Core Configuration)
  • Specify the Area of Interest with which any radio alarms or events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

(The ‘Area of Interest’ field is only displayed if the Area of Interest feature is enabled on your system.)

  • Specify the radio’s Normal and Promoted Scan Rates and Offsets (see Define the Scan Rate in the ClearSCADA Guide to Simple Drivers)
  • Specify whether the radio is given scanning preference when its points are on display (see Define Whether a Scanner is Promoted While its Points are on Display in the ClearSCADA Guide to Simple Drivers)
  • Specify whether the radio is updated when it scans for diagnostics data (see Define Whether a Scanner is Used to Trigger Logic in the ClearSCADA Guide to Simple Drivers).

The properties on the other tabs are common to many types of database item (see Tabs That are Common to Many Configuration Forms in the ClearSCADA Guide to Simple Drivers).


Trio Diagnostics Driver Guide - Specify the Channel with which the Radio is Associated (Configuring a Trio Diagnostics Radio)

Specify the Channel with which the Radio is Associated

Use the Channel field on the Radio tab to specify the Trio Diagnostics Channel that is used for communications with this radio (either directly, via a ‘base’ radio, or through a Terminal Server or similar device).

Select the field’s browse button to display a Reference browse window, then select the required channel from the window.


Trio Diagnostics Driver Guide - Specify the Serial Number of the Radio Unit (Configuring a Trio Diagnostics Radio)

Specify the Serial Number of the Radio Unit

Use the Unit Serial Number on the Radio tab to specify the serial number that applies to this particular Trio Datacom radio.

The serial number is factory preset and is unique to each radio unit. The serial number is included in any transmissions to or from the radio.

NOTE: If you need to replace a Trio Datacom radio with another radio unit, remember to update the Unit Serial Number to that of the replacement radio.


Trio Diagnostics Driver Guide - Specify the Stream on which the Radio is to Transmit Messages (Configuring a Trio Diagnostics Radio)

Specify the Stream on which the Radio is to Transmit Messages

Use the Stream ID field on the Radio tab to specify the SID code that is to be included in the header of the messages transmitted to and from this radio.

This field only applies if the Send SID check box is selected on the configuration Form of the Trio Diagnostics Channel that is used for communications with the radio (see Specify Whether to Include the Stream Identifier in each Data Packet).

In many cases, you can leave the Stream ID at the default of 0 (zero).

If the configuration in the radio has been modified to enable multistream functionality, use the Stream ID field to specify the SID code address that is configured in the radio unit.

For information on SID codes and multistream functionality, see the documentation supplied with your Trio Datacom radio equipment.


Trio Diagnostics Driver Guide - Specify the Protocol Version (Configuring a Trio Diagnostics Radio)

Specify the Protocol Version

Use the Protocol Version combo box on the Radio tab to specify the diagnostics protocol used by the Trio Datacom radio.

Specify Version 1 if the radio is a D Series radio.

Leave at the default of Version 2 for any other radio series.


Trio Diagnostics Driver Guide - Points Used on Trio Diagnostics Radios

Points Used on Trio Diagnostics Radios

In the ClearSCADA database, you need to configure one Trio Diagnostics Point per item of diagnostics information that you want to retrieve from a Trio Datacom radio. The Trio Diagnostics driver supports several types of point. Configure Trio Diagnostic points of the appropriate type to represent the type of data that you want the driver to retrieve.

The Trio Diagnostics driver supports these types of point:

  • Trio Diagnostics Analog Point (see Configuring Analog Points)

D Series radios provide support for interrogation of fewer diagnostics parameters than other supported radio series. To retrieve any item of diagnostics data from a D Series radio, you associate that data with a Trio Diagnostics Analog Point.

  • Trio Diagnostics Digital Point (see Configuring Digital Points)
  • Trio Diagnostics String Point (see Configuring String Points).

You configure each point that you require using the appropriate Trio Diagnostics Point Form. Each Form has several tabs.

The properties on the Trio Diagnostics tab includes several driver-specific properties (see the appropriate reference above, and see Configure the Common Trio Diagnostics Point Properties).

For information on each <Point Type> tab (such as the Digital Point tab on the Trio Diagnostics Digital Point Form), see the appropriate reference above.

The properties on the other tabs are common to points on many drivers (see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers).

Further Information

Create a Point and Display a Point Form: see Create and Configure a Point in the ClearSCADA Guide to Core Point Configuration.


Trio Diagnostics Driver Guide - Configure the Common Trio Diagnostics Point Properties (Points Used on Trio Diagnostics Radios)

Configure the Common Trio Diagnostics Point Properties

Use these fields on each Point Form’s Trio Diagnostics tab to configure these driver-specific point properties:

  • In Service—Use to specify whether the point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point that is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Radio—Use to specify the database item that represents the Trio Datacom radio from which ClearSCADA is to retrieve the diagnostics data for this point.

Select the browse button to display a Reference browse window, then select the required radio from the window. If more than one Trio Diagnostics Radio database item is used to represent the same radio unit, select the radio database item that represents the required data retrieval (scan) rate for this item of diagnostics data (see Configuring a Trio Diagnostics Radio).

  • Parameter—Use to specify the Parameter Identifier Code (PIC). The PIC identifies the diagnostics parameter that ClearSCADA’s Trio Diagnostics driver is to read from the radio for this particular point.

Use the Parameter field’s arrow button to display a list of PICs. The options vary depending on the type of point (see the point-specific configuration sections in this guide). Each type of Trio Datacom radio supports a subset of these PICs. You should select a PIC that exists on the Trio Datacom radio from which ClearSCADA is to read diagnostics data. D Series radios support a limited number of PICs compared to other supported series of radios—see Configure the Trio Diagnostics Analog Point Properties. For other series of radio, see the documentation supplied with your Trio Datacom radio equipment.

If the PIC that you require is not listed, but can be retrieved using the selected point type, select the Define PIC option. Further field(s) become available on the Trio Diagnostics tab to enable you to specify the PIC details.

  • PIC—Only applies when the Parameter field is set to ‘Define PIC’. Specify the Parameter Identifier Code (PIC) of the PIC that ClearSCADA’s Trio Diagnostics driver is to read from the radio.

Further properties are included on the Trio Diagnostics tab for some types of point. For information on those properties see, as appropriate:

  • Configure the Trio Diagnostics Analog Point Properties
  • Configure the Trio Diagnostics Digital Point Properties.


Trio Diagnostics Driver Guide - Configuring Analog Points

Configuring Analog Points

ClearSCADA can retrieve various forms of diagnostic data from a Trio Datacom radio. For each item of diagnostics data that can be in one of a range of numeric values, you need to configure a Trio Diagnostics Analog Point in the ClearSCADA Database.

Configure the point’s properties using the fields on the Trio Diagnostics Analog Point Form. The Form has several tabs.

Use the Trio Diagnostics tab to:

  • Configure the Trio Diagnostics Analog Point Properties
  • Configure the Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration)

The Analog Point tab contains properties that are common to analog points on many drivers (see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration).

The fields on other tabs are common to points on many drivers (see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers).


Trio Diagnostics Driver Guide - Configure the Trio Diagnostics Analog Point Properties (Configuring Analog Points)

Configure the Trio Diagnostics Analog Point Properties

Use the fields on the Trio Diagnostics tab to configure an analog point’s Trio Diagnostics specific properties. Some of the fields are common to many Trio Diagnostics points (see Configure the Common Trio Diagnostics Point Properties). Fields that are specific to Trio Diagnostics Analog points are explained below.

  • Parameter—This field is common to most points on the Trio Diagnostics driver (for details, see Configure the Common Trio Diagnostics Point Properties). The options that are available vary, depending on the type of point. The diagram below shows the Parameter Identifier Codes (PIC s) for many of the diagnostics parameters that are supported by Trio Diagnostics analog points. Each type of Trio Datacom radio supports a subset of these PICs—you need to select a PIC that exists on the radio from which the driver is to retrieve diagnostics data.

If the PIC that you require is not included in the list, but can be retrieved using a Trio Diagnostics analog point, select the ‘Define PIC’ option and use other fields on the tab to specify the PIC details.

D Series radios support a limited number of diagnostics parameters compared to the other supported radio series. Depending on the type of radio unit, valid diagnostics parameters that can be retrieved from a D Series radio comprise:

  • Internal Temperature ( PIC 3 )
  • RSSI ( PIC 6 )
  • Forward Transmit Power ( PIC 9 )
  • Supply Voltage ( PIC 12 )
  • Receive Frequency Error ( PIC 15 )
  • Peak Deviation ( D Series only )—supported by version 3 radios onwards.
  • Convert to mW—Only applies if the Parameter field is set to RSSI (PIC 6), RSSI Threshold (PIC 76), or one of the Power options (see above).

Select the Convert to mW check box if the value that the driver retrieves is in decibels (dB) and the driver is to convert the value to milliwatts (mW) for use in ClearSCADA.

Clear the check box if conversion is not required.

  • Convert to Fahrenheit—Only applies if the Parameter field is set to Internal Temperature ( PIC 3 ).

Select the Convert to Fahrenheit check box if the value that the driver retrieves is in degrees Celsius and the driver is to convert the value to Fahrenheit for use in ClearSCADA.

Clear the check box if conversion is not required.

  • Multiplier—Only applies if the Parameter field is set to Define PIC (see above). Use the Multiplier field to specify the amount by which the Trio Diagnostics driver is to multiply each diagnostic value that it retrieves from the radio, before passing the resultant value to ClearSCADA.

Leave at the default of 1 if the driver is not required to perform such a multiplication task.

  • Conversion—Only applies if the Parameter field is set to Define PIC (see above). Use the Conversion combo box to indicate whether the driver needs to convert each retrieved diagnostics value before passing the value onto ClearSCADA.

Choose from:

  • None—No conversion is required. This is the default option.
  • dBm to mW—Select this option if the retrieved values are power ratios in decibels (dB) and the driver is to convert those values to milliwatts (mW) for use in ClearSCADA.
  • mW to dBm—Select this option if the retrieved values are in milliwatts (mW) and the driver is to convert those values to decibels (dB) for use in ClearSCADA.
  • Celsius to Fahrenheit—Select this option if the retrieved values are temperatures measured in degrees Celsius, which the driver is to convert to degrees Fahrenheit for use in ClearSCADA.


Trio Diagnostics Driver Guide - Configuring Digital Points

Configuring Digital Points

NOTE: The diagnostics parameters on D Series radios are retrieved using Trio Diagnostics Analog points. Trio Diagnostics Digital Points are not used with D Series radios.

ClearSCADA can retrieve various forms of diagnostic data from a Trio Datacom radio. For each item of diagnostics data that can be in one of a set number of states, you need to configure a Trio Diagnostics Digital Point in the ClearSCADA Database.

Configure the point’s properties using the fields on the Trio Diagnostics Digital Point Form. The Form has several tabs.

Use the Trio Diagnostics tab to Configure the Trio Diagnostics Digital Point Properties.

The Digital Point tab contains properties that are common to digital points on many drivers (see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration).

The fields on other tabs are common to points on many drivers (see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers).


Trio Diagnostics Driver Guide - Configure the Trio Diagnostics Digital Point Properties (Configuring Digital Points)

Configure the Trio Diagnostics Digital Point Properties

Use the fields on the Trio Diagnostics tab to configure a digital point’s Trio Diagnostics specific properties. Some of the fields are common to many Trio Diagnostics points (see Configure the Common Trio Diagnostics Point Properties). Fields that are specific to Trio Diagnostics Digital points are explained below.

  • Parameter—This field is common to many points on the Trio Diagnostics driver (for details, see Configure the Common Trio Diagnostics Point Properties). The options that are available vary, depending on the type of point. The diagram below shows the Parameter Identifier Codes (PIC s) for many of the diagnostics parameters that are supported by Trio Diagnostics digital points. Each type of Trio Datacom radio supports a subset of these PICs—you need to select a PIC that exists on the radio from which the driver is to retrieve diagnostics data.

If the PIC that you require is not included in the list, but can be retrieved using a Trio Diagnostics digital point, select the ‘Define PIC’ option and use other fields on the tab to specify the PIC details.

  • Bit Offset—Only applicable if the Parameter field is set to Define PIC (see above). Specify the lowest (starting) bit of the diagnostics parameter that ClearSCADA is to read for this point. (Bit zero (0) is the lowest possible bit.)
  • Persistence—Use this field to specify the amount of time for which the point has to remain in a new State before that point state is updated in the ClearSCADA database. Persistence is designed to stop the driver from processing fleeting changes in point state and reporting those fleeting changes to the server. As the driver does not process or report fleeting changes, ClearSCADA does not have to raise change of state alarms or log change of state events when a point value is fluctuating.

Specify the required Persistence in seconds.


Trio Diagnostics Driver Guide - Configuring String Points

Configuring String Points

NOTE: The diagnostics parameters on D Series radios are retrieved using Trio Diagnostics Analog points. Trio Diagnostics String Points are not used with D Series radios.

ClearSCADA can retrieve various forms of diagnostic data from a Trio Datacom radio. For each item of diagnostics data that takes the form of a text string, you need to configure a Trio Diagnostics String Point in the ClearSCADA Database.

Configure the point’s properties using the fields on the Trio Diagnostics String Point Form. The Form has several tabs.

Use the Trio Diagnostics tab to Configure the Trio Diagnostics String Point Properties.

The String Point tab contains properties that are common to string points on many drivers (see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration).

The fields on other tabs are common to points on many drivers (see Tabs on Point Forms in the ClearSCADA Guide to Simple Drivers).


Trio Diagnostics Driver Guide - Configure the Trio Diagnostics String Point Properties (Configuring String Points)

Configure the Trio Diagnostics String Point Properties

Use the fields on the Trio Diagnostics tab to configure a string point’s Trio Diagnostics specific properties. Some of the fields are common to many Trio Diagnostics points (see Configure the Common Trio Diagnostics Point Properties). Fields that are specific to Trio Diagnostics String points are explained below.

  • Parameter—This field is common to many points on the Trio Diagnostics driver (for details, see Configure the Common Trio Diagnostics Point Properties). The options that are available vary, depending on the type of point. The diagram below shows the Parameter Identifier Codes (PIC s) for many of the diagnostics parameters that are supported by Trio Diagnostics string points. Each type of Trio Datacom radio supports a subset of these PICs—you need to select a PIC that exists on the radio from which the driver is to retrieve diagnostics data.

If the PIC that you require is not included in the list, but can be retrieved using a Trio Diagnostics string point, select the ‘Define PIC’ option and use the PIC field to specify to specify the PIC details.


Trio Diagnostics Driver Guide - Trio Diagnostics Specific Status Display Attributes

Trio Diagnostics Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each Trio Diagnostics point provides information about the present state of the individual point.

Use this section if you need information on the status of any Trio Diagnostics database items on your system.

This section explains the Primary Assign and Source status attributes, which are specific to the Trio Diagnostics driver.

NOTE: The Trio Diagnostics driver does not use the following status attributes: Primary Eavesdrop Tx Assign, Secondary Assign, and Secondary Eavesdrop Tx Assign.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Items on Many Drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Trio Diagnostics Driver Guide - Primary Assign (Trio Diagnostics Specific Status Display Attributes)

Primary Assign

Associated with: Trio Diagnostics channels

This attribute indicates whether the assignment of a Trio Diagnostics channel to its serial line has been unsuccessful. The line configuration is defined on the Connection tab of the Channel Form (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).

Possible States: Displays one of the Standard Alarm States.


Trio Diagnostics Driver Guide - Source (Trio Diagnostics Specific Status Display Attributes)

Source

Associated with: Trio Diagnostics database items

The Source attribute indicates the location at which an item resides.

The attribute is common to many Status displays, but the information shown varies, depending on the driver and type of item. For items on the Trio Diagnostics driver, this information is displayed:
Trio Diagnostics Item | Source Attribute
Channel (Serial Comms) | Format | <Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> Controller Address <Controller Address>
 | Example: | COM2:9600:8N1 Controller Address 3 (For a channel that uses a serial connection. The channel communicates via port COM2 at 9600 baud, using 8 bits, no parity, and 1 stop bit. The diagnostic application’s controller address is 3.)
Channel (TCP/IP Comms) | Format | <TCP/IP Type> <Host Address>:<Port>,<Local Port> Controller Address <Controller Address>
 | Example: | TCP 123.143.1.101:20,25 Controller Address 2 (For a channel that uses a TCP connection to communicate with Host Address 123.143.1.101, via Port 20. ClearSCADA listens for replies on Local Port 25. The diagnostic application’s controller address is 2.)
Radio (Serial Comms) | Format | S/N <Unit Serial Number> <Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> Controller Address <Controller Address>
 | Example: | S/N 155 COM2:9600:8N1 Controller Address 3 (For a remote or ‘base’ radio that has a Unit Serial Number of 155. ClearSCADA uses a serial connection to communicate with the radio network’s ‘base’ radio. The channel’s details are as per the Serial Comms Channel example above.)
Radio (TCP/IP Comms) | Format | S/N <Unit Serial Number> <TCP/IP Type> <Host Address>:<Port>,<Local Port> Controller Address <Controller Address>
 | Example: | S/N 12 TCP 123.143.1.101:20,25 Controller Address 2 (For a remote or ‘base’ radio that has a Unit Serial Number of 12. ClearSCADA uses a TCP connection to communicate with the radio network’s ‘base’ radio. The channel details are as per the TCP/IP Comms Channel example above.)
Analog or String Point (used for retrieving a predefined PIC, using TCP comms) | Format | S/N <Unit Serial Number> <TCP/IP Type> <Host Address>:<Port>,<Local Port> Controller Address <Controller Address>, <Parameter>
 | Example: | S/N 12 TCP 123.143.1.101:20,25 Controller Address 2, DSP Firmware Revision ( PIC 157 ) (An analog point that represents the diagnostics parameter ‘DSP Firmware Revision’. The diagnostics parameter is identified by the Parameter Identifier Code (PIC) 157. Radio and channel details as per the TCP/IP Comms examples above.)
Digital Point (used for retrieving an unlisted PIC, using TCP comms) | Format | S/N <Unit Serial Number> <TCP/IP Type> <Host Address>:<Port>,<Local Port> Controller Address <Controller Address>, PIC <PIC> Bit <Bit Offset>
 | Example: | S/N 12 TCP 123.143.1.101:20,25 Controller Address 2, PIC 204 Bit 2 (A digital point that represents an unlisted diagnostics parameter (one that is not included in the list that is available for the ‘Parameter’ property on the point’s configuration Form). The diagnostics parameter is identified by the Parameter Identifier Code (PIC) 204. The relevant data starts at Bit 2 in the value that ClearSCADA retrieves from the Trio Datacom radio. Radio and channel details as per the TCP/IP Comms Channel example above.)
Analog or String Point (used for retrieving an unlisted PIC, using TCP comms) | Format | S/N <Unit Serial Number> <TCP/IP Type> <Host Address>:<Port>,<Local Port> Controller Address <Controller Address>, PIC <PIC>
 | Example: | S/N 243 TCP 123.143.1.101:20,25 Controller Address 2, PIC 216 (A point that represents an unlisted diagnostics parameter (one that is not included in the list that is available for the ‘Parameter’ property on the point’s configuration Form). The diagnostics parameter is identified by the Parameter Identifier Code (PIC) 216. ClearSCADA retrieves the diagnostics parameter from the Trio Datacom radio that has a Unit Serial Number of 243. Channel details as per the TCP/IP Comms Channel example above.)
Digital Point (used for retrieving a predefined PIC, using serial comms) | Format | S/N <Unit Serial Number> <Port>:<Baud Rate>:<Data Bits><Parity><Stop Bits> Controller Address <Controller Address>, <Parameter>
 | Example: | S/N 155 COM2:9600:8N1 Controller Address 3, Diagnostics Checksum Enabled ( PIC 102 Bit 1 ) (A digital point that represents the diagnostics parameter ‘Diagnostics Checksum Enabled’. The diagnostics parameter is identified by the Parameter Identifier Code (PIC) 102. The relevant data starts at Bit 1 in the value that ClearSCADA retrieves the Trio Datacom radio that has a Unit Serial Number of 155. Channel details as per the Serial Comms Channel example above.)


Advanced Drivers Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Advanced Drivers Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Advanced Drivers Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Advanced Drivers Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Advanced Drivers Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Advanced Drivers Guide - Document Scope (About the Guide)

Document Scope

This guide explains those aspects of configuration that are common to many advanced drivers. It also explains the order in which you should perform advanced driver configuration.

Other sections in this guide provide information to assist with diagnosing any problems that ClearSCADA has detected on advanced driver items.

For more information, see Introduction to Advanced Drivers.


Advanced Drivers Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers that are tasked with configuring advanced driver features and items.

The guide is also intended for engineers and system administrators investigating any faults that ClearSCADA has reported on advanced driver items.


Advanced Drivers Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Advanced Drivers Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Lists

ClearSCADA Guide to Drivers

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Logic

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to the Server Status Tool.


Advanced Drivers Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Advanced Drivers Guide - Introduction to Advanced Drivers

Introduction to Advanced Drivers

The advanced drivers that are supported by ClearSCADA allow the ClearSCADA server to communicate with, for example, SCADAPack controllers and various third-party devices, including loggers.

Each driver provides extra features in the ClearSCADA database to present the data from the measuring instruments on those devices and to send controls to plant.

Use this Advanced Drivers Guide in conjunction with the ClearSCADA Guide to Drivers and the relevant driver-specific guide(s) for a comprehensive understanding of the configuration associated with your drivers. The Advanced Drivers Guide explains how to configure the features that are common to many advanced drivers (see Add a Driver-Specific Item to the Database, and see Tabs that are Common to Many Configuration Forms). It also explains the order that the configuration should take (see Configuration Order) and the additional Terminology used throughout the advanced driver documentation suite.

For aspects of configuration that are specific to a particular driver, see the driver-specific guide(s).

For aspects of configuration that are common to most types of database item (for instance, saving configuration changes, and renaming, copying, and deleting database items), see the ClearSCADA Guide to Core Configuration.

If additional fields have been added to any Forms specifically for your system, you should also refer to the system-specific documentation that explains those fields. For information on adding such fields, see Extra Database Fields in the ClearSCADA Guide to Server Administration.

You can use the core ClearSCADA features, such as Lists, Actions, and Mimics, with advanced driver items. For more information on the core database items, please refer to the general documentation (the non-driver specific documentation).


Advanced Drivers Guide - Terminology (Introduction to Advanced Drivers)

Terminology

Throughout most of the advanced driver documentation, the term ‘outstation’ is used to refer to any device such as an outstation, RTU, or Data Logger that is used to obtain data from measuring instruments or sensors.

For further details on the terminology that is used throughout the ClearSCADA documentation suite, see Terminology in the ClearSCADA Guide to Core Configuration.


Advanced Drivers Guide - Configuration Order (Introduction to Advanced Drivers)

Configuration Order

Your User Account needs to be assigned the Configure Database feature to enable you to configure items in the database (see Database Security in the ClearSCADA Guide to Core Configuration).

For each advanced driver, you need to configure:

  1. A Channel to define each communication connection between an outstation, or group of outstations, and the ClearSCADA server.

Some outstations can communicate using a variety of methods (for example, direct or PSTN)—ensure that you configure the correct type of channel to represent the type of communication used (see Configuring a Channel).

  2. An Outstation Set to define each group of outstations that share the same channel(s) (with the exception of PSTN) and use the same protocol.

As multi-drop scanning and processing becomes slower when there are many outstations in the same set, we recommend that you only include a maximum of 30 multi-drop outstations in a set (see Configuring an Outstation Set).

  3. An Outstation to define each unit that obtains data from measuring devices and/or sends instructions to controllable devices.

The type of communication may vary, depending on the outstation type—ensure that you configure the correct type of outstation for the type of communication used (see Outstation Types and Communications Set-ups, also see Scanning Direct Outstations, and see Configuring an Outstation).

  4. A Point to represent each measuring instrument or control device that is connected to the outstation.

The types of point that you can configure varies, depending on the driver (see Points on Advanced Drivers).

  5. A Pulse action (if required) to carry out control(s) on plant for only brief periods of time.

Pulse actions are supported by many drivers (see Defining Pulse Action Details in the ClearSCADA Guide to Core Point Configuration).

If data is to be uploaded to ClearSCADA using the ‘File Upload’ feature:

  6. File Upload(s) to specify the directories from which data files are to be uploaded into ClearSCADA, and the period for which any reports associated with the File Upload are to be retained on the server (see Configuring a File Upload).

To minimize the time taken to configure the required advanced driver items, you may want to configure them in the order given above. The order is more important for outstations that use a permanent connection rather than PSTN to communicate with the ClearSCADA server, as set configuration requires you to specify a channel, and outstation configuration requires you to specify a set, and so on. (With PSTN outstations, the association with a channel is only made during run time.)

By default, an item is not ‘In Service’ when you first create a database entry for it (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration). In order for the ClearSCADA server to communicate with an item, you have to put the item In Service (online), and ensure that it has valid configuration (see Checking for Invalid Configuration in the ClearSCADA Guide to Core Configuration). ClearSCADA will generally prompt you for any mandatory properties that an item requires as you configure it.

NOTE: If you later take an outstation out of service, its dependants (points, pulse actions, and so on) also become out of service.


Advanced Drivers Guide - Add a Driver-Specific Item to the Database (Introduction to Advanced Drivers)

Add a Driver-Specific Item to the Database

To add a driver-specific channel, set, outstation, point, or pulse action to your system (preferably in that order—see Configuration Order):

  1. Display the Database Bar.

(The Database Bar is an Explorer Bar (see Display an Explorer Bar in ViewX in the ClearSCADA Guide to ViewX and WebX Clients).)

  2. Right-click on the Group or System to which you want to add an item.
    A context sensitive menu is displayed.
  3. Select the New option.
    A further menu is displayed.
  4. Select the <Driver> option for the driver to which you want to add an item. For example, DNP3.
    A further menu is displayed.

If the driver that you require is not installed on your system or not displayed on the menu, contact a system administrator.

  5. Select the type of item that you want to add to the system, for example Analog Input Point.
    An item of the selected type is added to the database and displayed on the tree-structure. It is automatically selected, ready for you to define its name.
  6. Enter the required name for the item (see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  7. Select another part of the interface, or press the Enter key to confirm the entry.

You then need to display the Form to configure the item (see Display a Form in the ClearSCADA Guide to Core Configuration).

Further Information

Tabs that are Common to Many Configuration Forms.


Advanced Drivers Guide - Tabs that are Common to Many Configuration Forms (Introduction to Advanced Drivers)

Tabs that are Common to Many Configuration Forms

Much of the driver-specific configuration on advanced drivers is undertaken using a series of configuration Forms. These Forms have a series of ‘tabs’ or ‘pages’ on which you specify different aspects of configuration.

The Forms often have a combination of these tabs, which are common to many configuration Forms:

  • Identification—Use to optionally define a Help View and to indicate whether the item is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for the item (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with alarms for the item (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the item (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).

In addition, the Forms include one or more tabs for specifying item- or driver-specific configuration. For information on configuring the properties on such tabs, see the relevant driver-specific documentation (for example, for information on the DNP3 tab on the DNP3 Outstation Forms, see the ClearSCADA Guide to the DNP3 Driver).

For aspects of configuration that are common to most types of database item, see the ClearSCADA Guide to Core Configuration.


Advanced Drivers Guide - Configuring Advanced Driver Server Settings

Configuring Advanced Driver Server Settings

This section explains the procedure that a system administrator should perform to check that any driver-specific settings are correctly configured on each server when a ClearSCADA system is first installed. Such settings are configured using the ClearSCADA Server Configuration Tool. (For information on the driver installation process, see Set up the Drivers on a New ClearSCADA System in the ClearSCADA Guide to Drivers, or see Add a New Driver to an Existing ClearSCADA System in the ClearSCADA Guide to Drivers.)

Several advanced drivers have driver-specific settings. These settings are in addition to the ‘Drivers’ and other global parameters that are common to the drivers on your system (see Use the ClearSCADA Server Configuration Tool to Specify the Common Driver Settings in the ClearSCADA Guide to Drivers). Any driver-specific settings are defined in the corresponding driver-specific section of the ClearSCADA Server Configuration Tool and are explained in the relevant driver guide.

For drivers that have driver-specific settings, use this section in conjunction with the driver-specific documentation. For fields that are common to many advanced drivers, see the rest of this section. For fields that are not described here, see the driver-specific documentation. For File Upload server settings, see Upload Files over the Network.

NOTE: Repeat any changes that you make on each of the servers on your system (except for any Permanent Standby servers, which do not run the drivers).

To access the settings for a particular driver:

  1. Access the ClearSCADA Server Configuration Tool (see Working with the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Ensure that the entries are visible within the Global Parameters branch of the tree-structure.
  3. Within the Global Parameters branch, select the name of the driver for which you want to display the server settings.

The entries that are included in the Global Parameters branch vary, depending on the drivers that are installed on your system. (A separate driver entry is only included if that driver is installed and its server settings differ to those of other drivers.)

The appropriate driver section is displayed.

Example:

Selecting the SCADAPack Modbus driver entry, within the Global Parameters branch of the tree-structure...
...results in the SCADAPack Modbus driver section being shown.

  4. Refer to the appropriate ClearSCADA Driver Guide for information on configuring the settings for that driver. (Depending on the driver, these settings may include those for Defining Communication Delays, and for specifying additional PSTN Connection Types.)

(For features displayed within the ‘Drivers’ section of the tool, see Driver Settings in the ClearSCADA Guide to Server Administration.)

As you configure the settings, the driver entry in the hierarchical list changes color to indicate that changes are being made to the driver configuration.

Example:

Changes that affect the SCADAPack Modbus driver result in the SCADAPack Modbus entry being highlighted.

  5. Right-click on the server (‘node’) entry in the hierarchical list in the ClearSCADA Server Configuration Tool.
    A context-sensitive menu is displayed.
  6. Select the Apply Changes option.
    The changes are applied to the server configuration.

Example:

Right-click on the server node to display a context-sensitive menu...
...from which you select the Apply Changes option, to apply the changes to the server configuration.

  7. If the server is currently running as the main server, restart the driver for the changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).

With some configuration changes, you may also need to restart the server, in order for those changes to take effect—the driver-specific documentation indicates whether a server restart is required.

  8. Repeat the above steps for the other drivers on your system.
  9. Repeat the above steps on each of the servers that are not permanent standby servers on your system.


Advanced Drivers Guide - Defining Communication Delays (Configuring Advanced Driver Server Settings)

Defining Communication Delays

Several of the driver-specific sections on the ClearSCADA Server Configuration Tool include a combination of the fields that are described below. The fields allow you to specify delays that the server applies before re-establishing communications under various situations. The delays help to prevent errors being reported due to the outstation not responding to any messages while it is re-establishing communications. Refer to the driver-specific documentation for information on which fields apply to a particular driver.

  • Delay after closing line before starting direct comms—This delay applies to Direct outstations that have been using PSTN fallback to communicate with the server. The delay allows the outstation time to establish direct communications before receiving any messages.

Specify the delay between completing PSTN communications and attempting to re-establish direct communications.

  • Delay while outstation completes stopping comms—Specify the delay between stopping direct communications and restarting further direct communications. The delay stops any messages from being sent to the outstation while it is in the process of stopping communications.
  • Delay while outstation performs a reset—Specify the delay between resetting an outstation and restarting communications. The delay stops any messages from being sent to the outstation while it is in the process of resetting then establishing communications with the server.


Advanced Drivers Guide - PSTN Connection Types (Configuring Advanced Driver Server Settings)

PSTN Connection Types

PSTN Connection types are used to group PSTN outstations and channels that use like-communications.

Use PSTN Connection Types to specify any particular communication requirements for the outstations on your system. For instance to match outstations and channels due to particular hardware requirements or limitations, or for other logical reasons.

By default, any outstations and channels that communicate with the server via PSTN are placed into one group, which uses the Standard Modem connection type. However, in order to communicate successfully, the server needs to be notified if any differences in PSTN communications exist for any channels or outstations. For example, if the type of dial-up modem differs from one outstation to another. This is particularly important when an outstation dials in to the server.

If the channels and outstations on your system use different types of PSTN connection—for instance, different types of dial-up modem—add representations for the different connection types to the ClearSCADA Server Configuration Tool (see Adding Further Types of PSTN Connection).

Example:

Most of the DNP3 outstations on a particular ClearSCADA system communicate using a standard modem connection.

However, two of the DNP3 outstations communicate using a connection that requires a special dial-up modem. An additional PSTN connection type is configured to indicate this requirement. Additional channels are configured on which this connection type is specified. The database is configured to reflect the fact that these particular outstations use these channels to communicate with the server.


Advanced Drivers Guide - Adding Further Types of PSTN Connection (Configuring Advanced Driver Server Settings)

Adding Further Types of PSTN Connection

To add a further PSTN connection for a driver:

  1. Display the relevant driver-specific section of the ClearSCADA Server Configuration Tool (see Configuring Advanced Driver Server Settings).
  2. Select the Add button.
    The PSTN Connection Type window is displayed.
  3. The Index field shows the next available index number. The number is used to uniquely identify the new PSTN Connection Type. Either leave at the default, or specify a particular index number, as required. (The default ‘Standard Modem’ connection type is automatically assigned Index 0. Any additional connection types can be assigned Index 1 onwards.)
  4. Overtype the Description with an appropriate name.
  5. Select the OK button to confirm the entries.
    The new PSTN Connection Type is added to the list of additional PSTN Connection Types. The color of the entry indicates that its configuration has yet to be fully applied to the server (as per step 7, below).

    The relevant driver entry in the hierarchical list will also change color to indicate that changes have been made to the driver configuration.
  6. Repeat steps 2 to 5 for any further connection types that are required.
  7. Apply the changes to the server configuration (see Configuring Advanced Driver Server Settings).
  8. Repeat the same changes on each of the servers on your system, ensuring that you assign the same Description to the same Index number on each server. (Unlike many other Server Configuration settings, you do need to repeat such PSTN connection changes on any permanent standby servers.)

To use a new PSTN Connection type for channels or outstations on your system:

  1. Display the appropriate Channel or Outstation Form in ViewX.
  2. Select the Form’s PSTN tab.
  3. Use the Connection Type combo box to select the required entry.
  4. Configure the PSTN settings on the rest of the tab as required.

NOTE: If an Outstation or Channel Form is on display in ViewX when you add further PSTN Connection types to the server configuration, the new types will become available for selection the next time that the configuration is saved or the Form is closed then re-opened.

Further Information

Edit a PSTN Connection Type.

Remove an Obsolete PSTN Connection Type.


Advanced Drivers Guide - Edit a PSTN Connection Type (Configuring Advanced Driver Server Settings)

Edit a PSTN Connection Type

To edit an entry in the list of PSTN Connection Types:

  1. Either:
  1. Select the required entry.
    The entry will become highlighted.
  2. Select the Edit button.

Or:

  1. Double-click on the required entry.

The PSTN Connection Type window is displayed.

  2. Modify the properties as required (see Adding Further Types of PSTN Connection).
  3. Select the OK button.
    The PSTN Connection Type window is closed. The entry is updated in the PSTN Connection Types field. The entry is colored to indicate that its configuration is yet to be fully applied to the server.
  4. Repeat the above steps for any further connection types that need changing.
  5. Apply the changes to the server configuration (see Configuring Advanced Driver Server Settings).
  6. Repeat the same changes on each of the servers on your system, ensuring that you make identical changes on each server. (Unlike many other Server Configuration settings, you do need to repeat such PSTN connection changes on any permanent standby servers.)

Further Information

Remove an Obsolete PSTN Connection Type.


Advanced Drivers Guide - Remove an Obsolete PSTN Connection Type (Configuring Advanced Driver Server Settings)

Remove an Obsolete PSTN Connection Type

To remove a PSTN Connection Type that is no longer required:

  1. Select the relevant entry in the list of PSTN Connection Types.
    The entry is highlighted.
  2. Select the Remove button.
    The entry is removed from the list. The relevant driver entry in the hierarchical list changes color to indicate that changes have been made to the driver configuration.

ATTENTION: If you attempt to delete a PSTN Connection Type that is being used by a channel or outstation, a confirmation window is displayed, stating that the connection type is in use. If you proceed to delete the Connection Type, each channel or outstation that was using that particular Connection Type will revert to using the Standard Modem.

  3. Repeat the above steps for any other connection types that are no longer required.
  4. Apply the changes to the server configuration (see Configuring Advanced Driver Server Settings).
  5. Repeat the same changes on each of the servers on your system. (Unlike many other Server Configuration settings, you do need to repeat such PSTN connection changes on any permanent standby servers.)

Further Information

Adding Further Types of PSTN Connection.

Edit a PSTN Connection Type.


Advanced Drivers Guide - Outstation Types and Communications Set-ups

Outstation Types and Communications Set-ups

Outstations, or RTUs, are enclosed units that usually contain a communication mechanism, input points and/or output points, and a battery. The input and output points (I/O) correspond to measuring instruments and control equipment at the plant.

For each outstation that exists on your system, you need to create and configure a corresponding Outstation database entry within the ClearSCADA database.

Within the database, you group the outstations into Outstation Sets. With the exception of PSTN, the outstation set determines the communication Channels that each outstation uses (see Configuring an Outstation Set).

When configuring the database, you need to select the type(s) of outstation and communications that correspond to your system hardware. The types of outstation and the communication set-ups with which they are used vary per driver, but include representations for one or more of the following:

  • Direct Outstations
    (in either Direct or Switched outstation sets)
  • PSTN Outstations
    (see PSTN Outstations and Communications)
  • Shared Outstations.

NOTE: If required, a Queue feature can be enabled on your system to allow users to optionally queue certain pick action requests on PSTN and ‘On Demand’ outstations. For more information, see Define whether the Queue Parameter is Available in the ClearSCADA Guide to Server Administration, and see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations in the ClearSCADA Guide to Drivers.

Further Information

Add a Driver-Specific Item to the Database.

Configuration Order.

Scanning Direct Outstations.

Retrieving Data from PSTN Outstations.

Configuring a Channel

Configuring an Outstation Set.

Configuring an Outstation.

For details of the outstation types supported by individual drivers, see the driver-specific documentation.


Advanced Drivers Guide - Direct Outstations (Outstation Types and Communications Set-ups)

Direct Outstations

Direct outstations use permanent communications, such as a cable, radio or network, to communicate with the ClearSCADA server. Within the ClearSCADA database, you configure Direct outstations in sets that use Direct Channels for communicating with the server.

Direct outstations can belong to Direct Outstation Sets or Switched Outstation Sets, depending on the communications set-up that is required. Depending on the functionality supported by the driver and outstation type, direct outstations can be configured to use these communication set-ups:

  • Direct - Single Channel
  • Direct - Dual Channel
  • Direct - PSTN Fallback.

On most systems, ClearSCADA is configured to instigate communications with any direct outstations whenever required. On some systems, the communications availability might be restricted on some direct outstations. For example, communications might be limited to Incoming Only (whereby the outstation instigates all communications with ClearSCADA), or Periodic (whereby communications with the outstation is only available for a limited period). For more information, see Specify the Availability of Communications Between the Outstation and ClearSCADA.

Further Information

Scanning Direct Outstations.

Configuring a Channel.

Configuring an Outstation Set.

Configuring an Outstation.


Advanced Drivers Guide - Direct - Single Channel (Outstation Types and Communications Set-ups)

Direct - Single Channel

In a direct - single channel communications set-up, each Direct outstation in the set communicates with the ClearSCADA server via a single uninterrupted connection. For example, an outstation could communicate with the ClearSCADA server via a network connection, a radio connection, or a cable connection. The connection is permanently established.

A direct channel represents a single uninterrupted communications connection between the ClearSCADA server and one or more outstations.

With such a set-up, the server scans one outstation after another on the channel, starting with the outstation that has the lowest address. When the ClearSCADA server makes a request for data from an outstation, it establishes communications with that outstation. The outstation reports its data, and then the server requests data from the next outstation. Once the server has polled each outstation in turn, it repeats the whole process, starting once again with the outstation that has the lowest address.

For this type of communications set-up, you would configure a Direct Outstation to belong to a Direct Outstation Set, that communicates via a single Direct Channel.

NOTE: Leased line connections are represented by direct channels as they are permanently established.


Advanced Drivers Guide - Direct - Dual Channel (Outstation Types and Communications Set-ups)

Direct - Dual Channel

Some outstations can communicate via one of two direct channels. This is referred to as a direct-dual channel set-up.

There are two types of direct-dual channel set-up:

  • Switched Outstation Set—The outstations can communicate with the ClearSCADA server via one of two direct channels, with one channel being configured as the ‘Preferred Line’. At any given time, all of the outstations in the set have to use the same channel (see Switched Dual Channel).
  • Shared Outstation Set—The outstations can communicate with the ClearSCADA server via one of two direct channels. The outstations can communicate via either of the channels—they do not have to use the same channel as the rest of the outstations in the set. To use this form of communication, you need to configure Shared Outstations rather than Direct Outstations (see Shared Outstations).

Further Information

Configuring an Outstation Set.

Define an Outstation’s Shared Properties.

Switched Dual Channel

In a switched dual channel communications setup, the outstations communicate with the ClearSCADA server via one of two Direct Channels. The outstations are grouped into a Switched Outstation Set and they all use the same direct channel at any given time. Both direct channels are associated with the Switched Outstation Set (see Defining Channel Settings for a Switched Set). The Set’s configuration Form is used to specify which channel is deemed to be the ‘Preferred Line’ (channel).

The channel that the ClearSCADA server uses to communicate with the outstations depends on:

  • Channel State—If ClearSCADA deems that the channel being used by the outstations has failed, providing that the other channel:
  • was healthy when it was last used by the outstations

or:

  • has not been used by the Outstation Set since system or driver start-up

ClearSCADA will automatically switch all of the outstations onto that other channel, to help ensure that communications and data retrieval continue. With Switched Outstation Sets, you can specify the number of outstations that ClearSCADA is to detect as failed before automatic switching occurs. However, should ClearSCADA detect that the currently used channel has failed, it will switch the outstations to the other channel regardless of the number of outstations that it has detected as failed on the current channel.

If the other channel was last reported to be in a failed state when used by the outstations and the channel that the outstations are currently using is reported as failed or is taken out of service, no automatic switching will occur. Instead, you need to use the Switch Line pick action to switch the outstations to the other channel. For more information, see below.

If the channel that the outstations are using is taken out of service, ClearSCADA will automatically switch all of the outstations onto the other channel, providing that the other channel is In Service. This will occur regardless of the number of outstations that ClearSCADA has detected as failed on the current channel.

  • Outstation Set Configuration—You configure a Switched Outstation Set so that one direct channel is preferred to another (see Defining Channel Settings for a Switched Set). The ClearSCADA server attempts to use the preferred channel first.
  • Outstation State—If the number of failed outstations in the Outstation Set exceeds a defined limit (as specified on the Outstation Set’s Form), ClearSCADA automatically switches communications to the alternate channel. The exception to this is if the other channel was in a failed state when last used by the outstations in the set. In such a situation, you need to use the Switch Line pick action to switch the outstations to the other channel. You might want to consider incorporating the Switch Line pick action into, for example, a Structured Text Program that runs in the background and checks the state of several ‘nominated’ outstations—for more information, see below.
  • Any action that causes the outstations to use a particular channel—For example, an operator action, such as a Switch Line pick action to instruct the ClearSCADA server to use an alternate channel, or a Schedule that instructs the ClearSCADA server to switch between the available channels on a regular basis. (Scheduled switching allows you to check that both channels are in working order. We recommend that you set up Scheduled switching on your system to periodically check that both channels continue to remain fully functional (see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration).)

Communications via a ‘Healthy’ direct channel can be reported as failed when one or more outstations are disconnected, cables are damaged, there is signal interference, or the communications equipment is damaged or faulty. By switching channels, the ClearSCADA server may be able to establish communications and avoid the detected problems.

Outstations that use switched dual channels are expected to communicate with ClearSCADA via the ‘preferred’ channel whenever that channel is healthy.

Should ClearSCADA determine that the preferred channel has failed, it will switch the outstations to the other (‘backup’) channel (providing that channel is deemed to be healthy). You should then investigate the failure of the ‘preferred’ channel and, if possible, rectify the problem. Once rectified, use the Switch Line pick action to switch the outstations back to using the preferred channel.

Alternatively, you could use Structured Text to produce a program that periodically checks whether ClearSCADA has detected that one or more nominated outstations have failed and if so:

  • Automatically ‘line hunts’ for whichever channel becomes healthy first
  • Switches the outstations to use that channel.

(The state of a channel will only update when ClearSCADA has successfully communicated via that channel. Once you have rectified a problem that ClearSCADA has detected with a channel, that channel’s state will remain failed until ClearSCADA has attempted to use that channel. Be aware that a channel’s state is independent of any outstations that are attached to it—for the state of a channel to go healthy, it merely has to receive a validly framed unsolicited or solicited message for that protocol. As such, the channel state merely indicates the state of the port local to the server, whereas an outstation’s state indicates the state of the communications path between the outstation and the ClearSCADA server.)

For an example program, see Example 2 - Use an ST Program to Switch Channels Automatically.

Example 1 - An Example Switched Dual Channel Setup

Four Direct outstations are configured to communicate in a switched dual channel setup. They are associated with a Switched Outstation Set. The outstation set’s configuration specifies that the outstations communicate via Channel A or Channel B.

The ClearSCADA server attempts to establish communications with the outstations via Channel A. The channel is ‘Healthy’ but the ClearSCADA server cannot establish communications with the first outstation as there is signal interference. The ClearSCADA server switches to the alternate channel (Channel B) and requests data from each outstation.

All of the outstations communicate via Channel B as the switched dual channel setup only allows the outstations to communicate via one of the two channels.

Example 2 - Use an ST Program to Switch Channels Automatically

Four Direct outstations are associated with a Switched Outstation Set and communicate in a switched dual channel setup. The outstations in the set use Channel A as the preferred communications channel.

ClearSCADA detects that the line specified as Channel A has failed. ClearSCADA switches outstation communications to the ‘backup’ channel, Channel B.

A Structured Text program continuously runs in the background. The program monitors the state of two ‘nominated’ outstations on the switched set (outstations 1 and 2). Once ClearSCADA has detected that Channel A has failed, the Structured Text program periodically attempts to ‘toggle’ between the channels.

Engineers investigate the reported failure of Channel A and rectify the problem.

The next time that the Structured Text program attempts to ‘toggle’ between the channels, it detects that Channel A has recovered and uses the set’s Switch Line pick action to switch the outstations back to communicate via that channel.

The syntax used for the Structured Text program is based on the following:

PROGRAM AutoSwitchToChannelA
METHOD
SwitchedLine AT %M(.Switched Set.SwitchLine):DINT;
END_METHOD
VAR
RTU1state AT %M(.Outstation 1.State):BYTE;
RTU2state AT %M(.Outstation 2.State):BYTE;
END_VAR
VAR
RTU1Failed : BOOL;
RTU2Failed : BOOL;
TOGGLE : DINT :=0;
END_VAR
RTU1Failed := RTU1state = 3 OR RTU1state = 12;
RTU2Failed := RTU2state = 3 OR RTU2state = 12;
IF RTU1Failed AND RTU2Failed THEN
SwitchedLine(TOGGLE);
END_IF;
END_PROGRAM

where:
‘.Switched Set’ is the name and path of the outstation set
‘.Outstation n’ is the name and path of each nominated outstation
The program checks whether both outstations are in the Failed state (3), or in the Healthy, A Failed state (12) and if so, uses the set’s SwitchLine method to toggle the lines.

For more information on Structured Text programs and the syntax that ClearSCADA supports, see the ClearSCADA Guide to Logic. For ClearSCADA naming conventions and the arguments that particular database fields and methods support, see the Database Schema.


Advanced Drivers Guide - Direct - PSTN Fallback (Outstation Types and Communications Set-ups)

Direct - PSTN Fallback

If supported by the driver and outstation type, you can configure outstations that use Direct Channels for communications to have a ‘backup’ PSTN channel (referred to as a PSTN fallback channel). Configure PSTN fallback for any outstations on your system that have a dial-up modem as a ‘backup’ method of contacting the ClearSCADA server.

You enable and define the PSTN fallback properties on the relevant Outstation Form (see Define an Outstation’s PSTN Properties).

The ClearSCADA server typically only communicates with the outstation via the defined PSTN fallback channel if it detects that the outstation’s direct channel or channels have failed. Using the PSTN fallback channel, the ClearSCADA server can continue to retrieve the outstation’s data even after detecting that the direct channels have failed.

Once permanent communications is re-established, the outstation reverts to using its direct channel or channels.

Example:

The ClearSCADA server communicates with four outstations via a direct-dual channel (switched) communications set-up.

The outstations are configured to have PSTN fallback.

ClearSCADA communicates with the outstations via the direct channel that is configured as Line B.

ClearSCADA detects that the Line B channel has failed.

ClearSCADA switches the outstations to the alternate direct channel—Line A.

ClearSCADA detects that Line A has failed. This results in the outstations having no direct communications connection with the ClearSCADA server.

As ClearSCADA has detected that both direct channels have failed, the ClearSCADA server uses PSTN fallback channels to communicate with the outstations.

When the direct channels are restored to a ‘Healthy’ state, the outstations automatically switch back to the preferred direct channel.

With outstations that support configuration downloads and PSTN fallback, you can specify whether ClearSCADA is to download configuration to an outstation via PSTN, rather than the outstation’s direct channel(s) (see Downloading Configuration Changes in the ClearSCADA Guide to Core Configuration, and see Define an Outstation’s PSTN Properties).


Advanced Drivers Guide - Shared Outstations (Outstation Types and Communications Set-ups)

Shared Outstations

Shared outstations use a dual channel communications set-up whereby the outstations communicate with the ClearSCADA server via one of two Direct Channels. The outstations are grouped into Shared Outstation Sets. Unless configured otherwise, each outstation may communicate via either of its set’s direct channels—all of the outstations in the set do not have to use the same channel at any given time.

As with a Switched Dual Channel set-up, shared dual channel communications provide a direct ‘backup’ channel. If ClearSCADA detects that one of the direct channels has failed, it continues to communicate with the outstations using the alternate channel.

The main advantage of a shared dual channel set-up over a switched dual channel set-up is that each outstation may use either of the channels. This provides more efficient communications as the load is shared between the two channels rather than the entire data transfer occurring via one channel while the other channel is idle.

If supported by the driver and outstation type, a Shared outstation may also have a dial-up modem to provide PSTN fallback. With PSTN fallback, if ClearSCADA detects that both direct channels have failed, communications between ClearSCADA and the outstation continue via the modem and PSTN channel. For further information, see Direct - PSTN Fallback.

For information on assigning direct channels to a Shared outstation set, see Defining Channel Settings for a Shared Set.

You can configure each outstation in a shared outstation set to:

  • Use either channel (see Communications via Either Channel).
  • Use a specific channel (see Communications Fixed on Line A or Fixed on Line B).
  • Use the same channel as the outstation that has been designated that outstation’s ‘Group Master’ (see Communications Determined by a Group Master).

You configure the required properties using the fields on the Shared tab of the Outstation Form (see Define an Outstation’s Shared Properties).

NOTE: Shared dual channel communication set-ups are also referred to as Load Shared communications.


Advanced Drivers Guide - Communications via Either Channel (Outstation Types and Communications Set-ups)

Communications via Either Channel

Where the outstations on your system can use either of two direct channels to communicate with the server, you can configure the outstations to be in a shared outstation set that uses either of the available channels for communications. The outstations in a shared set do not all have to use the same channel at any given time.

In direct shared communication set-ups, the efficiency of data transfer is maximized as the load is shared between the two available channels, rather than all communications being via one of the channels. However, if ClearSCADA detects a fault with one of the channels, all communications will take place via the alternate channel.

When configuring a shared communication set-up, you should aim to distribute the outstations evenly across the channels, taking into account any outstations that are fixed to either channel. This will help to ensure that the channels do not become overloaded, and help provide the most efficient communications between the server and the outstations.

Providing that:

  • The two channels are completely separate (with no commonality anywhere along the network)

and:

  • The driver and remote device support such a feature

you can configure each shared outstation to use the heartbeat polling feature. When heartbeat polling is enabled, the ClearSCADA server automatically sends a heartbeat pulse to the outstation via the channel that is not in use. This checks that the shared outstations can communicate via their alternate channel (that is, the channel that they are not currently using for communications). Use the Heartbeat section on an Outstation Form’s Shared tab to specify whether heartbeat polling is required (see Poll Outstations on the Other Channel). Use the Reestablishment Interval field on the Scan Parameters tab of the Direct Channel Form (see Establish Communications with Failed Outstations) to specify the rate at which any heartbeat pulses are sent.

Example:

In this setup, each outstation is connected to both of the direct channels (Line A and Line B).

Outstations 1 and 2 are using Line B to communicate with the ClearSCADA server, whereas outstations 3 and 4 are using Line A.

This even distribution of outstations helps to prevent either of the channels becoming unnecessarily overloaded, and helps provide the most efficient communications between the ClearSCADA server and the outstations.


Advanced Drivers Guide - Communications Fixed on Line A or Fixed on Line B (Outstation Types and Communications Set-ups)

Communications Fixed on Line A or Fixed on Line B

Where the outstations on your system use only a single channel within a dual-channel set-up, you can configure those outstations to be in a shared outstation set, in which the outstations only communicate via a specified channel. The channels are identified as Line A and Line B (the channels are defined as Line A and Line B in the outstation set configuration).

Outstations that are ‘fixed on Line A’ cannot communicate with the ClearSCADA server via the alternate channel—‘Line B’ is unavailable. Similarly, outstations that are ‘fixed on Line B’ cannot communicate via Line A.

Fixed on Line A or B dual channel set-ups are used when an outstation only communicates via one direct channel, but that channel is used as part of a dual channel communications set-up (with other outstations that use both channels). Typically, this is the case when an outstation is located near to an existing dual channel set-up. It is more cost effective for the outstation to use one of the channels in the dual channel set-up than to set up a direct single channel set-up for the outstation.

Example:

In this example, the first two outstations in a set are connected to both direct channels (Line A and Line B). The set to which they belong is a shared set, and the outstations alternate between using Line A and Line B.

The last two outstations in the set use only one channel (Line A). These outstations, which have addresses 3 and 4, are in the same shared set, but have their communications fixed on Line A. The outstations communicate with the ClearSCADA server using only one direct channel.

To avoid the expense of installing an additional channel, the existing channel (Line A) is used for these outstations. As the outstations are of lesser importance than the other outstations in the set, it has been decided to avoid the expense of providing redundant communications, and so the outstations can only communicate on one channel.

To help provide the most efficient communications, the outstations with addresses 1 and 2 are configured to use Line B as the preferred channel. As such, they only use Line A (which is the line that is used by the outstations that can only communicate using one channel) if Line B is unavailable.


Advanced Drivers Guide - Communications Determined by a Group Master (Outstation Types and Communications Set-ups)

Communications Determined by a Group Master

You can configure each outstation in a shared outstation set to use the same channel as an outstation that has been designated as that outstation’s ‘Group Master’. The ‘Group Master(s)’ can be any independent outstation(s) within the set. The rest of the outstations in the set are known as Group Slave outstations. Whenever a Group Master switches to another channel, the Group Slave outstations that are assigned to that Group Master also switch to use the same channel as the Group Master.

Outstations that use a Group Master/Slave set-up are configured as Group Master or Group Slave outstations on the Outstation Form for each outstation. You need to ensure that one or more independent outstations in the set are defined as the Group Masters for the Group Slave outstations in the set. You also need to specify whether the switching takes place at each Group Master or on an individual outstation basis.

Group Slave outstations cannot switch channels independently—they are designed to use the same channel as their Group Master.

Example:

In this setup, the outstation with address 1 has been defined as the Group Master for the rest of the outstations in the set.

When the Group Master switches channels to communicate using channel B, each of the Group Slave outstations in the set also switch channels to communicate via channel B.


Advanced Drivers Guide - PSTN Outstations and Communications (Outstation Types and Communications Set-ups)

PSTN Outstations and Communications

PSTN Outstations communicate with the ClearSCADA server using a dial-up modem, and are grouped into PSTN Outstation Sets.

The ClearSCADA server and the PSTN outstations communicate via the Public Switched Telephone Network. This means that communications are only established under certain circumstances—in order for the outstations to report (dial in) to the ClearSCADA server when an alarm condition occurs, according to a schedule, or upon request.

With some protocols, you can associate a number of PSTN Channels with each PSTN outstation, to enable that outstation to dial out to the server when an alarm occurs (see the driver-specific guide for information on how many channels you can associate with each outstation). Ideally, some of these channels should be dedicated Dial In lines, to improve the likelihood of the outstation being able to contact the server if an alarm situation occurs. You specify whether a channel is Dial In, Dial Out, or Dial In and Out, on the Form for the channel (see Defining PSTN Settings for a Channel). PSTN channels are not dedicated to individual outstations—they can be used by any outstation that uses the same connection type to communicate with the server.

PSTN outstations store the data from the measuring instruments and control devices to which they are attached. The data is available to the ClearSCADA server upon request.

When the ClearSCADA server makes a request for the logged data, it typically calls the outstation, the outstation reports the data, and then the communications line is typically closed. This type of request is called a One Shot request.

A similar procedure occurs when controls are sent from the ClearSCADA server—the ClearSCADA server calls the outstation, sends the control, retrieves any data, and then closes the line.

If required, a Queue feature can be enabled on your system to allow users to optionally queue certain pick action requests on PSTN outstations, rather than send those requests to the outstations immediately. For more information, see Define whether the Queue Parameter is Available in the ClearSCADA Guide to Server Administration, and see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations in the ClearSCADA Guide to Drivers.

PSTN communications are used when:

  • A direct line connection is impractical due to the geographical location of the outstations (for example, radio communications may be impractical due to interference, or regulations regarding the erection of communication masts.)
  • A direct line connection is not cost-effective (for example, it can be expensive to lay direct lines over long distances).

Additionally, outstations that usually use a permanent connection to communicate with the ClearSCADA server can have a dial-up modem to use PSTN as a ‘fallback’ means of communication. Such outstations typically only use PSTN to communicate with the server if ClearSCADA detects that the direct channel or channels via which they normally communicate have failed. Once permanent communications is re-established, the outstations return to using the direct channels (see Direct - PSTN Fallback).

(With systems on which telephone call duration costs do not apply, an Open Line call is sometimes used instead of a One Shot call. Unlike a One Shot call, an Open Line call enables ClearSCADA to maintain communications with a PSTN outstation for a specified time period.)

Further Information

Retrieving Data from PSTN Outstations.

Defining PSTN Settings for a Channel.

Define an Outstation’s PSTN Properties.

Define Dial In Line Properties on a PSTN Outstation.

For an example that demonstrates how PSTN Channels might be used for inbound and outbound PSTN communications, see Define Dial In Line Properties on a PSTN Outstation.


Advanced Drivers Guide - Scanning Direct Outstations

Scanning Direct Outstations

The process of scanning (‘polling’) direct outstations for data differs with each advanced driver. This section explains the basic principles that apply to most advanced drivers. Use this section in conjunction with the relevant driver-specific documentation for comprehensive information on the scanning regime used by the driver(s) on your system.

This section describes the scanning method used for direct outstations on many advanced drivers.

Many outstations on advanced drivers support current data—the present state or value of a point at the instance that the ClearSCADA server requests current data from the outstation. Many outstations also support logged data—time stamped data that is stored at the outstation.

Scanning is the process of checking each of the outstations on a channel to assess whether any of those outstations have new current data or logged data. The data is then retrieved, processed and stored in the database, ready for use in ClearSCADA. Each advanced driver on a ClearSCADA system undertakes the scanning of the outstations that are associated with that driver. For instance, the IEC 60870-5 driver on a ClearSCADA system scans each of the IEC 60870-5 outstations that are active.

The process of retrieving data differs, depending whether the outstation has a permanent connection to the server (‘direct communications’), or uses a dial-up modem and telephone line for all communications (‘PSTN communications’). (With a PSTN outstation, communications are typically re-established each time the server requests data from the outstation, or the outstation dials in to report an alarm. Once data has been retrieved from a PSTN outstation, communications then typically cease until the next time that a connection is established. For information on this type of connection, see Retrieving Data from PSTN Outstations.)

For information on the process used to scan direct outstations on many advanced drivers, see Scanning Process.

Further Information

Outstation Types and Communications Set-ups.


Advanced Drivers Guide - Scanning Process (Scanning Direct Outstations)

Scanning Process

NOTE: With some advanced drivers, the scan process differs slightly to that documented within this section. For instance, some drivers can broadcast messages at the beginning of a System Scan. Where scanning by a particular driver differs, any differences are explained in the driver-specific documentation.

With direct communications—such as when an outstation communicates with ClearSCADA via a network, radio, or cable connection—a permanent connection is maintained between the ClearSCADA server and each outstation.

The server scans one outstation after another on each channel, starting with the outstation that has the lowest address. When the server makes a request for outstation data, it typically establishes communications with the outstation that has the lowest address on that channel. Once the outstation has reported its data, the server requests data from the next outstation on the channel. Once the server has scanned (polled) each outstation in turn on a particular channel, it repeats the whole process, starting once again with the outstation that has the lowest address.

The actual scanning process varies, depending on the protocol. With direct outstations on many advanced drivers, scanning is typically achieved using two scan phases. With many advanced drivers, the driver typically scans each of the outstations on a channel for current data (the Primary Phase of the scan). When each of the outstations have been scanned, the driver then typically scans the outstations again, this time for secondary (logged) data (the Secondary Phase of the scan). The complete process (retrieval of both current and logged data) is referred to as a System Scan.

The driver retrieves any current point data from the outstations.
The driver retrieves any time stamped logged data from the outstations.

The exception to this process is when the ClearSCADA server has not been in, or has regained, communications with an outstation. In such circumstances, the driver typically performs an Establishment Phase scan in place of a Primary Phase scan (see Establishment Phase).

The purpose of the two-phase scanning method is to retrieve the latest data quickly, while preventing any outstations that have a lot of data to report from dominating the communications on a channel.

Normally, system events will primarily be detected during current data extraction, with retrieval of event logs and timed logs (buffers) having secondary importance.

Example:

A driver scans four outstations that are using a direct channel to communicate with the server.

It firstly scans each of the outstations for current data. This is known as the Primary Phase of the scan.

It scans the outstations in ascending address order, starting with the lowest address (in this case, Address 3).

Outstations on a direct channel are scanned in ascending address order—in this case, address 3, followed by addresses 4, 5 and then 6.

As each outstation has differing amounts of current data, the time taken to scan each outstation differs.

Once the current point data has been retrieved from the four outstations, the driver scans the outstations for any logged data. Again, the amount of logged data varies per outstation and as such, the amount of time that the driver takes to scan each outstation differs. This part of the scan is known as the Secondary Phase.

For each driver that uses direct communications on your system, you need to specify the frequency with which the driver is to scan each outstation for current data and/or logged data. Depending on the protocol, you specify the required data retrieval or scan intervals on either the Channel Form or the Outstation Form (see the driver-specific documentation for details).

The rest of this section contains information on:

  • The Scanning Establishment Phase
  • System Scan Termination
  • Temporarily Increasing the Scan Rate
  • Configuration Requirements
  • Monitoring the State of Direct Communications on your System.


Advanced Drivers Guide - Establishment Phase (Scanning Direct Outstations)

Establishment Phase

NOTE: With some advanced drivers, the Establishment Phase scan differs to that documented within this section. Where this phase differs on a particular driver, any differences are explained in the driver-specific documentation.

When the ClearSCADA server has not been in communications with a direct outstation—for example, at system start-up, or when communications recover after previously being detected as having failed—the driver performs an Establishment Phase Scan, rather than the usual Primary Normal Phase scan.

The operations performed during an Establishment Phase Scan vary depending on the type of outstation, but may include:

  • Setting the outstation’s clock
  • Retrieving general information about the outstation
  • Retrieving current data from each of the points on the outstation.

With an Establishment Phase scan, or a Primary Phase scan, the driver checks for point changes. Following an Establishment Phase scan, the current data for each of the points on the outstation is updated in ClearSCADA. This is regardless of whether the data has changed since the server was last in communication with the outstation.

Following a Primary Phase scan, ClearSCADA typically only updates the data of those points that are genuinely deemed to have changed since the last data retrieval (for instance, points for which the value has changed significantly, or for which there has been a change of state).

The driver-specific documentation indicates if the update procedure differs from that mentioned here.

This initial establishment sequence indicates that the ClearSCADA server has been out of contact with the outstation for so long that the validity of the data held by the server for that outstation is suspect.

An Establishment Phase scan is typically performed only when one of the following conditions occur:

  • The server, a driver, channel, set, or outstation has become Active (In Service) after previously being inactive (not In Service). For example, when a new outstation has just been added to the system and is now ‘live’.
  • A direct outstation has been out of communications with the server and communications are restored. The server attempts to restore communications on the next scan, after a user-definable period of time has elapsed since the last attempt. Specify this time period using the Reestablishment Interval field on the Form(s) for the Channel(s) that the outstation is to use (see Establish Communications with Failed Outstations).
  • A Reset Outstation command is issued from the server.

The Establishment Phase replaces the Primary Normal Phase, and is followed by a Secondary Normal Phase, during which logged data is extracted from the outstation (see Scanning Process).

Properties that you specify on the Scan Parameters tab of each Channel Form determine how many times the server attempts to establish communications with a direct outstation before it deems that outstation to have failed, and thereafter how often it attempts to re-establish communications with that outstation.

Example:

A driver scans four outstations that are using a particular direct channel to communicate with the server. The outstations have outstation addresses of 3 to 6.

The channel via which ClearSCADA communicates with the outstations includes this configuration:

Comms Retries: 3
Transactions Attempts: 2

The driver tries to contact an outstation that has an address of 4, but receives no reply from the outstation. It tries to contact the outstation again. There is still no reply. It tries again for a third, and then a fourth time. As there is still no reply, and the Comms Retries for the outstation are defined as 3, the transaction is deemed to have failed.

The second transaction also fails. As the Transaction Attempts for the outstation is defined as 2, the outstation is deemed to have failed.

A Reestablishment Interval starts as soon as the outstation is deemed to have failed.

At the end of this interval, the driver only attempts to establish communications with the outstation once during each scan cycle.

In the next System Scan after the Reestablishment Interval has elapsed, the driver does manage to make contact with Outstation 4. However as the outstation was previously marked as failed, the driver performs a full Establishment Phase scan on the outstation. This type of scan is performed to ensure that the data retrieved from the outstation is fully up to date.

(For further information on Comms Retries and Transaction Attempts, see Defining Scan Parameter Settings for a Channel. For further information on the Reestablishment Interval, see Establish Communications with Failed Outstations.)


Advanced Drivers Guide - System Scan Termination (Scanning Direct Outstations)

System Scan Termination

A System Scan is typically deemed to be complete when a driver has scanned each of the direct outstations that are active on a channel, for new current and logged data.

The exact events that determine the termination of a system scan differ with some advanced drivers. Such differences, where they exist, are explained in the driver-specific documentation.


Advanced Drivers Guide - Temporarily Increasing the Scan Rate (Scanning Direct Outstations)

Temporarily Increasing the Scan Rate

Some advanced drivers allow the rate at which a direct outstation is scanned to be temporarily increased. Such an increase in scan rate is known as scanning ‘promotion’.

An operator with the required permissions can manually increase the rate of scanning a direct outstation by using a Promote Scanning pick action.

Such promotion might be required during times of critical operation procedures, for example when feedback is required following a control action.

In order to promote the scanning of an outstation following a control, the Promote feature has to be enabled on the Form for that output point or pulse action (see Promoting Scanning of Outstations Associated with Controls in the ClearSCADA Guide to Core Point Configuration).

In order to promote the scanning of an outstation while any of its points are displayed on a client—for example when a Mimic showing a point is on display—the Promote when Displaying Points feature has to be enabled on the Form for that outstation (see Define Whether an Outstation is Promoted While its Points are on Display).

You also need to define the promotion window for direct outstations by entering an appropriate period in the relevant field on the Channel or Outstation Form (see the driver-specific documentation).

At the end of a Promotion window, the server automatically returns a promoted outstation back to its non-promoted state, so that it is then included within the normal system scan. However, while an outstation is still promoted, an operator can manually return the outstation to its non-promoted state by using a Cancel Promoted Scanning pick action.

NOTE: For direct outstations that have fallen back to using PSTN communications, see Temporarily Increasing the Frequency with which an Outstation is Called.


Advanced Drivers Guide - Configuration Requirements (Scanning Direct Outstations)

Configuration Requirements

To define the scanning requirements on your system, you need to undertake a combination of:

  • Channel Configuration
  • Outstation Configuration
  • Point Configuration.

The configuration Forms on some advanced drivers may have other scan-related properties in addition to, or instead of, those listed in the above sections—see the driver-specific documentation for details.


Advanced Drivers Guide - Channel Configuration (Scanning Direct Outstations)

Channel Configuration

Use the fields on the Scan Parameters tab of each Channel Form to specify the following information:

  • Re-establishment Interval (see Defining Further Scan Parameter Settings for a Direct Channel)
  • Comms Retries (see Defining Scan Parameter Settings for a Channel)
  • Transaction Attempts (see Defining Scan Parameter Settings for a Channel)
  • The non-continuous polling Communications Statistics update rate (if required) (see Defining the Communication Statistics Update Rate).

With direct channels on many advanced drivers, you can specify up to eight Scan Groups to define the frequency with which the driver scans for data on the outstations on the channel. For the channels that support this feature, you configure the time interval for each Scan Group, Scan 1 to Scan 8, on the Scan Parameters tab of the Channel Form (see Define Intervals for Timed Current Data Updates). You can then select one of these Scan Groups on each Point Form, to specify how often the driver should request the data from each point on each outstation that is associated with the channel. The Scan times control the timed reporting of current data. The advantage of this time reported current data, over time reported logged data, is that if ClearSCADA detects that the outstation comms has failed, a backlog of timed reports is not accumulated.

For any fields on the Channel Form that are not listed above, see the driver-specific documentation.


Advanced Drivers Guide - Outstation Configuration (Scanning Direct Outstations)

Outstation Configuration

Use the Outstation Form to specify any scanning-related configuration for each outstation. The fields for this configuration vary per driver and per outstation—for details, see the Outstation Configuration chapters in the driver-specific documentation.


Advanced Drivers Guide - Point Configuration (Scanning Direct Outstations)

Point Configuration

Use the Point Form to specify any additional scanning-related configuration for each point. The field(s) for this additional configuration can vary per driver and per outstation—for details, see the Point Configuration chapters in the driver-specific documentation.

Typically, if an outstation supports logged data, you specify if data for a particular point is to be logged at the outstation and if so, the type of data that is to be logged. Some outstations also support timed reporting of data, for which you need to specify the frequency with which the reports occur.


Advanced Drivers Guide - Monitoring the State of Direct Communications on your System (Scanning Direct Outstations)

Monitoring the State of Direct Communications on your System

You can use Status displays to check on the status of individual channels or outstations (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients), and Mimics or Lists to monitor one or more channels or outstations on your system. Lists that display communication statistics, such as those listed below, are useful for monitoring the state of communications on a ClearSCADA system:

  • Channel Scanning Statistics List
  • Channel Serial Port Statistics List
  • Outstation Comms. Statistics List.

The Lists are available from the ViewX Queries Bar. For further information on using Lists, see the ClearSCADA Guide to Lists.


Advanced Drivers Guide - Retrieving Data from PSTN Outstations

Retrieving Data from PSTN Outstations

This section describes the data retrieval method used for PSTN outstations.

Many outstations on advanced drivers support current data—the present state or value of a point at the instance that the ClearSCADA server requests current data from the outstation. Many outstations also support logged data—time stamped data that is stored at the outstation.

The process of retrieving data from an outstation differs, depending whether the outstation has a permanent connection to the server (‘direct communications’), or uses a dial-up modem and telephone line for all communications (‘PSTN communications’). For information on the former type of connection, see Scanning Direct Outstations.

With a PSTN connection, communications are typically re-established each time the server requests data from the outstation or the outstation dials in to report an alarm. You can configure dial in limits for the outstation so that if it is dialing in too frequently, ClearSCADA will raise an alarm or generate an event to inform users that a potential problem has been detected. To configure the dial in limits, you need to use the Dial In Overactive feature (see Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently).

When data has been retrieved from a PSTN outstation, communications typically cease until the next time that a connection is established.

When ClearSCADA requests data from a PSTN outstation, the server typically makes a ‘One Shot’ call to that outstation to retrieve the data from the outstation. If you want a ‘One Shot’ to occur automatically and on a regular basis, you should associate the One Shot pick action with a Schedule (see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration). You can use a Schedule, for example, to trigger the server to call a particular outstation or outstations at 04:00 each day and retrieve any data that has been generated since the outstations were last called.

(With systems on which telephone call duration costs do not apply, you might want to consider using an Open Line call instead of a One Shot call. Unlike a One Shot call, an Open Line call enables ClearSCADA to maintain communications with a PSTN outstation for a specified time period—for more information, see Configuring an Outstation, and see Define an Outstation’s PSTN Properties.)

A One Shot call is triggered whenever any pick action is executed that requires the ClearSCADA server to communicate with a PSTN outstation, or an outstation that has fallen back to using PSTN communications. Such actions include, for example, any Control, Inching, or One Shot pick actions.

Use this section for information on:

  • Temporarily Increasing the Frequency with which an Outstation is Called
  • Configuration Requirements
  • Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently
  • Monitoring the State of PSTN Communications on your System.


Advanced Drivers Guide - Temporarily Increasing the Frequency with which an Outstation is Called (Retrieving Data from PSTN Outstations)

Temporarily Increasing the Frequency with which an Outstation is Called

The Promote Dial Out pick action can be used to increase the rate of data retrieval from a PSTN outstation or group of PSTN outstations. This pick action is also available for direct outstations that have fallen back to using PSTN communications.

Such promotion might be required during times of critical operation procedures, for example during a storm or a flood, when rapidly changing river-level data needs to be retrieved at a more frequent rate than usual.

When a ClearSCADA system is first installed, a system administrator should specify the default interval and duration for Promoted Dial Outs. These settings are configured using the ClearSCADA Server Configuration Tool (see Define the Default Promoted Dial Out Settings in the ClearSCADA Guide to Server Administration).

In order for the Promote Dial Out pick action to be accessible, the Promote Dial Out feature has to be enabled on the outstation (see Define an Outstation’s PSTN Properties), or the outstation set (see Defining Communication Settings).

While a dial out is still promoted, an operator can manually return the outstation to its non-promoted state by using a Cancel Promoted Dial Out pick action. This pick action is available for both PSTN outstations, and direct outstations that have fallen back to using PSTN communications.


Advanced Drivers Guide - Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently (Retrieving Data from PSTN Outstations)

Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently

You can use the Dial In Overactive feature to alert users whenever a PSTN outstation is dialing in excessively.

When you configure the Dial In Overactive feature for a PSTN outstation, you define a dial in limit and a time period. If the number of times the outstation dials in during the defined time period exceeds the dial in limit, an alarm is raised or an event is logged. The alarm or event indicates that the outstation is dialing in too frequently. The possible reasons for a PSTN outstation dialing in too often include:

  • A high number of alarms being raised or cleared
  • A log (or buffer) filling or overflowing
  • Scheduled dial-ins configured to occur too often
  • Excessive use of the Callback feature
  • The outstation requires configuration.

Some of these conditions may be due to incorrect configuration at the outstation, for example, there may be a high number of alarms being raised because of poorly configured alarm limits (and other alarm limit related settings, such as Persistence).

When an alarm is raised as a result of the outstation dialing in too frequently, the alarm is added to the various Alarms displays, including the Alarms List and Alarm Banner.

The alarm has the following message:

Too many incoming calls (# calls in less than <interval>)

Where:

  • # is the number of incoming calls
  • <interval> is the configured interval, for example, 1D.

The number of calls shown in the alarm message will be updated if additional incoming calls occur before the time period elapses. An event will be logged for each individual dial in and the alarm will clear automatically at the end of the dial in time period.

A dial in call is counted at the end of the call and so an alarm is only raised when the call has been completed. All incoming calls are counted, including any calls that are deemed to have failed (providing that the driver can identify which outstation made the call). Some drivers do not count text message calls. For further information, please refer to the driver documentation.

You can view the number of dial ins that have occurred during the current time period by accessing the status display for the required outstation. (The outstation status display is sometimes referred to as the outstation View window or outstation View dialog box). The number of dial ins is shown next to the Dial In Overactive entry and shows the number of incoming calls in the current time period and the maximum number of calls.

Example:

A PSTN outstation is scheduled to dial in once per day. Under normal circumstances, the outstation would be expected to detect between 0 and 9 alarm conditions per day.

The Dial In Overactive feature is configured for the outstation. This sets the outstation to have a limit of 10 dial ins per day (1 scheduled dial in and a maximum of 9 dial ins related to alarm detection). If the outstation dials in more than 10 times in a day, an alarm will be raised to indicate that there is an excessive number of dial ins.

The outstation detects 11 alarm conditions in 6 hours. This causes an alarm to be raised that informs users that the outstation is detecting an excessive amount of alarms. This may be due to a genuine problem on site that is causing a high number of alarm conditions or may be the result of incorrect configuration on the outstation. An engineer responds to the alarm by acknowledging it. The alarm remains uncleared. If there are any further dial ins, The number of calls shown in the alarm message will be updated and an event will be logged for each individual dial in.

An engineer investigates the alarms being detected by the outstation and determines that the problem is caused by incorrect alarm limits being configured at the outstation. The engineer corrects the configuration and the alarm is cleared at the start of the next dial in time period.

To configure the Dial In Overactive settings for an outstation, see Define Dial In Overactive Properties on a PSTN Outstation.


Advanced Drivers Guide - Configuring an Outstation to Generate an Event if it Dials In Too Frequently (Retrieving Data from PSTN Outstations)

Configuring an Outstation to Generate an Event if it Dials In Too Frequently

The Dial In Overactive feature allows you to configure an outstation to log an event if the outstation dials in too frequently. This works in the same way as alarms that can be raised when an outstation dials in too frequently—see Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently.


Advanced Drivers Guide - Configuration Requirements (Retrieving Data from PSTN Outstations)

Configuration Requirements

To define the data retrieval requirements on your system, you need to undertake a combination of:

  • Channel Configuration
  • Set Configuration
  • Outstation Configuration
  • Point Configuration.

The configuration Forms on some advanced drivers may include other retrieval-related properties in addition to those listed below—see the driver-specific documentation for details.


Advanced Drivers Guide - Channel Configuration (Retrieving Data from PSTN Outstations)

Channel Configuration

Use the Channel Form to configure the following information for each PSTN channel on your system:

  • The PSTN properties (see Defining PSTN Settings for a Channel)
  • Comms Retries (see Defining Scan Parameter Settings for a Channel)
  • Transaction Attempts (see Defining Scan Parameter Settings for a Channel).


Advanced Drivers Guide - Set Configuration (Retrieving Data from PSTN Outstations)

Set Configuration

Use the Outstation Set Form to specify whether the dial out frequency can be promoted for all outstations in the set (see Defining Communication Settings).


Advanced Drivers Guide - Outstation Configuration (Retrieving Data from PSTN Outstations)

Outstation Configuration

Use the Outstation Form to specify whether the dial out frequency can be promoted for an individual PSTN outstation (see Temporarily Increasing the Frequency with which an Outstation is Called).

You can also use the Outstation Form to define Dial In Overactive settings. These allow you to configure the outstation so that if it dials in too frequently within a defined time period, an alarm is raised or an event is generated (see Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently).


Advanced Drivers Guide - Point Configuration (Retrieving Data from PSTN Outstations)

Point Configuration

Use the Point Form to specify any additional data retrieval-related configuration for each point. The field(s) for this additional configuration can vary per driver and per outstation—for details, see the Point Configuration chapters in the driver-specific documentation.

Typically, if an outstation supports logged data, you specify if data for a particular point is to be logged at the outstation and if so, the type of data that is to be logged. Some outstations also support timed reporting of data, for which you need to specify the frequency with which the reports occur.


Advanced Drivers Guide - Monitoring the State of PSTN Communications on your System (Retrieving Data from PSTN Outstations)

Monitoring the State of PSTN Communications on your System

You can use Status displays to check on the status of individual channels or outstations (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients), and Mimics or Lists to monitor one or more channels or outstations on your system. Lists that display communication statistics, such as those listed below, are useful for monitoring the state of communications on a ClearSCADA system:

  • Channel Scanning Statistics List
    (this includes the number of messages that have been sent to the outstations via each channel, and how many of these messages succeeded or failed, since the statistics were last reset)
  • Channel Serial Port Statistics List
  • Outstation Comms. Statistics List
  • PSTN Channel Calls List
  • PSTN Outstation Calls List.

The Lists are available from the ViewX Queries Bar. For further information on using Lists, see the ClearSCADA Guide to Lists.


Advanced Drivers Guide - Configuring a Channel

Configuring a Channel

Telemetry Channels are the communication lines through which information is passed between the ClearSCADA server and the outstations on your system.

ClearSCADA commonly uses two types of telemetry channel, depending on types of communication supported by the outstations on your system:

  • Direct—Direct channels are used by outstations that are permanently connected to the ClearSCADA server (for example, via a cable, network, or a continuous radio signal).

You need to add and configure a suitable Direct channel for each uninterrupted communications connection between the ClearSCADA server and the Direct outstations in your system.

  • PSTN—PSTN (Public Switched Telephone Network) channels are used by outstations that communicate with the server using dial-up modems. ClearSCADA uses PSTN channels to represent telephone line connections between the ClearSCADA server and PSTN outstations.

Some types of outstation use PSTN channels as the primary means of communication with the ClearSCADA server. For outstations that use a Direct connection to the server, but that also have access to a suitable dial-up modem, PSTN can be used as a ‘fallback’ means of communicating with the server, should the permanent channel(s) become unavailable.

If your system uses PSTN outstations, you need to configure one PSTN Channel to represent each telephone line that is available for use by the ClearSCADA server and/or the PSTN outstations on your system.

If your system uses Direct outstations that are able to use PSTN as a fallback means of communication, you need to configure one PSTN Channel to represent each telephone line that is available for use by the ClearSCADA server and/or the PSTN and PSTN fallback outstations on your system.

Unlike permanent connections, PSTN connections are only established when required. The telephone call is usually terminated as soon as any data has been transmitted.

When a ClearSCADA server dials out to an outstation, it selects any channel that has the same Connection Type as the outstation, provided that the channel is available for use and has valid configuration, with Dial Out configured.

A system administrator can specify which channels the server should use if several are available (see Define how a PSTN Channel is Selected for Communications in the ClearSCADA Guide to Server Administration).

When an outstation dials in to the server, it only ever uses the line or lines that it is configured to use (see Define Dial In Line Properties on a PSTN Outstation). The channels it uses have to be configured to allow outstations to Dial In to the server.

Refer to the driver-specific documentation for the types of channel that an individual driver supports.

Use the fields on the appropriate Channel Form to configure the channels on your system. The Form has several tabs (see Tabs on Channel Forms).

Further Information

Outstation Types and Communications Set-ups.

Preparation - Direct Channels.

Preparation - PSTN Channels.

Minimum Configuration.


Advanced Drivers Guide - Preparation - Direct Channels (Configuring a Channel)

Preparation - Direct Channels

You need to add a suitable Direct Channel for each uninterrupted communications connection between the ClearSCADA server and the Direct outstations that are to use that particular connection. Typically, several outstations multi-drop off each direct channel.

To configure a Direct channel, you need to know the type of connection that the channel uses (Serial, Remote Serial, TCP/IP, or Network), and the settings used for that type of connection.

Often these settings are fixed, according to the type of communications equipment being used. Refer to the documentation associated with the communications equipment for these settings—you need to configure each direct channel to have the same settings as the communications equipment for the outstation(s) with which the channel is associated.

Where any settings are not fixed, you need to be aware of which settings are being used for the communications equipment on your system. The engineers that configure the outstations should create a list of the settings that they have configured. If you have access to such a list, you can use it to define those requirements.

You also need to establish which features are required for each direct channel. You can configure each direct channel to use a variety of features, including Alarm Redirection, and Alarm Views. However, many of these features are optional and do not affect the success of communications. The optional features include:

  • Alarm view
  • Alarm redirections
  • User methods.

If the features listed above are not configured, they are not used for the selected direct channel (they will be left blank).


Advanced Drivers Guide - Preparation - PSTN Channels (Configuring a Channel)

Preparation - PSTN Channels

You need to add an appropriate PSTN Channel for each telephone line that is used on your system.

To configure a PSTN channel, you need to have access to details of the outstation’s dial-up modem settings.

Often these settings are fixed, according to the type of dial-up modem being used. Refer to the documentation associated with the modems for these settings—you need to configure each PSTN channel to have the same settings as the modem with which it is associated.

Where any settings are not fixed, you need to be aware of which settings are being used for the dial-up modems on your system. The engineers that configure the outstations should create a list of the settings that they have configured. If you have access to such a list, you can use it to define those requirements.

In addition to the dial-up modem settings, you also need to know the:

  • Telephone number for the line that is connected to the ClearSCADA server’s modem.
  • Type of communications for which the channel is being used (Dial In and/or Dial Out)
  • Type of dialing supported by the telephone exchange (Pulse or Tone)
  • Delays required to allow the channel to establish communications with an outstation following system start-up or modem connection
  • Timeouts required to determine whether a call has failed
  • Modem command used to initialize the modem
  • Type of connection (see PSTN Connection Types).

You can configure each PSTN channel to use a variety of features, including Alarm Redirection, and Alarm Views. However, many of these features are optional and do not affect the success of communications between the ClearSCADA server and the outstations. The optional features include:

  • Alarm view
  • Alarm redirections
  • User methods.

If the features listed above are not configured, they are not used for the selected PSTN channel (they will be left blank).


Advanced Drivers Guide - Tabs on Channel Forms (Configuring a Channel)

Tabs on Channel Forms

Channel Forms have several ‘tabs’ for configuring different aspects of channel information. For most channels on advanced drivers, a combination of these tabs is available:

  • Identification—Use to optionally define a Help View and to indicate whether the item is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for a channel (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with any channel alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the channel (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • Channel—Use to define the basic communication properties for the channel (see Defining General Channel Communication Settings).
  • Connection—Use to define the connection-specific properties for the channel (see Configure a Channel’s Connection Properties in the ClearSCADA Guide to Drivers).
  • PSTN—Use to define the telephone and dial-up modem properties for a PSTN channel (see Defining PSTN Settings for a Channel).
  • Scan Parameters—Use to define:
  • The communications establishment properties for the channel (see Defining Scan Parameter Settings for a Channel)
  • When communications statistics are updated for outstations that do not use ‘conventional’ scanning (see Defining the Communication Statistics Update Rate)
  • The scan group properties for a direct channel (see Defining Further Scan Parameter Settings for a Direct Channel). (Scan groups apply to direct channels on most advanced drivers—the driver-specific documentation states if they do not apply.)
  • For channels on some advanced drivers, use to define any prefix that needs inserting at the start and/or suffix that needs inserting at the end of each message that is transmitted via the channel (see Defining any Default Pre- and Post-Amble Message Settings for a Channel).

Some advanced drivers have other fields on the Scan Parameters tab in addition to the above—for fields not listed above, see the driver-specific documentation.

This section explains the features on the Channel Form that are common to channels on most drivers.

For aspects of channel configuration that are common to most types of database item, see the ClearSCADA Guide to Core Configuration. For aspects of channel configuration that are specific to individual drivers, see the ClearSCADA driver-specific documentation.

For further information on the settings required for your communications equipment, see the manufacturer’s documentation.


Advanced Drivers Guide - Minimum Configuration (Configuring a Channel)

Minimum Configuration

As a minimum, for any type of channel you have to configure these connection-specific properties:

  • Serial connection—The port to which the channel is connected.
  • Remote serial connection—The host name of the machine that is running the Port Server application, and the port to which the channel is connected.
  • TCP/IP connection—The TCP/IP type, the host address, and port number.
  • Network—The TCP/IP type. (Network configuration is not applicable to PSTN channels.)

If you are configuring a PSTN channel, you also have to enter a telephone number in the appropriate field on the PSTN tab.

For any type of channel, you have to put the channel In Service, and save the configuration if you want the channel to be functional (online).

This will provide a functional channel that uses default configuration settings.


Advanced Drivers Guide - Defining General Channel Communication Settings (Configuring a Channel)

Defining General Channel Communication Settings

Use the fields on the Channel tab of the appropriate Channel Form to configure the basic communication properties for a channel.

The following fields are displayed for channels on many advanced drivers:

  • In Service—Use to specify whether the channel is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

The ClearSCADA server only communicates via channels that are enabled and are therefore ‘In Service’.

  • Severity—Use the combo box to define the priority of any alarms or events that are associated with the channel (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Channel tab. Use the field to specify the area with which any of the channel’s alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Time Zone—Use the combo box to specify the time zone that is used by the outstations’ clocks on this channel. The options vary, depending on the driver, but include one or more of the following:
  • Coordinated Universal Time (UTC)—The clocks run in Coordinated Universal Time.
  • Local Time without Daylight Saving Time—The clocks run in Local Time, for instance EST (Eastern Standard Time) if the local time zone is that for the East coast of America. No adjustments are made for Daylight Saving Time (DST).
  • Local Time with Daylight Saving Time—The clocks run in Local Time. ClearSCADA automatically adjusts the time to account for Daylight Saving Time.

ATTENTION: Depending on the driver, there may be gaps in the data when the clocks are adjusted forwards, or missing data when times repeat after the clocks are adjusted back to account for DST. Use the Local Time without Daylight Saving Time option if such gaps are not acceptable on your system.

On drivers that support local time but not daylight saving time, the latter two options are replaced by a single Local Time option.

For more information, see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.

  • Start Delay—Specify the amount of time between system start-up and the initial availability of the channel. The ClearSCADA server cannot use the channel for communications until the Start Delay time has expired.

Set the Start Delay to 0 on channels on which no delay is required between the system starting up and the channel being available for use. This is the default setting.

Set the Start Delay to a suitable value greater than 0 on channels on which a delay is required between the system starting up and the channel being available for use. For example, on a PSTN channel that is used as a dial-in PSTN fallback channel on outstations that support PSTN fallback. By entering a suitable Start Delay, you allow time for the ClearSCADA server to attempt to establish direct communications with the outstation, before ‘falling back’ to the PSTN channel. If you do not define such a Start Delay, the PSTN channel can be used instead of the direct communications, even when the direct channels are ‘Healthy’—the PSTN channel should only be used when the ClearSCADA server cannot establish communications via the direct channels.

If a PSTN channel is used as a ‘fallback’ channel, specify a suitable Start Delay. We recommend that you use the Event Journal (Events List) to determine how long it takes for the system to start direct communications with each outstation. You should set the Start Delay so that it is greater than the longest time taken to establish direct communications with any outstation that can use the PSTN channel.

You might also want to specify a suitable Start Delay should your system, for example, use multiple channels that communicate via a satellite link. With such a setup, consider whether you want to offset the start-up time of some of the channels to help prevent the satellite links from becoming saturated, should numerous channels activate simultaneously in the event of the system or driver being restarted.

In each case, enter a suitable Start Delay in the OPC Time Format. For example, 20S for 20 seconds. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required delay.

If a channel is not used as a PSTN ‘fallback’ channel and a start-up delay is not required for other reasons, ensure that the Start Delay is set to 0.

  • Eavesdropping—Only displayed if supported by the driver. Eavesdropping is designed for use when upgrading a system. You can use eavesdropping to allow
    a ClearSCADA server to receive unsolicited data via a serial cable link with a channel used by another server.

Use the check box to define whether eavesdropping is enabled or disabled. The check box displays a check mark when eavesdropping is enabled.

You should only enable eavesdropping if the communications channel is connected to the older server’s Rx connection (input connection), or Tx connection (output connection), as required by the protocol. Some protocols require both Tx and Rx eavesdropping, in which case a separate port is needed for each connection. For those drivers that support eavesdropping, the driver-specific documentation indicates which eavesdropping connection(s) are required by that protocol.

For more information on eavesdropping, see Using Eavesdropping to Test a New Server’s Configuration.

  • Establish Timeout—Specify the maximum permitted amount of time that can elapse between an incoming connection being made and ClearSCADA establishing communications with the outstation via this channel. With Direct channels, the timeout applies to inbound network connections; with PSTN channels, the timeout applies to calls made by an outstation dialing in to ClearSCADA.

In either case, if the outstation does not respond within the defined time, the ClearSCADA server cannot establish communications with the outstation and so deems the connection or call to have failed. The failure is shown in the statistics for the channel and the outstation (see the driver-specific documentation).

Specify the timeout in the OPC Time Format, for example, 25S for 25 seconds. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required time.


Advanced Drivers Guide - Defining PSTN Settings for a Channel (Configuring a Channel)

Defining PSTN Settings for a Channel

ClearSCADA uses PSTN Channels to represent communications via telephone lines between the ClearSCADA server and outstations on your system (see PSTN Outstations and Communications). PSTN communications are established each time the ClearSCADA server requests data, or the outstation reports (dials in) to the server.

If a device on your system uses PSTN to communicate with the server, use the fields on the PSTN tab of the associated Channel Form to define the required PSTN settings.

The following fields are displayed for channels on many advanced drivers. The default settings for the fields are shown in the window below.

  • Connection Type—Select the type of connection that is used between the server and the outstation:
  • Standard Modem—Communication is via an ordinary PSTN telephone line.

Other options may be available if they have been configured on the server (see PSTN Connection Types).

  • Telephone Number—Enter the telephone number of the line to which the ClearSCADA server’s dial-up modem is connected.
  • Dial In/Out—Use the combo box to define whether the PSTN channel is used for incoming calls only, outgoing calls only, or both incoming and outgoing calls.
  • Dial In Only—The ClearSCADA server only uses the PSTN channel for receiving calls from outstations.

Configure some of your channels as dedicated for Dial In Only, to ensure that outstations have a better chance of contacting the ClearSCADA server when an alarm occurs. By using such a channel, an outstation will not be blocked from contacting the server due to that channel being busy on an outgoing call.

  • Dial Out Only—The ClearSCADA server only uses the PSTN channel for initiating calls to the outstations.

Select this option if you want a channel to be dedicated to Dial Out Only. By using such a channel, the server is not blocked from issuing an urgent action or control due to the channel being busy on an incoming call.

  • Dial In and Out—The ClearSCADA server uses the PSTN channel for both receiving and initiating calls. This is the most commonly used option.

Select this option if it is not imperative for calls in either direction to get through immediately if the channel is already busy with a call going in the opposite direction. It is advisable to also configure a few dedicated channels on your system (see Dial In Only, and Dial Out Only, above).

Use fields on the PSTN tab of each Outstation Form to define which PSTN channels an outstation can use to dial in to the ClearSCADA server (see Define Dial In Line Properties on a PSTN Outstation). Also see this reference for an example that demonstrates how the various Dial In/Out settings might be used on a ClearSCADA system.

  • Pulse Dialing—Use the check box to define the type of dialing that is supported by the exchange.

Select the Pulse Dialing check box if the PSTN channel represents a connection via a telephone exchange that supports pulse dialing.

Clear the check box if the PSTN channel represents a connection via a telephone exchange that supports tone dialing.

  • Connection Timeout—Specify the maximum permitted amount of time between the ClearSCADA server initiating a telephone call and the dial-up modems making a connection.

Enter the time in the OPC Time Format, for example, 40S for 40 seconds. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required time.

If a connection is not made within the defined time limit, the call is deemed to have failed. The failure is logged in the Event journal as a ‘Modem connection timed out’ message. It is also displayed in the call statistics for the channel and the outstation (see the driver-specific documentation).

  • Post Connection Delay—Specify the amount of time after the dial-up modem has connected, before the server attempts to establish communications with the outstation. A Post Connection delay is often needed when using GSM modems, to allow for the delays caused by the GSM telephone network.

Enter the time in the OPC Time Format, for example, 10S for 10 seconds. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required delay.

  • Modem Command—Enter the Modem Command that initializes the ClearSCADA server’s dial-up modem. The command will vary according to the model of modem. The minimum requirements are:
  • Echo is disabled (E0)
  • Verbose command responses are enabled (V1)
  • Auto answer (S0=1)
    (Not required if the channel is configured for Dial Out Only (see above).)

We also recommend that the modem command includes a hang-up command (H0) so that the modem is initialized in a known state. For more information, please refer to the documentation supplied with your modem.


Advanced Drivers Guide - Defining Scan Parameter Settings for a Channel (Configuring a Channel)

Defining Scan Parameter Settings for a Channel

The communications establishment and reply properties for each channel define:

  • The number of times the ClearSCADA server attempts to establish communications with an outstation that is not responding
  • The maximum number of transaction attempts before ClearSCADA deems an unresponsive outstation to have failed
  • The amount of time the ClearSCADA server can wait for a reply from an outstation before recognizing that the outstation is not communicating (Out of Comms.)
  • The line speed of the connections
  • The amount of time allocated for unsolicited messages
  • The amount of time (if any) that the ClearSCADA server waits between messages that it sends to the outstations that communicate via the selected channel
  • How often the ClearSCADA server attempts to establish communications with an outstation that is not responding.

To configure these properties for a channel, select the Scan Parameters tab on the relevant Channel Form.

The following fields are displayed for both Direct and PSTN channels on many advanced drivers, along with fields for Defining the Communication Statistics Update Rate. In addition, other fields are displayed for channels used by outstations that communicate directly with the ClearSCADA server (see Defining Further Scan Parameter Settings for a Direct Channel). For information on the Reestablishment Interval field, see Establish Communications with Failed Outstations. For fields that are not described in these sections or below, see the driver-specific documentation.

  • Comms Retries—Enter the number of times that the ClearSCADA server attempts to resend a message to an outstation that does not respond to the initial message sent via the channel. If an outstation still does not respond to the final attempt to send the message, ClearSCADA deems the transaction to have failed. (A transaction is an operation, such as issuing a control, or polling an outstation to retrieve data. A transaction may comprise one or more messages sent to or from the server.)

We recommend that you set the Comms Retries to 3.

Example:

The Comms Retries for a channel are set to 3. The server uses the channel to send a control to a point on a particular outstation via that channel. The server does not receive a response to the message, indicating that the message has not been received successfully by the outstation.

The message is sent again. The outstation still does not respond to the message. The message is sent a total of four times (initial message plus 3 retries of the same message (as Comms Retries = 3)). The outstation still does not respond to the message, so ClearSCADA deems the transaction for that control to have failed.

The Comms Statistics for the outstation and channel are updated. As the transaction was for a control, a Control Failed alarm is raised.

  • Transaction Attempts—Enter the number of consecutive message transactions that must each fail to be sent to an individual outstation on the channel before ClearSCADA deems that outstation to have failed. Each transaction failure involves a message being sent then resent for the number of times defined in the Comms Retries field (see above) and still being deemed to have failed.

We recommend that you set the Transactions Attempts to 2.

Example:

The Comms Retries for a channel are set to 3, and the number of Transaction Attempts are set to 2.

The server uses the channel to send a control to a point on a particular outstation via that channel. The server does not receive a response to the message. The message is sent a total of 4 times (original message + 3 re-attempts to send the same message). ClearSCADA deems the transaction to have failed. As only one transaction has failed for the outstation, the outstation itself is not deemed as failed, but the Comms Statistics for the outstation and the channel are updated, and a Control Failed alarm is raised for the control.

The server then sends a separate message to another point on the same outstation. The server does not receive a reply to that message. The message is resent a further three times, but no reply is received from the outstation. ClearSCADA deems the transaction to have failed. ClearSCADA also deems the outstation to have failed as there have now been two consecutive failed attempts to perform any transaction on that outstation.

The Comms Statistics for the outstation and channel are updated. Additionally, ClearSCADA raises alarms and logs events associated with the changes to the outstation’s comms status.

  • Standard Reply Delay—The ClearSCADA server uses the Standard Reply Delay to make allowances for delays caused by the communications media, for example, delays caused by radio transmissions. (It is used by each driver as part of a calculation to determine the maximum amount of time in which an outstation should reply).

For most systems, the default setting of 1000 is suitable.

You may need to increase the Standard Reply Delay if there are a significant number of timeouts (as shown on the Comms. Stats List). For information on using Lists, see the ClearSCADA Guide to Lists.

  • Line Speed—Use to specify the speed of the slowest part of the connection, so that ClearSCADA can correctly calculate the transmission time for each message sent/received via the channel.

If the entire connection between the master station and the outstation uses the same speed (the baud rate), you can set the Line Speed to Same as Baud Rate. You can only use the Same as Baud Rate option if the channel has a baud rate (Serial, or Remote Serial). If you attempt to use the Same as Baud Rate option with other types of connection (TCP/IP, or Network), a diagnostic message is displayed. The Baud Rate is defined on the Connection tab of the Channel Form (see Tabs on Channel Forms).

If part of the connection uses a slower speed, you have to specify the speed in the Line Speed combo box (choose from the list of standard line speeds, or type in the required speed). The driver in the master station uses the baud rate and line speed in its calculations to determine the expected transmission time of each message.

On a Serial connection, the line speed is typically the same as the baud rate. However, for some connections, the Data Communications Equipment (DCE) speed is slower than the Data Terminal Equipment (DTE) speed, and so the line speed has to be set to the slower DCE speed.

On a Network connection, such as an Ethernet, LAN, or WAN connection, the speed is often faster than a Serial connection. For Network connections, we recommend a conservative line speed of 9600, but you can set a faster speed if desired.

For most protocols, speeds above 2Mbs provide typical message transmission times below 1ms.

Example:

A ClearSCADA master station is connected to a dial-up modem (we will refer to this device as Modem 1). A channel is configured for the connection between the master station and Modem 1 and the baud rate of the channel is set to 9600 (this is the baud rate that is supported by Modem 1). When the driver in the master station communicates via Modem 1, it sends the data at the defined baud rate (9600).

Modem 1 transmits the data it receives from the ClearSCADA master station to another modem that is connected to an outstation. We will refer to this 'other' modem as Modem 2. The modems communicate via a wireless connection that is slower than the connection between the master station and Modem 1. The wireless connection uses a line speed of 600.

So that the driver in the master station can correctly calculate the transmission time of each message, it needs to know the line speed of the connection between Modem 1 and Modem 2. So the channel is configured to have a baud rate of 9600 and a line speed of 600.

For information about how the driver calculates the timeout periods, see Driver Calculations for Message Timeouts.

  • Unsolicited Message Timeout—Specify the amount of time the master station will wait for the remaining part of a partial unsolicited message. Typically, the default setting of 5000 milliseconds is appropriate, but you may need to change this amount if you are getting lots of unsolicited messages timing out.

The purpose of the Unsolicited Message Timeout setting is to allow the driver to cease waiting for incomplete messages and allow other operations to continue via the channel. For example, if an outstation is sending an unsolicited message to the driver and the communications fail during the transmission, the driver will only receive part of the message. The driver uses the Unsolicited Message Timeout setting to calculate how long it should wait for the remainder of the unsolicited message. If the driver has not received the remainder of the message within the Unsolicited Message Timeout, the driver aborts waiting which allows other operations to continue via the channel.

When defining the Unsolicited Message Timeout, you need to consider any latency on the communications link. Latency can affect the amount of time it takes for the unsolicited message to be received by the driver.

For information about how the driver calculates the timeout periods, see Driver Calculations for Message Timeouts.

  • Inter Message Delay—Specify a value other than zero if you need to intentionally slow down communications. An inter message delay is useful when you require diagnostic information or when there is a need to prevent an outstation becoming overloaded with messages.

For most systems, the default Inter Message Delay of 0 is suitable.


Advanced Drivers Guide - Driver Calculations for Message Timeouts (Configuring a Channel)

Driver Calculations for Message Timeouts

When an advanced driver sends a message to an outstation, it performs a calculation to determine how long the message should take to arrive at the outstation. If a reply is required, the driver also calculates how long it should wait for a reply. The calculations are used to determine the timeouts for messages. If a message has not been sent or received within the calculated timeout period, the driver deems the message to have failed.

Advanced drivers also perform timeout calculations for unsolicited messages (messages that the outstation sends to the driver). An advanced driver calculates a timeout that is used when the outstation sends a partial message—the timeout defines how long the driver will wait for the remainder of the message. If the remainder of the message is not delivered within the timeout limit, the driver deems the unsolicited message to have failed.

The advanced drivers calculate the timeouts for messages as follows:

For a message that is sent from the driver to the outstation and for which the driver expects a reply, the calculation is:

Transmission time of message + Transmission time of largest possible reply + Standard reply delay + Turnaround time = Timeout.

For a message that is sent from the driver to the outstation and for which the driver does not expect a reply, the calculation is:

Transmission time of message + 1 second = Timeout.

For an unsolicited message (a message that is sent from the outstation to the driver without being requested by the driver), the calculation is:

Transmission time of remainder of message + Unsolicited message timeout = Timeout.

Where:

  • The transmission times are calculated by dividing the size of the message by the line speed.
  • The turnaround time is an estimate (calculated by the driver) of the amount of time the outstation will take to begin transmitting the reply after receiving the complete message.
  • All timeouts are rounded up to the nearest whole millisecond.


Advanced Drivers Guide - Defining the Communication Statistics Update Rate (Configuring a Channel)

Defining the Communication Statistics Update Rate

On channels on which non-continuous polling is used, use the fields within the Communication Statistics Updates section of the Scan Parameters tab to specify when the communications statistics are updated for the channel.

Non-continuous polling applies to PSTN channels.

It also applies to Direct channels, if one or more of the following situations apply:

  • During eavesdropping (when a new system runs in parallel to an existing system—see Using Eavesdropping to Test a New Server’s Configuration)
  • Any protocols that rely on exceptional reporting rather than ‘conventional’ scanning. The driver-specific documentation indicates if non-continuous polling is used by a particular protocol.

Where none of the above situations apply to a Direct channel, ClearSCADA ignores the settings in the Communication Statistics Updates section of the Form and updates communications statistics at the end of each System Scan (see Scanning Process).

The Communication Statistics Updates section of the tab contains these fields:

NOTE: Unless your system has a large number of channels and/or outstations, there should be no need to change these Communication Statistics Updates properties from their defaults. Increasing the Interval, and setting the Offset for multiple channels, can result in reduced CPU load on the ClearSCADA server.

  • Interval—Use to specify the frequency at which a channel’s communications statistics are updated. Enter the frequency in the OPC Time Format, for example, 1M for one minute. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required frequency.
  • Offset—Use to specify the offset, from midnight, for the first communications statistics update. Thereafter, the statistics are updated at the frequency specified in the Interval field, above.

Enter the offset in the OPC Time Format, for example 30S for a 30-second offset. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required offset.

Example:

The Update Rate for a channel has these settings:

Interval = 1M
Offset = 30S

If the time is currently 00:00:00, the next Communications Statistics update will occur at 00:00:30, followed by another update at 00:01:30, then another update at 00:02:30, and so on, at 1-minute intervals offset to 30-seconds past each minute.

Whenever a Direct channel’s communications statistics are updated as per the settings specified in the Communication Statistics Updates fields, the communications statistics for one of the outstations on that channel are also updated. When the next Interval elapses, the channel’s communications statistics are updated again, along with the communications statistics for the next outstation on the channel. This approach enables each of the outstation’s statistics to be updated in turn, without causing excessive loading on the server and clients. (With PSTN outstations, communication statistics are updated at the end of each call.)

You can view the statistics of an individual channel or outstation via that item’s Status display (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients). To view the statistics of more than one channel or outstation, display the Channel Scanning Statistics List, or the Outstation Comms. Statistics List, respectively. (For more information on Lists, see the ClearSCADA Guide to Lists.)


Advanced Drivers Guide - Defining Further Scan Parameter Settings for a Direct Channel (Configuring a Channel)

Defining Further Scan Parameter Settings for a Direct Channel

In addition to the basic Scan Parameters fields (see Defining Scan Parameter Settings for a Channel), further fields are displayed on the Scan Parameters tab for many Direct channels.

These additional fields are used to configure the following functions for Direct channels on advanced drivers:

  • The Reestablishment Interval—Used to define how often the server attempts to establish communications with a failed outstation (see Establish Communications with Failed Outstations).
  • Scan Groups—These are timed current data updates that help to prevent current data from appearing to be out of date (see Define Intervals for Timed Current Data Updates). (Scan groups apply to direct channels on most advanced drivers—the driver-specific documentation states if they do not apply.)
  • Outstation Clock Settings—Used to define when the ClearSCADA server sets the clocks on the outstations that communicate using the channel (see Define when the Server Sets the Outstations’ Clocks).

The direct channels on some drivers include additional fields on the Scan Parameters tab—for information on fields other than those that are listed above, see the driver-specific documentation.


Advanced Drivers Guide - Establish Communications with Failed Outstations (Configuring a Channel)

Establish Communications with Failed Outstations

The Reestablishment Interval field is displayed at the bottom of the Scan Parameters section on the Channel Form. Use the field to define how often the ClearSCADA server attempts to establish communications with an outstation that is deemed to have failed. For further information, and an example of how the Reestablishment Interval is used, see Establishment Phase.

For most systems the default setting of 30 seconds is suitable.

You may need to increase the Reestablishment Interval if the ClearSCADA server is allocating too much of its scan time to establishment attempts, leaving insufficient time to scan those outstations that are communicating.


Advanced Drivers Guide - Define Intervals for Timed Current Data Updates (Configuring a Channel)

Define Intervals for Timed Current Data Updates

Scan groups apply to direct channels on most advanced drivers—the driver-specific documentation states if they do not apply.

When supported by a driver, use timed current data updates (defined using Scan Groups) to help prevent the current data of points from appearing to be out of date. This maintains operators’ confidence in the accuracy of the points’ data.

You can define up to eight scan groups for each direct channel. Each scan group represents a scan interval. You can associate points on direct outstations with any (or none) of the scan groups.

Each point that is associated with a scan group is updated according to the interval that the scan group represents. This means that the points are updated at regular intervals, rather than just when the corresponding instrument or device value causes a significant change or a change of state.

Define the intervals that are required by your system using the eight groups labelled Scan 1 to Scan 8 within the Scan Groups section of a Channel Form’s Scan Parameters tab. The interval requirements will vary according to the purpose of your system.

For each of the Scan 1 to Scan 8 fields, enter the required interval in the OPC Time Format. You can enter the value directly in each field, or use the Interval Window (accessed via each field’s browse button) to specify the required update frequency.

Associate individual points on outstations that use the channel with particular scan groups by specifying the number in the Scan Group field on the <Point Type> tab of the relevant Point Form (see the driver-specific documentation).


Advanced Drivers Guide - Define when the Server Sets the Outstations' Clocks (Configuring a Channel)

Define when the Server Sets the Outstations’ Clocks

Use the Set Outstation Clock section on a Direct Channel Form’s Scan Parameters tab to define when the ClearSCADA server sets the outstation clocks. The ClearSCADA server uses the same interval and offset to set the outstation clocks on each of the outstations that communicate via a defined channel. This means that you can use different Set Clock times for each direct channel if required.

You should configure intervals and offsets that allow the ClearSCADA server to set the outstations at times when communications traffic is moderate. This reduces the load on the communications channel(s).

  • Interval—Specify the amount of time between each set clock message. This defines how often the server attempts to set the clocks of the outstations that communicate via the selected channel. The messages sent at this interval are in addition to the set clock messages that are sent when the ClearSCADA server establishes communications with each outstation.

Enter a suitable time in the OPC Time Format. You can enter the time directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required interval. For most systems, the default setting of 1H (1 hour) is suitable.

  • Offset—Use this field to specify the time offset to which the set clock messages are synchronized.

By default, the set clock messages are synchronized at midnight UTC and then the subsequent set clock messages are repeated according to the defined interval. For intervals of 1D or more, the set clock messages are synchronized at midnight UTC on the first day of the week (Monday), consistent with the Gregorian calendar.

By defining an offset, you can add time to the default synchronization times so that synchronization takes place at a different time. For example, if the Interval is set to 1H and the Offset is zero, it means that the set clock messages are sent every hour starting at the beginning of the next hour. If you define an offset of 10M, it adds 10 minutes to the synchronization time so that the set clock messages are sent every hour starting at 10 minutes past the beginning of the next hour. So if it is 10:35 when you set the Interval to 1H and the Offset to 10M, the next synchronization will take place at 11:10, the following synchronization will take place at 12:10, and so on.

Enter the offset time in the OPC Time Format. You can enter the time directly in the field, or you can use the Interval Window (accessed via the field’s browse button) to specify the required offset. We recommend using an Offset of 5M (5 minutes) to prevent the clocks being set on the hour, which is often the time when data transfers (such as point updates) occur. The Offset is not affected by the channel’s time zone.

Examples:

If the Interval is 1H and the Offset is 5M, the server sets the outstations’ clocks at 5 minutes past each hour, starting at 00:05. At midnight the server synchronizes its Set Clock settings, and the cycle starts again from 00:05 the next morning.

For a ClearSCADA server to set the outstations’ clocks at 1:00 pm on a daily basis, enter 1D in the Interval field and 13H in the Offset field. (13H is 13 hours after the start of the day (00:00)).


Advanced Drivers Guide - Defining any Default Pre- and Post-Amble Message Settings for a Channel (Configuring a Channel)

Defining any Default Pre- and Post-Amble Message Settings for a Channel

Some communications equipment or media require ‘padding’ or specific digits (an additional message) to be inserted at the start and/or at the end of each message that is transmitted using that equipment or media. Prefixed digits or padding are referred to as Pre-Amble and suffixed digits or padding as Post-Amble. Pre- and Post-Ambles always comprise an even number of digits, so giving a whole number of bytes. Pre- and Post-Ambles are typically used to prevent messages from being ‘clipped’ (truncated). However, some communications equipment may use Pre- and Post-Ambles to correctly interpret both the start and end of each transmitted message (or ‘data packet’), or to specify a delay to allow a channel to synchronize before any data is transmitted.

If Pre- and Post-Ambles are required, the actual digits that you need to specify differ, depending on:

  • ‘Padding’ Requirements—Certain types of media, such as old analog radios, are prone to ‘clipping’ messages, therefore padding is required to help to ensure that the actual message content is not clipped. The amount of padding required differs, depending on the communications equipment or media—see the documentation supplied with your communications equipment for the amount of padding that is required. This is typically given as a time (in milliseconds)—you then use the channel’s port settings to calculate the number of bytes that you need to specify to make allowance for the ‘padding’ time that is required (see Calculate the Time that a Channel Takes to Transmit each Byte of Data).

If Pre- or Post-Ambles are used as padding, you can typically specify any Hexadecimal digits that are compatible with the protocol, as long as you specify a sufficient number of digits. Be aware that in some protocols, each message begins with a particular sequence of bytes. Such bytes must not be used as Pre- or Post-Amble padding. Refer to the driver- or product-specific documentation for further details. Typically, the digits FF are used for padding.

  • Instructions for Communications Equipment—Some communications equipment may define commands that can be included with each message, which specify how to process the message. Such instructions typically differ on a per-outstation basis (see Define any Pre- and Post-Ambles for an Individual Outstation). Each command will consist of a sequence of bytes that precede and/or follow the message—you specify these as a sequence of hexadecimal digits in the Pre-Amble field (for instructions that precede the main message) and/or in the Post-Amble field (for instructions that follow the main message)—see the documentation supplied with your communications equipment for the details of any commands supported by the equipment.

If an advanced driver supports Pre- and Post-Ambles, the Channel Form(s) for the driver include an additional Pre/Post Amble section on the Scan Parameters tab. Use the fields within the Pre/Post Amble section to specify the Pre- and Post-Ambles that need including for any transmissions via that channel.

Should a particular outstation use different Pre- and/or Post-Amble bytes to those specified on the channel (for instance, if a radio communicates with that outstation at a different frequency to the other outstations on the channel), you can override the channel’s default Pre- and Post-Amble settings with outstation-specific settings for that particular outstation (see Define any Pre- and Post-Ambles for an Individual Outstation).

The Pre- and Post-Ambles configured in ClearSCADA are only applied to messages that ClearSCADA’s drivers transmit, rather than receive, via a channel.

ATTENTION: Pre-ambles on messages received via network-connected channels are only supported when ClearSCADA initiates the connection.

The Pre/Post Amble section on the Channel Form contains these fields:

  • Pre-amble—Use to specify any bytes that are required at the start of each message that the driver transmits via this channel.

Ensure that the field is empty if no pre-amble is required.

  • Post-amble—Use to specify any bytes that are required at the end of each message that the driver transmits via this channel.

Ensure that the field is empty if no post-amble is required.

Where a Pre- and/or Post-Amble is required, specify that pre- or post-amble as a sequence of hexadecimal digits. Each pair of digits forms a byte in the pre- or post-amble. Ensure that the number and type of digits specified are suitable for both the protocol and type of communications media being used. (Hexadecimal format is base 16 and can include the digits 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, and F. Each digit is a nibble (half a byte), therefore you should always specify pairs of digits.)

Refer to the documentation supplied with your communications equipment for the number of bytes (pairs of digits) that you need to specify. The padding will probably be specified as a time—to ascertain the number of bytes that you need to specify to allow for the required padding time, you will need to Calculate the Time that a Channel Takes to Transmit each Byte of Data.

Refer to the driver- or product-specific documentation for information on any protocol-specific limitations or requirements.

ATTENTION: Some protocols require each message to begin with a particular sequence of bytes. Do not use such bytes as Pre- or Post-Amble padding. Refer to the driver- or product-specific documentation for further details.


Advanced Drivers Guide - Calculate the Time that a Channel Takes to Transmit each Byte of Data (Configuring a Channel)

Calculate the Time that a Channel Takes to Transmit each Byte of Data

Certain types of media, such as old analog radios, are prone to ‘clipping’ messages, therefore ‘padding’ is required to ensure that the actual message content is not clipped. The documentation supplied with your communications equipment should indicate the amount of ‘padding’ that is required. This is typically given as a time (in milliseconds)—you then use the channel’s port settings to calculate the number of bytes that you need to specify as a Pre- and/or Post-Amble, to allow for that amount of ‘padding’ time.

To ascertain the channel’s transmission rate in bytes per second, use the following formula:

<Baud Rate> / (<One Start Bit> + <Number of Data Bits> + <Parity> + <Number of Stop Bits>)

(where <Parity> is 0 if set to ‘None’, and 1 if set to any other option)

Then to ascertain the milliseconds per byte:

1000/<Result of above calculation>

Example 1:

ClearSCADA is to communicate with an outstation using analog radio. The radio needs 16ms to power up at the start of each transmission.

Using 8N1 1200 baud settings, a byte takes approximately 8.3ms to transmit, therefore a pre-amble of two bytes—four digits—is required as ‘padding’ at the start of each message, to allow the radio the 16ms that it requires to power up.

The Pre-Amble FFFF is used to allow the radio time to power up. This will delay the genuine content of each message by a maximum of 16.6ms.

(At 8N1 1200, the channel transmits 1200/(1 + 8 + 0 + 1) = 120 bytes per second. As such, it takes 1000/120 = 8.3ms to transmit each byte of data. Therefore two bytes—four digits—are required to pad the message by 16.6ms.)

Example 2:

ClearSCADA is to communicate with an outstation using a dial-up modem.

After some initial testing, it has been found that the phone line and modem combination sometimes corrupts the first few bytes of a transmission.

A Pre-Amble is used to ‘pad’ each transmission with a specified number of bytes, which are discarded by the receiving device.


Advanced Drivers Guide - Configuring an Outstation Set

Configuring an Outstation Set

An Outstation Set is a group of outstations that share direct channels. All of the outstations in a set communicate with the server using the same driver-specific protocol. For outstations that are permanently connected to the server, you need to configure one outstation set for each group of outstations that communicate via a particular channel or pair of channels.

You also need to configure outstation sets for those outstations that communicate using a dial-up modem. Typically, you group these outstations according to their geographical region, with a PSTN Outstation Set being added for each region. You may also need to organize the outstations according to how you want to dial the outstations, as One Shot, and Promote Dial Out actions can be applied to all outstations in a set (see Temporarily Increasing the Frequency with which an Outstation is Called).

Each advanced driver on ClearSCADA supports one or more of these types of outstation set:

  • Direct—Direct outstation sets contain outstations that are connected to the master station via a direct link, for example, a cable or network (see Direct Outstations). The outstation set determines which direct channel is used to contact the ClearSCADA server (see Defining the Channel for a Direct Set).
  • Switched—Switched outstations sets contain outstations that communicate with the master station via one of two telemetry channels (see Switched Dual Channel). All of the outstations use the same channel at the same time. Specify the channels on the Outstation Set Form (see Defining Channel Settings for a Switched Set).

The server determines which channel is used by the outstations in the set.

  • Shared—Shared outstation sets contain outstations that communicate with the master station on either of two telemetry channels. Each outstation can use either channel A or channel B (see Shared Outstations). Specify the channels on the Outstation Set Form (see Defining Channel Settings for a Shared Set).
  • PSTN—PSTN outstation sets contain outstations that communicate with the master station via a dial-up modem (see PSTN Outstations and Communications). Specify the basic communication settings for a PSTN set using the Outstation Set Form (see Defining Communication Settings).

Refer to the driver-specific documentation for the types of set that are supported by individual drivers.

Use the fields on the appropriate Outstation Set Form to configure the sets on your system. The Form has several tabs (see Tabs on Outstation Set Forms).

Further Information

Outstation Types and Communications Set-ups.

Preparation.

Minimum Configuration.


Advanced Drivers Guide - Preparation (Configuring an Outstation Set)

Preparation

Before you can successfully configure an Outstation Set (other than PSTN), you need to have configured the channels that the outstations in the set are to use (see Configuring a Channel).

In order to do this, you need to be aware of the hardware setup on your system, as you need to configure the type(s) of set that correspond to your hardware setup. Therefore, you need to be aware of the type of communications used by the outstations in your system, and the channel(s) that those outstations use.

Configure your outstation sets to correspond to the communications structure of your system hardware.


Advanced Drivers Guide - Tabs on Outstation Set Forms (Configuring an Outstation Set)

Tabs on Outstation Set Forms

You configure the settings for each Outstation Set using the fields on the appropriate Outstation Set Form.

Each Form has several ‘tabs’ for configuring different aspects of Outstation Set information. For sets on advanced drivers, a combination of these tabs is available:

  • Identification—Use to optionally define a Help View and to indicate whether the set is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for a set (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Outstation Set—Use for Defining Communication Settings, including:
  • Whether the set is functional.
  • The severity of any events that are generated by the set.
  • Whether you can perform a promoted dial out in order to promote outstation scanning under certain circumstances. (For non-PSTN sets, the ability to promote dial out, if enabled, only applies whenever the outstation falls back to use PSTN communications.)
  • For non-PSTN sets, the channels that are used by the outstations in the set. For further information, see as appropriate:
  • Defining the Channel for a Direct Set
  • Defining Channel Settings for a Switched Set
  • Defining Channel Settings for a Shared Set.
  • <Set Type>—An additional tab available on some sets. Use the fields on the tab to define further type-specific information for a set (see the driver-specific documentation).

This section explains the features on the Outstation Set tab that are common to sets on most advanced drivers.

For aspects of outstation set configuration that are common to most types of database item, see the ClearSCADA Guide to Core Configuration.

For aspects of outstation set configuration that are specific to individual drivers, including fields on any additional tabs, see the ClearSCADA driver-specific documentation.


Advanced Drivers Guide - Minimum Configuration (Configuring an Outstation Set)

Minimum Configuration

For a set to be functional, as a minimum you have to specify the channel(s) that a non-PSTN set uses, then put the set In Service, and save the configuration.


Advanced Drivers Guide - Defining Communication Settings (Configuring an Outstation Set)

Defining Communication Settings

Use the fields at the top the Outstation Set tab on the appropriate Outstation Set Form to define the basic communication settings for a set.

Use the Promote Dial Out field to specify whether operators can promote all of the outstations in a PSTN set, or all of the outstations that are using PSTN fallback in a set. While promoted, ClearSCADA dials the outstations at a rapid rate in order to retrieve data at more frequent intervals than usual.

  • In Service—Use to specify whether the set is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Event Severity—Use the combo box to specify the priority of any events that are associated with the set (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Outstation Set tab. Use the field to specify the area with which any of the set’s events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Promote Dial Out—Select this check box if you want to give operators the option of retrieving data from outstations in this set at more frequent intervals than usual, should circumstances require it. This function is known as ‘promoted dial-out’. When a set is promoted, the ClearSCADA database can be updated more regularly at specific times (see Temporarily Increasing the Frequency with which an Outstation is Called).

In the water industry, for example, Promoted Dial Out it is used to allow the outstations to report every fifteen minutes for four hours during a flood.

With this feature enabled, operators can select the Promote Dial Out pick action for the set. The interval and duration for the promotion are specified in the window that is displayed when the pick action is selected. All outstations in the PSTN set, or all outstations that are using PSTN fallback in the non-PSTN set, are promoted when the option is selected. Promotion can be manually canceled using the Cancel Promoted Scanning pick action.


Advanced Drivers Guide - Defining the Channel for a Direct Set (Configuring an Outstation Set)

Defining the Channel for a Direct Set

For a Direct Set you need to specify the channel that outstations on the set use to communicate with the ClearSCADA server. Specify the required channel using the Channel field on the Outstation Set tab:

  • Channel—Specify an appropriate channel for the outstations in the set. The set and channel must be of the same type, for example, if you were configuring a DNP3 Direct Outstation Set, you would attach the set to a DNP3 Direct Channel.

The channel is used by all of the outstations that are associated with the set, and represents an uninterrupted communications connection with the outstations.

Use the browse button to display a Reference browse window, and choose an appropriate channel. The filters on the Reference browse window constrain the entries to channels of the appropriate type.

Further Information

Using a Single Channel Communications Set-up: see Direct - Single Channel.


Advanced Drivers Guide - Defining Channel Settings for a Switched Set (Configuring an Outstation Set)

Defining Channel Settings for a Switched Set

For a Switched Outstation Set you need to define the channels that the set uses to communicate with the ClearSCADA server, and when and where any automatic channel switching should occur.

Specify these requirements using the fields in the Channels section of the Outstation Set tab:

  • Line A and Line B—Specify two appropriate channels for the outstations in the set. The set and channels must be of the same type, for example, if you were configuring a DNP3 Switched Outstation Set, you would attach the set to two DNP3 Direct Channels.

Each channel, or line, represents an uninterrupted communications connection with the outstations. At any given time, all of the outstations in the set communicate using the same channel.

Use the browse button adjacent to each Line field to display a Reference browse window, and select an appropriate channel. The filters on the Reference browse window constrain the entries to channels of the appropriate type.

You cannot specify the same channel more than once for the same set, nor can you allocate a channel to more than one set.

  • Preferred Line—When a ClearSCADA system starts up, it automatically attempts to establish outstation communications using the channel that was in use when the system was last shut down. If the previously used channel cannot be used, ClearSCADA uses the preferred channel instead.

Use the combo box to specify which channel (A or B) is the preferred channel.

  • Location—Use the combo box to specify where the outstations are switched between channels. You need to select an option that corresponds to the hardware setup. If an incorrect location is specified, switching may take longer than required.

Choose from:

  • Master Station—The switch is located at the master station. With this option, ClearSCADA does not send a communications termination request to each outstation when a switch occurs.
  • Outstation—Only select this option if suitable hardware and a switch are installed at the outstation. ClearSCADA sends a communications termination request to each outstation within the outstation set when a switch occurs.

See the driver-specific documentation for details on which switch locations are supported by your outstations.

  • Switched after n outstations have failed—Specify how many outstations ClearSCADA has to detect as having failed in the set, before the server automatically switches lines. Following the line switch, the server attempts to re-establish communications with each of the outstations in the set.

Enter 0 for automatic switching to occur only if ClearSCADA detects that all of the outstations have failed in the set.

To disable the automatic switching feature, enter a number greater than the total number of outstations in the set. Switching of lines can still be performed manually, using the Switch Line pick action.

If the channel that a set is currently using fails, the server will switch all of the outstations in that set to the other channel immediately, regardless of the number that is specified in the Switched after n outstations have failed field. (The exception to this is if the other channel was in a failed state the last time that it was used by the outstations. In such a situation, you need to use the Switch Line pick action—perhaps incorporated into a suitable Structured Text Program—to switch the outstations to the other channel. For more information, see Switched Dual Channel.)

Further Information

Using a Switched Dual Channel Communications Set-up: see Switched Dual Channel.


Advanced Drivers Guide - Defining Channel Settings for a Shared Set (Configuring an Outstation Set)

Defining Channel Settings for a Shared Set

For a Shared Outstation Set you need to define the channels that the set uses to communicate with the ClearSCADA server, and a delay for any automatic channel switching.

Specify these requirements using the fields in the Channels section of the Outstation Set tab:

  • Line A and Line B—Specify two appropriate channels for the outstations in the set. The set and channels must be of the same type, for example, if you were configuring a DNP3 Shared Outstation Set, you would attach the set to two DNP3 Direct Channels.

Each channel, or line, represents an uninterrupted communications connection with the outstations.

The way in which each outstation in the set can communicate using the channels depends on the outstations’ Switch Type (configured on the Shared Outstation Form—see Define a Shared Outstation’s Switching Capabilities). The Switch Type defines whether individual outstations can switch channels independently, as a group, or whether outstations are fixed to communicate using only one of the channels.

Use the browse button adjacent to each Line field to display a Reference browse window, and select an appropriate channel. The filters on the Reference browse window constrain the entries to channels of the appropriate type.

You cannot specify the same channel more than once for the same set, nor can you allocate a channel to more than one set.

  • Wait n seconds between switching each outstation—Specify a delay between switching each outstation from one channel to another. The delay reduces the load on the ClearSCADA server when multiple outstations are switched at the same time, as the server staggers the switching by the specified delay time.

Example:

For example, if you were to enter ‘10’ in this field, the first outstation would switch channels after 10 seconds, the second after 20 seconds, and the third after 30 seconds, and so on.

  • Interleave—Select this check box if you want to ‘interleave’ transmissions on the two channels. With interleaved channels, only one of the two channels can be in use at any time, allowing both channels to use the same radio frequency.

Ensure that the check box is clear if the two channels operate independently to each other.

Further Information

Using a Shared Channel Communications Set-up: see Shared Outstations.


Advanced Drivers Guide - Configuring an Outstation

Configuring an Outstation

An Outstation, or Remote Terminal Unit (RTU), gathers data from, and send commands to, plant. This plant is represented by points in the ClearSCADA database.

Some drivers support third-party devices other than outstations, such as data loggers. These devices perform some of the functions of an outstation. For the purpose of this guide, these devices are also referred to globally as ‘outstation’.

ClearSCADA can process various forms of data from an outstation, depending on the type of data that the outstation supports. For example, many outstations support current data—the present state or value of a point when the ClearSCADA server requests current data from the outstation. Many outstations also support logged data—time stamped data that is stored in the outstation.

Outstations communicate with the ClearSCADA server using one of two types of connection:

  • Direct—Direct outstations communicate with the ClearSCADA server using a permanent connection, such as a cable or network. Direct outstations may be in Direct, Shared, or Switched outstation sets, depending what the outstation type supports (see Direct Outstations).

The ClearSCADA server retrieves data from direct outstations using timed scans. Where a Direct outstation has a large amount of logged data, several scans may be required to retrieve the data.

Where supported by the outstation type, operators with the required privileges can send commands to the outstation to, for example, control plant, or retrieve data.

For further information, see Scanning Direct Outstations, and refer to the driver-specific documentation for the types of outstation and communication that are supported by individual drivers.

  • PSTN—PSTN outstations communicate with the ClearSCADA server using a telephone line (see PSTN Outstations and Communications). This type of outstation is not in continuous contact with the server. Instead, the circumstances surrounding when the server and outstation are in contact differs depending on the type of outstation, but may include:
  • When an alarm is raised on the outstation—The outstation dials in to report an alarm. On some types of outstation, you can inhibit dial-ins using a Disable Dial In pick action.
  • A Scheduled One Shot—The server dials out to the outstation to retrieve its data on a scheduled basis, for example once a day.
  • An operator initiates a One Shot or Open Line call—The server dials out to the outstation and retrieves its data.
  • An operator initiates a Promoted Dial Out—The server dials out to the outstation to retrieve its data at a more frequent rate than usual, for the length of the promotion period.

Where a PSTN outstation has a very large amount of logged data, more than one call may be required in order to retrieve the logged data.

Where supported by the outstation type, operators with the required privileges can send other commands to the outstation to, for example, control plant, or extend a call to retrieve further data.

Some direct outstations can use PSTN as a fallback means of communication should ClearSCADA detect that the direct connection has failed (see Direct - PSTN Fallback). To use PSTN fallback, an outstation has to have a dial-up modem. Additionally, at least one PSTN Channel for the same driver and with the same Connection Type as the outstation, has to exist in the ClearSCADA database (see PSTN Connection Types).

For further information on PSTN outstations, see Retrieving Data from PSTN Outstations, and refer to the driver-specific documentation for the types of outstation and communication that are supported by individual drivers.

Use the fields on the appropriate Outstation Form to configure the properties of each outstation on your system. The Form has several tabs (see Tabs on Outstation Forms).

NOTE: If required, a Queue feature can be enabled on your system to allow users to optionally queue certain pick action requests on PSTN and ‘On Demand’ outstations. For more information, see Define whether the Queue Parameter is Available in the ClearSCADA Guide to Server Administration, and see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations in the ClearSCADA Guide to Drivers.

Further Information

Outstation Types and Communications Set-ups.

Preparation.


Advanced Drivers Guide - Preparation (Configuring an Outstation)

Preparation

Before you can successfully configure an outstation, you need to have configured:

  • One or more Channels of the appropriate type (see Configuring a Channel).
  • An Outstation Set (see Configuring an Outstation Set).

You will need access to information about the configuration of the outstation hardware, including the type of communications connection and the telephone number of the site at which the outstation is located. This information is typically recorded by the engineer that sets up the outstation hardware.

You also need an understanding of the configuration in the ClearSCADA database—you need to know which channels and outstation sets relate to the outstation that you are configuring. You need to be aware of the significance of the outstation’s alarms and events in relation to the entire system—this will determine the priority that you allocate to the outstation.

If you are configuring a PSTN outstation’s call properties, ensure that you are aware of the call requirements of the telephone service provider—there may be regulations regarding the period of time between calls to the same number.

If you do not have access to the required information, please contact a system administrator.


Advanced Drivers Guide - Tabs on Outstation Forms (Configuring an Outstation)

Tabs on Outstation Forms

Outstation Forms have several ‘tabs’ or ‘pages’ for configuring different aspects of outstation information. Most outstations on advanced drivers have a combination of these tabs:

  • Identification—Use to optionally define a Help View and to indicate whether the outstation is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for the outstation (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with any outstation alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the outstation (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • Outstation—Use the fields on this tab to:
  • Define the Basic Outstation Properties
  • Specify the Availability of Communications Between the Outstation and ClearSCADA
  • Specify the Properties of any Outstation Alarms and Events.
  • Network—Available for network connected outstations that use a permanent connection, rather than PSTN to communicate with the server.

Use to define the type of network (see Define an Outstation’s Network Properties).

  • PSTN—Available for outstations that communicate with the server using PSTN, or PSTN as a fallback means of communication (see PSTN Outstations and Communications).

Use to define the Public Switched Telephone Network properties of the outstation (see Define an Outstation’s PSTN Properties, and see Define Dial In Line Properties on a PSTN Outstation). If supported and required, also use the tab for Define Dial In Overactive Properties on a PSTN Outstation.

  • Shared—Available for outstations that communicate with the server using one of two channels. Each outstation in a Shared set can use either channel (see Shared Outstations). Use the fields on the Shared tab to Define an Outstation’s Shared Properties.
  • <Outstation Type>—Use to define any further type-specific information for an outstation (see the driver-specific documentation).

For some types of outstation, the <Outstation Type> tab includes fields that allow you to Define Whether an Outstation is Promoted While its Points are on Display and/or Define any Pre- and Post-Ambles for an Individual Outstation.

In addition, other driver-specific tabs are available for some types of outstation (see the driver-specific documentation).

This chapter explains the features on the Outstation, Network, PSTN, and Shared tabs that are common to outstations on most advanced drivers.

For aspects of outstation configuration that are common to most types of database item, see the ClearSCADA Guide to Core Configuration.

For aspects of outstation configuration that are specific to individual drivers, see the ClearSCADA driver-specific documentation.


Advanced Drivers Guide - Define the Basic Outstation Properties (Configuring an Outstation)

Define the Basic Outstation Properties

Use the fields at the top of the Outstation tab, on the appropriate Outstation Form, to specify the basic outstation properties:

  • In Service—Use to specify whether the outstation is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).

NOTE: If you take an outstation out of service, its dependants (such as points, and pulse actions) become out of service.

  • Outstation Set—Use this field to associate the outstation with an appropriate outstation set. The set must include outstations of the same type (protocol), and should reflect the plant layout. For example, in a Direct set, the outstations in the set are multi-dropped off the same channel—if you were configuring a DNP3 Direct outstation, you would attach the outstation to a DNP3 Direct, DNP3 Shared, or DNP3 Switched Outstation Set, depending on your system setup.

Use the browse button to display a Reference browse window, and choose an appropriate outstation set. The filters on the Reference browse window will constrain the entries to sets of the appropriate type.

  • Duty—This check box applies to Duty Duty systems only (see Enable or Disable Duty Mode in the ClearSCADA Guide to Server Administration). Select the Duty Duty check box if you want the Standby server to update the Main server following a Main-Main situation. The Standby server only updates the Main server with any data that is more recent than the data that is already on the Main server.

Ensure that the Duty Duty check box is clear if the Standby server is not to update the Main server following a Main-Main situation. The Main server is still able to update the Standby server once communications between the servers is restored. This means that the data recorded by the Standby server while the servers were in a Main-Main state is lost.

Use the rest of the fields on the Outstation tab to:

  • Specify the Availability of Communications Between the Outstation and ClearSCADA
  • Specify the Properties of any Outstation Alarms and Events.


Advanced Drivers Guide - Specify the Availability of Communications Between the Outstation and ClearSCADA (Configuring an Outstation)

Specify the Availability of Communications Between the Outstation and ClearSCADA

Use the fields within the Communications Availability section of the Outstation tab to specify when communications with the outstation is available:

  • Available—Use this combo box to specify the communications that exists between ClearSCADA and the outstation. Choose from:
  • Always—The default for most types of outstation. ClearSCADA is able to instigate communications with the outstation whenever required. Select this option, for example, if ClearSCADA is to instigate communicates with the outstation in order to retrieve the outstation’s data or send commands.
  • Never—ClearSCADA does not communicate with the outstation directly, but uploads the outstation data from another source, such as data files on disk. Select this option, for example, if the outstation data is to be uploaded into ClearSCADA using a File Upload. For more information on File Uploads, see Configuring a File Upload. For information on which drivers support File Uploads, see the driver-specific documentation.
  • Incoming Only—All communications between ClearSCADA and the outstation is instigated by the outstation. Select this option if the connection made between a network-connected outstation and ClearSCADA is always inbound, or if a PSTN outstation support incoming calls only. In either case, the available communications mean that ClearSCADA is unable to call and/or initiate a connection to the outstation. Instead, ClearSCADA has to wait for the outstation to dial in or connect to the server in order to communicate with the outstation.

With a network-connected outstation, the outstation’s network channel(s) have to be configured with a Listen Port, to accept inbound connections from the outstation (see Configure a Channel’s Network Connection Properties in the ClearSCADA Guide to Drivers). The properties on the outstation’s Network tab have to be configured specifically for Incoming Only outstation-instigated communications (see Define an Outstation’s Network Properties).

With a PSTN outstation, the outstation has to have at least one Local Dial In Line configured on the PSTN tab, to enable the outstation to call ClearSCADA (see Define Dial In Line Properties on a PSTN Outstation). (If any outgoing PSTN channels are available, ClearSCADA will not use those channels to call an outstation for which the Communications Availability is set to Incoming Only.)

  • Periodic—Communications between ClearSCADA and the outstation is only available periodically. Select this option, for example, if the outstation is battery-powered and only powers up at certain times of the day. Use the rest of the fields in the Communications Availability section to specify when communications is available.
  • Offset—Only applies if communications is Periodic. Specify the offset from midnight UTC to when communications is first available each day.
  • Duration—Only applies if communications is Periodic. Specify the length of time for which communications between the outstation and ClearSCADA is available during each period.
  • Interval—Only applies if communications is Periodic. Specify the length of time between each period of communications availability.

In the Offset, Duration, and Interval fields above, specify the time in the OPC Time Format. You can enter the time directly in each field, or use the Interval Window (accessed via each field’s browse button) to specify the required value.

NOTE: With some types of outstation, ClearSCADA will automatically queue certain pick action requests until it is next in communications with the outstation. With other types of outstation, you can enable a Queue feature on your system to enable users to optionally queue certain pick action requests on those outstations. For more information, see Define whether the Queue Parameter is Available in the ClearSCADA Guide to Server Administration, and see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations in the ClearSCADA Guide to Drivers.


Advanced Drivers Guide - Specify the Properties of any Outstation Alarms and Events (Configuring an Outstation)

Specify the Properties of any Outstation Alarms and Events

Use the fields within the Alarm/Event Logging section of the Outstation tab to specify the properties of any alarms or events that are associated with the outstation:

  • Severity—Use this combo box to define the priority of any alarms or events that are associated with the outstation (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed within the Alarm/Event Logging section on the Outstation tab. Use the field to specify the area with which any of the outstation’s alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Channel Alarms—Select this check box to raise an alarm for the outstation as well as the channel, if ClearSCADA detects that all of the channels that the outstation can use have failed.

Leave the box clear if ClearSCADA is not to raise an alarm for the outstation if it detects that all of the outstation’s channels have failed.

Examples:

The Channel Alarms check box is selected for each of 10 direct outstations that communicate via a single channel. ClearSCADA detects that the channel has failed. This results in ClearSCADA raising alarms for each outstation and for the channel, in addition to events stating that communications have failed on each outstation.

The Channel Alarms check box is left clear for each of 20 direct outstations in a Switched set. The outstations communicate via either of two channels. ClearSCADA detects that both channels have failed. This results in ClearSCADA raising alarms for each failed channel, and logging events to indicate that communications have failed on each outstation. An ‘avalanche’ of 20 outstation alarms is avoided due to the Channel Alarms feature being left clear.


Advanced Drivers Guide - Define an Outstation's Network Properties (Configuring an Outstation)

Define an Outstation’s Network Properties

If a device on your system uses network connected channel(s) to communicate with the server, use the fields on the Network tab of the associated Outstation Form to define that outstation’s network properties.

The following fields are displayed for network connected outstations on many advanced drivers.

Depending on the system setup, network connected outstations might be connected to a single or dual network.

  • Network—Specify the type of network. The option you choose depends on the outstation set configuration:
  • Single Network—For an outstation that is in a Direct set.
  • Dual Network—For an outstation that is in a Switched or Shared set, and is therefore connected to two networks. If you choose this option, two sets of Host Address and Port fields become available for configuration, one for Network A and one for Network B.
  • Host Address—On a single network system, enter the IP address of the outstation, or the node name (if supported). On a dual network system, you have to enter the IP address.

If an outstation’s Communications Availability is Incoming Only, the Host Address field can be left blank as any address is ignored (see Specify the Availability of Communications Between the Outstation and ClearSCADA).

  • Port—Enter the port number that is used by the outstation. On some protocols, specific port numbers are registered with the IANA (Internet Assigned Numbers Authority). The driver-specific documentation lists any registered port numbers.

Specify 0 (zero) if an outstation’s Communications Availability is Incoming Only, as the outstation will not be listening for connections (see Specify the Availability of Communications Between the Outstation and ClearSCADA).


Advanced Drivers Guide - Define an Outstation's PSTN Properties (Configuring an Outstation)

Define an Outstation’s PSTN Properties

If a device on your system uses PSTN to communicate with the server, or uses PSTN as a fallback means of communicating with the server, use the fields on the PSTN tab of the associated Outstation Form to define that outstation’s PSTN properties.

In order for a direct outstation to use PSTN fallback, that outstation has to have a dial-up modem. Additionally, at least one PSTN Channel for the same driver and with the same Connection Type as the outstation, has to exist in the ClearSCADA database.

The default settings for the fields on the PSTN tab are shown in the window below.

The following list describes many of the properties on the PSTN tab. For information on the Dial In Overactive properties, you should refer to Define Dial In Overactive Properties on a PSTN Outstation and for information on the Dial In Lines properties, see Define Dial In Line Properties on a PSTN Outstation. For fields that are not described in any of these sections, see the driver-specific documentation.

  • Enabled—Only displayed if an outstation can be configured to use PSTN as a fallback means of communicating with the server. ClearSCADA communicates with the outstation via a dial-up modem whenever it detects that the outstation’s direct channels have failed.

To enable PSTN fallback, select the check box so that it displays a check mark. Leave the check box clear if an outstation does not have PSTN fallback.

  • Connection Type—Use the combo box to choose the type of PSTN communications used by the outstation:
  • Standard Modem—For PSTN outstations that communicate via a Hayes compatible dial-up modem.

Other options may be available if they have been configured on the server (see PSTN Connection Types).

  • Telephone Number—Enter the telephone number of the site on which the outstation is located.
  • Retries—Enter the number of times that the ClearSCADA server will attempt to request data from the outstation (dial out to the outstation).

If the outstation does not respond to the ClearSCADA server’s initial data request, the server makes a further request (referred to as a ‘retry’). The server can repeat a data request up to the defined number of Retries.

The initial request and the retries are sent via the PSTN channel with either the least number of calls or the highest percentage of good calls (depending on the setting on the ClearSCADA Server window—see Define how a PSTN Channel is Selected for Communications in ClearSCADA Guide to Server Administration).

If the outstation does not report its data within the defined number of Retries, the ClearSCADA server will regard the outstation as having failed.

The default setting of 2 is suitable for most systems.

  • Timeout—Enter the number of seconds that the ClearSCADA server will wait before attempting a ‘retry’. This delay is a requirement of some telephone service providers. It also helps to ensure that a retry does not occur immediately (an immediate retry is likely to be unsuccessful for the same reason as the previous attempt).

Enter the duration in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required time.

The default setting of 30 seconds is suitable for most systems, but there may be a regulatory requirement for a different amount—for more information, please contact your telephone service provider.

  • Maximum Call Length—Specify the maximum duration of a telephone call. This defines the longest amount of time that the line between the ClearSCADA server and the outstation can be open. Set the duration to a suitable length of time to prevent the line staying online.

Enter the duration in the OPC Time Format, for example, 10M for 10 minutes. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required time.

With a One Shot call, ClearSCADA ends the call as soon as it has retrieved the outstation’s data, or once the Maximum Call Length is reached, whichever occurs first.

With an Open Line call, the line remains open for the Maximum Call Length, even if ClearSCADA has retrieved the outstation’s data before that length of time is reached.

With either type of call, if the call is incomplete when the Maximum Call Length time is reached, the call is terminated and any remaining data is not retrieved until the next call. However, if supported by the outstation type, operators can use the Extend Line pick action to reset a call that is still in progress. The Extend Line pick action re-applies the Maximum Call Length from the instant that the Extend Line pick action is executed. For example, if the Maximum Call Length is 15 minutes, an Open Line call will last 15 minutes. However, if 8 minutes into the call the Extend Line pick action is used to extend that call, the call will then last a further 15 minutes, resulting in a total call length of 23 minutes (8 minutes of original call, plus 15 minutes call extension).

Suitable default call lengths are provided on per driver basis.

  • Promote Dial Out—Select this check box if you want to give operators the option of retrieving data from an individual outstation at more frequent intervals than usual. When an outstation is ‘promoted’ in this way, the ClearSCADA database can be updated more regularly at specific times.

For example, in the water industry, Promoted Dial Out it is used to allow the outstations to report every fifteen minutes for four hours during a flood.

With this feature enabled, operators can select the Promote Dial Out pick action for the outstation. The interval and duration for the promotion are specified in the window that is displayed when the pick action is selected. Promotion can be manually canceled using the Cancel Promoted Dial Out pick action.

(The default offset, interval, and duration for promoted dial outs is specified using the ClearSCADA Server Configuration Tool—see Define the Default Promoted Dial Out Settings in the ClearSCADA Guide to Server Administration.)

NOTE: To enable all of the outstations in a set to be promoted at the same time, use the Promote Dial Out feature on the Outstation Set Form (see Defining Communication Settings), rather than the Outstation Form. Operators will then be able to use the Promote Dial Out pick action for the set, as opposed to just individual outstations.

When supported by the type of driver, these fields are also displayed on the PSTN tab:

  • Callback—Displayed when supported by the type of driver.

The Callback feature provides a means of testing the outstation’s dial in functionality. It works by allowing an operator to send a Callback message to the outstation, which causes the outstation to report (dial in) to the ClearSCADA server.

An alarm is raised if the ClearSCADA server does not receive a report from the outstation within the defined Callback period (as defined in the driver-specific section of the ClearSCADA Server Configuration Tool—see the driver-specific documentation for details).

By using the Callback feature, operators can check that the outstation can dial in during those periods when the outstation has not dialled in for some time.

Choose from:

  • None—The Callback feature is disabled for the outstation.
  • Via PSTN—The feature is enabled and the Callback pick action for the outstation is available to operators—they will be able to perform a Callback test to check that the outstation can dial in.

When the action is activated, the ClearSCADA server calls the outstation, sends the message, and then ends the call. The server than waits for the PSTN outstation to dial in to the server.

Further options are available for direct outstations that are configured to use PSTN as a fallback means of communication:

  • Via Multidrop—Operators can only send a callback request when the outstation is using multi-drop communications.
  • Via Multidrop/PSTN—Operators can send a callback request regardless of whether the outstation is in multi-drop communications, or has fallen back to use PSTN.
  • Always via PSTN—Used to test outstation communications in both directions, when an outstation is normally in multi-drop mode. When an operator initiates a call back, the server stops multi-drop communications and makes the call via PSTN. Multi-drop comms starts only when the outstation dials in and the call back is successful, or when the call back times out and is deemed to have failed. (The Callback period is defined in the driver-specific section of the ClearSCADA Server Configuration Tool—see the driver-specific documentation for details.).
  • Download Configuration via PSTN—Displayed for outstations that support configuration downloads and PSTN fallback. (The field is ‘grayed out’ on PSTN-only outstations.)

Select this check box if ClearSCADA is to download configuration to the outstation via PSTN (if a suitable telephone line is available), rather than via the outstation’s direct communications channel(s). If all PSTN channels (telephone lines) are busy, the driver will wait until one of those lines can be used. Select the check box if PSTN communications is, for example, a quicker or more robust means of communicating with the outstation. The driver will download configuration via PSTN in response to both user-initiated download requests (via the Download Configuration pick action) and download configuration requests from the outstation. The outstation reverts to using direct channel communications once a download is complete.

Ensure that the check box is clear if ClearSCADA is to download configuration via the outstation’s direct communications channel(s), in preference to PSTN.

Further Information

PSTN Outstations and Communications.

Using PSTN Fallback: see Direct - PSTN Fallback.

Define Dial In Line Properties on a PSTN Outstation.

Define Dial In Overactive Properties on a PSTN Outstation.

NOTE: If required, a Queue feature can be enabled on your system to allow users to optionally queue certain pick action requests on PSTN outstations. For more information, see Define whether the Queue Parameter is Available in the ClearSCADA Guide to Server Administration, and see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations in the ClearSCADA Guide to Drivers.


Advanced Drivers Guide - Define Dial In Line Properties on a PSTN Outstation (Configuring an Outstation)

Define Dial In Line Properties on a PSTN Outstation

Some PSTN outstations can use a number of PSTN channels to report alarm data to the ClearSCADA server. These channels are referred to as dial in channels as they are used when the outstation ‘dials in’ to the ClearSCADA server. The number of channels varies depending on the outstation type.

Use the fields on the PSTN tab of the associated Outstation Form to define the required Dial In properties. By default, the information in these fields is not set up when you first configure a new outstation.

The following Dial In Lines fields are displayed for outstations on many advanced drivers. For other common PSTN fields, see Define an Outstation’s PSTN Properties, and see Define Dial In Overactive Properties on a PSTN Outstation. For fields that are not described in any of these sections, see the driver-specific documentation.

  • Prefix Number—Use this field to specify any prefix that needs including at the start of any dial in numbers. Include a number in this field, for example, if the outstation is connected to a local telephone exchange and an additional number (such as 9) is required to dial an external line. The prefix is added to any downloaded dial in Telephone Numbers, and removed from any uploaded numbers.
  • Location—For each available line, use the Location combo box to define whether the line will be used by the outstation to contact the local ClearSCADA server, or another source:
  • Local—The channel is used to communicate with the ClearSCADA server that contains the configuration for the outstation (that is, the ClearSCADA server on which you are configuring the PSTN outstation).
  • Remote—The channel is used to communicate with another source, for example, a handset. The sources that are supported differ, depending on the type of outstation.

If you are defining a line with a Local location, proceed to the Channel field.

If you are defining a line with a Remote location, proceed to the Telephone Number field.

  • Channel—Only available for lines that are set to Local. Use the field to specify the PSTN channel that is to be used to communicate with the ClearSCADA server. Use the browse button to display a Reference browse window and choose the required channel. If you are unsure which channels are used, please contact a system administrator, or refer to the system design.

You can only specify a PSTN Channel that is configured as a Dial In Only, or Dial In and Out line (a channel that is configured as Dial Out Only is reserved for the ClearSCADA server to dial out to an outstation). You specify a channel’s Dial In/Out functionality using the PSTN tab on the Channel Form (see Defining PSTN Settings for a Channel).

If your system uses a ‘hunting’ telephone exchange or similar, whereby a pool of PSTN lines share the same telephone number, specify any one of those lines in this field. (The exchange can be local to the site or be provided by a telecoms provider.)

ClearSCADA monitors the channels that are listed in the Channel fields, along with their dial in and dial out properties. If using a ‘hunting exchange’, ClearSCADA also monitors any other channels that share the same telephone number as those listed. Such monitoring is used to determine the state of the outstation. Provided that the outstation is healthy, and at least one channel with dial in capability is available, the outstation will be able to dial in to ClearSCADA when required.

  • Telephone Number—Only available for lines that are set to Remote. Enter the telephone number of the remote source.

Example:

A particular ClearSCADA system has a number of PSTN lines. The properties of the lines, including their telephone numbers and dial in/out capability, are configured on the relevant PSTN Channel Forms:

(‘PSTN Channel C’ is a dedicated dial out line that the server can use to dial out to the outstations on the system.)

Several of the outstations on the system are able to dial in to ClearSCADA to report alarms. The properties on the PSTN tab of the relevant Outstation Forms are used to specify the PSTN line(s) that the outstations can use to dial in to ClearSCADA. The configuration of one of these outstations is as follows:

The ClearSCADA server monitors the status and dial in/out capability of its PSTN channels, to determine the communications status of each outstation. For the above PSTN outstation, when ClearSCADA is not actually communicating with, or attempting to establish communications with, the outstation via PSTN, the outstation’s status might be one of the following:
Channel Status | Outstation State | Comments
A, B, and C Healthy | Available | Channels A and B are available for dialing in to ClearSCADA. Channels A and C are available for dialing out.
A Failed, B and C Healthy | Available | Channel B is available for dialing in and channel C for dialing out.
B Failed, A and C Healthy | Available | Channel A is available for dialing in to ClearSCADA. Channels A and C are available for dialing out.
C Failed, A and B Healthy | Available | Channels A and B are available for dialing in to ClearSCADA. Channel A is available for dialing out.
A and B Failed, C Healthy | Available (Outgoing Only) | Channel C is available for dialing out.
A and C Failed, B Healthy | Available (Incoming Only) | Channel B is available for dialing in.
B and C Failed, A Healthy | Available | Channel A is available for dialing in or out.
A, B, and C Failed | All Channels Failed | No PSTN channels are available.

Further Information

Defining PSTN Settings for a Channel.


Advanced Drivers Guide - Define Dial In Overactive Properties on a PSTN Outstation (Configuring an Outstation)

Define Dial In Overactive Properties on a PSTN Outstation

The Dial In Overactive properties allow you to configure a PSTN outstation so that it raises an alarm or log an event if it is dials in excessively. The alarm or event indicates that the outstation is overactive and is dialing in too often. The reasons for the outstation dialing in include:

  • A high number of alarms being raised or cleared
  • A log (or buffer) filling or overflowing
  • Scheduled dial-ins configured to occur too often
  • Excessive use of the Callback feature
  • The outstation requires configuration.

Some of these conditions may be due to incorrect configuration at the outstation, for example, there may be a high number of alarms being raised because of poorly configured alarm limits (and other alarm limit related properties, such as Persistence).

For more information on the Dial In Overactive feature, see Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently.

Use the fields on the PSTN tab of the Outstation Form to define the required Dial In Overactive properties. The information in these fields is not set up by default when you first configure a new outstation.

The following Dial In Overactive fields are displayed for outstations on many advanced drivers:

  • Severity—Use the combo box to define the priority the alarms or events that are raised or logged as a result of the outstation dialing in too frequently (see Defining Severities in the ClearSCADA Guide to Core Configuration). If required, you can disable this feature by setting the Severity to None.
  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed in the Dial In Overactive section of the PSTN tab. Use the field to choose the area with which any of the outstation’s overactive dial in alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Number of Calls—Use to define the maximum number of calls in each dial in period. If the outstation dials in more than this amount during the defined time period, an alarm or event is logged. The alarm or event indicates that the outstation is dialing in too frequently. The time period is defined in the Interval and Offset fields.

The minimum amount for the Number of Calls setting is 1 (this is also the default setting for this property).

  • Interval—Specify the length of the dial in time period. Enter the interval in the OPC Time Format. The interval has to be greater than 1M (1 minute). The default setting is 1D (1 day). You can enter the value directly in the field or use the Interval Window (accessed via the field’s browse button) to specify the required interval.

Example:

An outstation’s Dial In Overactive configuration includes these settings:

Number of Calls: 5

Interval: 1D (one day)

The 1 day Interval specifies that ClearSCADA is to measure the total number of dial ins that the outstation makes in each 24-hour period.

The Number of Calls defines the maximum number of times that the outstation is expected to dial in within each 24-hour period.

The outstation dials in 4 times in 1 day. This is less than the expected maximum of 5 calls, so ClearSCADA does not generate an overactive dial in alarm or event.

The outstation dials in 8 times on another day. ClearSCADA generates an overactive alarm or event for the 6th dial in. Each subsequent dial in causes the alarm or event to update with new information.

  • Offset—The offset is used to synchronize the overactive dial-in period. For example, if you set the Offset to 6H, the start time of the dial in time period is 06:00am. So, if the Interval is 1D (1 Day), the day will begin at 06:00am and end at 06:00am the next day. The following day will start at 06:00am and end at 06:00am the next day and so on.

Enter the offset in the OPC Time Format, for example 30M for a 30 minute offset. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required offset.

The default offset setting is 0 (midnight on the first day of the week). You can enter an offset using minutes, hours, days or weeks as the time unit.

The time to which the offset is applied is defined by the Time Zone setting in the server configuration (see Define the Time Zone for the Dial In Overactive Feature in the ClearSCADA Guide to Server Administration).

ClearSCADA automatically clears any Overactive Dial In alarms at the end of each defined time period.

Further Information

Configuring an Outstation to Raise an Alarm if it Dials In Too Frequently.

Define an Outstation’s PSTN Properties.

Define Dial In Line Properties on a PSTN Outstation.


Advanced Drivers Guide - Define an Outstation's Shared Properties (Configuring an Outstation)

Define an Outstation’s Shared Properties

The Outstation Form for Shared outstations includes a Shared tab.

Shared outstations communicate with the ClearSCADA server using one of two direct channels (see Shared Outstations). The channels are referred to as Line A and Line B. You define which channels you want to use as Line A and Line B, using fields on the Outstation Set tab of the relevant Outstation Set Form (see Defining Channel Settings for a Shared Set).

Use the fields on the Shared tab of the Shared Outstation Form to:

  • Define a Shared Outstation’s Switching Capabilities
  • Define an Independently Switching Outstation’s Preferred Channel
  • Specify the Network-Connected Channels on Which the Driver Acknowledges Inbound Connections
  • Poll Outstations on the Other Channel
  • Hunt for a Healthy Line if ClearSCADA Detects that both Lines have Failed
  • Define Group Slave Properties.

For any Shared outstation fields not described in the above sections, see the driver-specific documentation.


Advanced Drivers Guide - Define a Shared Outstation's Switching Capabilities (Configuring an Outstation)

Define a Shared Outstation’s Switching Capabilities

Use the Switch Type combo box on the Shared tab to specify whether an outstation can switch between channels.

Choose from:

  • Independent—The outstation can switch independently to either channel (see Communications via Either Channel). If you select this option, use the Preferred Line combo box to specify which of the two channels you would prefer the outstation to use for communications with the server (see Define an Independently Switching Outstation’s Preferred Channel).

With Independent switching, other fields on the tab also become available for use. The fields allow you to specify whether ClearSCADA is to either:

  • Poll Outstations on the Other Channel

or:

  • Hunt for a Healthy Line if ClearSCADA Detects that both Lines have Failed.

Additionally, if the outstation uses network-connected channels, you can specify how the driver handles inbound connections on those channels (see Specify the Network-Connected Channels on Which the Driver Acknowledges Inbound Connections).

  • Fixed on Line A—The outstation is only connected to Line A, which is its only means of communication with the server (see Communications Fixed on Line A or Fixed on Line B).
  • Fixed on Line B—The outstation is only connected to Line B, which is its only means of communication with the server (see Communications Fixed on Line A or Fixed on Line B).
  • Group Slave—The outstation is a Group Slave and another independent outstation has been designated as its Group Master. Each Group Slave uses the same channel as its Group Master. As such, whenever the Group Master switches channels, the Group Slave switches communications to the same channel as that Group Master (see Communications Determined by a Group Master).

Use the Group Slave section of the tab to Define Group Slave Properties.


Advanced Drivers Guide - Define an Independently Switching Outstation's Preferred Channel (Configuring an Outstation)

Define an Independently Switching Outstation’s Preferred Channel

This section applies to shared outstations on which the Switch Type is set to Independent (see Define a Shared Outstation’s Switching Capabilities).

Use the Preferred Line combo box toward the top of the Shared tab to define the channel that you would prefer the outstation to use for communications with the ClearSCADA server. The driver will use the selected channel in preference to the other channel that is assigned to the outstation’s Set, providing that the preferred channel is healthy and the Switch Line pick action has not been used to switch the outstation to the other (non-preferred) channel.

Use the combo box to select either the channel that is assigned to Line A on the Shared Outstation Set Form, or the channel that is assigned to Line B. Ideally you should assign an equal number of outstations to each channel, to distribute the outstations evenly between the two channels (see Communications via Either Channel).

The outstation set’s Balance status attribute indicates the percentage of outstations that are currently using each channel in the set. The attribute is shown on the outstation set’s Status display (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients).

Further Information

Define which channels are assigned to Line A and Line B: see Defining Channel Settings for a Shared Set.


Advanced Drivers Guide - Specify the Network-Connected Channels on Which the Driver Accepts Inbound Connections (Configuring an Outstation)

Specify the Network-Connected Channels on Which the Driver Accepts Inbound Connections

This section applies to shared outstations:

  • That use network-connected channels on a Dual Network, where those channels are each configured with a Listen Port, to accept inbound connections from the outstation (see Configure a Channel’s Network Connection Properties in the ClearSCADA Guide to Drivers)

and:

  • For which the outstation’s Switch Type is set to Independent (see Define a Shared Outstation’s Switching Capabilities).

Use the Network Connection combo box to specify on which line(s) ClearSCADA is to accept inbound network connections. (An inbound connection is attempted whenever the outstation tries to instigate communications with ClearSCADA, rather than vice versa.)

Choose from:

  • Accept Inbound Connections on Both Lines—ClearSCADA will accept inbound connections on either of the network-connected channels on which the outstation can communicate.

If the inbound connection occurs on the channel that is not currently assigned to the outstation, the driver will automatically switch the outstation (and any Group Slave outstations for which that outstation is Group Master) to the other channel (the one on which the inbound connection occurred). If heartbeat polling is used, this will also change channels, so that the server continues to send ‘heartbeats’ via the channel that is not being used by the outstation.

  • Only Accept Inbound Connections on Current Line—ClearSCADA will only accept inbound connections on the network-connected channel that is currently assigned to the outstation.

Any attempt to connect to ClearSCADA via the channel that is not currently in use will be rejected.

With an Independent shared outstation, if the ClearSCADA Server Configuration Tool’s option to ‘Allow channels on a driver to share the same listen port’ is enabled:

  • ClearSCADA will accept inbound connections on the channel that is currently assigned to that outstation
  • ClearSCADA will accept inbound connections on the other channel that is assigned to the outstation set, providing that the outstation is configured to Accept Inbound Connections on Both Lines
  • If the outstation attempts to connect to ClearSCADA via a channel other than one that is assigned to the outstation set, ClearSCADA will route the connection to the channel that is currently assigned to the outstation.

(If the ‘Allow channels on a driver to share the same listen port’ option is disabled, any attempt to connect via a channel other than one that is assigned to the outstation set will be rejected. ClearSCADA will only accept inbound connections on the channel that is currently assigned to the outstation (unless the outstation is configured to Accept Inbound Connections on Both Lines).)

With an outstation that has a Switch Type other than ‘Independent’:

  • If the ‘Allow channels on a driver to share the same listen port’ option is enabled:
  • ClearSCADA will accept inbound connections on the channel that is currently assigned to that outstation
  • ClearSCADA will reject any attempt by the outstation to connect to ClearSCADA via the other channel that is assigned to the outstation set
  • If the outstation attempts to connect to ClearSCADA via a channel other than one that is assigned to the outstation set, ClearSCADA will route the connection to the channel that is currently assigned to the outstation.
  • If the ClearSCADA Server Configuration Tool’s option to ‘Allow channels on a driver to share the same listen port’ is disabled:
  • ClearSCADA will reject any attempt by that outstation to instigate communications via a network-connected channel other than the channel that is currently assigned to that outstation.

For information on the ‘Allow channels on a driver to share the same listen port’ option, see Define whether a Listen Port can be Shared in the ClearSCADA Guide to Server Administration.


Advanced Drivers Guide - Poll Outstations on the Other Channel (Configuring an Outstation)

Poll Outstations on the Other Channel

This section only applies to:

  • Shared outstations that can switch channels independently
  • Group Slave outstations that switch channels at the outstation rather than the Group Master

Providing that:

  • Both of the channels are completely separate to each other (with no commonality anywhere along the network and no possibility of messages being routed to both channels)
  • The driver and remote device support Heartbeat Polling. (The driver-specific documentation indicates whether the Shared outstations on a particular driver support Heartbeat polling.)

Heartbeat polling is used to monitor the state of the idle line to an outstation.

A ‘heartbeat’ is a request for a response from the outstation—no processing is performed on the response other than, for instance, to check the framing. ClearSCADA sends the ‘heartbeat' via the channel that the outstation is not currently using. For example, if an outstation’s current channel is B, ClearSCADA will send the heartbeat via channel A. The rate at which ClearSCADA sends heartbeat polls is defined using the channel’s Re-establishment Interval (see Defining Further Scan Parameter Settings for a Direct Channel).

Use the Heartbeat section of the Shared tab to specify whether heartbeat polls are required:

  • Enabled—Select the Enabled check box to enable heartbeating. The Use Preferred Line check box becomes available for use.

Clear the Enabled check box to disable heartbeating.

  • Use Preferred Line—Select this check box for an outstation to automatically switch to the preferred line, if heartbeating shows that the preferred line has become healthy. The preferred line is the channel with which an outstation usually communicates with ClearSCADA. An outstation only switches to using its ‘backup’ channel if ClearSCADA detects that the preferred channel has failed. The outstation continues to use the backup channel only until the preferred channel becomes healthy, then switches back to the preferred channel after the delay specified in the Use Preferred Line After n Seconds field.
  • Use Preferred Line After n Seconds—Specify the time period after which an outstation’s preferred channel is deemed healthy after ClearSCADA has detected that it has failed. Use this setting to help prevent an outstation from performing several switches if the preferred channel fluctuates between healthy and failed. An outstation switches back to using its preferred channel once the channel has been healthy for the length of time specified in this field.


Advanced Drivers Guide - Hunt for a Healthy Line if ClearSCADA Detects that both Lines have Failed (Configuring an Outstation)

Hunt for a Healthy Line if ClearSCADA Detects that both Lines have Failed

When the ClearSCADA server has lost communications with an outstation on both lines, it will attempt to re-establish communications on the last line that had healthy comms. By using Line Hunting, the server will alternate between both lines, trying to establish communications with the outstation.

Use the Line Hunting section of the Shared tab to define the Line Hunting interval.

Line Hunting is not available if Heartbeating and Use Preferred Line are enabled, as the outstation will automatically use whichever line becomes healthy (see Poll Outstations on the Other Channel).

  • Enabled—Select the Enabled check box to enable Line Hunting. The Interval field becomes available for use.

Clear the Enabled check box to disable Line Hunting.

  • Interval—Specify the frequency with which attempts are made to locate a usable channel. Whenever both communication channels are inoperative, Line Hunting checks both lines systematically at this frequency until one of the lines becomes operational.


Advanced Drivers Guide - Define Group Slave Properties (Configuring an Outstation)

Define Group Slave Properties

If an outstation is a Group Slave, use these fields in the Group Slave section of the Shared tab to define the Group Slave properties:

  • Group Master—Specify the outstation that is to act as this outstation’s Group Master. Whenever the Group Master switches channels, this Group Slave also switches channels so that it continues to use the same channel as the Group Master.

Use the browse button to display a Reference browse window. Select the required independent Shared outstation from the window.

  • Switch Location—Specify where the outstation is switched between channels. Select the option that corresponds to the hardware setup of your system.

Choose from:

  • Group Master—The switch is located at the Group Master. ClearSCADA will not send a Switch Line request to the Group Slave outstation when the Group Master switches channels.
  • Outstation—The Slave outstation uses a separate switch. When the Group Master switches channels, ClearSCADA sends a Switch Line request to the Group Slave outstation to prompt it to change channels.

When the switch is located at the outstation, you can use Heartbeat polls to Poll Outstations on the Other Channel.


Advanced Drivers Guide - Define Whether an Outstation is Promoted While its Points are on Display (Configuring an Outstation)

Define Whether an Outstation is Promoted While its Points are on Display

This feature applies to many outstations that are directly connected to a ClearSCADA server—see the driver-specific documentation to see whether this feature applies to the outstations on your system.

On outstations on which the feature is supported, you can specify whether the outstation is to be given scanning preference whenever any of its points are displayed on a client. For example, when a Mimic is displayed that shows one or more of the outstation’s points.

Select the Promote when Displaying Points check box if you want the ClearSCADA server to give scanning preference to the outstation whenever any of its points are displayed on a client.

Clear the check box if the server is not to give scanning preference to the outstation when its points are displayed on a client.

For more information, see Temporarily Increasing the Scan Rate.

ATTENTION: If this feature is enabled for many outstations, and points for many of those outstations are displayed at the same time, this could have an adverse affect on the system, and may result in the intended promotion not being achieved.


Advanced Drivers Guide - Define any Pre- and Post-Ambles for an Individual Outstation (Configuring an Outstation)

Define any Pre- and Post-Ambles for an Individual Outstation

Some communications equipment or media require ‘padding’ or specific digits (an additional message) to be inserted at the start and/or at the end of each message that is transmitted using that equipment or media. Prefixed digits or padding are referred to as Pre-Amble and suffixed digits or padding as Post-Amble. Pre- and Post-Ambles always comprise an even number of digits, so giving a whole number of bytes.

If an advanced driver supports Pre- and Post-Ambles, Pre/Post Amble sections are displayed on both the Channel and Outstation Forms for that driver.

Should Pre- and/or Post-Ambles be required, use the Pre/Post Amble section on the Channel Form to specify the bytes that need to be inserted at the start and end of each message that is transmitted via that channel (see Defining any Default Pre- and Post-Amble Message Settings for a Channel).

Use the Local Pre/Post Amble section on the Outstation Form to specify whether different bytes need to be substituted in place of the bytes mentioned above, for the messages that are transmitted to a particular outstation. You may need to specify different pre- and post-ambles, for example, if a particular make or model of radio defines a protocol that allows its frequency to be changed by sending a particular message. Where that radio is used to contact a particular outstation using a different radio frequency to the frequency used to contact the other outstations on the channel, you would need to specify different pre- and/or post-ambles for that outstation.

The Pre- and Post-Ambles configured in ClearSCADA are only applied to messages that ClearSCADA’s drivers transmit, rather than receive, via a channel.

ATTENTION: Pre-ambles on messages received via network-connected channels are only supported when ClearSCADA initiates the connection.

For more information on specifying Pre- and Post-Ambles, see Defining any Default Pre- and Post-Amble Message Settings for a Channel.

The Local Pre/Post Amble section on the Outstation Form contains these fields:

  • Enabled—Select this check box if the outstation is to use different pre- and post-ambles to those specified for the channel (see Defining any Default Pre- and Post-Amble Message Settings for a Channel). Use the Pre-amble and Post-amble fields below to specify the required digits. These will replace the pre- and post-ambles specified on the Channel Form for messages that ClearSCADA transmits to this outstation.

Ensure that the check box is clear if the outstation is to use the pre- and post-ambles that are specified for the channel (see Defining any Default Pre- and Post-Amble Message Settings for a Channel). The other fields in this section become ‘grayed out’ and unavailable for use.

  • Pre-amble—Applies when local pre/post amble is enabled. Use the Pre-amble field to specify any bytes that are required at the start of each message transmitted to this outstation.
  • Post-amble—Applies when local pre/post amble is enabled. Use the Post-amble field to specify any bytes that are required at the end of each message transmitted to this outstation.

For both the Pre-amble and Post-amble fields, you need to specify the pre- or post-amble as a sequence of hexadecimal digits. Each pair of digits forms a byte in the pre- or post-amble. Ensure that the number and type of digits specified are suitable for both the protocol and type of communications media being used.

ATTENTION: Some protocols require each message to begin with a particular sequence of bytes. Do not use such bytes as Pre- or Post-Amble padding. Refer to the driver- or product-specific documentation for further details.

For more information on pre- and post-ambles, see Defining any Default Pre- and Post-Amble Message Settings for a Channel.


Advanced Drivers Guide - Points on Advanced Drivers

Points on Advanced Drivers

With most advanced drivers, ClearSCADA is the SCADA master (see Master-Slave Communications in the ClearSCADA Guide to Drivers). With such drivers, ClearSCADA uses Points to represent the measuring instruments and control devices that are connected to the outstations that are scanned by those drivers. The type of point differs, depending on the type of measuring instrument or control device that the point represents.

The point types that are supported by each advanced driver differs, depending on the driver—for a list of the points that a particular driver supports, see the driver-specific documentation.

You configure the points that are required on your system using the appropriate Point Forms. For instance, to configure an analog input point, you use the appropriate Analog Input Point Form.

Each Point Form has several tabs (see Tabs on Point Forms). Use the tabs to define different aspects of point configuration.

Use the appropriate driver documentation, along with the ClearSCADA Guide to Core Point Configuration, for information on configuring the properties that appear on the <Point Type>, or Control tabs of the Point Form.

The specific driver guides explain point types and settings that are driver-specific. The ClearSCADA Guide to Core Point Configuration cover aspects of point configuration that are common to many drivers.

For information on creating a point and displaying a Point Form, see Create and Configure a Point in the ClearSCADA Guide to Core Point Configuration. Also see Preparation.

NOTE: On systems on which ClearSCADA is configured as a SCADA Slave, ClearSCADA acts as a Slave outstation. Slave outstations use Value Maps to map the point data into simple blocks of memory within the driver (see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).


Advanced Drivers Guide - Preparation (Points on Advanced Drivers)

Preparation

Before configuring new points on a ClearSCADA system, ensure that outstation(s) exist in the database to represent the devices on which the points are located (see Configuring an Outstation).

When configuring a point, you will need to know the unique identifier for the point, and the format in which the point data is to be displayed within ClearSCADA.

If you are configuring a point that uses digital-type processing, you will need to know what the states of the point represent.

If you are configuring a point that uses analog-type processing, you will need to know the type of scaling that is required to convert the raw input value into an engineering value that ClearSCADA can process, and the range of the point. This information is typically recorded by the engineer that sets up the outstation hardware.

You need to be aware of the significance of the point’s alarms and events in relation to the entire system—this will determine the priority that you allocate to the point.

If supported by the outstation and point type, and required on your system, you will need to know whether the outstation is to log historic or significant change data for the point, and if so, the type of data or changes that are to be logged.

If you do not have access to the required information, please contact a system administrator.


Advanced Drivers Guide - Tabs on Point Forms (Points on Advanced Drivers)

Tabs on Point Forms

Point Forms have several ‘tabs’ or ‘pages’ for configuring different aspects of point data. For most points on advanced drivers, these tabs are available:

  • Identification—Use to optionally define a Help View and to indicate whether the point is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for the point (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with any point alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the point (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • Historic—Use to define any historic data storage settings for the point (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).
  • <Point Type>—Use to define any point- or driver-specific settings (see Processing Alarm Data for Point States, and also see the driver-specific documentation).

In addition, Forms for points such as output and computed points include this tab:

  • Control—Use to define the control settings for a point (see the driver-specific documentation and also, as appropriate:
  • see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration
  • see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration
  • see Define the Control Settings for a String Point in the ClearSCADA Guide to Core Point Configuration
  • see Define the Control Settings for a Time Point in the ClearSCADA Guide to Core Point Configuration.)

The control actions for a Pulse point are typically configured on the Pulse Action tab (see Defining Pulse Action Details in the ClearSCADA Guide to Core Point Configuration).


Advanced Drivers Guide - Processing Alarm Data for Point States

Processing Alarm Data for Point States

ClearSCADA can process various forms of data from an outstation, depending on the type of data that the outstation supports. For example, many outstations support current data—the present state or value of a point when the ClearSCADA server requests current data from the outstation. Many outstations also support logged data—time stamped data that is stored in the outstation.

The type of communications used between the server and outstation plays a role in determining when the server retrieves data from the outstation (see Configuring an Outstation).

Where a type of point supports logged data, you can specify how the ClearSCADA server processes the data that it retrieves from the outstation, and specifically when it raises and clears point alarms. Depending on what is supported, the server can raise and clear point alarms when it is processing logged, current, or either type of data. The way the server processes point alarms can affect the speed of alarm annunciation, alarm time stamping, and how it processes cleared alarms (points that are no longer in an alarm state).

Where a type of point supports logged data, you specify when the ClearSCADA server raises and clears point alarms, using the Alarms From field on the <Point Type> tab of the Point Form:

  • Alarms From—Use the combo box to specify when the ClearSCADA server updates its database with any point-state alarm information for this particular point.

The available options vary with the type of outstation, but may include:

  • All Data—(The default setting.) The server raises or clears any alarms for the point when it is processing point data that it has received from the outstation, regardless of whether that data is logged data or current data, and regardless of the data’s time.

If the point is not currently in alarm, and the server is processing data that is older than the latest data, then if that data is an alarm state, the server raises then immediately clears the alarm to indicate that the point has been in an alarm state. This situation typically occurs with PSTN outstations, when an outstation does not dial in until after the alarm has cleared.

  • Logged Data Only—The server raises or clears any alarms for the point when it is processing logged data, rather than current data.

As the server only processes alarms from logged data, it is possible for it to process a logged alarm state and therefore raise an alarm, for a point that is currently no longer in alarm at the outstation—the server will clear the raised alarm when it processes the logged data that clears that alarm.

Choose this option, or the Most Recent Logged Data option, if a point that is on a PSTN outstation is configured to use the No Change feature (see Detect Whether a Point Value has Stopped Changing in the ClearSCADA Guide to Core Point Configuration).

  • Most Recent Data—The server raises or clears any alarms for the point when it is processing data that is newer than the data it has already processed, regardless of whether it is logged data or current data.

This option logs an event, but does not raise an alarm, if the point changes to an alarm state, but this is older than the most recent data for the point. (In other words, a ‘missed’ alarm is only logged as an event.)

This option is not recommended for some PSTN outstations.

  • Most Recent Logged Data—The server only raises or clears any alarms for the point when it is processing logged data that is newer than the logged data that it has already processed.

This option logs an event, but does not raise an alarm, if the point changes to an alarm state, but this is older than the most recent logged data for the point. (In other words, a ‘missed’ alarm is only logged as an event.)

Choose this option, or the Logged Data Only option, if a point that is on a PSTN outstation is configured to use the No Change feature (see Detect Whether a Point Value has Stopped Changing in the ClearSCADA Guide to Core Point Configuration).

Where the time of alarm is important, choose a logged data option, as these options use the time stamp recorded by the outstation and therefore show when the point actually changed state. Other options may time stamp the alarm with the time that the server processes the alarm (see the example, below). Alarms and events have both an occurrence time and a receipt time. If ClearSCADA does not know the occurrence time when it processes and raises an alarm, it will use that alarm’s receipt time. However, should it become aware of the occurrence time at a later stage, it will update the alarm’s time accordingly. (For instance, if it dials out to a PSTN outstation and retrieves the current data for a point that is in alarm, it will raise an alarm with the receipt time—the time that it processed the data. If it then retrieves logged data for that point, in which it retrieves the state change that triggered that alarm, the server will update the alarm data with the occurrence time—the time that the point changed state.)

Where speed of alarm annunciation is important, logged data options are slower than the other options. With most outstations that support logged data, ClearSCADA retrieves the older logged data before it retrieves the newer logged data (which may include a change of alarm state). The server processes the data in the order that it receives that data. With logged data options, the server therefore raises or clears alarms for the older logged data before it processes the newer logged data.

Example:

A major problem detected at a site results in all PSTN outstations attempting to dial in to the server together. This results in the phone lines being engaged when one of the outstations attempts to dial in. The outstation is able to dial in a few minutes later and the server retrieves the outstation’s data.

Several points on the outstation are configured to use the ‘All Data’ option, so that the ClearSCADA server raises and clears any point state alarms whenever it processes any data from the outstation. The server time stamps any raised or cleared alarms with the present time (that is, the time that it processes the data). This differs from the time that the alarms were actually raised or cleared at the outstation. However, operators are able to see the raised and cleared alarm data more quickly than for other points on the outstation that are configured to use the ‘Logged Data Only’ or ‘Most Recent Logged Data’ options.

For these points, the alarm data is time stamped with the time that the change actually occurred at the outstation, but the server processes the points’ older logged data first before coming to the newer logged data, in which some of the changes in alarm state occur.

(The server will adjust the time stamps on the ‘All Data’ alarms once it retrieves the logged data that indicates the occurrence time of those alarms.)

In the unlikely event that the server loses communications with an outstation while retrieving data for a point that uses a Logged Data option, it may be possible for:

  • A point to have an alarm, even though its current state is not an alarm (as the server has not yet retrieved the data that will clear the alarm).
  • A point to be in an alarm state, but for no alarm to be displayed (as the server has not yet retrieved the data that will raise the alarm).

The above situations become rectified as soon as communications is restored and the server is able to process the rest of the data.


Advanced Drivers Guide - Configuring a File Upload

Configuring a File Upload

On some systems, the system set-up does not allow ClearSCADA to communicate with one or more of the outstations on the system. Instead, the outstation data is uploaded into ClearSCADA, from file. In order to facilitate the upload procedure, some drivers support File Uploading. The driver-specific documentation indicates if a driver supports this feature and also indicates the format that the data files have to take.

Where File Uploading is supported, you need to configure a File Upload in the ClearSCADA database for each set of data files that need uploading into ClearSCADA. You need to decide whether you require one File Upload per system, or whether to logically divide your system and create one File Upload per region or other logical division.

You configure the settings for a File Upload using the fields on the appropriate File Upload Form. The Form has several tabs (see Tabs on File Upload Forms).

If ClearSCADA is required to log on to any remote node(s) in order to access the files that are to be uploaded to the local ClearSCADA system, logon settings need to be specified using the ClearSCADA Server Configuration Tool (see Upload Files over the Network).

The file upload procedure is triggered using the Upload File or Upload Files pick actions.

Further Information

Minimum Configuration.


Advanced Drivers Guide - Upload Files over the Network (Configuring a File Upload)

Upload Files over the Network

If files are to be uploaded from remote nodes (other computers or workstations that are connected to the ClearSCADA network), you need to specify the network domain, and any user name and password settings that are required to access and upload the files successfully.

An administrator-level user needs to specify the logon settings using the File Upload branch of the ClearSCADA Server Configuration Tool (see File Upload Settings in the ClearSCADA Guide to Server Administration). Each driver will log on when that driver starts, so that it has permission to access the other computer(s) when uploading files. (This only applies to drivers that support file uploads.)


Advanced Drivers Guide - Tabs on File Upload Forms (Configuring a File Upload)

Tabs on File Upload Forms

File Upload Forms have several ‘tabs’ for configuring different aspects of File Upload information. For drivers that support File Uploading, a combination of these tabs is available:

  • Identification—Use to optionally define a Help View and to indicate whether the File Upload is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for the File Upload (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with any File Upload alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the File Upload (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • File Upload—Use to Specify the File Upload Settings.
  • Historic—Use to Specify the Length of Time that a File Upload Report is Retained on the Server.

This section explains the features on the File Upload and Historic tabs that are common to File Uploads on several drivers.

For aspects of File Upload configuration that are common to most types of database item, see the ClearSCADA Guide to Core Configuration.

For aspects of File Upload configuration that are specific to individual drivers, see the ClearSCADA driver-specific documentation.


Advanced Drivers Guide - Minimum Configuration (Configuring a File Upload)

Minimum Configuration

As a minimum, for a File Upload to be functional, you have to specify the directory from which ClearSCADA is to upload the data files (File Upload tab) and then put the File Upload In Service and save the configuration.

This will provide a functional File Upload that uses default configuration settings.


Advanced Drivers Guide - Specify the File Upload Settings (Configuring a File Upload)

Specify the File Upload Settings

Use the fields on the File Upload tab of the File Upload Form to specify these settings:

  • In Service—Use to specify whether the File Upload is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Severity—Use this combo box to define the severity of any alarms or events that are associated with the File Upload. For more information on severities, see Defining Severities in the ClearSCADA Guide to Core Configuration.
  • Area of Interest—If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the File Upload tab. Use the field to specify the area with which any of the File Upload’s alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Directory—Use to specify the directory from which ClearSCADA is to upload the data files. Use the browse button to display a Reference browse window and select the required directory from the window. The location specified must include the full path to the directory.

Ensure that ClearSCADA has full read/write access to the files in the directory.

Be aware that storing data files in a single directory has redundancy implications, for which you may want to make further arrangements.

ATTENTION: The files within the source directory will be deleted as soon as they have been successfully uploaded to ClearSCADA.

The servers on a Hot- or Triple-Standby system must point to the same directory, so that each data file is only uploaded once. Use mapped drives or a UNC path (which may be on a separate file server) to ensure that the servers point to the same directory. (This requirement does not apply to permanent standby servers, as such servers do not run the drivers.)

Example:

A Hot-Standby system has two ClearSCADA servers, named SVRA and SVRB.

A folder named Upload is created on the C: drive of SVRA. The folder is shared, using the name Upload.

A mapped drive named U: is created on SVRA. The mapped drive has the folder \\SVRA\Upload.

Another mapped drive named U: is created on SVRB. The mapped drive has the folder \\SVRA\Upload.

The ClearSCADA File Upload directory is therefore specified as U:\ on the File Upload Form.


Advanced Drivers Guide - Specify the Length of Time that a File Upload Report is Retained on the Server (Configuring a File Upload)

Specify the Length of Time that a File Upload Report is Retained on the Server

Use the Historic tab of the File Upload Form to specify the amount of time for which any Report that is associated with the uploaded data, is retained on the server.

Specify the time in the OPC Time Format. For example, 4W for a Report to be retained for a four-week period. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required time.

Operators can display the Reports using the Display Report pick action. (Where more than one Report is stored on the server, a window is displayed, allowing the required Report to be selected.)


Advanced Drivers Guide - Using Eavesdropping to Test a New Server's Configuration

Using Eavesdropping to Test a New Server’s Configuration

Some advanced drivers support eavesdropping. The eavesdropping feature is designed to allow a new system to run in parallel to an existing system. This means that you can Test the Configuration of a New System with almost no risk to the operation of the outstations.

Eavesdropping works by allowing an existing system to maintain control of the outstations, while a new server processes the data that the outstations report to ClearSCADA.

The existing system communicates with the outstations via one or more channels. Each channel consists of a receive line (Rx) and a transmit line (Tx)—the Rx line at the ClearSCADA server connection is the Tx line at the outstation connection (the ClearSCADA server receives the data that is transmitted from the outstations).

Special serial cables are used to connect the new server to the line(s) at the existing server’s connection. The eavesdropping arrangement differs, depending on the drivers that are used on your system. Each type of driver requires one of these arrangements:

  • Eavesdrop Rx Only
  • Eavesdrop Rx and Tx.

Refer to the relevant driver guide for information on which arrangement is required by that particular protocol.


Advanced Drivers Guide - Eavesdrop Rx Only (Using Eavesdropping to Test a New Server's Configuration)

Eavesdrop Rx Only

With an Rx-only arrangement, special serial cables are used to connect the new server to the Rx line at the existing server’s connection. The new server contains the configuration for the relevant outstations, points, and so on, as well as the direct or PSTN channel that represents the connection. The channel has the eavesdropping feature enabled so that the new server can identify that the input (the data from the existing system’s Rx line) is unsolicited.

The Tx line of the new server’s connection to the existing system is disconnected. With this line disconnected, the new server cannot send data to the outstations, and therefore cannot affect the operation of the existing system.

Further Information

Test the Configuration of a New System.


Advanced Drivers Guide - Eavesdrop Rx and Tx (Using Eavesdropping to Test a New Server's Configuration)

Eavesdrop Rx and Tx

With an Rx and Tx arrangement, special serial cables are used to connect the new server to both the Rx and Tx lines at the existing server’s connection. The new server contains the configuration for the relevant outstations, points, and so on, as well as the direct or PSTN channel that represents the connection. The channel has the eavesdropping feature enabled so that the new server can identify that the input (the data from the existing system’s Rx line), and the output (the data from the existing system’s Tx line) is unsolicited.

The Tx lines of the new server’s connections to the existing system are disconnected. With these lines disconnected, the new server cannot send data to the outstations, and therefore cannot affect the operation of the existing system.

Further Information

Test the Configuration of a New System.


Advanced Drivers Guide - Test the Configuration of a New System (Using Eavesdropping to Test a New Server's Configuration)

Test the Configuration of a New System

To test the configuration of a new system:

  1. Configure the new system, including the database items that represent the set-up of the outstations and communications—for example, the channels, outstations, and points. For details, please refer to the relevant driver documentation.
  2. Enable the eavesdropping feature for each of the communication channels. The Eavesdropping check boxes are on the Channel tabs of the various Channel Forms.
    Select the Eavesdropping check box to enable eavesdropping on a channel.

  3. Carry out one of these procedures, depending on the eavesdropping arrangement:
  • Eavesdrop Rx Only —Ensure that the new server is connected to an existing system’s Rx line connection via a suitable serial cable.
  • Eavesdrop Rx and Tx —Ensure that the new server is connected to an existing system’s Rx line, and Tx line connections via separate suitable serial cables.

The outstations will report their data to the new system.

  4. Use the alarm, event, and diagnostics features to determine the cause of any problems that ClearSCADA detects.
  5. Train and familiarize operators and engineers in using the new system.
  6. Once there is confidence in using the new system, it can replace the old system—the new system will need to be connected to the outstations’ Tx communication lines and you will need to disable the eavesdropping feature on each channel.
    Clear the Eavesdropping check box to disable eavesdropping on a channel, once testing of the configuration on the new system is complete.


Advanced Drivers Guide - Quick Reference to Configuring Specific Features

Quick Reference to Configuring Specific Features

Use this quick reference to help you adjust the driver configuration settings for your particular requirements. The features are only available if supported by the type of driver, channel, set, outstation, or point.

What do you want to do?

  • Check that a PSTN outstation can still dial in to the server—Enable the Callback feature on the PSTN tab of the Outstation Form (see Define an Outstation’s PSTN Properties), then use the Callback pick action.
  • Report alarms on a PSTN outstation to another ClearSCADA database—Enable a Remote dial in line on the PSTN tab of the Outstation Form (see Define Dial In Line Properties on a PSTN Outstation).
  • Retrieve data from an individual PSTN outstation at a more frequent rate—Enable the Promote Dial Out feature on the Outstation Form (see Define an Outstation’s PSTN Properties), and use the Promote Dial Out pick action.
  • Retrieve data from PSTN outstations in an outstation set at a more frequent rate—Enable the Promote Dial Out feature on the Outstation Set Form (see Defining Communication Settings), and use the Promote Dial Out pick action.
  • Specify when point alarm states are updated in the ClearSCADA database—Select the appropriate option from the Alarms From field on the Point Form (see Processing Alarm Data for Point States).
  • Use different PSTN connection types for some channels and outstations—A system administrator needs to set up the types using the ClearSCADA Server Configuration Tool (see PSTN Connection Types). Once set up, you can specify the required type in the Connection Type window on the appropriate Channel Form (see Defining PSTN Settings for a Channel) and Outstation Form (see Define an Outstation’s PSTN Properties).


Advanced Drivers Guide - Common Advanced Driver Log File Options

Common Advanced Driver Log File Options

Driver Logging can be used to help diagnose abnormal conditions relating to driver activity. Driver logging can also be used for assessing potential problems. The log files that are produced provide useful diagnostic information about specific aspects of the system. For instance, the Points logging option provides diagnostic information about the points on a particular driver.

Should you need to contact Schneider Electric for assistance with resolving a problem that ClearSCADA has detected, you might be asked to provide Log files to help in assessing the cause of the problem. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

This section explains the driver logging options that are common to many advanced drivers.

Those driver logging options that are typically required for investigating abnormal conditions are enabled by default. We suggest that the logging options are left at this default unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

For information on any driver logging options that are not listed below, see the driver-specific documentation.

These driver log file options are common to many advanced drivers:

  • Application—Logs general information about the driver.
  • Errors—Logs any errors detected during driver operation. For example, a loss of connection to the ClearSCADA database.
  • Timers—Logs information about low-level internal thread timer queues.

ATTENTION: The Timers option typically logs a large amount of information. As such, we recommend that this option is only enabled if specifically requested by Schneider Electric’s engineers.

  • Events—Logs information about low-level internal thread event queues.

ATTENTION: The Events option typically logs a large amount of information. As such, we recommend that this option is only enabled if specifically requested by Schneider Electric’s engineers.

  • I/O—Logs information about low-level I/O.
  • Database Objects—Logs configuration changes to database items (any create, delete, or modify activity on the system).
  • Channels—Logs general information about the channels on the system, including the channel’s state, and activities including attaching or detaching outstation sets.
  • Outstation Sets—Logs general information about the outstation sets on the system, including one shot, promoted dial out, and channel switching.
  • Outstations—Logs general information about the outstations on the system, including the outstation’s state, current channel, and any switching activity.
  • Points—Logs general information about the points on the system, including controls and persistence.
  • Modems—Logs information on dial-up modem exchanges and states.
  • Scanners—Each channel has a scanner that is responsible for scanning the outstation(s) on that channel. The Scanner Log File option logs information about each scanner.
  • Requests (Actions)—Logs information about any external requests from users, plus internal requests within the driver.
  • Point Updates (Data)—Logs information about point data retrieved by the driver.
  • Scanning Phases—Logs information about the phases of outstation scanning (primary, secondary, promoted, exception, and so on).
  • Client Sink—Logs information about the low-level interface from server to driver.
  • Server Sink—Logs information about the low-level interface from driver to server.
  • Browse Server—Logs information about the use of the browse options on configuration Forms.

Further Information

Log files and Log file settings: see Driver Logging in the ClearSCADA Guide to Server Administration.

Displaying log files: see Display a Driver Log File in the ClearSCADA Guide to Server Administration.

The log file options to turn on if experiencing problems with an advanced driver, see Troubleshooting.

Types of log file supported by ClearSCADA: see Logging and Monitoring in the ClearSCADA Guide to Server Administration.


Advanced Drivers Guide - Troubleshooting

Troubleshooting

Use the charts in this section if you have an outstation on your system that should be, but is not, communicating with the ClearSCADA server. The charts guide you through a series of checks to assess why the outstation might not be communicating. The checks vary with the type of communications that the outstation uses.

We suggest that you start with CHART 1: Basic Checks for Outstations with no Communications. This chart will guide you through some basic checks. If these checks do not solve the communications problem that ClearSCADA has detected, you will be directed to carry out further checks on other charts. Alternatively, use the table below to check which chart you need to refer to if your system is displaying a specific error message.

If ClearSCADA has detected an abnormal condition on an advanced driver, we recommend the following:

  • If the problem that ClearSCADA has detected is related to communications with an outstation or dial-up modem, enable I/O logging on any affected channels (see Enable or Disable I/O Logging on a Channel in the ClearSCADA Guide to Server Administration)
  • Display the relevant Driver Logging window (see Define the Driver Logging Settings in the ClearSCADA Guide to Server Administration). Use the Typical button on the window to enable those driver logging options that are typically required for investigating abnormal conditions.

After the abnormal condition has re-occurred, send the log files to Schneider Electric. You may be asked to turn on different logging options and reproduce the abnormal condition, if the condition cannot be diagnosed from the initial logs. For further information on driver logging options, see Common Advanced Driver Log File Options.

NOTE: When troubleshooting on a ClearSCADA system, always check the Events List for diagnostic messages. These may help to identify the cause of any abnormal conditions that ClearSCADA has detected. Additionally, each item’s Status display summarizes that particular item’s current status. This might also help to indicate the location or extent of the problem that ClearSCADA has detected (see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers).

For information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool, and the driver-specific documentation.

Event Journal message

Reason

Type of communications being used

Chart to which you should refer for more information

Assign to COM Port Failed

The Windows® operating system has returned an error that is currently unhandled by ClearSCADA. The error indicates that an attempt to assign a COM Port has failed.

The Driver Log file indicates the specific operating system error that was returned. If such an error occurs, send the Driver Log file to Schneider Electric for investigation.

Direct Serial Comms

see CHART 2a: Outstations using Direct Serial Communications

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

Assign to TCP/IP Port Failed

The Windows® operating system has returned an error that is currently unhandled by ClearSCADA. The error indicates that an attempt to assign a TCP/IP Port has failed.

The Driver Log file indicates the specific operating system error that was returned. If such an error occurs, send the Driver Log file to Schneider Electric for investigation.

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

TCP/IP Comms

see CHART 5a: Outstations using TCP/IP Communications

COM Port Already Assigned

The COM port is being used by an application other than ClearSCADA.

Direct Serial Comms

see CHART 2a: Outstations using Direct Serial Communications

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

Could not bind to UDP port for inbound messages

The driver could not bind to the UDP port to listen for messages. This could be because another application (or a non-driver part of ClearSCADA) is already bound to that port.

Network Comms

see CHART 6a: Outstations using Network Communications

I/O Failure

The Windows® operating system returned an error during a read or write operation, or a received data packet was corrupt.

Direct Serial Comms

see CHART 2a: Outstations using Direct Serial Communications

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

I/O Timeout

This error may be due to one of several consecutive timeouts.

The error might indicate, for example, that the driver has not received a reply to a request, or that the Windows® operating system has not signalled that a write operation has completed its transmission.

The Driver log file will provide more information about the error.

Direct Serial Comms

see CHART 2a: Outstations using Direct Serial Communications

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

TCP/IP Comms

see CHART 5a: Outstations using TCP/IP Communications

Internal Error in Driver

The driver has encountered an unhandled condition. The error message relates to an unexpected condition occurring within the driver.

If such an error occurs, send the Driver Log files to Schneider Electric for investigation.

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

TCP/IP Comms

see CHART 5a: Outstations using TCP/IP Communications

Invalid COM Port

A COM port has been specified that is not defined in the Windows® operating system (for example, COM99 has been configured, but that port does not actually exist in the server).

On a Hot-Standby system, ensure that the same ports are available on each server. (This applies to Direct and PSTN communications.)

Direct Serial Comms

see CHART 2a: Outstations using Direct Serial Communications

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

Invalid Host Address

The Windows® operating system could not match the specified Host Address with a valid destination.

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

TCP/IP Comms

see CHART 5a: Outstations using TCP/IP Communications

Modem AT Command Error

The configured AT command is not compatible with the attached modem, so the modem is returning an error.

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

Modem Failed

The driver has attempted to poll the attached modem with the configured AT command. However, the driver has not received a valid response within the configured Standard Reply Delay.

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

No Write in Progress

The Windows® operating system has indicated that a Write operation has completed. However, ClearSCADA has no record of such a Write operation.

Direct Serial Comms

see CHART 2a: Outstations using Direct Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

Unable to Connect to TCP/IP Port

The driver has attempted to connect to a remote device, but that device has not acknowledged the request.

Remote Serial Comms

see CHART 3a: Outstations using Remote Serial Communications

PSTN Comms

see CHART 4a: Outstations using PSTN Communications

TCP/IP Comms

see CHART 5a: Outstations using TCP/IP Communications

Further Information

Driver Log Files: see Driver Logging in the ClearSCADA Guide to Server Administration.

Server settings that define the number of consecutive read/write failures that have to be exceeded before an I/O Failure alarm is generated: see Define the Maximum Number of Consecutive Failed Reads and Writes in the ClearSCADA Guide to Server Administration.

Server settings that define the number of consecutive timeouts that have to be exceeded before an I/O Timeout alarm is generated: see Define the Maximum Number of Consecutive Read and Write Timeouts in the ClearSCADA Guide to Server Administration.


Advanced Drivers Guide - CHART 1: Basic Checks for Outstations with no Communications (Troubleshooting)

CHART 1: Basic Checks for Outstations with no Communications

Further Information

CHART 2a: Outstations using Direct Serial Communications.

CHART 3a: Outstations using Remote Serial Communications

CHART 4a: Outstations using PSTN Communications.

CHART 5a: Outstations using TCP/IP Communications.

CHART 6a: Outstations using Network Communications.


Advanced Drivers Guide - CHART 2a: Outstations using Direct Serial Communications (Troubleshooting)

CHART 2a: Outstations using Direct Serial Communications

Further Information

CHART 1: Basic Checks for Outstations with no Communications.

CHART 2b: Direct Serial Comms - Channel Not Failed.

CHART 2c: Direct Serial Comms - Channel Failed.

CHART 3a: Outstations using Remote Serial Communications.


Advanced Drivers Guide - CHART 2b: Direct Serial Comms - Channel Not Failed (Troubleshooting)

CHART 2b: Direct Serial Comms - Channel Not Failed

Further Information

CHART 2a: Outstations using Direct Serial Communications.


Advanced Drivers Guide - CHART 2c: Direct Serial Comms - Channel Failed (Troubleshooting)

CHART 2c: Direct Serial Comms - Channel Failed

Further Information

CHART 2a: Outstations using Direct Serial Communications.

Server settings that define the number of consecutive timeouts that have to be exceeded before an I/O Timeout alarm is generated: see Define the Maximum Number of Consecutive Read and Write Timeouts in the ClearSCADA Guide to Server Administration.

Server settings that define the number of consecutive read/write failures that have to be exceeded before an I/O Failure alarm is generated: see Define the Maximum Number of Consecutive Failed Reads and Writes in the ClearSCADA Guide to Server Administration.


Advanced Drivers Guide - CHART 3a: Outstations using Remote Serial Communications (Troubleshooting)

CHART 3a: Outstations using Remote Serial Communications

Further Information

CHART 1: Basic Checks for Outstations with no Communications.

CHART 3b: Remote Serial Comms - Channel Not Failed.

CHART 3c: Remote Serial Comms - Channel Failed.

CHART 2a: Outstations using Direct Serial Communications.


Advanced Drivers Guide - CHART 3b: Remote Serial Comms - Channel Not Failed (Troubleshooting)

CHART 3b: Remote Serial Comms - Channel Not Failed

Further Information

CHART 3a: Outstations using Remote Serial Communications.


Advanced Drivers Guide - CHART 3c: Remote Serial Comms - Channel Failed (Troubleshooting)

CHART 3c: Remote Serial Comms - Channel Failed

Further Information

CHART 3a: Outstations using Remote Serial Communications.

Server settings that define the number of consecutive timeouts that have to be exceeded before an I/O Timeout alarm is generated: see Define the Maximum Number of Consecutive Read and Write Timeouts in the ClearSCADA Guide to Server Administration.

Server settings that define the number of consecutive read/write failures that have to be exceeded before an I/O Failure alarm is generated: see Define the Maximum Number of Consecutive Failed Reads and Writes in the ClearSCADA Guide to Server Administration.


Advanced Drivers Guide - CHART 4a: Outstations using PSTN Communications (Troubleshooting)

CHART 4a: Outstations using PSTN Communications

Further Information

CHART 1: Basic Checks for Outstations with no Communications.

CHART 4b: PSTN Comms - Channel Not Failed.


Advanced Drivers Guide - CHART 4b: PSTN Comms - Channel Not Failed (Troubleshooting)

CHART 4b: PSTN Comms - Channel Not Failed

Further Information

CHART 4a: Outstations using PSTN Communications.


Advanced Drivers Guide - CHART 5a: Outstations using TCP/IP Communications (Troubleshooting)

CHART 5a: Outstations using TCP/IP Communications

Further Information

CHART 1: Basic Checks for Outstations with no Communications.

CHART 5b: TCP/IP Comms - Channel Not Failed.

Server settings that define the number of consecutive timeouts that have to be exceeded before an I/O Timeout alarm is generated: see Define the Maximum Number of Consecutive Read and Write Timeouts in the ClearSCADA Guide to Server Administration.


Advanced Drivers Guide - CHART 5b: TCP/IP Comms - Channel Not Failed (Troubleshooting)

CHART 5b: TCP/IP Comms - Channel Not Failed

Further Information

CHART 5a: Outstations using TCP/IP Communications.


Advanced Drivers Guide - CHART 6a: Outstations using Network Communications (Troubleshooting)

CHART 6a: Outstations using Network Communications

Further Information

CHART 1: Basic Checks for Outstations with no Communications.

CHART 6b: Network Comms - Channel Not Failed.

Windows DNS and its use of random UDP ports to help ensure system security, see:

  • http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx
  • http://support.microsoft.com/kb/953230.

Network diagnostic tools: We recommend using tools such as the Microsoft® Windows® netstat command line tool, or a third-party tool such as Microsoft® Sysinternals™ TCPView.


Advanced Drivers Guide - CHART 6b: Network Comms - Channel Not Failed (Troubleshooting)

CHART 6b: Network Comms - Channel Not Failed

Further Information

CHART 6a: Outstations using Network Communications.


DNP3 Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


DNP3 Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


DNP3 Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


DNP3 Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


DNP3 Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


DNP3 Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s DNP3 driver. The DNP3 driver enables ClearSCADA to communicate with devices using the DNP3 protocol. For more details on the information included in this guide, see Introduction to the DNP3 Driver.


DNP3 Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring DNP3 items and features in the ClearSCADA database.

The guide also contains information for:

  • Operators and engineers who use the DNP3 driver to monitor and control plant
  • Maintenance engineers.


DNP3 Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


DNP3 Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Lists

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to ViewX and WebX Clients.


DNP3 Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


DNP3 Driver Guide - Introduction to the DNP3 Driver

Introduction to the DNP3 Driver

The DNP3 protocol is an open standard that allows interoperability between devices such as outstations, RTUs (Remote Telemetry Units) and IEDs (Intelligent Electronic Devices) and SCADA masters. A DNP3 network typically consists of a single master and multiple outstations. The master is usually a SCADA server (for example, a ClearSCADA Server) and the outstations are the RTUs and IEDs. The master maintains a local database that holds a copy of the data stored in each outstation.

The master processes the data received from the outstation and:

  • Displays current values to operators
  • Generates alarms
  • Stores historic event data so that it may be trended and reported.

The data sent by an outstation may be:

  • Values of physical inputs at the outstation
  • Values obtained from another device by the outstation (these values may be obtained using DNP3 or any other protocol, such as Modbus)
  • Values that are calculated by the outstation.

One of the fundamental concepts of DNP3 is that an outstation can buffer time stamped event data. The outstation sends its buffered data to the master when:

  • The master sends a poll request to the outstation—these can be scheduled by the master to optimize use of the communications network
  • The outstation sends an unsolicited message—these allow the outstation to send critical data (for example device faults) immediately.

The DNP3 protocol allows for a device to act as both a master and an outstation simultaneously. Outstations that provide this functionality are typically known as data concentrators. ClearSCADA provides a set of DNP3 Slave items that allow ClearSCADA to behave as an outstation on a DNP3 network.

The DNP3 driver in ClearSCADA allows you to configure master/slave scenarios that communicate using the DNP3 protocol (see Typical DNP3 Scenarios).

This guide explains how to configure DNP3 specific features and items within the ClearSCADA database. For further information, see these sections:

  • Configuring DNP3 Devices in ClearSCADA
  • DNP3 Secure Authentication
  • Scanning for Data on DNP3 Devices.

The guide also explains those DNP3 specific features that are of interest to operators, such as:

  • DNP3 Specific Alarm and Event Categories
  • Using DNP3 Specific Actions

and DNP3 specific aspects that are of interest to system administrators and engineers when investigating unexpected system behavior (relating to the DNP3 driver):

  • DNP3 Specific Status Descriptions on Historic Lists
  • DNP3 Specific Status Display Attributes
  • DNP3 Specific Colors
  • System Analysis.

NOTE: Some DNP3 devices have additional features that are unavailable on other DNP3 devices. To support these additional features, ClearSCADA uses a DNP3 Extension Driver. If your system uses a DNP3 Extension Driver, use the guide to that extension driver in conjunction with this guide.


DNP3 Driver Guide - Configuring DNP3 Devices in ClearSCADA (Introduction to the DNP3 Driver)

Configuring DNP3 Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, control devices and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the DNP3 devices on your system.

In order to represent any DNP3 devices, the DNP3 Driver has to be installed and running on the ClearSCADA servers on your system. When the DNP3 driver is first installed, a system administrator needs to define the server settings for the driver (see Configuring DNP3 Server Settings).

When you configure DNP3 items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant DNP3 devices on your system. Some settings are either fixed (incorporated into the design of the DNP3 outstation) or are configured by an engineer. You need to have access to, or an understanding of, the settings of the DNP3 devices on your system before you can configure the DNP3 database items successfully.

For instance, you need to know the DNP3 Event Class(es) that each DNP3 outstation supports.

Each DNP3 device has a Profile document that describes what functionality is provided. Use the document alongside this DNP3 Driver Guide to configure the settings for your devices.

The items that you need to configure vary, depending whether you require a master device (see DNP3 Master Configuration), or a Slave device (see DNP3 Slave Configuration).

You also need to be aware of which optional features are required for each DNP3 item. The features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with DNP3 database items, including Lists, Actions, and Mimics. For actions that are specific to the DNP3 driver, see Using DNP3 Specific Actions. For further information on actions and details on Lists and Mimics, see the core documentation.


DNP3 Driver Guide - DNP3 Master Configuration (Introduction to the DNP3 Driver)

DNP3 Master Configuration

To configure ClearSCADA as a DNP3 Master, you need to create and configure:

  1. DNP3 Channel(s) to define the communication connections between ClearSCADA and the DNP3 outstations (see Configuring a DNP3 Channel).
  2. A DNP3 Outstation Set to define each group of DNP3 outstations that share the same communications media (see Configuring a DNP3 Outstation Set).
  3. A DNP3 Outstation to represent each DNP3 outstation with which ClearSCADA communicates (see Configuring a DNP3 Outstation).

Many DNP3 outstations do not support downloading of configuration properties from ClearSCADA. For this reason, you should check that the outstation configuration in the ClearSCADA database matches the configuration that exists at the corresponding outstation.

  4. A DNP3 Point to represent each analog or binary measuring instrument or control device that is connected to each DNP3 outstation (see Points Used on DNP3 Outstations).
  5. DNP3 Pulse Actions (where needed) to carry out controls on plant for specified periods of time (see Configuring DNP3 Pulse Actions).
  6. DNP3 Status Points (where needed) to retrieve internal status information from each DNP3 outstation (see Configuring DNP3 Status Points).

If the DNP3 master is used for routing comms using a Virtual Terminal, you also need to Configure a DNP3 VT Service Port Master and Configure a DNP3 Virtual Terminal.

Further Information

Scanning for Data on DNP3 Devices.

ClearSCADA can communicate with other DNP3 devices using a DNP3 Extension Driver. For information on configuring such devices, see the relevant DNP3 extension driver guide.


DNP3 Driver Guide - DNP3 Slave Configuration (Introduction to the DNP3 Driver)

DNP3 Slave Configuration

To configure ClearSCADA as a DNP3 Slave, you need to create and configure:

  1. DNP3 Slave Channel(s) to define the communication connections between ClearSCADA and the DNP3 master (see Configuring a DNP3 Channel).
  2. A DNP3 Slave Outstation Set to define each group of slave outstations that share the same communications channel (see Configuring a DNP3 Outstation Set).
  3. DNP3 Slave Outstation(s) with which a DNP3 master may communicate, in order to obtain data from ClearSCADA (see Configuring a DNP3 Slave Outstation).
  4. Filtered Value maps for mapping point properties into memory so that they can be accessed by a DNP3 master (see Define the Filtered Value Map Locations, and see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).

If the DNP3 Slave is used for routing comms using a Virtual Terminal, you also need to Configure a VT Service Port Slave.


DNP3 Driver Guide - DNP3 Secure Authentication (Introduction to the DNP3 Driver)

DNP3 Secure Authentication

ClearSCADA supports DNP3 Secure Authentication version 2.00 for a single user—the ‘Default User’ (DNP3 User 1).

You can optionally enable DNP3 Secure Authentication on a per outstation basis in ClearSCADA. When enabled:

  • A DNP3 outstation can issue a ‘challenge’ to determine whether it is genuinely communicating with a particular DNP3 master
  • A DNP3 master can issue a ‘challenge’ to determine whether it is genuinely communicating with a particular outstation.

Due to factors such as the necessary increase in bandwidth and the extra processing involved, ‘challenges’ are only sent in relation to requests or responses that are deemed to be ‘critical’. The DNP3 standard dictates those function codes that are deemed critical; other function codes can be set to critical if required. In ClearSCADA, you define the criticality of function codes on a per server basis (see Define Which Function Codes are Critical).

Functions that are deemed to be non-critical are processed in the normal way. (The DNP3 master sends a non-critical request to an outstation; the outstation processes that request and sends the appropriate reply and/or data to the DNP3 master.)

When a DNP3 device receives a request or response that is deemed to be critical, that device replies with a ‘challenge’ (this differs slightly if Aggressive Mode is used). The challenge requires the sending device (the ‘Responder’) to send a reply within a defined time period.

If an authentic reply is received within the required time period, the device that issued the challenge (the ‘Challenger’) executes the critical function. If the challenger is an outstation, it performs the requested critical function and sends the appropriate response to the DNP3 master. If the challenger is a DNP3 master, it processes the stored response that triggered the challenge.

If a challenge is unsuccessful, the challenger rejects the critical request or response. If the challenger is an outstation, it does not perform the rejected critical request. If the challenger is a DNP3 master, it throws out the data that it received in relation to the rejected critical response. The challenger might also send a diagnostics message to the responder, but the number of diagnostics messages is actively limited.

To communicate using DNP3 Secure Authentication, the DNP3 master and the DNP3 outstation need to support DNP3 Secure Authentication version 2.00 and have that feature enabled. Both devices also need to be provided with a pre-shared private Update Key.

If security is required, but bandwidth is limited or high latency links are used, consider transmitting critical requests and/or responses using Aggressive Mode. Aggressive Mode is generally a sufficiently secure form of DNP3 Secure Authentication that differs slightly to the above described full ‘Challenge-Response’ mechanism in that fewer messages are transmitted between both devices (see Aggressive Mode).

Further Information

Configure the system-wide DNP3 Secure Authentication properties: see Configuring DNP3 Server Settings.

Configure a DNP3 master outstation’s DNP3 Secure Authentication properties: see Configure the Security Properties.

Configure a DNP3 slave outstation’s DNP3 Secure Authentication properties: see Configure the Slave’s Security Properties.


DNP3 Driver Guide - Terminology Associated with DNP3 Secure Authentication (Introduction to the DNP3 Driver)

Terminology Associated with DNP3 Secure Authentication

This section summarizes the terms with which you might need to be familiar in order to configure DNP3 Secure Authentication settings in ClearSCADA. The terms comprise:

  • Aggressive Mode
  • Challenge Data
  • ‘Challenge-Response’
  • Challenger
  • HMAC
  • Key Wrap
  • Responder
  • Session Key
  • Session Key Change
  • Update Key.

Aggressive Mode

In ClearSCADA, Aggressive Mode is enabled by default on DNP3 outstations that use DNP3 Secure Authentication. This is because Aggressive Mode provides:

  • A lower level of security than the full ‘Challenge-Response’ mechanism, but sufficient security for most systems
  • Greater communications efficiency, as fewer messages are transmitted.

With Aggressive Mode, the device that sends the critical request or response anticipates a challenge to that request or response. For this reason, it includes the necessary authentication data in the original message.

The receiving device (the ‘Challenger’) has no need to issue a challenge as it has already received the data with which to authenticate the request. The receiving device authenticates the request to confirm that the critical request has genuinely come from that particular DNP3 device. Providing that the message is authentic, the device performs the critical request and sends the appropriate response to the sending device (the ‘Responder’). If the message is not authentic, the receiving device rejects the critical request. The device may then send a diagnostics message indicating a possible security attack.

Aggressive Mode is directional, which means it is applied separately in each direction - ‘Master Station to Outstation’ and ‘Outstation to Master Station’. As Aggressive Mode is directional:

  • A DNP3 device can only issue Aggressive Mode requests once it has received a valid challenge (and replied successfully to that challenge). After the Session Keys expire, or communications are terminated, another valid challenge has to be received before the device can resume issuing Aggressive Mode requests.
  • A DNP3 device can only accept Aggressive Mode requests once it has issued a valid challenge (and received a valid reply to that challenge). After the Session Keys expire, or communications are terminated, the device has to issue another valid challenge before it can resume accepting Aggressive Mode requests.

Communications might cease, for example, due to a server changeover or driver shutdown in the case of direct communications, or at the end of a PSTN call in the case of PSTN communications.

Further Information

Specify whether ClearSCADA accepts Aggressive Mode requests from, or issues Aggressive Mode requests to a DNP3 master outstation: see Specify Whether Aggressive Mode is Used.

Specify whether a DNP3 slave outstation accepts or issues requests using Aggressive Mode: see Specify Whether Aggressive Mode is Used.

Challenge Data

Challenge data is pseudo-random data and is included in certain messages associated with DNP3 Secure Authentication. It is used to ensure that the content of those messages is unpredictable.

Further Information

Define the Challenge Data Length.

‘Challenge-Response’

DNP3 Secure Authentication uses the ‘challenge-response’ security principle to check critical messages. Using this principle, it can detect whether any critical messages transmitted to and/or from a DNP3 outstation are genuine and originate from a known DNP3 device.

With ‘Challenge-Response’, a DNP3 device has to challenge any critical request or response that it receives. The device only performs the critical request, or processes the data that it stored, after it receives an authentic reply to its challenge. For more information, see DNP3 Secure Authentication.

Also see Aggressive Mode.

Further Information

Define Which Function Codes are Critical.

Challenger

With ‘Challenge-Response’, the challenger is the DNP3 device that issues an authentication ‘challenge’ to another DNP3 device, after receiving a critical request or response from that device. The challenger can be a DNP3 master or a DNP3 outstation.

Also see Responder.

HMAC

Each DNP3 device includes a Hash-based Message Authentication Code (HMAC) value in certain messages associated with critical requests or responses. The HMAC value is used to verify the authenticity of each message. The Session Key appropriate to the direction of communication and an HMAC algorithm are used to calculate the HMAC value.

The Challenger specifies which HMAC algorithm the Responder is to use for the HMAC value that it includes:

  • in the reply to the challenge
  • any subsequent Aggressive Mode requests that it issues.

HMAC values are also included in certain messages associated with Session Key Changes. Such messages also include some Challenge Data.

Further Information

Specify the HMAC algorithm used by a DNP3 master outstation: see Specify the Algorithms used to Secure Message Content.

Specify the HMAC algorithm used by a DNP3 slave outstation: see Specify the Algorithms used to Secure Message Content.

Key Wrap

The Key Wrap algorithm is the algorithm that is used to encrypt the Session Keys and Challenge Data during a Session Key Change. Devices that use DNP3 Secure Authentication have to support the Advanced Encryption Standard (AES) AES-128 algorithm. AES-128 is the algorithm that ClearSCADA uses during each Session Key Change.

A pre-shared private Update Key is used in the encryption process.

Further Information

Specify the Key Wrap algorithm used by a DNP3 master outstation: see Specify the Algorithms used to Secure Message Content.

Specify the Key Wrap algorithm used by a DNP3 slave outstation: see Specify the Algorithms used to Secure Message Content.

Responder

With ‘Challenge-Response’, the responder is the DNP3 device that sends a critical request or response to another DNP3 device. The responder then responds or reacts to the authentication challenge that it receives from that device. The responder can be a DNP3 master or a DNP3 outstation.

Also see Challenger.

Session Key

Session Keys are used to authenticate Aggressive Mode requests and any messages that are challenged.

Two Session Keys are in use per outstation at any particular time—one Session Key per communications direction. This means that if a Session Key is compromised in one direction, it does not compromise communications in the other direction.

The DNP3 master initializes the Session Keys on communications start-up (for instance, when the DNP3 driver starts up, or when communications are first established with the outstation). The Session Keys are changed periodically thereafter, to maintain security (see Session Key Change).

On systems on which ClearSCADA is the DNP3 master, the size of the Session Keys is set using the ClearSCADA Server Configuration Tool (see Define the Session Key Length).

Session Key Change

During the Session Key Change process, the DNP3 master generates a new pair of Session Keys and sends an encrypted copy of those Session Keys to the outstation. The DNP3 master encrypts the Session Keys using another key, the Update Key, and a Key Wrap algorithm. The Update Key permits the DNP3 master to change the Session Keys even after a Session Key is compromised.

Session Keys are changed on a regular basis to maintain security. The DNP3 master also initiates a Session Key Change whenever it re-establishes communications with an outstation.

Further Information

Define when ClearSCADA changes the Session Keys on a DNP3 master outstation: see Define When the Session Keys Need to Change.

Specify When the Slave Outstation is to Invalidate its Pair of Session Keys.

Update Key

A pre-shared private Update Key is used, along with a Key Wrap algorithm, to encrypt the Session Keys during the Session Key Change process. ClearSCADA supports one Update Key per outstation (for the ‘Default User’). You set the Update Key using the Set Update Key pick action or method. (With DNP3 devices with which ClearSCADA communicates using a DNP3 Extension Driver, additional means of setting the Update Key may be supported. Any such additional functionality is explained in the relevant DNP3 extension driver guide.)

It is imperative that the Update Key is kept secret and is not stored or transmitted in any way that could permit unauthorized access to the key.


DNP3 Driver Guide - Typical DNP3 Scenarios (Introduction to the DNP3 Driver)

Typical DNP3 Scenarios

This section gives three typical scenarios in which DNP3 devices could be used with
a ClearSCADA system. These scenarios are designed to act as a guide when configuring your own ClearSCADA system to communicate with DNP3 devices—they are not designed to document the many possible scenarios in which DNP3 may be used.

Scenarios in which you would use a DNP3 driver include:

  • ClearSCADA as a DNP3 Master Communicating with DNP3 Outstations
  • Third-Party Master Communicating with a ClearSCADA DNP3 Slave
  • ClearSCADA Configured as a DNP3 Master and DNP3 Slave.

For an example of using a DNP3 master and slave in a Virtual Terminal (VT) scenario, see Configuring DNP3 Virtual Terminals.


DNP3 Driver Guide - ClearSCADA as a DNP3 Master Communicating with DNP3 Outstations (Introduction to the DNP3 Driver)

ClearSCADA as a DNP3 Master Communicating with DNP3 Outstations

Where ClearSCADA uses the DNP3 protocol to retrieve data from its outstations, the ClearSCADA system acts as a DNP3 Master.

For this scenario, within ClearSCADA you need to configure (as appropriate to the type of communications being used):

  • At least one DNP3 Direct Channel and/or DNP3 PSTN Channel
  • At least one DNP3 Direct Outstation Set and/or DNP3 PSTN Outstation Set
  • One DNP3 Direct Outstation or DNP3 PSTN Outstation for each DNP3 outstation with which the ClearSCADA server is to communicate.
  • A DNP3 Point for each point in the DNP3 outstations.

In the diagram below, ClearSCADA is using the DNP3 protocol to communicate with three DNP3 outstations:

Further Information

Scanning for Data on DNP3 Devices

Configuring a DNP3 Channel

Configuring a DNP3 Outstation Set

Configuring a DNP3 Outstation

Points Used on DNP3 Outstations.


DNP3 Driver Guide - Third-Party Master Communicating with a ClearSCADA DNP3 Slave (Introduction to the DNP3 Driver)

Third-Party Master Communicating with a ClearSCADA DNP3 Slave

Where a third-party server uses the DNP3 protocol to retrieve data from ClearSCADA, the ClearSCADA system acts as a Slave Outstation.

For this scenario, within ClearSCADA you need to configure (as appropriate to the type of communications being used):

  • At least one DNP3 Slave Direct Channel and/or DNP3 Slave PSTN Channel
  • At least one DNP3 Slave Direct Outstation Set and/or DNP3 Slave PSTN Outstation Set
  • One DNP3 Slave Direct Outstation or DNP3 Slave PSTN Outstation for each DNP3 outstation that the ClearSCADA server will act as (ClearSCADA may be configured to appear as more than one) outstation.
  • Filtered Value Maps to map values in the ClearSCADA database that will be read by the third party DNP3 master.

The diagram below shows a third party server acting as a DNP3 master to ClearSCADA:

Further Information

Configuring a DNP3 Channel

Configuring a DNP3 Outstation Set

Configuring a DNP3 Slave Outstation

Filtered Value Maps: see Configuring Value Maps in the ClearSCADA Guide to Core Configuration.


DNP3 Driver Guide - ClearSCADA Configured as a DNP3 Master and DNP3 Slave (Introduction to the DNP3 Driver)

ClearSCADA Configured as a DNP3 Master and DNP3 Slave

Where a third-party server uses the DNP3 protocol to obtain data from ClearSCADA, and ClearSCADA uses the DNP3 protocol to obtain its data from an outstation, ClearSCADA becomes dual-purpose, with regard to DNP3. When communicating with the third-party server, ClearSCADA acts as a DNP3 Slave, and when communicating with the outstation, ClearSCADA acts as a DNP3 Master.

In this scenario, you need to configure ClearSCADA as both a DNP3 master (see ClearSCADA as a DNP3 Master Communicating with DNP3 Outstations), and a DNP3 Slave, (see Third-Party Master Communicating with a ClearSCADA DNP3 Slave)

The diagram below shows a third party server acting as a DNP3 master to ClearSCADA, and ClearSCADA acting as a master to a DNP3 outstation. This scenario might be required, for example, should a system have a hierarchical structure, whereby ClearSCADA and/or a third-party server provide control and monitoring features for different subsets of data.


DNP3 Driver Guide - Configuring DNP3 Server Settings

Configuring DNP3 Server Settings

Some driver-specific settings need configuring on the server by a system administrator when a ClearSCADA system is first installed. These settings are configured using the ClearSCADA Server Configuration tool. For information on accessing the ClearSCADA Server Configuration tool, see Configuring Advanced Driver Server Settings in the ClearSCADA Guide to Advanced Drivers.

This section explains the properties on the DNP3 Master and DNP3 Slave sections of the tool.

On systems on which ClearSCADA is the DNP3 master, a system administrator have to use the DNP3 Master section of the tool to:

  1. Define the Maximum Size of Data Packets.
  2. Define the Direct Communications Re-establishment Delay.
  3. Define the DNP3 Master File Transfer Parameters.
  4. Define any additional PSTN Connection Types (see PSTN Connection Types in the ClearSCADA Guide to Advanced Drivers).
  5. Define the DNP3 Master Secure Authentication settings (see Define the Security Settings).
  6. If the server is also operating as a DNP3 slave, configure the settings on the DNP3 Slave section of the tool (see below).
  7. Apply the changes to the server (see Configuring Advanced Driver Server Settings in the ClearSCADA Guide to Advanced Drivers).
  8. If the server is currently running as the main server, restart the DNP3 driver for the other configuration changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).
  9. Repeat steps 1 to 8 for the other servers on your system. (You only need to repeat the steps on any permanent standby servers if you make changes to the PSTN Connection Types.)

On systems on which ClearSCADA operates as a DNP3 slave, a system administrator should use the DNP3 Slave section of the tool to:

  1. Define the Maximum Size of Data Packets.
  2. Define the DNP3 Slave File Transfer Parameters.
  3. Define the DNP3 Slave Secure Authentication settings (see Define the Security Settings).
  4. If the server is also operating as a DNP3 master, configure the settings on the DNP3 Master section of the tool (see above).
  5. Apply the changes to the server (see Configuring Advanced Driver Server Settings in the ClearSCADA Guide to Advanced Drivers).
  6. If the server is currently running as the main server, restart the DNP3 driver for the other configuration changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).
  7. Repeat steps 1 to 6 for the other servers on your system.


DNP3 Driver Guide - Define the Maximum Size of Data Packets (Configuring DNP3 Server Settings)

Define the Maximum Size of Data Packets

The DNP3 driver sends and receives data in packets that are known as Frames. For large amounts of information, more than one frame may need to be transmitted.

DNP3 application messages are broken into fragments. The fragment size is determined by the receiving device’s buffer. For systems operating in environments with high levels of electromagnetic noise, communications are often found to be more successful if the fragment size is further reduced.

Use these fields within the relevant DNP3 section of the tool to specify the maximum size of each frame and fragment:

  • Maximum size of Data Link Frame—Enter the maximum frame, or packet, size that the ClearSCADA DNP3 driver can transmit to the receiving device. You need to enter a value between 100 and 292 (inclusive).

Large amounts of information may need transmitting using more than one frame. Where this occurs, the frames are reassembled into the full message by the receiving device.

  • Maximum size of Application Fragment—Enter the maximum fragment size that the ClearSCADA DNP3 driver can transmit to the receiving device. The size is determined by the receiving device’s buffer, and have to fall within the range of 100 to 2048 (inclusive).

Messages that are larger than one fragment are sent using multiple fragments. Large fragments and multiple fragments are transmitted using more than one frame (for instance, a fragment of 2048 bytes needs breaking into at least 9 frames). Where this occurs, the frames are reassembled into the full message by the receiving device.


DNP3 Driver Guide - Define the Direct Communications Re-establishment Delay (Configuring DNP3 Server Settings)

Define the Direct Communications Re-establishment Delay

Use the Delay after closing line before starting direct comms field in the DNP3 Master section of the tool to specify a delay that allows a DNP3 outstation sufficient time to establish direct communications before receiving any messages:

This delay applies to direct outstations that have been using PSTN fallback to communicate with the server.


DNP3 Driver Guide - Define the DNP3 Master File Transfer Parameters (Configuring DNP3 Server Settings)

Define the DNP3 Master File Transfer Parameters

The DNP3 protocol allows a variety of files to be transferred between the DNP3 master and DNP3 outstations. Use these fields in the DNP3 Master section of the tool to specify the parameters for such file transfers:

  • File transfer request timeout—Use this field to specify the time that the server allows for file requests, such as those executed using the Download File pick action, to complete. The time specified in this field is added to the Request timeout extension time (specified in the Drivers section of the ClearSCADA Server Configuration tool) to determine whether a file transfer request is taking longer than expected to complete and should time out.

The time specified for the File transfer parameter needs to be sufficiently long enough for the expected upload/download file sizes and the speed of the communications link(s). The default setting is 20 minutes.

  • Specify the folder where the files will be uploaded to and downloaded from—Use this field to specify the folder that is used to store files for uploading to, or downloading from, this DNP3 master. The folder is only used for files being transferred from or to outstations that support the Legacy g70v1 File Transfer routine (see Specify Which File Transfer Routines an Outstation Supports).

Use the Browse button adjacent to the field to display a Reference browse window, and choose the required file location. On multi-server systems, the relevant files are uploaded to or downloaded from this location on whichever ClearSCADA server is the main server at the time. For information on uploading and downloading DNP3 files, see Actions Associated with DNP3 Outstations.


DNP3 Driver Guide - Define the DNP3 Slave File Transfer Parameters (Configuring DNP3 Server Settings)

Define the DNP3 Slave File Transfer Parameters

The DNP3 protocol allows a variety of files to be transferred between the DNP3 master and DNP3 outstations. Use this field in the DNP3 Slave section of the tool to specify the parameters for such file transfers:

  • Specify the folder that the Slave will use for file transfer—Use this field to specify the folder that is used to store files that the DNP3 Slave is to transfer to, or receive from, its DNP3 master. This folder only applies when ClearSCADA is a DNP3 Slave and the supported File Transfer routine is Legacy g70v1.

Use the Browse button adjacent to the field to display a Reference browse window, and choose the required file location.


DNP3 Driver Guide - Define the Security Settings (Configuring DNP3 Server Settings)

Define the Security Settings

The DNP3 Master and DNP3 Slave sections of the ClearSCADA Server Configuration Tool each include a Security section. Use the sections to define the server-wide DNP3 Secure Authentication properties.

ClearSCADA applies:

  • The DNP3 Master section’s Security settings to DNP3 master outstations on which DNP3 Secure Authentication is enabled (see Specify Whether DNP3 Secure Authentication is Used).

Use the DNP3 Master’s Security section to:

  • Define the Challenge Data Length
  • Define the Session Key Length
  • Define Which Function Codes are Critical.
  • The DNP3 Slave section’s Security settings to DNP3 slave outstations on which DNP3 Secure Authentication is enabled (see Specify Whether DNP3 Secure Authentication is Used). Slave outstations allow ClearSCADA to operate as a DNP3 Slave (see Third-Party Master Communicating with a ClearSCADA DNP3 Slave).

Use the DNP3 Slave’s Security section to:

  • Define the Challenge Data Length
  • Define Which Function Codes are Critical.


DNP3 Driver Guide - Define the Challenge Data Length (Configuring DNP3 Server Settings)

Define the Challenge Data Length

Challenge Data is pseudo-random data that is included in certain types of message associated with DNP3 Secure Authentication. The challenge data changes randomly, so increasing the security of the message’s content by making each message unpredictable.

ClearSCADA generates the random challenge data using FIPS 186-2 including Change Notice 1, a pseudo random number generator application used by the U.S. Federal government.

Use the Challenge Data Length field in the relevant DNP3 Security section of the ClearSCADA Server Configuration Tool to specify the number of bytes of pseudo-random data that is included in each message.

Specify the required random data length in the range of 4 to 40 bytes inclusive. The specified amount of random data is included in the relevant messages.


DNP3 Driver Guide - Define the Session Key Length (Configuring DNP3 Server Settings)

Define the Session Key Length

With DNP3 Secure Authentication, two Session Key s are required. One Session Key authenticates data transmitted in the monitoring direction (from a DNP3 outstation to its DNP3 master); the other Session Key authenticates data transmitted in the controlling direction (from the DNP3 master to a DNP3 outstation).

Use the Session Key Length field in the DNP3 Master’s Security section of the ClearSCADA Server Configuration Tool to specify the length of both Session Keys.

Specify a Session Key length that is supported by each of the DNP3 outstations on your system. The minimum length that you can specify is 128 bits.

For systems on which ClearSCADA is the DNP3 master, ClearSCADA generates Session Keys of the specified length using FIPS 186-2 including Change Notice 1.

Further Information

Session Key Change.


DNP3 Driver Guide - Define Which Function Codes are Critical (Configuring DNP3 Server Settings)

Define Which Function Codes are Critical

With devices that use DNP3 Secure Authentication, any request to perform a function that is deemed to be critical is ‘challenged’. Such a request is only processed once the correct reply has been received to that challenge. (With Aggressive Mode, the sending device anticipates a challenge and so includes the necessary authentication data in the same message as the critical request.)

Use the check boxes in the relevant DNP3 Security section of the ClearSCADA Server Configuration Tool to specify which function codes are deemed to be critical.

The DNP3 standard requires certain function codes (such as ‘Cold Restart’) to always be deemed critical. The check boxes for these function codes are ‘grayed out’ to indicate that they cannot be cleared.

With the remaining check boxes, select the boxes of those function codes that are critical. Ensure that the check boxes of any non-critical function codes are clear. Non-critical function codes are processed in the normal way without being challenged or sent using Aggressive Mode.

NOTE: With DNP3 devices with which ClearSCADA communicates using a DNP3 Extension Driver, that extension driver may have further mandatory critical function codes to those shown in the figure above. Use the relevant section of the ClearSCADA Server Configuration Tool to specify the criticality of such function codes. The relevant DNP3 extension driver guide will mention any server settings that are specific to the extension driver.

Use the check boxes on the DNP3 Master section of the ClearSCADA Server Configuration Tool to determine the criticality of function codes for systems on which ClearSCADA is the DNP3 master. Set the function codes’ criticality so that it matches that of your outstations. For example, if your outstations are configured to challenge ‘Read’ requests, select the ‘Read’ check box on the DNP3 Master section of the Tool. With this section of the Tool, all but the last two check boxes determine the criticality of function codes that ClearSCADA sends to any DNP3 outstations and therefore which functions ClearSCADA sends using Aggressive Mode. The last two check boxes (‘Response’ and ‘Unsolicited Response’) determine the criticality of, and therefore whether ClearSCADA challenges, the solicited and unsolicited responses that it receives from the DNP3 outstations.

Use the check boxes on the DNP3 Slave section of the ClearSCADA Server Configuration Tool to determine the criticality of function codes for systems on which ClearSCADA is operating as a DNP3 slave. Set the function codes’ criticality so that it matches that of your DNP3 master(s). For example, if your DNP3 master(s) are configured to challenge ‘Unsolicited Responses’, select the ‘Unsolicited Responses’ check box on the DNP3 Slave section of the Tool. With this section of the Tool, all but the last two check boxes determine the criticality of function codes that ClearSCADA receives from its DNP3 master(s) and therefore which function codes ClearSCADA challenges. The last two check boxes (‘Response’ and ‘Unsolicited Response’) determine the criticality of solicited and unsolicited responses that ClearSCADA sends to its DNP3 master(s) and therefore whether the Slave (ClearSCADA) sends those functions using Aggressive Mode.

Further Information

Configure a DNP3 master outstation to use Aggressive Mode: see Specify Whether Aggressive Mode is Used.

Configure a DNP3 slave outstation to use Aggressive Mode: see Specify Whether Aggressive Mode is Used.


DNP3 Driver Guide - Scanning for Data on DNP3 Devices

Scanning for Data on DNP3 Devices

The way in which the ClearSCADA DNP3 driver interrogates DNP3 devices for data differs to that of other advanced drivers.

This section summarizes the various features that are associated with such interrogation and includes information on:

  • DNP3 Integrity and Data Classes
  • DNP3 Event Polls
  • DNP3 IIN Flags
  • Unsolicited Messages
  • Outstation Clock
  • Scanning Direct Outstations on the DNP3 Driver
  • Configuration Requirements.

Further Information

DNP3 Secure Authentication.


DNP3 Driver Guide - DNP3 Integrity and Data Classes (Scanning for Data on DNP3 Devices)

DNP3 Integrity and Data Classes

Data on a DNP3 outstation is assigned a Class. ClearSCADA is able to poll for the data in each class independently of other classes.

An Integrity Poll causes an outstation to return any event data that is stored in its internal buffers. Use the Integrity Polling section on the Outstation Form to specify whether ClearSCADA issues DNP3 Integrity Polls to an outstation. By default, ClearSCADA also polls for Class 1, 2, or 3 data (see below) at the same time as it polls for Class 0 data. For Direct and Shared outstations, also use the Integrity Polling section to specify when ClearSCADA polls for Class 0 static data (see Specify When ClearSCADA Performs Integrity Polls). For PSTN-only outstations, issue a One Shot or Open Line action for ClearSCADA to dial the outstation.

ATTENTION: The DNP3 standard dictates that data for a DNP3 point has to be transmitted in chronological order. If you configure a point in the outstation to generate DNP3 events, it is inadvisable to perform Class 0 Only Polls of the outstation. (A Class 0 Only Poll of a point will return the point’s current value without any preceding DNP3 event data. It is therefore possible to return the value of such a point out-of-order.)

A Class 1, Class 2, or Class 3 Poll causes an outstation to return event data for the points that are assigned those particular Class(es). Use the individual Class n Polling sections on the Outstation Form to specify whether ClearSCADA issues DNP3 Class Polls for a given class to an outstation. For Direct and Shared outstations, also use each Class n Polling section to specify when ClearSCADA polls an outstation for each class of event data (see Specify When ClearSCADA Performs Class Polls). For PSTN-only outstations, issue a One Shot or Open Line action for ClearSCADA to dial the outstation.

Data is assigned to a specific class at the outstation. (If the DNP3 driver is being used for ‘transparent’ transmission of data between DNP3 devices, you also need to assign VT event data to an appropriate class, and Configure Virtual Terminal Support on the Outstation Form.

You can use the Class n Poll Statistics attribute on each DNP3 outstation’s Status display to ascertain the number of attempted and successful DNP3 Class Event Polls that the DNP3 driver has issued since the statistics were last reset.

In addition to Class polls, the DNP3 driver is able to issue polls for specific DNP3 types of data, such as analog input events, or static String Point data. For more information, see DNP3 Event Polls, or see Specify Whether ClearSCADA Polls an Outstation for Static String Point Data, as applicable.


DNP3 Driver Guide - DNP3 Event Polls (Scanning for Data on DNP3 Devices)

DNP3 Event Polls

This section applies to outstations that support DNP3 Level 2 only.

In addition to Class Polls (see DNP3 Integrity and Data Classes), the DNP3 driver is capable of issuing DNP3 Event Polls for specific binary, analog and/or counter events.

Configure DNP3 Event Scanning using the fields within the Event Scanning section of the DNP3 Outstation Form.

Configure the Scan Group Intervals that are associated with each type of event, using the Scan Groups fields on the DNP3 Channel Form.

Whenever an Event Scan Group timer expires, the driver requests that the outstation sends, in chronological order, the events that are associated with that point type.


DNP3 Driver Guide - DNP3 IIN Flags (Scanning for Data on DNP3 Devices)

DNP3 IIN Flags

Every data packet that a DNP3 outstation sends to the DNP3 master (ClearSCADA) includes various DNP3 flags (internal indications). You can specify how ClearSCADA handles these flags.

To specify how ClearSCADA handles the Events Available IIN Bit, see Specify When ClearSCADA Performs Class Polls. The DNP3 standard recommends that events are recovered whenever an outstation indicates that they are available. However, you may want to limit this functionality on systems that have limited bandwidth or a high latency network.

To specify how ClearSCADA handles the IIN Bit(s) that are transmitted if a problem is detected at the outstation, see Specify the IIN Severity.

To specify how ClearSCADA handles the Respond to Need Time IIN, see Define Whether ClearSCADA Updates the Outstation Clock.

In addition to displaying alarms or events whenever an outstation’s IIN bits are set, each outstation’s Status display also indicates whether these DNP3 flags are set:

  • Already Executing Alarm
  • Configuration Corrupt Alarm
  • Device Trouble Alarm
  • Event Buffer Overflow Alarm
  • IIN Status
  • Protocol Alarm.

(For more information on Status displays, see DNP3 Specific Status Display Attributes, and the ClearSCADA Guide to ViewX and WebX Clients.)

A further DNP3 IIN bit, LOCAL_CONTROL, indicates whether any output points are in local operation mode. Whenever this bit is reported as being set, ClearSCADA logs a Points in Local Operation event in the Event Journal. Whenever a point is in local operation mode, any control commands sent from ClearSCADA might not execute successfully. See the outstation documentation for information on clearing the LOCAL_CONTROL IIN bit.


DNP3 Driver Guide - Unsolicited Messages (Scanning for Data on DNP3 Devices)

Unsolicited Messages

Some DNP3 outstations have the capability to report event data to the DNP3 master (for instance ClearSCADA) independently of that master’s polling cycles. The outstations report such event data to the master by transmitting unsolicited messages.

Use the Enable Unsolicited Messages section on the DNP3 Outstation Form to specify:

  • Whether an outstation is allowed to transmit unsolicited messages
  • The data classes for which it is able to transmit such messages.

For more information, see Enable Unsolicited Message Generation.

In addition to the above, Enable Unsolicited Events and Disable Unsolicited Events pick actions can be used to enable or disable unsolicited events on an outstation, as required.

If the outstations use DNP3 Secure Authentication:

  • On systems on which ClearSCADA is the DNP3 master, use the Unsolicited Response check box in the DNP3 Master section of the ClearSCADA Server Configuration Tool to specify whether unsolicited messages are challenged.
  • On systems on which ClearSCADA operates as a DNP3 slave, use the Unsolicited Response check box in the DNP3 Slave section of the ClearSCADA Server Configuration Tool to specify whether ClearSCADA sends unsolicited messages using Aggressive Mode.

For more information on either section of the ClearSCADA Server Configuration Tool, see Define Which Function Codes are Critical.

You can use the Unsolicited Event Reporting Status attribute to ascertain which unsolicited event classes are enabled and disabled in an outstation.


DNP3 Driver Guide - Outstation Clock (Scanning for Data on DNP3 Devices)

Outstation Clock

ClearSCADA is able to set a Direct or Shared outstation’s internal clock on a regular basis, or by request. Use the Set Outstation Clock section on the Direct Channel Form to Configure the Set Outstation Clock Properties.

The DNP3 protocol allows an outstation to indicate that its internal clock is not up to date, as a means of requesting that the DNP3 master (ClearSCADA) to set the clock. Use the Set the Clock section on the Outstation Form to Define Whether ClearSCADA Updates the Outstation Clock. This latter function applies to PSTN outstations as well as Direct and Shared outstations.


DNP3 Driver Guide - Scanning Direct Outstations on the DNP3 Driver (Scanning for Data on DNP3 Devices)

Scanning Direct Outstations on the DNP3 Driver

This section describes how the DNP3 driver scans (polls) Direct and Shared outstations for data.

(The way in which ClearSCADA retrieves data from outstations that communicate via PSTN differs to the way in which it retrieves data from outstations that have a permanent (‘direct’) connection to the server. For information on scanning PSTN outstations, see Retrieving Data from PSTN Outstations in the ClearSCADA Guide to Advanced Drivers.)

The types of scan that the DNP3 driver can perform are:

  • Establishment Scan
  • Normal Scan
  • Level 3 Scan.


DNP3 Driver Guide - Establishment Scan (Scanning for Data on DNP3 Devices)

Establishment Scan

When the ClearSCADA server has not been in communications with a DNP3 outstation, ClearSCADA performs an Establishment Scan rather than a Normal Scan. ClearSCADA performs an Establishment Scan, for example, at system start-up, or when communications to an outstation has previously failed.

ClearSCADA also performs an Establishment Scan whenever it opens a connection to a DNP3 outstation for which direct communications is available:

  • On Demand (see Specify Whether the Direct Communications Connection is Always Online or only Available on Demand)
  • On a Periodic basis, when establishing communications with the outstation at the start of each period during which communications are available (see Specify the Availability of Communications Between the Outstation and ClearSCADA in the ClearSCADA Guide to Advanced Drivers).

(With an outstation for which Communications Availability is on a Periodic basis, comms persists for the period and then ceases at the end of that period.)

  • On Demand on a Periodic basis, whenever an action necessitates a connection to be opened.

Performing an action such as a Refresh or Control on an On Demand outstation that is currently offline will trigger ClearSCADA to perform an Establishment Scan, execute the required actions, and then close the connection. Such actions are only available during the outstation’s Communications Availability period—any attempt to trigger the actions outside of the outstation’s Communications Availability period will result in the requests being rejected.

With an Establishment Scan, the driver:

  1. Disables the outstation’s Unsolicited Messages feature (if that feature is supported by the outstation).
  2. Restores the values of the outstation’s output points if the Restart IIN flag is set in the outstation (and if configured to do so—see Configure the DNP3-Specific Control Properties on DNP3 Output Points).
  3. Reads the outstation’s Device Attributes (if configured to do so—see Configure the Actions that Occur on Communications Startup).
  4. Set the outstation’s clock (if configured to do so)—see Define Whether ClearSCADA Updates the Outstation Clock.
  5. Performs an Integrity Poll of the outstation.

The poll requests the outstation to send its Class 1, 2, and 3 event data and Class 0 static (current value) data in chronological order, to the server.

  6. Re-enables the outstation’s Unsolicited Messages feature (if supported by the outstation, unless that outstation is configured not to send unsolicited messages).


DNP3 Driver Guide - Normal Scan (Scanning for Data on DNP3 Devices)

Normal Scan

NOTE: For outstations for which communications is On Demand or Periodic, see Establishment Scan.

The DNP3 driver can routinely perform various polls—an Integrity Poll, a Class 1 Poll, a Class 2 Poll, a Class 3 Poll, and/or a poll for Static String Point Data. You specify the frequency of each poll using the relevant fields on the Outstation Form.

During an Integrity Poll, the driver requests the outstation to send its Class 1, 2, and 3 event data and Class 0 static (current value) data in chronological order. (The Integrity Polling procedure differs whenever ClearSCADA first establishes communications with a Direct or Shared outstation—see Establishment Scan.)

During a Class Poll, the driver requests the event data for that particular class.

During a String Points Poll, the driver retrieves static (current value) data for string points on an outstation. (String data can also be retrieved using a string point’s Read String pick action.)

An Integrity Poll is typically used to ‘synchronize’ the DNP3 master and slave databases and therefore tends to be assigned a slow poll rate. Class 1, 2, and 3 polls are typically used to retrieve individual class events at varying rates, depending on the importance of those events, with the more critical events being assigned to the classes that have the faster poll rate.

As DNP3 event data is reported by the outstation in chronological order, alarms for the point might raise and clear multiple times during a single poll, as the ClearSCADA server processes each individual event.

Example:

A DNP3 outstation includes this configuration:

Integrity Polling:
Interval: 1D
Offset: Day + 1 Hour

Class 1 Polling:
Interval: 5S
Offset: M

Class 2 Polling:
Interval: 30S
Offset: M

Class 3 Polling:
Interval: 5M
Offset: H

Critical binary events are assigned Class 1.
Important analog events are assigned Class 2.
Other events are assigned Class 3.

With the above setup, ClearSCADA scans the outstation at five-second intervals for Class 1 events, at 30-second intervals for Class 2 events and at five-minute intervals for Class 3 events. Additionally, at 01:00:00.000 each day, ClearSCADA performs an Integrity poll on the outstation.

NOTE: Some systems depend on outstations sending Unsolicited Messages to report event data to ClearSCADA, rather than on regular polling of those outstations. On such systems, if too much bandwidth is being consumed, consider reducing the rate at which the DNP3 driver polls those outstations for event data.

Further Information

DNP3 Integrity and Data Classes.

Specify When ClearSCADA Performs Integrity Polls.

Specify When ClearSCADA Performs Class Polls.

Specify Whether ClearSCADA Polls an Outstation for Static String Point Data.


DNP3 Driver Guide - Level 3 Scan (Scanning for Data on DNP3 Devices)

Level 3 Scan

ATTENTION: If you configure a point in the outstation to generate DNP3 events (see DNP3 Integrity and Data Classes), it is not advisable to perform DNP3 Level 3 Scans for that point. (The DNP3 standard dictates that event data for a DNP3 point has to be transmitted in chronological order. As a DNP3 Level 3 Scan returns a point’s current value without any preceding DNP3 event data, the value of the point may be returned out-of-order.)

If point data is not retrieved from a DNP3 outstation by other means, such as an Integrity Poll, you can retrieve that data using the Perform Level 3 Scan pick action.

In order to retrieve Class 0 static (current value) data in this way, you need to:

  • Enable Level 3 Scan functionality on the Point’s Form
  • Configure the point to have a suitable Scan Group (Confidence Poll).

For more information on either of the above, see Configure General Point Properties.

  • Use the Perform Level 3 Scan pick action to specify that the driver is to poll the outstation for the point data that is assigned the above Scan Group.

ClearSCADA retrieves any DNP3 Status Point data by performing a Level 3 scan.

Level 3 Scans do not apply to DNP3 Pulse Actions.

(With points that are assigned a Scan Group (Confidence Interval) but are excluded from Level 3 Scans, the DNP3 driver does not schedule a poll of the outstation when the Scan Group timer expires. Instead, it updates the point’s value with the response to the next scheduled Integrity Poll.)


DNP3 Driver Guide - Configuration Requirements (Scanning for Data on DNP3 Devices)

Configuration Requirements

To define the DNP3 scanning requirements on your system, you need to undertake a combination of:

  • Server Configuration
  • Channel Configuration
  • Outstation Set Configuration
  • Outstation Configuration
  • Point Configuration
  • Status Point Configuration.


DNP3 Driver Guide - Server Configuration (Scanning for Data on DNP3 Devices)

Server Configuration

Use the relevant DNP3 section of the ClearSCADA Server Configuration Tool to:

  • Define the Maximum Size of Data Packets
  • Define the Direct Communications Re-establishment Delay
  • If the outstations use DNP3 Secure Authentication, Define the Security Settings.


DNP3 Driver Guide - Channel Configuration (Scanning for Data on DNP3 Devices)

Channel Configuration

Use each DNP3 Channel Form to:

  • Configure the Scan Parameters
  • Configure the Communications Statistics Update Rate (see Defining the Communication Statistics Update Rate in the ClearSCADA Guide to Advanced Drivers)
  • Configure the Communications Parameters
  • Configure the Pre-Amble and Post-Amble Message Strings.

Additionally, on DNP3 Direct Channels, you can:

  • Configure the Scan Group Intervals
  • Configure the Set Outstation Clock Properties.


DNP3 Driver Guide - Outstation Set Configuration (Scanning for Data on DNP3 Devices)

Outstation Set Configuration

Use each DNP3 Outstation Set Form to:

  • Specify the Address of a DNP3 Master Set.


DNP3 Driver Guide - Outstation Configuration (Scanning for Data on DNP3 Devices)

Outstation Configuration

Use each DNP3 Outstation Form to specify various properties associated with scanning of the outstation’s data—for a comprehensive list of these properties, see Configuring a DNP3 Outstation.


DNP3 Driver Guide - Point Configuration (Scanning for Data on DNP3 Devices)

Point Configuration

Use each DNP3 Point Form to:

  • Configure General Point Properties
  • Configure Logged Data Properties.

With DNP3 Output Points, you can also:

  • Specify which Outstations are Integrity Polled after a Successful Control.


DNP3 Driver Guide - Status Point Configuration (Scanning for Data on DNP3 Devices)

Status Point Configuration

If ClearSCADA is to retrieve internal status information from a DNP3 device, consider whether to configure DNP3 Status Points in the ClearSCADA database (see Configuring DNP3 Status Points), or individual DNP3 points (see Points Used on DNP3 Outstations).

If you use the former, use each DNP3 Status Points Form to:

  • Specify the Scan Group that is Associated with the Status Data Retrieval.


DNP3 Driver Guide - Configuring a DNP3 Channel

Configuring a DNP3 Channel

You configure DNP3 Channels in the ClearSCADA database to represent the physical communication mechanisms between ClearSCADA and the DNP3 outstations on your system. The ClearSCADA DNP3 Driver supports these types of DNP3 Channel:

  • DNP3 Direct Channel—Used when ClearSCADA is the master DNP3 device and connects to the DNP3 outstations directly (for example by serial cable, IP network, or radio).

If your system setup allows, you can configure outstations that are connected via direct channels to use PSTN as a backup means of communication if the direct channel fails.

  • DNP3 PSTN Channel—Used when ClearSCADA is the master DNP3 device and connects to the DNP3 outstations using dial-up modems.
  • DNP3 Slave Direct Channel—Used when ClearSCADA is configured as a slave DNP3 device and other DNP3 devices connect to ClearSCADA directly (for example by serial cable, IP network, or radio).
  • DNP3 Slave PSTN Channel—Used when ClearSCADA is configured as a slave DNP3 device and other DNP3 devices connect to ClearSCADA using dial-up modems.

You specify the properties of a DNP3 channel using the fields on the DNP3 Direct Channel, DNP3 PSTN Channel, DNP3 Slave Direct Channel, or DNP3 Slave PSTN Channel Form, as appropriate.

Each Form has several tabs.

This section covers configuration of DNP3-specific properties on the Scan Parameters tab.

For each type of DNP3 Channel, you use the Scan Parameters tab to:

  • Configure the Scan Parameters
  • Configure the Communications Statistics Update Rate (see Defining the Communication Statistics Update Rate in the ClearSCADA Guide to Advanced Drivers)
  • Configure the Communications Parameters
  • Configure the Pre-Amble and Post-Amble Message Strings.

NOTE: Some Scan Parameters defined by the ClearSCADA advanced driver model are not used by the ClearSCADA DNP3 driver. You can use the configuration forms to disable unused properties.

For DNP3 Direct Channels, you also use the Scan Parameters tab to:

  • Configure the Scan Group Intervals
  • Configure the Set Outstation Clock Properties.

Properties on the other tabs are common to channels on many advanced drivers—for information, see Tabs on Channel Forms in the ClearSCADA Guide to Advanced Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional DNP3 Channel in ClearSCADA, see Minimum Configuration.


DNP3 Driver Guide - Minimum Configuration (Configuring a DNP3 Channel)

Minimum Configuration

As a minimum, you need to configure the following for each DNP3 channel:

  • Any Pre/Post-Amble message strings
  • For channels that have a Serial Connection, the port to which the channel is connected
  • For channels that have a Remote Serial Connection, the host name of the machine that is running the Port Server application, and the port to which the channel is connected
  • For channels that have a TCP/IP Connection, the TCP/IP Type, the host address and the port to which the channel is connected
  • For channels that have a Network Connection, the TCP/IP type. (Network configuration is not applicable to PSTN channels.)
  • The Telephone number (PSTN channels only).

You also need to put the channel In Service if you want the channel to be functional (online), and you will need to save the configuration.

Applying these minimum requirements will provide a functional DNP3 channel that uses the default configuration settings.


DNP3 Driver Guide - Configure the Scan Parameters (Configuring a DNP3 Channel)

Configure the Scan Parameters

Use the fields within the Scan Parameters section of the Scan Parameters tab to configure the basic communications settings for the channel. The fields are common to channels on many advanced drivers (see Defining Scan Parameter Settings for a Channel in the ClearSCADA Guide to Advanced Drivers).

As the DNP3 protocol has a more detailed communications structure than the standard advanced driver model, we advise that you enable Communications Parameters (see Configure the Communications Parameters). This is because Communications Parameters provide more detailed settings than are provided in the Scan Parameters section.

If Communications Parameters are enabled, the Comms Retries and Standard Reply Delay settings are ignored by the ClearSCADA DNP3 driver.


DNP3 Driver Guide - Configure the Scan Group Intervals (Configuring a DNP3 Channel)

Configure the Scan Group Intervals

This section applies to DNP3 Direct Channels only.

Use the fields within the Scan Groups section of the Scan Parameters tab to define the intervals of the eight scan group timers.

Use each Scan n field to specify the interval of the timer that is associated with that Scan Group. Enter the time in the OPC Time Format, for example 10S (for 10 seconds).

You can use Scan groups to:

  • Group points that are regularly updated in the ClearSCADA database. For further information, see Configure General Point Properties in this guide and see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers.
  • Periodically perform DNP3 outstation Event Scanning. For further information, see Configure DNP3 Event Scanning.

Scan group timers are synchronized to midnight.


DNP3 Driver Guide - Configure the Set Outstation Clock Properties (Configuring a DNP3 Channel)

Configure the Set Outstation Clock Properties

This section applies to DNP3 Direct Channels only.

Use the fields within the Set Outstation Clock section of the Scan Parameters tab to specify how often ClearSCADA updates the clocks of DNP3 outstations attached to the channel.

By default the Interval and Offset are set to zero on DNP3 channels. This is to disable regular clock setting and force each DNP3 outstation to request the server to set its clock.

Change the settings from the default if the ClearSCADA server is to set the clocks of the outstations on this channel on a regular basis, rather than depend on the outstations to request that their clocks be set.

For further information, see Define when the Server Sets the Outstations’ Clocks in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Configure the Communications Parameters (Configuring a DNP3 Channel)

Configure the Communications Parameters

The DNP3 protocol defines two layers for which timing has to be configured:

  • Data Link Layer—This layer handles the transmission of frames over physical communication links between the DNP3 devices. The Data Link layer helps to provide reliable transmission by implementing error and duplicate frame detection.
  • Application Layer—This layer manages large messages, such as file and event buffer transfers. The Application layer splits large messages into fragments. which consist of one or more frames and data formatting.

Use the fields within the Communications Parameters section of the Scan Parameters tab to specify:

  • Whether some of the properties within the Scan Parameters section (see Configure the Scan Parameters) are overridden by the Communications Parameters properties.
  • The DNP3 timing for the Data Link and Application Layers.

NOTE: A channel’s Communications Parameters properties can be overridden on a per outstation basis (see Specify Different Communications Parameters for an Individual Outstation). The Communications Parameters that you define on the Channel Form are usually appropriate for communications between the master station and outstations, as long as the outstations all use the same communications path. However, if there are outstations that use a different communications path, for example, outstations that communicate via a gateway, you may need to override the channel Communications Parameters in the outstations’ configuration. This will allow the outstations that use a different communications path to apply different communications parameters.

  • Enabled—Select this check box to override several properties within the Scan Parameters section (see Configure the Scan Parameters) with the properties in this section.

Clear the check box if all of the properties in the Scan Parameters section are to apply to this channel. The rest of the fields within the Communications Parameters section are ‘grayed out’ and unavailable for use.

  • Request Data Link Confirmation—Use this combo box to specify when ClearSCADA requests confirmation of Data Link frames from an outstation.

Choose from:

  • Never—The ClearSCADA DNP3 driver does not request confirmation of Data Link frames.
  • Sometimes—The ClearSCADA DNP3 driver requests confirmation of Data Link frames, but only if the Application Layer fragment consists of more than one frame.

This is the recommended option.

  • Always—The ClearSCADA DNP3 driver always requests confirmation of Data Link frames.

Select this option if the DNP3 devices that are using this channel are operating in a environment with a high level of electromagnetic noise that affects communications.

  • Data Link Retries—Use this field to specify the number of times that the ClearSCADA DNP3 driver is to re-send Data Link frames for which it has requested a confirm, and does not receive the confirm within the Data Link Timeout.

If the ClearSCADA DNP3 driver does not receive the confirmation within the Data Link Timeout, the Data Link frame is re-sent. If the frame is not confirmed before the timeout of the last retry, the transmission of the frame is deemed to have failed.

  • Data Link Timeout—Use to specify how long the ClearSCADA DNP3 driver is to wait for a Data Link confirmation from the outstation, before re-sending the frame.

NOTE: The Data Link Retries and Data Link Timeout fields are not available if Request Data Link Confirmation is set to Never.

  • Application Fragment Attempts—Use to specify the number of times that the ClearSCADA DNP3 driver is to attempt to send an Application Layer request. If this parameter is set to a value greater than one, ClearSCADA makes further attempt(s) to send a request, if it does not receive a response within the Application Fragment Timeout.

NOTE: This field specifies the number of attempts, not the number of retries. This field has to be set to a value of at least 1.

  • Application Fragment Timeout—Use to specify how long the ClearSCADA DNP3 driver is to wait for an Application Layer response from the outstation, before re-sending the request. Be aware that:
  • When the ClearSCADA DNP3 driver sends a request, the Application Fragment Timeout timer is not started until the last Data Link frame is sent
  • Whenever the ClearSCADA DNP3 driver receives a Data Link frame associated with an Application Layer request, the Application Fragment Timeout timer is restarted

For these reasons, it is unnecessary to set the Application Fragment Timeout to large values to account for multi-frame requests.

Set the Application Fragment Timeout so that it is large enough to allow for any Data Link retries. It should be set to at least:

((Data Link Retries + 1) * Data Link Timeout) + 1000

For example, if you have Data Link Retries set to 2 and Data Link Timeout set to 3000 milliseconds, you should set Application Fragment Timeout to at least 10000 milliseconds (as (2 + 1) * 3000 + 1000 = 10000).

Example:

Consider a radio channel with the following configuration:

Request Data Link Confirmation = Sometimes

Data Link Retries = 2

Data Link Timeout = 1000 milliseconds

Application Fragment Attempts = 2

Application Fragment Timeout = 10000 milliseconds

ClearSCADA issues a DNP3 Integrity Poll request to a DNP3 outstation that has a large number of events stored in its event buffer(s).

The request from ClearSCADA is a single DNP3 Data Link frame, therefore ClearSCADA does not request a Data Link confirm from the outstation.

After the request has been sent by the ClearSCADA DNP3 driver, its Application Fragment Timeout timer starts.

While the ClearSCADA DNP3 driver is receiving frames from the outstation every 10 seconds or less, the Application Fragment Timeout timer does not expire, even though it might take the outstation more than 10 seconds to send the events to ClearSCADA.


DNP3 Driver Guide - Configure the Pre-Amble and Post-Amble Message Strings (Configuring a DNP3 Channel)

Configure the Pre-Amble and Post-Amble Message Strings

Use the fields within the Pre/Post Amble section of the Scan Parameters tab to define any additional bytes that are transmitted before and after each DNP3 frame that is sent over a communications channel.

The bytes defined within this section are the default bytes that are applied if no Pre-Amble and Post-Amble bytes are specified on an outstation’s configuration Form (see Specify Different Pre- and Post-Amble Message Strings for an Individual Outstation).

In many cases, you will not need to specify any pre-amble or post-amble bytes. However, you might need to specify additional bytes to activate a particular communications channel, or to provide extra time to synchronize the channel.

  • Pre-Amble—Use to specify the bytes that are transmitted before each DNP3 frame.
  • Post-Amble—Use to specify the bytes that are transmitted at the end of each DNP3 frame.

Specify both the Pre-Amble and Post-Amble in hexadecimal format.

Example 1:

ClearSCADA is to communicate with a number of DNP3 outstations over a radio network that supports data streams. A data stream is specified using a specific pair of bytes (a Stream ID) at the start of each transmission. Stream 13 (decimal) is to be used for the DNP3 communications between ClearSCADA and the outstations. The Pre-Amble of the channel is therefore set to 0D (as 0D is the hexadecimal equivalent of the decimal number 13).

Example 2:

ClearSCADA is to communicate with a DNP3 outstation using a dial-up modem. After some initial testing, it has been found that the phone line and modem combination sometimes corrupts the first few bytes of a transmission. The Pre-Amble is used to ‘pad’ each transmission with a specified number of bytes that are discarded by the receiving device.

Example 3:

ClearSCADA is to communicate with a DNP3 outstation using analog radio. The radio needs time to power up at the start of each transmission. The Pre-Amble FFFF is used to allow the radio time to power up.

ATTENTION: We advise that you do not use a Pre- or Post-Amble of 0564, as the DNP3 protocol uses 0564 to indicate the start of a DNP3 frame.

For more information, see Defining any Default Pre- and Post-Amble Message Settings for a Channel in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Configuring a DNP3 Outstation Set

Configuring a DNP3 Outstation Set

The ClearSCADA DNP3 Driver supports these types of DNP3 outstation set:

  • DNP3 Direct Outstation Set—Used when ClearSCADA is the master DNP3 device and connects to the DNP3 outstations directly (for example by serial cable, IP network, or radio). If your system setup allows, you can configure outstations that are in a DNP3 Direct Outstation Set to use PSTN for backup communications in the event that the direct channel fails.
  • DNP3 PSTN Outstation Set—Used when ClearSCADA is the master DNP3 device and connects to the DNP3 outstations using dial-up modems.
  • DNP3 Shared Outstation Set—Used when redundant direct connections exist from the ClearSCADA server to the DNP3 outstation. Each outstation in the set can use either channel to communicate with the ClearSCADA server. If your system setup allows, you can configure outstations that are in a DNP3 Shared Outstation Set to use PSTN for backup communications in the event that both direct channels fail.
  • DNP3 Switched Outstation Set—Used when redundant direct connections exist from the ClearSCADA server to the DNP3 outstation. All of the outstations in the set use the same channel at the same time. If your system setup allows, you can configure outstations that are in a DNP3 Switched Outstation Set to use PSTN for backup communications in the event that both direct channels fail.
  • DNP3 Slave Direct Outstation Set—Used when ClearSCADA is configured as a slave DNP3 device and other DNP3 devices connect to ClearSCADA directly (for example by serial cable, IP network, or radio).
  • DNP3 Slave PSTN Outstation Set—Used when ClearSCADA is configured as a slave DNP3 device and other DNP3 devices connect to ClearSCADA using dial-up modems.
  • DNP3 Slave Switched Outstation Set—Used when ClearSCADA is configured as a slave DNP3 device and other DNP3 devices connect to ClearSCADA using redundant direct connections.

You specify the properties of each set using the fields on the appropriate DNP3 Outstation Set Form.

Each Form has several tabs.

This section describes the properties that are available on the DNP3 tab. These properties allow you to Specify the Address of a DNP3 Master Set. The tab only applies to sets that are used when ClearSCADA is the master DNP3 device.

Properties on the other tabs are common to outstation sets on many advanced drivers—for information, see Configuring an Outstation Set in the ClearSCADA Guide to Advanced Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional DNP3 Outstation Set in ClearSCADA, see Minimum Configuration.

For more information on the possible physical arrangements for DNP3 devices on
a ClearSCADA system, see Introduction to the DNP3 Driver.


DNP3 Driver Guide - Minimum Configuration (Configuring a DNP3 Outstation Set)

Minimum Configuration

For a DNP3 set to be functional, as a minimum you need to specify:

  • The Channel(s) on Direct, Shared, and Switched sets
  • The DNP3 Local Address (master sets only).

You also need to put the set In Service and save the configuration.


DNP3 Driver Guide - Specify the Address of a DNP3 Master Set (Configuring a DNP3 Outstation Set)

Specify the Address of a DNP3 Master Set

In addition to the common configuration properties on other tabs, the configuration Forms for DNP3 Direct Outstation Sets, DNP3 PSTN Outstation Sets, DNP3 Shared Outstation Sets, and DNP3 Switched Outstation Sets have an additional DNP3 tab.

  • DNP3 Local Address—Use this field to specify the source address for messages that ClearSCADA sends to the DNP3 outstations in this set. For example, 30000.

The outstations have to use the defined DNP3 Local Address as the destination address in any DNP3 frames that they transmit.


DNP3 Driver Guide - Configuring a DNP3 Outstation

Configuring a DNP3 Outstation

NOTE: In addition to the outstations listed below, ClearSCADA can communicate with other types of DNP3 outstation, using a DNP3 Extension Driver. For DNP3 outstations not listed below, see the relevant DNP3 extension driver guide.

This section covers the configuration of DNP3 outstations for which ClearSCADA is the DNP3 Master. The ClearSCADA DNP3 driver is also capable of operating as a DNP3 Slave. For information on configuring outstations on systems for which the ClearSCADA DNP3 driver is a DNP3 Slave, see Configuring a DNP3 Slave Outstation.

Within the ClearSCADA database, you can configure these types of outstation for a DNP3 master device:

  • DNP3 Direct Outstation—For communication with a DNP3 outstation using a permanent connection (for example direct serial, radio, or network).

Depending on the system set-up, a DNP3 Direct Outstation can belong to a DNP3 Direct Outstation Set, or a DNP3 Switched Outstation Set (see Configuring a DNP3 Outstation Set).

If the system set-up allows, a DNP3 Direct outstation can optionally be configured with PSTN fallback so that it can still communicate with the ClearSCADA server if direct communications fail.

  • DNP3 PSTN Outstation—For communication with a DNP3 outstation using a dial-up modem. Each DNP3 PSTN Outstation has to belong to a DNP3 PSTN Outstation Set.
  • DNP3 Shared Outstation—For communication with a DNP3 outstation that can use either of two channels. The outstation has to be associated with a DNP3 Shared Outstation Set (each outstation in a Shared Set can communicate with the server via either channel).

If the system set-up allows, a DNP3 Shared outstation can optionally be configured with PSTN fallback so that it can still communicate with the ClearSCADA server if both direct channels fail.

ATTENTION: Many DNP3 Shared outstations support ‘Heartbeating’. Heartbeating in DNP3 uses the Data Link command ‘Request Link Status’. Be aware that outstation devices need to support simultaneous communication on both channels from the same master (ClearSCADA) in order to support Heartbeating. Please consult the DNP3 outstation vendor’s documentation to check whether such simultaneous communication is supported, before using Heartbeating on the DNP3 outstations on your system. Attempts to use Heartbeating on outstations that do not support such simultaneous communication may cause erroneous behavior.

If your database structure is ‘modular’ and Group Templates are used to store ‘model’ DNP3 configuration, in addition to the above types of outstation, you can add this driver-specific ‘abstract’ outstation item to your Group Templates:

  • Abstract DNP3 Outstation—Converts to any of the DNP3 Outstations listed above. If your system is running a DNP3 Extension Driver, this abstract item will also convert to any additional DNP3 Outstation items supported by that extension driver.

You can only add Abstract Items to Group Template s. The abstract items appear as additional driver-specific entries when you display the context sensitive menu from a Group Template. As with other abstract items, in order to represent a ‘real’ outstation, you need to convert the abstract items into the required type of outstation within the Group Instances that reference the Group Template. For more information, see Add an Abstract Item to a Group Template in the ClearSCADA Guide to Core Configuration.

To configure a DNP3 outstation, you configure the outstation’s properties using the fields on the DNP3 Direct Outstation Form, the DNP3 Shared Outstation Form, or the DNP3 PSTN Outstation Form, as appropriate.

Each Form has several tabs.

For each type of DNP3 Outstation, you can use the fields on:

  • The DNP3 tab to Configure the DNP3 Properties
  • The Security tab to Configure the Security Properties

For DNP3 PSTN Outstations and DNP3 Direct Outstations or DNP3 Shared Outstations that are configured to use PSTN fallback, use the fields on the PSTN tab to:

  • Define the Common PSTN Properties (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers)
  • Specify Whether ClearSCADA is to Constantly Poll an Outstation During an Open Line Call
  • Configure the Dial In Lines (see Define Dial In Line Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers). DNP3 outstations can support up to 8 Dial In lines for reporting alarm data to ClearSCADA.
  • Configure the Dial In Overactive properties (see Define Dial In Overactive Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers).

For DNP3 Direct Outstations and DNP3 Shared Outstations, you use the fields on the Direct tab to:

  • Configure Ethernet Keep Alive Polls
  • Specify Whether the Direct Communications Connection is Always Online or only Available on Demand.

Properties on the other tabs of each Outstation Form are common to outstations on many advanced drivers. For information, see Tabs on Outstation Forms in the ClearSCADA Guide to Advanced Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional DNP3 Outstation in ClearSCADA, see Minimum Configuration.


DNP3 Driver Guide - Minimum Configuration (Configuring a DNP3 Outstation)

Minimum Configuration

As a minimum, for a DNP3 outstation to become functional (online), you need to configure the following settings, and then put the outstation In Service and save the configuration:

  • The outstation Address (DNP3 tab)
  • The Set to which the outstation belongs (Outstation tab)
  • The Shared properties of a shared outstation (Shared tab).

ATTENTION: Many DNP3 Shared outstations support ‘Heartbeating’. Heartbeating in DNP3 uses the Data Link command ‘Request Link Status’. Be aware that outstation devices need to support simultaneous communication on both channels from the same master (ClearSCADA) in order to support Heartbeating. Please consult the DNP3 outstation vendor’s documentation to check whether such simultaneous communication is supported, before using Heartbeating on the DNP3 outstations on your system. Attempts to use Heartbeating on outstations that do not support such simultaneous communication may cause erroneous behavior.

  • The Host Address and Port of any network connected outstations (Network tab). (Port number 20000 is the TCP and UDP port that is registered for DNP3 use with the IANA (Internet Assigned Numbers Authority).)
  • If the outstation communicates via PSTN or has PSTN fallback, the Telephone Number of the site on which the outstation is located (PSTN tab).

This will result in a functional DNP3 outstation that uses the default configuration settings.


DNP3 Driver Guide - Configure the DNP3 Properties (Configuring a DNP3 Outstation)

Configure the DNP3 Properties

Use the fields on the DNP3 tab of each DNP3 Outstation Form to:

  • Configure the Outstation Address
  • Specify the IIN Severity
  • Specify When ClearSCADA Performs Integrity Polls
  • Specify When ClearSCADA Performs Class Polls
  • Enable Unsolicited Message Generation
  • Configure Virtual Terminal Support
  • Configure the Actions that Occur on Communications Startup
  • Configure DNP3 Event Scanning
  • Specify Whether ClearSCADA Polls an Outstation for Static String Point Data
  • Define Whether ClearSCADA Updates the Outstation Clock
  • Configure Frozen Counter Support
  • Configure the Counter Reset Method
  • Specify Which File Transfer Routines an Outstation Supports
  • Specify Different Communications Parameters for an Individual Outstation
  • Specify Different Pre- and Post-Amble Message Strings for an Individual Outstation
  • Specify Whether the Outstation is a ClearSCADA DNP3 Slave Outstation.


DNP3 Driver Guide - Configure the Outstation Address (Configuring a DNP3 Outstation)

Configure the Outstation Address

Use the Address field at the top of the DNP3 tab to specify the DNP3 address of the outstation.

  • Address—Each outstation in the ClearSCADA database has to have a unique address. One outstation cannot have the same DNP3 address as another outstation in the ClearSCADA database. Use this field to specify the required address.


DNP3 Driver Guide - Specify the IIN Severity (Configuring a DNP3 Outstation)

Specify the IIN Severity

Use these fields on the DNP3 tab to specify how ClearSCADA processes any DNP3 IIN bits that are reported by the outstation. An outstation transmits DNP3 IIN bits if there is a problem at the outstation (see DNP3 IIN Flags).

  • IIN Severity—Use the first combo box to specify whether ClearSCADA should process specific DNP3 IIN bits as an Alarm, Event, or None. Use the second combo box to specify the severity of DNP3 IIN bits that are processed as Alarm or Event.

For further information on severities, see Defining Severities in the ClearSCADA Guide to Core Configuration.


DNP3 Driver Guide - Specify When ClearSCADA Performs Integrity Polls (Configuring a DNP3 Outstation)

Specify When ClearSCADA Performs Integrity Polls

NOTE: For PSTN-only outstations, Integrity Poll settings do not control how often an outstation is dialled. You need to issue a One Shot or Open Line action if you want ClearSCADA to dial a PSTN outstation. If you want the outstation to be contacted on a regular basis, consider using a Schedule to trigger the action(s) automatically. Alternatively, you can use the One Shot action on the outstation set to call all of the outstations on that set. Again, consider associating the action with a Schedule if the One Shot is to be triggered on a regular basis (see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration).

Use the fields within the Integrity Polling section of the DNP3 tab to define if and when ClearSCADA sends DNP3 Integrity Polls to the outstation.

  • Scheduled Polling Enabled—Use this check box to specify whether ClearSCADA issues DNP3 Integrity Polls to the outstation.

If this check box is enabled, ClearSCADA will poll the outstation periodically (using the poll specified in the Poll Type field). Typically, this poll will cause the outstation to return any buffered events and the current values of the points that are configured in the outstation.

If the Scheduled Polling Enabled check box is clear, ClearSCADA will not issue Integrity Polls.

  • Interval—Specify how often ClearSCADA issues the DNP3 Integrity Poll.

Enter the time in the OPC Time Format, for example, 1H (for one hour). You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

  • Offset—Specify the time offset of each poll. ClearSCADA uses the values in the Offset and Interval fields to calculate the timing of the poll.

Enter the time in the OPC Relative Time Format. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

It is advisable that the Interval and Offset are fully divisible, so that Integrity checks occur at readily recognizable times.

Example:

The Integrity Poll for a DNP3 outstation has these properties:

Interval: 1H
Offset: H + 5M (‘five minutes past the beginning of the present hour’)

This results in ClearSCADA polling the outstation at five minutes past each hour, every hour.

  • Poll Type—Use this combo box to specify the type of poll that ClearSCADA issues to the outstation. Choose from:
  • Class 0 Only—ClearSCADA issues requests for the outstation’s current value data only. The outstation does not report any events in response to the polls.

ATTENTION: The Class 0 Only option is not recommended as it does not conform to the DNP3 standard. This option is useful where ClearSCADA is being configured as a second DNP3 master on a system, but is communicating with DNP3 devices which do not support multiple masters, and therefore cannot report event data to ClearSCADA. Use this option only if it is absolutely necessary, and only if the outstation will not be reporting event data to ClearSCADA.

  • Class 1, 2, 3, 0—ClearSCADA issues requests for the outstation’s event data and current value data. The outstation reports any event data that is stored in its internal event buffer(s), followed by its static (current value) data.
  • Read Outstation Current Time—For devices that support the level 3 DNP3 object g50v1 Read function, you can specify whether ClearSCADA is to read the outstation’s time and use that time to time stamp the static data that it retrieves from the outstation. Using the outstation time in this way helps to avoid time stamp inconsistencies should the outstation and master station clocks differ slightly (for example, by a few seconds).

Select the Read Outstation Current Time check box for ClearSCADA to insert a g50v1 time request into the integrity poll before the Class 0 poll. ClearSCADA uses the time reported by the outstation to time stamp the static data (current values and states) that it retrieves from the outstation. The outstation time is used to apply time stamps to all static data, including the data retrieved during Level 3 and String data polls. The time is not applied to non-time stamped event data.

Clear the check box if:

  • The outstation does not support the DNP3 object g50v1 Read function

and/or

  • ClearSCADA is to use the server’s time to time stamp the static data that it retrieves from the outstation.


DNP3 Driver Guide - Specify When ClearSCADA Performs Class Polls (Configuring a DNP3 Outstation)

Specify When ClearSCADA Performs Class Polls

NOTE: For PSTN-only outstations, Class Poll settings do not control how often an outstation is dialled. You need to issue a One Shot or Open Line action if you want ClearSCADA to dial a PSTN outstation. If you want the outstation to be contacted on a regular basis, consider using a Schedule to trigger the action(s) automatically. Alternatively, you can use the One Shot action on the outstation set to call the outstations on that set. Again, consider associating the action with a Schedule if the One Shot is to be triggered on a regular basis (see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration).

Use the fields within the Class 1 Polling, Class 2 Polling, and Class 3 Polling sections of the DNP3 tab to define if, and when, ClearSCADA polls the outstation for event data for each of the three DNP3 Event Classes.

  • Scheduled Polling Enabled—Use this check box to specify whether ClearSCADA issues DNP3 Class Polls for the given class, to the outstation. Select the check box for ClearSCADA to periodically issue polls to the outstation, requesting event data for the given class. The outstation will respond by sending any events that are stored in its internal event buffer(s), and which match the requested class.
  • Interval—Specify how often ClearSCADA issues a DNP3 Class Poll.

Enter the time in the OPC Time Format, for example 5M (for five minutes). You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

We recommend that you specify a full division of, for instance, a minute, or hour, so that polling times are consistent (for example, at 5- or 10-second intervals).

  • Offset—Specify the time offset of each poll. ClearSCADA uses the values in the Offset and Interval fields to assess how the polls are to be staggered.

Enter the time in the OPC Relative Time Format. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.

  • Ignore Events Available IIN Bit—Every data packet that a DNP3 outstation sends to ClearSCADA includes various DNP3 flags (internal indications). Three of these flags indicate whether the outstation has any Class 1, Class 2, or Class 3 events in its Event Buffer.

Clear this check box if ClearSCADA is to poll the outstation for the buffered events for the given class. The poll will take place whenever the outstation sets the flag to indicate that it has events of the relevant class(es) in its Event Buffer.

Select the check box if ClearSCADA is to ignore the Events Available IIN Bit for the given class. The events for this class will be retrieved in the next scheduled poll, or when the outstation sends an unsolicited message to ClearSCADA.

You would typically select the Ignore Events Available IIN Bit check box if:

  • The outstation is generating a lot of events for the class—By ignoring the Events Available IIN Bit, greater control is retained over when the outstation is polled. It also means that ClearSCADA does not poll the outstation exclusively for numerous events.
  • There are a lot of outstations on the channel—By ignoring the Events Available IIN Bit, ClearSCADA is able to continue to poll the outstations on the channel, rather than polling this outstation repeatedly.
  • Communications to the outstation is slow—By ignoring the Events Available IIN Bit, ClearSCADA is able to continue its polling regime and poll other outstations for data.

Example:

On a ClearSCADA system, data that is logged at an outstation is given one of three levels of priority—low, medium, or high. Low priority data is to be reported within one hour of being logged. Medium priority data is to be reported within half an hour of being logged. High priority data is to be reported within ten minutes of being logged.

The outstation is configured to log high priority events as Class 1, medium priority events as Class 2, and low priority events as Class 3. In the ClearSCADA database, the DNP3 outstation is given this configuration:

Class 1 Polling
Scheduled Polling Enabled: True
Interval: 10M
Offset: H + 2M

Class 2 Polling
Scheduled Polling Enabled: True
Interval: 30M
Offset: H + 1M

Class 3 Polling
Scheduled Polling Enabled: True
Interval: 1H
Offset: H


DNP3 Driver Guide - Enable Unsolicited Message Generation (Configuring a DNP3 Outstation)

Enable Unsolicited Message Generation

The DNP3 protocol allows DNP3 outstations to report event data to the DNP3 master independently of the master’s polling cycles. When communicating in this way, the outstations report the event data to the DNP3 master by transmitting unsolicited messages (also referred to as unsolicited responses). However, this capability is only supported by certain DNP3 outstations.

Use the check boxes within the Enable Unsolicited Messages section of the DNP3 tab to specify the classes for which an outstation is allowed to generate unsolicited messages:

  • Enable Unsolicited Messages on Comms Start—Select this check box if ClearSCADA is to issue Function Code 20 (Enable Unsolicited) and Function Code 21 (Disable Unsolicited) messages to the outstation. If the system set-up and outstation support such functions, it is generally considered good practice by the DNP3 master (ClearSCADA) to issue a Function Code 21 (Disable Unsolicited) message to an outstation when establishing communications, and a Function Code 20 (Enable Unsolicited) message to the outstation after communications have been established.

Clear the check box to set ClearSCADA so that it does not issue Function Code 20 and 21 messages to the outstation. For example, you should clear the check box if:

  • The outstation does not support Function Codes 20 and 21
  • ClearSCADA is a second ‘pseudo’ DNP3 master, issuing only DNP3 Class 0 Polls to outstations that do not have multi-master support (see Specify When ClearSCADA Performs Integrity Polls).

In the situations mentioned above, having the check box selected could result in unexpected outstation behavior. (As a result of ClearSCADA issuing a Function Code 21 (Disable Unsolicited) message to the outstation).

  • Class n—Use the Class 1, Class 2, and Class 3 check boxes to specify the class(es) for which the outstation is able to generate unsolicited messages.

Select the check box(es) for the class(es) for which the outstation is to generate unsolicited messages.

Clear the check box(es) for the class(es) for which the outstation is not to generate unsolicited messages.

  • Retry Interval—Use to specify how often ClearSCADA is to attempt to re-issue a Function Code 20 (Enable Unsolicited) message to the outstation, in the event that the ClearSCADA DNP3 driver does not receive a response from the outstation, indicating success. ClearSCADA will continue to send the message at this rate until unsolicited messages are enabled successfully.

Enter the time in the OPC Time Format, for example 30S (for 30 seconds). You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.


DNP3 Driver Guide - Configure Virtual Terminal Support (Configuring a DNP3 Outstation)

Configure Virtual Terminal Support

The DNP3 protocol supports the ‘transparent’ transmission of data between DNP3 devices, through the use of DNP3 Virtual Terminals (VT).

If the servers on your system are being used to route comms in this way, you need to use the Virtual Terminal Support section of the DNP3 tab to specify the virtual terminal settings of the outstation. You also need to configure the required Virtual Terminal(s) and Service Port(s) (see Configuring DNP3 Virtual Terminals) that are required to allow a virtual, transparent, connection between a serial communications port on the ClearSCADA server and a serial communications port on the outstation.

Use the fields in the Virtual Terminal Support section of the DNP3 tab to specify whether ClearSCADA is to provide a virtual link between one of its serial ports and a serial port on the outstation:

  • Configure VT on Startup—For Virtual Terminal functionality to operate, it is necessary to send a message to enable VT functionality when communications are initiated with an outstation. Select this check box if Virtual Terminal functionality is being used and the outstation is to generate unsolicited messages that contain DNP3 VT data. The outstation will send any data that it receives on its designated serial port, back to ClearSCADA. The DNP3 Event Class used for VT event data is determined by the outstation. For example, SCADAPack E-Series outstations specify VT event data as Class 3.

Clear this check box if Virtual Terminal functionality is not required and the outstation is not providing a virtual serial port.

  • Poll for VT Events—Use this check box to specify whether ClearSCADA is to poll the outstation for VT event data.

To retrieve VT event data from an outstation, ClearSCADA must has to poll the outstation for the event class for which the outstation logs VT events. For example, ClearSCADA has to perform a Class 3 poll to retrieve VT event data from a SCADAPack E-Series outstation. Select this check box if ClearSCADA is to poll the outstation for VT event data and the outstation is not to generate unsolicited responses containing VT event data.

Leave the check box clear if the outstation is to generate unsolicited responses that contain VT event data.


DNP3 Driver Guide - Configure the Actions that Occur on Communications Startup (Configuring a DNP3 Outstation)

Configure the Actions that Occur on Communications Startup

Use the fields within the Startup section of the DNP3 tab to specify the message that the ClearSCADA DNP3 driver is to send to the outstation if it is offline, and to specify whether the driver is to poll the outstation for device attributes once communications are established.

  • Start Communications Message—Use to specify the DNP3 message that the ClearSCADA DNP3 driver sends, in order to initiate communications with the outstation if it is offline. The Restablishment Interval on the Channel Form (see Configure the Scan Parameters) defines the frequency with which ClearSCADA transmits this start-up message.

The message options are:

  • Delay Measurement—This option has the smallest request and response size and is therefore the default option. Select this option in preference to the others, if communications are to be established with many outstations simultaneously. This reduces the load on the communications network and the ClearSCADA server.
  • Integrity Poll—This option causes ClearSCADA to issue an Integrity Poll to the outstation. This may result in a very large response, as the outstation will respond with any DNP3 event data that is stored in its internal event buffer(s), and the current values of any configured points.
  • Class 1 Poll—This option causes ClearSCADA to issue a Class 1 Poll to the outstation. This may result in a large response, as the outstation will respond with any DNP3 Class 1 event data that is stored in its internal event buffer(s).
  • Class 2 Poll—This option causes ClearSCADA to issue a Class 2 Poll to the outstation. This may result in a large response, as the outstation will respond with any DNP3 Class 2 event data that is stored in its internal event buffer(s).
  • Class 3 Poll—This option causes ClearSCADA to issue a Class 3 Poll to the outstation. This may result in a large response, as the outstation will respond with any DNP3 Class 3 event data that is stored in its internal event buffer(s).
  • Read Device Attributes on Startup—Select this check box if ClearSCADA is to perform a Group 0 poll of the outstation whenever communications are established with that outstation. With a Group 0 poll, the ClearSCADA DNP3 driver retrieves the outstation’s device attributes. Device Attributes include information about the outstation, including software version, hardware version, and the maximum number of points that the outstation can support. You can view the retrieved attributes on the outstation’s Status Display (see DNP3 Specific Status Display Attributes). The attributes are also available as OPC properties (see the Database Schema and the ClearSCADA Guide to the Database).

Clear the check box if the outstation does not support device attributes, or you do not want ClearSCADA to read the attributes as part of the start-up sequence. (If the outstation supports attributes, they can still be read into ClearSCADA using the Read Device Attributes pick action, regardless of the setting of this check box.)


DNP3 Driver Guide - Configure DNP3 Event Scanning (Configuring a DNP3 Outstation)

Configure DNP3 Event Scanning

The ClearSCADA DNP3 driver is capable of issuing DNP3 event polls for specific DNP3 items, in addition to Class polls (see Specify When ClearSCADA Performs Class Polls).

Use the fields within the Event Scanning section of the DNP3 tab to specify the frequency at which ClearSCADA performs DNP3 Event polls:

Use each combo box to specify a Scan Group. The update frequency of each Scan Group, and the frequency with which ClearSCADA performs each DNP3 Event poll, is determined by the corresponding Scan Group property, configured on the DNP3 Channel Form (see Configure the Scan Group Intervals).

  • Binary Input Events Scan Group—Specify the Scan Group that the driver uses to poll for binary input events.
  • Binary Output Events Scan Group—Specify the Scan Group that the driver uses to poll for binary output events.
  • Double-bit Binary Input Events Scan Group—Specify the Scan Group that the driver uses to poll for double-bit binary input events.
  • Analog Input Events Scan Group—Specify the Scan Group that the driver uses to poll for analog input events.
  • Analog Output Events Scan Group—Specify the Scan Group that the driver uses to poll for analog output events.
  • Counter Events Scan Group—Specify the Scan Group that the driver uses to poll for counter events.

NOTE: DNP3 Event Scanning requires DNP3 Level 2 support at the outstation. If the outstation does not support DNP3 Level 2, set these fields to ‘None’.


DNP3 Driver Guide - Specify Whether ClearSCADA Polls an Outstation for Static String Point Data (Configuring a DNP3 Outstation)

Specify Whether ClearSCADA Polls an Outstation for Static String Point Data

Use the fields within the String Points Polling section of the DNP3 tab to specify whether ClearSCADA is to scan an outstation for static String point data:

  • Enabled—Use this check box to specify whether ClearSCADA polls the outstation for String point data.

String point data is not returned in the normal Class 0 - Integrity poll of the outstation. Select the Enabled check box for ClearSCADA to periodically issue polls to the outstation, requesting static data for the outstation’s String points. The outstation will respond by sending any static String point data that is stored in its internal buffer(s).

Clear the check box if the outstation does not have any String points, or you do not want ClearSCADA to poll all of the outstation’s String points on a regular basis.

  • Interval—Specify how often ClearSCADA polls the outstation for static String point data. Such polls may result in large quantities of data being returned to ClearSCADA. If an outstation has a large number of String points, carefully consider the frequency with which ClearSCADA should poll the outstation for String data. Depending on link speed, you should specify an interval of several minutes or hours for those outstations that have a large number of string points. Enter the time in the OPC Time Format, for example 5M (for five minutes). You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

We recommend that you specify a full division of, for instance, a minute, or hour, so that polling times are consistent (for example, at 5- or 10-minute intervals).

  • Offset—Specify the time offset of each poll. ClearSCADA uses the values in the Offset and Interval fields to assess how the polls are to be staggered.

Enter the time in the OPC Relative Time Format. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required offset.


DNP3 Driver Guide - Define Whether ClearSCADA Updates the Outstation Clock (Configuring a DNP3 Outstation)

Define Whether ClearSCADA Updates the Outstation Clock

The DNP3 protocol allows an outstation to indicate that its internal clock may not be up to date, as a mechanism to allow the DNP3 master (ClearSCADA) to set the time in the outstation. A DNP3 outstation indicates that it requires its internal clock to be set by setting the DNP3 Need Time IIN bit. ClearSCADA supports setting the outstation’s clock, using either Delay Measurement (Function Code 23) or Record Current Time (Function Code 24). You can use the outstation’s Clock Errors status attribute to ascertain whether the outstation’s clock has drifted from the server time or whether an error occurred during the last attempt to set the outstation’s clock.

Use the fields within the Set the Clock section of the DNP3 tab to specify if, and how, ClearSCADA sets the outstation’s clock.

  • Initiate Set Clock—Use this combo box to specify what triggers ClearSCADA to set the outstation’s clock. The options are:
  • Never—ClearSCADA is not to set the outstation’s clock due to any of the reasons listed in the bullet points for the other Initiate Set Clock options below. Select ‘Never’, for instance, if the outstation’s clock is set by another means, such as NTP, or by another DNP3 device. If required, you can still use the Set Clock pick action or method to set the outstation’s clock.

If the outstation supports the level 3 DNP3 object g50v1 Read function, use the other fields in this section of the tab to specify whether ClearSCADA is to perform periodic comparisons of the outstation’s time against ClearSCADA’s time.

  • Outstation—ClearSCADA sets the outstation’s clock in response to the outstation setting its DNP3 Need Time IIN bit.
  • ClearSCADA—ClearSCADA sets the outstation’s clock:
  • At the frequency specified on the relevant DNP3 Channel Form (see Configure the Set Outstation Clock Properties)
  • On establishing communications with the outstation
  • Whenever the driver detects a clock jump in the server.
  • Outstation and ClearSCADA—ClearSCADA sets the outstation’s clock:
  • At the frequency specified on the relevant DNP3 Channel Form
  • On establishing communications with the outstation
  • Whenever the driver detects a clock jump in the server
  • In response to the outstation setting its DNP3 Need Time IIN bit.
  • Set Clock Method—Use this combo box to specify the method by which ClearSCADA sets the outstation’s clock. Choose from:
  • Delay Measurement (FC 23)—Select this option if ClearSCADA connects to the outstation using a serial device (for example a direct serial cable, radio, or dial-up modem), or if the outstation does not support Record Current Time (Function Code 24).
  • Record Current Time (FC 24)—Select this option if the outstation supports Record Current Time (Function Code 24) and ClearSCADA connects to the outstation using TCP/IP.

NOTE: The selections you make for the Check Clock Drift, Maximum Acceptable Drift and Abort Set Clock settings (below) do not apply when the Set Clock pick action or method is used to set the outstation’s clock.

  • Check Clock Drift—Select this check box if the DNP3 outstation supports the level 3 DNP3 object g50v1 Read function and ClearSCADA is to read and compare the outstation’s clock time with that of ClearSCADA’s time. When selected, ClearSCADA checks the outstation’s clock at the frequency specified on the relevant DNP3 Channel Form (see Configure the Set Outstation Clock Properties).

Clear the check box if the outstation does not support the g50v1 Read function, or if any clock drift can be ignored.

  • Maximum Acceptable Drift—Use this field to specify the maximum amount by which the outstation’s time is permitted to differ from ClearSCADA’s time. Should the difference be greater than this amount, ClearSCADA will raise a clock drift alarm.

Specify the Maximum Acceptable Drift in the OPC Time Format.

  • Abort Set Clock—Applies when the Check Clock Drift check box is selected and Initiate Set Clock is set to an option other than ‘Never’. Select this check box if ClearSCADA is to abort setting the outstation’s clock if the difference between the outstation’s time and ClearSCADA’s time is greater than the Maximum Acceptable Drift (see above).

Clear the check box if ClearSCADA is to set the outstation’s clock even if its time differs from ClearSCADA’s time by more than the Maximum Acceptable Drift.


DNP3 Driver Guide - Configure Frozen Counter Support (Configuring a DNP3 Outstation)

Configure Frozen Counter Support

The DNP3 protocol provides Frozen Counters that allow a DNP3 master (ClearSCADA) to request the outstation to create a frozen ‘snapshot’ of the values of its counters.

Use the fields within the Freeze section of the DNP3 tab to specify whether the outstation supports frozen counters, and whether ClearSCADA requires a response to freeze counter requests.

  • Freeze Supported—Select this check box if the outstation supports DNP3 frozen counters, and you intend to send DNP3 freeze counter controls to the outstation. Use the outstation’s Freeze and Freeze and Clear pick actions to take snapshots of counter values (see Actions Associated with DNP3 Outstations).

Clear the check box if the outstation does not support DNP3 frozen counters, or you do not intend to issue DNP3 freeze counter controls to the outstation.

  • Request Response to Freeze (FC7 and 9)—Select this check box for ClearSCADA to request a response to any DNP3 Freeze Counter requests that it issues to the outstation.

Clear the check box if responses are not required.


DNP3 Driver Guide - Configure the Counter Reset Method (Configuring a DNP3 Outstation)

Configure the Counter Reset Method

Use this combo box within the Counters section of the DNP3 tab to specify how ClearSCADA resets counters in the outstation:

  • Reset Method—Use the combo box to specify the required counter reset method. Choose from:
  • Initialize_DATA (g20v0)—ClearSCADA instructs the outstation to reset the counter value to the default that is specified at the outstation.
  • WRITE (g20v6) - 16 Bit—ClearSCADA instructs the outstation to reset the counter to a 16-bit value that is specified by the operator. The value is specified using the Initialize pick action.
  • WRITE (g20v5) - 32 Bit—ClearSCADA instructs the outstation to reset the counter to a 32-bit value that is specified by the operator. The value is specified using the Initialize pick action.


DNP3 Driver Guide - Specify Which File Transfer Routines an Outstation Supports (Configuring a DNP3 Outstation)

Specify Which File Transfer Routines an Outstation Supports

ClearSCADA is able to transfer files such as ISaGRAF applications to an outstation that supported File Transfers.

Use the fields within the File Transfer section of the DNP3 tab to specify whether an outstation supports File Transfer routines and if so, the variation that it supports.

  • Variation—Use the combo box to specify the File Transfer routine that the outstation supports. Choose from:
  • Not Supported—The outstation does not support File Transfer routines.
  • Legacy g70v1—The outstation only supports the earlier g70v1 File Transfer routines.
  • Revised g70 Variations—The outstation supports the revised File Transfer routines defined by the DNP3 standard.

With an outstation that supports file transfers, you can use:

  • The Download File pick action to download a file from ClearSCADA to the outstation
  • The Upload File pick action to upload a file from the outstation to ClearSCADA
  • The Delete File pick action to delete a file on an outstation.

For more information, see Using DNP3 Specific Actions.

  • Requires Authentication—Applicable if the outstation supports Revised g70 Variations. Select this check box if a user name and password are required to access the outstation’s file system.

Clear the check box if user name and password authentication is not needed to access the outstation’s file system.

  • User Name—Only applies if the outstation supports Revised g70 Variations that require authentication. Specify a user name that provides read/write access to the outstation’s file system, to enable ClearSCADA to transfer files to and from the outstation.
  • Password—Specify the password that, combined with the User Name above, provides read/write access to the outstation’s file system.


DNP3 Driver Guide - Specify Different Communications Parameters for an Individual Outstation (Configuring a DNP3 Outstation)

Specify Different Communications Parameters for an Individual Outstation

Use the fields within the Communications Parameters section of the DNP3 tab to specify whether ClearSCADA is to override the default Communications Parameters that are defined for the channel (see Configure the Communications Parameters).

  • Enabled—Select this check box if the DNP3 communications parameters defined on the Channel Form are to be overridden by the parameters specified in this section. Select this check box and set the remaining fields if:
  • The outstation is on a significantly faster or slower link—in this situation, you would adjust the Data Link Timeout and Application Fragment Timeout accordingly.
  • The outstation is on a significantly more reliable or less reliable link—in this situation, you would adjust Data Link Retries and Application Fragment Attempts accordingly.

For the remainder of the fields within this section, see Configure the Communications Parameters.

Clear the Enabled check box if ClearSCADA is to communicate with the outstation using the Communication Parameters that are specified on the Channel Form (see Configure the Communications Parameters).


DNP3 Driver Guide - Specify Different Pre- and Post-Amble Message Strings for an Individual Outstation (Configuring a DNP3 Outstation)

Specify Different Pre- and Post-Amble Message Strings for an Individual Outstation

Use the fields within the Local Pre/Post Amble section of the DNP3 tab to specify whether ClearSCADA is to use different pre- or post-amble bytes to those specified for the channel (see Configure the Pre-Amble and Post-Amble Message Strings).

  • Enabled—Select this check box if the pre-amble and post-amble bytes defined on the Channel Form are to be overridden by the settings specified in this section.

For information on the remainder of the fields in the Local Pre/Post Amble section, see Configure the Pre-Amble and Post-Amble Message Strings.

Clear the Enabled check box to set ClearSCADA to use the pre-amble and post-amble defaults that are specified for the channel (see Configure the Pre-Amble and Post-Amble Message Strings).


DNP3 Driver Guide - Specify Whether the Outstation is a ClearSCADA DNP3 Slave Outstation (Configuring a DNP3 Outstation)

Specify Whether the Outstation is a ClearSCADA DNP3 Slave Outstation

Use the Communicating with ClearSCADA Slave check box on the DNP3 tab to specify whether the outstation is a ClearSCADA DNP3 Slave Outstation.

  • Communicating with ClearSCADA Slave—Select this check box if the DNP3 outstation
    is a ClearSCADA DNP3 Slave Outstation (see Configuring a DNP3 Slave Outstation). Extra functionality that is specific to Slave outstations becomes available for use (for example, the Execute Remote Method pick action).

Clear this check box if this outstation is not a ClearSCADA DNP3 Slave.


DNP3 Driver Guide - Configure the Security Properties (Configuring a DNP3 Outstation)

Configure the Security Properties

Use the fields on the Security tab of each DNP3 Outstation Form to:

  • Specify Whether DNP3 Secure Authentication is Used
  • Specify the Algorithms used to Secure Message Content
  • Define When the Session Keys Need to Change
  • Specify Whether Aggressive Mode is Used
  • Specify the Maximum Error Count
  • Define Whether ClearSCADA Logs Authentication and Key Change Information.

NOTE: Some DNP3 devices with which ClearSCADA communicates using a DNP3 Extension Driver support additional security properties. Such properties are configured on other tabs and are explained in the relevant DNP3 extension driver guide.


DNP3 Driver Guide - Specify Whether DNP3 Secure Authentication is Used (Configuring a DNP3 Outstation)

Specify Whether DNP3 Secure Authentication is Used

Use the Enabled check box at the top of a DNP3 Outstation’s Security tab to specify whether any outstation transmissions are to use DNP3 Secure Authentication:

Clear the check box if DNP3 Secure Authentication is not used for any transmissions to or from this outstation. An outstation that does not use DNP3 Secure Authentication is known as a non-secure device. Messages sent to or from the outstation are transmitted in the normal way, using the DNP3 protocol (see Scanning for Data on DNP3 Devices). None of the messages are challenged by the receiving device before being processed.

Select the Enabled check box if DNP3 Secure Authentication is to be used for critical transmissions to and/or from this outstation. To use this feature, the outstation has to support DNP3 Secure Authentication version 2.00. You can define the outstation’s DNP3 Secure Authentication properties by using the other fields on the Security tab.


DNP3 Driver Guide - Specify the Algorithms used to Secure Message Content (Configuring a DNP3 Outstation)

Specify the Algorithms used to Secure Message Content

Use the fields within the Algorithms section of the Security tab to specify which HMAC and Key Wrap algorithms this particular outstation uses.

  • HMAC—Specify which Hash-based Message Authentication Code (HMAC) algorithm the outstation is to use when:
  • responding to challenges sent by ClearSCADA
  • issuing Aggressive Mode responses to ClearSCADA. (This only applies if the outstation is configured to issue, and ClearSCADA is configured to accept, Aggressive Mode responses (see Specify Whether Aggressive Mode is Used).)

Use the combo box to display a list of supported HMACs. We recommend that you select the largest HMAC supported by the DNP3 outstation and appropriate to the type of communications being used. In addition to specifying which algorithm the devices are to use, the selected option also determines how each calculated HMAC value is truncated before being inserted into each message. (A SHA-1 value is 20 octets long before truncation; a SHA-256 value is 32 octets long before truncation.)

The outstation will generate an ‘HMAC Algorithm Not Permitted’ diagnostics message should it receive a challenge using an HMAC algorithm that it does not support. Should this occur, ClearSCADA will revert to using the HMAC-SHA1 algorithm for further challenge requests.

  • Key Wrap—ClearSCADA uses this Key Wrap algorithm to encrypt the Session Keys during a Session Key Change, using a pre-shared Update Key. The algorithm also determines the length of Update Key. ClearSCADA supports a single Key Wrap algorithm, the Advanced Encryption Standard (AES) AES-128. The AES-128 algorithm requires a 128-bit Update Key, comprising 32 hexadecimal digits.

During a Session Key Change, the outstation determines which Key Wrap algorithm ClearSCADA is to use for the Session Key Change. Should the outstation request an unsupported Key Wrap algorithm, ClearSCADA will send a ‘Key Wrap Algorithm Not Permitted’ error to the outstation. If this occurs, the outstation has to revert to using the mandatory Key Wrap algorithm AES-128.


DNP3 Driver Guide - Define When the Session Keys Need to Change (Configuring a DNP3 Outstation)

Define When the Session Keys Need to Change

To maintain security, ClearSCADA changes the Session Keys whenever either a Change Interval or Change Count is reached (whichever is the shorter). ClearSCADA also changes the Session Keys after any communications failure.

Use the fields within the Session Keys section of the Security tab to specify the change criteria.

Ideally, the values that you specify in these fields should equate to half that of the values configured in the outstation itself. This should help to prevent the outstation from invalidating the Session Keys unnecessarily if an expected Session Key Change is delayed. In certain circumstances, Session Key Change delays can occur, for instance, when the system is exceptionally busy.

  • Change Interval—Use to specify the frequency with which ClearSCADA is to change the Session Keys. The default is 15M (15 minutes). If a different interval is required, either overtype the existing entry or use the Interval Window (accessed via the field’s browse button) to specify the required interval. Ideally you should specify an interval that is half that of the interval specified in the outstation itself. When entering an interval, you need to use the OPC Time Format.

The maximum interval that you can specify varies, depending on the type of communications used by the outstation:

  • With outstations that have a direct communications connection that is constantly online, the maximum interval you can specify is 2 hours
  • With outstations that are sometimes offline, the maximum interval you can specify is 1 week. Outstations that may be offline at certain times include PSTN only outstations, direct outstations on which communications are ‘On Demand’, and outstations on which communications are ‘Incoming Only’ or ‘Periodic’.

The interval timer is reset whenever it expires, or the Change Count is reached (whichever is the shorter).

If required, you can disable the Change Interval by specifying an interval of 0 (zero). With such an interval, ClearSCADA changes the Session Keys whenever the Change Count is reached, or on re-establishing communications with the outstation.

  • Change Count—Use to specify the maximum number of authentication messages that can be transmitted between ClearSCADA and this outstation before the Session Keys have to change. The default is 1000 authentication messages. If required you can specify a different number of messages, in the range 1 to 10,000 inclusive. Ideally you should specify a count that is half that of the count specified in the outstation itself.

The count is reset whenever it is exceeded, or the Change Interval expires (whichever is the shorter).

Whenever either change trigger is reached, ClearSCADA changes the Session Keys.

Should communications fail at any time, the current Session Keys will be invalidated. When the communications with the outstation are re-established, ClearSCADA will re-initialize the Session Keys.

Further Information

‘On Demand’ outstations: see Specify Whether the Direct Communications Connection is Always Online or only Available on Demand.

‘Incoming Only’ and ‘Periodic’ communications: see Specify the Availability of Communications Between the Outstation and ClearSCADA in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Specify Whether Aggressive Mode is Used (Configuring a DNP3 Outstation)

Specify Whether Aggressive Mode is Used

Use the check boxes within the Aggressive Mode section of the Security tab to specify whether ClearSCADA is to accept Aggressive Mode requests from, or issue Aggressive Mode requests to, this outstation:

  • Accept Requests—Select this check box if ClearSCADA is to accept Aggressive Mode requests from the outstation. With such requests, the outstation includes the necessary authentication data in the same message as the critical request.

Clear the Accept Requests check box if ClearSCADA is to reject any Aggressive Mode requests. ClearSCADA may also send a diagnostics message indicating that it does not accept Aggressive Mode messages (see Specify the Maximum Error Count).

  • Issue Requests—Select this check box if ClearSCADA is to send Aggressive Mode requests to the outstation. With such requests, ClearSCADA includes the necessary authentication data in the same message as the critical request.

Clear the Issue Requests check box if ClearSCADA is not to send Aggressive Mode requests. The outstation will challenge the critical requests that it receives from ClearSCADA.

NOTE: If ClearSCADA issues an Aggressive Mode request to an outstation that does not accept Aggressive Mode requests, the outstation will generate an error (provided that the outstation has not exceeded its maximum error count). On detecting the error, ClearSCADA will raise an alarm, and will then issue the request, and all subsequent critical requests in that session, without using Aggressive Mode. However, when ClearSCADA makes a new connection attempt, for example, after a Main-Standby changeover, driver restart, or configuration change, it will attempt to use Aggressive Mode again. This means the Aggressive Mode error will be repeated on every new connection.
If an Aggressive Mode error occurs, correct the configuration in the relevant device so that the appropriate mode of DNP3 Secure Authentication is used.

It will not use Aggressive Mode for any further critical requests that it issues to the outstation during that session. However, on subsequent connections, ClearSCADA will attempt to use Aggressive Mode again.
If ClearSCADA has detected an error and is no longer using Aggressive Mode, you will need to configure the relevant device to use the appropriate mode of DNP3 Secure Authentication. This will allow ClearSCADA to communicate with the device more efficiently.
If you do not correct the configuration, ClearSCADA will attempt to use Aggressive Mode on each new connection attempt (for example, after a Main-Standby changeover, driver restart, or configuration change.) This means that the error-detection and switch to non-Aggressive Mode will occur each time a new connection is used, which makes the communications process less efficient.


DNP3 Driver Guide - Specify the Maximum Error Count (Configuring a DNP3 Outstation)

Specify the Maximum Error Count

ClearSCADA can detect errors during any part of the authentication process, including challenge-responses, Aggressive Mode requests, Aggressive Mode confirmations, and Session Key Changes. If ClearSCADA detects an error during the authentication process, it will determine whether it needs to report that error to the outstation. For example, if ClearSCADA received a critical response from an outstation, it issues a challenge to that outstation and waits for a response. If the outstation does not respond, or responds with an incorrect reply, ClearSCADA may generate an error message.

A malicious user may use a device to mount a denial-of-service attack against ClearSCADA by repeatedly sending ‘bad’ authentication messages. They may also send repeated challenges in an attempt to learn about ClearSCADA’s authentication. The Maximum Error Count setting helps to protect against such attacks by stopping ClearSCADA from transmitting error messages once a defined limit has been exceeded. This is in accordance with the DNP3 standard.

Use the Maximum Error Count spin box on the Security tab to specify the maximum number of authentication error messages that ClearSCADA is to send to this outstation:

You can specify a maximum error count of between 0 and 10 inclusive (with 2 being the default). Once this count has been exceeded, ClearSCADA will no longer send authentication error messages to this outstation.

The error count resets when either of the following occur:

  • ClearSCADA receives an authentic reply to its latest challenge
  • The Session Keys are changed (see Define When the Session Keys Need to Change).

If the error count is exceeded in ClearSCADA for any reason, ClearSCADA will initiate a Session Key Change.

If the error count is exceeded during a Session Key Change, ClearSCADA will assume that the outstation does not support DNP3 Secure Authentication, or does not have DNP3 Secure Authentication enabled. Further communications will proceed without any authentication while the outstation remains online. (Should this occur, correct the configuration in the relevant device so that there is no longer a security mismatch.)

Further Information

Define Whether ClearSCADA Logs Authentication and Key Change Information.

Aggressive Mode: see Specify Whether Aggressive Mode is Used.


DNP3 Driver Guide - Define Whether ClearSCADA Logs Authentication and Key Change Information (Configuring a DNP3 Outstation)

Define Whether ClearSCADA Logs Authentication and Key Change Information

ClearSCADA can log information about both successful and unsuccessful authentications and Session Key Changes.

Use the field(s) within the Alarm/Event Logging section of the DNP3 Outstation Form’s Security tab to define the priority that ClearSCADA assigns to the authentication and key change information that it logs for this particular outstation.

  • Severity—Use this combo box to specify the priority that is assigned to the alarms and events that ClearSCADA logs in relation to authentications and Session Key Changes.

ClearSCADA assigns this priority to the:

  • events that it logs for successful authentications
  • alarms that it logs for any unsuccessful authentications and any authentication errors that it has received.

(The None setting will result in ClearSCADA not logging any messages related to successful and unsuccessful authentications. For this reason, we recommend that you do not choose None for the Severity setting.)

For further information, see Defining Severities in the ClearSCADA Guide to Core Configuration.

To help protect against ‘denial of service’ attacks, the outstation will transmit only a limited number of authentication error messages before ceasing to report any authentication errors. If the outstation supports and communicates with multiple DNP3 masters, it will pass any authentication error messages onto each of its DNP3 masters. This means that all of the DNP3 masters are made aware of a possible security attack. Each authentication error message includes an ‘Association ID’, which indicates the DNP3 master with which the error is associated. Consult the outstation’s setup to ascertain the master to which an ‘Association ID’ relates.

  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed within the Alarm/Event Logging section of the tab. Use the field to specify the area of interest with which any authentication and Session Key Change alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.


DNP3 Driver Guide - Specify Whether ClearSCADA is to Constantly Poll an Outstation During an Open Line Call (Configuring a DNP3 Outstation)

Specify Whether ClearSCADA is to Constantly Poll an Outstation During an Open Line Call

This section applies to PSTN outstations and outstations that are configured to use PSTN fallback.

PSTN calls to an outstation can be initiated using the One Shot action or the Open Line action. With a One Shot call, ClearSCADA dials the outstation to collect that outstation’s data and then ends the call. With an Open Line call, the outstation remains online for a configurable period (specified using the Maximum Call Length field (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers)).

Use the Poll When Online check box on the PSTN tab to specify whether ClearSCADA is to send integrity polls to the outstation during an Open Line call, once it has retrieved the data from that outstation and performed any user requests.

The Poll When Online check box is selected by default. This results in ClearSCADA sending integrity polls to the outstation while the line remains open. Such polls are constant, but do take into account the PSTN channel’s Scan Parameters settings (such as the Inter Message Delay).

Clear the Poll When Online check box if ClearSCADA is not to constantly poll the outstation once it has retrieved the outstation’s data and the line is still open. This may be preferable if, for instance, the DNP3 outstation is being used to route data to other outstations, or is performing other tasks. If the check box is cleared, ClearSCADA will poll the outstation at the poll rates specified on the outstation’s DNP3 tab for the duration of the call.

ATTENTION: If the Poll When Online check box is clear, but the DNP3 poll rates are too slow, the outstation may terminate the call because its, or its dial-up modem’s, call timers expire. If this situation occurs, ClearSCADA will mark the outstation as failed.


DNP3 Driver Guide - Configure Ethernet Keep Alive Polls (Configuring a DNP3 Outstation)

Configure Ethernet Keep Alive Polls

Use the fields within the Ethernet Keep Alive Poll section of the Direct tab to configure if, and how often, ClearSCADA sends a periodic DNP3 Request Status of Link frame to the outstation. This transmission is designed to stop an Ethernet TCP/IP link from being disconnected by the ClearSCADA server’s operating system, or the outstation, due to long periods of inactivity.

  • Enabled—Select this check box if the ClearSCADA DNP3 driver is to send a periodic DNP3 Request Status of Link frame to the outstation. This ‘dummy poll’ helps to prevent the connection between the outstation and server from becoming disconnected during long periods of inactivity. For instance, if ClearSCADA is configured to poll the outstation at long intervals, and the outstation does not generate unsolicited responses between ClearSCADA polls, the link might be inactive for long periods of time (the ClearSCADA poll rate). This may cause the operating system of the ClearSCADA server, or the outstation, to disconnect the connection, unless a ‘dummy poll’ is sent to maintain some activity over the link.

Clear the Enabled check box if you want to prevent the driver from sending periodic DNP3 Request Status of Link frames to the outstation. Data will be sent over the link only when one of the following occurs:

  • ClearSCADA send a request to the outstation (for example, a Poll)
  • The outstation responds to a request from ClearSCADA
  • The outstation sends a unsolicited response to ClearSCADA
  • ClearSCADA responds to an unsolicited response sent by the outstation.
  • Interval—Specify the minimum rate at which the ClearSCADA DNP3 driver has to send DNP3 frames to the outstation.

Enter the time in the OPC Time Format, for example 10S (for 10 seconds).

If no frames are sent to the outstation within this interval, the ClearSCADA DNP3 driver will send a DNP3 Request Status of Link frame to the outstation.


DNP3 Driver Guide - Specify Whether the Direct Communications Connection is Always Online or only Available on Demand (Configuring a DNP3 Outstation)

Specify Whether the Direct Communications Connection is Always Online or only Available on Demand

Use the fields within the Direct Communications Connection section of the Direct tab to specify the availability of the outstation’s direct connection:

  • On Demand—With many system setups, ClearSCADA maintains a permanent online connection to those outstations with which it communicates using direct comms (as opposed to via a dial-up modem).

For a permanent online connection:

  • Clear the On Demand check box
  • Set the outstation’s Communications Availability to Always on the Outstation tab.

If you only need the direct connection between ClearSCADA and the outstation to be available periodically:

  • Select the On Demand check box, then use the other fields within the Direct Communications Connection section to specify the various properties associated with that connection.
  • Set the outstation’s Communications Availability to Periodic on the Outstation tab. Use the other fields within the Communications Availability section to specify when communications with the outstation is available.

(Should you opt to leave the On Demand check box clear and set the outstation’s Communications Availability to Periodic, ClearSCADA will establish a connection at the start of the available period and then close the connection at the end of the period.)

For information on specifying an outstation’s Communications Availability properties, see Specify the Availability of Communications Between the Outstation and ClearSCADA in the ClearSCADA Guide to Advanced Drivers.

NOTE: If required, a Queue feature can be enabled on your system to allow users to optionally queue certain pick action requests on ‘On Demand’ outstations. For more information, see Define whether the Queue Parameter is Available in the ClearSCADA Guide to Server Administration, and see Optionally Queue Pick Action Requests on PSTN and ‘On Demand’ Outstations in the ClearSCADA Guide to Drivers.

  • Retries—Enter the maximum number of times that the ClearSCADA server will re-attempt to request data from the outstation.

If the outstation fails to respond to the server’s initial data request, the server will make a further request (referred to as a ‘retry’). The server can repeat a data request up to the defined number of Retries.

If the outstation still fails to respond once the number of Retries has been exhausted, ClearSCADA will deem the permanent connection to the outstation to have failed. If the outstation has a dial-up modem as a backup means of communication, the server will then attempt to dial out to the outstation to request the data via PSTN.

  • Timeout—Enter the time that the server will wait before attempting a ‘retry’. This delay is useful, as an immediate retry is likely to fail for the same reason as the previous attempt.

Enter the duration in the OPC Time Format. The default of 30 seconds is suitable for many systems.

  • Max Online Time—Specify the maximum amount of time for which the direct connection is to remain online. Enter the duration in the OPC Time Format.

ClearSCADA terminates the connection as soon as it has retrieved the outstation’s data, or once the Max Online Time is reached, whichever is the shorter, unless:

  • The Close Connection pick action is used to close the open connection.
  • The Extend Connection pick action is used to extend the time for which the open connection remains online.
  • The Open Connection pick action is used to trigger communications with the outstation. An Open Connection keeps the connection open for the whole of the Max Online Time, even after any data retrieval is complete, unless either of the pick actions mentioned above are executed.


DNP3 Driver Guide - Configuring a DNP3 Slave Outstation

Configuring a DNP3 Slave Outstation

This section covers the configuration of DNP3 slave outstations—outstations that allow ClearSCADA to operate as a DNP3 Slave (see Third-Party Master Communicating with a ClearSCADA DNP3 Slave). For information on DNP3 outstations for which ClearSCADA operates as the DNP3 Master, see Configuring a DNP3 Outstation.

When ClearSCADA is configured as a DNP3 Slave, it appears as a DNP3 outstation to a DNP3 master, such as a third-party server. The DNP3 master accesses the data in the ClearSCADA database, by communicating with one or more of the following ClearSCADA database items:

  • DNP3 Slave Direct Outstation—Allows a DNP3 master to access data in the ClearSCADA database using a permanent connection (for example direct serial, radio, or network)
  • DNP3 Slave PSTN Outstation—Allows a DNP3 master to access data in the ClearSCADA database by using a dial-up modem.

You configure outstation properties using the fields on the DNP3 Slave Direct Outstation Form, or the DNP3 Slave PSTN Outstation Form, as appropriate.

Each Form has several tabs.

This section covers configuration of DNP3-specific properties that are on the DNP3 and Security tabs of each Form and on the PSTN tab of the DNP3 Slave PSTN Outstation Form.

For DNP3 Slave Direct Outstations and DNP3 Slave PSTN Outstations, use the DNP3 tab to:

  • Configure the General DNP3 Properties
  • Specify the Communications Parameters
  • Define the Filtered Value Map Locations
  • Specify the DNP3 Static Object Types
  • Specify the DNP3 Event Object Types
  • Configure the Number of Events Required to Generate an Unsolicited Message.

For DNP3 Slave Direct Outstations and DNP3 Slave PSTN Outstations that use DNP3 Secure Authentication, use the Security tab to:

  • Configure the Slave’s Security Properties.

For DNP3 Slave PSTN Outstations, use the PSTN tab to:

  • Define the Common PSTN Properties (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers)
  • Define the PSTN Idle Timeout
  • Define the Delay Between PSTN Call Attempts
  • Configure the Dial In Lines (see Define Dial In Line Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers). DNP3 Slave outstations can support a single Dial In line for reporting alarm data to the DNP3 master.

Properties on the other tabs of each Slave Outstation Form are common to outstations on many advanced drivers. For further information, see Tabs on Outstation Forms in the ClearSCADA Guide to Advanced Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional DNP3 Slave Outstation in ClearSCADA, see Minimum Configuration.


DNP3 Driver Guide - Minimum Configuration (Configuring a DNP3 Slave Outstation)

Minimum Configuration

As a minimum, for a DNP3 Slave outstation to become functional (online), you need to configure these properties, then put the outstation In Service and save the configuration:

  • The outstation Address (DNP3 tab)
  • The address of the DNP3 master (DNP3 tab)
  • The Set to which the outstation belongs (Outstation tab)
  • The Filtered Value Maps that define the locations of ‘point’ data in the outstation (DNP3 tab)
  • The Host Address and Port for any network connected DNP3 outstations (Network tab). (Port number 20000 is the TCP and UDP port that is registered for DNP3 use with the IANA (Internet Assigned Numbers Authority).)
  • If the outstation communicates via PSTN, the Telephone Number of the site on which the outstation is located (PSTN tab).

This will result in a functional DNP3 Slave outstation that uses the default configuration settings.


DNP3 Driver Guide - Configure the General DNP3 Properties (Configuring a DNP3 Slave Outstation)

Configure the General DNP3 Properties

Use the fields at the top of the DNP3 tab to define the general properties of the DNP3 slave outstation:

  • Address—Specify the DNP3 address of the DNP3 Slave outstation. Each DNP3 outstation has to be unique on the system.
  • DNP3 Master Address—Specify the address of the DNP3 master to which the DNP3 Slave outstation sends unsolicited messages.
  • Supports Multi-Master—Use this check box to specify whether the DNP3 Slave outstation is to respond to more than one DNP3 master.

Select the check box for the outstation to respond to masters other than that specified in the DNP3 Master Address field. If you select the check box, you will also need to:

  • Configure any secondary masters so that they only read the Slave outstation’s static data
  • Configure the master that is specified in the DNP3 Master Address field to read the Slave outstation’s event data.

Clear the check box if the Slave outstation is only to respond to the DNP3 master that is specified in the DNP3 Master Address field.

  • Unsolicited Message Generation—Use this check box to specify whether the DNP3 Slave outstation can report event data to the DNP3 master by using unsolicited messages.

Select the check box if the DNP3 Slave outstation is to send event data to the DNP3 master using unsolicited messages.

Clear the check box if the DNP3 Slave outstation is to send event data to the DNP3 master only in response to requests from the DNP3 master.

  • Event Notification Delay—Use this field to specify the delay (in seconds) that the DNP3 Slave outstation waits after an event occurs, before it transmits an unsolicited message containing the event, to the DNP3 master. The delay allows the Slave to accumulate any events that are generated during the delay period. Once the delay has expired, the Slave sends those events to the DNP3 master in the same unsolicited message, (and so less bandwidth is used when sending the messages).

The DNP3 Slave outstation takes into account any Buffered Events settings when transmitting event data in an unsolicited message (see Configure the Number of Events Required to Generate an Unsolicited Message).

  • Select-Before-Operate Timeout—Use this field to specify the maximum time that can elapse between the ClearSCADA slave outstation receiving a DNP3 Select message for a control, and receiving the corresponding DNP3 Operate message.

If the Slave does not receive the DNP3 Operate message within the specified time, the Slave will ignore the control request. The DNP3 master then has to resend both the Select and Operate messages again to perform the control.

  • Clock Set Request Interval—Use this field to specify how often the ClearSCADA slave outstation sets its DNP3 Need Time IIN bit. The slave sets this bit to indicate to the DNP3 master that it should set the clock in the ClearSCADA slave outstation. Enter the interval in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required interval. Specify 0 to configure the Slave so that it will not request a clock set from the DNP3 master.
  • Allow Method Calls—If the DNP3 master is a ClearSCADA server, it can execute methods on items in the database of the ClearSCADA server on which the ClearSCADA slave outstation is located. Select this check box if you want a remote ClearSCADA server to execute methods on items in the local database, via DNP3.
  • Method Call User—Use this field to specify the user (configured in the local ClearSCADA database) that is to execute any remote methods. By configuring the security settings of the items in the local database, you can control what items can, and cannot, have methods called remotely.


DNP3 Driver Guide - Specify the Communications Parameters (Configuring a DNP3 Slave Outstation)

Specify the Communications Parameters

Use this section on the DNP3 tab to specify the DNP3 Slave outstation’s Communications Parameters:

  • Send Data Link Confirmation—Use this combo box to specify when the DNP3 master should send data link confirmations in response to unsolicited frames sent by the ClearSCADA slave outstation. Choose from:
  • Never—The ClearSCADA slave outstation will not request data link confirmations. This is the recommended option unless the communications link between the master and slave is poor.

Any configuration regarding Data Link Retries and Timeouts is ignored.

  • Sometimes—The ClearSCADA slave outstation requests data link confirmations when the unsolicited message contains more than one DNP3 data link layer frame. If the unsolicited message contains only one frame, the ClearSCADA slave outstation does not request data link confirmations.
  • Always—The ClearSCADA slave outstation requests data link confirmations for unsolicited messages with one or more DNP3 data link layer frames.

Select this option if communications are unreliable—for example, devices operating in environments with high levels of electromagnetic noise.

  • Data Link Retries—Applicable if Send Data Link Confirmation is set to an option other than ‘Never’. Use this field to specify the number of times that the ClearSCADA slave outstation is to re-send Data Link frames for which it has requested a confirm, but for which it does not receive a confirm within the Data Link Timeout.

If the ClearSCADA slave outstation does not receive the confirmation within the Data Link Timeout, the Data Link frame is re-sent. If the frame is not confirmed before the timeout of the last retry, the transmission of the frame is deemed to have failed.

  • Data Link Timeout—Applicable if Send Data Link Confirmation is set to an option other than ‘Never’. Use this field to specify how long the ClearSCADA slave outstation is to wait for a Data Link confirmation from its DNP3 master, before re-sending the frame.
  • Application Fragment Timeout—When a ClearSCADA slave outstation sends an unsolicited message to an DNP3 master, it expects a response. You can use the Application Fragment Timeout field to define the maximum amount of time the ClearSCADA slave will wait for the response from the DNP3 master (in milliseconds). If the DNP3 master does not reply within the Application Fragment Timeout period, the message is deemed to have failed. Multiple consecutive failures will cause the communications to fail.

When defining the Application Fragment Timeout period, you need to set a time that:

  • Matches the period that is set on the master device (if this is a DNP3 master outstation, see Specify Different Communications Parameters for an Individual Outstation)
  • Is large enough to allow for any Data Link retries.

You should set the Application Fragment Timeout to at least:

((Data Link Retries + 1) * Data Link Timeout) + 1000

You may need to increase the timeout period if there are a significant number of timeouts.

For more information on the Application Fragment Timeout property, see Configure the Communications Parameters.


DNP3 Driver Guide - Define the Filtered Value Map Locations (Configuring a DNP3 Slave Outstation)

Define the Filtered Value Map Locations

DNP3 slave outstations use Filtered Value Maps to store ‘point’ data. The source of the Value Map data typically comes from another source, such as a Modbus device or an OPC source, and is mapped into ClearSCADA in order to enable the DNP3 master to extract the required data from that device, using the DNP3 protocol.

You need to specify the Filtered Value Maps that each Slave outstation uses, and the location of those Filtered Value Maps within the ClearSCADA database. The Filtered Value Maps that you use for the Slave outstation have to exist on your system and be suitably configured (see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).

Use the fields within the Value Maps section of the DNP3 tab to define the Filtered Value Maps that are associated with the DNP3 slave outstation.

  • Binary Input—Select the Filtered BIT Value Map that represents Binary Inputs on the outstation.
  • Binary Output—Select the Filtered BIT Value Map that represents Binary Outputs on the outstation.
  • Double-bit Binary Input—Select the Filtered BYTE Value Map that represents Double-bit Binary Inputs on the outstation.
  • Analog Input—Select the Filtered REAL Value Map that represents Analog Inputs on the outstation.
  • Analog Output—Select the Filtered REAL Value Map that represents Analog Outputs on the outstation.
  • Running Counter—Select the Filtered UDINT Value Map that represents Counter points on the outstation.
  • Frozen Counter—Select the Filtered UDINT Value Map that represents Frozen Counter points on the outstation.
  • String—Select the Filtered String Value Map that represents String points on the outstation.

Leave the fields blank for any Map types that are not used by the Slave outstation.

Use the fields within the Static Objects section of the tab to Specify the DNP3 Static Object Types that the outstation uses to send current data to the DNP3 master. Use the fields within the Event Objects section of the tab to Specify the DNP3 Event Object Types that the outstation uses to report event data to the DNP3 master.


DNP3 Driver Guide - Specify the DNP3 Static Object Types (Configuring a DNP3 Slave Outstation)

Specify the DNP3 Static Object Types

In the DNP3 protocol, the current value or state of a point is sent to the DNP3 master as a DNP3 Static Object. A DNP3 Static Object is typically sent by the DNP3 Slave outstation in response to a DNP3 Class 0 poll, issued by the DNP3 master.

Example:

A DNP3 master issues a Class 0 poll to a DNP3 Slave outstation.

The outstation responds with a message containing, along with other information, a number of Binary Input Objects. The Binary Input Objects contain the state (and possibly status) of the binary inputs on that ClearSCADA slave outstation.

For each type of point that is associated with a DNP3 Slave outstation, you need to assign a Filtered Value Map (see Define the Filtered Value Map Locations). For each point type that is assigned a Filtered Value Map, use the fields within the Static Objects section of the DNP3 tab to define how the DNP3 Slave outstation formats and presents the Static Object data for those points, to the DNP3 master.

ClearSCADA ignores the Static Object of any points types for which Filtered Value Maps are not configured.

NOTE: The DNP3 Static Objects and formats specified in this section are not used in a response to a DNP3 Level 3 Scan (this object and format is specified by the master when performing a DNP3 Level 3 Scan).

  • Binary Input—Use the combo box to specify the Static Object type that the outstation uses to send current states of binary input points. Choose from:
  • Binary Input (g1v1)—The current state of a binary input is sent without status (quality) flags.
  • Binary Input Status (g1v2)—The current state of a binary input is sent with status (quality) flags.
  • Binary Output—Use the combo box to specify the Static Object type that the outstation uses to send current states of binary output points. Choose from:
  • Binary Output (g10v1)—The current state of a binary output is sent without status (quality) flags.
  • Binary Output Status (g10v2)—The current state of a binary output is sent with status (quality) flags.
  • Double-bit Binary Input—Use the combo box to specify the Static Object type that the outstation uses to send current states of double-bit binary input points. Choose from:
  • Double-bit Binary Input (g3v1)—The current state of a double-bit binary input is sent without status (quality) flags.
  • Double-bit Binary Input Status (g3v2)—The current state of a double-bit binary input is sent with status (quality) flags.
  • Analog Input—Use the combo box to specify the Static Object type that the outstation uses to send current values of analog input points. Choose from:
  • 32-bit Analog Input (g30v1)—The current value of an analog input point is sent as a signed, 32-bit integer with status (quality) flags.
  • 16-bit Analog Input (g30v2)—The current value of an analog input point is sent as a signed, 16-bit integer with status (quality) flags.
  • 32-bit Analog Input No Flag (g30v3)—The current value of an analog input point is sent as a signed, 32-bit integer without status (quality) flags.
  • 16-bit Analog Input No Flag (g30v4)—The current value of an analog input point is sent as a signed, 16-bit integer without status (quality) flags.
  • Short Float Analog Input (g30v5)—The current value of an analog input point is sent as a signed, IEEE single-precision (32-bit) floating point number with status (quality) flags.
  • Double Float Analog Input (g30v6)—The current value of an analog input point is sent as a signed, IEEE double-precision (64-bit) floating point number with status (quality) flags.
  • Analog Output—Use the combo box to specify the Static Object type that the outstation uses to send current values of analog output points. Choose from:
  • 32-bit Analog Output Status (g40v1)—The current value of an analog output point is sent as a signed, 32-bit integer with status (quality) flags.
  • 16-bit Analog Output Status (g40v2)—The current value of an analog output point is sent as a signed, 16-bit integer with status (quality) flags.
  • Short Floating Point Analog Output Status (g40v3)—The current value of an analog output point is sent as a signed, IEEE single-precision (32-bit) floating point number with status (quality) flags.
  • Double Floating Point Analog Output Status (g40v4)—The current value of an analog output point is sent as a signed, IEEE double-precision (64-bit) floating point number with status (quality) flags.
  • Running Counter—Use the combo box to specify the Static Object type that the outstation uses to send current values of counters. Choose from:
  • 32-bit Binary Counter (g20v1)—The current value of a counter point is sent as an unsigned, 32-bit integer with status (quality) flags.
  • 16-bit Binary Counter (g20v2)—The current value of a counter point is sent as an unsigned, 16-bit integer with status (quality) flags.
  • 32-bit Counter No Flag (g20v5)—The current value of a counter point is sent as an unsigned, 32-bit integer without status (quality) flags.
  • 16-bit Counter No Flag (g20v6)—The current value of a counter point is sent as an unsigned, 16-bit integer without status (quality) flags.
  • Frozen Counter—Use the combo box to specify the Static Object type that the outstation uses to send current values of frozen counters. Choose from:
  • 32-bit Frozen Counter (g21v1)—The current value of a frozen counter point is sent as an unsigned, 32-bit integer with status (quality) flags.
  • 16-bit Frozen Counter (g21v2)—The current value of a frozen counter point is sent as an unsigned, 16-bit integer with status (quality) flags.
  • 32-bit Frozen Counter No Flag (g21v9)—The current value of a frozen counter point is sent as an unsigned, 32-bit integer without status (quality) flags.
  • 16-bit Frozen Counter No Flag (g21v10)—The current value of a frozen counter point is sent as an unsigned, 16-bit integer without status (quality) flags.
  • Send Counter Objects In Class 0 Reply—Use this combo box to specify which counter values the DNP3 Slave outstation sends as static data to the DNP3 master. Choose from:
  • Binary Counter Only—The outstation sends the current values of its binary (running) counter points. The values are sent in the format specified in the Static Object section’s Running Counter field.

The current values of any frozen counter points are not sent.

  • Frozen Counter Only—The outstation sends the current values of its frozen counter points. The values are sent in the format specified in the Static Object section’s Frozen Counter field.

The current values of any running counter points are not sent.

  • Binary and Frozen Counter—The outstation sends the current values of its running and frozen counter points.

Running counter values are sent in the format specified in the Static Object section’s Running Counter field.

Frozen counter values are sent in the format specified in the Static Object section’s Frozen Counter field.

The field is ignored if no Counter or Frozen Counter Maps are configured.


DNP3 Driver Guide - Specify the DNP3 Event Object Types (Configuring a DNP3 Slave Outstation)

Specify the DNP3 Event Object Types

A ClearSCADA DNP3 Slave outstation is capable of buffering changes to point values and states. The outstation can send these buffered events to its DNP3 master either in an unsolicited message, or in response to a request from the DNP3 master.

The format in which the Slave outstation sends its buffered events is specified using a DNP3 Event Object.

For each type of point that is associated with a DNP3 Slave outstation, you need to assign a Filtered Value Map (see Define the Filtered Value Map Locations). For each point type that is assigned a Filtered Value Map, use the fields within the Event Objects section of the DNP3 tab to define how the DNP3 Slave outstation formats and presents the event data for those points, to the DNP3 master.

ClearSCADA ignores the Event Objects of any points types for which Filtered Value Maps are not configured.

  • Binary Input—Specify the DNP3 Event Object that the outstation uses when sending events that contain the states of binary input points. Choose from:
  • Not Generated—Buffered events are not generated for binary points.
  • Binary Input Change No Time (g2v1)—Binary events are reported without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • Binary Input Change with Time (g2v2)—Each binary event reported to the DNP3 master has a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Binary Input Change Relative Time (g2v3)—Each DNP3 message reported to the DNP3 master has a single time stamp. Each binary event in the message has an offset relative to this time stamp. If the DNP3 master logs these events, it uses the time stamp supplied in the message, adjusted by the event’s offset.
  • Binary Output—Specify the DNP3 Event Object that the outstation uses when sending events that contain the states of binary output points. Choose from:
  • Not Generated—Buffered events are not generated for binary output points.
  • Binary Output Change No Time (g11v1)—Binary output events are reported without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • Binary Output Change with Time (g11v2)—Each binary output event reported to the DNP3 master has a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Double-bit Binary Input—Specify the DNP3 Event Object that the outstation uses when sending events that contain the states of double-bit binary input points. Choose from:
  • Not Generated—Buffered events are not generated for double-bit binary points.
  • Double-bit Binary Input Change No Time (g4v1)—Double-bit binary events are reported without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • Double-bit Binary Input Change with Time (g4v2)—Each double-bit binary event reported to the DNP3 master has a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Double-bit Binary Input Change Relative Time (g4v3)—Each DNP3 message reported to the DNP3 master has a single time stamp. Each double-bit binary event in the message has an offset relative to this time stamp. If the DNP3 master logs these events, it uses the time stamp supplied in the message, adjusted by the event’s offset.
  • Analog Input—Specify the DNP3 Event Object that the outstation uses when sending events that contain the values of unscaled (raw) analog points. Choose from:
  • Not Generated—Buffered events are not generated for analog points.
  • 32-bit Analog Input Change No Time (g32v1)—Unscaled analog events are reported as 32-bit signed integers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • 16-bit Analog Input Change No Time (g32v2)—Unscaled analog events are reported as 16-bit signed integers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • 32-bit Analog Input Change with Time (g32v3)—Unscaled analog events are reported as 32-bit signed integers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • 16-bit Analog Input Change with Time (g32v4)—Unscaled analog events are reported as 16-bit signed integers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Analog Output—Specify the DNP3 Event Object that the outstation uses when sending events that contain the values of unscaled (raw) analog output points. Choose from:
  • Not Generated—Buffered events are not generated for analog output points.
  • 32-bit Analog Output Change No Time (g42v1)—Unscaled analog events are reported as 32-bit signed integers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • 16-bit Analog Output Change No Time (g42v2)—Unscaled analog events are reported as 16-bit signed integers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • 32-bit Analog Output Change with Time (g42v3)—Unscaled analog events are reported as 32-bit signed integers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • 16-bit Analog Output Change with Time (g42v4)—Unscaled analog events are reported as 16-bit signed integers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Float Input—Specify the DNP3 Event Object that the outstation uses when sending events that contain the values of scaled analog points. Choose from:
  • Not Generated—Buffered events are not generated for floating points.
  • Short Float Analog Input Change No Time (g32v5)—Scaled analog events are reported as IEEE single-precision (32-bit) floating point numbers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • Double Float Analog Input Change No Time (g32v6)—Scaled analog events are reported as IEEE double-precision (64-bit) floating point numbers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • Short Float Analog Input Change with Time (g32v7)—Scaled analog events are reported as IEEE single-precision (32-bit) floating point numbers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Double Float Analog Input Change with Time (g32v8)—Scaled analog events are reported as IEEE double-precision (64-bit) floating point numbers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Float Output—Specify the DNP3 Event Object that the outstation uses when sending events that contain the values of scaled analog output points. Choose from:
  • Not Generated—Buffered events are not generated for floating points.
  • Short Float Analog Output Change No Time (g42v5)—Scaled analog events are reported as IEEE single-precision (32-bit) floating point numbers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • Double Float Analog Output Change No Time (g42v6)—Scaled analog events are reported as IEEE double-precision (64-bit) floating point numbers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • Short Float Analog Output Change with Time (g42v7)—Scaled analog events are reported as IEEE single-precision (32-bit) floating point numbers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Double Float Analog Output Change with Time (g42v8)—Scaled analog events are reported as IEEE double-precision (64-bit) floating point numbers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Running Counter—Specify the DNP3 Event Object that the outstation uses when sending events that contain the values of counter points. Choose from:
  • Not Generated—Buffered events are not generated for counter points.
  • 32-bit Counter Change No Time (g22v1)—Counter events are reported as 32-bit unsigned integers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • 16-bit Counter Change No Time (g22v2)—Counter events are reported as 16-bit unsigned integers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • 32-bit Counter Change with Time (g22v5)—Counter events are reported as 32-bit unsigned integers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • 16-bit Counter Change with Time (g22v6)—Counter events are reported as 16-bit unsigned integers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Frozen Counter—Specify the DNP3 Event Object that the outstation uses when sending events that contain the values of frozen counter points. Choose from:
  • Not Generated—Buffered events are not generated for frozen counter points.
  • 32-bit Frz Cnt Change No Time (g23v1)—Frozen counter events are reported as 32-bit unsigned integers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • 16-bit Frz Cnt No Time (g23v2)—Frozen counter events are reported as 16-bit unsigned integers, without a time stamp. If the DNP3 master logs these events, it applies a time stamp (which indicates the time that the DNP3 master received the event).
  • 32-bit Frz Cnt Change with Time (g23v5)—Frozen counter events are reported as 32-bit unsigned integers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • 16-bit Frz Cnt Change with Time (g23v6)—Frozen counter events are reported as 16-bit unsigned integers, with a time stamp. If the DNP3 master logs these events, it uses the time stamp supplied by the DNP3 Slave outstation.
  • Max Virtual Terminal Events—Use this field to specify the maximum number of Virtual Terminal events that the DNP3 Slave outstation is to buffer.

Should the number of entries in the outstation’s event buffer be exceeded, the outstation will discard the oldest Virtual Terminal events, until the number of Virtual Terminal events equals the Max Events value.


DNP3 Driver Guide - Configure the Number of Events Required to Generate an Unsolicited Message (Configuring a DNP3 Slave Outstation)

Configure the Number of Events Required to Generate an Unsolicited Message

Use the fields within the Buffered Events section of the DNP3 tab to define the minimum number of buffered events that are required in order for ClearSCADA to send a unsolicited message to the DNP3 master. When ClearSCADA generates an unsolicited response, it sends the buffered events (of all enabled event classes) for the DNP3 Slave outstation to the DNP3 master.

  • Class n Minimum Events—Specify the number of Class 1, Class 2, and Class 3 events that have to accumulate before the DNP3 slave outstation sends an unsolicited message containing event data, to the DNP3 master.

Example:

A DNP3 Slave outstation is configured to send unsolicited messages to its master. The outstation has this configuration:

Class 1 Minimum Events: 10
Event Notification Delay: 10 seconds

The DNP3 Slave outstation has nine Class 1 events in its buffer.

A tenth Class 1 event is added to the DNP3 Slave outstation’s event buffer.

Seven seconds after the tenth event, an eleventh Class 1 event is added to the DNP3 Slave outstation’s event buffer.

Ten seconds after the tenth event was added the DNP3 Slave outstation’s event buffer, ClearSCADA will send an unsolicited message to the DNP3 master. This message will contain eleven events.

After another two seconds, a twelfth Class 1 event is added to the DNP3 Slave outstation’s event buffer.

After the DNP3 master responds to the slave’s unsolicited message, ClearSCADA will remove the first eleven events from the DNP3 Slave outstation’s event buffer, leaving one event in the buffer (the event that occurred after the outstation sent the unsolicited message to the DNP3 master).

(The Event Notification Delay field is near the top of the DNP3 tab—for information, see Configure the General DNP3 Properties.)


DNP3 Driver Guide - Configure the Slave's Security Properties (Configuring a DNP3 Slave Outstation)

Configure the Slave’s Security Properties

Use the fields on the Security tab of each DNP3 Slave Outstation Form to specify properties that relate to DNP3 Secure Authentication when ClearSCADA is operating as a DNP3 Slave.

Use the fields on the Security tab to:

  • Specify Whether DNP3 Secure Authentication is Used
  • Specify the Algorithms used to Secure Message Content
  • Specify When the Slave Outstation is to Invalidate its Pair of Session Keys
  • Specify Whether Aggressive Mode is Used
  • Specify the Maximum Error Count
  • Define Whether the Slave Outstation Logs Authentication and Key Change Information.


DNP3 Driver Guide - Specify Whether DNP3 Secure Authentication is Used (Configuring a DNP3 Slave Outstation)

Specify Whether DNP3 Secure Authentication is Used

Use the Enabled check box at the top of a DNP3 Slave Outstation’s Security tab to specify whether the Slave outstation uses DNP3 Secure Authentication:

  • Clear the check box if DNP3 Secure Authentication is not used for any transmissions to or from this Slave outstation. Cleared is the default setting for the Enabled check box.

A Slave outstation that does not use DNP3 Secure Authentication is known as a non-secure device. Messages sent to or from the Slave outstation are transmitted in the normal way, using the DNP3 protocol (see Scanning for Data on DNP3 Devices). None of the messages are challenged by the receiving device before being processed.

  • Select the Enabled check box if DNP3 Secure Authentication is to be used for critical transmissions to and/or from this Slave outstation (ClearSCADA). The Slave’s DNP3 master(s) has to support DNP3 Secure Authentication version 2.00. Use the rest of the fields on the Security tab to define the Slave outstation’s DNP3 Secure Authentication properties.


DNP3 Driver Guide - Specify the Algorithms used to Secure Message Content (Configuring a DNP3 Slave Outstation)

Specify the Algorithms used to Secure Message Content

Use the fields within the Algorithms section of the Security tab to specify which HMAC and Key Wrap algorithms are used by this Slave outstation and its DNP3 master(s):

  • HMAC—Use to specify which Hash-based Message Authentication Code (HMAC) algorithm:
  • the Slave outstation is to use when responding to Key Status or Session Key Change requests sent by its DNP3 master(s)
  • the DNP3 master(s) are to use when responding to challenges sent by this Slave outstation (ClearSCADA)
  • the DNP3 master(s) are to use when issuing Aggressive Mode requests to this Slave outstation. (This only applies if the DNP3 master(s) are configured to issue, and the Slave outstation is configured to accept, Aggressive Mode requests—see Specify Whether Aggressive Mode is Used.)

We recommend that you select the largest HMAC supported by the DNP3 master(s) and appropriate to the type of communications being used.

  • Key Wrap—The DNP3 master uses this Key Wrap algorithm to encrypt the Session Keys during a Session Key Change, using a pre-shared Update Key. The algorithm also determines the length of the Update Key.

The Slave outstation (ClearSCADA) determines which Key Wrap algorithm the DNP3 master is to use during each Session Key Change. ClearSCADA supports a single Key Wrap algorithm, the Advanced Encryption Standard (AES) AES-128. The AES-128 algorithm requires a 128-bit Update Key, comprising 32 hexadecimal digits.


DNP3 Driver Guide - Specify When the Slave Outstation is to Invalidate its Pair of Session Keys (Configuring a DNP3 Slave Outstation)

Specify When the Slave Outstation is to Invalidate its Pair of Session Keys

To maintain security, the DNP3 master changes the Slave outstation’s current set of Session Keys whenever the DNP3 master’s change interval or change count is reached (whichever is the shorter). The DNP3 master also changes the Session Keys after detecting any communications failure.

Use the fields within the Session Keys section of the Security tab to specify how long the Slave outstation (ClearSCADA) should wait before invalidating its pair of Session Keys, should an expected Session Key Change not occur.

Ideally, the values that you specify in these fields should be twice the size of the values set in the DNP3 master. This will mean that ClearSCADA does not invalidate its Session Keys unnecessarily, should a Session Key Change be delayed when the system is exceptionally busy. (Should the Slave outstation invalidate its Session Keys, it will be unable to process any further critical requests. This will result in authentication failures, causing the DNP3 master to issue a new set of Session Keys once the DNP3 master’s Maximum Error Count has been exceeded.)

  • Change Interval—Use to specify the frequency with which the Slave outstation should invalidate its Session Keys.

We recommend that you specify an interval that is twice that of the DNP3 master’s change interval.

The default is 30M (30 minutes). If a different interval is required, either overtype the existing entry or use the Interval Window (accessed via the field’s browse button) to specify the required interval. When entering the Change Interval, you need to use the OPC Time Format.

The interval timer is reset whenever a Session Key Change occurs or the Slave outstation’s Change Count is reached (whichever is the shorter).

If required, you can disable the Change Interval by specifying an interval of 0 (zero). With such an interval, ClearSCADA invalidates its Session Keys whenever the Change Count is reached.

  • Change Count—Use the specify the maximum number of authentication messages that can be transmitted between the Slave outstation (ClearSCADA) and its DNP3 master before ClearSCADA is to invalidate its Session Keys.

We recommend that you specify a Change Count that is twice that of the DNP3 master’s change count.

The interval timer is reset whenever a Session Key Change occurs or the Slave outstation’s Change Interval is reached (whichever is the shorter).


DNP3 Driver Guide - Specify Whether Aggressive Mode is Used (Configuring a DNP3 Slave Outstation)

Specify Whether Aggressive Mode is Used

Use the check boxes within the Aggressive Mode section of the Security tab to specify whether the Slave outstation (ClearSCADA) is to accept or issue requests using Aggressive Mode:

  • Accept Requests—Select this check box if the Slave outstation (ClearSCADA) is to accept Aggressive Mode requests from its DNP3 master(s). With such requests, the DNP3 master includes the necessary authentication data in the same message as the critical request.

Clear the Accept Requests check box if the Slave outstation is to reject any Aggressive Mode requests that it receives from its DNP3 master(s). The Slave outstation may also send a diagnostics message indicating that it does not accept Aggressive Mode requests (see Specify the Maximum Error Count).

  • Issue Requests—Select this check box if the Slave outstation (ClearSCADA) is to send Aggressive Mode responses to its DNP3 master(s). With such responses, the Slave outstation includes the necessary authentication data in the same message as the critical response.

Clear the Issue Requests check box if the Slave outstation is not to send Aggressive Mode responses. The DNP3 master(s) will challenge any critical responses that they receives from this Slave outstation.

NOTE: If the Slave outstation issues an Aggressive Mode response to a DNP3 master that does not accept Aggressive Mode responses, the DNP3 master will generate an error (providing that the DNP3 master has not exceeded its maximum error count). On detecting such an error, the Slave outstation will send responses to subsequent requests, and issue any unsolicited messages, without using Aggressive Mode. As such, the Slave outstation will expect the DNP3 master to challenge such responses. The Slave outstation will not use Aggressive Mode for any other responses that it sends to the DNP3 master.
Should such a security conflict occur, correct the configuration in the relevant device so that the appropriate mode of DNP3 Secure Authentication is used. (If the configuration is not corrected, the Slave outstation will attempt to issue further Aggressive Mode responses should, for example, a Main-Standby changeover occur, the driver restart, or another configuration change be made.)


DNP3 Driver Guide - Specify the Maximum Error Count (Configuring a DNP3 Slave Outstation)

Specify the Maximum Error Count

Should an error occur during any part of the authentication process, the slave outstation (ClearSCADA) will determine whether it needs to report that error to its DNP3 master. For example, the slave outstation might send a diagnostics message if it has issued a challenge in response to a critical request from its DNP3 master, but has either not received a response to that challenge, or received an incorrect response.

A malicious user may use a device to mount a denial-of-service attack against ClearSCADA by repeatedly sending ‘bad’ authentication messages. They may also send repeated challenges in an attempt to learn about the slave outstation’s authentication. The Maximum Error Count setting helps to protect against such attacks by stopping the slave outstation from transmitting error messages once a defined limit has been exceeded. This is in accordance with the DNP3 standard.

Use the Maximum Error Count spin box on the Security tab to specify the maximum number of authentication errors that the Slave outstation is to generate:

You can specify a maximum error count of between 0 and 10 inclusive (with 2 being the default). Once this count has been exceeded, the slave outstation will no longer send authentication error messages to its DNP3 master.

The Maximum Error Count resets when either of the following occur:

  • The slave outstation receives an authentic reply to its latest challenge
  • The Session Keys are changed (see Specify When the Slave Outstation is to Invalidate its Pair of Session Keys).

If the error count is exceeded, the slave outstation will invalidate its Session Keys.

Further Information

Define Whether the Slave Outstation Logs Authentication and Key Change Information.

Aggressive Mode: see Specify Whether Aggressive Mode is Used.


DNP3 Driver Guide - Define Whether the Slave Outstation Logs Authentication and Key Change Information (Configuring a DNP3 Slave Outstation)

Define Whether the Slave Outstation Logs Authentication and Key Change Information

The Slave outstation (ClearSCADA) can log information about both successful and unsuccessful authentications and Session Key Changes. (To help protect against ‘denial of service’ attacks, the Slave outstation (ClearSCADA) will transmit only a limited number of error messages before ceasing to send such messages (see Specify the Maximum Error Count).)

Use the field(s) within the Alarm/Event Logging section of the DNP3 Slave Outstation Form’s Security tab to define the priority that ClearSCADA assigns to the authentication and key change information that it logs for this Slave outstation.

  • Severity—Use this combo box to specify the priority that is assigned to the alarms and events that ClearSCADA logs in relation to authentications and Session Key Changes.

ClearSCADA assigns this priority to the:

  • events that it logs for successful authentications
  • alarms that it logs for any unsuccessful authentications and any authentication errors that it has received.

(If required, you can select ‘None’ to set ClearSCADA so that it does not log any messages related to successful and unsuccessful authentications. However, we recommend that you choose one of the other Severity settings so that there is a record of authentications).

For further information, see Defining Severities in the ClearSCADA Guide to Core Configuration.

  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed within the Alarm/Event Logging section of the tab. Use the field to specify the area of interest with which any authentication and Session Key Change alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For further information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.


DNP3 Driver Guide - Define the PSTN Idle Timeout (Configuring a DNP3 Slave Outstation)

Define the PSTN Idle Timeout

Use the PSTN Idle Comms Timeout field on the PSTN tab to specify the maximum amount of time that a Slave maintains PSTN communications with its master when no communications traffic is detected on the line that is in use.

If no further communications traffic is detected, the call is terminated once the timeout elapses.

Specify the required timeout period in seconds.


DNP3 Driver Guide - Define the Delay Between PSTN Call Attempts (Configuring a DNP3 Slave Outstation)

Define the Delay Between PSTN Call Attempts

Use the Delay Between Call Attempts field on the PSTN tab to specify the delay that is to occur between the Slave attempting to call its master with alarm data, and the Slave making another attempt to dial out to its master, if the previous attempt and its retries fail.

Should the initial dial out attempt fail, the Slave will retry the call for the number of times specified in the Retries field. If the call is still unsuccessful, the Slave will wait for the time specified in the Delay Between Call Attempts field, before attempting the to contact its DNP3 master again.

Specify the required delay in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required offset.

(For further information on the Retries field, and the other fields on the PSTN tab that are common to PSTN outstations on many advanced drivers, see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers.)


DNP3 Driver Guide - Configuring DNP3 Virtual Terminals

Configuring DNP3 Virtual Terminals

You can use VT Service Port and Virtual Terminal configuration to allow data to be transported between, for example, a series of flow computers and a flow computer configuration tool, using the DNP3 protocol. By using VT Service Ports and Virtual Terminals, the ClearSCADA system and its outstations act as a ‘transparent’ means of routing communications. Furthermore, data transfers that would otherwise have required a separate physical connection to a non-DNP3 port can proceed over an existing DNP3 port.

This section explains the Preparation and Configuration Order that you need to follow to successfully configure ClearSCADA to transport data using the DNP3 protocol.

It also explains how to:

  • Configure a DNP3 VT Service Port Master
  • Configure a DNP3 Virtual Terminal
  • Configure a VT Service Port Slave.

For information on the minimal amount of configuration that you can undertake to enable ClearSCADA to transport data using the DNP3 protocol, see Minimum Configuration.

For examples demonstrating how you might configure a ClearSCADA system to transport data using the DNP3 protocol, see Example Configuration.


DNP3 Driver Guide - Preparation and Configuration Order (Configuring DNP3 Virtual Terminals)

Preparation and Configuration Order

You need to configure a VT Service Port Master before you can successfully configure any Virtual Terminals that are associated with that service port. You need to configure a VT Service Port Master for each external application on which you want a DNP3 port to double as a virtual service port. The virtual service port allows ‘transparent’ transfer of data via a ClearSCADA system, using the DNP3 and Virtual Terminal protocols (see Example Configuration).

You need to configure one Virtual Terminal for each outstation port through which communications are being routed. You also need to indicate the type of VT support required for each outstation. This is specified on the DNP3 tab of the DNP3 master Outstation Form (see Configure Virtual Terminal Support).

Before you can successfully configure a VT Service Port Slave, you need to have configured the DNP3 Slave outstation on which the service port is located.

Further Information

Configure a DNP3 VT Service Port Master.

Configure a DNP3 Virtual Terminal.

Configuring a DNP3 Slave Outstation.

Configure a VT Service Port Slave.


DNP3 Driver Guide - Minimum Configuration (Configuring DNP3 Virtual Terminals)

Minimum Configuration

For a Virtual Terminal to be functional, you need to specify (as a minimum):

  • The outstation with which the terminal is to be associated
  • The unique number that identifies the port on the outstation
  • The Master Service port that the terminal is to use.

For a VT Service Port Slave to be functional, you need to specify (as a minimum):

  • The DNP3 Slave outstation on which the port is located
  • The unique number that identifies the port that is to be used on that outstation (this number has to correspond to the number of a Virtual Terminal).

In either case, you need to put the item In Service and save the configuration.


DNP3 Driver Guide - Example Configuration (Configuring DNP3 Virtual Terminals)

Example Configuration

This section includes a series of examples that demonstrate how ClearSCADA might be configured to enable it to transfer data using the DNP3 protocol.

The examples in this section are:

  • Example DNP3 Master and Slave Configuration
  • Transfer Data Between a Configuration Tool and Three Flow Computers.


DNP3 Driver Guide - Example DNP3 Master and Slave Configuration (Configuring DNP3 Virtual Terminals)

Example DNP3 Master and Slave Configuration

This example demonstrates how ClearSCADA might be used to transfer data between a Flow Computer Configuration Tool and several Flow Computers.

Additionally, it also demonstrates how a DNP3 Slave might be used to transfer the data to a third-party server.

Example:

On a particular ClearSCADA system, data is transferred between the Flow Computer Configuration Tool and several Flow Computers. In order not to use a further physical port at the ClearSCADA server, an existing DNP3 port doubles as a virtual Service Port for the duration that Flow Computer data is transferred.

In this example, the DNP3 outstations retrieve and transmit data to the Flow computers. Again, existing DNP3 ports ‘double up’ to transfer data to and from the Flow computers, as required.

Virtual Terminal configuration within ClearSCADA specifies the ports for the data transfer. The DNP3 outstations use the Virtual Terminal configuration to determine which physical ports are used.

Where the data transfer takes place using a DNP3 Slave, VT Service Port Slave settings determine how the existing DNP3 port is used on the Slave to transfer the data. The port doubles as a virtual Service Port for the duration that the data is transferred.

By using the Virtual Terminal protocol, the data flow is transparent between the Flow Computers and the Flow Computer Configuration Tool.

Further Information

Preparation and Configuration Order.


DNP3 Driver Guide - Transfer Data Between a Configuration Tool and Three Flow Computers (Configuring DNP3 Virtual Terminals)

Transfer Data Between a Configuration Tool and Three Flow Computers

This example demonstrates how ClearSCADA might be configured in order for it to transfer data between a Flow Computer Configuration Tool and three Flow Computers.

Example:

A ClearSCADA system is used to transfer data between a Flow Computer Configuration Tool and three Flow Computers. In order to facilitate this, a VT Service Port Master is configured in the ClearSCADA database, along with three Virtual Terminals—one terminal for each outstation port (A, B, and C) that is being used to route the communications. Each Virtual Terminal Number configured in the database is used to uniquely identify one of the outstation ports.

The same ClearSCADA system is also used to transfer data between two DEC VT Terminals. In order to facilitate this, a second VT Service Port Master is configured in the ClearSCADA database, along with a fourth Virtual Terminal. This Virtual Terminal is for outstation port D—the port that is being used to route the communications to the DEC VT Terminal.

The ‘Master Port’ field on the Virtual Terminal Form is used to define which VT Service Port Master is associated with each Virtual Terminal.

Further Information

Configure a DNP3 VT Service Port Master.

Configure a DNP3 Virtual Terminal.

Define the Virtual Terminal Support requirements using the DNP3 master Outstation Form: see Configure Virtual Terminal Support.


DNP3 Driver Guide - Configure a DNP3 VT Service Port Master (Configuring DNP3 Virtual Terminals)

Configure a DNP3 VT Service Port Master

This section covers configuration of properties that are specific to a DNP3 VT Service Port Master.

The VT Service Port Master Form has several tabs.

Use the Master VT Port tab to:

  • Configure the Master VT Port Properties
  • Specify the Frequency with which Communications Statistics are Updated.

Use the Connection tab to define the connection-specific settings for the port. Select the connection type that the outstation uses from these options:

  • Serial connection (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Drivers).
  • Remote Serial connection (see Configure a Channel’s Remote Serial Connection Properties in the ClearSCADA Guide to Drivers).

The properties on the other tabs are common to many database items. For information on these properties, see Tabs that are Common to Many Configuration Forms in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Configure the Master VT Port Properties (Configuring DNP3 Virtual Terminals)

Configure the Master VT Port Properties

Use the fields at the top of the Master VT Port tab to define these general properties of the service port:

  • In Service—Use to specify whether the virtual port is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Severity—Use the combo box to define the priority of any alarms or events that are associated with the port (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed on the tab. Use the field to specify the Area of Interest with which any VT Service Port Master alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Typical Message Size—Specify the typical size, in bytes, of a virtual terminal message. Once the service port receives this many bytes, it sends the message to the DNP3 outstation that is specified on the associated DNP3 Virtual Terminal Form (see Configure a DNP3 Virtual Terminal).

If the number of bytes received on the service port does not reach this value, the message is sent after the Message Timeout (see below).

If a message larger than the specified size is received, the service port splits the message into separate data packets. Each data packet is of the size specified in this Typical Message Size field, with the exception of the last data packet, which may be smaller. The service port sends those data packets that are of the specified Typical Message Size to the DNP3 outstation immediately. If the final data packet is smaller than the specified Typical Message Size and no further data is waiting to be sent that would bring it up to the Typical Message Size, the final data packet is delayed by the time specified in the Message Timeout field (see below).

If a packet exceeds 255 bytes, it is split into smaller data packets (255 bytes is the maximum message size imposed by DNP3).

  • Message Timeout—Specify the time, in milliseconds, that the service port has to wait before sending a message that is smaller than the Typical Message Size (see above).

Example:

A VT Service Port has this configuration:

Typical Message Size: 10
Message Timeout: 20

A message 10 bytes in size is received and passed on immediately to the Slave.

A message of 8 bytes is received. The service port waits for 20ms before passing the message onto the Slave.

A message of 12 bytes is received. The service port splits the messages into two packets. The first 10-byte packet is immediately passed on to the Slave. The service port then waits 20ms before passing the remainder of the message on to the Slave in the next data packet.

A message of 21 bytes is received. This is split into three data packets. The service port immediately sends both 10-byte packets to the Slave. After 20ms, it sends the remaining 1-byte packet to the Slave. (Should the VT Service Port have received a further 9-byte message within the 20-second timeout period, it would have sent the remaining 1-byte of data, along with the new 9-byte message, in a single 10-byte data packet, as soon as it had accumulated that 10 bytes-worth of data.)

  • Line Speed—Use to specify the speed of the slowest part of the connection between the ClearSCADA server and the external application, so that ClearSCADA can correctly calculate the transmission time for each message that is transmitted via the service port.

If the entire connection uses the same speed (the baud rate), you can set the Line Speed to Same as Baud Rate. (The baud rate is specified on the VT Service Port’s Connection tab.)

If part of the connection uses a slower speed, specify that speed in the Line Speed combo box.

For more information on Line Speed, see Defining Scan Parameter Settings for a Channel in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Specify the Frequency with which Communications Statistics are Updated (Configuring DNP3 Virtual Terminals)

Specify the Frequency with which Communications Statistics are Updated

Use the fields within the Communication Statistic Updates section of the tab to define how often the communication statistics are updated for the VT Port. You can view the statistics on the port’s Status display.

  • Interval—Use to specify the frequency at which the VT Port’s communications statistics are updated. Enter the frequency in the OPC Time Format, for example, 1M (for one minute), or specify 0 to disable the Communications Statistics feature.
  • Offset—Use to specify the offset, from midnight, for the first communications statistics update. Thereafter, the statistics are updated at the frequency specified in the Interval field, above.

Enter the offset in the OPC Time Format, for example 30S (for a 30-second offset).

With either field, you can enter the required value directly in the field, or use the Interval Window (accessed via each field’s browse button) to specify the required interval or offset.

Example:

The Communication Statistic Updates settings for a VT Service Port Master are configured as:

Interval: 1M
Offset: 30S

If the time is currently 00:00:00, the next Communications Statistics update will occur at 00:00:30, followed by another update at 00:01:30, then another update at 00:02:30, and so on, at 1-minute intervals offset to 30-seconds past each minute.


DNP3 Driver Guide - Configure a DNP3 Virtual Terminal (Configuring DNP3 Virtual Terminals)

Configure a DNP3 Virtual Terminal

Use the DNP3 Virtual Terminal Form to specify the properties of a Virtual Terminal. The DNP3 Virtual Terminal Form has several tabs. Properties on the following tabs are common to many database items—for information on these properties, see the references listed below:

  • Identification—Use to define the Identification properties of the virtual terminal (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for the virtual terminal (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).

Use the fields on the Virtual Terminal tab to link a DNP3 VT Service Port Master to a DNP3 outstation:

  • In Service—Use to specify whether the virtual terminal is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Outstation—Specify the DNP3 outstation on which the virtual terminal is located. Use the browse button to display a Reference browse window and select the required outstation from the window.
  • Virtual Terminal Number—Allocate a unique ID number to the virtual terminal. The number is used to uniquely identify the outstation port through which communications are being routed. The number has to be the same as the port identifier for the outstation. Where the port is on a DNP3 Slave outstation, the Virtual Terminal Number has to be identical to the Point Number on the corresponding VT Service Port Slave Form (see Configure a VT Service Port Slave).

Enter the required number, which has to be within the range 0 to 65534.

  • Master Port—Specify the VT Service Port Master with which the virtual terminal is associated. Use the browse button to display a Reference browse window and select the required service port from the window.


DNP3 Driver Guide - Configure a VT Service Port Slave (Configuring DNP3 Virtual Terminals)

Configure a VT Service Port Slave

A VT Service Port Slave allows a DNP3 Virtual Terminal to transfer data transparently between a port on the ClearSCADA server DNP3 master, via a DNP3 Slave outstation item configured in the ClearSCADA database.

Where more than one port is used on a Slave outstation, you need to configure one VT Service Port Slave for each port.

Configure the service port settings using the VT Service Port Slave Form. The Form has several tabs.

Use the Connection tab to define the connection-specific settings for the port. The port uses serial communications (see Configure a Channel’s Serial Connection Properties in the ClearSCADA Guide to Advanced Drivers).

Use the Slave VT Port tab to:

  • Configure the Slave VT Port Properties.
  • Configure the Communication Statistic Update Properties.

The properties on the other tabs are common to many database items. For information on these properties, see Tabs that are Common to Many Configuration Forms in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Configure the Slave VT Port Properties (Configuring DNP3 Virtual Terminals)

Configure the Slave VT Port Properties

Use the fields on the Slave VT Port tab to define these properties of the service port:

  • In Service—Use to specify whether the virtual port is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Severity—Use the combo box to define the priority of any alarms or events that are associated with the port (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed on the tab. Use the field to specify the Area of Interest with which any VT Service Port Slave alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Outstation—Specify the Slave outstation on which the port is located. Use the browse button to display a Reference browse window and select the required outstation from the window.
  • Point Number—Enter the number that uniquely identifies the port through which data is to be routed. Where the master for the outstation is a ClearSCADA server, this number has to match the Virtual Terminal Number configured on a Virtual Terminal (see Configure a DNP3 Virtual Terminal).
  • Event Class—On DNP3 outstations, events such as state changes can be assigned into different classes (1, 2, or 3), depending, for instance, on their priority. Static data (present values and states) are assigned as Class 0. Enter the class of data that is transmitted using this port. The class has to be supported by the Slave outstation. Where the master for the outstation is a ClearSCADA server, you need to choose a class that is scanned by the master (see Specify When ClearSCADA Performs Class Polls).
  • Triggered Event—Use this check box to specify whether the outstation can report changes to its master without waiting for a request for data.

Select the check box if the Slave outstation is to send changes to its master without waiting for a request for data.

Clear the check box if the Slave outstation is only to report changes during the next request for data by its master.

Whether the outstation supports triggered events, or unsolicited message generation, is defined on the DNP3 tab of the Slave Outstation Form (see Configure the General DNP3 Properties).

  • Typical Message Size—Specify the typical size, in bytes, of a virtual terminal message. Once the service port receives this many bytes, it sends the message to the DNP3 master.

If the number of bytes received on the service port does not reach this value, the message is sent after the Message Timeout (see below).

If a message larger than the specified size is received, the service port splits the message into separate data packets. Each data packet is of the size specified in this Typical Message Size field, with the exception of the last data packet, which may be smaller. The service port sends those data packets that are of the specified Typical Message Size to the DNP3 master immediately. If the final data packet is smaller than the specified Typical Message Size and no further data is waiting to be sent that would bring it up to the Typical Message Size, the final data packet is delayed by the time specified in the Message Timeout field (see below).

A packet is split into smaller data packets if it exceeds 255 bytes—the maximum message size imposed by DNP3.

  • Message Timeout—Specify the time, in milliseconds, that the service port has to wait before sending a message that is smaller than the Typical Message Size (see above).

Example:

A VT Service Port Slave has this configuration:

Typical Message Size: 10
Message Timeout: 20

A message 10 bytes in size is received and passed on immediately to the master.

A message of 8 bytes is received. The service port waits for 20ms before passing the message onto the master.

A message of 12 bytes is received. The service port splits the messages into two packets. The first 10-byte packet is immediately passed on to the master. The size of this packet is determined by the ‘Typical Message Size’ of 10 bytes. The service port then waits 20ms before passing the remainder of the message on to the master in the next data packet.

A message of 34 bytes is received. This is split into four data packets. The service port immediately sends the three 10-byte packets to the master. After 20ms, it sends the remaining 4-byte packet to the master. (Should the VT Service Port Slave have received a further 6-byte message within the 20-second timeout period, it would have sent the remaining 4-bytes of data, along with the new 6-byte message, in a single 10-byte data packet, as soon as it had accumulated that 10 bytes-worth of data.)

  • Line Speed—Use to specify the speed of the slowest part of the connection between the Slave and its master.

If the entire connection uses the same speed (the baud rate), you can set the Line Speed to Same as Baud Rate. (The baud rate is specified on the VT Service Port’s Connection tab.)

If part of the connection uses a slower speed, specify that speed in the Line Speed combo box.

For more information on Line Speed, see Defining Scan Parameter Settings for a Channel in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Communication Statistic Update Properties (Configuring DNP3 Virtual Terminals)

Communication Statistic Update Properties

Use the fields within the Communication Statistic Updates section of the tab to define how often the communication statistics are updated for the Slave VT Port.

For information on configuring such fields, see Specify the Frequency with which Communications Statistics are Updated.


DNP3 Driver Guide - Points Used on DNP3 Outstations

Points Used on DNP3 Outstations

This section covers points on DNP3 outstations for which ClearSCADA is the DNP3 master. (DNP3 Slave Outstations use Filtered Value Maps rather than points to map point properties into the Slave’s memory, so that those properties can be accessed by the DNP3 protocol. For further information, see Configuring Value Maps in the ClearSCADA Guide to Core Configuration, and see Define the Filtered Value Map Locations.)

A DNP3 point is defined by its Point Type (for example, analog input, binary output, counter) and Point Number (address). DNP3 Direct Outstations and DNP3 PSTN Outstations support a combination of the point types that are listed below. You configure the properties for each point type using the fields on the appropriate DNP3 Point Form.

This section covers the configuration of properties that are common to the DNP3 points that are supported by the ClearSCADA DNP3 driver. It includes information on how to:

  • Configure General Point Properties
  • Configure Logged Data Properties
  • Specify Whether an Output Point is Controlled by ClearSCADA
  • Specify which Outstations are Integrity Polled after a Successful Control
  • Configure the DNP3-Specific Control Properties on DNP3 Output Points.

For configuration properties specific to a particular DNP3 point type, also see the following sections:

  • DNP3 Analog Input Point—see Configuring DNP3 Analog Points.
  • DNP3 Analog Output Point—see Configuring DNP3 Analog Points.
  • DNP3 Binary Input Point—a 1-, 2-, or 3-bit point that indicates the status of an item of plant, where the plant may be in one of several states (see Configuring DNP3 Binary Points).
  • DNP3 Binary Output Point—a 1-, 2-, or 3-bit point that is used to control the status of an item of plant, where the plant may be controlled to be in either or one of several states (see Configuring DNP3 Binary Points).
  • DNP3 Counter Point—a point that counts the number of pulses (see Configuring DNP3 Counter Points).
  • DNP3 Frozen Counter Point—a point that monitors the number of counts registered by a Counter Point (see Configuring DNP3 Counter Points).
  • DNP3 Pulse Action (NULL)—a one-action pulse (see Configuring DNP3 Pulse Actions).
  • DNP3 Pulse Action (Trip-Close)—a two-action pulse, for which each action can be performed on the same, or on a separate physical point (see Configuring DNP3 Pulse Actions).
  • DNP3 String Point—a point for which the value is a text string, rather than a numeric value (see Configuring DNP3 String Points).

To retrieve status information from a DNP3 device, consider using DNP3 Status Points, rather than the above DNP3 points (see Configuring DNP3 Status Points).

NOTE: In addition to the points listed above, ClearSCADA can support other types of DNP3 point, using a DNP3 Extension Driver. For information on any DNP3 points not listed above, see the relevant DNP3 extension driver guide.

For general information on configuring points, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

For information on configuring point properties that are common to points on many advanced drivers, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional DNP3 Point in ClearSCADA, see Minimum Configuration


DNP3 Driver Guide - Minimum Configuration (Points Used on DNP3 Outstations)

Minimum Configuration

For each DNP3 point, you need to specify the following properties on the appropriately named <Point Type> tab (as a minimum):

  • The outstation on which the point is located (except for Frozen Counter Points).
  • A unique point number (for Pulse (Trip-Close), two numbers are required—one for each action).
  • For integer-type analog points, any scaling that is required to convert the raw point value into an engineering value for use by the server.
  • For Frozen Counter Points, you need to specify the Counter Point that is the Frozen Counter Point’s parent point.
  • For Pulse Points, you need to specify the on and off time for each control action.

You also need to put the point In Service and save the configuration. When the configuration settings are saved and in place, the point is functional (and uses the default configuration settings).

If you want the ClearSCADA server to store point data historically, you also need to:

  • Enable and configure logging on the Historic tab if data is to be stored historically on the server database.
  • Enable and configure logging on the <Point Type> tab if data is to be stored historically at the outstation.


DNP3 Driver Guide - Configure General Point Properties (Points Used on DNP3 Outstations)

Configure General Point Properties

Use the fields at the top of the <Point Type> tab of the appropriate Point Form to define the general DNP3 settings for a point. These fields are common to many DNP3 points:

  • In Service—Use to specify whether the point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point that is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Outstation—Not applicable to Frozen Counter points. Specify the outstation on which the point is located.

Use the browse button to display a Reference browse window, and select the required outstation entry from the window.

  • Point Number—Enter the DNP3 point number that uniquely identifies this point in the outstation. You cannot have multiple points of the same point type and Point Number on the same outstation.

NOTE: For DNP3 Pulse (Trip-Close) points, you enter two Point Numbers in the Actions section of the Pulse Action tab (see Configure Trip and Close Pulse Actions).

  • Severity—Use this combo box to define the severity of point status alarms. For more information on severities, see Defining Severities in the ClearSCADA Guide to Core Configuration.
  • Scan Group (Confidence Poll)—A Scan Group defines a group of points for which the current values are updated at a particular rate, or are read during a DNP3 Level 3 Scan. You can assign each point to one of eight Scan Groups.

When you use the Perform Level 3 Scan pick action to read point data from a DNP3 outstation, you will be prompted to select which Scan Groups to include. The points from the selected Scan Groups that have the Level 3 Scan property enabled (see below) will be read from the outstation using a DNP3 Level 3 Scan. (If the Perform Level 3 Scan action is triggered by Schedule, you specify which Scan Groups are to be included, when you set up the Schedule.)

For Direct DNP3 Outstations, you also define the rate at which the current values of points in each Scan Group are updated, by using the corresponding Scan n field on the DNP3 Direct Channel Form (see Defining Further Scan Parameter Settings for a Direct Channel in the ClearSCADA Guide to Advanced Drivers).

NOTE: When the Scan Group timer expires, the DNP3 driver does not schedule a poll of the Outstation. Instead, it updates the point’s value with the response to the next scheduled poll, unless Level 3 Scanning is enabled (see below).

Scan Groups do not apply to DNP3 Pulse Action (NULL) or DNP3 Pulse Action (Trip-Close) points.

  • Level 3 Scan—Use this check box to specify whether the point’s value is read from the outstation using a DNP3 Level 3 Scan. Select the check box for the DNP3 driver to issue a DNP3 Level 3 Scan when the point’s Scan Group timer expires (DNP3 Direct Outstations), or the Perform Level 3 Scan pick action is executed.

Clear the check box if point data is to be retrieved through other means, such as an Integrity poll.

This field is not applicable to DNP3 Pulse Action (NULL) or DNP3 Pulse Action (Trip-Close) points.

For more information, see Level 3 Scan.


DNP3 Driver Guide - Configure Logged Data Properties (Points Used on DNP3 Outstations)

Configure Logged Data Properties

On DNP3 outstations, you can log data historically for point types other than Pulse Actions. Whenever the ClearSCADA DNP3 driver contacts a DNP3 outstation, it retrieves point data that is stored at the outstation and processes that data.

ATTENTION: If you enable logging on this tab, you also need to enable logging on the Historic tab. The Historic tab defines how the ClearSCADA server stores data historically.

Use the fields within the Logged Data section on the Point tab to specify which of this retrieved point data ClearSCADA logs historically, and which data it processes to generate alarms:

  • Historic Data Filter—Use the combo box to specify what type(s) of data retrieved by the DNP3 driver for this point are to be stored in the ClearSCADA server’s historical database.

Choose from:

  • None—ClearSCADA does not log any data that the outstation reports for this point, into the ClearSCADA historic database.

ATTENTION: This setting overrides any settings configured on the Historic tab (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

  • Static Data Only—ClearSCADA logs only the point data that is returned in a DNP3 Class 0 Poll or Level 3 Scan. This data includes the present state or value of the point.
  • Event Data Only—ClearSCADA logs only time stamped DNP3 Event data into the ClearSCADA historic database. Such data might include a change of state, or a value that has exceeded a limit.

ATTENTION: ClearSCADA will not log any point data historically if the Event Data only option is specified for a point that is configured in the outstation to report only Class 0 Static data, or if the point’s value is read using a DNP3 Level 3 Scan.

  • Static and Event Data—ClearSCADA logs all data that the outstation reports for the point, provided that the settings on the Historic tab are appropriately configured (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

NOTE: Regardless on the setting of the Historic Data Filter, ClearSCADA processes any DNP3 Event Data that is generated by the outstation for current value and, if configured to do so, logs events and generates alarms, as appropriate.

  • Alarms From—Specify how the ClearSCADA server processes the data that it retrieves from the outstation, specifically when the server raises and clears point alarms.
  • All Data—The ClearSCADA server will raise and clear alarms for the point when it receives any data from the outstation. This includes:
  • DNP3 Event Data returned in a DNP3 Class 1, 2, or 3 Poll, including event data with a time stamp prior to the latest data for the point stored in ClearSCADA
  • DNP3 Static Data returned in a DNP3 Class 0 Poll
  • DNP3 Static Data returned in a DNP3 Level 3 Scan.

NOTE: The DNP3 standard dictates that event data for a DNP3 point has to be transmitted in chronological order. However, a DNP3 Level 3 Scan, or Class 0 Only Poll of a point will return the points current value without any preceding DNP3 event data, and therefore it is possible to return the value of a point out-of-order. If you configure a point in the outstation to generate DNP3 events, it is not advisable to perform DNP3 Level 3 Scans for that point, or Class 0 Only Polls of the outstation.

  • Logged Data Only—The ClearSCADA server will raise and clear alarms only when it receives time stamped DNP3 Event Data for the point from the outstation. (This includes event data with a time stamp prior to the latest data that is stored in ClearSCADA for that point.)
  • Most Recent Data—This option is the same as All Data, but any DNP3 event data with a time stamp prior to the latest data for the point in the ClearSCADA database is ignored.

DNP3 event data is reported by the outstation in chronological order. As the ClearSCADA server processes each event individually, it means that alarms for the point might raise and clear multiple times during a single poll.

  • Most Recent Logged Data—This option is the same as Logged Data Only, but any DNP3 event data with a time stamp prior to the latest data for the point in the ClearSCADA database is ignored.

For further information, see Processing Alarm Data for Point States in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Specify Whether an Output Point is Controlled by ClearSCADA (Points Used on DNP3 Outstations)

Specify Whether an Output Point is Controlled by ClearSCADA

On some DNP3 devices, output points are controlled exclusively by other applications—such as ISaGRAF—rather than the DNP3 master (ClearSCADA).

Use the Enabled check box at the top of each output point’s Control tab to specify whether a point is controlled by ClearSCADA or exclusively by another application.

Output points are enabled for control via ClearSCADA by default.

Select the Enabled check box to allow ClearSCADA to be able to control the point. Configure the required settings on the rest of the Control tab—for information on configuring Analog Output points, see Configure the Control Properties of a DNP3 Analog Output Point; for information on configuring Binary Output points, see Configure the Control Properties of a DNP3 Binary Output Point. Once configured, the relevant control actions become available for use in ClearSCADA.

Clear the check box for other applications, such as ISaGRAF, to control the point exclusively. The rest of the fields on the Control tab become ‘grayed out’ and unavailable for use. No control actions are available for the point in ClearSCADA.

NOTE: Be aware that with some DNP3 devices, it is possible to switch point control between ClearSCADA and other applications. When supported, the functionality is explained in the relevant DNP3 extension driver guide.


DNP3 Driver Guide - Specify which Outstations are Integrity Polled after a Successful Control (Points Used on DNP3 Outstations)

Specify which Outstations are Integrity Polled after a Successful Control

NOTE: This section does not apply to output points that are controlled exclusively by another application, rather than ClearSCADA. (For further information, see Specify Whether an Output Point is Controlled by ClearSCADA.)

DNP3 Output points have an additional Control tab on the Point Form.

For output points that can be controlled by ClearSCADA, use the fields within the Promote section of the Control tab to specify any outstations that will be issued with an integrity poll, as a result of a successful control request being sent to an outstation for a point.

NOTE: The DNP3 Driver does not perform promoted scanning as described in the section on Promoting Scanning of Outstations Associated with Controls in the ClearSCADA Guide to Core Point Configuration. For DNP3 controls, when the driver receives an response indicating the control was successful, it will issue an integrity poll to each of the outstations listed in the Promote section.

  • Enabled—Select this check box if the ClearSCADA DNP3 driver is to issue an integrity poll to the Outstations specified in this section, following a successful control action.
  • Outstations—Use these fields to specify up to five DNP3 outstations that are to be integrity polled, following a successful control action.
  • Duration—This field is ignored by the ClearSCADA DNP3 Driver.


DNP3 Driver Guide - Configure the DNP3-Specific Control Properties on DNP3 Output Points (Points Used on DNP3 Outstations)

Configure the DNP3-Specific Control Properties on DNP3 Output Points

NOTE: This section does not apply to output points that are controlled exclusively by another application, rather than ClearSCADA. (For further information, see Specify Whether an Output Point is Controlled by ClearSCADA.)

These fields are displayed toward the bottom of the Control tab on the DNP3 Analog Output Point and DNP3 Binary Output Point Forms. For output points that can be controlled by ClearSCADA, use the fields to specify the type of control and whether ClearSCADA is to restore the point value in the event of power loss:

  • Operation Type—Use this combo box to specify which DNP3 control action ClearSCADA is to issue to the outstation, in order to set the value of the point. Choose from:
  • Direct Operate—ClearSCADA issues a DNP3 Direct Operate request, and expects the outstation to acknowledge the request.
  • Direct Operate - No ACK—ClearSCADA issues a DNP3 Direct Operate, and does not expect the outstation to acknowledge the request.
  • Select Before Operate—ClearSCADA issues a two-phase Select/Operate control to the outstation. ClearSCADA has to receive a valid response to the Select before it will issue the Operate.

If the point is on a DNP3 Slave outstation, you use the DNP3 tab on the DNP3 Slave Outstation Form to specify a suitable Select-Before-Operate Timeout for such a request (see Configure the General DNP3 Properties).

  • Restore Output—If the outstation’s internal indications indicate that the outstation has restarted (for example, following power failure, or a manual restart of the outstation), a point’s value is lost. Use the Restore Output check box to define whether, in such a situation, the ClearSCADA server is to restore the point’s value at the outstation to the previous point value. This can help to minimize data loss.

Select the check box if ClearSCADA is to issue a control to the outstation, if the outstation's DNP3 device restarted internal indication bit is set. The control sets the value of the point to the last known value stored in the ClearSCADA database. This might be the last read value, or the last controlled point value (if the Update Point on Successful Action check box is also selected on the Control tab). (The value written by ClearSCADA may not be the last ‘control’ value issued by an operator (or by a logic program in ClearSCADA). If ClearSCADA receives an update to the point’s value, through an integrity poll for example, the control issued to the outstation to restore the point’s value will contain the last value reported by the outstation.)

Clear the Restore Output check box if you do not want ClearSCADA to restore the point value in the outstation to the last known value (when the outstation's DNP3 device restarted internal indication bit is set).

  • Update Point on Successful Action—Select this check box for the point’s value in the ClearSCADA database to be updated as soon as ClearSCADA receives a response from the outstation, indicating that a control was successful.

Clear the check box to stop ClearSCADA from updating the point when a successful control has occurred. ClearSCADA will update the point’s value in the ClearSCADA database only when the outstation returns the point’s value, for example in a poll response.

In addition to the above, this DNP3-specific field is displayed on the Control tab of DNP3 Analog Output Points:

  • Control Object—Use this combo box to specify the format in which ClearSCADA sends the analog point’s value to the DNP3 outstation.

Choose from:

  • 32-bit Analog (g41v1)—The control value of an analog output point is sent as a signed, 32-bit integer with status (quality) flags.
  • 16-bit Analog (g41v2)—The control value of an analog output point is sent as a signed, 16-bit integer with status (quality) flags.
  • Single-precision float (g41v3)—The control value of an analog output point is sent as a signed, IEEE single-precision (32-bit) floating point number with status (quality) flags.
  • Double-precision float (g41v4)—The control value of an analog output point is sent as a signed, IEEE double-precision (64-bit) floating point number with status (quality) flags.


DNP3 Driver Guide - Configuring DNP3 Analog Points

Configuring DNP3 Analog Points

The ClearSCADA DNP3 driver supports Analog Input and Analog Output points.

Configure the properties of each Analog point using the fields on the DNP3 Analog Input Point Form, or the DNP3 Analog Output Point Form, as appropriate.

This section covers configuration of DNP3-specific properties on the Analog Point tab on both Forms and the Control tab on the DNP3 Analog Output Point Form.

For both DNP3 Analog Input Points and DNP3 Analog Outputs Points, use the Analog Point tab to:

  • Configure General Properties
  • Configure Alarm Limits
  • Configure any Alarm Limit Profiles (see Specify any Alarm Limit Profiles in the ClearSCADA Guide to Core Point Configuration)

(If your system is running a DNP3 Extension Driver, see the guide to that extension driver. Alarm Limit Profiles are only supported by analog points on some extension drivers.)

  • Configure Point Scaling
  • Configure Formatting properties (see Define the Appearance of an Analog Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Configure Override Properties
  • Configure Significant Change Properties
  • Configure the No Change Properties (see Detect whether an Analog Point has Stopped Changing in the ClearSCADA Guide to Core Point Configuration).
  • Configure Trend Properties (see Define an Analog Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure Logged Data Properties.

For DNP3 Analog Output Points, use the Control tab to:

  • Configure the Control Properties of a DNP3 Analog Output Point.

The fields on other tabs are common to points on many advanced drivers—see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - General Properties (Configuring DNP3 Analog Points)

General Properties

Use the fields at the top of the Analog Point tab to define the general properties for a DNP3 analog point. The properties are common to many DNP3 points—for information, see Configure General Point Properties.

You use the Severity field shown above to define the severity of alarms and events other than those that are generated in relation to changes in the point’s state or value. You use the Severity fields within the point’s Alarm Limits section to specify the severity level(s) of state-related alarms and events (see Alarm Limits).


DNP3 Driver Guide - Alarm Limits (Configuring DNP3 Analog Points)

Alarm Limits

Use the fields within the Alarm Limits section of the Analog Point tab to set limits for a DNP3 analog point and specify whether an alarm or event is generated if the point’s value exceeds those limits.

Many of the Alarm Limit fields are common to various types of analog points (see Configure the Limits for an Analog Point in the ClearSCADA Guide to Core Point Configuration). In addition to the usual Limits, DNP3 analog points also have an Invalid state. Use the fields associated with this state to define the properties should the analog to digital conversion process fail in the outstation.

For information on the Hysteresis property, see Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm in the ClearSCADA Guide to Core Point Configuration.

For information on the Engineering Units Exceeded property, see Define how Over Range and Under Range Values are Processed in the ClearSCADA Guide to Core Point Configuration.

For information on the Tune Limits property, see Define whether an Analog Point’s Limits can be Tuned in the ClearSCADA Guide to Core Point Configuration.

If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed within the Alarm Limits section. For information on this property, see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events in the ClearSCADA Guide to Core Point Configuration.


DNP3 Driver Guide - Configure Point Scaling (Configuring DNP3 Analog Points)

Configure Point Scaling

NOTE: ClearSCADA ignores any configuration within the Scaling section for analog points for which the outstation reports the value as a floating point value.

Use the fields within the Scaling section of the Analog Point tab to specify if, and how, ClearSCADA scales the point values that are reported by the outstation.

  • Enabled—Use this check box to determine whether ClearSCADA scales the integer values that are reported by the outstation.

Select the check box for ClearSCADA to interpret the reported value as a raw value and use the Raw Full Scale, Full Scale, Raw Zero Scale, and Zero Scale values to produce a corresponding engineering value.

Clear the check box to set ClearSCADA to use the reported value without applying any scaling. (If the outstation reports the value as a floating point value, ClearSCADA ignores any configuration within the Scaling section of the tab, regardless of the Enabled setting.)

  • Raw Full Scale—Specify the raw integer value that ClearSCADA is to scale to the Full Scale value. The Full Scale value is specified in the Alarm Limits section of the Analog Point tab (see Alarm Limits).
  • Raw Zero Scale—Specify the raw integer value that ClearSCADA is to scale to the Zero Scale value. The Zero Scale value is specified in the Alarm Limits section of the Analog Point tab (see Alarm Limits).

NOTE: When scaling is enabled, and the point value is not reported as a floating point value, any raw to engineering conversions performed by the outstation has to use the same Raw Full Scale, Full Scale, Raw Zero Scale, and Zero Scale values as those defined in ClearSCADA.


DNP3 Driver Guide - Configure Override Properties (Configuring DNP3 Analog Points)

Configure Override Properties

Use the fields within the Override section of the Analog Point tab to specify whether a point’s value can be overridden.

Many of the fields within this section are common to many analog points—for details, see Define whether an Analog Point can be Overridden in the ClearSCADA Guide to Core Point Configuration. Fields that are specific to DNP3 points are explained below.

  • Process Override Flag—Select this check box for ClearSCADA to set the point’s status in accordance with the point’s DNP3 Local Forced status flag.

Clear the check box for ClearSCADA to ignore the Local Forced status of the point.


DNP3 Driver Guide - Significant Change Properties (Configuring DNP3 Analog Points)

Significant Change Properties

Use the fields within the Significant Change section of the Analog Point tab to specify when ClearSCADA updates its database with the value reported by the outstation. For further information, see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration.


DNP3 Driver Guide - Configure the Control Properties of a DNP3 Analog Output Point (Configuring DNP3 Analog Points)

Configure the Control Properties of a DNP3 Analog Output Point

DNP3 Analog Output points have an additional Control tab on the Point Form.

Use the fields on the Control tab to define how the ClearSCADA server handles information related to control requests for the selected point.

Use the Control tab to Specify Whether an Output Point is Controlled by ClearSCADA and if so, use the rest of the fields on the tab to:

  • Specify the Analog Control Range and Severity Properties (see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Promote Retrieval of Data Associated with Controls (see Specify which Outstations are Integrity Polled after a Successful Control)
  • Configure the DNP3-specific control properties for the point (see Configure the DNP3-Specific Control Properties on DNP3 Output Points).


DNP3 Driver Guide - Configuring DNP3 Binary Points

Configuring DNP3 Binary Points

The ClearSCADA DNP3 driver supports 1-, 2- and 3-bit Binary Input, and Binary Output points. (ClearSCADA combines consecutive Binary points from a DNP3 outstation to form a 2- or 3-bit Binary Input or Output point within the ClearSCADA database.)

Configure the settings for each Binary point using the fields on the DNP3 Binary Input Point Form, or the DNP3 Binary Output Point Form, as applicable.

This section covers configuration of properties on the Binary Point tab of both Forms, and the Output tab of the DNP3 Binary Input Point Form.

For both DNP3 Binary Input Points and DNP3 Binary Output Points, use the Binary Point tab to:

  • Configure General Properties
  • Configure Binary Point States
  • Configure Override Properties
  • Configure Trend Properties (see Define a Digital Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure Logged Data Properties.

For DNP3 Binary Output Points, use the Control tab to:

  • Configure the Control Properties of a DNP3 Binary Output Point.

The fields on other tabs are common to points on many advanced drivers—see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

NOTE: Binary points are referred to as Digital points on many other drivers. As such, much of the common functionality for these points can be found in the Digital Points section of the ClearSCADA Guide to Core Point Configuration.


DNP3 Driver Guide - Configure General Properties (Configuring DNP3 Binary Points)

Configure General Properties

Use the fields at the top of the Binary Point tab to define the general properties for the point. Some of these fields are common to many types of DNP3 points (see Configure General Point Properties). Properties that are specific to DNP3 Binary points are explained below:

NOTE: Use the Severity field within the States section of the tab to specify the severity level(s) of alarms and events that are generated as a result of the point changing state (see Binary Point States).

  • Number of Bits—Use the combo box to specify the number of bits for the point. This corresponds to the number of consecutive 1-bit points that form the point. The number of bits directly affects the number of point states (see below). For further information, see Single and Multi-Bit Digital Points in the ClearSCADA Guide to Core Point Configuration.
  • Double Bit—Applies to DNP3 Binary Input points only. If the point comprises two bits (Number of Bits = 2), use the Double Bit check box to specify the whether the point comprises two single-bit points or one double-bit point at the outstation.

Select the check box if the point is a double-bit point (DNP3 Group 3/4).

Clear the check box if the point comprises two single-bit points (DNP3 Group 1/2). (Any single-bit points are combined to form double-bit binary input points in ClearSCADA.)

  • Format—Specifies the appearance of the point’s value in other ViewX displays, such as Lists. For further information, see Define the Format of a Digital Point’s Values in the ClearSCADA Guide to Core Point Configuration.


DNP3 Driver Guide - Binary Point States (Configuring DNP3 Binary Points)

Binary Point States

Use the fields within the States section of the Binary Point tab to define state-related information for the point, such as the handling of state-related alarms.

The Number of Bits, defined toward the top of the Binary Point tab, determines the number of state fields that are available for use.

For information on configuring binary point states, see Define the Point States for a Digital Point in the ClearSCADA Guide to Core Point Configuration.


DNP3 Driver Guide - Configure Override Properties (Configuring DNP3 Binary Points)

Configure Override Properties

Use the fields within the Override section of the Binary Point tab to define whether the value of a binary point can be overridden.

Some of the fields in the Override section are common to many digital points—for details, see Define whether a Digital Point can be Overridden in the ClearSCADA Guide to Core Point Configuration. Fields that are specific to DNP3 points are explained below
.

  • Process Override Flag—Select this check box for ClearSCADA to set the point’s status in accordance with the point’s DNP3 Local Forced status flag.

Clear the check box for ClearSCADA to ignore the Local Forced status of the point.


DNP3 Driver Guide - Configure the Control Properties of a DNP3 Binary Output Point (Configuring DNP3 Binary Points)

Configure the Control Properties of a DNP3 Binary Output Point

DNP3 Binary Output points have an additional Control tab on the Point Form.

Use the fields on the Control tab to define how the ClearSCADA server handles information related to control requests for the selected point.

Use the Control tab to Specify Whether an Output Point is Controlled by ClearSCADA and if so, use the rest of the fields on the tab to:

  • Configure the Point Actions (see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Promote Retrieval of Data Associated with Controls (see Specify which Outstations are Integrity Polled after a Successful Control)
  • Define the type of control and specify whether to restore the point value in the event of power loss (see Configure the DNP3-Specific Control Properties on DNP3 Output Points).


DNP3 Driver Guide - Configuring DNP3 Counter Points

Configuring DNP3 Counter Points

A DNP3 Counter point is typically used to count pulses on a physical binary input, or used to accumulate internally calculated values.

A DNP3 Frozen Counter point provides a mechanism for taking a ‘snap-shot’ of the current value of a DNP3 Counter—the Frozen Counter continues to hold the same value, while the Counter continues to count.

Configure the properties of a Counter point using the fields on the DNP3 Counter Point Form.

Configure the properties of a Frozen Counter point using the fields on the DNP3 Frozen Counter Point Form.

This section covers configuration of properties that are on the Counter Point tab of the Counter Point Form, and the Frozen Counter tab of the Frozen Counter Point Form. The fields on the other tabs are common to many points—for information, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

For DNP3 Counter Points, use the fields on the Counter Point tab to:

  • Configure General Properties of a DNP3 Counter Point
  • Configure the Multiplier Value
  • Configure Alarm Limits
  • Configure the Initialization Properties of a DNP3 Counter Point
  • Configure Override Properties
  • Configure the No Change Properties (see Detect whether a Counter-Type Point has Stopped Changing in the ClearSCADA Guide to Core Point Configuration).
  • Configure Trend Properties (see Define a Counter-Type Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure Formatting Properties (see Define the Appearance of a Counter-Type Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Configure Logged Data Properties.

For DNP3 Frozen Counter Points, use the fields on the Frozen Counter tab to:

  • Configure the General Properties of a DNP3 Frozen Counter Point
  • Configure the Multiplier Value
  • Configure Alarm Limits
  • Configure Override Properties
  • Configure Trend Properties (see Define a Counter-Type Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure Logged Data Properties.

NOTE: Many of the figures within this section show fields on the Counter tab of the Counter Point Form. For a Frozen Counter point, these fields are displayed on the Frozen Counter tab.


DNP3 Driver Guide - General Properties of a DNP3 Counter Point (Configuring DNP3 Counter Points)

General Properties of a DNP3 Counter Point

Use the fields at the top of the Counter Point tab to define the general properties for a DNP3 Counter point. The fields are common to many DNP3 points—for more information, see Configure General Point Properties.

You use the Severity field shown above to specify the severity of alarms and events other than those generated in relation to changes in the point’s state or value. You use the Severity fields within the point’s Alarm Limits section to specify the severity level(s) that apply to state-related alarms and events (see Configure Alarm Limits).


DNP3 Driver Guide - Configure the General Properties of a DNP3 Frozen Counter Point (Configuring DNP3 Counter Points)

Configure the General Properties of a DNP3 Frozen Counter Point

Use the fields at the top of the Frozen Counter tab to define the general properties of a Frozen Counter point. Some of these fields are common to many DNP3 points—for more information, see Configure General Point Properties. Fields that are specific to DNP3 Frozen Counter points are explained below:

  • Outstation—Provided for information only. The DNP3 driver determines the outstation directly from the Frozen Counter point’s Parent Point.
  • Parent Point—Specify the DNP3 Counter Point that you want to associate with this DNP3 Frozen Counter Point. The Parent Point is the counter that will be ‘frozen’ in the outstation.

Use the browse button to display a Reference browse window and select the required Counter point from the window.

  • Point Number—Provided for information only. The DNP3 driver determines the point number directly from the Frozen Counter point’s Parent Point.

NOTE: Use the Severity fields within the Alarm Limits section of the tab to specify the severity level of alarms and events that are generated as a result of the point value crossing an alarm limit (see Configure Alarm Limits).


DNP3 Driver Guide - Configure the Multiplier Value (Configuring DNP3 Counter Points)

Configure the Multiplier Value

Use the Multiplier fields below the general configuration fields on the Counter Point or Frozen Counter tab to define the scaling factor that is applied to the counter’s value.

  • Multiplier—The DNP3 protocol supplies each count as a whole number. Use a multiplier other than 1 if the value that is to be used in the ClearSCADA database is to differ from the actual count value. The counter values that are reported by the outstation are multiplied by the Multiplier value for use in ClearSCADA.

Example:

A Slave generates one count for every 0.33 liters of water pumped through a pipe.

A multiplier of 0.33 is used to show how many liters have been pumped.


DNP3 Driver Guide - Configure Alarm Limits (Configuring DNP3 Counter Points)

Configure Alarm Limits

Use the fields within the Alarm Limits section of the Counter Point or Frozen Counter tab to set the limit values for the point and specify whether an alarm or event is generated if the value of the counter rises to, or exceeds, a limit.

For information on configuring a counter point’s High High and High limits, and the properties for when the counter is in its Normal operating range, see Configure the Limits for a Counter-Type Point in the ClearSCADA Guide to Core Point Configuration.

For information on the Tune Limits property, see Define Whether a Counter-Type Point’s Limits can be Tuned in the ClearSCADA Guide to Core Point Configuration.

If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed within the Alarm Limits section. For information on this property, see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events in the ClearSCADA Guide to Core Point Configuration.


DNP3 Driver Guide - Configure the Initialization Properties of a DNP3 Counter Point (Configuring DNP3 Counter Points)

Configure the Initialization Properties of a DNP3 Counter Point

Use these fields within the Initialize section of the Counter Point tab to define the initialization properties for a counter point:

  • Enabled—Use this check box to specify whether operators can initialize the counter.

Select the check box to allow operators to reset the counter value using the Initialize pick action. The initialize value is specified in the window that is displayed when the pick action is selected.

If you allow initialization, you need to specify the DNP3 function and object that the outstation is to use to initialize the counter. To configure these properties, use the Reset Method field on the DNP3 Outstation Form (see Configure the Counter Reset Method).

Clear the Enabled check box to disable manual initialization. Operators will be unable to use the Initialize pick action for this counter point.

  • Confirm—Use this combo box to specify whether confirmation is required from the user when initializing the counter (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).
  • Update Point on Successful Action—Use to define when ClearSCADA updates the point’s value in the database following a Reset action. This setting only applies when the outstation’s counter Reset Method is set to a ‘Write’ option (see Configure the Counter Reset Method).

If you select the Update Point on Successful Action check box, ClearSCADA will update the value of the point in the ClearSCADA database as soon as the outstation responds successfully to a Reset action.

When a user selects the Reset action for the point, ClearSCADA sends the Reset value to the outstation. The outstation then uses the Reset value and responds to ClearSCADA to indicate whether the Reset action was successful. When ClearSCADA receives a reset successful notification, it updates the point’s value in the ClearSCADA database. This process normally happens very quickly.

If you clear the Update Point on Successful Action check box, ClearSCADA will only update the point’s value during a subsequent poll of the outstation. So, when the Reset value is sent to the outstation, ClearSCADA does not update the database after the outstation’s response - it leaves the existing value of the point in place. ClearSCADA only updates the point’s value in the database following the next poll of the outstation.

You need to make the most appropriate selection for your requirements. Selecting the Update Point on Successful Action check box will mean that the point’s value is updated in the database when the Reset completes. But it also means that it will be updated with the user-defined value that was sent to the outstation. This may differ slightly to the value in the outstation as the outstation may re-interpret the value. For example, some hardware devices may be unable to represent the value and so will alter it. As a result, the value in the outstation may be slightly different to the value that was sent.


DNP3 Driver Guide - Configure Override Properties (Configuring DNP3 Counter Points)

Configure Override Properties

Use the fields in the Override section of the Counter Point or Frozen Counter tab to define whether the value of a Counter or Frozen Counter can be overridden.

Some of the fields within this section are common to many counter points—for details, see Define Whether a Counter-Type Point can be Overridden in the ClearSCADA Guide to Core Point Configuration. Fields that are specific to DNP3 points are explained below.

  • Process Override Flag—Select this check box for ClearSCADA to set the point’s status in accordance with the point’s DNP3 Local Forced status flag.

Clear the check box for ClearSCADA to ignore the Local Forced status of the point.


DNP3 Driver Guide - Configuring DNP3 Pulse Actions

Configuring DNP3 Pulse Actions

The ClearSCADA DNP3 driver supports the following types of pulse action:

  • Pulse (NULL)—A one-action pulse for which a DNP3 NULL command executes the pulse.
  • Pulse (Trip-Close)—A two-action pulse for which both actions (trip and close) can be performed on the same, or separate, physical points.

Configure the settings for the pulse actions using the fields on the DNP3 Pulse (NULL), or the DNP3 Pulse (Trip-Close) Form, respectively.

This section covers configuration of properties on the Pulse Action tab of each Form.

For DNP3 Pulse (NULL) and DNP3 Pulse (Trip-Close) actions, use the Pulse Action tab to:

  • Configure General Properties
  • Configure Pulse Properties
  • Promote Retrieval of Data Associated with Pulse Controls (see Specify which Outstations are Integrity Polled after a Successful Control).

For DNP3 Pulse (NULL) actions, also use the Pulse Action tab to:

  • Configure a NULL Pulse Action.

For DNP3 Pulse (Trip-Close) actions, also use the Pulse Action tab to:

  • Configure Trip and Close Pulse Actions.

The fields on other tabs are common to points and pulse actions on many advanced drivers—see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

For an example that demonstrates how a Pulse Action might be configured to operate on a ClearSCADA system, see Pulse Control Example.


DNP3 Driver Guide - Configure General Properties (Configuring DNP3 Pulse Actions)

Configure General Properties

Use the fields at the top of the Pulse Action tab to define general settings for a Pulse Action. Some of the fields shown here are common to many DNP3 points—for further information, see Configure General Point Properties. Fields that are specific to DNP3 Pulse Actions are explained below.

  • Point Number—Applies to DNP3 Pulse (NULL) pulse actions only. Use to specify the point’s address in the outstation (see Configure General Point Properties).

NOTE: For DNP3 Pulse (Trip-Close) pulse actions, you need to specify a Point Number for each action. Specify these numbers in the Actions section of the tab (see Configure Trip and Close Pulse Actions).


DNP3 Driver Guide - Configure Pulse Properties (Configuring DNP3 Pulse Actions)

Configure Pulse Properties

Use the fields below the general properties of the Pulse Action action tab to define the basic pulse properties:

  • Inching—Use this check box to define whether operators can specify the length of time that each pulse control lasts.

Clear the check box if each pulse control should last for the time specified in the On Time and Off Time fields (see Configure a NULL Pulse Action, or see Configure Trip and Close Pulse Actions, as applicable) and for the number of pulse counts specified in the Pulse Count field (see below). Operators use the Control pick action to send the Control.

Select the check box to enable operators to:

  • Specify the number of pulses in a control, up to and including the number specified in the Pulse Count field (see below)
  • Carry out a control for any amount of time up to and including that specified in the On Time and Off Time fields.

Operators can use the Inching pick action to carry out a control for a user-configurable duration and user-configurable number of pulses. Alternatively, operators can use the Control pick action to carry out the control for the number of pulses and amount of time defined in the Pulse Count, On Time and Off Time fields.

  • Operation Type—Use this combo box to specify which DNP3 control action ClearSCADA is to issue to the outstation, in order to set the value of the point. For more information, see Configure the DNP3-Specific Control Properties on DNP3 Output Points.
  • Pulse Count—Specify the number of times that the outstation executes the On-Off pulse periods that are defined in the Actions section for each control. (Refer to a device’s DNP3 Profile document to ascertain whether a Pulse Count of greater than 1 is supported.)

When a control is executed, each pulse remains on for the duration specified in the On Time field, then goes off for the time specified in the Off Time field. This process is repeated until the Pulse Count is reached. (For an illustrated example, see Pulse Control Example.)

In each case, the complete pulse action lasts for the (On Time + Off Time) * Pulse Count.

Should an attempt be made to issue a further Control or Inching action to a pulse point for which a previously requested Control or Inching action is still active, the outstation will reject the request and an alarm will be raised.

For information on configuring the On Time and Off Time durations, see Configure a NULL Pulse Action, or see Configure Trip and Close Pulse Actions, as applicable.


DNP3 Driver Guide - Configure a NULL Pulse Action (Configuring DNP3 Pulse Actions)

Configure a NULL Pulse Action

A Pulse (NULL) has one action. Use the fields within the Actions section of the Pulse Action tab to define the properties of the NULL action.

The Severity, Description, and Confirm fields are common to pulse actions on many drivers—for information, see Define the Actions that a Pulse Undertakes in the ClearSCADA Guide to Core Point Configuration. Fields that are specific to DNP3 Pulse (NULL) Actions are explained below.

  • On Time—Specify how long each pulse should remain on. Use this parameter in conjunction with the Off Time (see below), and Pulse Count (see Configure Pulse Properties) to define the complete pulse action. For an illustrated example, see Pulse Control Example.

Enter the time in the OPC Time Format, for example 5S (for five seconds). You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required On time.

  • Off Time—Specify how long each pulse should remain off before it is pulsed on again. Use this parameter in conjunction with the On Time (see above), and Pulse Count (see Configure Pulse Properties) to define the complete pulse action. For an illustrated example, see Pulse Control Example.

Enter the time in the OPC Time Format, for example 5S (for five seconds). You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required Off time.


DNP3 Driver Guide - Configure Trip and Close Pulse Actions (Configuring DNP3 Pulse Actions)

Configure Trip and Close Pulse Actions

A Pulse (Trip-Close) has two actions. Use the fields within the Actions section of the Pulse Action tab to define the properties of the Trip and Close actions.

The Severity, Description, and Confirm fields are common to pulse actions on many drivers—for information, see Define the Actions that a Pulse Undertakes in the ClearSCADA Guide to Core Point Configuration. Fields that are specific to DNP3 Pulse (Trip-Close) Actions are explained below:

  • Point Number—Specify the DNP3 point number for each action. Each Point Number defines the location of the point on which that action is to be undertaken. You can assign the same point number, or different point numbers, to each action.
  • On Time—Use to specify how long each pulse should remain on (see Configure a NULL Pulse Action).
  • Off Time—Use to specify how long each pulse should remain off before it is pulsed on again (see Configure a NULL Pulse Action).

For an illustrated example showing how On Time and Off Time parameters can be used, see Pulse Control Example.


DNP3 Driver Guide - Pulse Control Example (Configuring DNP3 Pulse Actions)

Pulse Control Example

This example demonstrates how the On Time, Off Time and Pulse Count properties can be used to specify how many pulses are triggered by a single control action.

The first pulse within any DNP3 pulse control starts as soon as the execution of that control commences.

Example:

A DNP3 Pulse Action is configured as follows:

Pulse Count: 3
On Time: 1S (one second)
Off Time: 2S (two seconds).

This configuration means that for each control operation, three 1-second pulses are generated, each two seconds apart.


DNP3 Driver Guide - Configuring DNP3 String Points

Configuring DNP3 String Points

The ClearSCADA DNP3 driver supports DNP3 String points.

DNP3 String points allow text strings to be passed between a DNP3 outstation and the SCADA master (ClearSCADA).

Example:

An outstation contains a string point that stores a dial-up modem initialization string. A DNP3 String Point in the ClearSCADA database is used to set the string to a value, such as ATE0V0X0.

Another string point in the outstation stores the name of the logic program that is running at the outstation. A DNP3 String Point in the ClearSCADA database is used to read the name of the program from the outstation.

Configure the properties of each string point using the fields on the DNP3 String Point Form.

This section covers the configuration of properties that are specific to DNP3 String Points, on the String Point tab of the Form.

Use the String Point tab to:

  • Configure General Properties.

The fields on other tabs are common to points on many advanced drivers—see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.


DNP3 Driver Guide - Configure General Properties (Configuring DNP3 String Points)

Configure General Properties

Use the fields on the String Point tab to define the general properties for a string point. Some of these fields are common to many DNP3 points (see Configure General Point Properties). Fields that are specific to DNP3 String points are explained below:

  • Length of String to Request—Specify the length of the string that ClearSCADA is to request from the outstation.
  • Level 3 Scan—ClearSCADA can read DNP3 string values using a DNP3 Level 3 Scan. The DNP3 driver issues a DNP3 Level 3 scan whenever the point’s Scan Group timer expires.

Select this check box for ClearSCADA to read the string periodically from the outstation, using a Level 3 Scan.

Clear the check box if ClearSCADA is to read the string from the outstation by request only (using the Read String pick action).

  • Confirm Set Value—Use this combo box to specify whether a confirmation dialog box is displayed whenever an operator attempts to set the string’s value (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).


DNP3 Driver Guide - Configuring DNP3 Status Points

Configuring DNP3 Status Points

In addition to input and output data that relates to plant, many DNP3 devices are able to store status information and/or system point data that is internal to the DNP3 device. You can configure ClearSCADA to retrieve such status information using DNP3 Status Points. The values of up to 10 status points can be retrieved and stored per DNP3 Status Points database item. You can associate multiple DNP3 Status Points database items with each DNP3 outstation. ClearSCADA typically retrieves the DNP3 Status Points’ data periodically using a Level 3 Scan. The status values are also updated:

  • If returned in a DNP3 Class 0 poll (Integrity poll)
  • If the DNP3 Status Points’ Refresh pick action is used to create a Level 3 request for the status values
  • If the outstation’s Perform Level 3 Scan pick action is used to retrieve data for the Scan Group with which the status points are associated.

Use DNP3 Status Points database item(s) to retrieve a DNP3 device’s status data if that status data is required in ClearSCADA and:

  • The data does not need the ‘overheads’ associated with ClearSCADA points, such as the ability to:
  • generate point alarms and events
  • store point data historically
  • redirect alarms
  • associated the item with an Alarm View
  • use an alternative Alarm Source name for the item
  • override the item’s value
  • format the item’s value for use in ClearSCADA displays (for instance, for an analog’s value to include a set number of decimal places whenever that value is displayed in Lists and reports).

Use individual DNP3 Points, such as DNP3 Binary Points or DNP3 Analog Points, to retrieve DNP3 status data if the status points do require any of the above ‘overheads’. For information on configuring DNP3 points, see Points Used on DNP3 Outstations.

To configure DNP3 Status Points in ClearSCADA, you need to configure the properties on the DNP3 Status Points Form. The Form has several tabs.

Use the fields on the Parent tab to:

  • Specify the Outstation from which ClearSCADA is to Retrieve Status Data
  • Specify the Scan Group that is Associated with the Status Data Retrieval.

Use the fields on the Points tab to:

  • Specify the Status Points for which Data is Retrieved.

Properties on the other tabs are common to many driver items (see Tabs that are Common to Many Configuration Forms in the ClearSCADA Guide to Advanced Drivers).

NOTE: With DNP3 devices with which ClearSCADA communicates using a DNP3 Extension Driver, further means of retrieving internal status information may be available. Any such additional functionality is explained in the relevant DNP3 extension driver guide.


DNP3 Driver Guide - Specify the Outstation from which ClearSCADA is to Retrieve Status Data (Configuring DNP3 Status Points)

Specify the Outstation from which ClearSCADA is to Retrieve Status Data

Use the Outstation field on the Parent tab to specify the DNP3 outstation that ClearSCADA is to scan for status data:

Use the field’s browse button to display a Reference browse window and select the required outstation entry from the window.


DNP3 Driver Guide - Specify the Scan Group that is Associated with the Status Data Retrieval (Configuring DNP3 Status Points)

Specify the Scan Group that is Associated with the Status Data Retrieval

Use the Scan Group (Confidence Poll) combo box on the Parent tab to specify the Scan Group with which the Status points are associated. The Scan Group is used to determine whether the Status points are scanned during a Level 3 Scan. On Direct DNP3 outstations, the Scan Group also defines the rate at which Level 3 Scans are performed.

Use the combo box to select which one of up to eight Scan Groups is to be used by these particular Status points:

When you use the Perform Level 3 Scan pick action to read point data from a DNP3 outstation, you will be prompted to select which Scan Groups to include. The Status Points from the selected Scan Groups will be read from the outstation using a DNP3 Level 3 Scan. (If the Perform Level 3 Scan action is triggered by Schedule, you specify which Scan Groups are to be included, when you set up the Schedule.)

With Status Points on Direct DNP3 outstations, the rate at which the current values of the Status Points are updated is determined by the corresponding Scan n field on the DNP3 Direct Channel Form (see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers). Whenever the Scan Group timer expires, the DNP3 driver issues a DNP3 Level 3 Scan.

Select the Scan Group (Confidence Poll) option ‘None’ if the status data is not to be retrieved using a Level 3 Scan. ClearSCADA will update the status points’ data if it is returned during a DNP3 Class 0 Poll, or following a Refresh pick action request.


DNP3 Driver Guide - Specify the Status Points for which Data is Retrieved (Configuring DNP3 Status Points)

Specify the Status Points for which Data is Retrieved

Use the Points tab on the DNP3 Status Points Form to specify up to 10 Status Points for which ClearSCADA is to retrieve data. For each Status Point, you need to configure the following:

  • Description—Enter a concise description of the status information that the particular Status Point represents. You can enter up to 32 alphanumerical characters.

ClearSCADA prefixes each of the status attributes that are specific to that particular Status Point with the string that appears in this Description field. The status attributes are included on the DNP3 Status Point item’s Status display (see DNP3 Point and Pulse Action Status Attributes).

  • DNP3 Group—Use this combo box to specify the DNP3 Group in which the status point is located in the outstation. This defines the format in which the status data is stored at the outstation. Choose from:
  • Binary Input (Group 1)
  • Double-bit Binary Input (Group 3)
  • Binary Output (Group 10)
  • Running Counter (Group 20)
  • Frozen Counter (Group 21)
  • Analog Input (Group 30)
  • Analog Output (Group 40)
  • String Data (Group 110)
  • Unused—Select this option for any rows that are not required on the Points tab.
  • Point Number—Enter the DNP3 point number that uniquely identifies the status point in the outstation. You cannot have multiple points in the same DNP3 Group with the same DNP3 Point Number on the same outstation.

Any Status Point assigned the Point Number 65535 is deemed to be inactive.


DNP3 Driver Guide - DNP3 Specific Alarm and Event Categories

DNP3 Specific Alarm and Event Categories

Each alarm and event on a ClearSCADA system has a Category that indicates the type of alarm or event. The Category is included by default in the Events List and, if applicable, the Alarms List and the Alarm Banner.

You can optionally filter the entries in either List by category—the entries from which you can choose comprise various ‘core’ categories, along with any categories that are specific to the drivers that are installed on your system.

On systems on which the DNP3 driver is installed, in addition to the ‘core’ alarm and event categories, this DNP3 specific category is available:

  • DNP3 Authentication—Entries associated with DNP3 Secure Authentication, including successful and unsuccessful authentications and Session Key Changes.

NOTE: If your system is running a DNP3 Extension Driver, refer to the relevant DNP3 extension driver guide for any DNP3-specific categories that are not shown above.

Further Information

Events Lists and ‘core’ filter categories: see the ClearSCADA Guide to Lists.

Alarms Lists and ‘core’ filter categories: see the ClearSCADA Guide to Alarms.


DNP3 Driver Guide - DNP3 Specific Status Descriptions on Historic Lists

DNP3 Specific Status Descriptions on Historic Lists

You can display a Historic List for an individual point that has Historic Logging enabled (see Historic Lists in the ClearSCADA Guide to Lists).

With DNP3 points, you use the Logged Data section of the point’s configuration Form to specify whether ClearSCADA is to store Static (current) Data and/or Event (logged) Data historically for a point (see Configure Logged Data Properties). You can subsequently display that data in the form of a Historic List. Each Historic List comprises a series of rows and columns.

With points on the DNP3 driver, the Status column can include ‘core’ status information and/or one or more of these DNP3-specific descriptions:

  • Online—This status indicates that ClearSCADA stored the data historically while the point was online (In Service) at the outstation. This status might also be recorded for old Event Data that an outstation logged while a point was online, but that the outstation subsequently reported to ClearSCADA after the point was taken out of service locally at the outstation.

If the Online status is listed alongside other DNP3-specific descriptions, it indicates that the data might be inaccurate.

If the status is not listed for a DNP3 value that ClearSCADA has stored historically, the data should be treated as suspect.

  • Comms Lost—This status can only be set for a physical point that is on a remote device—a device (such as another DNP3 outstation) that is downstream of the outstation via which ClearSCADA obtains the point’s data. Comms Lost indicates that ClearSCADA stored the remote point’s data historically while communications between the outstation and the remote device were lost. The data shows the last value that was available before communications were lost.
  • Restart—This status indicates that the outstation had restarted, but had not yet had chance to scan its I/O when ClearSCADA attempted to read the data. Such data should be treated as suspect as it will typically be one of the following:
  • The last known value of the point, before the outstation restarted
  • A default value (such as zero)
  • A random uninitialized value.

Normally, a DNP3 outstation scans its I/O as soon as it starts up, so you would not expect to see this status. However, this status might be reported by a point that is on a remote device—a device that is downstream of the outstation via which ClearSCADA obtains the point’s data.

  • Remote Forced—This status can only be set for a physical point that is on a remote device—a device (such as another DNP3 outstation) that is downstream of the outstation via which ClearSCADA obtains the point’s data. Remote Forced indicates that ClearSCADA stored the data historically while the remote point’s value was ‘forced’ locally by the device on which the point is located.
  • Local Forced—This status indicates that ClearSCADA stored the data historically while the point’s value was ‘forced’ locally at the outstation (for instance, by a program running at the outstation, or by a local access device).
  • Chatter Filter—Applies to DNP3 binary input points only. ClearSCADA stored the data historically while the point was rapidly changing back and forth between point states. This status indicates that there may be a problem with the sensor.
  • Overrange—Applies to DNP3 analog points only. ClearSCADA stored the data historically while the point’s value was outside of the valid scale (it was exceeding either the Full Scale limit, or Zero Scale limit).

An analog point’s limits are defined in the Alarm Limits section of the Analog Point tab, on the point’s configuration Form. Many DNP3 outstations do not support downloading of configuration properties from ClearSCADA, but these limits should replicate the configuration that exists for that point at the outstation.

  • Rollover—This status has now been deprecated by DNP3, but may still be used by DNP3 counter and frozen counter points on some older DNP3 devices.

The DNP3 protocol does not have a mechanism for reporting the value at which a counter rolls over. Instead, the SCADA master (such as ClearSCADA) is expected to poll a device frequently enough to detect when a rollover has occurred. This status indicates that the data ClearSCADA has stored historically is for such a rollover.

  • Discontinuity—Applies to DNP3 counter and frozen counter points only. The data is not a true indication of the counter or frozen counter point’s value as ClearSCADA stored the data historically when the counter’s change in value could not be ascertained.
  • Reference Error—Applies to DNP3 analog points only. This status indicates that the value that ClearSCADA has stored historically might be inaccurate. For example, it might be that the sensor needed recalibrating at the time that the data was reported, or the raw data was affected by a significant amount of electromagnetic noise.

Some of the above status descriptions are further highlighted using DNP3 specific system colors (see DNP3 Specific Colors).


DNP3 Driver Guide - Using DNP3 Specific Actions

Using DNP3 Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section covers those actions that are DNP3 driver-specific, and includes:

  • Actions Associated with DNP3 Outstations
  • Actions Associated with DNP3 Counter Points
  • Actions Associated with DNP3 String Points
  • Actions Associated with DNP3 Pulse Actions
  • Actions Associated with DNP3 Status Points
  • Alphabetical List of DNP3 Specific Actions.

Remember that control actions are only available on DNP3 output points that can be controlled from ClearSCADA. If an output point is controlled exclusively by another application (such as ISaGRAF), no control actions are available for that point in ClearSCADA. For more information, see Specify Whether an Output Point is Controlled by ClearSCADA.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. For example, the Download File pick action is the equivalent of the DownloadFile method. A note is included with the relevant pick action whenever this naming convention differs. Refer to the Database Schema for argument naming conventions used with the Automation Interface.

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


DNP3 Driver Guide - Actions Associated with DNP3 Outstations (Using DNP3 Specific Actions)

Actions Associated with DNP3 Outstations

These actions are specific to DNP3 master outstations:

  • Close Connection—outstations for which direct communications is available on demand
  • Delete File
  • Disable Unsolicited Events
  • Download File
  • Enable Unsolicited Events
  • Execute Command
  • Execute Remote Method—on outstations that are also ClearSCADA DNP3 Slaves
  • Extend Connection—outstations for which direct communications is available on demand
  • Freeze—outstations using direct communications only
  • Freeze and Clear—outstations using direct communications only
  • Open Connection—outstations for which direct communications is available on demand
  • Perform Level 3 Scan
  • Read Device Attributes
  • Reset Poll Statistics
  • Set Clock
  • Set Update Key—outstations that use DNP3 secure authentication
  • Upload File.

This action is specific to DNP3 slave outstations:

  • Set Update Key—outstations that use DNP3 secure authentication.


DNP3 Driver Guide - Actions Associated with DNP3 Counter Points (Using DNP3 Specific Actions)

Actions Associated with DNP3 Counter Points

This action is specific to DNP3 Counter points:

  • Initialize.


DNP3 Driver Guide - Actions Associated with DNP3 String Points (Using DNP3 Specific Actions)

Actions Associated with DNP3 String Points

These actions are specific to DNP3 String points:

  • Read String
  • Set Value.


DNP3 Driver Guide - Actions Associated with DNP3 Pulse Actions (Using DNP3 Specific Actions)

Actions Associated with DNP3 Pulse Actions

This action is specific to DNP3 Pulse (NULL) Actions and DNP3 Pulse (Trip-Close) Actions:

  • Inching.


DNP3 Driver Guide - Actions Associated with DNP3 Status Points (Using DNP3 Specific Actions)

Actions Associated with DNP3 Status Points

This action is specific to DNP3 Status Points:

  • Refresh.


DNP3 Driver Guide - Alphabetical List of DNP3 Specific Actions (Using DNP3 Specific Actions)

Alphabetical List of DNP3 Specific Actions

This section lists those actions that are specific to items on the DNP3 driver. The actions are listed in alphabetical order and comprise:

  • Close Connection
  • Delete File
  • Disable Unsolicited Events
  • Download File
  • Enable Unsolicited Events
  • Execute Command
  • Execute Remote Method
  • Extend Connection
  • Freeze
  • Freeze and Clear
  • Inching
  • Initialize
  • Open Connection
  • Perform Level 3 Scan
  • Read Device Attributes
  • Read String
  • Refresh
  • Reset Poll Statistics
  • Set Clock
  • Set Update Key
  • Set Value
  • Upload File.

NOTE: If your system is running a DNP3 Extension Driver, refer to the relevant DNP3 extension driver guide for any DNP3-specific actions that are not listed above.


DNP3 Driver Guide - Close Connection (Using DNP3 Specific Actions)

Close Connection

Associated with: DNP3 master outstations for which the direct connection is available on demand rather than always online

Security permission required to access this pick action: Retrieve Data

WARNING

unexpected behavior of application

Use the Close Connection pick action with care. Always check an outstation’s current activity before deciding whether to use this action.

To check whether an outstation is currently processing a request, look at its entry in the Outstation List’s Current Request column. You can also check an outstation’s current activity via, for example, the Events List or the outstation’s Status display.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

This pick action is only available while the direct connection to an On Demand outstation is open (that is, while ClearSCADA is in the process of retrieving data from, or sending controls to, the outstation).

If necessary, use the Close Connection pick action to close the direct connection that is currently open.

When the Close Connection pick action is executed, ClearSCADA completes any outstanding read response, then closes the connection. Any actions that are otherwise in progress, or are outstanding, are canceled.

Also see Open Connection.


DNP3 Driver Guide - Delete File (Using DNP3 Specific Actions)

Delete File

Associated with: DNP3 master outstations

Security permission required to access this pick action: Configure

This pick action applies to outstations that support File Transfer routines (see Specify Which File Transfer Routines an Outstation Supports).

Use this pick action to delete a file on a DNP3 outstation.

Select the Delete File pick action to display the Delete File window. Enter the full path and name of the file that you want to delete and select the OK button for ClearSCADA to delete the file.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name DeleteOSFile.


DNP3 Driver Guide - Disable Unsolicited Events (Using DNP3 Specific Actions)

Disable Unsolicited Events

Associated with: DNP3 master outstations

Security permission required to access this pick action: Disable Alarms

Use the Disable Unsolicited Events pick action to specify the Event Classes for which an outstation is no longer to generate unsolicited messages, and whether Virtual Terminal data is to no longer cause the outstation to send unsolicited messages.

Select the Disable Unsolicited Events pick action to display the Disable Unsolicited Events window and select the required check boxes:

  • Class 1 to Class 3—Select the check boxes of each Event Class for which the outstation is not to generate unsolicited messages. Clear the check boxes for the Event Classes for which the outstation can generate unsolicited messages.
  • Virtual Terminal Support—Select this check box if Virtual Terminal data is not to generate unsolicited messages. Clear the check box if Virtual Terminal data can generate unsolicited messages.

Select the OK button on the Disable Unsolicited Events window to confirm the selections and stop the outstation from generating unsolicited messages for the selected classes.

(Use the Enable Unsolicited Events pick action to enable an outstation to generate unsolicited messages for a class that is currently disabled.)

NOTE: If using this pick action with the Automation Interface, you need to specify the method name DisableUnsolEvents.


DNP3 Driver Guide - Download File (Using DNP3 Specific Actions)

Download File

Associated with: DNP3 master outstations

Security permission required to access this pick action: Retrieve Data

Use the Download File pick action to download a file (for example, an ISaGRAF curve, or a log file) from the ClearSCADA server to a DNP3 outstation.

Select the Download File pick action to display the Download File window. The content of the window varies, depending on the File Transfer Variation supported by the outstation (see Specify Which File Transfer Routines an Outstation Supports).

Where an outstation supports the Revised g70 Variations of File Transfer routines, the Download File window includes these fields:

  • Source Filename—Use to specify the name of the file that ClearSCADA is to download to the outstation. The file can be on the current main ClearSCADA server, or on a remote server.

If the file is on the main server, include the full path on that server, for example:
C:\<directory>\file1.txt

If the file is on a remote server, you need to:

  • Specify the UNC path to the file, for example,
    \\<server name>\<share name>\<directory>\file1.txt
  • Provide ClearSCADA with the necessary Read access to the file on the remote server.
  • Destination Filename—Use to specify the location (full path) to which ClearSCADA is to download the file at the outstation, and the name that ClearSCADA is to assign to the downloaded file.

The DNP3 outstation may impose file name restrictions on the files that are to be downloaded to it. See the outstation documentation regarding such restrictions.

  • Activate—Select this check box to automatically activate the file once it has been downloaded. Files can only be activated automatically on DNP3 outstations that support DNP3 Function Code 31 (Activate Configuration).

Clear the check box (the default) if you do not want the file to be activated after being downloaded.

Where an outstation supports the Legacy g70v1 File Transfer variation, the Download File window includes a single Filename field. Use the field to enter the name of the file that you want to download to the outstation and then select the OK button for ClearSCADA to perform the download.

The location of the file on the server is specified as part of the ClearSCADA Server Configuration (see Define the DNP3 Master File Transfer Parameters). The file has to be in the specified folder on whichever ClearSCADA server is currently the main server.

The DNP3 outstation may impose file name restrictions on the files that are to be downloaded to it. See the outstation documentation regarding such restrictions.

Example:

The directory from which files on the current main server are downloaded to DNP3 outstations is set to C:\ClearSCADADB.

An operator selects the Download File pick action on a particular DNP3 outstation and specifies the file name myfile.txt.

On execution of the pick action, ClearSCADA downloads the file myfile.txt from the server location C:\ClearSCADADB, to the DNP3 outstation.


DNP3 Driver Guide - Enable Unsolicited Events (Using DNP3 Specific Actions)

Enable Unsolicited Events

Associated with: DNP3 master outstations

Security permission required to access this pick action: Disable Alarms

Use the Enable Unsolicited Events pick action to specify the Event Classes for which an outstation is permitted to generate unsolicited messages, and whether Virtual Terminal data will cause the outstation to send unsolicited messages.

Select the Enable Unsolicited Events pick action to display the Enable Unsolicited Events window and select the required check boxes:

  • Class 1 to Class 3—Select the check boxes of the Event Classes for which the outstation can generate unsolicited messages. Clear the check boxes for the Event Classes for which the outstation is not to generate unsolicited messages.
  • Virtual Terminal Support—Use to enable or disable Virtual Terminal unsolicited VT events on the outstation. (For more information on Virtual Terminals, (see Configure Virtual Terminal Support).

Select the Virtual Terminal Support check box if:

  • The outstation supports Virtual Terminals and you want it to generate unsolicited VT events.

Clear the Virtual Terminal Support check box if:

  • The outstation does not support Virtual Terminals

Or:

  • The outstation supports Virtual Terminals but you do not want it to generate unsolicited VT events.

Select the OK button on the Enable Unsolicited Events window to confirm the selections and allow the outstation to generate unsolicited messages for the selected classes.

This pick action is independent of the options configured in the ClearSCADA database. The DNP3 driver maintains status information on which classes are enabled (either through the pick action or via the message sent on start-up) and will check the classes that are not enabled for unsolicited events (the reverse applies to the Disable Unsolicited Events pick action). The pick action does not modify the database configuration.

Use the Disable Unsolicited Events pick action to stop an outstation from generating unsolicited messages for a class that is currently enabled.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name EnableUnsolEvents.


DNP3 Driver Guide - Execute Command (Using DNP3 Specific Actions)

Execute Command

Associated with: DNP3 master outstations

Security permission required to access this pick action: Retrieve Data

Use the Execute Command pick action to execute a particular command. The command can only be used with DNP3 Slaves that support this feature.

Select the Execute Command pick action to display the Execute Command window. Enter the command string that you want to execute at the outstation, and then select the OK button to execute that command.


DNP3 Driver Guide - Execute Remote Method (Using DNP3 Specific Actions)

Execute Remote Method

Associated with: DNP3 master outstations

NOTE: The Execute Remote Method pick action is only available when a DNP3 outstation is also a ClearSCADA DNP3 Slave Outstation
(see Specify Whether the Outstation is a ClearSCADA DNP3 Slave Outstation).

Security permission required to access this pick action: Control

Use the Execute Remote Method pick action to execute a method (pick action) on a remote ClearSCADA server. For example, to send a One Shot control to an outstation that is on another ClearSCADA system.

Select the pick action to display the Execute Remote Method window. Use the fields in the window to specify the method that you want ClearSCADA to perform on a remote item, and any parameters for that method:

  • Object—Enter the ID of the remote item or the full path of the item.
  • Method—Enter the name of the method that ClearSCADA is to execute on the remote item. Refer to the Database Schema for a list of methods associated with each type of database item. Depending on the method, you may need to check that the particular method is supported by the remote item (for instance, check that the feature is enabled in the remote item’s configuration).
  • Parameters—Specify the required values of any parameters associated with the specified method. Enter the parameter values as a comma separated list. You need to specify the parameters in the order that they are listed in the Database Schema. You typically need to specify each of the parameters for a method, although you can omit parameters if they are optional.

Leave the field blank if a method does not have any parameters associated with it.

Example:

The Execute Remote Method pick action is used to remotely trigger a Level 3 scan by a DNP3 outstation on a remote ClearSCADA system. The remote outstation is to scan those points that have Level 3 Scanning enabled and that are configured to use Scan Groups 2, 4 and 6.

To perform the required scan remotely, the Execute Remote Method window is used to specify these settings:

Object: DNP3.Ostn33

Method: PerformLevel3Scan (The method name of the required pick action, as listed in the Database Schema.)

Parameters: 0, 1, 0, 1, 0, 1, 0, 0 (The PerformLevel3Scan method can be used to scan points that are in any of up to eight scan groups, specified using the eight parameters Group1 to Group8. The parameters are set Boolean TRUE for the points in that scan group to be included in the Level 3 Scan, and FALSE to be excluded. For further details, see the PerformLevel3Scan method entry in the Database Schema, and see Perform Level 3 Scan.)

If an Execute Remote Method action is used on your system on a regular basis, you might want to consider associating the Execute Remote Method with a Schedule. This would enable the method to be triggered automatically at regular intervals, and would avoid the need to manually specify the Object, Method and Parameter properties whenever it is triggered. For information on configuring a Schedule and using it to trigger a method on a regular basis, see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration.

For an Execute Remote Method action that is only used when required, you might want to consider:

  • Specifying the Execute Remote Method as a custom method on the User Methods tab of the applicable configuration Form. For more information, see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration.
  • Using a stand-alone Method Call to execute the method. If you use a Method Call, you would specify the DNP3 Direct Outstation or DNP3 PSTN Outstation as the Method Object, and the Execute Remote Method as the Method. For more information, see Stand-Alone Method Calls in the ClearSCADA Guide to Core Configuration.

Either of these options would avoid the need to manually specify the Object, Method and Parameter properties whenever the Execute Remote Method is triggered.


DNP3 Driver Guide - Extend Connection (Using DNP3 Specific Actions)

Extend Connection

Associated with: DNP3 master outstations for which the direct connection is available on demand rather than always online

Security permission required to access this pick action: Retrieve Data

This pick action is only available while the direct connection to an On Demand outstation is open (that is, while ClearSCADA is in the process of retrieving data from, or sending controls to, the outstation).

Optionally use the Extend Connection pick action to extend the time for which the connection remains open. The time is extended by the Max Online Time from the instant that the request is executed. The Max Online Time is defined on the DNP3 Outstation Form’s Direct tab (see Specify Whether the Direct Communications Connection is Always Online or only Available on Demand).

Also see Open Connection, and see Close Connection.


DNP3 Driver Guide - Freeze (Using DNP3 Specific Actions)

Freeze

Associated with: DNP3 master outstations that support Frozen Counter points

Security permission required to access this pick action: Diagnostics

Use the outstation’s Freeze pick action to copy the values of the Counter Points to their associated Frozen Counter Points.

The pick action takes into account the Freeze settings configured on the Outstation Form (see Configure Frozen Counter Support).

Also see Freeze and Clear.


DNP3 Driver Guide - Freeze and Clear (Using DNP3 Specific Actions)

Freeze and Clear

Associated with: DNP3 master outstations that support Frozen Counter points

Security permission required to access this pick action: Diagnostics

Use the outstation’s Freeze and Clear pick action to copy the values of the Counter Points to their associated Frozen Counter Points, and then reset the Counters back to a pre-configured value. The reset value is determined by the Slave and is typically zero.

The pick action takes into account the Freeze settings configured on the Outstation Form (see Configure Frozen Counter Support).

Also see Freeze.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name FreezeClear.


DNP3 Driver Guide - Inching (Using DNP3 Specific Actions)

Inching

Associated with: DNP3 Pulse (NULL) Actions and DNP3 Pulse (Trip-Close) Actions

NOTE: The Inching pick action is only available for those Pulse Actions for which the Inching feature is enabled (see Configure Pulse Properties).

Security permission required to access this pick action: Control

Use the Inching pick action to request ClearSCADA to perform a pulse action control for a user-configurable amount of time and user-configurable number of pulses, up to and including those specified on the corresponding Pulse Action Form.

Select the Inching pick action to display the Inching window. Use the fields on the window to specify the required settings for the control:

  • Action—For a Trip-Close Pulse Action, use the combo box to select the required pulse action. A NULL Pulse Action has only a single action and as such, only one option is available.

The name of each action in the Action field corresponds to the description that has been assigned to that action, using the Description field within the Actions section of the Pulse Action Form (see Configure a NULL Pulse Action, and see Configure Trip and Close Pulse Actions).

  • Pulse Count—Use to specify the number of times that the outstation executes the On-Off pulse periods that are defined using the On Time and Off Time fields, below.

You can specify a value up to and including the number of Pulse Counts that are specified on the corresponding Pulse Action Form (see Configure Pulse Properties).

  • On Time—Specify how long each pulse should remain on. Use this parameter in conjunction with the Off Time and Pulse Count, to define the complete pulse action.

You can only specify a time period up to and including the length of the On Time that is specified on the Pulse Action Form (see Configure a NULL Pulse Action, and see Configure Trip and Close Pulse Actions).

Enter the time in the OPC Time Format, for example 5S (for five seconds). You can either overtype the existing entry, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

  • Off Time—Specify how long each pulse should remain off. Use this parameter in conjunction with the On Time and Pulse Count, to define the complete pulse action.

You can only specify a time period up to and including the length of the Off Time that is specified on the Pulse Action Form (see Configure a NULL Pulse Action, and see Configure Trip and Close Pulse Actions).

Enter the time in the OPC Time Format, for example 1S (for one second). You can either overtype the existing entry, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

For an illustrated example of how you might configure the above parameters for a Pulse Action, see Pulse Control Example.

You can use the Control pick action to carry out a pulse control for the same number of Pulse Counts and for the same amount of time that is defined on the Pulse Action Form (rather than for a user-configurable number of pulses or on and off times).


DNP3 Driver Guide - Initialize (Using DNP3 Specific Actions)

Initialize

Associated with: DNP3 Counter points

Security permission required to access this pick action: Control

Use the Initialize pick action to reset the value of a Counter point.

The Initialize pick action is only available on Counter points on which:

  • Initialization is enabled (see Configure the Initialization Properties of a DNP3 Counter Point)
  • Your User Account is allocated the Control security permission.

The outstation’s counter Reset Method determines whether the value to which a Counter point is reset is user configurable. The counter Reset Method is specified on the DNP3 Outstation Form (see Configure the Counter Reset Method).

If the counter Reset Method is set to Initialize_DATA (g20v0), selecting the Initialize pick action will reset the Counter point’s value to the default that is specified at the outstation.

If the counter Reset Method is set to one of the WRITE options, selecting the Initialize pick action will display an Initialize window.

Use the window’s Value field to specify the value to which the point is to be initialized.


DNP3 Driver Guide - Open Connection (Using DNP3 Specific Actions)

Open Connection

Associated with: DNP3 master outstations for which the direct connection is available on demand rather than always online

Security permission required to access this pick action: Retrieve Data

With an outstation on which the direct connection is available On Demand, ClearSCADA retrieves data from the outstation automatically, during the period for which communications is available to that outstation.

If required, you can also use the Open Connection pick action to retrieve data from the outstation. Use the Open Connection pick action to open the connection to the outstation and for the connection to stay online for the specified Max Online Time. The Max Online Time is defined on the DNP3 Outstation Form’s Direct tab (see Specify Whether the Direct Communications Connection is Always Online or only Available on Demand).

ClearSCADA only opens the connection should the pick action be triggered during the period for which outstation communications is available. The Communications Availability period is specified on the DNP3 Outstation Form’s Outstation tab (see Specify the Availability of Communications Between the Outstation and ClearSCADA in the ClearSCADA Guide to Advanced Drivers). (Should an Open Connection be requested outside of the outstation’s Communications Availability, the request will be rejected.)

Also see Extend Connection, and see Close Connection.


DNP3 Driver Guide - Perform Level 3 Scan (Using DNP3 Specific Actions)

Perform Level 3 Scan

Associated with: DNP3 master outstations

Security permission required to access this pick action: Retrieve Data

Use the Perform Level 3 Scan pick action to obtain data for any points that have Level 3 Scanning enabled and use one of the Scan Groups that are selected for the pick action. The pick action also obtains data for any DNP3 Status Points that use one of the selected Scan Groups.

Select the Perform Level 3 Scan pick action to display the Perform Level 3 Scan window.

Use the Group 1 to Group 8 check boxes to specify the Scan Groups for which an immediate Level 3 Scan is to be performed. Select a check box for each Group that is to be included in the Level 3 Scan. Clear the check box for each Group that is to be excluded from the scan.

Points are only scanned as a result of selecting this pick action if they are enabled for Level 3 scanning and they are configured to use one of the Scan Groups that is selected in the Perform Level 3 Scan window. (Scan Groups and Level 3 Scans are specified on a per point basis—see Configure General Point Properties. For DNP3 Status Points, see Specify the Scan Group that is Associated with the Status Data Retrieval. Unlike other DNP3 points, DNP3 Status Points are always enabled for Level 3 scanning.)

When the OK button is selected, the Perform Level 3 Scan pick action performs an immediate Level 3 Scan for those points that are enabled for Level 3 scanning and use one of the selected Scan Groups. The action does not wait for the Level 3 Scan timer to expire before performing the scan.


DNP3 Driver Guide - Read Device Attributes (Using DNP3 Specific Actions)

Read Device Attributes

Associated with: DNP3 master outstations

Security permission required to access this pick action: Retrieve Data

Use the Read Device Attributes pick action to request ClearSCADA to read an outstation’s Device attributes and store the results in the ClearSCADA database.

In addition to this pick action, the Read Device Attributes on Startup field on the DNP3 Outstation Form can be used to specify whether ClearSCADA is to read an outstation’s Device attributes automatically, whenever communications are established with that outstation (see Configure the Actions that Occur on Communications Startup).

You can view the uploaded attributes using the Outstation’s Status display window (see DNP3 Outstation Status Attributes). The attributes are also available as OPC properties (see the Database Schema and the ClearSCADA Guide to the Database).


DNP3 Driver Guide - Read String (Using DNP3 Specific Actions)

Read String

Associated with: DNP3 String Points

Security permission required to access this pick action: Diagnostics

Use the Read String pick action to update the value of the string point in the ClearSCADA database.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name RequestRead.


DNP3 Driver Guide - Refresh (Using DNP3 Specific Actions)

Refresh

Associated with: DNP3 Status Points

Security permission required to access this pick action: Retrieve Data

ClearSCADA typically retrieves DNP3 Status Point data using a DNP3 Level 3 Scan (see Configuring DNP3 Status Points). If required, you can use the Refresh pick action to scan for status point data on demand.

When the Refresh action is triggered, ClearSCADA generates a Level 3 request for the status values. The data is retrieved during the next scan of the outstation on which the Status Points are located, regardless of whether the data has changed.

For more information on the Refresh pick action, see Refresh in the ClearSCADA Guide to Drivers.


DNP3 Driver Guide - Reset Poll Statistics (Using DNP3 Specific Actions)

Reset Poll Statistics

Associated with: DNP3 master outstations

Security permission required to access this pick action: Diagnostics

Use the outstation’s Reset Poll Statistics pick action to reset the outstation’s Unsolicited Message, Integrity, and Class 1, 2 and 3 Poll Statistics. The statistics are shown on the Status display for the outstation (see DNP3 Outstation Status Attributes).


DNP3 Driver Guide - Set Clock (Using DNP3 Specific Actions)

Set Clock

Associated with: DNP3 master outstations

Security permission required to access this pick action: Control

Use the Set Clock pick action to trigger ClearSCADA to update a DNP3 outstation’s internal clock. The method by which ClearSCADA set’s the clock is specified on the outstation’s configuration Form (see Define Whether ClearSCADA Updates the Outstation Clock).


DNP3 Driver Guide - Set Update Key (Using DNP3 Specific Actions)

Set Update Key

NOTE: With DNP3 devices with which ClearSCADA communicates using a DNP3 Extension Driver, additional means of setting the Update Key may be supported. Any such additional functionality is explained in the relevant DNP3 extension driver guide.

Associated with: DNP3 master outstations and DNP3 slave outstations

Security permission required to access this pick action: Configure

This pick action is only available on outstations on which DNP3 Secure Authentication is enabled.

With DNP3 Secure Authentication, each DNP3 user requires their own Update Key. ClearSCADA supports a single user (the ‘Default User’ or ‘DNP3 User 1’). Use the pick action to set the private Update Key for the default user on a particular outstation. The outstation uses the Update Key to authenticate Session Key Change requests from its DNP3 master.

You will need to use a third-party random number generator application to generate a suitable Update Key. The key has to comprise a sequence of hexadecimal digits. The key is case insensitive. The size of the Update Key is determined by the Key Wrap algorithm. The algorithm AES-128 requires a 128-bit key comprising 32 hexadecimal digits (for example, 0123456789ABCDEF0123456789ABCDEF).

It is imperative that the security of the key is not compromised. Only store a copy of the Update Key in a format or location that cannot be accessed by others. Similarly, if you need to transmit the Update Key, you should use encryption so that the key cannot be accessed by eavesdropping on the communications.

Select the Set Update Key pick action to display the Set Update Key window.

Paste the required Update Key into the Key field in the window.

A diagnostics message is displayed if the key contains non-hexadecimal digits or is of the wrong length.


DNP3 Driver Guide - Set Value (Using DNP3 Specific Actions)

Set Value

Associated with: DNP3 String points

Security permission required to access this pick action: Control

Use the Set Value pick action to set the value of a string point. Select the Set Value pick action to display the Set Value window. Enter the required value, and then select the OK button to confirm the entry.


DNP3 Driver Guide - Upload File (Using DNP3 Specific Actions)

Upload File

Associated with: DNP3 master outstations

Security permission required to access this pick action: Retrieve Data

Use the Upload File pick action to upload any file from a Slave outstation to its master. You can use the pick action whenever the master is in communication with the Slave.

Select the Upload File pick action to display the Upload File window. The content of the window varies, depending on the File Transfer Variation supported by the outstation (see Specify Which File Transfer Routines an Outstation Supports).

Where an outstation supports the Revised g70 Variations of File Transfer routines, the Upload File window includes these fields:

  • Source Filename—Use to specify the full path and name of the file that ClearSCADA is to upload from the outstation.
  • Destination Filename—Use to specify the file to which ClearSCADA is to write on either the current main ClearSCADA server, or a remote server.

If the file is on the main server, include the full path on that server, for example:
C:\<directory>\file1.txt

If the file is on a remote server, you need to:

  • Specify the UNC path to the file—for example,
    \\<server name>\<share name>\<directory>\file1.txt
  • Provide ClearSCADA with the necessary Create/Write access permissions for the file on the remote server.

Where an outstation supports the Legacy g70v1 File Transfer variation, the Upload File window includes a single Filename field. Use the field to enter the name of the file that you want to upload, and then select the OK button to perform the upload.

The location to which the file is uploaded is specified as part of the ClearSCADA Server Configuration (see Define the DNP3 Master File Transfer Parameters). The file will be uploaded to that location on whichever ClearSCADA server is currently the main server.

The DNP3 outstation may impose file name restrictions on the files that it holds. See the outstation documentation regarding such restrictions.

Example:

The directory on the main server into which files are uploaded from DNP3 outstations is set to C:\ClearSCADADB.

An operator selects the Upload File pick action on a particular DNP3 outstation, and specifies the file name thisfile.txt.

On execution of the pick action, ClearSCADA uploads the file thisfile.txt from the DNP3 outstation, to the server location C:\ClearSCADADB.


DNP3 Driver Guide - DNP3 Specific Status Display Attributes

DNP3 Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each DNP3 outstation provides information about the present state of the individual outstation.

Use this section if you need information on the status of any DNP3 database items on your system.

This section covers those attributes that are DNP3 driver-specific and includes:

  • DNP3 Outstation Set Status Attributes
  • DNP3 Outstation Status Attributes
  • DNP3 Virtual Terminal Status Attributes
  • DNP3 Point and Pulse Action Status Attributes
  • Alphabetical List of DNP3 Specific Status Display Attributes
  • Numeric List of DNP3 Outstation Device Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


DNP3 Driver Guide - DNP3 Outstation Set Status Attributes (DNP3 Specific Status Display Attributes)

DNP3 Outstation Set Status Attributes

This Status attribute is specific to DNP3 Master Outstation Sets:

  • DNP3 Address.


DNP3 Driver Guide - DNP3 Outstation Status Attributes (DNP3 Specific Status Display Attributes)

DNP3 Outstation Status Attributes

These Status attributes are specific to DNP3 Master Outstations:

  • Device Trouble Alarm
  • Already Executing Alarm
  • Configuration Corrupt Alarm
  • Event Buffer Overflow Alarm
  • Enable Unsolicited Alarm
  • Disable Unsolicited Alarm
  • Data Processing Alarm
  • Clock Errors
  • Protocol Alarm
  • State
  • IIN Status
  • Integrity Poll Statistics
  • Class n Poll Statistics
  • Unsolicited Message Statistics
  • Last Unsolicited
  • Unsolicited Event Reporting Status.

In addition to the above, where a DNP3 outstation supports Device Attributes, one or more blocks of Device Attributes may be displayed (see Numeric List of DNP3 Outstation Device Attributes).


DNP3 Driver Guide - DNP3 Virtual Terminal Status Attributes (DNP3 Specific Status Display Attributes)

DNP3 Virtual Terminal Status Attributes

The Status displays for DNP3 VT Service Port Master, and DNP3 VT Service Port Slave items contain status attributes that are common to channels on many advanced drivers (see Actions Associated with Channels on Advanced Drivers in the ClearSCADA Guide to Drivers).

The Status displays for DNP3 Virtual Terminal items contain only ‘core’ status attributes (see Understand the Status Display in the ClearSCADA Guide to ViewX and WebX Clients).


DNP3 Driver Guide - DNP3 Point and Pulse Action Status Attributes (DNP3 Specific Status Display Attributes)

DNP3 Point and Pulse Action Status Attributes

This Status attribute is specific to DNP3 points other than DNP3 Status Points:

  • Source.

Each DNP3 Status Points database item can be used to specify up to 10 separate Status Points for which ClearSCADA is to retrieve data. For each separate Status Point that is defined on a DNP3 Status Points Form, ClearSCADA provides this set of status attributes:

  • <DNP3 Status Point Description> Source
  • <DNP3 Status Point Description> Value
  • <DNP3 Status Point Description> Quality
  • <DNP3 Status Point Description> Update Time.

<DNP3 Status Point Description> corresponds to the string that is entered in the relevant Description field on the DNP3 Status Points Form (see Specify the Status Points for which Data is Retrieved).

NOTE: Control attributes are only available for DNP3 output points that can be controlled from ClearSCADA. If an output point is controlled exclusively by another application, no control attributes are displayed for that point (see Specify Whether an Output Point is Controlled by ClearSCADA).


DNP3 Driver Guide - Alphabetical List of DNP3 Specific Status Display Attributes (DNP3 Specific Status Display Attributes)

Alphabetical List of DNP3 Specific Status Display Attributes

This section lists those Status attributes that are specific to items on the DNP3 driver.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.

The attributes are listed in alphabetical order and comprise:

  • Already Executing Alarm
  • Class n Poll Statistics
  • Clock Errors
  • Configuration Corrupt Alarm
  • Data Processing Alarm
  • Device Trouble Alarm
  • DNP3 Address
  • <DNP3 Status Point Description> Quality
  • <DNP3 Status Point Description> Source
  • <DNP3 Status Point Description> Update Time
  • <DNP3 Status Point Description> Value
  • Enable Unsolicited Alarm
  • Event Buffer Overflow Alarm
  • IIN Status
  • Integrity Poll Statistics
  • Last Unsolicited
  • Protocol Alarm
  • Source
  • State
  • Unsolicited Event Reporting Status
  • Unsolicited Message Statistics.

In addition to the above, where a DNP3 outstation supports Device Attributes, one or more blocks of Device Attributes may be displayed (see Numeric List of DNP3 Outstation Device Attributes).

NOTE: If your system is running a DNP3 Extension Driver, refer to the relevant DNP3 extension driver guide for any DNP3-specific status attributes that are not listed above.


DNP3 Driver Guide - Already Executing Alarm (DNP3 Specific Status Display Attributes)

Already Executing Alarm

Associated with: DNP3 master outstations

The Already Executing Alarm attribute indicates whether the outstation’s DNP3 ALREADY_EXECUTING IIN bit is set.

If the bit is set, this indicates that there is a problem executing one of the following functions:

  • The master station has sent a request to perform one of the following operations, but that operation is already in progress:
  • SELECT
  • OPERATE
  • DIRECT OPERATE
  • DIRECT OPERATE (NO Acknowledgment)
  • INIT. APPLICATION—The master station has sent a request to active an outstation application that is already being used.
  • START APPLICATION—The master station has sent a request to run an outstation program that is already running.
  • STOP APPLICATION—The master station has sent a request to stop an outstation program that is not running.
  • SAVE CONFIGURATION—The master station has requested that the configuration is saved, but the outstation is already in the process of saving configuration.

Possible States: Displays one of the Standard Alarm States.

If the ALREADY_EXECUTING IIN bit is set, use the outstation’s diagnostic features to determine why the outstation could not execute the function. For example, it could be that the outstation was unable to execute an action sent from ClearSCADA because at that time, the outstation was already executing the action as part of an internal logic program. When you have discovered why the outstation could not execute the function, you will need to determine whether there is a problem at the outstation or if it is just a case that the outstation was busy when ClearSCADA sent the request.


DNP3 Driver Guide - Class n Poll Statistics (DNP3 Specific Status Display Attributes)

Class n Poll Statistics

Associated with: DNP3 master outstations

The Class 1 Poll Statistics, Class 1 Poll Statistics, and Class 2 Poll Statistics attributes show the number of attempted and successful DNP3 Class Event Polls issued by the ClearSCADA DNP3 driver to the outstation, since the statistics were last reset.

You can reset the statistics using the Reset Poll Statistics pick action. If the poll statistics have been reset, two sets of Poll Statistics attributes are displayed for each class. The first displays the statistics since the last reset of poll statistics; the second displays the statistics between the previous two resets.

Example:

5 attempted, 5 successful since 04/Nov/2003 11:36:49.255

If the statistics have been reset, a second entry will display statistics in the form:

25 attempted, 23 successful between 14/Oct/2003 11:35:32.261 and 04/Nov/2003 11:36:49.255


DNP3 Driver Guide - Clock Errors (DNP3 Specific Status Display Attributes)

Clock Errors

Associated with: DNP3 master outstations

This status attribute indicates whether either of the following has occurred:

  • ClearSCADA has read the outstation’s time and found it to differ from the server’s time by more than the specified Maximum Acceptable Drift. (This only applies to outstations on which the Check Clock Drift feature is enabled and supported—see Define Whether ClearSCADA Updates the Outstation Clock.)
  • The ClearSCADA server has failed in its attempt to set the outstation’s clock (due, for example, to comms failure or a protocol error).

Possible States: Displays one of the Standard Alarm States.

(On an outstation on which ClearSCADA does NOT set the clock, the Clock Errors status attribute is ‘Enabled Inactive’, indicating no clock errors.)

Further Information

Outstation Clock.


DNP3 Driver Guide - Configuration Corrupt Alarm (DNP3 Specific Status Display Attributes)

Configuration Corrupt Alarm

Associated with: DNP3 master outstations

The Configuration Corrupt Alarm attribute indicates whether the outstation’s DNP3 CONFIG_CORRUPT IIN bit is set.

If the bit is set, this indicates that the outstation has detected corrupt configuration. This may relate to the corruption of essential configuration that affects the outstation’s ability to function reliably, or it may relate to non-critical configuration.

An outstation’s CONFIG_CORRUPT IIN bit might be set, for example, when:

  • A new outstation is installed.
  • The configuration is reset at the outstation.
  • A hardware fault at the outstation results in the configuration becoming corrupt or unavailable.

Possible States: Displays one of the Standard Alarm States.

See the outstation documentation for information on clearing the CONFIG_CORRUPT IIN bit. Depending on the problem that caused the bit to be set, you may need to re-configure the outstation.


DNP3 Driver Guide - Data Processing Alarm (DNP3 Specific Status Display Attributes)

Data Processing Alarm

Associated with: DNP3 master outstations

The Data Processing Alarm attribute indicates whether the SCADA master (ClearSCADA) has been unable to process a data response from the outstation. The master is unable, for example, to process data that is formatted incorrectly or that includes unsupported content.

Possible States: Displays one of the Standard Alarm States.

See the outstation documentation for information on clearing the Data Processing IIN bit.


DNP3 Driver Guide - Device Trouble Alarm (DNP3 Specific Status Display Attributes)

Device Trouble Alarm

Associated with: DNP3 master outstations

The Device Trouble Alarm attribute indicates whether the outstation’s DNP3 DEVICE_TROUBLE IIN bit is set. This bit is typically set when there is a hardware problem at the outstation.

Possible States: Displays one of the Standard Alarm States.

See the outstation documentation for information on clearing the Device Trouble IIN bit.


DNP3 Driver Guide - Disable Unsolicited Alarm (DNP3 Specific Status Display Attributes)

Disable Unsolicited Alarm

Associated with: DNP3 master outstations

The Disable Unsolicited Alarm attribute indicates whether the DNP3 ‘Disable Unsolicited’ message, sent by the ClearSCADA DNP3 driver to disable unsolicited responses in the outstation, was successful.

The ClearSCADA DNP3 driver will send the ‘Disable Unsolicited’ message if:

  • You Enable Unsolicited Message Generation in the outstation. (The outstation will initially send a ‘Disable Unsolicited’ message when establishing communications, followed by an ‘Enable Unsolicited’ message once communications are established.)
  • You Configure Virtual Terminal Support in the outstation
  • The Disable Unsolicited Events pick action is executed.

Possible States: Displays one of the Standard Alarm States.

Use the Unsolicited Event Reporting Status attribute to determine which unsolicited event classes are enabled and disabled in the outstation.


DNP3 Driver Guide - DNP3 Address (DNP3 Specific Status Display Attributes)

DNP3 Address

Associated with: DNP3 master outstation Sets

The DNP3 Address attribute displays the address of the outstation set, as configured on the DNP3 tab of the DNP3 Outstation Set Form (see Specify the Address of a DNP3 Master Set).

Example:

30000


DNP3 Driver Guide - <DNP3 Status Point Description> Quality (DNP3 Specific Status Display Attributes)

<DNP3 Status Point Description> Quality

Associated with: DNP3 Status Points

This attribute indicates the ‘quality’ or reliability of an individual Status Point’s data. The attribute is prefixed with the text that is entered in the relevant Description field on the DNP3 Status Points Form (see Specify the Status Points for which Data is Retrieved). This indicates the individual Status Point to which the information relates.

The attribute displays one of a subset of the values supported by the Quality attribute that is common to many driver items (see Quality in the ClearSCADA Guide to Drivers).

(To assess the quality of all of the data being reported by a DNP3 Status Points database item, as opposed to that of an individual Status Point on that item, look at the unprefixed Quality attribute. You can find the Quality attribute toward the top of the item’s Status display.)


DNP3 Driver Guide - <DNP3 Status Point Description> Source (DNP3 Specific Status Display Attributes)

<DNP3 Status Point Description> Source

Associated with: DNP3 Status Points

This attribute is prefixed with the text that is entered in the relevant Description field on the DNP3 Status Points Form (see Specify the Status Points for which Data is Retrieved). The text indicates the individual Status Point to which the information relates.

The attribute indicates the location of the individual Status Point. Information is displayed in this format:

<DNP3 Group> : Point Number <Point Number>

Example:

Group 30 Analog Input : Point Number 50000

Use the attribute in conjunction with the DNP3 Status Points database item’s unprefixed Source attribute, which indicates the outstation and DNP3 master with which the item is associated.


DNP3 Driver Guide - <DNP3 Status Point Description> Update Time (DNP3 Specific Status Display Attributes)

<DNP3 Status Point Description> Update Time

Associated with: DNP3 Status Points

This attribute indicates the date and time that an individual Status Point’s data was last updated in the database.

Example:

May/06/2009 16:00:00.035

The attribute is prefixed with the text that is entered in the relevant Description field on the DNP3 Status Points Form (see Specify the Status Points for which Data is Retrieved). The text indicates the individual Status Point to which the information relates.


DNP3 Driver Guide - <DNP3 Status Point Description> Value (DNP3 Specific Status Display Attributes)

<DNP3 Status Point Description> Value

Associated with: DNP3 Status Points

This attribute indicates the value of an individual Status Point. This is the value that ClearSCADA retrieved at the Status point’s last <DNP3 Status Point Description> Update Time.

The attribute is prefixed with the text that is entered in the relevant Description field on the DNP3 Status Points Form (see Specify the Status Points for which Data is Retrieved). The text indicates the individual Status Point to which the information relates.


DNP3 Driver Guide - Enable Unsolicited Alarm (DNP3 Specific Status Display Attributes)

Enable Unsolicited Alarm

Associated with: DNP3 master outstations

The Enable Unsolicited Alarm attribute indicates whether the DNP3 ‘Enable Unsolicited’ message, sent by the ClearSCADA DNP3 driver to enable unsolicited responses in the outstation, was successful.

The ClearSCADA DNP3 driver will send the ‘Enable Unsolicited’ message if:

  • You Enable Unsolicited Message Generation in the outstation
  • You Configure Virtual Terminal Support in the outstation
  • The Enable Unsolicited Events pick action is executed.

Possible States: Displays one of the Standard Alarm States.

Use the Unsolicited Event Reporting Status attribute to determine which unsolicited event classes are enabled in the outstation.


DNP3 Driver Guide - Event Buffer Overflow Alarm (DNP3 Specific Status Display Attributes)

Event Buffer Overflow Alarm

Associated with: DNP3 master outstations

The Event Buffer Overflow Alarm attribute indicates whether the outstation’s DNP3 EVENT_BUFFER_OVERFLOW IIN bit is set. This bit is set by the outstation when it has to discard events due to its internal event buffer being full. This might occur when an outstation has been offline for an extended period of time, or it is logging events too quickly and therefore its buffers are filling more quickly than expected. (Which events an outstation discards is outstation-specific. Some outstations might discard the oldest events, whereas other outstations might discard the newest events. Refer to a device’s DNP3 Profile document to determine which events it will discard.)

Having an outstation report that its EVENT_BUFFER_OVERFLOW IIN bit is set is a serious condition as it means data has been (and is still being) lost, so it is vital that the cause of the event buffer overflow is rectified as soon as possible. The problem might be due, for example, to bad configuration, a bad sensor, or communication problems. Once the problem is rectified and healthy communications are re-established, ClearSCADA will upload events from the outstation until all events have been successfully uploaded.

Possible States: Displays one of the Standard Alarm States.

If the event buffer of the outstation overflows regularly, do one (or more) of the following:

  • Increase the size of the outstation’s internal event buffer (see the documentation for the outstation)
  • Enable the outstation to generate unsolicited messages for the event class(es) that are filling the outstation’s event buffer (see Enable Unsolicited Message Generation)
  • Increase the frequency with which the ClearSCADA DNP3 driver polls the outstation for the event class(es) that often cause the outstation’s event buffer to fill (see Specify When ClearSCADA Performs Class Polls)
  • Increase the frequency with which the ClearSCADA DNP3 driver performs outstation Integrity polls (see Specify When ClearSCADA Performs Integrity Polls).


DNP3 Driver Guide - IIN Status (DNP3 Specific Status Display Attributes)

IIN Status

Associated with: DNP3 master outstations

Each DNP3 outstation reports the status of its IIN Status Bits in every data packet that it sends to its master. For each IIN Status Bit that is set, an IIN Status attribute is displayed. The attribute indicates which IIN Status Bit(s) are indicating a problem, or the result of the last command, and the time that bit was set.

The IIN Status attribute displays information in the form:

<IIN Status Bit> at <DD/MMM/YYYY HH:MM:SS.sss>

where the <IIN Status Bit> might be any of the following:

  • Device Trouble
  • Configuration Corrupt
  • Outstation Busy (for instance, a Pulse Action or Control is in progress)
  • Parameter Out-of-Range
  • Invalid Object
  • Unsupported Function.

Example:

Parameter out-of-range at 10/Aug/2006 09:12:44:330

Any IIN Status bits that can raise an alarm in ClearSCADA are also listed as separate alarm attributes (for instance, the Configuration Corrupt Alarm attribute).

Also see Protocol Alarm.


DNP3 Driver Guide - Integrity Poll Statistics (DNP3 Specific Status Display Attributes)

Integrity Poll Statistics

Associated with: DNP3 master outstations

The Integrity Poll Statistics attribute shows the number of attempted and successful DNP3 Integrity Polls issued by the ClearSCADA DNP3 driver to the outstation since the statistics were last reset.

You can reset the statistics using the Reset Poll Statistics pick action. If the poll statistics have been reset, two sets of Integrity Poll Statistics attributes are displayed. The first displays the statistics since the last reset of the poll statistics; the second displays the statistics between the previous two resets.

Example:

24 attempted, 23 successful since 04/Nov/2003 11:36:49.255

If the statistics have been reset, a second entry will display statistics in the form:

124 attempted, 99 successful between 04/Oct/2003 11:32:49.261 and 04/Nov/2003 11:36:49.255


DNP3 Driver Guide - Last Unsolicited (DNP3 Specific Status Display Attributes)

Last Unsolicited

Associated with: DNP3 master outstations

The Last Unsolicited attribute indicates the time and date that the ClearSCADA server last received an unsolicited message from the outstation. The attribute displays ‘Never’ if the outstation has never sent an unsolicited message or does not have the ability to send unsolicited messages.

Example:

27/Jun/2006 10:02:40.015


DNP3 Driver Guide - Protocol Alarm (DNP3 Specific Status Display Attributes)

Protocol Alarm

Associated with: DNP3 master outstations

The Protocol Alarm attribute is common to outstations on many advanced drivers, but the errors that it might indicate differ, depending on the driver. With outstations on the DNP3 driver, the Protocol Alarm attribute might indicate that any of the following DNP3 IIN Status Bits are set at the outstation:

  • NO_FUNC_CODE_SUPPORT—ClearSCADA has attempted to send a command to the DNP3 outstation using a command that the outstation does not support. For example, ClearSCADA has sent a request to disable unsolicited messages on an outstation that either does not support unsolicited messages or does not support the disabling of unsolicited messages.

If such an error occurs, alter the configuration in ClearSCADA, to disable those features that are not supported by the outstation.

  • OBJECT_UNKNOWN—ClearSCADA’s configuration includes database items that are not recognized or supported by the DNP3 outstation. For example, if the outstation only supports integer point types, a protocol alarm will be raised if ClearSCADA attempts to control a point using an IEEE floating point type.

If such an error occurs, alter the configuration in ClearSCADA, so that it only includes those objects that the outstation supports.

  • PARAMETER_ERROR—A parameter error occurs when a DNP3 outstation receives a request it supports, but that cannot be performed due to the request being incorrectly formed, or using a range that the outstation does not support. For example, if a Binary Output point with Point Number 100 exists in the ClearSCADA database, but does not exist at the outstation, a parameter error would be generated if an attempt was made to control that point.

If a parameter error occurs, alter the configuration either within ClearSCADA or the outstation, so that it corresponds to the features and data ranges that the outstation supports.

Possible States: Displays one of the Standard Alarm States.

Use the Protocol Alarm attribute in conjunction with the IIN Status attribute to ascertain the type of DNP3 IIN bit that is being set. Then check the Events List for any error messages that help to identify the request that is causing the IIN bit to be set. Correct the configuration in ClearSCADA accordingly.


DNP3 Driver Guide - Source (DNP3 Specific Status Display Attributes)

Source

Associated with: Many DNP3-specific database items

The Source attribute is common to many Status Displays. The attribute indicates the location at which the item, for example the point or pulse action, resides.

The information shown varies, depending on the type of item. For many point types and pulse actions on the DNP3 driver, information is displayed in this format:

Master <DNP3 Local Address>: OS <Address>:<Point Type> Point Number <No.>

For binary input and binary output points, information is displayed in this format:

Master <DNP3 Local Address>: OS <Address>:<Point Type> Point Number <No.> Bits <No.>

Examples:

Master 30000:OS 1:AI Point Number 1

for an analog input point residing at Point Number 1 in the outstation. The outstation’s address is 1, and it belongs to the outstation set that has a DNP3 Local Address of 30000.

Master 30000:OS 2:DGP Point Numbers 3 and 4

for a Pulse Action (Trip-Close). The Pulse’s Trip action is assigned to point address 3 and its Close action is assigned to point address 4. It is located on the outstation that has an address of 2, on the outstation set that has a DNP3 Local Address of 30000. As the DNP3 driver supports two types of Pulse Action, they are differentiated by the number of configurable actions and point numbers—one for NULL, and two for Trip-Close.

The Source value displays the type of DNP3 point using these abbreviations:
Abbreviation | Point Type
AI | Analog Input
AO | Analog Output
BI | Binary Input
BO | Binary Output
Counter | Counter
DGP | Pulse Action (NULL) The source value is appended by ‘Point Number #’
DGP | Pulse Action (Trip-Close) The source value is appended by ‘Point Numbers # and #’
FRZ | Frozen Counter
String | String

Also see <DNP3 Status Point Description> Source.


DNP3 Driver Guide - State (DNP3 Specific Status Display Attributes)

State

Associated with: DNP3 master outstations

The State status attribute is common to outstations on many drivers. The attribute indicates the present state of the outstation. With outstations on many drivers, the attribute displays one of a common set of possible states. For a list of these states, see State in the ClearSCADA Guide to Drivers.

With an outstation for which the direct communications connection is only available On Demand, the attribute might display one of the above states, or one of these states:

  • Multidrop Available—ClearSCADA is not currently in communications with the outstation, however multidrop communications via the outstation’s direct channel(s) is available when required.
  • Retry Connection Pending—A previous attempt to communicate with the outstation via its direct channel(s) was unsuccessful. ClearSCADA is currently waiting before trying to open the connection again. The time that the server waits is specified on the Direct tab of the Outstation Form (see Specify Whether the Direct Communications Connection is Always Online or only Available on Demand).


DNP3 Driver Guide - Unsolicited Event Reporting Status (DNP3 Specific Status Display Attributes)

Unsolicited Event Reporting Status

Associated with: DNP3 master outstations

This attribute lists the Event Classes for an outstation. It also indicates whether the outstation can generate unsolicited messages for each of those classes.

Information is displayed in this format:

Class 1: <Status>, Class 2: <Status>, Class 3: <Status>, Virtual Terminal: <Status>

Example:

Class 1: Enabled, Class 2: Disabled, Class 3: Disabled, Virtual Terminal: Enabled

(For an outstation that can generate unsolicited messages for Class 1 and Virtual Terminal events, but not for Class 2 or Class 3 events.)

Whether an outstation can generate unsolicited messages for a Class is initially specified on the Outstation Form (see Enable Unsolicited Message Generation and see Configure Virtual Terminal Support). These settings can be overridden at any time, using the Enable Unsolicited Events and Disable Unsolicited Events pick actions.

Use this attribute in conjunction with the Enable Unsolicited Alarm and Unsolicited Message Statistics attributes to obtain information on the status of unsolicited message generation.


DNP3 Driver Guide - Unsolicited Message Statistics (DNP3 Specific Status Display Attributes)

Unsolicited Message Statistics

Associated with: DNP3 master outstations

This attribute indicates the number of unsolicited messages that the server has received from an outstation since the statistics were last reset.

You can reset the statistics using the Reset Poll Statistics pick action. If the poll statistics have been reset, two sets of Unsolicited Message Statistics attributes are displayed. The first displays the statistics since the last reset of poll statistics; the second displays the statistics between the previous two resets.

Example:

26 unsolicited messages received since 23/May/2004 11:36:49.255

If the statistics have been reset, a second entry will display statistics in the form:

145 unsolicited messages received between 23/Apr/2004 11:35:32.261 and 23/May/2004 11:36:49.255

Use this attribute in conjunction with the Enable Unsolicited Alarm and Unsolicited Event Reporting Status attributes to obtain information on the status of unsolicited message generation.


DNP3 Driver Guide - Numeric List of DNP3 Outstation Device Attributes (DNP3 Specific Status Display Attributes)

Numeric List of DNP3 Outstation Device Attributes

This section applies to DNP3 outstations that support Device Attributes.

Many DNP3 outstations support a combination of the common Device Attributes that are listed below. Some DNP3 outstations also support block(s) of vendor-specific Device Attributes.

Each block of Device Attributes is stored at a separate index location at the outstation. Within the outstation’s Status display, each block of Device Attributes is displayed separately, in index order. Each block is each identified and headed by its corresponding Device Attributes attribute.

Where an outstation supports vendor-specific Device Attributes, you can use the User Attributes Identification attribute to ascertain how many block(s) of vendor-specific Device Attributes exist at the outstation, and the order in which each block is listed.

This section lists the common Device Attributes, a combination of which many DNP3 outstations support. For information on vendor-specific Device Attributes, see the vendor-specific documentation.

Once ClearSCADA has read an outstation’s Device Attributes during a Class 0 Device Attribute poll, a combination of the following attributes are displayed:

  • Device Attributes
  • User Attributes Identification (ID:211)—only displayed for outstations that also support vendor-specific Device Attributes
  • Master-Defined Data Set Prototypes (ID:212)
  • Outstation-Defined Data Set Prototypes (ID:213)
  • Master-Defined Data Sets (ID:214)
  • Outstation-Defined Data Sets (ID:215)
  • Maximum Binary Controls per Request (ID:216)
  • Local Timing Accuracy (ID:217)
  • Duration of Time Accuracy (ID:218)
  • Analog Output Events Supported (ID:219)
  • Maximum Analog Output Index (ID:220)
  • Number of Analog Output Points (ID:221)
  • Binary Output Events Supported (ID:222)
  • Maximum Binary Output Index (ID:223)
  • Number of Binary Output Points (ID:224)
  • Frozen Counter Events Supported (ID:225)
  • Frozen Counters Supported (ID:226)
  • Counter Events Supported (ID:227)
  • Maximum Counter Index (ID:228)
  • Number of Counter Points (ID:229)
  • Frozen Analog Inputs Supported (ID:230)
  • Analog Input Events Supported (ID:231)
  • Maximum Analog Input Index (ID:232)
  • Number of Analog Input Points (ID:233)
  • Double-Bit Binary Input Events Supported (ID:234)
  • Maximum Double-Bit Binary Input Index (ID:235)
  • Number of Double-Bit Binary Input Points (ID:236)
  • Binary Input Events Supported (ID:237)
  • Maximum Binary Input Point Index (ID:238)
  • Number of Binary Input Points (ID:239)
  • Maximum Transmit Fragment Size (ID:240)
  • Maximum Receive Fragment Size (ID:241)
  • Software Version (ID:242)
  • Hardware Version (ID:243)
  • User-Assigned ID Code (ID:246)
  • User-Assigned Name (ID:247)
  • Device Serial Number (ID:248)
  • DNP Subset Level and Conformance (ID:249)
  • Product Name and Model (ID:250)
  • Manufacturer’s Name String (ID:252).


DNP3 Driver Guide - Device Attributes (DNP3 Specific Status Display Attributes)

Device Attributes

Associated with: DNP3 master outstations

A Device Attributes entry is displayed at the top of each separate block of Device Attributes that is included in the Status display. The attribute differentiates each block of attributes that the outstation supports, and indicates the index location of each block in the outstation.

Many DNP3 outstations support a set of common DNP3 Device Attributes. Some outstations additionally support one or more blocks of vendor-specific Device Attributes. For information on the latter attributes, see the vendor-specific documentation.

Example:

Namespace DNP3 (Index 0)
(For the block of common DNP3 Device Attributes)


DNP3 Driver Guide - User Attributes Identification (ID:211) (DNP3 Specific Status Display Attributes)

User Attributes Identification (ID:211)

Associated with: DNP3 master outstations

This attribute is displayed if the outstation supports vendor-specific Device Attributes, in addition to common DNP3 Device Attributes. Each block of Device Attributes is stored at a separate index location at the outstation.

Within the outstation’s Status display, each set of Device Attributes is shown as a separate block in index order, each identified and headed by its corresponding Device Attributes attribute.

Use the User Attributes Identification attribute to ascertain how many block(s) of vendor-specific Device Attributes exist at the outstation. The attribute displays the information in this format:

<Namespace>, <Index Number>

Where more than one block of vendor-specific Device Attributes is supported, entries are separated by a semi-colon.

Example:

Schneider Electric, 1;WITS-DNP3, 2


DNP3 Driver Guide - Master-Defined Data Set Prototypes (ID:212) (DNP3 Specific Status Display Attributes)

Master-Defined Data Set Prototypes (ID:212)

Associated with: DNP3 master outstations

This attribute indicates the number of master-defined data set prototypes that exist at the outstation. (The master may be ClearSCADA or another master station.)

Example:

12

Also see Outstation-Defined Data Set Prototypes (ID:213).


DNP3 Driver Guide - Outstation-Defined Data Set Prototypes (ID:213) (DNP3 Specific Status Display Attributes)

Outstation-Defined Data Set Prototypes (ID:213)

Associated with: DNP3 master outstations

This attribute indicates the number of data set prototypes that exist at the outstation, which were defined by the outstation.

Example:

8

Also see Master-Defined Data Set Prototypes (ID:212).


DNP3 Driver Guide - Master-Defined Data Sets (ID:214) (DNP3 Specific Status Display Attributes)

Master-Defined Data Sets (ID:214)

Associated with: DNP3 master outstations

This attribute indicates the number of master-defined data sets that exist at the outstation. (The master may be ClearSCADA or another master station.)

Example:

4

Also see Outstation-Defined Data Sets (ID:215).


DNP3 Driver Guide - Outstation-Defined Data Sets (ID:215) (DNP3 Specific Status Display Attributes)

Outstation-Defined Data Sets (ID:215)

Associated with: DNP3 master outstations

This attribute indicates the number of data sets that exist at the outstation, which were defined by the outstation.

Example:

4

Also see Master-Defined Data Sets (ID:214).


DNP3 Driver Guide - Maximum Binary Controls per Request (ID:216) (DNP3 Specific Status Display Attributes)

Maximum Binary Controls per Request (ID:216)

Associated with: DNP3 master outstations

This attribute indicates the maximum number of Binary Controls that the outstation can handle, per control request. (These are the controls from object group 12.)

Example:

1


DNP3 Driver Guide - Local Timing Accuracy (ID:217) (DNP3 Specific Status Display Attributes)

Local Timing Accuracy (ID:217)

Associated with: DNP3 master outstations

This attribute indicates the reported local timing accuracy of the outstation, in microseconds. The value indicates the maximum time difference that could occur between the outstation detecting that an event has occurred, and the time stamping of that event by the outstation.

Example:

16000


DNP3 Driver Guide - Duration of Time Accuracy (ID:218) (DNP3 Specific Status Display Attributes)

Duration of Time Accuracy (ID:218)

Associated with: DNP3 master outstations

This attribute indicates the amount of time, in seconds, that the outstation should maintain its time accuracy, following a time synchronization with its master (ClearSCADA). Synchronization is undertaken by setting the outstation’s clock (see Configure the Set Outstation Clock Properties).

A value of zero indicates that the outstation’s clock is set by an external source, such as GPS. (Such a source would typically not require ClearSCADA to set the outstation’s clock.)

Example:

86,400
(for a time accuracy of one day, in seconds)


DNP3 Driver Guide - Analog Output Events Supported (ID:219) (DNP3 Specific Status Display Attributes)

Analog Output Events Supported (ID:219)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports Analog Output Events.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Maximum Analog Output Index (ID:220) (DNP3 Specific Status Display Attributes)

Maximum Analog Output Index (ID:220)

Associated with: DNP3 master outstations

This attribute indicates the maximum Analog Output Index that exists at the outstation.

Example:

14

Also see Number of Analog Output Points (ID:221).


DNP3 Driver Guide - Number of Analog Output Points (ID:221) (DNP3 Specific Status Display Attributes)

Number of Analog Output Points (ID:221)

Associated with: DNP3 master outstations

This attribute indicates the number of Analog Output points that presently exist at the outstation.

Example:

1

Also see Maximum Analog Output Index (ID:220).


DNP3 Driver Guide - Binary Output Events Supported (ID:222) (DNP3 Specific Status Display Attributes)

Binary Output Events Supported (ID:222)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports Binary Output Events.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Maximum Binary Output Index (ID:223) (DNP3 Specific Status Display Attributes)

Maximum Binary Output Index (ID:223)

Associated with: DNP3 master outstations

This attribute indicates the maximum Binary Output Index that the outstation supports.

Example:

7

Also see Number of Binary Output Points (ID:224).


DNP3 Driver Guide - Number of Binary Output Points (ID:224) (DNP3 Specific Status Display Attributes)

Number of Binary Output Points (ID:224)

Associated with: DNP3 master outstations

This attribute indicates the number of Binary Output points that exist at the outstation.

Example:

8

Also see Maximum Binary Output Index (ID:223).


DNP3 Driver Guide - Frozen Counter Events Supported (ID:225) (DNP3 Specific Status Display Attributes)

Frozen Counter Events Supported (ID:225)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports Frozen Counter Events.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Frozen Counters Supported (ID:226) (DNP3 Specific Status Display Attributes)

Frozen Counters Supported (ID:226)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports Frozen Counters.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Counter Events Supported (ID:227) (DNP3 Specific Status Display Attributes)

Counter Events Supported (ID:227)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports Counter Events.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Maximum Counter Index (ID:228) (DNP3 Specific Status Display Attributes)

Maximum Counter Index (ID:228)

Associated with: DNP3 master outstations

This attribute indicates the maximum Counter Index that exists at the outstation.

Example:

3

Also see Number of Counter Points (ID:229).


DNP3 Driver Guide - Number of Counter Points (ID:229) (DNP3 Specific Status Display Attributes)

Number of Counter Points (ID:229)

Associated with: DNP3 master outstations

This attribute indicates the number of Counter points that exist at the outstation.

Example:

2

Also see Maximum Counter Index (ID:228).


DNP3 Driver Guide - Frozen Analog Inputs Supported (ID:230) (DNP3 Specific Status Display Attributes)

Frozen Analog Inputs Supported (ID:230)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports Frozen Analog Input points.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Analog Input Events Supported (ID:231) (DNP3 Specific Status Display Attributes)

Analog Input Events Supported (ID:231)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports Analog Input Events.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Maximum Analog Input Index (ID:232) (DNP3 Specific Status Display Attributes)

Maximum Analog Input Index (ID:232)

Associated with: DNP3 master outstations

This attribute indicates the maximum Analog Input Index that exists at the outstation.

Example:

210

Also see Number of Analog Input Points (ID:233).


DNP3 Driver Guide - Number of Analog Input Points (ID:233) (DNP3 Specific Status Display Attributes)

Number of Analog Input Points (ID:233)

Associated with: DNP3 master outstations

This attribute indicates the number of Analog Input points that presently exist at the outstation.

Example:

2

Also see Maximum Analog Input Index (ID:232).


DNP3 Driver Guide - Double-Bit Binary Input Events Supported (ID:234) (DNP3 Specific Status Display Attributes)

Double-Bit Binary Input Events Supported (ID:234)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports double-bit Binary Input Events.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Maximum Double-Bit Binary Input Index (ID:235) (DNP3 Specific Status Display Attributes)

Maximum Double-Bit Binary Input Index (ID:235)

Associated with: DNP3 master outstations

This attribute indicates the maximum double-bit Binary Input Index that exists at the outstation.

Example:

4

Also see Number of Double-Bit Binary Input Points (ID:236).


DNP3 Driver Guide - Number of Double-Bit Binary Input Points (ID:236) (DNP3 Specific Status Display Attributes)

Number of Double-Bit Binary Input Points (ID:236)

Associated with: DNP3 master outstations

This attribute indicates the number of double-bit Binary Input points that exist at the outstation.

(Single-Bit Binary Inputs are recorded separately—see Number of Binary Input Points (ID:239).)

Example:

1

Also see Maximum Double-Bit Binary Input Index (ID:235).


DNP3 Driver Guide - Binary Input Events Supported (ID:237) (DNP3 Specific Status Display Attributes)

Binary Input Events Supported (ID:237)

Associated with: DNP3 master outstations

This attribute indicates whether the outstation supports Binary Input Events.

Possible States: 0 (not supported), 1 (supported).


DNP3 Driver Guide - Maximum Binary Input Point Index (ID:238) (DNP3 Specific Status Display Attributes)

Maximum Binary Input Point Index (ID:238)

Associated with: DNP3 master outstations

This attribute indicates the maximum Binary Input Point Index that exists at the outstation.

Example:

144

Also see Number of Binary Input Points (ID:239).


DNP3 Driver Guide - Number of Binary Input Points (ID:239) (DNP3 Specific Status Display Attributes)

Number of Binary Input Points (ID:239)

Associated with: DNP3 master outstations

This attribute indicates the number of single-bit Binary Input points that exist at the outstation.

(Double-Bit Binary Inputs are recorded separately—see Number of Double-Bit Binary Input Points (ID:236).)

Example:

3

Also see Maximum Binary Input Point Index (ID:238).


DNP3 Driver Guide - Maximum Transmit Fragment Size (ID:240) (DNP3 Specific Status Display Attributes)

Maximum Transmit Fragment Size (ID:240)

Associated with: DNP3 master outstations

This attribute indicates the maximum fragment size of any messages that the outstation transmits. The size is in bytes. Messages that are larger than this size are split into multiple fragments.

Example:

2048


DNP3 Driver Guide - Maximum Receive Fragment Size (ID:241) (DNP3 Specific Status Display Attributes)

Maximum Receive Fragment Size (ID:241)

Associated with: DNP3 master outstations

This attribute indicates the maximum fragment size of any messages that the outstation receives. The size is in bytes. Messages that are larger than this size are split into multiple fragments.

Example:

2048


DNP3 Driver Guide - Software Version (ID:242) (DNP3 Specific Status Display Attributes)

Software Version (ID:242)

Associated with: DNP3 master outstations

This attribute indicates the version of software that is running at the outstation.

Example:

5.3.006


DNP3 Driver Guide - Hardware Version (ID:243) (DNP3 Specific Status Display Attributes)

Hardware Version (ID:243)

Associated with: DNP3 master outstations

This attribute indicates the version of outstation hardware that is being used on this device.

Example:

2005-003


DNP3 Driver Guide - User-Assigned ID Code (ID:246) (DNP3 Specific Status Display Attributes)

User-Assigned ID Code (ID:246)

Associated with: DNP3 master outstations

This attribute displays the user-assigned ID code or number of the outstation. The way in which this information is set at the outstation varies, depending on the vendor.

Example:

528

Also see User-Assigned Name (ID:247).


DNP3 Driver Guide - User-Assigned Name (ID:247) (DNP3 Specific Status Display Attributes)

User-Assigned Name (ID:247)

Associated with: DNP3 master outstations

This attribute displays the user-assigned name of the outstation. The way in which this information is set at the outstation varies, depending on the vendor.

Example:

NW RTU 4

Also see User-Assigned ID Code (ID:246).


DNP3 Driver Guide - Device Serial Number (ID:248) (DNP3 Specific Status Display Attributes)

Device Serial Number (ID:248)

Associated with: DNP3 master outstations

This attribute indicates the serial number of the outstation.

Example:

2005-06-12:2031


DNP3 Driver Guide - DNP Subset Level and Conformance (ID:249) (DNP3 Specific Status Display Attributes)

DNP Subset Level and Conformance (ID:249)

Associated with: DNP3 master outstations

This attribute indicates the DNP3 subset level and the DNP3 Test Procedure version that applies to the outstation. The information is displayed in this format:

<DNP3 Subset Level>:<DNP3 Test Procedure Version>

Example:

2:2005


DNP3 Driver Guide - Product Name and Model (ID:250) (DNP3 Specific Status Display Attributes)

Product Name and Model (ID:250)

Associated with: DNP3 master outstations

This attribute indicates the product name and model of the DNP3 device that this outstation represents.

Example:

PDS Magna

Also see Manufacturer’s Name String (ID:252).


DNP3 Driver Guide - Manufacturer's Name String (ID:252) (DNP3 Specific Status Display Attributes)

Manufacturer’s Name String (ID:252)

Associated with: DNP3 master outstations

This attribute displays the device manufacturer’s name, as retrieved from the associated string in the outstation.

Example:

Schneider Electric


DNP3 Driver Guide - DNP3 Specific Colors

DNP3 Specific Colors

Each ClearSCADA system is supplied with a set of default system colors. These colors comprise both ‘core system’ and driver-specific colors. Each color is used to indicate the state of an item in the database. The color is used on various ClearSCADA displays to indicate that the item is in a particular state. This section covers the system colors that are specific to the DNP3 driver. ClearSCADA uses DNP3 driver-specific colors to indicate:

  • Comms Lost
  • Point Offline
  • Point Restarting.

For further driver-specific information about the Historic Lists on which the above colors might be displayed, see DNP3 Specific Status Descriptions on Historic Lists.

The ‘core’ states and corresponding system colors take priority over the DNP3-specific states (see Priority of DNP3 Point Foreground Colors).

For information on core system colors, see Alphabetical List of Core System Colors in the ClearSCADA Guide to Core Configuration.

NOTE: You can change a default system color by altering its color in the color palette. If you decide to do this, you should set the new color so that it is different to the other colors on your system, otherwise users may confuse it with another color. For information on configuring system colors, see Use the Color Palette to Define a Custom System Color in the ClearSCADA Guide to Core Configuration.


DNP3 Driver Guide - Comms Lost (DNP3 Specific Colors)

Comms Lost

Associated with: Historic List entries for DNP3 Points that have Historic enabled.

The Comms Lost status is indicated by a light blue foreground color, by default.

This color is used in the Historic List to indicate that communications have been lost with the DNP3 outstation on which the point is located.

With some types of DNP3 outstation, ClearSCADA can detect whether the connection between that DNP3 outstation and any remote device to which it is connected has been lost. In such a situation, only the points on the remote device are assigned the Comms Lost status.


DNP3 Driver Guide - Point Offline (DNP3 Specific Colors)

Point Offline

Associated with: Historic List entries for DNP3 Points that have Historic enabled.

The Point Offline status is indicated by a light blue foreground color, by default.

This color is used in the Historic List to indicate that the DNP3 point is offline.


DNP3 Driver Guide - Point Restarting (DNP3 Specific Colors)

Point Restarting

Associated with: Historic List entries for DNP3 Points that have Historic enabled.

The Point Restarting status is indicated by a light blue foreground color, by default.

This color is used in the Historic List to indicate that a DNP3 point value may no longer be accurate. The color indicates that no entries have been logged for a point since communications restarted with the DNP3 outstation on which the point is located.


DNP3 Driver Guide - Priority of DNP3 Point Foreground Colors (DNP3 Specific Colors)

Priority of DNP3 Point Foreground Colors

Each system color is assigned a level of importance, depending on the state that it represents. ClearSCADA uses the hierarchy to ascertain the color that it assigns to each database item.

A DNP3 point that has Historic enabled might be in one or more ‘core’ or DNP3-specific point state(s). The ‘core’ point states with which point foreground colors are associated take precedence over DNP-specific point states and colors.

This chart indicates which DNP3-specific status and corresponding system color takes precedence over another, should no ‘core’ point status apply:

Further Information

Core Point Foreground Color Chart: see Priority of Point Foreground Colors in the ClearSCADA Guide to Core Configuration.

DNP3 Specific Colors.


DNP3 Driver Guide - System Analysis

System Analysis

This section is designed to be used by system administrators and high-level engineers when assessing the state of the ClearSCADA system. It provides information on the statistical and diagnostic information that is available and applies specifically to the DNP3 driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

During system analysis, you might need to:

  • Adjust the Configuration of any DNP3 Points that Cause a High Load
  • Use Driver Logging Options that are Specific to the DNP3 Driver.

Additionally, if an outstation is not communicating with the server when it should be, see Troubleshooting in the ClearSCADA Guide to Advanced Drivers.

NOTE: When troubleshooting on a ClearSCADA system, look for error messages on the Events List. The messages may help to identify the cause of any unexpected system behavior.


DNP3 Driver Guide - Adjust the Configuration of any DNP3 Points that Cause a High Load (System Analysis)

Adjust the Configuration of any DNP3 Points that Cause a High Load

Inadequate client performance can cause your ClearSCADA system to be slow (see Diagnose Client Performance Problems in the ClearSCADA Guide to the Server Status Tool). One of the causes of inadequate performance is high load on the server.

You can use the statistics that are displayed in Lists and Status displays to identify any DNP3 outstations that are causing a high loading on the ClearSCADA system.

For those outstations that have a high load, use the Points List to identify the point(s) that are causing the high load.

High load is typically caused by a point updating at too frequent a rate.

Where a point on a DNP3 outstation is causing a high load:

  1. If the point is on an outstation that has a direct connection to the server, check the Scan Group (Confidence Poll) that the point is using (see Configure General Point Properties). If this is causing the server to update the current point value at too frequent a rate, you might need to:
  • Specify a different Scan Group.

or:

  • Specify a less frequent scan rate for the Scan Group (see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers).
  2. If the point is an Analog point:
  1. Enable the Significant Change feature (see Significant Change Properties).
  2. If Significant Change enabled, you might need to increase the Significant Change deadband—the amount by which the point value has to change for the value to be logged by the outstation (see Significant Change Properties).
  3. If none of the above checks and configuration changes have cleared the high load caused by the point, check:
  1. The configuration at the outstation.
  2. The outstation hardware for any faults.
  3. The plant for any faults.
  4. The instrumentation for any faults.


DNP3 Driver Guide - Driver Logging Options that are Specific to the DNP3 Driver (System Analysis)

Driver Logging Options that are Specific to the DNP3 Driver

NOTE: If your system is running a DNP3 Extension Driver, refer to the relevant extension driver guide for any DNP3-specific logging options that are not mentioned below.

Driver logging is useful for investigating driver problems, or potential problems. It provides useful diagnostic information for specific aspects of the system. For instance, the Points logging option provides diagnostic information for the points on a particular driver.

Should you need to contact Schneider Electric for assistance with resolving a problem on your system, you might be asked to provide Log files to help in assessing the cause of the problem. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

This section explains the driver logging options that are specific to the DNP3 Driver.

Those driver logging options that are typically required for investigating driver problems are enabled by default. We suggest that the options are left at this default unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

For information on log files and defining the log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration.

For information on the driver logging options that are available for many advanced drivers, see Common Advanced Driver Log File Options in the ClearSCADA Guide to Advanced Drivers.

These driver logging options are specific to the DNP3 Driver:

  • Application States—Logs information relating to the state of the current DNP3 Application Layer.
  • Data Link States—Logs information relating to the state of the current DNP3 Data Link Layer.
  • Slave Event Generation—Logs information relating to the generation of events by a DNP3 Slave outstation.
  • Slave Controls—Logs information relating to control issues on a DNP3 Slave outstation.
  • Security (Authentication)—Logs information relating to DNP3 Secure Authentication.


DNP3 SCADAPack Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


DNP3 SCADAPack Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


DNP3 SCADAPack Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


DNP3 SCADAPack Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


DNP3 SCADAPack Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


DNP3 SCADAPack Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s DNP3 SCADAPack E-Series driver. The driver is a DNP3 extension driver. The driver provides additional functionality to enable ClearSCADA to communicate with SCADAPack E-Series and 386 eNET outstations, using the DNP3 protocol.

For a list of the types of outstation with which ClearSCADA can communicate using the DNP3 SCADAPack E-Series driver, see Specify the Outstation Type.

For more details on the information included in this guide, see Introduction to the DNP3 SCADAPack E-Series Driver.


DNP3 SCADAPack Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring DNP3 SCADAPack E-Series items and features in the ClearSCADA database.

The guide also contains information for:

  • Operators and engineers who use the DNP3 SCADAPack E-Series driver to monitor and control plant
  • Maintenance engineers.


DNP3 SCADAPack Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


DNP3 SCADAPack Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to the DNP3 Driver

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Alarms

ClearSCADA Guide to Lists

ClearSCADA Guide to Trends

ClearSCADA Guide to the Database

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

SCADAPack ER Hardware User and Reference Manual

SCADAPack E-Series Communication Interfaces Technical User and Reference Manual

SCADAPack E-Series Configuration File Format User and Reference Manual

SCADAPack E-Series Configuration Technical User and Reference Manual

SCADAPack E-Series Configurator User Manual

SCADAPack E-Series Data Concentrator Technical User Reference Manual

SCADAPack E-Series DNP3 Technical User and Reference Manual

SCADAPack E-Series Firmware Update User Manual

SCADAPack E-Series ISaGRAF Function Block User and Reference Manual

SCADAPack E-Series ISaGRAF Technical User and Reference Manual

SCADAPack E-Series Modbus Communication Interfaces

SCADAPack E-Series Operation Reference Manual

SCADAPack E-Series Profiler User and Reference Manual

SCADAPack E-Series Remote I/O Technical Reference Manual

SCADAPack E-Series SCADAPack ES Hardware User and Reference Manual

SCADAPack E-Series Security Technical User and Reference Manual

SCADAPack E-Series TCP/IP Technical User and Reference Manual

SCADAPack E-Series Trend Sampler Technical User and Reference Manual

SCADAPack ES Hardware User and Reference Manual

PDS v7 Series Telemetry X.29 RTU Communication Interface Manual.


DNP3 SCADAPack Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


DNP3 SCADAPack Driver Guide - Introduction to the DNP3 SCADAPack E-Series Driver

Introduction to the DNP3 SCADAPack E-Series Driver

The ClearSCADA DNP3 SCADAPack E-Series driver is a DNP3 extension driver. It provides additional functionality to enable ClearSCADA to communicate specifically with SCADAPack E-Series and 386 eNET outstations, using the DNP3 protocol. In order to communicate with such outstations, both the DNP3 driver and the DNP3 SCADAPack E-Series extension driver need to be running on the ClearSCADA system (see Confirm that the DNP3 and SCADAPack E-Series Server Components are Installed).

SCADAPack E-Series and 386 eNET outstations are DNP3 compliant devices, with enhanced feature sets that provide additional functionality beyond the basic DNP3 requirements. The DNP3 SCADAPack E-Series driver enables ClearSCADA to support this enhanced feature set and provides the capability to configure those features in ClearSCADA.

The ClearSCADA DNP3 driver, which is also designed to the DNP3 standard, is capable of communicating with other devices that are compliant with the DNP3 standard (see Which Driver?).

The DNP3 SCADAPack E-Series driver provides database items that allow ClearSCADA to generate and download configurations to SCADAPack E-Series outstations for the following SCADAPack features:

  • Ports—serial and ethernet
  • TCP/IP—port settings and services
  • DNP3—events, object types, data link layer, application layer, and so on
  • Routing—DNP3 and TCP/IP
  • Point properties
  • Point data trend sampling
  • Remote I/O.

For further information, see Features of a SCADAPack E-Series Outstation.

NOTE: Throughout this guide, unless mentioning features that are specific to particular model(s) of outstation, the term ‘SCADAPack E-Series outstation’ is used to refer to any SCADAPack E-Series or eNET outstation with which ClearSCADA can communicate using the DNP3 protocol.

As ClearSCADA uses DNP3 as the communications protocol to write configuration information to SCADAPack E-Series outstations, it is recommended that you read the ClearSCADA Guide to the DNP3 Driver before reading this driver guide. Much of the information covered in the ClearSCADA Guide to the DNP3 Driver is assumed knowledge and needs to be followed in conjunction with information in this driver guide. It is also advisable that you have access to the SCADAPack E-Series product documentation when reading this guide.

This ClearSCADA Guide to the DNP3 SCADAPack E-Series Driver explains how to configure SCADAPack E-Series specific features and items within the ClearSCADA database. For further information, see:

  • Configuring DNP3 SCADAPack E-Series Devices in ClearSCADA
  • Supported Communications Setups
  • Scanning DNP3 SCADAPack E-Series Outstations
  • Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files
  • Using ClearSCADA to Import and Download SCADAPack Security Configuration Files
  • Configuring DNP3 SCADAPack Tables
  • Working with DNP3 SCADAPack E-Series Outstation Configuration Files.

(If you are unfamiliar with configuring SCADAPack E-Series devices in ClearSCADA, also consider following the Quick Start Tutorial.)

This guide also explains SCADAPack E-Series specific features that are of interest to operators, such as:

  • DNP3 SCADAPack Specific Alarm and Event Categories
  • DNP3 SCADAPack Specific Actions and Methods

and SCADAPack E-Series specific aspects that are of interest to system administrators and engineers when investigating unexpected behavior relating to the DNP3 SCADAPack E-Series driver:

  • Configuring ClearSCADA to Retrieve DNP3 SCADAPack Status Information
  • DNP3 SCADAPack Specific Status Display Attributes
  • DNP3 SCADAPack Specific Colors
  • DNP3 SCADAPack Specific Driver Log File Options.


DNP3 SCADAPack Driver Guide - Which Driver? (Introduction to the DNP3 SCADAPack E-Series Driver)

Which Driver?

ClearSCADA can communicate with SCADAPack outstations using one of several drivers. The driver that you need to use depends on the type of SCADAPack device(s) with which ClearSCADA is to communicate.

If ClearSCADA is to communicate with SCADAPack E-Series outstations, or 386 eNET outstations, your system needs to run the DNP3 driver, along with the DNP3 SCADAPack E-Series extension driver. Use these drivers to enable ClearSCADA to communicate with these SCADAPack outstations using the DNP3 protocol; with the DNP3 SCADAPack E-Series extension driver providing support for extended SCADAPack DNP3 functionality. Refer to the rest of this driver guide and the ClearSCADA Guide to the DNP3 Driver for information on configuring your database accordingly. (586 eNET outstations are now known as SCADAPack ES outstations and Magna eNET outstations are now known as SCADAPack ER outstations. Both types of outstation are models in the SCADAPack E-Series range of outstations.)

If ClearSCADA is to communicate with other (non E-Series) SCADAPack outstations, your system needs to run the SCADAPack Modbus driver, to enable ClearSCADA to communicate with those devices using the Modbus protocol. For more information, see the ClearSCADA Guide to the SCADAPack Modbus Driver. (SCADAPack E-Series outstations also support the Modbus protocol, however the E-Series Modbus support is not compatible with ClearSCADA’s SCADAPack Modbus database items. For ClearSCADA to communicate with SCADAPack E-Series outstations using the Modbus protocol, use either the ‘generic’ Modbus database items with ClearSCADA’s SCADAPack Modbus driver, or use the simple Modbus driver.)

For ClearSCADA to communicate with other (non E-Series) SCADAPack outstations using the DNP3 protocol, use the ‘standard’ DNP3 database items provided with ClearSCADA’s DNP3 driver (as opposed to DNP3 SCADAPack E-Series items). The DNP3 support provided by other (non E-Series) SCADAPack outstations is not compatible with ClearSCADA’s DNP3 SCADAPack E-Series range of database items. For information on ‘standard’ DNP3 items, see the ClearSCADA Guide to the DNP3 Driver.


DNP3 SCADAPack Driver Guide - Features of a SCADAPack E-Series Outstation (Introduction to the DNP3 SCADAPack E-Series Driver)

Features of a SCADAPack E-Series Outstation

Schneider Electric’s SCADAPack E-Series range of outstations provide several advanced features that are not typically found in other DNP3 outstations. In addition to the DNP3 protocol, SCADAPack E-Series outstations support:

  • Configuration download from the SCADA master (ClearSCADA)
  • Modbus (Serial and TCP/IP)
  • Communication protocols, including DF1, IDEC, ADS Flow, IEC 60870-5-103 master, IEC 60870-5-101 slave, and IEC 60870-5-104 slave
  • DNP3 routing
  • TCP/IP routing
  • DNP3 virtual terminal to physical serial ports
  • TCP service ports to physical serial ports
  • BOOTP Server
  • ISaGRAF 61131-3 Logic
  • Remote command execution via DNP3
  • Point data trend sampling.

You use a DNP3 file transfer to download the configuration file for these features, from the SCADA Master (ClearSCADA) to a SCADAPack E-Series outstation. If you create your database using the DNP3 SCADAPack E-Series database items (see Configuring DNP3 SCADAPack E-Series Devices in ClearSCADA), you can use ClearSCADA to generate the SCADAPack configuration file according to the settings that you specify for those database items. By using the Configuration Setup window in ClearSCADA, you can specify any additional files that contain configuration information that is not created by ClearSCADA (see Working with DNP3 SCADAPack E-Series Outstation Configuration Files).

The following sections illustrate a few examples of SCADAPack E-Series outstation features, including:

  • DNP3 Routing
  • TCP/IP Routing
  • TCP Service Ports (Virtual Serial Ports).

Also see Supported Communications Setups.

Be aware that some of the functions on a SCADAPack E-Series outstation are only activated if an outstation is licensed to provide those features. For instance, the appropriate licenses must be installed to activate Multi Master or Data Concentrator functionality.

You can combine various features illustrated in the examples mentioned above in a single configuration. For example, you can use a SCADAPack E-Series outstation to route DNP3 frames over a radio network and as a TCP/IP router linking two TCP/IP networks.


DNP3 SCADAPack Driver Guide - DNP3 Routing (Introduction to the DNP3 SCADAPack E-Series Driver)

DNP3 Routing

You can configure a SCADAPack E-Series outstation to route DNP3 frames between a SCADA Master (ClearSCADA) and other DNP3 devices.

A typical scenario would be to use a SCADAPack E-Series outstation to route DNP3 frames between ClearSCADA and remote outstations via a radio network, as illustrated below.

Further Information

Route DNP3 Frames Using a DNP Route Table.

SCADAPack E-Series Data Concentrators and Remote Outstations.


DNP3 SCADAPack Driver Guide - TCP/IP Routing (Introduction to the DNP3 SCADAPack E-Series Driver)

TCP/IP Routing

You can configure a SCADAPack E-Series outstation to route TCP/IP packets between multiple networks.

The outstation is capable of routing between Ethernet and Serial (PPP) on multiple interfaces.

Further Information

Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host.

Enable TCP/IP Services.

Configure TCP Service Port Properties.


DNP3 SCADAPack Driver Guide - TCP Service Ports (Virtual Serial Ports) (Introduction to the DNP3 SCADAPack E-Series Driver)

TCP Service Ports (Virtual Serial Ports)

A SCADAPack E-Series outstation is capable of providing serial data connections via TCP/IP, using TCP Service Ports. This feature allows ClearSCADA drivers to communicate with serial devices (for example Modbus PLCs) without needing a physical serial port on the ClearSCADA server. This is useful if the PLC is physically located too far away to use a direct serial connection.

The diagram below illustrates the ClearSCADA Modbus driver communicating with a serial Modbus device, using a SCADAPack E-Series outstation as a TCP terminal server.

With this scenario, the DNP3 driver and DNP3 SCADAPack E-Series extension driver could be used to retrieve the I/O monitoring data. They could also be used to send configuration to the SCADAPack E-Series outstation from ClearSCADA.

Further Information

Configure TCP Service Port Properties.

Using ClearSCADA’s Modbus driver to communicate with SCADAPack E-Series outstations: see Which Driver?.

Download Configuration.


DNP3 SCADAPack Driver Guide - Confirm that the DNP3 and SCADAPack E-Series Server Components are Installed (Introduction to the DNP3 SCADAPack E-Series Driver)

Confirm that the DNP3 and SCADAPack E-Series Server Components are Installed

In order for ClearSCADA to communicate with SCADAPack E-Series outstations using the DNP3 protocol, both the DNP3 and SCADAPack E-Series driver components have to be installed on each of the servers on your system (including any permanent standby servers).

Before you add any SCADAPack E-Series items to ClearSCADA, you need to make sure that both of these components are installed on the ClearSCADA servers on your system.

Use the Add/Remove Programs function in the Windows® Control Panel to confirm that both components are installed. The components are located in the Server group, as shown below.

Ensure that the symbols to the left of the text DNP3 and SCADAPack E-Series do not have a X on them. (You may need to expand the DNP3 branch in order to display the SCADAPack E-Series component.)


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack E-Series Devices in ClearSCADA (Introduction to the DNP3 SCADAPack E-Series Driver)

Configuring DNP3 SCADAPack E-Series Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, control devices and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the DNP3 SCADAPack E-Series devices on your system.

In order to represent any SCADAPack E-Series devices, the DNP3 Driver (including the SCADAPack E-Series component) have to be installed and running on the ClearSCADA servers on your system (see Confirm that the DNP3 and SCADAPack E-Series Server Components are Installed).

When you configure DNP3 SCADAPack E-Series items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant SCADAPack devices on your system. Some settings are either fixed (incorporated into the design of the SCADAPack E-Series outstation) or are configured by an engineer. You need to have access to, or an understanding of, the settings of the SCADAPack devices on your system before you can configure the DNP3 SCADAPack E-Series database items successfully.

For instance, you need to know the function of each port on each SCADAPack E-Series outstation on your system.

You also need to be aware of which optional features are required for each DNP3 SCADAPack E-Series item. The features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with DNP3 SCADAPack E-Series database items, including Lists, Actions, and Mimics. For actions that are specific to the DNP3 SCADAPack E-Series driver, see DNP3 SCADAPack Specific Actions and Methods. For further information on actions and details on Lists and Mimics, see the core documentation.

For each SCADAPack E-Series device with which ClearSCADA is to communicate using the DNP3 protocol, you need to configure:

  1. DNP3 Channel(s) to define the communication connections between ClearSCADA and the DNP3 SCADAPack E-Series outstations (see Configuring a DNP3 Channel in the ClearSCADA Guide to the DNP3 Driver).
  2. A DNP3 Outstation Set to define each group of DNP3 SCADAPack E-Series outstations that share the same communications media (see Configuring a DNP3 Outstation Set in the ClearSCADA Guide to the DNP3 Driver).
  3. A DNP3 SCADAPack E-Series Outstation to represent each SCADAPack E-Series outstation with which ClearSCADA communicates (see Configuring DNP3 SCADAPack E-Series Outstations and see SCADAPack E-Series Data Concentrators and Remote Outstations).

Unlike some types of DNP3 outstation, DNP3 SCADAPack E-Series Outstations do support downloading of configuration from ClearSCADA to the outstation.

You may initially need to use another application, such as the E-Series Configurator, to set up each outstation sufficiently for ClearSCADA to communicate with that outstation (see Notes on Configuring SCADAPack E-Series Outstations). Thereafter, you can download the outstation’s configuration from ClearSCADA to the SCADAPack outstation, using the Download Configuration pick action.

NOTE: Before configuring SCADAPack E-Series outstations using ClearSCADA, ensure that you are aware of the information listed in Notes on Configuring SCADAPack E-Series Outstations. Also see Supported Communications Setups.

  4. If applicable, a DNP3 SCADAPack IO item for each I/O expansion card or module that is connected to a SCADAPack E-Series outstation, in order to provide additional I/O for that outstation (see SCADAPack E-Series Outstations that have Separate or Additional I/O Cards or Modules and see Configuring I/O Expansion Cards and Modules).
  5. If required, a DNP3 SCADAPack Firmware Image item for each different version of operating system firmware that ClearSCADA is to update in the SCADAPack E-Series outstations (see Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files).
  6. If required, a DNP3 SCADAPack Security Configuration item for each different security configuration file that ClearSCADA is to download to the SCADAPack E-Series outstations (see Import and Download SCADAPack Security Configuration Files).
  7. If required, DNP3 SCADAPack Profiles to change point values or limits at different times of the day or week (see Configuring DNP3 SCADAPack Profiles).
  8. A DNP3 SCADAPack Point to represent each analog or binary measuring instrument or control device that is connected to each SCADAPack E-Series outstation (see Points Used on DNP3 SCADAPack E-Series Outstations).
  9. If the outstation is to sample point data, a DNP3 SCADAPack E-Series Trend item for each data stream that the outstation is to sample on a point (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality).

If the outstation is only to sample point data under certain circumstances, ensure that you also configure any DNP3 SCADAPack Binary Input point(s) that are to be used as Trigger Point(s) on the Trend items.

  10. If required, a DNP3 SCADAPack 32-Bit Point Modbus Map (see Configuring DNP3 SCADAPack 32-bit Point Modbus Maps).

Such a database item is only required if:

  • A SCADAPack E-Series outstation is a Modbus Slave, connected to a Modbus Master

and:

  • The Modbus Master reads or writes to one or more points that are configured as 32-bit points in the SCADAPack E-Series outstation.
  11. A DNP3 SCADAPack Pulse Action (where needed) to carry out control(s) on plant for specified periods of time (see Configuring DNP3 SCADAPack Pulse Actions).
  12. If required, a DNP3 SCADAPack Status Information item for each type of status information that ClearSCADA is to retrieve from a SCADAPack E-Series outstation (see Configuring ClearSCADA to Retrieve DNP3 SCADAPack Status Information).

If the DNP3 master driver is used for routing comms, using a Virtual Terminal, you also need to Configure a DNP3 VT Service Port Master and Configure a DNP3 Virtual Terminal. The Virtual Terminal Number on the DNP3 Virtual Terminal Form has to correspond to the Port number being used on the SCADAPack E-Series outstation. The port’s Function, specified on the Outstation Form’s Outstation Type tab, has to be set to DNP VT Service. For further information, see Configuring DNP3 Virtual Terminals in the ClearSCADA Guide to the DNP3 Driver, and see Configure the Properties of the Individual Ports.

Further Information

Scanning DNP3 SCADAPack E-Series Outstations.

For information on configuring DNP3—as opposed to DNP3 SCADAPack E-Series—points, see the ClearSCADA Guide to the DNP3 Driver.


DNP3 SCADAPack Driver Guide - Supported Communications Setups (Introduction to the DNP3 SCADAPack E-Series Driver)

Supported Communications Setups

ClearSCADA can communicate with SCADAPack E-Series outstations via PSTN or permanent communications, such as cable, radio, or network (see Outstation Types and Communications Set-ups in the ClearSCADA Guide to Advanced Drivers), including with:

  • SCADAPack E-Series Outstations that have Separate or Additional I/O Cards or Modules
  • SCADAPack E-Series Data Concentrators and Remote Outstations
  • SCADAPack E-Series Outstations that Communicate with more than one DNP3 Master.


DNP3 SCADAPack Driver Guide - SCADAPack E-Series Outstations that have Separate or Additional I/O Cards or Modules (Introduction to the DNP3 SCADAPack E-Series Driver)

SCADAPack E-Series Outstations that have Separate or Additional I/O Cards or Modules

SCADAPack ER-P600 and SCADAPack ER-P620 outstations do not have on-board I/O. Instead, separate cards or modules are used to provide the required I/O (input points and/or output points).

SCADAPack 330E, 334E, 350E and 357E outstations do have basic on-board I/O. However, unlike other SCADAPack E-Series outstations, that I/O is not automatically assigned any DNP3 Point Numbers. As such, in the ClearSCADA database you need to configure a DNP3 SCADAPack 5000 Series IO item for each on-board I/O card on a SCADAPack 330E, 334E, 350E or 357E outstation.

With any type of SCADAPack E-Series outstation, regardless of whether that outstation has on-board I/O, the number of I/O (points) can be increased by adding additional module(s) or card(s) to that outstation.

Example:

For any of the above scenarios, in ClearSCADA you need to configure a DNP3 SCADAPack E-Series Outstation of the appropriate type (Direct, PSTN, or Shared) for each SCADAPack E-Series outstation, along with the appropriate DNP3 Channel(s) and DNP3 Outstation Set(s).

You also need to configure a DNP3 SCADAPack IO item of the appropriate type for each separate I/O card or module that is connected to a SCADAPack E-Series outstation.

When a SCADAPack ES outstation is used as an I/O expansion module, that outstation performs as a ‘dumb’ outstation in that it provides facilities for monitoring and controlling I/O, but does not provide other SCADAPack outstation functionality such as ISaGRAF or Trend Sampler processing. Whenever such an I/O expansion module is used, you have to Configure SCADAPack ES Remote I/O Properties on the DNP3 SCADAPack E-Series Outstation to which that I/O module is connected. A SCADAPack E-Series outstation can automatically allocate the I/O DNP3 Point Numbers for a SCADAPack ES outstation that is used as an I/O expansion module, in which case you do not need to configure an expansion card or module in the ClearSCADA database. However, if the default automatic allocation of I/O is not suitable—for instance, if you want to specify different Point Numbers to those that would otherwise be assigned—you need to configure a DNP3 SCADAPack ES Remote IO item in the ClearSCADA database to represent the expansion I/O module.

Regardless of the type of expansion card or module, you also have to configure one DNP3 SCADAPack point for each point that ClearSCADA is to monitor or control on each SCADAPack E-Series outstation and I/O card or module. With points that are on a separate card or module, use the Outstation field on the Point Form’s <Point Type> tab, and the fields on the Mapping tab, to specify the location of the point (see With Which Database Item do I Associate each DNP3 SCADAPack Point?).

Further Information

Configuring DNP3 SCADAPack E-Series Outstations.

Configuring I/O Expansion Cards and Modules.

Points Used on DNP3 SCADAPack E-Series Outstations.

Specify any Point Mapping.


DNP3 SCADAPack Driver Guide - SCADAPack E-Series Data Concentrators and Remote Outstations (Introduction to the DNP3 SCADAPack E-Series Driver)

SCADAPack E-Series Data Concentrators and Remote Outstations

SCADAPack E-Series outstations are able to act as ‘data concentrators’ and retrieve data from other outstations—known as ‘remote’ outstations—using the DNP3 protocol. The data concentrators are the ‘parent’ outstations of the remote outstations.

With the DNP3 SCADAPack E-Series driver, any supported SCADAPack E-Series outstations that are able to act as data concentrators can be configured as parent outstations.

With a parent-remote setup, either:

  • A data concentrator can scan all of its remote outstations for data, then process that data before passing the relevant information onto ClearSCADA. (Only a SCADAPack E-Series outstation that is appropriately licensed can provide such data concentrator functionality.)

If communications with the ClearSCADA server is temporarily lost, the data concentrator can continue to poll its remote outstations.

  • ClearSCADA can scan the remote outstations itself, with communications going ‘transparently’ via the remote outstations’ parent outstation
  • A data concentrator can scan its remote outstations for some point data, with ClearSCADA scanning the same remote outstations ‘directly’ for other point data. If required, both the data concentrator and ClearSCADA can scan the same point(s) on a remote outstation.

In each of the above scenarios, a remote outstation can be a SCADAPack E-Series outstation, or another device that communicates using the DNP3 protocol.

A ClearSCADA system might be configured to use a parent-remote set-up if, for example, there were limited communications to a site. By using a parent outstation, ClearSCADA could obtain the data from multiple remote outstations via just the one radio or dial-up modem connection to each parent outstation. Similarly, a parent-remote set-up might be used to enable a parent outstation to contain the logic and other programming that is required for its remote outstations.

Example:

With a parent-remote setup, within ClearSCADA you need to configure a DNP3 SCADAPack E-Series Outstation of the appropriate type (Direct, PSTN, or Shared) for each parent outstation, along with the appropriate DNP3 Channel(s) and DNP3 Outstation Set(s).

You also need to configure a DNP3 SCADAPack Remote E-Series Outstation for each remote SCADAPack E-Series outstation (or a DNP3 SCADAPack Remote DNP3 Device for each remote third-party or non-E-Series outstation).

You need to configure a DNP3 SCADAPack point for each point that ClearSCADA is to monitor or control on each parent outstation and remote outstation. (This includes points on remote outstations that are not SCADAPack E-Series outstations, if the parent outstations are to scan those remote outstations for data.)

If the parent outstations are to scan the remote outstations for data, those parent outstations need to include blocks of internal Derived (User) points that enable them to control and monitor the status of the remote outstations (see Configure Common Properties of DNP3 SCADAPack Points and see Configure the Data Concentrator Status and Control Points).

If ClearSCADA is to scan the remote outstations ‘transparently’ via their parent outstation, you will need to configure a DNP3 Routing Table to specify how the remote outstations are connected to the parent outstation (see Route DNP3 Frames Using a DNP Route Table). If communications between the parent outstation and the remotes is via an Ethernet connection, an IP Route Table will be required (see Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host). (If the remote outstations are not SCADAPack E-Series outstations and ClearSCADA is to scan those outstations ‘transparently’ via their parent outstation, you will need to configure a DNP3 point for each point on those remote outstations, rather than a DNP3 SCADAPack point.)

The outstation with which you associate each point on a remote outstation varies, depending whether the point is scanned by a data concentrator and/or ClearSCADA (see With Which Database Item do I Associate each DNP3 SCADAPack Point?).

Further Information

Configuring DNP3 SCADAPack E-Series Outstations.

Configure Data Concentrator Properties.

Specify the Remote DNP3 Device Properties.

Points Used on DNP3 SCADAPack E-Series Outstations.

See the ClearSCADA Guide to the DNP3 Driver for information about configuring DNP3 Channels, Outstation Sets, non-SCADAPack E-Series outstations and DNP3 points.


DNP3 SCADAPack Driver Guide - SCADAPack E-Series Outstations that Communicate with more than one DNP3 Master (Introduction to the DNP3 SCADAPack E-Series Driver)

SCADAPack E-Series Outstations that Communicate with more than one DNP3 Master

Some SCADAPack E-Series outstations are able to communicate with more than one DNP3 master. Such outstations have to be suitably licensed to provide multi-master support.

Within ClearSCADA, with each DNP3 SCADAPack E-Series Outstation, you need to:

  • Configure the Unsolicited Message Properties that are Specific to a Particular DNP3 Master
  • Specify Whether an Outstation Communicates with Multiple DNP3 Masters (Depending on the system setup and outstation licensing, a SCADAPack E-Series outstation can communicate with to three DNP3 Masters.)

With each DNP3 SCADAPack Point, you need to:

  • Specify the Point Data Class that Applies when Communicating with another DNP3 Master.

Regardless of the number of DNP3 masters with which a SCADAPack E-Series outstation communicates, ClearSCADA is deemed to be DNP3 Master 1 (the server on the system on which the outstation is located).


DNP3 SCADAPack Driver Guide - Quick Start Tutorial

Quick Start Tutorial

This section provides a guided tour designed to lead you through connecting a SCADAPack E-Series outstation to ClearSCADA, then communicating with that outstation using the DNP3 protocol. The procedure is for a SCADAPack ES outstation, however similar steps can be undertaken using other E-Series outstation models.

To perform the procedure, you will need:

  • A server and client on which ClearSCADA is installed.
  • A SCADAPack ES outstation and power supply.
  • RS-232 9-Pin D-Sub to RJ12 Serial cable—see the SCADAPack ES Hardware User and Reference Manual for information on the construction of this cable.
  • A small flat head screwdriver—to change the Hex Switch settings and tighten the I/O terminals.
  • Two short lengths of insulated copper wire—to connect analog output 4 of the SCADAPack ES outstation to analog input 12.

Now proceed as follows:

  1. Confirm that the DNP3 and SCADAPack E-Series Server Components are Installed.
  2. Setup a SCADAPack ES Outstation.
  3. Create the ClearSCADA Database Items.
  4. Power Up the SCADAPack ES Outstation.
  5. Control the DNP3 SCADAPack Analog Output Point.


DNP3 SCADAPack Driver Guide - Setup a SCADAPack ES Outstation (Quick Start Tutorial)

Setup a SCADAPack ES Outstation

The figure below shows a typical SCADAPack ES outstation with the cover removed.

In order to successfully complete this Quick Start Tutorial, you need to perform the following actions to prepare the SCADAPack ES outstation:

  1. Use two lengths of insulated copper wire to connect analog output 4 of the SCADAPack ES outstation to analog input 12.

Make sure you match the +ve and -ve terminals.

  2. Connect the ClearSCADA server to Port 1 of the SCADAPack ES outstation using the RS-232 9-Pin D-Sub to the RJ12 Serial Cable.
  3. Unscrew the four thumb-screws and remove the casing of the SCADAPack ES outstation.
  4. Put the SCADAPack ES outstation in FC mode. Set the first hex switch to F and the 2nd hex switch to C. (When a new SCADAPack ES outstation is shipped, it will usually be shipped in FC mode.)
  5. Power up the SCADAPack ES outstation.
  6. Wait until the SCADAPack ES outstation has completed its start-up sequence. You can monitor the start-up sequence by watching the Run LED. At the end of the start-up sequence, the Run LED will flash rapidly for about one second and then start flashing steadily at one-and-a-half seconds on, one-and-a-half seconds off.
  7. Remove power to the SCADAPack ES outstation.
  8. Put the SCADAPack ES outstation in 00 mode (both hex switches in the 0 position).
  9. Do not power up the SCADAPack ES outstation yet.

For more information on setting up a SCADAPack ES outstation, refer to the SCADAPack ES product documentation.

Now Create the ClearSCADA Database Items that you require for this tutorial.


DNP3 SCADAPack Driver Guide - Create the ClearSCADA Database Items (Quick Start Tutorial)

Create the ClearSCADA Database Items

To successfully complete this Quick Start Tutorial, within ClearSCADA you need to:

  1. Create a DNP3 Direct Channel.
  2. Create a DNP3 Direct Outstation Set.
  3. Create a DNP3 SCADAPack E-Series Direct Outstation.
  4. Create a DNP3 SCADAPack Analog Output Point.
  5. Create a DNP3 SCADAPack Analog Input Point.
  6. Create a Mimic to Display the Points.


DNP3 SCADAPack Driver Guide - Create a DNP3 Direct Channel (Quick Start Tutorial)

Create a DNP3 Direct Channel

When you create the channel, most of the configuration fields can be left at their default values. The only fields you need to change for this tutorial are:

  • In Service—Located on the Channel tab. Ensure that the check box is selected so that it displays a check mark.
  • Port—Located on the Connection tab. Specify the ClearSCADA server COM Port that is connected to the SCADAPack ES outstation.

For further information on configuring a DNP3 Direct Channel, see Configuring a DNP3 Channel in the ClearSCADA Guide to the DNP3 Driver.

Once you have configured the channel, you can proceed to Create a DNP3 Direct Outstation Set.


DNP3 SCADAPack Driver Guide - Create a DNP3 Direct Outstation Set (Quick Start Tutorial)

Create a DNP3 Direct Outstation Set

When you create the outstation set, most of the configuration fields can be left at their default values. The only fields you need to change for this tutorial are:

  • In Service—Located on the Outstation Set tab. Ensure that the check box is selected so that it displays a check mark.
  • Channel—Located on the Outstation Set tab. Specify the DNP3 Direct Channel created above.
  • DNP3 Local Address—Located on the DNP3 tab. Set to 30000.

For further information on configuring a DNP3 Direct Outstation Set, see Configuring a DNP3 Outstation Set in the ClearSCADA Guide to the DNP3 Driver.

Once you have configured the outstation set, you can proceed to Create a DNP3 SCADAPack E-Series Direct Outstation.


DNP3 SCADAPack Driver Guide - Create a DNP3 SCADAPack E-Series Direct Outstation (Quick Start Tutorial)

Create a DNP3 SCADAPack E-Series Direct Outstation

When you create the outstation, most of the configuration fields can be left at their default values. The only fields you need to change for this tutorial are:

  • In Service—Located on the Outstation tab. Ensure that the check box is selected so that it displays a check mark.
  • Outstation Set—Located on the Outstation tab. Specify the DNP3 Direct Outstation Set created above (see Create a DNP3 Direct Outstation Set).
  • Address—Located on the DNP3 tab. Set to 0.
  • Allow Automatic Download—Located on the SCADAPack tab. Ensure that the check box is selected so that it displays a check mark.
  • Outstation Type—Located on the Outstation Type tab. Ensure that this is set to SCADAPack ES.

For further information on configuring a DNP3 SCADAPack E-Series Direct Outstation, see Configuring DNP3 SCADAPack E-Series Outstations .

NOTE: ClearSCADA will raise a Communication State - Failed alarm when you save the outstation’s configuration, as the outstation is not powered up.

Once you have configured the outstation in ClearSCADA, you can proceed to Create a DNP3 SCADAPack Analog Output Point.


DNP3 SCADAPack Driver Guide - Create a DNP3 SCADAPack Analog Output Point (Quick Start Tutorial)

Create a DNP3 SCADAPack Analog Output Point

When you create the analog output point, most of the configuration fields can be left at their default values.

On the Analog Point tab, the only fields you need to change for this tutorial are:

  • In Service—Ensure that the check box is selected so that it displays a check mark.
  • Outstation—Specify the DNP3 SCADAPack E-Series Direct Outstation created above.
  • Point Number—Set to 4.
  • Point Data Class—Set to Class 0 Static Only.
  • DNP Object Type—Set to Short Floating Point Analog Output Status (g40v3).
  • Historic Data Filter—(This field is within the Logged Data section, toward the bottom of the Analog Point tab.) Set to Static and Event Data.

On the Control tab you will need to set the following:

  • Control Object—Set to Single-precision float (g41v3).
  • Update Point on successful action—Ensure that the check box is selected so that it displays a check mark.
  • Restore Output—Ensure that the check box is selected so that it displays a check mark.

On the Historic tab you will need to set:

  • Enabled—Ensure that the check box is selected so that it displays a check mark.

For further information on configuring a DNP3 SCADAPack Analog Output Point, see Configuring DNP3 SCADAPack Analog Points.

Once you have configured the analog output point, you can proceed to Create a DNP3 SCADAPack Analog Input Point.


DNP3 SCADAPack Driver Guide - Create a DNP3 SCADAPack Analog Input Point (Quick Start Tutorial)

Create a DNP3 SCADAPack Analog Input Point

When you create the analog input point, most of the configuration fields can be left at their default values.

On the Analog Point tab, the only fields you need to change for this tutorial are:

  • In Service—Ensure that the check box is selected so that it displays a check mark.
  • Outstation—Specify the DNP3 SCADAPack E-Series Direct Outstation created above.
  • Point Number—Set to 12.
  • Point Data Class—Set to Class 1 Event.
  • DNP Object Type—Set to Short Float Analog Input (g30v5).
  • Historic Data Filter—(This field is within the Logged Data section, toward the bottom of the Analog Point tab.) Set to Static and Event Data.

On the Historic tab you will need to set:

  • Enabled—Ensure that the check box is selected so that it displays a check mark.

For further information on configuring a DNP3 SCADAPack Analog Input Point, see Configuring DNP3 SCADAPack Analog Points.

Once you have configured the analog input point, you can proceed to Create a Mimic to Display the Points.


DNP3 SCADAPack Driver Guide - Create a Mimic to Display the Points (Quick Start Tutorial)

Create a Mimic to Display the Points

  1. Create a Mimic (for information on creating and configuring a Mimic, see the ClearSCADA Guide to Mimics).
  2. Drag-and-drop the DNP3 SCADAPack Analog Output Point onto the Mimic.
    A context sensitive menu is displayed.
  3. Select the Value option.
    A further menu is displayed.
  4. Select Formatted Value option.
  5. Drag-and-drop the DNP3 SCADAPack Analog Input Point onto the Mimic.
    A context sensitive menu is displayed.
  6. Select the Value option.
    A further menu is displayed.
  7. Select Formatted Value option.
  8. Save the Mimic.
  9. Put the Mimic into Run mode.

Once you have configured the Mimic, you can Power Up the SCADAPack ES Outstation.


DNP3 SCADAPack Driver Guide - Power Up the SCADAPack ES Outstation (Quick Start Tutorial)

Power Up the SCADAPack ES Outstation

To power up the SCADAPack ES outstation once you have created the DNP3 SCADAPack E-Series items in the ClearSCADA database, connect the power supply to the SCADAPack ES outstation.

The SCADAPack ES outstation will perform its start-up sequence.

ClearSCADA will continually poll the SCADAPack ES outstation until it receives a response. The SCADAPack ES outstation will set the DNP3 Configuration Corrupt IIN bit in the response—this will cause ClearSCADA to raise a Configuration Required alarm.

ClearSCADA will download the configuration to the SCADAPack ES outstation—this will clear the Configuration Required alarm.

ClearSCADA will send a reset command the SCADAPack ES outstation—this will clear the Configuration Required alarm.

The SCADAPack ES outstation will reset—this will raise a Communication State - Failed alarm.

The SCADAPack ES outstation will perform its start-up sequence.

The SCADAPack ES outstation will send an unsolicited message to ClearSCADA—this will cause ClearSCADA to clear the Communication State - Failed alarm. The unsolicited message will contain have the DNP3 Configuration Corrupt IIN bit cleared, so that the Configuration Required alarm will not be raised, and ClearSCADA will not attempt to download a configuration to the SCADAPack ES outstation.

You can now proceed to Control the DNP3 SCADAPack Analog Output Point.


DNP3 SCADAPack Driver Guide - Control the DNP3 SCADAPack Analog Output Point (Quick Start Tutorial)

Control the DNP3 SCADAPack Analog Output Point

To control the DNP3 SCADAPack Analog Output point that you configured earlier in this tutorial:

  1. Ensure that the Mimic that you created for this tutorial is in Run mode.
  2. Click on the DNP3 SCADAPack Analog Output Point on the Mimic.
    A context sensitive menu is displayed.
  3. Select the Control option.
    The Control window is displayed.
  4. Enter a value between 0 and 100.
  5. Continue sending controls to the DNP3 SCADAPack Analog Output Point—send controls that change the output by amounts greater than 1.0, and controls that change the output by amounts smaller than 1.0.
  6. View the DNP3 SCADAPack Analog Input Point’s value on the Mimic. Notice that when the output value changes by 1.0 or more, the input value is updated. When the output value changes by less than 1.0, the input value remains unchanged. This is due to the input point’s Significant Change settings.

If you open the DNP3 SCADAPack Analog Input Point’s Form, on the Analog Point tab you will see that the Significant Change Type is Percentage of Span, and the Deadband is 1. This means that the input has to change by 1% for the SCADAPack ES outstation in order to generate an event.

  7. Display the Historic Lists of the DNP3 SCADAPack Analog Input and DNP3 SCADAPack Analog Output Points. (For information on Historic Lists, see the ClearSCADA Guide to Lists).

Congratulations—you have completed this Quick Start Tutorial!


DNP3 SCADAPack Driver Guide - Scanning DNP3 SCADAPack E-Series Outstations

Scanning DNP3 SCADAPack E-Series Outstations

The ClearSCADA DNP3 driver interrogates SCADAPack E-Series devices for data in a similar way to that for other DNP3 devices. For more information:

  • see Scanning for Data on DNP3 Devices in the ClearSCADA Guide to the DNP3 Driver
  • see Scanning Direct Outstations on the DNP3 Driver in the ClearSCADA Guide to the DNP3 Driver.

Additionally, SCADAPack E-Series outstations have an enhanced feature set that enables further control over some of the features that are associated with such interrogation. This section summarizes those features and includes information on:

  • Unsolicited Message Generation
  • Events and Data Classes
  • Interlock Points
  • Retrieval of Sampled Point Data
  • SCADAPack Time Zone Settings
  • Scanning Remote Outstations.


DNP3 SCADAPack Driver Guide - Unsolicited Message Generation (Scanning DNP3 SCADAPack E-Series Outstations)

Unsolicited Message Generation

In addition to the usual unsolicited message configuration (see Unsolicited Messages in the ClearSCADA Guide to the DNP3 Driver), on a SCADAPack E-Series outstation you can specify:

  • The port via which the outstation sends unsolicited messages to ClearSCADA. This is specified using the DNP Master Port field within the Master 1 Configuration section on the outstation’s configuration Form (see Configure the Unsolicited Message Properties that are Specific to a Particular DNP3 Master).
  • The minimum number of Class 1, 2, or 3 events that have to be stored in the outstation’s internal Event Buffer before that outstation is to attempt to send an unsolicited message to ClearSCADA (see Configure Unsolicited Message Generation).
  • Various timeouts associated with unsolicited message generation (see Configure Unsolicited Message Generation, and see Configure the Unsolicited Message Properties that are Specific to a Particular DNP3 Master).
  • Which Class(es) are to be enabled by default (for example, when the outstation restarts)—see Configure Unsolicited Message Generation.

For each point on a SCADAPack E-Series outstation, you can specify the type of DNP3 data Class with which the point’s events are associated. You can also specify whether the generation of such an event causes the outstation to send an unsolicited message to ClearSCADA, or whether the outstation just stores the event in its internal Event Buffer (see Specify Whether a Class n Event Triggers an Unsolicited Message).


DNP3 SCADAPack Driver Guide - Events and Data Classes (Scanning DNP3 SCADAPack E-Series Outstations)

Events and Data Classes

A SCADAPack E-Series outstation can generate events for both physical input points and for derived points that have a static DNP3 object type (see Configure Common Properties of DNP3 SCADAPack Points).

Use the fields within the Event Configuration section on a DNP3 SCADAPack E-Series outstation’s configuration Form to specify the format (DNP3 Object and Variation) in which a SCADAPack E-Series outstation sends its event data to ClearSCADA (see Configure Event Configuration).

Use the Point Data Class field on each DNP3 SCADAPack Point Form to specify the DNP3 Data Class that is associated with that point (see Configure Common Properties of DNP3 SCADAPack Points).

Use the DNP3 Object Type field on each DNP3 SCADAPack Point Form to specify the DNP3 Object type that applies to that point (see Configure Common Properties of DNP3 SCADAPack Points). This defines the format in which the outstation sends the point’s value to ClearSCADA, whenever ClearSCADA issues an Integrity Poll.

For more information, see DNP3 Integrity and Data Classes in the ClearSCADA Guide to the DNP3 Driver.

SCADAPack E-Series outstations can generate events for various point activities—for more information, see the relevant sections within the following:

  • Points Used on DNP3 SCADAPack E-Series Outstations
  • Configuring DNP3 SCADAPack Analog Points
  • Configuring DNP3 SCADAPack Binary Points
  • Configuring DNP3 SCADAPack Counter Points.


DNP3 SCADAPack Driver Guide - Interlock Points (Scanning DNP3 SCADAPack E-Series Outstations)

Interlock Points

On SCADAPack E-Series outstations, you can optionally control points and pulse actions from both ClearSCADA and ISaGRAF. So that both applications do not attempt to control the same point or pulse action at the same time, you need to set up one or more Interlock Points.

Each Interlock Point has to be on the same outstation as the output point or pulse action for which it provides interlock functionality.

An interlock point can be either:

  • a DNP3 SCADAPack Binary Input Point that has a Point Type of Physical Input or User (Derived)

or:

  • a DNP3 SCADAPack Binary Output Point that has a Point Type of User (Derived).

You can associate the same interlock point with one or more DNP3 SCADAPack output points and pulse actions, in order to determine whether ClearSCADA or ISaGRAF is in control of those output point(s) or pulse action(s).

ATTENTION: A point that is used as an interlock point must not be used as any other type of status point (such as a Rate of Change point).

Example:

A DNP3 SCADAPack Binary Output point with a User (Derived) Point Type is configured as the interlock point for a DNP3 SCADAPack Analog Output point. The interlock point allows ClearSCADA to control the interlock in the SCADAPack E-Series outstation, by enabling ClearSCADA to remotely ‘disconnect’ ISaGRAF’s control of the analog output point.

A DNP3 SCADAPack Binary Input point is configured as the interlock point for another DNP3 SCADAPack Output point. This particular interlock point is connected to a switch on site, which itself enables ISaGRAF’s control of the output point to be disconnected, so allowing the output point to be controlled via DNP3.

Further Information

Assign an interlock point to an output point or pulse action: see Configure an Output Point or Pulse Action’s Interlock Properties.

Point Types: see Configure Common Properties of DNP3 SCADAPack Points.


DNP3 SCADAPack Driver Guide - Retrieval of Sampled Point Data (Scanning DNP3 SCADAPack E-Series Outstations)

Retrieval of Sampled Point Data

SCADAPack E-Series outstations can optionally sample counter, analog input, binary input, derived analog, and derived binary data for particular trends (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality). Point values that fulfill the Trend criteria are stored locally at the outstation.

With a Direct or Shared outstation, you specify the required Trend Retrieval rate on the Outstation Form (see Configure the Trend Retrieval Properties). This defines the frequency with which ClearSCADA retrieves the sampled data from the outstation. With a PSTN outstation, ClearSCADA retrieves any stored sampled data whenever it is in communications with the outstation.

The Retrieve All Trends pick action can also be used to retrieve any sampled data.


DNP3 SCADAPack Driver Guide - SCADAPack Time Zone Settings (Scanning DNP3 SCADAPack E-Series Outstations)

SCADAPack Time Zone Settings

Each SCADAPack E-Series outstation’s internal clock can be set by ClearSCADA (see Outstation Clock in the ClearSCADA Guide to the DNP3 Driver), or by the Network Time Protocol (NTP) Service. (If the latter is used, ClearSCADA should not be configured to set the clock on those outstations.) Regardless of which application sets the outstation’s clock, ensure that the Channel’s Time Zone property indicates the time zone that the outstation uses (see Defining General Channel Communication Settings in the ClearSCADA Guide to Advanced Drivers).

Most SCADAPack functions, including DNP3 event time stamps, use the same time zone as the outstation’s clock. On outstations on which NTP is used to set the clock, the clock runs in Coordinated Universal Time (UTC). On outstations on which ClearSCADA sets the clock, the clock can run in either UTC or Local Time as required.

SCADAPack Profiler tasks and some ISaGRAF functions can be configured to use a different time zone to that used by the outstation’s internal clock. Use the Time Zone field on each SCADAPack E-Series outstation’s SCADAPack tab to Configure the Profiler and ISaGRAF Time Zone Properties.


DNP3 SCADAPack Driver Guide - Scanning Remote Outstations (Scanning DNP3 SCADAPack E-Series Outstations)

Scanning Remote Outstations

Points on a remote outstation can be scanned:

  • By a data concentrator (the remote outstation’s ‘parent’ outstation)
  • Directly by ClearSCADA, with communications being transmitted ‘transparently’ through the parent outstation
  • Both of the above.

If a data concentrator is to scan its remote outstations for data, you need to specify the type of polling regime that the data concentrator is to undertake, and the internal Derived (User) points that are used to control and monitor such polling. Use the fields on the Remote DNP3 Device tab of the DNP3 SCADAPack Remote E-Series Outstation or DNP3 SCADAPack Remote DNP3 Device Form to Specify the Remote DNP3 Device Properties.

The frequency with which ClearSCADA polls the data concentrator for data, and the ability of the data concentrator to transmit unsolicited messages to ClearSCADA, determines the frequency with which the data concentrator’s copy of the remote outstations’ data is transmitted to ClearSCADA. (Should communications be temporarily lost between ClearSCADA and a data concentrator, the data concentrator will continue to poll its remote outstations for data.)

If ClearSCADA is to scan remote outstations for data, you specify the required scanning regime for the remote outstation’s points in the same way as you would for points on any ‘local’ SCADAPack E-Series or generic DNP3 outstation. ClearSCADA scans the outstations for data as if they were ‘local’ outstations, other then that transmissions go ‘transparently’ through the remote outstations’ parent outstation. As such, communications with the parent outstation have to be healthy, in addition to the remote outstations.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack E-Series Outstations

Configuring DNP3 SCADAPack E-Series Outstations

The DNP3 SCADAPack E-Series driver can communicate with SCADAPack E-Series outstations using permanent (‘direct’) communications or PSTN. The driver can also communicate with SCADAPack or other DNP3 devices that are connected to ClearSCADA remotely, via other SCADAPack E-Series outstations (see SCADAPack E-Series Data Concentrators and Remote Outstations).

For each SCADAPack E-Series outstation with which you want ClearSCADA to communicate, you need to configure an appropriate type of DNP3 SCADAPack E-Series Outstation item in the ClearSCADA database.

The DNP3 SCADAPack E-Series driver supports these types of DNP3 SCADAPack E-Series Outstation:

  • DNP3 SCADAPack E-Series Direct Outstation—For communicating with a SCADAPack E-Series outstation using a permanent connection (for example, direct serial, radio, or network).

Depending on the system set-up, a DNP3 SCADAPack E-Series Direct Outstation can belong to a DNP3 Direct Outstation Set, or a DNP3 Switched Outstation Set (see Configuring a DNP3 Outstation Set in the ClearSCADA Guide to the DNP3 Driver).

A DNP3 SCADAPack E-Series Direct Outstation can be a parent outstation for a DNP3 SCADAPack Remote E-Series Outstation or a DNP3 SCADAPack Remote DNP3 Device.

A DNP3 SCADAPack E-Series Direct Outstation can optionally be configured with PSTN fallback, so that the outstation can still communicate with the server if ClearSCADA deems the direct channel to have failed.

  • DNP3 SCADAPack E-Series PSTN Outstation—For communicating with a SCADAPack E-Series outstation using a dial-up modem. Each DNP3 SCADAPack E-Series PSTN Outstation has to belong to a DNP3 PSTN Outstation Set.

A DNP3 SCADAPack E-Series PSTN Outstation can be a parent outstation for a DNP3 SCADAPack Remote E-Series Outstation or a DNP3 SCADAPack Remote DNP3 Device.

  • DNP3 SCADAPack E-Series Shared Outstation—For communication with a SCADAPack E-Series outstation that can use either of two channels. The outstation has to be associated with a DNP3 Shared Outstation Set (each outstation in a Shared Set can communicate with the server via either channel).

A DNP3 SCADAPack E-Series Shared Outstation can be a parent outstation for a DNP3 SCADAPack Remote E-Series Outstation or a DNP3 SCADAPack Remote DNP3 Device.

If the system set-up allows, a DNP3 SCADAPack E-Series Shared outstation can optionally be configured with PSTN fallback so that the outstation can still communicate with the server if ClearSCADA deems both direct channels to have failed.

CAUTION

unexpected behavior of application

‘Heartbeating’ is not supported by SCADAPack E-Series outstations. Attempts to use Heartbeating on such outstations may cause erroneous behavior.

Failure to follow these instructions can result in equipment damage.

  • DNP3 SCADAPack Remote DNP3 Device—For communicating remotely with devices other than SCADAPack E-Series outstations, using the DNP3 protocol.

ClearSCADA communicates with each Remote DNP3 Device via that device’s parent outstation. Depending on the system setup, the parent outstation can be either a DNP3 SCADAPack E-Series Direct, PSTN, or Shared outstation.

The actual outstation with which you associate the points on a Remote DNP3 Device varies, depending on the device that scans the remote for point data (see With Which Database Item do I Associate each DNP3 SCADAPack Point?).

  • DNP3 SCADAPack Remote E-Series Outstation—For communicating remotely with SCADAPack E-Series outstations, using the DNP3 protocol.

ClearSCADA communicates with each Remote E-Series outstation via that outstation’s parent outstation. Depending on the system setup, the parent outstation can be either a DNP3 SCADAPack E-Series Direct, PSTN, or Shared outstation.

The actual outstation with which you associate the points on a Remote E-Series Outstation varies, depending on the device that scans the remote outstation for point data (see With Which Database Item do I Associate each DNP3 SCADAPack Point?).

If your database structure is ‘modular’ and Group Templates are used to store ‘model’ DNP3 SCADAPack E-Series configuration, in addition to the above types of outstation, you can add this driver-specific ‘abstract’ outstation item to your Group Templates:

  • Abstract SCADAPack E-Series Outstation—Converts to any of the DNP3 SCADAPack E-Series Outstation items listed above.

NOTE: A DNP3 SCADAPack Remote DNP3 Device represents a generic (rather than E-Series) DNP3 outstation. If you require an abstract item that can convert to a DNP3 SCADAPack Remote DNP3 Device, use an Abstract DNP3 Outstation, rather than an Abstract SCADAPack E-Series Outstation.

You can only add Abstract Items to Group Template s. The abstract items appear as additional driver-specific entries when you display the context sensitive menu from a Group Template. As with other abstract items, in order to represent a ‘real’ outstation, you need to convert the abstract items into the required type of outstation within the Group Instances that reference the Group Template. For more information, see Add an Abstract Item to a Group Template in the ClearSCADA Guide to Core Configuration.

This section covers configuration of SCADAPack E-Series specific properties on the outstations mentioned above. The properties are displayed on various tabs on the outstations’ configuration Forms. The properties are used to specify properties that are downloaded to the SCADAPack E-Series outstation—they do not provide any additional functionality in ClearSCADA. For information on these SCADAPack E-Series properties, see the references listed below.

NOTE: Before you start using ClearSCADA to configure DNP3 SCADAPack E-Series outstations, ensure that you are aware of the information detailed in Notes on Configuring SCADAPack E-Series Outstations, also see Scanning DNP3 SCADAPack E-Series Outstations.

Use the DNP3 tab to:

  • Specify the DNP3 properties that are common to many DNP3 outstations (see Configuring a DNP3 Outstation in the ClearSCADA Guide to the DNP3 Driver).

If a Remote E-Series Outstation or Remote DNP3 Device is Polled By a Data Concentrator, the only field that applies on the remote’s DNP3 tab is the Address field. ClearSCADA ignores the configuration in the other fields on the tab. For such a setup, we suggest that you use the Remote DNP3 Device tab to Specify Which Devices Scan a Remote Outstation before configuring any properties on the DNP3 tab—most of the fields on the DNP3 tab become ‘grayed out’ once the configuration indicates that the remote is being polled by its Data Concentrator, rather than ClearSCADA.

If a Remote E-Series Outstation or Remote DNP3 Device is Polled By either the Master Station (ClearSCADA) or both the Data Concentrator and Master Station, use the fields on the remote’s DNP3 tab to specify the settings that apply when ClearSCADA polls (scans) the remote for data ‘transparently’ via that remote’s parent outstation.

Use the Security tab to:

  • Specify the DNP3 Secure Authentication properties that are common to many DNP3 outstations (see Configure the Security Properties in the ClearSCADA Guide to the DNP3 Driver).

For information on the additional Security Configuration properties supported by the DNP3 SCADAPack E-Series driver, see Configure the Security Configuration Properties. (The Security Configuration properties are on the outstation’s SCADAPack tab.)

Use the SCADAPack tab to:

  • Specify the SCADAPack Properties.

Use the Outstation Type tab to:

  • Specify the Outstation Type and Port Configuration Properties.

Use the Multiple Masters tab to:

  • Specify Whether an Outstation Communicates with Multiple DNP3 Masters.

Use the SCADAPack TCP/IP tab to:

  • Specify the SCADAPack TCP/IP Properties.

Use the X.29/TC Comms tab to:

  • Specify the X.29/TC Comms Properties.

The configuration Forms for DNP3 SCADAPack Remote DNP3 Devices and DNP3 SCADAPack Remote E-Series Outstations include a Remote DNP3 Device tab.

Use the Remote DNP3 Device tab to:

  • Specify the Remote DNP3 Device Properties.

NOTE: When configuring a SCADAPack Remote DNP3 Device, or Remote E-Series Outstation, ClearSCADA automatically specifies the Outstation Set on the Outstation tab, once you specify the Parent Outstation on the Remote DNP3 Device tab, and save the configuration.

The DNP3 SCADAPack Remote DNP3 Device Form only includes one SCADAPack-specific tab—the Remote DNP3 Device tab. The other tabs on the Form are common to many DNP3 outstations (see Configuring a DNP3 Outstation in the ClearSCADA Guide to the DNP3 Driver).

For information on configuring properties on the Direct, and PSTN tabs, see Configuring a DNP3 Outstation in the ClearSCADA Guide to the DNP3 Driver.

Properties on the other tabs of each Outstation Form are common to outstations on many advanced drivers. For information, see Tabs on Outstation Forms in the ClearSCADA Guide to Advanced Drivers.


DNP3 SCADAPack Driver Guide - Notes on Configuring SCADAPack E-Series Outstations (Configuring DNP3 SCADAPack E-Series Outstations)

Notes on Configuring SCADAPack E-Series Outstations

This section details some important information when using ClearSCADA to configure a DNP3 SCADAPack E-Series outstation.

  • When modifications are made the configuration of DNP3 SCADAPack E-Series outstation database items, ClearSCADA determines the outstation Restart Level that is required to apply the modifications. This may result in one or more of the following occurring at the outstation:
  • A restart of the DNP3 driver in the outstation—This has no effect on physical outputs or the running ISaGRAF applications.
  • A restart of the ISaGRAF application—The physical outputs will drop. Binary outputs will be turned off, and analog outputs will be set to their calibrated minimum (typically 4mA).
  • A restart of the Profiler—The new profile settings will be applied to any profiled points with no intermediate transition. This will not effect the running ISaGRAF application(s).
  • A restart of the Sampler—This has no effect on physical outputs or the running ISaGRAF application(s).
  • A complete Cold Reset—The physical outputs will drop. Binary outputs will be turned off, and analog outputs will be set to their calibrated minimum (typically 4mA).

A Cold Reset is equivalent to power cycling the outstation.

  • You may still need to use another application (for example, the E-Series Configurator) to initially setup the SCADAPack E-Series outstation sufficiently for communications with ClearSCADA. Typically, you will only need to setup the DNP3 outstation and master addresses and the communications port to the master (ClearSCADA).
  • In addition to the configuration file generated by ClearSCADA, you can also use ClearSCADA to download other files to a SCADAPack E-Series outstation. For more information, see Working with DNP3 SCADAPack E-Series Outstation Configuration Files. Additional files that are typically downloaded to a DNP3 SCADAPack E-Series outstation include:
  • Licenses
  • Profiler configurations
  • Sampler configurations
  • ISaGRAF applications.
  • You will need to configure the properties on the SCADAPack TCP/IP tab if the outstation uses any form of TCP/IP communications, whether or not TCP/IP is used to communicate with ClearSCADA (see Enable or Disable TCP/IP Functionality).
  • If you are using the PSTN functionality of a DNP3 SCADAPack E-Series outstation, even if PSTN is not used to communicate with ClearSCADA, you will need to configure the fields located within the Modem Parameters section of the SCADAPack tab (see Configure the Modem Parameters).

For further information on the functionality that SCADAPack E-Series outstations can provide, please contact Schneider Electric (see http://www.schneider-electric.com).

Further Information

Determine the Restart Level of a Configuration Download.

Specify Whether a Download Configuration Request Requires Confirmation.


DNP3 SCADAPack Driver Guide - Specify the SCADAPack Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Specify the SCADAPack Properties

Use the fields on the SCADAPack tab of each DNP3 SCADAPack E-Series Outstation Form to:

  • Configure Automatic Configuration Download
  • Specify Whether a Download Configuration Request Requires Confirmation
  • Configure the Unsolicited Message Properties that are Specific to a Particular DNP3 Master
  • Configure Unsolicited Message Generation
  • Configure Event Configuration
  • Configure the DNP Route Table and Modem Authentication Properties
  • Configure Application Layer Properties
  • Configure Network Access Parameters
  • Configure the Modem Parameters
  • Configure the Trend Retrieval Properties
  • Configure Data Concentrator Properties
  • Configure Modbus Properties
  • Configure SCADAPack ES Remote I/O Properties
  • Configure the Profiler and ISaGRAF Time Zone Properties
  • Specify the Profile Type
  • Configure Low Voltage Alarm Level
  • Configure Scratchpad String Points
  • Configure the Firmware Image Properties
  • Configure the Security Configuration Properties.


DNP3 SCADAPack Driver Guide - Configure Automatic Configuration Download (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Automatic Configuration Download

Use the Allow Automatic Download check box located at the top of the SCADAPack tab to specify whether ClearSCADA is to automatically download the outstation’s configuration, in response to the Configuration Corrupt IIN bit being set in DNP3 response messages sent from the outstation.

Select the check box for ClearSCADA to automatically download the configuration stored in the ClearSCADA database when the DNP3 SCADAPack E-Series outstation sets its DNP3 Configuration Corrupt IIN bit.

Ensure that the check box is cleared, for ClearSCADA to ignore the DNP3 Configuration Corrupt IIN bit.

In addition to the configuration defined by the outstation and its associated points, ClearSCADA will also download any additional files that are configured for Automatic Download in the Configuration Setup Windows (see Specify the Properties of a File in a SCADAPack E-Series Outstation’s Configuration).

Regardless of the setting of the Allow Automatic Download check box, the configuration can be downloaded manually, using the Download Configuration pick action (see Download Configuration).

NOTE: Automatic configuration downloads are initiated by the SCADAPack E-Series outstation, rather than ClearSCADA. If you modify the properties on the outstation, or any other database item or file associated with the outstation, you will need to manually initiate the configuration download (see Download Configuration).


DNP3 SCADAPack Driver Guide - Specify Whether a Download Configuration Request Requires Confirmation (Configuring DNP3 SCADAPack E-Series Outstations)

Specify Whether a Download Configuration Request Requires Confirmation

Downloading the full configuration to a SCADAPack E-Series outstation results in a cold reset of that outstation, once the download is complete.

Downloading the configuration that has changed since the last download may result in various applications restarting on the outstation, or a complete cold reset of the outstation, depending on the configuration changes (see Notes on Configuring SCADAPack E-Series Outstations).

As such, you can choose whether a Download Configuration request requires confirmation before ClearSCADA attempts to execute that request. This helps to ensure that such a request is not triggered unintentionally.

Use the Download Confirm combo box near the top of the SCADAPack tab to specify whether confirmation is required whenever a user selects the Download Configuration pick action.

For more information on the options that are available from this combo box, see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration.

The Download Confirm field does not apply to automatic configuration downloads, which are initiated by the outstation (see Configure Automatic Configuration Download).

Further Information

Specify whether a firmware download request requires confirmation: see Configure the Firmware Image Properties.

Specify whether a security configuration download request requires confirmation: see Configure the Security Configuration Properties.


DNP3 SCADAPack Driver Guide - Configure the Unsolicited Message Properties that are Specific to a Particular DNP3 Master (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Unsolicited Message Properties that are Specific to a Particular DNP3 Master

Use the fields within the Master 1 Configuration section of the SCADAPack tab to specify the settings that apply when the DNP3 SCADAPack E-Series outstation attempts to send an unsolicited event message to the ClearSCADA server.

If the outstation communicates with more than one DNP3 master, specify the communication settings for the other master(s) on the Multiple Masters tab (see Specify Whether an Outstation Communicates with Multiple DNP3 Masters).

In either case, the fields within the Master 1 Configuration section apply to the local DNP3 master—the server on the ClearSCADA system that is used to configure the outstation.

  • Application Layer Confirm (Event) Timeout—Specify the maximum amount of time that the outstation waits for:
  • Confirmation of an unsolicited response sent to the DNP3 master
  • Confirmation of a poll response that contains event data.

When the outstation receives the confirmation, the events that were sent in the response are deleted from the outstation’s internal Event Buffer.

Enter the required timeout in the OPC Time Format.

  • Unsolicited Allowed—Use this check box to specify whether the outstation can report event data to the DNP3 master by using unsolicited messages.

Select the check box if the outstation is to send event data to the DNP3 master using unsolicited messages. Other fields within this section of the tab become available for use.

Ensure that the check box is clear if the outstation is to send event data to the DNP3 master only in response to requests from that DNP3 master.

  • DNP3 Master Port—Use this combo box to specify the port via which the outstation is to send unsolicited messages to the DNP3 master. You can only specify a port that has its Function set to DNP3 or PPP/TCPIP (see Configure the Properties of the Individual Ports). If you specify an Ethernet port, you also have to Configure Ethernet DNP/IP Properties.
  • Minimum Unsolicited Event Tx Delay—Specify the minimum time between consecutive unsolicited messages sent by the outstation.

Enter the required delay in the OPC Time Format, for example 30S for a 30-second delay.

  • Quiet Time Delay—Specify the amount of time that the outstation is to wait if it has tried to send an unsolicited message for the maximum number of Unsolicited Attempts Per Burst and has still not received a response from the DNP3 master (see Configure Unsolicited Message Generation).

Once the Quiet Time Delay has elapsed, the outstation will attempt to resend the unsolicited message for up to the maximum number of Unsolicited Attempts per Burst again. This cycle is repeated until it receives a response from the DNP3 master.

Further Information

Unsolicited Message Generation.


DNP3 SCADAPack Driver Guide - Configure Unsolicited Message Generation (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Unsolicited Message Generation

NOTE: The fields within the Unsolicited Message Generation section of the tab apply to unsolicited messages that the outstation sends to any DNP3 master. If an outstation is to send unsolicited messages, in addition to the fields in this section, you also have to configure the properties within the Master 1 Configuration section of the tab and, if applicable, the relevant properties on the Multiple Masters tab.

Use the fields within the Unsolicited Message Generation section of the SCADAPack tab to specify the conditions that have to be met in order for the outstation to generate an unsolicited message.

  • Event Notification Delay—Specify the delay between the outstation detecting a ‘Send Unsolicited’ condition, and the contents of the Event Buffer being sent as an unsolicited message.

Enter the required delay in the OPC Time Format, for example 10S for a 10-second delay.

The SCADAPack E-Series outstation will send an unsolicited message if:

  • Its Event Buffer contains more than the specified number of one of the Event Classes
  • The generation of a particular event causes the outstation to transmit its buffered events to ClearSCADA in an unsolicited message (see Specify Whether a Class n Event Triggers an Unsolicited Message).
  • Class 1 Minimum Events—Specify the minimum number of Class 1 events that have to be stored in the SCADAPack E-Series outstation’s internal Event Buffer, before the outstation attempts to send an unsolicited message.
  • Class 2 Minimum Events—Specify the minimum number of Class 2 events that have to be stored in the SCADAPack E-Series outstation’s internal Event Buffer, before the outstation attempts to send an unsolicited message.
  • Class 3 Minimum Events—Specify the minimum number of Class 3 events that have to be stored in the SCADAPack E-Series outstation’s internal Event Buffer, before the outstation attempts to send an unsolicited message.
  • Default Enabled Event Classes—Use the combo box to specify the event classes that are enabled for unsolicited event generation by default (for example when the outstation restarts). This option is primarily used for compatibility with older DNP3 masters.

After initial communication with the outstation, ClearSCADA will override the Default Enabled Event Classes (this action does not change the value of this property). For further information, see Enable Unsolicited Message Generation in the ClearSCADA Guide to the DNP3 Driver.

  • Unsolicited Attempts Per Burst—Specify the maximum number of times that the outstation attempts to send an unsolicited message if it does not receive a response from the DNP3 master. If the DNP3 master has still not responded following the final attempt, the outstation waits for the DNP3 master’s Quiet Time Delay to elapse before attempting to resend the unsolicited event message.

The local ClearSCADA server’s Quiet Time Delay is specified using the relevant field within the Master 1 Configuration section of the tab (see Configure the Unsolicited Message Properties that are Specific to a Particular DNP3 Master). The Quiet Time Delay of any additional DNP3 masters is specified using the relevant field(s) on the Multiple Masters tab (see Specify Whether an Outstation Communicates with Multiple DNP3 Masters).

NOTE: When a SCADAPack E-Series outstation generates an unsolicited message, it sends the contents of the Event Buffer to the ClearSCADA server in a single DNP3 fragment. If there are too many events to send in a single DNP3 fragment, the outstation will indicate that more events are available, by setting the appropriate DNP3 IIN bit in the unsolicited message.


DNP3 SCADAPack Driver Guide - Configure Event Configuration (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Event Configuration

When a DNP3 device sends event data to a SCADA Master, each event is sent in a format known as a DNP3 Object. The DNP3 standard specifies Objects and Variations, which define the type and format of the data sent between DNP3 devices. For example, Object 2 is defined in the DNP3 standard as a Binary Event Object and is used to send binary event data between DNP3 devices. Object 2, Variation 1 is defined as a binary event object with no time stamp, while Object 2, Variation 2 is defined as a binary event object with a time stamp. DNP3 Object/Variations are usually written in abbreviated notation. For example, Object 2 Variation 1 is written as g2v1.

When a DNP3 object with a time stamp is specified, the time stamp for the event is applied by the SCADAPack E-Series outstation at the time the event occurs. When these events are received by ClearSCADA, the ClearSCADA server stores the values in its historic database, using the time stamp supplied in the Event Object. When a DNP3 object with no time stamp is specified, the values are stored in the ClearSCADA history database using the system time of the ClearSCADA server at the time the events are received by the ClearSCADA server.

NOTE: The DNP3 standard specifies event objects for input points only. SCADAPack E-Series outstations can generate events for physical inputs, and for derived points that have a static DNP3 object type. Specify the DNP3 input object/variation that applies to these points, using the DNP Object Type property on the relevant DNP3 SCADAPack Point Form (see Configure Common Properties of DNP3 SCADAPack Points).

Use the fields within the Event Configuration section of the outstation’s SCADAPack tab to specify the DNP3 Objects and Variations that the outstation uses to send event data to ClearSCADA.

Each of the Event Object fields is a drop-down list, allowing you to select one of the DNP3 event objects supported by the SCADAPack E-Series outstation (see below).

We recommend that you only specify event objects that include time stamps, so that ClearSCADA logs the data using its original occurrence time, rather than the time that the event arrives at the server. The following DNP3 event objects are supported:

  • Binary Event Object—Specify the DNP3 Object and Variation that the SCADAPack E-Series outstation uses to send binary input point event data to ClearSCADA. The following options are available:
  • Binary Input Change No Time (g2v1) – The outstation does not time stamp the event data. ClearSCADA stores the events in the history database using the time they arrive at the ClearSCADA server. Not recommended, as the actual occurrence time is lost.
  • Binary Input Change with Time (g2v2) – The outstation does time stamp the event data. ClearSCADA stores the events in the history database using the time stamp applied by the outstation.
  • Binary Input Change Relative Time (g2v3) - The outstation time stamps the event data. ClearSCADA stores the events in the history database using the time stamp applied by the outstation.

The g2v3 produces more efficient communications on a SCADAPack E-Series outstation that regularly produces more than a few binary events every minute (either continuously, or in bursts).

  • Analog Event Object—Specify the DNP3 Object and Variation that the outstation uses to send analog (integer) event data to ClearSCADA. The event object specified in this field is used for analog input points that are configured with an Analog DNP Object Type (see Configure Common Properties of DNP3 SCADAPack Points). The following options are available:
  • 32-bit Analog In Change No Time (g32v1)—Analog event data is sent to ClearSCADA with 32-bit resolution. The outstation does not time stamp the event data. ClearSCADA stores the events in the history database using the time that the events arrive at the ClearSCADA server. Not recommended, as the actual occurrence time is lost.
  • 16-bit Analog In Change No Time (g32v2)—Analog event data is sent to ClearSCADA with 16-bit resolution. The outstation does not time stamp the event data. ClearSCADA stores the events in the history database using the time that the events arrive at the ClearSCADA server. Not recommended, as the actual occurrence time is lost.
  • 32-bit Analog In Change with Time (g32v3)—Analog event data is sent to ClearSCADA with 32-bit resolution. The outstation time stamps the event data. ClearSCADA stores the events in the history database using the time stamp applied by the outstation.
  • 16-bit Analog In Change with Time (g32v4)—Analog event data is sent to ClearSCADA with 16-bit resolution. The outstation time stamps the event data. ClearSCADA stores the events in the history database using the time stamp applied by the outstation.

NOTE: If you intend to generate events for 32-bit integer analogs, specify either g32v1 or g32v3 as the analog event object. (If you use g32v2 or g32v4, analog event values will be truncated to 16 bits.)

  • Float Event Object—Specify the DNP3 Object and Variation that the outstation uses to send floating point event data to ClearSCADA. The event object specified in this field is used for analog input points that are configured with a Float DNP Object Type (see Configure Common Properties of DNP3 SCADAPack Points). The following options are available:
  • Float Analog Input Change with Time (g32v7)—Analog event data is sent to ClearSCADA as IEEE short floating point (32-bit) precision. The outstation time stamps the event data. ClearSCADA stores the events in the history database using the time stamp applied by the outstation.
  • Float Analog Input Change No Time (g32v5)—Analog event data is sent to ClearSCADA as IEEE short floating point (32-bit) precision. The outstation does not time stamp the event data. ClearSCADA stores the events in the history database using the time they arrive at the ClearSCADA server. Not recommended, as the actual occurrence time is lost.
  • Counter Event Object—Specify the DNP3 Object and Variation that the outstation uses to send counter point event data to ClearSCADA. The following options are available:
  • 32-bit Counter Change No Time (g22v1)—Counter event data is sent to ClearSCADA with 32-bit resolution. The outstation does not time stamp the event data. ClearSCADA stores the events in the history database using the time they arrive at the ClearSCADA server. Not recommended, as the actual occurrence time is lost.
  • 16-bit Counter Change No Time (g22v2)—Counter event data is sent to ClearSCADA with 16-bit resolution. The outstation does not time stamp the event data. ClearSCADA stores the events in the history database using the time they arrive at the ClearSCADA server. Not recommended, as the actual occurrence time is lost.
  • 32-bit Counter Change with Time (g22v5)—Counter event data is sent to ClearSCADA with 32-bit resolution. The outstation time stamps the event data. ClearSCADA stores the events in the history database using the time stamp applied by the outstation.
  • 16-bit Counter Change with Time (g22v6)—Counter event data is sent to ClearSCADA with 16-bit resolution. The outstation time stamps the event data. ClearSCADA stores the events in the history database using the time stamp applied by the outstation.

NOTE: The DNP3 standard specifies that analog values are signed, and counter values are unsigned. As such, the value returned by g32v2 and g32v5 has the range
-32768 to 32767, whereas g22v2 and g22v6 have the range 0 to 65535.

  • Analog/Float Event Buffer Mode—Use to specify whether or not the outstation buffers multiple analog and floating point events. Choose from:
  • Multiple—The outstation buffers multiple events for each analog point generating events.

We recommend using this setting for Analog/Float Event Buffer Mode.

  • Single—The outstation only buffers the last analog or floating point event that was generated for each analog point that can generate events. The Single option allows legacy support for older SCADA masters that are incapable of processing multiple analog events.
  • Maximum Events Storage—Specify the maximum number of events, regardless of type, that the outstation can store.


DNP3 SCADAPack Driver Guide - Configure the DNP Route Table and Modem Authentication Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the DNP Route Table and Modem Authentication Properties

Use the fields within the Port Configuration section of the SCADAPack tab to specify the DNP Route Table and PAP/CHAP Authentication:

  • DNP Route Table—If the SCADAPack E-Series outstation is used to route DNP3 frames, use this field to specify the DNP Route Table that defines the required routing. The DNP3 Route Table’s configuration needs to specify which DNP3 frames the outstation will re-send, and the port via which those frames will be transmitted (see Add and Configure the Entries in a DNP Route Table).

NOTE: If the outstation is not being used as a DNP router, you still need to use a DNP Route Table if the SCADAPack E-Series outstation is to send unsolicited messages to a SCADA master (ClearSCADA) via TCP/IP or PSTN.

  • PAP/CHAP Username—Where a GPRS modem is used, use this field to specify the Password Authentication Protocol (PAP) user name that is required to log on to the GPRS network. In order to use such a modem, at least one outstation port has to have its Function section to PPP/TCPIP and its Mode set to GPRS (see Configure the Properties of the Individual Ports).

Where a 1xRTT modem is used, use this field to specify the Challenge Handshake Authentication Protocol (CHAP) user name that is required to log onto the 1xRTT network. In order to use such a modem, at least one outstation port has to have its Function set to PPP/TCPIP and its Mode set to 1xRTT (see Configure the Properties of the Individual Ports).

  • PAP/CHAP Password—Where a GPRS or 1xRTT modem is used, use this field to specify the password that is required to log on to the GPRS or 1xRTT network.
  • PPP DCD Drop Delay—Specify the amount of time, in milliseconds, that the Data Carrier Detect (DCD) has to be deasserted by the connected modem before the outstation deems the connection to have failed.

Enter the delay in the OPC Time Format.


DNP3 SCADAPack Driver Guide - Configure Application Layer Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Application Layer Properties

The Application Layer is the highest user-configurable DNP3 communication level. Use the fields within the Application Layer Setup section of the SCADAPack tab to specify the properties of the SCADAPack E-Series outstation’s application layer. These properties apply to DNP3 requests by the outstation:

  • Application Layer Attempts—Specify the number of times that the SCADAPack E-Series outstation will send any Application Layer Fragments. Fragments are re-sent if an Application Layer Confirm for the fragment is not received within the Complete Fragment Timeout.

NOTE: This field specifies the number of Attempts, not the number of Retries.

  • Complete Fragment Timeout—Specify the time within which the outstation requires a response to peer application layer requests. If no response is received within this time, the outstation resends the request fragment. This sequence is repeated until either a response is received, or the number of attempts equals the number specified in the Application Layer Attempts field (see above).

Enter the time in the OPC Time Format.

  • Select Arm Timeout—Specify the time period within which the outstation has to receive an Operate command after receiving a Select command for a two-phase Select/Operate DNP3Control.

If the Operate command that corresponds to the Select command is received before the timeout elapses, the outstation performs the control operation.

If the Operate command is not received within the specified time period, the control operation is rejected.

Enter the time in the OPC Time Format.

  • Time Update Request Rate—Specify how often the outstation requests a time update from its DNP3 Master (ClearSCADA). The request is sent as a DNP3 IIN bit set in responses sent to the Master.

Enter the time in the OPC Time Format.

If the SCADAPack E-Series outstation is configured to use NTP Network Time synchronization (see Enable TCP/IP Services), the outstation will not request DNP3 time updates, and will ignore any DNP3 time writes that it receives from the ClearSCADA server.


DNP3 SCADAPack Driver Guide - Configure Network Access Parameters (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Network Access Parameters

For multi-drop networks, the SCADAPack E-Series outstation can perform ‘media collision avoidance’, whereby transmissions are checked for collisions with another transmission on the network. If a collision is detected, the outstation re-attempts the transmission, after a delay. The Modes that support collision avoidance are:

  • RS232 (RTS Keyed)
  • FSK Radio (only available on Port 3 on 386 eNET outstations)
  • FSK Landline (only available on Port 3 on 386 eNET outstations).

Use the fields within the Network Access Parameters section of the SCADAPack tab to define the operational characteristics when a SCADAPack E-Series outstation uses a multi-dropped network, such as a radio network. Specify each value in the OPC Time Format.

  • Tx Warmup Delay—Specify the delay that is required between the transmission media being activated and the actual transmission of data. This delay allows the transmission device (for example, a radio unit) to activate its transmitter.
  • Max Random Delay—Specify the maximum additional delay that the outstation adds to the Fixed Delay, before sending data on the transmission media, once the outstation has detected a transmission collision. The outstation will add a random delay of any length up to and including this value.
  • Fixed Delay—Specify the fixed time delay for which the outstation waits, before attempting a data transmission, once it has detected a transmission collision. Before the transmission is attempted, the outstation adds an additional random delay (see Max Random Delay above).

NOTE: If both the Fixed Delay and Max Random Delay are set to zero, the SCADAPack E-Series outstation does not perform any collision avoidance.

  • Response Delay—Specify the period for which the outstation is to delay transmission of any data prior to activating the transmission device. A delay other than zero may be required where a radio repeater is slow to drop its carrier and the outstation tries to respond too quickly to a request to send data.
  • Postamble Delay—Specify the amount of time that has to elapse between the last byte being sent and the Request to Sent (RTS) signal being turned off.


DNP3 SCADAPack Driver Guide - Configure the Modem Parameters (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Modem Parameters

Use the fields within the Modem Parameters section on the SCADAPack tab to specify the modem properties if the SCADAPack E-Series outstation is to communicate with any device—not just ClearSCADA—using a dial-up modem. Specify each value in the OPC Time Format.

  • Modem Inactivity Timeout—Specify the time that the outstation maintains the connection while no data is being transmitted or received through the modem.

This property is ignored on ports on which the Modem Mode is set to Hangup Disabled (see Configure the Properties of the Individual Ports).

  • Send Delay—Specify the time that the outstation has to wait before sending any Hayes commands to a modem port, after an inbound ring has been detected on that port.

Specify a Send Delay that is sufficiently long enough to allow the modem to detect the ring, pick up and ‘train’ (synchronize) with the calling modem. (If the delay is shorter than this, the outstation might send Hayes commands to the modem while it is in the process of connecting to the other modem, causing the local modem to hang up. The calling modem will then hang up when it fails to train.)

  • Message Tx Timeout—Specify the length of time that the outstation’s modem driver stores an outbound message in its Transmit (Tx) queue before discarding it.

Set this parameter to slightly less than the SCADAPack E-Series outstation’s DNP3 Application Layer Timeout parameter.

  • Test Interval—Specify the time between modem tests while the modem is not connected. The outstation uses the modem initialization string to check the health of the local modem at this interval.
  • DTR Delay Time—Applies to low power modems only. Specify the amount of time (in milliseconds) that separates the Data Terminal Ready (DTR) line being asserted and the transmission of data.

You specify whether a modem operates in low power mode using the relevant Low Power Modem check box on the Ports section of the Outstation Type tab (see Configure the Properties of the Individual Ports).


DNP3 SCADAPack Driver Guide - Configure the Trend Retrieval Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Trend Retrieval Properties

This section only applies if the outstation samples input or derived point data for particular trends (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality).

When an outstation samples any counter, analog input, binary input, or derived analog or binary data, it stores the values that fulfill the sample criteria locally at the outstation. Use the fields within the Trend Retrieval section of the SCADAPack tab to specify when that data is retrieved for use in ClearSCADA:

  • Interval—Only applies if the outstation is a DNP3 SCADAPack E-Series Direct or Shared outstation.

Use the Interval field to specify the frequency with which ClearSCADA retrieves any sampled data records from the outstation. Enter the frequency in the OPC Time Format.

Leave at the default of zero if the outstation does not sample point data, or sampled data is only to be retrieved using the Retrieve All Trends pick action.

  • Offset—Only applies if the outstation is a DNP3 SCADAPack E-Series Direct or Shared outstation.

Use the Offset field to specify the offset between midnight UTC at the start of the day and the time at which the first sampled data retrieval occurs. Thereafter, data is retrieved at the frequency specified in the Interval field, above.

Specify the Offset in the OPC Time Format.

  • Maximum Size—Only applies if the Outstation Type is set to 386 eNET (see Specify the Outstation Type).

Use this field to specify the maximum acceptable size of the data packet that the outstation can transmit to ClearSCADA in response to a request for the outstation’s sampled records. If the records exceed this size, the outstation will transmit the oldest records first. The sampled records are deleted from the outstation once ClearSCADA has retrieved the data successfully.

With a DNP3 SCADAPack E-Series PSTN outstation, ClearSCADA retrieves any stored sampled data values from the outstation whenever it is in communications with that outstation.


DNP3 SCADAPack Driver Guide - Configure Data Concentrator Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Data Concentrator Properties

This section only applies if the SCADAPack E-Series outstation is configured and licensed to operate as a data concentrator (see SCADAPack E-Series Data Concentrators and Remote Outstations). The setting is ignored by any outstation that is not a data concentrator.

Use the Stop Communications If Buffers Full field in the Data Concentrator section of the SCADAPack tab to specify what action the SCADAPack E-Series outstation will perform when its internal Event Buffer becomes full.

Select the check box for the data concentrator to send a ‘Disable Unsolicited’ message and stop performing event polls on its remote outstations when its internal Event Buffer becomes full. This will cause the remote outstations to buffer events until the data concentrator has free space in its Event Buffer, and so help to avoid any loss of events. Normal operation is resumed as soon as space becomes available in the data concentrator’s Event Buffer.

Ensure that the check box is clear for the SCADAPack E-Series outstation to create free space in its internal Event Buffer, by overwriting old events when the Buffer is full.


DNP3 SCADAPack Driver Guide - Configure Modbus Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Modbus Properties

This section only applies if the SCADAPack E-Series outstation is a Modbus Slave. To communicate as a Modbus Slave device, at least one of the SCADAPack E-Series outstation’s ports has to have its Function defined as Modbus Slave (see Configure the Properties of the Individual Ports). If the outstation is not configured as a Modbus Slave, ClearSCADA will ignore the settings in this section of the Form.

Use the fields in the Modbus section of the SCADAPack tab to specify these properties:

  • Slave Address—Use to specify the Modbus Slave Address of the SCADAPack E-Series outstation.

If an address other than zero is specified, the SCADAPack E-Series outstation only takes account of slave requests that match the specified address, unless such requests use the broadcast address of zero.

  • 32-Bit Point Modbus Map—If the Modbus master is to read or write 32-bit integer or floating point (real) data from the outstation, use this field to specify the 32-bit Point Modbus Map that is to be downloaded to the outstation.

Use the browse button to display a Reference browse window, then selected the required entry from the window. A suitably configured DNP3 SCADAPack 32-Bit Point Modbus Map has to exist in the ClearSCADA database (see Configuring DNP3 SCADAPack 32-bit Point Modbus Maps).


DNP3 SCADAPack Driver Guide - Configure SCADAPack ES Remote I/O Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure SCADAPack ES Remote I/O Properties

This section only applies if the SCADAPack E-Series outstation is the main unit of a Main-SCADAPack ES Remote I/O configuration. With such a setup:

  • One or more SCADAPack ES Remote IO modules will be connected to the outstation, to increase the number of I/O (points) on the outstation (see Configuring I/O Expansion Cards and Modules)
  • The outstation’s Outstation Type has to be set to SCADAPack ES, SCADAPack ER-P600, SCADAPack ER-P620, or 386 eNET (see Specify the Outstation Type)
  • If the SCADAPack ES Remote IO module is connected to the outstation via a serial port, that Port has to have its Function set to ‘SCADAPack ES Remote I/O’ (see Configure the Properties of the Individual Ports).

Use the fields within the SCADAPack ES Remote I/O section of the SCADAPack tab to specify the required timeouts for communications between this main outstation and its SCADAPack ES Remote IO module(s). Specify each timeout in the OPC Time Format.

  • Inactivity Timeout—Use to specify the maximum inactivity interval for communications between this outstation and its SCADAPack ES Remote IO module(s). If a module does not receive a valid message from the outstation within this interval, that Remote IO module will set its binary outputs to zero and its analog outputs to their minimum values.
  • Background Poll Timeout—Use to specify the required background poll rate of the SCADAPack ES Remote IO module(s). The background poll is used to verify that the Remote IO modules are operating correctly. If a SCADAPack ES Remote IO module sends an unsolicited message to the main unit within this period, no background poll is performed on that module.
  • Must Poll Timeout—Use to specify the rate at which the main unit has to poll its SCADAPack ES Remote IO module(s) for current data. The poll rate is used to synchronize the values in the main outstation with the values in the remote modules.

If the outstation does not receive a reply to a Background Poll or Must Poll request within 5 seconds of sending that request, it will retry the message up to two more times. If no response is received within 5 seconds of the final retry, the outstation will update the status points indicating the remote I/O status to indicate a failure.

For more information on SCADAPack E-Series Remote I/O, see the SCADAPack E-Series Remote I/O Technical Reference Manual.


DNP3 SCADAPack Driver Guide - Configure the Profiler and ISaGRAF Time Zone Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Profiler and ISaGRAF Time Zone Properties

Use the Time Zone field toward the bottom of the SCADAPack tab to specify the time zone that is used for the SCADAPack E-Series outstation’s Profiler and ISaGRAF functions. This time zone is independent of the time zone used for the SCADAPack E-Series outstation’s internal clock.

The outstation’s internal real-time clock is set to Coordinated Universal Time (UTC) by the NTP service (see Enable TCP/IP Services), or to UTC or Local Time (whichever is required) by ClearSCADA issuing DNP3 Write Time requests. Most outstation functions, including DNP3 event time stamps, use the time zone that is assigned to the outstation’s clock. For these functions, this Time Zone field has no effect. Only a few specific ISaGRAF function blocks and the SCADAPack E-Series outstation’s Profiler task use a time zone that is independent to that of the outstation’s clock (that is, the time zone specified using this Time Zone field). For further information, see the SCADAPack E-Series Operation Reference Manual.

Use the Time Zone combo box to specify the time zone used for specific ISaGRAF and outstation Profiler functions. Choose from:

  • Coordinated Universal Time (UTC)—The functions use UTC time.
  • Local Time without Daylight Saving Time—The functions use Local Time. For instance EST (Eastern Standard Time) if the local time zone is that for the East coast of America. No adjustments are made for any Daylight Saving Time (DST).
  • Local Time with Daylight Saving Time—The functions use Local Time. The time is adjusted automatically twice a year to account for Daylight Saving Time (DST). This is done by the driver sending a special command to the outstation indicating, at the relevant time, that Daylight Saving Time has started or ended. Should ClearSCADA not be communicating with the outstation at the time, the driver will send the command the next time that ClearSCADA is in communications with that outstation.

Further Information

Specify the Profile Type.

Time Zone property: see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


DNP3 SCADAPack Driver Guide - Specify the Profile Type (Configuring DNP3 SCADAPack E-Series Outstations)

Specify the Profile Type

Use the Profile Type field toward the bottom of the SCADAPack tab to specify the type of Profile that is used by the outstation’s points.

CAUTION

unexpected behavior of application

Take great care if you need to change an existing outstation’s Profile Type at some future date from Standard to Daily, or vice versa. Changing an outstation’s Profile Type will remove the existing Profile entries from the configuration Forms of the points on that outstation. (As that type of Profile would no longer be deemed to be valid.)

Ensure that you update each point’s configuration as required.

Failure to follow these instructions can result in unexpected configuration changes.

Select the type of Profile that is appropriate to your way of working. Choose from:

  • Standard—The default option. The outstation’s points use ClearSCADA’s standard or ‘core’ Time Profiles (see Configuring Time Profiles in the ClearSCADA Guide to Core Configuration).

With this type of Profile, each Time Profile database item defines a single profile (for example, a ‘2 High’ limit profile) for the whole week. With DNP3 SCADAPack points, each Time Profile can have a Daily or Weekly span, for which the data has to be Stepped. (With a Daily Time Profile, the profile’s span is repeated from the start of each day. With a Weekly Time Profile, the change in value over the profile’s span is repeated at the start of each week.)

On each DNP3 SCADAPack Point Form, you can associate a different Time Profile with each point limit or state.

  • Daily—The outstation’s points use DNP3 SCADAPack Profiles (see Configuring DNP3 SCADAPack Profiles).

With this type of Profile, each DNP3 SCADAPack Profile database item defines all of the profiles (for example, 4 High, 3 High, 2 High, 1 High, 1 Low, 2 Low, 3 Low, 4 Low, and Current Value) for a single day of the week.

On each DNP3 SCADAPack Point Form, you associate a DNP3 SCADAPack Profile with each day of the week.

Further Information

Configure the Profiler and ISaGRAF Time Zone Properties.

Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value.


DNP3 SCADAPack Driver Guide - Configure Low Voltage Alarm Level (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Low Voltage Alarm Level

Use the Low Voltage Alarm Level field on the SCADAPack tab to specify the DC supply voltage below which the SCADAPack E-Series outstation will set the ‘Local Input Power Supply Low’ system point.

NOTE: To generate an alarm in ClearSCADA when the SCADAPack E-Series outstation detects a low input voltage, create a DNP3 SCADAPack E-Series binary input point in the ClearSCADA database for the ‘Local Input Power Supply Low’ system point (point number 50206).


DNP3 SCADAPack Driver Guide - Configure Scratchpad String Points (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Scratchpad String Points

NOTE: The Scratchpad String Points fields are ‘grayed out’ and unavailable for use if any of the outstation’s serial ports are configured to route data using the X.29 communication driver interface (see Specify the X.29/TC Comms Properties).

Use the fields within the Scratchpad String Points section of the SCADAPack tab to specify up to eight arbitrary strings that are to be stored in the SCADAPack E-Series outstation.

The Scratchpad String Points can be accessed in an ISaGRAF application running in the outstation. See the SCADAPack E-Series product documentation for further details.


DNP3 SCADAPack Driver Guide - Configure the Firmware Image Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Firmware Image Properties

Use the fields within the Firmware section of the SCADAPack tab to define the properties associated with downloading operating system firmware to the outstation. In order to configure these Firmware properties successfully, a suitable DNP3 SCADAPack Firmware Image item has to exist in the ClearSCADA database (see Configure a DNP3 SCADAPack Firmware Image Item).

  • Image—Select the field’s browse button to display a Reference browse window. Select the required DNP3 SCADAPack Firmware Image item from the window. (To check which operating system firmware is associated with a particular Firmware Image database item, view that item’s Status display (see DNP3 SCADAPack Firmware Image Status Attributes).)
  • Firmware Download Confirm—A successful firmware download will result in a Cold Reset of the outstation. Use the Firmware Download Confirm combo box to specify whether confirmation is required whenever a user selects the Download Firmware or Download Remote Firmware pick actions.

For information on the options that are available from this combo box, see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration.

  • Patch Remotes—Only applies if the SCADAPack E-Series outstation is the main unit of a Main-SCADAPack ES Remote I/O configuration (see Configure SCADAPack ES Remote I/O Properties).

Select the Patch Remotes check box if ClearSCADA is to download the firmware image to both the main outstation and each of the SCADAPack ES Remote IO modules that are connected to that outstation. Such a download is only possible if both the main outstation and each of its remote IO modules are of the same type (for example, if they are all SCADAPack ES, or all 386 eNETs). Use the Download Firmware pick action to trigger such a download.

Ensure that the check box is clear if ClearSCADA is to download the firmware image only to the main outstation whenever the Download Firmware pick action is triggered. The Download Remote Firmware pick action has to be used to download firmware to any of the outstation’s SCADAPack ES Remote IO modules.

With either option, be aware that a firmware image will only download successfully if the boards are compatible with the firmware update that is being downloaded. For more information, see the SCADAPack E-Series Firmware Update User Manual.


DNP3 SCADAPack Driver Guide - Configure the Security Configuration Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Security Configuration Properties

This section only applies to outstations on which DNP3 Secure Authentication is enabled.

With a DNP3 outstation that is to communicate using DNP3 Secure Authentication, you need to enable security and configure the properties on the outstation’s Security tab (see Configure the Security Properties in the ClearSCADA Guide to the DNP3 Driver). The settings on the Security tab are used by ClearSCADA to determine the outstation’s security settings. They also determine how ClearSCADA interacts with that outstation with regard to security—the settings are not downloaded to the actual outstation.

With SCADAPack E-Series outstations, you can also configure the actual outstation’s security settings remotely, then download those settings to the outstation. To do this via ClearSCADA, you need to import the security configuration file into ClearSCADA, associate that file with the relevant outstation, then download that file to the outstation (see Import and Download SCADAPack Security Configuration Files). You use the fields in the Security Configuration section of the Outstation Form’s SCADAPack tab to associate the relevant security configuration file with an outstation. In order to configure the Security Configuration properties successfully, a suitable DNP3 SCADAPack Security Configuration item has to exist in the ClearSCADA database (see Import and Download SCADAPack Security Configuration Files).

  • File—Select the field’s browse button to display a Reference browse window. The window displays the DNP3 SCADAPack Security Configuration items on your system—these are the database items that are used to import security configuration files into ClearSCADA.

Select the required DNP3 SCADAPack Security Configuration item from the window.

To check which security configuration file is associated with a particular Security Configuration database item, view that item’s Status display (see DNP3 SCADAPack Security Configuration Status Attributes).

Ensure that the File field is blank if the outstation is not to use DNP3 Secure Authentication, or ClearSCADA is not being used to configure the outstation’s security settings remotely.

NOTE: In order to communicate using DNP3 Secure Authentication, both the DNP3 master (ClearSCADA) and the DNP3 outstation have to be provided with a pre-shared private Update Key. If the File field is used to associate a security configuration file with a DNP3 SCADAPack E-Series outstation that has not yet been assigned an Update Key, ClearSCADA will automatically assign the Update Key associated with that security configuration file to the outstation when the Outstation Form’s configuration is saved.

  • Download Confirm—A successful security configuration download will result in a Warm Reset of the outstation. Use the Download Confirm combo box to specify whether confirmation is required whenever a user selects the Download Security Configuration pick action.

For information on the options that are available from the Download Confirm combo box, see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration.


DNP3 SCADAPack Driver Guide - Specify the Outstation Type and Port Configuration Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Specify the Outstation Type and Port Configuration Properties

Use the fields on the Outstation Type tab of each DNP3 SCADAPack E-Series Outstation Form to:

  • Specify the Outstation Type
  • Configure the Properties of the Individual Ports
  • Configure the SCADAPack ER-P620 IRIG Mode (applies to SCADAPack ER-P620 outstations only).


DNP3 SCADAPack Driver Guide - Specify the Outstation Type (Configuring DNP3 SCADAPack E-Series Outstations)

Specify the Outstation Type

NOTE: Throughout this guide, unless mentioning features that are specific to particular model(s) of outstation, the term ‘SCADAPack E-Series outstation’ is used to refer to any SCADAPack E-Series or eNET outstation with which ClearSCADA can communicate using the DNP3 protocol.

Use the combo box at the top of the Outstation Type tab to specify the type of outstation that this DNP3 SCADAPack E-Series Outstation database item represents.

The types of outstation with which ClearSCADA can communicate using the DNP3 SCADAPack E-Series driver include:

  • SCADAPack ES
    (previously known as 586 eNET)
  • SCADAPack 350E
  • SCADAPack 357E
  • SCADAPack ER-P600
    (previously known as the Magna eNET P520)
  • SCADAPack ER-P620
    (previously known as the Magna eNET P524)
  • SCADAPack 330E
  • SCADAPack 334E
  • 386 eNET.

The fields on the remainder of the Outstation Type tab vary, depending on the Outstation Type that you select. Use the rest of the fields on the tab to:

  • Configure the Properties of the Individual Ports
  • Configure Data Link Layer Properties.

If the Outstation Type is set to ‘SCADAPack ER-P620’, also use the tab to:

  • Configure the SCADAPack ER-P620 IRIG Mode.


DNP3 SCADAPack Driver Guide - Configure the Properties of the Individual Ports (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Properties of the Individual Ports

ATTENTION: Ensure that you Specify the Outstation Type before configuring the properties on the Ports section of the Outstation Type tab.

Use the fields within the Ports section of the Outstation Type tab to specify the configuration of the serial ports on the SCADAPack E-Series outstation. The number of ports and configuration fields vary, depending on the Outstation Type that is specified at the top of the tab (see Specify the Outstation Type).

This section details the most common SCADAPack E-Series outstation port settings. For a complete description of the available port settings, see the SCADAPack E-Series Configuration Technical User and Reference Manual, and the SCADAPack E-Series Communication Interfaces Technical User and Reference Manual.

NOTE: Although ClearSCADA is capable of setting the outstation’s port configuration by downloading the outstation’s configuration, ClearSCADA first has to be able to communicate with the outstation. To enable this, use the E-Series Configurator to initially configure one of the outstation’s ports and its DNP3 address, to allow ClearSCADA to communicate with it.

  • Function—Use the combo box to specify the function of this port. The options vary, depending on the Outstation Type and the port number, and include a combination of the following:
  • None—The port is not used.
  • ISaGRAF—The port is used to locally connect ISaGRAF Workbench PC software. This software can be used to download or debug ISaGRAF applications.

The port also has limited Modbus support for a SCADAPack E-Series outstation that acts as a Modbus Slave, and also supports Command-line Shell. For further information, see the SCADAPack E-Series ISaGRAF Technical User and Reference Manual.

NOTE: Only one port may be assigned the ISaGRAF function.

  • DNP3—The port is used to communicate with other DNP3 devices. These may include devices local to the outstation, such as actuated valves, other SCADAPack E-Series outstations on the network, and ClearSCADA.
  • Cmd Line—The port is used for Command Line diagnostics. You can connect to this port using an ASCII Terminal Emulator to send commands and view diagnostic messages.

NOTE: Only one port may be assigned the Cmd Line function.

  • PLC Device—The port is used to communicate with a PLC, for example if you are using the SCADAPack E-Series outstation as a Modbus Master.
  • ISaGRAF User—The port enables an ISaGRAF User application that is running in an outstation to send and receive data. This functionality is typically used to create simple device drivers (such as alphanumeric displays). See the SCADAPack E-Series ISaGRAF Function Block User and Reference Manual for further information.
  • ISaGRAF 2—The port supports the same functionality as a standard ISaGRAF port (see above), except for the ‘Command Line’ and ‘Diagnostics’ shell commands. This second ISaGRAF port allows for simultaneous ISaGRAF/Modbus communications on dual ports.
  • SCADAPack ES Remote I/O—Available if the Outstation Type is set to SCADAPack ES, SCADAPack ER-P600, SCADAPack ER-P620, or 386 eNET. The port is used to communicate with a SCADAPack ES outstation, which provides additional I/O to this SCADAPack E-Series outstation.

If this port function is selected, you need to Configure SCADAPack ES Remote I/O Properties. A DNP3 SCADAPack ES Remote IO item will be required in the ClearSCADA database, to represent the I/O module (see Configuring I/O Expansion Cards and Modules).

  • PPP/TCPIP—The port is used for TCP/IP communications. The port can be used for any enabled TCP/IP Service (see Enable TCP/IP Services) and DNP3.

If this port Function is selected, you need to enable and Configure DNP/IP Parameters.

  • TCP Service—The port is used to provide a terminal-server like TCP serial interface. If this port function is selected, you need to:
  • Enable the outstation’s TCP/IP functionality (see Enable or Disable TCP/IP Functionality).
  • Configure TCP Service Port Properties.
  • Modbus Slave—The port is used to communicate with a Modbus Master device, using the Modbus protocol. If this port function is selected, you need to Configure Modbus Properties.

Where TCP/IP communications are used, see the following sections:

  • Enable TCP/IP Services.
  • Configure Modbus/TCP Unit Identifier.

For more information on Modbus, see the ClearSCADA Guide to the Modbus Driver.

  • DNP VT Service—The port is used to send and receive serial data between a SCADA Master (ClearSCADA) and a device connected to this port using DNP3 Virtual Terminal Objects (see Configuring DNP3 Virtual Terminals in the ClearSCADA Guide to the DNP3 Driver).

If the DNP3 master driver is used for routing comms, using a Virtual Terminal, you need to Configure a DNP3 VT Service Port Master and Configure a DNP3 Virtual Terminal. The Virtual Terminal Number on the DNP3 Virtual Terminal Form has to correspond to the Port number being used on the SCADAPack E-Series outstation.

  • IEC 60870-5-103 Master—Available for Outstation Types other than the 386 eNET. The SCADAPack E-Series outstation is an IEC 60870-5 Controlling Station (SCADA master) and obtains data from IEC 60870-5 Controlled Stations (Slave devices) on this port, using the IEC 60870-5-103 protocol.

Be aware that a SCADAPack E-Series outstation requires additional licensing in order to provide IEC 60870-5-103 master functionality.

  • IEC 60870-5-101 Slave—Available for Outstation Types other than the 386 eNET. The port is used to communicate with an IEC 60870-5 Controlling Station (SCADA master), using the IEC 60870-5-101 protocol.
  • NTP GPS Receiver—The port is connected to a GPS receiver. This enables the outstation to act as an NTP time server and provide an accurate time source.
  • Conitel Slave—Only available on Ports 5 to 8 when a SCADAPack ER-P620 Outstation Type is specified. The port is used to communicate with a SCADA master using the Conitel 2020 protocol.
  • Mode—Use the combo box to specify the mode in which a port is operating. The options vary, depending on Outstation Type and the port’s Function (see above). For most ports, the possible options are:
  • RS232 (RTS On)
  • RS232 (RTS Off)
  • RS232 (RTS Keyed)
  • RS422
  • RS485 2 Wire
  • RS485 4 Wire Master
  • RS485 4 Wire Slave
  • Hayes Modem
  • Hayes Pool
  • GPRS (only available on ports on which the Function is specified as PPP/TCPIP)
  • 1xRTT (only available on ports on which the Function is specified as PPP/TCPIP)
  • FSK Radio (only available on Port 3 on a 386 eNET)
  • FSK Landline (only available on Port 3 on a 386 eNET)
  • SMR Radio (only available on Port 3 on a 386 eNET)
  • X.29 (only available on ports on which the Function is specified as DNP3. Limited to certain ports on some types of SCADAPack E-Series outstation.) Use the properties on the outstation’s X.29/TC Comms tab to Specify the X.29/TC Comms Properties.

NOTE: Changing a port between RS232 and RS422 or RS485 may require a hardware modification. See the SCADAPack E-Series Communication Interfaces Technical User and Reference Manual for details.

If a SCADAPack 330E/334E, or SCADAPack 350E/357E Outstation Type is specified, Port 0, if used, has its Function limited to DNP3 and its Mode limited to USB. Additionally, with a SCADAPack 350E/357E Outstation Type, Port 1’s Mode is limited to RS485 2 Wire.

  • Baud Rate—Displayed when applicable. Use the combo box to specify the baud rate used for transferring data via the port.

NOTE: Some SCADAPack E-Series models have restrictions on the available ports, modes, functions, and baud rates. See the SCADAPack E-Series Operation Reference Manual for details on these limitations.

ATTENTION: If one of the outstation’s serial ports is being used to communicate with ClearSCADA, the configuration of the port in the ClearSCADA DNP3 SCADAPack E-Series outstation has to match the configuration of the Channel item that ClearSCADA uses to communicate with that outstation. If these configurations differ, communications to the outstation will be lost when ClearSCADA downloads the configuration to that outstation.

  • Data Mode—Displayed when applicable. Use the combo box to specify the number of data bits used to transmit each byte of data and the parity. The options vary, depending on the port’s Function, but comprise a combination of the following:
  • 8-bit No Parity
  • 8-bit Even Parity
  • 8-bit Odd Parity
  • 7-bit Even Parity
  • 7-bit Odd Parity.
  • Data Link Retries—see Configure Data Link Layer Properties.
  • Data Link Confirm Timeout—see Configure Data Link Layer Properties.
  • Data Link Confirm Mode—see Configure Data Link Layer Properties.
  • IP Address—Applies only if the Function of the port is set to PPP/TCPIP. Use to specify the IP Address of the port.
  • Subnet Mask—Applies only if the Function of the port is set to PPP/TCPIP. Use to specify the Subnet Mask of the port.
  • Init String—Applies only if the port Mode is set to Hayes Modem or Hayes Pool. Use to specify the initialization string that is sent to the modem on start-up and at 60 second intervals to check the health of the modem.
  • Dial Prefix—Applies only if the port Mode is set to Hayes Modem or Hayes Pool. Use to specify the prefix that is added to the phone number, in order to force the modem to dial the required number. Specify the actual telephone number in the DNP Route Table (see Add and Configure the Entries in a DNP Route Table).
  • Modem Mode—Applies only if the port Mode is set to Hayes Modem or Hayes Pool. Use the combo box to specify whether the outstation maintains a permanent connection with the remote device, or whether it hangs up the modem if no transmissions occur over the port for a specified period of time. Choose from:
  • Hangup Enabled—The default option. The modem hangs up once no communications traffic has occurred over the port for a specified time. Use the Modem Inactivity Timeout field within the Modem Parameters section of the SCADAPack tab to specify the timeout (see Configure the Modem Parameters).
  • Hangup Disabled—The SCADAPack E-Series outstation maintains a permanent connection with the remote device, until the remote device disconnects.
  • GPRS APN/1xRTT CRM String—Applies only if the port Mode is set to GPRS or 1xRTT. General Packet Radio Service (GPRS) is a service that allows information to be transmitted across a GSM mobile telephone network. 1xRTT is a Radio Packet service that allows information to be transmitted across a CMDA mobile telephone network.

Specify the network-specific setup string that the outstation is to send to the GPRS or 1XRTT modem when the outstation is establishing a connection.

Consult your network operator for the required string.

Example:

“AT+CGDCONT=1, “IP”, “<network name>””

Use the fields in the Port Configuration section of the SCADAPack tab to specify the PAP or CHAP username and password that enable access to the GPRS or 1xRTT network (see Configure the DNP Route Table and Modem Authentication Properties).

  • Low Power Modem—Applies only if the port Mode is set to Hayes Modem or Hayes Pool.

Select the check box if the outstation uses a low power modem. When selected, the Data Terminal Ready (DTR) signal is asserted by the outstation whenever the outstation needs to communicate via the port. Specify the required DTR Delay Time on the Modem Parameters section of the SCADAPack tab (see Configure the Modem Parameters).

Clear the check box if the modem is not set to operate in low power mode.


DNP3 SCADAPack Driver Guide - Configure Data Link Layer Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Data Link Layer Properties

Use the three Data Link Layer properties, located in the Ports section of the Outstation Type tab, to specify how and when the SCADAPack E-Series outstation will retry data link layer frames, and when the outstation will request confirmation of data link layer frames. These properties are only used by the outstation if the Function of the port is set to DNP3 or PPP/TCPIP and the port is used for sending DNP3 frames.

  • Data Link Retries—Specify the number of times that the outstation will resend any data link layer frames for which it has requested a confirm, but for which it does not receive the confirm response within the Data Link Confirm Timeout.
  • Data Link Confirm Timeout—Specify how long the outstation is to wait before re-sending any data link layer frames for which it has requested, but not received, a confirm response. The frames will be re-sent at this frequency, up to the number of times specified by the Data Link Retries field (see above).

Enter the time in the OPC Time Format.

  • Data Link Confirm Mode—Use the combo box to specify when the outstation requests confirmation of transmission of data link layer frames to a DNP3 node. Choose from:
  • Never—The outstation does not request confirmation. This is the recommended option, unless the communications link between the outstation and the DNP3 node is poor.
  • Sometimes—If a message is split into more than one frame, the outstation requests a Data Link confirmation for each frame. If the fragment fits within one frame, the outstation does not request a Data Link confirmation.

This setting is commonly used when the communications network is non-ideal—for example, if the devices are operating in high electromagnetic noise environments.

  • Always—The outstation requests a confirmation for each frame that it sends. This option is rarely used.

NOTE: Data Link Retries and Data Link Confirm Timeout apply only if the Function of the port is set to DNP3 or PPP/TCPIP, and the Data Link Confirm Mode is set to an option other than Never.


DNP3 SCADAPack Driver Guide - Configure the SCADAPack ER-P620 IRIG Mode (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the SCADAPack ER-P620 IRIG Mode

This section only applies if the Outstation Type is set to ‘SCADAPack ER-P620’ (see Specify the Outstation Type).

SCADAPack ER-P620 outstations support IRIG-B time synchronization, whereby the outstation’s time can be synchronized with that of an external IRIG-B time source. IRIG (Inter-Range Instrumentation Group) is a standardization of time codes that allows equipment to be synchronized to a known reference time. Group B is the most commonly used set of these standards.

Use this combo box at the bottom of the Outstation Type tab to specify the outstation’s IRIG Mode:

  • IRIG Disabled—This is the default option. When selected, no ports are used for IRIG-B time synchronization.
  • IRIG Standard—Select this option if the external time source connected to the port supports standard IRIG-B functionality, such as that for IRIG-B000, IRIG-B003, IRIG-B120, IRIG-B122, or IRIG-B123.
  • IRIG IEEE 1344—Select this option if the external time source connected to the port supports IRIG-B IEEE-1344 extensions, such as IRIG-B001, IRIG-B002, or IRIG-B121.

For more information on IRIG support, see the SCADAPack ER Hardware User and Reference Manual.


DNP3 SCADAPack Driver Guide - Specify Whether an Outstation Communicates with Multiple DNP3 Masters (Configuring DNP3 SCADAPack E-Series Outstations)

Specify Whether an Outstation Communicates with Multiple DNP3 Masters

NOTE: A SCADAPack E-Series outstation has to have a multi-master license in order to activate its multi-master functionality.

Use the Extra Masters combo box on the Multiple Masters tab to specify whether a SCADAPack E-Series outstation communicates with more than one DNP3 master.

If an outstation communicates with either One or Two other masters, additional fields are displayed on the Multiple Masters tab, to enable the properties specific to those masters to be specified. (Be aware that if you increase the number of Extra Masters from One to Two, any settings that differ from the defaults will need specifying for both additional masters.)

  • DNP3 Master Address—Use to specify the address of the other DNP3 master with which the outstation communicates.
  • DNP3 Outstation Address—Use to specify the address of the outstation, as used by the above DNP3 master, when communicating with this outstation.

For information on configuring the rest of the fields on the Multiple Masters tab, see Configure the Unsolicited Message Properties that are Specific to a Particular DNP3 Master.

If an outstation is configured to communicate with multiple DNP3 masters, other field(s) become available on the configuration Forms of the points on that outstation, to enable you to Specify the Point Data Class that Applies when Communicating with another DNP3 Master.

Further Information

SCADAPack E-Series Outstations that Communicate with more than one DNP3 Master.


DNP3 SCADAPack Driver Guide - Specify the SCADAPack TCP/IP Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Specify the SCADAPack TCP/IP Properties

Use the fields on the SCADAPack TCP/IP tab of each DNP3 SCADAPack E-Series Outstation Form to:

  • Enable or Disable TCP/IP Functionality
  • Configure General Ethernet Properties
  • Enable TCP/IP Services
  • Configure TCP Service Port Properties
  • Configure Modbus/TCP Unit Identifier
  • Configure Ethernet DNP/IP Properties
  • Configure DNP/IP Parameters
  • Specify IP Route and BOOTP Tables
  • Configure Host DNP/IP Tracking.


DNP3 SCADAPack Driver Guide - Enable or Disable TCP/IP Functionality (Configuring DNP3 SCADAPack E-Series Outstations)

Enable or Disable TCP/IP Functionality

Use the Enabled check box at the top of the SCADAPack TCP/IP tab to specify whether TCP/IP functionality is enabled for the SCADAPack E-Series outstation.

Select the check box for the other fields on the tab to become available.

Ensure that the check box is clear if the outstation does not require TCP/IP support.


DNP3 SCADAPack Driver Guide - Configure General Ethernet Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure General Ethernet Properties

SCADAPack E-Series outstations are supplied with a single or dual Ethernet interface. Use the fields within the Ethernet 1 and, if applicable, the Ethernet 2 sections of the SCADAPack TCP/IP tab to define the general properties for the interface(s).

With an outstation that has only one Ethernet interface, the fields within the Ethernet 2 section of the tab are ‘grayed out’ and unavailable for use.

  • Function—Use the combo box to define the function of each Ethernet interface. The options vary, depending on the Outstation Type (see Specify the Outstation Type), but will include a combination of the following:
  • ES Remote I/O—Enables the Ethernet interface for ES Remote I/O only. The other fields in the Ethernet section are ‘grayed out’ and unavailable for use.
  • TCP/IP + ES Remote I/O—Enables the Ethernet interface for both TCP/IP and ES Remote I/O. This is the default option.
  • TCP/IP Disabled—The Ethernet interface is not used. The other fields in the Ethernet section are ‘grayed out’ and unavailable for use.
  • TCP/IP Enabled—Enables the Ethernet interface for TCP/IP on a SCADAPack 350E or 357E outstation.
  • IP Address—Use to specify an appropriate IP Address for the Ethernet interface.

If the SCADAPack E-Series outstation is to communicate with a TCP/IP device that is not on either of its local Ethernet subnets, you will need to create an IP Route Table with a route entry for the destination device (see Add and Configure the Entries in an IP Route Table). You will need to link the IP Route Table to the outstation (see Specify IP Route and BOOTP Tables).

  • Subnet Mask—Use to specify an appropriate Subnet Mask if the Ethernet interface is to be used for TCP/IP communications.


DNP3 SCADAPack Driver Guide - Enable TCP/IP Services (Configuring DNP3 SCADAPack E-Series Outstations)

Enable TCP/IP Services

By default, only DNP3 communications over UDP and TCP are enabled on a SCADAPack E-Series outstation. A number of other TCP/IP services are available on the outstation.

Use the Enabled TCP/IP Services fields on the SCADAPack TCP/IP tab to specify those IP services that are required on the SCADAPack E-Series outstation.

For each service that is required, select the relevant check box so that it displays a check mark. Ensure that a check box is clear for any services that are not required. The services that you can choose from are:

  • ISaGRAF/TCP—This service permits ISaGRAF Workbench and tools to connect to the outstation via a TCP/IP connection.
  • Modbus/TCP (Client)—This service permits the outstation to communicate with Ethernet PLCs or I/O devices, using the open Modbus/TCP protocol.
  • Modbus/TCP (Server)—This service permits Modbus/TCP clients (for example Ethernet PLCs), to communicate with the outstation using the open Modbus/TCP protocol. The Modbus/TCP server listens to fixed TCP Port 502.

If you select this service, you have to specify the unit address to which the outstation responds (see Configure Modbus/TCP Unit Identifier).

  • Telnet Server—This service enables the outstation’s Telnet Server and permits up to five concurrent users to remotely connect to its Command Line.

NOTE: While multiple users may connect and use the Command Line of a SCADAPack E-Series outstation, only one user may activate Diagnostic output. This includes any connection via a serial port with a Function of Cmd Line (see Configure the Properties of the Individual Ports).

  • FTP Server—This service enables the outstation’s FTP Server and permits multiple users to remotely access its File System using FTP client tools.
  • BOOTP Server—This service enables the outstation’s BOOTP Server, which allows other Ethernet devices to automatically obtain their IP Addresses from the outstation.

If you enable the BOOTP service, you will need to configure a BOOTP Table within ClearSCADA and associate the table with the DNP3 SCADAPack E-Series outstation using the BOOTP Table field at the bottom of the SCADAPack TCP/IP tab (see Specify IP Route and BOOTP Tables).

  • NTP Network Time—Network Time Protocol (NTP) can be used to synchronize the time of the outstation with another NTP server.

A SCADAPack E-Series outstation synchronizing across a LAN to a NTP server using a Global Positioning Service (GPS) receiver can typically provide real time clock accuracy to within a few tens of milliseconds relative to Coordinated Universal Time (UTC). This is more accurate than is possible using DNP3 time synchronization (see Configure the Profiler and ISaGRAF Time Zone Properties).

  • IEC 60870-5-104 Slave—This option is available on DNP3 SCADAPack E-Series outstations, other than 386 eNET outstations.

This service permits the outstation to communicate with a Controlling Station (SCADA master), using the IEC 60870-5-104 protocol.

For more information on any of these IP services, see the documentation supplied with the SCADAPack E-Series outstation.


DNP3 SCADAPack Driver Guide - Configure TCP Service Port Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure TCP Service Port Properties

TCP Service Ports permit SCADAPack E-Series outstations to provide virtual serial ports over a TCP/IP connection. For a port to be used in this way, the port’s Function has to be set to TCP Service (see Configure the Properties of the Individual Ports). You can configure more than one SCADAPack E-Series outstation port to have this function, so providing multiple virtual serial ports. For a SCADAPack E-Series outstation to support TCP Service Port connections from multiple TCP/IP hosts, for example, each host has to connect to a different port (as only one TCP connection per virtual serial port is permitted).

Many ClearSCADA drivers can communicate with serial devices over a TCP/IP link using a TCP Service Port.

Use the fields within the TCP Service Ports section of the SCADAPack TCP/IP tab to define the properties that the SCADAPack E-Series outstation uses for TCP Service Port connections:

  • Base TCP Port—Use to specify the Base TCP Port number that is used for TCP Service Port connections. This number is added to the PDS Serial Port number to derive the actual TCP Port number.

Example:

If the Base TCP Port is set to 50000, and you want to use Port 2 of the outstation as a TCP Serviced Port, your TCP Services Client has to connect to TCP Port 50002.

NOTE: Some SCADAPack E-Series outstation models have Port 4 labelled ‘Diag Port’.

  • Inactivity Timeout—Use this field to specify how long the outstation will retain the TCP connection while data is not being transmitted or received through the virtual serial port.

Enter the time in the OPC Time Format.

ATTENTION: If the TCP Service Port connection is lost/dropped, a SCADAPack E-Series outstation cannot re-establish the connection back to the TCP host when it receives data on the serial port. The connection has to be re-established by the TCP host. Until the connection is re-established, data received on the serial port is discarded (data is not buffered).

A SCADAPack E-Series outstation can also be configured as a TCP Services Port Client. In this mode, the outstation establishes the TCP connection to a TCP Services Port Server. See the SCADAPack E-Series TCP/IP Technical User and Reference Manual for further information.


DNP3 SCADAPack Driver Guide - Configure Modbus/TCP Unit Identifier (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Modbus/TCP Unit Identifier

Use the Unit Identifier field within the Modbus TCP Server section of the SCADAPack TCP/IP tab to specify the Modbus/TCP Unit Address of the SCADAPack E-Series outstation.

For a SCADAPack E-Series outstation to operate as a Modbus/TCP server, you have to select the Modbus/TCP (Server) service within the Enabled TCP/IP Services section of the SCADAPack TCP/IP tab (see Enable TCP/IP Services), otherwise the setting of this field is ignored.


DNP3 SCADAPack Driver Guide - Configure Ethernet DNP/IP Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Ethernet DNP/IP Properties

Use the fields in the Ethernet DNP/IP section of the SCADAPack TCP/IP tab to specify the DNP3 Data Link configuration for frames transmitted through either of the SCADAPack E-Series outstation’s ethernet ports.

For information on configuring these properties, see Configure Data Link Layer Properties.


DNP3 SCADAPack Driver Guide - Configure DNP/IP Parameters (Configuring DNP3 SCADAPack E-Series Outstations)

Configure DNP/IP Parameters

Use the fields in the DNP/IP Parameters section of the SCADAPack TCP/IP tab to specify the default DNP3 over IP properties for the SCADAPack E-Series outstation.

  • DNP3-TCP Keep-Alive—Specify how often a DNP3 Link Status test message is transmitted across the active TCP socket to help ensure that the link remains active. If the timer is not required, set the value to zero.

Enter the time in the OPC Time Format.

  • Default DNP3 Transport—Use the combo box to specify the default transport protocol that is to be used to transmit outbound (initiating) DNP3 frames across LAN/WAN links. Response frames use the same protocol as the initiating frames. Choose from:
  • TCP—Use Transmission Control Protocol (TCP), a connection-orientated transport protocol
  • UDP—Use User Datagram Protocol (UDP), a connection-less transport protocol.
  • Default DNP3 Port—Specify the TCP/UDP port number to which DNP3 frames are sent and from which they are received. The default is 20000, which is the IETF assigned port number used by the DNP3 protocol.


DNP3 SCADAPack Driver Guide - Specify IP Route and BOOTP Tables (Configuring DNP3 SCADAPack E-Series Outstations)

Specify IP Route and BOOTP Tables

Use the IP Route Table and BOOTP Table fields on the SCADAPack TCP/IP tab to associate an IP Route Table and/or a BOOTP Table with the SCADAPack E-Series outstation.

  • IP Route Table—You need to configure and associate an IP Route Table with the SCADAPack E-Series outstation if the outstation is to:
  • Communicate with TCP/IP hosts that are not on the local subnet
  • Route TCP/IP packets between networks.

Select the browse button to display a Reference browse window and select the required route table. (For information on configuring IP Route Tables, see Configuring DNP3 SCADAPack Tables.)

Leave this field blank if an IP Route Table is not required.

  • BOOTP Table—You need to configure and associate a BOOTP Table with the outstation if you want to use the outstation’s BOOTP Server to allocate IP addresses to BOOTP Clients.

Select the browse button to display a Reference browse window and select the required BOOTP table. (For information on configuring BOOTP Tables, see Configuring DNP3 SCADAPack Tables.)

Leave this field blank if a BOOTP Table is not required.


DNP3 SCADAPack Driver Guide - Configure Host DNP/IP Tracking (Configuring DNP3 SCADAPack E-Series Outstations)

Configure Host DNP/IP Tracking

Use the fields on the Host DNP/IP Tracking section of the SCADAPack TCP/IP tab to specify up to four DNP3 address(es) for which the SCADAPack E-Series outstation tracks the IP Address.

When the SCADAPack E-Series outstation receives a DNP3 frame addressed to it from one of the above DNP3 addresses, it updates the corresponding host IP address system string point with the IP Address of the source DNP3 node (see the SCADAPack E-Series TCP/IP Technical User and Reference Manual for the point numbers). The host IP address system string points can be read by an ISaGRAF application running in the SCADAPack E-Series outstation, which may then perform actions based in the IP Address (for example modifying the DNP Route Table in a redundant gateway setup).

The outstation only tracks the IP Addresses of DNP3 frames with a Destination Address that matches the SCADAPack E-Series outstation’s DNP3 Address. DNP3 frames with a Source Address that matches any of the Host Address fields that are routed through the outstation to another DNP3 host, do not cause the corresponding Host IP Address System Point to be updated. The SCADAPack E-Series outstation’s DNP3 Route Table does track the host IP address for DNP3 frames routed through the outstation (see the DNP3 Networking section of the SCADAPack E-Series DNP3 Technical User and Reference Manual).


DNP3 SCADAPack Driver Guide - Specify the X.29/TC Comms Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Specify the X.29/TC Comms Properties

This section only applies to SCADAPack E-Series outstations that are used to route data between an X.29 Packet Assembler/Disassembler (PAD) and suitable remote packet-mode device(s) and/or other PAD(s).

To enable such functionality, at least one of the outstation’s serial ports has to have its Mode set to X.29 (see Configure the Properties of the Individual Ports).

Use the fields on the X.29/TC Comms tab of each DNP3 SCADAPack E-Series Outstation Form to:

  • Enable or Disable X.29/TC Comms Functionality
  • Configure the Telemetry Computer Properties
  • Configure the X.29 Parameters.

For more information on the X.29 communication driver interface, see the PDS v7 Series Telemetry X.29 RTU Communication Interface Manual.


DNP3 SCADAPack Driver Guide - Enable or Disable X.29/TC Comms Functionality (Configuring DNP3 SCADAPack E-Series Outstations)

Enable or Disable X.29/TC Comms Functionality

Select the Enabled check box on the X.29/TC Comms tab if the SCADAPack E-Series outstation is to route data between an X.29 Packet Assembler/Disassembler (PAD) and remote packet-mode device(s) and/or other PAD(s).

When the Enabled check box is selected, other fields on the X.29/TC Comms tab become available for use.

Use the fields to:

  • Configure the Telemetry Computer Properties
  • Configure the X.29 Parameters.

Ensure that the Enabled check box is clear if the outstation is not being used to communicate using the X.29 communication driver interface.


DNP3 SCADAPack Driver Guide - Configure the Telemetry Computer Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Telemetry Computer Properties

Use the fields within the Telemetry Computer Configuration section of the X.29/TC Comms table to specify the connection properties of up to four DNP3 master station servers that are running the X.29 Packet Assembler/Disassembler (PAD) software. The servers are also known as Telemetry Computers (TCs).

For greatest efficiency, enter the most frequently contacted Telemetry Computer’s details in the left-most column, followed by the next most frequently contacted TC, as the X.29 driver processes the entries in order, from left to right.

  • Telemetry Computer Number—Specify the identification number of the DNP3 master station server.
  • PSTN Dial String—The outstation will normally communicate with each Telemetry Computer using serial comms. Depending on the system setup, the outstation may be able to ‘fall back’ to using a dial-up modem to communicate with the Telemetry Computer should the serial communications be detected as failed. If the outstation is configured to ‘fall back’, use the PSTN Dial String field to specify the telephone number that the outstation should use to contact the Telemetry Computer.
  • X.25 Address—Use to specify the Telemetry Computer’s X.25 address. The address must be between 3 and 15 characters long.

Each DNP3 message that the outstation receives via its X.29-assigned serial port(s) includes an X.25 address. The outstation stores the messages in its internal driver list until it connects to the Telemetry Computer that is assigned that particular X.25 address. Once connected, it sends the messages that have the corresponding X.25 address to that device.


DNP3 SCADAPack Driver Guide - Configure the X.29 Parameters (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the X.29 Parameters

Use the fields within the X.29 Parameters section of the X.29/Comms tab to specify the X.29 timeouts and intervals. The settings apply to each outstation port that is configured to communicate using the X.29 communication driver interface.

  • Peer Inactivity Timeout—Specify the time after which the outstation will disconnect an X.25 connection if:
  • that connection is to a DNP3 address of a device other than the outstation’s DNP3 master(s)

and:

  • no DNP3 messages have been received or sent via the connection for the length of the Peer Inactivity Timeout period.

A ‘peer’ device is a device other than a Telemetry Computer (master station communications server).

The default is 10S (10 seconds).

  • Telemetry Computer Inactivity Timeout—Specify the time after which the outstation will disconnect an X.25 connection if:
  • that connection is to the DNP3 address of one of the outstation’s DNP3 masters

and:

  • no DNP3 messages have been received or sent via the connection for the length of the Telemetry Computer Inactivity Timeout period.

The default is 30S (30 seconds).

  • Message Tx Timeout—Specify the amount of time that the X.29 driver will retain a message in its internal driver list, while waiting for a connection to be made.

If a connection to the relevant device is made within the timeout period, the driver will attempt to deliver the message to that device.

If the Message Tx Timeout is exceeded before the connection can be made, the driver will delete the message without delivering it.

The default is 30S (30 seconds).

  • Status Poll Time—Specify the frequency with which the outstation sends Status Poll messages to the X.29 Packet Assembler/Disassembler (PAD), to check that the PAD’s status. The PAD software runs on each of the Telemetry Computers listed within the Telemetry Computer Configuration section of the X.29/TC Comms tab (see Configure the Telemetry Computer Properties).

The default is 14S (14 seconds).

  • Drop DTR Time—In order to successfully establish an X.29 communications link, the RS232 modem’s Data Carrier Detect (DCD) line has to be asserted. If it is found that the DCD line is not asserted, the RS232 Data Terminal Ready (DTR) line is lowered for 1.5 seconds then raised again in an attempt to force the modem to re-establish the connection.

Use the Drop DTR Time field to specify the frequency (in seconds) at which the state of the DCD line is rechecked, and the process repeated if necessary, should the DCD line not be asserted.

The default is 1M1S (61 seconds).


DNP3 SCADAPack Driver Guide - Specify the Remote DNP3 Device Properties (Configuring DNP3 SCADAPack E-Series Outstations)

Specify the Remote DNP3 Device Properties

Use the fields on the Remote DNP3 Device tab of each DNP3 SCADAPack Remote E-Series Outstation, or DNP3 SCADAPack Remote DNP3 Device Form to:

  • Specify a Remote Outstation’s Parent Outstation
  • Specify Whether ClearSCADA can Address a Remote Outstation Directly
  • Specify Which Devices Scan a Remote Outstation
  • Configure the Data Concentrator Polling
  • Configure the Data Concentrator Status and Control Points.

On a DNP3 SCADAPack Remote E-Series Outstation, also use the Remote DNP3 Device tab to:

  • Specify Whether the DNP3 Master Address is Inherited from the Outstation Set.


DNP3 SCADAPack Driver Guide - Specify a Remote Outstation's Parent Outstation (Configuring DNP3 SCADAPack E-Series Outstations)

Specify a Remote Outstation’s Parent Outstation

The DNP3 SCADAPack E-Series driver communicates with each DNP3 SCADAPack Remote DNP3 Device or DNP3 SCADAPack Remote E-Series outstation via that device’s parent outstation (see SCADAPack E-Series Data Concentrators and Remote Outstations).

Use the Parent Outstation combo box on the Remote DNP3 Device tab to specify a remote device’s parent outstation.

Select the field’s browse button to display a Reference browse window. Select the required SCADAPack E-Series outstation from the window. Depending on the system setup, the parent outstation (‘data concentrator’) can be a DNP3 SCADAPack E-Series Direct, PSTN, or Shared outstation.


DNP3 SCADAPack Driver Guide - Specify Whether ClearSCADA can Address a Remote Outstation Directly (Configuring DNP3 SCADAPack E-Series Outstations)

Specify Whether ClearSCADA can Address a Remote Outstation Directly

Use the Master Station Addressable check box on the Remote DNP3 Device tab to specify whether ClearSCADA can communicate with this remote outstation directly.

Select the check box if ClearSCADA is able to address the remote outstation directly. You might select this check box, for instance, if ClearSCADA is to reset the remote, perform file transfers, control the remote outstation, or for ClearSCADA to scan the remote outstation in a similar way to other SCADAPack E-Series or generic DNP3 outstations. Communications are transmitted ‘transparently’ via the remote outstation’s parent outstation (data concentrator). Both the data concentrator and the remote outstation have to be In Service and have valid configuration and healthy comms, in order for ClearSCADA to scan the remote outstation successfully. Additionally, the data concentrator’s DNP3 Route Table has to correctly specify how the remote outstations are connected to the data concentrator (see Route DNP3 Frames Using a DNP Route Table).

Ensure that the check box is clear if the remote outstation’s parent outstation (data concentrator) is to scan the remote outstation for data, then pass that data to ClearSCADA. With this setup, the data concentrator polls its various remote outstations and processes that data before passing the relevant information to ClearSCADA. In addition to the relevant ClearSCADA configuration, a SCADAPack E-Series outstation has to be suitably licensed in order to provide data concentrator functionality. If communications between ClearSCADA and the data concentrator are lost, the data concentrator will continue to scan its remote outstations for data. Once communications with ClearSCADA are re-established, the relevant data will be passed to the ClearSCADA server.

Use the tab’s Polled By field to Specify Which Devices Scan a Remote Outstation.

Further Information

SCADAPack E-Series Data Concentrators and Remote Outstations.


DNP3 SCADAPack Driver Guide - Specify Which Devices Scan a Remote Outstation (Configuring DNP3 SCADAPack E-Series Outstations)

Specify Which Devices Scan a Remote Outstation

Use the Polled by combo box on the Remote DNP3 Device tab to specify which device(s) are to scan (poll) this remote outstation. The options that are available depend on whether the Master Station Addressable check box is selected (see Specify Whether ClearSCADA can Address a Remote Outstation Directly). Be aware that the association of a point with a DNP3 SCADAPack E-Series outstation differs in the ClearSCADA database, depending on whether that point is scanned by ClearSCADA or a data concentrator (see With Which Database Item do I Associate each DNP3 SCADAPack Point?).

  • Data Concentrator—The remote outstation’s parent outstation (data concentrator) is the only device that scans this remote outstation.

When a remote outstation is Polled By a Data Concentrator, ClearSCADA ignores any configuration specified on the remote’s DNP3 tab, other then that of the Address field. Instead, the fields on the Remote DNP3 Device tab are used to determine how the remote is scanned for data. Use the rest of the fields on the Remote DNP3 Device tab to:

  • Configure the Data Concentrator Polling
  • Configure the Data Concentrator Status and Control Points.
  • Master Station—Only available if the Master Station Addressable check box is selected (see Specify Whether ClearSCADA can Address a Remote Outstation Directly). Select this option if ClearSCADA, rather than the remote’s parent outstation, is to scan the remote outstation. You might select this option if one or more remote outstations are connected to a DNP3 SCADAPack E-Series outstation, but you want ClearSCADA to communicate with those remote outstations ‘transparently’ through their parent outstation.

Other fields on the Remote DNP3 Device tab are ‘grayed out’ and unavailable for use, as the remote outstation is treated as any other generic DNP3 or SCADAPack E-Series outstation, other then that communications are transmitted ‘transparently’ through its parent outstation. The fields on the remote’s DNP3 tab determine how ClearSCADA scans the remote for data (see Configuring a DNP3 Outstation in the ClearSCADA Guide to the DNP3 Driver).

  • Data Concentrator and Master Station—Only available if the Master Station Addressable check box is selected. Select this option if the remote’s parent outstation is to scan some of the remote outstation’s points, and ClearSCADA is to scan other points on the remote outstation directly.

Also select this option if either the data concentrator or ClearSCADA are to be able to scan the same point(s) on the remote outstation. (In which case, two points will need creating in the ClearSCADA database for each item of data that can be scanned by both devices (see With Which Database Item do I Associate each DNP3 SCADAPack Point?).)

Use the rest of the fields on the Remote DNP3 Device tab to:

  • Configure the Data Concentrator Polling
  • Configure the Data Concentrator Status and Control Points.

Use the fields on the remote’s DNP3 tab to determine how ClearSCADA scans the remote for data (see Configuring a DNP3 Outstation in the ClearSCADA Guide to the DNP3 Driver).


DNP3 SCADAPack Driver Guide - Configure the Data Concentrator Polling (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Data Concentrator Polling

Use the fields within the Data Concentrator Polling section of the Remote DNP3 Device tab to specify the scanning regime of the remote outstation’s parent outstation (a data concentrator).

The fields within this section are ‘grayed out’ and unavailable for use if the Polled By field is set to Master Station (see Specify Which Devices Scan a Remote Outstation).

Where a remote outstation is polled by both its parent outstation and the ClearSCADA server, the properties within this Data Concentrator Polling section only apply to polls undertaken by the parent outstation. (The fields on the remote outstation’s DNP3 tab define the scanning regime undertaken by the ClearSCADA server (see Configuring a DNP3 Outstation in the ClearSCADA Guide to the DNP3 Driver).)

  • Type—Use this combo box to specify the polling regime that the parent outstation (data concentrator) performs on this remote outstation.

Choose from:

  • No Poll—Select this entry only if a remote outstation is not active. For example, if the device is being replaced, or has a known fault. When selected, the data concentrator will not scan the remote device for data; any unsolicited messages sent by the remote device will be ignored.

When this option is selected, the Poll Rate fields will be ‘grayed out’ and unavailable for use.

  • Background Poll—Select this option for the data concentrator to perform an Integrity poll of the remote outstation at the rate specified in the Poll Rate 2 field (see below). An Integrity poll is also performed if transmissions between the data concentrator and this remote outstation have not occurred within the ‘Background Poll’ interval (specified using the Poll Rate 1 field (see below). Such communications include any unsolicited messages sent by the remote.

Example:

A Remote E-Series Outstation has this configuration:

Polled By: Data Concentrator
Type: Background Poll
Poll Rate 1: 10S (A 10-second Background poll rate)
Poll Rate 2: 30S (A 30-second Must Poll rate)

This configuration results in the data concentrator polling the remote outstation every 30 seconds, regardless of the communications activity between the two devices. Additionally, the data concentrator polls the remote for data at 10-second intervals if no other communications occur within that time.

  • Ratio Poll—The data concentrator undertakes a combination of separate Integrity polls and event polls. The number of event polls that are performed in relation to the number of Integrity polls is user configurable.

Use the Poll Rate 1 field (see below) to specify interval between successive polls of any type.

Use the Event Polls field to specify the number of Class 1, 2, and 3 event polls that the data concentrator performs between each Integrity poll. (An Integrity poll is a request for Class 1, 2, and 3 event data and Class 0 static (current) data.)

Example:

A Remote E-Series Outstation has this configuration:

Polled By: Data Concentrator
Type: Ratio Poll
Poll Rate 1: 30S (30 seconds)
Event Polls: 2

This configuration results in the data concentrator polling the remote outstation every 30 seconds. Every 3rd poll is an Integrity poll; in between which the data concentrator performs two polls for Class 1, 2, and 3 event data.

  • Class Poll—The data concentrator sends requests for the remote outstation’s event data and current value data. The remote outstation reports any event data that is stored in its internal buffer(s), followed by its static (current value) data.

Use the Poll Rate n fields below to specify that rate at which the data concentrator requests each type of data.

  • Static Only Poll—The data concentrator only sends requests for the remote outstation’s static (current value) data. Any DNP3 Class Data Available IIN bits reported by the remote are ignored, however the data concentrator will process any event data that it receives in any unsolicited messages that are sent by the remote.

Use this option to provide basic multi-master support for remote devices that do not support multi-master operation. Use the option in situations where another DNP3 master polls the remote for data, in addition to the data concentrator.

Use the Poll Rate 1 field (see below) to specify rate at which the data concentrator polls the remote outstation for Class 0 static (current) data.

ATTENTION: The DNP3 standard dictates that data for a DNP3 point has to be transmitted in chronological order. If you configure a point in the remote outstation to generate DNP3 events that are sent to the data concentrator, it is not advisable to perform Static Only Polls of the remote outstation. (A Static Only Poll of a point will return the point’s current value without any preceding DNP3 event data. It is therefore possible to return the value of such a point out-of-order.)

  • Set Time—Select this check box if the data concentrator is to set the clock in this remote outstation whenever its DNP3 Need Time IIN bit is set.

Ensure the check box is clear if the remote outstation’s clock is to be set by other means. We recommend that the check box be left clear if the Type is set to Static Only Poll.

  • Maximum Poll Errors—Use to specify the maximum number of unsuccessful attempts to poll the remote outstation that have to occur for the remote device to be deemed to have failed. Should the remote device fail, the data concentrator will start transmitting the message defined in the Health Check Type field (see below) at the Health Check Poll Rate until the remote outstation responds. Additionally, the remote’s Outstation Status point will be set to indicate that the data concentrator has lost comms with the remote. This status point is specified within the Data Concentrator Status and Control Points section of the Remote DNP3 Device tab (see Configure the Data Concentrator Status and Control Points).
  • Application Layer Timeout—Use to specify the timeout that applies to Application Layer messages (Class Poll requests) that the data concentrator sends to the remote device. Specify 0 for the data concentrator’s default application layer timeout to apply (as specified using the Complete Fragment Timeout field on the SCADAPack tab (see Configure Application Layer Properties). The timeout restarts whenever the data concentrator receives a valid message from the remote.
  • Poll Rate n—The functionality of the four Poll Rate fields differs, depending on the poll Type (see above). Use the table below to ascertain each field’s function, then specify each rate in the OPC Time Format. In each case, you can specify the required rate directly in the field, or use the Interval Window (accessed via each field’s browse button) to specify the required value.

    Poll Rate Field and Function

    Poll Type

    Poll Rate 1

    Poll Rate 2

    Poll Rate 3

    Poll Rate 4

    Background Poll

    Use to specify the Background poll rate.

    (Typically set to a value less than the Must Poll rate.)

    Use to specify the Must Poll rate.

    (Typically set to a value greater than the Background poll rate.)

    Not used.

    Not used.

    Ratio Poll

    Use to specify the interval between successive polls.

    Not used.

    Not used.

    Not used.

    Class Poll

    Use to specify the Class 1 poll rate.

    (0 indicates no polling of events in this class.)

    Use to specify the Class 2 poll rate.

    (0 indicates no polling of events in this class.)

    Use to specify the Class 3 poll rate.

    (0 indicates no polling of events in this class.)

    Use to specify the Integrity poll rate.

    Static Only Poll

    Use to specify the Class 0 static data poll rate.

    Not used.

    Not used.

    Not used.
  • Event Polls—Applies only if the polling Type is set to Ratio Poll (see above). Use this field to specify the number of event polls that the data concentrator is to perform between each successive Integrity poll.
  • Health Check Poll Rate—Specify the rate at which the data concentrator attempts to poll this remote outstation, should the remote fail. The remote is deemed to have failed if its Maximum Poll Errors limit is reached (see above).

Specify the interval in the OPC Time Format.

  • Health Check Type—Use this combo box to specify the type of message that the data concentrator should send to this remote outstation, in order to re-establish communications once the remote outstation has recovered from any failure. Choose from:
  • Delay Measurement—This option has the smallest request and response size and is therefore the default option. Select this option in preference to the others, if communications are to be checked with many remote outstations simultaneously. This reduces the load on the communications network and the data concentrator.
  • Class 0 Poll—The data concentrator sends a request for this remote outstation’s Class 0 static (current value) data.
  • Event Poll—The data concentrator sends a request for any Class 1, 2, and 3 event data that is stored in this remote outstation’s internal Event Buffer(s).
  • Multiple Fragment Response—Select this check box if the remote outstation can send multiple fragment responses.

Clear the check box if the remote outstation does not support multiple fragment responses. The data concentrator will send a further Integrity poll request to the remote whenever it receives a full fragment poll response with no DNP3 Class Data Available IIN bit(s) reported. The data concentrator is deemed to have retrieved all of the static (current value) data from the remote once it has received two consecutive application fragments in which no DNP3 Class Data Available IIN bits are set.

For more information on data concentrator polling, see the SCADAPack E-Series Data Concentrator Technical User Reference manual.


DNP3 SCADAPack Driver Guide - Configure the Data Concentrator Status and Control Points (Configuring DNP3 SCADAPack E-Series Outstations)

Configure the Data Concentrator Status and Control Points

Use the fields within the Data Concentrator Status and Control Points section of the Remote DNP3 Device tab to specify the points that the remote outstation’s parent outstation (data concentrator) uses to control or monitor the status of this remote outstation. You can only specify points that have their Point Type set to User (Derived), and have their Outstation specified as this remote outstation’s parent outstation.

The fields within this section are ‘grayed out’ and unavailable for use if the Polled By field is set to Master Station (see Specify Which Devices Scan a Remote Outstation).

Where a remote outstation is polled by both its parent outstation and the ClearSCADA server, the properties within this Data Concentrator Status and Control Points section only apply to the remote’s parent outstation.

The fields on the left-hand side of the Data Concentrator Status and Control Points section of the tab are used to specify the DNP3 SCADAPack binary or pulse points that the data concentrator uses to control activity on this remote outstation.

The Point Numbers of the points in these fields have to be consecutive, with the Service Control Point having the lowest Point Number (n), the Force Event Poll point having the Point Number (n + 1), and so on. In each case, the point has to have its Point Type set to User (Derived) in order to be a valid control point (see Configure Common Properties of DNP3 SCADAPack Points).

Use the First Binary Control Point field to specify the Point Number of the Service Control Point. Providing that the points exist in the database, ClearSCADA will automatically populate the entries in the left-hand block of fields, once you specify this Point Number and save the configuration. As with other configuration in ClearSCADA, a message area will be displayed at the bottom of the Form should any of the control points have invalid configuration (such as an incorrect Point Type).

NOTE: If the remote outstation is in an Instance of a Group Template, enable the appropriate Property Overrides to allow the First Binary Control Point to be specified on a per-Instance basis.

The points are allocated in ascending address order, as follows:

  • Service Control Point—The binary point that controls scanning of this remote outstation by the data concentrator. The data concentrator polls the remote whenever this point has a value of 1. Controlling the point to a value of 0 will cause polling to stop.
  • Force Event Poll—The NULL Pulse Action that is used to trigger a Class 1, 2, and 3 event poll of this remote outstation. A positive pulse triggers the poll.
  • Force Integrity Poll—The NULL Pulse Action that is used to trigger an Integrity poll of this remote outstation. A positive pulse triggers the poll.
  • Force Warm Restart—The NULL Pulse Action that is used to trigger a Warm Reset request. A positive pulse triggers the request.
  • Force Cold Restart—The NULL Pulse Action that is used to trigger a Cold Reset request. A positive pulse triggers the request.
  • Spare—Any other binary points that exist within the DNP3 point number range n + 5 to n + 9 (where n is the point number specified in the First Binary Control Point field). The functionality of these points is undefined in the outstation.

The fields on the right-hand side of the Data Concentrator Status and Control Points section of the Remote DNP3 Device tab are used to specify the DNP3 SCADAPack analog points that monitor the poll (scan) status of this remote outstation.

The Point Numbers of the points in these fields have to be consecutive, with the Poll Counter point having the lowest Point Number (n), the Poll Response Error Counter point having the Point Number (n + 1), and so on. If any statuses are not being modified and those fields are therefore left blank, the Point Numbers of the points specified in the remaining fields have to continue the Point Number run as if all fields were populated. So if the Poll Counter point has Point Number n, the Point Numbers have to increment consecutively, culminating with the point used to monitor Poll 4 Countdown, which has to have the Point Number n + 8 (or the Spare point, if one exists, that has the Point Number n + 9). The point in each has to must have its Point Type set to User (Derived) in order to be a valid status point (see Configure Common Properties of DNP3 SCADAPack Points).

Again, providing that the points exist in the database, ClearSCADA will automatically populate the entries in this block of fields, once you specify the address of the First Analog Status Point and save the configuration. The address that you specify in the First Analog Status Point field has to be the address of the point that will be used as the Poll Counter.

NOTE: If the remote outstation is in an Instance of a Group Template, enable the appropriate Property Overrides to allow the First Analog Status Point to be specified on a per-Instance basis.

ClearSCADA will then assign the block of points, in ascending address order, as follows:

  • Poll Counter—The analog point that is used to monitor the number of successful polls of this remote outstation.
  • Poll Response Error Counter—The analog point that is used to monitor the number of unsuccessful polls (poll requests that the data concentrator has sent to this remote outstation, but that have not resulted in a successful poll).
  • Unsolicited Response Counter—The analog point that is used to monitor the number of unsolicited messages that the data concentrator has received from this remote outstation.

NOTE: To reset the Poll Counter, Poll Response Error Counter, or Unsolicited Response Counter from ClearSCADA, configure a DNP3 SCADAPack Analog Output point in the database and use that point to control the counter value to zero (or whichever value is required).

  • Outstation Status—The analog point that indicates the current status of this remote outstation, as received by the data concentrator. This analog point should be configured to have the following values:
  • 0—Outstation Not Found
  • 1—Finding Outstation
  • 2—Initializing Outstation
  • 3—Failed Communications
  • 4—Outstation Online
  • 5—Outstation Disabled.

For more information on the status that these values represent, see the SCADAPack E-Series Data Concentrator Technical User Reference Manual.

  • Reported IIN—The analog point that indicates the latest remote outstation IIN value to be received by the data concentrator.
  • Poll n Countdown—The analog points in the Poll 1 Countdown to Poll 4 Countdown fields are used to indicate the time left, in seconds, before the data concentrator sends specific poll requests to this remote outstation. Each countdown is for the corresponding poll that is represented by the Poll Rate 1 to Poll Rate 4 fields, in the Data Concentrator Polling section of the tab (see Configure the Data Concentrator Polling). The type of poll undertaken differs, depending on the specified poll Type.

Example:

A Remote E-Series Outstation has this configuration:

Polled By: Data Concentrator
Type: Background Poll
Poll Rate 1: 10S (A 10-second Background poll rate)
Poll Rate 2: 30S (A 30-second Must Poll rate)

With this configuration, analog points need specifying in just the Poll 1 Countdown and Poll 2 Countdown fields—the other countdown fields can be left blank. The point specified in the Poll 1 Countdown field will monitor the time left before the data concentrator undertakes the next background poll of the remote outstation (as per the Poll Rate 1 field). The point specified in the Poll 2 Countdown field will monitor the time left before the data concentrator undertakes the next ‘Must Poll’ Integrity poll (as per the Poll Rate 2 field).

Another Remote E-Series Outstation has this configuration:

Polled By: Data Concentrator
Type: Class Poll
Poll Rate 1: 20S (A 20-second Class 1 event poll)
Poll Rate 2: 30S (A 30-second Class 2 event poll)
Poll Rate 3: 40S (A 40-second Class 3 event poll)
Poll Rate 4: 50S (A 50-second Integrity poll)

With this configuration, an analog point needs specifying in each of the four Poll n Countdown fields. The point specified in the Poll 1 Countdown field will monitor the time left before the data concentrator undertakes the next Class 1 event poll of the remote outstation (as per the Poll Rate 1 field); the point specified in the Poll 2 Countdown field will monitor the time left before the data concentrator undertakes the next Class 2 event poll (as per the Poll Rate 2 field), and so on.

  • Spare—Any analog point that exists with the Point Number n + 9 (where n is the point number specified in the First Analog Status Point field). The functionality of this point is undefined in the outstation.

For more information on status and control points, see the SCADAPack E-Series Data Concentrator Technical User Reference Manual.


DNP3 SCADAPack Driver Guide - Specify Whether the DNP3 Master Address is Inherited from the Outstation Set (Configuring DNP3 SCADAPack E-Series Outstations)

Specify Whether the DNP3 Master Address is Inherited from the Outstation Set

This section applies to DNP3 SCADAPack Remote E-Series Outstations only.

Use the fields at the bottom of the Remote DNP3 Device tab to specify these properties:

  • Override DNP3 Master Address—Ensure that this check box is clear (the default) if the remote’s DNP3 Master 1 Address is the DNP3 address that is specified for the DNP3 Outstation Set.

Select the check box to specify a different DNP3 Master Address to that of the remote’s outstation set.

  • DNP3 Master Address—Only available if the Override DNP3 Master Address check box is selected. Use the field to specify the DNP3 address of the remote E-Series outstation’s primary DNP3 master.


DNP3 SCADAPack Driver Guide - Configuring I/O Expansion Cards and Modules

Configuring I/O Expansion Cards and Modules

SCADAPack ER-P600 and SCADAPack ER-P620 outstations do not have on-board I/O. Instead, separate cards or modules that are connected to the outstation are used to provide the required I/O (input points and/or output points).

SCADAPack 330E, 334E, 350E and 357E outstations do have basic on-board I/O. However, unlike on-board I/O on other SCADAPack E-Series outstations, that I/O is not automatically assigned any DNP3 Point Numbers. To represent such I/O cards in ClearSCADA, you need to configure a DNP3 SCADAPack 5000 Series IO item in the database for each on-board I/O card on a SCADAPack 330E, 334E, 350E or 357E outstation.

If any type of SCADAPack E-Series outstation requires separate I/O cards or modules, or the number of I/O (points) on a SCADAPack E-Series outstation have been expanded by adding additional module(s) or card(s) to that outstation, you need to configure DNP3 SCADAPack IO items in the ClearSCADA database, to represent those modules or cards. (You need only configure a SCADAPack ES Remote IO item in the database if the default automatic allocation of I/O is not suitable—for instance, if you want to specify different Point Numbers to those that would otherwise be assigned.)

You need to add and configure one DNP3 SCADAPack IO item of the appropriate type, for each separate I/O module or card that is connected to a SCADAPack E-Series outstation. You also need to add one DNP3 SCADAPack point in the database for each input or output on that module or card. (Use the fields on each Point Form’s Mapping tab to reference the I/O unit with which each point is associated (see Specify any Point Mapping).)

The type of DNP3 SCADAPack IO item that you need to add to ClearSCADA varies, depending on the type of SCADAPack E-Series outstation and the type of I/O unit that is connected to that outstation:
Type of SCADAPack E-Series Outstation to which the I/O is Connected | Type of IO Unit/ DNP3 SCADAPack IO Database Item that is Supported
SCADAPack 330E SCADAPack 334E SCADAPack 350E SCADAPack 357E | SCADAPack 5000 Series IO
SCADAPack ER-P600 SCADAPack ER-P620 | SCADAPack ER IO, or SCADAPack ES Remote IO
SCADAPack ES | SCADAPack 5000 Series IO, or SCADAPack ES Remote IO
SCADAPack 386 eNET | SCADAPack ES Remote IO

(A SCADAPack ES Remote IO module is a SCADAPack E-Series outstation that is used as an I/O expansion module. When used in this way, the outstation performs as a ‘dumb’ outstation, in that it provides facilities for monitoring and controlling I/O, but does not provide other outstation functionality such as ISaGRAF or Trend Sampler processing (such functionality cannot be configured on an E-Series outstation that is used as an I/O expansion module).)

You configure each DNP3 SCADAPack IO database item using the relevant DNP3 SCADAPack IO Form. Each Form has several tabs.

Use the Identification tab to optionally define a Help View and to indicate whether the item is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).

Use the User Methods tab to define any custom pick actions (‘methods’) for the item (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).

Use the 5000 Series tab on the SCADAPack 5000 Series IO Form to Configure the 5000 Series I/O Properties.

Use the ER I/O tab on the SCADAPack ER IO Form to Configure the ER I/O Properties.

Use the SCADAPack ES Remote I/O tab on the SCADAPack ES Remote IO Form to Configure the SCADAPack ES Remote I/O Properties.


DNP3 SCADAPack Driver Guide - Configure the 5000 Series I/O Properties (Configuring I/O Expansion Cards and Modules)

Configure the 5000 Series I/O Properties

Unlike the on-board I/O on other SCADAPack E-Series outstations, on-board I/O on SCADAPack 330E, 334E, 350E and 357E outstations are not automatically assigned any DNP3 Point Numbers. As such, in the ClearSCADA database you need to configure a DNP3 SCADAPack 5000 Series IO item for each on-board I/O card on a 330E, 334E, 350E or 357E outstation, in addition to one for each expansion card on that type of outstation.

Use the fields at the top of the 5000 Series tab on the DNP3 SCADAPack 5000 Series IO Form to configure these module-specific properties:

  • Outstation—Use to Specify the SCADAPack Outstation with Which the I/O is Associated.
  • Module Type—Use this combo box to specify the type of input or output module that this particular SCADAPack IO item represents.

The options vary, depending on the Outstation Type of the Outstation specified in the field above.

  • Module Address—Use the spin box to specify the address of the I/O module.

This field is ‘grayed out’ and unavailable for use if the Module Type is set to 5209 SCADAPack 350/357E base I/O, or 5210 SCADAPack 330/334 Base I/O 3 Counters.

  • Status Point—Use to specify the binary point that is to indicate the communications status of the I/O module. The point has to exist on the Outstation to which the I/O module is connected. The point’s Point Type has to be set to User (Derived) (see Configure Common Properties of DNP3 SCADAPack Points).

A Status Point is optional. If such a point is configured and is specified in this field, the point is used to indicate the ‘health’ of the I/O Module—whether the module is responding to requests for polls from the Outstation with which it is associated.

Use the browse button to display a Reference browse window. Select the relevant point from the window.

You can ascertain the DNP3 SCADAPack 5000 Series IO item for which a point is the Status Point, by looking at the Status Point for attribute on that point’s Status display (see DNP3 SCADAPack Specific Status Display Attributes).

In addition to the above fields, the 5000 Series tab includes a Module Specific Configuration section to enable you to Specify the Module Specific Configuration.


DNP3 SCADAPack Driver Guide - Specify the Module Specific Configuration (Configuring I/O Expansion Cards and Modules)

Specify the Module Specific Configuration

This section applies only to SCADAPack 5000 Series IO Forms.

When applicable, use the fields within the Module Specific Configuration section of the 5000 Series tab to specify further module-specific properties. The field(s) only apply when certain Module Type options are specified (the fields are ‘grayed out’ when not applicable).

  • Filter—Use the combo box to specify the filter rate that is used to reduce process variations or electromagnetic noise in each analog input channel. The options vary, depending on the Module Type.
  • Line Frequency—Use the combo box to specify the frequency of the mains supply to the module. Specifying the relevant frequency should help to improve any AC noise interference during analog input measurements.
  • Output Type—Use the combo box to specify the current range that applies to the outputs on this module.

Further Information

Specify the Module Type: see Configure the 5000 Series I/O Properties.


DNP3 SCADAPack Driver Guide - Configure the ER I/O Properties (Configuring I/O Expansion Cards and Modules)

Configure the ER I/O Properties

Use the fields on the ER I/O tab of the DNP3 SCADAPack ER IO Form to configure these card-specific properties:

  • Outstation—Use to Specify the SCADAPack Outstation with Which the I/O is Associated.
  • Card Type—Use this combo box to specify the type of input or output card that this particular SCADAPack ER IO item represents.
  • Slot—Use this combo box to specify the slot location (Slot 1 to Slot 13) of the I/O card.


DNP3 SCADAPack Driver Guide - Configure the SCADAPack ES Remote I/O Properties (Configuring I/O Expansion Cards and Modules)

Configure the SCADAPack ES Remote I/O Properties

NOTE: A DNP3 SCADAPack ES Remote I/O module is a SCADAPack E-Series outstation that is used as an I/O expansion module for another DNP3 SCADAPack E-Series outstation. Do not confuse this with the DNP3 SCADAPack Remote DNP3 Device, and DNP3 SCADAPack Remote E-Series Outstation items that you can also configure in the ClearSCADA database. These latter items enable ClearSCADA to retrieve data from remote DNP3 outstations (see Configuring DNP3 SCADAPack E-Series Outstations).

A SCADAPack E-Series outstation can automatically allocate the I/O for a SCADAPack ES outstation that is used as an I/O expansion module. If the I/O is allocated automatically for such an expansion module (the default), you do not need to configure an expansion card or module in the ClearSCADA database. However, if the default automatic allocation of I/O is not suitable—for instance, if you want to specify different Point Numbers to those that would otherwise be assigned—you need to configure a DNP3 SCADAPack ES Remote IO item in the ClearSCADA database to represent the expansion I/O module.

Should you need to configure a DNP3 SCADAPack ES Remote IO item, use the fields on the SCADAPack ES Remote I/O tab of the DNP3 SCADAPack ES Remote IO Form to specify these module-specific properties:

  • Outstation—Use to Specify the SCADAPack Outstation with Which the I/O is Associated.
  • Module Address—Use the spin box to specify the address of the I/O module.

Further Information

Specify the communication timeouts between the main SCADAPack E-Series outstation and the SCADAPack ES Remote I/O module: see Configure SCADAPack ES Remote I/O Properties.


DNP3 SCADAPack Driver Guide - Specify the SCADAPack Outstation with Which the I/O is Associated (Configuring I/O Expansion Cards and Modules)

Specify the SCADAPack Outstation with Which the I/O is Associated

Use the Outstation field on the <I/O Type> tab to specify the DNP3 SCADAPack E-Series outstation with which the I/O expansion card or module is associated.

Use the browse button to display a Reference browse window. Select the relevant outstation from the window. The window is filtered to include only those DNP3 SCADAPack E-Series outstations that have an Outstation Type that supports this particular type of I/O card or module (see Configuring I/O Expansion Cards and Modules).


DNP3 SCADAPack Driver Guide - Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files

Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files

The DNP3 SCADAPack E-Series driver is able to download operating system firmware files to a SCADAPack E-Series outstation. The firmware is downloaded as a compressed binary firmware image file. With an outstation that forms the main unit of a Main-SCADAPack ES Remote I/O configuration, ClearSCADA is optionally able to download the same firmware image file to each of that outstation’s remote I/O modules in addition to the main unit itself, via a single pick action.

SCADAPack E-Series outstations support firmware downloads in this file format:

  • .BIZ compressed binary image file—Use this type of file to upgrade to new firmware regardless of the version of firmware that currently exists in an outstation.

For more information on this file type, see the SCADAPack E-Series Firmware Update User Manual.

In order for ClearSCADA to be able to download operating system firmware to a SCADAPack E-Series outstation you need to:

  1. Create and configure a DNP3 SCADAPack Firmware Image item in the ClearSCADA database (see Configure a DNP3 SCADAPack Firmware Image Item). You need one Firmware Image item for each different set of operating system firmware that is to be updated.
  2. Use each DNP3 SCADAPack Firmware Image item’s Import Firmware Image pick action to import the required binary firmware image file(s) into ClearSCADA.

The location to which the files are imported is defined using the ClearSCADA Server Configuration Tool’s Data Files field (see Locations of the Database Folders in the ClearSCADA Guide to Server Administration).

  3. Use the Firmware fields on each DNP3 SCADAPack E-Series Outstation Form to:
  • Associate the relevant DNP3 SCADAPack Firmware Image item with each outstation
  • Specify whether ClearSCADA is to download operating system firmware to only that outstation, or also to any remote I/O modules that are connected to that outstation. (ClearSCADA is only able to download firmware to both the main outstation and its remote IO modules if both the main outstation and each of its remotes are of the same type (for example, if they are all SCADAPack ES, or all 386 eNETs)).

For more information, see Configure the Firmware Image Properties.

  4. Use either the Download Firmware or Download Remote Firmware pick actions to download the relevant binary firmware image file to each outstation and/or any remote I/O modules connected to that outstation.

    CAUTION

    inoperable device

    Should a firmware download be unsuccessful (for example, if power is lost at the outstation before the download completes), the outstation will typically revert to using the version of firmware that was running before the download was attempted. If power is lost while the bootloader is patching the firmware, the outstation might be left in an inoperable state. If this occurs, an engineer will need to recover the situation locally at the outstation.

    Only attempt to download firmware or download remote firmware when there is sufficient time to manually recover the situation in the unlikely event of an unsuccessful download.

    Failure to follow these instructions can result in inoperable equipment.


DNP3 SCADAPack Driver Guide - Configure a DNP3 SCADAPack Firmware Image Item (Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files)

Configure a DNP3 SCADAPack Firmware Image Item

If you want to download operating system firmware files to SCADAPack E-Series outstations from ClearSCADA, you first need to import those files into the ClearSCADA database. To do this, you need to create and configure a DNP3 SCADAPack Firmware Image database item for each separate version of operating system firmware that you want to maintain in your outstations. (Therefore, if the outstations on your system run two separate versions of firmware, you need to configure two DNP3 SCADAPack Firmware Image items—one of each version of firmware that needs updating.)

The configuration Form for each DNP3 SCADAPack Firmware Image item has just two tabs—Identification and User Methods. For information on configuring the properties on these tabs, see Tabs that are Common to Many Configuration Forms in the ClearSCADA Guide to Advanced Drivers.

Use the DNP3 SCADAPack Firmware Image item’s Import Firmware Image pick action to import the required compressed binary firmware image file into ClearSCADA.

To ascertain the latest firmware image file that has been imported using a particular DNP3 SCADAPack Firmware Image item, view that item’s Status display (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients, and see DNP3 SCADAPack Firmware Image Status Attributes).

Once the firmware has been imported, use the Download Firmware or Download Remote Firmware pick actions to download the firmware to the relevant SCADAPack E-Series outstation(s) and/or any remote I/O modules. To ascertain the latest firmware image file that has been downloaded to an outstation, look at the Downloaded Firmware Image attribute on that outstation’s Status display.

CAUTION

inoperable device

Should a firmware download be unsuccessful (for example, if power is lost at the outstation before the download completes), the outstation will typically revert to using the version of firmware that was running before the download was attempted. If power is lost while the bootloader is patching the firmware, the outstation might be left in an inoperable state. If this occurs, an engineer will need to recover the situation locally at the outstation.

Only attempt to download firmware or download remote firmware when there is sufficient time to manually recover the situation in the unlikely event of an unsuccessful download.

Failure to follow these instructions can result in inoperable equipment.


DNP3 SCADAPack Driver Guide - Import and Download SCADAPack Security Configuration Files

Import and Download SCADAPack Security Configuration Files

This section applies to SCADAPack E-Series outstations on which DNP3 Secure Authentication is enabled.

With SCADAPack E-Series outstations, you can configure the outstation’s DNP3 Secure Authentication settings remotely, in the form of a security configuration file, then download those settings to the outstation.

In order to download a security configuration file to a SCADAPack E-Series outstation from ClearSCADA, you need to:

  1. Create and configure a DNP3 SCADAPack Security Configuration item in the ClearSCADA database (see Configure a DNP3 SCADAPack Security Configuration Item).

You need one DNP3 SCADAPack Security Configuration item per security configuration file.

  2. Use each DNP3 SCADAPack Security Configuration item’s Import Security Configuration pick action to import the required security configuration file into ClearSCADA.

The DNP3 SCADAPack E-Series driver supports security configuration files that have an .rtk file extension. Such files are generated using Schneider Electric’s Security Administrator application. Each security configuration file includes various security settings and user details, along with an encrypted private Update Key. You need to have access to an unencrypted version of this Update Key in order to import and download the security configuration file successfully via ClearSCADA.

The location to which each security configuration file is imported is defined using the ClearSCADA Server Configuration Tool’s Data Files field (see Locations of the Database Folders in the ClearSCADA Guide to Server Administration).

  3. Use the Security Configuration fields on each DNP3 SCADAPack E-Series Outstation Form to associate the relevant DNP3 SCADAPack Security Configuration item with each outstation (see Configure the Security Configuration Properties).

If required, you can associate the same DNP3 SCADAPack Security Configuration item (and therefore the same security configuration file and Update Key) with more than one outstation.

  4. Use the Download Security Configuration pick action to download the relevant security configuration file to each outstation.


DNP3 SCADAPack Driver Guide - Configure a DNP3 SCADAPack Security Configuration Item (Import and Download SCADAPack Security Configuration Files)

Configure a DNP3 SCADAPack Security Configuration Item

If you want to download a security configuration file to a SCADAPack E-Series outstation from ClearSCADA, you first need to import that file into the ClearSCADA database. To do this, you need to create and configure a DNP3 SCADAPack Security Configuration item in the database. You need one DNP3 SCADAPack Security Configuration item for each security configuration file that you want to download to your outstations. (Therefore, if the outstations on your system require three separate security configuration files between them, you need to configure three DNP3 SCADAPack Security Configuration items—one of each security configuration file.)

The configuration Form for each DNP3 SCADAPack Security Configuration item has just two tabs—Identification and User Methods. For information on configuring the properties on these tabs, see Tabs that are Common to Many Configuration Forms in the ClearSCADA Guide to Advanced Drivers.

Use the DNP3 SCADAPack Security Configuration item’s Import Security Configuration pick action to import the required security configuration file into ClearSCADA.

To ascertain the latest security configuration file that has been imported using a particular DNP3 SCADAPack Security Configuration item, view that item’s Status display (see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients, and see DNP3 SCADAPack Security Configuration Status Attributes).

Once the security configuration has been imported, use the Download Security Configuration pick action to download the security configuration to the relevant SCADAPack E-Series outstation(s). To ascertain the latest security configuration file that has been downloaded to an outstation, look at the Downloaded Security File attribute on that outstation’s Status display.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack Profiles

Configuring DNP3 SCADAPack Profiles

If required, you can use Profiles to enable a DNP3 SCADAPack point’s limit value(s) and/or current value to change at different times of the day or week.

Use Profiles to change a point’s limit value(s), in order to take into account expected variations on site. When a DNP3 SCADAPack point’s limits are profile-controlled:

  • The level at which ClearSCADA generates alarms varies during the course of each day.

The point’s limits vary according to the profile’s changes in value. ClearSCADA generates alarms and/or events whenever those limits are transgressed.

  • The level at which DNP3 events are generated by the outstation also varies during the course of the day.

The level of the point’s limits at the outstation varies according to the profile’s changes in value. The outstation can generate DNP3 events whenever one of those limits is transgressed—this is configurable on a per limit basis (see Specify Whether a Class n Event Triggers an Unsolicited Message).

With DNP3 SCADAPack points and pulse actions, profile-related configuration is downloaded to the outstation along with other configuration (see Download Configuration).

With DNP3 SCADAPack Counter points—and with DNP3 SCADAPack Analog and Binary points other than ‘Physical Input’ points—you can also use Profiles to change a point’s current value. You might want to do this, for instance, to automate any routine operations to control the point’s value at specific times of the day.

DNP3 SCADAPack points can use ClearSCADA’s standard (‘core’) Time Profiles, or DNP3 SCADAPack Profiles. The points on a particular SCADAPack E-Series outstation have to use the same type of Profile.

The two types of Profile differ in the way they are configured and how they change a point’s values:

  • With ClearSCADA’s standard Time Profiles, each Time Profile database item defines a single profile (for example, a ‘2 High’ limit profile) for the whole week.

On each DNP3 SCADAPack Point Form, you associate the relevant Time Profile database item with each point limit and/or current value that is to be profile-controlled. (Leave the fields blank for any point limits or current value that are not to be profile-controlled.)

  • With DNP3 SCADAPack Profiles, each Profile database item defines all of the profiles (for example, 4 High, 3 High, 2 High, 1 High, 1 Low, 2 Low, 3 Low, 4 Low, and Current Value) for a single day of the week. (If required, specific limit profiles or the current value profile can be disabled on each Profile item, if those limits or current value are not to be profile-controlled.)

On the configuration Form of each DNP3 SCADAPack point that is to be profile-controlled, you need to associate the relevant DNP3 SCADAPack Profile database item with the relevant day of the week. Each day has to be assigned a Profile if that point is to be profile-controlled—a diagnostic message is generated if only some days are assigned a Profile.

The rest of this section explains how to configure DNP3 SCADAPack Profiles. For information on configuring ClearSCADA’s standard Time Profiles, see Configuring Time Profiles in the ClearSCADA Guide to Core Configuration.

With either type of Profile, to configure the Profile and associate it with a DNP3 SCADAPack point or pulse action, various Limitations and Restrictions need to be taken into account.

DNP3 SCADAPack Profiles have a daily span. You specify each Profile’s values using the SCADAPack Profile Editor. You enter the values in a tabular format. The DNP3 SCADAPack driver supports these DNP3 SCADAPack Profiles:

  • DNP3 SCADAPack Analog Profile—Use to change a DNP3 SCADAPack analog point’s limits and/or current value. Each DNP3 SCADAPack Analog Profile database item can comprise up to nine profiles—one profile per point limit, and one profile for the point’s current value. (A DNP3 SCADAPack analog point’s current value can only be profile-controlled if the point’s Point Type is set to an option other than ‘Physical Input’.)
  • DNP3 SCADAPack Binary Profile—Use to change a DNP3 SCADAPack binary point’s current value (providing that point has a Point Type other than ‘Physical Input’), or trigger a DNP3 SCADAPack pulse’s actions. Each DNP3 SCADAPack Binary Profile database item comprises a single profile for controlling the point’s current value.
  • DNP3 SCADAPack Counter Profile—Use to change a DNP3 SCADAPack counter point’s High limit and/or current value. Each DNP3 SCADAPack Counter Profile database item can comprise up to two profiles—one profile for the point’s limit, and another profile for the point’s current value.

You add a DNP3 SCADAPack Profile to the database in the same way as any other DNP3 SCADAPack item (see Add an Item to the Database in the ClearSCADA Guide to Core Configuration).

When configuring each Profile, ensure that you take into account the relevant Profile Limitations and Restrictions.

The rest of this section explains how to:

  • Generate a DNP3 SCADAPack Profile’s Data Programmatically
  • Manually Add one or More Rows of Vectors to a DNP3 SCADAPack Profile
  • Remove one or more Rows of Vectors from a Profile
  • Use Copy and Paste to Copy a DNP3 SCADAPack Profile’s Data
  • Manually Edit the Vectors on a DNP3 SCADAPack Profile
  • Disable or Enable the Profile for a Particular Limit or Current Value
  • Validate a DNP3 SCADAPack Profile’s Configuration.

Use the Profile Type field on each DNP3 SCADAPack E-Series Outstation Form to Specify the Profile Type that is used by the points on a particular outstation.

Use the fields within the Profiles section of each DNP3 SCADAPack Point Form to specify which Profiles apply to each point (see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value).


DNP3 SCADAPack Driver Guide - Generate a DNP3 SCADAPack Profile's Data Programmatically (Configuring DNP3 SCADAPack Profiles)

Generate a DNP3 SCADAPack Profile’s Data Programmatically

You can configure a DNP3 SCADAPack Profile’s data manually (see Manually Add one or More Rows of Vectors to a DNP3 SCADAPack Profile), or you can generate the data programmatically.

Use the SetVectors method to configure or modify a DNP3 SCADAPack Profile’s vector programmatically using a custom program, Logic, or script. The SetVectors method’s arguments vary, depending on the type of DNP3 SCADAPack Profile for which the method is being used. For information on the arguments that you need to define for each type of Profile, see SetVectors.

When using the SetVectors method, you need to disable the CurrentValues profile on any SCADAPack Analog Profile items that are to control the limits of points that have a ‘Physical Input’ Point Type. To do this, you specify an empty array for that particular profile’s values. If the profile is not disabled, the point’s configuration will be invalid. The way in which you specify an empty array varies, depending on the language used—for example, in VBScript, you can specify ‘nothing’ or an empty array; in JScript you have to specify an empty array (‘null’ is not supported). For other restrictions of which you need to be aware, see Limitations and Restrictions, and see SetVectors.

The rest of this section comprises a series of examples to demonstrate how you might use the SetVectors method to generate a profile’s vectors programmatically.

Examples:

A series of Microsoft® JScript programs were written to produce a series of demonstration Daily profiles. In each case, the programs use constant values, but the values and times could equally be calculated according to a particular algorithm.

The times are in minutes, from midnight at the start of each day.

One program is used to populate a DNP3 SCADAPack Analog Profile, named ‘Demo Analog Profile’.

With the SetVectors method, all of the Profile item’s profiles have to be defined, regardless of whether those profiles are used. With this particular Profile item, several limit profiles and the current profile are disabled. This is achieved by specifying empty arrays for those particular profiles. The empty arrays mean that the Current Value, High 4, High 3, Low 3, and Low 4 limits are not profile-controlled on the DNP3 SCADAPack point(s) with which the Profile item is associated. (Remember that for a particular limit or current value not to be profile-controlled, that particular profile have to be disabled on all Profile items that are associated with a point.)

var Times = new Array(5);
Times[0] = 300;
Times[1] = 500;
Times[2] = 800;
Times[3] = 1000;
Times[4] = 1200;
var High4 = new Array(0);
var High3 = new Array(0);
var High2 = new Array(5);
High2[0] = 65.0;
High2[1] = 70.0;
High2[2] = 75.0;
High2[3] = 70.0;
High2[4] = 65.0;
var High1 = new Array(5);
High1[0] = 50.0;
High1[1] = 55.0;
High1[2] = 50.0;
High1[3] = 60.0;
High1[4] = 55.0;
var Low1 = new Array(5);
Low1[0] = 46.0;
Low1[1] = 42.0;
Low1[2] = 40.0;
Low1[3] = 45.0;
Low1[4] = 41.0;
var Low2 = new Array(5);
Low2[0] = 32.0;
Low2[1] = 37.0;
Low2[2] = 35.0;
Low2[3] = 31.0;
Low2[4] = 34.0;
var Low3 = new Array(0);
var Low4 = new Array(0);
var Current = new Array(0);
var Profile = Server.FindObject("Demo Analog Profile");
Profile.Interface.SetVectors(Times, Low4, Low3, Low2, Low1, High1, High2, High3, High4, Current);

Another JScript program is used to populate a DNP3 SCADAPack Counter Profile, named ‘Demo Counter Profile’. This Profile item is used to control both the current value and High limit of each DNP3 SCADAPack Counter point with which it is associated.

var Times = new Array(5)
Times[0] = 300
Times[1] = 500
Times[2] = 800
Times[3] = 1000
Times[4] = 1200
var High = new Array(5)
High[0] = 10.0
High[1] = 25.0
High[2] = 50.0
High[3] = 30.0
High[4] = 20.0
var Current = new Array(5)
Current[0] = 5.0
Current[1] = 20.0
Current[2] = 40.0
Current[3] = 20.0
Current[4] = 10.0
var Profile = Server.FindObject("Demo Counter Profile");
Profile.Interface.SetVectors(Times, High, Current);

A third program is used to populate a DNP3 SCADAPack Binary Profile, named ‘Demo Binary Profile’. This type of Profile item can be used to control DNP3 SCADAPack pulse action(s), or the current value of DNP3 SCADAPack Binary point(s) (providing that the latter have a Point Type other than ‘Physical Input’).

var Times = new Array(5)
Times[0] = 300
Times[1] = 500
Times[2] = 800
Times[3] = 1000
Times[4] = 1200
var Values = new Array(5)
Values[0] = 0
Values[1] = 1
Values[2] = 0
Values[3] = 1
Values[4] = 0
var Profile = Server.FindObject("Demo Binary Profile");
Profile.Interface.SetVectors(Times, Values);

Further Information

Manually Add one or More Rows of Vectors to a DNP3 SCADAPack Profile.

Manually Edit the Vectors on a DNP3 SCADAPack Profile.

SetVectors method: see SetVectors.


DNP3 SCADAPack Driver Guide - Manually Add one or More Rows of Vectors to a DNP3 SCADAPack Profile (Configuring DNP3 SCADAPack Profiles)

Manually Add one or More Rows of Vectors to a DNP3 SCADAPack Profile

You can Generate a DNP3 SCADAPack Profile’s Data Programmatically or manually.

When you first add a DNP3 SCADAPack Profile to your database, that Profile will have no rows. Use the procedures below to add single or multiple rows of vectors to your Profiles. Each Profile needs to include one row per change in profile value. The maximum rate at which a profile can change value is at one-minute intervals.

In order to perform any of the procedures below, you first need to display the required DNP3 SCADAPack Profile in Edit mode (see Displaying an Editor in the ClearSCADA Guide to Core Configuration).

To add a row to a Profile that does not contain any rows, either:

  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Insert option.

Or:

  1. Press the CTRL and SHIFT and + (PLUS SIGN) keys simultaneously (where the latter key is the PLUS SIGN on the main keyboard, rather than the numeric keypad).

Or:

  1. Right-click on the top left of the DNP3 SCADAPack Profile editor.
    A context sensitive menu is displayed.
    Right-click on the top left corner of the SCADAPack Profile editor.

  2. Select the Insert option.

A row is added to the DNP3 SCADAPack Profile.

To add a further row to an existing Profile, either:

  1. Select the row above which the new row is to be added. (To select a row, select the index number of the row (the number that is displayed on the left-hand side of the Editor), to highlight the whole row.)
  2. Perform one of the following:
  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Insert option.

Or:

  1. Press the CTRL and SHIFT and + (PLUS SIGN) keys simultaneously (where the latter key is the PLUS SIGN on the main keyboard, rather than the numeric keypad).

A new row is added above the highlighted row.

Or:

  1. Right-click on the index number of the row above which the new row is to be added.
    A context sensitive menu is displayed.
  2. Select the Insert option.
    A new row is added above the highlighted row.

To add a new row after the last existing row:

  1. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Append option.

Or:

  1. Press the CTRL and SHIFT and ALT and + (PLUS SIGN) keys simultaneously (where the latter key is the PLUS SIGN on the main keyboard, rather than the numeric keypad).

Or:

  1. Right-click on any row.
    A context sensitive menu is displayed.
  2. Select the Append option.

A row is added to the end of the profile.

NOTE: The Append option is ‘grayed out’ and unavailable for use if the last existing row has a time of 23:59 or equivalent (that is, one minute before midnight), as this is the latest time that a DNP3 SCADAPack Profile can support.

To add multiple rows to a Profile, perform one of these procedures:

To double the number of existing rows (if possible):

  1. Right-click on the top left of the DNP3 SCADAPack Profile editor.
    A context sensitive menu is displayed.
  2. Select the Insert option.
    The number of existing rows doubles (if possible). The new rows are inserted before any of the existing rows.

If the time allocated to the first existing row is such that the number of rows cannot be doubled, as many new rows as possible will be inserted before the first row, each being assigned a different time, in sequential order.

To insert a specific number of rows above a block of existing rows:

  1. Drag over a block of existing rows at the required insertion point, until the relevant number of rows are highlighted. (For example, highlight four rows, in order to insert four new rows immediately above the block of highlighted rows.)
  2. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Insert option.

Or:

  1. Press the CTRL and SHIFT and + (PLUS SIGN) keys simultaneously (where the latter key is the PLUS SIGN on the main keyboard, rather than the numeric keypad).

Or:

  1. Right-click on the top left of the DNP3 SCADAPack Profile editor.
    A context sensitive menu is displayed.
  2. Select the Insert option.

A block of rows is added above the highlighted rows.

If sufficient room exists, the required number of rows are added. (For instance, if four rows were highlighted, four new rows will be inserted immediately above the block of highlighted rows.)

If the time allocated to the uppermost highlighted row is such that only a smaller number of rows can be inserted above it, as many rows as possible will be inserted above that row. Each new row will automatically be allocated a different time, in sequential order.

If no new rows can be inserted above the uppermost highlighted row, the computer will beep.

To select and insert multiple non-consecutive rows, follow the procedure shown above, but at step 1 hold down the CTRL key while you select each row above which you want to insert another row.

You can also use the standard Windows® keyboard shortcuts, context sensitive menu options, or the ViewX Edit menu options to copy and paste column(s), row(s) of vectors, or parts of rows (see Use Copy and Paste to Copy a DNP3 SCADAPack Profile’s Data).

Further Information

Manually Edit the Vectors on a DNP3 SCADAPack Profile.


DNP3 SCADAPack Driver Guide - Remove one or more Rows of Vectors from a Profile (Configuring DNP3 SCADAPack Profiles)

Remove one or more Rows of Vectors from a Profile

To remove one or more rows of vectors from a Profile and store a copy of the data in Windows’ temporary storage ‘clipboard’:

  1. Display the required DNP3 SCADAPack Profile in Edit mode (see Displaying an Editor in the ClearSCADA Guide to Core Configuration).
  2. Select the index number of the unwanted row. (To select multiple rows, select the initial row then either hold down the SHIFT key and select the last required row in a block of rows, or hold down the CTRL key while selecting further individual rows.)
    The selected row(s) are highlighted.
  3. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Cut option.

Or:

  1. Press the CTRL and X keys simultaneously.

Or:

  1. Right-click on the selected content.
    A context sensitive menu is displayed.
  2. Select the Cut option.

Or:

  1. Select the Cut button [image] on the File Toolbar.

The selected row(s) are removed from the Profile and stored in the clipboard.

  2. Paste a copy of the rows:
  • Onto the same or another DNP3 SCADAPack Profile (see Use Copy and Paste to Copy a DNP3 SCADAPack Profile’s Data)
  • Into another application, such as Microsoft® Excel.

To remove one or more rows of vectors from a Profile, but not store a copy of those vectors:

  1. Display the required DNP3 SCADAPack Profile in Edit mode (see Displaying an Editor in the ClearSCADA Guide to Core Configuration).
  2. Select the index number of the unwanted row. (To select multiple rows, select the initial row then either hold down the SHIFT key and select the last required row in a block of rows, or hold down the CTRL key while selecting further individual rows.)
    The selected row(s) are highlighted.
  3. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Delete option.

Or:

  1. Press the Delete key on the keyboard.

Or:

  1. Right-click on the selected content.
    A context sensitive menu is displayed.
  2. Select the Delete option.

The selected row(s) are removed from the Profile. The deleted data is not stored in the clipboard.


DNP3 SCADAPack Driver Guide - Use Copy and Paste to Copy a DNP3 SCADAPack Profile's Data (Configuring DNP3 SCADAPack Profiles)

Use Copy and Paste to Copy a DNP3 SCADAPack Profile’s Data

You can use the Copy and Paste feature to copy any portion of a DNP3 SCADAPack Profile’s data into Windows’ temporary storage ‘clipboard’. You can then use the clipboard’s contents to:

  • Add further rows to a Profile (a Profile is extended with extra rows when pasting, if needed)
  • Populate a Profile’s empty cells
  • Replace one or more cell’s, column’s, or row’s existing data.

If you are copying data from one Profile to another, for many paste actions to be successful, both DNP3 SCADAPack Profiles have to be of the same type (for instance, both DNP3 SCADAPack Analog Profiles).

To copy Profile data to the clipboard:

  1. Display the required DNP3 SCADAPack Profile in Edit mode (see Displaying an Editor in the ClearSCADA Guide to Core Configuration).
  2. Perform one of the following:
  • Select a single cell
  • Select the index number to select a single row
  • Select a column heading to select a single column
  • Perform any of the above, then hold down the SHIFT key while selecting further cells, rows and/or columns, to select a block of data
  • Perform one of the first three actions, then hold down the CTRL key while selecting further cells, rows and/or columns, to select those specific areas of the Profile
  • Select the top left of the Editor window to select all of the Profile’s data.

The selected content is highlighted.

  3. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Copy option.

Or:

  1. Press the CTRL and C keys simultaneously.

Or:

  1. Right-click on the selected content.
    A context sensitive menu is displayed.
  2. Select the Copy option.

Or:

  1. Select the Copy button [image] on the File Toolbar.

The selected content is copied to the clipboard.

To paste the clipboard’s content into a Profile:

ATTENTION: Be aware that if the copy and paste routine results in a whole column’s data being pasted into a currently disabled column, that column will become enabled. Similarly, if the routine results in the whole of a disabled column’s content being pasted into a currently enabled column, that column will become disabled. (If only part of such a column is replaced, the cells into which values are not being pasted will be set to zero.) For more information on disabled columns, see Disable or Enable the Profile for a Particular Limit or Current Value.

  1. Display the required DNP3 SCADAPack Profile in Edit mode (see Displaying an Editor in the ClearSCADA Guide to Core Configuration).
  2. Perform one of the following:
  • Select the cell into which a single cell’s data is to be pasted
  • Select the top-left cell of the block of cells into which data is to be pasted
  • Select the heading of the column into which a single column’s data is to be pasted
  • Select the heading of the furthest left column of the block of columns into which data is to be pasted
  • Select the index number of the row into which a single row’s data is to be pasted
  • Select the index row of the uppermost row into which a block of rows is to be pasted
  • Select the top-left corner of the Editor window into which a whole Profile’s data is to be pasted.
  3. Either:
  1. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Paste option.

Or:

  1. Press the CTRL and V keys simultaneously.

Or:

  1. Right-click on the selected content.
    A context sensitive menu is displayed.
  2. Select the Paste option.

Or:

  1. Select the Paste button [image] on the File Toolbar.

The clipboard’s content is pasted onto the selected Profile.

If a row was selected to form the start of a block of rows into which data was pasted, the selected and following rows’ content will be replaced by the clipboard’s content. Further rows will be added if the number of rows available is less than that required by the data that is stored in the clipboard.


DNP3 SCADAPack Driver Guide - Manually Edit the Vectors on a DNP3 SCADAPack Profile (Configuring DNP3 SCADAPack Profiles)

Manually Edit the Vectors on a DNP3 SCADAPack Profile

To manually specify the time and vector values on a DNP3 SCADAPack Profile:

  1. Overtype the Time with the required value.

The format in which you can enter time values depends on the Locale and Date Format assigned to your User Account.

Should an invalid value be entered in a Time cell, that value will automatically be highlighted in red. Invalid values are not saved to the database.

  2. With each of the remaining column(s), enter the vector value that applies at the specified Time.

Ensure that you specify values that are appropriate to the type of DNP3 SCADAPack Profile (see Limitations and Restrictions).

Should an invalid value be specified, that value will automatically be highlighted in red. Invalid values are not saved to the database.

NOTE: Remember that if a Profile is to control the limit(s) of a DNP3 SCADAPack Analog point that has a ‘Physical Input’ Point Type, the Profile’s Current value column has to be disabled (see Disable or Enable the Profile for a Particular Limit or Current Value).

Example:

This DNP3 SCADAPack Binary Profile has two invalid values, both of which were highlighted in red as soon as another part of the screen was selected.

This Time value is invalid. (It does not conform to this particular user’s HH:mm time format.)
This Current value is invalid. (Binary Profiles only support current values that are either 0 or 1.)

Further Information

Manually Add one or More Rows of Vectors to a DNP3 SCADAPack Profile.

Use Copy and Paste to Copy a DNP3 SCADAPack Profile’s Data.

Further Validate a DNP3 SCADAPack Profile’s Configuration.


DNP3 SCADAPack Driver Guide - Disable or Enable the Profile for a Particular Limit or Current Value (Configuring DNP3 SCADAPack Profiles)

Disable or Enable the Profile for a Particular Limit or Current Value

ATTENTION: When you assign a DNP3 SCADAPack Profile to a point, any profile-controlled limits become ‘grayed out’ within the Alarm Limits section of the Point Form and overwritten with a different value. If you later disable one of more of the Profile’s vector columns, ensure that you suitably configure any point limits that are no longer profile-controlled.

With a DNP3 SCADAPack Profile, you can optionally disable the individual profile for a particular limit or current value. To do this, you disable the column of vectors for the limit or current value that is not to be profile-controlled. For a limit or current value not to be profile-controlled on a DNP3 SCADAPack point that uses Profiles, that particular profile has to be disabled on each day of the week. In other words, on every DNP3 SCADAPack Profile that is assigned to that point. (If a particular profile is disabled on some (but not all) days of the week, both the outstation and ClearSCADA will use the last value of the previous day’s profile as the value for the ‘missing’ (disabled) day(s).)

The current value of a DNP3 SCADAPack Analog point can only be profile-controlled if that point has a Point Type other than ‘Physical Input’. With a ‘Physical Input’ analog point, you need to ensure that the Current Value profile is disabled on any DNP3 SCADAPack Analog Profile items that are to control any of that point’s limits.

(A DNP3 SCADAPack Binary point that has a ‘Physical Input’ Point Type cannot be profile-controlled. As such, that Point Form’s Profiles fields are ‘grayed out’ and unavailable for use.)

To disable one or more column(s) of vectors:

  1. Display the required DNP3 SCADAPack Profile in Edit mode (see Displaying an Editor in the ClearSCADA Guide to Core Configuration).
  2. Perform one of the following:
  1. To select a single column, right-click on the heading of the relevant column.
    A context sensitive menu is displayed.

Or:

  1. To select more than one column, either:
  • Drag over the headings of the relevant columns.
  • Right-click on the heading of the first column you require, then hold down the SHIFT key and select the heading of the last column you require.
    The block of columns is selected.

Or:

  • Right-click on the heading of any one of the columns you require, then hold down the CTRL key while selecting any other columns that are required.
    Each of the selected columns is highlighted.
  2. Right-click on any of the selected columns.
    A context sensitive menu is displayed.
  3. Select the Disable option.
    The vector values are removed and the column(s)’ background changes to gray.

To enable one or more currently disabled column(s) of vectors, follow the steps above, but select the Enable option at step 3. You will then need to configure the vector values that apply to the re-enabled column(s).

Example:

A series of analog points are assigned two Daily (DNP3 SCADAPack) Profiles—one to control some of the points’ limits during weekdays, and another to control the same limits at weekends.

With both DNP3 SCADAPack Analog Profiles, only the High limit profiles are enabled. The various Low limit and Current value profile columns are disabled. (The same profiles have to be disabled on all DNP3 SCADAPack Profile items that are assigned to a DNP3 SCADAPack point, in order for a particular limit or the current value not to be profile-controlled.)

Each Profile’s Low limit and Current columns are disabled...
...as only the Profiles’ High limits are used to change point limits.

The Profiles are associated with the relevant DNP3 SCADAPack Analog points, by using the daily profile fields in the Profiles section of each Point Form. In this particular example, one DNP3 SCADAPack Profile is allocated to Saturday and Sunday, and the other to each week day (Monday to Friday). (With a profile-controlled point that uses Daily (DNP3 SCADAPack) Profiles, a DNP3 SCADAPack Profile has to be assigned to every day of the week.)

On each Point Form, the DNP3 SCADAPack Profile items are assigned to the relevant days of the week.

With each point with which the Profiles are associated, the point’s fixed High limits are ‘grayed out’ (as those limits change according to whichever Profile is in force). The point’s other limits are fixed and are as per the values specified within the Alarm Limits section of the Point Form.

On the Forms of the points with which the Profiles are associated, the points’ fixed High limits are ‘grayed out’ (as these are profile-controlled)...
...whereas the point’s Low limits are not profile-controlled.


DNP3 SCADAPack Driver Guide - Validate a DNP3 SCADAPack Profile's Configuration (Configuring DNP3 SCADAPack Profiles)

Validate a DNP3 SCADAPack Profile’s Configuration

Whenever an attempt is made to save a DNP3 SCADAPack Profile’s configuration, ClearSCADA automatically checks:

  • Whether all Time values are sequential
  • If the Profile item is a DNP3 SCADAPack Analog Profile, whether any limit values cross over any other limit values.

(The contents of individual cells are validated when they are modified. Any invalid times or values are highlighted in red (see Manually Edit the Vectors on a DNP3 SCADAPack Profile).)

Only valid configuration is saved to the database. Diagnostic message(s) are displayed at the bottom of the DNP3 SCADAPack Profile Editor should a Profile have invalid configuration.

Example:

With this particular DNP3 SCADAPack Profile, two rows have been assigned the same time:

The message displayed at the bottom of the Editor indicates the configuration that is invalid. The message area is only displayed if the Profile has invalid configuration.
An attempt was made to save this Profile while two rows were assigned the same time.

To manually check a DNP3 SCADAPack Profile’s data for invalid configuration:

  1. Select the File menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  2. Select the Validate Profile option.
    ClearSCADA validates the Profile’s data. If any of the configuration is invalid, ClearSCADA displays diagnostic message(s) at the bottom of the DNP3 SCADAPack Profile Editor.

In addition to the above validation checks, ClearSCADA performs further checks whenever a Profile is assigned to a DNP3 SCADAPack Point and an attempt is made to save that point’s configuration (see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value).


DNP3 SCADAPack Driver Guide - Points Used on DNP3 SCADAPack E-Series Outstations

Points Used on DNP3 SCADAPack E-Series Outstations

DNP3 SCADAPack E-Series outstations support the point types that are listed below. You configure the properties of each point using the appropriate DNP3 SCADAPack Point Form.

Before configuring each DNP3 SCADAPack point in the ClearSCADA database, you need to be aware of how your system set-up needs representing in ClearSCADA (see With Which Database Item do I Associate each DNP3 SCADAPack Point?).

The rest of this section covers configuration of SCADAPack E-Series specific point properties that are:

  • Common to DNP3 SCADAPack points—see Configure Common Properties of DNP3 SCADAPack Points and see Specify any Point Mapping
  • Common to DNP3 SCADAPack Output points—see Configure an Output Point or Pulse Action’s Interlock Properties.

For information on DNP3 SCADAPack properties that are specific to a particular type of point, see the following sections:

  • DNP3 SCADAPack Analog Input Point—see Configuring DNP3 SCADAPack Analog Points.
  • DNP3 SCADAPack Analog Output Point—see Configuring DNP3 SCADAPack Analog Points.

NOTE: If a SCADAPack E-Series outstation is a Modbus Slave, and the Modbus Master reads or writes to 32-bit points in that Modbus Slave, use a DNP3 SCADAPack 32-bit Point Modbus Map to map the 32-bit data (see Configuring DNP3 SCADAPack 32-bit Point Modbus Maps).

  • DNP3 SCADAPack Binary Input Point—see Configuring DNP3 SCADAPack Binary Points.

NOTE: If a SCADAPack E-Series outstation is to sample a point’s data and store the sampled records at the outstation, you can optionally use a DNP3 SCADAPack Binary Input Point to control when the outstation samples the analog, counter, or binary point’s data (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality, and see Specify the Sample Rate and Sample Criteria).

  • DNP3 SCADAPack Binary Output Point—see Configuring DNP3 SCADAPack Binary Points.
  • DNP3 SCADAPack Counter Point—see Configuring DNP3 SCADAPack Counter Points.
  • DNP3 SCADAPack Pulse Action (NULL)—a one-action pulse (see Configuring DNP3 SCADAPack Pulse Actions).
  • DNP3 SCADAPack Pulse Action (Trip-Close)—a two-action pulse, for which each action can be performed on the same, or on a separate physical point (see Configuring DNP3 SCADAPack Pulse Actions).

In addition to SCADAPack E-Series properties, the above points have properties that are common to generic DNP3 points—for information on configuring these DNP3 properties, see Points Used on DNP3 Outstations in the ClearSCADA Guide to the DNP3 Driver.

For information on configuring point properties that are common to points on many advanced drivers, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

For general information on configuring points, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

In addition to the above points—which include properties that enable additional SCADAPack E-Series functionality—SCADAPack E-Series outstations can also support the DNP3 point types that a generic DNP3 outstation supports (see Points Used on DNP3 Outstations in the ClearSCADA Guide to the DNP3 Driver). However DNP3 points (as opposed to DNP3 SCADAPack points) should only be associated with a DNP3 SCADAPack E-Series outstation:

  • If upgrading those points from DNP3 to DNP3 SCADAPack on a DNP3 SCADAPack E-Series outstation. (You use the Convert To menu option to convert each DNP3 point to the appropriate type of DNP3 SCADAPack point, and carry out the necessary additional configuration.)
  • In situations during which a point’s configuration is not to be downloaded to the SCADAPack E-Series outstation (the point is only used internally within ClearSCADA).

Also be aware that if ClearSCADA scans a remote device for data and that remote is not an E-Series outstation, the points on that remote outstation have to be configured as DNP3 points, rather than DNP3 SCADAPack points, in the ClearSCADA database. This only applies if ClearSCADA scans the remote device ‘transparently’ via that remote’s parent DNP3 SCADAPack E-Series outstation, rather than if the parent outstation scans the remote (see SCADAPack E-Series Data Concentrators and Remote Outstations).

If the SCADAPack E-Series outstations on your system are to sample the data trends of any analog, binary, or counter points, you can configure the required Trend settings in ClearSCADA then download that configuration to the outstation (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality).


DNP3 SCADAPack Driver Guide - With Which Database Item do I Associate each DNP3 SCADAPack Point? (Points Used on DNP3 SCADAPack E-Series Outstations)

With Which Database Item do I Associate each DNP3 SCADAPack Point?

With most advanced drivers in ClearSCADA, you associate each point with the outstation on which that point is located.

With the DNP3 SCADAPack E-Series driver, the database item with which you associate a physical point depends on the system setup and the device that is to scan that point’s data. (A physical point—a point that represents physical I/O in the outstation—has to have its Point Type specified as either Physical Input or Physical Output (see Configure Common Properties of DNP3 SCADAPack Points).)

Use the table below to determine the database item with which you should associate each physical DNP3 SCADAPack point on your system:

System Setup

Database Item with Which the Point has to be Associated

The point is on a SCADAPack ES, or 386 eNET outstation.

In ClearSCADA, the outstation is represented by a DNP3 SCADAPack E-Series Direct, PSTN, or Shared outstation.

Specify the name of the DNP3 SCADAPack E-Series outstation in the Point Form’s Outstation field.

The point is on a SCADAPack 330E, 334E, 350E or 357E outstation.

In ClearSCADA, the outstation is represented by a DNP3 SCADAPack E-Series Direct, PSTN, or Shared outstation.

Each SCADAPack 330E, 334E, 350E and 357E outstation has basic on-board I/O, but that I/O is not automatically allocated any DNP3 Point Numbers. As such, a DNP3 SCADAPack 5000 Series IO item needs to be configured in the ClearSCADA database to represent each on-board I/O card on that outstation.

For each point on a SCADAPack 330E/334E, or SCADAPack 350E/357E outstation, specify the name of the DNP3 SCADAPack E-Series outstation with which the I/O module or card is associated in the Point Form’s Outstation field.

Use the Point Form’s Mapping tab to reference the I/O card and define the point’s location on that card (see Specify any Point Mapping).

The point is on a SCADAPack ER-P600, or SCADAPack ER-P620 outstation.

In ClearSCADA, the outstation is represented by a DNP3 SCADAPack E-Series Direct, PSTN, or Shared outstation.

SCADAPack ER-P600 and ER-P620 outstations do not have on-board I/O (input and output points). Instead, separate I/O card(s) or module(s) are connected to the outstations to provide the required I/O.

The configuration that is required in ClearSCADA to represent the I/O modules or cards differs, depending on the type of I/O module and whether the allocation of its I/O was automatic or manual.

Refer to the expansion module entries below for further information.

The point is on a remote DNP3 outstation that is Polled By a Data Concentrator.

(A remote DNP3 outstation is configured as a DNP3 SCADAPack Remote E-Series Outstation, or a DNP3 SCADAPack Remote DNP3 Device in the ClearSCADA database.)

Specify the name of the remote outstation’s Parent outstation (data concentrator) in the Point Form’s Outstation field. Use the Point Form’s Point Number field to specify the DNP3 point number used by the data concentrator to identify the point.

Use the fields on the Point Form’s Mapping tab to specify the point’s location on the remote outstation (see Specify any Point Mapping).

The point is on a remote DNP3 outstation that is Polled By the Master Station (ClearSCADA), rather than the data concentrator.

Specify the name of the remote outstation in the Point Form’s Outstation field.

The point is on a remote DNP3 outstation that is Polled By both the Data Concentrator and Master Station.

If the point is scanned only by the data concentrator, specify the name of the remote outstation’s Parent outstation (data concentrator) in the Point Form’s Outstation field. Use the fields on the Point Form’s Mapping tab to specify the point’s location on the remote outstation.

If the point is scanned only by the master station (ClearSCADA), specify the name of the remote outstation in the Point Form’s Outstation field.

If the point is scanned by both the data concentrator and ClearSCADA, you need to configure two points in the ClearSCADA database: one that is associated with the data concentrator, and one that is associated with the remote outstation. (The point that is associated with the data concentrator should reference the point that is associated with the remote outstation, via the properties on its Mapping tab.)

The point is on a SCADAPack ES outstation that is used as an I/O expansion module. The module’s I/O was allocated automatically when the module was connected to the outstation for which it provides additional I/O.

In the ClearSCADA database, a DNP3 SCADAPack E-Series Direct, PSTN, or Shared outstation (as applicable) is used to represent the outstation AND its expansion I/O module(s). (As the I/O was allocated automatically, no separate expansion I/O module items are required in the ClearSCADA database.)

Specify the name of the DNP3 SCADAPack E-Series outstation in the Point Form’s Outstation field.

The point is on an expansion I/O module or card that is connected to a DNP3 SCADAPack E-Series Direct, PSTN, or Shared outstation.

If the point is on a SCADAPack ES outstation that is used as an I/O expansion module, the default automatic allocation of I/O on that module was not suitable and has therefore been allocated manually.

For this type of setup, a DNP3 SCADAPack 5000 Series IO, ER IO, or ES Remote IO item (as applicable) needs to be configured in the ClearSCADA database to represent the expansion I/O module or card.

Specify the name of the DNP3 SCADAPack E-Series outstation with which the I/O module or card is associated in the Point Form’s Outstation field.

Use the Point Form’s Mapping tab to reference the expansion I/O module or card, and define the point’s location on that card (see Specify any Point Mapping).

The point is on a separate I/O module or card that is connected to a remote SCADAPack E-Series outstation.

The I/O module is a SCADAPack ES outstation that is used as an expansion I/O module. The I/O on the module have been allocated automatically when the module was connected to the remote outstation.

In the ClearSCADA database, a DNP3 SCADAPack Remote E-Series Outstation is used to represent the remote outstation AND its expansion I/O module(s). (As the I/O was allocated automatically, no separate expansion I/O module items are required in the ClearSCADA database.)

The outstation that you specify in the Point Form’s Outstation field depends on whether that point is being Polled By the Data Concentrator and/or the Master Station (ClearSCADA)—see the remote DNP3 outstation entries above.

The point is on a separate I/O module or card that is connected to a remote SCADAPack E-Series outstation.

If the point is on a SCADAPack ES outstation that is used as an I/O expansion module, the default automatic allocation of I/O on that module was not suitable and has therefore been allocated manually.

For this type of setup, a DNP3 SCADAPack 5000 Series IO, ER IO, or ES Remote IO item (as applicable) needs to be configured in the ClearSCADA database to represent the expansion I/O module or card. The remote outstation with which the I/O module or card is associated needs specifying in the Outstation field on that item’s configuration Form.

Specify the name of the DNP3 SCADAPack Remote E-Series outstation with which the I/O module or card is associated in the Point Form’s Outstation field.

Use the Point Form’s Mapping tab to reference the expansion I/O module or card, and define the point’s location on that card (see Specify any Point Mapping).

If the point is scanned by the data concentrator, a second point has to be configured in the ClearSCADA database. Specify the name of the data concentrator in the Point Form’s Outstation field. Additionally, use the Point Form’s Mapping tab to reference the expansion I/O module or card, and define the point’s location on that card.

Further Information

SCADAPack E-Series Outstations that have Separate or Additional I/O Cards or Modules

SCADAPack E-Series Data Concentrators and Remote Outstations.


DNP3 SCADAPack Driver Guide - Configure Common Properties of DNP3 SCADAPack Points (Points Used on DNP3 SCADAPack E-Series Outstations)

Configure Common Properties of DNP3 SCADAPack Points

In addition to the common configuration properties of DNP3 points (see Configure General Point Properties in the ClearSCADA Guide to the DNP3 Driver), DNP3 SCADAPack points have the following additional fields:

  • Point Type—Use to specify the type of point that is created in the SCADAPack E-Series outstation. Use the combo box to select the required type (some options may not be available for certain points):
  • Physical Input—The point references a physical input in the outstation, I/O card or module, or remote DNP3 device.
  • Physical Output—The point references a physical output in the outstation, I/O card or module, or remote DNP3 device.
  • User (Derived)—The point references an internal user point in the outstation.

Any point that a data concentrator uses to control or monitor the status of its remote outstations has to have a User (Derived) Point Type.

  • System (Derived)—The point references an internal system point in the outstation.

The following rules apply to the Point Type and Point Number for analog points, (namely DNP3 SCADAPack Analog Input Points and DNP3 SCADAPack Analog Output Points) that are attached to the same Outstation.

  • You can create either one DNP3 SCADAPack Analog Input Point or one DNP3 SCADAPack Analog Output Point with a Point Type of User (Derived) or System (Derived) provided there is no other DNP3 or DNP3 SCADAPack analog point with the same Point Number.
  • If you create a DNP3 SCADAPack Analog Input Point or DNP3 SCADAPack Analog Output Point with a Point Type of User (Derived), the point number has to be less than 50000.
  • If you create a DNP3 SCADAPack Analog Input Point or DNP3 SCADAPack Analog Output Point with a Point Type of System (Derived), the point number has to be greater than or equal to 50000.

The rules described above also apply to binary points, (namely DNP3 SCADAPack Binary Input Point, DNP3 SCADAPack Binary Output Point, DNP3 SCADAPack Pulse Action (NULL), and DNP3 SCADAPack Pulse Action (Trip-Close) points) that are attached to the same Outstation.

On a data concentrator, the analog points that are used to monitor the status of that data concentrator’s remote outstations have to have consecutive Point Numbers and User (Derived) Point Types. Similarly, the binary or pulse points that the data concentrator uses to control activity in its remote outstations have to have consecutive Point Numbers and User (Derived) Point Types. For more information, see Configure the Data Concentrator Status and Control Points.

For DNP3 SCADAPack Counter Points, the only supported Point Type is Physical Input. DNP3 SCADAPack Counters reference physical binary inputs. Ensure that a physical binary input exists for any DNP3 SCADAPack Counter Points that you create in ClearSCADA.

  • Point Data Class—Use to specify the DNP3 Data Class for the point created in the SCADAPack E-Series outstation. The options vary depending on the point type, but include a combination of the following:
  • Class 0 Static Only—The outstation does not generate and store events for the point. The outstation returns the current value of the point whenever ClearSCADA performs a Class 0 or Integrity poll.
  • Class n Event—Available for points that have a Point Type other than ‘Physical Output’. The outstation generates events of the specified class (1, 2, or 3) for the point. The outstation stores the event in its internal buffer, with a time stamp that indicates the time that the event was generated.

Whether the outstation immediately attempts to send an unsolicited message to ClearSCADA to report that event, or whether it waits until a sufficient number of events for the given DNP3 Event Class have been stored in the Event Buffer before sending an unsolicited message, depends on the reason for the event and the configuration that determines how the outstation handles such an event (see Specify Whether a Class n Event Triggers an Unsolicited Message).

The outstation may be configured not to generate unsolicited messages (see Enable Unsolicited Message Generation in the ClearSCADA Guide to the DNP3 Driver). If so, the outstation will only send the events that are stored in its Event Buffer to the ClearSCADA server, when ClearSCADA performs a DNP3 Event Poll (see Specify When ClearSCADA Performs Class Polls in the ClearSCADA Guide to the DNP3 Driver).

NOTE: If you configure any point to be Class n Event, it is not recommended that ClearSCADA issues Class 0 Only polls to the SCADAPack E-Series outstation. In such cases it is recommended that ClearSCADA issues Class 1, 2, 3, 0 integrity polls (see Specify When ClearSCADA Performs Class Polls in the ClearSCADA Guide to the DNP3 Driver).

  • Local—The point does not return data in response to a DNP3 Class 0 poll request, and does not generate DNP3 events. Data for the point is only available using DNP3 Subset Level 3 requests.

With a point that is on an outstation that communicates with more than one DNP3 master (see Specify Whether an Outstation Communicates with Multiple DNP3 Masters), use this Point Data Class field to specify the DNP3 data class that applies when the outstation communicates with the local ClearSCADA server (the server on the system on which the outstation is located). Use the field(s) within the Multi Master Configuration section on the <Point Type> tab to Specify the Point Data Class that Applies when Communicating with another DNP3 Master.

  • DNP Object Type—Use to specify the DNP3 Object that the outstation uses to send the point’s value to ClearSCADA, when ClearSCADA issues a Class 0 Poll. Use this field to specify:
  • If the value is returned with or without a DNP3 Status Flag. Sending values without the status flag results in smaller DNP3 frames being sent, but does not provide information such as failure of the physical I/O circuitry.

If you specify consecutively numbered binary points using a DNP Object Type which does not include the DNP3 Status Flag, they will be bit-packed. This may offer a considerable reduction in the size of the DNP3 frames.

  • For analog points, whether the point is a 16-bit integer, 32-bit integer, or an IEEE short floating point.

If you specify a DNP Object Type of 32-bit Analog Input (g30v1) or 32-bit Analog Input No Flag (g30v3) for any point, you should use either 32-bit Analog In Change No Time (g32v1) or 32-bit Analog In Change with Time (g32v3) as the Analog Event Object (see Configure Event Configuration).

A SCADAPack E-Series outstation stores events for any analog input point with a DNP Object Type of Short Float Analog Input (g30v5) or Short Floating Point Analog Output Status (g40v3) and Point Data Class of Class n Event, using the Float Event Object. For other analog DNP Object Types, the outstation stores events using the Analog Event Object (see Configure Event Configuration).


DNP3 SCADAPack Driver Guide - Specify Whether a Class n Event Triggers an Unsolicited Message (Points Used on DNP3 SCADAPack E-Series Outstations)

Specify Whether a Class n Event Triggers an Unsolicited Message

This section applies to DNP3 SCADAPack points for which the Point Data Class is set to Class 1 Event, Class 2 Event, or Class 3 Event (see Configure Common Properties of DNP3 SCADAPack Points).

If you configure a point to generate a Class 1 Event, Class 2 Event, or Class 3 Event, you need to use the various RTU Event field(s) on the Point Form to specify whether the SCADAPack E-Series outstation just stores a particular type of event, or immediately sends an unsolicited message to report the event to ClearSCADA.

If a point has a Point Data Class of Class 1 Event, Class 2 Event, or Class 3 Event...
...you need to use the various RTU Event fields on the Point Form to specify whether each type of event is just stored in the outstation, or triggers an unsolicited message.

The types of different event, and therefore the number of corresponding RTU Event fields, vary with the point type.

With DNP3 SCADAPack Analog Points, separate RTU Event fields are available for:

  • Each of the High and Low Alarm Limits (see Configure Alarm Limits)
  • The point becoming Underrange, Overrange, or Invalid (see Specify how the SCADAPack Outstation Handles Underrange, Overrange and Invalid RTU Events)
  • Event Deviation (see Configure the Event Deviation Properties).

With DNP3 SCADAPack Binary Points, an RTU Event field is available for:

  • State Changes (see Configure General Properties).

With DNP3 SCADAPack Counter Points, an RTU Event field is available for:

  • The High Alarm Limit (see Configure Alarm Limits).

With DNP3 SCADAPack Pulse Actions, an RTU Event field is available for you to:

  • Specify how the SCADAPack Outstation Handles any Pulse Action Events.

With each RTU Event field, you need to specify how the SCADAPack E-Series outstation handles the event. Choose from:

  • Disabled—Only applies to Alarm Limit RTU Events. The outstation does not generate an event if the point’s value exceeds the corresponding alarm limit.
  • Enabled—When the outstation generates an event for a point (for example by detecting a change in value), it stores the point’s value in its internal Event Buffer. The value is stored in the Event Buffer with a time stamp that was applied by the outstation’s internal clock at the time the event was generated.

If the outstation is configured to send unsolicited messages for that particular class, when a sufficient number of events have been stored in the Event Buffer, the outstation will attempt to send an unsolicited message to ClearSCADA. The unsolicited message will contain the events that are in the Event Buffer.

If the outstation is not configured to send unsolicited messages for that particular class, the outstation will buffer the events until ClearSCADA polls the outstation for the events in that particular event class.

  • Enabled Unsolicited—The generation of an event causes the outstation to attempt to send an unsolicited message to ClearSCADA. The message is generated regardless of the number of events in the outstation’s internal Event Buffer. As with the ‘Enabled’ option, the outstation’s internal clock applies a time stamp to the event at the time that the event is generated.

The unsolicited message may be sent immediately, or may be delayed according to the unsolicited message generation settings of the outstation (see Configure Unsolicited Message Generation and see Configure Event Configuration).

Further Information

Enable Unsolicited Message Generation for a Particular Class: see Enable Unsolicited Message Generation in the ClearSCADA Guide to the DNP3 Driver.

Specify how many Event Messages an Event Buffer is to Accumulate before a SCADAPack E-Series outstation sends an Unsolicited Message to ClearSCADA: see Configure Unsolicited Message Generation.

Example:

An analog point’s Point Data Class is set to generate Class 1 Events. The analog point includes this Alarm Limits configuration:

As such, whenever the point’s value rises from its Normal operating range to 80 or above, it generates a 1 High event. The outstation stores that event in its internal Event Buffer (as that limit’s RTU Event is set to Enabled). Once there are enough events in the buffer, the outstation generates an unsolicited message and reports those events to ClearSCADA.

If the point’s value continues to rise, it will generate another buffered event on rising above 85 (the 2 High limit).

Should the point’s value rise above 90, the 3 High event will cause the outstation to immediately trigger an unsolicited message, regardless of the number of events that are in its Event Buffer (as that limit’s RTU Event is set to Enabled Unsolicited). The unsolicited message will contain both the 2 High event (if that event has not already been reported to ClearSCADA) and the 3 High event. ClearSCADA will process the 2 High event as a Low priority Event and the 3 High event as a Medium priority Alarm (as those are the Severity settings that apply to those limits).

Further Information

Configure Alarm Limits.


DNP3 SCADAPack Driver Guide - Specify the Point Data Class that Applies when Communicating with another DNP3 Master (Points Used on DNP3 SCADAPack E-Series Outstations)

Specify the Point Data Class that Applies when Communicating with another DNP3 Master

This section only applies to DNP3 SCADAPack points on SCADAPack E-Series outstations that communicate with more than one DNP3 master (see Specify Whether an Outstation Communicates with Multiple DNP3 Masters).

Use the Master n Point Data Class field(s) within the Multi Master Configuration section of the <Point Type> tab to specify the DNP3 data class that applies when the outstation communicates with another DNP3 master (Master 2 or Master 3).

The options from which you can choose are the same as the Point Data Class options that you specify for Master 1 (ClearSCADA) on the <Point Type> tab (see Configure Common Properties of DNP3 SCADAPack Points).

Any Multi Master Configuration field(s) that are not applicable are ‘grayed out’ and unavailable for use. For instance, if an outstation communicates with two DNP3 Masters, only the Master 2 Point Data Class field will be available for use.

Further Information

SCADAPack E-Series Outstations that Communicate with more than one DNP3 Master.


DNP3 SCADAPack Driver Guide - Specify Whether any Profiles are Used to Change a Point's Limits or Current Value (Points Used on DNP3 SCADAPack E-Series Outstations)

Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value

With points on the DNP3 SCADAPack driver, Profiles can be used to enable a point’s limit(s) and/or current value to change at different times of the day or week.

DNP3 SCADAPack points support two types of Profile: ClearSCADA’s standard Time Profiles and DNP3 SCADAPack Profiles. Each of the points on an individual outstation have to use the same type of Profile. You specify the required Profile Type on the DNP3 SCADAPack Outstation Form (see Specify the Profile Type). Depending on the chosen type, different fields are available for use within the Profiles section on the <Point Type> tab of each DNP3 SCADAPack Point Form. Fields that apply to the other Profile type are ‘grayed out’ and unavailable for use.

With standard Time Profiles, you can specify a Profile per point limit and/or current value.

With DNP3 SCADAPack Profiles, you specify a Profile per day of the week. For each point that uses DNP3 SCADAPack Profiles, you need to assign a Profile to every day of the week. You can use the same Profile for multiple days if required, or use a different Profile for each day. If Profiles are assigned to some days, but not to others, a diagnostic message will be displayed. Depending on the type of point, its configuration and the configuration of each Profile database item, profiles can be used to control the point’s limit(s) and/or current value (see Configuring DNP3 SCADAPack Profiles).

To assign either type of Profile, you select the browse button next to the relevant field within the Profiles section. A Reference browse window is displayed—select the required Profile from the window.

When configuring each Profile, you need to take into account various Limitations and Restrictions to ensure that the Profile’s configuration is compatible with the point(s) with which it is to be associated.

The points on each DNP3 SCADAPack outstation can use up to 999 different Profile combinations between then. Each point’s Profile ID status attribute identifies the particular profile combination used by that point in the outstation. Should the 999 Profile combination limit be exceeded, a diagnostic message will be displayed whenever an attempt is made to save the point’s configuration.

When an outstation supports ClearSCADA’s Standard Time Profiles...
...the values or limits that type of Profile can be used to change are available for use on the Point Forms. (An analog point’s Current Value can only be profile-controlled if the point’s Point Type is set to an option other than ‘Physical Input’ (otherwise, the Current Value profile field is ‘grayed out’).)

When an outstation supports Daily DNP3 SCADAPack Profiles...
...fields on the Point Forms allow you to specify a different Profile per day of the week.
If any Daily profile does not have a value specified at midnight at the start of the day, ClearSCADA will assume the starting value to be that of the previous day’s profile.

With DNP3 SCADAPack analog and counter points, with each point limit to which a Profile is assigned, the unused ‘fixed’ Limit field within the Alarm Limits section of the <Point Type> tab becomes ‘grayed out’ and unavailable for use. (As that limit is profile-controlled.)

With DNP3 SCADAPack analog and counter points, use the Historic check box in the Profiles section of the <Point Type> tab to specify whether limit profiles are stored historically (current value profiles are not stored historically). The Profiles section’s Historic check box setting works independently to the settings specified on the Point Form’s Historic tab.

Select the Historic check box to store limit profiles historically (see How ClearSCADA Stores Profile Data Historically). Whenever you display the Historic Trend for the point, historic data for the limit profile(s) will be included in addition to any historically stored point data.

Ensure the check box is clear (the default) if ClearSCADA is not required to store profile data historically.

Further Information

Configuring Daily Profiles: see Configuring DNP3 SCADAPack Profiles.

Configuring Standard Time Profiles: see Configuring Time Profiles in the ClearSCADA Guide to Core Configuration.

Profile Configuration Limitations and Restrictions.

Display Historically Stored Profile Data.


DNP3 SCADAPack Driver Guide - Limitations and Restrictions (Points Used on DNP3 SCADAPack E-Series Outstations)

Limitations and Restrictions

This section summarizes the limitations and restrictions that need to be taken into account when configuring a Profile and associating that Profile with a DNP3 SCADAPack point or pulse action.

With standard (‘core’) Time Profiles, the specified Profile:

  • Has to be of the appropriate type:
  • A Float Time Profile to control the limits and/or current value of DNP3 SCADAPack Analog point(s)
  • An Unsigned Long Time Profile to either:
  • Control the current value of DNP3 SCADAPack Binary point(s) (providing that those points have a Point Type other than ‘Physical Input’)
  • Control the action(s) of DNP3 SCADAPack Pulse Action(s).
  • A Double Time Profile to control the High limit and/or current value of DNP3 SCADAPack Counter point(s).
  • Has to have its Mode set to ‘Stepped’
  • Has to use the same Time Zone as the DNP3 SCADAPack outstation on which the point(s) or pulse action(s) are located (for instance, ‘Local Time with Daylight Saving Time’ for a Profile that changes a point’s Limits during working hours). The outstation’s Time Zone is specified on the Outstation Form’s SCADAPack tab (see Configure the Profiler and ISaGRAF Time Zone Properties).
  • Has to have a compatible Range:
  • No greater than the point’s Zero to Full Scale range for analog points
  • 0 to 1 for binary points and pulse actions
  • A Minimum value greater than or equal to zero for counter points.
  • Must not use an inverted scale
  • Has to contain vectors (empty profiles are deemed to have invalid configuration)
  • If assigned to a DNP3 SCADAPack Analog point’s limits, the profile’s values:
  • Must not cross over profile values used to control any of the point’s other limits
  • Must not cross any of the point’s fixed Limits.

Further Information

Configuring Standard Time Profiles: see Configuring Time Profiles in the ClearSCADA Guide to Core Configuration.

With daily DNP3 SCADAPack Profiles, the specified Profile:

  • Has to be of the appropriate type:
  • A DNP3 SCADAPack Analog Profile to control the limits and/or current value of a DNP3 SCADAPack Analog point
  • A DNP3 SCADAPack Binary Profile to control a DNP3 SCADAPack Pulse’s action(s), or a DNP3 SCADAPack Binary point’s current value (unless that binary point has a ‘Physical Input’ Point Type)
  • A DNP3 SCADAPack Counter Profile to control the High limit and/or current value of a DNP3 SCADAPack Counter point.
  • Has to have its Current Value profile disabled if being used to control the limit(s) of a DNP3 SCADAPack Analog point that has a ‘Physical Input’ Point Type (see Disable or Enable the Profile for a Particular Limit or Current Value).
  • If it is a DNP3 SCADAPack Analog Profile, any limit profile values:
  • Must not cross over the values of any other limit profiles
  • Must not cross any of the point’s fixed Limits.

(The profiles for a binary point or pulse action can only contain the profile values 0 and 1. The profiles for a counter point can only contain profile values greater than or equal to 0. Both ViewX and the Automation Interface will reject any attempt to enter values that are deemed to be invalid (see Manually Edit the Vectors on a DNP3 SCADAPack Profile).)

If a Daily (DNP3 SCADAPack) profile does not have a value specified at midnight at the start of the day, ClearSCADA will assume the starting value to be that of the previous day’s last profile value. (The previous day’s profile being that specified for the previous day in the Profiles section of the Point Form.)

Further Information

Configuring DNP3 SCADAPack Profiles.


DNP3 SCADAPack Driver Guide - How ClearSCADA Stores Profile Data Historically (Points Used on DNP3 SCADAPack E-Series Outstations)

How ClearSCADA Stores Profile Data Historically

You use the Historic check box within the Profiles section of each DNP3 SCADAPack Point Form to specify whether ClearSCADA is to store limit profile data historically (current value profiles are not stored historically).

When the Historic check box is selected, ClearSCADA will store historically the data for any enabled Daily (DNP3 SCADAPack) limit profiles, or configured Standard limit profiles (depending on the type of Profile used by the point).

As Profiles have a one-minute resolution, ClearSCADA will store the value of each limit profile historically, once per minute, providing that:

  • The point is In Service
  • The point has valid configuration
  • The profile’s value has changed from its previously stored value.

The data that ClearSCADA stores historically comprises the profile data that is configured in the ClearSCADA database. Whenever a profile’s configuration is changed in ClearSCADA, those changes have to be downloaded to the outstation in order for that outstation to use the new profile data. With historically stored profile data, the stored data will differ from the actual profile used by the outstation for the period between any configuration changes being saved in ClearSCADA and those changes being downloaded to the outstation.

Further Information

Display Historically Stored Profile Data.


DNP3 SCADAPack Driver Guide - Display Historically Stored Profile Data (Points Used on DNP3 SCADAPack E-Series Outstations)

Display Historically Stored Profile Data

If a DNP3 SCADAPack point has limit(s) that are profile-controlled and that profile data is stored historically, you can display the historic profile data in either of two ways:

  • In the form of a historic Trend, using the point’s Display Historic Trend pick action.

Example:

With this particular DNP3 SCADAPack analog point, the point’s four High limits and one of its Low limits are Profile-controlled. ClearSCADA is configured to store both the point’s and the DNP3 SCADAPack Profile’s data historically.

When the Display Historic Trend pick action is used to display the historic data in Trend format, the point’s data is displayed along with both its fixed and Profile-controlled limits.

Profile-controlled limits are shown as dashed lines (by default). The lines step up or down, according to the profile’s change in value.
Fixed limits appear as unchanging horizontal lines.

  • A ‘custom’ queries List can be configured and used to display historic profile data in List format.

Example:

This example uses the same DNP3 SCADAPack analog point as the example above.

The historic data for the profiles that control the point’s 4 High and 3 High Limits is to be displayed in a ‘custom’ List. The List is embedded on a Mimic.

The List uses this SQL query:

SELECT TOP( 100000 )
"RecordId", "RecordTime" AS "~Time", "FormattedValue", "AggrName"
FROM
CDBPROFILEHISTORIC
WHERE
"Id" = 4204 AND ( "AggrName" = 'High4ProfileHistoric' OR "AggrName" = 'High3ProfileHistoric' ) AND "~Time" BETWEEN { OPC 'Month' } AND { OPC 'Now' }
ORDER BY
"~Time" DESC

CDBProfileHistoric is a pseudo historic table. It provides the interface to the historic aggregates that store the profile data.

The Id is that of the DNP3 SCADAPack analog point for which profile data is being displayed. (The Id can be ascertained by viewing the point’s Status display.)

The historic data for each limit profile is stored in a separate aggregate. Each aggregate forms part of the CeNET table for the type of point that is being queried. The CeNETAnalog table includes the historic aggregates for DNP3 SCADAPack Analog points and the CeNETCounter table includes the historic aggregates for DNP3 SCADAPack Counter points. You can use the database Schema, the OPC Data Bar, or the OPC Historic Data Bar to ascertain the name of each aggregate.

You can ascertain the names of the aggregates in which historic profile data is stored, by looking up the point in the OPC Historic Data Bar.

(Unlike each point’s standard Historic aggregate, which appears as the Historic tab on each Point Form, historic profile aggregates do not appear on the Point Form, as they do not contain any configuration fields.)

In this particular example, only the historic data for the High4ProfileHistoric and High3ProfileHistoric aggregates is to be queried.

Each aggregate name corresponds to the specific point Limit that is profile-controlled, regardless of the type of Profile (‘Daily’ or ‘Standard’) that is used to control that Limit. (With each DNP3 SCADAPack Analog point, up to eight ProfileHistoric aggregates can be queried, comprising four High and four Low ProfileHistoric aggregates. A List querying historically stored limit profile data for a DNP3 SCADAPack Counter point would query the HighProfileHistoric aggregate.)

RecordTime is used to constrain the List’s entries, so that the List only includes profile data from the start of the current month to ‘now’.

The SQL query results in the following type of information being displayed in List format:

Further Information

Trends: see the ClearSCADA Guide to Trends.

Producing Custom Lists: see Custom Lists in the ClearSCADA Guide to Lists.

CDBProfileHistoric database table: see the database Schema.

Using the Database Schema: see Working with the Database Schema in the ClearSCADA Guide to the Database.


DNP3 SCADAPack Driver Guide - Configure an Output Point or Pulse Action's Interlock Properties (Points Used on DNP3 SCADAPack E-Series Outstations)

Configure an Output Point or Pulse Action’s Interlock Properties

NOTE: For each DNP3 SCADAPack Output point that ClearSCADA is to control exclusively, or for which point control alters between ClearSCADA and ISaGRAF, ensure that the point’s Control aggregate is enabled (see Specify Whether an Output Point is Controlled by ClearSCADA in the ClearSCADA Guide to the DNP3 Driver).
For each DNP3 SCADAPack Output point that is controlled exclusively by another application, rather than ClearSCADA, you need to disable that point’s Control aggregate. For such points, fields on the Control tab are unavailable for use and you can ignore the rest of this section.

In addition to the properties that are common to DNP3 Output points (see Configure the DNP3-Specific Control Properties on DNP3 Output Points in the ClearSCADA Guide to the DNP3 Driver), DNP3 SCADAPack Output points have the properties that are described below. The properties below also apply to DNP3 SCADAPack Pulse Actions.

  • Remote Control Enabled Interlock Point—For any DNP3 SCADAPack output point or pulse action that is attached to an ISaGRAF Output Board, the SCADAPack E-Series outstation will not usually allow the point or pulse action to be controlled via DNP3. This is because the point or pulse action is assumed to be controlled by ISaGRAF. Use the Remote Control Enabled Interlock Point field to specify a DNP3 SCADAPack point that can be used to inhibit ISaGRAF’s control of this output point, so that the point or pulse action can be controlled by DNP3.

When the Remote Control Enabled Interlock Point is not active (OFF), ISaGRAF has control of the output point or pulse action. The outstation will not accept control requests via DNP3.

When the Remote Control Enabled Interlock Point is active (ON), ISaGRAF no longer has control of the output point or pulse action. The outstation will accept control requests via DNP3.

The Remote Control Enabled Interlock Point has to reside on the same outstation as the output point or pulse action and have a specific Point Type (see Interlock Points).

NOTE: Any point defined as a Remote Control Enabled Interlock Point cannot be defined as any other type of status point—for example a Rate of Change point (see Configure Rate of Change Properties). You can, however, use the same Remote Control Enabled Interlock Point on multiple points and pulse actions.

  • Interlock Timeout—Use this field to specify the length of time for which the Remote Control Enabled Interlock Point is to remain active (ON) under normal operating conditions.

If the Remote Control Enabled Interlock Point remains active for longer than this period and is configured with a Point Data Class of Class n Event, the outstation will generate a DNP3 Event for the Remote Control Enabled Interlock Point after this timeout, and at 10-minute intervals thereafter, while the Remote Control Enabled Interlock Point remains active.

Enter the timeout in the OPC Time Format. Specify zero if an interlock timeout is not required.

  • Interlock Drop Output—This check box only applies to DNP3 SCADAPack Binary Output points and DNP3 SCADAPack Pulse Actions.

Select this check box if the outstation is to set the point’s current state to the ‘off’ state whenever:

  • the Remote Control Enabled Interlock Point becomes active (ON)

and:

  • the point is under ISaGRAF control.

(With a Binary Output point, the ‘off’ state is State 0.)

Ensure that the check box is clear if the point or pulse action is to retain the state that it was in at the time that the Remote Control Enabled Interlock Point became active (ON). Be aware that, with the check box clear, should the point or pulse action be under ISaGRAF control when the Interlock Point is activated, that point or pulse action will maintain the state to which it was controlled by the ISaGRAF application.


DNP3 SCADAPack Driver Guide - Specify any Point Mapping (Points Used on DNP3 SCADAPack E-Series Outstations)

Specify any Point Mapping

This section only applies to DNP3 SCADAPack points that have their Point Type set to Physical Input or Physical Output (see Configure Common Properties of DNP3 SCADAPack Points). (For other Point Types, the Mapping tab is disabled.)

Use the fields on the Mapping tab of the DNP3 SCADAPack Point Form to Specify Whether Point Mapping is Used to define the source and location of the point data. When mapping is used, the fields on the tab vary, depending on the type of point and the device to which point data is being mapped.

DNP3 SCADAPack Trip-Close Pulse Actions have two Mapping tabs—one for each pulse action. Ensure that the relevant properties are configured on each of these tabs.


DNP3 SCADAPack Driver Guide - Specify Whether Point Mapping is Used (Points Used on DNP3 SCADAPack E-Series Outstations)

Specify Whether Point Mapping is Used

This section applies to points that have a Point Type of Physical Input or Physical Output. (For other Point Types, the Mapping tab is disabled. This is indicated by the text ‘No Mapping’ being displayed on the tab in place of any fields.)

Use the Mapping combo box on the Mapping tab to specify whether mapping is used to specify the source and location of a point. The options vary, depending on the Outstation Type of the DNP3 SCADAPack E-Series outstation with which the point is associated (see Specify the Outstation Type).

  • SCADAPack ES Remote I/O—The point is on a SCADAPack ES Remote I/O module and the I/O on that module have been allocated manually.

A suitably configured DNP3 SCADAPack ES Remote IO item has to exist in the ClearSCADA database, to represent the I/O module. Use the rest of the fields on the Mapping tab to map the point data (see Map to Point Data on a SCADAPack ES Remote I/O Module).

(If the point is on a SCADAPack ES outstation that is used as an I/O expansion module and the I/O on that module have the allocated automatically (the default), you do not need to specify any mapping for that point.)

  • 5000 Series I/O—The point is on a 5000 Series I/O module.

A suitably configured DNP3 SCADAPack 5000 Series IO item has to exist in the ClearSCADA database, to represent the I/O module. Use the rest of the fields on the Mapping tab to map the point data (see Map to Point Data on a 5000 Series I/O Card).

As the on-board I/O on a SCADAPack 330E, 334E, 350E or 357E outstation are not automatically allocated DNP3 Point Numbers, such I/O cards need representing by DNP3 SCADAPack 5000 Series IO item(s) in the ClearSCADA database.

  • SCADAPack ER I/O—The point is on an ER I/O card.

A suitably configured DNP3 SCADAPack ER IO item has to exist in the ClearSCADA database, to represent the I/O card. Use the rest of the fields on the Mapping tab to map the point data (see Map to Point Data on a SCADAPack ER I/O Card).

  • Remote DNP3—The point is on a remote DNP3 outstation.

A suitably configured DNP3 SCADAPack Remote DNP3 Device, or Remote E-Series Outstation item has to exist in the ClearSCADA database, to represent the remote outstation. Use the rest of the fields on the Mapping tab to map the point data (see Map to Point Data on a Remote DNP3 Device or Remote E-Series Outstation).

You can only map points on a DNP3 SCADAPack Remote DNP3 Device, or Remote E-Series Outstation if those points are scanned by a Data Concentrator.

  • No Mapping—Point mapping is not used on the point. Select this option if the point’s Point Number explicitly defines the I/O with which the point is associated. For example, when the point is on a:
  • SCADAPack ES outstation that is used as an I/O expansion module, and the I/O Point Numbers on that module were allocated automatically when the module was connected to the outstation.

(If the default automatic allocation is not suitable and the I/O is allocated manually, the Mapping has to be specified as SCADAPack ES Remote I/O (see above).)

Further Information

Configuring I/O Expansion Cards and Modules.

SCADAPack E-Series Data Concentrators and Remote Outstations.


DNP3 SCADAPack Driver Guide - Map to Point Data on a SCADAPack ES Remote I/O Module (Points Used on DNP3 SCADAPack E-Series Outstations)

Map to Point Data on a SCADAPack ES Remote I/O Module

When Mapping to point data on a SCADAPack ES Remote I/O module, use these fields to specify the physical location of the point on that module:

  • I/O Source—Use to Specify the I/O Module, I/O Card, or Remote Outstation on Which the Point is Located.
  • Remote Point Number—Use to Specify the Location of the Point on the I/O Module, I/O Card, or Remote Outstation.


DNP3 SCADAPack Driver Guide - Map to Point Data on a 5000 Series I/O Card (Points Used on DNP3 SCADAPack E-Series Outstations)

Map to Point Data on a 5000 Series I/O Card

When Mapping to point data on a 5000 Series I/O card, use these fields to specify the physical location of the point on that card:

  • I/O Source—Use to Specify the I/O Module, I/O Card, or Remote Outstation on Which the Point is Located.
  • Channel—Use to Specify the Location of the Point on the I/O Module, I/O Card, or Remote Outstation.
  • Point Type—Applies to Analog Input points only. Use this combo box to specify the type of data that the point is used to monitor.


DNP3 SCADAPack Driver Guide - Map to Point Data on a SCADAPack ER I/O Card (Points Used on DNP3 SCADAPack E-Series Outstations)

Map to Point Data on a SCADAPack ER I/O Card

When Mapping to point data on a SCADAPack ER I/O card, use these fields to specify the physical location of the point on that card:

  • I/O Source—Use to Specify the I/O Module, I/O Card, or Remote Outstation on Which the Point is Located.
  • Channel—Use to Specify the Location of the Point on the I/O Module, I/O Card, or Remote Outstation.


DNP3 SCADAPack Driver Guide - Map to Point Data on a Remote DNP3 Device or Remote E-Series Outstation (Points Used on DNP3 SCADAPack E-Series Outstations)

Map to Point Data on a Remote DNP3 Device or Remote E-Series Outstation

When Mapping to point data on a Remote DNP3 device, use these fields to specify the physical location of the point on that device:

  • I/O Source—Use to Specify the I/O Module, I/O Card, or Remote Outstation on Which the Point is Located.
  • Remote Point Number—Use to Specify the Location of the Point on the I/O Module, I/O Card, or Remote Outstation.


DNP3 SCADAPack Driver Guide - Specify the I/O Module, I/O Card, or Remote Outstation on Which the Point is Located (Points Used on DNP3 SCADAPack E-Series Outstations)

Specify the I/O Module, I/O Card, or Remote Outstation on Which the Point is Located

Use the I/O Source field on the Mapping tab to specify the expansion I/O module or card on which a point is located.

For a point that is on a remote E-Series or DNP3 outstation, use the field to specify the name of that outstation. In each case, use the browse button to display a Reference browse window and select the relevant entry from the window. The entries in the window are restricted to those I/O database item(s) and remote device(s) that are associated with the Outstation that is specified on the point’s <Point Type> tab.


DNP3 SCADAPack Driver Guide - Specify the Location of the Point on the I/O Module, I/O Card, or Remote Outstation (Points Used on DNP3 SCADAPack E-Series Outstations)

Specify the Location of the Point on the I/O Module, I/O Card, or Remote Outstation

Point data is stored in a series of point channels on each I/O module or card. Use the Channel or Remote Point Number combo box on the Mapping tab to specify the point channel that is used to store this point’s data on the I/O module or card.

If the point Mapping is to a Remote DNP3 device, you need to specify the Remote Point Number manually in the field of that name.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack Analog Points

Configuring DNP3 SCADAPack Analog Points

The ClearSCADA DNP3 SCADAPack E-Series driver supports the following DNP3 SCADAPack analog point types:

  • Physical Analog Inputs using DNP3 SCADAPack Analog Input Points.
  • Physical Analog Outputs using DNP3 SCADAPack Analog Output Points.
  • Derived (User and System) Analog Points using either DNP3 SCADAPack Analog Input Point or DNP3 SCADAPack Analog Output Points.

You configure the properties of each analog point using the appropriate DNP3 SCADAPack Analog Point Form. Each Form has several tabs. This section covers configuration of properties on the Analog Point and Mapping tabs of each Point Form, plus the Control tab of the DNP3 SCADAPack Analog Output Point Form.

For both DNP3 SCADAPack Analog Input Point and DNP3 SCADAPack Analog Output Points, use the Analog Point tab to:

  • Configure General Properties
  • Configure Alarm Limits
  • Specify when a Change in Value Triggers a Change in Point State
  • Configure Overrange and Underrange Processing
  • Define whether the Alarm Limits can be Tuned
  • Specify how the SCADAPack Outstation Handles Underrange, Overrange and Invalid RTU Events
  • Specify the Area of Interest (see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events in the ClearSCADA Guide to Core Point Configuration). (Only applies if the Area of Interest feature is enabled on your system.)
  • Optionally Associate one or More Profiles with the Point
  • Configure Point Scaling
  • Configure the Event Deviation Properties
  • Configure Rate of Change Properties
  • Specify Whether the SCADAPack Outstation is to Detect if an Analog Point has Stopped Changing
  • Configure Formatting Properties (see Define the Appearance of an Analog Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Configure Override Properties (see Configure Override Properties in the ClearSCADA Guide to the DNP3 Driver)
  • Configure Significant Change Properties
  • Configure the No Change Properties (see Detect Whether a Point Value has Stopped Changing in the ClearSCADA Guide to Core Point Configuration)
  • Configure Trend Properties (see Define an Analog Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure Logged Data Properties (see Configure Logged Data Properties in the ClearSCADA Guide to the DNP3 Driver)
  • Specify the Point Data Class that Applies when Communicating with another DNP3 Master.

For DNP3 SCADAPack Analog Input Points and DNP3 SCADAPack Analog Output Points that are Physical Inputs or Physical Outputs, use the Mapping tab to:

  • Specify any Point Mapping.

For DNP3 SCADAPack Analog Output Points that can be controlled by ClearSCADA, use the Control tab to:

  • Configure the Analog Control Range and Severity Properties (see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Promote Retrieval of Data Associated with Controls (see Specify which Outstations are Integrity Polled after a Successful Control in the ClearSCADA Guide to the DNP3 Driver)
  • Configure Analog Output Point DNP3 and SCADAPack Control Properties.

NOTE: For each DNP3 SCADAPack Output point that ClearSCADA is to control exclusively, or for which point control alters between ClearSCADA and ISaGRAF, ensure that the point’s Control aggregate is enabled (see Specify Whether an Output Point is Controlled by ClearSCADA in the ClearSCADA Guide to the DNP3 Driver).
For each DNP3 SCADAPack Output point that is controlled exclusively by another application, rather than ClearSCADA, you need to disable that point’s Control aggregate. For such points, fields on the Control tab are unavailable for use and you can ignore the above references.

The properties on other tabs are common to points on many advanced drivers—for information, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

NOTE: If a SCADAPack E-Series outstation is a Modbus Slave and a Modbus master is to read or write to 32-bit analog point data on that outstation, you should specify that data using a DNP3 SCADAPack 32-bit Point Modbus Map (see Configuring DNP3 SCADAPack 32-bit Point Modbus Maps).

If the outstations on your system are to sample analog point data for data trends, you need to configure the required Trend item(s) in the database and associate those items with the relevant analog points (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality).


DNP3 SCADAPack Driver Guide - General Properties (Configuring DNP3 SCADAPack Analog Points)

General Properties

Use the fields at the top of the Analog Point tab to define the general properties of a DNP3 SCADAPack Analog point.

For further information on these properties, see Configure Common Properties of DNP3 SCADAPack Points in this guide, and see Configure General Point Properties in the ClearSCADA Guide to the DNP3 Driver.


DNP3 SCADAPack Driver Guide - Configure Alarm Limits (Configuring DNP3 SCADAPack Analog Points)

Configure Alarm Limits

Use the fields within the Alarm Limits section of the Analog Point tab to set limits for a DNP3 SCADAPack analog point and specify whether an alarm or event is generated if the point’s value exceeds those limits.

The following properties are common to DNP3 SCADAPack analog points:

  • Overrange—Use to specify the maximum expected engineering value of the point, and the generation of alarms or events if the point value is greater than this value. (Overrange is equivalent to the Full Scale property of analog points on many other drivers.)
  • 1 High, 2 High, 3 High, and 4 High—Use to specify whether ClearSCADA generates an alarm or event whenever the points value rises to, or goes above, the corresponding Limit value.
  • Normal—Specifies whether ClearSCADA generates an event whenever the point returns to its normal operating range (the range between the 1 High and 1 Low Limit values).
  • 1 Low, 2 Low, 3 Low, and 4 Low—Use to specify whether ClearSCADA generates an alarm or event whenever the points value falls to, or goes below, the corresponding Limit value.
  • Underrange—Use to specify the minimum expected engineering value of the point, and whether ClearSCADA generates an alarm or event if the point value is less than this value. (Underrange is equivalent to the Zero Scale property of analog points on many other drivers.)
  • Invalid—Use to specify whether ClearSCADA generates an alarm or event whenever the point’s value is reported as invalid by the outstation. Use the fields associated with this state to define the properties should the analog to digital conversion process fail in the outstation.

For further information on configuring limits, see Configure the Limits for an Analog Point in the ClearSCADA Guide to Core Point Configuration.

NOTE: If any High or Low limits are profile-controlled, the unused ‘fixed’ Limit field within the Alarm Limits section of the tab will be ‘grayed out’ and unavailable for use. You still use the other fields within the Alarm Limits section to configure other properties associated with such limits. For more information, see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value.

If the point’s Point Data Class is set to Class 1 Event, Class 2 Event or Class 3 Event and the point’s limit has a Severity of Event or Alarm, the SCADAPack E-Series outstation can be configured to generate and store an event in its Event Buffer when the corresponding alarm limit is transgressed. The event is stored in the outstation’s Event Buffer according to the Point Data Class of the point (see Configure Common Properties of DNP3 SCADAPack Points). Use each limit’s RTU Event field to specify whether the outstation generates an event whenever the corresponding Alarm Limit is exceeded and if so, whether it just stores that event, or immediately generates an unsolicited message (see Specify Whether a Class n Event Triggers an Unsolicited Message).

Use the Out of Range RTU Event field at the bottom of the Alarm Limits section to Specify how the SCADAPack Outstation Handles Underrange, Overrange and Invalid RTU Events.

(RTU Event fields are ‘grayed out’ and unavailable for use if the point’s Point Data Class is set to Local or Class 0 Static Only.)


DNP3 SCADAPack Driver Guide - Specify when a Change in Value Triggers a Change in Point State (Configuring DNP3 SCADAPack Analog Points)

Specify when a Change in Value Triggers a Change in Point State

The following fields are displayed toward the bottom of the Alarm Limits section on the Analog Point tab:

  • Hysteresis—Use to specify the amount by which the DNP3 SCADAPack point’s engineering value has to change for an alarm condition to clear. For further information, see Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm in the ClearSCADA Guide to Core Point Configuration.

Hysteresis does not apply to Overrange and Underrange. When a point’s value returns from one of these conditions, the SCADAPack E-Series outstation immediately generates an event at the limit value.

  • Persistence into Alarm—Use to specify how long the point’s value has to transgress an Alarm Limit for before the outstation generates an event. If the point’s value returns from the transgressed state within this time, no event is generated.

Enter the time in the OPC Time Format.

Persistence into Alarm does not apply to Overrange and Underrange. When a point’s value returns from one of these conditions, the outstation immediately generates an event at the time that the limit is transgressed.

  • Persistence out of Alarm—When the point’s value is returning from an Alarm Limit transgression, this property specifies how long the point’s value has to remain within the Alarm Limit before the outstation generates an event. If the point’s value transgresses the Alarm Limit within this time, no event is generated.

Enter the time in the OPC Time Format.

With the Overrange and Underrange conditions, the outstation generates an event once the point’s value has remained Overrange or Underrange for one tenth of the specified Persistence out of Alarm time.

NOTE: The Persistence into/out of Alarm properties are only relevant if the point has a Point Data Class of Class n Event (see Configure Common Properties of DNP3 SCADAPack Points).


DNP3 SCADAPack Driver Guide - Configure Overrange and Underrange Processing (Configuring DNP3 SCADAPack Analog Points)

Configure Overrange and Underrange Processing

The following fields are displayed toward the bottom of the Alarm Limits section on the Analog Point tab:

  • Zero Threshold—Use to specify the engineering value below which the DNP3 SCADAPack analog point’s value will be forced to zero.

This property does not apply to Analog Output points that have a Point Type of Physical Out.

  • Engineering Units Exceeded—Use to specify how ClearSCADA processes the point’s value if the value returned from the SCADAPack E-Series outstation is greater than Overrange or less the Underrange. For further information, see Define how Over Range and Under Range Values are Processed in the ClearSCADA Guide to Core Point Configuration.


DNP3 SCADAPack Driver Guide - Define whether the Alarm Limits can be Tuned (Configuring DNP3 SCADAPack Analog Points)

Define whether the Alarm Limits can be Tuned

The Tune Limits field is displayed toward the bottom of the Alarm Limits section on the Analog Point tab:

  • Tune Limits—Use the check box to specify whether a points alarm limits can be tuned. For further information, see Define whether an Analog Point’s Limits can be Tuned in the ClearSCADA Guide to Core Point Configuration.

If this option is enabled, operators can tune the ‘standard’ alarm limits using the Tune Alarm Limits pick action, providing that those limits are not profile-controlled (see Optionally Associate one or More Profiles with the Point). Be aware that the action of tuning a point’s limits triggers ClearSCADA to download the point’s Alarm Limits to the SCADAPack E-Series outstation. (Should such a download be unsuccessful, a Tune Limits Alarm is generated.)


DNP3 SCADAPack Driver Guide - Specify how the SCADAPack Outstation Handles Underrange, Overrange and Invalid RTU Events (Configuring DNP3 SCADAPack Analog Points)

Specify how the SCADAPack Outstation Handles Underrange, Overrange and Invalid RTU Events

The Out of Range RTU Event field is displayed at the bottom of the Alarm Limits section on the Analog Point tab:

  • Out of Range RTU Event—Applies only if a point’s Point Data Class is set to Class 1 Event, Class 2 Event or Class 3 Event (see Configure Common Properties of DNP3 SCADAPack Points).

Use the Out of Range RTU Event combo box to specify whether the SCADAPack E-Series outstation just stores the event, or immediately generates an unsolicited message whenever the point’s value becomes Underrange, Overrange, or Invalid (see Specify Whether a Class n Event Triggers an Unsolicited Message).

NOTE: If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed below the Out of Range RTU Event field. For information on this property, see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events in the ClearSCADA Guide to Core Point Configuration.


DNP3 SCADAPack Driver Guide - Optionally Associate one or More Profiles with the Point (Configuring DNP3 SCADAPack Analog Points)

Optionally Associate one or More Profiles with the Point

Use the fields within the Profiles section of the Analog Point tab to specify whether any of the point’s limits and/or current value are profile-controlled. (A DNP3 SCADAPack Analog point’s current value can be profile-controlled providing that point has a Point Type other than ‘Physical Input’.)

Depending on the outstation’s Profile Type, DNP3 SCADAPack analog points can use either:

  • Stepped Standard Float Time Profiles, which you optionally specify in the Current Values to 4 Low fields within the Profiles section of the tab. (The Current Value field is ‘grayed out’ and unavailable for use if the analog’s Point Type is set to ‘Physical Input’.)

You only need specify a Profile for those limits or current value that are to be Profile-controlled. Leave the fields blank for any limits or current value that are not to be Profile-controlled. Limits that are not Profile-controlled are specified within the Alarm Limits section of the Point Form (see Configure Alarm Limits).

  • Daily DNP3 SCADAPack Analog Profiles, which you optionally specify in the Sunday to Saturday fields.

If the analog’s Point Type is set to ‘Physical Input’, the point’s current value cannot be profile-controlled. As such, the ‘CurrentValue’ profile has to be disabled on each of the DNP3 SCADAPack Analog Profile database items that are specified in any of the Sunday to Saturday fields. If the ‘CurrentValue’ profile is enabled on any of the Profile database items, the point is deemed to have invalid configuration and a diagnostic message is displayed when the point’s configuration is saved (see Mandatory Configuration and Invalid Configuration Messages in the ClearSCADA Guide to Core Configuration). For information on disabling a profile, see Disable or Enable the Profile for a Particular Limit or Current Value.

Leave the fields blank if the point is not Profile-controlled, or specify a Profile per day if the point is Profile-controlled.

Fields that do not apply to the specified Profile Type are ‘grayed out’ and unavailable for use.

With either type of Profile, use the Historic check box to specify whether ClearSCADA is to store point limit profile values historically.

For more information, see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value.

Remember that various Limitations and Restrictions have to be taken into account in order to associate Profiles successfully with a DNP3 SCADAPack point.


DNP3 SCADAPack Driver Guide - Configure Point Scaling (Configuring DNP3 SCADAPack Analog Points)

Configure Point Scaling

Use the fields within the Scaling section of the Analog Point tab to specify the range of raw input signal and engineering values for a DNP3 SCADAPack analog point.

  • Full Scale and Zero Scale—Specify the values that the SCADAPack E-Series outstation uses to convert the raw integer values into engineering values and vice versa.

In the Raw column, enter the uppermost limit for a raw input signal in the Full Scale field, and the lowest limit for a raw input signal in the Zero Scale field.

In the Engineering column, enter the highest valid engineering value in the Full Scale field, and the lowest valid engineering value in the Zero Scale field.

The Engineering values are independent of the Overrange and Underrange properties defined in the Alarm Limits section of the tab. (For details on configuring Overrange and Underrange alarms, see Configure Alarm Limits.)

  • Apply Master Station Scaling—Select this check box if ClearSCADA is to scale the integer values that the outstation reports for the point. If the outstation reports floating point values—for example if the DNP Object Type is set to Short Float Analog Input (g30v5) (see Configure Common Properties of DNP3 SCADAPack Points)—this setting has no effect.

If the check box is not selected and the outstation reports integer values for the point, ClearSCADA will process alarms and events based on the Raw value, rather than the Engineering value. The outstation, however, will process alarms and events using the Engineering value of the point.


DNP3 SCADAPack Driver Guide - Configure the Event Deviation Properties (Configuring DNP3 SCADAPack Analog Points)

Configure the Event Deviation Properties

Use the fields within the Event Deviation section of the Analog Point tab to determine the circumstances in which a SCADAPack E-Series outstation should generate an event for a DNP3 SCADAPack point, based on a change in the point’s value.

  • Type—Use to specify the type of Event Deviation processing that the outstation applies to the point. Choose from:
  • None—The outstation does not generate an event for the point, should the point merely deviate in value. However, the outstation may generate events should the point’s value cross over other limit thresholds.
  • Absolute—The outstation only generates an event for the point if the point’s value changes by a defined amount.

Use the Deadband field to define the amount by which the value has to change.

  • Percentage of Span—The outstation only generates an event for the point if the point’s value changes by a defined percentage of its span. The span is the point range (Engineering Zero Scale to Engineering Full Scale—see Configure Point Scaling).

Use the Deadband field to define the percentage.

  • Deadband—Applies only if the point’s Point Data Class is set to Class 1 Event, Class 2 Event or Class 3 Event (see Configure Common Properties of DNP3 SCADAPack Points). Specify the amount or percentage by which a point’s engineering value has to change before the outstation generates an event for the point.
  • RTU Event—Applies only if the point’s Point Data Class is set to Class 1 Event, Class 2 Event or Class 3 Event (see Configure Common Properties of DNP3 SCADAPack Points).

Use the RTU Event combo box to specify whether the outstation stores an event, or immediately generates an unsolicited message whenever the point’s value changes by the Deadband amount (see Specify Whether a Class n Event Triggers an Unsolicited Message).

NOTE: With physical analog inputs, you can use the Event Deviation properties to help prevent the SCADAPack E-Series outstation from reporting insignificant fluctuations in value to ClearSCADA. This can help reduce the bandwidth usage between ClearSCADA and the outstation, and improve performance of historical data access (for example, Trends).


DNP3 SCADAPack Driver Guide - Configure Rate of Change Properties (Configuring DNP3 SCADAPack Analog Points)

Configure Rate of Change Properties

Use the fields within the Rate of Change section of the Analog Point tab to define if the SCADAPack E-Series outstation detects whether a DNP3 SCADAPack point’s value is rising or falling too quickly.

NOTE: Rate of Change properties do not apply to analog points for which the Point Type is set to Physical Output (see Configure Common Properties of DNP3 SCADAPack Points).

  • Period—Specify the period over which the rate of change is measured. Specify a period of zero if rate of change detection is not to be performed.

Enter the time in the OPC Time Format.

  • Rising Threshold—Specify the amount, as a percentage of the point’s engineering range, that the point’s value can increase by within the Period (see above) before the Rising Point (see below) is set.
  • Rising Point—Specify a DNP3 SCADAPack Binary Input Point that the outstation will turn on when an excessive Rate of Rise is detected for this point.

This point has to exist as a DNP3 SCADAPack Binary Input Point in the ClearSCADA database, and be associated with the same DNP3 SCADAPack E-Series Outstation as the analog point. The point also has to have a Point Type of User (Derived) (see Configure Common Properties of DNP3 SCADAPack Points).

  • Falling Threshold—Specify the amount, as a percentage of the point’s engineering range, that the point’s value can decrease by within the Period (see above) before the Falling Point (see below) is set.
  • Falling Point—Specify a DNP3 SCADAPack Binary Input Point that the outstation will turn on when an excessive Rate of Fall is detected for this point.

This point has to exist as a DNP3 SCADAPack Binary Input Point in the ClearSCADA database, and be associated with the same DNP3 SCADAPack E-Series Outstation as the analog point. The point also has to have a Point Type of User (Derived) (see Configure Common Properties of DNP3 SCADAPack Points).

NOTE: A DNP3 SCADAPack Binary Input Point that is linked to one Rising Point or Falling Point cannot be linked to any other Rising Point, Falling Point, No Change Point (see Specify Whether the SCADAPack Outstation is to Detect if an Analog Point has Stopped Changing), control Interlock Point (see Interlock Points), or I/O Status Point (see Configure the 5000 Series I/O Properties).


DNP3 SCADAPack Driver Guide - Specify Whether the SCADAPack Outstation is to Detect if an Analog Point has Stopped Changing (Configuring DNP3 SCADAPack Analog Points)

Specify Whether the SCADAPack Outstation is to Detect if an Analog Point has Stopped Changing

Use the fields within the SCADAPack No Change section of the Analog Point tab to specify if the SCADAPack E-Series outstation is to detect whether a DNP3 SCADAPack point’s value is not changing by an expected value often enough.

NOTE: The SCADAPack No Change properties do not apply to analog points that have a Point Type of Physical Output.

  • Period—Specify the period over which the outstation is to perform its No Change detection. Specify a period of zero if the outstation is not to perform any No Change detection.

Enter the time in the OPC Time Format.

  • Threshold—Specify the amount, as a percentage of the point’s engineering range, that the point’s value is expected to change by within the Period specified above. If the point does not change by at least this amount, the Point (see below) is set.
  • Point—Specifies the DNP3 SCADAPack Binary Input Point that the outstation will turn on when a No Change condition is detected for this point.

This point has to exist as a DNP3 SCADAPack Binary Input Point in the ClearSCADA database, and be associated with the same DNP3 SCADAPack E-Series Outstation as the analog point. The point also has to have a Point Type of User (Derived) (see Configure Common Properties of DNP3 SCADAPack Points). You can only use the point as a No Change point for one analog point.


DNP3 SCADAPack Driver Guide - Configure Significant Change Properties (Configuring DNP3 SCADAPack Analog Points)

Configure Significant Change Properties

Use the fields within the Significant Change section of the Analog Point tab to define how much the DNP3 SCADAPack point’s engineering value has to change by in order for the SCADAPack E-Series outstation to generate an event for the point.

  • Type—Use to specify whether significant change is enabled, and whether the Deadband value is a percentage of the point’s range, or an absolute change of the point’s engineering value.
  • Deadband—Use to specify the amount which the point’s value has to change by before the outstation will generate an event for the point.

For further information, see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration.


DNP3 SCADAPack Driver Guide - Configure Analog Output Point DNP3 and SCADAPack Control Properties (Configuring DNP3 SCADAPack Analog Points)

Configure Analog Output Point DNP3 and SCADAPack Control Properties

NOTE: This section does not apply to DNP3 SCADAPack output points that are controlled exclusively by another application, rather than ClearSCADA. (For further information, see Specify Whether an Output Point is Controlled by ClearSCADA in the ClearSCADA Guide to the DNP3 Driver.)

For DNP3 SCADAPack output points that can be controlled by ClearSCADA, use the fields at the bottom of the Control tab to define the DNP3- and SCADAPack-specific control properties of the point.

For information on the first four fields, see Configure the DNP3-Specific Control Properties on DNP3 Output Points in the ClearSCADA Guide to the DNP3 Driver.

For information on the Interlock fields, see Configure an Output Point or Pulse Action’s Interlock Properties.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack Binary Points

Configuring DNP3 SCADAPack Binary Points

The ClearSCADA DNP3 SCADAPack E-Series driver supports the following DNP3 SCADAPack Binary Point types:

  • Physical binary inputs using DNP3 SCADAPack Binary Input Points.
  • Physical binary outputs using DNP3 SCADAPack Binary Output Points.
  • Derived (User and System) binary points using either DNP3 SCADAPack Binary Input Points or DNP3 SCADAPack Binary Output Points.

You configure the properties of each binary point using the appropriate DNP3 SCADAPack Binary Point Form. Each Form has several tabs. This section covers configuration of properties on the Binary Point and Mapping tabs of both DNP3 SCADAPack Binary Point Forms, the Input tab of the DNP3 SCADAPack Binary Input Point Form, and the Control tab of the DNP3 SCADAPack Binary Output Point Form.

NOTE: Binary points are referred to as Digital points on many other drivers and throughout much of the ClearSCADA documentation.

For DNP3 SCADAPack Binary Input Points and DNP3 SCADAPack Binary Output Points, use the Binary Point tab to:

  • Configure General Properties
  • Configure the Binary Point States

Use the RTU Event field (see Configure General Properties) to specify how the outstation handles any state change events.

  • Configure Override Properties (see Configure Override Properties in the ClearSCADA Guide to the DNP3 Driver)
  • Optionally Associate one or More Profiles with the Point
  • Configure Trend Properties (see Define a Digital Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure Logged Data Properties (see Configure Logged Data Properties in the ClearSCADA Guide to the DNP3 Driver)
  • Specify the Point Data Class that Applies when Communicating with another DNP3 Master.

For DNP3 SCADAPack Binary Input Points and DNP3 SCADAPack Binary Output Points that are Physical Inputs or Physical Outputs, use the Mapping tab to:

  • Specify any Point Mapping.

For DNP3 SCADAPack Binary Input Points, use the Input tab to:

  • Configure any Physical Binary Input Point Properties
  • Configure Alarm Persistence.

For DNP3 SCADAPack Binary Output Points that can be controlled by ClearSCADA, use the Control tab to:

  • Configure the Control Actions (see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Promote Retrieval of Data Associated with Controls (see Specify which Outstations are Integrity Polled after a Successful Control in the ClearSCADA Guide to the DNP3 Driver)
  • Configure Binary Output Point DNP3 and SCADAPack Control Properties.

NOTE: For each DNP3 SCADAPack output point that ClearSCADA is to control exclusively, or for which point control alters between ClearSCADA and ISaGRAF, ensure that the point’s Control aggregate is enabled (see Specify Whether an Output Point is Controlled by ClearSCADA in the ClearSCADA Guide to the DNP3 Driver).
For each DNP3 SCADAPack output point that is controlled exclusively by another application, rather than ClearSCADA, you need to disable that point’s Control aggregate. For such points, fields on the Control tab are unavailable for use and you can ignore the above references.

The properties on other tabs are common to points on many advanced drivers—for information, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

If the outstations on your system are to sample binary point data for data trends, you need to configure the required Trend item(s) in the database and associate those items with the relevant binary points (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality).


DNP3 SCADAPack Driver Guide - Configure General Properties (Configuring DNP3 SCADAPack Binary Points)

Configure General Properties

Use the fields at the top of the Binary Point tab to define the general properties of a DNP3 SCADAPack binary point. For further information on most of these properties, see Configure Common Properties of DNP3 SCADAPack Points in this guide, and see Configure General Properties in the ClearSCADA Guide to the DNP3 Driver. Properties that are specific to DNP3 SCADAPack Binary points are explained below:

  • RTU Event—Applies only if the point’s Point Data Class is set to Class 1 Event, Class 2 Event or Class 3 Event (see Configure Common Properties of DNP3 SCADAPack Points).

Use the RTU Event combo box to specify whether the outstation just stores the event, or immediately generates an unsolicited message whenever the point changes state (see Specify Whether a Class n Event Triggers an Unsolicited Message).


DNP3 SCADAPack Driver Guide - Binary Point States (Configuring DNP3 SCADAPack Binary Points)

Binary Point States

Use the fields within the States section of the Binary Point tab to define state-related information for the point, such as the handling of state-related alarms.

The Number of Bits, defined toward the top of the Binary Point tab, determines the number of state fields that are available for use (see Define the Number of Bits for a Digital Point in the ClearSCADA Guide to Core Point Configuration).

With a binary point on a SCADAPack E-Series outstation, you configure one of the point’s states to represent that point’s ‘Alarm Active’ state in the outstation.

You can configure any number of point states to raise an alarm in ClearSCADA. You do this by setting the state’s Severity to trigger an Alarm of the appropriate priority (see Procedure for Configuring a Digital Point’s States in the ClearSCADA Guide to Core Point Configuration). Should more than one binary point state be configured to raise an Alarm in ClearSCADA:

  • If State 1 is configured to raise an alarm at the outstation and in ClearSCADA, then State 1 is deemed to represent the point’s ‘Alarm Active’ state. (This is regardless of the number of other point states that are configured to raise an alarm is ClearSCADA.)
  • If State 1 is not configured to raise an alarm at the outstation and in ClearSCADA, State 0 is deemed to be the ‘Alarm Active’ state. (Again, with a multi-bit point, this is regardless of the number of other point states (other than State 1) that are configured to raise an alarm in ClearSCADA.)

With a DNP3 SCADAPack Binary Input Point, you can configure Persistence time delays for the outstation to apply before generating an event due to the binary point changing state into or out of the ‘Alarm Active’ state (see Configure Alarm Persistence).

For further information on configuring binary point states, see Define the Point States for a Digital Point in the ClearSCADA Guide to Core Point Configuration.


DNP3 SCADAPack Driver Guide - Optionally Associate one or More Profiles with the Point (Configuring DNP3 SCADAPack Binary Points)

Optionally Associate one or More Profiles with the Point

This section applies to DNP3 SCADAPack Binary points that have a Point Type other than ‘Physical Input’. (With ‘Physical Input’ points, the fields in the Profiles section are ‘grayed out’ and unavailable for use.)

Use the fields within the Profiles section of the Binary Point tab to specify whether any Profiles are used to control the point’s current value, depending on the time of day or week.

Depending on the outstation’s Profile Type, DNP3 SCADAPack binary points can use either:

  • A stepped Standard Unsigned Long Time Profile, which you optionally specify in the Current Value field within the Profiles section of the tab.

You only need specify a Profile in the Current Value field if the point’s value is to change according to that Profile. Leave the field blank if the point’s value is not to change according to a Profile.

  • Daily DNP3 SCADAPack Binary Profiles, which you optionally specify in the Sunday to Saturday fields.

Leave the fields blank if the point is not Profile-controlled, or specify a Profile per day if the point is Profile-controlled.

Fields that do not apply to the specified Profile Type are ‘grayed out’ and unavailable for use.

For more information, see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value.

Remember that in order to associate Profiles successfully with a DNP3 SCADAPack point, you have to take into account various Limitations and Restrictions.


DNP3 SCADAPack Driver Guide - Configure any Physical Binary Input Point Properties (Configuring DNP3 SCADAPack Binary Points)

Configure any Physical Binary Input Point Properties

Use the fields located at the top of the Input tab on the DNP3 SCADAPack Binary Input Point Form to specify how the SCADAPack E-Series outstation processes the binary point when it has a Point Type of Physical Input (see Configure Common Properties of DNP3 SCADAPack Points).

  • Invert Point State—If you select this check box, the outstation inverts the raw state of the physical input. The inversion is performed before any other processing such as Persistence into/out of Alarm.
  • De-bounce Time—Use to specify the time that a raw physical input has to remain in the same state before the outstation considers the point as being in that state.

You typically set the De-bounce Time to a few milliseconds and use it to filter out ‘chatter’ from physical switches.

Enter the time in the OPC Time Format.


DNP3 SCADAPack Driver Guide - Configure Alarm Persistence (Configuring DNP3 SCADAPack Binary Points)

Configure Alarm Persistence

Use the fields located at the bottom of the Input tab on the DNP3 SCADAPack Binary Input Point Form to specify the time delays that the SCADAPack E-Series outstation applies before generating an event due to a binary point changing state.

The Persistence into/out of Alarm settings are only relevant if the point has a Point Data Class of Class n Event (see Configure Common Properties of DNP3 SCADAPack Points).

The ‘Alarm Active’ state to which the persistence settings apply is determined by which of point States 1 and 0 is assigned a Severity other than ‘None’ (see Binary Point States).

  • Persistence into Alarm—Use to specify how long the binary point has to remain in the ‘Alarm Active’ state before the outstation will generate and store an event for the state change.

Enter the time in the OPC Time Format.

  • Persistence out of Alarm—Use to specify how long the binary point has to remain in the ‘Alarm Inactive’ state before the outstation will generate and store an event for the state change.

Enter the time in the OPC Time Format.

NOTE: If a DNP Class 0 Poll or DNP3 Level 3 Scan is performed during the Persistence into/out of Alarm period, ClearSCADA will log the changed state. The Persistence into/out of Alarm settings determine whether the outstation will generate a logged event. Use De-Bounce Time (see Configure any Physical Binary Input Point Properties) if you do not want the point state logged under such circumstances.


DNP3 SCADAPack Driver Guide - Configure Binary Output Point DNP3 and SCADAPack Control Properties (Configuring DNP3 SCADAPack Binary Points)

Configure Binary Output Point DNP3 and SCADAPack Control Properties

NOTE: This section does not apply to DNP3 SCADAPack output points that are controlled exclusively by another application, rather than ClearSCADA. (For further information, see Specify Whether an Output Point is Controlled by ClearSCADA in the ClearSCADA Guide to the DNP3 Driver.)

For output points that can be controlled by ClearSCADA, use the fields at the bottom of the Control tab to define the type of control and whether to restore the point value in the event of power loss:

For information on the first three fields, see Configure the DNP3-Specific Control Properties on DNP3 Output Points in the ClearSCADA Guide to the DNP3 Driver.

For information on the Interlock fields, see Configure an Output Point or Pulse Action’s Interlock Properties.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack Counter Points

Configuring DNP3 SCADAPack Counter Points

The ClearSCADA DNP3 SCADAPack E-Series driver provides a DNP3 SCADAPack Counter Point that enables you to configure physical counters in the SCADAPack E-Series outstation. Physical counters are used to count pulses on the physical binary inputs of the outstation.

NOTE: By default, physical counters are positive edge triggered (that is, they count off-to-on transitions). If you want to count on-to-off transitions, create a DNP3 SCADAPack Binary Input Point for the physical binary input and set its Invert Point State property (see Configure any Physical Binary Input Point Properties). You do not need to create a DNP3 SCADAPack Binary Input Point if you only need to use the default configuration of the physical binary input.

You configure the properties of each counter point using the DNP3 SCADAPack Counter Point Form. The Form has several tabs. This section covers configuration of properties on the Counter Point and Mapping tabs of the Form.

Use the Counter Point tab to:

  • Configure General Properties
  • Configure Alarm Limits
  • Optionally Associate one or More Profiles with the Point
  • Configure Initialization Properties (see Configure the Initialization Properties of a DNP3 Counter Point in the ClearSCADA Guide to the DNP3 Driver)
  • Configure Override Properties (see Configure Override Properties in the ClearSCADA Guide to the DNP3 Driver)
  • Configure Significant Change Properties
  • Configure the No Change Properties (see Detect Whether a Point Value has Stopped Changing in the ClearSCADA Guide to Core Point Configuration)
  • Configure Trend Properties (see Define a Counter-Type Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure Formatting Properties (see Define the Appearance of a Counter-Type Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Configure Logged Data Properties (see Configure Logged Data Properties in the ClearSCADA Guide to the DNP3 Driver)
  • Specify the Point Data Class that Applies when Communicating with another DNP3 Master.

Use the Mapping tab to:

  • Specify any Point Mapping.

The properties on other tabs are common to points on many advanced drivers—for information, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

If the outstations on your system are to sample counter point data for data trends, you need to configure the required Trend item(s) in the database and associate those items with the relevant counter points (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality).


DNP3 SCADAPack Driver Guide - Configure General Properties (Configuring DNP3 SCADAPack Counter Points)

Configure General Properties

Use the fields at the top of the Counter Point tab to define the general properties for the counter point. Many of these fields are common to most DNP3 SCADAPack points—see Configure Common Properties of DNP3 SCADAPack Points in this guide, and see Configure General Point Properties in the ClearSCADA Guide to the DNP3 Driver. Fields that are specific to DNP3 SCADAPack Counter Points are explained below.

  • Reset to Zero—Select this check box if the counter value is to be reset to zero upon outstation start-up or a cold reset.

Ensure that the check box is clear if the counter is to retain its last known value upon outstation start-up or a cold reset.

  • Multiplier—Use this field to define the scaling factor that ClearSCADA applies to the counter’s value. Values reported by the outstation for the counter are multiplied by this value for use in ClearSCADA.

Example:

A SCADAPack E-Series outstation generates one count for every 0.4 liters of water that is pumped through a pipe.

A multiplier of 0.4 is used to show how many liters have been pumped.


DNP3 SCADAPack Driver Guide - Configure Alarm Limits (Configuring DNP3 SCADAPack Counter Points)

Configure Alarm Limits

Use the fields within the Alarm Limits section of the Counter Point tab to set the High limit value for the point and specify whether an alarm or event is generated if the value of the counter rises to, or exceeds, the limit.

  • High Limit—Use to specify the maximum expected value of the counter, and whether ClearSCADA is to generate an alarm or event if the counter’s value rises to, or exceeds, this value.

Use the RTU Event field to specify whether the outstation is to generate an event if the point exceeds this limit and how the outstation handles that event (see Specify Whether a Class n Event Triggers an Unsolicited Message). (The RTU Event field is ‘grayed out’ and unavailable for use if the point’s Point Data Class is set to Local or Class 0 Static Only.)

For further information on configuring the High Limit, see Configure the Limits for a Counter-Type Point in the ClearSCADA Guide to Core Point Configuration.

NOTE: If the High limit is Profile-controlled, the ‘fixed’ High Limit within the Alarm Limits section is unused. As such, this High Limit field will be ‘grayed out’. You still use the other fields within the Alarm Limits section to configure other properties associated with this limit. For more information, see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value.

  • Normal—Use to specify whether ClearSCADA is to generate an event whenever the counter’s value is within its normal operating range (any value below the High Limit value). For further information, see Configure the Limits for a Counter-Type Point in the ClearSCADA Guide to Core Point Configuration.
  • Limit Exceeded Reference—Use to specify the DNP3 SCADAPack Binary Input Point that the outstation will turn on whenever the counter’s value rises to, or exceeds, the High Limit.

The point has to be configured as a DNP3 SCADAPack Binary Input Point in the ClearSCADA database, and be associated with the same DNP3 SCADAPack E-Series Outstation as the counter point. The DNP3 SCADAPack Binary Input Point has to have a Point Type of Derived (see Configure Common Properties of DNP3 SCADAPack Points).

NOTE: A DNP3 SCADAPack Binary Input Point that is specified in this field cannot be linked to any other Rising Point, Falling Point, or No Change Point (see Specify Whether the SCADAPack Outstation is to Detect if an Analog Point has Stopped Changing).

  • Tune Limits—Use to specify whether the point’s High alarm limit can be tuned. For further information, see Define Whether a Counter-Type Point’s Limits can be Tuned in the ClearSCADA Guide to Core Point Configuration.

If this option is enabled, operators can tune the ‘standard’ High alarm limit using the Tune Alarm Limits pick action, providing that the limit is not profile-controlled (see Optionally Associate one or More Profiles with the Point). Be aware that the action of tuning a point’s limits triggers ClearSCADA to download that point’s Alarm Limits to the outstation. (Should such a download be unsuccessful, a Tune Limits Alarm is generated.)

NOTE: If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed below the Tune Limits check box. For information on this property, see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events in the ClearSCADA Guide to Core Point Configuration.


DNP3 SCADAPack Driver Guide - Optionally Associate one or More Profiles with the Point (Configuring DNP3 SCADAPack Counter Points)

Optionally Associate one or More Profiles with the Point

Use the fields within the Profiles section of the Counter Point tab to specify whether any Profiles are used to control the point’s High limit and/or current value.

Depending on the outstation’s Profile Type, DNP3 SCADAPack counter points can use either:

  • Stepped Standard Double Time Profiles, which you specify in the Current Value and/or High fields within the Profiles section of the tab.

You only need specify a Profile for the High limit and/or Current Value if they are Profile-controlled. Leave the field blank for either limit/value that is not Profile-controlled. With a High limit that is not Profile-controlled, the fixed High limit value defined within the Alarm Limits section of the Point Form applies (see Configure Alarm Limits)).

  • Daily DNP3 SCADAPack Counter Profiles, which you specify in the Sunday to Saturday fields.

Leave the fields blank if a point is not Profile-controlled, or specify a Profile per day if the point is Profile-controlled.

(With either type of Profile, the Profile’s values are scaled from engineering to raw when downloaded to the SCADAPack E-Series outstation.)

Fields that do not apply to the specified Profile Type are ‘grayed out’ and unavailable for use.

With either type of Profile, use the Historic check box to specify whether ClearSCADA is to store the High limit profile values historically.

For more information, see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value.

Remember that in order to associate Profiles successfully with a DNP3 SCADAPack point, you have to take into account various Limitations and Restrictions.


DNP3 SCADAPack Driver Guide - Configure Significant Change Properties (Configuring DNP3 SCADAPack Counter Points)

Configure Significant Change Properties

Use the fields within the Significant Change section of the Counter Point tab to define by how much a counter’s engineering value has to change in order for the SCADAPack E-Series outstation to generate an event for the counter.

Use Significant Change to help prevent excessive database updates, by determining when a significant change in point value is included in the ClearSCADA database, and when an insignificant change in value can be discarded (the database retains the previously recorded value).

  • Type—Use this combo box to specify the type of significant change. Choose from:
  • None—The server only updates the point value in the ClearSCADA database when one or more of the following occurs:
  • The point changes state
  • On start-up of a call to the outstation on which the counter resides
  • A user requests a Refresh of a display on which the point is included
  • On system or driver start-up.
  • Absolute—In addition to the reasons listed in ‘None’ above, the point value is updated in the ClearSCADA database if it changes by a defined amount.

Use the Deadband field to define the amount by which the value has to change.

  • Deadband—Enter the amount by which the point’s value has to change before the outstation generates an event for the point.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack Pulse Actions

Configuring DNP3 SCADAPack Pulse Actions

The ClearSCADA DNP3 SCADAPack E-Series driver supports the following DNP3 SCADAPack Pulse Actions:

  • DNP3 SCADAPack Pulse Action (NULL)—Sends a DNP3 Pulse Action (NULL) to a DNP3 SCADAPack Binary Output or DNP3 SCADAPack Binary User Point
  • DNP3 SCADAPack Pulse Action (Trip-Close)—Sends a DNP3 Pulse Action (Trip-Close) to a DNP3 SCADAPack Binary Output or DNP3 SCADAPack Binary User Point.

You configure the properties of each pulse action using the appropriate DNP3 SCADAPack Pulse Action Form. Each Form has several tabs. This section covers configuration of properties on the Pulse Action and Mapping tabs of both Forms, the NULL tab of the DNP3 SCADAPack Pulse Action (NULL) Form, and the Trip/Close tab of the DNP3 SCADAPack Pulse Action (Trip-Close) Form.

For both DNP3 SCADAPack Pulse Action (NULL), and DNP3 SCADAPack Pulse Action (Trip-Close) points, use the Pulse Action tab to:

  • Configure General Properties
  • Specify how the SCADAPack Outstation Handles any Pulse Action Events
  • Configure Pulse Properties
  • Optionally Associate one or More Profiles with the Pulse Action
  • Promote Retrieval of Data Associated with Pulse Controls (see Specify which Outstations are Integrity Polled after a Successful Control in the ClearSCADA Guide to the DNP3 Driver)
  • Specify the Point Data Class that Applies when Communicating with another DNP3 Master.

Use the Mapping tab(s) to:

  • Specify any Point Mapping.

For DNP3 SCADAPack Pulse Action (NULL) points, use the NULL tab to:

  • Configure the NULL Pulse Action Properties.

For DNP3 SCADAPack Pulse Action (Trip-Close) points, use the Trip/Close tab to:

  • Configure the Trip and Close Pulse Action Properties.

The properties on other tabs are common to points and pulse actions on many advanced drivers—for information, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.


DNP3 SCADAPack Driver Guide - Configure General Properties (Configuring DNP3 SCADAPack Pulse Actions)

Configure General Properties

Use the fields at the top of the Pulse Action tab to define general properties of a DNP3 SCADAPack pulse action.

For further information on these properties, see Configure Common Properties of DNP3 SCADAPack Points in this guide, and see Configure General Point Properties in the ClearSCADA Guide to the DNP3 Driver.

NOTE: For a Pulse (Trip-Close), you need to define two Point Numbers—one for each action. You define these on the Trip-Close tab (see Trip and Close Pulse Action Properties).


DNP3 SCADAPack Driver Guide - Specify how the SCADAPack Outstation Handles any Pulse Action Events (Configuring DNP3 SCADAPack Pulse Actions)

Specify how the SCADAPack Outstation Handles any Pulse Action Events

The RTU Event property applies to DNP3 SCADAPack Pulse Actions that have a Point Type other than Physical Output, and a Point Data Class of Class 1 Event, Class 2 Event, or Class 3 Event (see Configure Common Properties of DNP3 SCADAPack Points).

  • RTU Event—Use this combo box to specify whether the SCADAPack E-Series outstation just stores each Pulse Action event, or whether it immediately generates an unsolicited message (see Specify Whether a Class n Event Triggers an Unsolicited Message).


DNP3 SCADAPack Driver Guide - Configure Pulse Properties (Configuring DNP3 SCADAPack Pulse Actions)

Configure Pulse Properties

Use the fields at the top of the Pulse Action tab to define the general properties of DNP3 SCADAPack Pulse Action (NULL) or DNP3 SCADAPack Pulse Action (Trip-Close) points.

The first three fields are common to Pulse Actions on the DNP3 driver—for information, see Configure Pulse Properties in the ClearSCADA Guide to the DNP3 Driver.

For information on the Interlock fields, see Configure an Output Point or Pulse Action’s Interlock Properties.

Fields that are specific to DNP3 SCADAPack Pulse Actions are summarized below.

  • Pulse Duration—Use to specify the duration of any pulses that are initiated by an ISaGRAF application.

Either leave at the default of 0 if ISaGRAF is not to initiate controls on this Pulse Action, or specify the default duration of any ISaGRAF-initiated pulse controls. Any ISaGRAF-initiated control will comprise a single pulse that lasts for this Pulse Duration (the Pulse Action tab’s Pulse Count field only applies to ClearSCADA-initiated pulse controls). For more information, see the SCADAPack E-Series ISaGRAF Function Block User and Reference Manual.

Enter the required duration in the OPC Time Format.

Use the fields on the NULL or Trip/Close tab to specify the pulse on and off times for controls that are initiated by ClearSCADA (see NULL Pulse Action Properties, or see Trip and Close Pulse Action Properties). Use the Pulse Action tab’s Pulse Count field to specify the number of times that the outstation executes these on-off pulse periods (see Configure Pulse Properties in the ClearSCADA Guide to the DNP3 Driver).

  • Confirm—Use this combo box to define whether a confirmation dialog box is displayed whenever an operator attempts to send a pulse control (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).


DNP3 SCADAPack Driver Guide - Optionally Associate one or More Profiles with the Pulse Action (Configuring DNP3 SCADAPack Pulse Actions)

Optionally Associate one or More Profiles with the Pulse Action

Use the fields within the Profiles section of the Pulse Action tab to specify whether any Profiles are used to trigger the pulse’s action(s), depending on the time of day or week.

Depending on the outstation’s Profile Type, DNP3 SCADAPack pulse actions can use either:

  • A stepped Standard Unsigned Long Time Profile, which you can optionally specify in the Current Value field within the Profiles section of the tab.
  • Daily DNP3 SCADAPack Binary Profiles, which you can optionally specify in the Sunday to Saturday fields.

Leave the fields blank if the pulse action is not Profile-controlled, or specify a Profile per day if the pulse action is Profile-controlled.

Fields that do not apply to the specified Profile Type are ‘grayed out’ and unavailable for use.

For more information, see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value.

Remember that in order to associate Profiles successfully with a DNP3 SCADAPack pulse action, you have to take into account Various Limitations and Restrictions.


DNP3 SCADAPack Driver Guide - NULL Pulse Action Properties (Configuring DNP3 SCADAPack Pulse Actions)

NULL Pulse Action Properties

Use the fields within the Action section of the NULL tab to define the configuration of the NULL pulse action.

For further information, see Configure a NULL Pulse Action in the ClearSCADA Guide to the DNP3 Driver.


DNP3 SCADAPack Driver Guide - Trip and Close Pulse Action Properties (Configuring DNP3 SCADAPack Pulse Actions)

Trip and Close Pulse Action Properties

Use the fields within the Action section of the Trip/Close tab to define the configuration of the Trip and Close pulse actions.

The DNP3 SCADAPack Pulse Action (Trip-Close) point is effectively two independent SCADAPack Pulse Action (Trip-Close) points that are controlled by a single ClearSCADA database point. For example, if you set the Pulse Count (see Configure Pulse Properties) greater than 1, you can send a control to the Close action while the Trip action is still executing. As with the DNP3 Pulse Action (Trip-Close) point, you cannot issue a Trip, for example, while the previous Trip action is still executing.

For further information, see Configure Trip and Close Pulse Actions in the ClearSCADA Guide to the DNP3 Driver.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality

Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality

SCADAPack E-Series outstations and 386 eNET outstations are capable of periodically sampling counter, analog input, binary input, derived analog, and derived binary point data. If the SCADAPack E-Series outstations on your system are to sample data, you can configure the settings for that Trend Sampling in ClearSCADA and then download that configuration to the outstation as part of the Download Configuration process. The outstation will then sample the data at the specified rate(s).

ClearSCADA can retrieve the data from each outstation automatically at the Trend Retrieval rate specified on the Outstation Form (see Configure the Trend Retrieval Properties). Alternatively, the Retrieve All Trends pick action can be used to retrieve the stored sampled data from an individual outstation.

The DNP3 SCADAPack E-Series driver supports these Trend items:

  • DNP3 SCADAPack E-Series Trend Analog—To define the rate at which a SCADAPack E-Series or 386 eNET outstation samples the data from an individual analog point. You can only associate a DNP3 SCADAPack E-Series Trend Analog item with an analog point that has a Physical Input or Derived Point Type.
  • DNP3 SCADAPack E-Series Trend Binary—To define the rate at which a SCADAPack E-Series or 386 eNET outstation samples the current data from an individual binary point. You can only associate a DNP3 SCADAPack E-Series Trend Binary item with a binary point that has a Physical Input or Derived Point Type.
  • DNP3 SCADAPack E-Series Trend Counter—To define the rate at which a SCADAPack E-Series or 386 eNET outstation samples the data from an individual counter point.

In the ClearSCADA database, you need to configure one Trend item for each different type of data sampling task that the outstation is to perform on an individual point’s data. Use the fields on each Trend’s configuration Form to configure the Trend’s properties. The Form has several tabs.

Use the Trend tab to Configure the Basic Trend Properties.

Use the Type tab to:

  • Define the Trend Data Sample Type
  • Specify the Sample Rate and Sample Criteria.

Use the Historic tab to specify:

  • Whether any compression is applied to the sampled point data before it is stored historically in the ClearSCADA database
  • The time period shown on any Historic Trends and Lists.

Historic storage of sampled point data is enabled on each Trend item by default. The properties on each Trend’s Historic tab are identical to those on the Historic tab of any Point Form (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

The fields on other tabs are common to many database items (see Tabs that are Common to Many Configuration Forms in the ClearSCADA Guide to Advanced Drivers).

For an example that demonstrates how to configure Trend sampling requirements on a ClearSCADA system, see Example Configuration. For more information on the SCADAPack E-Series Trend Sampler, see the SCADAPack E-Series Trend Sampler Technical User and Reference Manual.


DNP3 SCADAPack Driver Guide - Configure the Basic Trend Properties (Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality)

Configure the Basic Trend Properties

Use the fields on the Trend tab of the relevant DNP3 SCADAPack E-Series Trend Form to configure these properties:

  • In Service—Use to specify whether the Trend is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a Trend item that is In Service, or enable a Trend item that is not In Service. Such actions are performed using the Disable Point and Enable Point pick actions, available from the point with which the Trend is associated.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever a user requests that the Trend is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Outstation—This field is ‘grayed out’ and for information only. The name of the outstation is inherited from the Parent Point with which Trend is associated.
  • Parent Point—Use the browse button next to this field to display a Reference browse window. From the window, select the name of the point for which this Trend item defines the data sample rate. The entries in the Reference browse window are restricted to DNP3 SCADAPack Counter points, and DNP3 SCADAPack Analog and Binary points that have a Point Type of either Physical Input, User (Derived), or System (Derived).

The outstation on which the Parent Point is located in inherited from the point’s configuration. The name appears in the Trend tab’s Outstation field once the configuration is saved.


DNP3 SCADAPack Driver Guide - Define the Trend Data Sample Type (Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality)

Define the Trend Data Sample Type

ATTENTION: The fields and options on the Type tab vary, depending on the point on which the outstation is to sample data. Ensure that you Configure the Basic Trend Properties on the Trend tab before configuring the properties on the Type tab.

Use the Trend Type field at the Type tab of the relevant DNP3 SCADAPack E-Series Trend Form to specify the type of point data that the outstation is to sample using this Trend’s settings.

Choose from:

  • Current Value—The outstation is to sample the point’s current value. Use the rest of the fields on the Type tab to Specify the Sample Rate and Sample Criteria. If required, an outstation can perform up to six separate sampling tasks on a point’s current value.
  • Statistical—Applies only if the Trend item’s Parent Point is an analog or counter point. Select this option if the outstation is to analyze the data that it samples, storing only those values that meet the statistical and data storage requirements. When this option is selected, a Type field is displayed. Use the Type field to specify the type of statistical analysis that is required. Use the rest of the fields on the Type tab to Specify the Sample Rate and Sample Criteria.

  • Type—Only displayed when the Trend Type is set to Statistical. The type of statistical analysis that the outstation can perform varies, depending on the type of point on which it is to sample data. Choose the required type of analysis from a combination of these options:
  • Average—Only available if the Trend item’s Parent Point is an analog point.

The outstation analyzes the point’s values over the sample period and stores the arithmetic mean of those values, providing that the value fulfills the other Trend criteria. (The arithmetic mean is the sum of the point’s values over the sample period, divided by the number of values.)

  • Maximum—Only available if the Trend item’s Parent Point is an analog point.

The outstation analyzes the point’s values over the sample period and stores the highest value that occurs within that period, providing that the value fulfills the other Trend criteria.

  • Minimum—Only available if the Trend item’s Parent Point is an analog point.

The outstation analyzes the point’s values over the sample period and stores the lowest value that occurs over that period, providing that the value fulfills the other Trend criteria.

  • Change—Available if the Trend item’s Parent Point is an analog or counter point.

The outstation calculates the difference between the point’s values at the start and end of the sample period and stores that difference in value, providing the rest of the Trend criteria is fulfilled.


DNP3 SCADAPack Driver Guide - Specify the Sample Rate and Sample Criteria (Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality)

Specify the Sample Rate and Sample Criteria

Ensure that you Define the Trend Data Sample Type before configuring the properties mentioned in this section.

When the Trend Type is set to Statistical, the outstation performs a single data sampling and analysis routine on the point’s data.

When the Trend Type is set to Current Value, the outstation can perform up to six separate sampling tasks on the point’s data. For the outstation to perform more than one sampling routine, select the Enabled check box for each additional sampling routine that is required.

For each sampling task that the outstation is to perform, use these fields to specify the sample rate and other sample criteria:

  • Sample Rate—Specify the frequency with which the outstation samples the point’s data. The minimum value you can specify is 1S (one second), although for Statistical sampling, such as Average or Minimum, a longer sample rate will provide a more meaningful trend. Specify a rate that is a full division of, for instance, a minute or hour, for the rate at which data is sampled to remain consistent.

Enter the rate in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required rate.

Providing that the point’s data fulfills the sample requirements specified by the properties below, and sampling is not disabled, the outstation records a single value each time the Sample Rate is exceeded.

  • Trigger Point—If sampling is only to occur under certain circumstances, you can use the Trigger Point field to specify the binary point that is to trigger the data sampling. Use the browse button to display a Reference browse window and select the required DNP3 SCADAPack Binary Input point from the window. The Trigger Point has to reside on the same outstation as the Trend item’s Parent Point. Additionally, the Trigger Point’s states have to be configured such that sampling only occurs when the Trigger Point is in State 1. If required, the same DNP3 SCADAPack Binary Input point can be used to control data sampling on multiple points.

For an example that demonstrates how a binary input Trigger Point might be used to control data sampling, see Example Configuration.

  • Deviation—Only applicable when the Trend’s Parent Point is an analog or counter point. Optionally specify a Deviation greater than zero if the outstation is only to store the sampled value if it differs from the previously stored sampled value by at least the Deviation amount.

If the point being sampled is an analog point, use the Deviation field to specify the percentage of the point’s range (raw Full Scale to Zero Scale) by which the value has to differ for it to be recorded. For instance, specify a Deviation greater than zero if an outstation is to sample an analog point’s Change in value and that outstation is only to store the point’s value at the Sample Rate if that value actually differs from the last stored sampled value.

If the point being sampled is a counter point, use the Deviation field to specify the number of raw counts that has to have occurred in order for the outstation to record the value.

For an example that demonstrates how Deviation might be used when sampling data, Example Configuration.

When an outstation samples point data according to the above criteria, it stores the values that fulfill the sample criteria locally at the outstation. In order to process those values in ClearSCADA, the server retrieves the stored sampled data from the outstation at the Trend Retrieval rate specified on the Outstation Form (see Configure the Trend Retrieval Properties). Alternatively, the Retrieve All Trends pick action can be used to retrieve the stored sampled data from an individual outstation.


DNP3 SCADAPack Driver Guide - Example Configuration (Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality)

Example Configuration

This example demonstrates how ClearSCADA might be used to configure the settings that enable analog data to be sampled.

Example:

A SCADAPack E-Series outstation is to use multiple Trend steams to sample its analog data for current, average, minimum, and maximum values.

In the ClearSCADA database, a separate DNP3 SCADAPack E-Series Trend Analog database item is configured for each Trend stream on each analog point.

The DNP3 SCADAPack Analog Input Point for which each Trend item is to sample data is specified on the Trend tab of each Trend item’s configuration Form. The configuration is saved. The Outstation with which each Trend item is associated is inherited from the Trend item’s Parent Point—the point for which the outstation is to sample data.

The point on which the outstation is to sample data, using the settings specified on this Trend item’s configuration Form.

The required Trend Type is specified on the Type tab of each Trend item’s configuration Form:

For a Trend item that is to sample Current Values, a single Trend Type field is used to specify the type of data that is to be sampled.
For a Trend item that is to sample Statistical data, an additional Type field is used to specify the type of statistical data (Average, Maximum, Minimum, or Change).

The rest of the fields on the Type tab are used to specify the required Sample Rate and Deviation. (In this particular example, no Trigger Points are assigned to the Average, Maximum, or Minimum Trend streams.)

In the case of the Current Value Trend item, three Sample Rates are specified. The second and third rates only come into force when the respective Trigger Points are in State 1:

The Current Value Trend uses three Sample Rates. The 1H (one hourly) Sample Rate runs continuously (it has no Trigger Point)...
...whereas the 15M (15 minute) and 10M (10 minute) Sample Rates only run when the respective Trigger Point is in State 1.
The DNP3 SCADAPack Binary Input Point ‘Trigger Point R1’ triggers the outstation to sample point data at 15-minute intervals whenever the binary point is in State 1 ‘Sampling Data’.

The frequency with which ClearSCADA retrieves the sampled data is specified on the SCADAPack tab of the Outstation’s configuration Form:

The Trend item is put In Service, then the configuration is saved and downloaded to the outstation using the Download Configuration pick action.

The outstation samples the data of its analog points at the rates specified on the Trend Forms. So with Analog Input 5, for instance, the point’s current values are sampled at 1-hourly intervals. The outstation only stores the newly sampled data if the new value differs from the last stored value by at least 2% of the analog point’s range (as the Sample Rate’s Deviation = 2). (If the point being sampled was a counter point, rather than an analog point, a Deviation of 2 would indicate that a minimum of 2 raw counts was needed.)

Whenever the Trigger Point ‘Trigger Point R1’ is in State 1, the outstation also samples the analog point’s current values at 15-minute intervals. This sampling stops whenever ‘Trigger Point R1’ reverts back to State 0.

Similarly, whenever the Trigger Point ‘Trigger Point R2’ is in State 1, the outstation samples the analog point’s current values at 10-minute intervals. Again, this sampling stops whenever ‘Trigger Point R2’ reverts back to State 0.

ClearSCADA retrieves the stored sampled values automatically at 6-hourly intervals, at 00:05:00.000, 06:05:00.000, 12:05:00.000 and 18:05:00.000 each day.

(If further stored sampled data is required between these times, the Retrieve All Trends pick action is used to retrieve the data from the outstation.)

Further Information

Configure the Basic Trend Properties.

Define the Trend Data Sample Type.

Specify the Sample Rate and Sample Criteria.

Configuring DNP3 SCADAPack Binary Points.

Configure the Binary Point States: see Define the Point States for a Digital Point in the ClearSCADA Guide to Core Point Configuration.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack 32-bit Point Modbus Maps

Configuring DNP3 SCADAPack 32-bit Point Modbus Maps

This section only applies if:

  • A SCADAPack E-Series outstation is a Modbus Slave

(To communicate as a Modbus Slave device, the Function of at least one of the SCADAPack E-Series outstation’s ports has to be defined as Modbus Slave (see Configure the Properties of the Individual Ports).)

and:

  • The Modbus master is to read or write 32-bit integer or floating point (real) data from the SCADAPack E-Series outstation.

Modbus devices use registers to store point data. Each Modbus register comprises 16 bits (1 Word). To provide consistent mapping of 32-bit analog point values to Modbus registers, you need to map such point data to a DNP3 SCADAPack 32-bit Point Modbus Map in the ClearSCADA database.

Mapping the data using such a Point Map provides a consistent correlation between each analog point’s low Word and high Word and the Modbus register that holds the data.

Each DNP3 SCADAPack E-Series outstation that is a Modbus Slave can map data to one DNP3 SCADAPack 32-bit Point Modbus Map (see Configure Modbus Properties).

You can configure multiple DNP3 SCADAPack 32-bit Point Modbus Maps in ClearSCADA.

This section explains how to:

  • Specify the Map Size
  • Add and Edit the Entries in a 32-bit Point Modbus Map.

For an example that demonstrates how you might configure a 32-bit Point Modbus Map to correspond to data in a Modbus master, see Example Configuration.

For further information on 32-bit Point Modbus Maps, see the SCADAPack E-Series Modbus Communication Interfaces manual.


DNP3 SCADAPack Driver Guide - Specify the Map Size (Configuring DNP3 SCADAPack 32-bit Point Modbus Maps)

Specify the Map Size

Each populated row in a DNP3 SCADAPack 32-Bit Point Modbus Map represents a block of Modbus registers. One row is required for each contiguous block of 32-bit point data that the Modbus master is to read or write from a SCADAPack E-Series outstation. By default each new DNP3 SCADAPack 32-bit Point Modbus Map has one row.

To specify a different map size:

  1. Display the Map for which you want to specify a new size.
  2. Select the Edit menu from the ViewX menu bar.
    A context sensitive menu is displayed.
  3. Select the Modbus Map Size option.
    The Change SCADAPack 32-but Modbus Map Size window is displayed.
  4. Enter the required map size in the New field. (The range is 1 to 254 inclusive.)
  5. Select the OK button to confirm the change.
    The window is closed and the corresponding number of rows appear on the Map.


DNP3 SCADAPack Driver Guide - Add and Edit the Entries in a 32-bit Point Modbus Map (Configuring DNP3 SCADAPack 32-bit Point Modbus Maps)

Add and Edit the Entries in a 32-bit Point Modbus Map

Each populated row in a DNP3 SCADAPack 32-Bit Point Modbus Map represents a block of Modbus data. You need to configure one row in the Map for each contiguous block of 32-bit point data that the Modbus master is to read or write from the Modbus Slave (ClearSCADA).

For each row that is required you need to specify these properties:

  • Index—By default, each new Map contains only one row. Use the Modbus Map Size option (accessed from the Edit menu) to specify the number of rows that the Map is to contain. You can specify up to 254 rows (see Specify the Map Size). ClearSCADA allocates the Index numbers automatically when you specify the Map size.
  • Point Number—Specify the DNP3 address of the first point that is to be mapped into the Modbus address space.
  • Quantity—Specify the number of points that are to be mapped into the Modbus address space. Each point will map to two Modbus registers.
  • Point Type—Use the combo box (displayed whenever you select the field) to specify whether the row is used to map Input or Output data.

Once you have configured a DNP3 SCADAPack 32-bit Point Modbus Map, you need to associate it with the relevant DNP3 SCADAPack E-Series outstation (see Configure Modbus Properties).

For an example that demonstrates how you might configure a 32-bit Point Modbus Map to correspond to data in a Modbus master, see Example Configuration.


DNP3 SCADAPack Driver Guide - Example Configuration (Configuring DNP3 SCADAPack 32-bit Point Modbus Maps)

Example Configuration

This example demonstrates how a DNP3 SCADAPack 32-bit Point Modbus Map might be used to map data to two blocks of 32-bit data: one comprising 4 analog output points and another comprising 3 analog input points. The rows correlate to registers in the Modbus slave, enabling the master to write or read the data in the SCADAPack E-Series outstation with which the Map is associated.

Example:

In the ClearSCADA database, a DNP3 SCADAPack 32-Bit Point Modbus Map is configured as follows:

The Map is associated with the relevant DNP3 SCADAPack E-Series outstation:

The Function of the Port that the Modbus master uses to communicate with the outstation is set to Modbus Slave:

The Modbus master that reads and writes to data in the outstation uses 5-digit Modbus addressing. Its Input Registers are in the range 30001 - 39999 and its Holding Registers (including analog outputs) are in the range 40001 - 49999.

With the above configuration, the first row in the Map correlates to the analog outputs in registers 41001 to 41008, and the second row in the Map correlates to the analog inputs in registers 31001 to 31006. Each 32-bit point comprises two Words and therefore two contiguous registers. So, for instance:

  • Analog output DNP3 address 1001 mapped in row 1 corresponds to Modbus registers 41001 and 41002
  • The second analog point in row 1, analog output DNP3 address 1002, corresponds to the analog output Modbus registers 41003 and 41004

and so on.

Further Information

Add and Edit the Entries in a 32-bit Point Modbus Map.

Associated a Map with a DNP3 SCADAPack E-Series outstation: see Configure Modbus Properties.

Assign an outstation port a specific function: see Configure the Properties of the Individual Ports.


DNP3 SCADAPack Driver Guide - Configuring ClearSCADA to Retrieve DNP3 SCADAPack Status Information

Configuring ClearSCADA to Retrieve DNP3 SCADAPack Status Information

SCADAPack E-Series outstations store internal status information at specific DNP3 point numbers in the outstation database. Depending on the type of SCADAPack E-Series outstation and its configuration, such information might include the status of:

  • The outstation and any ISaGRAF applications running on it
  • The outstation’s serial or Ethernet ports
  • Any SCADAPack ES Remote IO modules that are connected to the outstation.

For ClearSCADA to retrieve any of this internal status data, there is no need to specify the individual Status Points for which ClearSCADA is to retrieve the data—instead, you merely need to specify the type of status information you want ClearSCADA to retrieve and, if applicable, the port or address. (To retrieve any other status information from an E-Series outstation, you do need to configure individual DNP3 Status Points (see Configuring DNP3 Status Points in the ClearSCADA Guide to the DNP3 Driver).)

To retrieve any of the above internal SCADAPack E-Series status information, you need to configure one DNP3 SCADAPack Status Information item in the database for each type of status data you want ClearSCADA to retrieve from an outstation.

Configure the required properties on the DNP3 SCADAPack Status Information Form. The Form has several tabs.

Use the Parent tab to:

  • Specify the Outstation from which ClearSCADA is to Retrieve Status Information
  • Specify the Scan Group that Determines the Frequency with which the Status Information is Updated.

Use the Status Type tab to:

  • Specify the Type of Status Information that ClearSCADA is to Retrieve.

Once the configuration is saved and ClearSCADA has retrieved the specified status information, you can view that retrieved data via the DNP3 SCADAPack Status Information item’s Status display (see DNP3 SCADAPack Status Information Attributes).


DNP3 SCADAPack Driver Guide - Specify the Outstation from which ClearSCADA is to Retrieve Status Information (Configuring ClearSCADA to Retrieve DNP3 SCADAPack Status Information)

Specify the Outstation from which ClearSCADA is to Retrieve Status Information

Use the Outstation field on the Parent tab to specify the DNP3 SCADAPack E-Series outstation from which ClearSCADA is to retrieve status information:

Use the field’s browse button to display a Reference browse window. Select the required outstation entry from the window.


DNP3 SCADAPack Driver Guide - Specify the Scan Group that Determines the Frequency with which the Status Information is Updated (Configuring ClearSCADA to Retrieve DNP3 SCADAPack Status Information)

Specify the Scan Group that Determines the Frequency with which the Status Information is Updated

Use the Scan Group (Confidence Poll) combo box on the Parent tab to specify the Scan Group with which the Status Information is associated. The Scan Group determines the frequency with which the status information is retrieved. The Scan Group works in the same way as that for Status Points on the parent DNP3 Driver (see Specify the Scan Group that is Associated with the Status Data Retrieval in the ClearSCADA Guide to the DNP3 Driver).


DNP3 SCADAPack Driver Guide - Specify the Type of Status Information that ClearSCADA is to Retrieve (Configuring ClearSCADA to Retrieve DNP3 SCADAPack Status Information)

Specify the Type of Status Information that ClearSCADA is to Retrieve

Use the fields on the Status Type tab to specify the type of status information that ClearSCADA is to retrieve from the SCADAPack E-Series outstation:

  • Type—Use this combo box to specify the type of status information that ClearSCADA is to retrieve. Choose from:
  • System Overview—Select this option to retrieve general status information about the SCADAPack E-Series outstation and any ISaGRAF applications running on it.
  • Port Status—Select this option to retrieve status information about a particular serial or Ethernet port.
  • SCADAPack ES Remote I/O—This option only applies if the outstation specified in the Parent tab’s Outstation field is to main unit of a Main-SCADAPack ES Remote I/O configuration. (For more information on such configuration, see Configure SCADAPack ES Remote I/O Properties.) Select this option to retrieve status information about one of the outstation’s SCADAPack ES Remote IO modules.

For details about the status information that ClearSCADA retrieves for each of the above options, see DNP3 SCADAPack Status Information Attributes.

  • Port Index—Only displayed if the status information Type is set to Port Status. Use the combo box to specify the Serial or Ethernet port for which ClearSCADA is to retrieve status information.
  • Remote Address—Only displayed if the status information Type is set to SCADAPack ES Remote I/O. Use the spin box to specify the address of the SCADAPack ES Remote IO module for which ClearSCADA is to retrieve status information.


DNP3 SCADAPack Driver Guide - Configuring DNP3 SCADAPack Tables

Configuring DNP3 SCADAPack Tables

SCADAPack E-Series outstations have three internal tables that ClearSCADA is capable of configuring. By configuring these tables, you can use a SCADAPack E-Series outstation to:

  • Route DNP3 traffic (see Route DNP3 Frames Using a DNP Route Table)
  • Route IP traffic (see Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host)
  • Set the IP address of other devices using the BOOTP protocol (see Add and Configure the Entries in a BOOTP Table).

In order to configure these tables, you will need to:

  1. Add a DNP3 SCADAPack Table.
  2. Display the Table.
  3. Specify the Table Size.
  4. Add the required entries to the table—see as appropriate:
  • Add and Configure the Entries in a BOOTP Table
  • Add and Configure the Entries in a DNP Route Table
  • Add and Configure the Entries in an IP Route Table.

Further Information

Import entries into BOOTP, IP Route, and DNP Route Tables using the Automation Interface: see DNP3 SCADAPack E-Series Automation Interface Methods.

Route DNP3 Frames Using a DNP Route Table.

Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host.

Types of IP Route.


DNP3 SCADAPack Driver Guide - Add a DNP3 SCADAPack Table (Configuring DNP3 SCADAPack Tables)

Add a DNP3 SCADAPack Table

To add a DNP3 SCADAPack table to the ClearSCADA database:

  1. In the Database Bar, right-click on the System or Group for which you want to add a DNP3 SCADAPack table.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not on display, you can display it by selecting the View menu, followed by the Explorer Bar, then the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the DNP3 option.
    A further menu is displayed.
  4. Select one of the following options:
  • SCADAPack BOOTP Table—Creates a new BOOTP Table in the ClearSCADA database. This table enables you to configure a SCADAPack E-Series outstation’s BOOTP Server to provide IP addresses to ethernet devices using the BOOTP protocol.
  • SCADAPack DNP Route Table—Creates a new DNP3 Route Table in the ClearSCADA database. This table enables you to configure a SCADAPack E-Series outstation to route DNP3 frames.
  • SCADAPack IP Route Table—Creates a new IP Route Table in the ClearSCADA database. This table enables you to configure a SCADAPack E-Series outstation to route IP packets.

The table is added to the root of the System or the selected Group (depending on your selection in step 1). It is selected automatically, ready for you to enter its name.

  5. Enter a suitable name for the table.
  6. Press the Enter key or select another part of the ViewX interface to confirm the entry.

When you have added a DNP3 SCADAPack table, you can then optionally define a Help View for the table (see Specify a Help View in the ClearSCADA Guide to Core Configuration). If Exclusive Control is used on your system, you can specify whether to exclude the table from any exclusive control activity (see Specify Whether to Exclude a Group or Database Item from Exclusive Control in the ClearSCADA Guide to Core Configuration).

You can then Display the Table, Specify the Table Size and add the required entries to the table.

Further Information

Add and Configure the Entries in a BOOTP Table.

Route DNP3 Frames Using a DNP Route Table.

Add and Configure the Entries in a DNP Route Table.

Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host.

Add and Configure the Entries in an IP Route Table.


DNP3 SCADAPack Driver Guide - Display the Table (Configuring DNP3 SCADAPack Tables)

Display the Table

To display a BOOTP, IP Route, or DNP Route Table in Edit mode, so that you can alter its configuration, either:

  1. Double-click on the table in the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature enabled).

NOTE: If the Database Bar is not displayed, you can access it by selecting the View menu, then selecting the Explorer Bar option, and then selecting the Database option.

Or:

  1. Right-click on the BOOTP, IP Route, or DNP Route Table in the Database Bar.
    A context sensitive menu is displayed.
  2. Select the Edit option.

The table will be displayed as a series of rows and columns, as shown below.

While a table is displayed in Edit mode, you can:

  • Specify the Table Size.
  • Add the required entries to the table—see, as applicable:
  • Add and Configure the Entries in a BOOTP Table
  • Add and Configure the Entries in a DNP Route Table
  • Add and Configure the Entries in an IP Route Table.

Further Information

Route DNP3 Frames Using a DNP Route Table.

Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host.

Types of IP Route.


DNP3 SCADAPack Driver Guide - Specify the Table Size (Configuring DNP3 SCADAPack Tables)

Specify the Table Size

Each entry that you add to a DNP3 SCADAPack BOOTP, IP Route, or DNP Route Table requires one row of that table.

By default, a new BOOTP, IP Route, or DNP Route Table has a size of one row. However, you can manually increase or decrease the size of each table as required, up to the following limits:

  • The maximum size of a DNP Route Table is 100 rows.
  • The maximum size of an IP Route Table is 20 rows.
  • The maximum size of a BOOTP Table is 20 rows.

To specify a table size:

  1. Display the Table for which you want to specify a new size (see Display the Table).
  2. Select the <Table Type> Table Size option from the Edit menu.
    The Change <Table Type> Table Size window is displayed.
  3. Enter the new table size in the New field.
  4. Select the OK button to confirm the change.
    The Change Table Size window is closed, and the corresponding number of index entries appear in the table.

If you attempt to reduce the size of a table so that it is smaller than the number of entries that it contains, a confirmation dialog box is displayed. The message in the dialog box indicates that entries set above the new table limit will be lost if the table is resized.

Select the OK button to resize the table and delete those entries, or select the Cancel button to cancel the request.

Further Information

Add and Configure the Entries in a BOOTP Table.

Add and Configure the Entries in a DNP Route Table.

Add and Configure the Entries in an IP Route Table.


DNP3 SCADAPack Driver Guide - Add and Configure the Entries in a BOOTP Table (Configuring DNP3 SCADAPack Tables)

Add and Configure the Entries in a BOOTP Table

The SCADAPack BOOTP server allows a SCADAPack E-Series outstation to provide an IP address for up to 20 BOOTP/DHCP clients. Typically, the BOOTP server is used to assign IP addresses to devices such as PLCs.

ATTENTION: A DHCP client determines whether the IP addresses allocated by a BOOTP server are acceptable. Some DHCP clients may reject IP addresses allocated by a SCADAPack E-Series outstation’s BOOTP server.

The BOOTP Table allows you to specify Ethernet device hardware addresses and corresponding IP addresses for up to 20 devices.

To configure a SCADAPack E-Series outstation’s BOOTP Table in ClearSCADA:

  1. Display the Table.
  2. If the table has insufficient rows, Specify the Table Size.
  3. For each BOOTP/DHCP client, use a row of the table to specify that device’s:
  1. Hardware Address—Each hardware address comprises 6 octets in one of the following formats:
  • 00:1A:2B:3C:4D:5E
  • 00-1A-2B-3C-4D-5E
  • 001A2B3C4D5E.

NOTE: A device’s Hardware Address is also known as its MAC Address (Media Access Controller Address).

  2. IP Address—Specify each IP Address using the IPv4 format A.B.C.D

Example:

192.168.1.97

  4. Repeat step 3 for each device that you want to include in the table.
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).
  6. If you haven’t done so already, associate the BOOTP table with a DNP3 SCADAPack E-Series Outstation (see Specify IP Route and BOOTP Tables).

(To enable a DNP3 SCADAPack E-Series outstation’s BOOTP server, you need to select the BOOTP Server option on the Outstation Form’s SCADAPack TCP/IP tab (see Enable TCP/IP Services).)


DNP3 SCADAPack Driver Guide - Route DNP3 Frames Using a DNP Route Table (Configuring DNP3 SCADAPack Tables)

Route DNP3 Frames Using a DNP Route Table

Where a SCADAPack E-Series outstation is used to route DNP3 frames to different parts of a communications network, or the outstation needs to know the PSTN Number or IP Address of the SCADA Master (ClearSCADA) or peer DNP3 devices, you will need to create and configure a DNP Route Table.

When the outstation receives or generates a DNP3 frame, it applies the following rules until the frame is either processed, sent or discarded:

  1. If the frame’s destination address is the SCADAPack E-Series outstation’s DNP3 address, the frame is processed.
  2. If the frame’s destination address is a DNP3 broadcast address, the frame is processed.
  3. The DNP3 Route Table is searched, starting from the first entry and proceeding sequentially through the table until a Table End entry is found, for the first entry that matches the frame’s Source Port, Source Address, and Destination Address. Any off-line entries (Off Static, Off Dynamic, and Off Fixed) are skipped.
  4. If an on-line entry is found, the frame is sent via the corresponding Destination Port, using the corresponding Connection Number.

NOTE: The Source Port and Source Address fields are ignored for any DNP3 frames that are generated by the outstation. In such a situation, the outstation will use the first route entry that matches the Destination Address of the frame.

  5. If the DNP3 Route Table is empty, and the frame was not received on the Master Port, the frame is sent via the Master Port (see Configure the Properties of the Individual Ports).
  6. The frame is discarded.

Further Information

Add and Configure the Entries in a DNP Route Table.


DNP3 SCADAPack Driver Guide - Add and Configure the Entries in a DNP Route Table (Configuring DNP3 SCADAPack Tables)

Add and Configure the Entries in a DNP Route Table

To add entries to a DNP Route Table, you need to Display the Table. If the table has insufficient rows, you will need to Specify the Table Size.

When adding entries to a DNP Route Table, you should take into account that the SCADAPack E-Series outstation scans the table entries from top to bottom and stops at the first matching entry (see Route DNP3 Frames Using a DNP Route Table). As such, it is more efficient to add the most frequently used routes first, followed by less frequently used routes.

ClearSCADA automatically allocates a unique Index number to each entry in a DNP Route Table. For each entry in the table, you need to specify:

  • Source Port—The Port on which the outstation receives in-bound DNP3 frames. Use the combo box to select the relevant port. The selected port’s Function must be set to DNP3.
  • Source Start—Use in conjunction with the Source End property to specify the source address range to which this table entry refers. Specify the lower number of the range of addresses between 0 and 65535 (inclusive).
  • Source End—Use in conjunction with the Source Start property to specify the source address range to which this table entry refers. Specify the higher number of the range of addresses between 0 and 65535 (inclusive).
  • Destination Start—Use in conjunction with the Destination End property to specify the destination address range to which this table entry refers. Specify the lower number of the range of addresses between 0 and 65535 (inclusive).
  • Destination End—Use in conjunction with the Destination Start property to specify the destination address range to which this table entry refers. Specify the higher number of the range of addresses between 0 and 65535 (inclusive).
  • Destination Port—The port to which the outstation sends any DNP3 frames that match the Source and Destination properties specified for this table entry. Use the combo box to select the relevant port.

If the selected port is a serial port, the port’s Function must be set to DNP3 or PPP (see Configure the Properties of the Individual Ports).

If the selected port is an ethernet port, its Function must be set to TCP/IP + ES Remote I/O (see Configure General Ethernet Properties).

  • Connection Number—Where applicable, use to specify either:
  • A telephone number—The corresponding port’s Mode must be set to Hayes Modem or Hayes Pool (see Configure the Properties of the Individual Ports).
  • An X.25 address—The corresponding port’s Mode must be set to X.29 (see Configure the Properties of the Individual Ports).
  • An IP address and TCP/UDP Port—The corresponding port must be either:
  • A serial port with a Function of PPP/TCPIP (see Configure the Properties of the Individual Ports).

Or:

  • An ethernet port with a Function of TCP/IP + ES Remote I/O (see Configure General Ethernet Properties).

The address format for TCP is A.B.C.D:T

The address format for UDP is A.B.C.D:<port>U

Example:

10.1.10.1:20001U
(Specifying that DNP3 frames will be sent to the host address 10.1.10.1, port 20001, using a UDP connection.)

NOTE: If the TCP/UDP port is not specified, the outstation will use the Default DNP3 Port, specified within the DNP/IP Parameters section on the Outstation Form’s SCADAPack TCP/IP tab. If the transport type (T or U) is not specified, the outstation will use the Default DNP3 Transport specified within the DNP/IP Parameters section on the SCADAPack TCP/IP tab (see Configure DNP/IP Parameters).

Ensure that this field is left blank if other means of communication are used.

  • Status—Use to specify whether the route is enabled or disabled. For TCP/IP routes, also use the Status to specify whether the SCADAPack E-Series outstation automatically updates the Connection Number when it receives DNP3 frames matching the route entry.

Use the combo box to choose one of the following:

  • On Static—The route is enabled. If the route uses TCP/IP, the Connection Number will be updated each time the outstation receives DNP3 frames matching the route table entry.
  • Off Static—The route is disabled. If the outstation receives DNP3 frames matching this route entry, the frame will not be forwarded. The outstation will update the Connection Number. If a return route for the frame does not already exist in the route table, the outstation will create a dynamic return route (see the SCADAPack E-Series DNP3 Technical User and Reference Manual).
  • On Dynamic—The route is enabled. If the outstation receives DNP3 frames matching this route entry, it will forward the frames via an automatically generated route.
  • Off Dynamic—The route is disabled. If the outstation receives DNP3 frames matching this route entry, the frame will not be forwarded, as the automatically generated route has expired.
  • On Fixed—The route is enabled, and the Connection Number will not be updated each time the outstation receives DNP3 frames matching the route table entry.
  • Off Fixed—The route is disabled. If the outstation receives DNP3 frames matching this route entry, the frame will not be forwarded. The outstation will not update the Connection Number. If a return route for the frame does not already exist in the route table, the outstation will not create a dynamic return route (see the SCADAPack E-Series DNP3 Technical User and Reference Manual).
  • Security Level—Use to specify whether AGA12-2 security is used to encrypt the DNP3 frames and if so, any AGA12 processing that the outstation undertakes when routing the DNP3 frames.

Use the combo box to choose one of the following:

  • None—Communications are routed between standard DNP3 devices that do not use AGA12 security. The frames that are routed comprise cleartext DNP3.
  • AGA12 Node—The outstation routes secure AGA12-2 DNP3 frames from one part of the network to another. Most SCADAPack E-Series outstations operate as AGA12 Nodes on a AGA12-2 secured system.
  • AGA12 Gateway n—DNP3 frames are routed via a security gateway node. Messages are routed to a nominated gateway SCADA Cryptographic Module (SCM) address, rather than to a destination DNP address. An outstation that is configured as a gateway node encodes and decodes messages on behalf of other DNP3 devices. For example, the outstation might route messages between a cleartext DNP3 master and secured AGA12-2 DNP3 devices.

For more information on AGA12 security, see the SCADAPack E-Series Security Technical User and Reference Manual.

Use the DNP Route Table field on the DNP3 SCADAPack E-Series Outstation Form’s SCADAPack tab to associate the table with a particular outstation (see Configure the DNP Route Table and Modem Authentication Properties).


DNP3 SCADAPack Driver Guide - Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host (Configuring DNP3 SCADAPack Tables)

Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host

When a SCADAPack E-Series outstation routes a TCP/IP packet to another TCP/IP host, the following rules are applied in order, until the packet has been sent or discarded:

  1. If only one TCP/IP interface is configured and that interface is PPP, the outstation routes each TCP/IP packet via that interface.
  2. If the TCP/IP packet has a destination address that matches a host on the same subnet as one of the Ethernet interfaces, the outstation routes the TCP/IP packet directly via that ethernet interface.
  3. If the packet has not been sent in step 1 or step 2, above, the outstation looks up the destination address of the packet in the IP Route table. It searches the entries in the route table in Host, Network, Gateway, and finally Default-Gateway order (see Types of IP Route). If a match is found, the outstation routes the packet to the corresponding gateway via the corresponding port.
  4. The packet is discarded.

NOTE: A SCADAPack E-Series outstation does not differentiate between TCP/IP packets that it generates itself and TCP/IP packets that it receives from another host. It applies the same routing rules to every packet.

If you create and configure an IP Route Table in ClearSCADA, you can use that table to specify up to 20 route entries for outbound TCP/IP packets. You can add entries to the table to allow a SCADAPack E-Series outstation to:

  • Route TCP/IP packets that the outstation generates, to any host that is not on a local subnet.
  • Act as a TCP/IP router, enabling the outstation to forward packets between subnets.

Further Information

Types of IP Route.

Add and Configure the Entries in an IP Route Table.


DNP3 SCADAPack Driver Guide - Types of IP Route (Configuring DNP3 SCADAPack Tables)

Types of IP Route

A SCADAPack E-Series outstation can support four types of IP route:
Type of Route (Priority Level) | Description | Destination IP Address | Destination Subnet Mask | Gateway IP
Host (1) | A route to a specific IP host | The IP address of the destination host | 255.255.255.255 | None (0.0.0.0)
Network (2) | A route to a network on which the target host is located | The network IP address | The network subnet mask | None (0.0.0.0)
Gateway (3) | A route to a network on which the target host is located via a gateway/router | The network IP address | The network subnet mask | The IP address of the gateway
Default Gateway (4) | The route for packets that do not match any other route entries | None (0.0.0.0) | None (0.0.0.0) | The IP address of the gateway. Use 0.0.0.0 if the default route is via a PPP link

NOTE: The Network route type should only be used for routing via serial ports configured for PPP/TCPIP.

Example:

A system has the following set-up:

In order for the outstation to route TCP/IP packets to the required TCP/IP hosts, an IP Route Table is configured. For the network shown above, the table has these settings:

This example illustrates the four types of IP Route that a SCADAPack E-Series outstation can support.

Row 1 shows how a Host route might be configured.
Row 2 shows how a Network route might be configured.
Row 3 shows how a Gateway route might be configured.
Row 4 shows how a Default-Gateway route might be configured.


DNP3 SCADAPack Driver Guide - Add and Configure the Entries in an IP Route Table (Configuring DNP3 SCADAPack Tables)

Add and Configure the Entries in an IP Route Table

To add entries to a IP Route Table, you need to Display the Table. If the table has insufficient rows, you will need to Specify the Table Size.

You need to add a route entry for each non-local IP address to which a SCADAPack E-Series outstation is to transfer data. There is no need to include entries for IP addresses that are on the same local subnet as the outstation, as data packets will be automatically forwarded to those addresses.

For greatest efficiency, order the entries in a IP Route Table so that routes that are used the most often appear at the top of the table, in priority order (Host, Network, Gateway, and then Default-Gateway). This allows the outstation’s TCP/IP stack to quickly locate the routes that it is to use to transfer most incoming IP data packets.

NOTE: The entries that you specify in an IP Route Table are persistent (that is, they are retained when the outstation restarts). Any routes that are added using the diagnostic ROUTE command or ISaGRAF function blocks are non-persistent (that is, they will be discarded when the outstation restarts). See the outstation documentation for details on the ROUTE command and ISaGRAF function blocks.

ATTENTION: Downloading an IP Route Table to a SCADAPack E-Series outstation will cause a Cold Reset and therefore the loss of any dynamic entries in a table.

ClearSCADA automatically allocates a unique Index number to each entry in an IP Route table. For each entry in the table, you need to specify:

  • Destination IP Address—The IP address of the host that matches the destination address of the TCP/IP packets sent by the outstation. The address is used in conjunction with the Subnet Mask to identify a range of target host IP addresses. Leave this field blank (defaults to 0.0.0.0 when saved) for Default Route entries.

Example:

192.186.1.0

  • Destination Subnet Mask—The Subnet Mask is used in conjunction with the Destination IP Address to identify either a single host address, or a range of host addresses (a subnet). Leave this field blank (defaults to 0.0.0.0 when saved) for Default Route entries.

Example:

255.255.255.0

  • Destination Port—The outstation Port via which the IP packet is to be sent. Use the combo box to select the required port.

If you select a serial port, ensure that the Port Function for that port is set to PPP/TCPIP (see Configure the Properties of the Individual Ports).

  • Gateway IP—The IP address of the host that provides the ‘gateway’ to the target host. Leave this field blank (defaults to 0.0.0.0 when saved) for non-gateway routes.

Example:

192.168.0.1

NOTE: The Gateway IP address has to be on the same subnet as the outstation’s interface for the corresponding route. For example, if the Ethernet 1 interface is configured with an IP address of 192.168.0.1 and a subnet mask of 255.255.255.0, the gateway address could be 192.168.0.2, but cannot be 192.169.0.1

  • Metric—Use to determine the route priority when multiple paths exist for interconnecting IP Hosts. The higher the number, the lower the priority. Set the entry to zero to apply the default metric value for a particular type of route (for example, PPP interfaces tend to have a higher metric and therefore a lower priority than Ethernet interfaces).

For an example that illustrates how the different route types (Host, Network, Gateway, and Default-Gateway) might be configured, see Types of IP Route.

Use the IP Route Table field on the DNP3 SCADAPack E-Series Outstation Form’s SCADAPack TCP/IP tab to associate the table with a particular outstation (see Specify IP Route and BOOTP Tables).


DNP3 SCADAPack Driver Guide - Working with DNP3 SCADAPack E-Series Outstation Configuration Files

Working with DNP3 SCADAPack E-Series Outstation Configuration Files

In addition to generating a SCADAPack E-Series outstation’s configuration based on the DNP3 SCADAPack E-Series items in the ClearSCADA database, ClearSCADA allows you to add a variety of files to a SCADAPack E-Series outstation, for downloading to that outstation during the configuration download process.

You can choose whether the additional files are downloaded during an automatic or manual configuration download to each outstation.

This section describes:

  • The Configuration Setup Window
  • The Supported File Types
  • File Restrictions
  • Add a File to a SCADAPack E-Series Outstation’s Configuration
  • Update a File in a SCADAPack E-Series Outstation’s Configuration
  • Export a File from a SCADAPack E-Series Outstation’s Configuration
  • Remove a File from a SCADAPack E-Series Outstation’s Configuration
  • View a File in a SCADAPack E-Series Outstation’s Configuration
  • Edit a File in a SCADAPack E-Series Outstation’s Configuration
  • Specify the Properties of a File in a SCADAPack E-Series Outstation’s Configuration
  • Generate Configuration and Profile Files for Diagnostic Purposes
  • Restart Level
  • Configuration Log File.

NOTE: You can also download files to a SCADAPack E-Series outstation by using the outstation’s Download File pick action. For further information, see Download File in the ClearSCADA Guide to the DNP3 Driver.

Further Information

Download Firmware.


DNP3 SCADAPack Driver Guide - Configuration Setup Window (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Configuration Setup Window

Use the configuration setup window (shown below) to add, modify, and remove files from a SCADAPack E-Series outstation configuration. To display the configuration setup window, right-click on the DNP3 SCADAPack E-Series outstation in the Database Bar and select the Configuration setup option.

A log file is added to the list of files once a download is generated. You can use the file to assess the success, or otherwise, of the last download.
Indication of whether the last download of a file was successful.
The action that ClearSCADA will perform on the outstation after the file has been downloaded.
The total size of the files that are listed above.
The size of each file.
List of files for downloading to a SCADAPack E-Series outstation.

You can use the Configuration Setup window to:

  • Add a File to a SCADAPack E-Series Outstation’s Configuration.
  • Update a File in a SCADAPack E-Series Outstation’s Configuration.
  • Export a File from a SCADAPack E-Series Outstation’s Configuration.
  • Remove a File from a SCADAPack E-Series Outstation’s Configuration.
  • View a File in a SCADAPack E-Series Outstation’s Configuration.
  • Edit a File in a SCADAPack E-Series Outstation’s Configuration.
  • Specify the Properties of a File in a SCADAPack E-Series Outstation’s Configuration.
  • Generate Configuration and Profile Files for Diagnostic Purposes.


DNP3 SCADAPack Driver Guide - Supported File Types (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Supported File Types

The types of file that you can download to a SCADAPack E-Series outstation via ClearSCADA include:

  • RTU Configuration Files (.RTU)—In order to configure SCADAPack E-Series functionality not supported by ClearSCADA, you can create up to two files containing additional configuration information. One file can be prepended to the beginning of the configuration created by ClearSCADA, and one file can be appended to the end of the configuration created by ClearSCADA.
  • ISaGRAF Files (.X8M)—You can add up to two ISaGRAF files to the ClearSCADA database, so that ClearSCADA can download the files to the outstation. For the naming conventions that are required when importing ISaGRAF files into ClearSCADA, see File Restrictions.
  • Configuration Files (.CONF)—You can add NTP configuration files to the ClearSCADA database, so that ClearSCADA can download the files to the outstation.

NOTE: The NTP configuration file must be named NTP.CONF

  • License Files (.LIC)—You can add license files to the ClearSCADA database. ClearSCADA can then be used to download the licenses to the outstation, to allow software to run at that outstation.

NOTE: License files are generated based on the serial number of the SCADAPack E-Series outstation. License files that are generated for one outstation will not enable the features on any other outstation.

  • Profile Files—The profiler is an advanced feature of the SCADAPack E-Series outstation that modifies the properties and values of points in the outstation based on a user-defined time profile. You can configure the required Profiles in ClearSCADA, then download the Profile configuration, in the form of Profile Files, to the outstation.

You can also generate temporary copies of the Profile Files for diagnostic purposes (see Generate Configuration and Profile Files for Diagnostic Purposes).

For information on configuring Profiles in ClearSCADA, see Configuring DNP3 SCADAPack Profiles.

For more information on the E-Series outstations’ Profile support, see the SCADAPack E-Series Profiler User and Reference Manual.

  • Binary Files—Any file containing binary data can be downloaded to the SCADAPack E-Series outstation.

In order to import any of these files successfully into ClearSCADA, you need to ensure that the files comply with certain File Restrictions.

NOTE: Whenever ClearSCADA downloads any RTU Configuration files to a DNP3 SCADAPack E-Series outstation, a log file is added to the list in the Configuration Setup window. You can use this ASCII file for diagnostic purposes (see Configuration Log File).


DNP3 SCADAPack Driver Guide - File Restrictions (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

File Restrictions

The files that you download to a SCADAPack E-Series outstation have to comply with the following conventions. Where a file name needs adjusting to conform to these requirements, you can do this by renaming the file (see Specify the Properties of a File in a SCADAPack E-Series Outstation’s Configuration), rather than renaming the original copy of the file.

If a file does not comply with these limitations or displays any invalid characters, the OK button on the Properties window will appear ‘grayed out’ and unavailable for use.

  • Each file has to have a unique name.
  • The total file name, including file extension, must be no longer than 20 characters.
  • The name must not include any character spaces (you can use underscores to separate characters if you wish).
  • When adding an ISaGRAF (*.X8M) file, you must name the file either ISa11 or ISa21 and remove the .X8M file extension.
  • You can add only one RTU Configuration File with a Concatenation Type of Beginning.
  • You can add only one RTU Configuration File with a Concatenation Type of End.


DNP3 SCADAPack Driver Guide - Add a File to a SCADAPack E-Series Outstation's Configuration (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Add a File to a SCADAPack E-Series Outstation’s Configuration

Use the Add button on the Configuration Setup Window to import a file into the ClearSCADA database so that it can be downloaded to the DNP3 SCADAPack E-Series outstation during a configuration download.

To add a file, select the Add button—the Open window (shown below) is displayed.

Use the Open window to browse to and select the file that you want to add to the outstation’s configuration. You can filter the type of file, using the Files of type combo box.

Once you have located the required file, highlight the file entry and select the Open button. The Properties window is displayed. Use the window to specify the properties of the file (see Specify the Properties of a File in a SCADAPack E-Series Outstation’s Configuration).

Once you have specified the file’s properties, select the OK button on the Properties window. The file’s details are added to the Configuration Setup Window.

Select the OK button on the Configuration Setup window to add the specified file to the DNP3 SCADAPack E-Series outstation in the ClearSCADA database.


DNP3 SCADAPack Driver Guide - Update a File in a SCADAPack E-Series Outstation's Configuration (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Update a File in a SCADAPack E-Series Outstation’s Configuration

Use the Update button on the Configuration Setup Window to replace an existing file with a more up-to-date copy of that file. This action allows you to retain the existing property settings for the file.

To update a file, select the file in the Configuration Setup window and then select Update. When you select the Update button, an Open window is displayed. Use the window to browse for the file with which you want to replace the selected file.

The specified file is only updated in the DNP3 SCADAPack E-Series outstation’s configuration in ClearSCADA database when you select the OK button on the Configuration Setup window.

For further information, see Add a File to a SCADAPack E-Series Outstation’s Configuration.


DNP3 SCADAPack Driver Guide - Export a File from a SCADAPack E-Series Outstation's Configuration (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Export a File from a SCADAPack E-Series Outstation’s Configuration

Use the Export button on the Configuration Setup Window to export a file from the SCADAPack E-Series outstation to disk. You may, for instance, want to export the config.log file, in order to send the file to the ClearSCADA support department if the configuration is invalid.

To export a file, select the file’s entry in the Configuration Setup window and then select Export. When you select the Export button, a Save As window (shown below) is displayed.

Use the window to browse to a location to save the selected file. Use the window’s File name field to specify the name under which the selected file will be saved.

NOTE: The file that is exported is the copy that is located in the ClearSCADA server’s database. This may not be the same as the copy that is stored in the outstation. To upload a file directly from the outstation, use the DNP3 SCADAPack E-Series outstation’s Upload File pick action. For further information, see Upload File in the ClearSCADA Guide to the DNP3 Driver.


DNP3 SCADAPack Driver Guide - Remove a File from a SCADAPack E-Series Outstation's Configuration (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Remove a File from a SCADAPack E-Series Outstation’s Configuration

Use the Remove button on the Configuration Setup Window to remove a file from the SCADAPack E-Series outstation.

To remove a file:

  1. Select the file’s entry in the Configuration Setup window.
  2. Select the Remove button.
    A confirmation dialog is displayed.
  3. Select Yes to remove the file from the list in the Configuration Setup Window.

(Select No to keep the selected file.)

  4. Select the OK button on the Configuration Setup window.
    If ‘Yes’ was chosen in step 3, the specified file is removed from the DNP3 SCADAPack E-Series outstation in ClearSCADA database.

Removing a file from the DNP3 SCADAPack E-Series outstation in the ClearSCADA database does not remove the file from the SCADAPack E-Series outstation’s file system.

To remove a file from the outstation’s file system:

  • If the removed file is an RTU Configuration file (.RTU), the file will be effectively removed next time you perform a configuration download.
  • For most other types of file, you need to issue a ‘delete’ command using the outstation’s Execute Command pick action (see Execute Command in the ClearSCADA Guide to the DNP3 Driver.)
  • To delete a removed ISaGRAF file (.X8M), issue a ‘clear isagraf’ command rather than a ‘delete’ command. (If the ISaGRAF application file is deleted using the ‘delete’ command, the outstation will re-create the file when ISaGRAF restarts—for example when the outstation is cold reset.)


DNP3 SCADAPack Driver Guide - View a File in a SCADAPack E-Series Outstation's Configuration (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

View a File in a SCADAPack E-Series Outstation’s Configuration

Use the View button on the Configuration Setup Window to view a file stored in the SCADAPack E-Series outstation.

To view a file, select the file’s entry in the Configuration Setup window and then select View.

For ISaGRAF files, a summary of the ISaGRAF application is displayed in an ISaGRAF Information window.

For most other types of file, the file content is displayed in a text View window. When a large file, such as an RTU Configuration file, is displayed, its content may overrun the View window. Use the window’s scroll bars to view other parts of the file.

The content of text files is displayed in a text View window
The summary of an ISaGRAF file is displayed in an ISaGRAF Information window.

You cannot edit a file in the View window. To edit a file, see Edit a File in a SCADAPack E-Series Outstation’s Configuration.

NOTE: You cannot view Profile or Binary files (see Supported File Types) in ViewX. To view these types of file, Export them (see Export a File from a SCADAPack E-Series Outstation’s Configuration) and view them in an external application.


DNP3 SCADAPack Driver Guide - Edit a File in a SCADAPack E-Series Outstation's Configuration (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Edit a File in a SCADAPack E-Series Outstation’s Configuration

Use the Edit button on the Configuration Setup Window to edit a Configuration (.Conf) or RTU Configuration (.RTU) file.

To edit a file, select the file’s entry in the Configuration Setup window and then select Edit. When you select the Edit button, an Edit window (shown below) is displayed.

Edit the contents of the file by modifying the text in the Edit window. When you have made the required changes, select the OK button.

Select the OK button on the Configuration Setup window to update the specified file in ClearSCADA database.

The instructions above explain how to edit a file in the DNP3 SCADAPack E-Series outstation in the ClearSCADA database. The changes that you make to the file in the database are only applied to the file stored in the SCADAPack E-Series outstation’s file system once a configuration download is initiated. Such a download is initiated using the outstation’s Download Configuration pick action (see Download Configuration).

NOTE: You can only use the Edit button to edit files that have been added to the DNP3 SCADAPack E-Series outstation in the ClearSCADA database using the Add button (see Add a File to a SCADAPack E-Series Outstation’s Configuration). You cannot use the Edit button to modify a temporary configuration using the Generate button (see Generate Configuration and Profile Files for Diagnostic Purposes). To edit a temporary configuration, Export the file (see Export a File from a SCADAPack E-Series Outstation’s Configuration) and edit it in an external application.


DNP3 SCADAPack Driver Guide - Specify the Properties of a File in a SCADAPack E-Series Outstation's Configuration (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Specify the Properties of a File in a SCADAPack E-Series Outstation’s Configuration

Use the Properties button on the Configuration Setup Window to edit the properties of a file in the SCADAPack E-Series outstation’s configuration. The Properties window is also displayed when you add a file to the DNP3 SCADAPack E-Series outstation’s configurations (see Add a File to a SCADAPack E-Series Outstation’s Configuration).

NOTE: The Properties window is not available for RTU Configuration files that are temporarily generated using the Generate button on the Configuration Setup window (see Generate Configuration and Profile Files for Diagnostic Purposes).

  • Filename—Use to specify the name of the file, including any file extension, that will be used when the file is downloaded to the outstation. The name has to comply with the file naming restrictions (see File Restrictions).

Rename any ISaGRAF application files to either ISA11 or ISA21 before selecting the OK button (see File Restrictions).

  • Automatic Download—Use to specify whether the file is downloaded as part of an automatic configuration download initiated by the outstation. The outstation initiates the automatic download by setting its configuration corrupt IIN bit.

In order for ClearSCADA to download configuration automatically, the Allow Automatic Download property has to be enabled on the DNP3 SCADAPack E-Series Outstation Form. For further information, see Configure Automatic Configuration Download.

ATTENTION: Automatic configuration downloads may cause the outstation to be reset. For further information see Restart Level.

  • Manual Download—Use to specify whether the file can be downloaded manually using the outstation’s Download Configuration and Download SCADAPack File pick actions.

ATTENTION: Manual configuration downloads may cause the outstation to be reset. For further information see Restart Level.

  • File Type—Use to specify the content of the file (see Supported File Types). When adding a file (see Add a File to a SCADAPack E-Series Outstation’s Configuration), and ClearSCADA recognizes the extension of the file, this field is set to the appropriate value automatically.
  • Concatenation Type—Use to specify whether an RTU Configuration (.RTU) file (see Supported File Types) is to be appended to the start or end of the RTU Configuration file generated by ClearSCADA.

Choose from:

  • Beginning—The RTU Configuration (.RTU) file is inserted before the start of the configuration generated by ClearSCADA.
  • End—The RTU Configuration (.RTU) file is inserted after the end of the configuration generated by ClearSCADA.

NOTE: You may configure only one RTU Configuration (.RTU) file to have a Concatenation Type of end, and only one RTU Configuration (.RTU) file to have a Concatenation Type of beginning.

Example:

The file AIPMap.rtu is generated by the E-Series Configurator.

The file is added to the Configuration Setup window within ClearSCADA.

Within the Properties window, the file’s Concatenation Type is specified as ‘End’, and the ‘Automatic Download’ check box is selected.

The SCADAPack E-Series outstation with which the file is associated requests a download.

ClearSCADA generates an RTU Configuration file that contains the ClearSCADA database configuration that is associated with the outstation.

ClearSCADA appends the AIPMap.rtu data to the end of the RTU Configuration file, such that the file that is downloaded to the outstation contains the ClearSCADA configuration data followed by the AIPMap data.

Both sets of information are transmitted to the outstation as a result of the download request.


DNP3 SCADAPack Driver Guide - Generate Configuration and Profile Files for Diagnostic Purposes (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Generate Configuration and Profile Files for Diagnostic Purposes

Use the Generate button on the Configuration Setup Window to:

  • Create a temporary copy of an RTU Configuration file
  • If the outstation has any Profiles, create temporary copies of the Profile files.

Use the files for diagnostic purposes. For instance, use the RTU Configuration file to determine the restart level that would be required should such configuration actually be downloaded to the SCADAPack E-Series outstation (using the outstation’s Download Configuration pick action), or to determine the configuration that would be included in such a download.

To produce a temporary copy of such file(s), select the Generate button to display the File options window. The window contains two check boxes:

  • Comments—Select this check box if the temporary configuration file includes comments. Comments in the configuration file allow the contents of the file to be easily cross-referenced with items in the ClearSCADA database. Comments are ignored by the outstation.
  • Full Configuration File—Select this check box if the generated configuration file is a complete SCADAPack E-Series outstation configuration.

Ensure that the check box is clear if the file contains only the incremental configuration as a result of any ClearSCADA database changes since the last configuration download.

NOTE: If you create a full configuration, a file named ClearSCADAConfig.rtu is generated. If you create an incremental configuration, a file named ClearSCADAConfig.inc is generated.

Select the OK button on the File Options window to generate the file(s). The ClearSCADAConfig file (and Profile files, if applicable) are added to the list of files in the Configuration Setup window:

The temporary ClearSCADAConfig and Profile files are only available on the ViewX client on which they were created, and are deleted when the Configuration Setup window is closed. You can perform the following actions on these temporary files:

  • Export (see Export a File from a SCADAPack E-Series Outstation’s Configuration)
  • Remove (see Remove a File from a SCADAPack E-Series Outstation’s Configuration)

With a temporary ClearSCADAConfig file, you can also perform this action:

  • View (see View a File in a SCADAPack E-Series Outstation’s Configuration).

The temporary ClearSCADAConfig file is an ASCII text file that you can view in any text editor. For further information on the format and contents of this configuration file, see the SCADAPack E-Series Configuration File Format User and Reference Manual.


DNP3 SCADAPack Driver Guide - Restart Level (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Restart Level

When a file is added to the ClearSCADA database, ready for downloading to a SCADAPack E-Series outstation, the action that ClearSCADA is to perform following the downloading of that file is specified in the Re-Start Level column of the Configuration Setup Window.

The following Restart Levels are available:

  • Cold Reset—An orderly shutdown and restart of the outstation is performed—this is the equivalent of power cycling the outstation. Any event data that is stored in the outstation’s Event Buffer is retained.

ATTENTION: A Cold Reset drops the outputs of the outstation. Binary outputs are turned off, and analog outputs drop to their calibrated zero count (typically 4mA).

  • Config—The outstation processes the configuration file that ClearSCADA downloads. This adds any new points, updates the properties of existing points, and deletes any points that no longer exist in the ClearSCADA database.

NOTE: Any points that are currently in use by ISaGRAF applications are not fully deleted from the outstation’s configuration until the outstation is Cold Reset.

  • ISaGRAF—The ISaGRAF applications in the outstation are restarted.

ATTENTION: An ISaGRAF restart drops any outputs of the outstation that are controlled by ISaGRAF at the time the ISaGRAF application is restarted. Binary outputs are turned off, and analog outputs drop to their calibrated zero count (typically 4mA). Points with active interlocks (see Configure an Output Point or Pulse Action’s Interlock Properties) do not drop their outputs.

  • License & Cold Reset—The outstation’s license service is restarted. Following this, a Cold Reset is performed (see above).
  • None—Applies to files such as the Configuration Log File, which are not downloaded to the outstation.
  • Profile—The outstation’s Profiler task is restarted. This causes any profile files to be reprocessed.
  • Warm Reset—The outstation’s DNP3 driver is restarted. Any event data that is stored in the outstation’s Event Buffer is retained.

For restart levels not listed above, see Determine the Restart Level of a Configuration Download.


DNP3 SCADAPack Driver Guide - Determine the Restart Level of a Configuration Download (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Determine the Restart Level of a Configuration Download

When you use the Download Configuration pick action to perform a configuration download (see Download Configuration) and select the All Configuration option, a Cold Reset is performed. However, if you select the Changed Configuration Only option, ClearSCADA will perform a restart in accordance with the Restart Level of the modified configuration. This level depends on the type of configuration changes that have been made since the configuration was last downloaded to the outstation.

If you need to determine what restart ClearSCADA will issue to a SCADAPack E-Series outstation after a Changed Configuration Only download, generate a temporary version of the configuration file. When you generate the file, ensure that the Full Configuration File check box is clear in the File Options window (see Generate Configuration and Profile Files for Diagnostic Purposes). The Restart Level of the temporary ClearSCADAConfig file will indicate if a Cold Reset will be performed. Depending on the types of configuration changes that have occurred, the restart level will be one of the following:

  • Config—The outstation processes the configuration file that ClearSCADA downloads. This adds any new points, updates the properties of existing points, and deletes any points that no longer exist in the ClearSCADA database.

NOTE: Any points that are currently in use by ISaGRAF applications are not fully deleted from the outstation’s configuration until the outstation is Cold Reset.

  • Config & Cold Reset—The outstation processes the configuration file that ClearSCADA downloads. This adds any new points, updates the properties of existing points, and deletes any points that no longer exist in the ClearSCADA database. Following this, an orderly shutdown and restart of the outstation is performed—this is the equivalent of power cycling the outstation. Any event data that is stored in the outstation’s Event Buffer is retained.

ATTENTION: A Cold Reset drops the outputs of the outstation. Binary outputs are turned off, and analog outputs drop to their calibrated zero count (typically 4mA).

  • Config & Warm Reset—The outstation processes the configuration file that ClearSCADA downloads. This adds any new points, updates the properties of existing points, and deletes any points that no longer exist in the ClearSCADA database. Following this, the outstation’s DNP3 driver is restarted. Any event data that is stored in the outstation’s Event Buffer is retained.

Further Information

Restart levels that apply to files other than configuration files: see Restart Level.


DNP3 SCADAPack Driver Guide - Configuration Log File (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Configuration Log File

A SCADAPack E-Series outstation automatically generates a config.log file whenever the configuration of the outstation is regenerated (for example during a Config Restart or Cold Reset). ClearSCADA uploads the log file from the outstation and checks it for download errors. Any errors found are logged in the Event Journal.

ClearSCADA adds the log file to the list of files that is displayed in the Configuration Setup Window for that outstation. The file is updated whenever a manual or automatic download occurs on the outstation.

In addition to checking the entries in the Event Journal, you can view the raw log file to diagnose download problems. The rest of this section shows the type of information that a config.log file might show following Successful Configuration Download, and if there is an Unknown Entry in Configuration.


DNP3 SCADAPack Driver Guide - Successful Configuration Download (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Successful Configuration Download

The figure below shows the configuration log file (config.log) for a successful configuration download.


DNP3 SCADAPack Driver Guide - Unknown Entry in Configuration (Working with DNP3 SCADAPack E-Series Outstation Configuration Files)

Unknown Entry in Configuration

The figure below shows the configuration log file (config.log) for a successful configuration download where the configuration file included entries that the SCADAPack E-Series outstation could not interpret. The configuration log file indicates the line number (110 in this example) in which the unknown entry occurs.

Unknown entries are typically introduced when you add extra configuration file(s) to the beginning and/or end of the automatically generated configuration (see Add a File to a SCADAPack E-Series Outstation’s Configuration). If the error is introduced due to an added configuration file, check the additional file for errors (see the SCADAPack E-Series Configuration File Format User and Reference Manual).

If you have not included any additional configuration files, or the detected error occurs in the configuration generated by ClearSCADA, check that the firmware of the SCADAPack E-Series outstation is the latest available version.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Specific Alarm and Event Categories

DNP3 SCADAPack Specific Alarm and Event Categories

Each alarm and event on a ClearSCADA system has a Category that indicates the type of alarm or event. The Category is included by default in the Events List and, if applicable, the Alarms List and the Alarm Banner.

You can optionally filter the entries in either List by category—the entries from which you can choose comprise various ‘core’ categories, along with any categories that are specific to the drivers that are installed on your system.

On systems on which both the DNP3 and DNP3 SCADAPack E-Series driver components are installed, in addition to the ‘core’ and DNP3 driver-specific alarm and event categories, these DNP3 SCADAPack specific categories are available:

  • Alarm Inhibit—Entries associated with attempts to Disable Alarm Reporting or Enable Alarm Reporting.
  • Off Scan—Entries associated with unsuccessful attempts to place an item Off Scan or On Scan.

Further Information

DNP3 Specific Alarm and Events Categories: see DNP3 Specific Alarm and Event Categories in the ClearSCADA Guide to the DNP3 Driver.

Events Lists and ‘core’ filter categories: see the ClearSCADA Guide to Lists.

Alarms Lists and ‘core’ filter categories: see the ClearSCADA Guide to Alarms.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Specific Actions and Methods

DNP3 SCADAPack Specific Actions and Methods

This section explains those actions and methods that are DNP3 SCADAPack-specific and comprises the following sections:

  • Actions Associated with DNP3 SCADAPack E-Series Outstations
  • Actions Associated with DNP3 SCADAPack Firmware Image Items
  • Actions Associated with DNP3 SCADAPack Security Configuration Items
  • Actions Associated with DNP3 SCADAPack Points
  • Actions Associated with DNP3 SCADAPack Pulse Actions
  • Actions Associated with DNP3 SCADAPack E-Series Trends
  • Alphabetical List of DNP3 SCADAPack Specific Actions
  • DNP3 SCADAPack E-Series Automation Interface Methods.

Use this section in conjunction with the DNP3 driver documentation on DNP3-specific actions (see Using DNP3 Specific Actions in the ClearSCADA Guide to the DNP3 Driver).

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).


DNP3 SCADAPack Driver Guide - Actions Associated with DNP3 SCADAPack E-Series Outstations (DNP3 SCADAPack Specific Actions and Methods)

Actions Associated with DNP3 SCADAPack E-Series Outstations

These actions are specific to DNP3 SCADAPack E-Series Outstations and DNP3 SCADAPack Remote E-Series Outstations:

  • Apply Update Key—outstations that use DNP3 secure authentication
  • Download Configuration
  • Download Firmware
  • Download Remote Firmware
  • Download SCADAPack File
  • Download Security Configuration—outstations that use DNP3 secure authentication
  • Execute Command
  • Off Scan
  • On Scan
  • Retrieve All Trends
  • Upload Config.

These actions are in addition to the actions that are associated with DNP3 Outstations. Such actions are also available to DNP3 SCADAPack E-Series Outstations, DNP3 SCADAPack Remote E-Series Outstations, and DNP3 SCADAPack Remote DNP3 Devices—for information, see Actions Associated with DNP3 Outstations in the ClearSCADA Guide to the DNP3 Driver.

DNP3 SCADAPack E-Series outstations also support additional methods (pick actions) for use with the Automation Interface (see DNP3 SCADAPack E-Series Automation Interface Methods).

NOTE: For information on the Configuration Setup menu option, which you can access by right-clicking on a SCADAPack E-Series outstation or SCADAPack Remote E-Series outstation in the Database Bar, see Working with DNP3 SCADAPack E-Series Outstation Configuration Files.


DNP3 SCADAPack Driver Guide - Actions Associated with DNP3 SCADAPack Firmware Image Items (DNP3 SCADAPack Specific Actions and Methods)

Actions Associated with DNP3 SCADAPack Firmware Image Items

This action is specific to DNP3 SCADAPack Firmware Image database items:

  • Import Firmware Image.


DNP3 SCADAPack Driver Guide - Actions Associated with DNP3 SCADAPack Security Configuration Items (DNP3 SCADAPack Specific Actions and Methods)

Actions Associated with DNP3 SCADAPack Security Configuration Items

This action is specific to DNP3 SCADAPack Security Configuration database items:

  • Import Security Configuration.


DNP3 SCADAPack Driver Guide - Actions Associated with DNP3 SCADAPack Points (DNP3 SCADAPack Specific Actions and Methods)

Actions Associated with DNP3 SCADAPack Points

These actions are specific to DNP3 SCADAPack points:

  • Disable Alarm Reporting
  • Disable All Trends—(Only on points with which at least one Trend item is associated)
  • Enable Alarm Reporting
  • Enable All Trends—(Only on points with which at least one Trend item is associated)
  • Off Scan
  • On Scan.


DNP3 SCADAPack Driver Guide - Actions Associated with DNP3 SCADAPack Pulse Actions (DNP3 SCADAPack Specific Actions and Methods)

Actions Associated with DNP3 SCADAPack Pulse Actions

These actions are specific to DNP3 SCADAPack pulse actions:

  • Disable Alarm Reporting
  • Enable Alarm Reporting
  • Off Scan
  • On Scan.


DNP3 SCADAPack Driver Guide - Actions Associated with DNP3 SCADAPack E-Series Trends (DNP3 SCADAPack Specific Actions and Methods)

Actions Associated with DNP3 SCADAPack E-Series Trends

These actions are specific to DNP3 SCADAPack E-Series Trend items:

  • Disable Point
  • Enable Point.


DNP3 SCADAPack Driver Guide - Alphabetical List of DNP3 SCADAPack Specific Actions (DNP3 SCADAPack Specific Actions and Methods)

Alphabetical List of DNP3 SCADAPack Specific Actions

This section lists those actions that are DNP3 SCADAPack-specific. These actions are in addition to actions that are specific to the parent DNP3 driver (see Using DNP3 Specific Actions in the ClearSCADA Guide to the DNP3 Driver).

  • Apply Update Key
  • Disable Alarm Reporting
  • Disable All Trends
  • Disable Point
  • Display Trend Objects
  • Download Configuration
  • Download Firmware
  • Download Remote Firmware
  • Download SCADAPack File
  • Download Security Configuration
  • Enable Alarm Reporting
  • Enable All Trends
  • Enable Point
  • Execute Command
  • Import Firmware Image
  • Import Security Configuration
  • Off Scan
  • On Scan
  • Retrieve All Trends
  • Upload Config.


DNP3 SCADAPack Driver Guide - Apply Update Key (DNP3 SCADAPack Specific Actions and Methods)

Apply Update Key

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this pick action: Configure

The Apply Update Key pick action is only available on outstations on which:

  • DNP3 Secure Authentication is enabled
  • The security settings are configured remotely via ClearSCADA (see Import and Download SCADAPack Security Configuration Files).

The security configuration file that is downloaded to an outstation using the Download Security Configuration pick action contains an encrypted Update Key. Once the download has completed successfully, both the outstation and ClearSCADA should automatically start to use the new Update Key for any secure communications. Should a download be successful, but an Update Key mismatch occur (for instance should the outstation neglect to notify ClearSCADA that the download succeeded), use the Apply Update Key pick action to instruct ClearSCADA to use the new Update Key.

Use the Apply Update Key pick action to indicate to ClearSCADA that it should now use the Update Key that was specified when the outstation’s security configuration file was imported into ClearSCADA (see Import Security Configuration).

(To apply a different Update Key to that associated with the outstation’s security configuration file, use the Set Update Key pick action, rather than the Apply Update Key pick action.)


DNP3 SCADAPack Driver Guide - Disable Alarm Reporting (DNP3 SCADAPack Specific Actions and Methods)

Disable Alarm Reporting

Associated with: DNP3 SCADAPack points and pulse actions

Security permission required to access this pick action: Disable Alarms

Use this pick action to disable alarm reporting on, for instance, a faulty sensor.

Use the Disable Alarm Reporting pick action to:

  • Request that the outstation ceases to generate events for the point (and so reduce system load by ceasing to report events for that point)

and:

  • Disable alarms on the point in ClearSCADA. (For information on the affect this has in ClearSCADA, see Disable Alarms and Enable Alarms in the ClearSCADA Guide to Alarms.)

On a PSTN outstation, use this pick action to trigger ClearSCADA to dial out to the outstation, and request that event generation is disabled for this point.

The point or pulse action’s Alarm Reporting status attribute indicates whether alarm reporting is currently disabled on that item.


DNP3 SCADAPack Driver Guide - Disable All Trends (DNP3 SCADAPack Specific Actions and Methods)

Disable All Trends

Associated with: DNP3 SCADAPack points to which at least one Trend item is attached

Security permission required to access this pick action: Disable Points

Use this pick action to disable the Trend items that are associated with this particular point (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality). While Trends are disabled, the outstation ceases to sample the point’s data.

On a PSTN outstation, use this pick action to trigger ClearSCADA to dial out to the outstation, to request that sampling of the point’s data ceases.

Use the Enable All Trends pick action to enable the outstation to start sampling the point’s data again.

An entry is logged in the Event Journal whenever either pick action is used. The message indicates whether Trend sampling has been enabled or disabled.

The point’s Trending Inhibited status attribute indicates whether Trend sampling is currently inhibited.

NOTE: If using this pick action with the Automation Interface (see DNP3 SCADAPack E-Series Automation Interface Methods), you need to specify the method name DisableTrending.

To disable data sampling on an individual Trend, use that Trend item’s Disable Point pick action.


DNP3 SCADAPack Driver Guide - Disable Point (DNP3 SCADAPack Specific Actions and Methods)

Disable Point

Associated with: DNP3 SCADAPack E-Series Trend items

Security permission required to access this pick action: Disable Points

Use the Disable Point pick action to temporarily disable a Trend item. When triggered, ClearSCADA clears the Trend item’s In Service property, so that the Trend item is no longer active. While the Trend remains disabled ClearSCADA ignores any trend data returned by the outstation for the disabled Trend.

To disable the Trend at the outstation in addition to ClearSCADA, use the Download Configuration pick action to download the changes to the outstation with which the Trend is associated.

Use the Enable Point pick action to place the Trend item back In Service.

An entry is logged in the Event Journal whenever either pick action is used. The message indicates whether the Trend item has been enabled or disabled.

Also see Disable All Trends.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Disable.


DNP3 SCADAPack Driver Guide - Display Trend Objects (DNP3 SCADAPack Specific Actions and Methods)

Display Trend Objects

Associated with: DNP3 SCADAPack points to which at least one Trend item is attached

Security permission required to access this pick action: Read

Select this pick action to display a Queries List of the Trend database item(s) that are associated with this particular point. Each Trend item defines the rate at which the outstation samples the point’s data (see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality).

NOTE: Do not confuse this pick action with the Display Current Trend and Display Historic Trend pick actions that are available for points on many drivers (the latter is only if Historic is enabled on a point). These pick actions enable you to display a point’s current or historic data in graph format (see Types of Trend in the ClearSCADA Guide to Core Point Configuration).

NOTE: The Display Trend Objects pick action is not a method and therefore cannot be used with the Automation Interface.


DNP3 SCADAPack Driver Guide - Download Configuration (DNP3 SCADAPack Specific Actions and Methods)

Download Configuration

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this pick action: Configure

WARNING

unexpected behavior of application

Downloading configuration may cause outstation tasks (such as ISaGRAF or Profiler), or the entire outstation, to reset. Always ensure that it is safe to allow the outstation to reset before issuing an All Configuration or Changed Configuration Only download.

You can generate a temporary copy of an RTU Configuration file, in order to determine the restart level that will be required (see Generate Configuration and Profile Files for Diagnostic Purposes). The Restart level determines if the SCADAPack E-Series outstation will be reset (see Restart Level).

Failure to follow these instructions can result in death, serious injury, or equipment damage.

CAUTION

inoperable device

Always verify that the outstation’s communications settings are configured correctly in ClearSCADA before triggering a Download Configuration action. Should the configuration conflict with the actual setup at the outstation, normal communications between ClearSCADA and the outstation might cease. This might occur, for example, if there is a mismatch between the downloaded port configuration and the actual ports that the outstation is using.

Only attempt to download configuration when there is sufficient time to recover the situation in the event of a configuration mismatch occurring.

Failure to follow these instructions can result in inoperable equipment.

The Download Configuration action allows you to download the outstation’s configuration from ClearSCADA, once that configuration has been specified in the ClearSCADA database. When you select this action, a Download Configuration window is displayed, prompting you to select the type of configuration download that ClearSCADA is to perform.

Choose from:

  • All Configuration—ClearSCADA downloads a complete configuration and then Cold Resets the SCADAPack E-Series outstation.
  • Changed Configuration Only—ClearSCADA downloads only the configuration changes that have been made since the last configuration download. This may result in a Cold Reset of the outstation, or restart some of the outstation’s tasks, depending on the configuration changes that are downloaded (see Determine the Restart Level of a Configuration Download).

With PSTN and ‘On Demand’ outstations, the Download Configuration window may display a Queue check box. Use the check box to indicate whether ClearSCADA is to perform the download immediately, or queue the request if ClearSCADA is not currently in communications with the outstation (see Queue Check Box in the ClearSCADA Guide to Drivers).

After selecting the OK button you may be asked to confirm your request before ClearSCADA attempts to execute or queue the download request—this helps to ensure that the request is not triggered unintentionally (see Specify Whether a Download Configuration Request Requires Confirmation).

After downloading the configuration, ClearSCADA uploads the config.log file that is produced by the SCADAPack E-Series outstation (see Configuration Log File). If the configuration file is invalid (cannot be processed by the outstation), ClearSCADA raises an alarm.

Further Information

DNP3 SCADAPack E-Series outstations can also support these Download pick actions:

  • Download Firmware
  • Download SCADAPack File
  • Download Security Configuration.


DNP3 SCADAPack Driver Guide - Download Firmware (DNP3 SCADAPack Specific Actions and Methods)

Download Firmware

Associated with: DNP3 SCADAPack E-Series Outstations and DNP3 SCADAPack Remote E-Series Outstations

Security permission required to access this pick action: Configure

WARNING

unexpected behavior of application

Downloading firmware to an outstation will cause the outstation to reset, during which time it will be offline for a number of minutes. Always ensure that any Trend data is recovered, and that it is safe to allow the outstation to reset, before issuing a Download Firmware request. For example, ensure that there are no active alarm conditions that need monitoring on the outstation or any remote I/O modules.

To check whether an outstation is currently processing a request, look at its entry in the Outstations List’s Current Request column. You can also check an outstation’s current activity via, for example, the Events List or the outstation’s Status display. Use the Retrieve All Trends pick action to retrieve any Trend data.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

CAUTION

inoperable device

Should a firmware download be unsuccessful (for example, if power is lost at the outstation before the download completes), the outstation will typically revert to using the version of firmware that was running before the download was attempted. If power is lost while the bootloader is patching the firmware, the outstation might be left in an inoperable state. If this occurs, an engineer will need to recover the situation locally at the outstation.

Only attempt to download firmware or download remote firmware when there is sufficient time to manually recover the situation in the unlikely event of an unsuccessful download.

Failure to follow these instructions can result in inoperable equipment.

Use this pick action to download a previously imported .biz file to a SCADAPack E-Series outstation, to update that outstation’s operating system firmware.

If the outstation is the main unit of a Main-SCADAPack ES Remote I/O configuration, the request may also result in the same firmware being downloaded automatically to each of the remote I/O modules that are connected to the outstation. The Patch Remotes check box on the outstation’s configuration Form determines whether the firmware is downloaded to only the main outstation or also to its remote SCADAPack ES I/O modules (see Configure the Firmware Image Properties). (To download firmware to remote I/O module(s) only, use the Download Remote Firmware pick action.)

Further Information

Importing firmware into ClearSCADA, and further information on .biz files: see Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files.


DNP3 SCADAPack Driver Guide - Download Remote Firmware (DNP3 SCADAPack Specific Actions and Methods)

Download Remote Firmware

Associated with: DNP3 SCADAPack E-Series Outstations and DNP3 SCADAPack Remote E-Series Outstations

Security permission required to access this pick action: Configure

WARNING

unexpected behavior of application

Downloading firmware to an outstation will cause the outstation to reset, during which time it will be offline for a number of minutes. Always ensure that any Trend data is recovered, and that it is safe to allow the outstation to reset, before issuing a Download Firmware request. For example, ensure that there are no active alarm conditions that need monitoring on the outstation or any remote I/O modules.

To check whether an outstation is currently processing a request, look at its entry in the Outstations List’s Current Request column. You can also check an outstation’s current activity via, for example, the Events List or the outstation’s Status display. Use the Retrieve All Trends pick action to retrieve any Trend data.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

CAUTION

inoperable device

Should a firmware download be unsuccessful (for example, if power is lost at the outstation before the download completes), the outstation will typically revert to using the version of firmware that was running before the download was attempted. If power is lost while the bootloader is patching the firmware, the outstation might be left in an inoperable state. If this occurs, an engineer will need to recover the situation locally at the outstation.

Only attempt to Download Remote Firmware when there is sufficient time to manually recover the situation in the unlikely event of an unsuccessful download.

Failure to follow these instructions can result in inoperable equipment.

With an outstation that is the main unit of a Main-SCADAPack ES Remote I/O configuration, you can use the Download Remote Firmware pick action to download a previously imported .biz file to one or more of the remote I/O modules that are connected to that outstation and/or the main outstation itself.

Select the Download Remote Firmware pick action to display the Download Remote Firmware window:

The window has two fields:

  • Firmware—Use this field’s browse button to display a Reference browse window. Select the relevant DNP3 SCADAPack Firmware Image database item from the window (this is the database item that has been used to import the firmware .biz file into ClearSCADA).
  • Target—Use this combo box to specify whether ClearSCADA is to download the firmware to the outstation and/or its remote I/O module(s). The options are:
  • Local—ClearSCADA downloads the firmware to the local outstation only.
  • Remote n—15 options that allow you to specify to which individual remote I/O module (1 to 15) ClearSCADA is to download the firmware.
  • All—ClearSCADA downloads the firmware to both the local outstation and each of the remote I/O modules that are connected to that outstation.
  • All Remotes—ClearSCADA downloads the firmware to each of the remote I/O modules that are connected to the outstation. This option doesn’t download the firmware to the local outstation itself.

Select the OK button to confirm the options and trigger the download.

Further Information

Importing firmware into ClearSCADA, and further information on .biz files: see Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files.

Use the Download Firmware pick action to Download Firmware.


DNP3 SCADAPack Driver Guide - Download SCADAPack File (DNP3 SCADAPack Specific Actions and Methods)

Download SCADAPack File

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this pick action: Retrieve Data

WARNING

unexpected behavior of application

Downloading a SCADAPack file may cause outstation tasks (such as ISaGRAF or Profiler), or the entire outstation, to reset. Always ensure that it is safe to allow the outstation to reset before issuing a Download SCADAPack File request.

You can generate a temporary copy of an RTU Configuration file, in order to determine the restart level that will be required (see Generate Configuration and Profile Files for Diagnostic Purposes). The Restart level determines if the SCADAPack E-Series outstation will be reset (see Restart Level).

Failure to follow these instructions can result in death, serious injury, or equipment damage.

This action allows you to download an individual file to the outstation. You can download any file that has been added to the SCADAPack E-Series outstation’s configuration using the Configuration Setup window (see Add a File to a SCADAPack E-Series Outstation’s Configuration), providing that the file is configured for Manual Download (see Specify the Properties of a File in a SCADAPack E-Series Outstation’s Configuration).

Select this pick action to display the Download SCADAPack File window. Use the Filename combo box to select the file that you want to download to the outstation and then select OK.

NOTE: If using this pick action with the Automation Interface (see DNP3 SCADAPack E-Series Automation Interface Methods), you need to specify the method name eNETDownloadFile.

Further Information

DNP3 SCADAPack E-Series outstations can also support these Download pick actions:

  • Download Firmware
  • Download Configuration
  • Download Security Configuration.


DNP3 SCADAPack Driver Guide - Download Security Configuration (DNP3 SCADAPack Specific Actions and Methods)

Download Security Configuration

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this pick action: Configure

The Download Security Configuration pick action is only available on outstations on which DNP3 Secure Authentication is enabled.

WARNING

unexpected behavior of application

Downloading security configuration will result in a Warm Reset of the outstation (see Restart Level).

Always ensure that it is safe to allow the outstation to reset before issuing a Download Security Configuration request.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

CAUTION

inoperable device

Should the downloaded security configuration prove invalid, normal communications between ClearSCADA and the outstation might cease. This might occur, for example, if there is a mismatch between the downloaded security configuration file and the Update Key being used for secure communications.

Only attempt to download security configuration when there is sufficient time to recover the situation in the event of the downloaded security configuration file being invalid.

Failure to follow these instructions can result in inoperable equipment.

Use the Download Security Configuration pick action to download a previously imported .rtk file to a SCADAPack E-Series outstation, to configure that outstation’s security settings remotely (see Import and Download SCADAPack Security Configuration Files).

Once the security configuration file has been downloaded, you can use the outstation’s Downloaded Security File and Downloaded Security Description status attributes to ascertain summary information about that downloaded file.

ATTENTION: The security configuration file that is downloaded to the outstation using this pick action contains an encrypted Update Key. Once the download has completed successfully, both the outstation and ClearSCADA should automatically start to use this Update Key for any secure communications. Should an Update Key mismatch occur following a successful download (for instance should the outstation fail to notify ClearSCADA that the download succeeded), use the Apply Update Key pick action to instruct ClearSCADA to use the new Update Key.

NOTE: If using this pick action with the Automation Interface (see DNP3 SCADAPack E-Series Automation Interface Methods), you need to specify the method name DownloadSecurityConfig.


DNP3 SCADAPack Driver Guide - Enable Alarm Reporting (DNP3 SCADAPack Specific Actions and Methods)

Enable Alarm Reporting

Associated with: DNP3 SCADAPack points and pulse actions

Security permission required to access this pick action: Disable Alarms

Use this pick action to:

  • Allow an outstation to start generating events for a point on which the Disable Alarm Reporting pick action has been used

and:

  • Enable alarms on the point in ClearSCADA. As such, any new or existing alarms are no longer withheld from alarm and other displays in ClearSCADA. (For more information, see Disable Alarms and Enable Alarms in the ClearSCADA Guide to Alarms.)

On a PSTN outstation, use this pick action to trigger ClearSCADA to dial out to the outstation, and request that event generation is enabled for this point.

The point or pulse action’s Alarm Reporting status attribute indicates whether alarm reporting is currently enabled on that item.


DNP3 SCADAPack Driver Guide - Enable All Trends (DNP3 SCADAPack Specific Actions and Methods)

Enable All Trends

Associated with: DNP3 SCADAPack points to which at least one Trend item is attached

Security permission required to access this pick action: Disable Points

Use this pick action to allow an outstation to start sampling the data on a point on which the Disable All Trends pick action has been used to cease data sampling.

On a PSTN outstation, use this pick action to trigger ClearSCADA to dial out to the outstation, to request that the outstation starts to sample the point’s data.

The point’s Trending Inhibited status attribute indicates whether Trend sampling is currently inhibited.

NOTE: If using this pick action with the Automation Interface (see DNP3 SCADAPack E-Series Automation Interface Methods), you need to specify the method name EnableTrending.

To enable data sampling on an individual Trend, use that Trend item’s Enable Point pick action.


DNP3 SCADAPack Driver Guide - Enable Point (DNP3 SCADAPack Specific Actions and Methods)

Enable Point

Associated with: DNP3 SCADAPack E-Series Trend items

Security permission required to access this pick action: Disable Points

Use the Enable Point pick action to place a Trend item In Service. Triggering the action changes the Trend item’s configuration so that its In Service property is enabled.

If you are using the Enable Point pick action to enable a Trend item that is disabled at the outstation as well as in ClearSCADA, you then need to download the Trend item’s configuration to the outstation, using the Download Configuration pick action.

Providing that the devices on which the Trend item is dependant (such as its parent point and SCADAPack E-Series outstation) are also In Service and have valid configuration, the Trend item will become active.

Also see Disable Point, and see Enable All Trends.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Enable.


DNP3 SCADAPack Driver Guide - Execute Command (DNP3 SCADAPack Specific Actions and Methods)

Execute Command

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this pick action: Retrieve Data

Use the Execute Command pick action to execute a particular command. This section details only commands that are specific to DNP3 SCADAPack E-Series Outstations. For further information on using the Execute Command action, see Execute Command in the ClearSCADA Guide to the DNP3 Driver.

SCADAPack E-Series outstations support the execution of a number of commands via DNP3 including:

  • APPEND—Append a file to the end of another
  • CLEAR—Clear specified PDS information
  • COPY—Duplicate a file
  • DEL—Delete a file
  • RENAME—Rename a file
  • RESTART—Restart PDS facilities
  • FILEDIAG—Log diagnostics to a file.

For further information on using these commands on SCADAPack E-Series outstations via DNP3, see the SCADAPack E-Series Operation Reference Manual.


DNP3 SCADAPack Driver Guide - Import Firmware Image (DNP3 SCADAPack Specific Actions and Methods)

Import Firmware Image

Associated with: DNP3 SCADAPack Firmware Image items

Security permission required to access this pick action: Configure

In order for ClearSCADA to be able to download operating system firmware to a SCADAPack E-Series outstation, the compressed binary file that contains that firmware ‘image’ has to exist in the ClearSCADA database.

Use the Import Firmware Image pick action to import the compressed binary file into the ClearSCADA database and ensure that the file resides in the same location on each of the servers on your system. The location at which each compressed binary file is stored in ClearSCADA is specified using the Data Files field, within the Location section of the ClearSCADA Server Configuration Tool (see Locations of the Database Folders in the ClearSCADA Guide to Server Administration).

Once the file(s) have been imported into ClearSCADA, use the Download Firmware or Download Remote Firmware pick actions to download the file(s) to the relevant outstation(s).

To import a compressed binary file into ClearSCADA:

  1. Select the Import Firmware Image pick action to display the Import Firmware Image window.
  2. Select the browse button next to the File Name field.
    A File Name window is displayed.

    The layout of the window varies, depending on the operating system that you are running.
  3. Use the window to locate and select the SCADAPack E-Series .biz file that you want to import into your database. (For more information on this type of binary file, see Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files.)
  4. Select the Open button on the File Name window.
    The File Name window is closed and the name of the selected file is displayed in the Import Firmware Image window’s File Name field.
  5. In the Description field, enter a brief description about the compressed binary file. Use the description to differentiate between the various firmware image files that might be imported into the ClearSCADA database.

Users can ascertain both the file name and description at any time by viewing the DNP3 SCADAPack Firmware Image item’s Status display (see DNP3 SCADAPack Firmware Image Status Attributes).

  6. Select the OK button to confirm the details and import the selected file.
    The file is imported into the location that is specified using the ClearSCADA Server Configuration Tool’s Data Files field.

You can use a single Firmware Image item to import as many firmware updates as required over time. If you do this, be aware that ClearSCADA only retains the last file to be imported by each Firmware Image item and discards any previously imported files as soon as a new file has been imported successfully.

NOTE: If using this pick action with the Automation Interface (see DNP3 SCADAPack E-Series Automation Interface Methods), you need to specify the method name ImportImage.


DNP3 SCADAPack Driver Guide - Import Security Configuration (DNP3 SCADAPack Specific Actions and Methods)

Import Security Configuration

Associated with: DNP3 SCADAPack Security Configuration items

Security permission required to access this pick action: Configure

In order for ClearSCADA to be able to download a security configuration file to a SCADAPack E-Series outstation, the file that contains that security configuration has to exist in the ClearSCADA database.

Use the Import Security Configuration pick action to import the security configuration file into the ClearSCADA database and ensure that the file resides in the same location on each of the servers on your system. The location at which each security configuration file is stored in ClearSCADA is specified using the Data Files field, within the Location section of the ClearSCADA Server Configuration Tool (see Locations of the Database Folders in the ClearSCADA Guide to Server Administration).

To import a security configuration file into ClearSCADA:

  1. Select the Import Security Configuration pick action to display the Import Security Configuration window.
  2. Select the browse button next to the File Name field.
    A File Name window is displayed. The layout of the window varies, depending on the operating system that you are running.
  3. Use the window to locate and select the SCADAPack E-Series .rtk file that you want to import into your database. (For more information, see Import and Download SCADAPack Security Configuration Files.)
  4. Select the Open button on the File Name window.
    The File Name window is closed and the name of the selected file is displayed in the Import Security Configuration window’s File Name field.
  5. In order to communicate successfully using DNP3 Secure Authentication, both the DNP3 master (ClearSCADA) and DNP3 outstation have to be provided with a pre-shared private Update Key. ClearSCADA supports one Update Key per outstation (for the ‘Default User’).

An encrypted Update Key is included in each security configuration file generated by Schneider Electric’s Security Administrator application. The Update Key is encrypted in the file in such a way that it cannot be read by the DNP3 master (such as ClearSCADA).

Use the Key field to enter the private Update Key that is included in the security configuration file that you specified in step 2. The key has to be a 128-bit key comprising 32 hexadecimal digits (for example, 0123456789ABCDEF0123456789ABCDEF). The key is case insensitive.

It is imperative that the Key is kept secret and is not stored or transmitted in any way that could permit unauthorized access to the key.

ClearSCADA will reject any attempt to import a security configuration file into ClearSCADA using this Import Security Configuration pick action should an invalid Update Key be specified in this Key field. (An invalid Update Key is a key that contains non-hexadecimal digits or is of the wrong length.)

  6. In the Description field, enter a brief description about the security configuration file. Use the description to differentiate between the various security configuration files that might be imported into the ClearSCADA database.

Users can ascertain both the file name and description at any time by viewing the DNP3 SCADAPack Security Configuration item’s Status display (see DNP3 SCADAPack Security Configuration Status Attributes).

  7. Select the OK button to confirm the details and import the selected file.
    The file is imported into the location that is specified using the ClearSCADA Server Configuration Tool’s Data Files field.

You need to associate the security configuration file with the relevant DNP3 SCADAPack E-Series outstation(s) (see Configure the Security Configuration Properties), before you can use the Download Security Configuration pick action to download the file to those outstation(s).

You can use a single DNP3 SCADAPack Security Configuration item to import as many security configuration updates as required over time. If you do this, be aware that ClearSCADA only retains the last file to be imported by each DNP3 SCADAPack Security Configuration item and discards any previously imported files as soon as a new file has been imported successfully.

NOTE: If using this pick action with the Automation Interface (see DNP3 SCADAPack E-Series Automation Interface Methods), you need to specify the method name ImportSecurityFile.


DNP3 SCADAPack Driver Guide - Off Scan (DNP3 SCADAPack Specific Actions and Methods)

Off Scan

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations; DNP3 SCADAPack points and pulse actions

Security permission required to access this pick action: Off/On Scan

NOTE: The ability to place points and outstations Off Scan is disabled on most systems by default. (Its permission is typically denied on a per server basis.)

WARNING

unexpected behavior of application

Use the Off Scan pick action on an outstation with care—always check an outstation’s current activity before deciding whether to use this action.

To check whether an outstation is currently processing a request, look at its entry in the Outstations List’s Current Request column. You can also check an outstation’s current activity via, for example, the Events List or the outstation’s Status display.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

Depending on the system configuration, it may be possible to place individual points, or outstations and their dependants (such as points and pulse actions) ‘Off Scan’.

When an item is Off Scan:

  • If the Off Scan item is a point or pulse action on an outstation that is still active, that and any other Off Scan items will not report data to any of their DNP3 masters (including ClearSCADA)
  • If the Off Scan item is an outstation, the driver will send Data Link Status polls to that device to check that it is still there, but will not scan the device for other data
  • Any changes to the item’s configuration can still be downloaded to the outstation (even if the outstation itself is Off Scan)
  • Files can still be transferred to and from the outstation, including files for any Off Scan items
  • While Off Scan, the item’s functionality is much reduced. As such, only a limited subset of pick actions remain available from the item’s context sensitive menu
  • The item’s foreground color changes on various ClearSCADA displays to indicate that the item is Off Scan.

An Off Scan item differs from an item that is not In Service. An item that is not In Service is not scanned at all and is effectively ignored by ClearSCADA.

To place an individual point or pulse action Off Scan, select the Off Scan pick action from that item’s context sensitive menu.

To place an outstation Off Scan, select the outstation’s Off Scan pick action to display the Off Scan window.

Select the window’s Include Points check box if each of the outstation’s dependants, such as points and pulse actions, are also to be placed Off Scan. No events are generated, or data logged, for any points or pulse actions while they are Off Scan.

Ensure the check box is clear if the outstation’s dependants are to remain On Scan. Although the outstation does not report any data to ClearSCADA while it remains Off Scan, the points and pulse actions will remain ‘live’. As such, the outstation may continue to generate events and/or log data for any On Scan items. Such data will be stored locally at the outstation and be retrieved by ClearSCADA when the outstation is placed back On Scan.

With PSTN or ‘On Demand’ outstations and points and pulse actions on such outstations, the Off Scan window may display a Queue check box. Use the check box to indicate whether ClearSCADA is to perform the request immediately, or queue the request if ClearSCADA is not currently in communications with the outstation (see Queue Check Box in the ClearSCADA Guide to Drivers).

The entry that is logged in the Event List when the Off Scan pick action is triggered on an outstation indicates whether the Off Scan request includes the outstation’s points. Additionally, each item’s On Scan status attribute indicates whether that item is currently On or Off Scan.

Use the On Scan pick action to return an Off Scan item back to its fully functioning ‘On Scan’ state.


DNP3 SCADAPack Driver Guide - On Scan (DNP3 SCADAPack Specific Actions and Methods)

On Scan

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations; DNP3 SCADAPack points and pulse actions

Security permission required to access this pick action: Off/On Scan

NOTE: The ability to place points and outstations On Scan is disabled on most systems by default. (Its permission is typically denied on a per server basis.) The On Scan pick action is also disabled on points and pulse actions that have been taken ‘Off Scan’ using the ‘Include Points’ option on the outstation’s ‘Off Scan’ pick action (see Off Scan).

An item is ‘On Scan’ when it has valid saved configuration, is In Service, and ClearSCADA is able to communicate successfully with the device that the item represents.

Use the On Scan pick action to place an item that is currently Off Scan back to its fully functioning ‘On Scan’ state.

When you select the On Scan pick action for an outstation, an On Scan window is displayed.

Select the window’s Include Points check box if the outstation’s dependants, such as points and pulse actions, are also to be placed back On Scan. Leave the check box clear if the outstation’s dependants are to remain Off Scan, or were not taken Off Scan.

With PSTN or ‘On Demand’ outstations and points and pulse actions on such outstations, the On Scan window may display a Queue check box. Use the check box to indicate whether ClearSCADA is to perform the request immediately, or queue the request if ClearSCADA is not currently in communications with the outstation (see Queue Check Box in the ClearSCADA Guide to Drivers).

The entry that is logged in the Event List when the pick action is triggered on an outstation indicates whether the On Scan request includes that outstation’s points.

Each item’s On Scan status attribute indicates whether that item is currently On or Off Scan.


DNP3 SCADAPack Driver Guide - Retrieve All Trends (DNP3 SCADAPack Specific Actions and Methods)

Retrieve All Trends

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this pick action: Retrieve Data

SCADAPack E-Series outstations and 386 eNET outstations are capable of periodically sampling counter, analog input, binary input, derived analog, and derived binary point data. The sampled point data is stored locally at the outstation.

If configured to do so, ClearSCADA will automatically retrieve any sampled point data from a Direct or Shared outstation at the Trend Retrieval rate specified on the Outstation Form (see Configure the Trend Retrieval Properties). (ClearSCADA automatically retrieves any sampled point data from a PSTN outstation whenever it is in communications with that outstation.)

You can also use the Retrieve All Trends pick action to retrieve any sampled data that is stored at an outstation.

In either case, the sampled data is deleted from the outstation once the DNP3 master has read the data successfully.

Be aware that the sampled data may contain gaps, or may not be available, for any points on which the Disable All Trends pick action has been used to cease any trend sampling activity.


DNP3 SCADAPack Driver Guide - Upload Config (DNP3 SCADAPack Specific Actions and Methods)

Upload Config

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this pick action: Retrieve Data

This pick action causes:

  • The SCADAPack E-Series outstation to generate a Configuration File
  • ClearSCADA to download the generated file to the location specified in the Upload Config window, shown below.

The generated file contains the complete configuration of the outstation, excluding:

  • ISaGRAF Applications
  • Profile Files
  • License Files
  • NTP Configuration Files.

The resulting file can be opened using the E-Series Configurator, to examine the configuration of the SCADAPack E-Series outstation.

NOTE: If using this pick action with the Automation Interface (see DNP3 SCADAPack E-Series Automation Interface Methods), you need to specify the method name eNETUploadConfig.

Also see Import Firmware Image.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack E-Series Automation Interface Methods (DNP3 SCADAPack Specific Actions and Methods)

DNP3 SCADAPack E-Series Automation Interface Methods

In addition to the pick actions that are available in ViewX, several additional methods (pick actions) are available using the ClearSCADA Automation Interface.

The following methods are available on DNP3 SCADAPack E-Series Outstations and DNP3 SCADAPack Remote E-Series Outstations when using Automation Interface:

  • AddFile
  • ExportFile
  • RemoveFile
  • UpdateFile
  • UpdateFileProperties.

The following method is available on DNP3 SCADAPack Tables and DNP3 SCADAPack 32-bit Point Modbus Maps when using the Automation Interface:

  • UpdateRowDetails.

The following method is available on DNP3 SCADAPack Profiles when using the Automation Interface:

  • SetVectors.

NOTE: Where an action is referenced in the Automation Interface, the method name is typically the pick action name minus any character spaces. For example, the Download File pick action is the equivalent of the DownloadFile method. A note is included with the relevant pick action whenever this naming convention differs. See the ClearSCADA Database Schema for argument naming conventions not covered in this section.

For information on other Methods that are supported by the Automation Interface, see the ClearSCADA Database Schema. For information on working with the Database Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.


DNP3 SCADAPack Driver Guide - AddFile (DNP3 SCADAPack Specific Actions and Methods)

AddFile

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this method: Configure

Use this method to add a file to the ClearSCADA database, ready for downloading to a SCADAPack E-Series outstation. Once added, the file becomes available to ViewX users via the Configuration Setup window (see Working with DNP3 SCADAPack E-Series Outstation Configuration Files).

This method is the equivalent of importing a file by using the Add button on the Configuration Setup window (see Add a File to a SCADAPack E-Series Outstation’s Configuration).

Arguments:

  • SrcFileName—Use to specify details about the source of the file that you want to add to the ClearSCADA database. The form that this argument takes differs, depending on the source file’s location:

If the source file is on disk on the main server, the SrcFileName argument can comprise a string. Use the argument to specify the full path of the relevant file on the main server.

If the source of the file is the client that is calling the method (for instance, if the source is read from a file on the client’s hard disk or from a memory stick) use the SrcFileName argument to specify one of the following:

  • A three-element one-dimensional array comprising:
  • first element: a byte array containing the file’s content
  • second element: a string with the name of the source file (do not include the path)
  • third element: the last modified time of the file.

For an example that demonstrates such an array, see below.

  • A single byte array containing the content of the file that is to be added to the database. This option is deprecated and retained for backwards compatibility.

With a single byte array, the server will time stamp the file with the current time when it adds the file to the database (as the server will not be able to ascertain the last modified time of the file).

  • DstFileName (String)—Specify the destination file name - the name by which the file will be downloaded to the outstation. This is also the name under which the file will be stored in the ClearSCADA database.

Take care to ensure that the name complies with the naming restrictions that apply to the outstation’s filing system (see File Restrictions).

  • ManDownload (Boolean)—This argument is optional and defaults to FALSE. Use the argument to indicate whether the file is to be available for manual download. Specify TRUE or FALSE.
  • AutoDownload (Boolean)—This argument is optional and defaults to FALSE. Use the argument to indicate whether the file is to be automatically downloaded, in response to the outstation setting its DNP3 Configuration Corrupt IIN bit. Specify TRUE or FALSE.
  • FileType (Byte)—This argument is optional and defaults to 5 (generic binary file). Use the File Type argument to specify the type of file.

The FileType argument must be included if the SrcFileName argument is used to specify a single byte array containing only the file’s content (as per the SrcFileName argument’s last bullet point, above).

Supported file types are:

  • 0 - Configuration file (*.rtu)
  • 1 - ISaGRAF file (*.X8M)
  • 2 - Configuration file (for example, NTP configuration file (*.conf))
  • 3 - License file (*.lic)
  • 4 - Profile file (PROFILE_xxx_y)
  • 5 - Generic binary file
  • 6 - Generic ASCII file.

If the SrcFileName argument contains the name of the file, you can omit the FileType argument to trigger ClearSCADA’s automatic file type detection. When omitted, ClearSCADA will attempt to determine the actual file type based on the value of the SrcFileName argument.

Example 1:

With the following line of code, the AddFile method’s SrcFileName argument (C:\myfile.rtu) includes the source file’s extension. As such, the FileType argument is omitted, as ClearSCADA will automatically set the file type to 0 (configuration file) based on the source file’s ‘.rtu’ extension.

AddFile("C:\myfile.rtu", "config.rtu")

Example 2:

With this line of code, the FileType argument is omitted, as ClearSCADA will automatically set the file type to 4 (Profile file) based on the ‘PROFILE’ prefix to the source file’s name:

AddFile("C:\My Profiles\PROFILE_001_1", "PROFILE_001_1", TRUE)
  • ConcatType (Byte)—This argument is optional and defaults to 0 (None).

If the FileType is 0 (indicating a Configuration file), use this argument to specify whether the file is appended to the beginning or end of the configuration that is automatically generated by ClearSCADA.

For files other than configuration files, (that is, when the FileType is not 0) this argument is ignored and should be set to 0 (None).

The ConcatType argument can have one of the following values:

  • 0—None. Use this value for all non-RTU configuration file types.
  • 1—Beginning. This option indicates that the file will be appended to the front of the generated RTU configuration file.
  • 2—End. This option indicates that the file will be appended to the end of the generated RTU configuration file.

NOTE: For rules regarding adding configuration files to the SCADAPack E-Series outstation’s configuration, see File Restrictions.

Example:

With this example, a Microsoft® JScript program is used to add a file (located on a ViewX client’s D: drive) to the ClearSCADA database. The program uses the AddFile method to add the file to the database.

In this particular case, the method’s SrcFileName argument comprises a three-element one-dimensional array (‘FileInfo’), in order to pass the relevant file details to the server. For more information about the format that this type of array has to take, see the SrcFileName entry above. The second element of the array is used to specify the file’s name (the ‘Name’ property of the ‘File’ object, specified in line 11 below). In this particular case, the same value is also used for the DstFileName (line 15).

Be aware that this example only comprises a brief outline of the type of content that might be included in program that uses the AddFile method. For a more robust application, the program code should also include, for example, any error handling that is deemed to be required.

function AddFile()
{
var fso = new ActiveXObject("Scripting.FileSystemObject");
var File = fso.GetFile("D:\\myfile.rtu");
var BinaryStream = new ActiveXObject("ADODB.Stream");
BinaryStream.Type = 1;// Binary
BinaryStream.Open();
BinaryStream.LoadFromFile(File.Path);
var FileInfo = new Array(3);
FileInfo[0] = BinaryStream.Read();
FileInfo[1] = File.Name;
FileInfo[2] = File.DateLastModified;
BinaryStream.Close();
var Outstation = Server.FindObject("My Outstation");
Outstation.Interface.AddFile(FileInfo, File.Name);
}


DNP3 SCADAPack Driver Guide - ExportFile (DNP3 SCADAPack Specific Actions and Methods)

ExportFile

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this method: Configure

Use this method to either:

  • Export a file from a SCADAPack E-Series outstation in the ClearSCADA database, to a disk file on the main server.

(To export the file to a disk file on a ViewX client, use the Export button on the Configuration Setup window (see Export a File from a SCADAPack E-Series Outstation’s Configuration).)

  • Return the content of a file in the ClearSCADA database, to enable that file to be accessed from a client (so that, for example, the file’s content can be saved on the client’s disk).

Arguments:

  • SrcFileName (String)—Specify the name of the file that is stored in the ClearSCADA database.
  • DstFileName (String)—To export the above file from the database to a file on disk on the main server, specify the export destination for the file. Ensure that you specify the full path to the file.

To return the content of the file in the database, specify an ‘empty’ variant (rather than an empty string) for this argument (as per the example below).

Returns:

The ExportFile method returns a byte array containing the file content if the DstFileName argument is an ‘empty’ variant. (No File information is returned if DstFileName is used to specify a file name.)

Example:

This example demonstrates how a Microsoft® JScript program might be used to obtain the content of a file in the database using the ExportFile method. In this particular example, the file, named ‘Config.log’, is associated with the DNP3 SCADAPack E-Series outstation database item named ‘My Outstation’.

Because the file’s content is being returned rather than exported, the DstFileName argument (called ‘Dest’ in this example) is specified as an ‘empty’ variant:

function ExportFile()
{
var Dest;
var Outstation = Server.FindObject("My Outstation");
var File = Outstation.Interface.ExportFile("Config.log", Dest);
var BinaryStream = new ActiveXObject("ADODB.Stream");
BinaryStream.Type = 1;// Binary
BinaryStream.Open();
BinaryStream.Write( File );
BinaryStream.SaveToFile( "D:\\Config.log", 2 );
BinaryStream.Close();
}


DNP3 SCADAPack Driver Guide - RemoveFile (DNP3 SCADAPack Specific Actions and Methods)

RemoveFile

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this method: Configure

CAUTION

unexpected behavior of application

Use the RemoveFile method with care. Ensure that the file is no longer required or in use before attempting to remove the file from the database.

Failure to follow these instructions can result in unexpected loss of outstation functionality.

Use this method to remove a file from a DNP3 SCADAPack E-Series outstation in the ClearSCADA database.

This method is the equivalent of removing a file by using the Remove button on the Configuration Setup window (see Remove a File from a SCADAPack E-Series Outstation’s Configuration).

Argument:

  • FileName (String)—Specify the name of the file that is to be removed from the ClearSCADA database.


DNP3 SCADAPack Driver Guide - SetVectors (DNP3 SCADAPack Specific Actions and Methods)

SetVectors

Associated with: DNP3 SCADAPack Analog Profiles, DNP3 SCADAPack Binary Profiles, and DNP3 SCADAPack Counter Profiles

Security permission required to access this method: Configure

Use the SetVectors method to define all of the profile vectors on a DNP3 SCADAPack Profile item that exists in the ClearSCADA database.

The method is the equivalent of manually editing a profile’s vectors in ViewX (see Configuring DNP3 SCADAPack Profiles).

The SetVectors method arguments vary, depending on the type of Profile. For more information, see:

  • DNP3 SCADAPack Analog Profile Arguments
  • DNP3 SCADAPack Binary Profile Arguments

A DNP3 SCADAPack Binary Profile can be used to control a DNP3 SCADAPack Pulse’s action(s), or a DNP3 SCADAPack Binary point’s current value (as long as that point has a Point Type other than ‘Physical Input’).

  • DNP3 SCADAPack Counter Profile Arguments.

With each type of Profile, the arguments comprises a Times and one or more <Value Type>Values arrays. Ideally the <Value Type>Values arrays should contain the type of value that corresponds to the Profile’s type (for instance floating point 32-bit values to configure a DNP3 SCADAPack Analog Profile’s vectors). However, if an array contains different type(s) of value, ClearSCADA will automatically convert those values to the correct type when the SetVectors method is executed.

To successfully configure a DNP3 SCADAPack Profile’s vectors using the SetVectors method, you need to ensure that:

  • The Times are in sequential order, starting with the earliest time.
  • The Times are unique.
  • The alarm limits on SCADAPack Analog Profiles do not cross over each other. For example, the High4Values profile is greater than the High3Values profile.
  • Each array (Times array plus <Value Type>Values array(s)) contains the same number of elements (or is empty, to disable that particular profile).

If any of the above requirements are not adhered to, the method call will not succeed and ClearSCADA will not modify the DNP3 SCADAPack Profile’s vectors.

DNP3 SCADAPack Analog Profile Arguments

Use these arguments for defining the profiles vectors on a DNP3 SCADAPack Analog Profile:

  • Times (Word array)—The array of times to be used for the Profile’s vectors.

Specify the times in minutes from midnight at the start of the day. Times have to be unique, sequential, and can comprise any whole values between 0 and 1439 (the number of minutes in a day).

To stipulate a specific starting value for each profile on this Profile item, specify the first Time value as 0 (midnight at the start of the day).

If the first Time value is a value other than 0, the profiles defined for this DNP3 SCADAPack Profile item will use, as their starting value, the last value that is assigned to the previous day’s DNP3 SCADAPack Profile. As such, if this DNP3 SCADAPack Profile is assigned to several points, each of its profile’s starting values could vary on a per point basis.

  • Low4Values (Float array)—The array of values used to control a DNP3 SCADAPack Analog point’s 4 Low limit. Specify an empty array if the limit is not to be profile-controlled.
  • Low3Values (Float array)—The array of values used to control a DNP3 SCADAPack Analog point’s 3 Low limit. Specify an empty if the limit is not to be profile-controlled.
  • Low2Values (Float array)—The array of values used to control a DNP3 SCADAPack Analog point’s 2 Low limit. Specify an empty if the limit is not to be profile-controlled.
  • Low1Values (Float array)—The array of values used to control a DNP3 SCADAPack Analog point’s 1 Low limit. Specify an empty if the limit is not to be profile-controlled.
  • High1Values (Float array)—The array of values used to control a DNP3 SCADAPack Analog point’s 1 High limit. Specify an empty array if the limit is not to be profile-controlled.
  • High2Values (Float array)—The array of values used to control a DNP3 SCADAPack Analog point’s 2 High limit. Specify an empty if the limit is not to be profile-controlled.
  • High3Values (Float array)—The array of values used to control a DNP3 SCADAPack Analog point’s 3 High limit. Specify an empty if the limit is not to be profile-controlled.
  • High4Values (Float array)—The array of values used to control a DNP3 SCADAPack Analog point’s 4 High limit. Specify an empty if the limit is not to be profile-controlled.
  • CurrentValues (Float array)—The array of values to be used to control a DNP3 SCADAPack Analog point’s current value.

Specify an empty CurrentValues array if the Profile item is not to control an analog point’s current value. (This array must be empty if the Profile controls a DNP3 SCADAPack Analog point that has a ‘Physical Input’ Point Type.)

For each of the populated Values arrays listed above, you should ideally specify the values as floating point 32-bit values (however ClearSCADA will automatically convert other values to the correct type when the SetVectors method is executed).

For an example that demonstrates how you might use the SetVectors method to generate a DNP3 SCADAPack Analog Profile’s vectors, see Generate a DNP3 SCADAPack Profile’s Data Programmatically.

DNP3 SCADAPack Binary Profile Arguments

A DNP3 SCADAPack Binary Profile can be assigned to DNP3 SCADAPack Pulse Action(s) and/or DNP3 SCADAPack Binary Point(s) (providing that the latter have a Point Type other than ‘Physical Input’).

Use these arguments for defining the profiles vectors on a DNP3 SCADAPack Binary Profile:

  • Times (Word array)—The array of times to be used for the Profile’s vectors.

For more information on this array, see DNP3 SCADAPack Analog Profile Arguments.

  • CurrentValues (Byte array)—The array of values to be used to control a pulse’s actions, or a binary point’s current value. Each value in the array can be 0 or 1, as required.

For an example that demonstrates how you might use the SetVectors method to generate a DNP3 SCADAPack Binary Profile’s vectors, see Generate a DNP3 SCADAPack Profile’s Data Programmatically.

DNP3 SCADAPack Counter Profile Arguments

Use these arguments for defining the profiles vectors on a DNP3 SCADAPack Counter Profile:

  • Times (Word array)—The array of times to be used for the Profile’s vectors.

For more information on this array, see DNP3 SCADAPack Analog Profile Arguments.

  • HighValues (Double array)—The array of values to be used to control a DNP3 SCADAPack Counter point’s High limit. Specify each value in engineering units.

Specify an empty HighValues array if the Profile item is not to control a counter point’s High limit.

  • CurrentValues (Double array)—The array of values to be used to control a DNP3 SCADAPack Counter point’s current value. Specify each value in engineering units, with 0 being the lowest supported value.

Specify an empty CurrentValues array if the Profile item is not to control a counter point’s current value.

For an example that demonstrates how you might use the SetVectors method to generate a DNP3 SCADAPack Counter Profile’s vectors, see Generate a DNP3 SCADAPack Profile’s Data Programmatically.


DNP3 SCADAPack Driver Guide - UpdateFile (DNP3 SCADAPack Specific Actions and Methods)

UpdateFile

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this method: Configure

Use this method to replace a file that exists in a DNP3 SCADAPack E-Series outstation in the ClearSCADA database, with a new copy of the file.

This method is the equivalent of updating a file via the Update button on the Configuration Setup window (see Update a File in a SCADAPack E-Series Outstation’s Configuration).

Arguments:

  • DstFileName (String)—Specify the name of the file that is to be updated in the ClearSCADA database.
  • SrcFileName—Use to specify details about the source of the file that you want to update in the ClearSCADA database. The form that this argument takes differs, depending on the source file’s location:

If the source of the file that is being updated is on disk on the main server, the SrcFileName argument can comprise a string. Use the argument to specify the full path of the relevant file on the main server.

If the source of the file is the client that is calling the method (for instance, if the source is read from a file on the client’s hard disk or from a memory stick) use the SrcFileName argument to specify one of the following:

  • A three-element one-dimensional array comprising:
  • first element: a byte array containing the updated file content
  • second element: a string with the name of the source file (do not include the path)
  • third element: the last modified time of the file.
  • A single byte array containing the content of the file that is to be updated in the database. This option is deprecated and retained for backwards compatibility.

With a single byte array, the server will time stamp the file with the current time when it updates the file in the database (as the server will not be able to ascertain the last modified time of the file).


DNP3 SCADAPack Driver Guide - UpdateFileProperties (DNP3 SCADAPack Specific Actions and Methods)

UpdateFileProperties

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations

Security permission required to access this method: Configure

Use this method to update the property parameters for a file that exists in a DNP3 SCADAPack E-Series outstation in the ClearSCADA database.

This method is the equivalent of updating the file properties via the Properties button on the Configuration Setup window (see Specify the Properties of a File in a SCADAPack E-Series Outstation’s Configuration).

Arguments:

  • FileName (String)—Specify the name of the file that is stored in the ClearSCADA database.
  • ManDownload (Boolean)—see AddFile.
  • AutoDownload (Boolean)—see AddFile.
  • FileType (Byte)—see AddFile.


DNP3 SCADAPack Driver Guide - UpdateRowDetails (DNP3 SCADAPack Specific Actions and Methods)

UpdateRowDetails

Associated with: DNP3 SCADAPack BOOTP, IP Route, DNP Route Tables, and 32-bit Point Modbus Maps

Security permission required to access this method: Configure

Use this method to update a row in a DNP Route, IP Route, BOOTP table, or 32-bit Point Modbus Map that exists in the ClearSCADA database.

This method is the equivalent of updating the row properties within ViewX (see Configuring DNP3 SCADAPack Tables, or see Configuring DNP3 SCADAPack 32-bit Point Modbus Maps, as applicable).

NOTE: Use the RowCount configuration parameter to specify the table or map size.

The UpdateRowDetails method arguments vary, depending on the type of database item. For further information, see:

  • BOOTP Table Arguments
  • DNP Route Table Arguments
  • IP Route Table Arguments
  • 32-bit Point Modbus Map Arguments.

BOOTP Table Arguments

Use these arguments for updating a row in a BOOTP table (for further information, see Add and Configure the Entries in a BOOTP Table):

  • Row (Byte)—Specify the row number within the table (1 to n).
  • HardwareAddr1 to HardwareAddr6 (Byte)—Use these six arguments to specify the separate parts of the hardware address of the Ethernet device for which the SCADAPack E-Series outstation is to remotely configure an IP address.

Example:

To specify the hardware address 00:1A:2B:3C:4D:5E, enter:

HardwareAddr1 as 00
HardwareAddr2 as 1A
HardwareAddr3 as 2B
and so on.

  • IPAddress (Long)—Specify the required IP address for the Ethernet device.

Example:

For the IP address 192.168.1.97

Convert each octet into its hexadecimal equivalent
192 (dec) = C0 (hex)
168 (dec) = A8 (hex)
1 (dec) = 01 (hex)
97 (dec) = 61 (hex)

Create the hexadecimal long equivalent
C0A80161

Convert to decimal (using ‘Calculator’ for example)
3232235873

DNP Route Table Arguments

When configuring DNP Route Tables, for greatest efficiency enter the most frequently used routes first (one row per route), followed by the less frequently used routes. (The SCADAPack E-Series outstation scans the table entries from top to bottom and stops at the first entry that matches a frame’s destination settings.)

Use these arguments for updating a row in a DNP Route table (for further information and an example of how these arguments might be used, see Route DNP3 Frames Using a DNP Route Table):

  • Row (Byte)—Specify the row number within the table (1 to n).
  • SourcePort (Byte)—Use this argument to specify the port via which the outstation receives in-bound DNP3 frames that are to be re-transmitted to another destination:
  • 0—Port 0
  • 1—Port 1
  • 2—Port 2
  • 3—Port 3
  • 4—Port 4/Diag Port
  • 5—Ethernet Port 1
  • 6—Ethernet Port 2
  • 10—Port 5
  • 11—Port 6
  • 12—Port 7
  • 13—Port 8
  • 254—Any port.
  • SourceStart (Long)—Use in conjunction with the SourceEnd argument to specify the source address range to which this table entry refers. Use this argument to specify the starting range for the source address.
  • SourceEnd (Long)—Use in conjunction with the SourceStart argument to specify the source address range to which this table entry refers. Use this argument to specify the end range for the source address.
  • DestinationStart (Long)—Use in conjunction with the DestinationEnd argument to specify the destination address range to which this table entry refers. Use this argument to specify the starting range for the destination address.
  • DestinationEnd (Long)—Use in conjunction with the DestinationStart argument to specify the destination address range to which this table entry refers. Use this argument to specify the end range for the destination address.
  • DestinationPort (Byte)—Use this argument to specify the port via which the outstation re-transmits the DNP3 frames that match the Source and Destination settings specified for this table entry:
  • 0—Port 0
  • 1—Port 1
  • 2—Port 2
  • 3—Port 3
  • 4—Port 4/Diag Port
  • 5—Ethernet Port 1
  • 6—Ethernet Port 2
  • 9—Hayes Modem Pool
  • 10—Port 5
  • 11—Port 6
  • 12—Port 7
  • 13—Port 8.
  • ConnectTo (String)—Where required, use this argument to specify either the:
  • Hayes Modem telephone number
  • X.25 address for X.29 links
  • IP address for TCP/IP host routes.

to enable the outstation to communicate with the destination DNP3 node. (Specify an empty string where none of the above apply.)

For an IP address, enter the address in the format:

  • x.x.x.x:T for a TCP address
  • x.x.x.x:U for a UDP address.
  • Status (Byte)—Use this argument to specify whether the route is enabled or disabled. For TCP/IP routes, also use the argument to specify whether the outstation automatically updates the ConnectTo number whenever it receives DNP3 frames that match the route entry. For more information on the options listed below, see Add and Configure the Entries in a DNP Route Table.
  • 0—On Static
  • 1—Off Static
  • 2—On Dynamic
  • 3—Off Dynamic
  • 4—On Fixed
  • 5—Off Fixed.
  • SecurityLevel (Byte)—Use this argument to specify whether AGA12-2 security is used to encrypt the DNP3 frames and if so, the AGA12 processing that the outstation undertakes. For more information on the options listed below, see Add and Configure the Entries in a DNP Route Table.
  • 0—None
  • 1—AGA12 Node
  • 2—AGA12 Gateway 1
  • 3—AGA12 Gateway 2
  • 4—AGA12 Gateway 3
  • 5—AGA12 Gateway 4
  • 6—AGA12 Gateway 5.

IP Route Table Arguments

Use these arguments for updating a row in a IP Route table (for further information, see Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host):

  • Row (Byte)—Specify the row number within the table (1 to n).
  • DestinationIPAddress (Long)—Specify the required destination IP address. This address is used in conjunction with the Subnet Mask to identify the required node on a remote subnet. For a table giving information on which IP address to add for each route type, see Use an IP Route Table to Route TCP/IP Packets to Another TCP/IP Host.

Example:

For the Destination IP address 192.168.1.97, you might use the hex value C0A80161.

  • DestinationSubnetMask (Long)—Specify the Subnet mask that is required in conjunction with the IP address to identify the required node on a remote subnet.
  • DestinationPort (Byte)—Use this argument to specify the SCADAPack E-Series outstation Port via which the IP packet is to be forwarded (re-transmitted):
  • 0—Port 0
  • 1—Port 1
  • 2—Port 2
  • 3—Port 3
  • 4—Port 4/Diag Port
  • 5—Ethernet Port 1
  • 6—Ethernet Port 2.
  • GatewayIP (Long)—Specify the IP address of the host that provides the ‘gateway’ to the target host. Specify 0.0.0.0 for non-Gateway routes.

Example:

For the Gateway IP address 192.168.1.97, you might use the hex value C0A80161.

  • Metric (Long)—Specify a number (1 to n) that determines the route priority when multiple paths exist for interconnecting IP hosts. The higher the number, the lower the priority. Specify zero to apply the default metric value for the particular type of route.

32-bit Point Modbus Map Arguments

Use these arguments for updating a row in a DNP3 SCADAPack 32-bit Point Modbus Map:

  • Row (Byte)—Specify the row number within the map. The range is 1 to 254.
  • Point Number (Long)—Specify the DNP3 Point Number of the first point in the block of data that is being mapped. The range is 1 to 65534.
  • Quantity (Long)—Specify the number of DNP3 points that are being mapped to double Modbus registers using this row. The range is 1 to 32767.
  • Point Type (Byte)—Specify whether the row is used to map input points (in which case, specify 3), or output points (in which case, specify 4).

Further Information

Configuring DNP3 SCADAPack 32-bit Point Modbus Maps.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Specific Status Display Attributes

DNP3 SCADAPack Specific Status Display Attributes

This section explains the status attributes that are specific to items on the DNP3 SCADAPack E-Series driver and comprises the following sections:

  • DNP3 SCADAPack Outstation Status Attributes
  • DNP3 SCADAPack Firmware Image Status Attributes
  • DNP3 SCADAPack Security Configuration Status Attributes
  • DNP3 SCADAPack Point Status Attributes
  • DNP3 SCADAPack Pulse Action Status Attributes
  • DNP3 SCADAPack Trend Status Attributes
  • DNP3 SCADAPack Status Information Attributes
  • Alphabetical List of DNP3 SCADAPack Specific Status Display Attributes.

Use this section in conjunction with the DNP3 driver documentation on status display attributes (see DNP3 Specific Status Display Attributes in the ClearSCADA Guide to the DNP3 Driver).


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Outstation Status Attributes (DNP3 SCADAPack Specific Status Display Attributes)

DNP3 SCADAPack Outstation Status Attributes

These status attributes are specific to DNP3 SCADAPack E-Series outstations, other than DNP3 SCADAPack Remote DNP3 Devices:

  • Trend Retrieval Alarm
  • Firmware Upgrade Alarm
  • Security Configuration Download Alarm
  • Downloaded Firmware Image
  • Downloaded Security File
  • Downloaded Security Description
  • Off Scan Alarm
  • On Scan.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Firmware Image Status Attributes (DNP3 SCADAPack Specific Status Display Attributes)

DNP3 SCADAPack Firmware Image Status Attributes

These status attributes are specific to DNP3 SCADAPack Firmware Image items:

  • Description
  • File.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Security Configuration Status Attributes (DNP3 SCADAPack Specific Status Display Attributes)

DNP3 SCADAPack Security Configuration Status Attributes

These status attributes are specific to DNP3 SCADAPack Security Configuration items:

  • Security File
  • Security Description.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Point Status Attributes (DNP3 SCADAPack Specific Status Display Attributes)

DNP3 SCADAPack Point Status Attributes

These status attributes are specific to DNP3 SCADAPack points:

  • Tune Limits Alarm—analog and counter points only
  • Trend Inhibit Alarm
  • On Scan
  • Trending Inhibited
  • Alarm Reporting
  • Profile ID—points that use Profiles
  • Status Point for—binary points configured as 5000 Series I/O Status points.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Pulse Action Status Attributes (DNP3 SCADAPack Specific Status Display Attributes)

DNP3 SCADAPack Pulse Action Status Attributes

These status attributes are specific to DNP3 SCADAPack pulse actions:

  • On Scan
  • Alarm Reporting
  • Profile ID—pulse actions that use Profiles.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Trend Status Attributes (DNP3 SCADAPack Specific Status Display Attributes)

DNP3 SCADAPack Trend Status Attributes

This status attribute is specific to DNP3 SCADAPack Trend items:

  • Source.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Status Information Attributes (DNP3 SCADAPack Specific Status Display Attributes)

DNP3 SCADAPack Status Information Attributes

Many of the status attributes that are displayed for DNP3 SCADAPack Status Information items vary, depending on the type of information that each item is configured to retrieve (see Configuring ClearSCADA to Retrieve DNP3 SCADAPack Status Information).

DNP3 SCADAPack Status Information items that are configured to retrieve System Overview information display a set of status attributes for each of the following items of data:

  • Device Type
  • Device Software Version
  • Device Monitor Version
  • Device Serial Number
  • ISaGRAF App n Name
  • ISaGRAF App n Version
  • ISaGRAF App n Size
  • ISaGRAF App n Start Time
  • ISaGRAF App n Halted.

With each of the above status attributes, related status attributes indicate the:

  • Quality of the data (see <Status Information Item> Quality)
  • Last Update Time of the data (see <Status Information Item> Update Time).

(The ISaGRAF status attributes provide information about any ISaGRAF programs that are loaded into the outstation. The status attributes provide information on the type of program and whether that program is currently running.)

DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information display a set of status attributes for each of the following items of data:

  • Received Bytes
  • Transmitted Bytes
  • Frames Received
  • Frames Transmitted
  • Master Frames Received
  • Link Confirm Timeouts
  • Received CRC Errors
  • Dial In Connects
  • Successful Dial Outs
  • Failed Dial Outs
  • DCD Drop Outs.

With each of the above status attributes, related status attributes indicate the:

  • Quality of the data (see <Status Information Item> Quality)
  • Last Update Time of the data (see <Status Information Item> Update Time).

DNP3 SCADAPack Status Information items that are configured to retrieve SCADAPack ES Remote I/O information display a set of status attributes for each of the following items of data:

  • Device Type
  • Device Software Version
  • Device Monitor Version
  • IO Module Failed
  • Input Power Low
  • Internal Battery Low
  • Calibration Invalid.

With each of the above status attributes, related status attributes indicate the:

  • Quality of the data (see <Status Information Item> Quality)
  • Last Update Time of the data (see <Status Information Item> Update Time).


DNP3 SCADAPack Driver Guide - Alphabetical List of DNP3 SCADAPack Specific Status Display Attributes (DNP3 SCADAPack Specific Status Display Attributes)

Alphabetical List of DNP3 SCADAPack Specific Status Display Attributes

In addition to ‘core’ status attributes, DNP3 SCADAPack extension driver items display both SCADAPack-specific status attributes and DNP3-specific status attributes. For the latter, see DNP3 Specific Status Display Attributes in the ClearSCADA Guide to the DNP3 Driver.

The SCADAPack-specific status attributes comprise:

  • Alarm Reporting
  • Calibration Invalid
  • DCD Drop Outs
  • Description
  • Device Monitor Version
  • Device Serial Number
  • Device Software Version
  • Device Type
  • Dial In Connects
  • Downloaded Firmware Image
  • Downloaded Security Description
  • Downloaded Security File
  • Failed Dial Outs
  • File
  • Firmware Upgrade Alarm
  • Frames Received
  • Frames Transmitted
  • Input Power Low
  • Internal Battery Low
  • IO Module Failed
  • ISaGRAF App n Halted
  • ISaGRAF App n Name
  • ISaGRAF App n Size
  • ISaGRAF App n Start Time
  • ISaGRAF App n Version
  • Link Confirm Timeouts
  • Master Frames Received
  • Off Scan Alarm
  • On Scan
  • Profile ID
  • Received Bytes
  • Received CRC Errors
  • Security Configuration Download Alarm
  • Security Description
  • Security File
  • Source
  • <Status Information Item> Quality
  • <Status Information Item> Update Time
  • Status Point for
  • Successful Dial Outs
  • Transmitted Bytes
  • Trend Inhibit Alarm
  • Trend Retrieval Alarm
  • Trending Inhibited
  • Tune Limits Alarm.


DNP3 SCADAPack Driver Guide - Alarm Reporting (DNP3 SCADAPack Specific Status Display Attributes)

Alarm Reporting

Associated with: DNP3 SCADAPack points and pulse actions

This status attribute indicates whether alarm reporting is currently enabled on a point or pulse action. Alarm reporting is disabled and enabled using the Disable Alarm Reporting and Enable Alarm Reporting pick actions respectively.

Possible states: Enabled, or Disabled.


DNP3 SCADAPack Driver Guide - Calibration Invalid (DNP3 SCADAPack Specific Status Display Attributes)

Calibration Invalid

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve SCADAPack ES Remote I/O information

This status attribute indicates whether the remote module’s I/O calibration parameters are invalid.

Possible states: True, or False.


DNP3 SCADAPack Driver Guide - DCD Drop Outs (DNP3 SCADAPack Specific Status Display Attributes)

DCD Drop Outs

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

Only applies if the port’s Function is set to PPP/TCPIP. (The status attribute’s value remains at zero for any ports that are assigned a different Function.)

This status attribute indicates the number of Data Carrier Detect (DCD) drop outs that have occurred on the port.


DNP3 SCADAPack Driver Guide - Description (DNP3 SCADAPack Specific Status Display Attributes)

Description

Associated with: DNP3 SCADAPack Firmware Image items

This status attribute displays the Description that was entered for the compressed binary firmware image file when it was imported into the ClearSCADA database (see Import Firmware Image).

Use this status attribute in conjunction with the File attribute to ascertain information about the .biz file with which this particular DNP3 SCADAPack Firmware Image item is associated.


DNP3 SCADAPack Driver Guide - Device Monitor Version (DNP3 SCADAPack Specific Status Display Attributes)

Device Monitor Version

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview, or SCADAPack ES Remote I/O information

This status attribute indicates the version of the Boot Monitor firmware that is running in the outstation or remote I/O module.

Example:

215


DNP3 SCADAPack Driver Guide - Device Serial Number (DNP3 SCADAPack Specific Status Display Attributes)

Device Serial Number

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview information

This status attribute applies to SCADAPack ES and ER models only. The attribute displays the serial number of the DNP3 device.

Example:

4125


DNP3 SCADAPack Driver Guide - Device Software Version (DNP3 SCADAPack Specific Status Display Attributes)

Device Software Version

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview, or SCADAPack ES Remote I/O information

This status attribute indicates the version of the firmware that is running in the I/O module.

Example:

7061


DNP3 SCADAPack Driver Guide - Device Type (DNP3 SCADAPack Specific Status Display Attributes)

Device Type

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview, or SCADAPack ES Remote I/O information

There are two Device Type status attributes.

The first status attribute shows the device type number that was returned by the outstation, decoded into a text string.

Example:

Device Type SCADAPack ES Model A (IO:32/16/12/4) , Ethernet

The second status attribute shows the raw number that was returned by the outstation.

Example:

49681


DNP3 SCADAPack Driver Guide - Dial In Connects (DNP3 SCADAPack Specific Status Display Attributes)

Dial In Connects

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of times that the outstation has dialled in successfully using this port.


DNP3 SCADAPack Driver Guide - Downloaded Firmware Image (DNP3 SCADAPack Specific Status Display Attributes)

Downloaded Firmware Image

Associated with: DNP3 SCADAPack E-Series Outstations and DNP3 SCADAPack Remote E-Series Outstations

This status attribute is only displayed if the Download Firmware, or Download Remote Firmware pick actions have been used to successfully download an operating system firmware file to the outstation. (Each firmware file comprises a SCADAPack E-Series .biz file that has been imported into ClearSCADA using a DNP3 Firmware Image database item.)

The status attribute displays:

  • The name of the last .biz file to be downloaded to the outstation.
  • A time stamp showing the last modification date and time of the SCADAPack E-Series .biz file from which the downloaded Firmware Image file was obtained.

For more information, see Using ClearSCADA to Import and Download SCADAPack Outstation Firmware Image Files.

Example:

"761e586.biz" Modified at 22/10/2008 10:38:58.000

(Indicating that the last Firmware Image file to be downloaded to the outstation was the file named ‘761e586.biz’. The SCADAPack E-Series .biz file from which the Firmware Image file was obtained was last modified on the date and time indicated above.)


DNP3 SCADAPack Driver Guide - Downloaded Security Description (DNP3 SCADAPack Specific Status Display Attributes)

Downloaded Security Description

Associated with: DNP3 SCADAPack E-Series Outstations and DNP3 SCADAPack Remote E-Series Outstations that use DNP3 secure authentication

This status attribute is only displayed if the Download Security Configuration pick action has been used to successfully download a security configuration file to the outstation. The security configuration file comprises an .rtk file that has been imported into ClearSCADA.

The Downloaded Security Description status attribute displays the Description that was entered for the .rtk file when it was imported into the ClearSCADA database (see Import Security Configuration).

Use this status attribute in conjunction with the Downloaded Security File attribute to ascertain information about the .rtk file that was last downloaded to the outstation.


DNP3 SCADAPack Driver Guide - Downloaded Security File (DNP3 SCADAPack Specific Status Display Attributes)

Downloaded Security File

Associated with: DNP3 SCADAPack E-Series Outstations and DNP3 SCADAPack Remote E-Series Outstations that use DNP3 secure authentication

This status attribute is only displayed if the Download Security Configuration pick action has been used to successfully download a security configuration file to the outstation. (Each file comprises an .rtk file that has been imported into ClearSCADA using a DNP3 SCADAPack Security Configuration database item.)

The status attribute displays:

  • The name of the last .rtk file to be downloaded to the outstation
  • A time stamp showing the last modification date and time of the file.

Example:

"system.rtk" Modified at 27/04/2010 09:33:37.000

Use this status attribute in conjunction with the Downloaded Security Description attribute to ascertain information about the .rtk file that was last downloaded to the outstation.

For more information, see Import and Download SCADAPack Security Configuration Files.


DNP3 SCADAPack Driver Guide - Failed Dial Outs (DNP3 SCADAPack Specific Status Display Attributes)

Failed Dial Outs

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of times that the outstation has been unsuccessful in its attempts to dial out using this port.

Also see Successful Dial Outs.


DNP3 SCADAPack Driver Guide - File (DNP3 SCADAPack Specific Status Display Attributes)

File

Associated with: DNP3 SCADAPack Firmware Image items

This status attribute displays the name of the compressed binary firmware image file that was last imported into the ClearSCADA database using this particular DNP3 SCADAPack Firmware Image item (see Import Firmware Image). The date and time of the last import process is included.

Use this status attribute in conjunction with the Description attribute to ascertain information about the .biz file with which this particular DNP3 SCADAPack Firmware Image item is associated.

Example:

"\750e386.biz" Modified at Mar/15/2007 15:37:24.000


DNP3 SCADAPack Driver Guide - Firmware Upgrade Alarm (DNP3 SCADAPack Specific Status Display Attributes)

Firmware Upgrade Alarm

Associated with: DNP3 SCADAPack E-Series outstations, other than DNP3 SCADAPack Remote DNP3 Devices

This status attribute indicates whether ClearSCADA’s last attempt to Download Firmware or Download Remote Firmware was unsuccessful.

An existing firmware upgrade alarm is cleared when ClearSCADA next updates the operating system firmware successfully.

Possible States: Displays one of the Standard Alarm States.


DNP3 SCADAPack Driver Guide - Frames Received (DNP3 SCADAPack Specific Status Display Attributes)

Frames Received

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of DNP3 frames that have been received using this port.

Also see Master Frames Received, and see Received CRC Errors.


DNP3 SCADAPack Driver Guide - Frames Transmitted (DNP3 SCADAPack Specific Status Display Attributes)

Frames Transmitted

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of DNP3 frames that have been transmitted using this port.


DNP3 SCADAPack Driver Guide - Input Power Low (DNP3 SCADAPack Specific Status Display Attributes)

Input Power Low

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve SCADAPack ES Remote I/O information

This status attribute indicates whether the power being used to run the remote I/O module is low.

Possible states: True, or False.

Do not confuse this status attribute with the Internal Battery Low attribute.


DNP3 SCADAPack Driver Guide - Internal Battery Low (DNP3 SCADAPack Specific Status Display Attributes)

Internal Battery Low

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve SCADAPack ES Remote I/O information

This status attribute indicates whether the on-board battery’s power is running low.

Possible states: True, or False.

Do not confuse this status attribute with the Input Power Low attribute.


DNP3 SCADAPack Driver Guide - IO Module Failed (DNP3 SCADAPack Specific Status Display Attributes)

IO Module Failed

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve SCADAPack ES Remote I/O information

This status attribute indicates whether this particular remote I/O module has failed. The module’s status is assessed by the outstation with which the I/O module is associated. The outstation then reports the status to ClearSCADA.

Possible states: True, or False.


DNP3 SCADAPack Driver Guide - ISaGRAF App n Halted (DNP3 SCADAPack Specific Status Display Attributes)

ISaGRAF App n Halted

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview information

This status attribute indicates whether the particular ISaGRAF application (1 or 2) is currently halted in the outstation.

Possible states: True, or False.


DNP3 SCADAPack Driver Guide - ISaGRAF App n Name (DNP3 SCADAPack Specific Status Display Attributes)

ISaGRAF App n Name

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview information

This status attribute displays the name that is assigned to the currently loaded ISaGRAF application.

Example:

dropgprs


DNP3 SCADAPack Driver Guide - ISaGRAF App n Size (DNP3 SCADAPack Specific Status Display Attributes)

ISaGRAF App n Size

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview information

This status attribute displays the size of the currently loaded ISaGRAF application.

Example:

1802


DNP3 SCADAPack Driver Guide - ISaGRAF App n Start Time (DNP3 SCADAPack Specific Status Display Attributes)

ISaGRAF App n Start Time

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview information

Two Start Time attributes are displayed for each ISaGRAF application (1 and 2).

The first status attribute indicates the date and time at which the currently loaded ISaGRAF application started to run, decoded into a text string.

Example:

May/08/2009 12:20:07.591

The second status attribute displays the raw number that was returned by the outstation, indicating this start time.


DNP3 SCADAPack Driver Guide - ISaGRAF App n Version (DNP3 SCADAPack Specific Status Display Attributes)

ISaGRAF App n Version

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve System Overview information

This status attribute displays the version number of the currently loaded ISaGRAF application.

Example:

17


DNP3 SCADAPack Driver Guide - Link Confirm Timeouts (DNP3 SCADAPack Specific Status Display Attributes)

Link Confirm Timeouts

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute only apply if the port’s Function is set to DNP3.

The status attribute indicates the number of times that a confirmation was expected, but was not received, for DNP3 data link frames that have been transmitted using this port.


DNP3 SCADAPack Driver Guide - Master Frames Received (DNP3 SCADAPack Specific Status Display Attributes)

Master Frames Received

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of DNP3 Master frames that have been received using this port.

Also see Frames Received.


DNP3 SCADAPack Driver Guide - Off Scan Alarm (DNP3 SCADAPack Specific Status Display Attributes)

Off Scan Alarm

Associated with: DNP3 SCADAPack E-Series outstations, other than DNP3 SCADAPack Remote DNP3 Devices

This status attribute indicates the success, or otherwise, of the last attempt to place an outstation Off Scan.

Possible states: Displays one of the Standard Alarm States.

Also see On Scan.


DNP3 SCADAPack Driver Guide - On Scan (DNP3 SCADAPack Specific Status Display Attributes)

On Scan

Associated with: DNP3 SCADAPack E-Series outstations, other than DNP3 SCADAPack Remote DNP3 Devices; DNP3 SCADAPack points and pulse actions

This status attribute indicates whether an item is currently On Scan (True) or Off Scan (False).

An outstation and/or its points can be placed Off Scan using the Off Scan pick action. An Off Scan outstation can be placed back On Scan using the On Scan pick action. (An Off Scan point or pulse action can only be placed back On Scan independently if the outstation on which that point or pulse action resides is still On Scan.)

With a point or pulse action, an On Scan attribute state of ‘False’ can indicate that either the point/pulse action or the outstation is Off Scan.

With an Off Scan outstation, to ascertain whether that outstation’s points and pulse actions are Off Scan, check the On Scan attribute for some of those points or pulse actions.

Possible states: True, or False.

Also see Off Scan Alarm.


DNP3 SCADAPack Driver Guide - Profile ID (DNP3 SCADAPack Specific Status Display Attributes)

Profile ID

Associated with: DNP3 SCADAPack points and pulse actions with which Profiles are associated

This status attribute is only displayed if a pulse’s action(s), or any of a point’s limits and/or current value are profile-controlled (see Specify Whether any Profiles are Used to Change a Point’s Limits or Current Value). The status attribute is displayed regardless of Profile Type.

The Profile ID status attribute identifies the combination of Profiles that is used by a point or pulse action on a particular outstation. Each DNP3 SCADAPack Outstation can support up to 999 unique combinations of Profiles. ClearSCADA allocates each point’s and pulse action’s Profile ID automatically, based on the combination of Profiles used by that particular point or pulse action and, for DNP3 SCADAPack Counter Points, the point’s Multiplier.

Example:

5


DNP3 SCADAPack Driver Guide - Received Bytes (DNP3 SCADAPack Specific Status Display Attributes)

Received Bytes

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of raw bytes that have been received using this port.


DNP3 SCADAPack Driver Guide - Received CRC Errors (DNP3 SCADAPack Specific Status Display Attributes)

Received CRC Errors

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of frames with Cyclic Redundancy Check (CRC) errors that have been received using this port.


DNP3 SCADAPack Driver Guide - Security Configuration Download Alarm (DNP3 SCADAPack Specific Status Display Attributes)

Security Configuration Download Alarm

Associated with: DNP3 SCADAPack E-Series outstations, other than DNP3 SCADAPack Remote DNP3 Devices

This status attribute indicates whether ClearSCADA’s last attempt to Download Security Configuration to the outstation was unsuccessful.

An existing Security Configuration Download Alarm is cleared when ClearSCADA next downloads a security configuration file successfully.

Possible States: Displays one of the Standard Alarm States.


DNP3 SCADAPack Driver Guide - Security Description (DNP3 SCADAPack Specific Status Display Attributes)

Security Description

Associated with: DNP3 SCADAPack Security Configuration items

This status attribute displays the description that was entered for the security configuration file when it was imported into the ClearSCADA database (see Import Security Configuration).

Use this status attribute in conjunction with the Security File attribute to ascertain information about the security configuration file with which this particular DNP3 SCADAPack Security Configuration item is associated.


DNP3 SCADAPack Driver Guide - Security File (DNP3 SCADAPack Specific Status Display Attributes)

Security File

Associated with: DNP3 SCADAPack Security Configuration items

This status attribute displays the name of the security configuration file that was last imported into ClearSCADA using this particular DNP3 SCADAPack Security Configuration item (see Import Security Configuration). The date and time that the file was last modified is also shown. (To ascertain the date and time that the file was imported into ClearSCADA, see the Events List.)

Use this status attribute in conjunction with the Security Description attribute to ascertain information about the security configuration file with which this particular DNP3 SCADAPack Security Configuration item is associated.

Example:

"system.rtk" Modified at May/06/2010 14:27:00.000


DNP3 SCADAPack Driver Guide - Source (DNP3 SCADAPack Specific Status Display Attributes)

Source

Associated with: Various DNP3 SCADAPack items

The Source status attribute is common to many Status Displays. The attribute indicates the location at which the item resides. The information shown varies, depending on the type of database item.

For DNP3 SCADAPack Trend Analog and Trend Counter items, information is displayed in this format:

Master <DNP3 Local Address>: OS <Address>:<Point Type> Point Number <No.>: <Sample Value Type> Trend

Example:

Master 30000:OS 12:AI Point Number 5: Maximum Value Trend

(For a Trend item that defines how often the outstation samples an analog point’s data to ascertain the maximum value reached during each sampling period. The point for which data is being sampled resides at Point Number 5 in the outstation. The outstation’s address is 1, and it belongs to the outstation set that has a DNP3 Local Address of 30000.)

For DNP3 SCADAPack Trend Binary items, information is displayed in this format:

Master <DNP3 Local Address>: OS <Address>:<Point Type> Point Number <No.> Bits <No.>: <Sample Value Type> Trend

Example:

Master 30000:OS 12:BI Point Number 2 Bits 1:Current Value Trend

(For a Trend item that defines how often the outstation samples a binary point’s current value. The point for which data is being sampled resides at Point Number 2 in the outstation. The outstation’s address is 1, and it belongs to the outstation set that has a DNP3 Local Address of 30000.)

For more information, see Source in the ClearSCADA Guide to the DNP3 Driver.


DNP3 SCADAPack Driver Guide - <Status Information Item> Quality (DNP3 SCADAPack Specific Status Display Attributes)

<Status Information Item> Quality

Associated with: DNP3 SCADAPack Status Information items

A set of status attributes is displayed for each item of status information that ClearSCADA retrieves from a DNP3 SCADAPack E-Series outstation or remote I/O module.

The <Status Information Item> Quality attribute indicates the reliability of a specific item of status information data. <Status Information Item> indicates the item of data to which the attribute refers.

Use the attribute in conjunction with the <Status Information Item> Update Time attribute to ascertain the reliability of that particular item of status information.

For a comprehensive list of possible Quality values, see Quality in the ClearSCADA Guide to Drivers.


DNP3 SCADAPack Driver Guide - <Status Information Item> Update Time (DNP3 SCADAPack Specific Status Display Attributes)

<Status Information Item> Update Time

Associated with: DNP3 SCADAPack Status Information items

A set of status attributes is displayed for each item of status information that ClearSCADA retrieves from a DNP3 SCADAPack E-Series outstation or remote I/O module.

The <Status Information Item> Update Time attribute indicates the date and time that ClearSCADA last retrieved a specific item of status information data. <Status Information Item> indicates the item of data to which the attribute refers.

Use the attribute in conjunction with the <Status Information Item> Quality attribute to ascertain the reliability of that particular item of status information.


DNP3 SCADAPack Driver Guide - Status Point for (DNP3 SCADAPack Specific Status Display Attributes)

Status Point for

Associated with: DNP3 SCADAPack Binary points that are configured as 5000 Series I/O Status points

This status attribute only applies to DNP3 SCADAPack Binary points that are configured as the Status Point on DNP3 SCADAPack 5000 Series IO database items (see Configure the 5000 Series I/O Properties). The Status Point indicates the communications status of the I/O module that the DNP3 SCADAPack 5000 Series IO database item represents.

The Status Point for attribute displays the full name (including the database path) of the DNP3 SCADAPack 5000 Series IO database item for which that binary point is the Status Point.

Example:

Eastern Region.Zone 3.RTU 55 IO Module

(Indicating that the binary point is the Status Point for the DNP3 SCADAPack 5000 Series IO item ‘RTU 55 IO Module’. The 5000 Series IO database item resides in the group ‘Zone 3’, which is itself in the group ‘Eastern Region’.)


DNP3 SCADAPack Driver Guide - Successful Dial Outs (DNP3 SCADAPack Specific Status Display Attributes)

Successful Dial Outs

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of times that the outstation has dialled out successfully via this port.

Also see Failed Dial Outs.


DNP3 SCADAPack Driver Guide - Transmitted Bytes (DNP3 SCADAPack Specific Status Display Attributes)

Transmitted Bytes

Associated with: DNP3 SCADAPack Status Information items that are configured to retrieve Port Status information

This status attribute indicates the number of raw bytes that have been transmitted using this port.


DNP3 SCADAPack Driver Guide - Trend Inhibit Alarm (DNP3 SCADAPack Specific Status Display Attributes)

Trend Inhibit Alarm

Associated with: DNP3 SCADAPack Analog, Binary, and Counter points

The Trend Inhibit Alarm status attribute is associated with ClearSCADA’s attempts to download the configuration that causes the outstation to start or stop sampling the point’s data. ClearSCADA attempts to download such configuration whenever the Enable All Trends or Disable All Trends pick action is triggered. The Trend Inhibit Alarm status attribute indicates whether ClearSCADA’s last attempt to download the configuration was unsuccessful.

Such a download would not succeed, for example, if communications were lost during the download, or an attempt was made to enable or disable DNP3 SCADAPack Trend sampling on a point for which such configuration did not yet exist in the outstation.

Possible states: Displays one of the Standard Alarm States.

Also see Trending Inhibited.


DNP3 SCADAPack Driver Guide - Trend Retrieval Alarm (DNP3 SCADAPack Specific Status Display Attributes)

Trend Retrieval Alarm

Associated with: DNP3 SCADAPack E-Series outstations, other than DNP3 SCADAPack Remote DNP3 Devices

This status attribute is associated with ClearSCADA’s attempts to retrieve stored sampled trend data from the outstation. A request to retrieve such data might be initiated:

  • Automatically, at the Trend Retrieval rate specified on the Outstation Form (see Configure the Trend Retrieval Properties)
  • Manually or automatically, using the Retrieve All Trends pick action.

Possible states: Displays one of the Standard Alarm States.

The Trend Retrieval Alarm status attribute indicates whether ClearSCADA’s last attempt to retrieval sampled trend data was unsuccessful.

An alarm state indicates that the last request to instruct the outstation to create a Trend log, retrieve a Trend log, or delete a Trend log after the file has been read, was unsuccessful. Should an alarm state occur, ensure that there are no problems with communications to the outstation. If large amounts of data regularly need retrieving, or the link to the outstation is slow or heavily utilized, timeouts might occur. If such timeouts occur regularly and are not due to equipment failure, modify the configuration.


DNP3 SCADAPack Driver Guide - Trending Inhibited (DNP3 SCADAPack Specific Status Display Attributes)

Trending Inhibited

Associated with: DNP3 SCADAPack Analog, Binary, and Counter points

This status attribute indicates whether sampling of the point’s data is currently inhibited at the outstation.

Possible states:

  • True (whenever the Disable All Trends pick action or DisableTrending method are used to inhibit Trend sampling)
  • False (whenever Trend sampling is enabled (for instance, through use of the Enable All Trends pick action)).

For more information on Trend sampling, see Configuring DNP3 SCADAPack E-Series Trend Sampler Functionality.


DNP3 SCADAPack Driver Guide - Tune Limits Alarm (DNP3 SCADAPack Specific Status Display Attributes)

Tune Limits Alarm

Associated with: DNP3 SCADAPack Analog points and DNP3 SCADAPack Counter points

The Tune Limits Alarm status attribute is associated with ClearSCADA’s attempts to download the point’s Alarm Limits configuration to the SCADAPack E-Series outstation. ClearSCADA attempts to download such configuration in response to a Tune Alarm Limits pick action request. The status attribute indicates an alarm state if ClearSCADA’s last attempt to download the point’s alarm limits was unsuccessful.

A download would be unsuccessful if, for example, communications were lost during the download, or an attempt was made to tune the limits of a point for which configuration did not yet exist in the outstation.

Possible states: Displays one of the Standard Alarm States.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Specific Colors

DNP3 SCADAPack Specific Colors

Each ClearSCADA system is supplied with a set of default system colors. These colors comprise both ‘core system’ and driver-specific colors. Each color is used to indicate the state of an item in the database. The color is used on various ClearSCADA displays to indicate that the item is in a particular state. This section covers the system colors that are DNP3 SCADAPack specific. These colors are in addition to those that are specific to the DNP3 driver (see DNP3 Specific Colors in the ClearSCADA Guide to the DNP3 Driver).

ClearSCADA uses a DNP3 SCADAPack driver-specific color to indicate this state:

  • Off Scan.

For charts that indicate which states—and therefore which corresponding system colors—take priority over other states, including the above the DNP3 SCADAPack specific state, see System Color Priorities.

NOTE: You can change a default system color by altering its color in the color palette. If you decide to do this, you should ensure that the new color is not identical to, or could be confused with another color on your system. For information on configuring system colors, see Use the Color Palette to Define a Custom System Color in the ClearSCADA Guide to Core Configuration.


DNP3 SCADAPack Driver Guide - Off Scan (DNP3 SCADAPack Specific Colors)

Off Scan

Associated with: DNP3 SCADAPack E-Series outstations and DNP3 SCADAPack Remote E-Series outstations; DNP3 SCADAPack points and pulse actions

The Off Scan status is indicated by an orange-brown foreground color by default.

The color indicates that the item is currently Off Scan.

The ability to place points and outstations ‘Off Scan’ is disabled on most systems by default. (Its permission is typically denied on a per server basis.) If enabled on your system, users with the relevant permissions can use the Off Scan and On Scan pick actions to place an outstation and/or its dependants (such as points and pulse actions) ‘Off Scan’ or back ‘On Scan’.


DNP3 SCADAPack Driver Guide - System Color Priorities (DNP3 SCADAPack Specific Colors)

System Color Priorities

Each system color is assigned a level of importance, depending on the state that it represents. ClearSCADA uses the hierarchy to ascertain the color that it assigns to each database item.

This section comprises charts that indicate which system foreground color takes priority when a DNP SCADAPack outstation or point is in a particular state:

  • Priority of DNP3 SCADAPack Outstation Foreground Colors
  • Priority of DNP3 SCADAPack Point Foreground Colors.

If more than one state applies simultaneously, the higher-priority color takes precedence until that state no longer applies.

For more information on system color priorities, and for charts that indicate the priority of states represented by background colors, see System Color Priorities in the ClearSCADA Guide to Core Configuration.


DNP3 SCADAPack Driver Guide - Priority of DNP3 SCADAPack Outstation Foreground Colors (DNP3 SCADAPack Specific Colors)

Priority of DNP3 SCADAPack Outstation Foreground Colors

This chart indicates which DNP3 SCADAPack E-Series outstation status takes precedence over another, and therefore which system foreground color is assigned to a DNP3 SCADAPack E-Series outstation at any particular time:

As such, if the ability to place SCADAPack E-Series outstations ‘Off Scan’ is enabled on a system on which a SCADAPack E-Series outstation:

  • Has valid configuration
  • Is In Service
  • Has been taken ‘Off Scan’ using the Off Scan pick action

the outstation’s foreground color will be orange-brown to indicate that the outstation is ‘Off Scan’.

Further Information

Alphabetical List of Core System Colors in the ClearSCADA Guide to Core Configuration.


DNP3 SCADAPack Driver Guide - Priority of DNP3 SCADAPack Point Foreground Colors (DNP3 SCADAPack Specific Colors)

Priority of DNP3 SCADAPack Point Foreground Colors

This chart indicates which DNP3 SCADAPack point status takes precedence over another, and therefore which system foreground color is assigned to a DNP3 SCADAPack point at any particular time:

Further Information

‘Off Scan’ system color: see Off Scan.

‘Point Offline’, ‘Point Restarting’, and ‘Comms Lost’ system colors: see Priority of DNP3 Point Foreground Colors in the ClearSCADA Guide to the DNP3 Driver.

Other foreground colors included in the chart: see Alphabetical List of Core System Colors in the ClearSCADA Guide to Core Configuration.


DNP3 SCADAPack Driver Guide - DNP3 SCADAPack Specific Driver Log File Options

DNP3 SCADAPack Specific Driver Log File Options

This section is for system administrators and high-level engineers who need to use diagnostic information to assess the state of the ClearSCADA system. Use this section in conjunction with the DNP3 driver documentation (see System Analysis in the ClearSCADA Guide to the DNP3 Driver).

This section lists those driver logging options that are specific to the DNP3 SCADAPack E-Series driver. To determine which logging options are available, select the DNP3 driver option from the Modules section of the ClearSCADA Server Status Tool, then select the Logging option to display the DNP3 Logging window.

For more information on driver logging, and for information on the DNP3 driver logging options that are available to this DNP3 extension driver, see Driver Logging Options that are Specific to the DNP3 Driver, in the ClearSCADA Guide to the DNP3 Driver.

This driver logging option is specific to the DNP3 SCADAPack E-Series driver:

  • Download Configuration—Logs information relating to downloading files from the ClearSCADA server to SCADAPack E-Series outstations.


IEC 60870-5 Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


IEC 60870-5 Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


IEC 60870-5 Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


IEC 60870-5 Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


IEC 60870-5 Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


IEC 60870-5 Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s IEC 60870-5 driver. The IEC 60870-5 driver enables ClearSCADA to communicate with devices using the IEC 60870-5-101 or IEC 60870-5-104 protocols. For more information about these protocols and for details about the information included in the rest of this guide, see Introduction to the IEC 60870-5 Driver.

NOTE: For information on how to configure ClearSCADA as an IEC 60870-5 Controlled Station (outstation or RTU), see the ClearSCADA Guide to the IEC 60870-5 Slave Driver.


IEC 60870-5 Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring IEC 60870-5 items and features in the ClearSCADA database.

The guide also contains information for:

  • Operators and engineers who use the IEC 60870-5 driver to monitor and control plant
  • Maintenance engineers.


IEC 60870-5 Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


IEC 60870-5 Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Server Status Tool.


IEC 60870-5 Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


IEC 60870-5 Driver Guide - Introduction to the IEC 60870-5 Driver

Introduction to the IEC 60870-5 Driver

The International Electrotechnical Commission (IEC) maintains a series of standards that provide rules for standardizing communications between Controlling Station(s) (SCADA master(s)) and Controlled Stations (including outstations, slaves, and remote terminal units (RTUs)).

IEC 60870-5 is the IEC’s protocol standard for monitoring and controlling geographically widespread processes.

The ClearSCADA IEC 60870-5 driver supports two of the IEC 60870-5 companion standard protocols:

  • IEC 60870-5-101, a protocol for directly-connected serial based communications
  • IEC 60870-5-104, a protocol for TCP/IP communications.

The ClearSCADA IEC 60870-5 driver provides ClearSCADA with the additional functionality that is required to enable the ClearSCADA server to retrieve data from and write to devices, using either of the above protocols.

This guide summarizes the IEC 60870-5 Terminology of which you need to be aware, and provides detailed information on Configuring IEC 60870-5 Devices in ClearSCADA.

It also explains:

  • IEC 60870-5 features that are of interest to operators (see Using IEC 60870-5 Specific Actions).
  • IEC 60870-5 specific aspects that are of interest to system administrators and engineers when investigating the causes of unexpected system behavior (relating to the IEC 60870-5 driver):
  • see IEC 60870-5 Specific Status Display Attributes
  • see System Analysis.

ClearSCADA can use IEC 60870-5 to communicate with a variety of devices, including some that support additional features that are unavailable on other IEC devices. Where ClearSCADA uses an IEC 60870-5 Extension Driver to support these additional features, you can use the guide to the relevant extension driver in conjunction with this guide.

NOTE: This guide explains how to configure ClearSCADA as an IEC 60870-5 Controlling Station (SCADA master). For information on how to configure ClearSCADA as an IEC 60870-5 Controlled Station (outstation or RTU), see the ClearSCADA Guide to the IEC 60870-5 Slave Driver.


IEC 60870-5 Driver Guide - IEC 60870-5 Terminology (Introduction to the IEC 60870-5 Driver)

IEC 60870-5 Terminology

This section summarizes the IEC 60870-5 terms with which you might need to be familiar, in order to configure IEC 60870-5 specific settings in ClearSCADA. These terms include:

  • APDU
  • ASDU
  • Controlled Station
  • Controlling Station
  • IEC 60870-5
  • Information Object
  • IOA.

Further Information

IEC 60870-5-101

IEC 60870-5-104.


IEC 60870-5 Driver Guide - APDU (Introduction to the IEC 60870-5 Driver)

APDU

An Application Protocol Data Unit (APDU) typically comprises an ASDU along with application protocol control information. However, when communicating using the IEC 60870-5-101 or IEC 60870-5-104 protocol, no application protocol control information is required, and therefore the ASDU and APDU are one and the same.


IEC 60870-5 Driver Guide - ASDU (Introduction to the IEC 60870-5 Driver)

ASDU

An Application Service Data Unit (ASDU) is a block of data that is sent from the Controlling Station (ClearSCADA) to an outstation or other device, or vice versa, using the IEC 60870-5 protocol.


IEC 60870-5 Driver Guide - Controlled Station (Introduction to the IEC 60870-5 Driver)

Controlled Station

A Controlled Station is a station such as an outstation, a slave, or a Remote Terminal Unit (RTU) that is monitored and/or controlled by a Controlling Station.

Through the ClearSCADA documentation suite, a controlled station is referred to as an outstation.


IEC 60870-5 Driver Guide - Controlling Station (Introduction to the IEC 60870-5 Driver)

Controlling Station

A Controlling Station is the SCADA master station at which telecontrol of the Controlled Stations (outstations) is performed. On a ClearSCADA system that is running the IEC 60870-5 driver, the ClearSCADA server is the controlling station.

Throughout this guide, the controlling station is referred to as the ClearSCADA server.


IEC 60870-5 Driver Guide - IEC 60870-5 (Introduction to the IEC 60870-5 Driver)

IEC 60870-5

Throughout this guide, any device (for example, an outstation or RTU) with which ClearSCADA communicates using either the IEC 60870-5-101 protocol, or the IEC 60870-5-104 protocol is referred to as an ‘IEC 60870-5 device’.

Similarly, any input or output on such a device is referred to as an ‘IEC 60870-5 point’.

Every IEC 60870-5 device has an interoperability Profile document that describes what functionality is provided. You need access to this document, or need to be aware of which functions each device supports, when configuring IEC 60870-5 items in ClearSCADA. (For more information, see Configuring IEC 60870-5 Devices in ClearSCADA.)


IEC 60870-5 Driver Guide - Information Object (Introduction to the IEC 60870-5 Driver)

Information Object

The IEC 60870-5 protocol uses the term ‘information object’ to refer to an input or output on an outstation or other controlled device.

Throughout the ClearSCADA documentation suite an information object is referred to as a point. The ClearSCADA IEC 60870-5 driver supports a variety of points for retrieving data from, or controlling data on, an outstation. For more information, see Points Used on IEC 60870-5 Outstations.


IEC 60870-5 Driver Guide - IOA (Introduction to the IEC 60870-5 Driver)

IOA

Each input or output on an IEC 60870-5 outstation or other controlled device has an Information Object Address (IOA). This address is used to uniquely identify each item on the device and is transmitted in each ASDU that includes information about that particular input or output.

Where an outstation contains more than one Common Address, IEC 60870-5 Logical outstations are used in ClearSCADA to represent each outstation sector or unit that has a separate Common Address. With such a setup, the outstation’s Common Address and the point’s IOA uniquely identify each Information Object.


IEC 60870-5 Driver Guide - Configuring IEC 60870-5 Devices in ClearSCADA (Introduction to the IEC 60870-5 Driver)

Configuring IEC 60870-5 Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the devices with which ClearSCADA is to communicate using the IEC 60870-5-101 or IEC 60870-5-104 protocols on your system.

To represent any such devices, the IEC 60870-5 Driver has to be installed and running on the ClearSCADA servers on your system.

When you configure IEC 60870-5 items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant IEC 60870-5 devices on your system. Some settings are either fixed (incorporated into the design of the device), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the IEC 60870-5 devices on your system before you can configure the IEC 60870-5 database items successfully.

Each IEC 60870-5 device, including ClearSCADA, has an interoperability Profile document that describes what functionality is provided. For each device with which you want ClearSCADA to communicate using the IEC 60870-5-101 or IEC 60870-5-104 protocol, refer to that device’s interoperability Profile document to compare the supported features of that device against the IEC features that ClearSCADA supports (and that are listed as such in ClearSCADA’s interoperability Profile document). You also need to be aware of the address settings and any options that are set on your devices. You can then refer to this ClearSCADA Guide to the IEC 60870-5 Driver for information on how to configure those features and options in ClearSCADA.

You also need to be aware of which optional features are required for each IEC 60870-5 item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with IEC 60870-5 database items, including Lists, Actions, and Mimics. For actions that are specific to the IEC 60870-5 driver, see Using IEC 60870-5 Specific Actions. For further information on actions and details on Lists and Mimics, see the core documentation.

For each device with which ClearSCADA is to communicate using the IEC 60870-5-101 or IEC 60870-5-104 protocol, you need to configure:

  1. An IEC 60870-5 Channel to represent each communication connection between an IEC 60870-5 outstation and the ClearSCADA server (see Configuring an IEC 60870-5 Channel).

For devices with which ClearSCADA communicates using the IEC 60870-5-101 serial based protocol, you need to configure one channel per serial connection.

For devices with which ClearSCADA communicates using the IEC 60870-5-104 internet communications protocol, configure one channel for each network-connected IEC 60870-5 device.

  2. An IEC 60870-5 Outstation Set to define each group of outstations that share the same channel (see Configuring an IEC 60870-5 Outstation Set).
  3. An IEC 60870-5 Direct Outstation to represent each unit (for example, an outstation or RTU) that monitors data and controls plant and with which ClearSCADA communicates directly (see Configuring an IEC 60870-5 Outstation).
  4. If required, an IEC 60870-5 Logical Outstation to represent each additional common address within an IEC 60870-5 Direct Outstation. An outstation might have multiple common addresses that are used to either:
  • Separate the points on the outstation into sectors that a Controlling Station (such as ClearSCADA) can read independently from other sectors.

or:

  • Represent multiple units from which the outstation itself is retrieving data.

For more information, see Configuring an IEC 60870-5 Outstation.

  5. An IEC 60870-5 Point to represent each analog or digital measuring instrument or control device that is connected to each IEC 60870-5 Direct outstation and each IEC 60870-5 Logical outstation (see Points Used on IEC 60870-5 Outstations).

To minimize the time that it takes to configure the required IEC 60870-5 items, you may want to configure them in the order listed above, as set configuration requires you to specify a channel, and outstation configuration requires you to specify a set, and so on.

ClearSCADA provides additional support for some devices, using an IEC 60870-5 Extension Driver. For information on configuring such devices, see the relevant IEC 60870-5 extension driver guide.


IEC 60870-5 Driver Guide - Configuring an IEC 60870-5 Channel

Configuring an IEC 60870-5 Channel

NOTE: In addition to the channel mentioned below, ClearSCADA can support other types of IEC 60870-5 channel, using an IEC 60870-5 Extension Driver. For information on any IEC 60870-5 channels not listed below, see the relevant IEC 60870-5 extension driver guide.

ClearSCADA can communicate with IEC 60870-5 devices using either of two IEC 60870-5 protocols (see Supported IEC 60870-5 Communication Protocols).

For either communications protocol, you need to configure one or more IEC 60870-5 Direct Channel(s) in the ClearSCADA database. You configure the properties of each channel using the fields on the IEC 60870-5 Direct Channel Form.

The Form has several tabs.

Use the fields on the IEC 60870-5 tab to:

  • Specify the IEC 60870-5 Communications Protocol.

then either Configure IEC 60870-5-101 Protocol Properties, or Configure IEC 60870-5-104 Protocol Properties, depending on the chosen protocol.

Use the fields on the Scan Parameters tab to:

  • Configure the Scan Parameters—see Defining Scan Parameter Settings for a Channel in the ClearSCADA Guide to Advanced Drivers
  • Specify when Communication Statistics are Updated—see Defining the Communication Statistics Update Rate in the ClearSCADA Guide to Advanced Drivers
  • Specify when ClearSCADA Sets the Clocks of the Outstations that Communicate using this Channel—see Define when the Server Sets the Outstations’ Clocks in the ClearSCADA Guide to Advanced Drivers.

(You specify whether ClearSCADA is to set an outstation’s clock, on a per-outstation basis (see Specify the Operations Performed on Communications Establishment).)

  • Specify any Pre- or Post-Amble Settings (see Defining any Default Pre- and Post-Amble Message Settings for a Channel in the ClearSCADA Guide to Advanced Drivers).

ATTENTION: The IEC 60870-5-101 protocol uses the hexadecimal digits 68 or 10 to indicate the start of a message (or hexadecimal E5 if the system uses single character acknowledgments). We advise only using hexadecimal 68, 10, or E5 as a Pre-Amble where such a character is required by the transmission system and is not seen by the receiving device. The hexadecimal digits 68, 10, or E5 should not be used for Pre- or Post-Amble ‘padding’.

NOTE: The Scan Groups fields and the second set of Scan Parameters fields defined by the ClearSCADA advanced driver model are not used by the ClearSCADA IEC 60870-5 driver. Any configuration in these fields is ignored by ClearSCADA.

For information on configuring the fields on the Connection tab, see IEC 60870-5-101, or see IEC 60870-5-104, as appropriate.

The fields on the other tabs are common to channels on many advanced drivers—for information, see Tabs on Channel Forms in the ClearSCADA Guide to Advanced Drivers.


IEC 60870-5 Driver Guide - Supported IEC 60870-5 Communication Protocols (Configuring an IEC 60870-5 Channel)

Supported IEC 60870-5 Communication Protocols

The ClearSCADA IEC 60870-5 driver supports the following IEC 60870-5 communication protocols:

  • IEC 60870-5-101
  • IEC 60870-5-104.


IEC 60870-5 Driver Guide - IEC 60870-5-101 (Configuring an IEC 60870-5 Channel)

IEC 60870-5-101

The IEC 60870-5-101 protocol is a serial based communications protocol. The protocol is designed to be used on systems where there are permanent direct connections between the Controlling Station (ClearSCADA) and the Controlled Station(s) (outstations or slaves).

Communications can be either:

  • Balanced—whereby there is a one-to-one full duplex connection between a channel and a single outstation
  • Unbalanced—whereby there is a half-duplex connection between a channel and one or more outstations (for instance, in a multidrop setup).

For more information on either of the above transmission procedures, see Configure IEC 60870-5-101 Protocol Properties.

When communicating using the IEC 60870-5-101 protocol, a channel will typically have a Serial Connection Type (specified on the Connection tab of the IEC 60870-5 Direct Channel Form) and use these settings:

  • Data Bits—Should be set to 8 bits.
  • Parity—Should be Even, to comply with the IEC 60870-5 standard.

If no parity is used (for instance, if the communications media does not support parity), be aware that this increases the likelihood of an error going undetected.

  • Flow Control—Generally specify None to comply fully with the IEC 60870-5 standard. However, be aware that some form of Flow Control may be required by transmission media that is not fully compatible with the IEC 60870-5 standard.

(Specify a different Connection Type if the serial interface is not directly connected to ClearSCADA—for more information, see Configure a Channel’s Connection Type in the ClearSCADA Guide to Drivers.)

You also need to Configure IEC 60870-5-101 Protocol Properties on the IEC 60870-5 tab.


IEC 60870-5 Driver Guide - IEC 60870-5-104 (Configuring an IEC 60870-5 Channel)

IEC 60870-5-104

The IEC 60870-5-104 protocol can be used to provide TCP/IP communication between a Controlling Station (ClearSCADA) and Controlled Station(s) (outstations or slaves). Stations that are IEC 60870-5-104 compliant have an Internet Transport Interface between the Application and lower layers.

In order for ClearSCADA to communicate using the IEC 60870-5-104 protocol, specify these settings on the Connection tab of the IEC 60870-5 Direct Channel Form:

  • Connection Type: Network
  • TCP/IP Type: TCP
  • Listen Port: Disabled.

and then Configure IEC 60870-5-104 Protocol Properties on the IEC 60870-5 tab.

For more information on Network communications, see Configure a Channel’s Network Connection Properties in the ClearSCADA Guide to Drivers.


IEC 60870-5 Driver Guide - Specify the IEC 60870-5 Communications Protocol (Configuring an IEC 60870-5 Channel)

Specify the IEC 60870-5 Communications Protocol

Use the Protocol Type field at the top of the IEC 60870-5 tab to specify which communications protocol is used by the channel:

Choose from:

  • IEC 60870-5-101 —The channel is used for serial communications.

If you select this option, you also need to Configure IEC 60870-5-101 Protocol Properties for the channel.

  • IEC 60870-5-104 —The channel is used for TCP/IP communications.

If you select this option, you also need to Configure IEC 60870-5-104 Protocol Properties for the channel.


IEC 60870-5 Driver Guide - Configure IEC 60870-5-101 Protocol Properties (Configuring an IEC 60870-5 Channel)

Configure IEC 60870-5-101 Protocol Properties

When a Channel is configured to use an IEC 60870-5-101 Protocol Type (see Specify the IEC 60870-5 Communications Protocol), you need to configure these properties on the IEC 60870-5 tab. The settings you specify for these properties need to match the correlating settings of the outstation(s) that use this channel.

  • Link Address Size—Use the combo box to specify the number of octets that are used to transmit the link address in each Application Service Data Unit (ASDU).

If the Transmission Procedure is Unbalanced, you need to specify the Link Address Size that corresponds to the size of the Link Address that is used by the outstation. Specify 1 Octet or 2 Octets, as appropriate. (You specify each outstation’s Link Address using the Link Address field on each Direct Outstation Form (see Specify the IEC 60870-5-101 Parameters).)

The Link Address is optional if the Transmission Procedure is Balanced (see below) as the address is not needed to identify the outstation. Therefore, with a Balanced transmission you can optionally specify 0 Octets.

  • Allow Single Character Acknowledgment—The IEC 60870-5-101 protocol defines two types of message that can be transmitted to acknowledge the receipt of a transmission.

One acknowledgment message is a single-byte response. This is the most efficient type of response, although it may be received spuriously if there is electromagnetic noise on the line. Select the Allow Single Character Acknowledgment check box if electromagnetic noise is not a problem, or if the outstation only sends single character acknowledgments. If the Transmission Procedure is Balanced, and an acknowledgment is requested, ClearSCADA will respond by sending a single-byte message to the outstation, in response to each data packet that it receives successfully.

The other type of acknowledgment message is a response that contains between four and six bytes (depending on the Link Address Size). This response is less efficient, but is appropriate for use on channels that are operating in an environment that is affected by electromagnetic noise. Clear the Allow Single Character Acknowledgment check box if the outstation is to send four- to six-byte acknowledgment messages in response to each request that it receives successfully from ClearSCADA (and vice versa if the Transmission Procedure is Balanced and ClearSCADA receives a request to send an acknowledgment). For an outstation to receive such messages successfully, the outstation has to be able to send long acknowledgment messages.

Regardless of the Transmission Procedure used, any message containing an ASDU that ClearSCADA sends to an outstation will require that outstation to send an acknowledgment of the type specified here. If the Transmission Procedure is Unbalanced (see below), ClearSCADA will not send any acknowledgment messages. If the Transmission Procedure is Balanced, an outstation response containing an ASDU might request that ClearSCADA sends an acknowledgment.

  • Transmission Procedure—Use to specify the transmission procedure that applies to the channel. Select the option that applies to your system setup:
  • Unbalanced—ClearSCADA controls the data traffic on this channel by scanning the channel’s outstations sequentially. The ClearSCADA server initiates transmissions via the channel. None of the outstations on the channel can initiate transmissions—instead, they can transmit data only in response to a poll from the server.
  • Balanced—The channel is used for point-to-point communications, whereby ClearSCADA uses the channel to communicate with a single outstation. With a Balanced transmission procedure, the outstation can initiate communications with ClearSCADA.
  • Test Link Interval—Only applies if the Transmission Procedure is Balanced. With a Balanced transmission, there may be long periods of time during which no data is transmitted. ClearSCADA can transmit a test frame at specified intervals, to determine whether the channel is still available. Whenever ClearSCADA sends a test frame, it expects a response from the outstation to indicate that communications are still healthy. If no response is received from the outstation, the outstation is deemed to have failed.

Use the Test Link Interval to specify the maximum amount of time, in seconds, that the Link Layer can remain idle, before ClearSCADA sends a test link frame to the outstation.

Specify 0 if ClearSCADA is not to send any test link frames via this channel.


IEC 60870-5 Driver Guide - Configure IEC 60870-5-104 Protocol Properties (Configuring an IEC 60870-5 Channel)

Configure IEC 60870-5-104 Protocol Properties

When a Channel is configured to use an IEC 60870-5-104 Protocol Type (see Specify the IEC 60870-5 Communications Protocol), you need to configure these properties on the IEC 60870-5 tab. The settings that you specify for these properties need to match the correlating settings of the outstation(s) that use this channel.

  • APDU Timeout (t1)—Use to specify the maximum amount of time, in seconds, that ClearSCADA waits for a transmitted Application Protocol Data Unit (APDU) to be confirmed as received by an outstation. If ClearSCADA does not receive confirmation by the specified time, it will fail the outstation.
  • APDU Acknowledge Timeout (t2)—Use to specify the maximum amount of time that ClearSCADA can remain idle after receiving an APDU, before ClearSCADA has to send a response to the outstation to indicate that it has received the APDU successfully.
  • Idle Timeout (t3)—If there are expected to be long periods of time during which no data is transmitted via this channel, ClearSCADA can transmit a test frame at specified intervals via the channel, to determine whether the channel is still available. Whenever ClearSCADA sends a test frame, it expects a response from the outstation to indicate that communications are still healthy.

Use the Idle Timeout field to specify the maximum amount of time, in seconds, that the Link Layer can remain idle, before ClearSCADA sends a test link frame to an outstation on this channel.

  • Maximum Transmitted APDUs (k)—Specify the maximum number of unconfirmed APDUs that ClearSCADA is to transmit via this channel, before it waits for acknowledgment from the outstation that those APDUs have been received successfully.
  • Maximum Received APDUs (w)—Specify the maximum number of APDUs that ClearSCADA can receive on this channel, before it sends confirmation that it has received those APDUs successfully.


IEC 60870-5 Driver Guide - Configuring an IEC 60870-5 Outstation Set

Configuring an IEC 60870-5 Outstation Set

NOTE: In addition to the outstation set mentioned below, ClearSCADA can support other types of IEC 60870-5 outstation set, using an IEC 60870-5 Extension Driver. For information on any IEC 60870-5 outstation sets not listed below, see the relevant IEC 60870-5 extension driver guide.

For outstations that communicate with the server using the IEC 60870-5-101 protocol, you need to configure one IEC 60870-5 Direct Outstation Set for each group of outstations that communicate via a particular channel.

For outstations that communicate with the server using the IEC 60870-5-104 protocol, you need to configure one IEC 60870-5 Direct Outstation Set per outstation.

Configure each set using the fields on the IEC 60870-5 Direct Outstation Set Form (see Configuring an Outstation Set in the ClearSCADA Guide to Advanced Drivers).

There are no driver-specific properties for IEC 60870-5 Direct Outstation Sets.


IEC 60870-5 Driver Guide - Configuring an IEC 60870-5 Outstation

Configuring an IEC 60870-5 Outstation

NOTE: In addition to the outstations listed below, ClearSCADA can support other types of IEC 60870-5 outstation, using an IEC 60870-5 Extension Driver. For information on any IEC 60870-5 outstations not listed below, see the relevant IEC 60870-5 extension driver guide.

The IEC 60870-5 driver supports these types of outstation:

  • IEC 60870-5 Direct Outstation—An outstation that is permanently connected to the ClearSCADA server via, for example, a cable, network, or a continuous radio signal.

An IEC 60870-5 Direct Outstation has one Common Address, which ClearSCADA uses when it interrogates the outstation for data.

An IEC 60870-5 Direct Outstation can be independent, or can be a ‘parent’ outstation for one or more IEC 60870-5 Logical Outstations (see below). When an IEC 60870-5 Direct Outstation is a ‘parent’ outstation, ClearSCADA can issue a station interrogation command to interrogate both the ‘parent’ and associated Logical outstations simultaneously. However, when requesting point data, ClearSCADA interrogates each Logical outstation individually.

  • IEC 60870-5 Logical Outstation—An IEC 60870-5 Logical Outstation represents a separate physical device or logical sector that is associated with an IEC 60870-5 Direct Outstation. Each IEC 60870-5 Logical Outstation has its own Common Address.

You need to configure one or more IEC 60870-5 Logical Outstations in ClearSCADA if the IEC 60870-5 Direct Outstation with which ClearSCADA communicates has more than one Common Address. You need to configure one IEC 60870-5 Logical Outstation for each additional Common Address that exists on the Direct outstation.

A device may have more than one Common Address to either:

  • Separate the points on the outstation into sectors that a Controlling Station (such as ClearSCADA) can read independently from other sectors.

or:

  • Represent multiple units from which the outstation itself retrieves data.

You use the Parent Outstation field on the Logical Outstation Form’s Remote tab to Specify a Logical Outstation’s Parent Outstation. The ‘parent’ outstation has to be an IEC 60870-5 Direct Outstation.

For each IEC 60870-5 outstation on your system, you need to configure an IEC 60870-5 Direct Outstation or IEC 60870-5 Logical Outstation (see above) in the ClearSCADA database.

You configure the properties of each outstation using the fields on the appropriate IEC 60870-5 Outstation Form.

Each Form has several tabs. This section explains the properties on the IEC 60870-5 tab on each Form, and the Remote tab on the IEC 60870-5 Logical Outstation Form.

For information on the other tabs, see Tabs on Outstation Forms in the ClearSCADA Guide to Advanced Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional IEC 60870-5 outstation in ClearSCADA, see Minimum Configuration.

With an IEC 60870-5 Direct Outstation, use the IEC 60870-5 tab to:

  • Configure the Common Address
  • Specify whether Scanning of the Outstation is Promoted while its Points are on Display (see Define Whether an Outstation is Promoted While its Points are on Display in the ClearSCADA Guide to Advanced Drivers)
  • Configure the Station and Group Interrogation Intervals
  • Configure the Counter Interrogation Intervals
  • Specify the Operations Performed on Communications Establishment
  • Specify any Local Pre- or Post-Amble Settings (see Define any Pre- and Post-Ambles for an Individual Outstation in the ClearSCADA Guide to Advanced Drivers).

For outstations that communicate using the IEC 60870-5-101 protocol, also use the tab to:

  • Specify the IEC 60870-5-101 Parameters.

With an IEC 60870-5 Logical Outstation, use the IEC 60870-5 tab to:

  • Configure the Common Address
  • Configure the Station and Group Interrogation Intervals
  • Configure the Counter Interrogation Intervals
  • Specify the Operations Performed on Communications Establishment.

The Form for an IEC 60870-5 Logical Outstation also has a Remote tab—use this tab to Specify a Logical Outstation’s Parent Outstation.


IEC 60870-5 Driver Guide - Minimum Configuration (Configuring an IEC 60870-5 Outstation)

Minimum Configuration

For an IEC 60870-5 Direct Outstation to become functional (online), you need to configure these properties:

  • Specify the Outstation Set (Outstation tab)
  • Specify the outstation’s Common Address (IEC 60870-5 tab)
  • Specify the outstation’s Link Address (IEC 60870-5 tab)
  • For each outstation that communicates using the IEC 60870-5-104 protocol, or is network-connected to ClearSCADA, you need to specify the Host Address(es) and Port(s) on the Network tab.

(Port number 2404 is the TCP port that is registered for IEC 60870-5-104 use with the IANA (Internet Assigned Numbers Authority).)

These are the minimum requirements for configuring a functional IEC 60870-5 direct outstation.

For an IEC 60870-5 Logical Outstation to become functional (online), you need to configure these properties:

  • Specify the Outstation Set (Outstation tab)
  • Specify the Logical outstation’s Parent outstation (Remote tab)
  • Specify the outstation’s Common Address (IEC 60870-5 tab).

These are the minimum requirements for configuring a functional IEC 60870-5 logical outstation.

With either type of outstation, you also need to put the outstation In Service and save the configuration. This will result in a functional IEC 60870-5 outstation that uses the default configuration settings.


IEC 60870-5 Driver Guide - Configure the Common Address (Configuring an IEC 60870-5 Outstation)

Configure the Common Address

Use the Common Address field at the top of the IEC 60870-5 tab to specify an outstation’s common address. (If an outstation has more than one Common Address, you need to configure one IEC 60870-5 Logical Outstation to represent each physical device or logical division that has a separate Common Address—see Configuring an IEC 60870-5 Outstation.)

For outstations that communicate using the IEC 60870-5-101 protocol, the address range varies, depending on the Common Address Size (see Specify the IEC 60870-5-101 Parameters):

  • If the Common Address Size is 1 Octet, you can specify a Common Address in the range 0 to 254 inclusive.
  • If the Common Address Size is 2 Octets, you can specify a Common Address in the range 0 to 65534 inclusive.

Outstations that communicate using the IEC 60870-5-104 protocol have a Common Address Size of 2 Octets, and an address range of 0 to 65534 inclusive.

Where an IEC 60870-5 Direct Outstation is configured as the ‘parent’ of one or more IEC 60870-5 Logical outstations, both the parent and its Logical outstations need to have unique Common Addresses.

With Direct outstations that communicate using the IEC 60870-5-101 protocol, each outstation’s Link Address is used in conjunction with its Common Address to identify the outstation.


IEC 60870-5 Driver Guide - Specify the IEC 60870-5-101 Parameters (Configuring an IEC 60870-5 Outstation)

Specify the IEC 60870-5-101 Parameters

The fields within the IEC 60870-5-101 Parameters section of the IEC 60870-5 tab apply to IEC 60870-5 Direct Outstations that communicate with ClearSCADA using the IEC 60870-5-101 protocol. (To communicate with ClearSCADA using the IEC 60870-5-101 protocol, the channel through which the outstation communicates has to be configured to use the IEC 60870-5-101 Protocol Type.)

Use the fields within the IEC 60870-5-101 Parameters section of the IEC 60870-5 tab to configure the protocol properties that are specific to that outstation. The settings that you specify for these properties must match the correlating settings in the actual outstation.

  • Link Address—Use to define the Link address of the outstation. The valid range varies, depending on the channel’s Link Address Size (see Configure IEC 60870-5-101 Protocol Properties).

If the Link Address Size is 1 Octet, the valid Link Address range is 0 to 254 inclusive.

If the Link Address Size is 2 Octets, the valid Link Address range is 0 to 65534 inclusive.

The Link Address is optional if the outstation is on a channel that uses a Balanced Transmission Procedure (see Configure IEC 60870-5-101 Protocol Properties). ClearSCADA ignores any configuration in the outstation’s Link Address field if the channel’s Link Address Size is set to 0 Octets.

  • Cause of Transmission Size—Each Application Service Data Unit (ASDU) includes an indication as to the ‘cause’ of the transmission. An ASDU might be transmitted, for example, as a result of a Control request, or due to periodic scanning of the outstation. Use the Cause of Transmission Size combo box to specify whether the cause is transmitted as 1 Octet, or 2 Octets.

(An outstation that communicates using the IEC 60870-5-104 protocol uses 2 octets to indicate the cause of a transmission.)

  • Common Address Size—The Common Address is used to identify the outstation on which each item of point data is located (see Configure the Common Address). The Common Address is transmitted in each ASDU. Use the Common Address Size combo box to specify whether the Common Address is transmitted as 1 Octet, or 2 Octets. (The valid range for the Common Address varies, depending on the Common Address Size—see Configure the Common Address.)
  • Information Object Address Size—Each input and output on an outstation has an Information Object Address (see Configure Common IEC 60870-5 Point Properties). The address is used to uniquely identify each item on the outstation and is transmitted in each ASDU that includes information about that particular input or output. Use the Information Object Address Size combo box to specify whether this address is transmitted as 1 Octet, 2 Octets, or 3 Octets. (The valid Information Object Address range varies depending on the number of octets—see Configure Common IEC 60870-5 Point Properties.)

(An outstation that communicates using the IEC 60870-5-104 protocol has an Information Object Address Size of 3 octets.)

  • Maximum Frame Length—The IEC 60870-5 protocol allows frames of up to 255 bytes. However, the size of frames that an outstation can receive may be restricted to frames that are smaller than this size. Such a restriction may apply if:
  • The communications link has a high bit error rate—in which case you may want to consider reducing the frame size, in order to increase the likely hood of data packets being sent without errors.
  • The outstation can only receive frames that are smaller than 255 bytes—each IEC 60870-5 device has an interoperability Profile document that describes what functionality is provided. Check what maximum frame length is specified for frames that are being sent in the control direction (that is, to the outstation).

Use the Maximum Frame Length field to specify the maximum length of frames that ClearSCADA sends to the outstation.

(The IEC 60870-5-104 protocol defines a fixed Maximum Frame Length of 255 bytes.)


IEC 60870-5 Driver Guide - Configure the Station and Group Interrogation Intervals (Configuring an IEC 60870-5 Outstation)

Configure the Station and Group Interrogation Intervals

The IEC 60870-5 driver supports regular interrogation of outstations for current point data. If supported by an outstation, ClearSCADA is able to interrogate that outstation for current point data on a per group basis, for up to a maximum of 16 interrogation groups.

Each IEC 60870-5 device has an interoperability Profile document that describes what functionality is provided. Refer to the document for information on whether an outstation supports group interrogation, and if so, how many interrogation groups are supported. Refer to the outstation product documentation for information on how to assign the points on the outstation to an interrogation group.

In ViewX, you can specify how often ClearSCADA will scan the outstation for:

  • The current data of every point on the outstation
  • Each interrogation group that is used by the outstation

To do this, you need to use the fields in the Interrogation Intervals section on the IEC 60870-5 Outstation Form’s IEC 60870-5 tab.

In each instance, use the Interval field to specify how often ClearSCADA scans the outstation for the relevant current point data. Use the Offset field to specify the synchronization offset—the amount of time that occurs from midnight before ClearSCADA first scans the outstation for that group’s current point data. Specify both the Interval and the Offset in the OPC Time Format.

  • Station Interrogation—ClearSCADA can be configured to scan an outstation for all of its current point data whenever communications are established with that outstation (see Specify the Operations Performed on Communications Establishment). Additionally, you can use the Station Interrogation Interval and Offset fields to specify whether ClearSCADA is to retrieve all of an outstation’s current point data on a regular basis.

Specify an Interval and Offset of 0 if ClearSCADA is only to scan an outstation for all of its current point data on establishing communications with that outstation.

  • Group n Interrogation—If an outstation supports Group Interrogation polls, you can use the Group 1 Interrogation to Group 16 Interrogation Interval and Offset fields to specify when ClearSCADA is to retrieve the current data of the points that are assigned to those groups. Points are assigned to an interrogation group at the outstation. Be aware that some outstations may support fewer than 16 interrogation groups.

Specify 0 for both the Interval and Offset of those groups that are not supported or not used on an outstation.

Example:

Group 1 Interrogation for a particular outstation has this configuration:

Interval: 15M
Offset: 5M

This results in ClearSCADA first scanning the outstation for Group 1 current point data at 00:05:00.000 and then at 15-minute intervals thereafter.

In addition to the above, you can specify whether ClearSCADA is to interrogate an outstation for current point data as soon as it establishes communications with that outstation (see Specify the Operations Performed on Communications Establishment).


IEC 60870-5 Driver Guide - Counter Operation Modes and Interrogation Requests (Configuring an IEC 60870-5 Outstation)

Counter Operation Modes and Interrogation Requests

Counters on outstations that communicate using the IEC 60870-5 protocol are periodically ‘frozen’ at the outstation, either automatically (‘spontaneously’) by the outstation, or in response to a request from the SCADA master (for instance ClearSCADA).

The outstations transmit the frozen counter values to the master, either automatically and/or in response to a request for those values. (A request for a counter value in between ‘freezes’ results in the server being sent the last frozen value for that counter.)

Frozen counter values can be reset at the outstation automatically and/or upon request, or the counter values can continue to increment in order to provide, for instance, a total runtime value.

The counter activity at each outstation depends on what counter operation modes that outstation supports and uses, and what functionality is configured in the master (ClearSCADA).

You need to refer to the outstation’s interoperability Profile document to ascertain which counter operation modes a particular outstation supports. You also need to be aware of what counter functions are set at the outstation. Within ClearSCADA, you then need to specify the counter interrogation requests that ClearSCADA is to perform—the properties for these requests are displayed within Counter Interrogation Intervals section of the Outstation Form (see Configure the Counter Interrogation Intervals).

The Counter Interrogation Intervals section includes check boxes that allow you to define whether ClearSCADA is to send messages to the outstation in order to:

  • Request the latest frozen counter values from the outstation
  • Freeze the counter values at the outstation
  • Reset the counter values at the outstation.

You need to select those check boxes for which ClearSCADA is to send requests to the outstation. Leave the check boxes clear for those functions for which the outstation is set to perform automatically, or which are not required.

Use the corresponding Interval and Offset fields to define when ClearSCADA sends the selected request(s) to the outstation (see Configure the Counter Interrogation Intervals).

If an outstation performs any counter interrogation activities automatically, you need to be aware of when the outstation performs those activities. You can then use this information to determine whether ClearSCADA’s Intervals and Offsets are set appropriately (for any counter requests that ClearSCADA sends to that outstation). For instance, an outstation might support automatic freezing and/or resetting of counter values, but might only transmit the frozen values to ClearSCADA on request. You would therefore need to be aware of when the outstation freezes and/or resets those values, so that you can specify appropriate counter Request intervals within ClearSCADA.

Use the information in the table below to help you decide which counter interrogation requests ClearSCADA needs to send to an outstation. The Mode column lists the various counter operation modes that might be supported by an outstation (as indicated in each outstation’s interoperability Profile document). The Request, Freeze, and Reset columns indicate which check boxes are selected in ClearSCADA (Yes) and which are clear (---).

ClearSCADA performs the selected activities at the times and frequency specified by the corresponding Interval and Offset fields (see Configure the Counter Interrogation Intervals).

Mode | Request | Freeze | Reset | Description
A—Local Freeze with Spontaneous Transmission | --- | --- | --- | The outstation performs the required counter operations automatically. No counter operation activity is triggered by ClearSCADA.
 | --- | --- | Yes | The outstation automatically freezes its counters and transmits those frozen counter values to ClearSCADA. ClearSCADA periodically sends requests to the outstation to reset the counter values.
B—Local Freeze with Counter Interrogation | Yes | --- | --- | The outstation freezes its counter values automatically. ClearSCADA periodically sends a request for frozen counter values to the outstation.
 | Yes | --- | Yes | The outstation freezes its counter values automatically. ClearSCADA periodically requests that the outstation resets it counters and sends the frozen counter values to ClearSCADA.
C—Freeze and Transmit by Counter Interrogation Commands | Yes | Yes | --- | The outstation only performs counter operations upon request from its master. ClearSCADA periodically requests that the outstation freezes its counter values and then transmits those frozen values to ClearSCADA.
 | Yes | Yes | Yes | The outstation only performs counter operations upon request from its master. ClearSCADA periodically requests that the outstation freezes and resets its counter values, and then transmits those frozen values to ClearSCADA.
D—Freeze by Counter Interrogation Command, Frozen Values Reported Spontaneously | --- | Yes | --- | ClearSCADA periodically requests that the outstation freezes its counter values. The outstation automatically transmits the frozen counter values to ClearSCADA.
 | --- | Yes | Yes | ClearSCADA periodically requests that the outstation freezes and resets its counter values. The outstation automatically transmits the frozen counter values to ClearSCADA.


IEC 60870-5 Driver Guide - Configure the Counter Interrogation Intervals (Configuring an IEC 60870-5 Outstation)

Configure the Counter Interrogation Intervals

The IEC 60870-5 driver supports regular interrogation of outstations for counter data. Some outstations are set to report their counter data to the SCADA master (ClearSCADA) automatically. Other outstations might only report their counter data on interrogation by the SCADA master. Similarly, an outstation might ‘freeze’ and/or reset its counter values automatically, or only on request (see Counter Operation Modes and Interrogation Requests).

ClearSCADA can send requests to an outstation to trigger it to perform operation(s) on all of its counters, or, if supported by the outstation, to perform operation(s) on only those counters that are associated with a particular counter interrogation group. An outstation might support up to four counter interrogation groups.

Refer to an outstation’s interoperability Profile document for information on:

  • Whether that outstation supports group interrogation and if so, how many interrogation groups are supported. (Refer to the outstation product documentation for information on how to assign counters to an interrogation group.)
  • What counter interrogation modes that outstation supports (see Counter Operation Modes and Interrogation Requests).

You also need to be aware of:

  • Which counter operations the outstation is set to perform automatically (such as ‘freezing’ its counter values)
  • How often the outstation performs the counter operations.

In ViewX, you can specify whether ClearSCADA is to send periodic requests that will trigger the outstation to perform certain operations on its counters. To do this, you need to use the fields in the Counter Interrogation Intervals section on the EIC 60870-5 tab of the IEC 60870-5 Outstation Form. For instance, if the outstation does not report its frozen counter values automatically, you can set it to report the values at regular intervals. This is achieved by selecting the Request check box and defining a suitable Interval and Offset.

For information on which of the Request, Freeze, and Reset check boxes to select, see Counter Operation Modes and Interrogation Requests.

In each instance, use the Interval field to specify how often ClearSCADA sends the selected counter request(s) to the outstation. Use the Offset field to specify the synchronization offset—the amount of time that occurs from midnight before ClearSCADA sends the first request to the outstation for each counter interrogation group. Specify both the Interval and the Offset in the OPC Time Format.

  • Station Counter Interrogation—Use the Station Counter Interrogation Interval and Offset fields to specify when ClearSCADA is to send Request, Freeze, and/or Reset requests for all of the outstation’s counters.

Specify an Interval and Offset of 0 if:

  • The outstation does not have any counters
  • The outstation performs the required counter operations automatically
  • ClearSCADA is only to interrogate counter data on a per group basis, using the Group n Counter Interrogation settings
  • ClearSCADA is only to scan an outstation for all of its counter data on establishing communications with that outstation.
  • Group n Counter Interrogation—If an outstation supports Group Interrogation polls, you can use the Group 1 Counter Interrogation to Group 4 Counter Interrogation Interval and Offset fields to specify when ClearSCADA is to send Request, Freeze, and/or Reset requests to the outstation for the counters that are assigned to those groups. Counters are assigned to a counter interrogation group at the outstation. Be aware that some outstations may support fewer than four counter interrogation groups.

Specify 0 for both the Interval and Offset:

  • If the outstation performs the required counter operations automatically
  • For those counter interrogation groups that are not supported by the outstation
  • For those counter interrogation groups that are not used on the outstation.

In addition to the above, you can specify whether ClearSCADA is to interrogate an outstation for counter data as soon as it establishes communications with that outstation (see Specify the Operations Performed on Communications Establishment).

NOTE: If an outstation supports counter data, map that data to IEC 60870-5 Analog Point(s) in the ClearSCADA database, in order to use that data within ClearSCADA (see Configuring Analog Points).


IEC 60870-5 Driver Guide - Specify the Operations Performed on Communications Establishment (Configuring an IEC 60870-5 Outstation)

Specify the Operations Performed on Communications Establishment

When the ClearSCADA server has not been in communications with an IEC 60870-5 outstation for some time, it performs an Establishment Phase scan, rather than the usual Primary Phase scan (see Establishment Phase in the ClearSCADA Guide to Advanced Drivers).

Use the fields within the Communications Procedure section of the IEC 60870-5 tab to specify the operations that the IEC 60870-5 driver performs during an Establishment Phase scan:

  • Global Interrogation on Establishment—Select this check box if ClearSCADA is to request all current point data from the outstation as soon as it establishes communications with that outstation. Thereafter, the ClearSCADA requests current point data at the next scheduled interval.

Clear the check box if the server is to only request all of the outstation’s current point data at the next scheduled interval (see Configure the Station and Group Interrogation Intervals).

  • Counter Interrogation on Establishment—Select this check box if ClearSCADA is to request all counter point values from the outstation as soon as it establishes communications with that outstation. Thereafter, the ClearSCADA requests counter data at the next scheduled interval.

Clear the check box if the server is to only request counter data at the next scheduled interval (see Configure the Counter Interrogation Intervals).

  • Set Clock—Select this check box if ClearSCADA is to set the outstation’s clock. The clock will be set as soon as ClearSCADA establishes communications with the outstation. Thereafter, ClearSCADA will set the outstation’s clock at the next scheduled interval (as specified on the Channel Form (see Define when the Server Sets the Outstations’ Clocks in the ClearSCADA Guide to Advanced Drivers)).

The Clock Set Failed status attribute indicates whether ClearSCADA’s latest attempt to set the outstation’s clock failed or succeeded (see IEC 60870-5 Specific Status Display Attributes).

Clear the check box if the outstation does not support clock setting or is receiving its time from another source (such as another Controlling Station, or a GPS clock).

  • Max Concurrent Requests—Use to specify the maximum acceptable number of active concurrent requests that the outstation can handle. An active request is a request, such as a control, that ClearSCADA has sent to the outstation, but for which ClearSCADA has not yet received a response to indicate that the outstation has completed the request.

Specify 1 if the outstation can only process one request at a time; ClearSCADA will queue further requests until it receives confirmation that the outstation has completed the currently active request.

Specify 0 (zero) to remove the upper limit on consecutive requests. Should the number of active concurrent requests be such that the outstation does not have space in its queue for any more requests, the outstation will reject any further requests by sending a suitable protocol response. Should this occur, will ClearSCADA queue the requests until the outstation indicates that it can accept more requests.


IEC 60870-5 Driver Guide - Specify a Logical Outstation's Parent Outstation (Configuring an IEC 60870-5 Outstation)

Specify a Logical Outstation’s Parent Outstation

Each IEC 60870-5 Logical Outstation on a ClearSCADA system represents a separate physical device or logical sector associated with an IEC 60870-5 Direct Outstation (see Configuring an IEC 60870-5 Outstation).

Use the Parent Outstation field on the Remote tab of the IEC 60870-5 Logical Outstation Form to specify the IEC 60870-5 Direct Outstation that is the Logical outstation’s ‘parent’ outstation. Use the field’s browse button to display a Reference browse window and select the required IEC 60870-5 Direct Outstation from the window. (An IEC 60870-5 Direct Outstation can be the ‘parent’ for multiple IEC 60870-5 Logical Outstations.)

ATTENTION: Be aware that should communications be lost with the parent outstation, ClearSCADA will also lose communications with that outstation’s Logical outstations.


IEC 60870-5 Driver Guide - Points Used on IEC 60870-5 Outstations

Points Used on IEC 60870-5 Outstations

Throughout the ClearSCADA documentation suite ‘information objects’—the objects that can be monitored or controlled on an outstation—are referred to as ‘points’. You create and configure different types of point in ClearSCADA, to represent the different types of information object on each outstation.

IEC 60870-5 outstations support a combination of these point types:

  • IEC 60870-5 Analog Input Point—see Configuring Analog Points.
  • IEC 60870-5 Analog Output Point—see Configuring Analog Points.
  • IEC 60870-5 Digital Input Point—see Configuring Digital Points.
  • IEC 60870-5 Digital Output Point—see Configuring Digital Points.

Within ClearSCADA you need to configure one point of the appropriate type per point on an IEC 60870-5 outstation. You configure the properties of each point using the appropriate IEC 60870-5 Point Form. Each Form has several tabs. For information on configuring each type of point, see the references above and also see the information in the rest of this section. This includes information on how to:

  • Configure Common IEC 60870-5 Point Properties
  • Specify how ClearSCADA Interprets an Input Point’s Cause of Transmission
  • Specify the Type of Point Data that ClearSCADA is to Store Historically
  • Configure the Common IEC 60870-5 Point Control Properties of Digital and Analog Output Points.

For information on the minimal amount of configuration that you can undertake to produce a functional IEC 60870-5 point in ClearSCADA, see Minimum Configuration.

For general information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.


IEC 60870-5 Driver Guide - Minimum Configuration (Points Used on IEC 60870-5 Outstations)

Minimum Configuration

For an IEC 60870-5 point to be functional (online), you need to configure these features, then put the point In Service and save the configuration:

  • The Outstation on which the point is located
  • The Information Object Address
  • If the point is a Digital Point, the Number of Bits that make up the point
  • If the point is a Digital Output Point, you must enable the required number of control Actions.

The settings above are the minimal requirements for a functional IEC 60870-5 outstation.

If you want the ClearSCADA server to store point data historically, you also need to:

  • Enable and configure logging on the Historic tab if data is to be stored historically in the server database
  • Enable and configure logging on the <Point Type> tab if data is to be stored historically at the outstation.


IEC 60870-5 Driver Guide - Configure Common IEC 60870-5 Point Properties (Points Used on IEC 60870-5 Outstations)

Configure Common IEC 60870-5 Point Properties

Use the fields at the top of the <Point Type> tab on the appropriate IEC 60870-5 Point Form to configure the general properties of a point. The properties described below are common to many points on IEC 60870-5 outstations:

  • In Service—Use to specify whether a point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point that is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Outstation—Specify the outstation on which the point is located. Use the browse button to display a Reference browse window, and choose the required outstation entry.
  • Information Object Address—This address, combined with the outstation’s Link Address (where applicable) and Common Address, uniquely identifies a point on a set.

Use the Information Object Address field to specify the address that identifies this point in the outstation. Each point requires a unique address (on that outstation), irrespective of point type.

For outstations that communicate using the IEC 60870-5-101 protocol, the valid range for this address varies, depending on the size that is specified for this address on the Outstation Form (see Specify the IEC 60870-5-101 Parameters).

  • If the Information Address Size is 1 Octet, the valid Information Object Address range is 1 to 255 inclusive.
  • If the Information Address Size is 2 Octets, the valid Information Object Address range is 1 to 65535 inclusive.
  • If the Information Address Size is 3 Octets, the valid Information Object Address range is 1 to 16777215 inclusive.

An outstation that communicates using the IEC 60870-5-104 protocol has an Information Address Size of 3 Octets and therefore has a valid address range of 1 to 16777215 inclusive.

  • Severity—Use this combo box to define the severity of any non-state events or alarms for the point.

For more information on severities, see Defining Severities in the ClearSCADA Guide to Core Configuration.


IEC 60870-5 Driver Guide - Specify how ClearSCADA Interprets an Input Point's Cause of Transmission (Points Used on IEC 60870-5 Outstations)

Specify how ClearSCADA Interprets an Input Point’s Cause of Transmission

Each IEC 60870-5 message includes a ‘Cause of Transmission’ indicator. The indicator specifies why the message was generated. Each outstation’s interoperability Profile document indicates which ‘Cause of Transmission’ indicators are supported. Point data that is returned by an outstation will be sent with one of four ‘Cause of Transmission’ indicators:

  • Interrogation—The outstation has sent the point data in response to an interrogation request from ClearSCADA (either a Station Interrogation, Group n Interrogation, Counter Interrogation, or Counter Group n Interrogation).
  • Spontaneous—The reason for data being sent with a Spontaneous ‘Cause of Transmission’ indicator is vendor-specific. Typically, an outstation sends ‘Spontaneous’ data, because a value has changed by a significant amount, has crossed a threshold, or changed state. Spontaneous data is not sent in response to a request from ClearSCADA.
  • Background—The reason for data being sent with a Background ‘Cause of Transmission’ indicator is vendor-specific. Such data might be sent, for example, because a value has not been sent for a period of time and the outstation is refreshing the value for operator confidence. Background data is not sent in response to a request from ClearSCADA.
  • Periodic/Cyclic—The reason for data being sent with a Periodic or Cyclic ‘Cause of Transmission’ indicator is vendor-specific. When supported, such data is typically sent at regular intervals, with the interval being set locally at the outstation. Periodic/Cyclic data is not sent in response to a request from ClearSCADA.

The Interrogation indicator is supported by each of the many different types of IEC 60870-5 outstation. However, support for the other indicators varies depending on the make and model of the outstation.

Use the fields within the Cause of Transmission Interpretation section on the <Point Type> tab to specify how ClearSCADA is to handle point data that it receives with each ‘Cause of Transmission’ indicator. By default, ClearSCADA points are configured to process the values that are returned by an outstation as current data. However, if you only require the data sent with certain ‘Cause of Transmission’ indicator(s) to be stored historically, you will need to specify different options. To do this, you will need to use the fields in the Historic Data Filter section to Specify the Type of Point Data that ClearSCADA is to Store Historically.).

  • Interrogation—Use the combo box to specify how ClearSCADA handles point data that the outstation sends in response to an interrogation request.
  • Spontaneous—Use the combo box to specify how ClearSCADA handles point data that the outstation transmits with a Spontaneous ‘Cause of Transmission’ indicator.
  • Background—Use the combo box to specify how ClearSCADA handles point data that the outstation transmits with a Background ‘Cause of Transmission’ indicator.
  • Periodic/Cyclic—Applies to Analog Input points only. Use the combo box to specify how ClearSCADA handles point data that the outstation transmits with a Periodic/Cyclic ‘Cause of Transmission’ indicator.

Use each combo box to display a list of options and select the required option. The options vary, depending on the transmission cause and the point type, but include a combination of the following:

  • Current, Update Always—ClearSCADA uses the data to update the point’s current value in the database, regardless of whether the value has changed.
  • Current, Update on Change—ClearSCADA only uses the data to update the point’s current value in the database if the value has changed. The value is deemed to have changed in ClearSCADA it if crosses one of the configured limit thresholds, has changed state, or has changed by a significant amount. (The latter applies to analog points only.)
  • Timed Report—ClearSCADA logs and processes the data as a Timed Report value (data that is reported at regular intervals, regardless of whether it has changed). With the IEC 60870-5 protocol, Timed Report values might comprise:
  • Values that the outstation sends spontaneously, in data packets that have either a Background or Periodic/Cyclic ‘Cause of Transmission’ indicator (see Specify how ClearSCADA Interprets an Input Point’s Cause of Transmission)
  • Values that are reported at the relevant ClearSCADA scanning interval, if the data is sent in response to an interrogation request from ClearSCADA (see Configure the Station and Group Interrogation Intervals, and see Configure the Counter Interrogation Intervals). Such data will be sent in data packets that have an Interrogation ‘Cause of Transmission’ indicator.
  • Significant Change—Applies to spontaneous Analog Input point data only. ClearSCADA logs the value as a Significant Change value and updates the current value if applicable.

The outstation configuration controls the number of values that are passed to the Controlling Station (ClearSCADA).

  • State Change—Applies to spontaneous Digital Input point data only. ClearSCADA logs the value as a digital point State Change and processes the data accordingly.

The outstation configuration controls the number of values that are passed to the Controlling Station (ClearSCADA).

ClearSCADA will log an error should an outstation send an unknown Cause of Transmission identifier.


IEC 60870-5 Driver Guide - Specify the Type of Point Data that ClearSCADA is to Store Historically (Points Used on IEC 60870-5 Outstations)

Specify the Type of Point Data that ClearSCADA is to Store Historically

Use the check boxes within the Historic Data Filter section of the <Point Type> tab to specify the type of data that ClearSCADA is to store historically for a particular input point.

The check boxes are only available for use if ClearSCADA is configured to store data historically for the point (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration). The options vary, depending on the point type:

  • Current—Select this check box for ClearSCADA to store current data values historically.
  • Significant Change—Applies to Analog Input points only. Select this check box if you want ClearSCADA to store any significant changes historically.
  • State Change—Applies to Digital Input points only. Select this check box for ClearSCADA to store point state changes historically.
  • Timed Report—Select this check box if you want ClearSCADA to store Timed Report data historically.
  • End of Period—Select this check box if you want ClearSCADA to store End of Period data historically.

If you do not want ClearSCADA to store a type of data historically for the point, clear the appropriate check box. For example, if the point has data that is logged because of an End of Period, and you do not want this data to be stored historically, clear the End of Period check box in the Historic Data Filter section.

When enabling or disabling the Historic Data Filter settings, you need to consider how ClearSCADA maps the point’s ‘Cause of Transmission’ indicators to ClearSCADA’s ‘Reasons for Logging’. For example, if you want data that has a ‘Spontaneous’ cause of transmission to be logged historically, you will need to determine which Reason for Logging the ‘Spontaneous’ indicator is mapped to, and then select the appropriate check box. You can determine how the ‘Cause of Transmission’ indicators are mapped to ‘Reasons for Logging’ by looking at the ‘Cause of Transmission Interpretation’ settings on the Point Form (see Specify how ClearSCADA Interprets an Input Point’s Cause of Transmission).


IEC 60870-5 Driver Guide - Configure the Common IEC 60870-5 Point Control Properties (Points Used on IEC 60870-5 Outstations)

Configure the Common IEC 60870-5 Point Control Properties

The Control tab for both IEC 60870-5 Analog Output Points and IEC 60870-5 Digital Output Points includes these fields:

  • Require Select—Select this check box is ClearSCADA is to issue a Select command before executing a control. Following the issue of a Select command, if the outstation is ready to accept the expected command, it sends a confirmation message to the server. On receipt of a valid confirmation message, the server sends an Execute command to the outstation to allow it to carry out the control.

Clear the check box if ClearSCADA is to issue a direct Execute command without issuing a separate Select command. Direct command controls are typically used for immediate control operations. With such a control, if the output is ready for execution, the outstation executes the control when it receives the Execute command. If the output is not ready, the control is rejected.

  • Expect Termination—Select this check box if the outstation sends a control confirmation message, followed by a control termination message, once a control is complete.

Clear the check box if the outstation sends only a control confirmation message once a control is complete.

In either case, if ClearSCADA does not receive the expected message(s) within the required duration, the control will time out, and ClearSCADA will raise an alarm to indicate that the control has failed. You can use the ClearSCADA Server Configuration Tool’s Request Timeout and Request Timeout Extension fields to define the amount of time in which a control has to complete. These fields are in the Drivers section (see Define the Driver Request Timeouts in the ClearSCADA Guide to Server Administration).

  • Update Point on Successful Action—Use to define when ClearSCADA updates the point’s value in the ClearSCADA database.

If you select the Update Point on Successful Action check box, ClearSCADA will update the point’s value in the database as soon as it receives a response from the outstation (that indicates the control was successful).

If you clear the Update Point on Successful Action check box, ClearSCADA will not update the point’s value in the database following a control - it leaves the existing value of the point in place.

In addition to the above fields, the Control tab for IEC 60870-5 output points also contains other fields. For information on these fields, see Configuring Analog Points, and see Configuring Digital Points.


IEC 60870-5 Driver Guide - Configuring Analog Points

Configuring Analog Points

The IEC 60870-5 driver supports Analog Input points and Analog Output points.

Use IEC 60870-5 Analog Input points to map analog or counter data for use within ClearSCADA. Use IEC 60870-5 Analog Output points to control analog values in an outstation.

Configure the properties of each analog point using the fields on the IEC 60870-5 Analog Input Point Form, or the IEC 60870-5 Analog Output Point Form, as appropriate. Each Form has several tabs.

For both IEC 60870-5 Analog Input Points and IEC 60870-5 Analog Output Points, use the Analog Point tab to:

  • Configure Common IEC 60870-5 Point Properties
  • Configure the Alarm Limits
  • Configure any Alarm Limit Profiles (see Specify any Alarm Limit Profiles in the ClearSCADA Guide to Core Point Configuration)
  • Configure Point Scaling
  • Configure the Point Formatting (see Define the Appearance of an Analog Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Override Properties (see Define whether an Analog Point can be Overridden in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration)
  • Configure the No Change Properties (see Detect whether an Analog Point has Stopped Changing in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Trend Properties (see Define an Analog Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Logged Data Properties (see Processing Alarm Data for Point States in the ClearSCADA Guide to Advanced Drivers).

For IEC 60870-5 Analog Input Points also use the Analog Point tab to:

  • Specify how ClearSCADA Interprets an Input Point’s Cause of Transmission
  • Specify the Type of Point Data that ClearSCADA is to Store Historically.

For IEC 60870-5 Analog Output Points, use the Control tab to:

  • Configure the Control Properties (see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Specify whether any Outstations are given Scanning Priority whenever a Control Action is Issued (see Promoting Scanning of Outstations Associated with Controls in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Format in which to Transfer Control Data
  • Configure the Common IEC 60870-5 Point Control Properties.

For information on the properties on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.


IEC 60870-5 Driver Guide - Alarm Limits (Configuring Analog Points)

Alarm Limits

Use the fields within the Alarm Limits section of the Analog Point tab to set limits for the point and specify whether an alarm or event is generated if a point exceeds those limits. For information on configuring these limits, see Configure the Limits for an Analog Point in the ClearSCADA Guide to Core Point Configuration.

The Alarm Limits section of the tab also has these fields:

  • Hysteresis—Use this field to configure the point so that its value has to alter by a specific amount before a change of state can occur (see Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm in the ClearSCADA Guide to Core Point Configuration).
  • Engineering Units Exceeded—Use this field to define how ClearSCADA handles a value that is over range or under range (see Define how Over Range and Under Range Values are Processed in the ClearSCADA Guide to Core Point Configuration).
  • Tune Limits—Select this check box if you want to operators to be able to ‘tune’ the alarm limits (change the limits temporarily). ‘Tuning’ the alarm limits of a point can be useful when you need to allow for values that would normally cause an alarm to be raised. For example, users may ‘tune’ alarm limits during maintenance so that ClearSCADA does not raise unnecessary alarms. For details on using this feature, see Define whether an Analog Point’s Limits can be Tuned in the ClearSCADA Guide to Core Point Configuration.

NOTE: If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed on the Analog Point tab. For information on this property, see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events in the ClearSCADA Guide to Core Point Configuration.


IEC 60870-5 Driver Guide - Configure Point Scaling (Configuring Analog Points)

Configure Point Scaling

Use the fields within the Scaling section of the Analog Point tab to specify whether and how ClearSCADA scales the point values that are reported by the outstation.

  • Enabled—Select this check box if the input value at the outstation needs scaling for use in ClearSCADA, and vice versa for output values. The IEC 60870-5 driver performs the required scaling before passing the value onto ClearSCADA.

Clear the Enabled check box if no scaling is required.

  • Raw Full Scale—Specify the raw integer value that ClearSCADA is to scale to the Full Scale value. The Full Scale value is specified within the Alarm Limits section of the tab (see Alarm Limits).
  • Raw Zero Scale—Specify the raw integer value that ClearSCADA is to scale to the Zero Scale value. The Zero Scale value is specified within the Alarm Limits section of the tab (see Alarm Limits).

Example:

If an outstation is reporting an analog point’s raw value as a Normalized Value (ID 9), you might specify a Raw Full Scale of +1 and Raw Zero Scale of -1.

If an outstation is reporting an analog point’s raw value as a Scaled Value (ID 11), you might use the Raw Full Scale and Raw Zero Scale fields to specify the required scaling, within the range +32767 and -32768.


IEC 60870-5 Driver Guide - Specify the Format in which to Transfer Control Data (Configuring Analog Points)

Specify the Format in which to Transfer Control Data

This section applies to IEC 60870-5 Analog Output Points only.

The IEC 60870-5-101 protocol defines a number of ASDU formats (ID 48 to ID 51) that can be used by ClearSCADA for sending analog control information to the outstation.

The IEC 60870-5-104 protocol defines the above ASDU formats along with an additional set of ASDU formats (ID 61 to ID 64). The latter formats allow ClearSCADA to include the time with each control message that it sends to the outstation. The IEC 60870-5-104 protocol includes these additional formats as the nature of TCP/IP means that control packets may arrive at the outstation a significant amount of time after they were sent. By using one of these formats, the outstation is able to reject any control requests that are deemed too far in the past. (The exact functionality is dependent on the manufacturer’s implementation.)

Each analog output on an outstation supports one or more of the ASDU formats mentioned above (refer to the outstation’s interoperability Profile document for information on which formats are supported). When ClearSCADA transmits a control request for an IEC 60870-5 analog output point, it uses the format that is specified in the point’s configuration. For this reason, you need to configure the IEC 60870-5 analog output points in the database to use the same formats as the points they represent on the outstation. To do this, use the IEC 60870-5 Type field on the Control tab of the IEC 60870-5 Analog Output Point Form.

Use the field’s combo box to select the required control format. The format that you choose has to match the format in which the outstation expects to receive control information for the point:

  • Normalized Value -1 to +1 (ID 48)—ClearSCADA takes a control value that is in the range -1 to +1 and encodes it to a 16-bit integer. It then sends that integer value in its control request to the outstation. Any control requests for values outside the -1 to +1 range are restricted to -1 or +1, as applicable.
  • Scaled Value -32678 to +32767 (ID 49)—ClearSCADA takes a raw integer control value that is in the range -32678 to +32767 and encodes it as a 16-bit integer. It then sends that integer value in its control request to the outstation. Any control request for values outside the above range are restricted to -32678 or +32767, as applicable.
  • 32-bit IEEE float (ID 50)—ClearSCADA encodes the control value as a signed IEEE single-precision (32-bit) floating point number. It then sends that integer value in its control request to the outstation.

Should the control value exceed the range that can be represented by a 32-bit IEEE float, ClearSCADA sends encoded value as +/- infinity.

  • 32-bit Bit String (ID 51)—ClearSCADA takes the 32-bit string that is the control value and encodes it as a 32-bit unsigned integer. It then sends that integer value in its control request to the outstation.

Should the control value exceed 4294967295, ClearSCADA only sends the lower 32-bits of the value as an integer.

  • Normalized Value with Timestamp (ID 61)—Only available for points on outstations that communicate using the IEC 60870-5-104 protocol. ClearSCADA encodes the control value in the same way as it does for ID 48. Additionally, it includes a time stamp in each control message.

The outstation executes the control request, unless the time stamp indicates that the request is too far in the past (in which case the request is rejected).

  • Scaled Value with Timestamp (ID 62)—Only available for points on outstations that communicate using the IEC 60870-5-104 protocol. ClearSCADA encodes the control value in the same way as it does for ID 49. Additionally, it includes a time stamp in each control message.

The outstation executes the control request, unless the time stamp indicates that the request is too far in the past (in which case the request is rejected).

  • 32-bit IEEE Float with Timestamp (ID 63)—Only available for points on outstations that communicate using the IEC 60870-5-104 protocol. ClearSCADA encodes the control value in the same way as it does for ID 50. Additionally, it includes a time stamp in each control message.

The outstation executes the control request, unless the time stamp indicates that the request is too far in the past (in which case the request is rejected).

  • 32-bit Bit String with Timestamp (ID 64)—Only available for points on outstations that communicate using the IEC 60870-5-104 protocol. ClearSCADA encodes the control value in the same way as it does for ID 51. Additionally, it includes a time stamp in each control message.

The outstation executes the control request, unless the time stamp indicates that the request is too far in the past (in which case the request is rejected).


IEC 60870-5 Driver Guide - Configuring Digital Points

Configuring Digital Points

The IEC 60870-5 driver supports 1-, and 2-bit Digital Input points and Digital Output points.

Configure the properties of each digital point using the fields on the IEC 60870-5 Digital Input Point Form, or the IEC 60870-5 Digital Output Point Form, as appropriate. Each Form has several tabs.

For both IEC 60870-5 Digital Input Points and IEC 60870-5 Digital Output Points, use the Digital Point tab to:

  • Configure the General Point Properties
  • Configure the Point States (see Define the Point States for a Digital Point in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Override Properties (see Define whether a Digital Point can be Overridden in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Trend Properties (see Define a Digital Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Logged Data Properties (see Processing Alarm Data for Point States in the ClearSCADA Guide to Advanced Drivers).

For IEC 60870-5 Digital Input Points, also use the Digital Point tab to:

  • Specify how ClearSCADA Interprets an Input Point’s Cause of Transmission
  • Specify the Type of Point Data that ClearSCADA is to Store Historically.

For IEC 60870-5 Digital Output Points, use the Control tab to:

  • Configure the control actions (see Define the Output Actions in the ClearSCADA Guide to Core Point Configuration)
  • Specify whether any Outstations are given Scanning Priority whenever a Control Action is Issued (see Promoting Scanning of Outstations Associated with Controls in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Format in which to Transfer Control Data
  • Specify the Default Control Action
  • Configure the Common IEC 60870-5 Point Control Properties.

For information on the properties on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.


IEC 60870-5 Driver Guide - Configure the General Point Properties (Configuring Digital Points)

Configure the General Point Properties

Use the fields at the top of the Digital Point tab to define the general properties of an IEC 60870-5 Digital Point (see Configure Common IEC 60870-5 Point Properties). Fields that are specific to IEC 60870-5 Digital Points are summarized below.

  • Number of Bits—Use this combo box to specify the number of bits for the point. This corresponds to the number of consecutive 1-bit points that form the point.

Specify 1 for a point that represents Single-point information, and 2 for a point that represents Double-point information.

The number of bits directly affects the number of point states that you can configure in the States section of the tab. For further information, see Define the Number of Bits for a Digital Point in the ClearSCADA Guide to Core Point Configuration.

  • Format—Specify the format in which the point’s value appears in other ViewX displays, such as Lists. For further information, see Define the Format of a Digital Point’s Values in the ClearSCADA Guide to Core Point Configuration.


IEC 60870-5 Driver Guide - Specify the Format in which to Transfer Control Data (Configuring Digital Points)

Specify the Format in which to Transfer Control Data

This section applies to IEC 60870-5 Digital Output Points only.

The IEC 60870-5-101 protocol defines a number of ASDU commands (ID 45 to ID 47) that can be used by ClearSCADA for sending digital control information to the outstation.

The IEC 60870-5-104 protocol defines the above ASDU commands along with an additional set of ASDU commands (ID 58 to ID 60). The latter commands allow ClearSCADA to include the time with each control message that it sends to the outstation. The IEC 60870-5-104 protocol includes these additional commands as the nature of TCP/IP means that control packets may arrive at the outstation a significant amount of time after they were sent. By using one of these commands, the outstation is able to reject any control requests that are deemed too far in the past. (The exact functionality is dependent on the manufacturer’s implementation.)

Each digital output on an outstation supports one or more of the ASDU commands mentioned above (refer to the outstation’s interoperability Profile document for information on which commands are supported). When ClearSCADA transmits a control request for an IEC 60870-5 digital output point, it uses the format that is specified in the point’s configuration. For this reason, you need to configure the IEC 60870-5 digital output points in the database to use the same commands as the points they represent on the outstation. To do this, use the IEC 60870-5 Type field on the Control tab of the IEC 60870-5 Digital Output Point Form.

Use the field’s combo box to select the required control command. The command type that you choose has to match the command type that the outstation expects to receive for the point:

  • Single Command (ID 45)—ClearSCADA issues a single-bit control to set the corresponding point to 0 or 1 in the outstation.
  • Double Command (ID 46)—ClearSCADA issues a 2-bit control to set the corresponding point to state 1 or state 2 in the outstation. This command is typically used for switches or valves, with state 1 representing the ‘Off’ state and state 2 the ‘On’ state. (Be aware that the IEC 60870-5 standard defines that states 0 and 3 are not permitted, therefore the outstation may reject any control requests to set such states.)
  • Regulating Step Command (ID 47)—ClearSCADA issues a 2-bit control to set the corresponding point to state 1 or state 2 in the outstation. The command is typically used to step up or down a transformer, with state 1 typically being used to represent ‘Next Step Lower’ and state 2 ‘Next Step Higher’. (Be aware that the IEC 60870-5 standard defines that states 0 and 3 are not permitted, therefore the outstation may reject any control requests to set such states.)
  • Single Command with Timestamp (ID 58)—Only available for points on outstations that communicate using the IEC 60870-5-104 protocol. This control is similar to ID 45, but additionally, ClearSCADA includes a time stamp in each control message.

The outstation executes the control request, unless the time stamp indicates that the request is too far in the past (in which case the request is rejected).

  • Double Command with Timestamp (ID 59)—Only available for points on outstations that communicate using the IEC 60870-5-104 protocol. This control is similar to ID 46, but additionally, ClearSCADA includes a time stamp in each control message.

The outstation executes the control request, unless the time stamp indicates that the request is too far in the past (in which case the request is rejected).

  • Regulating Step Command with Timestamp (ID 60)—Only available for points on outstations that communicate using the IEC 60870-5-104 protocol. This control is similar to ID 47, but additionally, ClearSCADA includes a time stamp in each control message.

The outstation executes the control request, unless the time stamp indicates that the request is too far in the past (in which case the request is rejected).


IEC 60870-5 Driver Guide - Specify the Default Control Action (Configuring Digital Points)

Specify the Default Control Action

You can define a Default Action for IEC 60870-5 Digital Output Points. The action you choose will be performed whenever ClearSCADA sends a control request for the relevant point on the outstation.

When you specify a Default Action for an IEC 60870-5 digital output point, you need to choose an action that is supported by the outstation and is appropriate for your requirements. To find out which default actions are supported, please refer to the outstation’s interoperability Profile document.

To define the Default Action for an IEC 60870-5 digital output point, you need to use the Default Action setting on the Control tab of the IEC 60870-5 Digital Output Point Form:

Use the field’s combo box to select the relevant option:

  • No Additional Definition—The type of control that is performed depends on the default that is set at the outstation. This might be a short or long pulsed control, or a maintained control.
  • Short Pulse Duration—The control changes the state of plant for a defined short period of time. The actual pulse length is defined at the outstation.
  • Long Pulse Duration—The control changes the state of plant for a defined period of time. The actual pulse length is defined at the outstation.
  • Persistent Output—The control changes the state of plant until another control is sent to further alter the state.


IEC 60870-5 Driver Guide - Using IEC 60870-5 Specific Actions

Using IEC 60870-5 Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section covers actions that are IEC 60870-5 driver-specific and includes:

  • Actions Associated with IEC 60870-5 Outstations
  • Actions Associated with IEC 60870-5 Digital Output Points
  • Alphabetical List of IEC 60870-5 Specific Actions.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


IEC 60870-5 Driver Guide - Actions Associated with IEC 60870-5 Outstations (Using IEC 60870-5 Specific Actions)

Actions Associated with IEC 60870-5 Outstations

These actions are specific to IEC 60870-5 outstations:

  • Delete File
  • Download File
  • Get Directory
  • Upload File.


IEC 60870-5 Driver Guide - Actions Associated with IEC 60870-5 Digital Output Points (Using IEC 60870-5 Specific Actions)

Actions Associated with IEC 60870-5 Digital Output Points

This action is associated with IEC 60870-5 Digital Output points:

  • Control with Qualifier.


IEC 60870-5 Driver Guide - Alphabetical List of IEC 60870-5 Specific Actions (Using IEC 60870-5 Specific Actions)

Alphabetical List of IEC 60870-5 Specific Actions

This section lists those actions that are specific to the IEC 60870-5 driver. The actions are listed in alphabetical order and comprise:

  • Control with Qualifier
  • Delete File
  • Download File
  • Get Directory
  • Upload File.


IEC 60870-5 Driver Guide - Control with Qualifier (Using IEC 60870-5 Specific Actions)

Control with Qualifier

Associated with: IEC 60870-5 Digital Output Points

Security permission required to access this pick action: Control

The type of control that an IEC 60870-5 digital output point supports differs, depending on the type(s) of control that are supported by the outstation on which that point resides.

Use the Control with Qualifier pick action to control an IEC 60870-5 digital output point. Select the pick action to display the Control with Qualifier window. Use the fields in the window to specify the control that ClearSCADA is to perform:

  • Qualifier—Use the combo box to specify the type of control. Choose from No Addition Definition, Short Pulse Duration, Long Pulse Duration, and Persistent Output. The type of control you choose should be:
  • Appropriate to your requirements
  • Supported by the relevant point (otherwise the control will be unsuccessful)

For more information on above options, see Specify the Default Control Action.

  • Action—Use this combo box to specify the control action. The number of actions varies, depending on the number of Bits allocated to the point and the number of actions that are enabled.

The name of each action corresponds to the description that is assigned to that action. This is assigned using the relevant Description field, located within the Actions section on the Point Form’s Control tab (see Define the Output Actions in the ClearSCADA Guide to Core Point Configuration).


IEC 60870-5 Driver Guide - Delete File (Using IEC 60870-5 Specific Actions)

Delete File

Associated with: IEC 60870-5 Outstations

Security permission required to access this pick action: Configure

Use this pick action to delete a binary file on an IEC 60870-5 outstation.

Select the Delete File pick action to display the Delete File window. Use the fields in the window to specify the file that ClearSCADA is to delete.

  • Source IOA—Specify the Information Object Address at which the file is located on the outstation. The valid address range varies, depending on the IOA size supported by the outstation.

An outstation that communicates using the IEC 60870-5-104 protocol has an Information Object Address size of 3 octets.

With an outstation that communicates using the IEC 60870-5-101 protocol, the size ranges between 1 and 3 octets (see Specify the IEC 60870-5-101 Parameters).

  • Source Filename—Specify the number of the file that ClearSCADA is to delete from the above IOA on the outstation. The file name is a 2 octet number, in the range 0 to 65535.

Also see Get Directory.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name DeleteOSFile.


IEC 60870-5 Driver Guide - Download File (Using IEC 60870-5 Specific Actions)

Download File

Associated with: IEC 60870-5 Outstations

Security permission required to access this pick action: Retrieve Data

Use the Download File pick action to download a binary file from the ClearSCADA server to an IEC 60870-5 outstation. Select the pick action to display the Download File window. Use the fields in the window to specify the file and the destination to which it is to be downloaded.

  • Source Filename—Use to specify the name of the file that ClearSCADA is to download to the outstation.

If the file is on the local server, you need to:

  • Specify the full path to the file, including the drive—for example,
    <drive>:\<directory>\File1.txt

If the file is on a remote server, you need to:

  • Specify the UNC path to the file—for example,
    \\<server name>\<directory>\file1.txt
  • Provide ClearSCADA with the necessary Read and Write access to that location on the remote server.
  • Destination IOA—Specify the Information Object Address to which ClearSCADA is to download the file. The valid address range varies, depending on the IOA size supported by the outstation.

An outstation that communicates using the IEC 60870-5-104 protocol has an Information Object Address size of 3 octets.

With an outstation that communicates using the IEC 60870-5-101 protocol, the size ranges between 1 and 3 octets (see Specify the IEC 60870-5-101 Parameters).

  • Destination Filename—Specify the name that ClearSCADA is to assign to the downloaded file. Specify the name as a 2 octet number, in the range 0 to 65535.
  • Destination Section Name—Specify the section to which ClearSCADA is to download the file. Specify the section as a 1 octet number, in the range 0 to 255.

Also see Get Directory.


IEC 60870-5 Driver Guide - Get Directory (Using IEC 60870-5 Specific Actions)

Get Directory

Associated with: IEC 60870-5 Outstations

Security permission required to access this pick action: Retrieve Data

Use the Get Directory pick action to obtain a list of binary files on an IEC 60870-5 outstation. This is useful when you need to ascertain the locations and names of files on an outstation—for instance, before uploading files from, or downloading files to that outstation.

Select the Get Directory pick action to display the Get Directory window. The window has these fields:

  • Destination File—Use to specify the name and location of the file to which ClearSCADA is to write the directory information.

If the file is to reside on the local server, you need to:

  • Specify the full path to the file, including the drive—for example,
    <drive>:\<directory>\IOA3DirectoryList.txt

If the file is to reside on a remote server, you need to:

  • Specify the UNC path to the file—for example,
    \\<server name>\<directory>\IOA3DirectoryList.txt
  • Provide ClearSCADA with the necessary Read and Write access to that location on the remote server.
  • Source IOA—Specify the Information Object Address for which ClearSCADA is to obtain a directory listing. The valid address range varies, depending on the IOA size supported by the outstation.

An outstation that communicates using the IEC 60870-5-104 protocol always has an Information Object Address size of 3 octets.

With an outstation that communicates using the IEC 60870-5-101 protocol, the size ranges between 1 and 3 octets (see Specify the IEC 60870-5-101 Parameters).

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Directory.

Example:

This directory listing for IOA 0 shows that nine files exist at that address in that particular outstation.

Also see:

Delete File

Download File

Upload File.


IEC 60870-5 Driver Guide - Upload File (Using IEC 60870-5 Specific Actions)

Upload File

Associated with: IEC 60870-5 Outstations

Security permission required to access this pick action: Retrieve Data

Use this pick action to upload a binary file from an IEC 60870-5 outstation to the ClearSCADA server.

Select the Upload File pick action to display the Upload File window. Use the fields in the window to specify the file that ClearSCADA is to upload.

  • Destination Filename—Specify the name of the file to which ClearSCADA is to write on the local server, or a remote server.

If the file is to be uploaded to the local server:

  • Specify the full path to the file—for example,
    <drive>:\<directory>\File1.txt

If the file is to be uploaded to a remote server, you need to:

  • Specify the UNC path to the file—for example,
    \\<server name>\<directory>\File1.txt
  • Provide ClearSCADA with the necessary Read and Write access to that location on the remote server.
  • Source IOA—Specify the Information Object Address from which ClearSCADA is to upload the file. The valid address range varies, depending on the IOA size supported by the outstation, but will comprise between 1 and 3 octets.
  • Source Filename—Specify the name of the file that ClearSCADA is to upload from the above IOA on the outstation. The file name is a 2 octet number, in the range 0 to 65535.

Also see Get Directory.


IEC 60870-5 Driver Guide - IEC 60870-5 Specific Status Display Attributes

IEC 60870-5 Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each IEC 60870-5 outstation provides information about the present state of the individual outstation.

Use this section if you need information on the status of any IEC 60870-5 database items on your system.

This section covers those attributes that are IEC 60870-5 driver specific and includes:

  • IEC 60870-5 Outstation Status Attributes
  • IEC 60870-5 Point Status Attributes
  • Alphabetical List of IEC-60870-5 Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Common Status Attributes: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.

Understand and Resolve Outstation Interrogation Alarms.


IEC 60870-5 Driver Guide - IEC 60870-5 Outstation Status Attributes (IEC 60870-5 Specific Status Display Attributes)

IEC 60870-5 Outstation Status Attributes

These status attributes are specific to IEC 60870-5 outstations:

  • Station Interrogation Alarm
  • Group n Interrogation Alarm
  • Station Counter Interrogation Alarm
  • Group n Counter Interrogation Alarm
  • Clock Set Failed
  • Source.


IEC 60870-5 Driver Guide - IEC 60870-5 Point Status Attributes (IEC 60870-5 Specific Status Display Attributes)

IEC 60870-5 Point Status Attributes

This status attribute is specific to IEC 60870-5 points:

  • Source.


IEC 60870-5 Driver Guide - Alphabetical List of IEC-60870-5 Specific Status Display Attributes (IEC 60870-5 Specific Status Display Attributes)

Alphabetical List of IEC-60870-5 Specific Status Display Attributes

This section lists those Status attributes that are specific to items on the IEC 60870-5 driver.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.

The attributes are listed in alphabetical order and comprise:

  • Clock Set Failed
  • Group n Counter Interrogation Alarm
  • Group n Interrogation Alarm
  • Source
  • Station Counter Interrogation Alarm
  • Station Interrogation Alarm.


IEC 60870-5 Driver Guide - Clock Set Failed (IEC 60870-5 Specific Status Display Attributes)

Clock Set Failed

Associated with: IEC 60870-5 outstations

This attribute indicates whether the latest attempt by ClearSCADA to set an outstation’s clock failed.

Possible states: Displays one of the Standard Alarm States.


IEC 60870-5 Driver Guide - Group n Counter Interrogation Alarm (IEC 60870-5 Specific Status Display Attributes)

Group n Counter Interrogation Alarm

Associated with: IEC 60870-5 outstations

Each of these attributes indicates whether the latest Request, Freeze and/or Reset request for the counters that are assigned to that particular group, has failed. One Group n Counter Interrogation Alarm attribute is displayed for each of the four possible counter interrogation groups.

The frequency with which ClearSCADA attempts to execute the above requests is specified as part of the outstation’s configuration (see Configure the Counter Interrogation Intervals).

Possible states: Displays one of the Standard Alarm States. (Unused counter groups display the state ‘Enabled Inactive’.)

Further Information

Understand and Resolve Outstation Interrogation Alarms.


IEC 60870-5 Driver Guide - Group n Interrogation Alarm (IEC 60870-5 Specific Status Display Attributes)

Group n Interrogation Alarm

Associated with: IEC 60870-5 outstations

Each of these attributes indicates whether the latest attempt to scan that particular group of points for current data has failed. One Group n Interrogation Alarm attribute is displayed for each of the 16 possible interrogation groups.

The frequency with which ClearSCADA attempts to scan each group of points for current data is specified as part of the outstation’s configuration (see Configure the Station and Group Interrogation Intervals).

Possible states: Displays one of the Standard Alarm States. (Unused groups display the state ‘Enabled Inactive’.)

Further Information

Understand and Resolve Outstation Interrogation Alarms.


IEC 60870-5 Driver Guide - Source (IEC 60870-5 Specific Status Display Attributes)

Source

Associated with: various IEC 60870-5 items

The Source attribute is common to many Status Displays. The attribute indicates the location at which an item resides.

The information show varies, depending on the type of item.

For IEC 60870-5 outstations, information is displayed in this format:

Link <Link Address>:Common <Common Address>

Example:

Link 26:Common 14
(For an outstation that has a Link Address of 26 and a Common Address of 14.)

For IEC 6087-5 points, information is displayed in this format:

Link <Link Address>:Common <Common Address>:<Point Type> IOA <Information Object Address>

Example:

Link 22:Common 11:AI IOA 3
(For an Analog Input point that has an Information Object Address (IOA) of 3. The point is on an outstation that has a Link Address of 22 and a Common Address of 11.)

For Digital points, the information is appended by the number of bits.

Example:

Link 22:Common 11:DI IOA 1 Bits 2
(For a Digital Input point that has an Information Object Address of 1. The point comprises 2 bits. Outstation details are as per the example above.)

The Source Attribute displays the type of IEC 60870-5 point using these abbreviations:
Abbreviation | Type of Point
AI | Analog Input Point
AO | Analog Output Point
DI | Digital Input Point
DO | Digital Output Point


IEC 60870-5 Driver Guide - Station Counter Interrogation Alarm (IEC 60870-5 Specific Status Display Attributes)

Station Counter Interrogation Alarm

Associated with: IEC 60870-5 outstations

This attribute indicates whether the latest Request, Freeze and/or Reset request for the outstation’s counters has failed (see Understand and Resolve Outstation Interrogation Alarms).

The frequency with which ClearSCADA attempts to execute the above requests is specified as part of the outstation’s configuration (see Configure the Counter Interrogation Intervals).

Possible states: Displays one of the Standard Alarm States.


IEC 60870-5 Driver Guide - Station Interrogation Alarm (IEC 60870-5 Specific Status Display Attributes)

Station Interrogation Alarm

Associated with: IEC 60870-5 outstations

This attribute indicates whether the latest attempt to scan the outstation for its current point data has failed (see Understand and Resolve Outstation Interrogation Alarms).

The frequency with which ClearSCADA attempts to scan the outstation for current point data is specified as part of the outstation’s configuration (see Configure the Station and Group Interrogation Intervals).

Possible states: Displays one of the Standard Alarm States.


IEC 60870-5 Driver Guide - Understand and Resolve Outstation Interrogation Alarms (IEC 60870-5 Specific Status Display Attributes)

Understand and Resolve Outstation Interrogation Alarms

ClearSCADA raises an interrogation alarm of the appropriate type (see IEC 60870-5 Outstation Status Attributes) when it either:

  • Fails to receive a valid termination message for an interrogation request that it has sent to an IEC 60870-5 outstation. (For instance, in response to a station interrogation request, group interrogation request, or a request for station or group counter data.)
  • Fails to receive an activation confirmation, in response to a station or group counter Reset or Freeze request.

Failure to receive such a termination or confirmation message from the outstation may occur for one of several reasons, including:

  • The outstation not supporting the interrogation command that ClearSCADA has sent.

Each IEC 60870-5 device has an interoperability Profile document that describes what functionality is provided. If the interrogation command is not supported, disable ClearSCADA from sending that type of interrogation request.

  • ClearSCADA timing out the request, because the outstation is taking longer than the expected time to return the data that ClearSCADA has requested. To rectify this, either:
  • Reduce the amount of data that the outstation is generating.
  • Increase the driver timeouts, in order to give the outstation longer to return its data.
  • ClearSCADA not receiving the expected sequence of events, due to an unusual network condition.

This should clear automatically the next time that the interrogation interval expires.

Further Information

Configure the Station and Group Interrogation Intervals.

Counter Operation Modes and Interrogation Requests.

Configure the Counter Interrogation Intervals.

Driver timeouts are configured using the ClearSCADA Server Configuration Tool (specifically the fields within the Timeouts part of the Drivers section—see Driver Settings in the ClearSCADA Guide to Server Administration).


IEC 60870-5 Driver Guide - System Analysis

System Analysis

This section is designed for use by system administrators and high-level engineers when assessing the state of the ClearSCADA system. It describes the statistical and diagnostic information provided specifically for the IEC 60870-5 driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

During system analysis, you might need to:

  • Adjust the Configuration of any IEC 60870-5 Points that Cause a High Load
  • Driver Logging Options that are Specific to the IEC 60870-5 Driver.

Additionally, if an outstation is not communicating with the server when it should be, see Troubleshooting in the ClearSCADA Guide to Advanced Drivers.

NOTE: When troubleshooting on a ClearSCADA system, examine the error messages in the Events List. The error messages may help you to identify the cause of any problems.

Further Information

Understand and Resolve Outstation Interrogation Alarms.


IEC 60870-5 Driver Guide - Adjust the Configuration of any IEC 60870-5 Points that Cause a High Load (System Analysis)

Adjust the Configuration of any IEC 60870-5 Points that Cause a High Load

By using the statistics that are shown in Lists and Status displays, you can determine whether any IEC 60870-5 outstations are causing a high load on the ClearSCADA system. A high load on the ClearSCADA server can lead to slow client performance (see Diagnose Client Performance Problems in the ClearSCADA Guide to the Server Status Tool).

Once you have identified any IEC 60870-5 outstations that are causing a high load, you can investigate which points on the outstation are contributing to the load issue. To do this, use the Points List. Typically, a high load on the server is cause by a point updating too frequently.

Where a point on an IEC 60870-5 outstation is causing a high load:

  1. If many of the points on the outstation are causing a high load, and Station Interrogation is used to regularly scan that outstation for current data, you may need to specify a less frequent interrogation rate (see Configure the Station and Group Interrogation Intervals).
  2. If the point is on an outstation that supports Group Interrogation, check which interrogation group the point is using. If this is causing the server to update the current point value at too frequent a rate, you may need to:
  • Specify a different interrogation group. (This is done at the outstation, rather than via ClearSCADA.)

or:

  • Specify a less frequent interrogation rate for the group (see Configure the Station and Group Interrogation Intervals).
  3. If none of the above checks and configuration changes have cleared the high load caused by the point, you should investigate:
  1. The configuration at the outstation.
  2. The outstation hardware for any faults.
  3. The plant for any faults.
  4. The instrumentation for any faults.


IEC 60870-5 Driver Guide - Driver Logging Options that are Specific to the IEC 60870-5 Driver (System Analysis)

Driver Logging Options that are Specific to the IEC 60870-5 Driver

Driver Logging is useful for investigating unexpected system behavior relating to drivers. It provides useful diagnostic information for specific aspects of the system. For instance, the Points logging option provides diagnostic information for the points on a particular driver.

Should you need to contact Schneider Electric for assistance with resolving a problem on your system, you might be asked to provide Log files to help in assessing the cause of the problem. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

This section explains the driver logging options that are specific to the IEC 60870-5 Driver.

Those driver logging options that are typically required for investigating driver problems are enabled by default. We suggest that the logging options are left at this default unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

For information on log files and defining the log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration.

For information on the driver logging options that are available for many advanced drivers, see Common Advanced Driver Log File Options in the ClearSCADA Guide to Advanced Drivers.

These driver logging options are specific to the IEC 60870-5 Driver:

  • IEC60870 Application Layer—Logs information relating to the state of the current IEC 60870-5 Application Layer.
  • IEC60870 Link Layer—Logs information relating to the state of the current IEC 60870-5 Link Layer.


IEC 60870-5 Phoenix Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


IEC 60870-5 Phoenix Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


IEC 60870-5 Phoenix Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


IEC 60870-5 Phoenix Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


IEC 60870-5 Phoenix Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


IEC 60870-5 Phoenix Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s IEC 60870-5 Phoenix driver. The driver is an IEC 60870-5 extension driver. The driver provides additional functionality to enable ClearSCADA to communicate with Phoenix Contact devices, using the IEC 60870-5-101 protocol.

For more details on the information included in this guide, see Introduction to the IEC 60870-5 Phoenix Driver.


IEC 60870-5 Phoenix Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for engineers who are responsible for configuring IEC 60870-5 Phoenix items and features in the ClearSCADA database.


IEC 60870-5 Phoenix Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


IEC 60870-5 Phoenix Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to the IEC 60870-5 Driver

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


IEC 60870-5 Phoenix Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


IEC 60870-5 Phoenix Driver Guide - Introduction to the IEC 60870-5 Phoenix Driver

Introduction to the IEC 60870-5 Phoenix Driver

The IEC 60870-5 Phoenix driver is an IEC 60870-5 extension driver. It provides additional functionality to enable ClearSCADA to communicate specifically with Phoenix Contact devices, using the IEC 60870-5-101 protocol over a PSTN or GSM connection. In order to communicate with such devices, your ClearSCADA system needs to be running both the IEC 60870-5 driver and the IEC 60870-5 Phoenix extension driver (see Confirm that the Required ClearSCADA Components are Installed). In addition, your Phoenix devices need to be running logic programs that enable those devices to communicate with ClearSCADA using the IEC 60870-5-101 protocol over PSTN.

Use this driver guide alongside the ClearSCADA Guide to the IEC 60870-5 Driver. As much of the information in the IEC 60870-5 driver guide is assumed knowledge, we recommend that you read the ClearSCADA Guide to the IEC 60870-5 Driver before reading this driver guide. When configuring Phoenix devices in ClearSCADA, you might also find it useful to have access to the interoperability Profile documents for both ClearSCADA and the Phoenix devices.

This ClearSCADA Guide to the IEC 60870-5 Phoenix Driver explains the Terminology of which you need to be aware, and provides detailed information on Configuring IEC 60870-5 Phoenix Devices in ClearSCADA.

For IEC 60870-5 specific aspects that are not covered in this guide, see the ClearSCADA Guide to the IEC 60870-5 Driver.


IEC 60870-5 Phoenix Driver Guide - Terminology (Introduction to the IEC 60870-5 Phoenix Driver)

Terminology

Throughout this guide, the term ‘outstation’ is used to refer to any Phoenix outstation, controller, or other Phoenix device that is used to obtain data from measuring instruments or sensors.

Throughout the ClearSCADA documentation suite ‘information objects’—the objects that can be monitored or controlled on an outstation—are referred to as ‘points’.

For information on this and other IEC 60870-5 terms with which you might need to be familiar in order to configure Phoenix and IEC 60870-5 specific settings in ClearSCADA, see IEC 60870-5 Terminology in the ClearSCADA Guide to the IEC 60870-5 Driver.


IEC 60870-5 Phoenix Driver Guide - Confirm that the Required ClearSCADA Components are Installed (Introduction to the IEC 60870-5 Phoenix Driver)

Confirm that the Required ClearSCADA Components are Installed

Before you add any IEC 60870-5 Phoenix items to ClearSCADA, you need to confirm that the IEC 60870-5 and Phoenix components are installed on the ClearSCADA servers on your system.

On each server on your system, use the Add/Remove Programs function in the Windows® Control Panel to see if the required ClearSCADA components are installed. The required components are:

  • IEC 60870-5
  • Phoenix PSTN

These components are located in the Server group, as shown below. (You may need to expand the IEC 60870-5 branch in order to display the Phoenix PSTN component.(

If either of the required components have an X on them, it means they are not currently installed. You will need to install them before you can configure ClearSCADA to communicate with IEC 60870-5 Phoenix devices (see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers).


IEC 60870-5 Phoenix Driver Guide - Configuring IEC 60870-5 Phoenix Devices in ClearSCADA (Introduction to the IEC 60870-5 Phoenix Driver)

Configuring IEC 60870-5 Phoenix Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the Phoenix devices with which ClearSCADA is to communicate using the IEC 60870-5-101 protocol.

To represent any such devices, the IEC 60870-5 driver (including the Phoenix PSTN component) has to be installed and running on the ClearSCADA servers on your system (see Confirm that the Required ClearSCADA Components are Installed).

When you configure IEC 60870-5 Phoenix items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant Phoenix devices on your system. Some settings are either fixed (incorporated into the design of the device), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the Phoenix devices on your system before you can configure the IEC 60870-5 Phoenix database items successfully.

Each IEC 60870-5 device, including ClearSCADA, has an interoperability Profile document that describes what functionality is provided. For each Phoenix device with which you want ClearSCADA to communicate using the IEC 60870-5-101 protocol, refer to that device’s interoperability Profile document to compare the supported features of that device against the IEC features that ClearSCADA supports (and that are listed as such in ClearSCADA’s interoperability Profile document). You also need to be aware of the address settings and any options that are set on your devices. You can then refer to this ClearSCADA Guide to the IEC 60870-5 Phoenix Driver and the ClearSCADA Guide to the IEC 60870-5 Driver for information on how to configure those features and options in ClearSCADA.

You also need to be aware of which optional features are required for each IEC 60870-5 Phoenix item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with IEC 60870-5 Phoenix database items, including Lists, Actions, and Mimics. For actions that are specific to IEC 60870-5 database items, see Using IEC 60870-5 Specific Actions in the ClearSCADA Guide to the IEC 60870-5 Driver. For further information on actions and details on Lists and Mimics, see the core documentation.

For each Phoenix device with which ClearSCADA is to communicate using the IEC 60870-5-101 protocol, you need to configure:

  1. An IEC 60870-5 Phoenix PSTN Channel to represent each telephone line connection between the ClearSCADA server and the Phoenix outstations on your system (see Configuring an IEC 60870-5 Phoenix PSTN Channel).
  2. An IEC 60870-5 Phoenix PSTN Outstation Set to define each group of Phoenix outstations (see Configuring an IEC 60870-5 Phoenix PSTN Outstation Set).
  3. An IEC 60870-5 Phoenix PSTN Outstation to represent each Phoenix outstation or similar Phoenix device that monitors data and/or controls plant (see Configuring an IEC 60870-5 Phoenix PSTN Outstation).
  4. An IEC 60870-5 Point to represent each analog or digital measuring instrument or control device that is connected to each IEC 60870-5 Phoenix PSTN outstation (see Points Used on IEC 60870-5 Phoenix PSTN Outstations, and see Points Used on IEC 60870-5 Outstations in the ClearSCADA Guide to the IEC 60870-5 Driver).

To minimize the time that it takes to configure the required database items, you may want to configure them in the order listed above, as outstation configuration requires you to specify a set, and point configuration requires you to specify an outstation, and so on. (With PSTN outstations, the association with a channel is only made during runtime.)

Further Information

Terminology.


IEC 60870-5 Phoenix Driver Guide - Configuring an IEC 60870-5 Phoenix PSTN Channel

Configuring an IEC 60870-5 Phoenix PSTN Channel

For each telephone line connection that exists for communications between the ClearSCADA server and the Phoenix outstations on your system, you need to configure an IEC 60870-5 Phoenix PSTN Channel item in the ClearSCADA database.

You configure the properties of each channel using the fields on the IEC 60870-5 Phoenix PSTN Channel Form. The Form has several tabs.

Use the fields on the PSTN Channel tab to:

  • Specify the IEC 60870-5 Communications Protocol.

Use the fields on the Scan Parameters tab to:

  • Configure the Scan Parameters—see Defining Scan Parameter Settings for a Channel in the ClearSCADA Guide to Advanced Drivers.
  • Specify when Communication Statistics are Updated—see Defining the Communication Statistics Update Rate in the ClearSCADA Guide to Advanced Drivers.
  • Specify any Pre- or Post-Ambles—see Defining any Default Pre- and Post-Amble Message Settings for a Channel in the ClearSCADA Guide to Advanced Drivers.

ATTENTION: The IEC 60870-5-101 protocol uses the hexadecimal digits 68 or 10 to indicate the start of a message (or hexadecimal E5 if the system uses single character acknowledgments). As such, we advise only using hexadecimal 68, 10, or E5 as a pre-amble where such a character is required by the transmission system and is not seen by the receiving device. Hexadecimal 68, 10, and E5 should not be used for pre- or post-amble ‘padding’.

The fields on other tabs are common to channels on many advanced drivers—for information, see Tabs on Channel Forms in the ClearSCADA Guide to Advanced Drivers.


IEC 60870-5 Phoenix Driver Guide - Specify the IEC 60870-5 Communications Protocol (Configuring an IEC 60870-5 Phoenix PSTN Channel)

Specify the IEC 60870-5 Communications Protocol

Use the Protocol Type field at the top of the PSTN Channel tab to specify the communications protocol that the Phoenix channel uses.

IEC 60870-5 Phoenix PSTN channels support the IEC 60870-5-101 protocol. This protocol is used for serial communications.

The fields within the IEC 60870-5-101 Parameters section of the tab are ‘grayed out’ and displayed for information only. Their values are fixed to those settings that are supported by Phoenix outstations. For more information on these fields, see Configure IEC 60870-5-101 Protocol Properties in the ClearSCADA Guide to the IEC 60870-5 Driver.


IEC 60870-5 Phoenix Driver Guide - Configuring an IEC 60870-5 Phoenix PSTN Outstation Set

Configuring an IEC 60870-5 Phoenix PSTN Outstation Set

In ClearSCADA, each IEC 60870-5 Phoenix PSTN outstation has to be associated with an IEC 60870-5 Phoenix PSTN outstation set.

An IEC 60870-5 Phoenix PSTN outstation set is a database item that represents a ‘logical collection’ of associated IEC 60870-5 Phoenix outstations. For example, an IEC 60870-5 Phoenix PSTN outstation set could be used to form a collection of IEC 60870-5 Phoenix outstations according to:

  • Their geographical location
  • Whether you want ClearSCADA to be able to dial the outstations more frequently (as you can promote dial out to all of the outstations in a set).

When you have created an IEC 60870-5 Phoenix PSTN outstation set item in the database, you can configure it by using the IEC 60870-5 Phoenix PSTN Set Form.

There are no driver-specific properties on IEC 60870 Phoenix outstation sets. The fields on the tabs are common to outstation sets on many advanced drivers—see Tabs on Outstation Set Forms in the ClearSCADA Guide to Advanced Drivers.


IEC 60870-5 Phoenix Driver Guide - Configuring an IEC 60870-5 Phoenix PSTN Outstation

Configuring an IEC 60870-5 Phoenix PSTN Outstation

For each Phoenix outstation or similar Phoenix device with which you want ClearSCADA to communicate using the IEC 60870-5-101 protocol, you need to configure an IEC 60870-5 Phoenix PSTN Outstation in the ClearSCADA database.

You configure the properties of each outstation using the IEC 60870-5 Phoenix PSTN Outstation Form. The Form has several tabs.

Use the IEC 60870-5 tab to:

  • Specify the IEC 60870-5 properties. These properties are common to many outstations that communicate with ClearSCADA using the IEC 60870-5 protocol (see Configuring an IEC 60870-5 Outstation in the ClearSCADA Guide to the IEC 60870-5 Driver).

Each response packet from a Phoenix outstation contains only a single data value. This limits the outstation to reporting about four data values a second when connected via a standard modem. A general interrogation of an outstation that contains a moderate number of points will therefore take some time to complete. For this reason, we recommend that the Station and Group n Interrogation Intervals, and the Counter Interrogation Intervals are set to 0. This configures the outstation so that it is only interrogated at the start of communications and whenever a Refresh of the outstation’s data is requested.

Use the Phoenix tab to:

  • Specify the Master and Outstation Passwords
  • Specify the Operations that ClearSCADA Performs when it Receives an Incoming Call.

Use the PSTN tab to:

  • Specify the Common PSTN Properties (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers)
  • Configure any Dial In Lines (see Define Dial In Line Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers).

Phoenix outstations support up to three Dial In Lines to report alarm data to ClearSCADA.

  • Configure the Dial In Overactive Properties (see Define Dial In Overactive Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers).

The fields on other tabs are common to outstations on many advanced drivers—see Tabs on Outstation Forms in the ClearSCADA Guide to Advanced Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional IEC 60870-5 Phoenix outstation, see Minimum Configuration.


IEC 60870-5 Phoenix Driver Guide - Minimum Configuration (Configuring an IEC 60870-5 Phoenix PSTN Outstation)

Minimum Configuration

For an IEC 60870-5 Phoenix PSTN Outstation to be functional (online), you need to specify these properties (as a minimum):

  • The telephone number of the site on which the outstation is located (PSTN tab)
  • The Set to which the outstation belongs (Outstation tab)
  • The outstation’s Common Address (IEC 60870-5 tab)
  • The Master Password (Phoenix tab)
  • The Outstation Password (Phoenix tab).

You also need to put the outstation In Service and save the configuration.

This will result in a functional outstation that uses the default configuration settings.


IEC 60870-5 Phoenix Driver Guide - Specify the Master and Outstation Passwords (Configuring an IEC 60870-5 Phoenix PSTN Outstation)

Specify the Master and Outstation Passwords

Use the fields at the top of the Phoenix tab to specify the passwords that are required for communications between ClearSCADA and this particular Phoenix outstation:

  • Master Password—Enter the password that ClearSCADA is to send to the outstation, whenever it establishes communications with that outstation. The outstation uses the password to identify the SCADA master. On successful receipt of the Master Password, the outstation will respond by sending its Outstation Password.
  • Outstation Password—Enter the password that the outstation sends to ClearSCADA whenever ClearSCADA establishes communications with that outstation, or whenever the outstation dials in to the server. ClearSCADA uses the password to identify the outstation.

Each password has to be between 1 and 20 ASCII characters long. Refer to the Phoenix product documentation for further information.


IEC 60870-5 Phoenix Driver Guide - Specify the Operations that ClearSCADA Performs when it Receives an Incoming Call (Configuring an IEC 60870-5 Phoenix PSTN Outstation)

Specify the Operations that ClearSCADA Performs when it Receives an Incoming Call

Use the check boxes within the Incoming Call section of the Phoenix tab to specify which operations ClearSCADA is to perform whenever it is contacted by this particular outstation:

  • Station Interrogation—Select this check box if ClearSCADA is to request all current point data from the outstation, whenever the outstation dials in to the server.

Clear the check box if the server is to only request the outstation’s current point data at the next scheduled interval (see Configure the Station and Group Interrogation Intervals in the ClearSCADA Guide to the IEC 60870-5 Driver).

  • Station Counter Interrogation—Select this check box if ClearSCADA is to request all counter point values from the outstation, whenever the outstation dials in to the server.

Clear the check box if the server is to only request counter data at the next scheduled interval (see Configure the Counter Interrogation Intervals in the ClearSCADA Guide to the IEC 60870-5 Driver).

  • Set Clock—Select this check box if ClearSCADA is to set the outstation’s clock, whenever the outstation dials in to the server.

Clear the check box if the server is to only set the outstation’s clock whenever the server initiates communications, rather than the outstation.

  • Retrieve Historic Data—Select this check box if ClearSCADA is to retrieve all of the available historic data from the outstation, whenever the outstation dials in to the server.

Ensure that the check box is clear if the server is to only retrieve historic data whenever the server initiates communications, rather than the outstation.

Remember that ClearSCADA only stores IEC 60870-5 point data historically if:

  • The relevant point(s) have Historic enabled (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration)
  • The point is an input point, and the point’s Historic Data Filter check boxes have been used to specify the type of data that ClearSCADA is to store historically for that point (see Specify the Type of Point Data that ClearSCADA is to Store Historically in the ClearSCADA Guide to the IEC 60870-5 Driver).


IEC 60870-5 Phoenix Driver Guide - Points Used on IEC 60870-5 Phoenix PSTN Outstations

Points Used on IEC 60870-5 Phoenix PSTN Outstations

Throughout the ClearSCADA documentation suite ‘information objects’—the objects that can be monitored or controlled on an outstation—are referred to as ‘points’. You create and configure different types of point in ClearSCADA, to represent the different types of information object on each outstation or other Phoenix device.

Within ClearSCADA you need to configure one IEC 60870-5 Point of the appropriate type for each information object that ClearSCADA is to monitor or control. There are no Phoenix-specific points in ClearSCADA, instead you create and configure the appropriate type of IEC 60870-5 point and assign that point to the relevant IEC 60870-5 Phoenix PSTN outstation.

For information on the types of point that the IEC 60870-5 Phoenix driver supports and how to configure those points, see Points Used on IEC 60870-5 Outstations in the ClearSCADA Guide to the IEC 60870-5 Driver.

Phoenix outstations have a fixed interpretation of the IEC 60870-5 ‘Cause of Transmission’ indicators. As such, ClearSCADA ignores any configuration within the Cause of Transmission Interpretation section of an input point’s Form, if that point is associated with an IEC 60870-5 Phoenix PSTN outstation. With points on Phoenix outstations:

  • Values that are returned with an Interrogation ‘Cause of Transmission’ indicator are used to update the point’s current value in the database, regardless of whether the value has changed.
  • Values that are returned with a Spontaneous ‘Cause of Transmission’ indicator are treated as value changes.
  • Values that are returned with either a Background, or Periodic/Cyclic ‘Cause of Transmission’ indicator are logged and processed as Timed Report values.

For more information, see Specify how ClearSCADA Interprets an Input Point’s Cause of Transmission in the ClearSCADA Guide to the IEC 60870-5 Driver.

NOTE: If a Phoenix device supports counter data, map that data to IEC 60870-5 Analog Point(s) in the ClearSCADA database, in order to use that data within ClearSCADA.


IEC 60870-5 SLAVE Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


IEC 60870-5 SLAVE Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


IEC 60870-5 SLAVE Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


IEC 60870-5 SLAVE Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


IEC 60870-5 SLAVE Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


IEC 60870-5 SLAVE Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s IEC 60870-5 Slave driver. The IEC 60870-5 Slave driver enables ClearSCADA to act as an IEC 60870-5 Controlled Station (outstation or RTU) and report any data changes back to its Controlling Station (SCADA master). The driver enables ClearSCADA to communicate with the SCADA master using either the IEC 60870-5-101 or IEC 60870-5-104 protocol.

For more details on the information included in this guide, see Introduction to the IEC 60870-5 Slave Driver.

NOTE: For information on how to configure ClearSCADA as an IEC 60870-5 Controlling Station (SCADA master), see the ClearSCADA Guide to the IEC 60870-5 Driver.


IEC 60870-5 SLAVE Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring IEC 60870-5 Slave items and features in the ClearSCADA database.

The guide also contains information for maintenance engineers.


IEC 60870-5 SLAVE Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


IEC 60870-5 SLAVE Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration.


IEC 60870-5 SLAVE Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


IEC 60870-5 SLAVE Driver Guide - Introduction to the IEC 60870-5 Slave Driver

Introduction to the IEC 60870-5 Slave Driver

The slave functionality that is built into the IEC 60870-5 Driver allows a ClearSCADA system to act as an IEC 60870-5 Controlled Station (outstation) and report any data changes back to its Controlling Station (SCADA master station). The slave transmits any changes to its database, or sets values or states in its database, upon request from the SCADA master.

The slave can obtain its data directly from plant, from calculated values, or from any item in the ClearSCADA database. Its SCADA master can be another ClearSCADA server, or a third party server that is using either the IEC 60870-5-101, or IEC 60870-5-104 protocol.

The IEC 60870-5 Driver provides extra functionality within a ClearSCADA server for transmitting data or setting points upon request from an IEC 60870-5 master. When configured as an IEC 60870-5 slave, ClearSCADA uses Filtered Value Maps for mapping point properties into memory, so that they can be accessed using the IEC 60870-5-101, or IEC 60750-5-104 protocol.

This guides summarizes the IEC 60870-5 Terminology of which you need to be aware, and provides detailed information on Configuring IEC 60870-5 Slave Devices in ClearSCADA.

It also explains the IEC 60870-5 slave statistics and diagnostic features. System administrators and engineers may find these features useful when investigating unexpected behavior relating to the IEC 60870-5 driver (see IEC 60870-5 Slave Specific Status Display Attributes).

NOTE: There are no driver-specific pick actions for slave items on the IEC 60870-5 driver. However, users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

NOTE: This guide explains how to configure ClearSCADA as an IEC 60870-5 Controlled Station (outstation or RTU). For information on how to configure ClearSCADA as an IEC 60870-5 Controlling Station (SCADA Master), see the ClearSCADA Guide to the IEC 60870-5 Driver.


IEC 60870-5 SLAVE Driver Guide - IEC 60870-5 Terminology (Introduction to the IEC 60870-5 Slave Driver)

IEC 60870-5 Terminology

This section summarizes the IEC 60870-5 terms with which you might need to be familiar, in order to configure IEC 60870-5 slave specific properties in ClearSCADA. These terms include:

  • APDU
  • ASDU
  • Controlled Station
  • Controlling Station
  • IEC 60870-5
  • Information Object
  • IOA.

Further Information

IEC 60870-5-101

IEC 60870-5-104.


IEC 60870-5 SLAVE Driver Guide - APDU (Introduction to the IEC 60870-5 Slave Driver)

APDU

An Application Protocol Data Unit (APDU) typically comprises an ASDU along with application protocol control information. However, when communicating using the IEC 60870-5-101 or IEC 60870-5-104 protocol, no application protocol control information is required, and therefore the ASDU and APDU are one and the same.


IEC 60870-5 SLAVE Driver Guide - ASDU (Introduction to the IEC 60870-5 Slave Driver)

ASDU

An Application Service Data Unit (ASDU) is a block of data that is sent from the Controlling Station (SCADA master) to an outstation or other device (such as ClearSCADA), or vice versa, using the IEC 60870-5 protocol.


IEC 60870-5 SLAVE Driver Guide - Controlled Station (Introduction to the IEC 60870-5 Slave Driver)

Controlled Station

A Controlled Station is a station such as an outstation, a slave (such as ClearSCADA), or a Remote Terminal Unit (RTU) that is monitored and/or controlled by a Controlling Station.

On a ClearSCADA system that is running as an IEC 60870-5 slave, the ClearSCADA server is a controlled station.

Through the ClearSCADA documentation suite, a controlled station is referred to as an outstation.


IEC 60870-5 SLAVE Driver Guide - Controlling Station (Introduction to the IEC 60870-5 Slave Driver)

Controlling Station

A Controlling Station is the SCADA master station at which telecontrol of the Controlled Stations (outstations, or other slave devices, such as ClearSCADA) is performed.

Throughout this guide, the controlling station is referred to as the SCADA master.


IEC 60870-5 SLAVE Driver Guide - IEC 60870-5 (Introduction to the IEC 60870-5 Slave Driver)

IEC 60870-5

Throughout this guide, any device (for example, a slave outstation) that communicates with a SCADA master using either the IEC 60870-5-101 protocol, or the IEC 60870-5-104 protocol is referred to as an ‘IEC 60870-5 device’.

Similarly, any input or output on such a device is referred to as an ‘IEC 60870-5 point’.

Every IEC 60870-5 device has an interoperability Profile document that describes what functionality is provided. You need access to this document, or need to be aware of which functions each device supports, when configuring IEC 60870-5 slave items in ClearSCADA. (For more information, see Configuring IEC 60870-5 Slave Devices in ClearSCADA.)


IEC 60870-5 SLAVE Driver Guide - Information Object (Introduction to the IEC 60870-5 Slave Driver)

Information Object

The IEC 60870-5 protocol uses the term ‘information object’ to refer to an input or output on an outstation or other controlled device.

Throughout the ClearSCADA documentation suite an information object is referred to as a point.

On a ClearSCADA system that is running as an IEC 60870-5 slave, Filtered Value Maps are used to map ‘point’ data onto Information Objects, in order for the Controlling Station (SCADA master) to extract the required data. For more information, see Specify the Filtered Value Maps that Store the Source Data.


IEC 60870-5 SLAVE Driver Guide - IOA (Introduction to the IEC 60870-5 Slave Driver)

IOA

Each input or output on an IEC 60870-5 outstation or other controlled device has an Information Object Address (IOA). This address is used to uniquely identify each item on the device and is transmitted in each ASDU that includes information about that particular input or output.


IEC 60870-5 SLAVE Driver Guide - Configuring IEC 60870-5 Slave Devices in ClearSCADA (Introduction to the IEC 60870-5 Slave Driver)

Configuring IEC 60870-5 Slave Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the IEC 60870-5 slave devices on your system.

In order to represent any such devices, the IEC 60870-5 Driver has to be installed and running on the ClearSCADA servers on your system.

When you configure IEC 60870-5 slave items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant IEC 60870-5 devices on your system. Some settings are either fixed (incorporated into the design of the device), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the IEC 60870-5 devices on your system before you can configure the IEC 60870-5 slave database items successfully.

Each IEC 60870-5 device, including ClearSCADA, has an interoperability Profile document that describes what functionality is provided. For each Controlling Station (SCADA master station) that is to communicate with ClearSCADA using the IEC 60870-5-101 or IEC 60870-5-104 protocol, refer to that device’s interoperability Profile document to compare the supported features of that device against the IEC features that ClearSCADA supports (and that are listed as such in ClearSCADA’s interoperability Profile document). You also need to be aware of the address settings and any options that are set on your devices. You can then refer to this ClearSCADA Guide to the IEC 60870-5 Slave Driver for information on how to configure those features and options in ClearSCADA.

You also need to be aware of which optional features are required for each IEC 60870-5 slave item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with IEC 60870-5 slave database items, including Lists, Actions, and Mimics. See the core documentation for details.

For each IEC 60870-5 slave device that ClearSCADA is to represent, you need to configure:

  1. IEC 60870-5 Slave Direct Channel(s) to represent the communication connections between ClearSCADA and the IEC 60870-5 Master (see Configuring an IEC 60870-5 Slave Channel).
  2. An IEC 60870-5 Slave Direct Outstation Set to define each group of slave outstations that share the same communications channel (see Configuring an IEC 60870-5 Slave Outstation Set).
  3. Filtered Value Map(s) for mapping ‘point’ properties onto Information Objects so that they can be accessed by the slave’s Master (see Specify the Filtered Value Maps that Store the Source Data, and see Configuring Value Maps in the ClearSCADA Guide to Core Configuration).
  4. One or more IEC 60870-5 Slave Direct Outstation(s) with which the IEC 60870-5 Master may communicate, in order to obtain data from ClearSCADA (see Configuring an IEC 60870-5 Slave Outstation).
  5. If required, one or more IEC 60870-5 Slave Logical Outstation(s) to enable the IEC 60870-5 Master, for example, to read the data from some Filtered Value Maps independently from other Filtered Value Maps (see Configuring an IEC 60870-5 Slave Outstation).

Slave Logical outstation(s) might be used, for example:

  • to divide the data that is sent to the SCADA master into blocks that represent specific physical devices

or:

  • to extend the number of points (Information Objects) that can be sent to a SCADA master. (If, for example, a channel only supports a 1-byte IOA, a single Slave outstation will only be able to report 255 points.)

To minimize the time that it takes to configure the required IEC 60870-5 slave items, you may want to configure them in the order listed above, as Outstation configuration requires that you specify an Outstation Set and the Value Maps that hold the ‘point’ data, and Set configuration requires that you specify a channel.


IEC 60870-5 SLAVE Driver Guide - Configuring an IEC 60870-5 Slave Channel

Configuring an IEC 60870-5 Slave Channel

ClearSCADA can communicate with an IEC 60870-5 Controlling Station (SCADA master station) using either of two IEC 60870-5 protocols (see Supported IEC 60870-5 Communication Protocols).

For either communications protocol, you need to configure one or more IEC 60870-5 Slave Direct Channel(s) in the ClearSCADA database.

You configure the properties of each channel using the fields on the IEC 60870-5 Slave Direct Channel Form.

The Form has several tabs.

Use the fields on the IEC 60870-5 tab to:

  • Specify the IEC 60870-5 Communications Protocol.

then either Configure IEC 60870-5-101 Protocol Properties, or Configure IEC 60870-5-104 Protocol Properties, depending on the chosen protocol.

Use the fields on the Scan Parameters tab to:

  • Configure the Scan Parameters—see Defining Scan Parameter Settings for a Channel in the ClearSCADA Guide to Advanced Drivers
  • Specify when Communication Statistics are Updated—see Defining the Communication Statistics Update Rate in the ClearSCADA Guide to Advanced Drivers
  • Specify any Pre- or Post-Amble Settings—see Defining any Default Pre- and Post-Amble Message Settings for a Channel in the ClearSCADA Guide to Advanced Drivers.

ATTENTION: The IEC 60870-5-101 protocol uses 68 to indicate the start of a message. As such, we advise only using 68 as a Pre-Amble where such a character is required by the transmission system, and not to use 68 for Pre- or Post-Amble ‘padding’.

NOTE: The Scan Groups fields and the second set of Scan Parameters fields defined by the ClearSCADA advanced driver model are not used by the ClearSCADA IEC 60870-5 driver. Any configuration in these fields is ignored by ClearSCADA.

For information on configuring the fields on the Connection tab, see IEC 60870-5-101, or see IEC 60870-5-104, as appropriate.

The fields on the other tabs are common to channels on many advanced drivers—for information, see Tabs on Channel Forms in the ClearSCADA Guide to Advanced Drivers.


IEC 60870-5 SLAVE Driver Guide - Supported IEC 60870-5 Communication Protocols (Configuring an IEC 60870-5 Slave Channel)

Supported IEC 60870-5 Communication Protocols

The ClearSCADA IEC 60870-5 driver supports the following IEC 60870-5 communication protocols:

  • IEC 60870-5-101
  • IEC 60870-5-104.


IEC 60870-5 SLAVE Driver Guide - IEC 60870-5-101 (Configuring an IEC 60870-5 Slave Channel)

IEC 60870-5-101

The IEC 60870-5-101 protocol is a serial based communications protocol. The protocol is designed for use on systems that use permanent direct connections between the Controlling Station (SCADA master) and the Controlled Station(s) (outstations or slaves, including ClearSCADA).

Communications can be either:

  • Balanced—whereby there is a one-to-one full duplex connection between a channel and an individual slave outstation
  • Unbalanced—whereby there is a half-duplex connection between a channel and one or more slave outstations (for instance, in a multi-drop setup). With unbalanced communications, it is also possible for other slaves (not necessarily ClearSCADA slave outstations) to be connected to the transmission media to which the channel is connected.

For more information on either of the above transmission procedures, see Configure IEC 60870-5-101 Protocol Properties.

When communicating using the IEC 60870-5-101 protocol, a channel will typically have a Serial Connection Type (specified on the Connection tab of the IEC 60870-5 Slave Direct Channel Form) and use these settings:

  • Data Bits—Should be set to 8 bits.
  • Parity—Should be Even, to comply with the IEC 60870-5 standard.

If no parity is used (for instance, if the communications media does not support parity), be aware that this increases the likelihood of an error going undetected.

  • Flow Control—Generally specify None to comply fully with the IEC 60870-5 standard. However, be aware that some form of Flow Control may be required by transmission media that is not fully compatible with the IEC 60870-5 standard.

(Specify a different Connection Type if the serial interface is not directly connected to ClearSCADA—for more information, see Tabs on Channel Forms in the ClearSCADA Guide to Advanced Drivers.)

You also need to Configure IEC 60870-5-101 Protocol Properties on the IEC 60870-5 tab.


IEC 60870-5 SLAVE Driver Guide - IEC 60870-5-104 (Configuring an IEC 60870-5 Slave Channel)

IEC 60870-5-104

The IEC 60870-5-104 protocol can be used to provide TCP/IP communication between a Controlling Station (SCADA master) and Controlled Station(s) (outstations or slaves, including ClearSCADA). Stations that are IEC 60870-5-104 compliant have an Internet Transport Interface between the Application and lower layers.

In order for ClearSCADA to communicate using the IEC 60870-5-104 protocol, specify these settings on the Connection tab of the IEC 60870-5 Direct Channel Form:

  • Connection Type: Network
  • TCP/IP Type: TCP
  • Listen Port: 2404 (to comply with the IEC 60870-5-104 standard, although the driver allows other ports to be used if necessary).

and then Configure IEC 60870-5-104 Protocol Properties on the IEC 60870-5 tab.

For more information on Network communications, see Configure a Channel’s Network Connection Properties in the ClearSCADA Guide to Drivers.


IEC 60870-5 SLAVE Driver Guide - Specify the IEC 60870-5 Communications Protocol (Configuring an IEC 60870-5 Slave Channel)

Specify the IEC 60870-5 Communications Protocol

Use the Protocol Type field at the top of the IEC 60870-5 tab to specify which communications protocol is used by the channel:

Choose from:

  • IEC 60870-5-101 —The channel is used for serial communications.

If you select this option, you also need to Configure IEC 60870-5-101 Protocol Properties for the channel.

  • IEC 60870-5-104 —The channel is used for TCP/IP communications.

If you select this option, you also need to Configure IEC 60870-5-104 Protocol Properties for the channel.

For more information on the IEC 60870-5-101 and IEC 60870-5-104 protocols, see Supported IEC 60870-5 Communication Protocols.


IEC 60870-5 SLAVE Driver Guide - Configure IEC 60870-5-101 Protocol Properties (Configuring an IEC 60870-5 Slave Channel)

Configure IEC 60870-5-101 Protocol Properties

When a Slave Channel is configured to use an IEC 60870-5-101 Protocol Type (see Specify the IEC 60870-5 Communications Protocol), you need to configure these properties on the IEC 60870-5 tab:

  • Link Address Size—Use the combo box to specify the number of octets that are used to transmit the link address in each Application Service Data Unit (ASDU).

If the Transmission Procedure is Unbalanced, specify the Link Address Size that corresponds to the size of the Link Address that is to be used by the slave outstation(s) on this channel. Specify 1 Octet or 2 Octets, as appropriate. (You specify each slave outstation’s Link Address using the Link Address field on the Slave Direct Outstation Form (see Configure the IEC 60870-5-101 Parameters).)

If the Transmission Procedure is Balanced (see below), the Link Address is optional, as the address is not needed to identify the slave outstation (ClearSCADA). Therefore, with a Balanced transmission you can optionally specify 0 Octets.

  • Allow Single Character Acknowledgment—The IEC 60870-5-101 protocol defines two types of message that the SCADA master, or Controlling Station, can send to a slave to acknowledge the receipt of a data packet.

One message is a single-byte response. This is an efficient type of response, although it may be received spuriously if there is electromagnetic noise on the line.

The other type of message is a response that contains between four and six bytes (depending on the Link Address Size). This response is less efficient, but is appropriate on channels that are operating in an environment that has electromagnetic noise.

  • Select the Allow Single Character Acknowledgment check box if there is no electromagnetic noise. You should also select the check box if the SCADA master is to send a single-byte message to the slave outstation (ClearSCADA), in response to each data packet that the SCADA master receives successfully.
  • Clear the Allow Single Character Acknowledgment check box if the SCADA master is to send four- to six-byte acknowledgment messages in response to each data packet that it receives successfully from the slave outstation (ClearSCADA).
  • Transmission Procedure—Use to specify the transmission procedure that applies to the channel. Select the option that applies to your system setup:
  • Unbalanced—The SCADA master controls the data traffic on this channel by scanning the channel’s outstations sequentially. The SCADA master initiates transmissions via the channel. None of the outstations on the channel can initiate transmissions—instead, they can transmit data only in response to a poll from the SCADA master.
  • Balanced—The channel is used for point-to-point communications, whereby the SCADA master uses the channel to communicate with a single slave outstation. With a Balanced transmission procedure, the slave outstation (ClearSCADA) can initiate communications with the SCADA master.
  • Test Link Interval—Only applies if the Transmission Procedure is Balanced.

With a Balanced transmission, there may be long periods of time during which no data is transmitted. The slave outstation (ClearSCADA) can transmit test frames at specified intervals to determine whether the channel is still available.

Use the Test Link Interval to specify the maximum amount of time, in seconds, that the Link Layer can remain idle, before the slave outstation is to send a test link frame to the SCADA master.

Specify 0 if the slave outstation (ClearSCADA) is not to send any test link frames via this channel.


IEC 60870-5 SLAVE Driver Guide - Configure IEC 60870-5-104 Protocol Properties (Configuring an IEC 60870-5 Slave Channel)

Configure IEC 60870-5-104 Protocol Properties

When a Slave Channel is configured to use an IEC 60870-5-104 Protocol Type (see Specify the IEC 60870-5 Communications Protocol), you need to configure these properties on the IEC 60870-5 tab:

  • APDU Timeout (t1)—Use to specify the maximum amount of time, in seconds, that the slave outstation (ClearSCADA) waits for a transmitted Application Protocol Data Unit (APDU) to be confirmed as received by the SCADA master.
  • APDU Acknowledge Timeout (t2)—Use to specify the maximum amount of time that the slave outstation (ClearSCADA) can remain idle after receiving an APDU, before it has to send a response to the SCADA master to indicate that it has received the APDU successfully.
  • Idle Timeout (t3)—Use to set the slave outstation to transmit a test frame at specified intervals (via the channel). By transmitting a test frame, the slave outstation can determine if the channel is still available after a prolonged period of communications inactivity (no data being sent via the channel).

Use the Idle Timeout field to specify the maximum amount of time, in seconds, that the Link Layer can remain idle. If the Link Layer is idle for longer than the Idle Timeout, the slave outstation will send a test link frame to an outstation on this channel.

  • Maximum Transmitted APDUs (k)—Specify the maximum number of unconfirmed APDUs that the slave outstation (ClearSCADA) is to transmit via this channel, before it waits for acknowledgment from the SCADA master that those APDUs have been received successfully.
  • Maximum Received APDUs (w)—Specify the maximum number of APDUs that the slave outstation can receive on this channel, before it sends confirmation that it has received those APDUs successfully.


IEC 60870-5 SLAVE Driver Guide - Configuring an IEC 60870-5 Slave Outstation Set

Configuring an IEC 60870-5 Slave Outstation Set

When using IEC 60870-5 slave outstations, you need to create one or more IEC 60870-5 Slave Direct Outstation Sets. ClearSCADA uses the IEC 60870-5 Slave Direct Outstation Sets as a way of determining which IEC 60870-5 outstations communicate via a specific direct channel. The Slave Direct Outstation Set ‘groups’ the outstations that use a defined channel (specified in the configuration of the outstation set).

However, with certain IEC 60870-5 protocols, an outstation set can only contain one slave outstation. For this reason, the number of IEC 60870-5 Slave Direct Outstation Sets you need to configure is dependent on the number of slave outstations on your system and the IEC 60870-5 protocols they use for communicating with the SCADA master:

You need to configure one IEC 60870-5 Slave Direct Outstation Set for each IEC 60870-5 slave outstation that:

  • Communicates with the SCADA master using the IEC 60870-5-104 protocol

or

  • Uses the IEC 60870-5-101 protocol for Balanced transmissions.

This is because slave outstations that use these protocols cannot be grouped with other outstations (and so each slave outstation requires its own slave direct outstation set).

If you have IEC 60870-5 slave outstations that communicate with the SCADA master using the IEC 60870-5-101 protocol with Unbalanced transmissions:

  • Configure one IEC 60870-5 Slave Direct Outstation Set for each serial port (to which the IEC 60870-5 slave outstations connect)

When you have created an IEC 60870-5 Slave Direct Outstation Set, you will need to configure it using the fields on the IEC 60870-5 Slave Direct Outstation Set Form (see Configuring an Outstation Set in the ClearSCADA Guide to Advanced Drivers).

There are no driver-specific properties on IEC 60870-5 Slave Outstation Sets.

Further Information

For information on specifying the Transmission Procedure on channels that communicate using the IEC 60870-5-101 protocol, see Configure IEC 60870-5-101 Protocol Properties.


IEC 60870-5 SLAVE Driver Guide - Configuring an IEC 60870-5 Slave Outstation

Configuring an IEC 60870-5 Slave Outstation

This section covers the configuration of IEC 60870-5 Slave outstations—outstations that allow ClearSCADA to operate as an IEC 60870-5 Controlled Station (outstation). When ClearSCADA is configured as an IEC 60870-5 slave, it appears as a Controlled Station to an IEC 60870-5 Controlling Station (SCADA master station).

The SCADA master station accesses the data in the ClearSCADA database by communicating with one or more of the following ClearSCADA database items:

  • IEC 60870-5 Slave Direct Outstation—An outstation that is permanently connected to its SCADA master via, for example, a cable, network, or a continuous radio signal.

An IEC 60870-5 Slave Direct Outstation can be independent, or can be a ‘parent’ outstation for one or more IEC 60870-5 Slave Logical Outstations (see below). When an IEC 60870-5 Slave Direct Outstation is a ‘parent’ outstation, the SCADA master can issue station interrogation commands to interrogate both the ‘parent’ and any associated Logical outstations.

  • IEC 60870-5 Slave Logical Outstation—A Logical outstation represents a separate logical sector that is associated with an IEC 60870-5 Slave Direct Outstation. Each IEC 60870-5 Slave Logical Outstation has its own Common Address and can be read independently from other logical sectors by the SCADA master.

Configure a separate Slave Logical Outstation for each set of Value Maps that a SCADA master is to read separately from other Value Maps. You might want to use Slave Logical outstation(s), for example, to:

  • divide the data that is sent to the SCADA master into blocks that represent specific physical devices

or:

  • extend the number of points (Information Objects) that can be sent to the SCADA master. (If, for example, a channel only supports a 1-byte IOA, a single Slave outstation will only be able to report 255 points.)

You use the Parent Outstation field on the Slave Logical Outstation Form’s Remote tab to Specify a Slave Logical Outstation’s Parent Outstation. The ‘parent’ outstation has to be an IEC 60870-5 Slave Direct Outstation.

You configure each outstation’s properties using the fields on the IEC 60870-5 Slave Direct Outstation Form, or the IEC 60870-5 Slave Logical Outstation Form, as appropriate.

Each Form has several tabs.

Use the Value Maps tab to:

  • Specify the Filtered Value Maps that Store the Source Data.

Use the IEC 60870-5 tab to:

  • Configure the Common Address.

On an IEC 60870-5 Slave Direct Outstation that communicates using the IEC 60870-5-101 protocol, also use the IEC 60870-5 tab to:

  • Configure the IEC 60870-5-101 Parameters.

On an IEC 60870-5 Slave Direct Outstation that communicates using the IEC 60870-5-104 protocol, use the Network tab to specify the Host Address and Port (see Define an Outstation’s Network Properties in the ClearSCADA Guide to Advanced Drivers). (Port number 2404 is the TCP and UDP port that is registered for IEC 60870-5-104 use with the IANA (Internet Assigned Numbers Authority).)

On an IEC 60870-5 Slave Logical Outstation, use the Remote tab to:

  • Specify a Slave Logical Outstation’s Parent Outstation.

The fields on other tabs are common to outstations on many advanced drivers—for information, see Tabs on Outstation Forms in the ClearSCADA Guide to Advanced Drivers.


IEC 60870-5 SLAVE Driver Guide - Configure the Common Address (Configuring an IEC 60870-5 Slave Outstation)

Configure the Common Address

Use the Common Address field at the top of the IEC 60870-5 tab to specify a slave outstation’s common address.

For outstations that communicate using the IEC 60870-5-101 protocol, the address range varies, depending on the Common Address Size (see Configure the IEC 60870-5-101 Parameters):

  • If the Common Address Size is 1 Octet, you can specify a Common Address in the range 0 to 254 inclusive.
  • If the Common Address Size is 2 Octets, you can specify a Common Address in the range 0 to 65534 inclusive.

Outstations that communicate using the IEC 60870-5-104 protocol have a Common Address Size of 2 Octets, and an address range of 0 to 65534 inclusive.

If you are configuring an IEC 60870-5 Slave Direct Outstation that is a ‘parent’ of one or more IEC 60870-5 Slave Logical outstations, you need to:

  • Define a unique Common Address for the ‘parent’ outstation
  • Define unique Common Addresses for each of the ‘parent’ outstation’s Logical outstations.

With Slave Direct outstations that communicate using the IEC 60870-5-101 protocol, each outstation’s Link Address is used in conjunction with its Common Address to identify the outstation (see Configure the IEC 60870-5-101 Parameters).


IEC 60870-5 SLAVE Driver Guide - Configure the IEC 60870-5-101 Parameters (Configuring an IEC 60870-5 Slave Outstation)

Configure the IEC 60870-5-101 Parameters

The fields within the IEC 60870-5-101 Parameters section of the IEC 60870-5 tab apply to IEC 60870-5 Slave Direct Outstations that communicate with ClearSCADA using the IEC 60870-5-101 protocol. (To communicate with ClearSCADA using the IEC 60870-5-101 protocol, the channel through which the outstation communicates has to be configured to use the IEC 60870-5-101 Protocol Type (see Specify the IEC 60870-5 Communications Protocol).)

Use the fields within the IEC 60870-5-101 Parameters section of the IEC 60870-5 tab to configure the protocol properties that are specific to that slave outstation.

  • Link Address—Use to define the Link address of the slave outstation. The valid range varies, depending on the channel’s Link Address Size (see Configure IEC 60870-5-101 Protocol Properties).

If the Link Address Size is 1 Octet, the valid Link Address range is 0 to 254 inclusive.

If the Link Address Size is 2 Octets, the valid Link Address range is 0 to 65534 inclusive.

The Link Address is optional if the outstation is on a channel that uses a Balanced Transmission Procedure (see Configure IEC 60870-5-101 Protocol Properties). ClearSCADA ignores any configuration in the outstation’s Link Address field if the channel’s Link Address Size is set to 0 Octets.

  • Cause of Transmission Size—Each Application Service Data Unit (ASDU) includes an indication as to the ‘cause’ of the transmission. An ASDU might be transmitted, for example, as a result of a Control request, or due to periodic scanning of the slave outstation. Use the Cause of Transmission Size combo box to specify whether the cause is transmitted as 1 Octet, or 2 Octets.

(A slave outstation that communicates using the IEC 60870-5-104 protocol uses 2 octets to indicate the cause of a transmission.)

  • Common Address Size—The Common Address is used to identify the outstation on which each item of point data is located (see Configure the Common Address). The Common Address is transmitted in each ASDU.

Use the Common Address Size combo box to specify whether the Common Address is transmitted as 1 Octet, or 2 Octets. (The valid range for the Common Address varies, depending on the Common Address Size—see Configure the Common Address.)

  • Information Object Address Size—Each input and output on a slave outstation has an Information Object Address (IOA). The address is associated with the Filtered Value Map that is used to map the ‘point’ data. It used to uniquely identify each item on the slave outstation and is transmitted in each ASDU that includes information about that particular input or output.

Use the Information Object Address Size combo box to specify whether this address is transmitted as 1 Octet, 2 Octets, or 3 Octets. (The valid range within which the First IOA on each Filtered Value Map has to occur varies, depending on the number of octets specified in this field—see Specify the Filtered Value Maps that Store the Source Data.)

(An outstation that communicates using the IEC 60870-5-104 protocol has an Information Object Address Size of 3 octets.)


IEC 60870-5 SLAVE Driver Guide - Specify the Filtered Value Maps that Store the Source Data (Configuring an IEC 60870-5 Slave Outstation)

Specify the Filtered Value Maps that Store the Source Data

Throughout the ClearSCADA documentation suite ‘Information Objects’—the objects that can be monitored or controlled on an outstation—are referred to as ‘points’. IEC 60870-5 slave outstations use Filtered Value Maps to store ‘point’ data. The source of the Filtered Value Map data typically comes from another source, such as another IEC 60870-5 device. The data is mapped into ClearSCADA in order to enable the Controlling Station(s) to extract the required data from that device, using the IEC 60870-5-101 or IEC 60870-5-104 protocol.

You need to specify the Filtered Value Maps that each slave outstation uses, and the location of those Filtered Value Maps within the ClearSCADA database. Before you can do this, you need to have created the required Filtered Value Maps on your system and configured them appropriately.

To determine which type(s) of Filtered Value Map need to be created, you need to know:

  • The type of point data that each slave outstation is to store
  • The ASDU format(s) that both ClearSCADA and the SCADA master(s) support and are to use
  • The type of Filtered Value Map that applies to each of those ASDU formats and point types.

The IEC 60870-5 protocol defines a number of ASDU formats (Types 1 to 15) that can be used for transmitting input or counter data. ClearSCADA supports the odd-numbered ASDU types within this range. (ClearSCADA also supports ASDU Types 30 to 37, which it uses for transmitting the same type of data with a 56-bit time stamp. Whenever events are generated for a Value Map, the slave transmits the data using the appropriate ASDU Type 30 to 37, rather than Type 1 to 15.) Refer to the SCADA master’s interoperability Profile document for information on which ASDU formats the SCADA master supports. For information on which type of Filtered Value Map applies to each ASDU format, see Specify the Status Value Maps.

The IEC 60870-5 protocol also defines a number of ASDU formats (Types 45 to 51) that are associated with output data. Again, refer to the SCADA master’s interoperability Profile document for information on which ASDU formats the SCADA master supports. For information on which type of Filtered Value Map applies to each ASDU format, see Specify the Control Value Maps.

For information on configuring Filtered Value Maps, see Configuring Value Maps in the ClearSCADA Guide to Core Configuration.

Once the Filtered Value Maps have been created and suitably configured on your system, you can associate those Value Maps with the relevant slave outstation. To do this, you use the fields on the Value Maps tab of the appropriate IEC 60870-5 Slave Outstation Form to define the Filtered Value Maps that a particular slave outstation uses.

The Value Maps tab contains fields that enable you to:

  • Specify the Status Value Maps
  • Specify the Control Value Maps.


IEC 60870-5 SLAVE Driver Guide - Specify the Status Value Maps (Configuring an IEC 60870-5 Slave Outstation)

Specify the Status Value Maps

Use the fields within the Status Value Maps section of the Value Maps tab to specify the Filtered Value Maps that store the input data for this slave outstation. The Filtered Value Maps that store a slave outstation’s data have to exist on your system before you can use the fields below to map to such data. (For more information, see Specify the Filtered Value Maps that Store the Source Data, and see Configuring Value Maps in the ClearSCADA Guide to Core Configuration.)

  • Single Point (ASDU Type 1)—Specify the Filtered Value Map that is used to store single-bit input values. Use the browse button to display a Reference browse window and select the required Filtered BIT Value Map from the window.
  • Double Point (ASDU Type 3)—Specify the Filtered Value Map that is used to store the 2-bit input values that represent, for example, the present state of a switch or valve. Use the browse button to display a Reference browse window and select the required Filtered BYTE Value Map from the window.
  • Step Position (ASDU Type 5)—Specify the Filtered Value Map that is used to store the 2-bit input values that represent the present step position on a transformer. Use the browse button to display a Reference browse window and select the required Filtered DINT Value Map from the window.
  • Bit String (ASDU Type 7)—Specify the Filtered Value Map that is used to store 32-bit string input values. Use the browse button to display a Reference browse window and select the required Filtered UDINT Value Map from the window.
  • Measured Value Normalized (ASDU Type 9)—Specify the Filtered Value Map that is used to store ‘normalized’ analog input values (input values that are restricted to the range -1 to +1). Use the browse button to display a Reference browse window and select the required Filtered REAL Value Map from the window.
  • Measured Value Scaled (ASDU Type 11)—Specify the Filtered Value Map that is used to store scaled analog input values (input values that are in the range -32678 to +32767). Use the browse button to display a Reference browse window and select the required Filtered DINT Value Map from the window.
  • Measured Value Floating Point (ASDU Type 13)—Specify the Filtered Value Map that is used to store IEEE single-precision (32-bit) floating point input values. Use the browse button to display a Reference browse window and select the required Filtered REAL Value Map from the window.
  • Integrated Total (ASDU Type 15)—Specify the Filtered Value Map that is used to store counter values. Use the browse button to display a Reference browse window and select the required Filtered DINT Value Map from the window.

Leave the fields blank for any Status Value Map types that are not used by this slave outstation.

For each Filtered Value Map that you specify, use the corresponding First IOA field to specify the address of the first input on that Value Map:

  • First IOA—Each input on a slave outstation has an Information Object Address (IOA). This address is used to uniquely identify each item on the outstation and is transmitted in each ASDU that includes information about that particular input.

Use the First IOA field adjacent to a Filtered Value Map field to specify the IOA address of the first input on that particular Value Map.

For outstations that communicate using the IEC 60870-5-101 protocol, the valid range for this address varies, depending on the size that is specified for this address on the IEC 60870-5 tab of the Outstation Form (see Configure the IEC 60870-5-101 Parameters). (For Slave Logical outstations, the address is specified on the parent outstation’s Form.)

  • If the Information Address Size is 1 Octet, the valid Information Object Address range is 1 to 255 inclusive.
  • If the Information Address Size is 2 Octets, the valid Information Object Address range is 1 to 65535 inclusive.
  • If the Information Address Size is 3 Octets, the valid Information Object Address range is 1 to 16777215 inclusive.

An outstation that communicates using the IEC 60870-5-104 protocol has an Information Address Size of 3 Octets and therefore has a valid address range of 1 to 16777215 inclusive.

In each case, Address 0 on the Filtered Value Map represents the IOA that you specify in the First IOA field for that Value Map; Address 1 represents the next consecutive IOA, and so on.


IEC 60870-5 SLAVE Driver Guide - Specify the Control Value Maps (Configuring an IEC 60870-5 Slave Outstation)

Specify the Control Value Maps

Use the fields within the Control Value Maps section of the Value Maps tab to specify the Filtered Value Maps that store the output data for this slave outstation. The Filtered Value Maps that store a slave outstation’s data have to exist on your system before you can use the fields below to map to such data. (For more information, see Specify the Filtered Value Maps that Store the Source Data, and see Configuring Value Maps in the ClearSCADA Guide to Core Configuration.)

  • Single Command (ASDU Type 45)—Specify the Filtered Value Map that is used to store single-bit output values. Use the browse button to display a Reference browse window and select the required Filtered BIT Value Map from the window.
  • Double Command (ASDU Type 46)—Specify the Filtered Value Map that is used to store 2-bit output values. A Double Command is typically used for a switch or valve, with state 1 representing the ‘Off’ state and state 2 the ‘On’ state.

Use the browse button to display a Reference browse window and select the required Filtered BYTE Value Map from the window.

  • Regulating Step Command (ASDU Type 47)—Specify the Filtered Value Map that is used to store 2-bit output step values. A Regulating Step Command is typically used to step up or down a transformer, with state 1 typically being used to represent ‘Next Step Lower’ and state 2 ‘Next Step Higher’.

Use the browse button to display a Reference browse window and select the required Filtered BYTE Value Map from the window.

  • Analog Normalized Command (ASDU Type 48)—Specify the Filtered Value Map that is used to store ‘normalized’ analog output values (values that are restricted to the range -1 to +1). Use the browse button to display a Reference browse window and select the required Filtered REAL Value Map from the window.
  • Analog Scaled Command (ASDU Type 49)—Specify the Filtered Value Map that is used to store scaled analog output values (values that are in the range -32678 to +32767). Use the browse button to display a Reference browse window and select the required Filtered DINT Value Map from the window.
  • Analog Float Command (ASDU Type 50)—Specify the Filtered Value Map that is used to store IEEE single-precision (32-bit) floating point output values. Use the browse button to display a Reference browse window and select the required Filtered REAL Value Map from the window.
  • Bit String Command (ASDU Type 51)—Specify the Filtered Value Map that is used to store 32-bit string output values. Use the browse button to display a Reference browse window and select the required Filtered UDINT Value Map from the window.

Leave the fields blank for any Control Value Map types that are not used by this slave outstation.

The Control Value Maps section also includes fields that you use to specify the:

  • First IOA—Each output on a slave outstation has an Information Object Address (IOA). This address is used to uniquely identify each item on the outstation and is transmitted in each ASDU that includes information about that particular output.

Use the First IOA field adjacent to a Filtered Value Map field to specify the IOA address of the first output on that particular Value Map. In each case, Address 0 on the Filtered Value Map represents the IOA that you specify in the First IOA field for that Value Map; Address 1 represents the next consecutive IOA, and so on.

For outstations that communicate using the IEC 60870-5-101 protocol, the valid range for this address varies—for more information, see the First IOA field details within Specify the Status Value Maps.


IEC 60870-5 SLAVE Driver Guide - Specify a Slave Logical Outstation's Parent Outstation (Configuring an IEC 60870-5 Slave Outstation)

Specify a Slave Logical Outstation’s Parent Outstation

Each IEC 60870-5 Slave Logical Outstation on a ClearSCADA system represents a separate physical device or logical sector associated with an IEC 60870-5 Slave Direct Outstation (see Configuring an IEC 60870-5 Slave Outstation).

Use the Parent Outstation field on the Remote tab of the IEC 60870-5 Slave Logical Outstation Form to specify the IEC 60870-5 Slave Direct Outstation that is the Logical outstation’s ‘parent’ outstation. Use the field’s browse button to display a Reference browse window and select the required IEC 60870-5 Slave Direct Outstation from the window. (An IEC 60870-5 Slave Direct Outstation can be the ‘parent’ for multiple IEC 60870-5 Slave Logical Outstations.)

ATTENTION: Be aware that should the SCADA master lose communications with the parent slave outstation, it will also lose communications with any Logical outstations on that outstation.


IEC 60870-5 SLAVE Driver Guide - IEC 60870-5 Slave Specific Status Display Attributes

IEC 60870-5 Slave Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each IEC 60870-5 Slave Direct Outstation provides information about the present state of the individual outstation.

Many of the attributes on IEC 60870-5 slave Status displays are common to many drivers, however, the information displayed by the Source attribute differs, depending on the driver and the type of item to which the attribute refers.

This section describes the Source attribute information that is displayed for slave items on the IEC 60870-5 driver (see IEC 60870-5 Slave Source Attribute).

Further Information

Working with Status displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


IEC 60870-5 SLAVE Driver Guide - IEC 60870-5 Slave Source Attribute (IEC 60870-5 Slave Specific Status Display Attributes)

IEC 60870-5 Slave Source Attribute

Associated with: IEC 60870-5 Slave Outstations

The Source attribute is common to many Status Displays. The attribute indicates the location at which an item resides.

The information show varies, depending on the type of item.

For IEC 60870-5 slave outstations, information is displayed in this format:

Link <Link Address>:Common <Common Address>

Example:

Link 64:Common 53
(For a slave outstation that has a Link Address of 64 and a Common Address of 53.)


Kingfisher Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Kingfisher Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Kingfisher Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Kingfisher Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Kingfisher Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Kingfisher Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s Kingfisher driver. The Kingfisher driver enables ClearSCADA to communicate with Kingfisher RTUs using the Kingfisher protocol.

For more details on the information included in this guide, see Introduction to the Kingfisher Driver.


Kingfisher Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring Kingfisher items and features in the ClearSCADA database.

The guide also contains information for:

  • Operators and engineers who use the Kingfisher driver to monitor and control plant
  • Maintenance engineers.


Kingfisher Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Kingfisher Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Lists

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Server Status Tool.


Kingfisher Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Kingfisher Driver Guide - Introduction to the Kingfisher Driver

Introduction to the Kingfisher Driver

Kingfisher Remote Telemetry Units (RTUs) or outstations are used to monitor data and provide operator interaction. They are used on systems in a variety of industries, including water distribution, waste water, oil and gas.

The Kingfisher Driver allows the ClearSCADA system to communicate with Kingfisher outstations, either directly or remotely. It provides the server with extra functionality for interacting with the instruments and devices that are connected to each outstation.

You can configure ClearSCADA to communicate directly with multiple Kingfisher outstations. Alternatively, you can set up ClearSCADA to communicate with multiple Kingfisher outstations via a Kingfisher master outstation (a Master/Remote setup).

In a Master/Remote setup:

  • The Master obtains its data from either a single Remote, or several Remotes that are multidropped together.
  • A Remote transmits the contents of its database to its Master outstation, upon request or change of state.

The Kingfisher driver in ClearSCADA allows you to configure Master/Remote scenarios that communicate using the Kingfisher protocol (see Typical Master/Remote Scenarios).

To communicate with Kingfisher outstations via a Kingfisher Master outstation, ClearSCADA uses:

  • A Kingfisher Master database item to represent the master outstation. The data for this item is the local data for the master outstation, not the data reported by the remote outstations.
  • A Kingfisher Remote database item for each remote device that transmits data to the Kingfisher Master. The data for the Kingfisher Remote items is the data that the remote devices transmit to the Kingfisher Master (and is stored on the Kingfisher Master).

The Kingfisher Driver documentation explains how to configure Kingfisher-specific features and items within the ClearSCADA database (see Configuring Kingfisher Devices in ClearSCADA).

It also explains:

  • Kingfisher features that are of interest to operators (see Using Kingfisher Specific Actions)
  • Kingfisher-specific aspects that may be of interest to system administrators and engineers when investigating unexpected system behavior:
  • Kingfisher Eavesdropping Arrangement
  • Kingfisher Specific Status Display Attributes
  • System Analysis.


Kingfisher Driver Guide - Configuring Kingfisher Devices in ClearSCADA (Introduction to the Kingfisher Driver)

Configuring Kingfisher Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant and measuring instruments on your system. This section summarizes the database items that you need to configure to represent the Kingfisher devices on your system.

In order to represent any Kingfisher devices, the Kingfisher Driver has to be installed and running on the ClearSCADA servers on your system. When the driver is first installed, a system administrator needs to define the server settings for the driver (see Configuring Kingfisher Server Settings).

When you configure Kingfisher items in the ClearSCADA database, many of the properties of those items need to correspond to the settings of the relevant Kingfisher devices on your system. Some settings are either fixed (incorporated into the design of the Kingfisher outstation), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the Kingfisher devices on your system before you can configure the Kingfisher database items successfully.

The items that you need to configure vary, depending whether you require a Master device (see Kingfisher Master Configuration), or a Remote device (see Kingfisher Remote Configuration).

For instance, for Kingfisher Master configuration, you need to know whether the points on your Kingfisher outstations are physical (Hardware) points, or internal (Register) points. You also need to know the slot number or Register address of each point.

You also need to be aware of which optional features are required for each Kingfisher item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with Kingfisher database items, including Lists, Actions, and Mimics. For actions that are specific to the Kingfisher driver, see Using Kingfisher Specific Actions. For further information on actions and details on Lists and Mimics, see the core documentation.


Kingfisher Driver Guide - Kingfisher Master Configuration (Introduction to the Kingfisher Driver)

Kingfisher Master Configuration

For each Kingfisher Master, you need to configure:

  1. Kingfisher Channels to represent the communication connections between the Master Kingfisher outstation and its Remote outstation(s) (see Configuring a Kingfisher Channel).
  2. Kingfisher Outstation Sets to define groups of Master outstations that share the same communications media (see Configuring a Kingfisher Outstation Set).
  3. A Kingfisher Master Outstation to define the unit that monitors data and controls the Remote outstations (see Configuring a Kingfisher Outstation).

For more information on how a Kingfisher Master outstation communicates with Kingfisher Remote outstations, see Kingfisher Master Outstation with Remote Outstations.

  4. Kingfisher Remote Outstations for each unit that monitors data and controls plant. These units transmit their data to a Kingfisher Master outstation (see Configuring a Kingfisher Outstation)
  5. Kingfisher Points to represent the analog and digital measuring instruments and control devices that are connected to the Kingfisher outstations (see Points Used on Kingfisher Outstations). You will need to configure database points for the inputs and outputs on the Kingfisher Master outstation, as well as the inputs and outputs on the Kingfisher Remote outstations.

To minimize the time that it takes to configure the required Kingfisher items, you may want to configure them in the order listed above. This is because set configuration requires you to specify a channel, outstation configuration requires you to specify a set, and so on.

Further Information

Scanning Direct Outstations on the Kingfisher Driver.


Kingfisher Driver Guide - Kingfisher Remote Configuration (Introduction to the Kingfisher Driver)

Kingfisher Remote Configuration

For each Kingfisher Remote, you need to configure a Remote Kingfisher Outstation to define the unit that monitors data and control plant (see Configuring a Kingfisher Outstation).

Each Kingfisher Remote communicates with a Kingfisher Master. You need to set up one suite of Kingfisher Master Configuration (see Kingfisher Master Configuration) for each Master-to-Outstation network. For an example of a Master/Remote setup, see Kingfisher Master Outstation with Remote Outstations.


Kingfisher Driver Guide - Typical Master/Remote Scenarios (Introduction to the Kingfisher Driver)

Typical Master/Remote Scenarios

This section gives three typical scenarios in which Kingfisher devices could be used with a ClearSCADA system:

  • Kingfisher Outstation Communicating Directly with ClearSCADA
  • Kingfisher Master Outstation with Remote Outstations
  • Kingfisher Master Outstation using a Shared Outstation Set.

You can use the scenarios as a guide when you are configuring your own ClearSCADA system.

It is beyond the scope of this document to describe each possible scenario in which Kingfisher outstations could be used.


Kingfisher Driver Guide - Kingfisher Outstation Communicating Directly with ClearSCADA (Introduction to the Kingfisher Driver)

Kingfisher Outstation Communicating Directly with ClearSCADA

Using the Kingfisher protocol, the ClearSCADA system can act as a Kingfisher Master and poll a Kingfisher outstation.

For this scenario, within ClearSCADA you need to configure a Kingfisher Channel (as appropriate to the type of communications being used), a Kingfisher Outstation Set, and a Kingfisher Outstation. You also need to configure points in the database, to correspond to the points in the Kingfisher outstation. For further information, see Kingfisher Master Configuration.

Example:

In the diagram below, ClearSCADA is using the Kingfisher protocol to communicate with a Kingfisher outstation. The points configured for the Kingfisher outstation in the ClearSCADA database correspond to the points that reside in that outstation.


Kingfisher Driver Guide - Kingfisher Master Outstation with Remote Outstations (Introduction to the Kingfisher Driver)

Kingfisher Master Outstation with Remote Outstations

Where ClearSCADA uses the Kingfisher protocol to retrieve data from more than one outstation, ClearSCADA can send and receive the network data via a systems RTU Master. For this scenario, you need to configure one Kingfisher Master Outstation for each Master-to-Outstation network.

Within ClearSCADA you need to configure a Kingfisher Channel, a Kingfisher Outstation Set, and a Kingfisher Master Outstation. In addition, for each device from which the Master is obtaining its data using Kingfisher, you need to configure a Kingfisher Remote Outstation, and database points to correspond to the points in each of those devices (see Kingfisher Master Configuration).

The Address for each Kingfisher Master Outstation and Remote Outstation must be unique on the system.

Example:

In the diagram below, a Kingfisher Master retrieves its data from a Remote. Kingfisher Remote Outstations are configured in the ClearSCADA database—the first representing the properties required to communicate between the Master outstation and the first Remote outstation; the second representing the properties required to communicate between the Master outstation and the second Remote outstation, and so on. (For each Remote outstation on the network, a Remote outstation must be configured in ClearSCADA.)


Kingfisher Driver Guide - Kingfisher Master Outstation using a Shared Outstation Set (Introduction to the Kingfisher Driver)

Kingfisher Master Outstation using a Shared Outstation Set

One of the features of the ClearSCADA driver is the Shared Outstation Set. A Shared Outstation Set is used where ClearSCADA, using the Kingfisher protocol, is configured have a standby direct channel as a backup communications to the main Master outstation, or to a Redundant outstation.

For this scenario, you need to configure a Kingfisher Shared Outstation Set that is referenced by two separate Direct Channels. The Master and Remote outstations on the network must be configured to be a Kingfisher Shared Master Outstation and a Kingfisher Shared Outstation respectively. You need to configure a Kingfisher Shared Outstation for each device from which the Master obtains its data using the Kingfisher protocol, and database points to correspond to the points in each of those devices (see Kingfisher Master Configuration).

The Address for each Kingfisher Shared Master Outstation and Shared Outstation must be unique on the system.

The shared channels are configured to have different methods of communication to the Master outstation. The Shared Outstation Set has a priority A or B that references the two separate shared channels. If the communications Line A fails, then the communications to the Master outstation switches over to the Line B option to communicate.

Example:

In the diagram below, ClearSCADA is retrieving its information from a Kingfisher Master Outstation that is using the primary communications Line A ‘Ethernet’.

If the Ethernet fails, then the communications will swap to the RS-232 serial communications port, which has been designated as Line B.


Kingfisher Driver Guide - Kingfisher Eavesdropping Arrangement (Introduction to the Kingfisher Driver)

Kingfisher Eavesdropping Arrangement

Eavesdropping allows a new system to run in parallel with an existing system in order to test the new system’ s configuration. The Kingfisher protocol uses an Rx eavesdropping arrangement.

Due to the flexible nature of the Kingfisher protocol, if you want to eavesdrop to a third-party server, we recommend that you contact Schneider Electric beforehand to confirm compatibility with ClearSCADA.

For more information on eavesdropping, see Using Eavesdropping to Test a New Server’s Configuration in the ClearSCADA Guide to Advanced Drivers.


Kingfisher Driver Guide - Configuring Kingfisher Server Settings

Configuring Kingfisher Server Settings

Some driver-specific settings need configuring on the server by a system administrator when a ClearSCADA system is first installed. These settings are configured using the ClearSCADA Server Configuration Tool. This section explains the Kingfisher driver-specific settings that need specifying using this tool.

For information on running the ClearSCADA Server Configuration Tool, see Configuring Advanced Driver Server Settings in the ClearSCADA Guide to Advanced Drivers.

NOTE: If you make configuration changes on a ClearSCADA server, you also need to make the same changes on any other ClearSCADA servers on your system. This is because the servers need to have matching configuration settings. The only exception to this rule is Permanent Standby servers - you only need to apply the changes to Permanent Standby servers if you have changed the PSTN Connection Types.

When the Kingfisher driver is first installed on a ClearSCADA system, a system administrator needs to:

  1. Specify the System ID.
  2. Specify the Communications Re-Establishment Delay.
  3. Specify any additional PSTN Connection Types (see PSTN Connection Types in the ClearSCADA Guide to Advanced Drivers).
  4. Apply the changes to the server (see Configuring Advanced Driver Server Settings in the ClearSCADA Guide to Advanced Drivers).
  5. Either:
  • If the server is currently running as the main server, restart the Kingfisher driver for the changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).
  • If the server is not currently running as the main server, go to step 6.
  6. Repeat steps 1 to 5 for each of the servers on your system. (You only need to repeat the steps on any permanent standby servers if you make changes to the PSTN Connection Types.)


Kingfisher Driver Guide - Specify the System ID (Configuring Kingfisher Server Settings)

Specify the System ID

The System ID is a synchronization character that is used within the Kingfisher network. By default, the ID is 174 (AE in hexadecimal notation). If your network uses a different System ID, change the ID in the System ID field accordingly.


Kingfisher Driver Guide - Specify the Communications Re-Establishment Delay (Configuring Kingfisher Server Settings)

Specify the Communications Re-Establishment Delay

Use the Delay while outstation performs a reset field to specify the delay between resetting a Kingfisher outstation and restarting communications.

The delay stops any messages from being sent to the outstation while it is in the process of resetting, then establishing communications with the server.


Kingfisher Driver Guide - Scanning Direct Outstations on the Kingfisher Driver

Scanning Direct Outstations on the Kingfisher Driver

The Kingfisher driver enables ClearSCADA to communicate with Kingfisher outstations either directly or remotely (see Configuring a Kingfisher Outstation).

This section summarizes aspects of outstation interrogation that are specific to the Kingfisher driver and that apply when ClearSCADA is configured to communicate with a Kingfisher outstation directly, using a permanent connection such as a cable, network, or a continuous radio signal. Use this section in conjunction with the advanced drivers scanning information (see Scanning Direct Outstations in the ClearSCADA Guide to Advanced Drivers).

(With Remote Kingfisher outstations (systems on which a Kingfisher Master outstation communicates with one or more Remote outstations), ClearSCADA retrieves the Master outstation’s copy of each Remote outstation’s data when it scans the Master outstation. If required, you can set up a Confidence Scan Interval to specify the interval with which the Kingfisher driver retrieves the Master outstation’s copy of the Remote outstation’s data, regardless of whether that data has changed (see Define the Remote Outstation Properties).)

Refer to the following sections for information on:

  • Scanning Periods and Scan Phases
  • System Scan Termination
  • Scan Quality Factor
  • Outstation Promotion.

The process of retrieving data differs on those Kingfisher outstations for which ClearSCADA uses a dial-up modem and telephone line for communications (‘PSTN communications’). For information on scanning outstations with this type of connection, see Retrieving Data from PSTN Outstations in the ClearSCADA Guide to Advanced Drivers.


Kingfisher Driver Guide - Scanning Periods and Scan Phases (Scanning Direct Outstations on the Kingfisher Driver)

Scanning Periods and Scan Phases

This section includes detailed information about scanning direct outstations on the Kingfisher driver. The section explains these processes and features:

  • System Scan Interval
  • Primary Normal Phase
  • Secondary Normal Phase.

If required, you can configure individual polling intervals and offsets on any direct outstations that the Kingfisher driver is not required to poll (scan) continuously—see Specify the Polling Intervals and Offset.

For further information on scanning direct outstations, see Scanning Process in the ClearSCADA Guide to Advanced Drivers.


Kingfisher Driver Guide - System Scan Interval (Scanning Direct Outstations on the Kingfisher Driver)

System Scan Interval

A complete scan of the outstations on a channel typically consists of two phases:

  • A Primary Phase, during which the driver retrieves the current data from the configured points on the outstations (see Primary Normal Phase).
  • A Secondary Phase, that follows the Primary Phase, during which the driver retrieves any time stamped data that has been logged by the outstations (see Secondary Normal Phase).

However, when the ClearSCADA server has not been in, or has regained, communications with an outstation, it typically performs an Establishment Phase scan in place of a Primary Phase scan (see Establishment Phase in the ClearSCADA Guide to Advanced Drivers).

The driver retrieves any time stamped logged data from the outstations.
The driver retrieves any current point data from the outstations.

With either phase, the driver scans the outstations on the channel in outstation Address order, starting with the lowest address. (The exception to this is any outstations that are configured with individual polling intervals and offsets and for which the driver is not required to scan the outstation at that particular time (see Specify the Polling Intervals and Offset).)

During the Primary Normal Phase or Establishment Phase of a scan, in addition to point data, the Kingfisher driver also retrieves status information about each connected outstation. You can view this information via the outstation’s Status display (see Kingfisher Specific Status Display Attributes).

Example:

During the Secondary Phase of the scan, and within the time remaining for the System Scan, as many outstations as possible are scanned for logged data.

The System Scan Interval defines the maximum duration of a System Scan under normal scanning conditions. This time may be exceeded under exceptional scanning conditions, for example on system start-up, where the Primary Phase of the first system scan contains the current data from the outstations that are scanned by a channel (see Establishment Phase in the ClearSCADA Guide to Advanced Drivers).

Specify the interval using the System Scan field on the Form(s) for the Channel(s) via which each outstation communicates (see Define the Permitted Scan Durations). When defining the System Scan, you need to consider the Recommended Settings for Scan Durations.

You also need to specify:

  • The time that you expect a complete (Primary and Secondary Phase) scan to take (see Acceptable Scan Interval)
  • The minimum amount of time that the driver should take to complete the secondary phase of a scan (see Minimum Secondary Scan Interval).

Acceptable Scan Interval

Use the Acceptable Scan Interval to define the maximum acceptable time period for the completion of the Primary and Secondary scans. If the scans exceed the Acceptable Scan time, then the Quality Factor (if used) is decreased by 1 (see Quality Factor).

Specify the interval using the Acceptable Scan field on the Form(s) for the Channel(s) via which each outstation communicates (see Define the Permitted Scan Durations). When defining the Acceptable Scan, you need to consider the Recommended Settings for Scan Durations.

For an example that uses an Acceptable Scan Interval, see Quality Factor.

Minimum Secondary Scan Interval

Use the Minimum Secondary Scan Interval to define the least amount of time in which secondary data extraction can take place per System Scan.

If the System Scan time expires and this minimum period has not elapsed then the scan time will be extended to accommodate the extra time required to achieve the Minimum Secondary Scan time.

If all of the available logged data is retrieved before the minimum period has elapsed, then the Secondary Phase completes.

Specify the interval using the Minimum Secondary Scan field on the Form(s) for the Channel(s) via which each outstation communicates (see Define the Permitted Scan Durations). When defining the Minimum Secondary Scan, you need to consider the Recommended Settings for Scan Durations.

Example:

A driver scans four direct outstations that communicate with the server via a particular channel. The outstations have addresses 3, 4, 5, and 6.

The driver firstly scans the outstations on the channel for current data (the Primary Phase of the scan). As the scan starts, the System Scan time starts to elapse.

Once the current point data has been retrieved from the four outstations, the driver scans the outstations for any logged data (the Secondary Phase of the scan). However, the Primary Phase in this instance has left less System Scan time remaining then has been defined as the minimum time for a Secondary Phase. Therefore, the scan time is extended until the Minimum Secondary Scan time has elapsed.

As the time remaining for the Secondary Phase of this System Scan is less than the Minimum Secondary Scan Interval...
...the scan time is extended until the Minimum Secondary Scan time has elapsed.


Kingfisher Driver Guide - Primary Normal Phase (Scanning Direct Outstations on the Kingfisher Driver)

Primary Normal Phase

The Primary Normal Phase of a System Scan is used to retrieve the current data of configured points from connected outstations. During the Primary Normal Phase, current data is retrieved from every connected outstation, except for those outstations that:

  • are configured with individual polling intervals and offsets

and

  • are not due to be scanned by the driver at that particular time (see Specify the Polling Intervals and Offset).

Outstations are scanned for primary data in ascending outstation number order starting from the lowest outstation address. During the Primary Normal Phase, the driver will only visit an outstation once for extracting data. However, a number of protocol exchanges may take place per visit.

The Primary Normal Phase runs until it has scanned the appropriate outstations for current data. In exceptional circumstances, this may cause the Primary Phase to exceed the System Scan time (see System Scan Interval). For example, the Primary Phase may exceed the System Scan time when system is first started (see Establishment Phase in the ClearSCADA Guide to Advanced Drivers).


Kingfisher Driver Guide - Secondary Normal Phase (Scanning Direct Outstations on the Kingfisher Driver)

Secondary Normal Phase

The Secondary Normal Phase of a System Scan is used to extract logged data from as many outstations as possible in the available time. Each set of transactions (visits) with an outstation will be limited to a maximum user configurable duration known as the Maximum Secondary Scan per Outstation time (see Maximum Secondary Phase Time).

Outstations are scanned for secondary data in ascending outstation number order. Unlike the Primary Normal Phase, the time available to retrieve secondary data during a system scan is limited - the Secondary Normal Phase cannot continue if the System Scan time expires.

If the Secondary Normal Phase is incomplete when the System Scan time expires, the Secondary Normal Phase is suspended (see System Scan Interval). On subsequent System Scans, secondary data extraction will continue from where it was suspended on the previous scan.

Maximum Secondary Phase Time

During the Secondary Phase Time, ClearSCADA attempts to scan those outstations that have secondary data available. Rather than scan each outstation for all secondary data, it ‘visits’ each outstation for a certain amount of time. During a ‘visit’, ClearSCADA retrieves as much secondary data as possible. At the end of the ‘visit’ it moves on to the next outstation. The maximum duration of a ‘visit’ is called the Maximum Secondary Scan per O/S.

The Maximum Secondary Scan per O/S allows ClearSCADA to use the Secondary Phase Time to scan a range of outstations. It is particularly effective when there are outstations with large amounts of secondary data available, as it stops ClearSCADA from using all of the available time scanning one outstation.

As long as ClearSCADA has completed a secondary scan of the outstations that have secondary data, it should be able to ‘re-visit’ the outstations. During the ‘re-visit’, ClearSCADA will attempt to retrieve any remaining secondary data (see Re-Visiting of Outstations During the Secondary Normal Phase).

To specify the Maximum Secondary Scan per O/S setting, you need to use the Channel Form. The time limit you specify will apply to each of the outstations that communicate via that channel. For more information, see Define the Permitted Scan Durations. Before specifying a time limit, you should also consider Recommended Settings for Scan Durations.

Re-Visiting of Outstations During the Secondary Normal Phase

If there is still time remaining before the System Scan time expires, then outstations that still have secondary data available can be re-visited for a period limited by the Maximum Secondary Scan per O/S interval as many times as necessary until the System Scan time expires.

Example:

A driver scans four outstations that are using the same direct channel to communicate with the server.

It first scans the outstations on the channel for current data (the Primary Phase of the scan).

The outstations are scanned in ascending address order—in this case, address 3, followed by addresses 4, 5 and then 6.

The driver then scans the outstations for time stamped logged data (the Secondary Phase of the scan).

The outstation with Address 5 has a lot of logged data. Some of the data cannot be retrieved within the Maximum Secondary Scan per O/S time. When the Maximum Secondary Scan per O/S time elapses, the driver scans the next outstation for secondary data.

The outstation with Address 6 only has a little logged data to report. Once this data has been retrieved, there is still some System Scan time remaining.

The outstation with address 5 has logged a lot of logged data, some of which cannot be retrieved within the Maximum Secondary Scan per O/S time. However, the outstation with address 6 only has a little logged data to report, and some of the System Scan Interval time remains once this data has been retrieved...

Therefore, the driver re-visits Outstation Address 5 and retrieves the logged data that it did not have time to retrieve on the first visit.

...The remaining System Scan Interval time allows the driver to revisit the outstation with address 5, and retrieve the remaining logged data.


Kingfisher Driver Guide - System Scan Termination (Scanning Direct Outstations on the Kingfisher Driver)

System Scan Termination

A System Scan is deemed to be complete when one of the following events occur:

  • The Primary Normal Phase exceeds the System Scan time and the Minimum Secondary Scan time elapses (see Minimum Secondary Scan Interval).
    The Primary Phase of this scan overran the System Scan Interval time. The overall scan time automatically increased to take into account the Minimum Secondary Scan Interval, after which the scan terminated.

  • The System Scan time elapses and the Secondary Normal Phase has run for longer than the Minimum Secondary Scan time, but there is still secondary data to extract.
    The scan has terminated as the System Scan Interval has elapsed, and the Secondary Phase of the scan has run for longer than the Minimum Secondary Scan Interval. Despite this, the outstation with address 6 has not yet been scanned for Secondary Data. This will be the first outstation to be scanned in the Secondary Phase of the next System Scan, following which data will be retrieved in the usual ascending Outstation Address order.

  • The available secondary data has been retrieved from the outstations, even after multiple re-visits to outstations with more data than can be accommodated in a Maximum Secondary Scan per Outstation time interval (see Maximum Secondary Promoted Time).
    The scan has terminated as all current and logged data has been extracted from the outstations (including those that were re-visited to retrieve their logged data).


Kingfisher Driver Guide - Quality Factor (Scanning Direct Outstations on the Kingfisher Driver)

Quality Factor

You can specify a Quality Factor number on the Form for each direct channel (see Define the Permitted Scan Durations). When specifying a Quality Factor, you need to consider the Recommended Settings for Scan Durations.

Each System Scan is given a scan factor rating to indicate that it is either:

  • On Target—The System Scan completed within the System Scan time (see System Scan Interval).
  • Acceptable—The System Scan completed within the Acceptable Scan time (see Acceptable Scan Interval).
  • Unacceptable—The System Scan completed after the Acceptable Scan time has expired (see the example below).

Each Unacceptable scan decrements the scan factor down from the Quality Factor number, and each Acceptable or On Target scan increments it back up again. If the scan factor reaches zero, an alarm is raised if configured. The alarm has the severity that has been specified for any alarms associated with the channel (see Defining General Channel Communication Settings in the ClearSCADA Guide to Advanced Drivers).

You can view this information in the form of a Scan Quality attribute, available on the Status Display for the channel.

View the number of On Target, Acceptable, and Unacceptable scans on a channel since its communication statistics were last reset, using the Channel Scanning Statistics List, or the Channel Status Display. (For more information, see Monitoring the State of Direct Communications on your System in the ClearSCADA Guide to Advanced Drivers, and see Kingfisher Channel Status Attributes.)

Further Information

Kingfisher Specific Status Display Attributes.

Using Lists: See the ClearSCADA Guide to Lists.

Example:

The Primary Phase of a scan has taken so long that the amount of time remaining for the System Scan Interval is less then that specified as a minimum time for retrieving secondary (logged) data (see Minimum Secondary Scan Interval). Therefore, the scan continues until the Minimum Secondary Scan time has elapsed.

If the revised scan time is still within the Acceptable Scan Interval (see Acceptable Scan Interval), then no alarm is raised, and the Scan Factor (if it is less than the Quality Factor number) is incremented by one.

As the time remaining for the Secondary Phase of this System Scan is less than the Minimum Secondary Scan Interval...
...the scan time is extended until the Minimum Secondary Scan time has elapsed.

However, if the revised scan time is greater than the Acceptable Scan time, then the Scan Factor decrements by one. If this results in a Scan Factor of zero, then an alarm is raised (if configured to do so).

The alarm is only cleared when enough On Target, or Acceptable scans occur to increment the Scan Factor value back up until it matches the Quality Factor value.


Kingfisher Driver Guide - Outstation Promotion (Scanning Direct Outstations on the Kingfisher Driver)

Outstation Promotion

Outstations on the Kingfisher driver can be promoted to a higher and more frequent level of data extraction upon request. The data from such outstations is then scanned during a Promotion Window. Promotion can be instigated:

  • Using the Promote Scanning pick action.
  • Automatically following a control.
  • Automatically while displaying the data for any points on the outstation.

For further information, see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers.

The period for which an outstation can remain in the promoted state is limited. When the promotion period expires, any outstation that is still in the promoted state will be returned to the normal scan state by the driver. This stops outstations from being left in the promoted state accidentally. Promoted outstations can also be returned to the normal system scan by operator request if the promotion was manually initiated (see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers), or by closing any displays that show point data for an outstation that is promoted while its points are on display.

Both primary and secondary data may be extracted from outstations during a Promotion window. Outstations that are promoted are still included within the normal system scan—the Promotion window occurs in addition to the normal scan.

For each channel on the Kingfisher driver, you need to specify appropriate promotion periods in these fields on the Kingfisher Direct Channel Form:

  • Promoted Scan
  • Maximum Promoted Scan
  • Maximum Promoted Secondary Scan.

For information on configuring promoted scan rates on the Channel Form, see Define the Permitted Scan Durations.

If required, you can configure individual outstations to have different normal and promoted scan rates to those specified on the channel. Where such rates exist, the driver takes into account the scan rates specified on the Outstation Form rather than those on the Channel Form. For information on configuring scan (poll) rates on the Outstation Form, see Specify the Polling Intervals and Offset.

For information on how the fields’ settings affect outstation promotion, see Promotion Window.


Kingfisher Driver Guide - Promotion Window (Scanning Direct Outstations on the Kingfisher Driver)

Promotion Window

A Promotion window allows outstations that have been promoted to be scanned at a more frequent rate (see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers). Define the rate at which Promoted outstations are scanned (Promoted Scan time), and the duration of a Promotion scan window (Maximum Promoted Scan time) using fields on the relevant Channel Form(s) (see Define the Permitted Scan Durations).

Promotion Window - Primary Phase

You can configure a Promotion window for the Primary Phase scan. The Promotion window is a defined amount of time, during which, ClearSCADA will only attempt to scan promoted outstations for primary data (current data).

At the start of the Promotion scan window for the Primary Phase, ClearSCADA scans those outstations that are in the promoted state for primary data. The outstations are scanned in address order (ascending). The other outstations are not scanned during this time.

When the Promotion scan window ends, ClearSCADA makes a record of which outstations it had scanned. When the next Promotion scan window begins, it will resume the scans from the point it was scanning when the previous Promotion scan window ended.

When the Promotion scan window has expired, the ‘normal’ scan period begins. During the ‘normal’ scan period, ClearSCADA will attempt to retrieve primary data from all of the outstations, including those that have not been promoted.

When the ‘normal’ scan period ends, ClearSCADA makes a record of which outstations it had scanned. When the next ‘normal’ scan period begins, ClearSCADA will resume scanning from the point it was scanning when the previous ‘normal’ scan period ended.

To specify the duration for a Promotion window, enter the required period in the Promoted Scan field on the Form(s) for the Channel(s) that a Promoted outstation is to use (see Define the Permitted Scan Durations).

When specifying a Promoted Scan, you should consider the Recommended Settings for Scan Durations.

Promotion Window - Secondary Phase

You can configure a Promotion window for the Secondary Phase scan. The Promotion window is a defined amount of time, during which, ClearSCADA will only attempt to scan promoted outstations for secondary data (logged data).

A Promotion window for the Secondary Phase scan works in a similar way to a Promotion window for a Primary Phase scan (see Promotion Window - Primary Phase). The only differences are that:

  • During a Promotion window for the Secondary Phase scan, ClearSCADA only scans those promoted outstations that have secondary data available for transfer.
  • The Promotion scan window can be disabled for secondary data. This may be your preference if the speed of secondary data extraction is unimportant on your system. You can disable the Promotion scan window for secondary data by setting the Maximum Secondary Promoted Time to zero.

Maximum Secondary Promoted Time

The Maximum Secondary Promoted time is a configurable interval used to specify the maximum time allowed to extract secondary data during a Promoted window.

If the Primary Phase completes quickly, then secondary data is only extracted until this period elapses, or the Promoted Scan time expires. As such, the time a Promotion window is active may be less than the Maximum Secondary Promotion time.

Specify the maximum secondary promotion time using the Maximum Promoted Secondary Scan field on the Form(s) for the Channel(s) that a Promoted outstation is to use (see Define the Permitted Scan Durations). When defining a Maximum Promoted Secondary Scan, you should consider the Recommended Settings for Scan Durations.

You can set the Maximum Secondary Promoted Time to zero, where the speed of secondary data extraction is not of paramount importance. In such cases, only the extraction of primary (current) data is promoted, and the extraction of secondary (logged) data occurs as part of the Secondary Phase of the normal (not Promoted) System Scan.

Example:

A driver scans six outstations that are using a particular channel to communicate with the server. An operator promotes the outstations that have addresses 5 and 6.

As with a normal System Scan, the promoted outstations are also scanned in address order, but only within the Promotion window.

A normal System Scan begins. Part-way through scanning outstation 7 for primary (current) data, a Promotion window begins. Outstations 5 and 6 are scanned for data.

When the Promotion window ends, the driver resumes the normal System Scan from where it left off—in this case, scanning outstation 7 for primary data.

When a Promotion window occurs, it interrupts the normal System Scan.

The Secondary Phase of the normal System Scan starts. While outstation 4 is being scanned for logged data, the scan is interrupted by the next Promotion window.

The Promotion window ends in less than the time specified for the Minimum Secondary Scan per O/S interval, so the driver resumes scanning outstation 4 for logged data.

As a Promotion window interrupted the Secondary Phase of the scan, this forces an extension of the Minimum Secondary Scan interval by the amount of time taken up by the Promotion window. This results in the System Scan taking longer to complete than the System Scan Interval.

If the Secondary Phase of a System Scan is interrupted by a Promotion window, the Minimum Secondary Phase time automatically extends by the time taken up by the Promotion window. This can force a System Scan to run for longer than the System Scan Interval.

The normal System Scan terminates once the extended Minimum Secondary Scan phase elapses.

If the time for the System Scan exceeded the Acceptable Scan Interval, and a Quality Factor is specified for the channel, the Scan Factor would decrement by one. If this were to result in a Scan Factor of zero, an alarm would be raised (if configured to do so).

However, if the overall time taken for the System Scan is equal to, or less than, the Acceptable Scan Interval, then no alarm is raised.

(For information on using Quality Factors and Scan Factors, see Quality Factor.)

Further Information

Promoting an outstation: see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers.


Kingfisher Driver Guide - Configuring a Kingfisher Channel

Configuring a Kingfisher Channel

The Kingfisher driver supports these types of Kingfisher channel:

  • Kingfisher Direct Channel—For Kingfisher outstations that are permanently connected to the ClearSCADA server, for example via a cable, network, or a continuous radio signal.

You need to configure a Kingfisher Direct Channel for each uninterrupted (‘direct’) communications connection that exists between the ClearSCADA server and the Kingfisher Direct outstations on your system.

  • Kingfisher PSTN Channel—For Kingfisher outstations that communicate with the server using dial-up modems.

For the Kingfisher outstations that use PSTN communications on your system, you need to configure a Kingfisher PSTN Channel for each telephone line connection between the ClearSCADA server and the PSTN outstations.

Some outstations that communicate using direct channel(s), have a dial-up modem as a ‘backup’ means of contacting the ClearSCADA server. You can configure such outstations to use PSTN as a ‘fallback’ means of communication, should the direct channel(s) fail. (In which case, you need to configure a Kingfisher PSTN Channel to represent each PSTN line via which the outstations can communicate, in addition to the Kingfisher Direct Channel(s).)

Before you configure any Kingfisher channels in ClearSCADA, familiarize yourself with the hardware settings for the channels on your system. This is because you will need to specify appropriate properties for the channels in the ClearSCADA database (see Preparation - Direct Channels in the ClearSCADA Guide to Advanced Drivers, and see Preparation - PSTN Channels in the ClearSCADA Guide to Advanced Drivers).

For a channel to be functional (online), you need to specify certain properties (see Minimum Configuration in the ClearSCADA Guide to Advanced Drivers).

In each case, you specify the channel’s properties using the fields on the appropriate Kingfisher Channel Form. Each Form has several tabs. The subsection that follows covers configuration of properties that are Kingfisher specific. For information on configuring properties that are common to channels on many advanced drivers, including information on tabs not covered in this section, see Tabs on Channel Forms in the ClearSCADA Guide to Advanced Drivers.

On the Kingfisher Direct Channel Form, the Scan Parameters tab includes a second Scan Parameters section, to enable you to Define the Permitted Scan Durations. Other fields on the Scan Parameters tab are common to channels on many advanced drivers (see Tabs on Channel Forms in the ClearSCADA Guide to Advanced Drivers).

When a Kingfisher Direct Channel has a Serial connection, it typically uses these settings (specified on the Connection tab of the Kingfisher Direct Channel Form):

  • Baud Rate—9600
  • Data Bits—8 bits
  • Parity—None
  • Stop Bits—1 bit
  • Flow Control—None.


Kingfisher Driver Guide - Define the Permitted Scan Durations (Configuring a Kingfisher Channel)

Define the Permitted Scan Durations

Use the second Scan Parameters section on a Kingfisher Direct Channel Form’s Scan Parameters tab to define the permitted scan durations for the direct channel.

The ClearSCADA server uses the scan times to determine whether the outstations that communicate via the selected channel are scanned within a suitable time. If not, the server generates alarms relating to the scan status.

Before you attempt to define the scan durations, you need to have an appreciation of the scanning procedure, and the different types of scans (see Scanning Direct Outstations on the Kingfisher Driver).

Use these fields to specify the Quality Factor and permitted scan durations for a channel. You can enter the durations directly in each scan field, or use the Interval Window (accessed via each field’s browse button) to specify the required durations.

  • System Scan—Specify the expected duration of the primary and secondary scans combined. Enter the time in the OPC Time Format, for example, 15S for 15 seconds.

For further details, see Recommended Settings for Scan Durations, and see System Scan Interval.

  • Acceptable Scan—Specify the total amount of extra time allowed to complete a system scan.

If the system scan is complete within the Acceptable scan time, the quality of the scan is not affected—the system scan took longer than expected, but was able to run to completion.

If the System Scan is incomplete at the end of the Acceptable Scan time, the scan has been unsuccessful and the Quality Factor decreases by 1.

Enter the time in the OPC Time Format, for example, 30S for 30 seconds.

For further details, see Recommended Settings for Scan Durations, and see Acceptable Scan Interval.

  • Quality Factor—Enter the required Quality Factor number. This is the start number of the Quality Factor accumulator—it will decrease by 1 each time there is a Bad quality scan via the selected channel. If it reaches 0, ClearSCADA detects that the channel has failed.

We recommend that you use the Quality Factor default of 5.

For further details, see Quality Factor.

  • Minimum Secondary Scan—Specify the least amount of time that the ClearSCADA server can spend scanning the outstations (that communicate via the selected channel) for secondary data.

The system scan cannot complete until the ClearSCADA server has performed the primary scan, and has performed a secondary scan for the amount of time you define in this field.

Enter the time in the OPC Time Format, for example, 5S for five seconds.

For further details, see Recommended Settings for Scan Durations, and see Minimum Secondary Scan Interval.

  • Maximum Secondary Scan per O/S—Specify the maximum amount of time that the ClearSCADA server can spend performing a secondary scan on a single outstation (via the selected channel).

This setting helps to prevent the server from using too much of the secondary phase scan time for communicating with one outstation.

Enter the time in the OPC Time Format, for example, 2S for two seconds.

For further details, see Recommended Settings for Scan Durations, and see Maximum Secondary Phase Time.

  • Promoted Scan—Specify the amount of time between each promotion window.

This defines how often the ClearSCADA server performs a promoted scan on those outstations that communicate via the selected channel and have been promoted (operators can promote an outstation by using the Promote Scanning action).

Enter the time in the OPC Time Format. We recommend that you use the default of 10S (10 seconds).

For further details, see Outstation Promotion.

If a particular outstation needs scanning at a different promotion interval to that of other outstations on the channel, you can specify such an interval using the outstation’s Promoted Polling Interval property (see Specify the Polling Intervals and Offset). When an outstation has such an interval configured, the driver uses the outstation’s Promoted Polling Interval rather than the channel’s Promoted Scan interval to determine how often it needs to perform a promoted scan on that particular outstation.

  • Maximum Promoted Scan—Specify the maximum duration of each promotion window (opened for the selected channel).

If a Promoted scan is incomplete when the Maximum Promoted Scan time is reached, the Promotion window is closed. The Promoted scan will continue from the point at which it was interrupted when the next Promotion window occurs.

Enter the time in the OPC Time Format. We recommend that you use the default of 5S (five seconds).

For further details, see Promotion Window.

  • Maximum Promoted Secondary Scan—Specify the maximum amount of time that the ClearSCADA server can spend retrieving secondary data during a Promotion window (via the selected channel).

Enter the time in the OPC Time Format. We recommend that you use the default of 2S (two seconds).

For further details, see Maximum Secondary Promoted Time.

NOTE: The Kingfisher driver does not use the Maximum Exception Secondary Scan. Leave the default setting of 5S in place for this field.


Kingfisher Driver Guide - Recommended Settings for Scan Durations (Configuring a Kingfisher Channel)

Recommended Settings for Scan Durations

The recommended settings for some of the scan durations vary according to the number of outstations that are associated with the selected direct channel. This section provides the recommended settings for typical system setups (that is, channels associated with 1, 10, 20, 50, 100, and 250 outstations). The settings apply to Kingfisher outstations other than PSTN and Remote outstations, whenever the driver is set to poll the outstations on the channel continuously (that is, each individual outstation’s Polling Interval is set to 0 (zero)).

(With Remote outstations, ClearSCADA retrieves the Master outstation’s copy of each Remote outstation’s data when it scans the Master outstation (see Master and Remote Outstations). Scanning of PSTN outstations differs to that of Direct and Shared outstations (see Retrieving Data from PSTN Outstations in the ClearSCADA Guide to Advanced Drivers).).
 | Number of Outstations
Scan Interval | 1 | 10 | 20 | 50 | 100 | 250
System Scan | 5S | 15S | 30S | 1M 15S | 2M 30S | 5M
Acceptable Scan | 10S | 30S | 50S | 2M 5S | 3M 45S | 8M 20S
Quality Factor (No.) | 5 | 5 | 5 | 5 | 5 | 5
Minimum Secondary Scan | 2S | 5S | 10S | 25S | 50S | 1M 40S
Max Secondary Scan per O/S | 2S | 2S | 4S | 4S | 4S | 4S
Promoted Scan | 10S | 10S | 10S | 10S | 10S | 10S
Maximum Promoted Scan | 5S | 5S | 5S | 5S | 5S | 5S
Maximum Promoted Secondary Scan | 2S | 2S | 2S | 2S | 2S | 2S

Each Direct channel’s Scan Count status attribute indicates how many scans have completed within the System Scan and Acceptable Scan times that are defined for that channel (see Kingfisher Channel Status Attributes).


Kingfisher Driver Guide - Configuring a Kingfisher Outstation Set

Configuring a Kingfisher Outstation Set

The Kingfisher driver supports these types of Kingfisher outstation set:

  • Kingfisher Direct Outstation Set—A set in which the outstations use a single direct channel to communicate with the server.

You need to configure one Kingfisher Direct Outstation Set for each group of Kingfisher outstations that communicate via a particular direct channel.

  • Kingfisher Shared Outstation Set—A set in which each outstation can communicate with the server using either of two direct channels. Each outstation in the set can use either channel.

You need to configure one Kingfisher Shared Outstation Set for each group of Kingfisher outstations that communicate via, and share, a particular pair of direct channels. For an example of Shared Set usage, see Kingfisher Master Outstation using a Shared Outstation Set.

  • Kingfisher Switched Outstation Set—A set in which outstations communicate with the server using one of two direct channels.

As there are two direct channels, one channel is used for communications and the other is a backup channel. ClearSCADA will switch the outstations from one channel to the other channel:

  • If ClearSCADA detects that the channel being used by the outstations has failed
  • If ClearSCADA detects that a specific number of outstations that use the channel have failed.

You need to configure one Kingfisher Switched Outstation Set for each group of Kingfisher outstations that communicate via, and can switch between, a particular pair of direct channels.

Kingfisher outstations support master station switching of channels on switched sets.

  • Kingfisher PSTN Outstation Set—For outstations that connect to ClearSCADA via the telephone network, using an individual or shared dial-up modem.

You need to divide any PSTN outstations into groups and configure one Kingfisher PSTN Outstation Set per group (see Configuring an Outstation Set in the ClearSCADA Guide to Advanced Drivers).

Specify the features of each set using the fields on the appropriate Kingfisher Outstation Set Form.

Each Form has several tabs. This section explains the driver-specific fields on the Kingfisher tab of each Form. For information on the fields on other tabs, see Tabs on Outstation Set Forms in the ClearSCADA Guide to Advanced Drivers.

Use the Kingfisher tab to:

  • Specify the Master Station Address
  • Specify Whether the Outstation Clocks Run at UTC or Local Time.

For information on the minimal amount of configuration that you can undertake to produce a functional Kingfisher Outstation Set, see Minimum Configuration.


Kingfisher Driver Guide - Minimum Configuration (Configuring a Kingfisher Outstation Set)

Minimum Configuration

For a Kingfisher Outstation Set to be functional, you need to specify:

  • The Channel(s) for the set (unless that set is a Kingfisher PSTN Outstation Set—with PSTN outstations, the association with a channel is only made during run time)
  • The master station Address.

You also need to put the set In Service and save the configuration.

These are the minimum requirements, and when configured, will result in a functional Kingfisher Outstation Set.


Kingfisher Driver Guide - Specify the Master Station Address (Configuring a Kingfisher Outstation Set)

Specify the Master Station Address

Use the Address field on the Kingfisher tab to specify the master station address that ClearSCADA uses when communicating with the Kingfisher outstations in a set. The address has to be different to those addresses that are used by:

  • Other master station software
  • Kingfisher ToolBox tasks that are scanning outstations on the same network.


Kingfisher Driver Guide - Specify Whether the Outstation Clocks Run at UTC or Local Time (Configuring a Kingfisher Outstation Set)

Specify Whether the Outstation Clocks Run at UTC or Local Time

Use the Local Time field on the Kingfisher tab to specify whether the outstations’ real time clocks runs in Local Time or UTC (Coordinated Universal Time).

Select the check box for each clock to run in Local time (for instance EST (Eastern Standard Time) if the local time zone is that for the East coast of America). No adjustments are made for Daylight Saving Time.

Clear the check box for each clock to run in UTC time.

For more information on Time Zone settings, see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


Kingfisher Driver Guide - Configuring a Kingfisher Outstation

Configuring a Kingfisher Outstation

For each Kingfisher outstation that exists on your system, you need to create and configure a corresponding outstation database entry within the ClearSCADA database. When configuring the database, you need to select the type(s) of outstation and communications that match those of your system hardware.

The types of outstation that the Kingfisher driver supports are listed below. For further information on which type(s) of outstation are appropriate representations of your system setup, see Outstation Types and Communications Set-ups in the ClearSCADA Guide to Advanced Drivers. Also see Master and Remote Outstations, and see Typical Master/Remote Scenarios.

The Kingfisher driver supports these types of outstation:

  • Kingfisher Direct Outstation—A outstation that is directly connected to the ClearSCADA server, for example, via a cable, network, or a continuous radio signal.

Depending on the system setup, a Kingfisher Direct Outstation can belong to a Direct or Switched Outstation Set.

  • Kingfisher Shared Outstation—An outstation that is directly connected to the ClearSCADA server. The outstation can communicate with the server using either of two channels. Each outstation in a Shared Outstation Set can communicate via either channel.
  • Kingfisher PSTN Outstation—An outstation that uses a dial-up modem to communicate with the ClearSCADA server. The outstation has to belong to a PSTN Outstation Set.
  • Kingfisher Direct Master Outstation—An outstation that is directly connected to the ClearSCADA server and acts as a ‘Parent’ outstation to a group of Kingfisher Remote Outstations.

Depending on the system setup, a Kingfisher Direct Master Outstation can belong to a Direct or Switched Outstation Set.

  • Kingfisher Shared Master Outstation—An outstation that is directly connected to the ClearSCADA server and acts as a ‘Parent’ outstation to a group of Kingfisher Remote Outstations. A Kingfisher Shared Master Outstation can communicate with the server using either of two channels, and has to be associated with a Shared Outstation Set (each outstation in a Shared Outstation Set can communicate with the server via either channel).
  • Kingfisher PSTN Master Outstation—An outstation that uses a dial-up modem to communicate with the ClearSCADA server and acts as a ‘Parent’ outstation to a group of Kingfisher Remote Outstations. A Kingfisher PSTN Master Outstation has to be associated with a PSTN Outstation Set.
  • Kingfisher Remote Outstation—An outstation that communicates with the ClearSCADA server via a Master (‘Parent’) outstation (see Master and Remote Outstations, and see Typical Master/Remote Scenarios). The information stored in a Remote outstation’s Hardware Registers and Local Registers is mapped through to the Master outstation’s memory. ClearSCADA then retrieves the Master outstation’s copy of the Remote outstation’s data when it scans the Master outstation.

For each Kingfisher outstation on your system, you specify the outstation features using the fields on the appropriate Kingfisher Outstation Form.

Each Form has several tabs. This section covers configuration of driver-specific properties on the Kingfisher, Remote, and PSTN tabs.

Use the fields on the Kingfisher tab to:

  • Specify the Outstation Address
  • Specify Whether the Order of Event Data is Checked

For outstations other than Kingfisher PSTN and Remote outstations, the Kingfisher tab also includes fields to enable you to:

  • Specify Whether an Outstation is Scanned more Frequently while its Points are Displayed (see Define Whether an Outstation is Promoted While its Points are on Display in the ClearSCADA Guide to Advanced Drivers)
  • Specify the Polling Intervals and Offset.

Use the Remote tab on the Kingfisher Remote Outstation Form to:

  • Define the Remote Outstation Properties.

Kingfisher outstations that communicate via PSTN, or use PSTN fallback, can support up to 2 Dial In lines for reporting alarm data to ClearSCADA. You configure the Dial In Lines on each outstation’s PSTN tab (see Define Dial In Line Properties on a PSTN Outstation in the ClearSCADA Guide to Advanced Drivers). For information on the other properties on the PSTN tab, see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers.

NOTE: The Kingfisher driver does not use ‘Heartbeating’ (a feature which is supported by shared outstations on some advanced drivers, and is specified on the Shared tab).

The fields on the other tabs are common to outstations on many advanced drivers—for information, see Tabs on Outstation Forms in the ClearSCADA Guide to Advanced Drivers.

For information on the minimal amount of configuration that you can undertake to produce a functional Kingfisher Outstation in ClearSCADA, see Minimum Configuration.


Kingfisher Driver Guide - Minimum Configuration (Configuring a Kingfisher Outstation)

Minimum Configuration

For a Kingfisher outstation to become functional (online) you need configure these features, then put the outstation In Service and save the configuration:

  • The Set to which the outstation belongs (Outstation tab)
  • The outstation Address (Kingfisher tab)
  • The host address and port for any network connected outstations (Network tab) (Port number 4058 is the TCP and UDP port that is registered with the IANA (Internet Assigned Numbers Authority) for the Kingfisher protocol.)
  • If the outstation communicates via PSTN or has PSTN fallback, the Telephone Number of the site on which the outstation is located (PSTN tab)
  • If the outstation is a Remote outstation, its Parent Outstation (Remote tab).

These are the minimum requirements and, when configured, will result in a functional Kingfisher outstation that uses the default configuration settings.


Kingfisher Driver Guide - Master and Remote Outstations (Configuring a Kingfisher Outstation)

Master and Remote Outstations

Kingfisher Master Outstations are used as ‘Parent’ outstations for Kingfisher Remote Outstations.

Remote outstations communicate with the ClearSCADA server via a Master outstation. Each Master outstation polls its Remote outstations and retrieves their data. The Master outstation then passes the polled data onto the server.

As each Master outstation can poll a large number of Remote outstations, this can reduce the communications traffic with the ClearSCADA server quite considerably. Up to 248 Remote outstations can communicate with one Master outstation, although typically much smaller numbers of Remote outstations are used on systems that use a Master and Remote outstation setup.

If communications with the ClearSCADA server is temporarily lost, a Master outstation can continue to poll its Remote outstations.

Direct Master Outstations communicate with the ClearSCADA server using a permanent connection, in a similar way to Direct Outstations.

Shared Master Outstations communicate with the ClearSCADA server using either of two channels, in a similar way to Shared Outstations.

PSTN Master Outstations use a dial-up modem to communicate with the ClearSCADA server.

Depending on the system setup, any of the above types of Master outstation can use either a multidrop permanent connection or PSTN to communicate with their Remote outstations.

For further information, see Typical Master/Remote Scenarios.


Kingfisher Driver Guide - Specify the Outstation Address (Configuring a Kingfisher Outstation)

Specify the Outstation Address

Use the Address field on the Kingfisher tab to specify the outstation address. The address has to be unique on the system.


Kingfisher Driver Guide - Specify Whether the Order of Event Data is Checked (Configuring a Kingfisher Outstation)

Specify Whether the Order of Event Data is Checked

If a Kingfisher outstation’s clock is changed, the event data that ClearSCADA then retrieves from the outstation may appear to be out of sequence. This may result in duplicate historic entries being logged in the Event Journal.

Select the Chronological Event Data check box to set ClearSCADA to check that the received event messages are in chronological order. Any event data that does not arrive from the outstation in chronological order is discarded and a message is logged in the Event Journal.

Clear the check box if you do not want ClearSCADA to perform checks on the chronological order of event data. With this setting cleared, ClearSCADA may log duplicate historic entries.


Kingfisher Driver Guide - Specify the Polling Intervals and Offset (Configuring a Kingfisher Outstation)

Specify the Polling Intervals and Offset

With Kingfisher outstations that have a permanent (‘direct’) connection to the ClearSCADA server, you use fields on the Kingfisher Channel Form to configure various properties related to the scanning (polling) of those outstations (see Define the Permitted Scan Durations). Should any of the outstations on the channel not need polling as frequently as other outstations, you can use the Polling fields on relevant Outstation Forms to specify different polling requirements for those particular outstations.

Use these fields on the Kingfisher tab to define how often the driver polls (scans) a particular outstation to retrieve its data:

  • Polling Interval—Use to specify the frequency with which the Kingfisher driver usually polls the outstation for data.

If the driver is to poll the outstation continuously, set this field to 0 (zero). The remaining polling fields on the tab will be ‘grayed out’ and unavailable for use.

If you want to restrict the polling of this outstation (in order to reduce comms bandwidth usage, for example, or to give priority to other outstations on the channel), enter the required frequency in the OPC Time Format. For example, 10S for ten seconds.

The following fields are only available for use if the Polling Interval is set to a value other than 0 (zero):

  • Promoted Polling Interval—Use to specify the frequency with which the Kingfisher driver polls the outstation for data when scanning is promoted. Specify a rate that is less than or equal to the Polling Interval. Enter the required frequency in the OPC Time Format. You can enter the value directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value.

A Promoted Polling Interval of 0 (zero) is invalid unless the Polling Interval is 0 (zero).

  • Polling Offset—Use to specify the actual time at which a poll of the outstation takes place. Polling times are synchronized with the server’s system clock whenever the driver is restarted. The driver uses the Polling Offset in conjunction with the relevant polling interval to determine when each poll should occur.

Enter the required offset in the OPC Relative Time Format. You can enter the value directly in the field, or use the Offset Window (accessed via the field’s browse button) to specify the required value.

Ideally, the polling intervals and offset should be fully divisible, so that polling occurs at readily recognizable times.

Example:

A Kingfisher outstation has this configuration:

Polling Interval: 30S
Promoted Polling Interval: 10S
Polling Offset: M + 5S (‘five seconds past the beginning of the current minute’)

With the above configuration, the Kingfisher driver normally scans the outstation at 5 seconds and then 35 seconds past each minute.

Promotion occurs whenever any of the outstation’s points are displayed on a client. While any of the points are on display, the driver increases its polling rate to 10-second intervals, resulting in the outstation being scanned at 5 seconds, 15 seconds, 25 seconds, 35 seconds, 45 seconds, and 55 seconds past the minute.

The driver reverts to polling the outstation at its normal 30-second polling interval, at 5 and 35 seconds past each minute, as soon as the outstation’s points are no longer on display.

Further Information

For more information on scanning promotion:

  • see Outstation Promotion
  • see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers
  • see Define Whether an Outstation is Promoted While its Points are on Display in the ClearSCADA Guide to Advanced Drivers.


Kingfisher Driver Guide - Define the Remote Outstation Properties (Configuring a Kingfisher Outstation)

Define the Remote Outstation Properties

The Outstation Form for Kingfisher Remote Outstations includes a Remote tab.

Use the Remote tab to specify a Remote outstation’s ‘Parent’ outstation, the type of communications that the Remote outstation uses, and whether a Confidence Scan is required.

  • Parent Outstation—Use this field to specify the Master outstation with which this Remote outstation communicates. The Master outstation polls the Remote outstations with which it is associated and passes the polled data onto the ClearSCADA server (see Master and Remote Outstations).

Use the browse button adjacent to the Parent Outstation field to display a Reference browse window. Select the required Master outstation from the window.

  • PSTN—Use this check box to specify the type of communications used by the Remote outstation.

Select the check box if the Remote outstation uses a PSTN link to communicate with its Master outstation. ClearSCADA will not attempt to communicate directly with the Remote outstation. Any control requests from ClearSCADA are proxied through the Master outstation. The Master outstation sends confirmation to ClearSCADA on receipt of an acceptable control request, but ClearSCADA does not receive any confirmation that the control has executed successfully.

Clear the check box if the Remote outstation uses a multidrop permanent connection to communicate with its Master outstation. For certain requests, such as when ClearSCADA is starting communications or sending a control request, ClearSCADA will communicate directly with the Remote outstation. This is done in order to ascertain that such a request is executed successfully. To retrieve point data from a Remote outstation, ClearSCADA scans the Master outstation and retrieves the Master outstation’s copy of the Remote outstation’s data.

  • Never Read Remote Directly—Select this check box to set the Kingfisher driver so that it will not read data (such as module status information) directly from the Remote outstation. Instead, the driver obtains Remote outstation data from the Master outstation.

Clear the check box if the Kingfisher driver is to read certain data directly from the Remote outstation. Such data typically includes module status information that allows ClearSCADA to ascertain whether the Remote outstation is online. ClearSCADA also contacts the Remote directly on driver start-up.

Regardless of the status of the Never Read Remote Directly check box, the Kingfisher driver will:

  • Send control requests directly to the Remote outstation
  • Retrieve a Remote outstation’s point data by reading the registers in the Master outstation.
  • Confidence Scan Interval—The Kingfisher driver scans any Master outstations regularly for updates to the Remote outstations’ data. When the driver detects that a Master outstation has recovered new data from its Remote outstations, the driver recovers the data from that Master outstation.

Use the Confidence Scan Interval field to specify an interval at which the Kingfisher driver recovers the Master outstation’s copy of the Remote outstation’s data, even if that data has not changed.

Enter a suitable scan interval in the OPC Time Format, for example 5M for five minutes.

Specify zero if a Confidence scan is not required.


Kingfisher Driver Guide - Points Used on Kingfisher Outstations

Points Used on Kingfisher Outstations

Kingfisher outstations support a combination of these point types:

  • Kingfisher Analog Input Points—see Configuring Analog Points
  • Kingfisher Analog Output Points—see Configuring Analog Points
  • Kingfisher Counter Points—see Configuring Counter Points
  • Kingfisher Digital Input Points—see Configuring Digital Points
  • Kingfisher Digital Output Points—see Configuring Digital Points.

You need to configure one point of the appropriate type per point at an outstation. You configure the properties of each point using the appropriate Kingfisher Point Form.

This section covers the configuration of properties that are common to many Kingfisher points. It includes information on how to:

  • Configure Common Point Properties
  • Use Persistence to Stop Fleeting Changes in Value from Changing a Point State
  • Log Point Data on Kingfisher Outstations.

For Kingfisher Analog Output Points and Kingfisher Digital Output Points, it also explains how to:

  • Specify Whether to Update an Output Point Value Immediately Following a Control.

For information on the minimal amount of configuration that you can undertake to produce a functional Kingfisher Point in ClearSCADA, see Minimum Configuration.

For general information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

NOTE: On systems on which ClearSCADA communicates with Kingfisher outstations using a Master/Slave setup (see Typical Master/Remote Scenarios), each Kingfisher Remote outstation monitors the change of state of its inputs and uses Kingfisher RTUTX statements to send the information to the Kingfisher Master outstation. The information then appears in the Master outstation’s network address registers. It is this register information that is read by ClearSCADA. (In other words, ClearSCADA reads the information from the local Master outstation only and not from the Remote outstations on the network.)


Kingfisher Driver Guide - Minimum Configuration (Points Used on Kingfisher Outstations)

Minimum Configuration

For each point, you need to specify these features on the appropriately named <Point Type> tab, then put the point In Service and save the configuration:

  • The outstation on which the point is located
  • The I/O Type
  • The point’s address
  • For digital points, the Bit Number and Number of Bits
  • For Hardware analog and counter points, the Channel Number.

If the point is an output point, you need to:

  • Enable and configure the required properties on the Control tab.

If you want point data to be stored historically, you also need to:

  • Enable and configure logging on the Historic tab if data is to be stored historically in the server database.

These are the minimum requirements and, when configured, will result in a functional point that uses the default settings.


Kingfisher Driver Guide - Configure Common Point Properties (Points Used on Kingfisher Outstations)

Configure Common Point Properties

Use the fields at the top of the <Point Type> tab to configure the common point properties.

The following fields are common to the points on Kingfisher outstations. For fields that are not described here, see the relevant point configuration section within this guide.

  • In Service—Use to specify whether the point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point that is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Outstation—Use to specify the outstation on which a point is located. Use the browse button to display a Reference browse window and select the relevant outstation from the window.
  • I/O Type—Points on a Kingfisher outstation can be physical or internal points. Use the I/O Type combo box to specify the point type. Choose from:
  • Register—The point is an internal point that exists in the outstation software.
  • Hardware—The point is a physical point for which I/O hardware connections exist.

NOTE: On some systems, ClearSCADA communicates with Kingfisher outstations using a Master/Remote setup (see Typical Master/Remote Scenarios). With this type of arrangement, each Kingfisher Remote outstation monitors the change of state of its inputs and uses Kingfisher RTUTX statements to send the information to the Kingfisher Master outstation. The information then appears in the Master outstation’s network address registers. It is this register information that is read by ClearSCADA. (ClearSCADA reads the information from the local Master outstation only and not from the Remote outstations on the network.)

  • Address—Use to specify the point’s address.

For Register points, specify the point’s register address, in the range 1 to 2048.

For Hardware points, specify the slot number, in the range 1 to 64.

  • Severity—Use this combo box to define the severity of any non-state events or alarms for the point. For more information on severities, see Defining Severities in the ClearSCADA Guide to Core Configuration.
  • Area of Interest—This field is only displayed if the Area of Interest feature is enabled on your system. Use the field to specify the Area of Interest with which any non-state related point alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).
  • Scan Group—Use the combo box to specify the Scan Group with which the point is associated. The Scan Group determines the frequency with which the driver updates the server with the current value for the point.

Specify the frequency of the group on the Scan Parameters tab of the associated Channel Form (see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers).


Kingfisher Driver Guide - Use Persistence to Stop Fleeting Changes in Value from Changing a Point State (Points Used on Kingfisher Outstations)

Use Persistence to Stop Fleeting Changes in Value from Changing a Point State

Use Persistence to stop momentary changes in point value from changing the state of a point. This stops the outstation from processing fleeting changes in point state and reporting those fleeting changes to the server. When a point that supports persistence changes value, any change of point state is delayed until the point remains in the new state for a specified amount of time. If the point does not remain in the new state for the required amount of time, no change in point state is recorded.

Use the Persistence feature to stop ClearSCADA from raising change of state alarms and logging change of state events when a point value is fluctuating.

On Kingfisher outstations, many point types support persistence (only counter points do not support persistence).

Configure the required persistence settings using the Persistence field for analog points, and the Persistence section for digital points. In both cases, these fields are on the <Point Type> tab of the Point Form. For further information, see the examples below and the appropriate point configuration section.

Example 1 - Using Persistence with an Analog Point

An analog point has this configuration:

High-High Alarm Limit = 80
High Alarm Limit = 70
Low Alarm Limit = 20
Low-Low Alarm Limit = 10

with this Persistence setting:

At 12:00:00 the point value is 50 (Normal).

At 12:00:23 the point value increases to 73, which is above the High Limit.

At 12:00:28 the point value is still 73, so the point state changes to High, as it has been 5 seconds since the value crossed the High Limit from the Normal state.

At 12:00:38 the point value rises further to 84 (the High-High Limit).

At 12:00:40 the point value drops to 78, so the point state of High remains unchanged, as the point was in the High-High range for less than the Persistence time.

Example 2 - Using Persistence with a Digital Point

A 1-bit digital point is configured to show the state of a pump (running, or stopped). The point states are configured as:

State 0 = Pump Running
State 1 = Pump Stopped

The Persistence settings are:

The pump is not running so the point is in State 1. The pump starts to run then stops again after 2 milliseconds. The point state remains unchanged as the pump did not run for the duration of the Leaving Other States persistence time (three milliseconds).

The pump starts to run and remains running. After three milliseconds, the pump is still running so the point state changes to 0. The change is reported to the server the next time that the driver scans the outstation. The reported data is processed and ClearSCADA raises or logs any alarms or events that are configured for State 0.

The pump stops running and remains stopped. After five milliseconds (the Leaving State 0 persistence time), the pump is still not running. The point state changes to 1. The change of state is reported to the server the next time that the driver scans the outstation. The reported data is processed and ClearSCADA raises or logs any alarms or events that are configured for State 1.


Kingfisher Driver Guide - Log Point Data on Kingfisher Outstations (Points Used on Kingfisher Outstations)

Log Point Data on Kingfisher Outstations

You can log data historically for points on Kingfisher outstations.

Define whether ClearSCADA retrieves any logged data using the fields within the Logged Data section of the <Point Type> tab of the appropriate Point Form:

  • Enabled—Use this check box to specify whether ClearSCADA is to retrieve logged data for the point.

Leave the check box clear if retrieval of logged data is not required.

Select the Enabled check box if you want ClearSCADA to retrieve any logged data from the outstation for this point. If you enable the Logged Data function, you also need to have logging enabled on the Historic tab for the point. The Historic tab defines how data is stored historically on the ClearSCADA server, whereas the <Point Type> tab defines how data is stored historically at the outstation.

If you enable the Logged Data function, the other fields within the Logged Data section of the Form become available for use.

  • Alarms From—Use this field to define how the ClearSCADA server processes the data that it retrieves from the outstation, specifically when it raises and clears point alarms.

Choose All Data, Logged Data Only, Most Recent Data, or Most Recent Logged Data, as appropriate. For more information on each option, see Processing Alarm Data for Point States in the ClearSCADA Guide to Advanced Drivers.

ClearSCADA interprets the Priority field that is included with every data value from a Kingfisher outstation, to derive why each value was logged. The information appears in the ‘Reason’ column when the data is displayed in a Historic List.

For analog and counter points, ClearSCADA supports these Priority values:

  • 0—Value Change
  • 1—State Change
  • 2—Timed Report
  • 3—End of Period
  • 4—End of Period Reset.

Any other Priority value is logged as a Value Change.

For digital points, ClearSCADA supports these Priority values:

  • 0—State Change
  • 1—Timed Report.

Any other Priority value is logged as a State Change.

Where ClearSCADA communicates with Kingfisher outstations in a Master/Slave setup (see Typical Master/Remote Scenarios), each Kingfisher Remote outstation logs data into its memory via the standard Kingfisher ladder logic. The Kingfisher Master outstation polls its Remote outstations for event logs. The Master outstation stores the logged data that it retrieves from its Remote outstations in its memory, along with an index reference for each log file. This information is uploaded from the Kingfisher Master outstation and placed into the ClearSCADA database.


Kingfisher Driver Guide - Specify Whether to Update an Output Point Value Immediately Following a Control (Points Used on Kingfisher Outstations)

Specify Whether to Update an Output Point Value Immediately Following a Control

This section only applies to Kingfisher Analog Output Points and Kingfisher Digital Output Points. For both of these point types, an Update point on successful action check box is displayed at the bottom of the Control tab.

Select the Update point on successful action check box for the point value to be reported immediately following a successful control action.

Clear the check box for the point value to be reported in the next poll.


Kingfisher Driver Guide - Configuring Analog Points

Configuring Analog Points

The Kingfisher driver supports Analog Input points and Analog Output points.

With the Kingfisher protocol, the preferred setup is for analog inputs to report state changes back to a Master outstation from a Remote outstation. With such a setup, use the standard Kingfisher Remote Outstation Change of State programming to report any state changes to the Master outstation.

Configure the properties of each analog point using the fields on the Kingfisher Analog Input Point Form, or the Kingfisher Analog Output Point Form, as appropriate.

This section covers configuration of properties on the Analog Point tab of both Kingfisher Analog Point Forms, and the properties on the Control tab of the Kingfisher Analog Output Point Form.

Use the Analog Point tab to:

  • Configure Common Point Properties
  • Configure Alarm Limits
  • Configure Point Scaling
  • Configure Format Properties (see Define the Appearance of an Analog Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Configure Override Properties (see Define whether an Analog Point can be Overridden in the ClearSCADA Guide to Core Point Configuration)
  • Configure Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration)
  • Configure the No Change Properties (see Detect whether an Analog Point has Stopped Changing in the ClearSCADA Guide to Core Point Configuration)
  • Configure Trend Properties (see Define an Analog Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Logged Data Properties (see Log Point Data on Kingfisher Outstations).

For Kingfisher Analog Output points, use the Control tab to:

  • Configure the Control Properties (see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Specify whether any Outstations are given Scanning Priority whenever a Control Action is Issued (see Outstation Promotion in this guide, and see Promoting Scanning of Outstations Associated with Controls in the ClearSCADA Guide to Core Point Configuration)
  • Specify Whether to Update an Output Point Value Immediately Following a Control.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.


Kingfisher Driver Guide - Common Point Properties (Configuring Analog Points)

Common Point Properties

Use the fields at the top of the Analog Point tab to Configure Common Point Properties. Fields that are specific to analog points are explained below.

  • Channel Number—Only applies to Hardware I/O types. Use the Channel Number field to specify the channel number for the point, in the range 1 to 8.


Kingfisher Driver Guide - Configure Alarm Limits (Configuring Analog Points)

Configure Alarm Limits

Use the fields within the Alarm Limits section of the Analog Point tab to set limits for a point and specify whether an alarm or event is generated if the point exceeds those limits.

Some of the Alarm Limits fields are common to many analog points (see Configure the Limits for an Analog Point in the ClearSCADA Guide to Core Point Configuration).

For information on Hysteresis, see Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm in the ClearSCADA Guide to Core Point Configuration.

For information on the Engineering Units Exceeded field, see Define how Over Range and Under Range Values are Processed in the ClearSCADA Guide to Core Point Configuration.

  • Persistence—Use this field to stop a change in value from affecting the point state until the point has been in that state for a specified time. This means the outstation will not process momentary changes of state and report such momentary changes to the server (see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State).

Use the Persistence field to define any persistence time, in seconds. The persistence time begins whenever the point value drops below or rises above a state limit (by default, High-High, Low, and so on).

If, within the persistence time, the point value crosses a further limit in the same direction (that is, still continuing away from the Normal state, or still continuing toward the Normal state), the persistence period does not restart as it crosses the further limit. If the point value remains within the new state as the original persistence time elapses, the outstation updates the point state.

If the point value crosses back over a limit before the persistence time has elapsed, the point does not change state, and a new persistence time starts for the point value traveling in the new direction.

For examples of how persistence is used, see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State.

If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed within the Alarm Limits section. For information on this property, see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events in the ClearSCADA Guide to Core Point Configuration.


Kingfisher Driver Guide - Configure Point Scaling (Configuring Analog Points)

Configure Point Scaling

Use the fields within the Scaling section of the Analog Point tab to specify the format of the raw data and the range of the raw input signal values for an analog point.

  • Data Type—Use this combo box to select the format of the raw data. The outstation uses the format to perform the appropriate calculations when converting the signals into engineering values for use in the ClearSCADA database and vice versa when sending raw data values to plant. Choose the format that relates to the analog equipment that you are using, for example, Unsigned 16 bit.
  • Raw Full Scale—Use to specify the highest acceptable raw data value for the point.
  • Raw Zero Scale—Use to specify the lowest acceptable raw data value for the point.


Kingfisher Driver Guide - Configuring Counter Points

Configuring Counter Points

The Kingfisher driver supports Counter Points. A counter point is a point that accumulates a value over time.

Configure the properties of each counter point using the fields on the Kingfisher Counter Point Form.

This section covers configuration of properties on the Count tab of the Form.

Use the Count tab to:

  • Configure Common Point Properties
  • Configure Alarm Limit Properties
  • Configure Format Properties (see Define the Appearance of a Counter-Type Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Configure Override Properties (see Define Whether a Counter-Type Point can be Overridden in the ClearSCADA Guide to Core Point Configuration)
  • Configure Significant Change Properties
  • Configure the No Change Properties (see Detect whether a Counter-Type Point has Stopped Changing in the ClearSCADA Guide to Core Point Configuration)
  • Configure Trend Properties (see Define a Counter-Type Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Logged Data Properties (see Log Point Data on Kingfisher Outstations).

For information about fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.


Kingfisher Driver Guide - Common Point Properties (Configuring Counter Points)

Common Point Properties

Use the fields at the top of the Count tab to Configure Common Point Properties. Fields that are specific to counter points are explained below.

  • Channel Number—Only applies to Hardware I/O types. Use the Channel Number field to specify the channel number for the point, in the range 1 to 8.
  • Data Type—Use this combo box to select the format of the raw data. The outstation uses the format to perform the appropriate calculations when converting the signals into engineering values and vice versa. Choose the format that relates to the counter equipment that you are using, for example, Unsigned 16 bit.


Kingfisher Driver Guide - Alarm Limit Properties (Configuring Counter Points)

Alarm Limit Properties

Use the fields within the Alarm Limits section of the tab to define the limit properties of the point.

Use the High and High High fields to set the limits for the point, and to specify whether an event or alarm is generated if the point reaches these levels. For further information, see Configure the Limits for a Counter-Type Point in the ClearSCADA Guide to Core Point Configuration.


Kingfisher Driver Guide - Significant Change Properties (Configuring Counter Points)

Significant Change Properties

Use the fields within the Significant Change section of the tab to define the amount by which a counter point’s value has to change before it is reported to the ClearSCADA server.

Use the Significant Change feature to help prevent excessive database updates. It allows you to define whether a counter point’s value change is stored in the database or is deemed as insignificant and is discarded. If ClearSCADA discards a value, the counter point’s previous recorded value is retained in the ClearSCADA database.

Configure the required settings using these fields within the Significant Change section of the tab:

  • Type—Use this combo box to define the type of significant change. Choose from:
  • None—The server only updates the point value in the ClearSCADA database when one or more of the following occurs:
  • The point changes state
  • The point’s Scan Group interval expires
  • A user requests a Refresh of a display on which the point is included
  • On system or driver start-up.
  • Absolute—In addition to the reasons listed in ‘None’ above, the point value will be updated in the ClearSCADA database if it changes by a defined amount.

You can define the amount by which the value has to change in the Deadband field.

  • Deadband—Enter the amount by which the point value has to change for it to be deemed significant.

Example:

A counter point is scanned every 5 seconds and reports a value of 10. There is no need for the database to log the same value every 5 seconds. Significant Change is used to only log the value when it changes by more than 2 (Type = Absolute, Deadband = 2). The point’ s value is only updated in the ClearSCADA database when it reaches or rises above 12, and thereafter whenever the value increases by 2 or more.

  • Log Event—Select this check box for any significant changes in point value to be logged in the Event Journal.

ATTENTION: Numerous messages may be logged in the Event Journal if Log Event is enabled for a point that frequently changes significantly in value.

Ensure that the Log Event check box is clear if any significant changes in point value are to be updated in the database, but not logged in the Event Journal.


Kingfisher Driver Guide - Configuring Digital Points

Configuring Digital Points

The Kingfisher driver supports 1-, 2-, and 3-bit Digital Input Points and Digital Output Points.

Configure the properties of each digital point using the fields on the Kingfisher Digital Input Point Form, or the Kingfisher Digital Output Point Form, as appropriate.

This section covers configuration of properties on the Digital Point tab of both Kingfisher Digital Point Forms, and the properties on the Control tab for Digital Output points.

Use the Digital Point tab to:

  • Configure Common Point Properties
  • Configure Point State Properties
  • Configure Override Properties (see Define whether a Digital Point can be Overridden in the ClearSCADA Guide to Core Point Configuration)
  • Use Persistence to Stop Fleeting Changes in Value from Changing the Point State
  • Configure Trend Properties (see Define a Digital Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Logged Data Properties (see Log Point Data on Kingfisher Outstations).

For Kingfisher Digital Output points, use the Control tab to:

  • Configure the Control Actions (see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Specify whether any Outstations are given Scanning Priority whenever a Control Action is Issued (see Outstation Promotion in this guide, and see Promoting Scanning of Outstations Associated with Controls in the ClearSCADA Guide to Core Point Configuration)
  • Specify Whether to Update an Output Point Value Immediately Following a Control.

For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.


Kingfisher Driver Guide - Common Point Properties (Configuring Digital Points)

Common Point Properties

Use the fields at the top of the Digital Point tab to Configure Common Point Properties. Fields that are specific to digital points are explained below.

  • Bit Number—Enter the lowest (starting) bit of the point. With a multi-bit point, the bits need to be consecutive (for example, a 2-bit digital might use bits 5 and 6, where bit 5 would be the starting bit).

Enter the appropriate bit number, within the range 1 to 16.

  • Number of Bits—Use this combo box to specify the number of bits for the point. This corresponds to the number of consecutive 1-bit points that form the point.

The number of bits directly affects the number of point states (see Point State Properties). For further information, see Single and Multi-Bit Digital Points in the ClearSCADA Guide to Core Point Configuration.

  • Format—Specify the format in which the point’s value appears in other ViewX displays, such as Lists. For further information, see Define the Format of a Digital Point’s Values in the ClearSCADA Guide to Core Point Configuration.


Kingfisher Driver Guide - Point State Properties (Configuring Digital Points)

Point State Properties

Use the fields in the States section of the Digital Point tab to define state-related information for the point, such as the handling of state-related alarms by the outstation.

The Number of Bits, defined toward the top of the Form (see Common Point Properties), determines the number of state fields that are available for use.

For further information, see Define the Point States for a Digital Point in the ClearSCADA Guide to Core Point Configuration.


Kingfisher Driver Guide - Use Persistence to Stop Fleeting Changes in Value from Changing the Point State (Configuring Digital Points)

Use Persistence to Stop Fleeting Changes in Value from Changing the Point State

Use the fields within the Persistence section of the Digital Point tab to stop fleeting changes in value from causing a change in point state. With the Persistence feature, a change in value will only cause a change in point state if that point remains in the new state for a specified time.

For information on defining the Persistence times, see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State.


Kingfisher Driver Guide - Using Kingfisher Specific Actions

Using Kingfisher Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section explains the Reset Statistics pick action, the functionality of which differs slightly on the Kingfisher driver compared to other drivers.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Kingfisher Driver Guide - Reset Statistics (Using Kingfisher Specific Actions)

Reset Statistics

Associated with: Kingfisher channels

Security permission required to access this pick action: Diagnostics

Use this pick action to reset a Kingfisher channel’s statistics. These comprise the:

  • Scan Statistics (on a Kingfisher Direct channel)
  • Scan Duration (on a Kingfisher Direct channel)
  • Comms Statistics (on a Kingfisher PSTN channel)
  • Message Count (on both types of channel).


Kingfisher Driver Guide - Kingfisher Specific Status Display Attributes

Kingfisher Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each Kingfisher outstation provides information about the present state of the individual outstation.

Use this section if you need information on the status of any Kingfisher database items on your system.

This section covers those status attributes that are Kingfisher driver-specific, and includes:

  • Kingfisher Channel Status Attributes
  • Kingfisher Outstation Status Attributes
  • Kingfisher Point Status Attributes
  • Alphabetical List of Kingfisher Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Kingfisher Driver Guide - Kingfisher Channel Status Attributes (Kingfisher Specific Status Display Attributes)

Kingfisher Channel Status Attributes

These status attributes are specific to Kingfisher Direct channels:

  • Scan Statistics
  • Scan Duration
  • Scan Count.


Kingfisher Driver Guide - Kingfisher Outstation Status Attributes (Kingfisher Specific Status Display Attributes)

Kingfisher Outstation Status Attributes

These status attributes are specific to Kingfisher outstations:

  • Battery Alarm
  • Source
  • RTU Software Version
  • Module n.


Kingfisher Driver Guide - Kingfisher Point Status Attributes (Kingfisher Specific Status Display Attributes)

Kingfisher Point Status Attributes

This status attribute is specific to Kingfisher points:

  • Source.


Kingfisher Driver Guide - Alphabetical List of Kingfisher Specific Status Display Attributes (Kingfisher Specific Status Display Attributes)

Alphabetical List of Kingfisher Specific Status Display Attributes

This section lists those status attributes that are specific to items on the Kingfisher driver.

The status attributes are listed in alphabetical order and comprise:

  • Battery Alarm
  • Module n
  • RTU Software Version
  • Scan Count
  • Scan Duration
  • Scan Statistics
  • Source.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.


Kingfisher Driver Guide - Battery Alarm (Kingfisher Specific Status Display Attributes)

Battery Alarm

Associated with: Kingfisher outstations

This status attribute indicates whether the outstation’ s battery voltage is low.

Possible States: Displays one of the Standard Alarm States.


Kingfisher Driver Guide - Module n (Kingfisher Specific Status Display Attributes)

Module n

Associated with: Kingfisher outstations

Module status attributes are displayed once the outstation is or has been in communication with the server. One status attribute is displayed per outstation module, including each of the I/O modules on which points are located. Each status attribute displays information about that particular module.

Example:

Module 1 PSU-6 Power Supply Module
Module 2 CP-11 Master Processor Module
Module 3 MC-31 Multi Communications Module


Kingfisher Driver Guide - RTU Software Version (Kingfisher Specific Status Display Attributes)

RTU Software Version

Associated with: Kingfisher outstations

This status attribute is displayed once an outstation is or has been in communication with the server. The attribute shows the version of software that is running at the outstation.

Example:

1.40b


Kingfisher Driver Guide - Scan Count (Kingfisher Specific Status Display Attributes)

Scan Count

Associated with: Kingfisher Direct channels

The Scan Count status attribute indicates the number of scans that ClearSCADA has completed via a channel, including how many of those scans:

  • Completed within the channel’s System Scan time
  • Completed within the channel’s Acceptable Scan time
  • Took longer than the Acceptable Scan time to complete.

The System Scan and Acceptable Scan times are both specified on the Kingfisher Direct Channel Form’s Scan Parameters tab (see Define the Permitted Scan Durations).

If the Reset Statistics pick action has been used to reset the count, two Scan Count attributes are displayed. The first displays the scan count since the statistics were last reset; the second displays the scan count between the previous two resets.

Example:

125 scans, 110 on target (88%), 10 acceptable (8%), 5 unacceptable (4%)

(Indicating 125 completed scans, of which 110 completed within the System Scan time, 10 completed within the Acceptable Scan time, and 5 took longer than the Acceptable Scan time.)

Also see Scan Duration.


Kingfisher Driver Guide - Scan Duration (Kingfisher Specific Status Display Attributes)

Scan Duration

Associated with: Kingfisher Direct channels

This status attribute indicates the shortest and longest times taken to complete a scan on a particular channel, along with the average scan completion time on that channel.

If the Reset Statistics pick action has been used to reset the duration, two Scan Duration attributes are displayed. The first displays the scan durations since the last reset; the second displays the scan durations between the previous two resets.

Example:

Minimum 1 seconds, Maximum 5 seconds, Mean 2 seconds

Also see Scan Count.


Kingfisher Driver Guide - Scan Statistics (Kingfisher Specific Status Display Attributes)

Scan Statistics

Associated with: Kingfisher Direct channels

This status attribute indicates the time period for which the Scan Duration, Scan Count, and Message Count statistics apply.

If the Reset Statistics pick action has been used to reset the statistics, two Scan Statistics entries are displayed. The first entry indicates the date and time from which the current set of statistics commenced; the second entry indicates the time period to which the previous set of statistics applies.

Example:

Since Jul/12/2010 15:56:51.830

If the statistics have been reset, a second entry will display this type of information:

Between Sep/29/2009 14:37:43.473 and Jul/12/2010 15:56:51.830


Kingfisher Driver Guide - Source (Kingfisher Specific Status Display Attributes)

Source

Associated with: Many Kingfisher items

The Source status attribute is common to many Status displays. The attribute indicates the location at which an item resides.

The information shown varies, depending on the type of item:
Kingfisher Item | Source Attribute
Outstation | Format | Set <Set Address>:OS <Outstation Address>
 | Example | Set 255:OS 2 for an outstation with an address of 3, which is associated with an outstation set that has an address of 255
Analog Input Point (Register) | Format | Set <Set Address>:OS <Outstation Address>:AIP Value, Register <Address>
 | Example | Set 255:OS 2:AIP Value, Register 3 for an analog input point that resides at Register 3 on the outstation that has an address of 2. The outstation belongs to the outstation set that has an address of 255.
Analog Input Point (Hardware) | Format | Set <Set Address>:OS <Outstation Address>:AIP Value, Module <Address>, Channel <Number>
 | Example | Set 255:OS 34:AIP Value, Module 3, Channel 4 for an analog input point that resides on Channel 4 of the 3rd Module on the outstation that has an address of 34. The outstation belongs to the outstation set that has an address of 255.
Analog Output Point (Register) | Format | Set <Set Address>:OS <Outstation Address>:AOP Value, Register <Address>
 | Example | Set 255:OS 24:AOP Value, Register 3 for an analog output point that resides at Register 3 on the outstation that has an address of 24. The outstation belongs to the outstation set that has an address of 255.
Analog Output Point (Hardware) | Format | Set <Set Address>:OS <Outstation Address>:AOP Value, Module <Address>, Channel <Number>
 | Example | Set 255:OS 22:AOP Value, Module 7, Channel 4
Counter Point (Register) | Format | Set <Set Address>:OS <Outstation Address>:Count Input, Register <Address>
 | Example | Set 255:OS 7:Count Input, Register 1 for a counter point that resides on the 1st Register of the outstation that has an address of 7. The outstation belongs to the outstation set that has an address of 255.
Counter Point (Hardware) | Format | Set <Set Address>:OS <Outstation Address>:Count Input, Module <Address>, Channel <Number>
 | Example | Set 255:OS 7:Count Input, Module 1, Channel 2
Digital Input Point (Register) | Format | Set <Set Address>:OS <Outstation Address>:DIP Value, Register <Address>, Bit Number <Number>, Bits <Number of Bits>
 | Example | Set 255:OS 4:DIP Value, Register 10, Bit Number 2, Bits 3 for a 3-bit digital input point that resides at Bit 2 on the 10th Register of the outstation that has an address of 4. The outstation belongs to the outstation set that has an address of 255.
Digital Input Point (Hardware) | Format | Set <Set Address>:OS <Outstation Address>:DIP Value, Module <Address>, Bit Number <Number>, Bits <Number of Bits>
 | Example | Set 255:OS 5:DIP Value, Module 9, Bit Number 4, Bits 3
Digital Output Point (Register) | Format | Set <Set Address>:OS <Outstation Address>:DOP Value, Register <Address>, Bit Number <Number>, Bits <Number of Bits>
 | Example | Set 255:OS 6:DOP Value, Register 4, Bit Number 2, Bits 1 for a 1-bit digital output point that resides at Bit 2 on the 4th Register of the outstation that has an address of 6. The outstation belongs to the outstation set that has an address of 255.
Digital Output Point (Hardware) | Format | Set <Set Address>:OS <Outstation Address>:DOP Value, Module <Address>, Bit Number <Number>, Bits <Number of Bits>
 | Example | Set 255:OS 2:DOP Value, Module 12, Bit Number 2, Bits 3


Kingfisher Driver Guide - System Analysis

System Analysis

This section is designed for use by system administrators and high-level engineers when assessing the state of the ClearSCADA system. It contains information that relates specifically to the Kingfisher Driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

During system analysis, you might need to:

  • Adjust the Configuration of any Points that Cause a High Load
  • Use Driver Logging.

Additionally, if an outstation is not communicating with the server when it should be, see Troubleshooting in the ClearSCADA Guide to Advanced Drivers.

NOTE: When troubleshooting on a ClearSCADA system, examine the messages in the Events List. The messages may indicate the cause of any unexpected system behavior.


Kingfisher Driver Guide - Adjust the Configuration of any Points that Cause a High Load (System Analysis)

Adjust the Configuration of any Points that Cause a High Load

A high load on the ClearSCADA server can cause slow system performance (see Diagnose Client Performance Problems in the ClearSCADA Guide to the Server Status Tool). By using the statistics that are shown in Lists and Status displays, you may be able to identify any Kingfisher outstations (and points) that are causing a high load on the server. High load is often caused by a point updating at too frequently.

Where a point on a Kingfisher outstation is causing a high load:

  1. If the point is on an outstation that has a direct connection to the server, check the Scan Group that the point is using (see Configure Common Point Properties). If this is causing the server to update the current point value at too frequent a rate, you might need to:
  • Specify a different Scan Group.

or:

  • Specify a less frequent scan rate for the Scan Group (see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers).
  2. If historic data is being logged for a point, you might need to decrease the frequency with which that data is logged (see Log Point Data on Kingfisher Outstations).
  3. If the point is an analog or counter point, enable the Significant Change feature. For analog points, see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration; for counter points, see Significant Change Properties.
  4. If the point is an analog point, or counter point with Significant Change enabled, you might need to increase the Significant Change deadband. This deadband defines the amount by which the point value has to change before the value will be logged by the outstation. For analog points, see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration; for counter points, see Significant Change Properties.
  5. If fleeting changes in value are causing a high load, you might want to increase the Persistence settings for the point (see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State). However, a sudden increase in momentary changes in state might indicate a problem elsewhere. For this reason, you should examine the outstation, plant, and instrumentation for any underlying hardware problem that may be causing the sudden increase.
  6. If none of the above checks and configuration changes have cleared the high load caused by the point, check the following equipment for any faults:
  1. Outstation hardware
  2. Plant
  3. Instrumentation.


Kingfisher Driver Guide - Driver Logging (System Analysis)

Driver Logging

Driver Logging is useful for investigating unexpected driver behavior as it provides diagnostic information for specific aspects of the system. For instance, the Points logging option provides diagnostic information on the points on a particular driver.

Should you need to contact Schneider Electric for assistance with unexpected behavior on your system, you may be asked to produce Log files. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

Those driver logging options that are typically required for investigating driver behavior are enabled by default. We suggest that the logging options are left at this default unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

For information on producing Log files and defining the Log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration.

For information on the driver log options that are available for the Kingfisher driver, see Common Advanced Driver Log File Options in the ClearSCADA Guide to Advanced Drivers.


SCADAPack Modbus Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SCADAPack Modbus Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


SCADAPack Modbus Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


SCADAPack Modbus Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


SCADAPack Modbus Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SCADAPack Modbus Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s SCADAPack Modbus driver. The SCADAPack Modbus driver enables ClearSCADA to communicate with generic Modbus and SCADAPack controllers using the Modbus protocol suite.

For more details on the information included in this guide, see Introduction to the SCADAPack Modbus Driver.


SCADAPack Modbus Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring SCADAPack Modbus items and features in the ClearSCADA database.

The guide also contains information for:

  • Operators and engineers who use the SCADAPack Modbus driver to monitor and control plant
  • Maintenance engineers.


SCADAPack Modbus Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


SCADAPack Modbus Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Server Status Tool.


SCADAPack Modbus Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


SCADAPack Modbus Driver Guide - Introduction to the SCADAPack Modbus Driver

Introduction to the SCADAPack Modbus Driver

The SCADAPack Modbus driver provides functionality that enables ClearSCADA to communicate with Generic Modbus® and SCADAPack® controllers, using the Modbus® protocol suite (see Which Driver?). The Modbus communication types that the driver supports include:

  • Modbus RTU serial, Modbus ASCII serial
  • Modbus RTU over TCP, Modbus ASCII over TCP
  • Modbus RTU over UDP, Modbus ASCII over UDP
  • Open Modbus/TCP.

ClearSCADA can communicate with SCADAPack and Generic Modbus controllers directly, using direct or PSTN communications. Function codes supported by the SCADAPack Modbus driver determine how it reads or writes to data on the controllers (see Modbus Function Codes Supported by the ClearSCADA SCADAPack Modbus Driver).

ClearSCADA can also provide a communications ‘gateway’ to allow applications such as TelePACE®, and ISaGRAF®, to communicate with SCADAPack controllers remotely, via the same communications link (for example, in situations where a SCADAPack controller has only one radio link). With the latter set-up, a Remote Connection database item provides a TCP/IP socket connection between ClearSCADA and the remote application.

The SCADAPack Modbus driver also enables ClearSCADA to retrieve DLOG (stored SCADAPack) data records from SCADAPack controllers and, if required, store those records historically in the ClearSCADA database.

The SCADAPack Modbus driver documentation:

  • Summarizes the Terminology of which you need to be aware
  • Explains how to:
  • Confirm that the SCADAPack Modbus Server Component is Installed
  • Configure SCADAPack and Generic Modbus specific features and items within the ClearSCADA database (see Configuring SCADAPack Modbus Devices in ClearSCADA, and see Scanning Direct Controllers on the SCADAPack Modbus Driver).

The documentation also explains:

  • Features that are of interest to operators (see Using SCADAPack Modbus Specific Actions)
  • Driver-specific aspects that are of interest to system administrators and engineers when investigating unexpected behavior relating to the SCADAPack Modbus driver. For information, see:
  • SCADAPack Modbus Eavesdropping Arrangement
  • SCADAPack Modbus Specific Status Display Attributes
  • System Analysis.

NOTE: Some devices with which ClearSCADA can communicate using the SCADAPack Modbus driver, support additional features that do not apply to other SCADAPack or Generic Modbus devices. Where ClearSCADA uses a SCADAPack Modbus Extension Driver to support such features, use the guide to that extension driver in conjunction with this guide.


SCADAPack Modbus Driver Guide - Which Driver? (Introduction to the SCADAPack Modbus Driver)

Which Driver?

ClearSCADA can communicate with SCADAPack controllers using one of several drivers. The driver that you need to use depends on the type of SCADAPack device(s) with which ClearSCADA is to communicate.

If ClearSCADA is to communicate with non E-series SCADAPack controllers, your system needs to run the SCADAPack Modbus driver, to enable ClearSCADA to communicate with those devices using the Modbus protocol. If the RealFLO feature is enabled on any of those controllers, ClearSCADA also needs to run the SCADAPack Modbus RealFLO Extension Driver, to enable ClearSCADA to retrieve gas flow measurement data from those controllers. (The RealFLO feature converts a SCADAPack controller into an electronic natural gas Flow Computer.) Refer to the rest of this guide for information on configuring ClearSCADA to communicate with non E-Series SCADAPack controllers using the Modbus protocol. Refer to the ClearSCADA Guide to the SCADAPack Modbus RealFLO Driver for information on configuring ClearSCADA to communicate with RealFLO-enabled SCADAPack controllers.

If ClearSCADA is to communicate with SCADAPack E-Series controllers, or 386 eNET outstations, your system needs to run the DNP3 driver, along with the DNP3 SCADAPack E-Series Extension Driver. Use these drivers to enable ClearSCADA to communicate with E-Series controllers and eNET outstations using the DNP3 protocol; with the DNP3 SCADAPack E-Series extension driver providing support for extended SCADAPack DNP3 functionality. For further information, see the ClearSCADA Guide to the DNP3 Driver, and the ClearSCADA Guide to the DNP3 SCADAPack E-Series Driver. (ClearSCADA can also communicate with non E-Series SCADAPack controllers using the DNP3 protocol. As non E-Series SCADAPack controllers do not support extended SCADAPack DNP3 functionality, you need to use DNP3, rather than DNP3 SCADAPack E-Series, database items to enable ClearSCADA to communicate with such devices using the DNP3 protocol.)

For ClearSCADA to communicate with SCADAPack E-Series controllers, or 386 eNET outstations, using the Modbus protocol, use either the ‘generic’ Modbus database items with ClearSCADA’s SCADAPack Modbus driver, or the simple Modbus driver. (E-Series controllers and eNET outstations do not support the extended Modbus functionality of other (non E-Series) SCADAPack controllers.)

For ClearSCADA to communicate with any non SCADAPack controllers using the Modbus protocol, use either the ‘generic’ Modbus database items with ClearSCADA’s SCADAPack Modbus driver, or the simple Modbus driver. For information on the latter driver, see the ClearSCADA Guide to the Modbus Driver.


SCADAPack Modbus Driver Guide - Terminology (Introduction to the SCADAPack Modbus Driver)

Terminology

Throughout most of the advanced driver documentation, the term ‘outstation’ is used to refer to any device such as a data logger, programmable logic controller (PLC), outstation, or RTU that is used to obtain data from measuring instruments or sensors.


SCADAPack Modbus Driver Guide - Modbus Function Codes Supported by the ClearSCADA SCADAPack Modbus Driver (Introduction to the SCADAPack Modbus Driver)

Modbus Function Codes Supported by the ClearSCADA SCADAPack Modbus Driver

The ClearSCADA SCADAPack Modbus Driver supports several Modbus function codes, enabling it to read and write data on SCADAPack and Generic Modbus devices. The standard function codes that the ClearSCADA SCADAPack Modbus Driver supports are:
Modbus Function Code | Functionality | Maximum Number of Registers that can be Read or Written to using a Single Command
FC1 | Read Coil Status | 2000
FC2 | Read Input Discretes | 2000
FC3 | Read Multiple Registers | 125
FC4 | Read Input Registers | 125
FC5 | Write Single Coil | 1
FC6 | Write Single Register | 1
FC15 | Write Multiple Coils | 3
FC16 | Write Multiple Registers | 4
FC22 | Mask Write Register | 1

NOTE: The actual maximum number of registers or coils requested in a read might be smaller than the number listed above. This will occur if a channel’s Maximum Packet Size has been reduced (see Specify the Required Modbus Protocol and Packet Size).

As only a limited number of generic controllers support FC22, this function is made optional on SCADAPack Modbus Digital Output Points in ClearSCADA (see Specify the Type of Control Operation).

Similarly, as some generic controllers do not support both FC6 and FC16, each generic controller’s Register Write function has to be specified in ClearSCADA (see Specify the Register Write Function).

For information on the controller address ranges that apply to the different types of Modbus data, see SCADAPack and Generic Modbus Point Addressing.

In addition to the above standard function codes, the ClearSCADA SCADAPack Modbus Driver also supports a number of proprietary function codes. These codes are used with SCADAPack controllers.


SCADAPack Modbus Driver Guide - Confirm that the SCADAPack Modbus Server Component is Installed (Introduction to the SCADAPack Modbus Driver)

Confirm that the SCADAPack Modbus Server Component is Installed

Before you add any SCADAPack Modbus items to ClearSCADA, you need to make sure that the relevant components are installed on the ClearSCADA servers on your system.

Use the Add/Remove Programs function in the Windows® Control Panel to check whether the required components are installed.

In order for ClearSCADA to communicate with any SCADAPack or Generic Modbus devices, the SCADAPack Modbus component has to be installed on each of the servers on your system (including any permanent standby servers).

The SCADAPack Modbus component is located in the Server group. To check that this component has been installed, ensure that the symbol to the left of the text SCADAPack Modbus does not have an X on it.

NOTE: If ClearSCADA uses a SCADAPack Modbus Extension Driver to support additional features on some devices, also ensure that the relevant extension driver component is installed.


SCADAPack Modbus Driver Guide - Configuring SCADAPack Modbus Devices in ClearSCADA (Introduction to the SCADAPack Modbus Driver)

Configuring SCADAPack Modbus Devices in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, measuring instruments, and control devices on your system. This section summarizes the database items that you need to configure to represent the SCADAPack Modbus devices on your system.

In order to represent any SCADAPack Modbus devices, the SCADAPack Modbus Driver has to be installed and running on the ClearSCADA servers on your system (see Confirm that the SCADAPack Modbus Server Component is Installed). When the driver is first installed, a system administrator needs to define the server settings for the driver (see Configuring SCADAPack Modbus Server Settings).

When you configure SCADAPack Modbus items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant SCADAPack Modbus devices on your system. Some settings are either fixed (incorporated into the design of the SCADAPack or Generic Modbus controller), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the SCADAPack Modbus devices on your system before you can configure the SCADAPack Modbus database items successfully. For instance, you need to specify the type of firmware that is running on each SCADAPack controller on your system.

You also need to be aware of which optional features are required for each SCADAPack Modbus item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with SCADAPack Modbus database items, including Lists, Actions, and Mimics. For actions that are specific to the SCADAPack Modbus driver, see Using SCADAPack Modbus Specific Actions. For further information on actions and for details on Lists and Mimics, see the core documentation.

The order and items that you configure in the ClearSCADA database differ, depending whether you want to:

  • Configure ClearSCADA to Communicate with SCADAPack Devices using Direct or PSTN Comms
  • Configure a SCADAPack Modbus Remote Connection to enable other applications to communicate remotely via ClearSCADA.

NOTE: ClearSCADA provides additional support for some devices using a SCADAPack Modbus Extension Driver. For information on configuring such devices, see the relevant SCADAPack Modbus extension driver guide.


SCADAPack Modbus Driver Guide - Configure ClearSCADA to Communicate with SCADAPack Devices using Direct or PSTN Comms (Introduction to the SCADAPack Modbus Driver)

Configure ClearSCADA to Communicate with SCADAPack Devices using Direct or PSTN Comms

For SCADAPack Modbus devices that are to communicate with ClearSCADA using direct or PSTN communications, you need to configure:

  1. SCADAPack Modbus Channels to represent the communication connections between a SCADAPack or Generic Modbus controller and the ClearSCADA server (see Configuring a SCADAPack Modbus Channel).
  2. SCADAPack Modbus Sets to define groups of SCADAPack or Generic Modbus controllers (see Configuring a SCADAPack Modbus Set).
  3. Generic or SCADAPack Modbus Controllers to define the units that monitor data and control plant.

For each non-SCADAPack device, you need to configure a Generic Modbus Controller (see Configuring a Generic Modbus Controller).

For each SCADAPack device, you need to configure a SCADAPack Modbus Controller (see Configuring a SCADAPack Controller). If ClearSCADA is running a SCADAPack Modbus Extension Driver to provide additional support for SCADAPack controllers, also see the relevant section in the appropriate SCADAPack Modbus extension driver guide.

  4. SCADAPack Modbus Analog and Digital Points to represent the analog and digital measuring instruments and control devices that are connected to each controller (see Points Used on SCADAPack Modbus Controllers).

If you want other applications to communicate remotely with SCADAPack Modbus devices via ClearSCADA, you also need to Configure a SCADAPack Modbus Remote Connection.

To minimize the time that it takes to configure the required SCADAPack Modbus items, you may want to configure them in the order listed above. The order is more important for controllers that use a permanent connection rather than PSTN to communicate with the ClearSCADA server, as set configuration requires you to specify a channel, and controller (outstation) configuration requires you to specify a set, and so on. (With PSTN controllers, the association with a channel is only made during run time.)

Further Information

Scanning Direct Controllers on the SCADAPack Modbus Driver.

NOTE: SCADAPack and Generic Modbus Controllers do not support writing of configuration from the ClearSCADA server, however you may be able to write configuration remotely, via applications such as TelePACE®. Refer to the documentation supplied with the application for information.


SCADAPack Modbus Driver Guide - Configure a SCADAPack Modbus Remote Connection (Introduction to the SCADAPack Modbus Driver)

Configure a SCADAPack Modbus Remote Connection

If an application such as TelePACE is to communicate remotely with SCADAPack Modbus devices via ClearSCADA, in addition to the configuration required to Configure ClearSCADA to Communicate with SCADAPack Devices using Direct or PSTN Comms, you also need to configure:

  • A SCADAPack Modbus Remote Connection to define the port on which ClearSCADA is to receive commands from the application(s) (see Configuring a SCADAPack Modbus Remote Connection).

We suggest that you configure the Remote Connection after configuring the SCADAPack Modbus Controllers with which the application(s) are to communicate.

NOTE: SCADAPack and Generic Modbus Controllers do not support writing of configuration from the ClearSCADA server. However, you may be able to write configuration remotely, via applications such as TelePACE®. Refer to the documentation supplied with the application for information.


SCADAPack Modbus Driver Guide - SCADAPack Modbus Controller and Point Addressing (Introduction to the SCADAPack Modbus Driver)

SCADAPack Modbus Controller and Point Addressing

This section covers:

  • SCADAPack and Generic Modbus Controller Addressing
  • SCADAPack and Generic Modbus Point Addressing.


SCADAPack Modbus Driver Guide - SCADAPack and Generic Modbus Controller Addressing (Introduction to the SCADAPack Modbus Driver)

SCADAPack and Generic Modbus Controller Addressing

Each SCADAPack and Generic Modbus controller address must be unique in a set.

Each SCADAPack controller supports both Standard and Extended addressing. Use Extended addressing when more than 255 controllers exist on a channel.

You need to specify the Addressing Mode (Standard or Extended) of each SCADAPack Modbus Channel that SCADAPack controllers can use to report alarms (see Specify Whether a Channel Uses Unsolicited PLC Functionality). You also need to specify the Addressing Mode on each SCADAPack Outstation Form (see Specify the Address Mode), along with the individual controller Address (see Specify the Controller Address).

For each Generic Modbus controller, you need to specify the individual controller Address on the Generic Modbus Outstation Form (see Specify the Controller Address). Unlike SCADAPack controllers, Generic Modbus controllers do not support an Extended addressing mode.


SCADAPack Modbus Driver Guide - SCADAPack and Generic Modbus Point Addressing (Introduction to the SCADAPack Modbus Driver)

SCADAPack and Generic Modbus Point Addressing

SCADAPack and Generic Modbus controllers support one of two point address ranges—5 Digit, or 6 Digit. You need to be aware of which address range each controller on your system supports. (For instance, current SCADAPack controllers use 5-Digit addressing.) Specify the supported Point Address Range on each SCADAPack or Generic Modbus Outstation Form (see Specify the Point Address Range).

Specify the individual point Address on each SCADAPack Modbus Point Form (see Configure Common Point Properties). Points on SCADAPack and Generic Modbus controllers use addresses within the 5- and 6-Digit address ranges listed below. Be aware that each type of controller has its own specific address range—refer to the controller documentation for the address range that applies to a specific type of controller.
Modbus Data Type | ClearSCADA Point Type | 5-Digit Address Range | 6-Digit Address Range
Coil, Discrete Output | Digital Output Point, Digital Input Point | 1 to 9999 | 000001 to 099999
Discrete Input | Digital Input Point | 10001 to 19999 | 100001 to 199999
Input Register | Analog Input Point, Digital Input Point | 30001 to 39999 | 300001 to 365536
Holding Register | Analog Output Point, Digital Output Point, Analog Input Point, Digital Input Point | 40001 to 49999 | 400001 to 465536

Further Information

Modbus Function Codes Supported by the ClearSCADA SCADAPack Modbus Driver.


SCADAPack Modbus Driver Guide - SCADAPack Modbus Eavesdropping Arrangement (Introduction to the SCADAPack Modbus Driver)

SCADAPack Modbus Eavesdropping Arrangement

Eavesdropping allows a new system to run in parallel with an existing system in order to test the new system’s configuration. The SCADAPack Modbus protocol uses an Rx and Tx eavesdropping arrangement.

While eavesdropping is in progress, any unexpected behavior can be investigated using the SCADAPack Modbus Eavesdrop logging option (see Driver Logging Options that are Specific to the SCADAPack Modbus Driver).

For more information on eavesdropping, see Using Eavesdropping to Test a New Server’s Configuration in the ClearSCADA Guide to Advanced Drivers.


SCADAPack Modbus Driver Guide - Configuring SCADAPack Modbus Server Settings

Configuring SCADAPack Modbus Server Settings

NOTE: If your system is running a SCADAPack Modbus Extension Driver, refer to the relevant extension driver guide for any driver-specific settings that are not mentioned below.

Some driver-specific settings need configuring on the server by a system administrator when an system is first installed. These settings are configured using the ClearSCADA Server Configuration tool.

For information on accessing the ClearSCADA Server Configuration tool, see Configuring Advanced Driver Server Settings in the ClearSCADA Guide to Advanced Drivers.

When the SCADAPack Modbus driver is first installed on a ClearSCADA system, a system administrator has to:

  1. Define the Delay While a Controller Performs a Reset.
  2. Define the Acceptable Controller Clock Drift.
  3. Define any Additional PSTN Connection Types (see PSTN Connection Types in the ClearSCADA Guide to Advanced Drivers).
  5. Apply the changes to the server (see Configuring Advanced Driver Server Settings in the ClearSCADA Guide to Advanced Drivers).
  6. If the server is currently running as the main server, restart the SCADAPack Modbus driver for the changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).
  7. Repeat steps 1 to 6 for each server on your system. (You only need to repeat the steps on any permanent standby servers if you make changes to the PSTN Connection Types.)


SCADAPack Modbus Driver Guide - Define the Delay While a Controller Performs a Reset (Configuring SCADAPack Modbus Server Settings)

Define the Delay While a Controller Performs a Reset

Use the Delay while outstation performs a reset field to specify the delay between resetting a controller and restarting communications. The delay stops any messages from being sent to the controller while it is in the process of resetting and then establishing communications with the server.


SCADAPack Modbus Driver Guide - Define the Acceptable Controller Clock Drift (Configuring SCADAPack Modbus Server Settings)

Define the Acceptable Controller Clock Drift

Applies to RealFLO-enabled SCADAPack controllers only.

Use the Allowable clock drift before an alarm is raised field to specify the amount of time by which a controller’s clock can differ from the server time before ClearSCADA raises an alarm.

The server sets a controller’s clock whenever it re-establishes communications with the controller, and thereafter at the frequency specified on the Channel Form (see Define when the Server Sets the Outstations’ Clocks in the ClearSCADA Guide to Advanced Drivers). At the same time, the server performs a check to assess the clock’s drift. If the time differs by more than the acceptable value, the server raises an alarm to indicate that the controller’s time has drifted by more than the acceptable amount.


SCADAPack Modbus Driver Guide - Scanning Direct Controllers on the SCADAPack Modbus Driver

Scanning Direct Controllers on the SCADAPack Modbus Driver

This section describes how the SCADAPack Modbus driver scans (polls) Generic Modbus, and SCADAPack Direct controllers for data. Use this section in conjunction with the advanced drivers scanning information (see Scanning Direct Outstations in the ClearSCADA Guide to Advanced Drivers).

This section includes information on:

  • Data Packets
  • Request for an Immediate Poll
  • Broadcast Messages
  • Normal and Promoted Scanning.

Also see Specify how any Scanning Gaps are Handled.

(The way in which ClearSCADA retrieves data from controllers that communicate via PSTN differs to the way in which it retrieves data from controllers that have a permanent (‘direct’) connection to the server. For information on scanning PSTN controllers, see Retrieving Data from PSTN Outstations in the ClearSCADA Guide to Advanced Drivers.)


SCADAPack Modbus Driver Guide - Data Packets (Scanning Direct Controllers on the SCADAPack Modbus Driver)

Data Packets

Unlike some protocols, Modbus has no ability to receive multi-packet messages—the information has to arrive in one packet and include the complete message within that packet.

This may mean that ClearSCADA needs to make more requests than for some protocols, in order to receive data updates. For example, if a controller has 200 points, but the message limit is reached once the message includes the data for only 150 of those points, the data for the other 50 points will be requested in the next message from ClearSCADA.

You specify the Maximum Packet Size, using the field on the Modbus tab of the Channel Form (see Specify the Required Modbus Protocol and Packet Size).

Also see Specify how any Scanning Gaps are Handled.


SCADAPack Modbus Driver Guide - Request for an Immediate Poll (Scanning Direct Controllers on the SCADAPack Modbus Driver)

Request for an Immediate Poll

Controllers, including Generic Modbus controllers that have the ability to act as Modbus Masters, can be configured to send an unsolicited message to ClearSCADA, to request an ‘immediate’ poll (see Specify Whether a Channel Uses Unsolicited PLC Functionality).


SCADAPack Modbus Driver Guide - Broadcast Messages (Scanning Direct Controllers on the SCADAPack Modbus Driver)

Broadcast Messages

The SCADAPack Modbus driver can send a Set Clock message to the broadcast address on a SCADAPack Modbus set (see Specify Whether a Set Broadcasts Set Clock Messages). Such a broadcast simultaneously re-synchronizes the time on each of the SCADAPack Modbus controllers on the set.

This feature is not available on Generic Modbus controllers and should not be used on sets that contain any RealFLO controllers. (The RealFLO method of setting a clock results in a RealFLO controller restarting its current Hour log.) (For more information on RealFLO, see the ClearSCADA Guide to the SCADAPack Modbus RealFLO Driver.)


SCADAPack Modbus Driver Guide - Normal and Promoted Scanning (Scanning Direct Controllers on the SCADAPack Modbus Driver)

Normal and Promoted Scanning

You configure different types of point in ClearSCADA, depending on the type of data that you want the SCADAPack Modbus driver to retrieve (see Configuring SCADAPack Modbus Devices in ClearSCADA). To retrieve or write to data on Generic Modbus, or SCADAPack controllers, you configure the relevant type of ‘standard’ analog or digital point (see Points Used on SCADAPack Modbus Controllers).

This section summarizes the way in which ClearSCADA retrieves data from most types of point on a Generic Modbus or SCADAPack controller (see Standard Points). If your system is running a SCADAPack Modbus Extension Driver, refer to the relevant extension driver guide for any scanning methodology that differs from that mentioned in this section.


SCADAPack Modbus Driver Guide - Standard Points (Scanning Direct Controllers on the SCADAPack Modbus Driver)

Standard Points

ClearSCADA can retrieve current data from each Generic Modbus, or SCADAPack controller at one of eight Normal frequencies, which you specify on the Modbus tab of the relevant Outstation Form (see Define the Data Retrieval Intervals).

Under certain circumstances, you might want to ‘promote’ a controller’s scan rate, so that its data is retrieved at a more frequent rate. Specify this rate using the eight Promoted intervals on the same tab. Use the Promote when Displaying Points check box on the Direct tab of the Outstation Form to specify whether scanning is automatically promoted while a controller’s points are on display (see Define Whether an Outstation is Promoted While its Points are on Display in the ClearSCADA Guide to Advanced Drivers). (You can manually promote scanning using a controller’s Promote Scanning pick action—see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers.)

Use the Retrieval Interval field on each Point Form to specify which of the eight Normal and Promoted retrieval interval combinations apply to each point (see Configure Common Point Properties). Whenever one or more retrieval intervals expire, the driver will attempt to poll the controller for the data for those points on which the intervals have expired.

Example:

A controller includes this configuration:
Normal Retrieval Interval 1: 5 Seconds
Normal Retrieval Interval 2: 10 Seconds

One of the analog points on the controller has this configuration:
Address: 30001
Retrieval Interval: Interval 1

Another analog point on the controller has this configuration:
Address: 30002
Retrieval Interval: Interval 2

The above configuration results in the driver scanning point addresses 30001 and 30002 together at 10 second intervals, in addition to scanning address 30001 every other 5 seconds. (As 30001 is scanned at 5-second intervals and 30002 at 10-second intervals.)

Retrieval Intervals do not apply to points for which ClearSCADA is configured to retrieve DLOG data only.

You can also assign a Scan Group to each point (other than those for which ClearSCADA only retrieves historic data), to provide confidence that the point’s data is still up-to-date, even if the point has not changed for some time at the controller. Be aware that ClearSCADA will attempt to poll a controller for current data whenever any of the points’ Scan Group intervals expires (see Configure Common Point Properties). Typically, a Scan Group interval should be a multiple of a point’s Retrieval Interval.

If a point is on a SCADAPack controller, use the Logged Data section of the Point Form to specify whether ClearSCADA is to retrieve DLOG (logged) data for a point, in addition to, or instead of, current data (see Log Point Data on SCADAPack Controllers). Use the Scan Rate field, within the DLOG section of the SCADAPack Controller’s Outstation Form, to specify the frequency with which the driver retrieves any logged data (see Define Whether Logged Data Records are Scanned).


SCADAPack Modbus Driver Guide - Configuring a SCADAPack Modbus Channel

Configuring a SCADAPack Modbus Channel

The SCADAPack Modbus driver supports two types of SCADAPack Modbus channel:

  • SCADAPack Modbus Direct Channel—For controllers that are permanently connected to the ClearSCADA server, for example via a cable, network, or a continuous radio signal.

For the controllers that use direct communications on your system, you need to configure a SCADAPack Modbus Direct Channel for each uninterrupted communications connection that exists between the ClearSCADA server and SCADAPack, or Generic Modbus controllers.

  • SCADAPack Modbus PSTN Channel—For controllers that communicate with the server using modems.

For the controllers that use PSTN communications on your system, you need to configure a SCADAPack Modbus PSTN Channel for each telephone line connection between the ClearSCADA server and the SCADAPack, or Generic Modbus controllers.

SCADAPack and Generic Modbus controllers can communicate with the ClearSCADA server using direct comms or PSTN. With any controllers that communicate using a direct channel but that have a dial-up modem as a ‘backup’ means of contacting the ClearSCADA server, you can configure the controllers to use PSTN as a ‘fallback’ means of communication (see Direct - PSTN Fallback in the ClearSCADA Guide to Advanced Drivers). (In which case, you need to configure a SCADAPack Modbus PSTN Channel to represent each PSTN line via which the controllers can communicate, in addition to the SCADAPack Modbus Direct Channel(s).)

In each case, you specify the features for a channel using the fields on the appropriate SCADAPack Modbus Channel Form.

Each SCADAPack Modbus Channel Form has several tabs. This section covers configuration of properties that are SCADAPack Modbus specific. For information on configuring properties that are common to many channels, and for information on tabs not covered in this section, see Tabs on Channel Forms in the ClearSCADA Guide to Advanced Drivers.

Use the fields on the Modbus tab to:

  • Specify Whether a Channel Uses Unsolicited PLC Functionality
  • Specify the Required Modbus Protocol and Packet Size.

With Direct channels, use the fields within the Scan Groups section of the Scan Parameters tab to specify the frequency with which current data is updated in ClearSCADA (see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers). For ‘standard’ points (points supported directly by the SCADAPack Modbus driver, rather than an Extension Driver), the Scan Group interval should be a multiple of the points’ Retrieval Interval rate (see Configure Common Point Properties).


SCADAPack Modbus Driver Guide - Specify Whether a Channel Uses Unsolicited PLC Functionality (Configuring a SCADAPack Modbus Channel)

Specify Whether a Channel Uses Unsolicited PLC Functionality

Use the fields within the Unsolicited PLC section of the Modbus tab to define whether unsolicited PLC functionality is enabled for the controllers on a channel.

Unsolicited PLC functionality allows SCADAPack controllers to invoke an ‘immediate’ poll from the ClearSCADA server. Generic Modbus controllers that have the capability to act as Modbus Masters can also use Unsolicited PLC functionality.

  • Enabled—Select this check box for Unsolicited PLC support to be available to the controllers on a channel. When enabled, SCADAPack or Generic Modbus controllers can write their address to the specified Register Address (see below), in order to invoke a poll from the ClearSCADA server.

For a PSTN channel, ensure that this check box is selected if the controllers are to use the channel to dial in and report alarm data.

Ensure that the Enabled check box is clear is Unsolicited PLC support is not available for the controllers on this channel. The other fields within the Unsolicited PLC section of the tab become ‘grayed out’ and unavailable for use.

If Unsolicited PLC functionality is not enabled on a PSTN channel (the Enabled check box is clear), the channel can only be used to dial out to SCADAPack or Generic Modbus controllers. The controllers cannot use the channel to dial in to report alarms.

  • Addressing Mode—Use this combo box to specify the address mode that the unsolicited PLC uses when operating on the channel. Choose from Standard or Extended (Modbus) addressing, depending on the number of SCADAPack or Generic Modbus controllers that exist on your ClearSCADA system (see SCADAPack and Generic Modbus Controller Addressing).
  • Address—Specify the address that the unsolicited PLC is to use on this channel.
  • Register Address—Specify the register address that any controller on this channel is to use in order to invoke a poll from ClearSCADA. The valid range is 40001 to 65535 inclusive.

For any SCADAPack or Generic Modbus controller to send an unsolicited message successfully to ClearSCADA, that message has to contain the following:

  • The Modbus Target Address has to comprise the address that is specified in the channel’s Address field (see above). The format of this address has to conform to the Addressing Mode specified for the channel (see above).
  • The Modbus Function Code that the SCADAPack Modbus driver is to use has to be specified as FC 16 (decimal). (This Function Code instructs the driver to Write to Multiple Registers).
  • The Starting Register Address has to comprise that which is specified in the channel’s Register Address field (see above).
  • The Quantity of Registers has to be 2.
  • The two registers that the unsolicited message transmits have to have the following content:
  • The first register has to contain the Set Address—the Modbus address of the Outstation Set with which the controller is associated (see Specify the Set Address).
  • The second register has to contain the Address of the controller that ClearSCADA is to poll on the above Outstation Set (see Specify the Controller Address). (This is typically the address of the controller that sent the unsolicited message, but could be the address of another controller that ClearSCADA is to poll in response to the message. (Any controller that can act as a Modbus Master can send a message to ClearSCADA to request it to poll a different controller, provided that controller is on the same set as the controller that sent the unsolicited message.))

Example:

A SCADAPack Modbus Channel includes the following configuration:

A Set that uses the above channel includes this configuration:
Set Address: 200

A controller on the above set includes this configuration:
Address: 60

The above controller sends an unsolicited message to ClearSCADA. The message includes the following information:

Modbus Target Address = 53
Function Code = FC 16 (decimal)
Starting Register Address = 40001
Quantity of Registers = 2
The data in register 1 = 200
The data in register 2 = 60

On receipt of the above message, ClearSCADA will poll the controller that sent the message (the controller that has an Address of 60, on the Set that has a Set Address of 200.)

(If the outstation and outstation set in the message did not correlate with an outstation that exists in the database, then ClearSCADA would respond with a Modbus exception response. If the message was not properly framed, or the target Modbus address or addressing type were not the same as the ClearSCADA settings, then ClearSCADA would discard the message and make no response.)


SCADAPack Modbus Driver Guide - Specify the Required Modbus Protocol and Packet Size (Configuring a SCADAPack Modbus Channel)

Specify the Required Modbus Protocol and Packet Size

Use these fields on the Modbus tab to specify the type of Modbus protocol that the channel is to use and the maximum size of the data packets that can be transmitted via the channel:

  • Protocol Type—Use this field to specify the type of Modbus protocol that the channel is to use. Choose RTU, ASCII, or TCP, as required (the TCP option only applies to Network channels).
  • Maximum Packet Size—Messages are transmitted as blocks of data known as packets. With the Modbus protocol, each data packet has to contain a complete message.

Use the spin box to specify the maximum acceptable packet (message) size of:

  • Requests that ClearSCADA can send to a controller on this channel
  • Replies that a controller on this channel can send to ClearSCADA. (The size that you define excludes framing and checksum bytes.)

Should ClearSCADA or a controller need to send more information than can be contained within one message, it will send further message(s) containing the data that had to be omitted from the original message.


SCADAPack Modbus Driver Guide - Configuring a SCADAPack Modbus Set

Configuring a SCADAPack Modbus Set

The SCADAPack Modbus driver supports four types of SCADAPack Modbus outstation set:

  • SCADAPack Modbus Direct Outstation Set—A set in which the controllers use a single channel to communicate with the server.

You need to configure one SCADAPack Modbus Direct Outstation Set for each group of SCADAPack or Generic Modbus controllers that communicate via a particular direct channel.

  • SCADAPack Modbus Shared Outstation Set—A set in which each controller can communicate with the server using either of two channels. Each controller in the set can use either channel.

You need to configure one SCADAPack Modbus Shared Outstation Set for each group of SCADAPack or Generic Modbus controllers that communicate via, and share, a particular pair of direct channels.

  • SCADAPack Modbus Switched Outstation Set—A set in which each of the controllers communicate with the server using one of two channels. All of the controllers in the set use the same channel.

If ClearSCADA detects that the channel in use has failed, or that a specified number of controllers have failed, ClearSCADA will switch the controllers to communicate using the alternative channel.

You need to configure one SCADAPack Modbus Switched Outstation Set for each group of SCADAPack or Generic Modbus controllers that communicate via, and can switch between, a particular pair of direct channels.

SCADAPack and Generic Modbus controllers support master station switching of channels on switched sets.

  • SCADAPack Modbus PSTN Outstation Set—For SCADAPack or Generic Modbus controllers connect to ClearSCADA via the telephone network, using an individual or shared modem.

You need to divide any PSTN controllers into groups and create one SCADAPack Modbus PSTN Outstation Set per group (see Configuring an Outstation Set in the ClearSCADA Guide to Advanced Drivers).

In each case, you specify the features for a set by using the fields on the appropriate SCADAPack Modbus Outstation Set Form.

Each Form has several tabs.

Use the Modbus tab to:

  • Specify the Set Address

For SCADAPack Modbus Outstation Sets other than PSTN, also use the Modbus tab to:

  • Specify Whether a Set Broadcasts Set Clock Messages.

Properties on other tabs are common to outstation sets on many advanced drivers—for information, see Tabs on Outstation Set Forms in the ClearSCADA Guide to Advanced Drivers.


SCADAPack Modbus Driver Guide - Specify the Set Address (Configuring a SCADAPack Modbus Set)

Specify the Set Address

ClearSCADA uses a Set Address to identify each SCADAPack or Generic Modbus controller that dials in to the system, or uses a remote connection to communicate with ClearSCADA. The Set Address defines the group to which each controller belongs. The address is used internally by ClearSCADA—it does not exist in the controller hardware.

Use the Set Address field on the Modbus tab to specify the address of the set:

ClearSCADA automatically allocates the next available address to a set, whenever a set is created in the database. The allocated address is displayed when you open the Form.

If you want to specify a particular address, overwrite the entry in the Set Address field.


SCADAPack Modbus Driver Guide - Specify Whether a Set Broadcasts Set Clock Messages (Configuring a SCADAPack Modbus Set)

Specify Whether a Set Broadcasts Set Clock Messages

The Broadcast feature does not apply to PSTN sets.

Use the Broadcast Set Clock check box on the Modbus tab to specify whether the server updates the controllers’ clocks individually or simultaneously.

Select the check box to broadcast a Set Clock message simultaneously to each of the SCADAPack Modbus controllers in the set. (Set Clock broadcasting does not apply to Generic Modbus controllers.)

Ensure that the check box is clear if you want the server to set the time on each controller individually. If your system is running the RealFLO Extension Driver, ensure the check box is clear if a set contains any RealFLO controllers (as the RealFLO method of setting a clock results in the controller restarting its current Hour log).

Use the Set Outstation Clock settings on the Scan Parameters tab of the Channel Form to specify when the clocks are set on the controllers that communicate via a particular channel (see Define when the Server Sets the Outstations’ Clocks in the ClearSCADA Guide to Advanced Drivers).


SCADAPack Modbus Driver Guide - Configuring Controllers on the SCADAPack Modbus Driver

Configuring Controllers on the SCADAPack Modbus Driver

NOTE: In addition to the controllers listed below, ClearSCADA can communicate with other types of controller using a SCADAPack Modbus Extension Driver. For information on controllers that are not listed below, see the relevant SCADAPack Modbus extension driver guide.

The SCADAPack Modbus driver supports these types of controller:

  • Generic Modbus controllers, used to represent ‘generic’ or non-SCADAPack controllers.
  • SCADAPack controllers, which make use of additional controller features, such as DLOG.

For each SCADAPack or generic Modbus controller that exists on your system, you need to create and configure a corresponding outstation database entry within the ClearSCADA database. When configuring the database, ensure that you select the type(s) of controller and communications that correspond to your system hardware.

The types of controller that the SCADAPack Modbus driver supports are listed below. For further information on the type(s) of controller that best represent your system set-up, see Outstation Types and Communications Set-ups in the ClearSCADA Guide to Advanced Drivers.

The SCADAPack Modbus driver supports these types of controller (outstation):

  • Generic Modbus Direct Outstation/SCADAPack Direct Outstation—Controllers that are directly connected to the ClearSCADA server.

Depending on the system set-up, a Direct controller can belong to a Direct or Switched Outstation Set.

  • Generic Modbus PSTN Outstation/SCADAPack PSTN Outstation—Controllers that communicate with the server using a dial-up modem.
  • Generic Modbus Shared Outstation/SCADAPack Shared Outstation—Controllers that are directly connected to the ClearSCADA server. A Shared controller can communicate with the server using either of two channels. Each controller in a Shared Set can communicate via either channel.

If your database structure is ‘modular’ and Group Templates are used to store ‘model’ SCADAPack Modbus configuration, in addition to the above types of controller, you can add any of these driver-specific ‘abstract’ controller items to your Group Templates:

  • Abstract SCADAPack Modbus Outstation—Converts to any of the SCADAPack Outstation items listed above.
  • Generic Modbus Abstract Outstation—Converts to any of the Generic Modbus Outstation items listed above.

You can only add Abstract Items to Group Template s. The abstract items appear as additional driver-specific entries when you display the context sensitive menu from a Group Template. As with other abstract items, in order to represent a ‘real’ controller, you need to convert the abstract items into the required type of controller (outstation) within the Group Instances that reference the Group Template. For more information, see Add an Abstract Item to a Group Template in the ClearSCADA Guide to Core Configuration.

For each Generic Modbus controller on your system, you specify the controller features using the fields on the appropriate Generic Modbus Outstation Form (see Configuring a Generic Modbus Controller).

For each SCADAPack controller on your system, you specify the controller features using the fields on the appropriate SCADAPack Outstation Form (see Configuring a SCADAPack Controller).

Each Form has several tabs. (For any driver-specific tabs not listed below, see the relevant SCADAPack Modbus extension driver guide.)

For information on the Modbus tab, see Configuring a Generic Modbus Controller.

For information on the SCADAPack tab, see Configuring a SCADAPack Controller.

Use the Direct tab to specify whether a controller is given scanning preference while its Points are on display (see Define Whether an Outstation is Promoted While its Points are on Display in the ClearSCADA Guide to Advanced Drivers).

Use the PSTN tab to define the Public Switched Telephone Network properties for a controller (see Define an Outstation’s PSTN Properties in the ClearSCADA Guide to Advanced Drivers.)

Use the Network tab to define additional properties for any network connected SCADAPack controller (see Define an Outstation’s Network Properties in the ClearSCADA Guide to Advanced Drivers). (Port number 502 is the Modbus TCP port that is registered for use with the IANA (Internet Assigned Numbers Authority).)

Use the Shared tab to:

  • Define when a Shared controller switches channels (see Define an Outstation’s Shared Properties in the ClearSCADA Guide to Advanced Drivers).
  • Additionally, if the controller is to use Heartbeat Polling, you need to Specify the Heartbeat Address that is used on a Shared Controller.

The fields on other tabs are common to controllers and outstations on many advanced drivers (see Tabs on Outstation Forms in the ClearSCADA Guide to Advanced Drivers).


SCADAPack Modbus Driver Guide - Specify the Controller Address (Configuring Controllers on the SCADAPack Modbus Driver)

Specify the Controller Address

Use the Address field on the SCADAPack or Modbus tab to specify the address for a SCADAPack or Generic Modbus controller.

Each SCADAPack and Generic Modbus address has to be unique on the system.

For Generic Modbus controllers, enter the required address in the range 1 to 255.

For SCADAPack controllers, enter the required address in the range 1 to 255 (Standard Addressing) or 1 to 65534 (Extended Addressing), depending on the number of controllers on a channel (see SCADAPack and Generic Modbus Controller Addressing). (If more that 255 SCADAPack controllers exist on a channel, ensure that the Addressing Mode is set to Extended (see Specify the Address Mode).)

Modbus uses Address 0 for broadcasting, therefore this address cannot be used as a SCADAPack or Generic Modbus controller address.


SCADAPack Modbus Driver Guide - Specify the Point Address Range (Configuring Controllers on the SCADAPack Modbus Driver)

Specify the Point Address Range

Use the Point Address Range field on the SCADAPack or Modbus tab to specify whether the points on a controller use a 5 Digit or 6 Digit address range. ClearSCADA performs configuration time-range checking on the controller’s points according to this property.

Specify whichever address range is supported by the controller. Current SCADAPack controllers use 5 Digit addressing.

Specify the actual point addresses on the individual Point Forms (see Configure Common Point Properties).


SCADAPack Modbus Driver Guide - Define the Data Retrieval Intervals (Configuring Controllers on the SCADAPack Modbus Driver)

Define the Data Retrieval Intervals

Use the Retrieval Intervals section of the SCADAPack or Modbus tab to determine how often the driver polls a SCADAPack or Generic Modbus controller to retrieve its point data:

  • Normal 1 to Normal 8—Specify the frequency with which the driver polls the controller for point data. You can specify up to eight different polling intervals.

Enter each interval in the OPC Time Format, for example 10S for ten seconds.

  • Promoted 1 to Promoted 8—Specify the frequency with which the driver polls the controller for point data when scanning is promoted. You can specify up to eight different polling intervals. Each Promoted frequency replaces the corresponding Normal frequency while scanning is promoted for the controller. For more information, see Temporarily Increasing the Scan Rate in the ClearSCADA Guide to Advanced Drivers, and see Define Whether an Outstation is Promoted While its Points are on Display in the ClearSCADA Guide to Advanced Drivers.

Enter each interval in the OPC Time Format, for example 5S for five seconds.

To define which of the eight Normal/Promoted intervals is used for a particular point, use the Retrieval Interval field on the <Point> tab of the corresponding SCADAPack Modbus Point Form (see Configure Common Point Properties).

Example:

An Analog point on a SCADAPack controller has this configuration:
Retrieval Interval:5

The SCADAPack Controller includes this configuration:
Normal Retrieval Interval 5:8S
Promoted Retrieval Interval 5:4S
The Promote when Displaying Points check box is selected.

ClearSCADA scans the SCADAPack controller every eight seconds for the Analog point data.

A Mimic that contains a point from the SCADAPack controller is displayed on one of the ViewX workstations.

While the Mimic is on display, scanning of the controller is promoted. While scanning is promoted, ClearSCADA scans the SCADAPack controller at four-second intervals for the Analog point data.

For further information on retrieval intervals, see Normal and Promoted Scanning.


SCADAPack Modbus Driver Guide - Specify how any Scanning Gaps are Handled (Configuring Controllers on the SCADAPack Modbus Driver)

Specify how any Scanning Gaps are Handled

The SCADAPack Modbus driver typically scans each contiguous group of points for data at a particular retrieval interval. The driver calculates the group at the start of the poll, based on the points for which data needs retrieving. Each group comprises a particular address range, for example, holding registers, or input registers. In some instances, there may be gaps in the point Addresses within the group of points that the driver is to scan. This could occur, for instance, if it is not possible or practical to group the data points into tight contiguous point Address ranges.

In such a situation, it may be preferable to scan a wider range of points in a single scan, rather than split those points into smaller scan groups, using the gap in point Addresses to separate each group. A single scan is more efficient if the overhead of making multiple requests outweighs the extra unused bytes in a single read request.

Use the Scanning Gaps section on the SCADAPack or Modbus tab to specify how ClearSCADA determines the maximum Address gap size before splitting a read request:

  • User Defined—Select this check box if you want to manually specify the circumstances in which ClearSCADA should split a poll. Use the rest of the fields in the Scanning Gaps section to specify the settings that determine whether a poll should be split into multiple read requests.

Leave the check box clear for the driver to automatically calculate whether to split a poll. The driver calculates the optimum maximum gap size based on the speed and latency of the communications link. The calculation compares the expected time to read each of the registers, coils, or discrete inputs in one request, versus the expected time if the poll was split at the first large Address gap.

If the driver deems it more efficient to perform multiple read requests, it splits the poll at that Address gap and sends a read request for the data up to that gap. The driver then performs a similar calculation on the remaining items. If further Address gaps exist, the driver ascertains whether to split the request for the remaining data into more than one read request. In each case, the driver performs the number of read requests that is deemed to have the least overhead. For more information, see The Type of Calculation that the Driver Performs.

  • Register—Only applies when the User Defined check box is selected.

Use the Register field to specify the maximum acceptable gap in any group of registers that the driver is to poll (scan).

Whenever the SCADAPack Modbus driver is to scan a group of registers in which there are a number of unused registers:

  • If the gap size is less than or equal to the specified unused Register gap, the driver will scan the registers in one read request (providing that this does not exceed the maximum number of registers that can be read in one request).
  • If the gap is greater than the unused Register gap, the driver will split the poll into multiple read requests—one for the group of registers before each large gap, and another for the group of registers after each large gap.
  • Coil/Discrete Input—Only applies when the User Defined check box is selected.

Use the Coil/Discrete Input field to specify the maximum acceptable gap in a group of coils or discrete inputs that the driver is to poll (scan). The value that you specify has to be a multiple of 8 (as coils and input discretes are returned in one-byte blocks (which equates to 8 coils or input discretes)).

Whenever the SCADAPack Modbus driver is to scan a group of coils or discrete inputs in which there are a number of unused coils or discrete inputs:

  • If the gap size is less than or equal to the specified unused Coil/Discrete Input gap, the driver will scan each of the coils or discrete inputs in one read request.
  • If the gap is greater than this unused Coil/Discrete Input gap, the driver will split the poll into multiple read requests—one for the group of coils or discrete inputs before each large gap, and another for the group of coils or discrete inputs after each large gap.

Further Information

The types of ClearSCADA points that represent Modbus registers, coils, and discretes: see SCADAPack and Generic Modbus Point Addressing.

The maximum number of registers that can be read in one request: see Modbus Function Codes Supported by the ClearSCADA SCADAPack Modbus Driver.


SCADAPack Modbus Driver Guide - The Type of Calculation that the Driver Performs (Configuring Controllers on the SCADAPack Modbus Driver)

The Type of Calculation that the Driver Performs

The maximum gap size used to determine whether to split a poll into more than one read request can be user defined, or be calculated automatically by the SCADAPack Modbus driver (see Specify how any Scanning Gaps are Handled).

If the driver performs the calculation automatically, it calculates the optimum maximum gap size based on the channel’s configured pre- and post-message delay, plus the time needed to transmit the header bytes on both Tx (transmitted) and Rx (received) messages.

In each case:

  • The minimum gap is at least 4 registers or 40 coils or discretes
  • The maximum gap is the maximum number of registers, coils, or discretes that can be read in one request (see Modbus Function Codes Supported by the ClearSCADA SCADAPack Modbus Driver).

The number of header bytes varies, depending on the type of Modbus communications being used:

Modbus RTU

With Standard addressing, the header bytes total 13 (((Address + function + 2 byte CRC) * 2) + read command + reply count)

With Extended addressing, the header bytes total 17.

Modbus ASCII

With Standard addressing, the header bytes total 25 (3 framing bytes (:CRLF) + (((( Address + function + LRC) * 2) + read command + reply count) * 2))

With Extended addressing, the header bytes total 33.

Modbus TCP

With Standard addressing, the header bytes total 21 (((TCP header (6 bytes) + address + function) * 2) + read command + reply count)

With Extended addressing, the header bytes total 25.

Example:

A device is configured to use the following:

  • Modbus RTU
  • Standard addressing
  • A serial line at 9600 baud rate
  • No pre- or post-message delay.

The driver is configured to automatically calculate the optimum maximum gap size. To do this, the driver uses one of the following calculations (depending on the type of data that is to be read):

For registers:

14 (time in ms to transmit overhead bytes) / 3 (time is ms to transmit 1 register) = 4 registers.

For coils:

14 (time in ms to transmit overhead bytes) / 2 (time in ms to transmit 8 coils)) * 8 = 56 coils.

Further Information

Specify the Required Modbus Protocol and Packet Size.

Standard and Extended Addressing: see SCADAPack and Generic Modbus Controller Addressing.


SCADAPack Modbus Driver Guide - Specify the Heartbeat Address that is used on a Shared Controller (Configuring Controllers on the SCADAPack Modbus Driver)

Specify the Heartbeat Address that is used on a Shared Controller

This section applies to SCADAPack and Generic Modbus Shared controllers only.

If you use Heartbeat polling to monitor the state of the idle line to any of the above controllers, you need to specify the address of the register or coil that the driver is to read for such heartbeating.

Use the Heartbeat Address field toward the bottom of the Shared tab to specify this address.

When Heartbeat polling is enabled on a SCADAPack or Generic Modbus Shared Controller...
...The Heartbeat Address field becomes available for use.

For information on configuring the fields that are displayed within the Heartbeat section of the Shared tab, see Poll Outstations on the Other Channel in the ClearSCADA Guide to Advanced Drivers.


SCADAPack Modbus Driver Guide - Configuring a Generic Modbus Controller

Configuring a Generic Modbus Controller

The SCADAPack Modbus driver supports three types of Generic Modbus controller (see Configuring Controllers on the SCADAPack Modbus Driver).

For each type of ‘generic’ (non-SCADAPack) Modbus controller on your system, you need to specify the controller features using the fields on the appropriate Generic Modbus Outstation Form.

Each Generic Modbus Outstation Form has several tabs.

Use the Modbus tab to:

  • Specify the Controller Address
  • Specify the Point Address Range
  • Specify Whether the Registers are Swapped
  • Specify when a Control Request has Completed Successfully
  • Specify the Register Write Function
  • Define the Data Retrieval Intervals
  • Specify how any Scanning Gaps are Handled
  • Specify any Local Pre and Post Amble Message Settings (see Define any Pre- and Post-Ambles for an Individual Outstation in the ClearSCADA Guide to Advanced Drivers).

For information on the other tabs, see Configuring Controllers on the SCADAPack Modbus Driver.

For information on the minimal amount of configuration that you can undertake to produce a functional Generic Modbus controller in ClearSCADA, see Minimum Configuration.

NOTE: If your system includes Generic Modbus controllers that do not have ‘live’ points, see Generic Modbus Controller and Associated Channel States.


SCADAPack Modbus Driver Guide - Minimum Configuration (Configuring a Generic Modbus Controller)

Minimum Configuration

As a minimum, for a Generic Modbus controller to become functional (online), you have to configure these features on the Generic Modbus Outstation Form, then put the controller In Service and save the configuration:

  • The Set to which the controller belongs (Outstation tab)
  • The controller’s Address (Modbus tab)
  • The Point Address Range (Modbus tab)
  • The telephone number of the site on which a PSTN controller is located (PSTN tab)
  • The Network properties for a network connected controller (Network tab)
  • The Shared properties for a shared controller (Shared tab).

This will result in a functional Generic Modbus controller that uses the default configuration settings.


SCADAPack Modbus Driver Guide - Specify Whether the Registers are Swapped (Configuring a Generic Modbus Controller)

Specify Whether the Registers are Swapped

The Swap Registers check box applies when two or more Modbus registers store the value of a point on a controller. Use the check box to specify the order in which the Words of data that form the point value are presented to ClearSCADA.

Ensure that the Swap Registers check box is clear if the data in the registers is not to be swapped for use within ClearSCADA. For multi-register data, the highest numbered register contains the most significant Word.

Select the Swap Registers check box if the Word values are to be swapped for use within ClearSCADA. For multi-register data, the lowest numbered register contains the most significant Word.

Example 1:

The data for an Analog Input point is stored in registers 30016 to 30017. The Registers are not swapped.

The present value of the Analog is:

Word 16 = 1
Word 17 = 0

As the registers are not swapped, this results in the Analog point being given a value of 1 within ClearSCADA.

If the configuration was such that the registers were swapped, this would result in the Analog point being given a value of 65536 within ClearSCADA.

Example 2:

An Analog Input point obtains its data from Generic Modbus registers 30010 to 30013. The registers are not swapped, therefore register 30013 contains the most significant Word.

(If the registers were swapped, register 30010 would contain the most significant Word, and register 30013 the least significant.)


SCADAPack Modbus Driver Guide - Specify when a Control Request has Completed Successfully (Configuring a Generic Modbus Controller)

Specify when a Control Request has Completed Successfully

Use the Complete Control on Acknowledge check box to specify the response that a controller sends to ClearSCADA, in order to indicate the successful completion of a control request.

Select the check box for ClearSCADA to process an acknowledge exception response as a successful control completion response. Ensure that this check box is selected if a controller responds to a register write command with an exception response acknowledgment, rather than the usual Modbus successful write response.

Ensure that the Complete Control on Acknowledge check box is clear if a controller responds to a write command with a conventional Modbus successful write response.


SCADAPack Modbus Driver Guide - Specify the Register Write Function (Configuring a Generic Modbus Controller)

Specify the Register Write Function

Use the Register Write Function combo box to specify which function ClearSCADA uses when writing to a controller’s registers.

Choose from:

  • Driver Defined—The default option. Select this option if a controller supports both Single and Multiple Register Writes—the driver uses the most appropriate command:
  • For controllers that use a TCP framing type, the driver uses a Multiple Register Write (FC 16). (The framing type is specified using the Protocol Type field on the Channel Form—see Specify the Required Modbus Protocol and Packet Size.)
  • For controllers that use RTU or ASCII framing (see Specify the Required Modbus Protocol and Packet Size), the driver uses a Single Register Write (FC 06) when writing single registers (16-bit data types), and a Multiple Register Write (FC 16) when writing larger data types (such as 32-Bit Integers, and Single or Double Precision Floating Analog Points).
  • Multiple Register Write (FC 16)—Select this option only if the controller does not support Single Register Writes.
  • Single Register Write (FC 06)—Select this option only if the controller does not support Multiple Register Writes. (With such controllers, several protocol operations are required to control 32- or 64-bit values, and as such, more bandwidth is consumed than with controllers that support Multiple Register Writes.)


SCADAPack Modbus Driver Guide - Configuring a SCADAPack Controller

Configuring a SCADAPack Controller

NOTE: For each ‘generic’ (non-SCADAPack) Modbus controller on your system, you need to configure a Generic Modbus Controller, as opposed to a SCADAPack Controller—see Configuring a Generic Modbus Controller. (ClearSCADA interrogates SCADAPack devices for information that is unique to SCADAPack controllers, such as the firmware version.)

The SCADAPack Modbus driver supports three types of SCADAPack controller (see Configuring Controllers on the SCADAPack Modbus Driver).

For each SCADAPack controller that exists on your system, you need to specify the controller features using the fields on the appropriate SCADAPack Outstation Form. (Unless the SCADAPack controller has additional features enabled that are supported by a SCADAPack Modbus Extension Driver—in which case, see the relevant section in the appropriate SCADAPack Modbus extension driver guide.)

Each SCADAPack Outstation Form has several tabs.

Use the fields on the SCADAPack tab to:

  • Specify the Address Mode
  • Specify the Controller Address
  • Specify the Firmware Type
  • Specify the Point Address Range
  • Define the Set Clock Method
  • Define the Data Retrieval Intervals
  • Specify how any Scanning Gaps are Handled
  • Define Whether Logged Data Records are Scanned
  • Specify Whether ClearSCADA can Suspend Polling of a Controller
  • Specify any Local Pre and Post Amble Message Settings (see Define any Pre- and Post-Ambles for an Individual Outstation in the ClearSCADA Guide to Advanced Drivers).

For information on other tabs, see Configuring Controllers on the SCADAPack Modbus Driver. For information on the minimal amount of configuration that you can undertake to produce a functional SCADAPack controller in ClearSCADA, see Minimum Configuration.

NOTE: If your ClearSCADA system is running a SCADAPack Modbus Extension Driver, to communicate with SCADAPack controllers that have additional features enabled, see the relevant configuration section in the appropriate SCADAPack Modbus extension driver guide. The configuration Forms for such controllers typically contain other driver-specific tab(s) in addition to the SCADAPack tab covered in this section.


SCADAPack Modbus Driver Guide - Minimum Configuration (Configuring a SCADAPack Controller)

Minimum Configuration

As a minimum, for a SCADAPack controller to become functional (online), you have to configure these features on the SCADAPack Outstation Form, then put the controller In Service and save the configuration:

  • The Set to which the controller belongs (Outstation tab)
  • The Addressing Mode (SCADAPack tab)
  • The controller’s Address (SCADAPack tab)
  • The Firmware Type (SCADAPack tab)
  • The Point Address Range (SCADAPack tab)
  • The DLOG properties (if required) (SCADAPack tab)
  • The telephone number of the site on which a PSTN controller is located (PSTN tab)
  • The Network properties for a network connected controller (Network tab)
  • The Shared properties for a shared controller (Shared tab).

This will result in a functional SCADAPack controller that uses the default configuration settings.


SCADAPack Modbus Driver Guide - Specify the Address Mode (Configuring a SCADAPack Controller)

Specify the Address Mode

Use the Addressing Mode field on the SCADAPack tab to specify whether a SCADAPack controller uses Standard or Extended (Modbus) addressing.

Where a controller uses Standard addressing, Modbus addresses 1 to 255 are valid.

Where a controller uses Extended addressing, the valid address range is 1 to 65534. Use Extended addressing if more than 255 controllers exist on your system (see SCADAPack and Generic Modbus Controller Addressing).

Use the Address field to Specify the Controller Address.


SCADAPack Modbus Driver Guide - Specify the Firmware Type (Configuring a SCADAPack Controller)

Specify the Firmware Type

Use the Firmware Type field on the SCADAPack tab to specify the type of firmware used in a SCADAPack controller. Specify TelePACE, or ISaGRAF, as applicable.

With newer SCADAPack controllers, ClearSCADA is able to ascertain the firmware type when it first contacts the controller—you can then view the Firmware Type in the Status display for the controller (see SCADAPack Modbus Specific Status Display Attributes). In such cases, you can leave the Firmware Type property on the Outstation Form at the default.

For older SCADAPack controllers, ensure that you specify the actual Firmware Type that the controller uses.


SCADAPack Modbus Driver Guide - Define the Set Clock Method (Configuring a SCADAPack Controller)

Define the Set Clock Method

Use the Set Clock Method field on the SCADAPack tab to define whether a controller’s clock is synchronized from ClearSCADA or another source:

The options vary, depending on the type of controller:

  • None—The controller’s clock is synchronized via a source other than ClearSCADA.
  • TeleBUS—ClearSCADA synchronizes a SCADAPack controller’s clock using a TeleBUS protocol command.

For information about any Set Clock Method options not mentioned above, see the appropriate SCADAPack Modbus extension driver guide.


SCADAPack Modbus Driver Guide - Define Whether Logged Data Records are Scanned (Configuring a SCADAPack Controller)

Define Whether Logged Data Records are Scanned

Use the fields within the DLOG section of the SCADAPack tab to define whether ClearSCADA is to scan logged data (DLOG) records on a SCADAPack controller, and the settings for such scanning:

  • Enabled—ClearSCADA supports scanning of SCADAPack logged data records. Select this check box to enable the driver to scan and read logged data records from a controller.

NOTE: When DLOG functionality is enabled, ensure that one (and only one) of the controller’s DLOG fields is configured as a Time Stamp field. The controller uses the field to specify the time stamps for the associated point data.

Ensure that the Enabled check box is clear if the driver is not to read logged data records from a controller. The driver only scans the controller for real time data. The other fields within the DLOG section of the tab are ‘grayed out’ and unavailable for use.

  • Scan Rate—Use to specify the rate at which the driver is to scan logged data records.

Enter the rate in the OPC Time Format, for example, 5M for five minutes.

  • Max DLOG Requests per Scan—Use to specify the number of consecutive DLOG requests that the driver can issue per scan, regardless of DLOG ID. By limiting the number of requests, this helps to ensure that the driver is given sufficient time to scan for real time data as well as logged data.

When ClearSCADA scans for DLOG data, it extracts the data for the lowest configured DLOG ID first (which may be split, as defined by the Max DLOG Requests per Scan setting), and then moves onto the next configured DLOG ID, and so on. The driver only polls for those DLOG IDs that are configured in the ClearSCADA database—if a particular DLOG ID has not been allocated to a point in the database, the driver will not poll for data at that ID. (You assign DLOG IDs on a per point basis. For more information, see Log Point Data on SCADAPack Controllers.)


SCADAPack Modbus Driver Guide - Specify Whether ClearSCADA can Suspend Polling of a Controller (Configuring a SCADAPack Controller)

Specify Whether ClearSCADA can Suspend Polling of a Controller

Polling of a SCADAPack controller needs suspending under certain circumstances, such as to allow software to be written to a controller. Polling is typically suspended via a Remote Connection interface.

Use the fields in the Suspend Polling section of the SCADAPack tab to specify whether to allow ClearSCADA to postpone polling of a SCADAPack controller and for how long.

  • Allowed—Select this check box for ClearSCADA to be able to postpone polling of a controller, for the time specified in the Duration field. Once enabled, polling can be suspended using the Suspend Polling pick action.

Clear the Allowed check box if ClearSCADA is not to postpone polling of the controller.

  • Duration—Use to specify the time period for which ClearSCADA can postpone polling a controller. Enter the time in the OPC Time Format, for example 5M for a five-minute duration.

If you intend to update the firmware in a controller using the Firmware Loader® program, ensure that this duration is long enough to cover the entire firmware load. The time required varies, depending on the type of controller and communications channel used.

Example:

A Duration of 20M (20 minutes) is sufficient to update the firmware in a SCADAPack controller that is using a 9600 baud serial channel.


SCADAPack Modbus Driver Guide - Configuring a SCADAPack Modbus Remote Connection

Configuring a SCADAPack Modbus Remote Connection

NOTE: You only need to create and configure a SCADAPack Modbus Remote Connection if ClearSCADA is to share a communications link with other software applications (such as TelePACE) in order to communicate with SCADAPack or Generic Modbus controllers. A SCADAPack Modbus Remote Connection is not required if ClearSCADA and the other software applications use separate communications links to interrogate SCADAPack or Generic Modbus controllers.

A SCADAPack Modbus Remote Connection allows ClearSCADA to share a link with software applications such as TelePACE, and ISaGRAF, such that both ClearSCADA and the other application(s) use the same link to communicate with SCADAPack or Generic Modbus controllers. With a shared connection, ClearSCADA acts as a ‘gateway’, to allow such applications to interrogate the controllers remotely. When the applications communicate with SCADAPack or Generic Modbus controllers via ClearSCADA, the application software communicates with ClearSCADA, and then ClearSCADA communicates with the controllers.

For systems on which such applications are to use ClearSCADA to communicate with SCADAPack or Generic Modbus controllers remotely, you need to configure one or more SCADAPack Modbus Remote Connections. Each Remote Connection provides a TCP/IP socket connection between ClearSCADA and the remote applications (such as TelePACE). ClearSCADA extracts the address information from any messages sent via this connection, in order to establish the SCADAPack or Generic Modbus controller to which the messages relate. ClearSCADA then interrogates the appropriate controller and sends the data on to the remote application.

You need to configure one SCADAPAck Modbus Remote Connection in the ClearSCADA database per TCP/IP port that a remote application is to use to communicate with ClearSCADA. One Remote Connection can enable multiple applications to communicate remotely with numerous SCADAPack or Generic Modbus controllers.

You configure the properties for each remote connection using the fields on the SCADAPack Modbus Remote Connection Form.

The Form has several tabs.

Use the Remote Connection tab to:

  • Specify Whether a Remote Connection is Active (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration)
  • Define the Severity of any Alarms or Events (see Defining Severities in the ClearSCADA Guide to Core Configuration)
  • Specify the Frequency with which Communications Statistics are Updated.

NOTE: If the Area of Interest feature is enabled on your system, an additional Area of Interest field is displayed immediately below the Severity field. Use the field to specify the Area of Interest with which any remote connection alarms or events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).
For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

Use the Connection tab to:

  • Specify the Port Number via Which a Remote Application Communicates with ClearSCADA.

For information on the fields on other tabs, see Tabs that are Common to Many Configuration Forms in the ClearSCADA Guide to Advanced Drivers.

NOTE: To display remote connection details in List format from the Queries Bar, filter the constraints on the Channels List.


SCADAPack Modbus Driver Guide - Specify the Frequency with which Communications Statistics are Updated (Configuring a SCADAPack Modbus Remote Connection)

Specify the Frequency with which Communications Statistics are Updated

Use the Communication Statistic Updates section on the Remote Connection tab to define how often the communication statistics are updated. You can view the statistics on the remote connection’s Status display.

  • Interval—Use to specify the frequency at which a remote connection’s communications statistics are updated.

Enter the frequency in the OPC Time Format, for example, 1M for one minute, or specify 0 to disable the Communications Statistics feature.

  • Offset—Use to specify the offset, from midnight, for the first communications statistics update. Thereafter, the statistics are updated at the frequency specified in the Interval field, above.

Enter the offset in the OPC Time Format, for example 30S for a 30-second offset.

Example:

The Communication Statistic Updates properties for a remote connection are configured as:

Interval = 1M
Offset = 30S

If the time is currently 00:00:00, the next Communications Statistics update will occur at 00:00:30, followed by another update at 00:01:30, then another update at 00:02:30, and so on, at 1-minute intervals offset to 30-seconds past each minute.


SCADAPack Modbus Driver Guide - Specify the Port Number via Which a Remote Application Communicates with ClearSCADA (Configuring a SCADAPack Modbus Remote Connection)

Specify the Port Number via Which a Remote Application Communicates with ClearSCADA

Use the Port field on the Connection tab to specify the TCP/IP port number that ClearSCADA uses to listen for commands from the application software.

The default is 49155. Specify the required number, typically in the range 1025 to 65535 (numbers 1 to 1024 are reserved for special use).

Where only one Remote Connection exists on a system, you can leave this setting at its default. Where multiple Remote Connections exist, ensure that different Port numbers are specified for each connection.


SCADAPack Modbus Driver Guide - Points Used on SCADAPack Modbus Controllers

Points Used on SCADAPack Modbus Controllers

SCADAPack and Generic Modbus controllers support a combination of these point types:

  • SCADAPack Modbus Analog Input Points—see Configuring Analog Points.
  • SCADAPack Modbus Analog Output Points—see Configuring Analog Points.
  • SCADAPack Modbus Digital Input Points—see Configuring Digital Points.
  • SCADAPack Modbus Digital Output Points—see Configuring Digital Points.

You need to configure one point of the appropriate type per point on a controller. You configure the properties for each point using the appropriate SCADAPack Modbus Point Form.

The rest of this section covers the configuration of properties that are common to most points supported by the SCADAPack Modbus driver. It includes information on how to:

  • Configure Common Point Properties
  • Use Persistence to Stop Fleeting Changes in Value from Changing a Point State
  • Log Point Data on SCADAPack Controllers.

For information on the minimal amount of configuration that you can undertake to produce a functional SCADAPack or Generic Modbus point in ClearSCADA, see Minimum Configuration.

NOTE: In addition to the points listed above, ClearSCADA can support other types of point, using a SCADAPack Modbus Extension Driver. For information on SCADAPack Modbus points not listed above, see the relevant SCADAPack Modbus extension driver guide.

NOTE: If your system includes Generic Modbus controllers that do not have ‘live’ points, see Generic Modbus Controller and Associated Channel States.


SCADAPack Modbus Driver Guide - Minimum Configuration (Points Used on SCADAPack Modbus Controllers)

Minimum Configuration

For each SCADAPack Modbus point, as a minimum you have to specify these features on the appropriately named <Point Type> tab, then put the point In Service and save the configuration:

  • The controller on which the point is located
  • The point’s address
  • The data Retrieval Interval
  • The Scan Group (Confidence Interval)
  • The Logged Data properties (if required)
  • For Digital points, the Number of Bits
  • For Analog points, the Data Type, and the Scaling.

Additionally, if the point is an output point, you have to:

  • Enable and configure the required properties on the Control tab.

If you want SCADAPack Modbus point data to be stored historically, you also have to:

  • Enable and configure logging on the Historic tab if data is to be stored historically in the server database.


SCADAPack Modbus Driver Guide - Configure Common Point Properties (Points Used on SCADAPack Modbus Controllers)

Configure Common Point Properties

Use the fields at the top of the <Point Type> tab to configure the common point properties.

The following fields are common to most points on SCADAPack and Generic Modbus controllers. For fields that are not described here, see the relevant point configuration section within this guide.

  • In Service—Use to specify whether a point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point that is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Outstation—Use to specify the controller on which a point is located. Use the browse button to display a Reference browse window and select the relevant controller from the window.
  • Address—Use to specify the point’s address. Ensure that you specify the address in the format and range that is supported by the controller on which the point is located (see Specify the Point Address Range). Current SCADAPack controllers use 5 Digit addressing.

For a table of acceptable address ranges for each point type, see SCADAPack and Generic Modbus Point Addressing.

  • Severity—Use this combo box to define the severity of point status alarms. For more information on severities, see Defining Severities in the ClearSCADA Guide to Core Configuration.
  • Retrieval Interval—Use this combo box to determine how often the server polls the controller to retrieve the point's current data.
  • None - Not Polled—The server does not poll the controller for the point's current data.
  • Interval 1 to Interval 8—The server polls the controller for the point's current data at timed intervals. The actual frequency of the selected interval is configured on the corresponding SCADAPack or Generic Modbus Outstation Form (see Define the Data Retrieval Intervals).
  • Continuous—The server constantly polls the controller for the point's current data.

The Retrieval Interval defines the polling frequency between ClearSCADA and the controller on which the point is located. If Persistence is used, any point state changes will be delayed until the specified persistence time has expired. If the point is configured to use Significant Change, any change in point value will only be recorded if the change exceeds the Significant Change deadband. For more information on both of these properties, see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State.

On SCADAPack controllers, the Retrieval Interval combo box on ‘standard’ points is ‘grayed out’ and unavailable for use if the server only retrieves logged, but not current data for that point. (This occurs when the point’s DLOG Only check box is selected—see Log Point Data on SCADAPack Controllers.)

Be aware that the Retrieval Interval field does not apply to some point types supported by SCADAPack Modbus Extension Drivers.

  • Scan Group (Confidence Interval)—Use the combo box to specify the Scan Group with which the point is associated. The Scan Group determines the frequency with which the driver updates the server with the current value for the point. This provides confidence that all is well between ClearSCADA and the direct controller, as the point is updated in the database at the Scan Group rate, regardless of whether the point has changed in the controller.

With most types of point on the SCADAPack Modbus driver, the specified Scan Group triggers a poll for data at the corresponding Scan Group interval. You therefore typically assign a Scan Group that has an interval that is a multiple of the point’s Retrieval Interval rate. Be aware that if a Scan Group is specified that has a faster interval than the Retrieval Interval, polling will occur at the Scan Group rate (however, this is not recommended).

For any type of point on the SCADAPack Modbus driver, specify the frequency of each Scan Group on the Scan Parameters tab of the associated Channel Form (see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers).

The Scan Group (Confidence Interval) combo box does not apply if the server only retrieves logged, but not current data for a point. (This occurs when a point’s DLOG Only check box is selected—see Log Point Data on SCADAPack Controllers.)

NOTE: The polling of some point types that are supported by SCADAPack Modbus Extension Drivers differs from that mentioned above. Where the polling regime differs, the difference is explained in the relevant SCADAPack Modbus extension driver guide.


SCADAPack Modbus Driver Guide - Use Persistence to Stop Fleeting Changes in Value from Changing a Point State (Points Used on SCADAPack Modbus Controllers)

Use Persistence to Stop Fleeting Changes in Value from Changing a Point State

Most types of point on SCADAPack Modbus controllers support Persistence.

Use Persistence to stop momentary changes in point value from changing the state of a point. When used, persistence stops the driver from processing fleeting changes in point state and reporting those fleeting changes to the server. This stops ClearSCADA from raising change of state alarms and logging change of state events when a point value is fluctuating.

You can configure persistence for changes into a state, or out of a state, using a point’s Persistence Type field. Use this field in conjunction with the Persistence Duration fields, which define the required amount of time before a change in point value is recorded as a change in point state. The persistence fields are on the <Point Type> tab of the Point Form.

Use the Persistence Type field to specify one of the following:

  • None—Persistence is not used for the point. Any changes in point state will be recorded as soon as they occur.
  • Into State—When a point’s value changes, any change of point state is delayed until the point has remained in that new state for the specified Persistence Duration. Only then is the new state recorded.

If, within the Persistence Duration, the point value changes such that the point reverts back to its previous state, the fleeting change in state will not be recorded and the point will be deemed not to have changed.

If, within the Persistence Duration, the point value changes further, such that the point enters another state, the persistence timer will be restarted. The timer will then run for the Persistence Duration of the newly entered state, before recording the point as being in that new state (providing that the point does not enter yet another state before the Persistence Duration has elapsed).

  • Out of State—When a point’s value changes, any change from its current state has to persist for the specified Persistence Duration for that change in state to be recorded. The point can enter any number of other states during this time, as long as it remains out of its original state.

If, within the Persistence Duration, the point value changes such that the point does revert back to its original state, the fleeting change in state will not be recorded and the point will be deemed not to have changed.

NOTE: Persistence delays the recording of a change in state, not the recording of a change in value. If a point is also configured to use Significant Change and a change in value exceeds the Significant Change Deadband, the value of the point will be updated immediately, although the state will not have changed at that stage. Any change in state will only be recorded, along with the point’s current value at that time, once the Persistence Duration has elapsed. (For an example that demonstrates this, see Use Persistence with an Analog Point.)

With a Persistence Type other than ‘None’, use the point’s Persistence Duration fields to specify the amount of time during which a change in state has to persist, before that change in state is recorded:

With digital points, a Persistence Duration field exists for each point state.

With analog points, a Persistence Duration field exists for each state limit. (Persistence does not apply should an analog point become over range (above Full Scale), under range (below Zero Scale), or Invalid, as these states are reported immediately.)

For each change in state that is to persist before it is recorded, use the relevant Persistence Duration field to specify the required time period. You can either enter the time period in the OPC Time Format directly in the field, or use the Interval Window (accessed via the field’s browse button) to specify the required value. (Leave a Persistence Duration field at the default of 0 for any state changes that are to be recorded immediately.)

Be aware that an analog point’s Significant Change settings also have an effect on when and if that point’s change in value and state is recorded:

With a Persistence Type other than ‘None’, whenever an analog point’s value crosses a state limit, the relevant Persistence Duration begins.

If the point’s Significant Change Deadband has not been exceeded due to the value change, then the value of the point will only be updated once the Persistence Duration expires.

However, if the point’s Significant Change Deadband has been exceeded due to the value change, then the value change will be recorded immediately, but the point state will remain the same. Once the Persistence Duration expires, the point’s current value will be logged, along with the new state. This is because persistence applies to the state change and not the value change. (If, during the Persistence Duration, the point’s value crosses the state limit back to the original state, the point value will not update and the persistence time will be canceled.)

For examples that demonstrate how persistence might be used with points on the SCADAPack Modbus driver, see the following:

  • Use Persistence with an Analog Point
  • Use Persistence with a Digital Point.


SCADAPack Modbus Driver Guide - Use Persistence with an Analog Point (Points Used on SCADAPack Modbus Controllers)

Use Persistence with an Analog Point

These examples demonstrate how persistence might be used on an analog point on the SCADAPack Modbus driver. Additionally, the second part of the Out of State Persistence example illustrates how Significant Change settings affect when the point’s change in value is recorded.

For more information on persistence, see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State. For more information on Significant Change, see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration.

Example 1 - Into State Persistence:

An analog point has this configuration:

The relevant persistence time begins whenever the analog point’s value crosses a state limit.

The analog point changes value from 50 (Normal state) to 35. A period of 2 seconds has to elapse before the point value and point state (Low) are deemed to have changed and are recorded. This is because the Persistence Duration for the point going into the Low state is specified as 2S (2 seconds).

If, during this two-second period, the point’s value rose back above 40 (back into the Normal state), no change in point value or state would be recorded, as the point would be deemed not to have changed.

If, during the two-second period, the point’s value did not rise, but instead it continued to fall, if it dropped below 20 (the Low Low limit), the persistence timer would restart. A period of 5 seconds would then have to elapse before the point value and state (Low Low) were deemed to have changed and are recorded. This is because the Persistence Duration for the point going into the Low Low state is specified as 5S (5 seconds).

Example 2 - Out of State Persistence:

An analog point has this configuration:

The relevant persistence time begins whenever the analog point’s value crosses a state limit.

The analog point changes value from 50 (Normal state) to 35. As the Normal state’s Persistence Duration is zero, the change in point value and point state (Low) are recorded immediately.

The point’s value continues to fall. The value drops below 20, triggering the Out of State Persistence Duration for the Low limit. This is triggered as soon as the point moves out of the Low state into another state. A period of 2 seconds then has to elapse before the point value and point state (Low Low) are deemed to have changed and are recorded. This is because the Persistence Duration for the point going out of the Low state is specified as 2S (2 seconds).

If, during this two-second period, the point’s value changes further, rising above 20, back into the Low state, the fleeting change in point value and state (to Low Low) would not be recorded, as the point would be deemed not to have changed from the Low state.

If the point’s value continues to rise, once it travels out of the Low state again, it would trigger the Out of State Persistence Duration for that state. It the point remains out of the Low state for the entire 2-second duration, its new state and value would be recorded as that duration elapses. So, if after 2 seconds the point’s value is 75, this value, along with its new state (High) would be recorded.

If the point used these Significant Change settings, along with a Persistence Type of ‘Out of State’:

If the change in point value when the point moved into the Low Low state resulted in a value change that exceeded the Significant Change Deadband, the new value and old state (Low) would be recorded immediately, due to that Deadband being exceeded. (The Deadband in this example is 5% of the point range (Zero Scale to Full Scale).) Additionally, if the point remained out of the old state (Low) for the Persistence Duration of 2S (2 seconds), once that duration had elapsed, the current point value (which might differ from the value that was recorded when the Significant Change Deadband was exceeded) and new state (Low Low) would be recorded. However, if at any stage during the Persistence Duration, the point reverts back to a value greater than 20 (back into the Low state), the fleeting change to the Low Low state would not be recorded.

Similarly, if the change in point value when the point rose out of the Low state resulted in a value change that exceeded the Significant Change Deadband, the new value and old state (Low) would be recorded at that instant. Then when the Low state’s Out of State Persistence Duration has been exceeded, the point’s current value (75 in this example) and state (High) would be recorded.


SCADAPack Modbus Driver Guide - Use Persistence with a Digital Point (Points Used on SCADAPack Modbus Controllers)

Use Persistence with a Digital Point

This example demonstrates how persistence might be used on a digital point on the SCADAPack Modbus driver. For more information on persistence, see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State.

Example:

A one-bit digital point has this configuration:

The relevant persistence time begins whenever the digital point’s value changes.

As such, when the point changes from ‘Running’ to ‘Stopped’, three seconds has to elapse before the value and state are recorded as having changed (as the point’s Persistence Type is configured as ‘Into State’, with a Persistence Duration of 3S (3 seconds) for the ‘Stopped’ state). If, during this three-second period, the value changes back, the fleeting change in value and state are not logged.

(If the Persistence Type was ‘Out of State’, when the point changed from ‘Running’ to ‘Stopped’, only two seconds would need to have elapsed before the value and state were recorded as having changed (as the Persistence Duration for the state that was being left is specified as 2S (2 seconds)). Again, if the point value changed back at any time during the two-second persistence period, the fleeting change in value and state would not be logged, as the point would be deemed not to have changed value.)


SCADAPack Modbus Driver Guide - Log Point Data on SCADAPack Controllers (Points Used on SCADAPack Modbus Controllers)

Log Point Data on SCADAPack Controllers

On SCADAPack controllers, you can log point data historically, in the form of DLOG records.

Define the specifications for such logging, using the fields within the Logged Data section of the <Point Type> tab of the appropriate Point Form:

  • DLOG ID—On SCADAPack controllers, use this combo box to specify the DLOG ID (1 to 16) for a point. You can use the same DLOG ID for up to seven different points (where those points are any supported point type). (Generic Modbus controllers do not support DLOG data, therefore the DLOG ID is fixed to ‘None’.)

Where a DLOG ID other than None is specified, the server retrieves SCADAPack DLOG record data for a point. Should a historic value have a newer time stamp than the point’s current value, ClearSCADA will update the point with the more up-to-date data, along with other relevant processing.

Where a point has no DLOG ID and the value None is specified, ClearSCADA only retrieves current data for a point, using ClearSCADA’s usual scanning mechanism.

  • DLOG Only—Applies when a DLOG ID other than ‘None’ is specified above and the point is a ‘standard’ Digital Input or Analog Input. Select this check box for the server to only retrieve logged data for a point, via the SCADAPack DLOG mechanism. No current data is retrieved for the point.

Ensure that the check box is clear for ClearSCADA to scan a point for both current data and DLOG data.

  • Field—Applies when a DLOG ID other than ‘None’ is specified above. Use the combo box to specify the number of the field that is used to store the DLOG record at the controller. Specify the required number, in the range 1 to 8.
  • Bit Packed—Applies to Digital points only. Select this check box if the DLOG record for a digital point is ‘packed up’ with the records for other digital points at the controller. Use the Bit Offset field (see below) to specify the offset for the record for this particular digital point.

Ensure that the Bit Packed check box is clear if the DLOG record for each digital point is stored separately at the controller. Only records for 1-bit Digital points can be stored separately.

  • Bit Offset—Applies to Digital points only. Use the spin box to specify the bit offset in the DLOG record for a digital point, when it is ‘packed up’ with the data for other digital points.
  • Historically Store Current Data—Select this check box for ClearSCADA to store both current values and DLOG values historically.

Ensure that the check box is clear for ClearSCADA to store only DLOG values historically.

  • Alarms From—Only applies when DLOG ID is set to an option other than ‘None’. Use the Alarms From combo box to specify how the ClearSCADA server processes the data that it retrieves from a SCADAPack controller, specifically when the server raises and clears point alarms. Choose All Data, Logged Data Only, Most Recent Data, or Most Recent Logged Data, as appropriate. For more information on each option, see Processing Alarm Data for Point States in the ClearSCADA Guide to Advanced Drivers.


SCADAPack Modbus Driver Guide - Configuring Analog Points

Configuring Analog Points

NOTE: In addition to the analog points mentioned below, ClearSCADA can support other types of analog point using a SCADAPack Modbus Extension Driver. For information on any SCADAPack Modbus points not listed below, see the relevant SCADAPack Modbus driver extension guide.

The SCADAPack Modbus driver supports SCADAPack Modbus Analog Input points and Analog Output points.

Configure the properties for each analog point using the fields on the SCADAPack Modbus Analog Input Point Form, or the SCADAPack Modbus Analog Output Point Form, as appropriate.

This section covers configuration of properties on the Analog Point tab of each Form, and the properties on the Control tab of the SCADAPack Modbus Analog Output Point Form. For information on the fields on other tabs, see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers.

For SCADAPack Modbus Analog Input or Analog Output points, use the Analog Point tab to:

  • Configure the General SCADAPack Modbus Analog Point Properties
  • Configure Alarm Limits
  • Configure any Alarm Limit Profiles (see Specify any Alarm Limit Profiles in the ClearSCADA Guide to Core Point Configuration)
  • Define the Point Scaling
  • Define the Point Formatting (see Define the Appearance of an Analog Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Override Properties (see Define whether an Analog Point can be Overridden in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Significant Change Properties
  • Configure the No Change Properties (see Detect whether an Analog Point has Stopped Changing in the ClearSCADA Guide to Core Point Configuration).
  • Specify the Trend Properties (see Define an Analog Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Logged Data Properties.

For SCADAPack Modbus Analog Output points, use the Control tab to:

  • Configure the Control Properties (see Define the Control Settings for an Analog Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Specify whether any Controllers are given Scanning Priority whenever a Control Action is Issued (see Promoting Scanning of Outstations Associated with Controls in the ClearSCADA Guide to Core Point Configuration)
  • Specify Whether to Restore the Control Value Following a Cold Reset
  • Specify Whether to Update the Point Value Immediately Following a Control.


SCADAPack Modbus Driver Guide - Configure the General SCADAPack Modbus Analog Point Properties (Configuring Analog Points)

Configure the General SCADAPack Modbus Analog Point Properties

NOTE: For information on configuring properties on SCADAPack Modbus analog points other than SCADAPack Modbus Analog Input Points and SCADAPack Modbus Analog Output Points, see the relevant SCADAPack Modbus driver extension guide.

Use the fields at the top of the Analog Point tab on the SCADAPack Modbus Analog Point Form to Configure Common Point Properties. Fields that are specific to SCADAPack Modbus Analog points are explained below.

  • Data Type—Use this combo box to specify the format of the raw data.

NOTE: The Double Precision Float data type is only supported by some generic Modbus controllers. SCADAPack controllers do not support this data type.


SCADAPack Modbus Driver Guide - Configure Alarm Limits (Configuring Analog Points)

Configure Alarm Limits

Use the fields within the Alarm Limits section of the Analog Point tab to set limits for a point and specify whether an alarm or event is generated if the point exceeds those limits.

Many of the Alarm Limits fields are common to many analog points (see Configure the Limits for an Analog Point in the ClearSCADA Guide to Core Point Configuration).

For information on Hysteresis, see Specify the Hysteresis - the Minimum Value Change that can Clear an Alarm in the ClearSCADA Guide to Core Point Configuration.

For information on Persistence Type, see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State. (Persistence does not apply to some types of analog point that are supported by SCADAPack Modbus Extension Drivers.)

For information on the Engineering Units Exceeded field, see Define how Over Range and Under Range Values are Processed in the ClearSCADA Guide to Core Point Configuration.

For information on the Tune Limits feature, see Define whether an Analog Point’s Limits can be Tuned in the ClearSCADA Guide to Core Point Configuration.

If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed within the Alarm Limits section. For more information on this property, see Specify the Area of Interest Associated with a Point’s State-Related Alarms and Events in the ClearSCADA Guide to Core Point Core Point Configuration.


SCADAPack Modbus Driver Guide - Define the Point Scaling (Configuring Analog Points)

Define the Point Scaling

Use the fields in the Scaling section of the Analog Input Point Form to specify the type and range of the raw input signals, so that they can be suitably converted into floating-point engineering values for use in the ClearSCADA database.

Conversely, use the section on the Analog Output Point Form to perform a similar conversion on any output signals. ClearSCADA uses the conversion calculation to produce a raw data value that is sent to plant.

  • Enabled—Select this check box if the input value at the controller needs scaling for use by ClearSCADA, and vice versa for output values. The SCADAPack Modbus driver performs the required scaling before passing the value on to ClearSCADA. Use the Raw Full Scale and Raw Zero Scale fields to define the scaling that is required, up to a maximum 32-bit value.

Ensure that the Enabled check box is clear if no scaling is required.

  • Raw Full Scale—Applies when Scaling is enabled. Enter the highest acceptable raw data value for the point. The range must be between 1 and 4,294,967,295.
  • Raw Zero Scale—Applies when Scaling is enabled. Enter the lowest acceptable raw data value for the point. The range must be between 0 and 4,294,967,294.


SCADAPack Modbus Driver Guide - Significant Change Properties (Configuring Analog Points)

Significant Change Properties

Use the fields within the Significant Change section of the Analog Point tab to define the amount by which an Analog point’s value has to change before it is reported to the ClearSCADA server.

For further details, see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration.

Be aware that if an analog point is configured to use Persistence in addition to Significant Change, this has an affect on when a change in point state is recorded (see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State).


SCADAPack Modbus Driver Guide - Logged Data Properties (Configuring Analog Points)

Logged Data Properties

Use the fields within the Logged Data section of the Analog Point tab to specify how the ClearSCADA server processes the data that it receives from a controller, specifically when the server raises and clears point alarms.

(Be aware that the DLOG Only property does not apply to every type of analog point supported by SCADAPack Modbus Extension Drivers.)

For information, see Log Point Data on SCADAPack Controllers.


SCADAPack Modbus Driver Guide - Specify Whether to Restore the Control Value Following a Cold Reset (Configuring Analog Points)

Specify Whether to Restore the Control Value Following a Cold Reset

This section applies to SCADAPack Modbus Analog Output Points only.

In the event of any cold reset of a controller (for example, due to power failure), a point value is lost. Use the Restore Output check box on the Control tab to define whether, in such a situation, the server restores the previous controlled value of the point, so restoring the plant to its original state.

Select the Restore Output check box for the server to restore the last controlled value should a cold reset occur.

Ensure that the Restore Output check box is clear if the server is not to restore the point to its last controlled value should a cold reset occur. A point is only restored to its last controlled value once polling is resumed, or following a manual reset (using the Reset Outstation pick action) from ClearSCADA.


SCADAPack Modbus Driver Guide - Specify Whether to Update the Point Value Immediately Following a Control (Configuring Analog Points)

Specify Whether to Update the Point Value Immediately Following a Control

This section applies to SCADAPack Modbus Analog Output Points only.

Select the Update point on successful action check box on the Control tab for the point value to be reported immediately following a successful control action.

Ensure that the check box is clear for the point value to be reported in the next poll.


SCADAPack Modbus Driver Guide - Configuring Digital Points

Configuring Digital Points

The SCADAPack Modbus driver supports 1-, 2-, and 3-bit Digital Input points and Digital Output points.

Configure the properties for each Digital point using the fields on the SCADAPack Modbus Digital Input Point Form, or the SCADAPack Modbus Digital Output Point Form, as appropriate.

This section covers configuration of properties on the Digital Point tab of both SCADAPack Modbus Digital Point Forms, and the properties on the Control tab for Digital Output points. The properties on other tabs are common to points on many advance drivers (see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers).

Use the Digital Point tab to:

  • Configure Common Point Properties
  • Specify the Point State Properties
  • Define Override Properties (see Define whether a Digital Point can be Overridden in the ClearSCADA Guide to Core Point Configuration)
  • Define Trend Properties (see Define a Digital Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Logged Data Properties.

For SCADAPack Modbus Digital Output Points, use the Control tab to:

  • Configure the Control Actions (see Define the Control Settings for a Digital Output Point in the ClearSCADA Guide to Core Point Configuration)
  • Specify whether any Controllers are given Scanning Priority whenever a Control Action is Issued (see Promoting Scanning of Outstations Associated with Controls in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Type of Control Operation
  • Specify Whether to Restore the Control Value Following a Cold Reset
  • Specify Whether to Update the Point Value Immediately Following a Control.


SCADAPack Modbus Driver Guide - Common Point Properties (Configuring Digital Points)

Common Point Properties

Use the fields at the top of the Digital Point tab to Configure Common Point Properties. Fields that are specific to digital points are explained below.

  • Bit Offset—Only applies if the point resides within a Modbus Input Register or Holding Register address range (see SCADAPack and Generic Modbus Point Addressing). Use the spin box to specify the lowest (starting) bit of the point.

With a multi-bit point, ensure that all bits are consecutive (for example, a 2-bit digital might use bits 5 and 6, where bit 5 would be the starting bit). All the bits of a multi-bit point must reside consecutively in the same Word within a register range—bits for one point cannot continue into another Word. The range is 0 to 15.

It is important to be aware of the Word order in a Modbus device. For instance, the Word order is reversed when using ISaGRAF 32-bit variables. So, for example, if an ISaGRAF 32-bit variable is assigned network address 30001, as the Words are stored in reverse order in the Modbus device, this means that bits 0 to 15 are assigned the network address 30002, and bits 16 to 31 are assigned network address 30001.

The field is ‘grayed out’ and unavailable for use if the point is an Output Coil, or Input Discrete.

  • Number of Bits—Use this combo box to specify the number of bits for the point. This corresponds to the number of consecutive 1-bit points that form the point.

The number of bits directly affects the number of point states (see Point State Properties). For further information, see Single and Multi-Bit Digital Points in the ClearSCADA Guide to Core Point Configuration.

  • Format—Specify the format in which the point’s value appears in other ViewX displays, such as Lists. For further information, see Define the Format of a Digital Point’s Values in the ClearSCADA Guide to Core Point Configuration.


SCADAPack Modbus Driver Guide - Point State Properties (Configuring Digital Points)

Point State Properties

Use the fields in the States section of the Digital Point tab to define state-related information for the point, such as the handling of state-related alarms by the controller.

Most of the fields within the States section are common to many digital points.

The Number of Bits, defined toward the top of the Form (see Common Point Properties), determines the number of state fields that are available for use.

For further information on configuring state fields, see Define the Point States for a Digital Point in the ClearSCADA Guide to Core Point Configuration.

For information on Persistence Type, see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State.


SCADAPack Modbus Driver Guide - Logged Data Properties (Configuring Digital Points)

Logged Data Properties

Use the fields within the Logged Data section of the Digital Point tab to specify how the ClearSCADA server processes the data that it receives from a controller, specifically when the server raises and clears point alarms.

For information, see Log Point Data on SCADAPack Controllers.


SCADAPack Modbus Driver Guide - Specify the Type of Control Operation (Configuring Digital Points)

Specify the Type of Control Operation

This section applies to SCADAPack Modbus Digital Output Points only.

Use the Control Operation combo box on the Control tab to specify the type of control operation that ClearSCADA is to undertake when addressing Holding Registers (see SCADAPack and Generic Modbus Point Addressing).

Choose from:

  • Direct Write—ClearSCADA writes values to the register on which the Digital Output point resides. ClearSCADA writes the values for each of the points for which it has information on that register. It sets any bits for which it does not have information to zero.

    CAUTION

    unexpected behavior of application

    Use the Direct Write option with care if a register is being used for anything other than output points. A Direct Write operation can inadvertently clear or set bits that are being used by input points, or other programs or applications.

    Failure to follow these instructions can result in equipment damage.

If other output points reside on the same register and exist in the ClearSCADA database, ClearSCADA will write the value of those points back to the register in addition to the value of the Digital Output point that is being controlled. This operation should not affect the values of the other output points in the register.

As the Direct Write operation does not entail reading the register, be aware that if input points reside on the same register, the values of those points may have changed since the control was requested and the register was last scanned. As such, the values that are written back to the bits for those points may not be the most recent values for those points.

If other bits in the register are used by programs or applications other than ClearSCADA, these will be set to zero when the values are written back to the register.

We recommend using a Direct Write operation only when a register is used purely for output points and for which information exists in the ClearSCADA database.

  • Read-Modify-Write—Only applies to points on Holding Registers. ClearSCADA reads the whole register in order to obtain the most recent values of the bits in that register. It then ANDs in the bits for this Digital Output point and writes the values back to the register.

This operation is slightly slower than a Direct Write operation, but is the option that we recommend if a register is used by anything other than this Digital Output point.

  • Mask Write (Function 22)—Only applies to points on Holding Registers. This Modbus function 22 control operation is supported by only a limited number of generic Modbus controllers. ClearSCADA writes back only the bits for this Digital Output point. Other bits in the register are not affected by the operation.


SCADAPack Modbus Driver Guide - Specify Whether to Restore the Control Value Following a Cold Reset (Configuring Digital Points)

Specify Whether to Restore the Control Value Following a Cold Reset

This section applies to SCADAPack Modbus Digital Output Points only.

In the event of any cold reset of a controller (for example, due to power failure), a point value is lost. Use the Restore Output check box on the Control tab to define whether, in such a situation, the server restores the previous controlled value of the point, so restoring the plant to its original state.

Select the Restore Output check box for the server to restore the last controlled value should a cold reset occur.

Ensure that the Restore Output check box is clear if the server is not to restore the point to its last controlled value should a cold reset occur. A point is only restored to its last controlled value once polling is resumed, or following a manual reset (using the Reset Outstation pick action) from ClearSCADA.


SCADAPack Modbus Driver Guide - Specify Whether to Update the Point Value Immediately Following a Control (Configuring Digital Points)

Specify Whether to Update the Point Value Immediately Following a Control

This section applies to SCADAPack Modbus Digital Output Points only.

Select the Update point on successful action check box on the Control tab for the point value to be reported immediately following a successful control action.

Ensure that the check box is clear for the point value to be reported in the next poll.


SCADAPack Modbus Driver Guide - Using SCADAPack Modbus Specific Actions

Using SCADAPack Modbus Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section covers actions that are SCADAPack Modbus driver-specific (see Actions Associated with SCADAPack Controllers). If your ClearSCADA system is running a SCADAPack Modbus Extension Driver, further driver-specific actions might be available—see the relevant extension driver guide for information.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


SCADAPack Modbus Driver Guide - Actions Associated with SCADAPack Controllers (Using SCADAPack Modbus Specific Actions)

Actions Associated with SCADAPack Controllers

These actions are specific to SCADAPack controllers:

  • DLOG Scan
  • Resume Polling
  • Suspend Polling.

NOTE: If your system is running a SCADAPack Modbus Extension Driver, refer to the relevant SCADAPack Modbus extension driver guide for any driver-specific actions that are not listed above.


SCADAPack Modbus Driver Guide - DLOG Scan (Using SCADAPack Modbus Specific Actions)

DLOG Scan

Associated with: SCADAPack controllers on which DLOG is enabled

Security permission required to access this pick action: Retrieve Data

Use the DLOG Scan pick action to request the driver to scan a controller and retrieve its DLOG (stored SCADAPack) data records. Use this pick action to perform a DLOG scan that is in addition to the DLOG scanning that is already configured for the controller.

Unlike the automated DLOG scanning process, the action retrieves all of the DLOG data records, as the Max DLOG Requests Per Scan restriction specified for the automated process does not apply.


SCADAPack Modbus Driver Guide - Resume Polling (Using SCADAPack Modbus Specific Actions)

Resume Polling

Associated with: SCADAPack controllers on which Suspend Polling is enabled

Security permission required to access this pick action: Diagnostics

The Remote Connection interface is typically used to suspend or resume polling of a SCADAPack controller. However, if Suspend Polling is enabled, you can use the Resume Polling pick action to abort any current polling suspension and resume normal polling of a controller.

The Resume Polling pick action is only available for controllers on which the ‘Suspend Polling’ feature is enabled (see Specify Whether ClearSCADA can Suspend Polling of a Controller).

Use the Resume Polling pick action to force polling to resume, regardless of whether polling was suspended via the Suspend Polling pick action, or the Remote Connection interface.


SCADAPack Modbus Driver Guide - Suspend Polling (Using SCADAPack Modbus Specific Actions)

Suspend Polling

Associated with: SCADAPack controllers on which Suspend Polling is enabled

Security permission required to access this pick action: Diagnostics

The Remote Connection interface is typically used to suspend or resume polling of a SCADAPack controller. However, if Suspend Polling is enabled, you can use the Suspend Polling pick action to force ClearSCADA to suspend polling of a controller.

The Suspend Polling pick action is only available for controllers on which the ‘Suspend Polling’ feature is enabled (see Specify Whether ClearSCADA can Suspend Polling of a Controller).

NOTE: To update the firmware in a SCADAPack controller, polling has to be suspended long enough to allow the entire firmware load to complete. If the firmware is read via the Remote Connection interface, polling is suspended and resumed automatically. If the firmware is read via a local serial port, polling needs suspending manually, using the Suspend Polling pick action. (If polling is not suspended when reading firmware, alarms will occur).

Select the Suspend Polling pick action to display the Suspend Polling window.

Enter the required time in the Duration field. Specify the time in the OPC Time Format, for example 1M for a one-minute duration. The maximum duration that you can specify is limited to the duration defined on the configuration Form for the controller (see Specify Whether ClearSCADA can Suspend Polling of a Controller).

Select the OK button. Where confirmation of user actions is enabled, a confirmation dialog is displayed before the action is executed:

Select the OK button for ClearSCADA to suspend polling the SCADAPack controller for the specified duration. Once the duration has elapsed, normal polling will resume.

If necessary, you can abort any currently active delay by using the Resume Polling pick action.


SCADAPack Modbus Driver Guide - SCADAPack Modbus Specific Status Display Attributes

SCADAPack Modbus Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for a SCADAPack controller provides information about the present state of that controller.

Use this section if you need information on the status of any SCADAPack Modbus database items on your system.

This section covers those attributes that are SCADAPack Modbus driver-specific and includes:

  • SCADAPack Modbus Controller Status Attributes
  • SCADAPack Modbus Point Status Attributes
  • Alphabetical List of SCADAPack Modbus Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


SCADAPack Modbus Driver Guide - SCADAPack Modbus Controller Status Attributes (SCADAPack Modbus Specific Status Display Attributes)

SCADAPack Modbus Controller Status Attributes

NOTE: If your system includes Generic Modbus controllers that do not have ‘live’ points, also see Generic Modbus Controller and Associated Channel States.

These Status attributes apply to all controllers on the SCADAPack Modbus driver:

  • Source
  • Last Unsolicited.

These Status attributes are specific to SCADAPack controllers:

  • DLOG Errors
  • Polling Suspended
  • Controller Type
  • Version Number
  • Firmware Type
  • Firmware Variant
  • IO Controller Firmware Version.

NOTE: If your system is running a SCADAPack Modbus Extension Driver, refer to the relevant SCADAPack Modbus extension driver guide for any driver-specific status attributes that are not listed above.


SCADAPack Modbus Driver Guide - SCADAPack Modbus Point Status Attributes (SCADAPack Modbus Specific Status Display Attributes)

SCADAPack Modbus Point Status Attributes

This Status attribute applies to points on the SCADAPack Modbus driver:

  • Source.


SCADAPack Modbus Driver Guide - Alphabetical List of SCADAPack Modbus Status Display Attributes (SCADAPack Modbus Specific Status Display Attributes)

Alphabetical List of SCADAPack Modbus Status Display Attributes

This section lists those Status attributes that are specific to items on the SCADAPack Modbus driver.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if an alarm condition occurs.

The attributes are listed in alphabetical order and comprise:

  • Controller Type
  • DLOG Errors
  • Firmware Type
  • Firmware Variant
  • IO Controller Firmware Version
  • Last Unsolicited
  • Polling Suspended
  • Source
  • Version Number.

NOTE: If your system is running a SCADAPack Modbus Extension Driver, refer to the relevant SCADAPack Modbus extension driver guide for any driver-specific status attributes that are not listed above.


SCADAPack Modbus Driver Guide - Controller Type (SCADAPack Modbus Specific Status Display Attributes)

Controller Type

Associated with: SCADAPack controllers

This attribute indicates the type of SCADAPack controller. The attribute is displayed once a controller is or has been in communication with the server.

Example:

SCADAPack Light


SCADAPack Modbus Driver Guide - DLOG Errors (SCADAPack Modbus Specific Status Display Attributes)

DLOG Errors

Associated with: SCADAPack controllers

This attribute indicates whether there are any DLOG errors. For example, if there is no time field in a DLOG record (for further information on Time Stamp fields, see Define Whether Logged Data Records are Scanned).

Possible States: Displays one of the Standard Alarm States.


SCADAPack Modbus Driver Guide - Firmware Type (SCADAPack Modbus Specific Status Display Attributes)

Firmware Type

Associated with: SCADAPack controllers

This attribute indicates the type of firmware that is running on a controller. The attribute is displayed once a controller is or has been in communication with the server.

Example:

TelePACE
(for a controller that is running TelePACE firmware)


SCADAPack Modbus Driver Guide - Firmware Variant (SCADAPack Modbus Specific Status Display Attributes)

Firmware Variant

Associated with: SCADAPack controllers

This attribute indicates the variant of the firmware that is running on a controller. The attribute is displayed once a controller is or has been in communication with the server.

Example:

DNP3 Supported
(for a controller that is running firmware that supports DNP3 functionality)


SCADAPack Modbus Driver Guide - IO Controller Firmware Version (SCADAPack Modbus Specific Status Display Attributes)

IO Controller Firmware Version

Associated with: SCADAPack controllers

This attribute indicates the version of I/O firmware that is running on a controller. The attribute is displayed once a controller is or has been in communication with the server.

Example:

3


SCADAPack Modbus Driver Guide - Last Unsolicited (SCADAPack Modbus Specific Status Display Attributes)

Last Unsolicited

Associated with: Controllers on the SCADAPack Modbus driver

This attribute indicates the time and date that the ClearSCADA server last received an unsolicited message from the controller. The attribute displays ‘Never’ if the controller has never sent an unsolicited message, or does not have the ability to send unsolicited messages.

Example:

27/Jun/2006 10:05:44.000


SCADAPack Modbus Driver Guide - Polling Suspended (SCADAPack Modbus Specific Status Display Attributes)

Polling Suspended

Associated with: SCADAPack controllers

This attribute indicates whether polling of a controller is presently suspended. Polling can be suspended and resumed automatically, using the Remote Connection interface. On controllers on which the ‘Suspend Polling’ feature is enabled, polling can also be suspended and resumed by using the Suspend Polling and Resume Polling pick actions, respectively.

Possible states: True, False


SCADAPack Modbus Driver Guide - Source (SCADAPack Modbus Specific Status Display Attributes)

Source

Associated with: Various items on the SCADAPack Modbus driver

The Source attribute is common to many Status Displays. The attribute indicates the location at which an item resides.

The information shown varies, depending on the type of item.

For SCADAPack and Generic Modbus controllers, information is displayed in this format:

Set <Set Address>:OS <Controller Address>

Example:

Set 2:OS 5
(For a controller with an address of 5, in the set that has an address of 2.)

For SCADAPack Modbus points, information is displayed in this format:

Set <Set Address>:OS <Controller Address>:<Point Type> Address <Point Address>

Example:

Set 2:OS 5:AI Address 30001
(For an Analog Input point located at point address 30001, on the controller that has an address of 5. The controller is in the set that has an address of 2.)

For a Digital Input or Digital Output point, the information is appended by the number of bits.

Example:

Set 2:OS 5:DI Address 10001 Bits 1
(For a 1-bit Digital Input point located at point address 10001, on the controller that has an address of 5. The controller is in the set that has an address of 2.)

The Source attribute displays the type of SCADAPack Modbus point using these abbreviations:
Abbreviation | Type of Point
AI | Analog Input Point
AO | Analog Output Point
DI | Digital Input Point
DO | Digital Output Point


SCADAPack Modbus Driver Guide - Version Number (SCADAPack Modbus Specific Status Display Attributes)

Version Number

Associated with: SCADAPack controllers

This attribute indicates the version number of the firmware that is running on the controller. The attribute is displayed once a controller is or has been in communication with the server.

Example:

2.11
(for a controller that is running firmware version 2.11)


SCADAPack Modbus Driver Guide - System Analysis

System Analysis

This section is for system administrators and high-level engineers who need to use statistical and diagnostic information to assess the state of the ClearSCADA system. This section applies specifically to the SCADAPack Modbus driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

During system analysis, you might need to:

  • Adjust the Configuration of any Points that Cause a High Load
  • Use Driver Logging Options that are Specific to the SCADAPack Modbus Driver.

Additionally, if a controller is not communicating with the server when it should be, see Troubleshooting in the ClearSCADA Guide to Advanced Drivers.

(If your system includes Generic Modbus controllers that do not have ‘live’ points, also see Generic Modbus Controller and Associated Channel States.)

NOTE: When troubleshooting on a ClearSCADA system, check the Events List for diagnostic messages. These may help to identify the cause of any abnormal conditions that ClearSCADA has detected.


SCADAPack Modbus Driver Guide - Adjust the Configuration of any Points that Cause a High Load (System Analysis)

Adjust the Configuration of any Points that Cause a High Load

A possible cause of deficient performance on a ClearSCADA system is that of inadequate client performance (see Diagnose Client Performance Problems in the ClearSCADA Guide to the Server Status Tool). One of the causes of inadequate performance is high load on the server.

You can use the statistics that are shown in Lists and Status displays to identify any SCADAPack or Generic Modbus controllers that are causing a high loading on the ClearSCADA system.

For those controllers that have a high load, use the Points List to identify the point(s) that are causing the high load.

High load is typically caused by a point updating at too frequent a rate.

Where a point on a SCADAPack or Generic Modbus controller is causing a high load:

  1. Check the Retrieval Interval that the point is using (see Configure Common Point Properties). If this is causing the server to update the current point value at too frequent a rate, you might need to:
  • Specify a different Retrieval Interval.

or:

  • Specify a less frequent Normal or Promoted Retrieval rate (see Define the Data Retrieval Intervals).
  2. If the point is on a controller that has a direct connection to the server, check the Scan Group (Confidence Interval) that the point is using (see Configure Common Point Properties). If this is causing the server to update the current point value at too frequent a rate, you might need to:
  • Specify a different Scan Group.

or:

  • Specify a less frequent scan rate for the Scan Group (see Define Intervals for Timed Current Data Updates in the Guide to Advanced Drivers).
  3. If the point is an Analog point, ensure that the Significant Change feature is enabled (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration).
  4. If the point is an Analog point with Significant Change enabled, you might need to increase the Significant Change deadband—the amount by which the point value has to change in order for the value to be updated in the ClearSCADA database (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration).
  5. If fleeting changes in value are causing a high load, you might want to increase the Persistence settings for the point (see Use Persistence to Stop Fleeting Changes in Value from Changing a Point State). However, a sudden increase in momentary changes in state might indicate an abnormal condition elsewhere. If this occurs, check the controller, plant, and instrumentation to see whether an underlying hardware problem is causing the sudden increase.
  6. If none of the above checks and configuration changes have cleared the high load caused by the point, check the following equipment for any faults:
  1. Controller hardware
  2. Plant
  3. Instrumentation.


SCADAPack Modbus Driver Guide - Generic Modbus Controller and Associated Channel States (System Analysis)

Generic Modbus Controller and Associated Channel States

When a Generic Modbus Direct or Shared controller is first added to a ClearSCADA system and you associate that controller with a SCADAPack Modbus Direct Channel, the state of the controller will initially register as ‘Healthy’ and the state of the channel will remain as ‘Disconnected’. This initial Generic Modbus controller state is not a true indication of that controller’s status. It is only once you have added point(s) to the controller and ClearSCADA polls that controller for point data via the channel, that both the controller’s and channel’s states update to indicate their true state. (If ClearSCADA polls the controller successfully, that controller’s state will remain Healthy and the channel’s state will also update to Healthy.)

In situations where a Generic Modbus Direct or Shared controller remains without any associated points in the ClearSCADA database, the state of the controller will remain as ‘Healthy’ although this will not be a true indication of that controller’s status. (Generic Modbus controllers do not universally support a start comms message that ClearSCADA can use to ascertain the correct state of such a controller until it has polled that controller for point data.) Similarly, the SCADAPack Modbus Direct Channel that is associated with such a controller will continue to show a ‘Disconnected’ state until ClearSCADA polls that channel for point data (on either that controller or any other controller that uses that channel).

This situation only affects Generic Modbus controllers—with SCADAPack controllers, the controller supports a start comms message that enables ClearSCADA to ascertain the correct state of the controller, once that controller goes online.

Further Information

Ascertain the State of a Controller or Channel: see Monitoring the State of Direct Communications on your System in the ClearSCADA Guide to Advanced Drivers.


SCADAPack Modbus Driver Guide - Driver Logging Options that are Specific to the SCADAPack Modbus Driver (System Analysis)

Driver Logging Options that are Specific to the SCADAPack Modbus Driver

Driver Logging can be used to help diagnose abnormal conditions relating to driver activity. Driver logging can also be used for assessing potential problems. The log files that are produced provide useful diagnostic information about specific aspects of the system. For instance, the Points logging option provides diagnostic information about the points on a particular driver.

This section explains the driver logging options that are specific to the SCADAPack Modbus driver.

Those driver logging options that are typically required for investigating abnormal conditions are enabled by default. We suggest that the logging options are left at this default unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

Should you need to contact Schneider Electric for assistance with resolving a problem that ClearSCADA has detected, you might be asked to provide Log files to help in assessing the cause of the problem. For information on Log files and defining the Log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

For information on the driver log options that are available for many advanced drivers, see Common Advanced Driver Log File Options in the ClearSCADA Guide to Advanced Drivers.

These driver logging options are specific to the SCADAPack Modbus driver:

  • Remote Connection—Logs information relating to the state of the connection to a remote application. (A remote connection enables applications such as TelePACE to interrogate SCADAPack or Generic Modbus controllers remotely, via ClearSCADA—see Configuring a SCADAPack Modbus Remote Connection.)
  • Eavesdrop—Logs information relating to the state of any eavesdropping communications (see SCADAPack Modbus Eavesdropping Arrangement).


SCADAPack Modbus RealFLO Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SCADAPack Modbus RealFLO Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


SCADAPack Modbus RealFLO Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


SCADAPack Modbus RealFLO Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


SCADAPack Modbus RealFLO Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SCADAPack Modbus RealFLO Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration, features and database items that are specific to ClearSCADA’s SCADAPack Modbus RealFLO driver. The driver is a SCADAPack Modbus extension driver. The driver provides additional functionality to enable ClearSCADA to interface with RealFLO components on RealFLO-enabled SCADAPack controllers. The driver enables ClearSCADA to communicate with the controllers using the Modbus protocol with proprietary extensions. Using the driver, ClearSCADA can interface with RealFLO to monitor and process gas flow data.

For more details on the information included in this guide, see Introduction to the SCADAPack Modbus RealFLO Driver.


SCADAPack Modbus RealFLO Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is primarily intended for engineers who are responsible for configuring ClearSCADA to interface with RealFLO.

The guide also contains information for:

  • Operators and engineers who use the SCADAPack Modbus RealFLO driver to control plant and monitor and process gas flow data
  • Maintenance engineers.


SCADAPack Modbus RealFLO Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


SCADAPack Modbus RealFLO Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to the SCADAPack Modbus Driver

ClearSCADA Guide to Drivers

ClearSCADA Guide to Advanced Drivers

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Database

ClearSCADA Guide to Alarms

ClearSCADA Guide to Lists

ClearSCADA Guide to Logic

ClearSCADA Guide to Trends

ClearSCADA Guide to Mimics

ClearSCADA Guide to the CFX Export Driver

ClearSCADA Guide to the Crystal Reports Driver

ClearSCADA Guide to ViewX and WebX Clients

RealFLO 6 Reference and User Manual (CMI, Sept 2009).


SCADAPack Modbus RealFLO Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


SCADAPack Modbus RealFLO Driver Guide - Introduction to the SCADAPack Modbus RealFLO Driver

Introduction to the SCADAPack Modbus RealFLO Driver

The SCADAPack Modbus RealFLO driver is a SCADAPack Modbus extension driver. It provides additional functionality to enable ClearSCADA to interface with SCADAPack controllers that are running RealFLO™. The RealFLO feature converts a SCADAPack controller into an electronic natural gas Flow Computer. ClearSCADA can interface with RealFLO, in order to monitor and process the gas flow data that is being retrieved by the Gas Flow Computer. ClearSCADA can access the Flow Computer’s data, configuration and calculation factors by interrogating the RealFLO components on the SCADAPack controllers. When ClearSCADA is to interact with a controller’s RealFLO components, the SCADAPack controller is referred to as a RealFLO controller throughout the ClearSCADA documentation, to indicate that additional interaction.

In order to communicate with RealFLO controllers, your ClearSCADA system needs to be running both the SCADAPack Modbus driver and the SCADAPack Modbus RealFLO extension driver (see Confirm that the RealFLO Server Component is Installed).

If required, ClearSCADA can export retrieved gas flow measurement data in Common File Exchange (CFX) format. The CFX file format is proprietary and confidential to Flow-Cal, Inc. The exported data can then be imported into any of Flow-Cal’s measurement data management applications. To export data in this format, ClearSCADA also needs to be running the CFX driver. For information on that driver, see the ClearSCADA Guide to the CFX Export Driver.

Use this ClearSCADA Guide to the SCADAPack Modbus RealFLO Driver alongside the ClearSCADA Guide to the SCADAPack Modbus Driver. As much of the information in the latter guide is assumed knowledge, we recommend that you read the ClearSCADA Guide to the SCADAPack Modbus Driver before reading this driver guide.

The SCADAPack Modbus RealFLO driver documentation:

  • Summarizes the Terminology of which you need to be aware
  • Explains how to:
  • Confirm that the RealFLO Server Component is Installed
  • Configure SCADAPack Modbus RealFLO specific features and items within the ClearSCADA database (see Configure ClearSCADA to Monitor RealFLO Gas Calculation Data, and see Scanning RealFLO Points on SCADAPack Modbus Controllers).

It also explains features that are of interest to operators, such as:

  • RealFLO Specific Alarm and Event Categories
  • Using RealFLO Specific Actions

and driver-specific aspects that are of interest to system administrators and engineers when investigating unexpected behavior relating to the SCADAPack Modbus RealFLO driver. For information, see:

  • RealFLO Specific Status Display Attributes.

For further information on RealFLO, or on gas flow data that is not covered by this guide, please refer to the documentation provided with the RealFLO application.

RealFLO Flow Computer functionality is licensed by Control Microsystems Inc. For more information, see the Control Microsystem’s web site (www.controlmicrosystems.com).


SCADAPack Modbus RealFLO Driver Guide - Terminology (Introduction to the SCADAPack Modbus RealFLO Driver)

Terminology

Throughout most of the advanced driver documentation, the term ‘outstation’ is used to refer to any device such as a data logger, programmable logic controller (PLC), outstation, or RTU that is used to obtain data from measuring instruments or sensors.

Throughout the ClearSCADA SCADAPack Modbus documentation, the term ‘RealFLO controller’ is used to refer to a SCADAPack-series controller that is running RealFLO, and with which ClearSCADA communicates in order to retrieve gas flow calculation data. (If ClearSCADA is not to retrieve gas flow calculation data from a SCADAPack controller, you configure a SCADAPack controller, rather than a RealFLO controller, in the ClearSCADA database.)


SCADAPack Modbus RealFLO Driver Guide - Confirm that the RealFLO Server Component is Installed (Introduction to the SCADAPack Modbus RealFLO Driver)

Confirm that the RealFLO Server Component is Installed

The RealFLO extension driver provides the SCADAPack Modbus driver with extra functionality, enabling ClearSCADA to monitor gas calculation data on RealFLO-enabled SCADAPack devices. In order to monitor such data, the RealFLO component has to be installed on each of the servers on your system (including any permanent standby servers), in addition to the SCADAPack Modbus component (for information on installing the latter component, see Confirm that the SCADAPack Modbus Server Component is Installed in the ClearSCADA Guide to the SCADAPack Modbus Driver).

Use the Add/Remove Programs function in the Windows® Control Panel to check whether the required components are installed.

The RealFLO component is located in the Server group, in a branch off from its SCADAPack Modbus ‘parent’ driver component. To check that this component has been installed, ensure that the symbol to the left of the text RealFLO does not have an X on it.

The RealFLO extension driver is licensed separately to the SCADAPack Modbus driver.


SCADAPack Modbus RealFLO Driver Guide - Configure ClearSCADA to Monitor RealFLO Gas Calculation Data (Introduction to the SCADAPack Modbus RealFLO Driver)

Configure ClearSCADA to Monitor RealFLO Gas Calculation Data

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the plant, measuring instruments, and control devices on your system. This section summarizes the database items that you need to configure to represent the SCADAPack Modbus RealFLO devices on your system.

In order to represent any SCADAPack Modbus RealFLO devices, both the SCADAPack Modbus Driver and the RealFLO extension component have to be installed and running on the ClearSCADA servers on your system (see Confirm that the RealFLO Server Component is Installed). When the driver is first installed, a system administrator needs to define the server settings for the driver (see Configuring SCADAPack Modbus Server Settings in the ClearSCADA Guide to the SCADAPack Modbus Driver, and see Configuring RealFLO Server Settings in this guide).

When you configure SCADAPack Modbus RealFLO items in the ClearSCADA database, many of the settings for those items need to correspond to the settings of the relevant SCADAPack Modbus RealFLO devices on your system. Some settings are either fixed (incorporated into the design of the RealFLO-enabled SCADAPack controller), or are configured by an engineer. You need to have access to, or an understanding of, the settings of the SCADAPack Modbus RealFLO devices on your system before you can configure the SCADAPack Modbus RealFLO database items successfully. For instance, you need to specify the user ID and passcode needed to access the RealFLO components on each RealFLO-enabled SCADAPack controller on your system.

You also need to be aware of which optional features are required for each SCADAPack Modbus RealFLO item. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with SCADAPack Modbus RealFLO database items, including Lists, Actions, and Mimics. For actions that are specific to the SCADAPack Modbus driver, see Using SCADAPack Modbus Specific Actions in the ClearSCADA Guide to the SCADAPack Modbus Driver, and see Using RealFLO Specific Actions in this guide. For further information on actions and for details on Lists and Mimics, see the core documentation.

In order for ClearSCADA to monitor glow flow data via SCADAPack devices that are running RealFLO, you need to configure:

  1. A SCADAPack Modbus Channel to represent each communication connection between a SCADAPack RealFLO controller and the ClearSCADA server (see Configuring a SCADAPack Modbus Channel in the ClearSCADA Guide to the SCADAPack Modbus Driver).

With a Direct channel, use the fields within the Scan Groups section of the Scan Parameters tab to specify the frequency with which current data is updated in ClearSCADA (see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers). For points other than RealFLO Analog Input points, the Scan Group interval should be a multiple of the points’ Retrieval Interval rate (see Configure Common Point Properties in the ClearSCADA Guide to the SCADAPack Modbus Driver). For RealFLO Analog Input points, the Scan Group interval should be a multiple of the relevant Flow Run’s Current Scan interval (see Configure the Scanning Properties).

  2. A SCADAPack Modbus Set to define each group of SCADAPack RealFLO controllers (see Configuring a SCADAPack Modbus Set in the ClearSCADA Guide to the SCADAPack Modbus Driver).

ATTENTION: Any sets that contain RealFLO controllers should have their Broadcast Set Clock feature disabled. (The RealFLO method of setting a clock results in a RealFLO controller restarting its current Hour log.)

  3. A RealFLO Controller to define each SCADAPack controller that is running RealFLO, and is calculating gas volume and compressibility data (see Configuring SCADAPack Modbus RealFLO Controllers).
  4. A Flow Run for each set of flow run calculation parameters that ClearSCADA is to monitor from a Flow Computer (see Configuring a SCADAPack Modbus Flow Run).

Depending on your system hardware, you can attach between 1 and 10 Flow Runs to each RealFLO Controller.

NOTE: You can fully configure each Flow Run directly in ClearSCADA, or you can read the majority of a Flow Run’s configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration). If you choose the latter option, each Flow Run needs to have been configured using a PC that is running the RealFLO application, before the ClearSCADA server can successfully read the Flow Run configuration into the ClearSCADA database.

  5. A RealFLO Analog Input Point for each item of Flow Run data that is to be further processed in ClearSCADA (see Configuring RealFLO Analog Input Points, and see Scanning RealFLO Points on SCADAPack Modbus Controllers).

(To view certain Flow Run values in ClearSCADA, you can attach and display those values in a Mimic, or in a Data Grid. You only need to configure a RealFLO Analog Input point if you want to view data that is not directly available from the Flow Run database item, or to further process an item of Flow Run data in ClearSCADA (for example, to raise alarms, or to store data historically in ClearSCADA). For more information, see View and Process Flow Run Data.)

  6. If required, SCADAPack Modbus Analog and Digital Points to represent any other analog and digital measuring instruments and control devices that are connected to a RealFLO-enabled SCADAPack controller (see Points Used on SCADAPack Modbus Controllers in the ClearSCADA Guide to the SCADAPack Modbus Driver). You can use these points to optionally represent any controller functions that run independently to the RealFLO components.

If you want other applications to communicate remotely with SCADAPack Modbus RealFLO devices via ClearSCADA, you also need to configure a Remote Connection (see Configuring a SCADAPack Modbus Remote Connection in the ClearSCADA Guide to the SCADAPack Modbus Driver).

To minimize the time that it takes to configure the required SCADAPack Modbus RealFLO items, you may want to configure them in the order listed above, as set configuration requires you to specify a channel, and controller (outstation) configuration requires you to specify a set, and so on.

NOTE: RealFLO-enabled SCADAPack controllers only support writing of Flow Run configuration from the ClearSCADA server. However, you may be able to write other configuration remotely, via applications such as TelePACE®. Refer to the documentation supplied with the application for information.


SCADAPack Modbus RealFLO Driver Guide - Configuring RealFLO Server Settings

Configuring RealFLO Server Settings

Some driver-specific settings need configuring on the server by a system administrator when a ClearSCADA system is first installed. If any SCADAPack controllers on your system are running RealFLO, in addition to defining the settings on the ClearSCADA Server Configuration Tool’s SCADAPack Modbus section, a system administrator will also need to define the settings on the tool’s RealFLO section. This section explains how to configure the RealFLO settings. For information on configuring the SCADAPack Modbus settings, see Configuring SCADAPack Modbus Server Settings in the ClearSCADA Guide to the SCADAPack Modbus Driver.

When the RealFLO extension driver is first installed on a ClearSCADA system, a system administrator has to:

  1. Define the Minimum Drift before ClearSCADA Sets the RealFLO Clock.
  2. Define the Flow Computer Command Timeout.
  3. Specify Whether ClearSCADA is to Check that each Flow Computer ID is Unique.
  4. Apply the changes to the server (see Configuring Advanced Driver Server Settings in the ClearSCADA Guide to Advanced Drivers).
  5. If:
  • changes have been made during steps 1 or 2

and:

  • the server is currently running as the main server

restart the SCADAPack Modbus driver for the changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).

  6. Repeat the above steps for each server on the system (other than any permanent standby servers).


SCADAPack Modbus RealFLO Driver Guide - Define the Minimum Drift before ClearSCADA Sets the RealFLO Clock (Configuring RealFLO Server Settings)

Define the Minimum Drift before ClearSCADA Sets the RealFLO Clock

Use the Minimum clock drift before RealFLO clock is set field on the RealFLO section to specify the minimum amount of time by which a RealFLO controller’s clock has to drift before ClearSCADA is to set the clock’s time. Specify a suitable time, in seconds, so that ClearSCADA does not reset the clock on RealFLO controllers excessively. (When a controller’s clock is set using the RealFLO method, the controller logs an event and restarts the current Hour log. Excessive setting of the clock would cause the controller to generate numerous such events and to send those events to ClearSCADA.)


SCADAPack Modbus RealFLO Driver Guide - Define the Flow Computer Command Timeout (Configuring RealFLO Server Settings)

Define the Flow Computer Command Timeout

Use the Flow Computer Command Timeout field on the RealFLO section to define the timeout period for RealFLO commands.

The timer is triggered whenever a RealFLO command is issued using a register write.

The timer is canceled as soon as the reply registers update to indicate the completion of the command.

If the reply registers have not updated as expected by the time that the timer expires, the driver will wait for any outstanding replies to be received. Then if the reply registers have still not changed the driver will fail the request, indicating the fact that the RealFLO command registers did not update as the reason.


SCADAPack Modbus RealFLO Driver Guide - Specify Whether ClearSCADA is to Check that each Flow Computer ID is Unique (Configuring RealFLO Server Settings)

Specify Whether ClearSCADA is to Check that each Flow Computer ID is Unique

Use the Validate flow computer ID is unique across the system check box on the RealFLO section to specify whether the server is to check that the Flow Computer ID on each RealFLO controller is unique across the system.

Select the check box for ClearSCADA to verify whether each Flow Computer ID is unique. When ClearSCADA first communicates with a Flow Computer, it reads the data from that Flow Computer and stores it in the ClearSCADA database. Once stored, ClearSCADA re-validates the data to verify that the Flow Computer ID is unique. If the ID is not unique, the configuration of the RealFLO controllers that have the same Flow Computer ID becomes invalid. As with any invalid configuration, this is indicated in the Database Bar by the controllers’ icons each displaying a red cross. Similarly, should you display such a controller’s configuration Form, it will contain an invalid configuration message in the message area at the bottom of the Form (see Mandatory Configuration and Invalid Configuration Messages in the ClearSCADA Guide to Core Configuration).

Clear the Validate flow computer ID is unique across the system check box if ClearSCADA is not to determine whether each Flow Computer’s ID is unique across the system.

For more information on Flow Computer IDs, see View the Flow Computer Details.


SCADAPack Modbus RealFLO Driver Guide - Scanning RealFLO Points on SCADAPack Modbus Controllers

Scanning RealFLO Points on SCADAPack Modbus Controllers

Use this section in conjunction with the scanning section in the SCADAPack Modbus driver guide (see Scanning Direct Controllers on the SCADAPack Modbus Driver in the ClearSCADA Guide to the SCADAPack Modbus Driver).

You configure different types of point in ClearSCADA, depending on the type of data that you want the SCADAPack Modbus driver to retrieve. To monitor RealFLO Gas Calculation data on a Flow Run in a RealFLO controller (a SCADAPack controller that is running RealFLO), you configure RealFLO Analog Input points. (To monitor any other data on a RealFLO controller, you configure suitable ‘standard’ analog or digital points (see Points Used on SCADAPack Modbus RealFLO Controllers).)

The way in which ClearSCADA retrieves data from the points on each controller varies, depending whether those points are ‘standard’ points (see Standard Points in the ClearSCADA Guide to the SCADAPack Modbus Driver) or RealFLO Points (see below).

To monitor RealFLO Gas Calculation data on a Flow Run in a RealFLO controller, in the ClearSCADA database you attach RealFLO Analog Input point(s) to a Flow Run, then attach that Flow Run to a RealFLO Outstation (see Configure ClearSCADA to Monitor RealFLO Gas Calculation Data).

Unlike ‘standard’ points on the SCADAPack Modbus driver, RealFLO Analog Input points are not scanned independently of each other. Instead, the RealFLO Analog Input points on a particular Flow Run are scanned in one block—at the rate defined by that Flow Run’s scanning intervals (see Configure the Scanning Properties). The fields within the Scanning section of the Flow Run Form specify both the frequency with which ClearSCADA retrieves Flow Run data and how often ClearSCADA scans the controller for RealFLO Analog Point data. (Should you choose to configure a Flow Run on a PC that is running the RealFLO application, you also use the fields to determine the frequency with which ClearSCADA updates its copy of that configuration.)

Depending on the type of data that each RealFLO point monitors, ClearSCADA retrieves the point’s data at the Flow Run’s Current Scan, Hourly History Scan, or Daily History Scan interval (see Specify the Item of Flow Run Data that a RealFLO Analog Represents).

Additionally, you can assign a Scan Group to each RealFLO point that is used to retrieve current data, to provide confidence that the point’s data is still up-to-date, even if the Flow Run data has not changed for some time (see Configure Common Point Properties in the ClearSCADA Guide to the SCADAPack Modbus Driver). On a RealFLO Analog Input point, the Scan Group interval should typically be a multiple of the relevant Flow Run’s Current Scan interval. (If the selected Scan Group’s interval is faster than the Current Scan interval, the point will only update at the Current Scan interval—the driver will not schedule extra polls if the Scan Group’s rate is faster.)

Use the Logged Data section of the Point Form to specify whether ClearSCADA is to retrieve DLOG (logged) data for a RealFLO point, in addition to current data (see Log Point Data on SCADAPack Controllers in the ClearSCADA Guide to the SCADAPack Modbus Driver). Use the Scan Rate field, within the DLOG section of the RealFLO Controller’s Outstation Form, to specify the frequency with which the driver retrieves any logged data (see Define Whether Logged Data Records are Scanned in the ClearSCADA Guide to the SCADAPack Modbus Driver).


SCADAPack Modbus RealFLO Driver Guide - Configuring SCADAPack Modbus RealFLO Controllers

Configuring SCADAPack Modbus RealFLO Controllers

ClearSCADA has the ability to monitor gas flow calculation data from a RealFLO-enabled SCADAPack controller (a SCADAPack controller that is a gas flow computer). For each SCADAPack controller that is running RealFLO and for which you want ClearSCADA to process gas flow data, you need to add and configure a suitable SCADAPack Modbus RealFLO controller in the ClearSCADA database.

The SCADAPack Modbus RealFLO driver supports these types of RealFLO controller (outstation):

  • SCADAPack Modbus RealFLO Direct Outstation—to represent a RealFLO-enabled SCADAPack controller that is directly connected to the ClearSCADA server.

Depending on the system setup, a Direct controller can belong to a Direct or Switched Outstation Set.

  • SCADAPack Modbus RealFLO PSTN Outstation—to represent a RealFLO-enabled SCADAPack controller that can communicate with the server using a dial-up modem.
  • SCADAPack Modbus RealFLO Shared Outstation—to represent a RealFLO-enabled SCADAPack controller that is directly connected to the ClearSCADA server, and that can communicate with the server using either of two channels. Each controller in a Shared Set can communicate via either channel.

If your database structure is ‘modular’ and Group Templates are used to store ‘model’ SCADAPack Modbus RealFLO configuration, in addition to the above types of controller, you can add this driver-specific ‘abstract’ controller item to your Group Templates:

  • SCADAPack Modbus RealFLO Abstract Outstation—Converts to any of the SCADAPack Modbus RealFLO Outstation items listed above.

You can only add Abstract Items to Group Template s. The abstract items appear as additional driver-specific entries when you display the context sensitive menu from a Group Template. As with other abstract items, in order to represent a ‘real’ controller, you need to convert the abstract items into the required type of controller (outstation) within the Group Instances that reference the Group Template. For more information, see Add an Abstract Item to a Group Template in the ClearSCADA Guide to Core Configuration.

You specify each controller’s properties using the fields on the appropriate RealFLO Outstation Form.

Each RealFLO Outstation Form has several tabs.

Use the SCADAPack tab to:

  • Define the Set Clock Method
  • Configure various SCADAPack-specific controller features (see Configuring a SCADAPack Controller in the ClearSCADA Guide to the SCADAPack Modbus Driver).

Use the RealFLO tab to enable ClearSCADA to access the RealFLO components on a SCADAPack controller. The tab provides fields for you to:

  • View the Flow Computer Details
  • Specify the User ID and Passcode that Allow Access to the RealFLO Components.

For information on the other tabs, see Configuring Controllers on the SCADAPack Modbus Driver in the ClearSCADA Guide to the SCADAPack Modbus Driver.

For information on the minimal amount of configuration that you can undertake to produce a functional RealFLO-enabled SCADAPack controller in ClearSCADA, see Minimum Configuration.

Once you have configured a RealFLO controller in ClearSCADA, you need to create and configure the necessary Flow Run(s), and associate those Flow Run(s) with the RealFLO controller (see Configuring a SCADAPack Modbus Flow Run).


SCADAPack Modbus RealFLO Driver Guide - Minimum Configuration (Configuring SCADAPack Modbus RealFLO Controllers)

Minimum Configuration

If ClearSCADA is to monitor gas flow data, in addition to the Minimum Configuration required to produce a functional (online) SCADAPack controller, you need to specify:

  • The RealFLO User ID that is required to access the RealFLO components of the controller (RealFLO tab)
  • The corresponding RealFLO Passcode (RealFLO tab).

Also ensure that the controller is In Service and save the configuration. This will result in a functional RealFLO controller that uses the default configuration settings.


SCADAPack Modbus RealFLO Driver Guide - Define the Set Clock Method (Configuring SCADAPack Modbus RealFLO Controllers)

Define the Set Clock Method

Use the Set Clock Method field on the SCADAPack tab to define whether a controller’s clock is synchronized from ClearSCADA or another source:

With a RealFLO-enabled SCADAPack controller, the options are:

  • None—The controller’s clock is synchronized via a source other than ClearSCADA.
  • RealFLO—ClearSCADA synchronizes a RealFLO controller’s clock using a RealFLO protocol command.

ATTENTION: Ensure that any SCADAPack Modbus Outstation Sets that contain RealFLO controllers have their Broadcast Set Clock feature disabled. (The RealFLO method of setting a clock results in a RealFLO controller restarting its current Hour log.)


SCADAPack Modbus RealFLO Driver Guide - View the Flow Computer Details (Configuring SCADAPack Modbus RealFLO Controllers)

View the Flow Computer Details

These fields are displayed at the top of the RealFLO tab:

  • Flow Computer ID—A string that uniquely identifies the Gas Flow Computer’s components on a RealFLO-enabled SCADAPack controller. The ID comprises any combination of up to eight characters.

In order for the ClearSCADA server to read the ID into the ClearSCADA database and communicate successfully with the controller’s RealFLO components, you need to Specify the User ID and Passcode that Allow Access to the RealFLO Components.

The Flow Computer ID is then read into ClearSCADA when the server successfully establishes communications with the controller.

NOTE: The Event Table and User Table fields on the tab are ‘grayed out’ and unavailable for use. These fields are reserved for future use.


SCADAPack Modbus RealFLO Driver Guide - Specify the User ID and Passcode that Allow Access to the RealFLO Components (Configuring SCADAPack Modbus RealFLO Controllers)

Specify the User ID and Passcode that Allow Access to the RealFLO Components

In order for ClearSCADA to access the RealFLO components on a RealFLO-enabled SCADAPack controller, you need to specify the following:

  • User ID—Specify a valid user ID that enables access to the RealFLO components. Enter an ID of up to eight alphanumeric characters.
  • Passcode—Specify the passcode that is used in conjunction with the above User ID. The range is 0 to 65535.


SCADAPack Modbus RealFLO Driver Guide - Configuring a SCADAPack Modbus Flow Run

Configuring a SCADAPack Modbus Flow Run

NOTE: You only need to create and configure a SCADAPack Modbus Flow Run if ClearSCADA is to monitor gas flow calculation data on a SCADAPack controller (see Configure ClearSCADA to Monitor RealFLO Gas Calculation Data).

A Flow Run is a two-calculation run that calculates both the volume and compressibility of the gas that flows through an individual gas meter. The driver can read a Flow Run’s calculation parameters into ClearSCADA, from a SCADAPack controller that is running RealFLO, or you can fully configure a Flow Run directly in the ClearSCADA database and then write that configuration to the SCADAPack controller (see Configure or Read the Flow Run Configuration). You can then use ClearSCADA to monitor and process the flow run’s data remotely.

You need to add one Flow Run item to the ClearSCADA database for each separate flow run that ClearSCADA is to monitor. Each Gas Flow Computer can support between 1 and 10 flow runs—the number of actual flow runs that a controller can use is limited by RealFLO license and the type of hardware that is being used to run the Flow Computer. For example, the hardware for a controller might support a maximum of 10 Flow Runs, but the license might support only four Flow Runs. (When RealFLO is enabled on SCADAPack controller, the controller converts into a fully functioning gas flow computer.)

You configure the properties of each Flow Run in ClearSCADA, using the SCADAPack Modbus Flow Run Form. The amount of configuration varies, depending whether you are configuring a Flow Run fully in ClearSCADA, or reading most of the configuration from a RealFLO controller (see Preparation and Minimum Configuration).

To enable operators to view a Flow Run’s values, you can attach and display those values in a Mimic. To process an item of Flow Run data independently in ClearSCADA, you can add and configure a SCADAPack Modbus RealFLO Analog Input point. For more information, see View and Process Flow Run Data.

The SCADAPack Modbus Flow Run Form has several tabs.

Use the Flow Run tab to:

  • Configure the Flow Run Properties and either configure, or display the read, Input, Static Pressure, Temperature, and Contract properties.

Use the Compressibility Calculation tab to:

  • Specify or ascertain the type of compressibility calculation that the Flow Run performs and configure, or display the read, calculation data (see Compressibility Calculation Properties).

Use the Flow Calculation tab to:

  • Specify or ascertain the type of flow calculation that the Flow Run performs and configure, or display the read, calculation data (see Flow Calculation Properties).

For information on the fields on other tabs, see Tabs that are Common to Many Configuration Forms in the ClearSCADA Guide to Advanced Drivers. For flow run information that is not covered by this guide, refer to the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Configure or Read the Flow Run Configuration (Configuring a SCADAPack Modbus Flow Run)

Configure or Read the Flow Run Configuration

There are two ways to configure a gas Flow Run on a ClearSCADA system.

You can configure a Flow Run directly in ClearSCADA. ClearSCADA’s SCADAPack Modbus Flow Run Form contains the fields that you need to use in order to fully configure a Flow Run in the ClearSCADA database. Once the configuration is complete, get the driver to write that configuration to the Gas Flow Computer (the SCADAPack controller that is running RealFLO), in order to produce a fully functioning Flow Run. Use the Write Configuration pick action to write the Flow Run’s configuration to the Gas Flow Computer.

Alternatively, you can configure a Flow Run using a PC that is running a supported version of the RealFLO application. The driver can then read the Flow Run configuration into the ClearSCADA database, using the Read Configuration pick action. If you choose to read the configuration in this way, use the properties within the Scanning section of the Flow Run Form’s Flow Run tab (see Configure the Scanning Properties) to define the frequency at which that configuration is updated in the ClearSCADA database. If the Flow Run is in an Instance of a Group Template, also ensure that the appropriate Property Overrides are enabled to allow the configuration to be read successfully (for more information, see Read Configuration). A read might occur while a Flow Run’s configuration Form is open. Should this happen and an attempt be made to save any user-instigated configuration changes to that Flow Run after the read is complete, a diagnostic message will be displayed. The message will indicate that the Flow Run’s configuration has changed on the server since the Form was opened. Options are provided to discard the user-instigated changes or overwrite the server’s Flow Run configuration with those changes.


SCADAPack Modbus RealFLO Driver Guide - Preparation and Minimum Configuration (Configuring a SCADAPack Modbus Flow Run)

Preparation and Minimum Configuration

The preparation and minimum configuration that you need to undertake in order to produce a functional Flow Run varies, depending whether it is:

  • For a Flow Run that is Configured Directly in ClearSCADA
  • For a Flow Run that is Configured using the RealFLO Application.


SCADAPack Modbus RealFLO Driver Guide - For a Flow Run that is Configured Directly in ClearSCADA (Configuring a SCADAPack Modbus Flow Run)

For a Flow Run that is Configured Directly in ClearSCADA

Before you can successfully configure a Flow Run directly in ClearSCADA:

  • You need to have configured the RealFLO controller with which the Flow Run is associated (see Configuring SCADAPack Modbus RealFLO Controllers).
  • You also need to ascertain the flow run’s settings.

As a minimum, for a Flow Run to be functional (online), you need to configure:

  • The properties on the Flow Run tab
  • The properties on the Compressibility Calculation tab
  • The properties on the Flow Calculation tab.

You then need to put the Flow Run In Service and save the configuration.

In order to produce a fully functional Flow Run, you will also need to use the Write Configuration pick action to write the configuration to the RealFLO controller on which the Flow Run is located.


SCADAPack Modbus RealFLO Driver Guide - For a Flow Run that is Configured using the RealFLO Application (Configuring a SCADAPack Modbus Flow Run)

For a Flow Run that is Configured using the RealFLO Application

If the majority of a Flow Run’s configuration is being undertaken using the RealFLO application and then being read into the ClearSCADA database, before you can successfully configure a Flow Run in ClearSCADA:

  • You need to ensure that each Flow Run has been fully configured in the Gas Flow Computer, using a PC that is running the RealFLO application. (After the corresponding Flow Run items have been created and enabled in the ClearSCADA database, the ClearSCADA server reads the Flow Run’s configuration from the Gas Flow Computer.)
  • In the ClearSCADA database, you need to have configured the RealFLO controller with which the Flow Run is associated (see Configuring SCADAPack Modbus RealFLO Controllers).
  • You also need to ascertain:
  • How many flow runs ClearSCADA is to monitor on a controller
  • The numbers of those flow run(s).
  • If the Flow Run is in an Instance of a Group Template, ensure that the appropriate Property Overrides are enabled to allow the configuration to be read successfully (for more information, see Read Configuration).

As a minimum, for a Flow Run to be functional (online), you need to configure the Flow Run’s number and specify the name of the outstation (controller) with which the Flow Run is associated.

You then need to put the Flow Run In Service and save the configuration.

Use the Read Configuration pick action to read the rest of the Flow Run’s configuration from the controller into the ClearSCADA database.

CAUTION

unexpected behavior of application

Use the Read Configuration action with care. The action will overwrite the configuration on a Flow Run’s Flow Run, Compressibility Calculation, and Flow Calculation tabs, other than the Basic Flow Run properties and the Scanning properties (both configured on the Flow Run tab).

Failure to follow these instructions can result in unexpected configuration changes.

Should a read occur while a Flow Run’s configuration Form is open and an attempt be made to save any user-instigated configuration changes to that Flow Run after the read is complete, a diagnostic message will be displayed. The message will indicate that the Flow Run’s configuration has changed on the server since the Form was opened. Options are provided to discard the user-instigated changes or overwrite the server’s Flow Run configuration with those changes.


SCADAPack Modbus RealFLO Driver Guide - View and Process Flow Run Data (Configuring a SCADAPack Modbus Flow Run)

View and Process Flow Run Data

Once you have configured a Flow Run in the database, you may want to use other ClearSCADA features to further process the Flow Run data, or to enable operators to view that data. This section provides a summary of some of the features you may want to consider.

To enable operators to view a Flow Run’s values, you can attach and display those values in a Mimic, on a Trend, or in Data Grid. For a list of the configuration and data field values that you can display for a Flow Run, see the SCADAPack Modbus Flow Run entry in the Database Schema.

To process an item of Flow Run data independently in ClearSCADA, or to view an item of Flow Run data that is not directly available from the Flow Run database item, you can add and configure a SCADAPack Modbus RealFLO Analog Input point (see Configuring RealFLO Analog Input Points). You can then further process the data using a Data Grid, by displaying the data on a Mimic or Trend, or by using the values in a Logic program.

For example, to process a Flow Run’s current Static Pressure value in ClearSCADA, you can configure a RealFLO Analog Input point to have an ‘Input’ Source and monitor the appropriate ‘Static Pressure’ Item (see Flow Run Input Data).

For a list of the configuration and data field values that you can display for a RealFLO Analog point, see the SCADAPack Modbus RealFLO Analog Input Point entry in the Database Schema.

If your system is licensed to run the CFX driver, the retrieved gas flow measurement data can be exported to a suitable third-party flow calculation application for analysis. The CFX driver exports flow run data in Flow-Cal’s Common File Exchange (CFX) format. For more information, see the ClearSCADA Guide to the CFX Export Driver.

You can also use ClearSCADA in conjunction with Crystal ReportsTM to produce a record of a Flow Run’s data at a particular instant, either in electronic or hard copy format.

Further Information

Using the Database Schema: see Working with the Database Schema in the ClearSCADA Guide to the Database.

Working with Data Grids: see Configuring Data Grids in the ClearSCADA Guide to Core Configuration.

Configuring Logic Programs: see the ClearSCADA Guide to Logic.

Configuring Mimics: see the ClearSCADA Guide to Mimics.

Configuring Reports: see the ClearSCADA Guide to the Crystal Reports Driver.

Configuring Trends: see the ClearSCADA Guide to Trends.

RealFLO Specific Alarm and Event Categories.

Actions Associated with SCADAPack Modbus Flow Runs.


SCADAPack Modbus RealFLO Driver Guide - Configure the Flow Run Properties (Configuring a SCADAPack Modbus Flow Run)

Configure the Flow Run Properties

Use the fields on the Flow Run tab of the Flow Run Form to:

  • Configure the Basic Flow Run Properties
  • Configure the Scanning Properties

With the properties listed below, you can either Configure or Read the Flow Run Configuration.

  • Input Properties
  • Static Pressure Properties
  • Temperature Properties
  • Contract Properties.


SCADAPack Modbus RealFLO Driver Guide - Configure the Basic Flow Run Properties (Configuring a SCADAPack Modbus Flow Run)

Configure the Basic Flow Run Properties

Use the fields at the top of the Flow Run tab on the Flow Run Form to specify these properties:

  • In Service—Use this check box to specify whether the Flow Run is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Outstation—Use to specify the controller with which the Flow Run is associated. This is the RealFLO controller that is running the RealFLO interface to the Gas Flow Computer.

Use the browse button to display a Reference browse window. Select the required RealFLO controller from the window.

  • Flow Run Number—Use the spin box to specify the number of this Flow Run.

The number of runs that a Gas Flow Computer can support depends on the type of SCADAPack controller that is being used to run the Gas Flow computer, and the RealFLO license agreement.

  • Severity—Use this combo box to define the priority of any alarms or events that ClearSCADA raises locally for the Flow Run (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Event Severity—Use this combo box to specify the severity of any Event Logs that ClearSCADA retrieves for the Flow Run. ClearSCADA adds the retrieved Event Log entries to the Event Journal, using the severity specified in this field.

Be aware that the generation of some Flow Run events is user-configurable. For example, an engineer can use the RealFLO application to specify whether a Gas Flow Computer is to log events associated with:

  • A Flow Run’s Low Flow (see Input Properties)
  • Changes in the configuration of a Flow Run’s compressibility calculation (see General NX-19 Calculation Properties, or see General AGA-8 Calculation Properties, as applicable).
  • Alarm Severity—Use this combo box to specify the severity of any Alarm Logs that ClearSCADA retrieves for the Flow Run. The server raises the retrieved alarms in ClearSCADA, using the severity specified in this field.
  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed on the tab. Use the field to specify the Area of Interest with which any Flow Run alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Confirm—Use this combo box to specify whether a confirmation dialog box is displayed whenever any of these critical action requests are triggered:
  • Abort Orifice Plate Change
  • Change Gas Composition Ratios
  • Force Inputs
  • Normalize
  • Orifice Plate Change
  • Read Configuration
  • Start Orifice Plate Change
  • Write Configuration.

For more information, see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration.


SCADAPack Modbus RealFLO Driver Guide - Configure the Scanning Properties (Configuring a SCADAPack Modbus Flow Run)

Configure the Scanning Properties

The ClearSCADA SCADAPack Modbus driver scans the RealFLO components of a controller on server, controller, or driver start-up, and whenever a new Flow Run is added to the system. Thereafter, the driver scans the controller’s RealFLO components for Flow Run data at the frequency specified in the Scanning section of the Flow Run tab.

For each of the separate scans listed, you specify an Interval and an Offset.

You use the Interval field to specify how often ClearSCADA scans the controller for Flow Run data. You use the Offset field to specify the synchronization offset—the amount of time that occurs before ClearSCADA first scans the controller for Flow Run data. Specify the Interval in the OPC Time Format, and the Offset in the OPC Relative Time Format.

Example:

The Hourly History Scan for a particular Flow Run has this configuration:

Interval:1H
Offset:H + 5M

This results in ClearSCADA scanning the controller for the Flow Run’s hourly historic data logs at five minutes past the start of the present hour, and at one-hourly intervals thereafter.

  • Current Scan—Specify the Interval and Offset at which ClearSCADA scans the Flow Run components for current data, including the latest calculation results.

The Current Scan also defines the frequency with which ClearSCADA retrieves the current data of any RealFLO Analog Input points, other than those that are configured to retrieve RealFLO History data.

  • Alarm Log Scan—Specify the Interval and Offset at which ClearSCADA scans the Flow Run components for alarm log data. ClearSCADA processes the read alarm log data using the severity specified in the Flow Run Form’s Alarm Severity field (see Configure the Basic Flow Run Properties).
  • Event Log Scan—Specify the Interval and Offset at which ClearSCADA scans the Flow Run components for event log data. ClearSCADA processes the read event log data using the severity specified in the Flow Run Form’s Event Severity field (see Configure the Basic Flow Run Properties).
  • Hourly History Scan—Specify the Interval and Offset at which ClearSCADA scans the Flow Run components for the data that the Gas Flow Computer stores historically on an hourly basis.

Unless ClearSCADA is retrieving historic data for the first time for a Flow Run, it typically retrieves only the hourly historic data that the Gas Flow Computer has stored for that Flow Run, since the previous Hourly History Scan. Be aware that this retrieval process differs whenever a RealFLO Analog Input point with an ‘Hourly History Data’ Source is added to the database. When ClearSCADA first retrieves data for such a point, it will read all of the Hourly History data that the Gas Flow Computer has in its database for that Flow Run. System performance might be affected while the retrieval of up to 35 days’ worth of historic data is in progress.

NOTE: For optimum system performance, we recommend that all points that are to have an ‘Hourly History Data’ source are configured and placed online at the same time.

(If necessary, operators can use the Hourly Demand Poll pick action to retrieve a Flow Run’s hourly historic data between scheduled Hourly History Scans.)

  • Daily History Scan—Specify the Interval and Offset at which ClearSCADA scans the Flow Run components for the data that the Gas Flow Computer stores historically on an daily basis.

Unless ClearSCADA is retrieving historic data for the first time for a Flow Run, it typically retrieves only the daily historic data that the Gas Flow Computer has stored for that Flow Run since the previous Daily History Scan. Be aware that this retrieval process differs whenever a RealFLO Analog Input point with a ‘Daily Flow History’ Source is added to the database. When ClearSCADA first retrieves data for such a point, it will read all of the Daily History data that the Gas Flow Computer has in its database for that Flow Run. System performance might be affected while the retrieval of up to 35 days’ worth of historic data is in progress.

NOTE: For optimum system performance, we recommend that all points that are to have an ‘Daily Flow History’ source are configured and placed online at the same time.

(If necessary, operators can use the Daily Demand Poll pick action to retrieve a Flow Run’s daily historic data between scheduled Daily History Scans.)

  • Flow Run Configuration Scan—Set both the Interval and Offset to zero if the Flow Run is being fully configured directly in ClearSCADA (see Configure or Read the Flow Run Configuration).

If the majority of the Flow Run’s configuration is undertaken using RealFLO and then read into ClearSCADA, specify the Interval and Offset at which ClearSCADA scans the Flow Run components for Flow Run configuration data. This scan defines the frequency with which ClearSCADA reads the Flow Run’s full configuration into the ClearSCADA database.

We recommend that operators use the Read Configuration pick action to manually read a Flow Run’s configuration into ClearSCADA, as required. For example, if a Flow Run’s configuration has been changed.

Use the Flow Run Configuration Scan as a ‘fall back’ measure. Use the Flow Run Configuration Scan to get ClearSCADA to read the Flow Run configuration at a frequency that maintains operator confidence that ClearSCADA has the latest configuration installed.

  • Allow Automatic Read of Flow Run Configuration—Only applies to SCADAPack controllers that are running RealFLO 6 or a later version of the software.

Select the check box if:

  • The majority of the Flow Run’s configuration is undertaken using RealFLO and then read into ClearSCADA.

and

  • ClearSCADA is to automatically read the Flow Run configuration if there is a noticeable update to that configuration since it was last read.

Clear the check box if:

  • The Flow Run is fully configured directly in ClearSCADA (see Configure or Read the Flow Run Configuration).

or:

  • The majority of the Flow Run’s configuration is undertaken using RealFLO and then read into ClearSCADA, and ClearSCADA is to update the Flow Run configuration data following the next scheduled Flow Run Configuration Scan (see above), or (if specified) Read Flow Run Configuration at Startup.
  • Read Flow Run Configuration at Startup—Select this check box if:
  • The majority of the Flow Run’s configuration is undertaken using RealFLO and then read into ClearSCADA.

and

  • ClearSCADA is to automatically read the Flow Run configuration on start-up of the server, ClearSCADA SCADAPack Modbus driver, the controller, or whenever a new Flow Run is added and enabled on the system.

Clear the check box if:

  • The Flow Run is fully configured directly in ClearSCADA (see Configure or Read the Flow Run Configuration).

or:

  • The majority of the Flow Run’s configuration is undertaken using RealFLO and then read into ClearSCADA, and ClearSCADA is to only read the controller’s Flow Run configuration when it is scheduled to perform a Flow Run Configuration Scan (see above), or if ClearSCADA is configured to Allow Automatic Read of Flow Run Configuration.


SCADAPack Modbus RealFLO Driver Guide - Input Properties (Configuring a SCADAPack Modbus Flow Run)

Input Properties

The fields within the Input section of the Flow Run tab display those properties that are associated with the flow calculation’s input values (the values that derive from the sensors that are used for the calculation’s input).

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation provided with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Static Pressure Properties (Configuring a SCADAPack Modbus Flow Run)

Static Pressure Properties

The fields within this section of the Flow Run tab display those properties that are associated with Static Pressure measurement.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation provided with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Temperature Properties (Configuring a SCADAPack Modbus Flow Run)

Temperature Properties

The fields within this section of the Flow Run tab display those properties that are associated with a Flow Run’s Temperature inputs.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation provided with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Contract Properties (Configuring a SCADAPack Modbus Flow Run)

Contract Properties

The fields within the Contract section of the Flow Run tab display those configuration properties that are associated with the output of the flow calculation.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation provided with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Compressibility Calculation Properties (Configuring a SCADAPack Modbus Flow Run)

Compressibility Calculation Properties

The Compressibility Calculation tab on the Flow Run Form displays the properties that are associated with a Flow Run’s compressibility calculation. Use the fields to configure or view specific properties that are associated with the calculation.

The fields vary, depending on the The Compressibility Calculation Type that a Flow Run performs.


SCADAPack Modbus RealFLO Driver Guide - The Compressibility Calculation Type (Configuring a SCADAPack Modbus Flow Run)

The Compressibility Calculation Type

Depending on the system setup, a RealFLO-enabled SCADAPack controller can provide one of two industry-standard gas compressibility calculations:

  • AGA-8—A detailed gas compressibility calculation. This is the recommended calculation for systems that can support this type.
  • NX-19—A gas compressibility calculation for use on older applications that do not support AGA-8 calculations.

The Type of calculation that a Flow Run performs is read into ClearSCADA when the server establishes communications with the controller on which the Flow Run is located. You can also specify the calculation Type manually, if required. For instance, if a Flow Run’s data is to be used on report(s), and you want to configure those reports to include the relevant data fields, before ClearSCADA establishes communications with the controller on which the Flow Run is located.

The Type field at the top of the Compressibility Calculation tab indicates the type of compressibility calculation that a Flow Run performs.

The type of calculation that a Flow Run performs determines the fields that are displayed on the rest of the tab.

If the Compressibility Calculation Type is NX-19, the tab displays fields that show the General NX-19 Calculation Properties.

If the Compressibility Calculation Type is AGA-8, the tab displays fields that show the:

  • General AGA-8 Calculation Properties
  • AGA-8 Gas Composition Properties
  • AGA-8 Hexane Properties
  • AGA-8 Relative Density and Heating Value Properties.


SCADAPack Modbus RealFLO Driver Guide - General NX-19 Calculation Properties (Configuring a SCADAPack Modbus Flow Run)

General NX-19 Calculation Properties

These fields are displayed on the Compressibility Calculation tab if a Flow Run performs NX-19 calculations (see The Compressibility Calculation Type).

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

  • Specific Gravity—The specific gravity of the gas that is being measured. The range is 0.554 to 1.000.
  • Carbon Dioxide—The percentage of carbon dioxide in the gas that is being measured. The range is 0 to 15%.
  • Nitrogen—The percentage of nitrogen in the gas that is being measured. The range is 0 to 15%.
  • Heating Value—The heating value of the gas that is being measured. The range is 0 to 1800 BTU/ft3, or equivalent. (The default is 1014.33 BTU/ft3.)
  • Configuration Events—This field specifies whether the Gas Flow Computer logs an event whenever the NX-19 configuration changes (Log Changes), or does not log an event whenever the NX-19 configuration changes (Ignore).

The ClearSCADA SCADAPack Modbus driver scans a Flow Run’s Event Log at the frequency specified in the Scanning section of the Flow Run tab (see Configure the Scanning Properties). The server then processes the events in accordance with the Flow Run tab’s Event Severity setting.


SCADAPack Modbus RealFLO Driver Guide - General AGA-8 Calculation Properties (Configuring a SCADAPack Modbus Flow Run)

General AGA-8 Calculation Properties

These fields are displayed at the top of the Compressibility Calculation tab if a Flow Run performs AGA-8 compressibility calculations.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

  • Composition Units—Defines whether the various components that combine to form the gas are specified as a percentage of the overall composition (0 to 100%), or as a fraction of the gas that is being measured (0 to 1.0000).

The field indicates either Percent or Mole Fraction. The unit applies to the AGA-8 Gas Composition Properties and AGA-8 Hexane Properties that are displayed on the Compressibility Calculation tab.

  • Configuration Events—This field specifies whether the Gas Flow Computer logs an event whenever the AGA-8 configuration changes.

The ClearSCADA SCADAPack Modbus driver scans a Flow Run’s Event Log at the frequency specified in the Scanning section of the Flow Run tab (see Configure the Scanning Properties). The server then processes the events in accordance with the Flow Run tab’s Event Severity setting.


SCADAPack Modbus RealFLO Driver Guide - AGA-8 Gas Composition Properties (Configuring a SCADAPack Modbus Flow Run)

AGA-8 Gas Composition Properties

The fields within this section of the Compressibility Calculation tab display those properties that are associated with Gas Composition. The properties display the amount of each component that combines to form the overall composition of the gas that the Flow Run is measuring.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

The values are displayed as either a percentage or fraction of the overall composition, depending on the unit that is specified in the Composition Units field (see General AGA-8 Calculation Properties).

The sum of the non-zero values within the Gas Composition section of the tab needs to equate to 100 (if they are displayed as a percentage), or 1 (if they are displayed as a fraction). ClearSCADA displays a diagnostic message should the configuration be saved when the sum of the non-zero values equates to a value other than this total. Should the values equate to an incorrect total, you might want to consider using the Normalize pick action to request ClearSCADA to adjust each of the non-zero values by an appropriate amount so that they combine to form the required total. (You may need to close and redisplay the Form for the data to be updated in the Gas Composition fields.)

Only one Hexanes+ field is available for use instead of the individual n-Hexane to n-Decane fields if a Combined Hexanes+ Ratios composition is specified in the AGA-8 Hexane Properties section of the tab.


SCADAPack Modbus RealFLO Driver Guide - AGA-8 Hexane Properties (Configuring a SCADAPack Modbus Flow Run)

AGA-8 Hexane Properties

The fields within the Hexanes+ section of the Compressibility Calculation tab display the properties that are associated with the hexane components in the gas. The properties display the amount of the various hexane and higher components that contribute to the overall Hexanes+ content within the gas.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

If the Hexanes+ Ratios are set to Individual, the values of the individual hexane components are displayed in the AGA-8 Gas Composition Properties section of the tab.

If the Hexanes+ Ratios are set to Combined, the rest of the fields within the Hexanes+ section of the tab become available for use. The individual values are displayed as a percentage of the overall Hexane content in the gas. The sum of the non-zero values needs to equate to 100. ClearSCADA displays a diagnostic message should the configuration be saved when the sum of the non-zero values equates to a value other than 100. Should this occur, you might want to consider using the Normalize pick action to request ClearSCADA to adjust each of the non-zero values by an appropriate amount so that they do total 100%. (You may need to close and redisplay the Form for the data to be updated in the Hexanes+ fields.)


SCADAPack Modbus RealFLO Driver Guide - AGA-8 Relative Density and Heating Value Properties (Configuring a SCADAPack Modbus Flow Run)

AGA-8 Relative Density and Heating Value Properties

The fields within this section of the Compressibility Calculation tab display the calculation’s Relative Density and Heating Value properties.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on the above properties, see the documentation provided with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Flow Calculation Properties (Configuring a SCADAPack Modbus Flow Run)

Flow Calculation Properties

The Flow Calculation tab on the Flow Run Form displays the parameters that are associated with a Flow Run’s flow calculation. You can use the fields to configure or view specific properties that are associated with the calculation.

The fields vary, depending on the The Type of Flow Calculation that a Flow Run performs.


SCADAPack Modbus RealFLO Driver Guide - The Type of Flow Calculation (Configuring a SCADAPack Modbus Flow Run)

The Type of Flow Calculation

Depending on the system setup, a RealFLO-enabled SCADAPack controller can provide one of several industry standard gas flow calculations:

  • AGA-3 (1985)—Gas volume calculated using a pre-1992 orifice meter
  • AGA-3 (1992)—Gas volume calculated using an orifice meter
  • AGA-7—Gas volume calculated using a turbine meter
  • V-Cone—Gas volume calculated using a V-Cone gas flow meter.

The type of calculation that a Flow Run performs is read into ClearSCADA when the server establishes communications with the controller on which the Flow Run is located. You can also specify the calculation Type manually, if required. For instance, if a Flow Run’s data is to be used on report(s), and you want to configure those reports to include the relevant data fields, before ClearSCADA establishes communications with the controller on which the Flow Run is located.

The Type field at the top of the Flow Calculation tab indicates the type of flow calculation that a flow run performs.

The type of calculation that a Flow Run performs, determines the fields that are displayed on the rest of the tab.

If the Flow Calculation Type is AGA-3, the tab displays fields that show:

  • AGA-3 or V-Cone Differential Pressure Properties
  • AGA-3 General Properties
  • AGA-3 Deadband Properties.

If the Flow Calculation Type is AGA-7, the tab displays fields that show:

  • AGA-7 Turbine Properties
  • AGA-7 Factor Properties.

If the Flow Calculation Type is V-Cone, the tab displays fields that show:

  • AGA-3 or V-Cone Differential Pressure Properties
  • V-Cone General Properties
  • V-Cone Flow Coefficient Properties.


SCADAPack Modbus RealFLO Driver Guide - AGA-3 or V-Cone Differential Pressure Properties (Configuring a SCADAPack Modbus Flow Run)

AGA-3 or V-Cone Differential Pressure Properties

The fields within this section of the Flow Calculation tab display properties associated with the calculation’s Differential Pressure input.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

The availability of the fields in this section varies, depending on the Input Type.

For more information on the properties that are displayed in this section, see the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - AGA-3 General Properties (Configuring a SCADAPack Modbus Flow Run)

AGA-3 General Properties

The fields within this section of the Flow Calculation tab display properties associated with the AGA-3 calculation parameters.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - AGA-3 Deadband Properties (Configuring a SCADAPack Modbus Flow Run)

AGA-3 Deadband Properties

The fields within this section of the Flow Calculation tab display properties associated with the AGA-3 calculation Deadbands.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - AGA-7 Turbine Properties (Configuring a SCADAPack Modbus Flow Run)

AGA-7 Turbine Properties

The fields within this section of the Flow Calculation tab display properties associated with the Turbine input for the calculation.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - AGA-7 Factor Properties (Configuring a SCADAPack Modbus Flow Run)

AGA-7 Factor Properties

The fields within this section of the Flow Calculation tab display properties associated with the AGA-7 calculation parameters.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - V-Cone General Properties (Configuring a SCADAPack Modbus Flow Run)

V-Cone General Properties

The fields within this section of the Flow Calculation tab display properties associated with the basic V-Cone parameters.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - V-Cone Flow Coefficient Properties (Configuring a SCADAPack Modbus Flow Run)

V-Cone Flow Coefficient Properties

The fields within this section of the Flow Calculation tab display properties associated with the V-Cone Flow Coefficients.

You can configure these properties directly in ClearSCADA, or read the configuration into the ClearSCADA database (see Configure or Read the Flow Run Configuration).

For more information on these properties, see the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Points Used on SCADAPack Modbus RealFLO Controllers

Points Used on SCADAPack Modbus RealFLO Controllers

SCADAPack Modbus RealFLO controllers support a combination of these point types:

  • SCADAPack Modbus RealFLO Analog Input Points—Use SCADAPack Modbus RealFLO Analog Input Points (see Configuring RealFLO Analog Input Points) to process Flow Run data on a RealFLO controller.

The rate at which ClearSCADA retrieves RealFLO data on SCADAPack Modbus RealFLO Analog Input Points is determined by the intervals specified on the configuration Form of the Flow Run with which each RealFLO point is associated.

Unlike the ‘standard’ SCADAPack Modbus Analog points listed below, SCADAPack Modbus RealFLO Analog Input points do not support Persistence.

To process other data on a RealFLO controller, you use the appropriate ‘standard’ point type listed below:

  • SCADAPack Modbus Analog Input Points—see Configuring Analog Points in the ClearSCADA Guide to the SCADAPack Modbus Driver
  • SCADAPack Modbus Analog Output Points—see Configuring Analog Points in the ClearSCADA Guide to the SCADAPack Modbus Driver
  • SCADAPack Modbus Digital Input Points—see Configuring Digital Points in the ClearSCADA Guide to the SCADAPack Modbus Driver
  • SCADAPack Modbus Digital Output Points—see Configuring Digital Points in the ClearSCADA Guide to the SCADAPack Modbus Driver.

For information on the minimal amount of configuration that you can undertake to produce a functional RealFLO point in ClearSCADA, see Minimum Configuration.

Be aware that although ClearSCADA assigns RealFLO Analog Input point addresses automatically, you need to manually assign appropriate addresses for those SCADAPack Modbus points that represent data other than RealFLO data on a RealFLO controller (see SCADAPack Modbus RealFLO Point Addressing).


SCADAPack Modbus RealFLO Driver Guide - Minimum Configuration (Points Used on SCADAPack Modbus RealFLO Controllers)

Minimum Configuration

For each SCADAPack Modbus RealFLO Analog Input point, as a minimum you need to specify these features on the Analog Point tab, then put the point In Service and save the configuration:

  • The Flow Run with which the point is associated
  • The Source and Item of Flow Run data that the point represents
  • The Scan Group (Confidence Interval)
  • The Scaling
  • The Logged Data properties (if required).

If you want SCADAPack Modbus RealFLO point data to be stored historically, you additionally need to:

  • Enable and configure logging on the Historic tab if data is to be stored historically in the server database.


SCADAPack Modbus RealFLO Driver Guide - SCADAPack Modbus RealFLO Point Addressing (Points Used on SCADAPack Modbus RealFLO Controllers)

SCADAPack Modbus RealFLO Point Addressing

Controllers on the SCADAPack Modbus driver support one of two point address ranges—5 Digit, or 6 Digit. You need to be aware of which address range each controller on your system supports. (For instance, current SCADAPack controllers use 5-Digit addressing.) Specify the supported Point Address Range on each SCADAPack Modbus RealFLO Outstation Form (see Specify the Point Address Range in the ClearSCADA Guide to the SCADAPack Modbus Driver).

ClearSCADA assigns RealFLO Analog Input point addresses automatically. However, you still need to manually assign appropriate addresses for those SCADAPack Modbus points that represent data other than RealFLO data on a RealFLO controller. For such points, specify the individual point Address on each SCADAPack Modbus Point Form (see Configure Common Point Properties in the ClearSCADA Guide to the SCADAPack Modbus Driver).

Further Information

SCADAPack and Generic Modbus Point Addressing in the ClearSCADA Guide to the SCADAPack Modbus Driver.


SCADAPack Modbus RealFLO Driver Guide - Configuring RealFLO Analog Input Points

Configuring RealFLO Analog Input Points

SCADAPack RealFLO controllers support ‘standard’ SCADAPack Modbus Analog Input points and Analog Output points (see Points Used on SCADAPack Modbus RealFLO Controllers). SCADAPack Modbus RealFLO controllers also support SCADAPack Modbus RealFLO Analog Input points—points that are used to process gas flow calculation data in ClearSCADA (see Configure ClearSCADA to Monitor RealFLO Gas Calculation Data).

This section summarizes the RealFLO-specific properties that apply to SCADAPack Modbus RealFLO Analog Input points. You configure these properties using the fields on the Analog Point tab of the SCADAPack Modbus RealFLO Analog Input Point Form.

Use the Analog Point tab to:

  • Configure the General RealFLO Analog Point Properties
  • Configure the Alarm Limits (see Configure Alarm Limits in the ClearSCADA Guide to the SCADAPack Modbus Driver)
  • Configure any Alarm Limit Profiles (see Specify any Alarm Limit Profiles in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Point Scaling (see Define the Point Scaling in the ClearSCADA Guide to the SCADAPack Modbus Driver)
  • Define the Point Formatting (see Define the Appearance of an Analog Point’s Values in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Override Properties (see Define whether an Analog Point can be Overridden in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Significant Change Properties (see Define the Criteria for a Significant Change in Value in the ClearSCADA Guide to Core Point Configuration)
  • Configure the No Change Properties (see Detect whether an Analog Point has Stopped Changing in the ClearSCADA Guide to Core Point Configuration).
  • Specify the Trend Properties (see Define an Analog Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Specify the Logged Data Properties (see Log Point Data on SCADAPack Controllers in the ClearSCADA Guide to the SCADAPack Modbus Driver).

The fields on other tabs are common to points on many advanced drivers (see Tabs on Point Forms in the ClearSCADA Guide to Advanced Drivers).


SCADAPack Modbus RealFLO Driver Guide - Configure the General RealFLO Analog Point Properties (Configuring RealFLO Analog Input Points)

Configure the General RealFLO Analog Point Properties

RealFLO Analog Input points are used to process gas flow calculation data in ClearSCADA (see Configure ClearSCADA to Monitor RealFLO Gas Calculation Data). (To process any other data on a RealFLO controller, configure a ‘standard’ analog or digital point, rather than a RealFLO Analog Input point.)

Use the fields at the top of the Analog Point tab on the SCADAPack Modbus RealFLO Analog Input Point Form to configure the point’s common properties. Fields that are specific to RealFLO Analog Input points are explained below. For properties that are also common to other points on the SCADAPack Modbus driver, see Configure Common Point Properties in the ClearSCADA Guide to the SCADAPack Modbus Driver.

  • Outstation—This field is for information only. It displays the name of the controller on which the point is located.

Use the Flow Run field (see below) to specify the Flow Run with which the RealFLO Analog Input point is associated. The Outstation (controller) is inherited from the Flow Run and is displayed in this field the next time that the configuration is saved.

  • Flow Run—Use to specify the Flow Run with which the point is associated. Use the browse button to display a Reference browse window. Select the required Flow Run from the window.
  • Address—This field is for information only. It displays the address that defines the location of the item of Flow Run data that the point reads.

ClearSCADA allocates the address automatically, in relation to the Source and Item (see below) that are specified for the point. Once the Source and Item have been specified, the Address is inherited from those properties and is displayed in this field the next time that the configuration is saved.

  • Source—Use to define the source of the data in the Flow Run. Use this field in conjunction with the Item field (see below) to Specify the Item of Flow Run Data that a RealFLO Analog Represents.

The possible Source options are:

  • Accumulation—A Gas Flow Computer is able to accumulate data about the gas flow over the present and previous day and month. Select this option if the point is being used to read an item of data from the Gas Flow Computer’s Accumulated Reading register (see Flow Run Accumulation Data).

ClearSCADA retrieves any Accumulation point values at the frequency specified for the Flow Run’s Current Scan (see Configure the Scanning Properties).

  • Input—The point is used to read one of the inputs that is associated with either the Flow Run’s configuration or its Flow Calculation (see Flow Run Input Data). The actual Flow Run and Flow Calculation properties are specified on the Flow Run Form (see Configure the Flow Run Properties, or see Flow Calculation Properties, as appropriate.)

ClearSCADA retrieves any Input point values at the frequency specified for the Flow Run’s Current Scan (see Configure the Scanning Properties).

  • Flow Calculation—The point is used to read an item of Flow Calculation Data. For the type of Flow Calculation that the Flow Run performs and the properties that are associated with that calculation, see Flow Calculation Properties.

Flow Calculations continuously recalculate in a Gas Flow Computer. ClearSCADA retrieves any Flow Calculation point values at frequency specified for the Flow Run’s Current Scan (see Configure the Scanning Properties).

  • Compressibility Calculation—The point is used to read an item of Flow Run Compressibility Calculation Data. For the type of Compressibility Calculation that the Flow Run performs and the properties that are associated with that calculation, see Compressibility Calculation Properties.

Compressibility Calculations continuously recalculate in a Gas Flow Computer. ClearSCADA retrieves any Compressibility Calculation point values at frequency specified for the Flow Run’s Current Scan (see Configure the Scanning Properties).

  • Density Calculation—The point is used to read the Heating Value that is associated with the Flow Run’s Compressibility Calculation (see Flow Run Density Calculation Data). The raw Heating value that is read into ClearSCADA is displayed on the Compressibility Calculation tab of the Flow Run Form (see General NX-19 Calculation Properties, or see AGA-8 Relative Density and Heating Value Properties).

Density Calculations continuously recalculate in a Gas Flow Computer. ClearSCADA retrieves any Density Calculation point values at frequency specified for the Flow Run’s Current Scan (see Configure the Scanning Properties).

  • Daily Flow History—The point is used to read data from the daily logs that are produced by the Flow Computer (see Flow Run Daily History Data). Each Flow Computer can retain 35 days-worth of daily logs.

ClearSCADA retrieves this point data at the frequency specified for the Flow Run’s Daily History Scan (see Configure the Scanning Properties).

Be aware that should a RealFLO Analog Input point with a ‘Daily Flow History’ Source be added to an existing system, when ClearSCADA first retrieves the data for that point, it will read all of the Daily History data that the Gas Flow Computer has in its database for the Flow Run. System performance may be affected while the retrieval of up to 35 days’ worth of historic data is in progress.

NOTE: For optimum system performance, we recommend that all points that are to have an ‘Daily Flow History’ source are configured and placed online at the same time.

  • Hourly History Data—The point is used to read data from the hourly logs that are produced by the Flow Computer (see Flow Run Hourly History Data). Each Flow Computer can retain 35 days-worth of hourly logs.

ClearSCADA retrieves this point data at the frequency specified for the Flow Run’s Hourly History Scan (see Configure the Scanning Properties).

Be aware that should a RealFLO Analog Input point with an ‘Hourly History Data’ Source be added to an existing system, when ClearSCADA first retrieves the data for that point, it will read all of the Hourly History data that the Gas Flow Computer has in its database for the Flow Run. System performance may be affected while the retrieval of up to 35 days’ worth of historic data is in progress.

NOTE: For optimum system performance, we recommend that all points that are to have an ‘Hourly History Data’ source are configured and placed online at the same time.

  • Item—Use to Specify the Item of Flow Run Data that a RealFLO Analog Represents. The options vary, depending on the type of data Source that the point represents.
  • Scan Group (Confidence Interval)—Use the combo box to specify the Scan Group with which the point is associated. The Scan Group determines the frequency with which the driver updates the server with the current value for the point. This provides confidence that all is well between ClearSCADA and the direct controller, as the point is updated in the database at the Scan Group rate, regardless of whether the point has changed in the controller.

With RealFLO Analog Input points, you should specify a Scan Group that has an interval that is a multiple of the Flow Run’s Current Scan interval (see Configure the Scanning Properties). RealFLO Analog Input points are polled in a block at the Flow Run’s scanning intervals, rather than individually. As such, a RealFLO point’s Scan Group interval does not trigger a poll for data. Therefore, if a Scan Group is specified that has an interval that is faster than the Flow Run’s Current Scan interval, the point will still only be updated at the latter rate—the driver will not schedule extra polls if the Scan Group’s rate is faster.

Specify the frequency of each Scan Group on the Scan Parameters tab of the associated Channel Form (see Define Intervals for Timed Current Data Updates in the ClearSCADA Guide to Advanced Drivers).

The Scan Group (Confidence Interval) combo box does not apply if the server only retrieves logged, but not current data for a point. (This occurs when a point’s DLOG Only check box is selected—see Log Point Data on SCADAPack Controllers in the ClearSCADA Guide to the SCADAPack Modbus Driver. On a RealFLO Analog Input point, this also occurs when the point’s Source is specified as either Daily Flow History or Hourly History Data (see above).)

  • Data Type—This field is for information only. The Data Type is determined by the type of data Source and Item of Flow Run data that the RealFLO Analog represents. The Data Type specifies the format of the raw data.

Examples:

In order to assess the amount of gas that has been used during the past month, you might configure a RealFLO Analog Input point to have the following properties:

Source:Accumulation
Item:Flow volume in current month

In order to assess the current flow rate, you might configure a RealFLO Analog Input point to have these properties:

Source:Flow Calculation
Item:Flow volume rate

For more information on the type of Flow Run data that a RealFLO Analog Input point can monitor, see Specify the Item of Flow Run Data that a RealFLO Analog Represents.


SCADAPack Modbus RealFLO Driver Guide - Specify the Item of Flow Run Data that a RealFLO Analog Represents (Configuring RealFLO Analog Input Points)

Specify the Item of Flow Run Data that a RealFLO Analog Represents

This section indicates which items of Flow Run data you can configure a RealFLO Analog Input point to represent.

Many items of Flow Run data are available directly from the Flow Run itself—to enable users to view such data, you can attach the Flow Run properties to a display, such as a Mimic, or a Trend. (In such cases, you only need to associate the data with an Analog point if you want ClearSCADA to further process or store the Flow Run data—for more information, see View and Process Flow Run Data.)

Some items of Flow Run data are not available directly from the Flow Run database item—they are calculated using the Flow Run’s configuration, but are stored internally. To view or process these items of data in ClearSCADA, you need to configure a RealFLO Analog Input point. These items of data are listed in this section.

To process an item of Flow Run data independently in ClearSCADA, or to view an item of Flow Run data that is not directly available from the Flow Run Form, you can add and configure a SCADAPack Modbus RealFLO Analog Input point (see Configure the General RealFLO Analog Point Properties).

To define which item of Flow Run data a RealFLO Analog Input point represents, you need to specify:

  • The Flow Run with which the Analog point is associated
  • The Source of the Flow Run data with which the point associated (for example, the Compressibility Calculation)
  • The individual Item of Source data that the Analog point represents (for example, the Mass density at flow conditions).

You configure each of the above, using the appropriate fields at the top of the Analog Point tab on the Point Form (see Configure the General RealFLO Analog Point Properties).

You can configure a RealFLO Analog Input point to represent:

  • Flow Run Accumulation Data
  • Flow Run Input Data
  • Flow Calculation Data
  • Flow Run Compressibility Calculation Data
  • Flow Run Density Calculation Data
  • Flow Run Daily History Data
  • Flow Run Hourly History Data.

For information on Flow Run data that is not covered by this guide, see the documentation supplied with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Flow Run Accumulation Data (Configuring RealFLO Analog Input Points)

Flow Run Accumulation Data

If you configure a RealFLO Analog Input point to have an Accumulation Source, you can configure that Analog point to represent any one of these Items of Flow Run data:


SCADAPack Modbus RealFLO Driver Guide - Flow Run Input Data (Configuring RealFLO Analog Input Points)

Flow Run Input Data

If you configure a RealFLO Analog Input point to have an Input Source, you can configure that Analog point to represent any one of these Items of Flow Run data:


SCADAPack Modbus RealFLO Driver Guide - Flow Calculation Data (Configuring RealFLO Analog Input Points)

Flow Calculation Data

If you configure a RealFLO Analog Input point to have a Compressibility Calculation Source, you can configure that Analog point to represent any one of these Items of Flow Run data:


SCADAPack Modbus RealFLO Driver Guide - Flow Run Compressibility Calculation Data (Configuring RealFLO Analog Input Points)

Flow Run Compressibility Calculation Data

If you configure a RealFLO Analog Input point to have a Compressibility Calculation Source, you can configure that Analog point to represent any one of these Items of Flow Run data:


SCADAPack Modbus RealFLO Driver Guide - Flow Run Density Calculation Data (Configuring RealFLO Analog Input Points)

Flow Run Density Calculation Data

If you configure a RealFLO Analog Input point to have a Density Calculation Source, you can configure that Analog point to represent this Item of Flow Run data:


SCADAPack Modbus RealFLO Driver Guide - Flow Run Daily History Data (Configuring RealFLO Analog Input Points)

Flow Run Daily History Data

If you configure a RealFLO Analog Input point to have a Daily Flow History Source, you can configure that Analog point to represent any one of these Items of Flow Run data:

Always ensure that Historic is enabled for a RealFLO Analog Input point that has a Daily Flow History Source, so that ClearSCADA stores the data historically. For information on enabling Historic data storage, see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration.

ATTENTION: If a RealFLO Analog Input point with a ‘Daily History Data’ Source is added to an existing system, when ClearSCADA first retrieves the data for that point, it will read all of the Daily History data that the Gas Flow Computer has in its database for that Flow Run. System performance may be affected while the retrieval of up to 35 days’ worth of historic data is in progress.


SCADAPack Modbus RealFLO Driver Guide - Flow Run Hourly History Data (Configuring RealFLO Analog Input Points)

Flow Run Hourly History Data

If you configure a RealFLO Analog Input point to have a Hourly History Data Source, you can configure that Analog point to represent any one of these Items of Flow Run data:

Always ensure that Historic is enabled for a RealFLO Analog Input point that has an Hourly History Data Source, so that ClearSCADA stores the data historically. For information on enabling Historic data storage, see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration.

ATTENTION: If a RealFLO Analog Input point with an ‘Hourly History Data’ Source is added to an existing system, when ClearSCADA first retrieves the data for that point, it will read all of the Hourly History data that the Gas Flow Computer has in its database for that Flow Run. System performance may be affected while the retrieval of up to 35 days’ worth of historic data is in progress.


SCADAPack Modbus RealFLO Driver Guide - RealFLO Specific Alarm and Event Categories

RealFLO Specific Alarm and Event Categories

Each alarm and event on a ClearSCADA system has a Category that indicates the type of alarm or event. The Category is included by default in the Events List and, if applicable, the Alarms List and the Alarm Banner.

You can optionally filter the entries in either List by category—the entries from which you can choose comprise various ‘core’ categories, along with any categories that are specific to the drivers that are installed on your system.

On systems on which both the SCADAPack Modbus and RealFLO driver components are installed, in addition to the ‘core’ alarm and event categories, these RealFLO specific categories are available:

  • EFM Alarm—Entries associated with EFM alarms that have been logged in the controller’s Flow Run.
  • EFM Event—Entries associated with EFM events that have been logged in the controller’s Flow Run.

Further Information

Events Lists and ‘core’ filter categories: see the ClearSCADA Guide to Lists.

Alarms Lists and ‘core’ filter categories: see the ClearSCADA Guide to Alarms.


SCADAPack Modbus RealFLO Driver Guide - Using RealFLO Specific Actions

Using RealFLO Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section covers those actions that are RealFLO-specific and comprises:

  • Actions Associated with SCADAPack Modbus Flow Runs
  • Actions Associated with SCADAPack Modbus RealFLO Controllers
  • Alphabetical List of SCADAPack Modbus RealFLO Specific Actions.

These actions are in addition to SCADAPack Modbus-specific actions (see Using SCADAPack Modbus Specific Actions in the ClearSCADA Guide to the SCADAPack Modbus Driver).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


SCADAPack Modbus RealFLO Driver Guide - Actions Associated with SCADAPack Modbus Flow Runs (Using RealFLO Specific Actions)

Actions Associated with SCADAPack Modbus Flow Runs

These actions are specific to SCADAPack Modbus Flow Runs:

  • Abort Orifice Plate Change—Dual Chamber Orifice Plate Changes
  • Alarm Log Demand Poll
  • Change Gas Composition Ratios—AGA-8 only
  • Daily Demand Poll
  • Event Log Demand Poll
  • Force Inputs
  • Hourly Demand Poll
  • Normalize—AGA-8 only
  • Orifice Plate Change—AGA-3 only
  • Read Configuration
  • Start Orifice Plate Change—Dual Chamber Orifice Plate Changes
  • Write Configuration.


SCADAPack Modbus RealFLO Driver Guide - Actions Associated with SCADAPack Modbus RealFLO Controllers (Using RealFLO Specific Actions)

Actions Associated with SCADAPack Modbus RealFLO Controllers

This action is specific to RealFLO controllers:

  • Set Clock.


SCADAPack Modbus RealFLO Driver Guide - Alphabetical List of SCADAPack Modbus RealFLO Specific Actions (Using RealFLO Specific Actions)

Alphabetical List of SCADAPack Modbus RealFLO Specific Actions

This section lists those actions that are specific to the SCADAPack Modbus RealFLO driver. These actions are in addition to the actions that are specific to the parent SCADAPack Modbus driver (see Using SCADAPack Modbus Specific Actions in the ClearSCADA Guide to the SCADAPack Modbus Driver).

  • Abort Orifice Plate Change
  • Alarm Log Demand Poll
  • Change Gas Composition Ratios
  • Daily Demand Poll
  • Event Log Demand Poll
  • Force Inputs
  • Hourly Demand Poll
  • Normalize
  • Orifice Plate Change
  • Read Configuration
  • Set Clock
  • Start Orifice Plate Change
  • Write Configuration.


SCADAPack Modbus RealFLO Driver Guide - Abort Orifice Plate Change (Using RealFLO Specific Actions)

Abort Orifice Plate Change

Associated with: SCADAPack Modbus Flow Runs that perform AGA-3 Flow Calculations and have a Dual Chamber Orifice

Security permission required to access this pick action: Tune Limits

CAUTION

unexpected behavior of application

Ensure that the relevant sensors or registers are connected before using the Abort Orifice Plate Change pick action to end plate change forcing and revert the Flow Run’s inputs back to live values.

If the live input values are provided by local registers but those registers are not connected beforehand, the input values will be undefined.

If the live input values are provided by sensors but those sensors are not connected beforehand, the Flow Computer will report communication lost. If supported by the version of RealFLO, the Flow Computer will then use the last known good value or the Default Value specified in the configuration. This might result in the flow calculation producing a different result to that which is expected.

Failure to follow these instructions can result in unexpected Flow Calculation results.

Use this pick action to abort a Start Orifice Plate Change request that is in process.

When triggered, the Abort Orifice Plate Change pick action removes any plate change forcing that is in existence and reverts the inputs to live sensor values.


SCADAPack Modbus RealFLO Driver Guide - Alarm Log Demand Poll (Using RealFLO Specific Actions)

Alarm Log Demand Poll

Associated with: SCADAPack Modbus Flow Runs

Security permission required to access this pick action: Retrieve Data

Use this pick action to request the driver to perform an Alarm Log Demand Poll on a controller for the alarms that are associated with a particular Flow Run.

Select the Alarm Log Demand Poll pick action to display the Alarm Log Demand Poll window. Use the window’s Range field to specify which alarms to retrieve:

  • New—Retrieve only those alarms that have been raised since the last Alarm Log Demand Poll.
  • All—Retrieve all of the Flow Run’s alarms from the controller’s alarm log.

ATTENTION: Retrieving of All of a Flow Run’s alarms may result in duplicate entries being logged in ClearSCADA’s Event Journal.

Select the OK button to confirm the request and retrieve the specified alarms.


SCADAPack Modbus RealFLO Driver Guide - Change Gas Composition Ratios (Using RealFLO Specific Actions)

Change Gas Composition Ratios

Associated with: SCADAPack Modbus Flow Runs that perform AGA-8 Compressibility Calculations

Security permission required to access this pick action: Tune Limits

This pick action enables a user that is allocated the Tune Limits permission for a Flow Run, to change that Flow Run’s Gas Composition ratios.

Select the pick action to display the Change Gas Composition Ratios window, showing the Flow Run’s present Gas Composition values.

Update the value in each field as required.

The Hexanes+ field is available for use should a Flow Run’s configuration specify that the Hexanes+ Ratios are Combined.

The n-Hexane to n-Decane fields are available for use (and the Hexanes+ field ‘grayed out’) should a Flow Run’s configuration specify that the Hexanes+ Ratios are Individual.

Select the Normalize check box if you want ClearSCADA to adjust each non-zero value appropriately, if the sum of the non-zero values does not equate to 100% (if the values are displayed as a percentage), or 1 (if the values are displayed as a mole fraction). If the values equate correctly, or ClearSCADA successfully normalizes the values, it will write the changes to the Flow Run. (For more information on normalizing values, see Normalize.)

Ensure that the Normalize check box is clear if ClearSCADA is only to check whether the non-zero values equate to 100% or 1 and is not to normalize any values. If the non-zero values do not equate to the expected value, ClearSCADA will raise a diagnostic message. Correct the non-zero values accordingly—once they equate correctly, ClearSCADA will write the changes to the Flow Run.

Further Information

AGA-8 Gas Composition Properties.

AGA-8 Hexane Properties.


SCADAPack Modbus RealFLO Driver Guide - Daily Demand Poll (Using RealFLO Specific Actions)

Daily Demand Poll

Associated with: SCADAPack Modbus Flow Runs

Security permission required to access this pick action: Retrieve Data

ClearSCADA automatically polls a controller for a Flow Run’s daily historic data at the frequency that is specified using the Flow Run’s Daily History Scan field (see Configure the Scanning Properties).

The Daily Demand Poll pick action allows a Flow Run’s daily historic data to be retrieved between scheduled Daily History scans.

Select the pick action to display the Daily Demand Poll window. Use the window’s Range field to specify the range of daily historic data that the driver is to retrieve:

  • Most Recent—The driver retrieves any daily history data that the Flow Run has generated at the controller, since the last item of daily history data that is recorded for that Flow Run in ClearSCADA.
  • All—The driver retrieves all of the Flow Run’s daily historic data.

ATTENTION: Use this option with care. Specifying that ClearSCADA is to retrieve All of a Flow Run’s daily historic data could have an adverse affect on system performance, while ClearSCADA retrieves and processes up to 35 day’s worth of historic data.


SCADAPack Modbus RealFLO Driver Guide - Event Log Demand Poll (Using RealFLO Specific Actions)

Event Log Demand Poll

Associated with: SCADAPack Modbus Flow Runs

Security permission required to access this pick action: Retrieve Data

Use this pick action to request the driver to perform an Event Log Demand Poll on a controller for the events that are associated with a particular Flow Run.

Select the Event Log Demand Poll pick action to display the Event Log Demand Poll window. Use the window’s Range field to specify which events to retrieve:

  • New—Retrieve only those events that have been raised since the last Event Log Demand Poll.
  • All—Retrieve all of the Flow Run’s events from the controller’s event log.

ATTENTION: Retrieving All of a Flow Run’s events may result in duplicate entries being logged in ClearSCADA’s Event Journal.

Select the OK button to confirm the request and retrieve the specified events.


SCADAPack Modbus RealFLO Driver Guide - Force Inputs (Using RealFLO Specific Actions)

Force Inputs

Associated with: SCADAPack Modbus Flow Runs

Security permission required to access this pick action: Override/Release

NOTE: To adjust the input values before changing a Dual Chamber Orifice Plate, use the Start Orifice Plate Change pick action, rather than the Force Inputs pick action.

To enable a Gas Flow Computer to continue to calculate gas flow data while any of its sensors are being calibrated, a Flow Run can be configured to use ‘forced’ values in its calculations. Once the sensors are calibrated, the flow calculations revert to using live values and the forced values are disabled.

You can ascertain the present values of a Flow Run’s Forced inputs by looking at the Forced Differential Pressure (or Forced Pulse Rate for AGA-7 calculations), Forced Static Pressure, and Forced Temperature attributes on the Flow Run’s Status Display (see SCADAPack Modbus Specific Status Display Attributes).

You can then use the Flow Run’s Force Inputs pick action to either force the inputs, or to remove existing forcing, as required. (When any sensors are being calibrated, use the Force Inputs pick action just before calibration, to change the inputs to Fixed Values. On completion of the calibration, use the Force Inputs pick action again, to revert the inputs back to using live Current Values.)

CAUTION

unexpected behavior of application

Ensure that the relevant sensors or registers are connected before using the Force Inputs pick action to end forcing and revert inputs back to live values.

If the live input values are provided by local registers but those registers are not connected beforehand, the input values will be undefined.

If the live input values are provided by sensors but those sensors are not connected beforehand, the Flow Computer will report communication lost. If supported by the version of RealFLO, the Flow Computer will then use the last known good value or the Default Value specified in the configuration. This might result in the flow calculation producing a different result to that which is expected.

Failure to follow these instructions can result in unexpected Flow Calculation results.

Select the Force Inputs pick action to display the Force Inputs window. The window displays the present state and value of each input on the Flow Run. The fields vary, depending on the type of Flow Calculation that the Flow Run performs (the Differential Pressure Forced State is replaced with Pulse Counter on Flow Run’s that perform AGA-7 Flow Calculations).

For each input, use the left-hand combo box to specify the type of input. Choose from:

  • Current Value—The input is fixed at the current live sensor value, which is displayed in the right-hand field. (The value shown in the right-hand field is for information only—if you want to specify a different value to that shown, use the left-hand combo box to specify a Fixed Value instead of a Current Value (see below).)
  • Fixed Value—The input is a fixed value. Use the right-hand field to specify the required input value.
  • Remove—Disables any forcing. The input reverts to its live sensor value.
  • No Change—The input is to continue as a live or fixed sensor value or a forced value (whichever presently applies).

For options other than Fixed Value, the values in the corresponding right-hand fields are displayed for information only—ClearSCADA ignores any changes that are made to such values.


SCADAPack Modbus RealFLO Driver Guide - Hourly Demand Poll (Using RealFLO Specific Actions)

Hourly Demand Poll

Associated with: SCADAPack Modbus Flow Runs

Security permission required to access this pick action: Retrieve Data

ClearSCADA automatically polls a controller for a Flow Run’s hourly historic data at the frequency that is specified using the Flow Run’s Hourly History Scan field (see Configure the Scanning Properties).

The Hourly Demand Poll pick action allows a Flow Run’s hourly historic data to be retrieved between scheduled Hourly History scans.

Select the pick action to display the Hourly Demand Poll window. Use the window’s Range field to specify the range of hourly historic data that the driver is to retrieve:

  • Most Recent—The driver retrieves any hourly history data that the Flow Run has generated at the controller, since the last item of hourly history data that is recorded for that Flow Run in ClearSCADA.
  • All—The driver retrieves all of the Flow Run’s hourly historic data.

ATTENTION: Use this option with care. Specifying that ClearSCADA is to retrieve All of a Flow Run’s hourly historic data could have an adverse affect on system performance, while ClearSCADA retrieves and processes up to 35 day’s worth of historic data.


SCADAPack Modbus RealFLO Driver Guide - Normalize (Using RealFLO Specific Actions)

Normalize

Associated with: SCADAPack Modbus Flow Runs that perform AGA-8 Compressibility Calculations

Security permission required to access this pick action: Configure

Use the Normalize pick action to check and, if required, have ClearSCADA adjust a Flow Run’s individual Gas Composition values so that they total 100% (if the values are displayed as a percentage), or 1 (if the values are displayed as a fraction).

When the Normalize pick action is triggered, ClearSCADA checks whether the total of the non-zero entries equates to the required total. If they do not, ClearSCADA adjusts each value comparatively. Therefore, if non-zero percentage values equate to more than 100, ClearSCADA will reduce each of those values by an appropriate amount in order that they equate to 100. Similarly, if non-zero percentage values equate to less than 100, ClearSCADA will increase each of those values by an appropriate amount in order that they equate to 100.

If a Flow Run’s Hexanes+ Ratios are set to Combined, the Normalize window is displayed when the Normalize pick action is selected. Use the window’s Type field to select whether to normalize the Gas Composition ratios and/or the Hexanes+ ratios:

  • Both—ClearSCADA will check whether the sums of the individual non-zero Gas Composition values, and the individual Hexanes+ values, each equate to the appropriate totals. If they do not, ClearSCADA will adjust the values appropriately.
  • Gas Ratios—ClearSCADA will check whether the sum of the individual non-zero Gas Composition values equate to 100% (if the values are displayed as a percentage), or 1 (if the values are displayed as a fraction). If they do not, ClearSCADA will adjust the values appropriately.
  • Hexanes+—ClearSCADA will check whether the sum of the individual non-zero Hexanes+ values equate to 100%. It will adjust the values appropriately if they do not. (Hexanes+ values are displayed as a percentage.)

NOTE: ClearSCADA displays a diagnostic message should any Flow Run configuration be saved that has Gas Composition and/or Hexanes+ values that do not equate to the required totals.

Example:

A Flow Run’s Gas Composition properties are configured as a percentage of the overall gas composition. They are configured to have the following values:

(The Flow Run’s other Gas Composition properties are set to zero.)

As the above Gas Composition values equate to 105%, ClearSCADA displays a diagnostic message when the configuration is saved.

The Normalize pick action is used to adjust the values so that they do equate to 100%. When the pick action is triggered, ClearSCADA adjusts each non-zero Gas Composition value by an appropriate amount. In this particular example, this results in the Flow Run having the following Gas Composition values:

Further Information

AGA-8 Gas Composition Properties.

AGA-8 Hexane Properties.


SCADAPack Modbus RealFLO Driver Guide - Orifice Plate Change (Using RealFLO Specific Actions)

Orifice Plate Change

Associated with: SCADAPack Modbus Flow Runs that perform AGA-3 Flow Calculations

Security permission required to access this pick action: Tune Limits

CAUTION

unexpected behavior of application

Execution of the Orifice Plate Change pick action automatically ends any currently active orifice plate change forcing on a Flow Run that has a dual chamber orifice plate. Ensure that the relevant sensors or registers are connected before activating this pick action.

If the live input values are provided by local registers but those registers are not connected beforehand, the input values will be undefined.

If the live input values are provided by sensors but those sensors are not connected beforehand, the Flow Computer will report communication lost. If supported by the version of RealFLO, the Flow Computer will then use the last known good value or the Default Value specified in the configuration. This might result in the flow calculation producing a different result to that which is expected.

Failure to follow these instructions can result in unexpected Flow Calculation results.

Use the Orifice Plate Change pick action once an orifice plate change is complete, to specify the diameter of the new plate.

During a single chamber (see AGA-3 General Properties) orifice plate change, flow stops while the plate is being changed, then recommences once the Orifice Plate Change pick action has executed successfully.

With a dual chamber (see AGA-3 General Properties) orifice plate change, before an orifice plate change or inspection commences, use the Start Orifice Plate Change pick action to specify the forcing that is required during the plate change or inspection. Flow calculation continues while the plate is being changed or inspected, using the fixed values specified using the Start Orifice Plate Change pick action. Once the orifice plate has been changed or the inspection has been completed, use the Orifice Plate Change pick action to complete the process—the Flow Run resumes its normal flow measurements.

With either type of orifice plate, select the Orifice Plate Change pick action to display the Orifice Plate Change window:

Use the New Plate Diameter field to specify the diameter of the new orifice plate.


SCADAPack Modbus RealFLO Driver Guide - Read Configuration (Using RealFLO Specific Actions)

Read Configuration

Associated with: SCADAPack Modbus Flow Runs

Security permission required to access this pick action: Configure

CAUTION

unexpected behavior of application

Use the Read Configuration action with care. The action will overwrite the configuration on a Flow Run’s Flow Run, Compressibility Calculation, and Flow Calculation tabs, other than the Basic Flow Run properties and the Scanning properties (both configured on the Flow Run tab).

Failure to follow these instructions can result in unexpected configuration changes.

When a Flow Run is added to the ClearSCADA database, basic settings, such as the controller with which the Flow Run is associated, have to be specified on the Flow Run Form (see Preparation and Minimum Configuration). You can then either specify the rest of a Flow Run’s configuration in ClearSCADA, or have the driver read (‘upload’) the majority of an existing Flow Run’s configuration from the controller into ClearSCADA (see Configure or Read the Flow Run Configuration).

In order to read the configuration from an existing Flow Run into ClearSCADA:

  • The controller on which the Flow Run is located has to be a Gas Flow Computer that is running a supported version of RealFLO™
  • If the Flow Run is in an Instance of a Group Template, ensure that the appropriate Property Overrides are enabled to allow the configuration to be read into ClearSCADA successfully (see Define which Property Values Derive from a Group Template in the ClearSCADA Guide to Core Configuration). Flow Run properties that have to have their property overrides enabled in the Group Template comprise:
  • Each of the properties on the Compressibility Calculation tab
  • Each of the properties on the Flow Calculation tab
  • The properties within these sections of the Flow Run tab:
  • Inputs
  • Static Pressure
  • Temperature
  • Contract.

The property overrides for each of the above properties are enabled by default. Should an attempt be made to Read Configuration while one of more of the above properties does not have its property overrides enabled, the request for that Flow Run will be unsuccessful. Should this occur, ClearSCADA will log a separate message in the Event Journal for each of the Flow Run’s tabs on which the necessary property overrides are not enabled. Each message will list those properties for which the property override still needs enabling in order for ClearSCADA to read the configuration successfully.

If you specify that ClearSCADA is to read the majority of a Flow Run’s configuration from a controller, ClearSCADA will automatically scan the RealFLO controller for Flow Run configuration, at the frequency specified in the Scanning section of the Flow Run Form (see Configure the Scanning Properties). This Flow Run Configuration Scan is a ‘fall back’ measure, to confirm that a Flow Run’s configuration data remains up to date in the ClearSCADA database. Should a read occur while a Flow Run’s configuration Form is open and an attempt be made to save any user-instigated configuration changes to that Flow Run after the read is complete, a diagnostic message will be displayed. The message will indicate that the Flow Run’s configuration has changed on the server since the Form was opened. Options are provided to discard the user-instigated changes or overwrite the server’s Flow Run configuration with those changes.

If changes are made to such a Flow Run’s configuration and the next scheduled Flow Run Configuration Scan is not imminent, use the Read Configuration pick action to read that configuration into ClearSCADA.

Also see Write Configuration.


SCADAPack Modbus RealFLO Driver Guide - Set Clock (Using RealFLO Specific Actions)

Set Clock

Associated with: SCADAPack RealFLO controllers

Security permission required to access this pick action: Control

Use the Set Clock pick action to manually set the clock on a RealFLO-enabled SCADAPack controller, if that clock’s time has drifted significantly.

Be aware that when a controller’s clock is set using the RealFLO method (as per this pick action), the controller logs an event and restarts its current Hour log.

(ClearSCADA can be configured to automatically set a controller’s RealFLO clock whenever the clock drifts by more than a specified amount—for more information, see Specify Whether a Set Broadcasts Set Clock Messages, and see Define the Set Clock Method.)


SCADAPack Modbus RealFLO Driver Guide - Start Orifice Plate Change (Using RealFLO Specific Actions)

Start Orifice Plate Change

Associated with: SCADAPack Modbus Flow Runs that perform AGA-3 Flow Calculations and have a Dual Chamber Orifice

Security permission required to access this pick action: Tune Limits

Select this pick action when a Dual Chamber orifice plate (see AGA-3 General Properties) is about to be changed or inspected. The pick action forces the Flow Run’s calculations to use estimated fixed input values during the time period within which the plate change or inspection is due to take place. Once the timeout for that period elapses, the Flow Run resumes its normal flow measurements.

CAUTION

Unexpected behavior of application

Ensure that the relevant sensors or registers are connected before forcing ends and the inputs revert back to live values.

If the live input values are provided by local registers but those registers are not connected beforehand, the input values will be undefined.

If the live input values are provided by sensors but those sensors are not connected beforehand, the Flow Computer will report communication lost. If supported by the version of RealFLO, the Flow Computer will then use the last known good value or the Default Value specified in the configuration. This might result in the flow calculation producing a different result to that which is expected.

Failure to follow these instructions can result in unexpected Flow Calculation results.

Select the Start Orifice Plate Change pick action to display the Start Orifice Plate Change window. Use the window’s fields to specify the required forced values of the Flow Calculation’s inputs and the timeout by which the plate change or inspection needs to have taken place:

For each of the three inputs, use the left-hand combo box to specify the type of input that the Flow Run is to use while the orifice plate change or inspection take place.

Choose from:

  • Current Value—The input is fixed at the current live sensor value, which is displayed in the right-hand field. (The value shown in the right-hand field is for information only—if you want to specify a different value to that shown, use the left-hand combo box to specify a Fixed Value instead of a Current Value (see below).)
  • Fixed Value—The input is a fixed value. Use the right-hand field to specify the required input value.

Use the Timeout field to specify the time by which the plate change or inspection needs to have taken place. Specify the required timeout in the OPC Time Format. You can either overtype the existing entry, or use the Interval Window (accessed via the field’s browse button) to specify the required value. Once this timeout elapses, any forcing ends and the Flow Run reverts back to using live sensor values.

Once the physical plate has been changed, use the Orifice Plate Change pick action to specify the diameter of the new orifice plate.

NOTE: To force the input values for any other reason, use the Force Inputs pick action, rather than the Start Orifice Plate Change pick action.
For information on changing a Single Chamber orifice plate, see Orifice Plate Change.

If required, you can use the Abort Orifice Plate Change pick action to abort an orifice plate change or inspection.

The Flow Run’s Abort Orifice Plate Change status attribute indicates whether the last attempt to change or inspect the orifice plate was aborted due to a timeout in the driver.


SCADAPack Modbus RealFLO Driver Guide - Write Configuration (Using RealFLO Specific Actions)

Write Configuration

Associated with: SCADAPack Modbus Flow Runs

Security permission required to access this pick action: Configure

When a Flow Run is added to the ClearSCADA database, basic settings, such as the controller with which the Flow Run is associated, have to be specified on the Flow Run Form (see Preparation and Minimum Configuration). You can then either specify the rest of a Flow Run’s configuration in ClearSCADA, or have the driver read the majority of an existing Flow Run’s configuration from the controller into ClearSCADA (see Configure or Read the Flow Run Configuration).

If you specify the rest of a Flow Run’s configuration in ClearSCADA, you need to write that configuration to the relevant RealFLO controller. In order to do this successfully, ensure that the Flow Run(s) have valid, saved configuration and are In Service (if they are to function online)—for more information, see Mandatory Configuration and Invalid Configuration Messages in the ClearSCADA Guide to Core Configuration. Then use the Write Configuration pick action to write (‘download’) that configuration to the RealFLO controller on which the Flow Run is located.

Also see Read Configuration.


SCADAPack Modbus RealFLO Driver Guide - RealFLO Specific Status Display Attributes

RealFLO Specific Status Display Attributes

This section explains those status attributes that are SCADAPack Modbus RealFLO-specific and comprises the following sections:

  • SCADAPack Modbus RealFLO Controller Status Attributes
  • SCADAPack Modbus Flow Run Status Attributes
  • Alphabetical List of SCADAPack Modbus RealFLO Status Display Attributes.

Use the sections in conjunction with the SCADAPack Modbus driver documentation on status display attributes (see SCADAPack Modbus Specific Status Display Attributes in the ClearSCADA Guide to the SCADAPack Modbus Driver).


SCADAPack Modbus RealFLO Driver Guide - SCADAPack Modbus RealFLO Controller Status Attributes (RealFLO Specific Status Display Attributes)

SCADAPack Modbus RealFLO Controller Status Attributes

In addition to SCADAPack Modbus Controller Status Attributes, RealFLO-enabled SCADAPack controllers support the following RealFLO-specific status attributes:

  • Real Time Clock Errors
  • Application Identifier—controllers running RealFLO 6.70 or later
  • Gas Flow Application Number
  • Gas Flow Application Build Number
  • Maximum Gas Flow Runs Available
  • User Number.


SCADAPack Modbus RealFLO Driver Guide - SCADAPack Modbus Flow Run Status Attributes (RealFLO Specific Status Display Attributes)

SCADAPack Modbus Flow Run Status Attributes

SCADAPack Modbus Flow Runs support these RealFLO-specific status attributes:

  • Write Configuration Failed
  • Read Configuration Failed
  • Abort Orifice Plate Change—AGA-3/Dual Chamber Orifice only
  • Current Data Last Updated
  • Meter Run
  • Execution State
  • Calibration Flags
  • Compressibility Approximated Flag
  • Temperature Input Alarm
  • Static Pressure Alarm
  • Forced Temperature
  • Forced Static Pressure
  • Compressibility Calculation Error Code
  • Compressibility Calculation Update Time
  • Flow Calculation Error Code
  • Flow Calculation Update Time
  • Number of Flow Calculations in Current Contract Day
  • Number of Flow Calculations in Previous Contract Day
  • Flow Time This Contract Day
  • Flow Time Previous Contract Day
  • Flow Time This Month
  • Flow Time Last Month
  • Uncorrected Flow Volume Today
  • Uncorrected Flow Volume Yesterday
  • Uncorrected Flow Volume This Month
  • Uncorrected Flow Volume Last Month
  • Time of Last Flow Configuration Change
  • Time of Last Density Configuration Change
  • Turbine Pulses Input Alarm—AGA-7 only
  • Forced Pulse Rate—AGA-7 only
  • Uncorrected Flow Volume
  • Differential Pressure Alarm
  • Forced Differential Pressure—AGA-3 and V-Cone only
  • Flow Product—AGA-3 (1985) only
  • Flow Extension.


SCADAPack Modbus RealFLO Driver Guide - Alphabetical List of SCADAPack Modbus RealFLO Status Display Attributes (RealFLO Specific Status Display Attributes)

Alphabetical List of SCADAPack Modbus RealFLO Status Display Attributes

This section lists those status attributes that are specific to items on the SCADAPack Modbus RealFLO driver. These are in addition to the status attributes supported by the SCADAPack Modbus driver itself (see SCADAPack Modbus Specific Status Display Attributes in the ClearSCADA Guide to the SCADAPack Modbus Driver).

The attributes are listed in alphabetical order and comprise:

  • Abort Orifice Plate Change
  • Application Identifier
  • Calibration Flags
  • Compressibility Approximated Flag
  • Compressibility Calculation Error Code
  • Compressibility Calculation Update Time
  • Current Data Last Updated
  • Differential Pressure Alarm
  • Execution State
  • Flow Calculation Error Code
  • Flow Calculation Update Time
  • Flow Extension
  • Flow Product
  • Flow Time Last Month
  • Flow Time Previous Contract Day
  • Flow Time This Contract Day
  • Flow Time This Month
  • Forced Differential Pressure
  • Forced Pulse Rate
  • Forced Static Pressure
  • Forced Temperature
  • Gas Flow Application Build Number
  • Gas Flow Application Number
  • Maximum Gas Flow Runs Available
  • Meter Run
  • Number of Flow Calculations in Current Contract Day
  • Number of Flow Calculations in Previous Contract Day
  • Read Configuration Failed
  • Real Time Clock Errors
  • Static Pressure Alarm
  • Temperature Input Alarm
  • Time of Last Density Configuration Change
  • Time of Last Flow Configuration Change
  • Turbine Pulses Input Alarm
  • Uncorrected Flow Volume
  • Uncorrected Flow Volume Last Month
  • Uncorrected Flow Volume This Month
  • Uncorrected Flow Volume Today
  • Uncorrected Flow Volume Yesterday
  • User Number
  • Write Configuration Failed.


SCADAPack Modbus RealFLO Driver Guide - Abort Orifice Plate Change (RealFLO Specific Status Display Attributes)

Abort Orifice Plate Change

Associated with: Flow Runs that perform AGA-3 Flow Calculations and have a Dual Chamber Orifice

This attribute indicates whether the last attempt to change or inspect the orifice plate was aborted due to a timeout in the driver.

When a dual chamber orifice plate is about to be changed or inspected, the Start Orifice Plate Change pick action is used to force the Flow Run’s calculations to use estimated input values. The pick action is also used to specify the time period within which the orifice plate change or inspection have to be completed. If neither the Orifice Plate Change or Abort Orifice Plate Change pick actions are executed by the time that this timeout elapses, the driver raises an alarm and sets the Abort Orifice Plate Change status attribute to an alarm state.

Possible States: Displays one of the Standard Alarm States.

If this status attribute displays an alarm state, use the Events or Alarms List to ascertain further details about the aborted orifice plate change or inspection.


SCADAPack Modbus RealFLO Driver Guide - Application Identifier (RealFLO Specific Status Display Attributes)

Application Identifier

Associated with: RealFLO controllers that are running RealFLO 6.70 or later

This attribute identifies the RealFLO application that is currently running in the controller.

Application identifiers are supported by RealFLO version 6.70 onwards. The attribute is not displayed for controllers running versions of RealFLO in which the application identifier is undefined.

Example:

SCADAPack 350 TelePACE


SCADAPack Modbus RealFLO Driver Guide - Calibration Flags (RealFLO Specific Status Display Attributes)

Calibration Flags

Associated with: Flow runs

This attribute displays the present calibration flags of the Flow Run. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

0


SCADAPack Modbus RealFLO Driver Guide - Compressibility Approximated Flag (RealFLO Specific Status Display Attributes)

Compressibility Approximated Flag

Associated with: Flow runs

This attribute displays the compressibility flag that presently applies to the Flow Run. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Possible States:

  • Compressibility value is calculated result
    (Displayed when the flag is not set (reads 0))
  • Compressibility value is approximate
    (Displayed when the flag is set (reads 1))


SCADAPack Modbus RealFLO Driver Guide - Compressibility Calculation Error Code (RealFLO Specific Status Display Attributes)

Compressibility Calculation Error Code

Associated with: Flow runs

This attribute indicates whether the Flow Run’s Compressibility Calculation has generated an error. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller. Information is displayed in this format:

<Error Code>:<Description>

where 0: No error indicates that the calculation has recalculated successfully. If an error has occurred, a 5-digit error code and corresponding description is displayed.

Example:

20002: Inputs have not been configured

For a list of compressibility calculation error codes and their corresponding descriptions, see the documentation provided with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Compressibility Calculation Update Time (RealFLO Specific Status Display Attributes)

Compressibility Calculation Update Time

Associated with: Flow runs

This attribute indicates the date and time of the latest compressibility calculation data to be retrieved from the Gas Flow Computer. The data is time stamped at the Gas Flow Computer before being retrieved by ClearSCADA. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

07/Jun/2006 08:42:01.000


SCADAPack Modbus RealFLO Driver Guide - Current Data Last Updated (RealFLO Specific Status Display Attributes)

Current Data Last Updated

Associated with: Flow runs

This attribute indicates the date and time that ClearSCADA last updated the Flow Run’s current data. ClearSCADA applies the time stamp when it updates the data in its database. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

07/Jun/2006 08:42:00.314


SCADAPack Modbus RealFLO Driver Guide - Differential Pressure Alarm (RealFLO Specific Status Display Attributes)

Differential Pressure Alarm

Associated with: Flow runs

This attribute indicates that the Differential Pressure is in alarm and displays the value of that Differential Pressure. The attribute is displayed once the Instantaneous and Accumulated Readings Registers are read from the Flow Computer. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

9.065
(for a value in kPa)


SCADAPack Modbus RealFLO Driver Guide - Execution State (RealFLO Specific Status Display Attributes)

Execution State

Associated with: Flow runs

This attribute indicates the present execution state of the Flow Run’s calculations. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Possible States:

  • Not Set
    (The Flow Run has never executed. This state typically applies to newly configured Flow Runs that have not yet been put into service.)
  • Stopped
    (The Flow Run’s calculations have stopped running in the Gas Flow Computer.)
  • Running
    (The Flow Run’s calculations are running at the Gas Flow Computer, and the Flow Run’s current readings are being updated.)


SCADAPack Modbus RealFLO Driver Guide - Flow Calculation Error Code (RealFLO Specific Status Display Attributes)

Flow Calculation Error Code

Associated with: Flow runs

This attribute indicates whether the Flow calculation has generated an error. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller. Information is displayed in this format:

<Error Code>: <Description>

where 0: No error indicates that the calculation has recalculated successfully. If an error has occurred, a 5-digit error code and corresponding description is displayed.

Example:

20817: AGA8 - Not running

For a list of Flow calculation error codes and their corresponding descriptions, see the documentation provided with the RealFLO application.


SCADAPack Modbus RealFLO Driver Guide - Flow Calculation Update Time (RealFLO Specific Status Display Attributes)

Flow Calculation Update Time

Associated with: Flow runs

This attribute indicates the date and time of the latest flow calculation data to be retrieved from the Gas Flow Computer. The data is time stamped at the Gas Flow Computer before being retrieved by ClearSCADA. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

07/Jun/2006 08:41:58.000


SCADAPack Modbus RealFLO Driver Guide - Flow Extension (RealFLO Specific Status Display Attributes)

Flow Extension

Associated with: Flow runs

A Flow Extension is an intermediate value that is derived from a flow calculation. Flow editing software uses the Flow Extension value in its re-calculations if an incorrect measurement is made (for example, if communications is lost with a flow computer, but the flow is still running properly). The Flow Extension attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller. The displayed value is in kg/m3s.

Example:

1695.78


SCADAPack Modbus RealFLO Driver Guide - Flow Product (RealFLO Specific Status Display Attributes)

Flow Product

Associated with: Flow runs that perform AGA-3 (1985) flow calculations

This attribute displays the average Flow Product value (AGA-3 (1985) only) for the period.

Example:

3.02


SCADAPack Modbus RealFLO Driver Guide - Flow Time Last Month (RealFLO Specific Status Display Attributes)

Flow Time Last Month

Associated with: Flow runs

This attribute indicates the total amount of time that the Flow Run ran and calculated gas flow data, during the previous month. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

4W2D23H59M51.75S
(for a Flow Run that was running for 4 weeks, 2 days, 23 hours, 59 minutes, and 51.75 seconds during the last month)


SCADAPack Modbus RealFLO Driver Guide - Flow Time Previous Contract Day (RealFLO Specific Status Display Attributes)

Flow Time Previous Contract Day

Associated with: Flow runs

This attribute indicates the total running time of the Flow Run, during the previous contract day. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

1D
(for a Flow Run that ran for the whole of the previous contract day)


SCADAPack Modbus RealFLO Driver Guide - Flow Time This Contract Day (RealFLO Specific Status Display Attributes)

Flow Time This Contract Day

Associated with: Flow runs

This attribute indicates the amount of time that the Flow Run has been running so far, during this present contract day. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

07H52M17.39S
(for a Flow Run that has been running for 7 hours, 52 minutes, and 17.39 seconds on this contract day)


SCADAPack Modbus RealFLO Driver Guide - Flow Time This Month (RealFLO Specific Status Display Attributes)

Flow Time This Month

Associated with: Flow runs

This attribute indicates the amount of time that the Flow Run has run and calculated gas flow data so far, this month. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

1W6H31M5.562S
(for a Flow Run that has been running for 1 week, 6 hours, 31 minutes, and 5.562 seconds this month)


SCADAPack Modbus RealFLO Driver Guide - Forced Differential Pressure (RealFLO Specific Status Display Attributes)

Forced Differential Pressure

Associated with: Flow runs that perform AGA-3 or V-Cone flow calculations

To enable a Gas Flow Computer to continue to calculate gas flow data while any of its sensors are being calibrated, a Flow Run can be configured to use ‘forced’ values in its calculations. Once the sensors are calibrated, the flow calculations revert to using live values and the forced values are disabled.

This attribute indicates the forced differential pressure that is presently being used in the Flow Run’s flow calculations. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

4.05246
(for a value in kPa)


SCADAPack Modbus RealFLO Driver Guide - Forced Pulse Rate (RealFLO Specific Status Display Attributes)

Forced Pulse Rate

Associated with: Flow runs that perform AGA-7 flow calculations

To enable a Gas Flow Computer to continue to calculate gas flow data while any of its sensors are being calibrated, a Flow Run can be configured to use ‘forced’ values in its calculations. Once the sensors are calibrated, the flow calculations revert to using live values and the forced values are disabled.

This attribute indicates the forced pulse rate that is presently being used in the Flow Run’s flow calculations. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

22


SCADAPack Modbus RealFLO Driver Guide - Forced Static Pressure (RealFLO Specific Status Display Attributes)

Forced Static Pressure

Associated with: Flow runs

To enable a Gas Flow Computer to continue to calculate gas flow data while any of its sensors are being calibrated, a Flow Run can be configured to use ‘forced’ values in its calculations. Once the sensors are calibrated, the flow calculations revert to using live values and the forced values are disabled.

This attribute indicates the forced static pressure that is presently being used in the Flow Run’s flow calculations. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

15.1657
(for a value in KPa)


SCADAPack Modbus RealFLO Driver Guide - Forced Temperature (RealFLO Specific Status Display Attributes)

Forced Temperature

Associated with: Flow runs

To enable a Gas Flow Computer to continue to calculate gas flow data while any of its sensors are being calibrated, a Flow Run can be configured to use ‘forced’ values in its calculations. Once the sensors are calibrated, the flow calculations revert to using live values and the forced values are disabled.

This attribute indicates the forced temperature that is presently being used in the Flow Run’s flow calculations. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

23.87
(for a temperature in degrees Celsius)


SCADAPack Modbus RealFLO Driver Guide - Gas Flow Application Build Number (RealFLO Specific Status Display Attributes)

Gas Flow Application Build Number

Associated with: RealFLO controllers

This attribute indicates the build number of the Gas Flow application that is running on the controller. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

5


SCADAPack Modbus RealFLO Driver Guide - Gas Flow Application Number (RealFLO Specific Status Display Attributes)

Gas Flow Application Number

Associated with: RealFLO controllers

This attribute indicates the version of the Gas Flow application that is running on the controller. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

6.01


SCADAPack Modbus RealFLO Driver Guide - Maximum Gas Flow Runs Available (RealFLO Specific Status Display Attributes)

Maximum Gas Flow Runs Available

Associated with: RealFLO controllers

This attribute indicates the maximum number of Flow Runs that the controller can support. The number is limited by the controller hardware and the RealFLO license. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

2


SCADAPack Modbus RealFLO Driver Guide - Meter Run (RealFLO Specific Status Display Attributes)

Meter Run

Associated with: Flow runs

This attribute indicates the Flow Run number of the present meter run. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

1


SCADAPack Modbus RealFLO Driver Guide - Number of Flow Calculations in Current Contract Day (RealFLO Specific Status Display Attributes)

Number of Flow Calculations in Current Contract Day

Associated with: Flow runs

This attribute indicates the number of flow calculations that have occurred so far, during the present contract day. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

14175


SCADAPack Modbus RealFLO Driver Guide - Number of Flow Calculations in Previous Contract Day (RealFLO Specific Status Display Attributes)

Number of Flow Calculations in Previous Contract Day

Associated with: Flow runs

This attribute indicates the total number of flow calculations that occurred during the previous contract day. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

43221


SCADAPack Modbus RealFLO Driver Guide - Read Configuration Failed (RealFLO Specific Status Display Attributes)

Read Configuration Failed

Associated with: Flow Runs

This attribute indicates whether ClearSCADA’s last attempt to read the Flow Run’s configuration into the ClearSCADA database was unsuccessful.

The Flow Run’s configuration is read using the Read Configuration pick action.

Possible States: Displays one of the Standard Alarm States.


SCADAPack Modbus RealFLO Driver Guide - Real Time Clock Errors (RealFLO Specific Status Display Attributes)

Real Time Clock Errors

Associated with: RealFLO controllers

This attribute indicates whether any of the following abnormal conditions have occurred:

  • The controller’s time has drifted significantly from the system time (the acceptable time drift is specified at the server—see Define the Acceptable Controller Clock Drift).
  • The server’s last attempt to broadcast its Set Clock message (to set the clock at the controller) was unsuccessful.
  • The server’s last attempt to set the controller’s clock directly was unsuccessful.

Possible States: Displays one of the Standard Alarm States.


SCADAPack Modbus RealFLO Driver Guide - Static Pressure Alarm (RealFLO Specific Status Display Attributes)

Static Pressure Alarm

Associated with: Flow runs

This attribute indicates that the Static Pressure is in alarm and displays the value of that Static Pressure. The attribute is displayed once the Instantaneous and Accumulated Readings Registers are read from the Flow Computer. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

25.323
(for a value in kPa)


SCADAPack Modbus RealFLO Driver Guide - Temperature Input Alarm (RealFLO Specific Status Display Attributes)

Temperature Input Alarm

Associated with: Flow runs

This attribute indicates that the Temperature is in alarm and displays the value of that Temperature. The attribute is displayed once the Instantaneous and Accumulated Readings Registers are read from the Flow Computer. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

98.23
(for a temperature in degrees Celsius)


SCADAPack Modbus RealFLO Driver Guide - Time of Last Density Configuration Change (RealFLO Specific Status Display Attributes)

Time of Last Density Configuration Change

Associated with: Flow runs

This attribute indicates the date and time of the latest density configuration parameters to be retrieved from the Gas Flow Computer. The updated configuration is time stamped at the Gas Flow Computer before being retrieved by ClearSCADA. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

07/Jun/2006 08:05:02.000


SCADAPack Modbus RealFLO Driver Guide - Time of Last Flow Configuration Change (RealFLO Specific Status Display Attributes)

Time of Last Flow Configuration Change

Associated with: Flow runs

This attribute indicates the date and time of the latest flow configuration parameters to be retrieved from the Gas Flow Computer. The updated configuration is time stamped at the Gas Flow Computer before being retrieved by ClearSCADA. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller.

Example:

07/Jun/2006 08:40:08.000


SCADAPack Modbus RealFLO Driver Guide - Turbine Pulses Input Alarm (RealFLO Specific Status Display Attributes)

Turbine Pulses Input Alarm

Associated with: Flow runs that perform AGA-7 flow calculations

This attribute indicates the status of the instantaneous Turbine Pulses Input Alarm. This alarm goes true when the Turbine Pulses Input drops below the Low Flow Pulse Limit, or when the pulses are not detected for a period of time longer than the Low Flow Detect Time. (Both of these parameters are defined on the Flow Calculation tab of the Flow Run Form—see AGA-7 Turbine Properties.)

Example:

1


SCADAPack Modbus RealFLO Driver Guide - Uncorrected Flow Volume (RealFLO Specific Status Display Attributes)

Uncorrected Flow Volume

Associated with: Flow runs

This attribute indicates the total uncorrected gas flow volume that the Flow Run has calculated for the period. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller, if that Flow Run performs AGA-7 Flow Calculations. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

353.2


SCADAPack Modbus RealFLO Driver Guide - Uncorrected Flow Volume Last Month (RealFLO Specific Status Display Attributes)

Uncorrected Flow Volume Last Month

Associated with: Flow runs

This attribute indicates the total uncorrected gas flow volume that the Flow Run calculated last month. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller, if that Flow Run performs AGA-7 Flow Calculations. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

22.311
(for uncorrected gas flow volume in E3m3 (or 103m3))


SCADAPack Modbus RealFLO Driver Guide - Uncorrected Flow Volume This Month (RealFLO Specific Status Display Attributes)

Uncorrected Flow Volume This Month

Associated with: Flow runs

This attribute indicates the uncorrected gas flow volume so far, this month. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller, if that Flow Run performs AGA-7 Flow Calculations. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

24.213
(for uncorrected gas flow volume in E3m3 (or 103m3))


SCADAPack Modbus RealFLO Driver Guide - Uncorrected Flow Volume Today (RealFLO Specific Status Display Attributes)

Uncorrected Flow Volume Today

Associated with: Flow runs

This attribute indicates the uncorrected gas flow volume so far, during the present contract day. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller, if that Flow Run performs AGA-7 Flow Calculations. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

12.45
(for uncorrected gas flow volume in E3m3 (or 103m3))


SCADAPack Modbus RealFLO Driver Guide - Uncorrected Flow Volume Yesterday (RealFLO Specific Status Display Attributes)

Uncorrected Flow Volume Yesterday

Associated with: Flow runs

This attribute indicates the total uncorrected gas flow volume during the previous contract day. The attribute is displayed once the server has retrieved Flow Run data from a RealFLO-enabled SCADAPack controller, if that Flow Run performs AGA-7 Flow Calculations. The units that apply to the attribute depend on the Measurement Units system being used for the Flow Run’s Contract Units.

Example:

11.23
(for uncorrected gas flow volume in E3m3 (or 103m3))


SCADAPack Modbus RealFLO Driver Guide - User Number (RealFLO Specific Status Display Attributes)

User Number

Associated with: RealFLO controllers

This attribute displays the User Number that is associated with the controller’s User ID name. (The User ID is defined on the RealFLO tab of the controller’s configuration Form—see Specify the User ID and Passcode that Allow Access to the RealFLO Components.) The attribute is displayed once a controller is or has been in communication with the server.

Example:

1


SCADAPack Modbus RealFLO Driver Guide - Write Configuration Failed (RealFLO Specific Status Display Attributes)

Write Configuration Failed

Associated with: Flow runs

This attribute indicates whether ClearSCADA’s last attempt to write the Flow Run’s configuration to the RealFLO controller was unsuccessful.

Configuration is written to a RealFLO controller using the Write Configuration pick action.

Possible States: Displays one of the Standard Alarm States.


Crystal Reports Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Crystal Reports Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Crystal Reports Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Crystal Reports Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Crystal Reports Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Crystal Reports Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains the configuration and features associated with ClearSCADA’s Crystal Reports driver. The Crystal Reports driver enables ClearSCADA to interface with the third-party Crystal Reports™ application to produce professional reports that contain information obtained from the ClearSCADA database.

You can use the Crystal Reports driver to enable ClearSCADA to interface with either Crystal Reports version XI release 2 or Crystal Reports version 2008 (also known as SAP Crystal Reports).

For more information on the subjects included in this guide, see Introduction to Using Crystal Reports with ClearSCADA.


Crystal Reports Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for:

  • Engineers who are responsible for:
  • Configuring ClearSCADA to interface with the third-party Crystal Reports™ application
  • Using the third-party Crystal Reports™ application to produce reports that contain ClearSCADA data.

(Such engineers are expected to have the appropriate experience or knowledge of the Crystal Reports™ application.)

  • Operators and engineers who work with the reports that contain ClearSCADA data
  • System administrators who are investigating unexpected conditions related to the Crystal Reports driver.


Crystal Reports Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Crystal Reports Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Mimics

ClearSCADA Guide to Logic

ClearSCADA Guide to Security

ClearSCADA Guide to the Database

ClearSCADA Guide to Server Administration

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to Client Administration

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Lists.


Crystal Reports Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Crystal Reports Driver Guide - Introduction to Using Crystal Reports with ClearSCADA

Introduction to Using Crystal Reports with ClearSCADA

Crystal ReportsTM is a third-party application that can be used in conjunction with ClearSCADA to produce professional reports that contain information obtained from the ClearSCADA database.

Crystal Reports is a powerful application that allows you to structure reports to your requirements. You can then generate and display your reports, print your reports out, or export your reports to a variety of formats and destinations. For instance, you might want to transfer your reports to disk, or export reports in Adobe AcrobatTM format and send them via e-mail to a system engineer or manager.

Use Crystal Reports to produce a ‘snap-shot’ of the data on your system. Use ClearSCADA displays such as Lists, Mimics, and Trend Graphs to access up-to-date ‘live’ data on your system.

Much of the structure and layout of a report is performed using the Crystal Reports application. As such, we advise that any reports or report templates are produced by engineers that have the appropriate experience or knowledge of the Crystal Reports application.

The ClearSCADA Guide to the Crystal Reports Driver explains the ClearSCADA interface to the Crystal Reports application and the ClearSCADA specific features related to producing reports. You can use the ClearSCADA Crystal Reports driver to interface with either Crystal Reports version XI release 2 or Crystal Reports version 2008 (also known as SAP Crystal Reports). For more information on each version of Crystal Reports and the editions that ClearSCADA supports, see Installation on ViewX Clients on Which You Want to Edit Reports.

This document explains how to:

  • Install Crystal Reports
  • Plan Your Reports
  • Configure Your Reports (taking into account the Important Guidelines on Configuring and Generating Reports)
  • Trigger Your Reports Automatically (see Activating a Report Action Automatically).

It also explains:

  • Driver-specific aspects that are of interest to operators, including:
  • Using Actions Associated with Crystal Reports
  • Using the Crystal Reports Viewer
  • Working with the Reports List.
  • Driver-specific aspects that may be of interest to system administrators and engineers when investigating unexpected behavior relating to the Crystal Reports driver. The driver-specific aspects include:
  • Crystal Reports Specific Status Display Attributes
  • Crystal Reports Specific Colors
  • Crystal Reports Specific Driver Log File Options
  • Troubleshooting.

For information on using the Crystal Reports software or writing formulae to produce the reports you require, see the documentation supplied with the Crystal Reports application.


Crystal Reports Driver Guide - Install Crystal Reports (Introduction to Using Crystal Reports with ClearSCADA)

Install Crystal Reports

On a typical ClearSCADA system, you create your reports on one or more ClearSCADA clients and then store those reports on the ClearSCADA server.

You can produce reports using ClearSCADA’s Crystal Reports feature, but only after the correct components have been installed on your system.

The procedure for installing the components varies, depending on whether you are installing software on a server or a client:

  • Server Installation
  • Installation on ViewX Clients on Which You Want to Edit Reports
  • Installation on Clients on Which You Only Want to Display or Print or Export Reports.


Crystal Reports Driver Guide - Server Installation (Introduction to Using Crystal Reports with ClearSCADA)

Server Installation

ATTENTION: If you want to edit Crystal Reports on a server that also acts as a client, you will need to install the Crystal Reports software and service pack. These need to be installed on the server before you install ClearSCADA. To install Crystal Reports and the service pack on a server-client, complete steps 1 and 2 of Installation on ViewX Clients on Which You Want to Edit Reports before performing the steps provided below.

On each server in your system (with the exception of permanent standby servers), you need to:

  1. Install the ClearSCADA software, including the relevant Crystal Reports Server and ViewX Client components, and the Data Access component (which includes ODBC).
  2. Set up the required ViewX client connections to the server. For information, see:
  • Crystal Reports Installation on ViewX Clients on Which You Want to Edit Reports
  • Crystal Reports Installation on Clients on Which You Only Want to Display or Print or Export Reports
  • ViewX Client - System Connections in the ClearSCADA Guide to Client Administration.
  3. Add an ODBC Data Source Name (DSN) for the ClearSCADA driver, to allow Crystal Reports to access the ClearSCADA database. You add the DSN using the ODBC Data Source Administrator Tool. You can access the Tool from the Crystal Reports section of the ClearSCADA Server Configuration Tool (see Configuring Crystal Reports Server Settings). Crystal Reports uses the DSN to access the relevant database whenever you generate, print, or export a report using the Generate Report, Print Report, or Export Report pick actions.

The DSN has to be an ODBC System DSN.

On a computer running a 64-bit version of Windows®, the DSN has to be a 32-bit ODBC System DSN (as Crystal Reports is a 32-bit application).

We advise that the same System DSN name is used throughout your system. That is, that the System DSN has the same name on both the client(s) on which the reports are to be created, and on the server(s) that will be used to generate those reports. This applies even if you are only going to access the Local Database with Crystal Reports. (The Local Database is the ClearSCADA database that contains the report.)

NOTE: On machines running 32-bit versions of Windows®, you can also access the ODBC Data Source Administrator Tool from the Control Panel on your PC. On machines running 64-bit versions of Windows®, you need to run the 32-bit version of the ODBC Data Source Administrator Tool. To do this, run the Odbcad32.exe file that is located in the %windir%\SysWoW64 folder.

For more information on setting up an ODBC DSN, see Configure a Third Party ODBC Client - System Connection in the ClearSCADA Guide to Client Administration.

  4. Use the Crystal Reports section of the ClearSCADA Server Configuration Tool to enter the name of ODBC System DSN that you added in step 3. This provides the association between the ClearSCADA database and the ODBC DSN that the Crystal Reports driver uses to access the local database (see Configuring Crystal Reports Server Settings, and see Accessing the ClearSCADA Database).
  5. If your system comprises Multiple Databases, repeats step 2 to 4 as required, in order to add a client connection and ODBC Data Source Name (DSN) for each ClearSCADA database that Crystal Reports is to access from the server.

If Crystal Reports is to access the data from one or more Remote Database(s) (see Specify the Data Source) the DSNs used in such reports have to match on the client(s) and server(s) on your system. (That is, for each ClearSCADA database, the DSN has to have the same name and be connected to the same data source on the client(s) on which the reports are to be created, and on the server(s) that will be used to generate those reports.)

  6. Repeat the above steps for the other servers on your system (except permanent standby servers).

Further Information

For diagrams that illustrate the location of the ClearSCADA components that you need to install, see ClearSCADA Software Components.


Crystal Reports Driver Guide - Installation on ViewX Clients on Which You Want to Edit Reports (Introduction to Using Crystal Reports with ClearSCADA)

Installation on ViewX Clients on Which You Want to Edit Reports

On the ViewX clients on which you want to edit reports on your system, you need to:

  1. Install the software for the third-party Crystal Reports application. ClearSCADA can interface with either:
  • Crystal Reports version 2008 (also known as SAP Crystal Reports)

or:

  • Crystal Reports version XI release 2
    (With this version of Crystal Reports, the edition of software has to be Crystal Reports Professional or higher).

With either version of Crystal Reports, you need to include the drivers for any Export options that you will be using for your reports.

  2. If you installed Crystal Reports version XI release 2 in step 1, install the relevant Crystal Reports version XI release 2 Service Pack (see http://resourcecenter.controlmicrosystems.com/pages/releaseview.action?pageId=917534).
  3. Install the ClearSCADA software, including:
  • The relevant Crystal Reports ViewX Client component (the one that indicates the version of Crystal Reports software that you installed in step 1)
  • The Data Access component.
  4. Add an ODBC Data Source Name (DSN) to allow Crystal Reports to access the ClearSCADA database. Crystal Reports uses the DSN to access the relevant database whenever you create or edit a report on a client.

The DSN on a client can be either a System DSN or a User DSN. (A System DSN is shared by all Windows Users on a machine; a User DSN is specific to an individual Windows User—the user that was logged on when the DSN was added.)

We advise that the same data source name is used throughout your system, even if Crystal Reports is only to access the Local Database. (The Local Database is the ClearSCADA database that contains the report.) By using the same data source name, you allow your reports to be fully portable - they can be edited from any client on which ClearSCADA and Crystal Reports are installed.

(If any of your reports are to access Multiple Databases, the same data source name has to be used throughout your system—see step 5.)

If your computer is running a 64-bit version of Windows®, you need to add a 32-bit ODBC DSN, as Crystal Reports is a 32-bit application. (Be aware that the 32-bit and 64-bit versions of the ODBC Data Source Administrator Tool display both 32-bit and 64-bit User DSNs on computers running 64-bit operating systems.)

On machines running the 32-bit version of Windows®, you can access the ODBC Data Source Administrator Tool from the Control Panel on your PC. On machines running the 64-bit version of Windows®, you need to run the 32-bit version of the ODBC Data Source Administrator Tool. To do this, run the Odbcad32.exe file that is located in the %windir%\SysWoW64 folder.

For more information on setting up an ODBC DSN, see Configure a Third Party ODBC Client - System Connection in the ClearSCADA Guide to Client Administration.

  5. If any of your reports are to access more than one database, repeat step 4 as required, in order to add one ODBC DSN for each additional database.

In order for Crystal Reports to access multiple databases, each DSN that you add:

  • Has to be a 32-bit ODBC DSN
  • Has to have the same name on both the client(s) on which the reports are to be created, and on the server(s) that will be used to generate those reports.

For Crystal Reports to access the data from other databases, the relevant reports have to be configured to access Remote Database(s) (see Specify the Data Source).

  6. Repeat the above steps on each ClearSCADA clients that is to be used for editing reports.

Further Information

For diagrams that illustrate the location of the ClearSCADA components that you need to install, see ClearSCADA Software Components.


Crystal Reports Driver Guide - Installation on Clients on Which You Only Want to Display or Print or Export Reports (Introduction to Using Crystal Reports with ClearSCADA)

Installation on Clients on Which You Only Want to Display or Print or Export Reports

On the ViewX clients on which you want to display reports, or print or export reports locally, but not edit reports, you need to:

  1. Install the ClearSCADA software, including the relevant Crystal Reports ViewX Client component (the one that indicates the version of Crystal Reports software that is installed on your system).
  2. Repeat the above step on each of the ClearSCADA clients that will be used for displaying, printing or exporting reports (but will not be used for editing).

NOTE: You can request the server to export or print a report from any client. Such requests are made using the Print Report or Export Report pick actions, respectively.

On any WebX clients on which you want to display the latest generated version of a report, you need to:

  1. Install the ClearSCADA WebX Client component, or download the component automatically from the Web server (if permitted to do so by Windows® Internet Explorer security).
  2. Install Adobe Reader® from the Adobe web site (http://www.adobe.com/reader).
  3. Repeat the above steps for each of the WebX clients that will be used to display reports.

WebX can display any report that has been configured to be available (see Specify Whether a Report is to be Made Available for Display in WebX.)

Further Information

For diagrams that illustrate the location of the ClearSCADA components that you need to install, see ClearSCADA Software Components.


Crystal Reports Driver Guide - ClearSCADA Software Components (Introduction to Using Crystal Reports with ClearSCADA)

ClearSCADA Software Components

This section shows the location of the ClearSCADA components that need installing in order to produce or work with reports, using ClearSCADA’s Crystal Reports feature.

Which components you need to install on each computer varies, depending whether you are installing the software on a server or client (see Install Crystal Reports).

The ClearSCADA components comprise:

  • Server Component
  • ViewX Client Component
  • Data Access Component
  • WebX Client Component.

Server Component

You need to install the relevant Crystal Reports Server component on both the servers and the ViewX clients on your system.

You also need to install the relevant ViewX Client Component and the Data Access Component on your system’s servers.

For the step-by-step procedure that you should follow in order to install the required software on your system’s server(s) and ViewX clients, see Install Crystal Reports.

For further information on installing components within the Server branch, see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers.

ViewX Client Component

You need to install the relevant Crystal Reports ViewX Client component on both the servers and the ViewX clients on your system.

You also need to install the relevant Server Component and the Data Access Component on your system’s servers.

For the step-by-step procedure that you should follow in order to install the required software on your system’s server(s) and ViewX clients, see Install Crystal Reports.

Data Access Component

You need to install ClearSCADA’s Data Access component on both the servers on your system, and the clients on which you want to create or edit reports.

For the step-by-step procedures that you should follow in order to install the required software on your system’s servers and clients, see as applicable:

  • Server Installation
  • Installation on ViewX Clients on Which You Want to Edit Reports.

WebX Client Component

You need to install ClearSCADA’s WebX Client component on any WebX clients on your system.

Further Information

Procedure for installing the required software on any WebX clients on which you want to display the latest generated version of a report: see Installation on Clients on Which You Only Want to Display or Print or Export Reports.


Crystal Reports Driver Guide - Plan Your Reports (Introduction to Using Crystal Reports with ClearSCADA)

Plan Your Reports

Before you launch Crystal Reports or add new report entries to the ClearSCADA database, you should decide:

  • The type(s) of report that you require.

For instance, are the reports to contain current or historic data? If the reports are to contain historic data, be aware that you will need to constrain the amount of data that each report is to include (see Important Guidelines on Configuring and Generating Reports).

  • The content that you want to include in those reports.

In order to include ClearSCADA data in your reports, you need to specify to which ClearSCADA database table(s) each report is to map. Additionally, you need to specify which of the fields within those database tables are to be included in each report. To do this, you need to be familiar with the ClearSCADA database structure and naming conventions. For more information, see Accessing the ClearSCADA Database, and see Working with ClearSCADA Database Tables.

Large reports, complex reports, and reports that query historic table(s) can place a significant demand on system resources and affect system performance. For this reason, you should include suitable data restrictions when creating such reports (see Important Guidelines on Configuring and Generating Reports).

  • On an appropriate structure and layout for those reports.

If you are going to produce many similar reports, you may want to consider configuring your ‘base’ reports within Group Templates (see Configuring Reports within Group Templates).

Be aware that if you are planning on exporting your reports to a different format, some Crystal Report components may not be supported by the chosen export Format. For example, you should not include fields other than data fields in a report that is to be exported to a programmatic-type text format, such as a Separated Values format. Therefore, you may want to exclude headers, footers, and field titles from your report, to avoid these being exported as data records if you are exporting that report to such a format.

  • Whether you want to export the reports to another destination and if so, the format that the reports are to take (see Define the Export Format for a Report, and see Define the Export Destination for a Report).

A system administrator needs to check that the drivers for the required export formats have been fully installed as part of the Crystal Reports installation process—see Install Crystal Reports.

  • For more complex reports, you may need to include formulae to allow you to display the information you require, in the format or order in which you require it.

For this, you need experience or knowledge of the Crystal Reports coding language (see the documentation supplied with the Crystal Reports application for information). For an example of how formulae can be used, see Point Listing that Uses Color to Indicate Alarm Status).

  • Whether the reports are to be triggered manually or automatically (see Activating a Report Action Automatically).


Crystal Reports Driver Guide - Configure Your Reports (Introduction to Using Crystal Reports with ClearSCADA)

Configure Your Reports

To produce reports in ClearSCADA, the ClearSCADA Data Access component has to be installed and running on the ClearSCADA servers on your system, and also on any ViewX clients that will be used for report editing. Additionally, the third-party Crystal Reports application has to be installed on the clients on which your reports are to be configured (see Install Crystal Reports).

When ClearSCADA is first installed, a system administrator needs to define the server settings for the driver (see Configuring Crystal Reports Server Settings).

Before you configure any reports in ClearSCADA, you need to be aware of the required content and layout of those reports (see Plan Your Reports).

You also need to be aware of which optional features are required for each report. The features include:

  • Help views
  • Historic storage
  • User methods.

You can also use core ClearSCADA features with reports, including Lists, Actions, and Mimics. For driver-specific information, see Working with the Reports List and see Using Actions Associated with Crystal Reports. For further information on Lists, Actions and Mimics, see the core documentation.

For each report, you need to:

  1. Create a Crystal Report and configure the report properties within ClearSCADA (see Creating a Report and Defining the Report Properties).
  2. Configure the report structure and content using Crystal Reports application. For more information, see:
  • Configuring the Report Structure and Basic Content
  • Accessing the ClearSCADA Database
  • Adding Fields and Data to a Report.

You should also adhere to the Important Guidelines on Configuring and Generating Reports.

If applicable, also see Configuring a Report that Queries a Historic Table.

For information on Group Templates, see Configuring Reports within Group Templates.

  3. If the report is to be generated automatically, you need to associate the report with the relevant Schedule or Alarm Redirection Action (see Activating a Report Action Automatically).


Crystal Reports Driver Guide - Important Guidelines on Configuring and Generating Reports (Introduction to Using Crystal Reports with ClearSCADA)

Important Guidelines on Configuring and Generating Reports

ATTENTION: To update a report in the ClearSCADA database, ViewX has to be running while the report is being edited in the Crystal Reports application. As each report has to be saved using its original file name, we advise that you use the Crystal Reports’ Save, rather than the Save As option, to store your reports.

ATTENTION: Do not use the Report Creation Wizards in Crystal Reports XI or 2008 (except for adding any subreports) as these produce new reports that cannot be saved in the ClearSCADA database. Instead, you use a series of ‘Expert’ windows that allow you to configure various features in your reports.

When producing large or complex reports, or reports that query historic table(s), you should:

  • Restrict the Data that a Report is to Retrieve
  • Consider When to Generate Complex or Large Data Queries.


Crystal Reports Driver Guide - Restrict the Data that a Report is to Retrieve (Introduction to Using Crystal Reports with ClearSCADA)

Restrict the Data that a Report is to Retrieve

The generation of an unrestricted large or complex report may cause a temporary adverse affect on a ClearSCADA system, as the ClearSCADA database cannot be updated until the query for report data is complete. For this reason, we advise that you restrict the amount of data that can be requested in a large or complex report, by building in restrictions to that report.

Include the necessary restrictions as soon as you create a report entry in the database, and certainly before you attempt to preview any report data. This avoids inadvertently generating a report that attempts to retrieve an unconstrained amount of data, such as all historic data ever produced on the system. As a minimum with a report that queries historic table(s), constrain the data by time (for example, one week). For more information, see Restrict the Amount of Data that is Queried in a Report.

You should also consider using stored data to check out the changes that you are making to a report while you are configuring that report—see Decide Whether to Refresh Data or Use Saved Data. By using stored data, the Crystal Reports application does not need to access the ClearSCADA database should you want to preview the report layout during the configuration stage. Once a report is complete, you need to check that the data is no longer stored with the report and that the report uses the most up-to-date data.


Crystal Reports Driver Guide - Consider When to Generate Complex or Large Data Queries (Introduction to Using Crystal Reports with ClearSCADA)

Consider When to Generate Complex or Large Data Queries

The generation of large or complex reports can have a temporary adverse effect on the performance of a ClearSCADA system. We advise that such reports are generated when little communications traffic is expected on a ClearSCADA system—for example in the early hours of the morning.

Although there are no limits to the number of records that ClearSCADA can query, there are limits on the size of the result set that ClearSCADA can return from a single query. By default, this is limited to 1,000,000 rows or 50MB, whichever limit is exceeded first. These limits can be changed on a per system basis, but this may impact on system performance (see Use the Parameters Settings to Define the SQL Query Row and Size Limit in the ClearSCADA Guide to Server Administration).

Furthermore, if a query takes too long to execute, the report may be unable to generate due to the ODBC connection between the Crystal Reports application and ClearSCADA timing out. For this reason, we recommend that you Restrict the Amount of Data that is Queried in a Report, especially if the report queries historic table(s). You may also need to adjust the value of the connection’s Request Timeout property to avoid the ODBC connection timing out (see Define the Port and Poll Timeouts and Intervals for a ViewX Client Connection in the ClearSCADA Guide to Client Administration).


Crystal Reports Driver Guide - Configuring Crystal Reports Server Settings

Configuring Crystal Reports Server Settings

Some driver-specific settings need configuring on the server by a system administrator when a ClearSCADA system is first installed. These settings are configured using the ClearSCADA Server Configuration Tool.

This section explains the settings that are specific to the Crystal Reports driver. These settings are in addition to:

  • The Drivers global parameters (see Driver Settings in the ClearSCADA Guide to Server Administration)
  • Parameters that specify the location of Database components, such as:
  • Historic Files—including any historic files that are generated by Crystal Reports.
  • Data Files—including each report’s ‘definition’ (the report’s content and layout) and the latest generated version of each report.

For further information, see Locations of the Database Folders in the ClearSCADA Guide to Server Administration.

  • The Printing user parameters that the Crystal Reports driver uses when executing the Export Report and Print Report pick actions (see Printer Settings in the ClearSCADA Guide to Server Administration).

The specified printing user:

  • Needs to have write access to any directories and shares to which reports are to be exported, when the export destination is set to File on Disk (see Define the Export Destination for a Report).
  • Has to have been allocated the ‘Log on as a Service’ privilege.
  • Determines which printers are available for server-side printing.
  • Determines the e-mail settings for each report that is to be exported in an E-mail when using the server’s Windows MAPI settings to export such e-mails (see Define the Export Destination for a Report).

NOTE: The steps in the procedure below need to be performed locally on the server(s) on which Crystal Reports is installed. The procedure cannot be completed successfully from a client PC.

To access the Crystal Reports section of the ClearSCADA Server Configuration Tool and make any necessary configuration adjustments:

  1. Run the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Expand the Global Parameters branch in the Server Configuration tree-structure.
  3. Within the Global Parameters tree-structure, select the Crystal Reports entry.

    The Crystal Reports section is shown in the right-hand pane of the Server Configuration window. (The layout varies slightly, depending which version of Crystal Reports driver is installed.)
  4. Crystal Reports uses Open DataBase Connectivity (ODBC) to access the ClearSCADA database. In order to produce Crystal Reports within ClearSCADA, you need to add a System Data Source (DSN) for the ClearSCADA driver, to each server on your system (see Server Installation).

To modify or add a System Data Source via the ClearSCADA Server Configuration Tool:

  1. Select the Setup button in the Crystal Reports’ Data Source section.
    The ODBC Data Source Administrator Tool is displayed.

NOTE: If you access this section from a client or a server other than the local server, the Setup button is ‘grayed out’ and is unavailable for use.

  2. Select the Tool’s System DSN tab.
  3. Use the tab to modify or create a suitable data source (for restrictions and recommendations, see Server Installation).

For information on creating a System DSN for the ClearSCADA driver, see Third Party ODBC Client - System Connections in the ClearSCADA Guide to Client Administration. You need to specify a name that is clearly recognizable as the ClearSCADA System data source, as the data source will need specifying for each report on your system. (We recommend that you leave the data source User Name and Password fields blank and restrict access to the ClearSCADA database by creating one or more Crystal Reports users within ClearSCADA—see Configure the Report Properties.)

If ‘Date Time’ Parameters are to be used to query the ClearSCADA database (see Parameter Field), set the DSN to use Local Time, rather than UTC.

For further information on creating DSNs, refer to your Windows® documentation.

  4. Select the OK button.
    The ODBC Data Source Administrator window is closed.

NOTE: On machines that are running a 32-bit version of Windows®, you can also access the ODBC Data Source Administrator Tool from the Control Panel on your PC. On machines running a 64-bit version of Windows®, you need to run the 32-bit version of the ODBC Data Source Administrator Tool. To do this, run the Odbcad32.exe file that is located in the %windir%\SysWoW64 folder. For more information, see Configure a Third Party ODBC Client - System Connection in the ClearSCADA Guide to Client Administration.

  5. Enter the data source name in the DSN field of the Crystal Reports’ Data Source section.

This provides the association between the ClearSCADA database and the ODBC System DSN that the Crystal Reports driver uses to access the local database.

  5. ClearSCADA can interface with either Crystal Reports version XI release 2, or Crystal Reports version 2008 (also known as SAP Crystal Reports) (see Install Crystal Reports).

If ClearSCADA is configured to interface with Crystal Reports version 2008, the Crystal Reports section of the ClearSCADA Server Configuration Tool will include an E-mail check box.

Select the check box if ClearSCADA is to E-mail report exports using server SMTP settings. ClearSCADA will use the SMTP settings specified in the E-Mail section of the ClearSCADA Server Configuration Tool when exporting any Crystal Reports via e-mail. For further information on these settings, see E-Mail Settings in the ClearSCADA Guide to Server Administration.

The check box needs to be clear (the default setting) for ClearSCADA to use the server’s Windows MAPI settings when exporting reports via e-mail. For more information on these settings, see Export the Report in an E-Mail Message.

(If ClearSCADA is configured to interface with Crystal Reports version XI release 2, it will use the server’s Windows MAPI settings to export reports via e-mail.)

  6. Right-click on the server (‘node’) entry in the hierarchical list in the Server Configuration window.
    A context sensitive menu is displayed.
  7. Select the Apply Changes option.
    The changes are applied to the server configuration.
  8. If the server is currently running as the main server, restart the driver for the changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).
  9. Repeat the above steps for each server in your system (with the exception of permanent standby servers).


Crystal Reports Driver Guide - Creating a Report and Defining the Report Properties

Creating a Report and Defining the Report Properties

Reports can be used to produce a ‘snap-shot’ of the data on your system.

When you add a report to your system, you specify the general report properties, historic life, and export properties using ClearSCADA’s Crystal Report Form.

This section explains how to:

  • Create a Report
  • Configure the Report Properties
  • Define the Historic Storage of a Report
  • Define the Export Format for a Report
  • Define the Export Destination for a Report
  • Specify Whether a Report is to be Made Available for Display in WebX.

To configure the report content and layout (known as the report ‘definition’), you use the third-party Crystal Reports application (see Configuring the Report Structure and Basic Content, and see Adding Fields and Data to a Report).


Crystal Reports Driver Guide - Create a Report (Creating a Report and Defining the Report Properties)

Create a Report

To add a Crystal Report to ClearSCADA:

  1. In the Database Bar, right-click on the Group or System to which you want to add a report.
    A context sensitive menu is displayed.

NOTE: If the Database Bar is not displayed, you can access it by selecting the View menu, then selecting the Explorer Bar option, then selecting the Database option.

  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select the Crystal Report option.
    A Crystal Report entry is added to the Group or System. The entry is highlighted in the Database Bar tree structure, ready for you to define its name.
  5. Enter a suitable name for the report (see Naming Restrictions in the ClearSCADA Guide to Core Configuration).
  6. Select another part of the interface or press the Enter key to confirm the entry.

You can then use the Crystal Report Form to configure the report’s properties. The Form has several tabs:

  • Identification—Use to optionally define a Help View and to indicate whether the report is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for the report (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Crystal Report—Use to Configure the Report Properties
  • Historic—Use to Define the Historic Storage of a Report.

If you want to export the report, you also need to configure the relevant properties on the following tabs:

  • Export Format—Use to Define the Export Format for a Report
  • Export Destination—Use to Define the Export Destination for a Report.

(If the report is not going to be exported, set the Export Format and Destination to ‘None’.)

If the report needs to be displayed from WebX clients, configure the relevant properties on this tab:

  • Generate for WebX—Use to Specify Whether a Report is to be Made Available for Display in WebX.

For further information on configuring reports, see as appropriate:

  • Configuring a Report that Queries a Historic Table
  • Configuring Reports within Group Templates
  • Example Reports.


Crystal Reports Driver Guide - Configure the Report Properties (Creating a Report and Defining the Report Properties)

Configure the Report Properties

Use the fields on the Crystal Report tab of the Crystal Report Form to:

  • Specify the General Report Properties
  • Specify the Data Source
  • Define the Print Properties
  • Define the Page Margins.


Crystal Reports Driver Guide - Specify the General Report Properties (Creating a Report and Defining the Report Properties)

Specify the General Report Properties

Use the fields at the top of the Crystal Report tab to specify these general properties:

  • In Service—Use to specify whether the report is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Severity—Use the combo box to define the priority of any alarms or events that are associated with the report (see Defining Severities in the ClearSCADA Guide to Core Configuration).


Crystal Reports Driver Guide - Specify the Data Source (Creating a Report and Defining the Report Properties)

Specify the Data Source

Use the fields within the Data Source section on the Crystal Report tab to specify whether the report is to query data from just the local ClearSCADA database, or from other database(s):

  • Location—Use this combo box to specify the location of the database(s) that the report is to query. Crystal Reports accesses the database(s) via ODBC, using one or more ODBC DSN connection(s) (one per database). You specify the DSN(s) that are required to access the data in a particular report, using the Crystal Reports application (see Accessing the ClearSCADA Database).

Choose from:

  • Local Database—The report is only to query the local ClearSCADA database. (The Local Database is the database in which the report is located).
  • Remote Database(s)—The report is to access database(s) other than the Local Database.

A Remote Database might comprise:

  • A different ClearSCADA database on another server
  • One of several other ClearSCADA databases on the local server
  • A database belonging to another application, which Crystal Reports can access using an ODBC DSN connection.

If you select the Remote Database(s) option, your system needs to be set up so that:

  • The ClearSCADA servers are configured to have all of the ODBC data sources that are used in the report (see Server Installation).
  • The ODBC data sources have exactly the same names on each server (the names of the data sources are determined by the DSNs that are on the client that is used to create the report—see Installation on ViewX Clients on Which You Want to Edit Reports).
  • The data sources allow access to their respective databases without prompting for any information (such as a password). For more information, see Configure a Third Party ODBC Client - System Connection in the ClearSCADA Guide to Client Configuration.
  • User—Only applies if a report queries the Local Database (see above). You can optionally use this field to specify the user that is to generate, print or export the report. Use the browse button to display a Reference browse window, and select the user from the window.

Specify a user in order to restrict the content that can be included in a report when that report is generated, printed or exported. The report content is restricted to the data to which the specified user has access, in addition to the restrictions that are specified for the report itself.

If you use security settings on your ClearSCADA system, we recommend that you set up one or more Crystal Reports users on your system and specify such a user in the User field. (If your system is divided into regions or other logical divisions, you can set up a series of Crystal Reports users, each having access to a different division or set of system features, and specify the required user in the User field.)

If you set the User field to be blank (have no value), the Crystal Reports application will attempt to access the ClearSCADA database using the ODBC Data Source logon account (the Crystal Reports application accesses ClearSCADA using a ODBC Data Source—see Configuring Crystal Reports Server Settings).

If the DSN user name and password are left blank (as recommended), the Crystal Reports application will log on to ClearSCADA using the Guest user account.

If security has been used to restrict the Guest account so that the user does not have read access to the database items that might be included in reports, blank reports will be produced.

If the Guest user only has read access to some of the items in the database, then the reports may only contain some of the expected information (they will only contain those items to which the Guest User has access).

If your system does not use ClearSCADA security, set the User field to have no entry (be blank).

For information on ClearSCADA security and setting up user accounts, see Setting up System Security in the ClearSCADA Guide to Security.


Crystal Reports Driver Guide - Define the Print Properties (Creating a Report and Defining the Report Properties)

Define the Print Properties

Use the fields within the Printing section of the Crystal Report tab to define the settings that are used when printing a report using the Print Report pick action. This pick action allows you to print a report using data obtained directly from the database.

(If you print a report directly from the Crystal Reports application, you need to specify the print setup from within the Crystal Reports application, rather than on this Form. If you use the Crystal Reports Viewer to display a previously generated report in ViewX, and then choose to print that report using the Print menu option or toolbar button, you need to specify the print settings using the Print Setup option, available from the File menu in ViewX. (For more information on the latter, see Using the Crystal Reports Viewer.))

NOTE: When defining the printing options, remember that the settings you choose must also be supported by the printer(s) on your system.

  • Orientation—Use the combo box to specify whether the page orientation for any printed reports is Portrait or Landscape.

If you specify Landscape, you will also need to use a Landscape orientation for your reports within the Crystal Reports application (see Specify the Page Setup).

  • Paper Size—Use the combo box to specify the paper size for any printed reports. The default is A4.
  • Paper Source—Use the combo box to specify the source for the paper used to print any reports. For example, the Upper, Lower, or Middle printer tray. The default is Automatically Select, which uses the printer’s default setting.
  • Duplex—Use the combo box to specify whether the printed report is to be Single Sided, or printed doubled-sided (using Double Sided - Flip on Vertical Edge, or Double Sided - Flip on Horizontal Edge, as supported by your printer(s)).

Additionally, you also need to Define the Page Margins for any printed reports.


Crystal Reports Driver Guide - Define the Page Margins (Creating a Report and Defining the Report Properties)

Define the Page Margins

In addition to using the Printing section of the Crystal Report tab to Define the Print Properties, you need to use the fields within the Margins section of the tab to define the page margins for reports that are printed using the Print Report pick action.

Enter the margin sizes in millimeters. If you are specifying small margins, you should consider the capabilities of your system printer(s), as they may only support margins of a certain size.

(If you print a report directly from the Crystal Reports application, you need to specify the page setup from within the Crystal Reports application, rather than on this Form. If you use the Crystal Reports Viewer to display a previously generated report in ViewX, and then choose to print that report using the Print menu option or toolbar button, you need to specify the page setup using the Print Setup option, available from the File menu in ViewX. (For more information on the latter, see Using the Crystal Reports Viewer.))


Crystal Reports Driver Guide - Define the Historic Storage of a Report (Creating a Report and Defining the Report Properties)

Define the Historic Storage of a Report

Use the fields on the Historic tab to specify whether the server is to store reports historically:

  • Enabled—Select this check box if the server is to store reports historically.

If each report is to be overwritten the next time that it is generated, clear the Enabled check box.

NOTE: To retain reports for long periods or indefinitely, we recommend that you export those reports, rather than store them in the database (see Define the Export Format for a Report, and see Define the Export Destination for a Report).

  • Life—For reports that ClearSCADA is to store historically, specify the length of time that the reports are to be retained on the server. Specify the time in the OPC Time Format, for example, 4W for ClearSCADA to store reports for a four-week period.

When more than one version of a report is stored on the server, users can choose which version they want to display, by selecting the required report from a list of time stamped files (see Display).


Crystal Reports Driver Guide - Define the Export Format for a Report (Creating a Report and Defining the Report Properties)

Define the Export Format for a Report

You can export your reports in a wide variety of formats, using the Export Report pick action. This pick action allows you to export a report containing the latest ‘live’ data, obtained from the ClearSCADA server.

NOTE: Export Report is a separate function to the Export feature that allows you to duplicate ClearSCADA database items and transfer those duplicates to other databases—for information on that Export feature, see Importing and Exporting Database Items in the ClearSCADA Guide to Core Configuration.

Use the Format field on the Export Format tab of the Crystal Report Form to define the format in which a report is to be exported using the Export Report pick action.

Select a format that applies to your system setup. In many cases, the appropriate third-party application has to be installed at the target destination (see Define the Export Destination for a Report) in order to read the reports in the chosen export format.

Choose from:

  • None—The report is not to be exported.
  • Export the Report in Adobe Acrobat Format
  • Export the Report in Crystal Reports Format
  • Export the Report in HTML Format
  • Export the Report in Microsoft Excel Format
  • Export the Report in Microsoft Word Format
  • Export the Report in Rich Text Format
  • Export the Report in Separated Values Format
  • Export the Report in Separated Text Format
  • Export the Report in Plain Text Format
  • Export the Report in XML Format.

If ClearSCADA is configured to interface with Crystal Reports version XI release 2, you can also choose to:

  • Export the Report in Record Style Format
  • Export the Report to another Database using ODBC.

If you choose an export option other than None or ODBC above, you also need to Define the Export Destination for a Report.

Be aware that if you export to a format other than Crystal Reports, some of the formatting you have applied may be lost. In many cases, the export type determines which attributes are preserved in an exported report. In other cases, you can specify which attributes you want to include in an exported report.

When exporting a report, you need to choose an Export Format that is compatible with the Export Destination.

NOTE: The setting(s) specified on the Export Format tab do not affect reports when they are displayed on WebX clients.


Crystal Reports Driver Guide - Export the Report in Adobe Acrobat Format (Creating a Report and Defining the Report Properties)

Export the Report in Adobe Acrobat Format

If ClearSCADA is to export a report to Adobe Acrobat format, use the Format field on the Export Format tab to specify the Adobe Acrobat format.

When exported, a printable PDF file is generated. The file can be viewed using Adobe® Reader®.

NOTE: This option does not affect the format of a report that is displayed on a WebX client (see Specify Whether a Report is to be Made Available for Display in WebX).


Crystal Reports Driver Guide - Export the Report in Crystal Reports Format (Creating a Report and Defining the Report Properties)

Export the Report in Crystal Reports Format

If ClearSCADA is to export a report in Crystal Reports format, use the Format field on the Export Format tab to specify the Crystal Reports format.

When exported, the report remains in Crystal Reports format and retains the settings and layout that were specified when the report was last edited (assuming that the specified fonts are available from whichever location the exported report is accessed).


Crystal Reports Driver Guide - Export the Report in HTML Format (Creating a Report and Defining the Report Properties)

Export the Report in HTML Format

If ClearSCADA is to export a report in HTML format, use the Format field on the Export Format tab to specify the HTML format. Use the fields on the tab to specify:

  • Version—Specify to which version of HTML a report is to be exported. Choose from 3.2 or 4.0.
  • Page Navigator—Select this check box to add a ‘page navigator’ to the bottom of each page of a report, when it is exported to HTML format. The page navigator enables you to navigate between the HTML pages in a report, regardless of whether the pages form the same or a series of separate HTML files.

Clear the check box if you do not require a page navigator in your report.

  • Separate HTML Pages—Select this check box for the report to form one or more separate HTML pages, when it is exported to HTML format. Each page forms a separate HTML file. As such, if you have a seven-page report, ClearSCADA exports the report as seven separate HTML files, with each file name comprising the report name, followed by a number (1 to 7). You can specify a Page Navigator (see above) in order to navigate between the HTML files.

To set the report to form a single HTML file when exported to HTML, clear the check box. The pages of the report follow on from one another in the file. If you specify a single-file HTML file in conjunction with a Page Navigator, the navigator will appear at the end of each ‘page’ within the HTML file, allowing easy navigation to other pages within the file.

Example:

When used with a single-file HTML report, the page navigator appears at the end of each ‘page’ within the report.
Header indicating the start of ‘page’ 2.
Footer indicating the end of ‘page’ 1.


Crystal Reports Driver Guide - Export the Report in Microsoft Excel Format (Creating a Report and Defining the Report Properties)

Export the Report in Microsoft Excel Format

ATTENTION: It is imperative that formatting of reports that are to be exported to Microsoft Excel is precise. Any objects that are not aligned on such a report may cause the exported version of the report to include blank or mis-aligned rows and/or columns. Ideally, use the Snap to Grid feature on the Options window to help position objects accurately.

If ClearSCADA is to export a report in Microsoft Excel format, use the Format field on the Export Format tab to specify the Microsoft Excel format.

When the Format is set to Microsoft Excel, the tab displays these fields:

  • Version—Use to specify to which version of Excel a report is to be exported. Choose from:
  • 97-2000—Exports the report data and any supported formatting into an Excel 97/2000 work sheet.
  • 97-2000 (Data only)—Exports purely the report data, excluding any layout or format settings, into a default Excel 97/2000 work sheet.

Use the fields within the Column Widths section of the tab to specify:

  • Constant Column Width—Select this check box if you want to specify a particular width, in points, for each column in a report, for when that report is exported to Excel. Use the Points field to specify the width for each column.
    When a Constant Column Width is specified, the column widths within the Excel version of the report use the width specified in the Points field (in this example, 500pts).
    The report content takes on the layout specified in the Crystal Reports version of the report. Each field takes up one or more column-widths, depending on the size of the field.

Clear the check box if the column widths are to assume a particular width, based on a particular column-type. Use the remaining fields in the Column Widths section of the tab to specify that width.

  • Column Width Based on Objects in Area—Use this combo box to specify the criteria that you want ClearSCADA to use for assigning the column widths in the Excel version of a report. As Header and Footer ‘field objects’ are optional in Crystal Reports, you should only select an option that is applicable to that particular report.

Choose from:

  • Report Header—The Excel columns are based on the width and position of any fields that appear in the ‘Report Header’ section of the report.
    Select the ‘Report Header’ Column Width option for the Excel columns to be based on the position and widths of the fields that appear in the ‘Report Header’ section of the report.

  • Page Header—The Excel columns are based on the width and position of any fields that appear in the ‘Page Header’ section of the report.
  • Group Header—The Excel columns are based on the width and position of any fields that appear in the ‘Group Header’ section of the report. As you can assign multiple Groups to a report, use the adjacent field to specify to which Group number you are referring.
  • Detail—The default option. The columns of the Excel file assume the widths of the fields that appear in the ‘Details’ section of the Crystal Reports version of the report.
    Select the ‘Detail’ Column Width option for the Excel columns to assume the widths of the corresponding fields that are specified in the ‘Details’ section of the Crystal Report. This means that each field is one column wide.

  • Group Footer—The Excel columns are based on the width and position of any fields that appear in the ‘Group Footer’ section of the report. As you can assign multiple Groups to a report, use the adjacent field to specify to which Group number you are referring.
  • Page Footer—The Excel columns are based on the width and position of any fields that appear in the ‘Page Footer’ section of the report.
  • Report Footer—The Excel columns are based on the width and position of any fields that appear in the ‘Report Footer’ section of the report.

Use these fields on the tab to specify whether Headers and Footers are exported with a report and additional properties that define how Excel handles the exported information:

  • Page Headers and Page Footers—Use to specify the location of the headers and footers in the exported version of a report. As headers and footers are optional in a report, you should only specify options that are applicable to the report.

Choose from:

  • None—If the export Version is 97-2000, select this option if Headers and footers are not to be used in the Excel version of a report.

If the export Version is 97-2000 (Data only), select this option to exclude Page Headers and Page Footers, but include Report Headers and Footers. The Report Header appears at the start of the report, and the Report Footer at the end of the report.

  • Once Per Report—If the export Version is 97-2000, select this option if the exported report is to have Report Headers and Footers. A Report Header appears only once, on the first page of a report. A Report Footer appears only once, on the last page of a report.

If the export Version is 97-2000 (Data only), select this option to include the Page Header and Page Footer once only in the exported report. The Page Header appears at the start of the report, and the Page Footer at the end of the report.

  • On Each Page—Only applies if the export Version is 97-2000. Select this option if the exported report is to have Page Headers and Page Footers that appear at the top and bottom of each page of the report, respectively.
  • Create Page Breaks For Each Page—Select this check box if page breaks are to be included in the exported report. You can view the page breaks by using the ‘Page Break Preview’ option within Excel.

Clear the check box if page breaks are not required.

  • Convert Date Values to Strings—Select this check box for Crystal Reports to convert any date values in a report into text strings, when it exports the report to Excel. Crystal Reports will only convert the date values into strings and will not change the formatting of the date information.

Clear the check box If date information is not required in a report, or re-formatting of the date information is required or acceptable.

  • Show Gridlines—Select this check box for the exported report to display grid lines, to the same specifications as the grid lines that are used in the Crystal Reports version of the report.
    Select the Show Gridlines check box for the Excel version of the report to display grid lines. The grid lines indicate the positions of the fields that appear in the ‘Details’ section of the Crystal Reports version of the report.

Clear the check box if grid lines are not required on the exported version of the report.

If specifying the 97-2000 (Data Only) export Version, use these fields to further specify what other report content is exported along with the report data:

  • Export Object Formatting—Select this check box to export the object formatting for a report. Clear the check box to set the exported report to use the default Excel formatting.

Example:

With a 97-2000 (Data Only) exported report, you can choose whether to export the formatting...
...or have the exported report use Excel’s default format settings.

  • Export Images—Select this check box to include any images in the exported report. For example, pictorial images such as company logos or Charts. Clear the check box to exclude any images from the export procedure.
  • Use Worksheet Functions for Summaries—Select this check box for exported summaries to use Excel’s summary functionality for data analysis.

Clear the check box if summary functionality is not used or is not required in the exported version of a report.

  • Maintain Relative Object Position—Select this check box for the exported objects (fields, images, and so on) in a report to maintain their positions relative to other objects in the report. Any field content is displayed in full.

Clear the check box if the exported objects in a report are not to maintain their positions relative to other objects in the report. Each item is assigned to the first available cell in a row. Any content that overflows the column width is hidden from view.

Example:

With a 97-2000 (Data Only) exported report, you can choose whether to allow the fields to maintain their relative positions and display the entire field content, regardless of whether it overflows the cell width...
...or assign the exported fields to the first available cell in each row, and for each cell to display only that content that fits within the cell width.

  • Maintain Column Alignment—Select this check box if the exported report is to use the minimum number of columns, in order to maintain the column alignment that is specified in the Crystal Reports version of the report.

Clear the check box for the exported data to be displayed up to the field width specified (for that data) in the Crystal Reports version of the report.

Example:

With a 97-2000 (Data Only) exported report, you can choose whether to use a minimum number of Excel columns in order to replicate the Crystal Reports version of a report...
...or take into account the widths of the fields in the Crystal Reports version of a report when exporting and displaying the field content in the Excel version of the report.

  • Simplify Page Header—Select this check box for the exported version of the report to only contain the bottom line of any Page Header content.

Clear the check box for the exported version of the report to contain the full content of any multi-line Page Headers.

(Remember that Page Headers are only displayed in the exported Excel version of a report if the Page Headers and Page Footers field on the Export Format tab is set to an option other than None.)

Example:

A report contains this layout:

In the Crystal Reports version of a report, the Page Header contains fields on two lines.

You can choose to export the Page Header content in one of two ways:

With a 97-2000 (Data Only) exported report, you can choose whether to export each of the rows of a Page Header...
...or simplify the Page Header so that only the bottom row of a multi-row Page Header is included in the exported version of a report.


Crystal Reports Driver Guide - Export the Report in Microsoft Word Format (Creating a Report and Defining the Report Properties)

Export the Report in Microsoft Word Format

If ClearSCADA is to export a report in Microsoft WordTM format, use the Format field on the Export Format tab to specify the Microsoft Word format.

As with other export formats, use the fields on the Crystal Report tab of the Crystal Report Form to specify the page settings that the exported report is to use (see Configure the Report Properties).

When exported, the report forms a single or multi-page Word document, depending on the specified page settings and size of the report.


Crystal Reports Driver Guide - Export the Report to another Database using ODBC (Creating a Report and Defining the Report Properties)

Export the Report to another Database using ODBC

NOTE: This export option is only available if ClearSCADA is configured to interface with Crystal Reports version XI release 2.

NOTE: If you specify the ODBC export format, you need to specify a Destination of ‘None’ on the Export Destination tab (as the export destination for the ODBC format is specified on the Export Format tab).

ClearSCADA can use Open Database Connectivity (ODBC) to export a report to another database. To make this possible, you need to check that the target database has a DSN configured in the ODBC control panel:

  1. Display the Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration)
  2. Select the Global Parameters branch, and then select the Crystal Reports section.
  3. In the Data Source box, select the Setup button to display the ODBC Data Source Administrator, then select the System DSN tab. The tab should contain the DSN of the target database.

If the target database’s DSN is not listed, you will need to add the DSN via the ODBC Data Source Administrator. Please refer to your Microsoft windows documentation for details on adding a DSN, but take care to display the ODBC Data Source Administrator from the Server Configuration Tool (as this displays the required 32-bit version).

When adding a DSN, you will need to choose the ODBC driver for the target database. This should be installed on the ClearSCADA server that is to generate the reports. If the driver is not listed, you will need to install the required driver on the ClearSCADA server. For more information, please refer to the documentation provided by the manufacturer of your target database.

When the target database’s ODBC driver and DSN are listed on the ODBC Data Source Administrator, you can:

  • Specify ODBC as the Format on the Export Format tab, and then use the remaining fields to configure the database connection settings (Data Source Name, User, Password, Table, and Trip Sequence Time).

When the Format is set to ODBC, the Export Format tab displays these fields:

  • Data Source Name—Specify the Data Source Name (DSN) for the database to which ClearSCADA is to export the report data. Specify either a System DSN or a User DSN.

If you specify a User DSN, it has to be a DSN of the Windows® user that is defined for server printing (see Printer Settings in the ClearSCADA Guide to Server Administration) and has to exist on every ClearSCADA server in your system (except permanent standby servers).

  • User—If access to the other application’s database is password protected, specify the user name that, used in conjunction with the Password given below, gives read/write access to that database.
  • Password—If access to the other application’s database is password protected, specify the password that, used in conjunction with the above User name, gives read/write access to that database and allows you to add new tables to that database.
  • Table—Specify the database table to which Crystal Reports is to write the report data. Crystal Reports creates the table in the target database when it exports the report.

You can include trip sequences in the table name, in order to include specific report information—see Trip Sequences Supported by ClearSCADA. Use the Trip Sequence Time field to specify the date/time information that is to be included in any Date or Time trip sequences.

Example:

AreaAReport%DddMMyy%

will result in a table name of the form:

AreaAReport010305

  • Trip Sequence Time—Use to specify the time or date that ClearSCADA uses for any Date or Time trip sequences that are specified in the Table field, above. Enter the time in the OPC Relative Time Format. (The default of NOW results in a time stamp based on ‘now’ exactly.)

For information on using this field, in conjunction with trip sequences, to produce the required date/time settings, see Specify the Trip Sequence Time.


Crystal Reports Driver Guide - Export the Report in Record Style Format (Creating a Report and Defining the Report Properties)

Export the Report in Record Style Format

NOTE: This export option is only available if ClearSCADA is configured to interface with Crystal Reports version XI release 2.

Use the Record Style export format if you want to export a report as a set of data—effectively a database—rather than as a page-based document for users to read. The exported data is exported as a text file that can be used by other programs that support such formats.

Example:

If ClearSCADA is to export a report in Record Style format, use the Format field on the Export Format tab to specify the Record Style format.

ATTENTION: If you are going to export a report in Record Style format, you should only include content in data fields in the report. The export process treats fields as records and as such will export multiple copies of any headers, footers, field titles, and so on.

When the Format is set to Record Style, the tab displays these fields:

  • Use Same Number Format as Report—Select this check box if you want to preserve number formatting in the exported version of a report.

Clear the check box if number formatting is not required in the exported version of a report.

  • Use Same Date Format as Report—Select this check box if the data in a report includes dates for which you want to preserve the format in the exported version of the report.

Clear the check box if date formatting is not required in the exported version of a report.


Crystal Reports Driver Guide - Export the Report in Rich Text Format (Creating a Report and Defining the Report Properties)

Export the Report in Rich Text Format

If ClearSCADA is to export a report in Rich Text Format (RTF), use the Format field on the Export Format tab to specify the Rich Text format.

When the Format is set to Rich Text, the tab displays these fields:

  • Editable—Select this check box to convert the report content to text lines. Any drawing objects are inlined with the text content and will move to accommodate changes if the content is edited in the exported version of the report. Text formatting is retained, but some other report formatting may not be retained.

Clear the Editable check box to export a report in an exact format that retains some formatting. Any drawing objects are placed in text frames. This option is typically used to produce forms to which text is to be added.

  • Create Page Breaks For Each Page—Select this check box for each page of a report to be separated by a page break. (Be aware that Crystal Report’s page breaks may not correspond to the page breaks created by Microsoft Word.)

Clear the check box if page breaks are not required.


Crystal Reports Driver Guide - Export the Report in Separated Values Format (Creating a Report and Defining the Report Properties)

Export the Report in Separated Values Format

If ClearSCADA is to export a report in Separated Value format, use the Format field on the Export Format tab to specify the Separated Value format.

ATTENTION: If you are going to export a report in Separated Value Format, only include content in data fields. This is because the export process treats all fields as records and so will export multiple copies of any headers, footers, field titles, and so on.

When the Format is set to Separated Value, the tab displays these fields:

  • Mode—Use to specify the ‘mode’ in which reports are to be exported. Choose from:
  • Legacy—Reports are exported in ‘old style’ Comma Separated Value (CSV) format. The mode provides limited control over the format of the exported report. The CSV file is encoded using a Multibyte character set (MBCS).

Legacy mode is unlikely to be supported by later versions of Crystal Reports.

  • Standard—Reports are exported in standard CSV format. The CSV file is encoded using the UTF-8 character set. Reports exported using this option retain more of their formatting than with the Legacy option. For instance, the reports retain any line breaks and take into account any conditional suppression.

When you Export a Previously Generated Report using the Crystal Reports Viewer, or export a report in Separated Values format from the full Crystal Reports application, a window is displayed. The window enables you to specify the export mode. If you opt to export the report in Standard mode, further options allow you to specify whether various elements of the report (such as headers and footers) are displayed in the CSV output. If you attempt to export the report in Legacy mode, a message is displayed. The message requests that the report is upgraded to and exported in Standard mode.

  • Type—Use to specify the separator that is used to indicate individual data entries in an exported report. Select the option that is supported by the program which is to use the exported data.

Choose from:

  • Comma—Data entries are separated by commas.
    When a report is exported in Comma Separated Value (CSV) format, the data is separated by commas.

  • Tab—Data entries are separated by tabs.
    When a report is exported in Tab Separated Value (TSV) format, the data is separated by tabs.

  • Custom—Select this option if a different set of field and string separators is to be used for an exported report. Use the Field Delimiter and String Delimiter fields below to specify the separators that are required.
  • Field Delimiter—Only applicable if the Type is set to ‘Custom’. Specify the separator that is required to indicate individual data entries in an exported report. The default delimiter is a comma.
  • String Delimiter—Only applicable if the Type is set to ‘Custom’. Specify the separator that is required to indicate individual text entries in an exported report. The default is ’’ (double quotation marks).
  • Use Same Number Format as Report—Select this check box if you want to preserve number formatting in the exported version of a report.

Clear the check box if number formatting is not required in the exported version of a report.

  • Use Same Date Format as Report—Select this check box if the data in a report includes dates for which you want to preserve the format in the exported version of the report.

Clear the check box if date formatting is not required in the exported version of a report.


Crystal Reports Driver Guide - Export the Report in Separated Text Format (Creating a Report and Defining the Report Properties)

Export the Report in Separated Text Format

Separated Text Format differs slightly from Separated Values Format in that some formatting is preserved, and column headings are handled slightly differently in reports that are exported in Separated Text Format.

If ClearSCADA is to export a report in Separated Text format, use the Format field on the Export Format tab to specify the Separated Text format.

When the Format is set to Separated Text, the tab displays these fields:

  • Type—Specify the separator that is used to indicate individual data entries in an exported report. The presently supported option is a Tab separator.

You can open Tab Separated Text files in applications such as Microsoft® Notepad, and Microsoft® Excel.

When a report is exported in Tab Separated Text format, the data is separated by tabs. Any string values are surrounded by double quotation marks.

  • Characters per Inch—Text format exports are based on the number of characters per inch. Use this field to specify the number of characters per inch used for an exported report.


Crystal Reports Driver Guide - Export the Report in Plain Text Format (Creating a Report and Defining the Report Properties)

Export the Report in Plain Text Format

If ClearSCADA is to export a report in plain Text format, use the Format field on the Export Format tab to specify the Text format.

Unlike with programmatic-type text export formats, headers and footers are treated as fields, rather than data records, and as such can be used in a report that is exported to Text Format.

Be aware that the export process takes into account the report’s field widths when exporting data and truncates any content that overruns such widths.

Unlike the text-type export formats that are designed to produce sets of data records, you can include headers and footers in a report that you want to export to Text Format.
Be aware that any content that overruns the field widths specified in the Crystal Reports version of the report will be truncated when it is exported.

NOTE: If you want to export a report in text format for programmatic purposes, you may want to Export the Report in Separated Values Format, or Export the Report in Separated Text Format.

When the Format is set to Text, the tab displays these fields:

  • Paginate—Select this check box for page breaks to be inserted when a report is exported. Use page breaks if you are going to print a report.
    Form feed character indicating a page break.

Clear this check box if page breaks are not required in the exported version of the report.

  • Number of Lines per Page—Only applicable if the Paginate option is enabled. Use this field to specify the number of text lines that are to be included on each page of an exported report. This includes the number of blank lines if space is included between rows of fields.
  • Characters per Inch—Text format exports are based on the number of characters per inch. Use this field to specify the number of characters per inch used for an exported report.


Crystal Reports Driver Guide - Export the Report in XML Format (Creating a Report and Defining the Report Properties)

Export the Report in XML Format

If ClearSCADA is to export a report in XML format, use the Format field on the Export Format tab to specify the XML format.

Example:

A report exported to XML Format:


Crystal Reports Driver Guide - Define the Export Destination for a Report (Creating a Report and Defining the Report Properties)

Define the Export Destination for a Report

You can export your reports to a variety of target destinations.

Use the Destination field on the Export Destination tab of the Crystal Report Form to define the export destination for each report.

Select a destination that applies to your system setup—in some cases, the appropriate third-party application has to be installed on the target machine(s) on your system, in order to export reports to the required target destination.

Choose from:

  • None—Select this option if:
  • The report is not to be exported to another destination

or:

  • ClearSCADA is configured to interface with Crystal Reports version XI release 2 and you want to Export the Report to another Database using ODBC (as the destination is specified as part of the export format).

For other export formats, you can choose whether to:

  • Export the Report to a File on a Disk
  • Export the Report in an E-Mail Message
  • Export the Report to Microsoft Exchange.

If ClearSCADA is configured to interface with Crystal Reports version XI release 2, you can also choose to:

  • Export the Report to Lotus Domino.

If you are going to export your reports, you should also Define the Export Format for a Report. The export format has to be compatible with the export destination (with the destination ‘None’ being specified for ODBC-exported reports).

ATTENTION: Be aware that the Crystal Reports driver is logged on as the ClearSCADA server’s Printing user when exporting reports. As such, the Printing user needs to have write access to the export destination. For further information, see Configuring Crystal Reports Server Settings, and the references above.

NOTE: The setting(s) specified on the Export Destination tab have no effect on the location of a report that is displayed on a WebX client.


Crystal Reports Driver Guide - Export the Report to a File on a Disk (Creating a Report and Defining the Report Properties)

Export the Report to a File on a Disk

You can export a report to disk automatically. You can use this feature to provide long-term offline storage of reports on a variety of devices, including removable hard disks, CD-Rs, CD-RWs, DVD-Rs, and DVD-RAM, depending on your system hardware.

If you are using this feature to store reports on removable media, the media has to be at the required location and available for use. For example, if the report is to be stored on a CD-R, you need to check that a CD-R is in the CD-RW drive of the server before a report is due to be exported.

To allow ClearSCADA to export a report to a file on a disk, you need to specify the File on Disk Destination on the Export Destination tab, and then use the tab to specify these properties:

  • File Name—Specify the name of the file to which the report is to be exported, including the full path to that file. The file name can be local to the main server, or a UNC path to a shared directory on another computer.

You can include trip sequences in the file name, in order to include specific report information—see Trip Sequences Supported by ClearSCADA. Use the Trip Sequence Time field to specify the date/time information that is to be included in any Date or Time trip sequences.

Example:

E:\Monthly Reports\%DMMM yyyy%\AreaA_Report.pdf

to export a report to a directory that indicates the month and year in which the export takes place. For example:

E:\Monthly Reports\Feb 2005\AreaA_Report.pdf

If you exclude the file extension, ClearSCADA will automatically add an extension appropriate to the format in which the file is being exported, when you save the configuration.

If you have chosen to Export the Report in HTML Format to a file on disk and ClearSCADA is configured to interface with Crystal Reports version 2008, ClearSCADA will:

  • Export the report to the file of the name specified in the File Name field
  • Place that file in a subfolder off the path specified in the File Name field. The subfolder will have the name ‘Report nnnn’, where nnnn is a random number.

ATTENTION: To export a report successfully, the server’s printing user has to have write access to the specified location. If the File Name field is used to specify a UNC path (such as \\Server\Monthly_Reports\AreaA_Report_%DyyMM%.pdf), the printing user has to have write access to the specified share and underlying folder. The printing user is the user that is specified in the Printing section of the ClearSCADA Server Configuration Tool (see Printer Settings in the ClearSCADA Guide to Server Administration).

  • Trip Sequence Time—Use to specify the time or date that ClearSCADA uses for any Date or Time trip sequences that are specified in the File Name field, above. Enter the time in the OPC Relative Time Format. (The default of NOW results in a time stamp based on ‘now’ exactly.)

For information on using this field, in conjunction with trip sequences, to produce the required date/time settings, see Specify the Trip Sequence Time.


Crystal Reports Driver Guide - Export the Report in an E-Mail Message (Creating a Report and Defining the Report Properties)

Export the Report in an E-Mail Message

ATTENTION: If an e-mail client is installed on the ClearSCADA server(s), you need to set it so that it does not request confirmation whenever an application attempts to send an e-mail (see The Server Fails to Export Reports via E-Mail). You may also want to check whether An Unused E-Mail Client on the Server is Storing Copies of E-Mailed Reports. (With systems on which ClearSCADA is configured to interface with Crystal Reports version 2008, these requirements only apply if reports are exported using Windows MAPI settings.)

You can attach a report to an e-mail and send that e-mail automatically to any User, User Group, or User Roster on your system. To use the e-mail facility, you need to check that:

  • The servers on your system are configured to send e-mail messages.

When interfacing with Crystal Reports version XI release 2, the ClearSCADA Server Configuration Tool’s E-Mail settings are not used for exporting reports via the Export Report pick action, instead the Crystal Reports driver uses the server’s Windows® MAPI settings. The location of the Mail applet used to specify the MAPI settings varies, depending on the Windows® operating system. For example, on a 32-bit computer running Windows XP, you can access the Mail applet directly from the Windows’ Control Panel. On a 64-bit computer running Windows Vista, you access the Mail applet from the Control Panel’s ‘View 32-bit Control Panel Items’ section. For more information, see the documentation for the relevant Windows® operating system.

For the servers to send e-mails, you have to set up mail for the Windows® user that is specified for printing on each server (the printing user is the user that is specified in the Printing section of the ClearSCADA Server Configuration Tool—see Printer Settings in the ClearSCADA Guide to Server Administration).

If ClearSCADA is configured to interface with Crystal Reports version 2008, you can specify whether reports are to be exported to e-mail using Windows MAPI settings (the default) or SMTP (see Configuring Crystal Reports Server Settings).

  • The users to which you want to send the e-mails have valid e-mail accounts. For information, see Creating a User Account in the ClearSCADA Guide to Security, and see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security.
  • The users can view the report in the format in which you are sending it.

To allow ClearSCADA to export a report via e-mail, you need to specify the E-Mail Destination on the Export Destination tab, and then use the tab to specify these e-mail properties:

  • To—Use to specify the name of the recipient of the e-mail. Select the browse button adjacent to the field to display a Reference browse window. Select the required User name, User Group, or User Roster from the window. Only users with an e-mail address are valid.

Use the adjacent E-Mail Contact combo box to specify to which e-mail account the report is to be sent. Each user can be allocated up to four e-mail addresses through which they can be contacted. Each address is allocated to a separate E-Mail Contact Account—see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security.

ATTENTION: To successfully export a report by e-mail to all of the users in a User Group or User Roster, each of those users must be configured to use the same e-mail contact number (1, 2, 3, or 4).

  • CC—Use to specify the names of any other Users, User Groups, or User Rosters to which a copy of the e-mail and attached report are to be sent.
  • Subject—Use to enter to title of the e-mail. You can include trip sequences in the Subject line, in order to include specific report information—see Trip Sequences Supported by ClearSCADA. Use the Trip Sequence Time field (see below) to specify the date/time information that is to be included in any Date or Time trip sequences.
  • Message—Use to enter the e-mail message. You can include trip sequences in the message content, in order to include specific report information—see Trip Sequences Supported by ClearSCADA. Use the Trip Sequence Time field (see below) to specify the date/time information that is to be included in any Date or Time trip sequences.

The Crystal Reports application determines the e-mail format (plain text or HTML). (The format settings for the recipient’s e-mail account in ClearSCADA do not apply to reports that are exported by e-mail.)

  • Trip Sequence Time—Use to specify the time or date that ClearSCADA uses for any Date or Time trip sequences that are specified in the Subject or Message fields, above.

Enter the time in the OPC Relative Time Format. (The default of NOW results in a time stamp based on ‘now’ exactly.)

For information on using this field, in conjunction with trip sequences, to produce the required date/time settings, see Specify the Trip Sequence Time.

Example:

A report that has its export Destination specified as E-Mail, and contains this configuration on the Export Destination tab of the Crystal Report Form:

is used to export reports as attachments to e-mails that contain this type of content:

Further Information

see User Accounts in the ClearSCADA Guide to Security.

see User Groups in the ClearSCADA Guide to Security.

see Configure a User Roster in the ClearSCADA Guide to Alarm Redirection.


Crystal Reports Driver Guide - Export the Report to Microsoft Exchange (Creating a Report and Defining the Report Properties)

Export the Report to Microsoft Exchange

Microsoft ExchangeTM is one of the components of Microsoft BackOfficeTM. Exchange can be used to manage group scheduling, Internet connections, e-mail, and electronic forms. If your organization uses Microsoft Exchange, you can choose to automatically export your reports as a Post Doc Message or, in the format that you specify, to a Microsoft Exchange Folder.

To allow ClearSCADA to export a report to Microsoft Exchange, you need to specify the Microsoft Exchange Destination on the Export Destination tab, and then use the tab to specify these properties:

  • Type—Use to specify the type of destination to which the report is to be exported.

Choose from:

  • Folder—The report is to be exported to a Microsoft Exchange folder. Use the Folder field (below) to specify the folder name and location.
  • Post Doc Message—The report is to be exported as a Post Doc message.
  • Folder—Only applicable when Type is set to ‘Folder’. Use to specify the path of the Exchange Folder to which the report is to be exported.

You can include Trip characters within the path name, in order to include specific report information—see Trip Sequences Supported by ClearSCADA. Use the Trip Sequence Time field (see below) to specify the date/time information that is to be included in any Date or Time trip sequences.

Once exported, the report can be accessed using a Microsoft Exchange client.

  • Profile—Specify an appropriate User Profile for ClearSCADA to use, in order to access the Exchange folder while the report is being exported.

Specify a user that has sufficient privileges.

  • Password—Specified the Password that is to be used in conjunction with the User Profile, to allow ClearSCADA to access the Exchange folder while the report is being exported.
  • Trip Sequence Time—Use to specify the time or date that ClearSCADA uses for any Date or Time trip sequences that are specified in the Folder field, above. Enter the time in the OPC Relative Time Format. (The default of NOW results in a time stamp based on ‘now’ exactly.)

For information on using this field, in conjunction with trip sequences, to produce the required date/time settings, see Specify the Trip Sequence Time.


Crystal Reports Driver Guide - Export the Report to Lotus Domino (Creating a Report and Defining the Report Properties)

Export the Report to Lotus Domino

NOTE: This destination option is only available if ClearSCADA is configured to interface with Crystal Reports version XI release 2.

If IBM’s Lotus DominoTM version 3.0 or later is used on your system, you can choose to export your reports to a Lotus Domino Form.

To export reports to Lotus Domino, you need to:

  • Have depositor or greater access
  • Create a Form in Lotus that:
  • Has the name Report Form
  • Includes a Comments field that you can edit
  • Has a View that has two columns—one named # and another that points to the Comments field.

To allow ClearSCADA to export a report to Lotus Domino, you need to specify the Lotus Domino Destination on the Export Destination tab, and then use the tab to specify these properties:

  • Database—Use to specify the name of the Lotus Notes database to which ClearSCADA is to export the report, including the full path to that database.
  • Form—Specify the name of the Lotus Notes Form that ClearSCADA is to use when exporting the report.
  • Comments—Specify any comments to include in the Comments field of the Form.

You can include Trip characters, in order to include specific report information—see Trip Sequences Supported by ClearSCADA. Use the Trip Sequence Time field (see below) to specify the date/time information that is to be included in any Date or Time trip sequences.

  • Trip Sequence Time—Use to specify the time or date that ClearSCADA uses for any Date or Time trip sequences that are specified in the Comments field, above. Enter the time in the OPC Relative Time Format. (The default of NOW results in a time stamp based on ‘now’ exactly.)

For information on using this field, in conjunction with trip sequences, to produce the required date/time settings, see Specify the Trip Sequence Time.


Crystal Reports Driver Guide - Trip Sequences Supported by ClearSCADA (Creating a Report and Defining the Report Properties)

Trip Sequences Supported by ClearSCADA

The export locations for a report, and the ODBC export format, support ‘Trip Sequences’ that allow you to specify:

  • A date, based on the date that the report is exported (see Specify a Trip Sequence for a Date)
  • A time, based on the time that the report is exported (see Specify a Trip Sequence for a Time)
  • The value(s) of a Parameter that is included in the report. This trip sequence only applies to reports that use Parameter Fields (see Specify a Trip Sequence for a Parameter)
  • Information about the report database item (see Specify a Trip Sequence for a Report Object).

For example, you might want to produce a monthly report in which the file name includes the month and year that the report covers. Or you might want to export a report to a location based on the report’s location in the ClearSCADA database.

You can enter any combination of trip sequences at any location within the file name, folder name, or subject line, and so on, that ClearSCADA uses when exporting your reports.

You can include character spaces within each trip sequence—these will be included in the final string when ClearSCADA replaces the trip sequence with the actual information.

You can also include additional string characters—such as commas—in a trip sequence. For example, %Dddd the dd of MMMM yyyy%. To include string characters that would otherwise appear as trip code, enclose the characters in single quotation marks, for example, ‘MM’ (to print the characters MM).

To include the export date or time, you specify the relevant date or time trip sequence along with the Trip Sequence Time, to define the time or date information that is to be included.

With each trip sequence, ClearSCADA replaces the trip sequence with the required information when it exports the report.

Further Information

Export the Report to another Database using ODBC.

Define the Export Destination for a Report.

Resolving any Trip Sequence Errors.


Crystal Reports Driver Guide - Specify a Trip Sequence for a Date (Creating a Report and Defining the Report Properties)

Specify a Trip Sequence for a Date

To specify a trip sequence for a date, you enter the trip code:

%D<format>%

where <format> is one or more of the Windows® picture string date formats that ClearSCADA supports (see Supported Trip Codes for Dates).

To specify the date that ClearSCADA substitutes for the trip code, you use the Trip Sequence Time field on the appropriate tab of the Crystal Report Form.

The default of NOW results in a time of ‘now’ exactly. If an offset time stamp is required, you can specify another time value in the OPC Relative Time Format.

For examples of how to use the Trip Sequence Time in conjunction with the trip sequences that you specify for your exported reports, see Specify the Trip Sequence Time.

For a detailed example that demonstrates how a Date trip sequence might be used to define the month for which a report contains data, see Specify a Trip Sequence for a Report Object.

Further Information

Resolving any Trip Sequence Errors.


Crystal Reports Driver Guide - Specify a Trip Sequence for a Time (Creating a Report and Defining the Report Properties)

Specify a Trip Sequence for a Time

To specify a trip sequence for a time, you enter the trip code:

%T<format>%

where <format> is one or more of the Windows® picture string time formats that ClearSCADA supports (see Supported Trip Codes for Times).

To specify the time that ClearSCADA substitutes for the trip code, you use the Trip Sequence Time field on the appropriate tab of the Crystal Report Form.

The default of NOW results in a time of ‘now’ exactly. If an offset time stamp is required, you can specify another time value in the OPC Relative Time Format.

For examples of how to use the Trip Sequence Time in conjunction with the trip sequences that you specify for your exported reports, see Specify the Trip Sequence Time.

Further Information

Resolving any Trip Sequence Errors.


Crystal Reports Driver Guide - Specify a Trip Sequence for a Parameter (Creating a Report and Defining the Report Properties)

Specify a Trip Sequence for a Parameter

NOTE: You can only use a Parameter trip sequence with a report that contains one or more Parameter fields (see Allow Users to Specify which Data is Included in a Report).

To specify a trip sequence for a Parameter, you enter the trip code:

%P<name>[.<sub-item>][;<format>]%

where:

<name> is the name of a Parameter field used in the report

<sub-item> can optionally be specified if the Parameter is a range Parameter (see Parameter Field). A range Parameter has two values—one that defines the start of the range, and another that defines the end of the range. With a range Parameter, you can either:

  • Omit the <sub-item> for ClearSCADA to replace the trip sequence with both Parameter values, separated by a space

or:

  • Specify the <sub-item> as:
  • Start for ClearSCADA to replace the trip sequence with the Parameter’s starting value

or:

  • End for ClearSCADA to replace the trip sequence with the Parameter’s ending value.

For examples of range Parameter trip sequences, see below.

ATTENTION: When a user exports a report and enters values for a range Parameter, they can optionally omit either the start (No Lower Bound) or end (No Upper Bound) value of the range. If both values are being used by a trip sequence, only a single value will replace the trip sequence if one of the bounds is omitted. If only one of the values is being used in the trip sequence and that value/bound is omitted, the report will still export, but the trip sequence will be replaced by nothing.

<format> is optionally used to control the appearance of the information that ClearSCADA substitutes in place of the Parameter’s trip sequence. You only need to specify a format if:

  • The format is to differ from the default for the type of Parameter

or if:

  • The Parameter is a Date Time, or Time Parameter (see Parameter Field) for which the default format includes a colon (:) (for instance to produce a time in the form 12:30:00)

and the trip sequence is:

  • Used to specify a file name (as a colon is not a valid character for a file name)

or:

  • Used elsewhere, where similar restrictions exist (for instance, if used to specify an ODBC Table name).

The custom formats that you can specify for a Parameter are the standard custom value formats that are supported by ClearSCADA (see Date and Time Syntax, see Numeric Syntax, see Text String Syntax, and see Boolean Syntax—these are sections in the ClearSCADA Guide to Core Configuration).

Examples:

A report uses a range Parameter named ‘MyRange’. The Parameter has a range of values, starting with the value ‘1’ and ending with the value ‘10’. The trip sequence %PMyRange% provides both values, in the form ‘1 10’. The trip sequence %PMyRange.Start% provides only the starting value ‘1’, and the trip sequence %PMyRange.End% provides only the end value ‘10’.

A report uses a range Parameter named ‘Time Range’. The Parameter is used to specify the time period for which data is included in the report. The trip sequence %PTimeRange.Start;d MMMM yyyy% is used to specify the earliest date for which data is included in the report. The format d MMMM yyyy sets the time to use the time and date form of: 5 September 2011.

A report includes a Parameter named ‘Number’. The Parameter is referenced in the trip sequence %PNumber;0.00%. The format 0.00 means that the Parameter’s value takes the form 1.30.

A report includes a Parameter named ‘SpecifyGroupName’. The Parameter is used to restrict the points included in the report to those in a specific database Group. The Group is specified when the report is exported. The File Name field on the report’s Export Destination tab is set to: \\GRBServer\\Reports\%PSpecifyGroupName% Points.pdf. This results in the exported report being assigned a name that indicates the Group to which the point data in the report is restricted.

Further Information

Resolving any Trip Sequence Errors.


Crystal Reports Driver Guide - Specify a Trip Sequence for a Report Object (Creating a Report and Defining the Report Properties)

Specify a Trip Sequence for a Report Object

You can use an Object trip sequence to specify information about the report database item itself (as opposed to the report’s content). This type of trip sequence can be used to include information on:

  • Any of the report’s properties in the ClearSCADA database
  • Any property of any database item that the report references directly (such as the report’s Parent Group)
  • Any property of any database item that the report references indirectly (such as the report’s Grandparent Group (the Group in which the report’s Parent Group is located)).

To specify the trip sequence for a report Object, you enter the trip code:

%O<field>[.<field>][;<format>]%

where:

the first <field> is one of the following:

  • A Reference field—A field that provides a link to an associated database item, such as a report’s parent Group (the database Group in which the report is located).

With a Reference field, you can optionally specify a further <field> in the referenced database item.

  • An Aggregate field—A field that provides a link to an associated ‘aggregate’, or tab on a database item’s configuration Form. For instance, the ExportFormat aggregate on the Crystal Report Form.

With an Aggregate field, you can optionally specify a further <field> in the referenced aggregate.

  • Any Configuration or Data field associated with the Crystal Report database item, or a database item that the report item references.

If <field> is a reference field or an aggregate field, then you can include further <field>(s) in the trip sequence, in order to specify further database item(s), that are themselves referenced by the database item listed in the preceding <field>.

Use the final <field> in the trip sequence to specify the required Configuration or Data field (OPC property) in the database item or aggregate that is specified in the preceding <field>.

<format> is optionally used to control the appearance of the information that ClearSCADA substitutes in place of the Object’s trip sequence. You only need to specify a format if:

  • The format is to differ from the default for the type of field. (For instance, with a trip sequence that queries a String field, ClearSCADA will supply the value of that field, using whatever capitalization that applies to the string’s value, unless you specify a different format, such as > to force the whole string to appear in upper case.)

or if:

  • The final field is a Time field for which the default format includes a colon (:) (for instance, to produce a time in the form 12:30:00)

and the trip sequence is:

  • Used to specify a file name (as a colon is not a valid character for a file name)

or:

  • Used elsewhere, where similar restrictions exist (for instance, if used to specify an ODBC Table name).

The custom formats that you can specify for an Object field are the standard custom value formats that are supported by ClearSCADA (see Date and Time Syntax, see Numeric Syntax, see Text String Syntax, and see Boolean Syntax—these are sections in the ClearSCADA Guide to Core Configuration).

You can ascertain the configuration, data, reference, and aggregate fields that you can specify using an Object trip sequence, along with an indication of each field’s type, using either of the following:

  • The database Schema (see Working with ClearSCADA Database Tables)
  • The OPC Data Bar.

You can also click on the relevant configuration field on a Form and observe its name and type in the Status Bar. (Remember that a field’s name often differs from the label that is shown for that field on the configuration Form. (The label is displayed in the language that is associated with the logged on user’s specified Locale.) It is a field’s name, rather than its label, that has to be specified in any Object trip sequence.) Data fields (and some Configuration fields, such as ParentGroupName) are not displayed on configuration Forms—use the database Schema or OPC Data Bar to ascertain information about such fields.

Examples:

%OParentGroupId.Name%
(Provides the name of the Group or Group Instance in which the report is located. For instance, ‘Zone 1’, for a report that is located in the Group ‘Zone 1’.)

%OParentGroupId.ParentGroupId.FullName%
(Provides the full name (including the path) of the report’s ‘grandparent’ Group or Group Instance—the Group or Group Instance in which the report’s Group or Group Instance is located. For instance, ‘My Database.Eastern Region’, for a report that is located in the Group ‘Zone 1’, which itself is within the Group ‘Eastern Region’. (With ‘Eastern Region’ being in the Group ‘My Database’.))

%OParentGroupId.AlarmRedirection.Trigger1%
(Provides the value of the Trigger1 property. ‘AlarmRedirection’ is the name of the field on the parent Group that links to the Alarm Redirection aggregate. Trigger1 defines the first Trigger State on the Alarm Redirection aggregate. (On the corresponding Form’s Redirection tab, ‘Trigger State’ is the label that identifies the column of trigger state fields—the label is displayed in the language that is associated with the logged on user’s specified Locale.) This trip sequence can only be used if a report’s parent Group has Alarm Redirection enabled.)

%OExportDestination.TripSequenceTime%
(Provides the value of the report’s Trip Sequence Time field (for instance ‘NOW’). ‘ExportDestination’ is the name of the field that links the report database item to its Export Destination aggregate. This is the aggregate that contains the Trip Sequence Time field. The example can only be used with a report that is configured with an export destination that includes a trip sequence.)

%OId;000000%
(Provides the report’s Id—the number that uniquely identifies the report in the ClearSCADA database. The 00000 formatting is included to force the Id to be displayed as a series of five digits (if the Id is smaller then five digits, it will be preceded by one or more zeros).)

A more detailed example is given below:

Example:

A particular ClearSCADA system is modular. Its database has been configured using a Group Template and a series of Group Instances. A report has been configured within the Group Template—each Instance of the report is used to list each of the items in that particular Group Instance.

Each Instance of the report is to be exported to a different location—the subdirectory to which each file is to be exported is to have the same name as the Group Instance that is associated with that particular report.

In the Group Template, the File Name field on the report’s Export Destination tab is used to specify the location to which the report is to be exported.

The File Name field includes a Parameter trip sequence to define the subdirectory to which each report is exported.

The File Name is specified as:

\\GRBServer\Reports\%OParentGroupId.Name%\%OName% - %DMMM yyyy%.pdf

This includes two occurrences of an Object trip sequence—one to specify the name of the Group (or Group Instance) in which the report is located, and the other to specify the name that the report item has been given in the ClearSCADA database.

The File Name also includes a Date trip sequence, %DMMM yyyy%, to specify the month for which each report contains data (see Supported Trip Codes for Dates). As the report for each month is exported at the start of the following month, the Trip Sequence Time is specified as MO-1D (the ‘last day of the previous month’), so that each report’s name correctly identifies the month for which it contains data.

A Schedule is used to export each report automatically at the start of each month. Within each Group Instance, each report is attached to its Schedule. The Group Instance to which each report’s content is to be restricted is specified as each report is attached to the Schedule (see Guidelines on Configuring Reports within Group Templates for an example that demonstrates this in more detail).

The name of the Group Instance is specified when each Instance of the report is added to the Instance of the Schedule.

When each report is exported using the Schedule, it is automatically exported to the subdirectory that has the same name as the Group Instance with which the report is associated. As such, in this example, the Regional Report for ‘Eastern Region’ is exported to the location \\GRBServer\Reports\Eastern Region\, while the Regional Report for ‘Northern Region’ is exported to the location \\GRBServer\Reports\Northern Region\, and so on.

The first Object trip sequence used in each report’s File Name field defines the subdirectory to which each Instance of the report is exported.
The second Object trip sequence is used to define the first part of the exported report’s name. The Date trip sequence defines the month for which data is included in the report. The date is also included in each report’s name.

Further Information

Use a Schedule to Trigger a Report on a Regular Basis.

Resolving any Trip Sequence Errors.


Crystal Reports Driver Guide - Supported Trip Codes for Dates (Creating a Report and Defining the Report Properties)

Supported Trip Codes for Dates

ATTENTION: Trip codes are case sensitive. When specifying trip codes, you should use the case indicated in the table below.

The format for a date trip sequence is %D<format>%, where <format> contains one or more of the trip codes listed below. The resulting date is affected by the Trip Sequence Time field on the Crystal Report Form (see Specify the Trip Sequence Time).

ClearSCADA supports these trip codes for date strings within exported reports:
Trip Sequence | Description | Example
d | The day of the month as a digit. No leading zeros are included for single-digit days. | 3 (for the third day in a month)
dd | The day of the month as a digit.Leading zeros are included for single-digit days. | 03 (for the third day in a month)
ddd | The day of the week, abbreviated to three letters. | Tue (for Tuesday)
dddd | The full name for the day of the week. | Tuesday
M | The month as a digit.Leading zeros are excluded for single-digit months. | 4 (for April)
MM | The month as a digit.Leading zeros are included for single-digit months. | 04 (for April)
MMM | The month, abbreviated to three letters. | Aug (for August)
MMMM | The full name for the month. | August
y | The last two digits of the year. Leading zeros are not included for years below 10. | 5 (for the year 2005)
yy | The last two digits of the year. Leading zeros are included for years below 10. | 05 (for the year 2005)
yyyy | The year, presented as four digits. | 2005
gg | The era. | AD

Examples:

The code
%Dd MMM yy%

displays a date in the form
2 May 05
(to display the date of the month as two digits, you would use dd, rather than d)

The code
%Dddd, dd MMMM%

displays a date in the form
Fri, 04 March


Crystal Reports Driver Guide - Supported Trip Codes for Times (Creating a Report and Defining the Report Properties)

Supported Trip Codes for Times

ATTENTION: Trip codes are case sensitive. When specifying a trip code, you should use the case indicated in the table below.

The format for a time trip sequence is %T<format>%, where <format> contains one or more of the trip codes listed below. The resulting time is affected by the Trip Sequence Time field on the Crystal Report Form (see Specify the Trip Sequence Time).

ClearSCADA supports these trip codes for time strings within exported reports:
Trip Sequence | Description | Example
h | The hour in the day, using a 12-hour clock. Leading zeros are excluded for single-digit hours. | 3 (for 3am or 3pm)
hh | The hour in the day, using a 12-hour clock. Leading zeros are included for single-digit hours. | 03 (for 3am or 3pm)
H | The hour in the day, using a 24-hour clock. Leading zeros are excluded for single-digit hours. | 3 (for 3am) 15 (for 3pm)
HH | The hour in the day, using a 24-hour clock. Leading zeros are included for single-digit hours. | 03 (for 3am) 15 (for 3pm)
m | The minutes past the hour. Leading zeros are excluded for single-digit minutes. | 4 (for four minutes past the hour)
mm | The minutes past the hour. Leading zeros are included for single-digit minutes. | 04 (for four minutes past the hour)
s | The seconds past the minute. Leading zeros are excluded for single-digit seconds. | 9 (for nine seconds)
ss | The seconds past the minute. Leading zeros are included for single-digit seconds. | 09 (for nine seconds)
t | A one-character string, A or P, to indicate whether the time is before or after midday. | A (to indicate that a time is before midday)
tt | A two-character string, AM or PM, to indicate whether the time is before or after midday. | AM (to indicate that a time is before midday)

Example:

The code
%THH:mm:ss%

displays a time in the form
14:25:06


Crystal Reports Driver Guide - Specify the Trip Sequence Time (Creating a Report and Defining the Report Properties)

Specify the Trip Sequence Time

You specify the time or date by using the Trip Sequence Time field on the appropriate tab of the Crystal Report Form. You specify the time in the OPC Relative Time Format.

The default of NOW results in a time of ‘now’ exactly.

For some reports, you may want to specify an offset time:

Example:

On a ClearSCADA system, reports for the previous month are generated at the start of the following month.

The reports are exported to CD and then stored in the company archives.

The directory into which each report is archived indicates the year for which the report data corresponds. The file name of each report includes the month and year for which the report data corresponds. The directory and file name are specified using a trip sequence:

E:\Reports\%Dyyyy%\Report for %DMMM yyyy%

(where Report for %DMMM yyyy% is the name of the report)

As the reports for February are exported at the beginning of March, and the reports for March are exported at the beginning of April, and so on, a Trip Sequence Time of NOW would result in the reports for February being exported with a March file name.

In order to export the reports with the appropriate file name, the Trip Sequence Time is specified as:

MO-1D

(the last day of the previous month)

This results in reports containing February’s data (which are exported at the start of March) being exported with a February file name (as the date with which ClearSCADA replaces the trip sequence %DMMM yyyy% is calculated using the last day of the previous month as the time source).

For further examples on using the OPC Relative Time format, and the time units that you can use to specify the Trip Sequence Time, see OPC Relative Time Format in the ClearSCADA Guide to Core Configuration.


Crystal Reports Driver Guide - Specify Whether a Report is to be Made Available for Display in WebX (Creating a Report and Defining the Report Properties)

Specify Whether a Report is to be Made Available for Display in WebX

NOTE: The settings on the Generate for WebX tab are completely independent of the settings on the Export Format and Export Destination tabs. The latter tabs have no effect on the format or destination of a report that is accessed via a WebX client.

Use the check box on the Crystal Report Form’s Generate for WebX tab to specify whether the latest report is to be made available for display on WebX clients.

If you do not need to display a report in WebX, clear the check box (this is the default setting). Generated reports can only be displayed on ViewX clients.

Select the Enabled check box if users are to be able to display the latest report from a WebX Client. (ViewX has to be used to display any reports that are stored historically—only the latest generated version of a report can be viewed from a WebX client.) Whenever the Generate Report pick action is used to produce a report, ClearSCADA will additionally produce a copy of the report in printable PDF format. Users with the relevant permissions will be able to use the Display pick action on a List or Mimic, or select the report name hyperlink on the database browser, to view the PDF version of the report on a WebX client. Adobe® Reader® has to be installed on the WebX client, in order to display the report.

ATTENTION: Enabling large or complex reports to be displayed via a WebX client can place extra demand on the system resources required to generate such reports.

Further Information

Display a Report in WebX: see View the Most Recently Generated Version of a Report on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


Crystal Reports Driver Guide - Configuring the Report Structure and Basic Content

Configuring the Report Structure and Basic Content

Once you have produced an initial report by Creating a Report and Defining the Report Properties, you need to specify the report ‘definition’—the structure and the type of data that you want to include in the report. To do this, you use the Crystal Reports application.

ATTENTION: You generally edit reports on a ViewX client (workstation). To update a report in the ClearSCADA database, ViewX must remain running while the report is being edited in the Crystal Reports application. As each report must be saved using its original file name, we advise that you use the Crystal Reports’ Save, rather than the Save As option, to store your reports.

The topics covered in this section comprise:

  • How to Launch the Crystal Reports Application
  • Understand the Crystal Reports Work Areas
  • Basic Configuration
  • Specify the Page Setup
  • Decide Whether to Refresh Data or Use Saved Data
  • Save Configuration Changes.

Use this section in conjunction with the documentation supplied with the Crystal Reports application, for help on producing reports.


Crystal Reports Driver Guide - Launch the Crystal Reports Application (Configuring the Report Structure and Basic Content)

Launch the Crystal Reports Application

To launch the Crystal Reports application from within ClearSCADA, either:

  1. Double-click on the Report entry within the Database Bar (if you are logged on as a user that has the Double Click Edits Documents feature).

Or:

  1. Either:
  • Right-click on the Report entry within the Database Bar.

or:

  • Select the required Report entry on a List.

or:

  • Select an animated representation of the report on a Mimic.

A context sensitive menu is displayed.

  2. Select the Edit option.

The Crystal Reports application window overlays the ClearSCADA window (see Understand the Crystal Reports Work Areas).


Crystal Reports Driver Guide - Understand the Crystal Reports Work Areas (Configuring the Report Structure and Basic Content)

Understand the Crystal Reports Work Areas

The basic work areas in the Crystal Report application are as follows:

Work on the Design tab when making any changes to your report. (Or the relevant subreport tab if you are making changes to the structure of a subreport (a subreport is a report within a report).
Use the Report Header area to include any information that you want to display at the start of your report. The information that you include here is only displayed on the front page of your report.
Use the Page Footer area for any information that you want to display at the bottom of each page of your report.
Use the Report Footer area for any information that you want to display at the very end of your report. The information that you include here is only displayed on the last page of your report.
Use the Page Header area for any information that you want to display at the top of each page of your report.
Use the Details area to define what data is to be included in your report, and how each data entry is displayed. The information that you include here defines what information is included for each data record in your report.

You can include multiple headers and footers in a report—for example, a left page footer and a right page footer. See the documentation supplied with the Crystal Reports application for details.

You can also optionally include one or more Group headers and footers—one for each Group Name Field that you use to group the data in your report.

ATTENTION: If you are going to export a report in one of the programmatic formats, such as Separated Value format, only include content in data fields. The export process for programmatic formats treats fields as records and will export multiple copies of any headers, footers, field titles, and so on.

Example:

A report containing this configuration...

The fields that are included in the Details area of the report...
‘Fields’ that have been added to the report.

...is used to produce a report with this layout:

...define the information that is displayed for each of the records that are included in the report.


Crystal Reports Driver Guide - Basic Configuration (Configuring the Report Structure and Basic Content)

Basic Configuration

ATTENTION: Do not use the Report Creation Wizards in Crystal Reports XI or 2008 (except for adding any subreports) as these produce new reports that cannot be saved in the ClearSCADA database. Instead, you use a series of ‘Expert’ windows that allow you to configure various features in your reports.

You should configure your primary reports using the Design tab of the Crystal Reports application. You can view the resulting report layout using the Preview tab (you will need to retrieve the ClearSCADA data in order to view the resulting report—see Decide Whether to Refresh Data or Use Saved Data). (If your reports include subreports, configure the ‘definition’ of each subreport using the relevant subreport tab. You can Use a Subreport to Include Unrelated Data in the Same Report.)

When configuring large or complex reports, or reports that query historic table(s), take care to adhere to the Important Guidelines on Configuring and Generating Reports. Inappropriately configured reports, especially complex reports, can affect system performance.

You can add static text, lines, charts, maps, pictures and so on, to your reports. You can use rulers, guidelines, and grids to help you to align the elements that you add to your reports. For information, see the documentation supplied with the Crystal Reports application.

To produce much of the report content within the Design tab, you add fields to your reports (typically by ‘dragging’ them from the Field Explorer Bar). For information on how to use fields to display ClearSCADA data, see Adding Fields and Data to a Report. For further information on configuring fields, see the documentation supplied with the Crystal Reports application.

In order to add the required information to your reports, you need to have an understanding of the ClearSCADA database structure, and an appreciation of the naming conventions used for ClearSCADA database tables and fields (see Working with ClearSCADA Database Tables).

ATTENTION: To update a report in the ClearSCADA database, ViewX must remain running while the report is being edited in the Crystal Reports application. As each report has to be saved using its original file name, we advise that you use the Crystal Reports’ Save, rather than the Save As option, to store your reports.

For further information and examples on using reports to display ClearSCADA data, see as appropriate:

  • Configuring a Report that Queries a Historic Table
  • Configuring Reports within Group Templates
  • Example Reports.


Crystal Reports Driver Guide - Specify the Page Setup (Configuring the Report Structure and Basic Content)

Specify the Page Setup

If you want your reports to be landscape rather than portrait, you need to specify the settings that you require within the Crystal Reports Page Setup.

You can print your reports directly from the Crystal Reports application, or from ViewX.

Whenever you print your reports directly from the Crystal Reports application, you need to specify the page setup and printer using the options in Crystal Reports’ File menu.

(When you print your reports on the server, using the Print Report pick action, the server uses the print settings that you specify on the Crystal Reports tab of the Crystal Report Form (see Configure the Report Properties). Whenever you use the Crystal Reports Viewer to display a previously generated report in ViewX, and then choose to print that report, you specify the print settings using the Print Setup option, available from the ViewX File menu. You then use ViewX’s Print menu option or toolbar button to print the report. (For more information on using the Viewer, see Using the Crystal Reports Viewer.))


Crystal Reports Driver Guide - Decide Whether to Refresh Data or Use Saved Data (Configuring the Report Structure and Basic Content)

Decide Whether to Refresh Data or Use Saved Data

When viewing a report using the Preview tab, you may be asked whether you want the report to be populated with previously saved data or if you want to refresh the data.

If you Refresh the data, the Crystal Reports application retrieves fresh data from the ClearSCADA server—with large or complex reports, this may take some time, and may have an adverse affect on the system communications (see Important Guidelines on Configuring and Generating Reports).

If you choose to use saved data, the Crystal Reports application uses the data that it last retrieved for the report and does not access the server again before re-displaying the report. Using saved data in this way is often sufficient when checking out changes that are being made to report configuration, and avoids disrupting system communications unnecessarily.

ATTENTION: Turn off the Save Data with Report option (File menu) when you have finished editing a report. This helps to prevent ‘old’ data from being stored with a report.


Crystal Reports Driver Guide - Save Configuration Changes (Configuring the Report Structure and Basic Content)

Save Configuration Changes

You generally edit reports on a ViewX client (workstation). When you edit a report, ensure that you select Save, rather than Save As, to ensure that any changes that you make are stored in the ClearSCADA database.

ATTENTION: ViewX needs to be running on clients that are being used to edit Crystal Reports. If ViewX is not running, any changes made to that report could be lost (as ViewX transfers the changes back to the server database when the Save option is selected.) If ViewX is closed while editing a report, it is possible to recover any changes that were made to the report after ViewX was closed (see Retain the Latest Changes to a Report Should ViewX be Closed).

ATTENTION: Do not use the Report Creation Wizards in Crystal Reports XI or 2008 (except for adding any subreports) as these produce new reports that cannot be saved in the ClearSCADA database. Instead, you use a series of ‘Expert’ windows that allow you to configure various features in your reports.


Crystal Reports Driver Guide - Accessing the ClearSCADA Database

Accessing the ClearSCADA Database

In order to display ClearSCADA data in a report, the Crystal Reports application needs to access the ClearSCADA database. This access is made using an ODBC connection to the main server (see Connect to the ClearSCADA Database). You need to specify this ODBC connection for each report on your system. (If your reports include subreports, you also need to specify the relevant ODBC connection for each of those subreports.)

You also need to specify the database tables that each report and subreport is to access (see Provide Access to the Relevant Database Tables).

If a report references more than one table, you need to Specify the Links Between Multiple Tables, or Use a Subreport to Include Unrelated Data in the Same Report.

In order to reference the relevant database tables and include the required ClearSCADA data in your reports, you need to be familiar with the ClearSCADA database structure and naming conventions—this information is covered in detail in the ClearSCADA Guide to the Database. For a summary of the ClearSCADA database structure, and information on using database tables in reports, see Working with ClearSCADA Database Tables.

If required, you can include ‘custom’ database tables, such as Data Grids, in your reports (see Custom Tables and Fields). We do not recommend renaming or removing fields from a Data Grid Table that is used in a report. However, you can reflect renaming and removal changes by re-mapping the table data in the Crystal Reports application (see Map Field Changes to a Custom Table).


Crystal Reports Driver Guide - Connect to the ClearSCADA Database (Accessing the ClearSCADA Database)

Connect to the ClearSCADA Database

In order to use ClearSCADA data in a report, the Crystal Reports application needs to access the ClearSCADA database. In order to do this, you need to specify an ODBC connection to the database. You need to specify this connection whenever you create a report or subreport.

NOTE: A system administrator needs to set up one ODBC DSN per ClearSCADA database when ClearSCADA and Crystal Reports are first installed (see Installation on ViewX Clients on Which You Want to Edit Reports).

To specify an ODBC connection to the ClearSCADA database from a report that is being produced using Crystal Reports:

  1. View your report on the Design tab of the Crystal Reports application (or, in the case of a subreport, the relevant subreport tab).
  2. Select the Database menu.
    A context sensitive menu is displayed.
  3. Select the Database Expert option.
    The Database Expert window is displayed.
  4. Expand the Create New Connection entry in the list of Available Data Resources.
  5. Expand the ODBC (RDO) entry.
    If a connection already exists to the ClearSCADA database, an appropriate entry will be displayed here—see Provide Access to the Relevant Database Tables. If no connection exists, the ODBC (RDO) window is displayed.
  6. Select the required entry from the Data Source Name list (the required DSN may, for example, be labelled to reflect the name of your system or site—see your system administrator for details).
  7. Select the Next button.
    The Connection Information page is displayed.
  8. Specify the User ID (name) and Password that allow the Crystal Reports application to access the ClearSCADA database.

This would typically comprise the ClearSCADA logon name and password of the User that is specified on the Crystal Report tab of the Crystal Report Form (if any), but may comprise any other name and password combination that provides sufficient access to the ClearSCADA database.

The User ID and Password combination that you specify determines what data is included in the report. (The report can only include ClearSCADA data to which this user account has access.)

Be aware that if the User ID differs to that specified on the Crystal Report Form (see Specify the Data Source), the report may differ in content whenever it is generated, printed, or exported, as to when the report is being edited.

  9. Select the Finish button.
    The ODBC (RDO) window is closed. The ClearSCADA DSN is added to the list of ODBC (RDO) database connections.

The expanded ClearSCADA entry displays a hierarchical list of ClearSCADA data sources. The list varies, depending on the drivers that are installed on your system. Any custom database tables, such as Data Grid tables, are included in the list.

  10. Expand the list of ClearSCADA data sources as required.
    A list of the database tables applicable to that particular component or driver is displayed.
    The ClearSCADA DSN that enables Crystal Reports to access the ClearSCADA database via ODBC (the name may differ on your system).
    The ClearSCADA data sources and database tables that can be selected for use with Crystal Reports (the entries vary, depending on the drivers that are installed on your system).

  11. Specify which tables you want to use in the report (see Provide Access to the Relevant Database Tables).
  12. Select the OK button to confirm the settings.
    The Database Expert window is closed.


Crystal Reports Driver Guide - Provide Access to the Relevant Database Tables (Accessing the ClearSCADA Database)

Provide Access to the Relevant Database Tables

In order for the Crystal Reports application to access the data that you want to use in a report, you need to specify the ClearSCADA database tables with which that data is associated. You need to do this on a per report basis.

To specify the database table(s) that you want to use in a report that is being produced using Crystal Reports:

  1. View your report on the Design tab of the Crystal Reports application (or, in the case of a subreport, the relevant subreport tab).
  2. Use the Database menu to display the Database Expert window (for information on accessing this window, see Connect to the ClearSCADA Database).
  3. Expand the ODBC (RDO) entry in the tree-structure.
    The ClearSCADA DSN is displayed (if no connection exists to the ClearSCADA database, see Connect to the ClearSCADA Database).
  4. If necessary, expand the ClearSCADA entry.
    A hierarchical list of existing ClearSCADA data sources is displayed.
  5. Expand the list of ClearSCADA data sources as required. (For instance, if the DNP3 driver is installed on your system and your report is to reference a particular DNP3 table, expand the DNP3 entry to access the list of tables that exist on that driver—each driver has a separate table for each type of database item that it supports.)
    The lists of ClearSCADA data sources (the entries vary, depending on the drivers that are installed on your system).
    Expand the relevant entry (such as that for a particular driver)...
    ... to display the list of database tables that can be selected for use with Crystal Reports.

In addition to driver-specific categories, the ClearSCADA data sources include three ‘generic’ categories for non-driver-specific database tables: Core, Historic, and HistoricView.

  6. Select the table(s) that you require.
    The selected table(s) are highlighted.

In many cases, you may only need to select a single database table.

However, for complex reports, or reports that query historic data, you may want to specify several tables, in order to include data for the type(s) of item for which you want to produce a report. In such cases, you will need to Specify the Links Between Multiple Tables.

To include data from unrelated tables, consider whether to Use a Subreport to Include Unrelated Data in the Same Report, a ClearSCADA Data Grid, or a ClearSCADA Data Table (see Custom Tables and Fields).

NOTE: You can use standard key combinations, such as the CTRL and SHIFT keys, to select multiple table entries. For further information on selecting tables for use in reports, see the documentation supplied with the Crystal Reports application.

  7. Use the Right Arrow button to add the table(s) to the Selected Tables list.
    The ClearSCADA database table(s) that you specify, are added to the Selected Tables list.

  8. Repeat Step 6, as required.
  9. If your report is to access more than one database table, you need to Specify the Links Between Multiple Tables.

To include data from unrelated tables, consider whether to Use a Subreport to Include Unrelated Data in the Same Report, a ClearSCADA Data Grid, or a ClearSCADA Data Table (see Custom Tables and Fields).

  10. Select the OK button to confirm the settings.
    The Database Expert window is closed.

The database tables are now available for selection from the Field Explorer Bar in the Crystal Reports application, enabling you to Add a Field to a Report.


Crystal Reports Driver Guide - Specify the Links Between Multiple Tables (Accessing the ClearSCADA Database)

Specify the Links Between Multiple Tables

In many cases, you will probably only access one ClearSCADA database table per report. However, with more complex reports, such as reports that query historic table(s), you may want to access more than one database table per report. In such cases, you need to specify the relationship between those tables.

In order to link the records in one table with the records in another table, you need to specify which table properties the Crystal Reports application is to use to match both sets of records. (To include data from unrelated tables, consider whether to Use a Subreport to Include Unrelated Data in the Same Report, a ClearSCADA Data Grid, or a ClearSCADA Data Table (see Custom Tables and Fields).)

ATTENTION: We advise that you only use Id numbers for linking database tables in reports and not for any means of filtering, sorting, or otherwise restricting the report content.

Once you Provide Access to the Relevant Database Tables, use this procedure to specify the links between the tables:

  1. View your report on the Design tab of the Crystal Reports application.
  2. Use the Database menu to display the Database Expert window (for information on accessing this window, see Connect to the ClearSCADA Database).
  3. Select the Links tab.
    The tables that have been specified for the report are shown, with suggested or existing link(s).
  4. Adjust the link(s) between the tables, as necessary.

If the suggested link(s) are incorrect, use the Clear Links or Delete Link buttons to clear the links, then either select an Auto-Link and select the Link button, or manually create a link by dragging from a field in one table over to the required field in another table.

You can only link fields that are ‘keys’ which appear in both tables. Typical ‘keys’ that you can use to link ClearSCADA database tables include the Id and FullName fields. For more information on creating and removing links, see the documentation supplied with the Crystal Reports application.

Example:

In a report that queries both the CDBHistoric and CDBPoint tables, you would choose to link the tables by Id.

(Colored ‘Index Legend’ symbols (shown as red symbols in the above example) indicates the keys that exist in each table—you typically only link those key fields that appear in both tables.)

  5. Select the OK button to confirm the changes.
    The Database Expert window is closed.


Crystal Reports Driver Guide - Working with ClearSCADA Database Tables

Working with ClearSCADA Database Tables

The ClearSCADA database comprises a series of Classes. The classes are arranged in a hierarchical structure, such that one class can be derived from another class (known as its parent class).

Each class contains a collection of Fields and Aggregates (or ‘extension’ classes). The database structure is organized such that the base class contains common fields, and each subclass contains fields common to that subclass, and so on, until you reach a level of subclass that contains fields that are specific to a particular type of item within the database. For further information, see Understanding the Database in the ClearSCADA Guide to the Database.

Example:

A DNP3 Analog Input point is a point that supports current and logged data, and is associated with the DNP3 advanced driver. The class structure takes into account these aspects and the database class CDNP3AnalogIn, which is specifically associated with DNP3 Analog Input points, is derived from a hierarchy of other classes:

The CDBObject class is the base class for items in the ClearSCADA database. It contains common configuration fields such as ‘TypeDesc’.
The CDNP3AnalogIn class is the subclass that contains fields specific to DNP3 Analog Input points. It includes the ‘ProcessDNP3OverrideFlag’ and ‘ScaleType’ configuration fields.
The CDNP3Point class is the subclass that is common to DNP3 points. It contains the ‘Historic’ aggregate.
The CAdvPointCDRLog class is the subclass that is common to advanced driver points that support current and logged data. It contains data fields such as ‘LoggedReason’.
The CAdvPoint class is the subclass that is common to advanced driver points. It contains data fields such as ‘PreviousTimeInvalid’.
The CDBPoint class is the subclass that is common to database points. It contains configuration fields such as ‘Source’.
The CAlarmObject class is the subclass that is common to database items that support alarms. It contains configuration fields such as ‘AlarmViewName’, and the ‘AlarmRedirection’ aggregate.

Within the ClearSCADA database, classes are grouped into Tables, with each table comprising a class and that class’s base classes. As such, each table contains the Fields and Aggregates that are associated with those classes. The next section summarizes what you need to take into account when Using Database Tables within Crystal Reports. Also included is a section on The Naming Convention used for Database Tables.

You can also add ‘custom’ tables to the ClearSCADA database and include those tables in your reports (see Custom Tables and Fields).


Crystal Reports Driver Guide - Using Database Tables within Crystal Reports (Working with ClearSCADA Database Tables)

Using Database Tables within Crystal Reports

When producing a Crystal Report, you need to specify the ClearSCADA table(s) that contain the fields that you want to display in that report (see Provide Access to the Relevant Database Tables).

In order to ascertain which database table(s) you need to add to a report, you need to use Internet Explorer to display the ClearSCADA Database Schema (see Access the Database Schema in the ClearSCADA Guide to the Database). From there, you can ascertain which fields and therefore which table(s) you need to add to your report(s).

You can add a single database table or multiple tables to each report. Typically, reports that query historic data reference two or more tables, whereas other reports typically reference a single table.

Example:

Taking into account the class structure given in the example above (see Working with ClearSCADA Database Tables), the database tables that contain information about DNP3 Analog Input points include:

CDBObject—The base table that contains information that is common to items in the database.

CAlarmObject—This table includes information that is common to items that support alarms in the database. It is inclusive of the information in the CDBObject table, with the addition of alarm information. The table entries are therefore limited to those for items that support alarms.

CDBPoint—This table includes information that is common to points in the database. It is inclusive of the information in the CAlarmObject table, but the table entries are limited to, and include additional information on, all points in the database.

CAdvPoint—This table includes information that is common to advanced driver points in the database. It is inclusive of information in the CDBPoint table, but the table entries are limited to, and include additional information for, points on advanced drivers.

CAdvPointCDRLog—This table includes information that is in the CAdvPoint table, with the addition of information that is specific to advanced driver points that support current and logged data. The table entries are therefore limited to those types of point.

CDNP3Point—This table includes the information that is in the CAdvPointCDRLog table, with the addition of DNP3-specific point information. The table entries are therefore limited to those for DNP3 points.

CDNP3AnalogIn—This table includes the information that is in the CDNP3Point table, with the addition of DNP3 analog input-specific information. The table entries are therefore limited to those for DNP3 Analog Input points.

In addition to the above, there are various other database tables that can prove useful for reporting point data. For example:

CDBHistoric—This table contains information on data that has been stored historically within ClearSCADA. Use this table with care.

CDBEventJournal—This table contains information on the events that have been logged in ClearSCADA. Use this table with care.

If more that one table is used for a report, you need to specify how the tables relate to each other (see Specify the Links Between Multiple Tables).

For complex reports, you may want to consider using Data Grids (see Custom Tables and Fields).

For reports that contain more than one query, such as reports that query several unrelated database tables, use subreports in those reports. For an example that demonstrates the use of subreports, see Use a Subreport to Include Unrelated Data in the Same Report.

Further Information

The Naming Convention used for Database Tables.


Crystal Reports Driver Guide - The Naming Convention used for Database Tables (Working with ClearSCADA Database Tables)

The Naming Convention used for Database Tables

Many tables in the ClearSCADA database start with the letter C.

Tables that contain general, rather than driver-specific information are sometimes prefixed with the letters CDB.

Example:

The table CDBObject contains fields that are common to the items in the ClearSCADA database. For example, Name, FullName, and ConfigValid (which indicates whether the item has valid configuration).

The table CDBPointSource contains information about the source of each point in the database (the source is typically the outstation, PLC, or scanner with which a point is associated).

(When you use Crystal Reports’ Database Expert window to specify which table(s) a report is to reference, you will need to expand the Core, Historic, or HistoricView entry in the list of ClearSCADA data sources, in order to display the lists of ‘generic’ tables—tables that contain general, rather than driver-specific information (see Provide Access to the Relevant Database Tables).)

Tables that contain driver specific-information are prefixed with the letter C, and are generally followed by the driver name.

Example:

The table CDNP3Point contains fields that are associated with the various types of DNP3 point.

The table CDNP3ChannelDirect contains fields that are associated with DNP3 Direct Channels.

(When you use Crystal Reports’ Database Expert window to specify which table(s) a report is to reference, you will need to expand the driver entry in the list of ClearSCADA data sources, in order to display the list of tables that are associated with a particular driver (see Provide Access to the Relevant Database Tables).)

Typically, the more specific the table name, the more specific the information that the table contains.

Take care when adding tables to Crystal Reports, and only select those table(s) that are the most appropriate. Use the Database Schema (see Access the Database Schema in the ClearSCADA Guide to the Database) for reference when choosing the table(s) that you require for your reports.

Further Information

Custom Tables and Fields.


Crystal Reports Driver Guide - Custom Tables and Fields (Working with ClearSCADA Database Tables)

Custom Tables and Fields

NOTE: If you add a custom field to a table that is already used in a report, you may need to refresh the report data in order to access the new field within Crystal Reports’ Field Explorer Bar.

You can add ‘custom’ tables, such as Data Tables, Data Grids, and Historic Views, to the ClearSCADA database. We advise that such tables are given names that start with letters other than C or CDB, to differentiate them from ‘standard’ tables.

You can use ‘custom’ tables in your reports, in a similar way to ‘standard’ tables.

Using a ‘custom’ table can reduce the time that it takes to configure a report using the Crystal Reports application.

A Historic View, for instance, can be used to allow Crystal Reports to access sampled historic ClearSCADA data. A Historic View represents a specific calculation (for example, the average of a set of values) and includes a resample interval and time period over which historic data is sampled. You can display the results of the calculation in a report—for example, the average value of a particular point at 4-hourly intervals over the past week. For information on setting up Historic Views, see Historic Views in the ClearSCADA Guide to Server Administration. A Historic View table exists in the database for each Historic View that has been configured on your system. For further information on each table, see the database Schema. For information on using the Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.

A Data Grid, is typically used to extract data from multiple database items into a single table, which is simple and efficient to query from a report. ClearSCADA can perform a variety of calculations on values in the database, the results of which populate the Data Grid. The Data Grid values can then be displayed in a report, in the same way as data from ‘standard’ tables. For further information, see Configuring Data Grids in the ClearSCADA Guide to Core Configuration. For an example of how a Data Grid can be used in a report, see Embedded Data Grid Content.

A Data Table is typically used to store data from multiple sources in a single table. The Data Table’s values can then be displayed in a report, in the same way as data from ‘standard’ tables. For further information, see Configuring Data Tables in the ClearSCADA Guide to Core Configuration.

NOTE: We do not recommend renaming or removing fields from a ‘custom’ Table, after that table has been attached to a report. However the table data can be re-mapped within the Crystal Reports application to reflect changes (see Map Field Changes to a Custom Table).

The topics in the rest of this section contain further information on using custom fields. The topics comprise:

  • Custom Configuration Fields
  • ClearSCADA Parameters
  • Custom Data Fields
  • Custom Fields in Reports.


Crystal Reports Driver Guide - Custom Configuration Fields (Working with ClearSCADA Database Tables)

Custom Configuration Fields

You can add ‘custom’ configuration fields to the ClearSCADA database—for example, you might add a custom ‘Description’ field to the points in your system.

You can include the data from such ‘custom’ fields in your reports, in the same way as other fields. Custom fields are listed in the Database Schema and are displayed alongside other Database fields in Crystal Reports’ Field Explorer Bar.

For information on configuring ‘custom’ configuration fields in ClearSCADA, see Extra Database Fields in the ClearSCADA Guide to Server Administration.


Crystal Reports Driver Guide - ClearSCADA Parameters (Working with ClearSCADA Database Tables)

ClearSCADA Parameters

You can add Parameter database items to ClearSCADA. You can use such Parameters for storing static data values, such as map grid references. Parameters are internal to ClearSCADA and are designed to store data that is not directly associated with other items in the database (such as individual points, outstations, or scanners). You can use Parameters as an alternative to Custom Configuration Fields, if the values that need storing are not directly associated with other items in the ClearSCADA database.

To include ClearSCADA Parameter data in your reports, you need to either include the Parameters in a Data Grid, or as a subreport (see Use a Subreport to Include Unrelated Data in the Same Report).

For more information on configuring ClearSCADA Parameters, see Using Parameters to Store Static Data Values in the ClearSCADA Guide to Core Configuration.

NOTE: Do not confuse ClearSCADA Parameters with Crystal Reports’ Parameters (see Parameter Field).


Crystal Reports Driver Guide - Custom Data Fields (Working with ClearSCADA Database Tables)

Custom Data Fields

You can add ‘custom’ data fields to points in the ClearSCADA database—for example, you might add a custom ‘ExportTime’ field to the points in your system, in order for an external application to assess the period for which it is to export point data.

You can include the data from such ‘custom’ fields in your reports, in the same way to other fields. Custom fields are listed in the Database Schema and are displayed alongside other Database fields in Crystal Reports’ Field Explorer Bar.

For information on configuring ‘custom’ data fields in ClearSCADA, see Extra Database Fields in the ClearSCADA Guide to Server Administration.


Crystal Reports Driver Guide - Custom Fields in Reports (Working with ClearSCADA Database Tables)

Custom Fields in Reports

You can add ‘custom’ fields in Crystal Reports.

To add a ‘custom’ field to a report, you create a Formula Field and use a formula to define the field’s content.

To create a Formula field, right-click on the Formula Fields entry in the Field Explorer Bar and select the New option. Specify a suitable name for the field and then use the Formula Editor window to specify the formula for the field.

For information on using Formula fields, see the documentation supplied with the Crystal Reports application.


Crystal Reports Driver Guide - Map Field Changes to a Custom Table (Working with ClearSCADA Database Tables)

Map Field Changes to a Custom Table

NOTE: We do not recommend renaming or removing fields from a ‘custom’ Table that is used a report. However, the table data can be re-mapped within the Crystal Reports application to reflect changes.

You can use custom tables, such as Data Grids or Data Tables, in your reports (see Custom Tables and Fields).

Should any fields be added to a ‘custom’ table after that table has been attached to a report, you will need to refresh the report data in the Crystal Reports application. A message will be displayed indicating that the database has changed. Select OK for the application to add the new fields to the Field Explorer Bar. You can then add the new fields to your report (see Adding Fields and Data to a Report).

Should any fields in a ‘custom’ table be renamed after that table has been attached to a report, you will need to refresh the report data in the Crystal Reports application. A message will be displayed indicating that the database has changed. A Map Fields window is then displayed, indicating which of that table’s fields are not mapped within the Crystal Reports application. Use the Map Fields window to update the mapping to include the changed fields. Updating the database mapping in this way allows you to otherwise maintain the existing report configuration.

Should any fields in a ‘custom’ table be deleted after that table has been attached to a report, you will need to refresh the report data in the Crystal Reports application. A message will be displayed indicating that the database has changed. A Map Fields window is then displayed, indicating which of that table’s fields are no longer mapped within the Crystal Reports application (as they no longer exist in the ‘custom’ table). Select the OK button on the Map Fields window to update the mapping to exclude the deleted field—the fields are removed from the Report structure and the Field Explorer Bar. Adjust the report configuration as necessary. Updating the database mapping in this way allows you to otherwise maintain the existing report configuration.

For information on mapping fields using the Map Fields window, see the documentation supplied with the Crystal Reports application. For an example of how you can use the window to update the field mapping for a Data Grid, see below.

Example:

A Data Grid table is configured in a ClearSCADA database. The Data Grid table is used in a report. One of the fields in the Data Grid table is renamed from ‘Status’ to ‘Quality’.

The affected report is edited in the Crystal Reports application. When the report data is refreshed, a message is displayed indicating that database fields have changed. A Map Fields window indicates the affected fields:

The Data Grid field that was previously mapped in the report has been renamed to ‘Quality’.
To map the renamed field in Crystal Reports, select the entry in the top-right pane, and then select the Map button.

When the renamed field is mapped, the window’s content is updated to reflect the changes:

Once the changed field is mapped, it appears within the Mapped Fields section of the window...
...select the OK button to confirm the mapping changes.

A message confirms that the database connections have been updated. The field name is updated within the Field Explorer Bar.


Crystal Reports Driver Guide - Adding Fields and Data to a Report

Adding Fields and Data to a Report

ATTENTION: To update a report in the ClearSCADA database, ViewX has to be running while the report is being edited in the Crystal Reports application. As each report must be saved using its original file name, we advise that you use the Crystal Reports’ Save, rather than the Save As option, to store your reports.

You display data in a report by adding ‘fields’ to that report. Each row of fields that you add to the Details section in the Crystal Reports application (see Understand the Crystal Reports Work Areas) defines the information that is to be displayed for the records that you include in your report.

Before you can display ClearSCADA data in a report, you need to check that you provide the necessary access to the ClearSCADA database (see Accessing the ClearSCADA Database).

In order to reference the relevant database tables and include the required ClearSCADA data in your reports, you need to be familiar with the ClearSCADA database structure and naming conventions—this information is covered in detail in the ClearSCADA Guide to the Database. For a summary of the ClearSCADA database structure, and information on using database tables and fields in reports, see Working with ClearSCADA Database Tables.

When configuring large or complex reports, or reports that query historic table(s), take care to adhere to the Important Guidelines on Configuring and Generating Reports. Inappropriate configuration of large or complex reports can affect system performance.

This section explains the different Field Types that you can use in your reports.

It also explains how to:

  • Add a Field to a Report
  • Specify the Order in which Data is Displayed on a Report
  • Group the Data in a Report
  • Limit the Data that is Included in a Report
  • Allow Users to Specify which Data is Included in a Report.

ATTENTION: Be aware that any changes to items in the ClearSCADA database can affect the content of your reports. For example, let’s assume you filter or group a report by FullName and later rename or move some of the database items that appear in the report. As you have changed the location and name of items, you will need to check that the filters for the report are still suitable as they may now cause the report to contain inappropriate records.

Further Information

Map Field Changes to a Custom Table.


Crystal Reports Driver Guide - Field Types (Adding Fields and Data to a Report)

Field Types

You can add various types of field to a report. A summary of some of the types of field and how they are used in conjunction with ClearSCADA is given below. For more information on field types and using fields in reports, see the documentation supplied with the Crystal Reports application.

NOTE: To add any static text to your reports, you need to add a Text Object. You add a Text Object by using the Insert Text Object menu option or toolbar button. If you want to add specific information to a report, such as the report title or a page number, you may want to insert a Special Field, rather than static text.

The types of field that you may want to use in your reports include:

  • Database Field
  • Formula Field
  • Parameter Field
  • Group Name Field
  • Special Field.

If the data that you want to include in your reports contains calculations, you may want to consider using Data Grids. Data Grids are ‘custom’ tables that you can configure within ClearSCADA. ClearSCADA can perform a variety of calculations on the data in a Data Grid and display the results of those calculations in the report. For further information, see Configuring Data Grids in the ClearSCADA Guide to Core Configuration. For an example of how a Data Grid can be used in a report, see Embedded Data Grid Content.


Crystal Reports Driver Guide - Database Field (Adding Fields and Data to a Report)

Database Field

Database fields are often used in reports as they allow you to display data directly from the ClearSCADA database.

Before you can add any Database fields to a report, you need to check that:

  1. Crystal Reports has an ODBC connection to the ClearSCADA database (see Connect to the ClearSCADA Database)
  2. The database tables that the report is to access have been specified (see Provide Access to the Relevant Database Tables, and see Specify the Links Between Multiple Tables).

For complex reports, you may want to use Data Grids or Data Tables to specify the fields that you want to display in a report. You add Data Grid tables and Data Tables to reports in the same way as other database tables. For an example of using a Data Grid in a report, see Embedded Data Grid Content. For more information, see Configuring Data Grids in the ClearSCADA Guide to Core Configuration, or see Configuring Data Tables in the ClearSCADA Guide to Core Configuration. Also consider whether you want to Use a Subreport to Include Unrelated Data in the Same Report.

By default, when you add a Database field to the Details section of a report, the field title is added to the Page Header section of the report (see Understand the Crystal Reports Work Areas). In some instances, you may want to replace the default text for a title with a custom title.

To specify a custom title:

  1. Right-click on the field title in the Page Header.
    A context sensitive menu is displayed.
  2. Select the Edit Text option.
    The cursor is positioned in the field title box, ready for you to modify the text.
  3. Enter the required title for the field.

If you do not want a field title to be inserted whenever you add a field to a report, clear the Insert Detail Field Headings check box on the Layout tab in the Options window.

For an example that demonstrates how to include ClearSCADA data in a report, by adding Database fields to that report, see Add a Field to a Report. For further suggestions as to the type of data that you might want to consider including in your reports, see the examples throughout this guide.

For further information on using Database Fields in Crystal Reports, see the documentation supplied with the Crystal Reports application.


Crystal Reports Driver Guide - Formula Field (Adding Fields and Data to a Report)

Formula Field

You can use Formula fields to include data that does not exist in any ClearSCADA database fields. By writing a formula, you can calculate additional data that you want to use or display in a report.

You typically write formulas using Crystal syntax—for information, see the documentation provided with the Crystal Reports application. For examples of how a formula (rather than a Formula field) can be used in a report, see Point Listing that Uses Color to Indicate Alarm Status, and see Example 1 - Filter by Point and Record Time.

When writing formulas, use the Check button [image] to test that the syntax is correct.

As an alternative to using formulas in Crystal Reports, you can use Data Grids to specify the information that you want to include in a report. A Data Grid is in effect a ‘custom’ table. ClearSCADA can perform a variety of calculations on the data in a Data Grid and display the results of those calculations in the report. For further information, see Configuring Data Grids in the ClearSCADA Guide to Core Configuration. For an example of how a Data Grid can be used in a report, see Embedded Data Grid Content.

Further Information

Add a Field to a Report.

Custom Fields in Reports.


Crystal Reports Driver Guide - Parameter Field (Adding Fields and Data to a Report)

Parameter Field

ATTENTION: If you are using Date Time parameters in your reports, check that the DSN that is used to access the ClearSCADA database is configured to use Local Time, rather than UTC.

Use Parameter fields to allow user-input into what data is included when a report is generated. ClearSCADA supports a maximum eight parameters per report, with Range Values counting as two parameters.

When an operator attempts to generate a report that include parameters, a window is displayed, allowing the user to restrict the data that is included in the report (see Allow Users to Specify which Data is Included in a Report).

Note that to incorporate a Parameter field in the report layout, you need to place the Parameter field in the report manually. If placed in a section such as a Footer, the section can optionally be hidden from view.

If you add Parameters to a report, remember to provide the necessary operator instructions on how to use those parameters. You might want to produce the instructions as a printed document, as online Notes that you attach to the report using ClearSCADA’s Notes facility, or as a Help View that displays instructions about using the parameters. See the relevant core documentation for further details.

When you configure a Parameter field using the Crystal Reports application, you are offered a set of configuration options. The options differ, depending on the type of Parameter field that you are configuring (such as Boolean, string, or time). ClearSCADA supports a subset of these configuration options. The table below indicates which options ClearSCADA supports (‘Yes’) and which options are not available for use (‘No’). When configuring Parameter fields, only specify options that are supported.
Configuration Option | Parameter Type
 | Boolean | Currency | Date | Date Time | Number | String | Time
List of Values - Static | No | Yes | Yes | Yes | Yes | Yes | Yes
List of Values - Dynamic | No | No | No | No | No | No | No
Value Field | No | Yes | Yes | Yes | Yes | Yes | Yes
Description Field | No | Yes | Yes | Yes | Yes | Yes | Yes
Prompt Text | Yes | Yes | Yes | Yes | Yes | Yes | Yes
Prompt with Description Only | No | Yes | Yes | Yes | Yes | Yes | Yes
Default Value | No | No* | No* | No* | No* | No* | No*
Boolean Group # | Yes |  |  |  |  |  |
Exclusive Group | (See below) |  |  |  |  |  |
Allow Custom Values |  | Yes | Yes | Yes | Yes | Yes | Yes
Allow Multiple Values |  | No | No | No | No | No | No
Allow Discrete Values |  | Yes | Yes | Yes | Yes | Yes | Yes
Allow Range Values |  | Yes | Yes | Yes | Yes | Yes | Yes
Start |  |  | No | No |  |  | No
Min Value |  | No |  |  | No |  |
Min Length |  |  |  |  |  | No |
End |  |  | No | No |  |  | No
Max Value |  | No |  |  | No |  |
Max Length |  |  |  |  |  | No |
Edit Mask |  |  |  |  |  | No |

* The Default Value have to appear as the first entry in the Static Value list that is displayed above the Options area in the Create New Parameter and Edit Parameter windows. Any entry that is specified as the Default Value in the Options area of the window is ignored.

Boolean Exclusive Group parameters are supported on systems on which ClearSCADA is configured to interface with Crystal Reports version XI release 2.

For information on using the Create New Parameter and Edit Parameter windows, see the documentation supplied with the Crystal Reports application.

For examples that demonstrate the use of Parameter fields in reports, see:

  • Specify a Trip Sequence for a Parameter
  • Allow Users to Specify which Data is Included in a Report
  • Example 2 - Allow Users to Restrict the Time Period for a Report
  • Guidelines on Configuring Reports within Group Templates.


Crystal Reports Driver Guide - Group Name Field (Adding Fields and Data to a Report)

Group Name Field

For large or complex reports, you might choose to split the data entries into groups. Use Group Name fields to specify the data Groups in your reports (see Group the Data in a Report).

By default, when you add a Group Name field to a report, the Group Name title is added to the corresponding Group Header section of the report. If you do not want a Group Name title to be inserted whenever you add a Group to a report, clear the Insert Group Name with Group check box on the Layout tab in the Options window.

To generate only the data for a specific Group, rather than all of the Groups in a report, consider using a Parameter Field.


Crystal Reports Driver Guide - Special Field (Adding Fields and Data to a Report)

Special Field

Special fields are pre-configured generic fields, such as Report Title, File Creation Date, and Page N of M, that you may want to include on your reports.

For information on using Special fields, see the documentation supplied with the Crystal Reports application.

NOTE: If you want to use the Report Title field to display the title of a report, you need to specify the report title in the Document Properties window in Crystal Reports. To display the window, select the File menu, followed by the Summary Info option.


Crystal Reports Driver Guide - Add a Field to a Report (Adding Fields and Data to a Report)

Add a Field to a Report

To add any type of field to a report:

  1. View your report on the Design tab of the Crystal Reports application (or, in the case of a subreport, the relevant subreport tab).
  2. Check that the Field Explorer Bar is displayed. (If the Bar is not displayed, select the View menu, followed by the Field Explorer option.)
  3. Within the Field Explorer Bar, expand the tree-structure for the type of field that you want to add to the report (see Field Types).
  4. Drag the required field from the Field Explorer Bar onto the report.

For a field that is to display data for every entry in the report, place the field in the Details section of the report.

For fields that are only to appear at the start or end of a report, or in the header or footer of each page of a report, place the field in the appropriate section of the report (see Understand the Crystal Reports Work Areas).

Bear in mind that for those export options that treat fields as records, you should only include data fields in a report. Such export processes will export multiple copies of any headers, footers, and field titles, and so on, as each of the report fields are treated as records. To check if this applies to the export format that you want to use on a report, see Define the Export Format for a Report and go to the section on that export format.

  5. Format the field as required.

Example:

A simple report is required, which displays each of the SCADAPack Modbus points on a ClearSCADA system.

The CSCADAPackMPoint table is used for the report.

To add fields to the report, the Database Fields entry is expanded in the Field Explorer Bar, so that it shows the fields that are available in the CSCADAPackMPoint table.

The Name and CurrentValueFormatted fields are dragged onto the Details area of the report. This results in a report that includes the name of each point and the current point value.


Crystal Reports Driver Guide - Specify the Order in which Data is Displayed on a Report (Adding Fields and Data to a Report)

Specify the Order in which Data is Displayed on a Report

You can use the Record Sort Expert window to specify the order in which data is displayed in a report. When you add ClearSCADA data to a report, that data is sorted using a default sorting order (typically the item’s ID). You can use the window to specify a different sorting order—for example, to sort the entries in alphabetical order.

For an example of how you can use this feature to sort ClearSCADA data in a report, see below. For information on using the Record Sort Expert window, see the documentation provided with the Crystal Reports application.

Example:

A simple report displays the SCADAPack Modbus points on a ClearSCADA system.

By default, the data on the report is displayed in point ID order.

Within the CSCADAPackMPoint table that the report uses, the Name field specifies the short name for each point.

The Record Sort Expert window is used to select the Name field and specify that the data in the report is ordered in ascending alphabetical order, using the entries in that field.

This results in a report in which the data is sorted alphabetically, by name:

You can specify more complex sorting methods by using formulas (see Formula Field).


Crystal Reports Driver Guide - Group the Data in a Report (Adding Fields and Data to a Report)

Group the Data in a Report

You can use the Group feature within Crystal Reports to group the data on a report. This feature is particularly useful for large reports, or reports in which you want to mimic the ClearSCADA database hierarchy by structuring the report content in a similar way to the entries in the Database Bar.

When you add a Group to a report, a Group Name Field is created for that Group.

For an example of how you can group ClearSCADA data in a report, see below. For further information on Group Name fields and using the Insert Group window, see the documentation provided with the Crystal Reports application.

Example:

A report lists the values of the points in the ClearSCADA database. The points are ordered by the Group in which they are located in the ClearSCADA database. To do this, a Group is added to the report. The Group uses the ParentGroupName field in the CDBPoint database table to sort the points alphabetically, in Parent Group Name order.

The Group appears as a Group Name field in the Field Explorer Bar:

By default, a corresponding Group Name Header and Group Name Footer are added to the report, and are displayed when the report is viewed using the Design tab.

In Preview mode, the group entries appear in a hierarchical list, under the report name. You can select a list entry to display relevant Group in the report.

Select a Group Name heading to display the points for that Group in the report.

The report entries are ordered by Parent Group Name:

By default, the Groups are displayed as subheadings in the report. If the headings are not required, you can remove them by deleting the corresponding Group Header.

NOTE: To remove an obsolete Group from a report, use the left arrow to remove the Group from the Group Expert window. For more information, see the documentation provided with the Crystal Reports application.


Crystal Reports Driver Guide - Limit the Data that is Included in a Report (Adding Fields and Data to a Report)

Limit the Data that is Included in a Report

You can use the Select Expert window to limit the data that is displayed in a report. You may want to use this feature if a report uses the data from a ‘common’ database table and you want to limit the data that appears in the report to, for example, items that are in a particular Group, or that include a particular name.

For examples of how you can use this feature to limit the ClearSCADA data that is included in a report, see below. For information on using the Select Expert window, see the documentation provided with the Crystal Reports application.

NOTE: To allow operators to specify what data is to be included in a report, use Parameter fields (see Allow Users to Specify which Data is Included in a Report).

Example 1 - Limit Data to a Particular Group

A report references the CDBPoint database table. The CDBPoint table contains data on the points in a ClearSCADA system.

The report is to list only those points that are in any of the ‘DNP3’ Groups.

Within the CDBPoint table, the name of the group to which each point belongs is specified using the ParentGroupName field.

The Select Expert window is used to select the ParentGroupName field and specify that the field has to start with the string ‘DNP3’ for a point to be included in the report.

(The asterisk (*) indicates multiple further characters may be included in the name, so that the ParentGroupName fields that start with the word ‘DNP3’ are included in the selection.)

The resulting report lists only those points that appear within the Groups that start with the name ‘DNP3’:

Example 2 - Limit Data to a Particular Type

A report references the CDBPoint database table. The CDBPoint table contains data on the points in a ClearSCADA system.

The report is only to include analog-type points that are in the ‘DNP3’ series of Groups.

Within the CDBPoint table, the point type is specified using the TypeDesc field.

The Select Expert window is used to select the TypeDesc field and specify that the field has to contain the string ‘Analog’ for a point to be included in the report.

(Asterisks (*) are used either side of the word Analog to indicate that other text may appear before or after the word.)

The Select Expert window is also used to specify that the report is to contain only points that are in one of the ‘DNP3’ Groups (see Example 1 - Limit Data to a Particular Group).

The report lists only those analog-type points that appear within the Groups that start with the name ‘DNP3’:


Crystal Reports Driver Guide - Allow Users to Specify which Data is Included in a Report (Adding Fields and Data to a Report)

Allow Users to Specify which Data is Included in a Report

You can use Parameters to enable user-input as to which data is included in a report (see Parameter Field). This allows you to produce one report that can be used as a basis for generating reports that have different content.

For examples of how you can use Parameters to limit the ClearSCADA data that is included in a report, see below. For information on using Parameter fields and the Select Expert window, see the documentation provided with the Crystal Reports application.

Parameters are particularly useful when generating reports that query historic table(s), as they can be used to specify the time-period for which data is required (see Example 2 - Allow Users to Restrict the Time Period for a Report). You may also find Parameters useful when Configuring Reports within Group Templates.

NOTE: To produce a report that has a subset of the overall data in a database table, see Limit the Data that is Included in a Report.

Example:

A report references the CDBPoint database table. The CDBPoint table contains data on the points in a ClearSCADA system.

Whenever the report is generated, it only needs to include the data for points that reside in a whichever Group in the ClearSCADA database is of interest at that time.

A Parameter field is added to the report to allow users to specify the Group for which data is to be generated for the report.

When a user selects the Generate Report pick action from ViewX, a window is displayed prompting the user to specify the Group for which they want to generate the report:

The user uses the combo box to display a list of available Groups and specify the Group for which the report is to be generated:

The resulting report only includes the data for the points that are in the specified Group:

In this report, the Parameter field is displayed in the footer. The field indicates the Group for which point data is included in this version of the report.

If a user later generates another copy of the report for another Group:

another version of the same report is generated, which displays point data for that selected Group:

This version of the same report contains point data for the DNP3 Group.

To enable Group selection in this way, the Parameter field that was added to the report references the ParentGroupName field within the CDBPoint table. The ParentGroupName field is the field that specifies the Group to which each point belongs.

The Parameter field, named SpecifyGroupName, includes this configuration:

  • Type—String. (The Group Names are text strings.)
  • Value Field—ParentGroupName. (The field that specifies the Group with which a point is associated. This field is in the CDBPoint table.)
  • Prompt Text—Please Specify the Point Group. (This is the prompt that is displayed whenever a user attempts to generate the report.)

Use the Actions menu to Append all database values. (This adds the Parent Group Names to the list that is offered whenever a user attempts to generate the report.)

Once the Parameter field has been added to the report, the Select Expert window is used to define the selection settings for the ParentGroupName field. (In this case, that the ParentGroupName field should be restricted to the entry that a user specifies using the Parameter field (which itself is named ‘SpecifyGroupName’).)

NOTE: Be aware that in the above example, the list of Groups that are available for selection is a ‘snap-shot’ of the Groups that existed at the time that the report was configured. If Groups are later added or removed from the ClearSCADA database, the report’s Parameter configuration will need updating to encompass those changes.

For a further example on using Parameter fields in reports, see Configuring Reports within Group Templates.


Crystal Reports Driver Guide - Configuring a Report that Queries a Historic Table

Configuring a Report that Queries a Historic Table

ATTENTION: In order to update a report in the ClearSCADA database, ViewX has to remain running while the report is being edited in the Crystal Reports application. As each report has to be saved using its original file name, we advise that you use the Crystal Reports’ Save, rather than the Save As option, to store your reports.

When configuring a report that queries a historic table, take care to adhere to the Important Guidelines on Configuring and Generating Reports. Reports that query a historic table and are inappropriately configured can affect system performance.

You configure a report that queries a historic table in a similar way to other reports (see Configure a Report that Queries a Historic Table). As with other large or complex reports, you need to Restrict the Amount of Data that is Queried in a Report. You should include these restrictions as soon as you create a new report entry in the ClearSCADA database.


Crystal Reports Driver Guide - Configure a Report that Queries a Historic Table (Configuring a Report that Queries a Historic Table)

Configure a Report that Queries a Historic Table

You can produce a report that queries a historic table in a similar way to other reports.

With such a report, you reference one of the following:

  • A ‘custom’ Historic View
  • The historic table, CDBHistoric
  • The Event Journal table, CDBEventJournal.

In addition, you can reference table(s) that contain the database items that are of interest—for example:

  • The Points table, CDBPoint
  • The advanced drivers’ points table, CAdvPoint
  • The simple drivers’ points table, CSimplePoint
  • A driver-specific table.

Where a report references more than one database table, you need to specify the links between those tables (see Specify the Links Between Multiple Tables).

(To include data from unrelated tables, consider whether to Use a Subreport to Include Unrelated Data in the Same Report, a ClearSCADA Data Grid, or a ClearSCADA Data Table (see Custom Tables and Fields).)

With a report that queries a historic table, you have to restrict the amount of data that the report can retrieve from the server. You should include such a restriction as soon as you create the report and certainly before you attempt to preview the report, refresh the report data, or otherwise generate the report. For information, see Restrict the Amount of Data that is Queried in a Report.

Further Information

Working with ClearSCADA Database Tables.


Crystal Reports Driver Guide - Restrict the Amount of Data that is Queried in a Report (Configuring a Report that Queries a Historic Table)

Restrict the Amount of Data that is Queried in a Report

You need to restrict the amount of data that a report that queries a historic table can retrieve from the server as soon as you create the report. This will help to reduce any adverse affects on the communications on your system, caused by a report attempting to retrieve large amounts of historic data from the server (see Important Guidelines on Configuring and Generating Reports). ClearSCADA flags up an error should you attempt to retrieve historic data for a report that has no time constraint specified. However, you should still check that any time-period specified for a report is short enough to avoid causing any unnecessary adverse affects on the performance of your system.

We suggest that you filter a report that queries a historic table:

  • To an individual point in the database (for reports that query the CDBHistoric table or a ‘custom’ Historic View)

and

  • By Time (by limiting the maximum period for which a report can retrieve data, and also by using Parameters to allow users to further restrict the time-period for which historic data is retrieved).

ATTENTION: When restricting such a report by time, use the RecordTime field in the CDBHistoric table, rather than the Time field. (As ‘Time’ is a reserved word in SQL.)

To restrict a report by Point and Time, you use the Select Expert window. For examples of how you can use this window to limit the ClearSCADA data that is included in a report, see below, and see Limit the Data that is Included in a Report. For information on using the Select Expert window, see the documentation provided with the Crystal Reports application.

You can also use Formulas within your reports. For example, to restrict a report to retrieve only the data that occurred during particular a week or month. You write formulas using Crystal syntax. For information on formulas and Formula fields, see Formula Field, and see the documentation provided with the Crystal Reports application.

Example 1 - Filter by Point and Record Time

A report is used to retrieve the data for the DNP3 driver point, AIP4, for the previous week. The report references both the Historic table, CDBHistoric, and the Points table, CDBPoint. The tables are linked by Id field.

In order to retrieve historic data for only the point AIP4, the FullName field is used to restrict the CDBPoint table to entries with the name ‘DNP3 Group.DNP3 Direct.AIP4’. (The FullName field is used in preference to the Name field so that only that particular point is selected—the Name field would include any other points that have the same name (AIP4) but reside in different locations in the database.)

The Select Expert window is used to select the FullName field and specify the required restriction:

To restrict the report to retrieve historic data for the past week, the Select Expert window is used to select the RecordTime field from the CDBHistoric table and specify the required restriction (the restriction Last7Days is specified using the Formula Editor and selecting the entry from the list of Date Range functions):

The resulting report is restricted to retrieving data for the DNP3 point AIP4, for the previous week. For the week starting 3rd January 2005 and ending at midnight at the start of 10th January 2005, this is the resulting report:

(This information in this particular report is displayed using the Name field from the CDBPoint table and the StateDesc, Value, and RecordTime fields from the CDBHistoric table.)

Example 2 - Allow Users to Restrict the Time Period for a Report

The report used in Example 1, above, is further restricted by using a selection window. The window enables users to further limit the amount of data that the report is to generate, by specifying the start and end dates for that data.

To enable time selection in this way, a Parameter Field is added to the report.

The Parameter field, named RestrictTimePeriod, contains this configuration:

  • Type—DateTime. (The RecordTime field contains date and time values.)
  • Value Field—None. (The parameter does not reference a field in the database.)
  • Prompt Text—Specify the period for which data is required. (This is the prompt that is displayed whenever a user attempts to generate the report.)
  • Allow Range Values—True. (Enables users to specify a value range.)

Once the Parameter field has been added to the report, the Select Expert window is used to restrict the RecordTime field entries to those specified using the Parameter field:

Whenever a user attempts to generate the report from ViewX or a WebX client, a selection window is displayed, prompting them to specify the time period for which the report is to include historic data.

This allows the user to restrict the amount of data that needs to be retrieved from the server in order to generate the report, by selecting just the time-period that is of interest.

For another example of using a selection window to restrict the data that is included in a report, see Allow Users to Specify which Data is Included in a Report.


Crystal Reports Driver Guide - Configuring Reports within Group Templates

Configuring Reports within Group Templates

As with other database items, you can add reports to Group Templates. This section includes Guidelines on Configuring Reports within Group Templates.

Within a Group Template, a report is a ‘model’ report that is not ‘live’, but is used as a reference for the reports in the Group Instances that reference the Group Template.

Within each Group Instance, a ‘live’ report can be generated, printed, or exported as usual. The reports that are generated for one Instance are completely separate to the reports that are generated and stored for another Instance.

For more information, see Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration.


Crystal Reports Driver Guide - Guidelines on Configuring Reports within Group Templates (Configuring Reports within Group Templates)

Guidelines on Configuring Reports within Group Templates

You configure a report in a Group Template in a similar way to a report in any ‘normal’ Group. However, as a report in a Group Template is used as a basis for all instances of that report, there are some additional considerations that need to be taken into account.

By default, you cannot Edit a report within a Group Instance. Instead, when you alter the report configuration in a Group Template, the same alteration is made to the corresponding reports in the Instances of that Group Template.

Each report in an Instance has the same configuration as a corresponding report in a Group Template. For this reason, you need to make sure that users can specify the information they need to be included in each instance of a report. You can do this in several ways, including writing Structured Text, or using Parameters that enable users to specify the information that is to be generated for each instance of a report.

For information on using Structured Text, see the ClearSCADA Guide to Logic.

For an example of how to use Parameters to specify the information that a report is to contain, see below.

ATTENTION: Within the Property Overrides settings for a Group Template, you can set the Content of a report so that it is configurable from within each Group Instance. Only select this check box if no global updates to report configuration are to be carried out once a report has been added to a Group Template. Any changes made to a report from within a Group Template will not be transmitted to the reports in any Group Instances once this check box has been selected. For more information on Property Overrides, see Configure the Properties that are Unique to the Items in a Group Instance in the ClearSCADA Guide to Core Configuration.

Example:

The report in this example uses a Parameter to specify a report Instance.

A report is to list the items in a Group Instance, with an indication of when each item’s configuration was last modified. (Remember that each Instance contains the same items as the Group Template. Depending on the Property Overrides that are specified for those items, some configuration properties, such as an outstation’s address, can be overridden within each Instance.)

The report is configured within a Group Template. Several Group Instances reference the Template. Each Group Instance contains a ‘live’ version of the report. Each ‘live’ version contains exactly the same configuration as the report in the Group Template.

To allow users to specify the data that each instance of that report is to contain, the report in the Group Template is configured to use Parameters.

The report references the CDBObject database table. Within this table, the ParentGroupName field defines the Group or Group Instance to which an item belongs. (The ParentGroupName field does not include entries for Group Templates.)

A Parameter Field, named ‘SpecifyInstance’, is added to the report. The Parameter field references the ParentGroupName field. The required Group Instances are added to the list of default Values, to enable users to specify the Group or ‘region’ for which they want to generate a particular Instance of the report. The Select Expert window is used to limit the ParentGroupName records to those defined by the Parameter field:

Within ViewX, each Instance of the report is attached to a Schedule. As each report is dragged onto its Schedule, the Add Action window is displayed. The engineer that is configuring the Schedule uses the window to specify the Generate Report method, along with the ‘region’ (Group Instance) for which the Schedule is to generate a report.

The Method combo box is used to specify the Generate Report method.
The ‘SpecifyInstance’ parameter is displayed in the Arguments list. (Its name is the Prompt Text that the engineer specified when configuring the parameter in the Crystal Reports application.)
As the parameter has been assigned a set of values (in this case, Group Instances), the engineer can right-click on the parameter in the Arguments list and select the required Instance from the pop-up list.

(For clarity in this example, the Group Instance names contain the name ‘Instance’.)

Therefore, if the engineer specifies the region ‘Kingfisher Instance 1’, the Schedule will generate a report that contains data for items that are in the Group Instance ‘Kingfisher Instance 1’:

In this particular report, the value of the Parameter field is used along with static text to produce a unique title for the report.
The footer displays the date and time that this instance of the report was generated.
The report displays data for the items that belong to the ‘Kingfisher Instance 1’ Group Instance. Within this Instance, the configuration for analog point AI Point 1 was modified at 15:05:56 on 12th January 2005.

If the engineer specifies the region ‘Kingfisher Instance 2’, the Schedule will generate a report that contains data for the items that are in the Group Instance ‘Kingfisher Instance 2’:

By using the Parameter field in the report title, this indicates that this particular report is for ‘Kingfisher Instance 2’.
This instance of the report was generated slightly later than the report for ‘Kingfisher Instance 1’...
...but shows that the configuration for the analog point AI Point 1 was modified at the earlier time of 13:40:22 within this particular Instance.

(This report displays data using the CDBObject table’s Name, TypeDesc, ConfigUser, and ConfigTime fields.)

For further examples on using Parameter fields, see:

  • Specify a Trip Sequence for a Parameter
  • Allow Users to Specify which Data is Included in a Report
  • Example 2 - Allow Users to Restrict the Time Period for a Report.

For more information on using Schedules to generate reports, see Use a Schedule to Trigger a Report on a Regular Basis.


Crystal Reports Driver Guide - Example Reports

Example Reports

This section includes a series of sample reports to further demonstrate how ClearSCADA data can be used in reports, and the format that the data can take.

In the examples that follow, the format of many of the reports has been adjusted from the Crystal Reports default to give a more professional report layout. For information on adjusting the format of a report, see the documentation supplied with the Crystal Reports application.

Be aware that if you want to export a report to a programmatic-type text format (record-based), you may want to exclude items such as headers, footers, and field titles. Programmatic-type export procedures, with the exception of Separated Text Format, handle all fields as data records. Other export formats also affect the attributes that are preserved in a report when it is exported to another format. For information on export formats, see Define the Export Format for a Report.

For other examples, see as appropriate:

  • Specify a Trip Sequence for a Report Object
  • Configuring a Report that Queries a Historic Table.
  • Configuring Reports within Group Templates.
  • Activating a Report Action Automatically (for examples on using Schedules or Alarm Redirection Actions to trigger reports automatically).

The examples in the rest of this section comprise:

  • Templates and Instances Listing
  • Embedded Data Grid Content
  • Point Listing that Uses Color to Indicate Alarm Status
  • Display the Latest Report via a Button on a Mimic
  • Use a Subreport to Include Unrelated Data in the Same Report.


Crystal Reports Driver Guide - Templates and Instances Listing (Example Reports)

Templates and Instances Listing

This example shows how Crystal Reports can be used to produce two very simple reports. One report lists the Group Templates that are configured on a system, and the other report lists the Instances of those templates, and their location within the database. (You can display a list of Instances that reference an individual template, by using the Display References option in ViewX, but these reports are useful for displaying information on all of the Templates and Instances on your system.)

Example:

A report is produced that lists the Group Templates that exist on a system. It also contains notes that specify the type of equipment that each template represents.

The report uses the CTemplate database table. The following fields from the CTemplate table are used within the report:

  • Name—The name of the template.
  • NoteText—The user notes that have been manually entered within ClearSCADA for each template. (Notes are entered for each template by right-clicking on the template entry in the Database Bar, choosing the ‘Notes’ option from the context sensitive menu and manually entering free-form text.)

The entries in the report are sorted alphabetically, by template name. (Sorting is specified in Crystal Reports by selecting the ‘Report’ menu option, choosing the ‘Record Sort Expert’, specifying the required Sort Field (in this case ‘Name’) and selecting the required sort order.)

A second report lists the Group Instances in the same system. The entries are sorted alphabetically, firstly by Template name order and then by Instance name order.

From looking at the ‘Template Used’ column, engineers can assess which Instances will be affected if configuration changes are made to a particular Template. They can therefore assess the Instances for which additional configuration may be required if the Template configuration is changed.

This report references two database tables:

The CTemplateInstance database table, from which the following fields are used in the report:

  • Name—The name of the instance.
  • FullName—The full database path for the Instance.

The CTemplate database table, from which the following field is used in the report:

  • Name—The name of the template. (This appears as ‘Template Used’ within the report).

The records in both tables were matched by linking the Id field in the CTemplate table to the TemplateId field in the CTemplateInstance table.

As with the Group Templates report, the field titles were modified within Crystal Reports to give them more meaningful names. This was done by right-clicking on each field title, selecting the ‘Edit Text object’ from the pop-up menu, and entering the required text.

Further Information

Group Templates and Group Instances: see Group Templates and Group Instances in the ClearSCADA Guide to Core Configuration.

Specify the Links Between Multiple Tables.

For a further example that demonstrates how to use the Record Sort Expert, see Specify the Order in which Data is Displayed on a Report.


Crystal Reports Driver Guide - Embedded Data Grid Content (Example Reports)

Embedded Data Grid Content

You can use Data Grids to define the data that you want to include in a report.

A Data Grid effectively adds a ‘custom’ table to the ClearSCADA database (see Configuring Data Grids in the ClearSCADA Guide to Core Configuration).

If, for example, you want to collate together an arbitrary collection of values into tabular format and include those values in a single report, you may want to use a Data Grid to specify those values. Within the report, you then only need to specify the Data Grid table itself, rather than use Crystal Reports to constrain the data from other database table(s) to just those values that are of interest.

Similarly, if you want ClearSCADA to perform a series of calculations on some data and display the results of those calculations in a report, you may want to specify those calculations in a Data Grid, and attach that Data Grid to a report. A Data Grid can perform a variety of calculations, the results of which can be displayed in a report, so reducing the time that it takes to configure the report within the Crystal application.

For complex reports, you can attach more than one Data Grid to a report.

ATTENTION: We do not recommend renaming or removing fields from a Data Grid Table, after that Data Grid Table has been attached to a report. However, you can re-map the table data in the Crystal Reports application to reflect changes (see Map Field Changes to a Custom Table).

Example:

A Data Grid is produced that indicates the current quality of various items of plant—channels, sets, outstations, specific points, and so on. The entries in the Data Grid are grouped to reflect the system structure—for instance, the points in a particular outstation are listed below the outstation entry, and so on.

The information from the Data Grid is used in a report. The report is to be an aid for engineers that are troubleshooting on the system.

The Data Grid table is added to the report in the same way as other database tables.

In the Database Expert window, the Data Grid table ‘PlantStatus’, is specified in the same way as a ‘standard’ ClearSCADA database table.

The Data Grid fields, LastUpdate, Plant, Point, and Quality, are added to the report in the same way as other database fields.

The Data Grid fields are selected from the Field Explorer window in the same way as other database fields.

The report is formatted as required.

The report configuration is saved. The report is generated and displayed to show the latest data.

The report data can be used as an aid for detecting any unexpected behavior on the system.

NOTE: If you wanted to include the points on each of the outstations in the above report, rather than just a couple of specific points, it would be better to include the point data in a subreport (see Use a Subreport to Include Unrelated Data in the Same Report). (This would avoid the need to edit the Data Grid should any of the outstations’ points be added or removed from the database.)


Crystal Reports Driver Guide - Point Listing that Uses Color to Indicate Alarm Status (Example Reports)

Point Listing that Uses Color to Indicate Alarm Status

You can configure the entries in a report so that their color is determined by their status at the time of report generation.

This example shows how alarm descriptions in a report can be configured to use color to indicate the alarm status of each point at the time that the report was generated.

The color change is configured using a formula. When using formulas in Crystal Reports, you need to use Basic or Crystal syntax, as applicable (see the documentation supplied with the Crystal Reports application for details).

Example:

A report uses dynamic colors to indicate the alarm status of each point, at the time that the report was generated.

On this report, the font color used for the Alarm Description is dynamic. The color is used to indicate the alarm status of each point at the time that the report was generated.

The report uses the CDBPoint table.

The report layout is configured to display records for the following fields:

  • Name—The name of the item.
  • CurrentValueFormatted—The value of the item.
  • AlarmDesc—The description of the current alarm state.

The field titles have been slightly reworded within the report.

To set each record so that the ‘Alarm Description’ value changes color, depending on the alarm state of the item, the AlarmDesc field in the ‘Detail’ section of the report is formatted, so that its font color alters in line with the item’s alarm state.

To do this, a Formula is specified for the font color. The Formula button [image] is selected next to the font color in the Format Editor window, in order to display the Formula Editor window in which the required formula is entered.

In this particular report, it was decided that the ‘Alarm Description’ entries should use the following colors to represent the alarm state of each point:

  • Black—Normal state (point not in alarm)
  • Gray—Alarms are disabled
  • Green—The alarm has cleared but remains unacknowledged
  • Red—The point is in alarm

The AlarmState field in the CAlarmObject table indicates an item’s alarm state. The Database Schema was used to determine the AlarmState values that indicate each alarm state. These are:

  • 0—Normal
  • 1—Disabled
  • 2—Acknowledged Uncleared
  • 3—Unacknowledged Cleared
  • 4—Unacknowledged Uncleared.

Therefore following formula was used for the font color for the ‘Alarm Description’ entries:

IF {CAlarmObject.AlarmState}= 0 THEN crBlack ELSE IF {CAlarmObject.AlarmState}= 1 THEN crGray ELSE IF {CAlarmObject.AlarmState}= 3 THEN crGreen ELSE crRed

(The Formula Editor window allows selection of field names and color constants—see the documentation supplied with the Crystal Reports application for details.)

When the report is generated, the formula determines the ‘Alarm Description’ font color that is used for each entry in the report.


Crystal Reports Driver Guide - Display the Latest Report via a Button on a Mimic (Example Reports)

Display the Latest Report via a Button on a Mimic

You can specify whether the ClearSCADA server is to store a report historically (see Define the Historic Storage of a Report). If a report is stored historically and more than one version of that report is retained on the server, when a user attempts to display that report from ViewX or a hyperlink on a Mimic, they are offered a list of available report files (see Display).

This example demonstrates how to configure a hyperlink on a Mimic, so that operators can use it to display the latest generated report automatically, rather than be offered a list of available versions of that report.

Example:

A report on a particular ClearSCADA system is used to summarize the point status of a particular area of plant. The report is stored historically. As such, whenever operators select the ‘Display’ pick action from the report’s entry in the Database Bar, they are offered a list of available reports.

When more than one version of a report is stored on the server, operators are offered a list of available versions of that report.

Operators need to be able to display the latest version of the report from a Mimic.

To enable this, a button is added to the Mimic. The button’s Pick Action Wizard is used to provide a hyperlink to the report’s URL and open that report in a new window.

A hyperlink is added to a Mimic, to enable users to access the latest version of the report.

As the report is stored historically and the server retains several versions of that report at any one time, when operators select the button, the Select Report window is displayed, offering them a list of available versions of that report.

In order to display the latest generated version of the report automatically, rather than the list of available versions of that report, an additional query is appended to the report’s URL:

Append the query ?latest to the end of the URL, to specify that the latest version of a historically stored report is to be displayed.

When operators select the button on the Mimic, the latest generated version of the report is displayed in the Crystal Reports Viewer.

NOTE: If you were to produce a hyperlink to a report by dragging a copy of that report onto a Mimic and choosing to add the entry as a hyperlink, you would need to delete any PickParam animations that are created, in order to enable the above command take effect.

Further Information

Add a Button to a Mimic: see Adding Objects to a Mimic in the ClearSCADA Guide to Mimics.

Edit a Button on a Mimic: see Editing Objects on a Mimic in the ClearSCADA Guide to Mimics.

The Syntax of a URL to a Specific Report: see Creating a Hyperlink to a Crystal Report in the ClearSCADA Guide to Mimics.

Using the Crystal Reports Viewer.


Crystal Reports Driver Guide - Use a Subreport to Include Unrelated Data in the Same Report (Example Reports)

Use a Subreport to Include Unrelated Data in the Same Report

This example demonstrates how you might use a subreport (a separate report within a main or ‘primary’ report) in order to include indirectly related or unrelated data in the same report.

This particular example uses a subreport to enable the value of a ClearSCADA Parameter to be included in a report, however you can use subreports whenever you want to include more than one query in a report. You can, for example, use subreports if you want to include data from any database tables that are unrelated to another, and for which the records in those tables cannot therefore be linked together. You might also want to consider using subreports to display more than one view of the same data in a single primary report.

For detailed information on subreports, see the documentation supplied with the Crystal Reports application.

NOTE: As an alternative to using subreports, you might want to consider using ClearSCADA Data Grids (see Custom Tables and Fields). Data Grids enable you to collate data from a variety of different sources in a single table, which you can then include in a report.

Example:

A particular ClearSCADA system is split into geographical zones. ClearSCADA Grid Reference Parameters are used to store the map grid references that define each zone’s geographical location. The grid references are included in any Mimics and reports that relate to specific zones.

Each ClearSCADA Grid Reference Parameter stores data that specifies the geographical location in which an area of plant is located. However, that map reference data is not directly related to the database records that store the actual plant data—there is no direct link between the database table that stores the grid reference data, and the database tables that store the plant data for a particular zone. Therefore, in order to include the ClearSCADA Grid Reference Parameter data in a report, that data is included in a Crystal Reports subreport.

A primary report is produced, which references the database table(s) that contain the plant data. The data that is included in the report is constrained to that of the relevant zone. (For instance, by using the Select Expert window to restrict the data to that of the relevant ParentGroupName.)

The map grid reference that defines the zone’s geographical location is to be displayed in the primary report’s Report Header.

A subreport is added to the primary report, in order to include the grid reference data. (To add a subreport to a primary report, select the Insert Subreport button in the Crystal Reports application, or select the Insert menu, followed by the Subreport option.)

The subreport is given a suitable name—‘Map Reference’.

As with the primary report, the relevant ODBC connection is specified to enable the Crystal Reports application to access the ClearSCADA database and include data in the subreport. However, unlike the primary report, which references other database table(s), the subreport is configured to reference the CParamGridRef table—the database table that stores ClearSCADA Grid Reference Parameter data. The table has three configuration fields, Ref1, Ref2, and Ref3, which are used to store the map grid data. The three fields are included in the subreport.

The subreport is embedded in the primary report’s header. Additionally, in this particular report, static text is also added to the report header, along with one of the database fields from the primary report:

An additional tab is provided on the primary report, to enable you to modify the content of the subreport.
The subreport ‘Map Reference’ is added to the primary report’s Report Header. (On the Design tab, only the name of the subreport is displayed—you need to go to the subreport’s tab to see the subreport’s actual ‘definition’ (layout).)
Static text.
In this particular example, the primary report’s header includes one of the primary report’s database fields.

As with any subreport, the subreport’s tab (named, in this case, ‘Map Reference’, after the subreport to which it relates) is used to configure the subreport’s ‘definition’ (the layout and information that is to be included in that subreport). In this particular example, for instance, the Select Expert window is used to restrict the grid reference data to that of the relevant map grid reference:

...such as the database fields that are to be included in the subreport...
Use the subreport’s tab to configure the subreport’s definition...
...and whether the subreport’s Report Headers and Report Footers are to be suppressed (hidden from view in the finished report).

This results in a report with the following layout:

The report header, comprising a combination of static text, the value of a database field from the primary report (‘Eastern Region. Zone 1’), and the value of the ClearSCADA Grid Reference Parameter (‘SP 335 785’) from the subreport.
The main body of the report, comprising the values of database fields from the primary report.

Further Information

ClearSCADA Parameters, including Grid Reference Parameters: see Using Parameters to Store Static Data Values in the ClearSCADA Guide to Core Configuration.

Specify an ODBC Connection: see Accessing the ClearSCADA Database.

For an example that further demonstrates use of the Select Expert window, see Limit the Data that is Included in a Report.


Crystal Reports Driver Guide - Using Actions Associated with Crystal Reports

Using Actions Associated with Crystal Reports

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section cover those actions that are report-specific (see Alphabetical List of Crystal Reports-Specific Actions).

In addition to the above pick actions, further Crystal Reports-specific actions are available to engineers that are using the Automation Interface to configure ClearSCADA. For information about these pick actions, see Crystal Reports Methods Available Only for Use with the Automation Interface.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. A note is included with the relevant pick action whenever this naming convention differs. Refer to the Database Schema for argument naming conventions not covered in this section.

For information on automating actions by attaching them to Schedules or Alarm Redirections, see Activating a Report Action Automatically.

NOTE: Users with the required permissions can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.


Crystal Reports Driver Guide - Alphabetical List of Crystal Reports-Specific Actions (Using Actions Associated with Crystal Reports)

Alphabetical List of Crystal Reports-Specific Actions

These actions are specific to Crystal Reports:

  • Display
  • Export Report
  • Generate Report
  • Print Report.

NOTE: You can print or export a previously generated report, using separate options in the Crystal Reports Viewer (see Using the Crystal Reports Viewer). Use those options to print or export reports that are already stored in the database, rather than ‘live’ report data.


Crystal Reports Driver Guide - Display (Using Actions Associated with Crystal Reports)

Display

Associated with: Crystal Reports.

Security permission required to access this pick action: Read.

Use the Display pick action to display a generated report. Depending on the system setup, the pick action can be used to:

  • Display a Report in ViewX
  • Display a Report on a WebX Client.

NOTE: The Display pick action is not a method and therefore cannot be used with the Automation Interface.

Display a Report in ViewX

If a report is stored historically (see Define the Historic Storage of a Report) and more than one version of the report exists on the server, when you select the Display pick action, a Select Report window is displayed.

To display the required report, either double-click on the required entry, or select the time of the report that you want to display and then select the OK button.

If more than one version of a report is stored on the server, a Select Report window is displayed when you select the Display pick action. Select the version of the report that you want to display.

Be aware that a report that is produced using the Export Report or Print Report pick actions does not appear as an entry in the Select Report window—only reports that are produced using the Generate Report pick action appear in this window.

(It is possible to configure a hyperlink on a Mimic to display a specific report, or only the most recently generated report, rather than a list of available versions of that report—see Display the Latest Report via a Button on a Mimic.)

The report is displayed in an inset Crystal Reports viewer (see Using the Crystal Reports Viewer).

Example:

If a report includes Groups, you can use the left pane to select the information that you want to view in the right-hand pane.

If the Display pick action is selected before a report has been generated, ClearSCADA displays an error message.

Generate the report using the Generate Report pick action and then use the Display pick action to display the report.

Display a Report on a WebX Client

A WebX Client can be used to display the latest generated version of a report providing that:

  • The Generate for WebX feature is enabled on the Crystal Report Form (see Specify Whether a Report is to be Made Available for Display in WebX)
  • The Generate Report pick action has been used to generate the report
  • Adobe Reader® is installed on the WebX client. (On a WebX client, the most recently generated version of a report is displayed in printable Adobe® PDF format.)

For information on navigating your system using a WebX client, see Use the WebX Interface in the ClearSCADA Guide to ViewX and WebX Clients.

For information on displaying a report on a WebX client, see View the Most Recently Generated Version of a Report on a WebX Client in the ClearSCADA Guide to ViewX and WebX Clients.


Crystal Reports Driver Guide - Export Report (Using Actions Associated with Crystal Reports)

Export Report

Associated with: Crystal Reports.

Security permission required to access this pick action: Control.

ATTENTION: The Crystal Reports driver uses the server’s specified printing user when exporting a report using the Export Report pick action. The printing user determines the e-mail settings for reports that are exported via e-mail, using the server’s Windows MAPI settings. As such, the printing user has to have the necessary write access to any directories to which reports are exported. The printing user is specified in the Printing section of the ClearSCADA Server Configuration Tool (see Printer Settings in the ClearSCADA Guide to Server Administration). (If ClearSCADA is configured to interface with Crystal Reports version 2008, you can specify whether reports are to be exported to e-mail using Windows MAPI settings (the default) or SMTP (see Configuring Crystal Reports Server Settings).)

The Export Report pick action is only available if Exporting is configured for a report. (To export a previously generated report, whether or not that report has exporting configured, use the Crystal Reports Viewer—see Export a Previously Generated Report.)

Use the Export Report pick action to export a report in the format and to the destination specified on the Crystal Report Form (see Define the Export Format for a Report, and see Define the Export Destination for a Report).

The Export Report pick action instructs the server to produce a report that contains the latest data, and export that report to the pre-defined destination. (A report that is produced in this way does not appear as an entry in the Select Report window (see Display)—only reports that are produced using the Generate Report pick action appear in this window.)

If a report uses Parameters (see Parameter Field), a window is displayed whenever the Export Report pick action is selected. The window allows you to restrict the data that is to be exported. The prompts and options that appear in such a window are specified by the engineer that configured the report parameters—see that engineer or a system administrator for further information.

Example:

If a report includes Parameters, a selection window is displayed when you select the Export Report pick action. The window allows you to restrict the data that is to be included in the exported version of the report. The prompts and options that appear in a selection window are specified by the engineer that configured the report parameters.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Export.

Should you experience difficulties when exporting reports, see Troubleshooting.


Crystal Reports Driver Guide - Generate Report (Using Actions Associated with Crystal Reports)

Generate Report

Associated with: Crystal Reports.

Security permission required to access this pick action: Control.

ATTENTION: Generation of large or complex reports, or reports that query historic table(s), can have a temporary adverse effect on the system. We advise that such reports are generated when little communications traffic is expected on a ClearSCADA system—for example in the early hours of the morning. Be aware that if a report is configured to enable it to be displayed on a WebX client in addition to a ViewX client, ClearSCADA will generate two versions of that report whenever the Generate Report pick action is used.

Use the Generate Report pick action to generate a report. When generated, a report is either:

  • Stored on the server until it is replaced by the next generated version of the same report (if the report is not stored historically).
  • Stored on the server as a time stamped file until its Historic Life expires (see Define the Historic Storage of a Report). If more than one version of a report is stored on the server, operators can specify which version they want to Display.

ATTENTION: If a report is to be displayed on a WebX client, this feature has to be enabled on the Crystal Report Form’s Generate for WebX tab (see Specify Whether a Report is to be Made Available for Display in WebX). When enabled, the Generate Report action will trigger ClearSCADA to generate two versions of the report, including one in Adobe® PDF format for displaying on the WebX client.

If a report uses Parameters (see Parameter Field), a window is displayed whenever the Generate Report pick action is selected. The window allows you to restrict the data that is included in the generated report. The prompts and options that appear in such a window are specified by the engineer that configured the report parameters—see your system administrator for further information.

Example:

If a report includes Parameters, a selection window is displayed when you select the Generate Report pick action. The window allows you to restrict the data that is to be included in the generated report. The prompts and options that appear in a selection window are specified by the engineer that configured the report parameters.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Generate.

Should you experience difficulties when generating reports, see The Server Fails to Generate a Report.


Crystal Reports Driver Guide - Print Report (Using Actions Associated with Crystal Reports)

Print Report

Associated with: Crystal Reports.

Security permission required to access this pick action: Control.

ATTENTION: The Crystal Reports driver uses the server’s specified printing user when printing a report using the Print Report pick action. The printing user determines which printer(s) are available to the server. The user is specified in the Printing section of the ClearSCADA Server Configuration Tool (see Printer Settings in the ClearSCADA Guide to Server Administration).

Use the Print Report pick action to print a copy of a report to a printer on your system. The server produces and prints a report that contains the latest data.

The page setup for a report is specified on the Crystal Report Form (see Configure the Report Properties) and the Crystal Reports application (see Specify the Page Setup).

Select the Print Report pick action to display the Print Report window. The window displays the fields listed below. (If a report uses Parameters (see Parameter Field), other fields may be displayed, allowing you to specify the report data that is to be printed—see your system administrator for further information about such parameters).

  • Printer—Use the combo box to specify the printer on which you want to print the report. Only printer(s) that have been added to the server are listed.
  • Number of Copies—Specify the number of hard-copy printouts that you require.
  • Collate—If printing multiple copies of a multi-page report, use this check box to specify whether you want the printer to collate the printouts.

Leave the check box clear if collating is not required.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Print.

NOTE: You can print a previously generated report using a separate option, available from the Crystal Reports Viewer (see Using the Crystal Reports Viewer). Use the option if you want to print a copy of a report that is already stored in the database, rather than print ‘live’ report data.


Crystal Reports Driver Guide - Crystal Reports Methods Available Only for Use with the Automation Interface (Using Actions Associated with Crystal Reports)

Crystal Reports Methods Available Only for Use with the Automation Interface

In addition to the pick actions that are available to ViewX users (see Alphabetical List of Crystal Reports-Specific Actions), several additional Crystal Reports pick actions (‘methods’) are available to engineers that are using ClearSCADA’s Automation Interface. (Database Schema and Automation Interface methods are known as pick actions when available via the ViewX interface.)

The Automation Interface is a built-in interface that allows access to the properties and methods of every item in the database. The interface can be used for rapid configuration of ClearSCADA, enabling engineers to import existing system configuration from another source, such as a database spread sheet.

The Automation Interface supports the standard and driver-specific Methods (pick actions) that are available to ViewX users. In addition, where configuration properties cannot be exposed through the conventional interface, some drivers include further Methods that are only available for use with the Automation Interface. The Crystal Reports driver has several of these additional Methods.

The following Crystal Reports-specific Methods are only available for use with the Automation Interface:

  • ExportDefinition
  • ExportLatestReport
  • ImportDefinition
  • ImportLatestReport.

NOTE: In addition to the above, Export, Generate, and Print methods are available for use with the Automation Interface. These methods have Parameter arguments that can be implemented for reports that use parameters (up to eight parameters can be associated with a report, to restrict the content of that report—see Parameter Field). Specify only those Parameters that apply to a particular report.


Crystal Reports Driver Guide - ExportDefinition (Using Actions Associated with Crystal Reports)

ExportDefinition

Associated with: Crystal Reports.

Use the ExportDefinition method to export the report ‘definition’—the report configuration that is specified using the Crystal Reports application—to a file.

Arguments:

  • Filename (String)—Specify the destination file name, including the full path of the location to which the report file (.rpt) is to be exported from the main server.


Crystal Reports Driver Guide - ExportLatestReport (Using Actions Associated with Crystal Reports)

ExportLatestReport

Associated with: Crystal Reports.

If a report has historic storage enabled, more than one generated copy of the report might be stored on the server.

Use the ExportLatestReport method to export the latest generated copy of the report to a file on disk. The selected file is exported in Crystal Reports format (rather than any export format that is specified on the Export Format tab of the report’s configuration Form).

Arguments:

  • Filename (String)—Specify the destination file name, including the full path of the location to which file is to be exported from the main server.


Crystal Reports Driver Guide - ImportDefinition (Using Actions Associated with Crystal Reports)

ImportDefinition

Associated with: Crystal Reports.

Use the ImportDefinition method to import the report ‘definition’—the report configuration that is specified using the Crystal Reports application—from a file.

Arguments:

  • Filename (String)—Specify the source file name, including the full path to the file on the main server.


Crystal Reports Driver Guide - ImportLatestReport (Using Actions Associated with Crystal Reports)

ImportLatestReport

Associated with: Crystal Reports.

Use the ImportLatestReport method to import a file into the latest report in the database. The selected file is imported in Crystal Reports format.

Arguments:

  • Filename (String)—Specify the source file name, including the full path to the file on the main server.


Crystal Reports Driver Guide - Activating a Report Action Automatically

Activating a Report Action Automatically

You can generate, print, or export a report manually using the relevant pick action (see Using Actions Associated with Crystal Reports).

To generate, print, or export a report automatically, you can:

  • Use a Schedule to Trigger a Report on a Regular Basis
  • Use an Alarm Redirection to Trigger a Report under Particular Conditions.


Crystal Reports Driver Guide - Use a Schedule to Trigger a Report on a Regular Basis (Activating a Report Action Automatically)

Use a Schedule to Trigger a Report on a Regular Basis

You can use a Schedule to generate, print, or export a report at regular, specified times. Scheduled events are triggered infinitely at the times and regularity indicated on the associated Schedule Display. You choose the type of Schedule that you require in relation to the frequency that the report is to be generated, printed, or exported—Daily, Weekly, Monthly, or Yearly. For more information on using Schedules, see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration.

Example:

A Schedule is configured to generate a series of reports on a weekly basis. Each report summarizes the activity of a number of critical items of plant over the past week.

The Schedule generates the reports automatically at 7am each Monday, in readiness for the 8am Managers’ meeting.

In this example, a Weekly Schedule is used to automatically generate a series of reports at 7am each Monday.

If a report uses Parameters to enable user-specification of the data that is to be included in a report, those Parameters have to be specified when the report is attached to a Schedule.

Example:

A Schedule is used to generate two reports, one of which uses Parameters to specify the Group for which to generate data. The Parameter needs specifying when the report is attached to the Schedule. The Parameter setting is displayed in the Action column at the bottom of the Schedule display:

When generated, this report is to include data for only the Eastern Region.

For information on configuring Parameters, see Parameter Field, and see Allow Users to Specify which Data is Included in a Report.

For other examples of how Parameters can be used in reports, see Configuring a Report that Queries a Historic Table, and see Configuring Reports within Group Templates.


Crystal Reports Driver Guide - Use an Alarm Redirection to Trigger a Report under Particular Conditions (Activating a Report Action Automatically)

Use an Alarm Redirection to Trigger a Report under Particular Conditions

You can use a Method Action Alarm Redirection to generate, print, or export a report automatically should a specific alarm condition occur for a particular item or group of items. Alarm Redirection is available for any database item that can raise an alarm—you configure the properties using the Redirection tab on the item’s Form.

To use Alarm Redirection to generate, print, or export a report automatically, you need to configure a Method Action to specify the report that you want to trigger, and the action that you want ClearSCADA to trigger on that report (for example, ‘Generate Report’). For more information, see Configure a Redirection Action in the ClearSCADA Guide to Alarm Redirection.

You then need to use the Redirection tab on the relevant configuration Form to specify the trigger conditions and the Method Action that you want to trigger. You also need so specify any trigger limitations (such as any Alarm Severity that has to occur before a report is generated, or the time period during which that report is to be generated). For further information, see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection.

Example:

Alarm Redirection is used to generate a report should an alarm remain uncleared and unacknowledged for a period of more than 15 minutes. The report summarizes the events that led up to the alarm occurrence. Engineers use the report data to determine the cause of the alarm.

A Method Action, named ‘Generate Report Action’, is configured to specify the report that is to be generated, should the alarm situation occur:

The Method Action Form is used to specify the report...
...and the action (or ‘method’) that is to be triggered for that report.

The Redirection tab on the relevant Point Form is used to specify the trigger conditions and the Method Action that is to be triggered:

The Trigger State is used to specify that ClearSCADA is to trigger the Method Action if an alarm is Unacknowledged and Uncleared.
The Action field is used to specify the Method Action that ClearSCADA is to trigger (in this case, ‘Generate Report Action’).

The Delay field is used to specify that ClearSCADA is only to trigger the Method Action (and therefore generate the report) if the alarm remains in the Unacknowledged Uncleared state for more than 15 minutes.
The Abort State field is used in conjunction with the Delay field to specify that a report is not to be generated if the alarm is acknowledged and clears within 15 minutes of the alarm being raised.

Further Information

Using the Edit Method window to specify a Method: see Specify a Method in the ClearSCADA Guide to Core Configuration.


Crystal Reports Driver Guide - Using the Crystal Reports Viewer

Using the Crystal Reports Viewer

When you use the Display pick action in ViewX, the selected report is displayed in an inset Crystal Reports Viewer. You use the Viewer to display a report that has been previously generated using the Generate Report pick action.

If the Report is stored historically and more than one version of the report exists on the server, a Select Report window is displayed. Use the window to select the report that you want to display in the Crystal Reports Viewer.

You can use the Viewer to navigate, search, print, and export your reports.

The information in this section helps you to Understand the Crystal Reports Viewer Layout and explains how to:

  • Navigate Around a Report
  • Specify the Report Magnification
  • Specify Whether to Stop Loading Further Report Data
  • Export a Previously Generated Report
  • Print a Previously Generated Report
  • Ascertain the Database Fields that are used in a Report
  • Copy Part of the Report Content.

NOTE: Your system might also contain Mimics with hyperlinks that allow you to display reports directly from those Mimics. As with the Display pick action, when you select such a hyperlink, the report is displayed in the Crystal Reports Viewer. (For an example that summarizes how to set up such a hyperlink, see Display the Latest Report via a Button on a Mimic.)


Crystal Reports Driver Guide - Understand the Crystal Reports Viewer Layout (Using the Crystal Reports Viewer)

Understand the Crystal Reports Viewer Layout

The Crystal Reports Viewer comprises a toolbar and a viewing area in which the selected report is displayed:

If a Report includes Groups, an additional left-hand pane is displayed in the Viewer, allowing you to select the group for which you want to view the report data:

If a report includes Groups, you can use the Group Tree pane to select the group that you require...
...for the Viewer to display the report from that group onwards.

Use the Toggle Group Tree [image] toolbar button to display or close the left-hand pane of the Viewer, as required.

If a Report includes on-demand subreports, an additional tab can be displayed per subreport, to allow you to navigate between the different reports:

A tab for an on-demand subreport...
...is displayed once you select that subreport’s hyperlink on the main report.

With a report that contains on-demand subreports, initially only the tab for the main report is displayed. To display the tab for a subreport, select the hyperlink to that subreport from the main report. (The data for on-demand subreports is only retrieved, as the name suggests, on demand.) For more information on on-demand subreports, see the documentation supplied with the Crystal Reports application.


Crystal Reports Driver Guide - Navigate Around a Report (Using the Crystal Reports Viewer)

Navigate Around a Report

You can use the scroll bars to navigate around a report and the Group Tree pane.

You can also right-click a blank area of the report and select an appropriate menu option, or use the corresponding series of toolbar buttons to access different pages of a multi-page report:

Use the Go to First Page [image] toolbar button to display the starting page of a report.

Use the Go to Previous Page [image] toolbar button to display the page immediately before the one that is presently on display.

Use the Go to Next Page [image] toolbar button to display the page immediately after the one that is presently on display.

Use the Go to Last Page [image] toolbar button to display the final page of a multi-page report.

Use the Page toolbar button to specify the page number that you want to view in a report. Enter the required number and then select the Enter key—the Viewer displays the specified page or if this doesn’t exist, the last page of the report (whichever number is the smaller).

To navigate to another page on a multi-page report, specify the number in the Page field and then press the Enter key.

A multi-page report is indicated by the number adjacent to the Page field initially displaying 1+. This number increments as you select further pages on a report. The total number of pages is indicated by a number without a plus (+) sign.

The total number of pages in a multi-page report is indicated by a number adjacent to the Page field, that doesn’t include a plus (+) sign.

You can navigate a report by using the Search Text [image] toolbar button to search for a particular word or text string.

Select the button to display a Search window, within which you enter the text that you want to search for.

Select the Find Next button to perform the search.


Crystal Reports Driver Guide - Specify the Report Magnification (Using the Crystal Reports Viewer)

Specify the Report Magnification

Use the Magnification toolbar button
to specify the required magnification of a report that is displayed in the Crystal Reports Viewer.

You can enter a value in the Magnification field and press the Enter key, or use the combo box to select a magnification level from a list of options.


Crystal Reports Driver Guide - Specify Whether to Stop Loading Further Report Data (Using the Crystal Reports Viewer)

Specify Whether to Stop Loading Further Report Data

Large or complex reports may take some time to fully load their data.

You can use the Stop Loading [image] toolbar button to cease loading the data for a report.

This is useful, for example, to halt further loading of data if the data you need is already loaded (and there is more data, of no interest, yet to be loaded).


Crystal Reports Driver Guide - Export a Previously Generated Report (Using the Crystal Reports Viewer)

Export a Previously Generated Report

You can use the Export Report [image] toolbar button to export a report that is displayed in the Crystal Reports Viewer.

ATTENTION: If you use the Crystal Reports Viewer to export a report, be aware that the report content may not contain the latest ClearSCADA data. Instead, the report that you export will contain data that has been previously retrieved using the Generate Report pick action.

To export a report a previously generated report:

  1. Display the required report in the Crystal Reports Viewer.
  2. Either:
  1. Select the Export Report button.

Or:

  1. Right-click on a blank area of the report.
    A context sensitive menu is displayed.
  2. Select the Export option.

The Export Report window is displayed.

  3. Use the Format combo box to specify the required export format.

Be aware that the type of format that you select will affect the amount of formatting that is included in the exported version of the report. Additionally, some programmatic-type export formats, such as CSV, are not designed to handle non-record fields, such as report headings or titles.

For further information, see Define the Export Format for a Report, and see the documentation supplied with the Crystal Reports application.

Select the Report Definition option to export information on the structure and format of the report, as specified for the report configuration using the Crystal Reports application. This export option does not export any of the report data content.

  4. Use the Destination combo box to specify the required export destination.

Select an option that is applicable to your system setup.

For example, If you select the MAPI option to export the report in an e-mail, you need to set up Microsoft e-mail on the client computer.

For further information, see Define the Export Destination for a Report, and see the documentation supplied with the Crystal Reports application.

  5. Select the OK button.
    An Options window is displayed, allowing you to specify further export properties. The window content varies, depending on the selected export format. Each window contains parameters similar to those displayed for the same export format on the Crystal Report Form. For information on these properties, see Define the Export Format for a Report.

Example:

If you select the MS Excel 97-2000 (XLS) export format, the Excel Format Options window is displayed. The parameters that you can specify in this window are similar to those that are specified on the Crystal Report Form for the MS Excel 97-2000 export format (see Export the Report in Microsoft Excel Format). Additionally, you can specify which report pages you want to export (see below).

  6. Specify the range of pages that you want to include in the exported version of the report. The page range parameters are displayed in a separate Export Options window, or within the format-specific Options window (as in the example above).

Either:

  1. Select the All option button to export every page of the report.

Or:

  1. Select the Page Range option button to export a specified range of pages.
  2. Use the From and To fields to specify the page range.
  7. Specify the export destination properties using the further window that is displayed. The window varies, depending on the destination type.

Example:

If you specified the MAPI export destination in Step 4 of this procedure, the Send Mail window is displayed. Use the window to specify the recipient, subject matter and any e-mail message.

If you selected the Disk File export destination in Step 4 of this procedure, the Choose Export File window is displayed. Use the window to specify the name and location of the exported report file.

The report is exported in the format and to the destination specified above.


Crystal Reports Driver Guide - Print a Previously Generated Report (Using the Crystal Reports Viewer)

Print a Previously Generated Report

You can print a report that is displayed in the Crystal Reports Viewer by using the Print Setup and Print options from the ViewX File menu.

ATTENTION: If you use the Crystal Reports Viewer to print a report, be aware that the report content will not contain the latest ClearSCADA data. Instead, the report that you print will contain data that has been previously retrieved using the Generate Report pick action.

Be aware that any print settings specified on the report’s configuration Form do not apply when printing a report directly from the Crystal Reports Viewer—instead, you need to specify the required settings using the Print Setup option on the ViewX File menu.


Crystal Reports Driver Guide - Ascertain the Database Fields that are used in a Report (Using the Crystal Reports Viewer)

Ascertain the Database Fields that are used in a Report

To ascertain which database fields are used in a report, use the cursor to ‘hover’ over a data field in the Crystal Reports Viewer—a ToolTip will display the field source.

Example:

Hover over a field...
...to display the field source in a ToolTip
(in this example, the source is the ‘Name’ field in the CDBPoint table).

Alternatively, you can select a field with the cursor and then right-click on the report. The field source is displayed in a context sensitive menu.

Example:

Select a field and then right-click on the report...
...to display the field source in a pop-up menu (in this example, the source is the ‘Name’ field in the CDBPoint table).


Crystal Reports Driver Guide - Copy Part of the Report Content (Using the Crystal Reports Viewer)

Copy Part of the Report Content

You can copy any of the report content from the Crystal Reports Viewer and paste that content to another application. For instance, you might want to copy some of the report content into a document, or paste the content into the Notes that are associated with that report in ClearSCADA.

To select and copy some of report content:

  1. Use the cursor to ‘drag’ a selection box around the fields that you want to select. (You can make multiple selections by holding down the Ctrl key while you select further fields.)
    Use the cursor to drag over the content that you want to copy...

  2. Release the left-hand mouse key.
    The selected fields are highlighted.
    ...the selected content is highlighted, ready for copying.

  3. Right-click on the report in the Crystal Reports Viewer.
    A context sensitive menu is displayed.
  4. Select the Copy option.
    The highlighted selection(s) are copied to the clipboard, ready for pasting into another application.


Crystal Reports Driver Guide - Working with the Reports List

Working with the Reports List

The Reports List is Crystal Reports specific—it is only available on systems that have the Crystal Reports driver installed. You use the Reports List to display a list of the Reports on your system. You can display the List from the Queries Bar or the web interface, as you would any other Lists (see the ClearSCADA Guide to Lists).

As with other Lists, the Reports List consists of rows and columns. Each row represents an individual report entry, and each column contains information about a specific value for that report.

The Reports List contains these column headings:

  • Name—The full name of a report, including its path within the ClearSCADA database.
  • Status—The present activity status of a report. The states that are shown here are identical to those for the Status attribute on the report’s Status display. For more information, see Status.
  • Last Updated—The time and date that a report’s activity status last changed. This entry is identical to the Last Updated attribute on the report’s Status display. For more information, see Last Updated.
  • Quality—The quality of a report’s data. The states that are shown here are identical to those for the Quality attribute on the report’s Status display. For more information, see Quality.
  • Type—The type of database item. This column displays the entry ‘Crystal Report’ for reports that are produced using the Crystal Reports application.
  • Memory Usage—The approximate amount of system memory occupied by a report, specified in bytes.

As with other Lists, you can right-click on an entry in the List to display a context sensitive menu. From this menu, you can select options to display further information about a Report, or request various actions. For information on the actions that are Crystal Reports specific, see Using Actions Associated with Crystal Reports.

ClearSCADA displays the entries on the List using a series of system colors. For information on the driver-specific colors associated with the Crystal Reports List, see Crystal Reports Specific Colors.


Crystal Reports Driver Guide - Crystal Reports Specific Status Display Attributes

Crystal Reports Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item. For instance, the Status display for each Crystal Report provides information about the present state of the individual report.

The same Status display, viewed from a WebX Client:

Use this section if you need information on the status of any reports on your system.

This section covers these attributes that are Crystal Reports specific:

  • Last Updated
  • Quality
  • Status.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Using WebX: see Use the WebX Interface in the ClearSCADA Guide to ViewX and WebX Clients.


Crystal Reports Driver Guide - Alphabetical List of Crystal Reports Specific Status Display Attributes (Crystal Reports Specific Status Display Attributes)

Alphabetical List of Crystal Reports Specific Status Display Attributes

This section lists those status attributes that are specific to Crystal Reports. The attributes are listed in alphabetical order and comprise:

  • Last Updated
  • Quality
  • Status.


Crystal Reports Driver Guide - Last Updated (Crystal Reports Specific Status Display Attributes)

Last Updated

Associated with: Crystal Reports

This attribute indicates the time and date that the report status was last updated. The status is updated whenever ClearSCADA executes a request associated with the report.

Example:

08/Mar/2005 12:54:45.732
(For a Report for which the status was last updated at 12:54:45.732 on the 8th March 2005.)


Crystal Reports Driver Guide - Quality (Crystal Reports Specific Status Display Attributes)

Quality

Associated with: Crystal Reports

This attribute indicates the quality of a report’s data.

Possible States:

  • Good—The report has valid configuration.
  • Out of Service—The report is not functional (online) as it is configured as not In Service. Check with a system administrator as to whether the report should be put online.
  • Not Connected—The report has no definition (it is a new, blank, report). An engineer needs to specify the required report content and layout using the Crystal Reports application (see Configuring the Report Structure and Basic Content).
  • Configuration Error—Part of the report’s configuration is invalid. Correct the configuration errors. (For more information, see Checking for Invalid Configuration in the ClearSCADA Guide to Core Configuration).


Crystal Reports Driver Guide - Status (Crystal Reports Specific Status Display Attributes)

Status

Associated with: Crystal Reports

This attribute indicates the present status of any activity associated with a report, such as a request to export, print, or generate a report.

Possible States:

  • Idle—ClearSCADA is not actively processing any requests associated with, and there are no requests outstanding for, this report. The last request associated with the report was executed successfully.
  • In Progress—ClearSCADA is actively processing a request associated with this report. For example, a request to generate the report.
  • Pending—A request associated with this report is pending (as ClearSCADA is presently processing request(s) for other items). This state will change to ‘In Progress’ when a thread becomes available for use.
  • Failed—The last request associated with the report failed. Refer to the Events List for further information about the failure (for example, an Export request might fail if the export destination cannot be reached).


Crystal Reports Driver Guide - Crystal Reports Specific Colors

Crystal Reports Specific Colors

Each ClearSCADA system is supplied with a set of default system colors. These colors comprise both ‘core system’ and driver-specific colors. Each color is used to indicate the state of an item in the database. The color is used on various ClearSCADA displays to indicate that the item is in a particular state. This section covers the system colors that are specific to the Crystal Reports driver. These comprise the colors that ClearSCADA uses to indicate the following states:

  • Report In Progress
  • Report Pending.

For information on core system colors, see Alphabetical List of Core System Colors in the ClearSCADA Guide to Core Configuration.

NOTE: You can change a default system color by altering its color in the color palette. If you decide to do this, set the new color is unique and unlikely to be confused with other colors on your system. For information on configuring system colors, see Use the Color Palette to Define a Custom System Color in the ClearSCADA Guide to Core Configuration.


Crystal Reports Driver Guide - Report In Progress (Crystal Reports Specific Colors)

Report In Progress

Associated with: Crystal Reports

The Report In Progress status is indicated by a flashing blue foreground color, by default.

The color indicates that a report is being generated, printed, or exported.


Crystal Reports Driver Guide - Report Pending (Crystal Reports Specific Colors)

Report Pending

Associated with: Crystal Reports

The Report Pending status is indicated by a dark blue background color, by default.

The color indicates that a request to generate, print, or export a report is awaiting processing. ClearSCADA can process one request per thread at a time—further requests remain as pending until a thread becomes available.


Crystal Reports Driver Guide - Crystal Reports Specific Driver Log File Options

Crystal Reports Specific Driver Log File Options

This section is designed to be used by system administrators and high-level engineers who need to use diagnostic information to assess the state of the ClearSCADA system. The section is specific to the Crystal Reports driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

NOTE: When troubleshooting on a ClearSCADA system, check the Events List for error messages. These may help to identify the cause of any unexpected system behavior.

Driver logging is useful for investigating driver issues and potential problems. It provides useful diagnostic information for specific aspects of the system. For instance, the Database Objects logging option provides diagnostic information for the individual database items on a particular driver. Those driver logging options that are typically required for investigating driver problems are enabled by default. We suggest that the logging options are left at this default unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

Should you need to contact Schneider Electric for assistance with resolving a problem on your system, you might be asked to provide Log files to help in assessing the cause of the problem. For information on Log files, and defining the Log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration.

This section explains the driver logging options that are available for the Crystal Reports driver. As the Crystal Reports application accesses the ClearSCADA database using ODBC, you may also need to generate ODBC log files (see ODBC Logging in the ClearSCADA Guide to Client Administration).

The Crystal Reports driver log file options are:

  • Application—Logs general information about the driver.
  • Errors—Logs any unexpected failures that occur during driver operation.
  • Timers—Logs information about low-level internal thread timer queues.

ATTENTION: Due to the large amount of information logged when the Timers option is enabled, we recommend that it is disabled. Only enable the Timers option if you are specifically requested to do so by Schneider Electric’s engineers.

  • Events—Logs information about low-level internal thread event queues.

ATTENTION: Due to the large amount of information logged when the Events option is enabled, we recommend that it is disabled. Only enable the Events option if you are specifically requested to do so by Schneider Electric’s engineers.

  • Database Objects—Logs changes to database items.
  • Requests (Actions)—Logs information about any external requests from users, plus internal requests within the driver.
  • Client Sink—Logs information about the low-level interface from server to driver.
  • Server Sink—Logs information about the low-level interface from driver to server.
  • Browse Server—Logs information about the use of browse options on configuration Forms.
  • Crystal Reports—Logs Crystal-specific diagnostic information.


Crystal Reports Driver Guide - Troubleshooting

Troubleshooting

Use this section if you are experiencing problems with the ClearSCADA Crystal Reports driver. The topics that are included in this section explain the actions to undertake when:

  • The Crystal Reports Driver will not Run
  • The Server Fails to Generate a Report
  • A Report is Blank or does not Contain all of the Expected Information
  • The Server Fails to Export Reports to Disk
  • The Server Fails to Export Reports via E-Mail
  • An Unused E-Mail Client on the Server is Storing Copies of E-Mailed Reports
  • Edit and Display Options are not Available for any Reports
  • Display Options are not Available for Reports on WebX Clients
  • Resolving any Trip Sequence Errors.

It also explains the actions that need to be undertaken to Retain the Latest Changes to a Report Should ViewX be Closed.

NOTE: When troubleshooting on a ClearSCADA system, always check the Events List for error messages. These may help you to identify the cause of any problems.

Further Information

For information regarding installation, see Install Crystal Reports.

For information regarding system performance while querying large amounts of data for a report, see Important Guidelines on Configuring and Generating Reports.


Crystal Reports Driver Guide - The Crystal Reports Driver will not Run (Troubleshooting)

The Crystal Reports Driver will not Run

This section explains the actions to undertake if the Crystal Reports driver shuts down whenever it is run.

The Crystal Reports driver uses the server’s specified printing user when printing or exporting reports using the Print Report or Export Report pick actions. The printing user is configured in the Printing section of the ClearSCADA Server Configuration Tool (see Printer Settings in the ClearSCADA Guide to Server Administration).

If a printing user has been specified, but that printing user has invalid configuration (such as the wrong password), the driver will shut down with a ‘Logon failure’ error whenever it is run.

The Crystal Reports driver will log an error of this type:

8007052E - > Logon failure: unknown user name or bad password.
Failed to logon user <name>

(where <name> is the name of the printing user via which the Crystal Reports driver attempted to log on to ClearSCADA.)

If the Crystal Reports driver shutdown occurs, check that the printing user has valid configuration and the necessary read/write access.

(For more information on driver logging, see Crystal Reports Specific Driver Log File Options.)


Crystal Reports Driver Guide - The Server Fails to Generate a Report (Troubleshooting)

The Server Fails to Generate a Report

Reports are generated using the Generate Report pick action.

If report generation fails, an error message appears in the Status bar and is logged in the Event Journal. The error message summarizes the reason that the server failed to generate the report.

As with other many activities on a ClearSCADA system, messages are displayed in the Status Bar, and are logged in the Event Journal.

If the reason that the report failed to generate is due to logon failure, check that:

  • You specify a valid user name and password when asked to log on to ClearSCADA from Crystal Reports.

User access is typically restricted on a per report basis—see Specify the Data Source.

  • The system DSN that enables Crystal Reports to access the ClearSCADA database is correctly set up.

For information on accessing the ODBC Data Source Administrator Tool in which the DSN is configured, see Third Party ODBC Client - System Connections in the ClearSCADA Guide to Client Administration. For recommendations and restrictions, see Server Installation. For more information on configuring DSNs, refer to your Windows® documentation.

If the reason that a report failed to generate is due to a missing table, check that the table(s) that the report references do exist in the database. An error occurs if an attempt is made to generate a report that references a non-existent database table (for example, a custom table such as a Historic View, that has not been configured on the server).

Within ClearSCADA, this message is displayed:

‘Generate report request failed - Failed to generate report, the table “ could not be found...’


Crystal Reports Driver Guide - A Report is Blank or does not Contain all of the Expected Information (Troubleshooting)

A Report is Blank or does not Contain all of the Expected Information

Reports can be used to access data from one or more databases. If a report accesses remote database(s), you need to check that the relevant ODBC data source(s) have been created on each server, and that they allow the necessary access to those database(s). On a Hot-Standby system, remember to also add the same DSNs to any standby server(s). The ODBC data source(s) that are used to create the report(s) require exactly the same names as those that have been created on the relevant servers. (You create each ODBC data source (DSN) using the ODBC Data Source Administrator Tool. On a ClearSCADA server you can access this Tool via the Crystal Reports section of the ClearSCADA Server Configuration Tool (see Configuring Crystal Reports Server Settings). For information on accessing the ODBC Data Source Administrator Tool from a client, see Installation on ViewX Clients on Which You Want to Edit Reports.) Any difference between the DSNs used to create a report and the DSNs on the servers will result in either blank reports, or reports are missing some of the expected information.

If the reports on your system query the ClearSCADA database that is located on the local server and your system uses security, you need to check the user access rights. The user that is used to generate, print or export the reports has to have he necessary access to the database items that are included in those reports. If the user does not have the necessary database access, the reports will either be blank, or may have be missing some of the expected information (they will only contain those items to which the user has read access).

For more information, see Specify the Data Source. (Typically, if a report accesses remote database(s), the user credentials specified in each DSN are used to access each database. If a report only accesses the local ClearSCADA database, these credentials are typically left blank, and a user specified on the Crystal Report Form instead.)

Any changes to items the database can also affect the content of your reports. For example, if a report is filtered or grouped by ‘FullName’ and several database items that appear in the report are later renamed or moved, you need to check the filtering of the report. The change of names and location may cause the filtering to allow or omit records that should/should not be included in the report. For more information, see Adding Fields and Data to a Report.

ATTENTION: It is imperative that formatting of reports that are to be exported to Microsoft Excel is precise. Any objects that are not aligned on such a report may cause the exported version of the report to include blank or mis-aligned rows and/or columns. Ideally, use the Snap to Grid feature on the Options window to position the objects in a report accurately.


Crystal Reports Driver Guide - The Server Fails to Export Reports to Disk (Troubleshooting)

The Server Fails to Export Reports to Disk

The Crystal Reports driver logs on as the server’s printing user to export reports to disk. For this reason, the printing user needs to have write access to the directories and shares to which reports are to be exported. (The printing user is specified in the Printing section of the ClearSCADA Server Configuration Tool (see Printer Settings in the ClearSCADA Guide to Server Administration).)

If the attempt to export a report fails, an error message appears in the Status bar and is logged in the Event Journal. The message indicates the reason that the report has failed to export, for example:

  • An error message of the type ‘Export report request failed - Failed to export report, Access denied’ indicates that the printing user does not have the required write access to the export destination.
  • An error message of the type ‘Export report request failed - Failed to export report, Invalid directory’ indicates that the File Name has not been specified correctly on the Export Destination tab of the Crystal Report Form.

If the File Name on the report’s Export Destination tab contains trip sequence(s) and the report does not export to the expected location, check that the trip sequences have been specified correctly (see Resolving any Trip Sequence Errors).

Further Information

Export the Report to a File on a Disk.


Crystal Reports Driver Guide - The Server Fails to Export Reports via E-Mail (Troubleshooting)

The Server Fails to Export Reports via E-Mail

NOTE: This section only applies when ClearSCADA uses the server’s Windows MAPI settings to export reports via e-mail. ClearSCADA uses Windows MAPI settings to export reports to e-mail when interfacing with Crystal Reports version XI release 2. With systems on which ClearSCADA is configured to interface with Crystal Reports version 2008, you can specify whether reports are to be exported to e-mail using Windows MAPI settings (the default) or SMTP (see Configuring Crystal Reports Server Settings).

Crystal Reports requires a third-party e-mail client to be configured to enable it to send reports via e-mail, using the server’s Windows MAPI settings. Some e-mail clients have security settings that stop third-party applications from sending e-mails without notification. Both ClearSCADA and Crystal Reports require any e-mail transmission to be a seamless process, whereby no dialogs are displayed as a result of an e-mail being sent.

To export reports via e-mail, you need to set up mail for the Windows® user that is specified for printing on each server. Also, the e-mail recipient(s) need to be configured to receive e-mails (see Export the Report in an E-Mail Message).

If your ClearSCADA server also has Microsoft® Outlook®, Microsoft® Outlook Express®, or a similar e-mail client installed, e-mail security may produce a message requesting whether to allow the server to send the e-mail that is exporting a report. To avoid these request messages occurring automatically, you need to disable this aspect of e-mail security.

If Microsoft Outlook Express 6 is the default e-mail client, for example, you can disable this feature as follows:

  1. On the ClearSCADA server, log onto Windows® using the server’s printing user.
  2. Select the Tools menu within Outlook Express.
    A drop-down menu is displayed.
  3. Select the Options option.
    The Options window is displayed.
  4. Select the Security tab.
  5. Clear the Warn me when other applications try to send mail as me check box.
  6. Select the OK button.
    The Options window is closed.
  7. Repeat the above steps on the other ClearSCADA servers on your system (with the exception of Permanent Standby servers).


Crystal Reports Driver Guide - An Unused E-Mail Client on the Server is Storing Copies of E-Mailed Reports (Troubleshooting)

An Unused E-Mail Client on the Server is Storing Copies of E-Mailed Reports

NOTE: This section only applies when ClearSCADA uses the server’s Windows MAPI settings to export reports via e-mail. ClearSCADA uses Windows MAPI settings to export reports to e-mail when interfacing with Crystal Reports version XI release 2. With systems on which ClearSCADA is configured to interface with Crystal Reports version 2008, you can specify whether reports are to be exported to e-mail using Windows MAPI settings (the default) or SMTP (see Configuring Crystal Reports Server Settings).

Crystal Reports requires a third-party e-mail client to be configured to enable it to send reports via e-mail, using the server’s Windows MAPI settings.

You need to check that the Windows® user account that is used for sending e-mails and printing does not store copies of e-mailed reports, or only stores copies of those e-mails for a set lifetime.

For example, if Microsoft Outlook Express 6 is the default e-mail client that is used to send e-mailed reports from Crystal Reports:

  1. On the ClearSCADA server, log onto Windows® using the server’s printing user.
  2. Select the Tools menu within Outlook Express.
    A drop-down menu is displayed.
  3. Select the Options option.
    The Options window is displayed.
  4. Select the Send tab.
  5. Clear the Save copy of sent messages in the ‘Sent Items’ folder check box.
  6. Select the OK button.
    The Options window is closed.
  7. Repeat the above steps on the other ClearSCADA servers on your system (with the exception of Permanent Standby servers).


Crystal Reports Driver Guide - Edit and Display Options are not Available for any Reports (Troubleshooting)

Edit and Display Options are not Available for any Reports

If a report can be generated and exported as normal, but the Edit and Display options are not available from the report’s context sensitive menu, check that the relevant Crystal Reports ViewX Client component is installed on the clients on which reports are to be edited and displayed.

For more information, see Installation on ViewX Clients on Which You Want to Edit Reports, and see Installation on Clients on Which You Only Want to Display or Print or Export Reports.

Also see Display Options are not Available for Reports on WebX Clients.


Crystal Reports Driver Guide - Display Options are not Available for Reports on WebX Clients (Troubleshooting)

Display Options are not Available for Reports on WebX Clients

You can only display the latest generated version of a report on a WebX client if this feature is enabled for that report (see Specify Whether a Report is to be Made Available for Display in WebX).

Also see Edit and Display Options are not Available for any Reports.


Crystal Reports Driver Guide - Retain the Latest Changes to a Report Should ViewX be Closed (Troubleshooting)

Retain the Latest Changes to a Report Should ViewX be Closed

ViewX has to be running on the client on which you are editing a report. This is because any changes that are made can only be transferred back to the ClearSCADA database if ViewX is running.

However, if ViewX is closed while you are editing a report, you can recover any changes that you had made after ViewX was closed. To recover the changes:

  1. Use the Save option to save the report in Crystal Reports.
    If ViewX is no longer running, this action stores a local copy of the report on the client. Follow the rest of the steps in this procedure in order to transfer the local copy back to the ClearSCADA database.
  2. Close the Crystal Reports application.
  3. Restart ViewX on the same head (if you are working on a multi-headed workstation) of the same client (workstation) on which you last edited the report.
  4. Attempt to edit the report on that head.
    A message is displayed, asking if you want to edit the local temporary report, or the copy of the report that is stored in the database.

Example:

  5. If you saved the report as instructed in Step 1 (above), choose ‘Yes’ to edit the local temporary copy of the report.

(If you choose ‘No’ to edit the report that is stored in the ClearSCADA database, any changes that you saved since ViewX stopped running will be lost.)

  6. Use the Save option in Crystal Reports to save the report configuration back into the ClearSCADA database.

You can now continue to edit the report in the usual way.

For other precautions regarding editing and saving reports, see Important Guidelines on Configuring and Generating Reports.


Crystal Reports Driver Guide - Resolving any Trip Sequence Errors (Troubleshooting)

Resolving any Trip Sequence Errors

The export locations for a report, and the ODBC export format, support ‘Trip Sequences’ (see Trip Sequences Supported by ClearSCADA).

Use this section if ClearSCADA is unable to evaluate a trip sequence, or the trip sequence does not evaluate as expected.

Use the table below to determine the cause of any trip sequence errors:

Type of Trip Sequence

Error Message

Description

Date or Time

#ERROR#

The specified format is invalid (see Supported Trip Codes for Dates, or see Supported Trip Codes for Times, as applicable).

Object

#NO REFERENCE#

The referenced field is null (the field does not reference another item and is blank on the associated configuration Form).

This error would occur, for example, should %OParentGroupId.AlarmViewId.Name% be evaluated for a report for which the parent Group does not have an Alarm View associated with it.

#GET REFERENCE FAILED#

ClearSCADA was not able to read the value of the referenced field. This error is unlikely to occur.

#NOT REFERENCE#

The trip sequence incorrectly references a field that is not a reference field.

For example, %ODataSourceLocation.UserId%, where ‘DataSourceLocation’ is a byte field, rather than a reference field.

Refer to the database Schema, or the OPC Data Bar for a comprehensive list of fields and field types.

#AGGREGATE DISABLED#

The trip sequence references a database aggregate that is presently disabled, therefore ClearSCADA cannot display the referenced information.

#REFERENCE NOT FOUND#

The trip sequence contains a reference that is not a field or aggregate.

For example, %OExportDest.TripSequenceTime%, where there is neither a field or aggregate named ‘ExportDest’.

Refer to the database Schema, or the OPC Data Bar for a comprehensive list of the fields that can be specified.

#VALUE ERROR#

ClearSCADA was not able to read the value of the referenced field. This error is unlikely to occur.

#FIELD NOT FOUND#

The trip sequence references a field that does not exist.

(Remember to specify a field’s property name (as listed in the Schema, or OPC Data Bar), rather than its ‘display name’, or the field label shown on the configuration Form, as the latter two vary with the Locale and language assigned to the logged on User).

#GET PROPERTY FAILED#

The Crystal Reports driver has failed to retrieve the specified property from the database. This error is unlikely to occur.

Parameter

#ERROR GET RANGE#

Applies to Range parameters only. This error indicates that ClearSCADA failed to get the value(s) of the range from the report. This error is unlikely to occur.

(Remember that users can optionally omit either the start (No Lower Bound) or end (No Upper Bound) value of a range when a report is exported. If both values are used in a trip sequence, only a single value will be returned if one of the bounds is omitted. If only one of the values is used in the trip sequence and that value/bound is omitted, the trip sequence will be replaced by nothing.)

#INVALID RANGE ITEM#

Applies to Range parameters only. The specified range <sub-item> is invalid: only 'Start' and 'End' (not case sensitive) are valid range items (see Specify a Trip Sequence for a Parameter).

#PARAMETER NOT FOUND#

There is no Parameter with the specified name in the report. (Parameter trip sequences can only be used with reports that contain one or more Parameter Fields.)

Further Information

Specify a Trip Sequence for a Date.

Specify a Trip Sequence for a Time.

Specify a Trip Sequence for a Parameter.

Specify a Trip Sequence for a Report Object.

Specify the Trip Sequence Time.

For information on the database Schema, see Working with ClearSCADA Database Tables in this guide, and see Working with the Database Schema in the ClearSCADA Guide to the Database.


CFX Export Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


CFX Export Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


CFX Export Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


CFX Export Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


CFX Export Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


CFX Export Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to:

  • Add and configure CFX Export items in ClearSCADA.
  • Use actions that are specific to the CFX Export driver
  • Interpret the alarm and event categories that are specific to the CFX Export driver
  • Use the status displays for the CFX Export driver for diagnosis.
  • Use the logging features for the CFX Export driver.

For more details on the subjects covered in this guide, see Introduction to the CFX Export Driver.


CFX Export Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for all levels of user:

  • Engineers who are responsible for configuring CFX Export items and features
  • Operators who use CFX Export-specific actions and alarm and event categories when performing their duties
  • System administrators who may use the CFX Export driver statistics for diagnostics when investigating the cause of any unexpected behavior (relating to the CFX Export driver).


CFX Export Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems] in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


CFX Export Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to the SCADAPack Modbus RealFLO Driver

ClearSCADA Guide to Drivers

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to Alarms

ClearSCADA Guide to Lists

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Alarm Redirection.


CFX Export Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


CFX Export Driver Guide - Introduction to the CFX Export Driver

Introduction to the CFX Export Driver

ClearSCADA’s CFX Export Driver enables gas flow measurement data to be exported from ClearSCADA in Common File Exchange (CFX) format. The CFX file format is proprietary and confidential to Flow-Cal, Inc. Once exported, the data can be imported into any of Flow-Cal’s measurement data management applications.

ClearSCADA can monitor natural gas flow by interfacing with SCADAPack controllers that are running RealFLO™. The RealFLO feature converts SCADAPack controllers into electronic natural gas Flow Computers. To retrieve gas flow measurement data, your ClearSCADA system has to be running the SCADAPack Modbus driver, along with the RealFLO driver extension. A SCADAPack Modbus Flow Run item has to be suitably configured in the ClearSCADA database for each flow run (for which gas flow calculation data is to be retrieved). For further information on SCADAPack Modbus and RealFLO, see the ClearSCADA Guide to the SCADAPack Modbus RealFLO Driver.

To export the retrieved gas flow measurement data in Flow-Cal’s CFX format, your ClearSCADA system has to:

  • Be running the CFX driver. (When that driver is first installed on the system, a system administrator will need to define the settings for the driver (see Configuring CFX Server Settings).)
  • Have at least one CFX Export item in the ClearSCADA database, and the item needs to be suitably configured and put In Service. Users can only define the export properties, including the location to which the data is to be exported, if a suitable CFX Export item exists in the database.

This guide explains how to Add and Configure a CFX Export item in ClearSCADA.

It also explains the CFX specific features that are of interest to operators:

  • CFX Specific Alarm and Event Categories
  • Using CFX Specific Actions

and CFX specific features that may be of interest to system administrators and engineers when investigating unexpected system behavior (relating to the CFX Export driver):

  • CFX Specific Status Display Attributes
  • CFX Specific Driver Log File Options.

For information on gas flow data that is not covered by this guide or the ClearSCADA Guide to the SCADAPack Modbus RealFLO Driver, see the documentation provided with the RealFLO application, or the third-party application to which the retrieved data is to be exported.


CFX Export Driver Guide - Configuring CFX Server Settings

Configuring CFX Server Settings

Some driver-specific settings need configuring on the server by a system administrator when a ClearSCADA system is first installed. These settings are configured using the ClearSCADA Server Configuration Tool.

This section explains the settings that are specific to the CFX Export driver. These settings are in addition to the Drivers global parameters (see Driver Settings in the ClearSCADA Guide to Server Administration).

To access the CFX section of the ClearSCADA Server Configuration Tool and make any necessary configuration adjustments:

  1. Run the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Expand the tree-structure in the left-hand pane, so that the next-level entries are visible within the Global Parameters branch.
  3. Select the CFX entry.

The CFX section is shown in the right-hand pane of the Server Configuration Tool’s window.

  4. A ‘Thread’ is a lightweight process, such as exporting, that can occur at the same time as other threads on a system. The size of the CFX Thread Pool defines the number of export requests that can be performed simultaneously on your system. Be aware that the larger the thread pool, the more resources that are required.

Use the Size spin box to specify how many threads the CFX Export driver can use in order to export sets of Flow Run data concurrently.

  5. Right-click on the server (‘node’) entry in the hierarchical list in the Server Configuration Tool.
    A context-sensitive menu is displayed.
  6. Select the Apply Changes option.
    The changes are applied to the server configuration.
  7. If the server is currently running as the main server, restart the driver for the changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).
  8. Repeat the above steps for each server on your system (except permanent standby servers).


CFX Export Driver Guide - Add and Configure a CFX Export

Add and Configure a CFX Export

In order to specify the format of the file(s) that are generated, and the location to which those file(s) are exported, you need to configure at least one CFX Export item in the ClearSCADA database. (The actual Flow Run for which you want to export data is specified at the time that the export is requested.)

To add a CFX Export item to your database, right click on the Group or Group Template within which you want to add the item. From the context-sensitive menu that is displayed, select the New option, followed by the Other option, and then select CFX Export.

Configure each CFX Export item using the CFX Export Form. The Form has several tabs.

Use the Identification tab to optionally define a Help View and to indicate whether the CFX Export is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).

Use the User Methods tab to define any custom pick actions (‘methods’) for the CFX Export (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).

Use the Alarm tab to define optional features associated with CFX Export alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).

Use the Redirection tab to define any CFX Export alarm redirections (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).

Use the CFX Export tab to:

  • Specify whether the CFX Export is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration)
  • Specify the Severity of any CFX Export alarms and events (see Defining Severities in the ClearSCADA Guide to Core Configuration)
  • If the Area of Interest feature is enabled on your system, specify the area of interest associated with any CFX Export alarms and events (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration)
  • Specify the File Description Information that is Exported
  • Specify the Default Path and Output File Naming Convention
  • Specify Whether the Inputs used for the Gas Calculations are Live or Static.

Use the Export to CFX pick action to export gas flow measurement data from ClearSCADA in Flow-Cal’s CFX format, using the settings specified on the Form.


CFX Export Driver Guide - Specify the File Description Information that is Exported (Add and Configure a CFX Export)

Specify the File Description Information that is Exported

Use the fields within the File Description section of the CFX Export tab to specify the descriptive information that is exported with the gas flow measurement data. The CFX Header is included in each exported file’s header, whereas the Meter Number, Meter Name and Serial Number are typically included at the start of the configuration section in each export file.

  • CFX Header—Use to enter a general description about the exported data. The description can be up to 77 ASCII characters in length, with no special format restrictions. The description appears in the exported file’s header and can be read using the MS-DOS Command Prompt’s Type command.
  • Meter Number—Use the combo box to specify the property from which the exported data’s meter number is derived. Choose from:
  • None—The information is not required to identify the exported data.
  • Flow Computer ID—This is the property from which the Meter Number is derived, by default. Its value is derived from the Flow Computer ID property on the Outstation Form of the controller with which the Flow Run is associated.
  • Flow Run ID—This is the property from which the Meter Name (see below) is derived, by default. Its value is derived from the Flow Run ID on the SCADAPack Modbus Flow Run Form.
  • Flow Run Number—This is the property from which the Serial Number (see below) is derived, by default. Its value is derived from the Flow Run Number on the SCADAPack Modbus Flow Run Form.
  • Meter Name—Use the combo box to specify the property from which the exported data’s meter name is derived. The options are the same as those for the Meter Number, above.
  • Serial Number—Use the combo box to specify the property from which the exported data’s Flow Run serial number is derived. The options are the same as those for the Meter Number, above.


CFX Export Driver Guide - Specify the Default Path and Output File Naming Convention (Add and Configure a CFX Export)

Specify the Default Path and Output File Naming Convention

Use the fields within the Output Path/Name Configuration section of the CFX Export tab to specify these properties:

  • Naming Convention—Use this combo box to specify whether the gas flow measurement data is exported as a single file, or as a series of dated files. This property also specifies the naming convention used if exporting to a series of files.

In each case, use the Default Destination Directory and Default Name/Subdirectory Format fields to specify the export location and subdirectory or file name. Alternatively, allow this information to be specified when the Export to CFX pick action is used to request the export.

Choose from:

  • Specific Filename—The gas flow measurement data is exported to a single CFX file. Use the Default Name/Subdirectory Format field (see below) to specify the default naming convention used for the file.
  • Dated filenames (YYYYMMDDSQ)—The data is exported to a series of CFX files, with one file per day. Each day is a 24-hour ‘Contract Day’, the start of which is defined by the Flow Run’s Contract Hour. The Contract Hour is specified on the SCADAPack Modbus Flow Run Form.

Each export file uses the naming convention <YYYYMMDDSQ>.cfx, where:

YYYY = four digits that indicate the year
MM = two digits that indicate the month
DD = two digits that indicate the day within the month
SQ = two digits that indicate the daily sequence number.

Example:

Gas flow measurement data for a particular Flow Run is exported for the time period 3rd September 2008 to 7th September 2008. The export files use the Dated filenames (YYYYMMDDSQ) naming convention. This results in data being exported to a series of files (one per day) with the names of the format 2008090300.cfx to 2008090700.cfx (where 2008090300.cfx is the file that contains data for the Contract Day that starts on the 3rd September 2008, 2008090700.cfx is the file that contains data for the Contract Day that starts on the 7th September 2008, and so on).

  • Dated filenames (YYMMDDSQ)—The data is exported to a series of CFX files, with one file per Contract Day. Each file uses the naming convention <YYMMDDSQ>.cfx. This is a similar naming convention to that mentioned above, other than the year being represented by two digits, rather than four.

Example:

Gas flow measurement data for a particular Flow Run is exported for the time period 1st September 2008 to 7th September 2008. The export files use the Dated filenames (YYMMDDSQ) naming convention. This results in the data being exported to a series of files (one per day) with the names of the format 08090100.cfx to 08090700.cfx (where 08090100.cfx is the file that contains data for the Contract Day that starts on the 1st September 2008, 08090700.cfx is the file that contains data for the Contract Day that starts on the 7th September 2008, and so on).

  • Default Destination Directory—Use to specify the default location to which the gas flow measurement data is to be exported using this particular CFX Export. Select the browse button to display a Reference browse window, then select the required target directory from the window.

If the Naming Convention is set to ‘Specific Name’, by default, data will be exported to a single .cfx file at this location.

If the Naming Convention is set to one of the Dated options, by default, data will be exported to a series of .cfx files in this directory, or in a subdirectory off this location.

  • Default Name/Subdirectory Format—The function of this field differs, depending on the specified Naming Convention:

If the Naming Convention is set to ‘Specific Name’, use this field to specify the naming convention used for the .cfx export file to which the gas flow data is exported by default.

If the Naming Convention is set to one of the Dated options, use this field to specify the naming convention used for the subdirectory into which the gas flow data is exported as a series of .cfx files.

In each case, use the combo box to specify the required naming convention.

Select an option other than ‘None’ to specify the component(s) that are used to form the name of the default export file or subdirectory. The components themselves reference the Flow Run or Flow Computer properties that identify the source of the gas flow measurement data. Whenever the Export to CFX pick action is used to request an export, ClearSCADA substitutes the details of these components, in order to form the .cfx file or subdirectory name.

The table below contains more information about each component. You can use this information to help determine which naming format is appropriate for your requirements:
Component | Description | SCADAPack Modbus RealFLO Source
FlowRunObjName_ID | The name and identifier that are assigned to the Flow Run database item in ClearSCADA. | This is the name that is assigned to the SCADAPack Modbus Flow Run item in the ClearSCADA database; along with the ID that ClearSCADA automatically assigned to that item when it was added to the database. (You can ascertain a Flow Run’s ID by viewing its Status display.)
Flow Computer ID | The identifier of the Flow Computer with which the Flow Run is associated. | Derived from the Flow Computer ID field on the SCADAPack Modbus RealFLO Outstation Form.
Run# | The Flow Run number. | Derived from the Flow Run Number field on the SCADAPack Modbus Flow Run Form.
Run ID | The Flow Run identifier. | Derived from the Flow Run ID field on the SCADAPack Modbus Flow Run Form.

(For information on configuring Flow Runs in ClearSCADA, see the ClearSCADA Guide to the SCADAPack Modbus RealFLO Driver.)

Example:

A SCADAPack Modbus Flow Run named ‘Flow Run T2’ includes this configuration:

Flow Run Number: 2
Flow Run ID: FR2

ClearSCADA automatically assigned ID 3425 to the Flow Run when the Flow Run database item was added to the database.

The Flow Run’s data is exported in Flow-Cal’s CFX Format. The CFX Export’s Form includes this configuration:

Naming Convention: Specific Filename
Default Destination Directory: C:\Exported_Data
Default Name/Subdirectory Format: FlowRunObjName_ID - Run# (run ID)

Whenever the Export to CFX pick action is used to export that particular Flow Run’s data, the above configuration sets the data to be exported to this file and location by default:

C:\Exported_Data\Flow Run T2_3425 - Run2 (FR2).cfx

Specify the Default Name/Subdirectory Format option ‘None’ if:

  • The Naming Convention is set to one of the Dated options and by default the files are to be exported directly to the Default Destination Directory, rather than to a subdirectory off that directory.

Or:

  • Regardless of Naming Convention, the file or subdirectory name is to be specified manually, whenever the Export to CFX pick action is used to request an export

and:

  • there is no suitable default that can be specified using the Default Name/Subdirectory Format field.

If this latter combination applies, clear the Use Default Path/Name when Exporting check box (see below).

  • Use .CFX Extension on Subdirectory Name—Applies only when a Dated Naming Convention is specified. Select the check box if the name of the subdirectory into which the exported files are to be placed is to be appended with the string ‘.CFX’.

Example:

A CFX Export includes this configuration:

Naming Convention: Dated filenames (YYYYMMDDSQ)
Default Destination Directory: C:\Exported_Data
Default Name/Subdirectory Format: Run#(run ID)
Use .CFX Extension on Subdirectory Name: check box selected

Whenever the Export to CFX pick action is used to export gas flow data for a Flow Run that has this configuration:

Flow Run Number: 2
Flow Run ID: FR2

by default, the data is exported to a series of .cfx files at this location:
C:\Exported_Data\Run2(FR2).cfx\

Clear the check box if the subdirectory is not to be appended with ‘.CFX’.

Example:

A CFX Export includes the configuration specified above, with the exception of this property:

Use .CFX Extension on Subdirectory Name: check box clear

This results in files for the above mentioned Flow Run being exported, by default, to this directory:
C:\Exported_Data\Run2(FR2)\

  • Use Default Path/Name when Exporting—Select this check box if the data is only to be exported to the name and directory defined in the Default Destination Directory and Default Name/Subdirectory Format fields. (If the Naming Convention is set to ‘Specific Name’, you need to specify a Default Name/Subdirectory Format other than ‘None’.)

Clear the check box to allow a name and directory to be specified whenever the Export to CFX pick action is used to trigger an export. Any defaults that are specified in the Default Destination Directory and Default Name/Subdirectory Format fields are used should no other name and directory be specified at that time.

  • Overwrite Existing Files—Select this check box if each new export file is to overwrite any existing file of the same name.

Clear the check box if older export files with the same name are to be retained. Should older files with the same name exist in the specified export location, any attempt to export data using the Export to CFX pick action will be unsuccessful. The pick action can only be performed successfully after the existing files have either been moved, removed, or renamed.

  • Time Zone Setting—Use this combo box to specify the time zone that ClearSCADA applies when exporting gas flow measurement data. Choose from:
  • Coordinated Universal Time (UTC)—For the exported data to use Coordinated Universal Time (UTC).
  • Local Time with Daylight Saving Time—For the exported data to use Local Time. ClearSCADA automatically adjusts the time to account for Daylight Saving Time (DST).
  • Local Time without Daylight Saving Time—For the exported data to use Local Time; for instance EST (Eastern Standard Time) if the local time zone is that for the East coast of America. No adjustments are made for any Daylight Saving Time (DST).

For more information on Time Zone settings, see Time Zone Support in ClearSCADA in the ClearSCADA Guide to Core Configuration.


CFX Export Driver Guide - Specify Whether the Inputs used for the Gas Calculations are Live or Static (Add and Configure a CFX Export)

Specify Whether the Inputs used for the Gas Calculations are Live or Static

Use the check boxes in the Live Input Flags section of the CFX Export tab to specify which input data used in the Flow Runs’ calculations is ‘live’ (obtained from another device in real time) and which is static (obtained from offline analysis). Only select those check boxes for data that is calculated in real time, either directly or indirectly (for instance using a program running in the controller or other means, if direct real-time data retrieval is not supported.)

  • Live Gas Composition (A)—Select this check box if the gas composition data used in the Flow Runs’ calculations is calculated in real time. The gas composition analysis flag is flag A.

Clear the check box (the default) if gas composition data is not calculated in real time.

  • Live Energy (B)—Select this check box if the heating value of the gas that is being measured by each Flow Run is calculated in real time. The heating value is flag B.

Clear the check box (the default) if the heating value is not calculated in real time.

  • Live Gravity (G)—Select this check box if the specific gravity (or relative density) of the gas that is being measured by each Flow Run is calculated in real time. The live gravity flag is flag G.

Clear the check box (the default) if the specific gravity or relative density data is not calculated in real time.

Information on whether each check box is selected or not is included with the data that is exported in Flow-Cal’s CFX format. (Some third-party flow calculation applications can handle a Flow Run’s historic data differently, depending whether the inputs used for the Flow Run’s calculations are live or static.)


CFX Export Driver Guide - Using CFX Specific Actions

Using CFX Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. These actions can be triggered automatically by ClearSCADA or can be activated manually by a user (typically by selecting an action from a context-sensitive menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients)).

This section explains the Export to CFX action that is specific to the CFX Export driver.

NOTE: Users with the required permissions can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as 'methods').

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


CFX Export Driver Guide - Export to CFX (Using CFX Specific Actions)

Export to CFX

Associated with: CFX Exports

Use the Export to CFX pick action to export gas flow measurement data from ClearSCADA in Flow-Cal’s Common File Exchange (CFX) format. The pick action enables gas flow data that ClearSCADA has retrieved from any SCADAPack Modbus Flow Run(s) on the system to be exported to a suitable third-party application for data analysis.

The data that is exported includes the Flow Run’s configuration, current readings, and (if available for the time period specified) alarm log, event log, and hourly history data. If any of the latter data does not exist for the date range requested for the export, those particular section(s) in the resulting CFX file(s) will include a message to that effect (for example, ‘No Alarms’).

The Export to CFX pick action is only available if your User Account is allocated the Control security permission for the CFX Export. In addition, your User Account has to be allocated the Read and Browse security permissions for the Flow Run item(s) for which you want to export data in Flow-Cal’s CFX format.

NOTE: If the data is being exported to removable media, please check that the media is at the required location and is available for use. For example, if the data is to be stored on a CD-R, check that a suitable CD-R is in the CD-RW driver of the server before the gas flow measurement data is exported.

Select the Export to CFX pick action to display the Export to CFX window. Use the fields in the window to specify the Flow Run and period for which data is to be exported:

  • ID of the Flow Run for which data will be exported—Specify the required Flow Run. Use the adjacent browse button to display a Reference browse window. Use the window to navigate the list of SCADAPack Modbus Flow Run items that exist on the system. Select the required Flow Run from the window.
  • Export start date—Use to specify the date of the earliest Flow Run data that is to be exported in Flow-Cal’s CFX format. For information on specifying a different date to the default, see Specifying the Required Entry in a Date and Time Field in the ClearSCADA Guide to Core Configuration.
  • Export end date—Use to specify the date of the most recent Flow Run data that is to be exported.

If the Use Default Path/Name when Exporting check box is clear on the CFX Export’s configuration Form (see Specify the Default Path and Output File Naming Convention), an additional field is displayed in the Export to CFX window:

  • Destination filename/directory—Enter the required directory path and file name. A default name and directory will be displayed in this field if a Default Destination Directory is specified on the CFX Export’s configuration Form—overtype the entry with the required directory or file name, as required.

Select the OK button to trigger the export. ClearSCADA will export the data in the format that is specified on the CFX Export’s configuration Form. You can ascertain the progress of an export by monitoring its Status. For more information, see CFX Specific Status Display Attributes.

Should an export be unsuccessful, ClearSCADA will raise an alarm. The alarm message will indicate the reason for the export failure. The alarm will clear once a successful export is performed. For more information, see CFX Specific Alarm and Event Categories.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name Export. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)

Example:

A typical CFX Export:

(If there is no Historic data, Alarms, or Events for the specified period of time, the export to CFX will be successful, but the tabs for which no data is available will display entries such as ‘No Alarms’ or ‘No Events’.)


CFX Export Driver Guide - CFX Specific Alarm and Event Categories

CFX Specific Alarm and Event Categories

Each alarm and event on a ClearSCADA system has a Category that indicates the type of alarm or event. The Category is included by default in the Events List and, if applicable, the Alarms List and the Alarm Banner.

You can optionally filter the entries in either List by category—the entries from which you can choose comprise various ‘core’ categories, along with any categories that are specific to the drivers that are installed on your system.

On systems on which the CFX Export driver is installed, in addition to the ‘core’ alarm and event categories, this CFX-specific category is available:

  • CFX Export—Entries associated with CFX Export activity.

Further Information

Events Lists and ‘core’ filter categories: see the ClearSCADA Guide to Lists.

Alarms Lists and ‘core’ filter categories: see the ClearSCADA Guide to Alarms.


CFX Export Driver Guide - CFX Specific Status Display Attributes

CFX Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for a CFX Export provides information about the present state of that item.

Use this section if you need information on the status of any CFX Export database items on your system.

This section explains the CFX Export Alarm and Status attributes that are specific to the CFX Export driver.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


CFX Export Driver Guide - CFX Export Alarm (CFX Specific Status Display Attributes)

CFX Export Alarm

Associated with: CFX Exports

This status attribute indicates whether the last Export to CFX request completed successfully.

Possible states: Displays one of the Standard Alarm States.


CFX Export Driver Guide - Status (CFX Specific Status Display Attributes)

Status

Associated with: CFX Exports

This status attribute indicates the present state of an export request.

The possible states are:

  • Idle—No data export is in progress.
  • Pending—An Export to CFX action associated with this CFX Export database item is awaiting execution.
  • In Progress—An Export to CFX action associated with this CFX Export item is presently under way.
  • Failed—This state indicates that the most recent Export to CFX action was unsuccessful. The status will remain Failed until another export is requested, and then the Status attribute will change to indicate the status of the new action. The cause of the failure will be indicated by an entry in the Alarms List and Alarm Banner (see CFX Specific Alarm and Event Categories).


CFX Export Driver Guide - CFX Specific Driver Log File Options

CFX Specific Driver Log File Options

This section is designed for system administrators and high-level engineers who need to use statistical and diagnostic information to assess the state of the ClearSCADA system. This section is specific to the CFX Export driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

NOTE: When troubleshooting on a ClearSCADA system, use the Events List to view diagnostics messages. The messages may help you to identify the cause of any unexpected behavior.

Driver logging is useful for investigating unexpected behavior relating to a driver. It provides useful diagnostic information for specific aspects of the system.

Should you need to contact Schneider Electric for assistance with resolving a problem on your system, you might be asked to provide Log files. Schneider Electric engineers may be able to use the information in the Log files to diagnose the cause of the unexpected behavior on your system. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

This section explains the driver logging options that are available on the CFX Export driver.

Those driver logging options that are typically required for investigating unexpected driver behavior are enabled by default. We suggest that these options are left enabled unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

For information on log files and defining the log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration.

The CFX Export driver log file options are:

  • Application—Logs general information about the driver.
  • Errors—Logs any unexpected failures that occur during driver operation.
  • Timers—Logs information about low-level internal thread timer queues.

ATTENTION: When enabled, the Timers option can cause a large amount of information to be logged. This can make it more difficult to locate information of interest, due to the high amount of data. It is also possible that the information required maybe overwritten if the log files become full very quickly. For this reason, we recommend that the Timers option is disabled and that you only enable it if specifically asked to do so by a Schneider Electric engineer.

  • Events—Logs information about low-level internal thread event queues.

ATTENTION: When enabled, the Events option can cause a large amount of information to be logged. This can make it more difficult to locate information of interest, due to the high amount of data. It is also possible that the information required maybe overwritten if the log files become full very quickly. For this reason, we recommend that the Events option is disabled and that you only enable it if specifically asked to do so by a Schneider Electric engineer.

  • Database Objects—Logs changes to database items.
  • Requests (Actions)—Logs information about any external requests from users, plus internal requests within the driver.
  • Client Sink—Logs information about the low-level interface from server to driver.
  • Server Sink—Logs information about the low-level interface from driver to server.
  • Browse Server—Logs information about the use of browse options on configuration Forms.
  • CFX Export—Logs CFX export-specific diagnostic information.


ICMP Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


ICMP Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


ICMP Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


ICMP Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


ICMP Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


ICMP Driver Guide - Document Scope (About the Guide)

Document Scope

This guide describes:

  • How to configure ICMP-specific points in ClearSCADA.
  • Driver-specific aspects that are of interest to operators
  • Driver-specific aspects that are of interest to system administrators and engineers during any fault finding on the system.

For more information on the subjects covered in this guide, see Introduction to the ICMP Driver.


ICMP Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by all levels of user:

  • Engineers who are responsible for configuring ICMP points in ClearSCADA
  • Operator-level users whose duties require them to use the ICMP driver features
  • System administrators who are interested in statistics and diagnostics information relating to the ICMP driver.


ICMP Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


ICMP Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Alarms

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Lists

ClearSCADA Guide to Drivers

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to ViewX and WebX Clients.


ICMP Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


ICMP Driver Guide - Introduction to the ICMP Driver

Introduction to the ICMP Driver

The Internet Control Message Protocol (ICMP) is one of the core network operations and maintenance protocols. The ICMP protocol is often used by operating systems to send diagnostics messages indicating, for instance, that a remote device cannot be reached.

The ClearSCADA ICMP Driver utilizes the ICMP’s Ping Tool functionality to detect whether network-connected remote device(s) are reachable. It does this by sending ICMP Echo Request Messages to each remote device, and expects those devices to each respond by sending back an ICMP Echo Response message. If ClearSCADA does not receive a response within a specified time period, it can re-attempt to poll a device for a specified number of times. Should it still receive no response, it will set the relevant point to State 1, indicating failure.

ClearSCADA also uses ICMP for hot-standby link monitoring. Such monitoring is completely independent from the ICMP driver and does not require the ICMP driver to be running or installed on ClearSCADA. (For information on ICMP hot-standby link monitoring, see ICMP Polls in the ClearSCADA Guide to the Server Status Tool).

The ICMP Driver documentation explains how to configure ICMP-specific points in ClearSCADA (see Configuring ICMP Points in ClearSCADA).

It also explains:

  • Driver-specific aspects that are of interest to operators (see Using ICMP Specific Actions)
  • Driver-specific aspects that may be of interest to system administrators and engineers when investigating any unexpected system behavior relating to the driver (see ICMP Specific Status Display Attributes, and see ICMP-Specific Driver Log File Options).


ICMP Driver Guide - Configuring ICMP Points in ClearSCADA (Introduction to the ICMP Driver)

Configuring ICMP Points in ClearSCADA

For ClearSCADA can use ICMP to detect whether network-connected devices are reachable. To do this, the ICMP Driver has to be installed and running on the ClearSCADA servers on your system.

You also need to configure one ICMP Digital Point in the ClearSCADA database for each network-connected device that the driver is to monitor using ICMP (see Configuring ICMP Digital Points).

You need to be aware of which optional features are required for each ICMP Point. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use other core ClearSCADA features with ICMP Points, including Lists, Actions and Mimics. For actions that are specific to the ICMP driver, see Using ICMP Specific Actions. For further information on actions and for details on Lists and Mimics, see the core documentation.


ICMP Driver Guide - Configuring ICMP Digital Points

Configuring ICMP Digital Points

For each network-connected device that you want ClearSCADA to monitor using the ICMP driver, you need to create and configure an ICMP Digital Point in the ClearSCADA database.

Each ICMP Digital Point can be in either of two states:

  • State 0 indicates that ClearSCADA can poll the remote device successfully
  • State 1 indicates that ClearSCADA cannot poll the device.

Configure the properties of each digital point using the fields on the ICMP Digital Point Form.

The Form has these tabs:

  • Identification—Use to optionally define a Help View and to indicate whether the point is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for the point (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with alarms for the point (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the point (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • Digital Point—Use to:
  • Configure the Basic Point Properties
  • Configure the Poll Properties
  • Configure the Point States (see Define the Point States for a Digital Point in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Trend Properties (see Define a Digital Point’s Trend Settings in the ClearSCADA Guide to Core Point Configuration)
  • Configure the Override Properties (see Define whether a Digital Point can be Overridden in the ClearSCADA Guide to Core Point Configuration).
  • Historic—Use to define any historic data storage for the point (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).


ICMP Driver Guide - Configure the Basic Point Properties (Configuring ICMP Digital Points)

Configure the Basic Point Properties

Use the fields at the top of the Digital Point tab to configure the basic properties of an ICMP Digital point:

  • In Service—Use to specify whether the point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point that is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Device—Use to specify the remote network-connected device with which this point is associated.

To specify a computer that is on the local network, select the browse button to display a Reference browse window and select the required device from the window.

To specify any other IP-connected device, enter the machine name, or the IP address, directly in the Device field.

  • Format—Specify the format in which the point’s value appears in other ViewX displays, such as Lists. For further information, see Define the Format of a Digital Point’s Values in the ClearSCADA Guide to Core Point Configuration.
  • Severity—Use this combo box to define the severity of any non-state events or alarms for the point.

For more information on severities, see Defining Severities in the ClearSCADA Guide to Core Configuration.

  • Area of Interest—Only displayed if the Area of Interest feature is enabled on your system. Use this field to specify the Area of Interest with which any non-state related point alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).


ICMP Driver Guide - Configure the Poll Properties (Configuring ICMP Digital Points)

Configure the Poll Properties

Use the fields within the Poll section of the Digital Point tab to specify these poll properties:

  • Poll Interval—Use to specify the frequency with which the ICMP driver polls the remote device. Enter the interval in the OPC Time Format, for example 1M for a one-minute interval.
  • Timeout—Use to specify how long the driver is to wait to receive a response to each poll request. If the driver does not receive a response within this time, it re-attempts the poll, for up to the maximum number of Retries (see below).

Enter the timeout in the OPC Time Format, for example 0.1S for 100 milliseconds.

  • Retries—If a poll is unsuccessful, the ICMP driver will re-attempt to poll the remote device for up to the number of retries specified in this field. Should the driver re-attempt to poll the device for this number of times and not receive a response from the device, the device is deemed to have failed.

Use the Retries field to specify the maximum number of times that the ICMP driver is to re-attempt to poll the remote device should it not respond to a poll.

Enter 0 if only one poll is required to determine whether the device has failed.

  • Data Size—Specify the size of the data segment that the ICMP driver transmits in a single data packet to the remote device. The remote device echoes the data segment back to the driver.


ICMP Driver Guide - ICMP Specific Alarm and Event Categories

ICMP Specific Alarm and Event Categories

Each alarm and event on a ClearSCADA system has a Category that indicates the type of alarm or event. The Category is included by default in the Events List and, if applicable, the Alarms List and the Alarm Banner.

You can optionally filter the entries in either List by category—the entries from which you can choose comprise various ‘core’ categories, along with any categories that are specific to the drivers that are installed on your system.

On systems on which the ICMP driver is installed, in addition to the ‘core’ alarm and event categories, this ICMP specific category is available:

  • ICMP Configuration Error—Entries associated with ICMP point configuration that contains an invalid IP address or node name. The ICMP driver generates such entries whenever it receives invalid configuration messages from the device(s) that it is polling.

Each ICMP point has an ICMP Config Alarm status attribute that indicates whether an ICMP Configuration Error was reported when the driver last attempted to retrieve the point’s data. You can ascertain the status of this attribute by viewing an ICMP point’s Status display (see ICMP Specific Status Display Attributes).

Further Information

Events Lists and ‘core’ filter categories: see the ClearSCADA Guide to Lists.

Alarms Lists and ‘core’ filter categories: see the ClearSCADA Guide to Alarms.


ICMP Driver Guide - Using ICMP Specific Actions

Using ICMP Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see the ClearSCADA Guide to ViewX and WebX Clients).

This section covers the Reset Poll Statistics action, which is specific to the ICMP driver.

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


ICMP Driver Guide - Reset Poll Statistics (Using ICMP Specific Actions)

Reset Poll Statistics

Associated with: ICMP Digital Points

Security permission required to access this pick action: Diagnostics

Use the Reset Poll Statistics pick action to reset the Poll Times statistics for a point. The statistics indicate, for example, the number of times that the ICMP driver has polled the device with which the point is associated (see Poll Times).

NOTE: If using this pick action with the Automation Interface, you need to specify the method name ResetStatistics.


ICMP Driver Guide - ICMP Specific Status Display Attributes

ICMP Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for each ICMP Digital Point provides information about the present state of the point and the remote IP-connected device that the point represents.

Use this section if you need information on the status of any ICMP digital points on your system (see ICMP Digital Point Status Attributes).

Further Information

Working with Status displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


ICMP Driver Guide - ICMP Digital Point Status Attributes (ICMP Specific Status Display Attributes)

ICMP Digital Point Status Attributes

This section lists the Status attributes that are specific to points on the ICMP Driver. The attributes are listed in alphabetical order and comprise:

  • ICMP Config Alarm
  • Poll Statistics
  • Poll Times.


ICMP Driver Guide - ICMP Config Alarm (ICMP Specific Status Display Attributes)

ICMP Config Alarm

Associated with: ICMP Digital Points

The ICMP Config Alarm attribute indicates whether the point configuration contains an invalid IP address or node name. (This error is only detected when the driver attempts to poll the specified device—any other configuration errors are detected by the server, at the time that the configuration is saved.)

Possible States: Displays one of the Standard Alarm States. If an alarm state is displayed, this is followed by the time and date at which the alarm occurred.

Example:

Enabled Active Fleeting at 31/Oct/2006 at 11:52:09.637

If an alarm state is displayed, use the Events or Alarms List to ascertain further information about the cause of the alarm. You can filter either List so that it only shows those entries that are specifically related to such an alarm (see ICMP Specific Alarm and Event Categories).


ICMP Driver Guide - Poll Statistics (ICMP Specific Status Display Attributes)

Poll Statistics

Associated with: ICMP Digital Points

The Poll Statistics attribute indicates the time and date at which the Poll Times statistics were last reset.

You can reset the statistics using the Reset Poll Statistics pick action. If the poll statistics have been reset, two sets of Poll Statistics attributes are displayed. The first displays the statistics since the last reset of the poll statistics; the second displays the statistics between the previous two resets.

Example:

Since 03/Nov/2006 11:56:16.136

If the statistics have been reset, a second entry will display statistics in the form:

Between 03/Nov/2006 10:18:53.945 and 03/Nov/2006 11:56:16.136


ICMP Driver Guide - Poll Times (ICMP Specific Status Display Attributes)

Poll Times

Associated with: ICMP Digital Points

The Poll Times attribute indicates the number of times that the ClearSCADA server has polled the remote device since the Poll Statistics were last reset. It also indicates:

  • How many of those polls were successful (Good)
  • How many of those polls were unsuccessful (Bad)
  • The transmission time of the Last poll
  • The Maximum transmission time since the Poll Statistics were last reset, in milliseconds
  • The Minimum transmission time since the Poll Statistics were last reset, in milliseconds
  • The Average time that the polls have taken since the Poll Statistics were last reset.

If the Poll Statistics have been reset, two sets of Poll Times attributes are displayed. The first displays the statistics since the last reset; the second displays the statistics between the previous two resets.

Example:

79 Polls, 79 Good, 0 Bad, Last 0.789206ms, Maximum 17.4098ms, Minimum 0.551467ms, Average 0.911682ms.


ICMP Driver Guide - ICMP-Specific Driver Log File Options

ICMP-Specific Driver Log File Options

This section is designed for use by system administrators and high-level engineers who need to use diagnostic information to assess the state of the ClearSCADA system. contains information that is specific to the ICMP driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

NOTE: When troubleshooting on a ClearSCADA system, use the Events List to view any diagnostics messages. These messages may help you to identify the cause of any unexpected behavior.

Driver logging is useful for investigating unexpected driver behavior. It provides useful diagnostic information for specific aspects of the system. For instance, the Points logging option provides diagnostic information for the points on a particular driver. Should you need to contact Schneider Electric for assistance with resolving a problem on your system, you might be asked to provide Log files to help in assessing the cause of the problem. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

This section explains the driver logging options that are specific to the ICMP driver.

Those driver logging options that are typically required for investigating driver problems are enabled by default. We recommend that you leave the default logging options in place unless you are asked to change the logging options by Schneider Electric, or the default options are adversely affecting system performance.

For information on Log files and defining the Log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration.

The ICMP driver log file options are:

  • Application—Logs general information about the driver.
  • Errors—Logs any errors detected during driver operation. For example, communications failures, or a failure to connect to the ClearSCADA database.
  • Timers—Logs information about low-level internal thread timer queues.

ATTENTION: When enabled, the Timers option can cause a large amount of information to be logged. This can make it more difficult to locate information of interest, due to the high amount of data. It is also possible that the information required maybe overwritten if the log files become full very quickly. For this reason, we recommend that the Timers option is disabled and that you only enable it if specifically asked to do so by a Schneider Electric engineer.

  • Events—Logs information about low-level internal thread event queues.

ATTENTION: When enabled, the Events option can cause a large amount of information to be logged. This can make it more difficult to locate information of interest, due to the high amount of data. It is also possible that the information required maybe overwritten if the log files become full very quickly. For this reason, we recommend that the Events option is disabled and that you only enable it if specifically asked to do so by a Schneider Electric engineer.

  • I/O—Logs information about low-level I/O.
  • Database Objects—Logs changes to database items.
  • Points—Logs changes to point configuration within ClearSCADA.
  • Requests (Actions)—Logs information about any external requests from users, plus internal requests within the driver.
  • Point Updates (Data)—Logs information about point data retrieved by the driver.
  • Client Sink—Logs information about the low-level interface from server to driver.
  • Server Sink—Logs information about the low-level interface from driver to server.
  • Browse Server—Logs information about the use of the browse options on configuration Forms.
  • ICMP Diagnostics—Contains diagnostic information that is specific to the ICMP driver. For instance, information about the packets that it has received.
  • Comms Logging—Logs information about the communications between ClearSCADA and the network-connected remote devices. The option creates a global comms log for the whole driver. The log file is named DriverICMP Poll IO_nnn.log (where nnn is the sequential number of the log file—for instance, 002).


Pager Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Pager Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


Pager Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


Pager Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


Pager Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


Pager Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to configure and operate your ClearSCADA system so that it can communicate with pager devices and mobile telephones.

For details on the subjects covered in this Guide, see Introduction to the Pager Driver.


Pager Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed to be used by engineer-level users who are responsible for configuring the system and devices to communicate via the following protocols:

  • TAP - Telocator Alphanumeric input Protocol
  • Multitone
  • UCP - Universal Computer Protocol
  • SMS - Short Message Service.

The Guide also provides information on pager actions, pager alarms and events, and pager logging for operator-level users and system administrators.


Pager Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


Pager Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Security

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to the Server Status Tool

ClearSCADA Guide to Expressions

ClearSCADA Guide to Drivers

ClearSCADA Guide to Alarms

ClearSCADA Guide to Lists.


Pager Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


Pager Driver Guide - Introduction to the Pager Driver

Introduction to the Pager Driver

Welcome to the Pager Driver Guide. In this Guide, we provide information about the Pager Driver and explain how you can configure your ClearSCADA system to utilize its features. When you have configured your Pager Services, Pager Channels, and User accounts as described, you will be able to use ClearSCADA to send messages to pager devices and mobile telephones.

The Pager Driver Guide consists of the following sections:

  • Understanding the Pager Driver
  • Protocols Supported by the Pager Driver
  • Configuring Pager Devices in ClearSCADA
  • Configuring a Pager Service
  • Configuring a Pager Channel
  • Configuring a User Account's Pager Properties
  • Configuring Pager Server Settings
  • Sending a Message to a Pager or Mobile Phone
  • Using SMS to Trigger an Action
  • Using Pager Specific Actions
  • Pager Specific Alarm and Event Categories
  • Pager Specific Status Display Attributes
  • Pager-Specific Driver Log File Options.

The information in the Pager Driver Guide is designed to provide you with information on the pager-specific properties that you will need to use when configuring your system to use the Pager Driver. For information on those properties that feature on Pager items and displays but are not specific to pagers, you should refer to the core (non-driver-specific) documentation.

If you are familiar with how the Pager Driver works and the protocols it supports, we recommend that you refer to Configuring Pager Devices in ClearSCADA. There, you will find information on the various items you need to configure to allow the Pager Driver to send messages to pagers and mobile telephones.

When you have configured the necessary database items, you can use ClearSCADA's actions to send messages manually. Alternatively, you can configure ClearSCADA to send messages in response to alarms or periodically.


Pager Driver Guide - Understanding the Pager Driver (Introduction to the Pager Driver)

Understanding the Pager Driver

The Pager Driver allows ClearSCADA to send messages to pagers and mobile phones. This is useful as it means information such as alarm messages can be sent to remote users who are remote from a client. For example, an alarm message could be sent to the pager of an engineer who is traveling between sites.

The Pager Driver works by allowing ClearSCADA to send messages using the following protocols:

  • TAP - Telocator Alphanumeric input Protocol
  • Multitone
  • UCP - Universal Computer Protocol
  • SMS - Short Message Service.

These protocols are the standard protocols used for pager and mobile telephone communications.

For information on how to configure your ClearSCADA system to use the Pager Driver, see Configuring Pager Devices in ClearSCADA.


Pager Driver Guide - Protocols Supported by the Pager Driver (Introduction to the Pager Driver)

Protocols Supported by the Pager Driver

The Pager Driver supports the following protocols:

  • TAP - Telocator Alphanumeric input Protocol
  • Multitone
  • UCP - Universal Computer Protocol
  • SMS - Short Message Service.


Pager Driver Guide - TAP - Telocator Alphanumeric input Protocol (Introduction to the Pager Driver)

TAP - Telocator Alphanumeric input Protocol

TAP (Telocator Alphanumeric input Protocol) is a long-established protocol that is used to send one-way alphanumeric messages to pagers and mobile telephones.

The TAP paging protocol requires a modem to communicate with the service provider. Depending on the equipment used, the TAP protocol can enable text messages to be sent to pagers or mobile telephones.

With TAP, ClearSCADA sends messages to a pager or mobile phone by using the Pager Driver to communicate with the Service Provider via a modem. This message is then sent by the network service provider which then sends the message to the receiving device over a communications network.


Pager Driver Guide - Multitone (Introduction to the Pager Driver)

Multitone

The Multitone protocol was developed by Multitone Electronics PLC for use with Multitone pager systems. Usually, Multitone pager systems are site-based systems with some or all of the pager devices situated locally (within range of the transmitter).

With Multitone systems, ClearSCADA communicates with a Multitone pager by using the pager driver to send a message to the Multitone devices (encoder, transmitter, and so on). This message is then broadcast to the relevant Multitone pager device. However, the Multitone pager device can only receive the message if it is within the signal range of the transmitter.


Pager Driver Guide - UCP - Universal Computer Protocol (Introduction to the Pager Driver)

UCP - Universal Computer Protocol

Universal Computer Protocol is used for sending messages to pagers and mobile telephones. While TAP is the more commonly used protocol for sending messages to pagers and mobile telephones, some countries use UCP, in particular Belgium and those in the Scandinavia region.

The communications setup for UCP is similar to that for TAP, with ClearSCADA sending the message to the Service Provider via a modem. The only difference is that the UCP protocol is used instead of the TAP protocol. For more information, see TAP - Telocator Alphanumeric input Protocol.


Pager Driver Guide - SMS - Short Message Service (Introduction to the Pager Driver)

SMS - Short Message Service

Short Message Service (SMS) is a communications protocol specially designed for sending text messages between mobile telephone devices. It is used throughout the world.

The communications setup required for ClearSCADA to send SMS messages is similar to that for TAP - Telocator Alphanumeric input Protocol.

However, SMS has some key differences:

  • Advantages:
  • Your system is not reliant on the network service provider permitting dial in access to their network. This also means that your system is not affected if the network service provider does provide dial in access but uses a protocol not supported by ClearSCADA.
  • Your system is not reliant on a conventional telephone line. Conventional telephone lines may not be available if the server is in a remote location, or may be available but extremely costly.
  • Disadvantages:
  • The volume of messages that you can send is low in comparison to TAP and UCP. Both TAP and UCP allow you to send many more messages in a short space of time.
  • SMS messages may be more costly to use as they invariably involve a greater cost per message.

Your GSM modem needs to support these protocol commands:
Command | Purpose
ATM0V1E0H0S0=0 | This initial poll string consists of standard Hayes modem commands that turn on verbose mode and turn off echo, auto-answer, and speaker. They also check that the GSM modem is ready to send data.
AT+CMEE? | This queries the levels of error-support offered by the GSM modem.
AT+CMEE=<n> | Where <n> = 0-2 (the angle brackets < > are not included). This command sets the GSM modem to the highest available error-support mode (determined from the query).
AT+CMGF=1 | Checks that the GSM modem is set to text mode before it attempts to send messages.
AT+CMGS="<recipient number>" | Sends a text message to the defined recipient number (the angle bracket < > are not included). When the GSM modem responds to the command, the message is sent. When the message has been sent, the command is terminated by Ctrl-Z.

These commands are supported by many GSM modems and are the only commands supported by the Pager driver.

For further information on this protocol, please refer to the Global System for Communications (GSM) document: Digital cellular telecommunications system (Phase 2+); Use of Data Terminal Equipment - Data Circuit terminating; Equipment (DTE - DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) (GSM 07.05 version 5.5.0). This document can be searched for, and downloaded from, this web site: http://pda.etsi.org/pda/queryform.asp

The commands used by the Pager Driver when sending an SMS message are:
Command | Description
AT+CMEE=? | Requests the modem to respond with its error support number. The error support number indicates the level of error support that is provided by the modem.
AT+CMGF=1 | Puts the modem into Text mode so that it can send text characters, as required for sending SMS messages.
AT+CSCS='GSM' | Checks that the modem is set to use the GSM 03.38 character set so that non-Roman characters can be sent correctly. If the modem cannot be put into GSM 03.38 mode, an error occurs.
AT+CMGS='<telephone number>' Where <telephone number> is the telephone number of the mobile telephone that is to receive the SMS message. | Identifies the mobile telephone to which the message is to be sent. The GSM modem responds to this with a prompt for the body of the message. You then enter the body of the message and the GSM modem sends the message to the telephone number defined in this command.


Pager Driver Guide - Configuring Pager Devices in ClearSCADA (Introduction to the Pager Driver)

Configuring Pager Devices in ClearSCADA

For ClearSCADA to make use of the pager/mobile telephone messaging features, you need to configure:

  • Pager Services—ClearSCADA uses Pager Services to determine which protocol to use when sending messages (see Configuring a Pager Service)
  • Pager Channels—ClearSCADA uses these to determine which physical connections (ports and so on) are to be used when sending a message (see Configuring a Pager Channel)
  • User Accounts—ClearSCADA uses the User accounts of system users to determine which pager device or mobile telephone is to receive a message (see Configuring a User Account's Pager Properties).
  • Pager Settings at the Server—Typically, you would only need to consider adjusting the Multipage SMS Message Timeout setting if there are alarms on your system relating to the delivery of incomplete multipage messages (see Configuring Pager Server Settings).

Before you can configure these items, you need to have access to, or an understanding of, the settings of the pagers and mobile telephones that are going to be used with your system. This is because many of the settings you need to define in the ClearSCADA database have to correspond to the settings of the relevant pager equipment. For example, when you configure a User account, you will need to enter a Pager ID that corresponds to the pager number or mobile telephone number of the device owned by the user of the account.

You also need to know which of the optional features are required for your pager items. The optional features include alarm views, alarm redirections, and User methods.

When you have the pager settings information and you understand which optional features are required, you can proceed with configuring the pager items on your system:

  1. Install the Pager Driver on each of the ClearSCADA servers in your system and check that it is running. To install the Pager Driver, simply re-install ClearSCADA and set the installation to include the Pager Driver.
  2. Check that appropriate Pager settings are in place on the ClearSCADA server (see Configuring Pager Server Settings).
  3. Configure a Pager Service for each protocol that is required (see Configuring a Pager Service). You will need to configure additional Pager Services for each variation in the protocol settings, for example, if you need SMS Pager Services with different timeout settings, you will need an SMS Pager Service item for each variation.
  4. Configure a Pager Channel to represent each connection between the Pager Driver and the Service Provider (see Configuring a Pager Channel).
  5. Configure the User accounts for those members of staff that are going to need to receive messages on their pager devices or mobile telephones. Each of these User accounts has to:
  • Have a Pager ID number so that the system can send a message to the correct pager or mobile phone
  • Be associated with the relevant Pager Service.

For more information on defining the Pager ID and the Pager Service, see Configuring a User Account's Pager Properties.

When you have configured the properties described above, you can send messages manually to those system users that have a pager device/mobile telephone. For further information, see Sending a Message Manually.

If automatic messaging is required, some further configuration is needed:

  • If pager and SMS messages are to be sent automatically when certain alarm conditions occur, you will also need to configure Alarm Redirections (see Redirecting Alarm Messages to Pagers or Mobile Phones Automatically).
  • If pager messages are to be sent automatically at regular time intervals, you will need to configure a schedule. You will also need to associate the recipient's User account with the schedule and set up the Send Message or Send Pager Message action. For more information, see Scheduling Automatic Pager and SMS Messages.

When you have successfully configured the pager items, they will be available for use in the ClearSCADA database. You can use the pager items with the core ClearSCADA features, including Lists, Actions and Mimics. For example, it is possible for operators to filter the Alarms and Events Lists so that they only display those entries that are associated with the state of Pager Comms. For further information:

  • see Welcome to the ViewX and WebX Clients Guide in the ClearSCADA Guide to ViewX and WebX Clients
  • see Welcome to the ClearSCADA Guide to Lists in the ClearSCADA Guide to Lists
  • see Introduction to the Pager Driver in the ClearSCADA Guide to Alarms.

NOTE: The configuration Forms for Pager items contain a series of tabs. Some of these tabs are common to many types of database item and have no Pager-specific properties (see Tabs on Configuration Forms). In this guide, we explain how to configure those properties that are specific to Pager items.


Pager Driver Guide - Tabs on Configuration Forms (Introduction to the Pager Driver)

Tabs on Configuration Forms

The configuration Forms for Pager items (Pager Services and Pager Channels) contain a combination of common and item-specific tabs.

The common tabs are available on the Forms for many types of database item:

  • Identification—Use to define a Help View and to indicate whether the Pager item is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions ('methods') for an item (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the item (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).

The item-specific tabs contain properties that are specific to the Pager Service or Pager Channel:

  • Channel—Use to define the physical connection properties (see Configuring a Pager Channel).
  • <Pager> Service—Use to define the properties of the protocol to be used (see Configuring a Pager Service). The name of the <Pager> Service tab varies according to the type of Pager Service. For example, the <Pager> Service tab for an SMS Pager Service is named SMS Service.


Pager Driver Guide - Configuring a Pager Service

Configuring a Pager Service

ClearSCADA uses Pager Service database items to represent the various protocols that are required on your system. The configuration of each Pager Service item defines which protocol is to be associated with that Pager Service and also specific properties such as the maximum message size and limits for timeouts. So, while there are only four protocols, you may need to configure a greater number of Pager Service items, for example, if you have two GSM modems, you would need two SMS Pager Services and two SMS Pager Channels.

In this section, we explain how to:

  • Define the Minimum Configuration for Pager Services
  • Create a Pager Service Database Item
  • Display the Pager Service Form
  • Configure the Common Pager Service Properties
  • Configure a Multitone Pager Service
  • Configure a TAP Pager Service
  • Configure a UCP Pager Service
  • Configure an SMS Pager Service.


Pager Driver Guide - Minimum Configuration for Pager Services (Configuring a Pager Service)

Minimum Configuration for Pager Services

For a successful Pager Service, the minimum configuration requirement is:

  • The Pager Service has to be placed In Service (active)
  • The Telephone Number of the Service Provider's access point has to be defined (TAP and UCP Pager Services only).

There are defaults for every other Pager Service configuration, so the Pager Service can be associated with a Pager Channel of the appropriate type (see Configuring a Pager Channel).

For ClearSCADA to be able to send a message to a pager device or mobile telephone, there has to be:

  • a valid Pager Service
  • a valid Pager Channel associated with the Pager Service
  • Correctly configured Pager Contact details for the User account of the user that receives the message.

Further Information

Configuring a User Account's Pager Properties.

Sending a Message to a Pager or Mobile Phone.


Pager Driver Guide - Create a Pager Service Database Item (Configuring a Pager Service)

Create a Pager Service Database Item

To create a new Pager Service database item, you need to use the New>Pager>Pager Service options that are available from the context-sensitive menu in the Database Bar of ViewX. There are options for each type of Pager Service as well as each type of Pager Channel.

The New>Pager>Pager Service options are only available if the Pager Driver is installed and you log on to ViewX via a User account that has the Configure Database permission (in the User account configuration).

When you add a Pager Service database item, you will need to define an appropriate name (see Naming Restrictions in the ClearSCADA Guide to Core Configuration). When you have entered a name for the Pager Service, you can begin to configure the item by displaying its Form (see Display the Pager Service Form).


Pager Driver Guide - Display the Pager Service Form (Configuring a Pager Service)

Display the Pager Service Form

Each Pager Service item has a Form which contains the configurable properties, including timeouts, number of retries, and maximum message lengths. You need to use the Pager Service Form when setting up your system to communicate with pagers and mobile telephones via the Pager Driver.

To display the Pager Service Form, right-click on the Pager Service database item in the Database Bar, then select the Properties option. You have to be logged on via a User account that has the Configure Database permission. (If the Pager Service item does not already exist in the database, you will need to Create a Pager Service Database Item.)

NOTE: There are several other ways of displaying a Form for a database item (see Display a Form. in the ClearSCADA Guide to Core Configuration).

When you have displayed the Form for your Pager Service database item, you can use it to define the properties of the service. For more information, see:

  • Configure a Multitone Pager Service
  • Configure a TAP Pager Service
  • Configure a UCP Pager Service
  • Configure an SMS Pager Service.

Further Information

Displaying Configuration Forms: see Display a Form in the ClearSCADA Guide to Core Configuration.

User Account Database Items and Permissions: see User Accounts in the ClearSCADA Guide to Security.


Pager Driver Guide - Configure the Common Pager Service Properties (Configuring a Pager Service)

Configure the Common Pager Service Properties

The Pager Service configuration Form contains several tabs. The Identification, User Methods, Alarm, and Redirection tabs are common to many types of database item (see Tabs on Configuration Forms). The <Pager> Service tab is specific to Pager Services and varies according to the type of Pager Service. For example, the Form for a TAP Pager Service has a TAP Service tab.

Each <Pager> Service tab contains properties that define how ClearSCADA uses the Pager Service. Some of these properties are available for multiple types of Pager Service (common properties), while others are specific to a certain type. For example, the Multitone Pager Service Form and the UCP Pager Service Form both have the 'common' Maximum Message Length property, but only the UCP Pager Service Form has the Standard Reply Delay property (this is a UCP-specific property).

In this section, we explain how to use those properties that are available on the <Pager> Service tab of the Pager Form for multiple types of Pager Service (these are the 'common' Pager Service properties):

  • In Service—Use to set the Pager Service database item to active or inactive in the database (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Telephone Number—Only applies to UCP Pager Services and TAP Pager Services. TAP and UCP Pager Services connect to the service provider via a modem. To make the connection, the modem needs to call the telephone number of the service provider. Use to the Telephone Number field to define the telephone number of the Service Provider. You can obtain the correct telephone number from your service provider. If a valid telephone number is not supplied, the modem will be unable to make a connection.
  • Maximum Message Length—Use to define the maximum number of characters permitted per message (see Define the Maximum Message Length Properties for a Pager Service)
  • When Message Length Exceeded—Use to define what method is used to shorten the message if the number of characters in the message exceed the Maximum Message Length (see Define the Maximum Message Length Properties for a Pager Service).
  • Severity—Use to set the importance (severity) of alarms and events that are raised or logged for the Pager Service (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed on the <Pager> Service tab. Use the field to specify the Area of Interest with which any Pager Service alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Retries—Use to define the number of times the Pager Driver will attempt to -resend the entire message should the initial attempt to send the message fail (see Define the Retry and Timeout Properties for a Pager Service).
  • Timeout—The Timeout property varies according to the type of Pager Service you are configuring:
  • For Multitone, TAP and UCP Pager Services, you can use the Timeout property to define the amount of time that the Pager Driver will wait for a response to a message. If there is no response within the defined time limit, the Pager Driver will attempt to resend the message for a defined number of times (Retries). If there is still no reply, the message is deemed to have failed. For more information, see Define the Retry and Timeout Properties for a Pager Service.
  • For SMS Pager Services, you can use the Timeout property to define the amount of time that the Pager Driver will wait before sending another request (retrying a request). If the Pager Driver does not receive a reply to the retry request, the message is deemed to have failed. For more information, see Define the Retry and Timeout Properties for a Pager Service.

For information on those properties that are specific to a particular type of Pager Service, you should refer to the relevant section:

  • Configure a TAP Pager Service
  • Configure a UCP Pager Service
  • Configure an SMS Pager Service.

NOTE: Multitone Pager Services only have common configuration properties (they have no service-specific configuration properties).


Pager Driver Guide - Define the Maximum Message Length Properties for a Pager Service (Configuring a Pager Service)

Define the Maximum Message Length Properties for a Pager Service

Every pager and mobile telephone has a maximum number of characters that it can receive in a single message. As this limit can vary between devices, you need to include the limit supported by your devices in the Pager Service configuration. This allows ClearSCADA to determine whether a message is going to exceed the message size supported by the recipient mobile telephone or pager.

If ClearSCADA needs to send a message that does exceed the limit that is supported by the recipient pager or mobile telephone, ClearSCADA will attempt to shorten the message. You can use the Pager Service configuration to choose the method of message shortening that ClearSCADA will use.

To define the maximum message length and the action to be taken if the message length is exceeded:

  1. Display the Pager Service Form.
  2. Select the <Pager> Service tab, for example, for a Multitone Pager Service, select the Multitone Service tab.
  3. Define the Maximum Message Length. This has to match the maximum message length that is supported by the recipient mobile telephone or pager. For more details, please refer to the documentation supplied with your pager or mobile telephone.

The Maximum Message Length should be long enough to contain plain text message and any parameter substitutions that are included as a result of using trip characters. Trip characters are only relevant to alarm messages that are redirected automatically (see Trip Sequences Supported by Redirection Actions in the ClearSCADA Guide to Alarm Redirection).

NOTE: For UCP Pager Services, the highest amount you can enter for the Maximum Message Length is dependent on whether the Service Provider is set to use Long Messages. If it is set to use Long Messages, the Maximum Message Length can be up to 640. If Long Messages are not used, the Maximum Message Length can be up to 160.

  4. Use the When Message Length Exceeded property to specify which message shortening method ClearSCADA will use to reduce the size of any messages that exceed the Maximum Message Length.

Choose from:

  • De-Vowel—If a message exceeds the Maximum Message Length, ClearSCADA attempts to shorten the message. First it removes duplicate spaces, then if the message is still too large, it will remove duplicate letters (one letter at a time until the message fits). If the message is still too large, ClearSCADA will remove the vowels one letter at a time, starting with the first word in the message. If the vowels are removed and the message still exceeds this length, the message is then truncated (see the Truncate option, below).
  • Truncate—If a message exceeds the Maximum Message Length, those characters that appear after the limit are omitted. For example, if the Maximum Message Length is 160 and a message contains 168 characters, the characters from 161 to 168 inclusive will be removed from the message before the pager driver sends it to the relevant pager or mobile telephone.

ATTENTION: If you choose the Truncation option, engineers will need to include the crucial part of any message within the Maximum Message Length.

  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Define the Retry and Timeout Properties for a Pager Service (Configuring a Pager Service)

Define the Retry and Timeout Properties for a Pager Service

In normal conditions, the Pager Driver sends a message to a pager or mobile telephone and receives a confirmation message in response (this response may be from the device or from the network provider). This confirmation message allows ClearSCADA to determine whether a message was sent and received successfully.

However, on systems where there are networking problems or electromagnetic noise issues, the Pager Driver may fail to receive a response to the messages it transmits. When a Pager Driver fails to receive a response, it either:

  • Deems the message to have failed immediately (the Pager Channel and Pager Service are not configured to make use of Comms Retries and Retries)

or

  • Attempts to send the message again (this is dependent on the configuration of both the Pager Channel and the Pager Service):
  1. ClearSCADA checks to see whether the Pager Channel makes use of the Comms Retries feature. If it does, the Pager Driver will attempt to re-send the data packet of the message that previously failed. If there is a response to the first re-sent packet, the Pager Driver completes the transmission by sending any remaining packets. If there are no responses to the initial data packet, the Pager Driver deems the Comms Retries to have failed.
  2. If the Pager Service being used is a Multitone, TAP or UCP Pager Service and is configured to use Retries, the Pager Driver will disconnect from the pager service ('hang up') and will then wait for a defined amount of time for a response (the Timeout). When the timeout has expired, the Pager Driver will reconnect to the pager service and attempt to re-send the entire message.
  • If the retry is successful and a response is received, the original message is recognized as being successful, even though there was not a response when it was first sent.
  • If the retry attempt is unsuccessful, the Pager Driver will continue to try and re-send the entire message until the maximum number of retries limit is reached (defined by the Retries property in the Pager Service configuration).

With SMS Pager Services, the process differs slightly as the Timeout defines the amount of time the Pager Driver will wait before re-sending a request, rather than the amount of time it waits for a response. If the Pager Driver does not receive a response to a request within the Timeout period, it will send the request again when the Timeout period expires.

If the Pager Service responds to a communications attempt with an error, this would indicate that the communications are healthy but the Pager Service could not allow the message due to an error. Depending on the type of error, the Pager Service will either abandon the attempt to send the data packet or will continue to retry until the defined number of Retries have been exhausted (see Define the Number of Communications Retries for a Pager Channel).

If the permitted Pager Channel Comms Retries and the Pager Service Retries are unable to solicit a response from the recipient network service provider, the message is deemed to have failed. Appropriate alarms and events will be generated and logged in ClearSCADA.

You can use the Pager Service Form to define:

  • The maximum number of Retries for the Pager Service
  • The Timeout that is applied when the Pager Driver disconnects from the modem following an unsuccessful retry attempt.

To define the maximum number of retries for a Pager Service:

  1. Display the Pager Service Form.
  2. Select the <Pager> Service tab, for example, for a Multitone Pager Service, select the Multitone Service tab.
  3. In the Retries field, specify the maximum number of times that the Pager Driver will attempt to re-send a message that previously failed. Remember that this setting is for re-sending the entire message and is only used after the Comms Retries of the Pager Channel have attempted.

The default setting is 2, which is suitable for many systems. However, you can increase or decrease this amount as required.

We recommend that you limit any increases to the Retries limit so that it is lower than 10. A Retries limit of more than 10 may result in long delays between a message being sent and that message being recognized as failed (if the transmission is unsuccessful).

NOTE: With TAP and UCP Pager Services, each retry is sent in a separate call. So if an initial message attempt is unsuccessful, the call will be terminated and a new call will be established for the retry attempt(s).

  4. In the Timeout field, enter the amount of time (in seconds) that has to pass before the Pager Driver attempts to create a new call for a retry attempt. The default amount of 30 seconds is usually appropriate, but you may need to change the setting if the service provider requires an extended period. Your service provider should be able to provide you with information on a suitable timeout setting.
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Define the Number of Communications Retries for a Pager Channel.


Pager Driver Guide - Configure a Multitone Pager Service (Configuring a Pager Service)

Configure a Multitone Pager Service

If your system is using Multitone pagers, you need to configure Multitone Pager Service database items to represent the Multitone protocol.

Each Multitone Pager Service item represents the Multitone pager protocol and has a range of properties including timeouts and retries. If you have multiple Multitone systems, you will need to configure one Multitone Pager Service and one Multitone Channel for each system. This is because a Multitone Pager Service has a one-to-one relationship with a Multitone Pager Channel.

To configure a Multitone Pager Service:

  1. Log on to your system via a User Account that has the Configure Database permission (see User Account Permissions in the ClearSCADA Guide to Security).
  2. Display the Pager Service Form for the Pager Service item you want to configure. If the item does not already exist in the database, you will need to Create a Pager Service Database Item.
  3. Configure the properties on the Identification, User Methods, Alarm, and Redirection tabs as required (see Tabs on Configuration Forms)
  4. Configure the properties on the Multitone Service tab. The properties are common to many Pager Services (see Configure the Common Pager Service Properties).
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

When you have configured and saved a Multitone Pager Service, you will be able to associate it with Pager Channels and User accounts.

Further Information

Configure a Multitone Pager Channel.

Configuring a User Account's Pager Properties.


Pager Driver Guide - Configure a TAP Pager Service (Configuring a Pager Service)

Configure a TAP Pager Service

If your pager or mobile telephone provider uses a TAP interface to send messages, you will need to configure TAP Pager Service database items to represent the TAP protocol.

You need to configure one TAP Pager Service for each service provider through which you wish to send messages. For example, in the UK, to send messages through the Vodafone and Orange networks, you would need to configure two TAP Pager Services, one for the Vodafone network and one for the Orange network.

With TAP Pager Services (and UCP Pager Services), you can use multiple channels for redundancy. For example, two Pager Channels could be assigned to the same TAP Pager Service, with one channel acting as a back-up channel in case of difficulties connecting via the other channel. However, each Pager Channel can only be assigned to one Pager Service.

To configure a TAP Pager Service:

  1. Log on to your system via a User Account that has the Configure Database permission (see User Account Permissions in the ClearSCADA Guide to Security).
  2. Display the Pager Service Form for the Pager Service item you want to configure. If the item does not already exist in the database, you will need to Create a Pager Service Database Item.
  3. Configure the properties on the Identification, User Methods, Alarm, and Redirection tabs as required (see Tabs on Configuration Forms).
  4. Select the TAP Service tab.
  5. Configure the 'common' Pager Service properties on the tab (see Configure the Common Pager Service Properties).
  6. Configure these TAP-specific properties on the tab:
  • Password—Some TAP service providers offer a subscription service that is password-protected. If the TAP service used on your system is password-protected, enter the password for your subscription service in the Password field (the password is supplied by the service provider). The password allows ClearSCADA to establish a connection with the TAP Pager Service provider.

Leave the Password field blank (empty) if your TAP Pager Service provider does not use password-protection.

  • Service Supports a Beep Code—Use to toggle Beep Code support on and off. You should only enable this feature if your Service Provider supports beep codes (can instruct a pager device or mobile telephone to make different sounds). For more information, see Enable or Disable Beep Code Support for a TAP Pager Service.
  7. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Configuring a Pager Channel.


Pager Driver Guide - Enable or Disable Beep Code Support for a TAP Pager Service (Configuring a Pager Service)

Enable or Disable Beep Code Support for a TAP Pager Service

Some pager service providers support a beep code. This is a simple ASCII code that is sent with the pager message and it instructs the pager to make a particular sound (beep). The sound that is made will vary according to the type of device and the pager service provider.

You can use ClearSCADA to send beep codes to TAP pagers, but this functionality is only available if you enable the Service supports a beep code property on the TAP Pager Service Form.

To enable or disable beep code support for a TAP Pager Service:

  1. Display the Pager Service Form.
  2. Select the TAP Service tab.
  3. Either:
  • Select the Service supports a beep code check box to enable the beep code support feature. You should only check this check box if the pager service provider supports beep codes. Your pager service provider should be able to provide information on whether beep codes are supported, and if so, which codes can be used.

Or:

  • Clear the Service supports a beep code check box to disable the beep code support feature. This is the default setting.
    Check or clear the Service supports a beep code check box on the TAP Service tab.

  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

If you have enabled the beep code feature, users will be able to define a beep code when they send a message. The code that they enter will instruct the recipient pager to make a specific sound when it receives the message.

Further Information

Sending a Message to a Pager or Mobile Phone.

Configure a TAP Pager Service.


Pager Driver Guide - Configure a UCP Pager Service (Configuring a Pager Service)

Configure a UCP Pager Service

If your pager or mobile telephone service provider uses a UCP interface to send messages, you need to configure UCP Pager Service database items to represent the UCP protocol.

You need to configure one UCP Pager Service for each service provider through which you wish to send messages. For example, to send messages in Norway through the Telenor and TMN networks, you would need to configure two UCP Pager Services, one for the Telenor network and one for the TMN network.

With UCP Pager Services (and TAP Pager Services), you can use multiple channels for redundancy. For example, two Pager Channels could be assigned to the same UCP Pager Service, with one channel acting as a back-up channel in case of difficulties connecting via the other channel. However, each Pager Channel can only be assigned to one Pager Service.

To configure a UCP Pager Service:

  1. Log on to your system via a User Account that has the Configure Database permission (see User Account Permissions in the ClearSCADA Guide to Security).
  2. Display the Pager Service Form for the Pager Service item you want to configure. If the item does not already exist in the database, you will need to Create a Pager Service Database Item.
  3. Configure the properties on the Identification, User Methods, Alarm, and Redirection tabs as required (see Tabs on Configuration Forms).
  4. Select the UCP Service tab.
  5. Configure the 'common' Pager Service properties on the tab (see Configure the Common Pager Service Properties).
  6. Configure the following UCP-specific property:
  • Standard Reply Delay—Use to define the amount of time the Pager Driver will wait for a response to a sent message. If the service provider does not respond within the Standard Reply Delay time, the Pager Driver deems the transaction to have failed. It will attempt to resend the message a specified number of times (defined by the Pager Channel’s Comms Retries property and the Pager Service’s Retries property), and if there is still no response, it will deem the message to have failed. For more information, see Define the Standard Reply Delay for a UCP Pager Service.
  7. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Configuring a Pager Channel.

Define the Retry and Timeout Properties for a Pager Service.

Define the Number of Communications Retries for a Pager Channel.


Pager Driver Guide - Define the Standard Reply Delay for a UCP Pager Service (Configuring a Pager Service)

Define the Standard Reply Delay for a UCP Pager Service

When the Pager Driver sends a message via a UCP Pager Service provider, it sends the message data in a single transmission. This includes the commands, pager or telephone number, and the actual body of the message. When the Pager Service provider receives the message from ClearSCADA, it forwards it to the relevant pager or mobile telephone and a response is sent to ClearSCADA.

If ClearSCADA does not receive a response within a specified amount of time, the message that was sent is deemed to have failed. Depending on the configuration of the Pager Service and Pager Channel, ClearSCADA may attempt to resend the message.

The amount of time that ClearSCADA will wait for a response from the UCP network provider is defined via the Standard Reply Delay property on the UCP Pager Service Form. By default, the Standard Reply Delay is 1000 milliseconds, but you may need to change this if messages sent via UCP are failing. If an Unknown error message is reported for the failed pager message, it is likely that the Standard Reply Delay is too short; the pager, mobile telephone or service provider cannot send a response signal within the defined amount of time. In this situation, you should increase the Standard Reply Delay time and then attempt to send messages again. Continue to increase the Standard Reply Delay time until the messages are successful. If you have increased the Standard Reply Delay significantly, for example, from 1000 milliseconds to 10000 milliseconds and the message continues to fail, the error is possibly related to a network problem rather than the Standard Reply Delay property (your service provider may be able to provide information relating to network issues).

To set the Standard Reply Delay:

  1. Display the Pager Service Form.
  2. Select the UCP Service tab.
  3. Enter the Standard Reply Delay time in the Standard Reply Delay field. The default setting of 1000 milliseconds is usually appropriate.
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Configure an SMS Pager Service (Configuring a Pager Service)

Configure an SMS Pager Service

If you are using a GSM modem to send SMS messages to pager devices or mobile telephones, you need to configure SMS Pager Service database items to represent the SMS protocol.

For each GSM modem that you are going to use, you will need to configure one SMS Pager Service and one SMS Pager Channel.

To configure an SMS Pager Service:

  1. Log on to your system via a User Account that has the Configure Database permission (see User Account Permissions in the ClearSCADA Guide to Security).
  2. Display the Pager Service Form for the Pager Service item you want to configure. If the item does not already exist in the database, you will need to Create a Pager Service Database Item.
  3. Configure the properties on the Identification, User Methods, Alarm, and Redirection tabs as required (see Tabs on Configuration Forms).
  4. Select the SMS Service tab.
  5. Configure the 'common' Pager Service properties on the tab (see Configure the Common Pager Service Properties).
  6. Define whether an SMS Service can Process Incoming Messages.
  7. Define the Number of Times an SMS Service will attempt to Process Messages.
  8. Define whether ClearSCADA Replies to Incoming SMS Messages.
  9. Define the Data Coding Scheme for an SMS Service
  10. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Configure an SMS Pager Channel.


Pager Driver Guide - Define whether an SMS Service can Process Incoming Messages (Configuring a Pager Service)

Define whether an SMS Service can Process Incoming Messages

You can configure an SMS Service to process incoming messages so that users can issue commands remotely via SMS. This is a useful feature as it means users can perform actions and issue controls from almost anywhere.

If an SMS Service has its Process Incoming SMS Messages feature enabled, it can allow incoming SMS messages and will process them. Those messages that contain a valid command alias or valid command (full reference to a method) will be processed and the system will execute the relevant methods. Any messages that are invalid are disregarded (there is a limit to the number of failed SMS messages that may occur in sequence, see Define the Number of Times an SMS Service will attempt to Process Messages).

If an SMS Service has its Process Incoming SMS Messages feature disabled, any incoming SMS messages will be disregarded and so users will not be able to issue controls remotely via SMS.

By default, the Process Incoming SMS Messages feature is disabled for added security. If you enable the Process Incoming SMS Messages feature, we advise you to check that appropriate security settings (User accounts, Permissions, and so on) are in place to prevent unauthorized access to controls. For more information, please refer to the ClearSCADA Guide to Security.

To define whether an SMS Service can process incoming messages:

  1. Display the Pager Service Form.
  2. Select the SMS Service tab.
  3. Select the Process Incoming SMS Messages check box to enable or disable the feature as required. The feature is disabled when the check box is clear (empty).
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Define the Number of Times an SMS Service will attempt to Process Messages.

Method Calls: see Stand-Alone Method Calls in the ClearSCADA Guide to Core Configuration.


Pager Driver Guide - Define the Number of Times an SMS Service will attempt to Process Messages (Configuring a Pager Service)

Define the Number of Times an SMS Service will attempt to Process Messages

Each SMS Service has an Incoming SMS Fail Limit which you can configure on the SMS Service Form. This property allows you to define when ClearSCADA will generate an alarm associated with an SMS service receiving invalid SMS messages.

The Incoming SMS Fail Limit works in conjunction with an internal Fail count which starts at 0 and increases by 1 each time an invalid SMS message is received. It is reset to 0 each time a valid SMS message is received or when a manual reset is triggered (see Checking and Resetting the Fail Count for an SMS Service). If the Fail count exceeds the Incoming SMS Fail Limit, an alarm is raised.

An SMS message is deemed to be invalid if:

  • The SMS message received by the Pager Driver has an invalid structure. SMS messages consist of a variety of components, including protocol information, a time stamp, and the body of the message. If an SMS message does not contain the required components of a valid message, the Pager Driver will not process the message and will instruct ClearSCADA to increase the Fail count will rise by 1.

If the Pager Driver receives a signal that does not contain any SMS message components (for example, some other form of unsolicited signal), the signal is disregarded. This will have no effect on the Fail count as the signal was not identified as an SMS message.

  • ClearSCADA has received a message that has valid SMS components (as detected by the Pager Driver) but ClearSCADA is unable to preform the command. ClearSCADA cannot perform SMS commands if it is unable to match the database item and method (or command alias) defined in SMS message to a corresponding item and method in the database. This may occur when a user has made a mistake when entering the command in the body of the SMS message, for example, they may make an error when entering the name of a command alias.

Example:

The Incoming SMS Fail Limit is set to the default of 5 and the Fail count for SMS messages is at 0.

An SMS message with a valid structure is sent to the system. The Pager Driver analyzes the message, and having recognized that it is a valid SMS message, it extracts some of the information in the message and sends that information to ClearSCADA.

ClearSCADA receives the SMS message information from the Pager Driver. The information includes the body of the SMS message which contains a command alias. ClearSCADA attempts to match the command alias with the configured command alias setting of a Method Call in the database. There are no Method Calls with matching command aliases and so ClearSCADA cannot process the SMS message. This causes the Fail count to rise by 1.

The next 2 SMS messages to be received by ClearSCADA are similar - they both contain invalid aliases. This causes the Fail count to rise by a further 2, so the count is now 3.

A valid SMS message is the next message received, and as ClearSCADA can process the message correctly, the Fail count is reset to 0.

The next 5 messages have invalid structures and so are disregarded by the Pager Driver. The Fail count increases to 5, but there is no alarm yet as the Incoming SMS Fail Limit has only been reached, not exceeded.

The next SMS message to be received has an invalid alias and so cannot be processed. This causes the Fail count to rise to 6. As this exceeds the Incoming SMS Fail Limit of 5, an alarm is raised.

To define the Incoming SMS Fail Limit for an SMS Service:

  1. Display the Pager Service Form.
  2. Select the SMS Service tab.
  3. Enter the Incoming SMS Fail Limit that you require. The Incoming SMS Fail Limit is set to 5 by default which is appropriate for many systems.
  4. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Define whether an SMS Service can Process Incoming Messages.

Checking the Fail Count for Incoming SMS Commands.

Checking and Resetting the Fail Count for an SMS Service.


Pager Driver Guide - Define whether ClearSCADA Replies to Incoming SMS Messages (Configuring a Pager Service)

Define whether ClearSCADA Replies to Incoming SMS Messages

When ClearSCADA receives an SMS command, it processes the command, but by default, does not send a reply to the sender of the SMS message. This does not affect the running of a system, but may mean that the sender of the SMS is unable to determine whether the SMS command was successful. This is especially true if the sender is in a remote location without access to a system client.

By using the Acknowledge SMS Commands setting on the SMS Service Form, you can configure ClearSCADA to reply to incoming SMS messages. This means that the sender of the message is notified of the outcome of the message being sent to ClearSCADA:

  • the SMS command was successful
  • the SMS command failed (and a brief description of the cause of the failure)
  • the SMS command was rejected by the Pager Driver (and a brief description of the cause of the rejection). It is extremely unlikely that the Pager Driver will reject any incoming SMS messages.

If an SMS command fails or is rejected, an alarm is also raised in ClearSCADA (the alarm also provides a brief description of the cause of the problem).

To configure ClearSCADA to reply to incoming SMS pager messages:

  1. Display the Pager Service Form.
  2. Select the SMS Service tab.
  3. Select the Process Incoming SMS Messages check box (so that it is checked).
  4. Choose the required setting from the Acknowledge SMS Commands combo box:
  • Never—ClearSCADA will not reply to any incoming SMS messages.
  • On Failure—ClearSCADA will send a reply to any incoming SMS messages that fail or are rejected
  • Always—ClearSCADA will send a reply to each type of incoming SMS message (failed messages, rejected messages and successful messages).
  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Define the Data Coding Scheme for an SMS Service (Configuring a Pager Service)

Define the Data Coding Scheme for an SMS Service

The type and amount of characters you can use in an SMS message is dependent on the data coding scheme that is in place. ClearSCADA supports two data coding schemes for SMS messages:

  • GSM for characters included in the GSM 03.38 standard. These characters include the basic Latin characters used in languages such as English. GSM does not include the characters required in some non-Latin based languages, such as Russian and Chinese.

GSM is supported by many SMS devices and allows up to 160 characters per SMS message.

  • UCS-2 for characters included in the UTF-16/UCS-2 standard. This extended character set includes Latin characters and many other characters such as those required in Cyrillic languages.

UCS-2 is only supported by some SMS devices and has a limit of 70 characters per SMS message. This limit is due to the two byte representation of each UCS-2 character.

If you need more information about the characters supported in the data coding schemes, refer to:

  • The European Telecommunications Standards Institute (www.etsi.org) for GSM
  • The Unicode Consortium (www.unicode.org) for UCS-2.

When you configure an SMS Pager Service, you need to choose the appropriate type of data coding for your needs:

  • If you use a Latin based language such as English, Spanish, French or German, you should leave the Data Coding Scheme setting as GSM (the default setting).
  • If you use a non-Latin based language, you should set the Data Coding Scheme to UCS-2. This will allow you to use the non-Latin characters required in your language, but will reduce the amount of characters you can use in each SMS message. You also need to adjust the Maximum Message Length to 70 or less as the default Maximum Message Length of 160 is inappropriate for UCS-2.

To define the Data Coding Scheme for an SMS service:

  1. Display the Pager Service Form and then select the SMS Service tab.
  2. Choose the required setting from the Data Coding Scheme combo box:
  • GSM—You can use many of the characters included in the GSM 03.38 standard in your SMS messages. The maximum number of characters per message is 160.

The characters that are included in GSM 03.38 but which cannot be used in ClearSCADA SMS messages are:
Symbol | Description
 | Greek Capital Xi
No symbol | Form Feed
 | Circumflex accent
 | Left brace
 | Right brace
 | Reverse solidus
 | Left square bracket
 | Tilde
 | Right square bracket
 | Vertical sign
 | Euro sign

  • UCS-2—You can use any of the characters in the UTF-16/UCS-2 standard in your SMS messages. The maximum number of characters per message is 70.

NOTE: If you select UCS-2, you also need to change the Maximum Message Length setting to 70 or less (see Define the Maximum Message Length Properties for a Pager Service).

  3. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Configuring a Pager Channel

Configuring a Pager Channel

Pager Channel database items are used to represent the physical connections between ClearSCADA and the intermediate devices that relay the messages to the recipient pager devices and mobile telephones. The intermediate devices can be GSM modems, service centers (with which ClearSCADA communicates via a PSTN modem), or a local Multitone PC interface device.

In ClearSCADA, each Pager Channel has a configuration Form that contains a variety of settings. You need to configure the properties of the Pager Channel item in ClearSCADA to match the settings that are supported by your communications equipment, including Baud Rate, Data Bits and Parity.

You need to configure at least one Pager Channel for each Pager Service, for example, if you have two TAP/UCP Pager Services, you will need to configure at least two PSTN Pager Channels; a minimum of one for each service.

The Pager Driver supports three types of Pager Channel:

  • Multitone Channel—For use with a Multitone Pager Service. You need to configure one Multitone Channel per Multitone Service (see Configure a Multitone Pager Channel).
  • PSTN Pager Channel—For use with TAP and UCP Pager Services. You need to configure at least one PSTN Pager Channel per TAP/UCP Service (see Configure a PSTN Pager Channel).

The Pager driver will attempt to send pager/SMS messages via an available PSTN Pager Channel. If your system has more than one PSTN Pager Channels, and there are unexpected difficulties with the usual pager modem, the driver will use one of the alternate PSTN Pager Channels instead (if any are available).

  • SMS Pager Channel—For use with SMS Pager Services. You need to configure one SMS Pager Channel per SMS Service (see Configure an SMS Pager Channel).


Pager Driver Guide - Preparation (Configuring a Pager Channel)

Preparation

Before you can successfully configure a Pager Channel, you need to configure an appropriate Pager Service (see Configuring a Pager Service). For example, can only configure a PSTN Pager Channel if you database already has a suitably configured TAP or UCP Pager Service.

During the configuration of your Pager Channel, you may also need to know:

  • The type of connection that is represented by the Pager Channel (Serial, Remote Serial, or TCP/IP).
  • The properties used for the Serial, Remote Serial, or TCP/IP connection. For more information on the settings that are in place (which may be fixed or user-configurable), please refer to the manufacturers' documentation supplied with your communications equipment.
  • Which features are required for each Pager Channel. You can configure each channel to use a variety of features, including alarm redirection. However, many of these features are optional and have no effect on the success of communications. The optional features include:
  • Alarm view
  • Alarm redirections
  • User methods.

If the features listed above are not configured, they are not used for the selected channel (they will be left blank).

  • The amount of time it takes for your communications equipment to initialize, connect, and respond to messages. This information may be included in the manufacturers' documentation, or you can use I/O logs for the Channel to calculate appropriate times.

When you have configured Pager Services and Pager Channels, you will need to define Pager Contact information in the User accounts of each user that is to receive pager or mobile telephone messages from ClearSCADA.


Pager Driver Guide - Minimum Configuration for Pager Channels (Configuring a Pager Channel)

Minimum Configuration for Pager Channels

For a Pager Channel to become functional (online), the minimum properties you need to configure are:

  • The communications port for the channel
  • The Pager Service with which the channel is associated
  • These connection-specific properties:
  • Serial connection—the port to which the serial cable represented by the Pager Channel is connected
  • Remote serial connection—the host name of the PC that is running the Port Server application, and the port on the PC to which the serial cable is connected
  • TCP/IP connection—The TCP/IP type, the host address, and the port number.

You also need to put the Pager Channel In Service and save the configuration.

This will result in a functional channel that uses the default configuration settings.


Pager Driver Guide - Create a Pager Channel Database Item (Configuring a Pager Channel)

Create a Pager Channel Database Item

Pager Channel database items are used to represent the physical connections between ClearSCADA and the pager or mobile telecommunications service provider. You need to create and configure at least one Pager Channel for each Pager Service.

To create a Pager Channel database item:

  1. Log on to ClearSCADA via a User account that has the Configure Database permission (see User Account Permissions in the ClearSCADA Guide to Security).
  2. In the Database Bar, right-click on the System or Group that is to contain the new Pager Channel Database item.
    A context sensitive menu is displayed.
  3. Select New>Pager><Pager> Channel

Where <Pager> Channel is the option for the required type of Pager Channel, for example, PSTN Pager Channel.
A new Pager Channel database item is added to the hierarchy in the Database Bar. It is highlighted automatically, ready for you to define its name.

  4. Define a suitable name for the Pager Channel (see Naming Restrictions in the ClearSCADA Guide to Core Configuration), then press the Enter key or select another part of the interface to confirm.

Once you have created a new Pager Channel database item, you will need to use its configuration Form to define its properties (see Display the Pager Channel Form).


Pager Driver Guide - Display the Pager Channel Form (Configuring a Pager Channel)

Display the Pager Channel Form

Each Pager Channel database item has a configuration Form that you can use to define the various properties for the channel.

To display the Pager Channel Form, right-click on the Pager Channel database item in the Database Bar, then select the Properties option. You need to be logged on via a User account that has the Configure Database permission. (If the Pager Channel item does not already exist in the database, you will need to Create a Pager Channel Database Item.)

NOTE: There are several other ways of displaying a Form for a database item (see Display a Form in the ClearSCADA Guide to Core Configuration).

When you have displayed the Form for your Pager Channel database item, you can use it to define the properties for the channel. For more information, see:

  • Configure a Multitone Pager Channel
  • Configure a PSTN Pager Channel
  • Configure an SMS Pager Channel.


Pager Driver Guide - Configure the Common Channel Properties for a Pager Channel (Configuring a Pager Channel)

Configure the Common Channel Properties for a Pager Channel

Pager Channels have a Channel tab on their configuration Form. The Channel tab contains a variety of properties, some of which are exclusive to a particular type of Pager Channel and some of which are common to multiple types of Pager Channel.

The properties that are common to multiple types of Pager Channel include:

  • In Service—Use to set the Pager Channel database item to active or inactive in the database (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Severity—Use to define the severity (importance) of alarms and events that are generated and logged for the Pager Channel (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed on the Channel tab. Use the field to specify the Area of Interest with which any Pager Channel alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).

For more information on the Area of Interest feature, see Restrict Alarm and Event Access to Specific Areas of Interest in the ClearSCADA Guide to Core Configuration.

  • Pager Service—Use to associate the Pager Channel with the Pager Service database item that provides information about the protocol to be used with the Pager Channel.

Use the Pager Service field's browse button to display a Reference window that contains a list of Pager Services. The list only contains those Pager Services that are compatible with the type of Pager Channel you are configuring, for example, the reference window for an SMS Pager Channel only shows the SMS Pager Services on your system. Choose the required Pager Service from the list, then select the OK button to confirm your selection and close the Reference window.

  • Comms Retries—Use to define the number of times the Pager Driver will attempt to resend data packets to which the 'receiving' communications equipment has failed to respond (see Define the Number of Communications Retries for a Pager Channel).
  • Line Speed—Use to define the slowest part of the connection that is represented by the Pager Channel (see Define the Line Speed for a Pager Channel).
  • Modem Command—Use to enter the Modem Command that is required to initialize your modem. The default entry provides the minimum command required to allow ClearSCADA to communicate with the modem. Depending on the type of modem being used, you may need to apply additional commands. For more information, see Define the Modem Command for a Pager Channel.

NOTE: The Modem Command property is only available on PSTN and SMS Pager Channels.

For information on the properties that are specific to a particular type of Pager Channel, please refer to the relevant section:

  • Configure a Multitone Pager Channel
  • Configure a PSTN Pager Channel
  • Configure an SMS Pager Channel.


Pager Driver Guide - Define the Number of Communications Retries for a Pager Channel (Configuring a Pager Channel)

Define the Number of Communications Retries for a Pager Channel

When ClearSCADA is used to send a pager or SMS message, the Pager Driver sends the message in packets of data. Each packet is sent to the service provider via the local communications equipment.

Typically, the Service Provider will receive the first packet of data and then send a response to the Pager Driver. The response indicates that the packet was received successfully. The Pager Driver then transmits the remaining packets in turn. Usually, the Service Provider responds to each packet that it receives from the Pager Driver. The Service Provider will then send the message to the relevant pager or mobile telephone.

However, if the Service Provider does not respond to one of the packets sent by the Pager Driver, there may be a problem. For example, a Service Provider may receive a corrupted (and therefore invalid) packet as a result of electromagnetic noise on the communications connection. The amount of time the Pager Driver will wait for a response is based on an internal calculation that uses the Baud Rate and Line Speed and the protocol (the protocol provides information about the processing times of the devices at the Service Provider). For SMS Pager Channels, the calculation also involves the Message Send Timeout (see Define the Message Send Timeout for an SMS Pager Channel)

When the Service Provider does not respond successfully to a sent data packet, the Pager Driver checks the Comms Retries property of the appropriate Pager Channel. This property defines the maximum number of times the Pager Driver can attempt to send a data packet that does not result in a response from the Service Provider. For example, if the Comms Retries is set to 2, the Pager Driver will make a maximum of 3 attempts to send the first packet of a message (1 initial attempt and 2 Comms Retries attempts).

If a Service Provider responds to one of the Comms Retries attempts, the data packet is sent successfully and the Pager Driver attempts to send the remaining data packets of the message (if any). But if the Service Provider does not respond and the Comms Retries limit is reached, the Pager Driver stops sending the data packet and checks the Retries property of the Pager Service that is associated with the Pager Channel. If the Retries property is used (that is, has a value other than 0), the Pager Driver will attempt to send the entire message to the Service Provider. It will continue to send the entire message until the Service Provider responds or the Retries limit is reached.

If the Comms Retries limit of the Pager Channel and the Retries limit of the Pager Service have been reached and the Service Provider has still not responded, the message is deemed to have failed. In ClearSCADA, an appropriate alarm is raised and an event is logged.

NOTE: If a message is deemed to have been successful in ClearSCADA, but it has not been received by the relevant pager device or mobile telephone, please check the details are correct (for example, pager id/number). You should also check that the receiving device is in range and turned on. If the details are correct and the device is on and in range, contact your service provider for further assistance.

Example:

The Retries property for a Pager Service is defined as 2.
The Comms Retries property for a Pager Channel is also defined as 2.

ClearSCADA attempts to send a message to a mobile phone via the Pager Channel. The Pager Driver sends the first packet of the message data to the Service Provider. The Service Provider receives the first data packet of the message and responds. The Pager Driver receives the response and sends the second data packet of the message.

The second data packet becomes corrupted during communications due to interference. As a result, the Service Provider does not receive a valid second data packet and so does not respond to the Pager Driver.

The Pager Driver recognizes that the Service Provider has not responded to the second data packet and so makes another attempt to send it (this is the first Comms Retries attempt). The Service Provider does not respond.

The Pager Driver makes another attempt to send the second data packet (the second Comms Retries attempt and the third attempt in total). The Service Provider does not respond and so the transaction of the entire message is deemed to have failed. However, ClearSCADA does not regard the entire message until the Retries attempts have been also been made.

As the Retries of the Pager Service is set to 2, the Pager Driver attempts to send the entire message a further 2 times. If the Service Provider responds positively to either of these attempts, ClearSCADA deems the message to be a success. If the Service Provider does not respond to either of these attempts, ClearSCADA logs an event recording the failure in the Event Journal and raises an alarm.

To define the maximum number of times the Pager Driver will attempt to resend the data packets sent via a Pager Channel:

  1. Display the Pager Channel Form.
  2. Select the Channel tab.
  3. In the Comms Retries field, enter the maximum number of times the Pager Driver will attempt to send an unsuccessful data packet (a data packet that is unsuccessful in its attempts to solicit a response from the Service Provider). Remember that the Comms Retries attempts are in addition to the initial attempt.

The default setting for Comms Retries is 2 which is appropriate for many systems as it allows the Pager Driver to overcome any intermittent difficulties. Please be aware that increasing the Comms Retries number will result in slower detection of failed messages (as a message is only deemed to have failed after the Comms Retries and Retries limits have been reached).

When you have defined the appropriate Comms Retries setting, you can either proceed with the Pager Channel configuration (see Configure the Common Channel Properties for a Pager Channel), or you can save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Define the Retry and Timeout Properties for a Pager Service.


Pager Driver Guide - Define the Line Speed for a Pager Channel (Configuring a Pager Channel)

Define the Line Speed for a Pager Channel

PSTN, Multitone, and SMS Pager Channels have a Line Speed property that you need to use to define the slowest part of the connection that is represented by the Pager Channel. This is required as the Pager Driver uses the Line Speed, Baud Rate and information in the protocol to calculate the amount of time it should take to:

  • Send a message to the Service Provider
  • Receive a response from the Service Provider.

The Line Speed and Baud Rate are used to calculate the actual time it takes for the message and response to be transmitted across the communications connection, with information in the protocol allowing the Pager Driver to account for processing delays at the Service Provider. For SMS Pager Channels, the Pager Driver also uses the Message Send Timeout to allow for delays between stages of SMS message sending.

Typically, Pager communications equipment and connections use the same speed, so you will set the Line Speed to match the Baud Rate. However, if your Pager Channel represents a connection that has various speeds, you will need to set the Line Speed property to match the slowest speed on the connection. For example, with a TAP or UDP connection, you may require that the connection between ClearSCADA and the local modem uses a high speed, even though the local modem and remote modem actually communicate at a slower speed. In this situation, you would need to configure the Line Speed to match the slower speed that is used between the local modem and the remote modem.

If the Line Speed setting does not match the slowest speed on the connection, the calculation made by the Pager Driver will be inaccurate which may result in failed messages and unnecessary alarms and events.

To define the Line Speed for a Pager Channel:

  1. Display the Pager Channel Form.
  2. Select the Channel tab.
  3. Use the Line Speed combo box to select the appropriate speed. If configuring a Serial or Remote Serial channel, you can also choose the Same as Baud Rate option if the Line Speed is to be the same as the Baud Rate for the Pager Channel. For TCP/IP channels, you need to select the correct speed.

Remember that the speed you choose should match the slowest part of the communications connection that is represented by the Pager Channel.

When you have defined the appropriate Line Speed setting, you can either proceed with the Pager Channel configuration (see Configure the Common Channel Properties for a Pager Channel), or you can save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Baud Rate: see Configure a Channel’s Connection Properties in the ClearSCADA Guide to Drivers.

Define the Message Send Timeout for an SMS Pager Channel.


Pager Driver Guide - Define the Modem Command for a Pager Channel (Configuring a Pager Channel)

Define the Modem Command for a Pager Channel

PSTN and SMS Pager Channels have a Modem Command property that is used to initialize the local modem that is connected to ClearSCADA (either directly or over a network). The Modem Command instructs the modem about which parameters to use for communications, for example, whether to enable or disable echoing and whether to hang-up the previous call before attempting to communicate.

When you create a Pager Channel, it has a default Modem Command which provides the minimum amount of information that is required for ClearSCADA to be able to communicate with the local modem successfully. Usually, the manufacturers' documentation supplied with your modem will provide information on any additional commands that you need to apply. To connect with your remote modem correctly, your local modem may also require some additional details—these should be provided by your Service Provider.

To define the Modem Command for your PSTN or SMS Pager Channel:

  1. Refer to the manufacturers' documentation supplied with your modem and contact your Service Provider for more information on the modem commands required on your system.
  2. Log on to ClearSCADA and Display the Pager Channel Form.
  3. Select the Channel tab.
  4. Use the Modem Command field to define the required Modem Commands. The AT command at the start of the string allows you to add each modem command to a single string without repeating the AT command. The Modem Command is limited to 59 characters.

NOTE: To work correctly with ClearSCADA, modem commands need to contain V1 and E0 as a minimum.

When you have defined the appropriate Modem Command setting, you can either proceed with the Pager Channel configuration (see Configure the Common Channel Properties for a Pager Channel), or you can save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Configure a Multitone Pager Channel (Configuring a Pager Channel)

Configure a Multitone Pager Channel

To configure a Multitone Pager Channel:

  1. Display the Pager Channel Form. If the Pager Channel you want to configure does not already exist in the database, you will need to Create a Pager Channel Database Item, then display its Form.
  2. Configure the Identification, User Methods, Alarm, and Redirection properties as required. These properties are common to many types of database item (see Tabs on Configuration Forms).
  3. Configure the properties on the Connection tab (see Configure a Channel’s Connection Properties in the ClearSCADA Guide to Drivers). The properties vary according to the Connection Type you select (see Configure a Channel’s Connection Type in the ClearSCADA Guide to Drivers).
  4. Configure the properties on the Channel tab.

With Multitone Pager Channels, the tab contains only properties that are common to each type of Pager Channel (see Configure the Common Channel Properties for a Pager Channel).

  5. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Configure a PSTN Pager Channel (Configuring a Pager Channel)

Configure a PSTN Pager Channel

To configure a PSTN Pager Channel:

  1. Display the Pager Channel Form. If the Pager Channel you want to configure does not already exist in the database, you will need to Create a Pager Channel Database Item, then display its Form.
  2. Configure the Identification, User Methods, Alarm, and Redirection properties as required. These properties are common to many types of database item (see Tabs on Configuration Forms).
  3. Configure the properties on the Connection tab (see Configure a Channel’s Connection Properties in the ClearSCADA Guide to Drivers). The properties vary according to the Connection Type you select (see Configure a Channel’s Connection Type in the ClearSCADA Guide to Drivers).
  4. Display the Channel tab.
  5. Configure those properties on the tab that are common to many Pager Channels (see Configure the Common Channel Properties for a Pager Channel).
  6. Configure the properties that are specific to PSTN Pager Channels:
  • Pulse Dialing—Use the Pulse Dialing check box to define whether the PSTN exchange (to which the modem represented by the Pager Channel is connected) uses Pulse Dialing or Tone dialing (Dual Tone Multi-Frequency). Select the check box if Pulse Dialing is used, or clear the check box if Dual Tone Multi-Frequency is used.

For more information, see Define whether a PSTN Pager Channel uses Pulse Dialing or Tone Dialing.

  • Connection Timeout—Define the amount of time the Pager Driver will wait for the local modem to connect to the remote modem (see Define the Connection Timeout for a PSTN Pager Channel).
  • Establish Timeout—Define the amount of time the Pager Driver will wait for the remote modem to respond to an 'establish' message that has been sent by the Pager Driver. The time you enter has to be in the OPC Time Format.

The default time of 25 seconds is usually applicable, but you may need to change the setting if messages fail consistently.

For more information, see Define the Establish Connection Timeout for a PSTN Pager Channel.

  • Modem Command—Enter the Modem Command that is required to initialize your modem. The default entry provides the minimum command required to allow ClearSCADA to initialize the modem. Depending on the type of modem being used, you may need to apply additional commands. For more information, see Define the Modem Command for a Pager Channel.
  • Post Connection Delay—Define the amount of time the Pager Driver waits between detecting the modems have connected and transmitting the first message. Normally, you only need to change this setting from 0 if you are using GSM modems, as these are known to experience lag for a short time after the connection is established.

If you are using GSM modems, we recommend that you set the Post Connection Delay to 2S (2 seconds). You need to use the OPC Time Format.

For more information, see Define the Post Connection Delay for a PSTN Pager Channel.

  7. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Define whether a PSTN Pager Channel uses Pulse Dialing or Tone Dialing (Configuring a Pager Channel)

Define whether a PSTN Pager Channel uses Pulse Dialing or Tone Dialing

Each PSTN Pager Channel has a Pulse Dialing property that you can use to define whether the PSTN exchange supports Pulse Dialing (sometimes referred to as Loop Disconnect dialing, Rotary dialing or Decadic dialing).

As technology has advanced, pulse dialing has been superseded by another system—Dual Tone Multi-Frequency (DTMF), which is also referred to as touch tone or tone dialing. Many national telephone networks and telephone devices use DTMF, but also provide some level of pulse dialing support. However, in some countries DTMF is not supported, and some private PSTN exchanges may also only support pulse dialing.

When configuring a PSTN Pager Channel, you need to specify whether the connection that is represented by the channel uses pulse dialing or DTMF. This setting has to match the type of signalling that is supported by the PSTN exchange into which the connection is plugged. For example, if a Pager Channel represents a connection between ClearSCADA and a private PSTN exchange that only supports Pulse dialing, the Pager Channel has to be configured to use Pulse dialing, otherwise the PSTN exchange will not recognize the signals being received via the connection.

You can use the PSTN Pager Channel's Pulse Dialing property to define whether the connection uses Pulse dialing or DTMF:

  1. Display the Pager Channel Form.
  2. Select the Channel tab.
  3. Either:
  • Select the Pulse Dialing check box to set the connection represented by the Pager Channel to use Pulse dialing (Pulse dialing also has to be supported by the PSTN exchange to which the connection is made).

Or:

  • Clear the Pulse Dialing check box to set the connection represented by the Pager Channel to use Dual Tone Multi-Frequency dialing (DTMF dialing also has to be supported by the PSTN exchange to which the connection is made).

When you have defined the appropriate Pulse Dialing setting, you can either proceed with the Pager Channel configuration (see Configure a PSTN Pager Channel), or you can save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Define the Connection Timeout for a PSTN Pager Channel (Configuring a Pager Channel)

Define the Connection Timeout for a PSTN Pager Channel

Each PSTN Pager Channel has a Connection Timeout property that you can use to define how long ClearSCADA will wait for the connection between the local modem and remote modem to be made.

When a message is to be sent from ClearSCADA to a pager device or mobile telephone, the Pager Driver initializes the local modem, then instructs it to establish a connection with the remote modem. During the establishment of the connection, the two modems will 'handshake' to confirm that the connection has been made successfully.

If the remote modem does not respond to the connection attempt that is made by the local modem within a defined time (the Connection Timeout), ClearSCADA deems the call to have failed. This results in the failure being logged in the Event Journal as a 'Failed to send pager message' entry for the relevant Pager Service.

You can define the Connection Timeout for each PSTN Pager Channel by using the PSTN Pager Channel Form:

  1. Display the Pager Channel Form.
  2. Select the Channel tab.
  3. Either:
  • Use the browse button feature of the Connection Timeout field to define the amount of time that ClearSCADA will wait for the two modems to establish a connection.

Or:

  • In the Connection Timeout field, enter the amount of time that ClearSCADA will wait for the two modems to establish a connection. You need to enter the time in the OPC Time Format, for example, 40S for 40 seconds.

The default setting for the Connection Timeout is 40 seconds. This is appropriate for many types of modem.

If you are using modems from different manufacturers or different models of modem, it is possible that the modems will take longer than 40 seconds to establish a connection. If this is the case, messages sent via the Pager Channel will fail. If you are experiencing failed messages, and the various modem related Pager Channel configuration settings are correct (Baud Rate, Line Speed and so on), you may need to increase the Connection Timeout. In this situation, we recommend that you examine the I/O log for the Pager Channel—from the entries in the I/O log, you will be able to determine whether the problem is caused by the modems failing to connect.

We recommend that you try increasing the Connection Timeout in 10 second increments.

When you have defined the appropriate Connection Timeout setting, you can either proceed with the Pager Channel configuration (see Configure a PSTN Pager Channel), or you can save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Logging and Monitoring in the ClearSCADA Guide to Server Administration.


Pager Driver Guide - Define the Establish Connection Timeout for a PSTN Pager Channel (Configuring a Pager Channel)

Define the Establish Connection Timeout for a PSTN Pager Channel

Each PSTN Pager Channel has an Establish Timeout property that you can use to define how long ClearSCADA will wait for a response to an 'establish' message.

When a message is to be sent from ClearSCADA to a pager device or mobile telephone, the Pager Driver initializes the local modem, and then the local modem and remote modem establish a connection. Once the connection has been established, the Pager Driver may wait for a defined amount of time (the Post Connection Delay, see Define the Post Connection Delay for a PSTN Pager Channel), before sending an 'establish' message to the remote paging service.

The 'establish' message sent is used by ClearSCADA to confirm that the correct connection has been made—when the connection has been established, the pager service will send a response to the Pager Driver. The response is used by the Pager Driver to confirm that the device at the other end of the connection is the expected device.

If the paging service does not respond to the 'establish' message sent by the Pager Driver within a specific amount of time, ClearSCADA deems the call to have failed. This results in the failure being logged in the Event Journal as a 'Failed to send pager message' entry for the relevant Pager Service. The amount of time that ClearSCADA will wait for the response to the 'establish' message is defined by the Establish Timeout property in the Pager Channel configuration.

To define the Establish Timeout for a PSTN Pager Channel:

  1. Display the Pager Channel Form.
  2. Select the Channel tab.
  3. Either:
  • Use the browse button feature of the Establish Timeout field to define the amount of time that ClearSCADA will wait for the paging service to respond to an 'establish' message.

Or:

  • In the Establish Timeout field, enter the amount of time that ClearSCADA will wait for the paging service to respond to an 'establish' message. You need to enter the time in the OPC Time Format, for example, 25S for 25 seconds.

The default setting for the Establish Timeout is 25 seconds. This is appropriate for many situations. However, some paging services may take longer to respond.

If you are experiencing failed messages, and the various modem related Pager Channel configuration settings are correct (Baud Rate, Line Speed and so on), you may need to increase the Establish Timeout. In this situation, we recommend that you examine the
I/O log for the Pager Channel—from the entries in the I/O log, you may be able to determine whether the difficulties are being caused by the Pager Service failing to send a response to the 'establish' message.

We recommend that you try increasing the Establish Timeout in 5 second increments.

When you have defined the appropriate Establish Timeout setting, you can either proceed with the Pager Channel configuration (see Configure a PSTN Pager Channel), or you can save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Logging and Monitoring in the ClearSCADA Guide to Server Administration.


Pager Driver Guide - Define the Post Connection Delay for a PSTN Pager Channel (Configuring a Pager Channel)

Define the Post Connection Delay for a PSTN Pager Channel

Each PSTN Pager Channel has a Post Connection Delay property that you can use to define how long the Pager Driver will wait between the modems reporting that a connection has been made and sending an 'establish' message.

When a message is to be sent from ClearSCADA to a pager device or mobile telephone, the Pager Driver initializes the local modem, and then the local modem and remote modem establish a connection. Once the connection has been established, the Pager Driver waits for the Post Connection Delay, before sending an 'establish' message to the paging service. The Post Connection Delay is normally only used when GSM modems are used, as GSM modems are known to experience lag during the initial connection being reported and the actual connection being available (even though the connection between the local and remote modem appears to be healthy). By adding an extra delay (the Post Connection Delay), the Pager Driver can avoid the problems that can be caused by the initial lag (which include messages and replies being out of sync).

The Post Connection Delay property is set to 0 by default. This means that it is not used. If you are using GSM modems, you may need to enable the Post Connection Delay by entering or choosing a suitable time delay. The amount of time you need to enter varies according to the type of GSM modems being used. We recommend that you begin by using a setting of 2 seconds and then use the I/O log for the Pager Channel to determine whether this needs to be increased.

To define the Post Connection Delay for a PSTN Pager Channel:

  1. Display the Pager Channel Form.
  2. Select the Channel tab.
  3. Either:
  • Use the browse button feature of the Post Connection Delay field to define the amount of time that the Pager Driver will wait between detecting the connection between modems has been made and sending the 'establish' message.

Or:

  • In the Post Connection Delay field, enter the amount of time that the Pager Driver will wait between detecting the connection between modems has been made and sending the 'establish' message. You need to enter the time in the OPC Time Format, for example, 2S for 2 seconds.

When you have defined the appropriate Post Connection Delay setting, you can either proceed with the Pager Channel configuration (see Configure a PSTN Pager Channel), or you can save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Further Information

Logging and Monitoring in the ClearSCADA Guide to Server Administration.


Pager Driver Guide - Configure an SMS Pager Channel (Configuring a Pager Channel)

Configure an SMS Pager Channel

To configure an SMS Pager Channel:

  1. Display the Pager Channel Form. If the Pager Channel you want to configure does not already exist in the database, you will need to Create a Pager Channel Database Item, then display its Form.
  2. Configure the Identification, User Methods, Alarm, and Redirection properties as required. These properties are common to many types of database item (see Tabs on Configuration Forms).
  3. Configure the properties on the Connection tab (see Configure a Channel’s Connection Properties in the ClearSCADA Guide to Drivers). The properties vary according to the Connection Type you select (see Configure a Channel’s Connection Type in the ClearSCADA Guide to Drivers).
  4. Display the Channel tab.
  5. Configure those properties on the tab that are common to many Pager Channels (see Configure the Common Channel Properties for a Pager Channel):
  6. Configure the properties that are specific to SMS Pager Channels:
  • Modem Command—Enter the Modem Command that is required to initialize your modem. The default entry provides the minimum command required to allow ClearSCADA to initialize the modem. Depending on the type of modem being used, you may need to apply additional commands. For more information, see Define the Modem Command for a Pager Channel.
  • Message Send Timeout—Define the amount of time the Pager Driver allows for the mobile telephone network to confirm that the message has been received (see Define the Message Send Timeout for an SMS Pager Channel).
  7. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Define the Message Send Timeout for an SMS Pager Channel (Configuring a Pager Channel)

Define the Message Send Timeout for an SMS Pager Channel

SMS Pager Channels have a Message Send Timeout property that you can use to define the amount of time the Pager Driver allows for the mobile telephone network to confirm that it has received a message from ClearSCADA.

When the body of the SMS message has been sent, the Pager Driver waits for a response from the Service Provider. The response informs the Pager Driver that the SMS message has been received successfully. The Pager Driver will wait for a specific amount of time for this response—the Message Send Timeout time that is defined on the SMS Pager Channel Form.

The Message Send Timeout has a default setting of 5000 milliseconds, which is appropriate for many systems. But if you are experiencing failed SMS messages and there does not appear to be a problem with your communications network, you may wish to increase the Message Send Timeout. In some instances, the Service Provider's communication devices take longer than 5000 milliseconds to process an SMS message received from ClearSCADA and respond with a receipt signal. Increasing the Message Send Timeout can provide the extra amount of time needed for such devices to respond before ClearSCADA deems the message to have failed.

To define the Message Send Timeout for an SMS Pager Channel:

  1. Display the Pager Channel Form.
  2. Select the Channel tab.
  3. Enter the required amount of time (in milliseconds) in the Message Send Timeout field. If you need to increase the time, we recommend you make adjustments in 1000 milliseconds increments until you discover a timeout suitable for your system.

When you have defined the appropriate Message Send Timeout setting, you can either proceed with the Pager Channel configuration (see Configure an SMS Pager Channel), or you can save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).


Pager Driver Guide - Configuring a User Account's Pager Properties

Configuring a User Account's Pager Properties

For ClearSCADA to send a message to a particular pager device or mobile telephone, it needs to be able to:

  • Identify the individual pager device or mobile telephone
  • Determine which protocol should be used when sending messages to the pager device or mobile telephone.

This information is stored in the configuration of the User account of the system user that is to receive the message (the 'owner' of the pager device or mobile telephone):

  • Pager ID—This is the number of the pager device or mobile telephone that the user of the account will use. ClearSCADA uses this information to identify the device to which it needs to send a message.
  • Pager Service—This associates the User account with a Pager Service database item, which allows ClearSCADA to determine the protocol that is required to send messages to the device (specified by the Pager ID number).

For each User that is going to receive messages on a pager device or mobile telephone, you need to:

  1. Create a User account or edit the existing User account (see User Accounts in the ClearSCADA Guide to Security).
  2. Select the Contact Information tab.
  3. Enter the number of the relevant pager device or mobile telephone in the Pager ID field.
  4. Use the browse button to associate the User account with the appropriate Pager Service. If there are no suitable Pager Services available, you will need to configure one (see Configuring a Pager Service).
  5. Use the SMS Commands check boxes to define whether the User is authorized to execute actions via the devices with the corresponding Pager IDs.

An incoming SMS message may contain an action. If the User is authorized to use SMS Commands (for the device on which the message was received) and their user account has sufficient permissions, they can execute the action.

For more information, see Define the E-Mail, Pager, and Voicemail Contact Settings for a User.

NOTE: If an incoming SMS message has a number that is not associated with a user account, it is directed to the Guest user account. If the message contains an action, that action can only be executed by a Guest user if the Guest User account has SMS Commands enabled and the relevant permissions. The SMS Commands check box for the Guest User is on the Guest User tab of the Root Group Form (System Form). For more information, see Define the Global Settings for All Guest and Web User Accounts.

  6. Save the configuration (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration).

Each User account can have up to four Pager Contacts (a Pager ID and its corresponding Pager Service are referred to as a Pager Contact). This means that a single user can receive messages on a maximum of four pagers or mobile telephones.

When you have configured the Pager Contacts details for those users that are to receive pager and SMS messages, you can begin to send messages to them. Messages can be sent manually or automatically (see Sending a Message to a Pager or Mobile Phone).

Further Information

Pager Contact Details: see User Accounts in the ClearSCADA Guide to Security.

Configuring a Pager Service.


Pager Driver Guide - Configuring Pager Server Settings

Configuring Pager Server Settings

The ClearSCADA server has 1 Pager Driver-specific setting that you may need to configure:

  • The Multipage SMS Message Timeout

Typically, you would only need to consider adjusting this setting if there are alarms on your system relating to multipage messages not being delivered in full. Normally this type of alarm indicates that there is an unexpected problem with the communications network as the messages are not being sent within the expected amount of time. However, it is possible that a low Multipage SMS Message Timeout setting could also cause the multipage messages to be disregarded (by not allowing enough time for each page of the messages to arrive).

For information on the Multipage SMS Message Timeout, see Define the Timeout Period for Multipage Messages.


Pager Driver Guide - Define the Timeout Period for Multipage Messages (Configuring Pager Server Settings)

Define the Timeout Period for Multipage Messages

ClearSCADA can receive 7 bit or 8 bit SMS messages. There is a limit to the number of characters permitted in each SMS message (between 134 and 140 for 7 bit messages and 152 and 160 for 8 bit messages).

If the number of characters in an incoming SMS message exceeds the limit, the message is split into separate messages called ‘pages’. A message that is split into pages is called a ‘multipage’ message.

The Pager driver can acknowledge multipage SMS messages as commands, but only if all of the ‘pages’ for a message arrive within a specified amount of time (the Multipage SMS Message Timeout). If all of the pages of a message are not received within the defined time limit, the message is disregarded and an alarm is raised to indicate that only part of a multi-page message has been received.

If your system has alarms indicating that multi-page messages have not been received in full, there may be a problem with the communications network. There may also be an inappropriate Multipage SMS Message Timeout setting on the ClearSCADA server, although if the default settings are in place, this is unlikely. If the Multipage SMS Message Timeout is too low, there could be insufficient time for all parts of a multi-page message to be received.

To change the Multipage SMS Message Timeout setting:

  1. Run the Server Configuration Tool
  2. Log on to the Server Configuration Tool (if required)
  3. Expand the Global Parameters branch
  4. Select Pager
  5. In the Multipage SMS Message Timeout section, enter the amount of time for the multipage message timeout (in seconds).

The default amount of 3600 seconds is appropriate for many systems. In the unlikely event that you need to increase the timeout, we recommend that you increase the amount in increments of 1800 seconds.

  6. Right-click on the system icon in the tree-structure, and select the Apply Changes option to apply the changes.


Pager Driver Guide - Sending a Message to a Pager or Mobile Phone

Sending a Message to a Pager or Mobile Phone

When your database contains suitably configured User accounts, Pager Services, and Pager Channels, you can use the Send Message and Send Pager Message actions to send messages to pager devices and mobile telephones. The availability of these actions depends on:

  • The configuration of the Pager Service or User account that you select (the Send Pager Message action is only available for Pager Services and User accounts that support the TAP or Multitone protocol).
  • The permissions of your own User account. You need to have the ViewX Operate permission in the configuration of your own User account. You also need to have the Control security permission for the Pager Service or User account that you are using to access the Send Message or Send Pager Message action.
  • The User account or Pager Service being In Service.

If you have access to the Send Message and Send Pager Message actions, you can use ClearSCADA to:

  • Send a message to a pager or mobile telephone manually. By selecting the Send Message or Send Pager Message action, you can display a prompt that allows you to choose the recipient of the message, define the content of the message, and send the message.

For more information, see Sending a Message Manually.

  • Send a defined message to a pager or mobile telephone automatically on a regular basis. By associating the Send Message or Send Pager Message action with a Schedule, you can set ClearSCADA to send a defined message automatically at regular intervals.

For more information, see Scheduling Automatic Pager and SMS Messages.

If your User account has the Configure Database permission and the Configure permission for an Alarm Redirection Pager Action, you can configure ClearSCADA to redirect alarm messages to a pager or mobile telephone. To do this, you need to configure an Alarm Redirection Pager Action so that it is associated with database items that are to have their alarm messages redirected. When alarm messages are generated for these database items, ClearSCADA will automatically send the messages to the pager or mobile telephone specified in the configuration of the Alarm Redirection Pager Action. For more information, see Redirecting Alarm Messages to Pagers or Mobile Phones Automatically.


Pager Driver Guide - Sending a Message Manually (Sending a Message to a Pager or Mobile Phone)

Sending a Message Manually

When ClearSCADA has been configured to make use of the functionality provided by the Pager Driver, you can use ClearSCADA to manually send messages to pager devices and mobile telephones.

There are two ways of sending a message manually:

  • You can use the Send Message or Send Pager Message action for the User account of the system user that is to receive the message (the 'owner' of the pager device or mobile telephone).
  • You can use the Send Message or Send Pager Message action for the Pager Service item that represents the appropriate protocol (the protocol supported by the pager device or mobile telephone that is to receive the message).

The only difference between the two methods of sending messages is that when you use the Send Message or Send Pager Message action for a Pager Service, you need to specify which user is to receive the message.

NOTE: You can configure alternative ways of sending a message, for example, you can create a Mimic button that, when selected, triggers the Send Message or Send Pager Message action. For more information on alternative ways of triggering the Send Message and Send Pager Message actions, please refer to the ClearSCADA Guide to Mimics and the ClearSCADA Guide to Logic.

To send a message manually:

  1. Log on to ClearSCADA via a User account that has the Control permission for either or both of the following:
  • The User account of the user that is to receive the message. The User account has to be configured so that it is associated with a Pager Service.
  • The Pager Service item that represents the protocol for the message.

If you only have the Control permission for a User account, you will only be able to use the Send Message or Send Pager Message action for the User account. Similarly, if you only have the Control permission for a Pager Service, you will only be able to access the Send Message or Send Pager Message action for the Pager Service.

  2. In the Database Bar, right-click on either:
  • The User account of the user that is to receive the message
  • The Pager Service item that represents the protocol for the message.

This displays a context sensitive menu.

NOTE: When you right-click on the relevant database item, the context sensitive menu displays the Send Message and/or the Send Pager Message as appropriate.

  3. Select the Send Message or Send Pager Message option.

If you are sending a message using an SMS Pager Service, UCP Pager Service, or a TAP Pager Service that has Beep Code support disabled, select the Send Message option.

If you are sending a message using a Multitone or TAP Pager Service with Beep Code support enabled, you should select the Send Pager Message option.

Depending on your choice, the Send Message window or the Send Pager Message window is displayed.

If the Send Message window is displayed, proceed to Step 4.

If the Send Pager Message window is displayed, proceed to Step 5.

  4. Use the Send Message window to define the Recipient (To), Pager Number and Message:
  • To—Choose the User account that is used by the system user that is to receive the message (see Define the Recipient of the Message (To)).

NOTE: You only have to define the To property if you have selected the Send Pager Message action for a Pager Service database item.

  • Pager Number—Choose the Pager Contact that represents the pager device or mobile telephone that is to receive the message (see Choose the Pager Number for the Device that is to Receive the Message).

Message—Enter the characters that comprise your message (see Define the Content of a Pager Message).

When you have defined the To, Pager Number and Message properties, proceed to Step 6.

  5. Use the Send Pager Message window to define the Recipient (To), Pager Number, Message and Beep Code:
  • To—Choose the User account that is used by the system user that is to receive the message (see Define the Recipient of the Message (To)).

NOTE: You only have to define the To property if you have selected the Send Pager Message action for a Pager Service database item.

  • Pager Number—Choose the Pager Contact that represents the pager device or mobile telephone that is to receive the message (see Choose the Pager Number for the Device that is to Receive the Message).
  • Message—Enter the characters that comprise your message (see Define the Content of a Pager Message).
  • Beep Code—Use to define the Beep Code to be used by the Service Provider. The Service Provider uses the Beep Code to instruct the recipient pager device to make a specific audible sound when it receives a message.

The code you need to enter varies according to the type of Pager Service being used. For more information, see Define the Beep Code for a Message Sent using the TAP or Multitone Protocol.

NOTE: The Beep Code property is only available for TAP Pager Services if the Service supports a beep code property is enabled in the Pager Services' configuration (see Enable or Disable Beep Code Support for a TAP Pager Service).

  6. Select the OK button to send the message. When the message has been sent, the Event Journal logs an entry that indicates that the Service Provider has received the message.

If the initial attempt to send the message is unsuccessful, ClearSCADA will make a defined number of further attempts to send the message. If these attempts are also unsuccessful, the message is deemed to have failed.

The number of times ClearSCADA will attempt to resend a message is defined in the configuration of the Pager Service and Pager Channel. For more information, see:

  • Define the Number of Communications Retries for a Pager Channel.
  • Define the Retry and Timeout Properties for a Pager Service.


Pager Driver Guide - Define the Recipient of the Message (To) (Sending a Message to a Pager or Mobile Phone)

Define the Recipient of the Message (To)

When sending a message to a pager device or mobile telephone, you need to specify which User account is used by the intended recipient of the message. For example, if you want to send a message to a system user named M. Green, you would configure the To property to match the User account used by M.Green.

You only need to configure the To property if you use the Send Pager Message action for a Pager Service item. The To property does not apply if you select this action for a User item (as the User account to be used is implicit).

To define the To property:

  1. Display the Send Pager Message window by right-clicking on a Pager Service and selecting the Send Pager Message action (see Sending a Message Manually).
  2. Use the To combo box to select the User account of the intended recipient. You can only choose from those User accounts that have been configured to be associated with the selected Pager Service.

Further Information

Sending a Message Manually.


Pager Driver Guide - Choose the Pager Number for the Device that is to Receive the Message (Sending a Message to a Pager or Mobile Phone)

Choose the Pager Number for the Device that is to Receive the Message

When sending a message, you need to specify which pager device or mobile telephone is to receive the message. To do this, you need to use the Pager Number property on the Send Message window or the Send Pager Message window.

The message you are sending is associated with a User account (either a User account specified by the To property, or the User account you used to access the Send Message or Send Pager Message action). In the configuration of the User account, there are up to 4 Pager Contacts, each containing a Pager ID and a Pager Number. Each Pager Contact represents a single pager device or mobile telephone.

When you send a message, you need to choose a Pager Number. The options for the Pager Number correspond to the Pager Contacts of the User account associated with your message. You need to select the name of the Pager Contact that represents the pager device or mobile telephone that is to receive the message.

To define the Pager Number property:

  1. Display the Send Message or Send Pager Message window by right-clicking on a Pager Service or User and selecting the Send Message or Send Pager Message action (see Sending a Message Manually).
  2. Use the Pager Number combo box to select the name of the Pager Contact that represents the pager device or mobile telephone that is to receive the message.

Further Information

Sending a Message Manually.

Configuring a User Account's Pager Properties.


Pager Driver Guide - Define the Content of a Pager Message (Sending a Message to a Pager or Mobile Phone)

Define the Content of a Pager Message

When sending a message from ClearSCADA to a pager device or mobile telephone, you need to use the Send Message or Send Pager Message window to define the content of your message:

  1. Display the Send Message or Send Pager Message window by right-clicking on a Pager Service or User and selecting the Send Message or Send Pager Message action (see Sending a Message Manually).
  2. Enter the characters that comprise your message in the Message field. The message that you enter will be the message that is displayed on the recipient pager device or mobile telephone.

Your message will be shortened if it exceeds the Maximum Message Length that has been configured for the Pager Service used to send the message. The method that ClearSCADA uses to shorten the message is also defined in the Pager Service configuration. For more information, please refer to Define the Maximum Message Length Properties for a Pager Service.

Further Information

Sending a Message Manually.


Pager Driver Guide - Define the Beep Code for a Message Sent using the TAP or Multitone Protocol (Sending a Message to a Pager or Mobile Phone)

Define the Beep Code for a Message Sent using the TAP or Multitone Protocol

If you are sending a message that uses the Multitone protocol or TAP protocol with Beep Code support enabled, you can define a Beep Code for your message. Beep Codes are supported by certain Service Providers and pager devices, and they are used to instruct a recipient pager device to make a specific audible sound when it receives a message. By using the Beep Code property on the Send Pager Message window, you can define which sound is to be played.

For pagers using the Multitone protocol, you can use the following Beep Codes:
Beep Code | Audible Sound
1 | Triple Beep
2 | Single Beep
3 | Double Beep
4 | Continuous Beeps
5 | Triple Pip
6 | Single Pip
7 | Double Pip
8 | Continuous Pips

Pagers that use the TAP protocol use various different codes, depending on the manufacturer and the device. For information on the Beep Codes supported by your pager device, please refer to the manufacturers' documentation.

NOTE: The Beep Code property is only available for TAP Pager Services if the Service supports a beep code property is enabled in the Pager Services' configuration (see Enable or Disable Beep Code Support for a TAP Pager Service).

To define the Beep Code for your message:

  1. Display the Send Pager Message window by right-clicking on a Pager Service or User and selecting the Send Pager Message action (see Sending a Message Manually).
  2. Enter the characters for the required sound in the Beep Code field, for example, if you are sending a message to a Multitone pager and want it to make a double beep, enter 3 in the Beep Code field.

Further Information

Sending a Message Manually.


Pager Driver Guide - Redirecting Alarm Messages to Pagers or Mobile Phones Automatically (Sending a Message to a Pager or Mobile Phone)

Redirecting Alarm Messages to Pagers or Mobile Phones Automatically

ClearSCADA includes an Alarm Redirection feature that allows an alarm message to be sent automatically in the form of a pager message or SMS message (Alarm Redirection also supports e-mail and voice message alarm redirections). This means that when an alarm is raised for a database item, the alarm message can be shown in ClearSCADA and sent to an engineer's pager or mobile phone, which is especially useful when there are engineers working remotely (off site).

In this section, we provide a brief overview of the configuration required to redirect a database item's alarms in the form of a pager message or SMS message. For more detailed information on Alarm Redirection, please refer to the sections listed under ‘Further Information’ at the end of this section.

To redirect a database item's alarms in the form of a pager message or SMS message, you need to:

  1. Create and configure an Alarm Redirection Pager Action. The configuration of the Redirection Action includes the To, Pager Number, (Pager) Message, and Beep Code properties that you need to configure when sending a message manually (see Sending a Message Manually). The Pager Number and To properties associate the Alarm Redirection with a User account and one of its Pager Contact settings. The Pager Contact setting determines whether a pager message or an SMS message is sent (the Pager Service for the Pager Contact represents a pager protocol or the SMS protocol).
  2. Configure the Redirection properties of the System, Group, or database item that is to have its alarms redirected in the form of a Pager message or SMS message. The Redirection properties need to associate the item's alarms with the Alarm Redirection Pager Action (you do this by selecting the Alarm Redirection Pager Action in the Action field on the Redirection tab of the relevant database item).

Further Information

Configuring and using the Alarm Redirection feature within ClearSCADA: see Introduction to Alarm Redirection in the ClearSCADA Guide to Alarm Redirection.

Introduction to the Pager Redirection Action: see Pager/SMS Redirection in the ClearSCADA Guide to Alarm Redirection.

Procedure for configuring a Redirection Action: see Configure a Redirection Action in the ClearSCADA Guide to Alarm Redirection.

Defining the properties for a pager or SMS message. (This is the message that ClearSCADA will send automatically in response to an alarm trigger.): see Define the Pager Action Details in the ClearSCADA Guide to Alarm Redirection.

Trip characters that can be used in pager messages (trip characters are specific to alarm messages that are automatically redirected, using a Pager Redirection Action): see Trip Sequences Supported by Redirection Actions in the ClearSCADA Guide to Alarm Redirection.

Procedure for optionally configuring an Action Roster (to trigger redirection actions in a different order at different times): see Configure an Action Roster in the ClearSCADA Guide to Alarm Redirection.

Procedure for optionally configuring an Action Calendar (to trigger different redirections on different types of day (such as a non-working day, or public holiday)): see Configure an Alarm Redirection Calendar in the ClearSCADA Guide to Alarm Redirection.

Assigning the Redirection Action to a particular database item or Group: see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection.


Pager Driver Guide - Scheduling Automatic Pager and SMS Messages (Sending a Message to a Pager or Mobile Phone)

Scheduling Automatic Pager and SMS Messages

You can configure ClearSCADA to send a message automatically at regular intervals. This is useful if you need to send a generic message to a particular user on an ongoing basis, for example, if you need to send a reminder message to a user every week.

To send a message automatically on a regular basis, you need to associate the Send Message or Send Pager Message action of a User or Pager Service item with a Schedule item. This will allow ClearSCADA to trigger the Send Message or Send Pager Message action at a specific time on a regular basis, for example, at 12:00 midday, every Friday.

To configure a pager message to be sent automatically on a regular basis:

  1. Log on to ClearSCADA via a User account with the Configure Database permission.
  2. Create a Schedule item. If your database already contains a suitable Schedule item, there is no need to create a new one (see Add a Schedule in the ClearSCADA Guide to Core Configuration).
  3. Configure the Schedule item so that it represents a Schedule of the appropriate type (for example, Simple, Daily, or Weekly).

NOTE: If you configure the Schedule item to be a Simple Schedule, you cannot use the Schedule Editor to define the time at which the Send Message or Send Pager Message action will be triggered. Instead, you need to use the Interval and Offset properties on the Schedule Form.

  4. Display the Schedule Editor (right-click on the Schedule item then select the Edit option).
  5. In the Database Bar, locate the User or the Pager Service to which you want to send a message.
  6. Drag the User item or Pager Service item into the Action area at the bottom of the Schedule Editor. When you release the left-hand mouse button, the Add Action window is displayed.

If you associated a User account with the Schedule, proceed to Step 7.

If you associated a Pager Service with the Schedule, proceed to Step 8.

  7. Configure the properties for the User account message:
  • Set the Aggregate combo box to (None).
  • Use the Method combo box to choose the Send Message or Send Pager Message action as appropriate (the Send Pager Message action is for messages that use the Multitone or TAP protocol). When you have selected the action, you will see that the Arguments section becomes available and it has these fields: Pager Number and Message. There may also be a Beep Code field. (These fields correspond to the properties of the same name when sending a message manually, see Sending a Message Manually).
  • Configure the properties for the Arguments. To do this, right-click on an argument, then select the Edit option to display the Expression window for the argument. Use the Expression window to define the appropriate settings:
  • For the Pager Number field, the entry needs to be one of up to four Pager IDs that have been configured for the User account. You can use the browse button's OPC Tag feature to locate and select the required Pager ID (they are located in the ContactConfig>$Config branch for the appropriate User account).
  • For the Message field, you need to define the content of your message. The message should be enclosed in single straight quotation marks ' '. Remember that if your message exceeds the defined maximum length, it will be shortened appropriately (see Define the Maximum Message Length Properties for a Pager Service).
  • For the Beep Code field, enter the characters for the required Beep Code. The characters you enter have to be enclosed in single straight quotation marks ' '. For more information on Beep Codes, see Define the Beep Code for a Message Sent using the TAP or Multitone Protocol.

When you have configured the properties for a message that is associated with a User account, proceed to Step 9.

  8. Configure the properties for the Pager Service message:
  • Set the Alarm combo box to (None).
  • Use the Method combo box to choose the Send Message or Send Pager Message action as appropriate (the Send Pager Message action is for messages that use the Multitone or TAP protocol). When you have selected the action, you will see that the Arguments section becomes available and it has these fields: To, Pager Number and Message. There may also be a Beep Code field. (These fields correspond to the settings of the same name when sending a message manually, see Sending a Message Manually).
  • Configure the properties for the Arguments. To do this, right-click on an argument, then select the Edit option to display the Expression window for the argument. Use the Expression window to define the appropriate setting:
  • For the To field, the entry needs to be the User account of the intended recipient of the message. You can use the browse button's OPC Tag feature to locate and select the required User account.
  • For the Pager Number field, the entry needs to be one of up to four Pager IDs that have been configured for the User account that you have defined in for the To field. You can use the browse button's OPC Tag feature to locate and select the required Pager ID (they are located in the ContactConfig>$Config branch for the appropriate User account).
  • For the Message field, you need to define the content of your message. The message should be enclosed in single straight quotation marks ' '. Remember that if your message exceeds the defined maximum length, it will be shortened appropriately (see Define the Maximum Message Length Properties for a Pager Service).
  • For the Beep Code field, enter the characters for the required Beep Code. The characters you enter have to be enclosed in single straight quotation marks ' '. For more information on Beep Codes, see Define the Beep Code for a Message Sent using the TAP or Multitone Protocol.

When you have configured the properties for a message that is associated with a Pager Service, proceed to Step 9.

  9. Select the OK button to confirm the settings and close the Add Action window.
  10. Define the time at which ClearSCADA will send the message for the User account or Pager Service:
  • If you are using a Simple Schedule, define the time by displaying the Schedule's Form, then using the following properties:
  • Offset—Use to define the time of the first message. This is an offset in the OPC Relative Time Format, for example, H sets the first message to occur at the start of the current hour.
  • Interval—Use to define how often subsequent messages are sent. This is an interval in the OPC Time Format, for example, 12H for 12 hours (the message will be sent every 12 hours).
  • If you are using a Daily, Weekly, Monthly or Yearly Schedule, double-click on the time line on the Schedule Editor to define the required time(s).
  11. Save the configuration of the Schedule (see Saving Configuration Changes in the ClearSCADA Guide to Core Configuration). ClearSCADA will now trigger the Send Message or Send Pager Message action for the selected User account or Pager Service at the times specified in the Schedule configuration.

Further Information

Using the Add Action and Edit Method Windows in the ClearSCADA Guide to Core Configuration.

ClearSCADA Expression Windows: see Using the Expression Editors in the ClearSCADA Guide to Expressions.

Schedules: see Using Schedules to Automate Regular Functions in the ClearSCADA Guide to Core Configuration.

Sending a Message Manually.

Configuring a Pager Service.

Configuring a User Account's Pager Properties.


Pager Driver Guide - Using SMS to Trigger an Action

Using SMS to Trigger an Action

By using an SMS service and SMS channel, you can instruct ClearSCADA to perform actions remotely. This means that engineers and operators can use SMS compatible devices such as mobile telephones to trigger actions in ClearSCADA from any location that has suitable network coverage.

There are three ways of sending an SMS message to trigger an action:

  • Use an alias and a Method Call
  • Reference the Execute action of a Method Call
  • Reference a database item’s action directly.

We recommend that wherever possible, you use an alias on a Method Call. This is because this way of sending an SMS command is much more convenient, cost-efficient and reliable. To learn how to use an alias on a Method Call, see:

  • Issue an SMS Command by using an Alias on a Method Call.

If, for some reason, you need to use a different technique for issuing an SMS command, please refer to the following sections:

  • Issue an SMS Command by Referencing the Execute action of a Method Call
  • Issue an SMS Command by Referencing the Action of a Database Item.


Pager Driver Guide - Issue an SMS Command by using an Alias on a Method Call (Using SMS to Trigger an Action)

Issue an SMS Command by using an Alias on a Method Call

If you want users to be able to trigger actions remotely by using SMS, we recommend that you configure your system to make use of the alias feature on Method Call database items. The alias feature allows you to associate a string of up to 32 characters with the action and database defined in the Method Call’s configuration. Remote users with appropriate permissions can then trigger the Method Call’s action by entering the alias string as the content of their SMS. There are several benefits to using aliases when sending SMS commands:

  • Convenience

It is much quicker to issue an SMS command when using an alias. This is because an alias can only be up to 32 characters, whereas a full reference to an action can be considerably longer and may even span multiple SMS messages.

As an alias is only 32 characters or less, there is also less likelihood of a user making an error when entering the content of the SMS message.

  • Increased Reliability

If an alias is used, the SMS command is a single SMS message. This means ClearSCADA can trigger the appropriate action as soon as ClearSCADA receives and processes the SMS message. As the SMS command is a single message, the potential for delays is reduced, as ClearSCADA only needs to receive one SMS message for the command as opposed to multiple messages which can be the case when aliases are not used.

If an alias is not used, the reference to trigger a remote action may exceed the length of a single SMS message. In this situation, the reference will be sent in multiple messages (referred to as a multi-part message). This has the potential to cause problems as the SMS service provider may not send all parts of the multi-part message within a suitable time frame (1 hour), for example, during times of heavy network traffic, there may be delays between each part of the multi-part message being sent. As ClearSCADA can only process the SMS command when it receives all parts of a multi-part message, any delays at the service provider will also mean there are delays between the SMS being sent and the action being executed in ClearSCADA. If all parts of a multi-part SMS message have not arrived within 1 hour, the message is disregarded by ClearSCADA (and a record of the incomplete message is logged in the Pager Driver log).

  • Reduced Cost

As an SMS command that uses an alias can only be a single SMS message, the cost of sending that command is the cost of sending 1 SMS message. If an alias is not used, an SMS command can span multiple messages, with the total cost of sending the SMS command being the cost of sending each part of the message.

To issue an SMS command by using an alias, the following configuration has to be in place:

  • An SMS Service has to be In Service and configured to define the appropriate message settings such as Maximum Message Length, number of Retries and the Timeout
  • An SMS Pager Channel has to be In Service and configured to have the appropriate settings for the ClearSCADA-service provider connection
  • Your user account has to have the appropriate Pager ID for the device you are going to use to send the SMS. It also needs to be associated with the appropriate SMS Pager Service and have SMS Commands enabled

For more information on the User Form’s Contact Information properties, see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security.

  • Your user account needs the appropriate permission for the database item (that has the action that is to be triggered). The permission required will vary according to the action you are attempting to trigger. For example, if you are using SMS to acknowledge an alarm for a point, your user account needs the Acknowledge Alarms permission for that specific point, whereas if you are using SMS to Hand Control a point, your user account will need to have the Control permission for the point.

For more information on permissions, see Permissions for Database Items in the ClearSCADA Guide to Security.

  • A Method Call item has to be configured to reference the appropriate database item and action for your requirements. If there are parameters for the action, these also need to be defined in an expression in the Method Call item’s configuration. The Method Call configuration should also define the alias that you need to use when sending the SMS command.

For more information on the Method Call configuration, see Configure the Method Call’s Properties in the ClearSCADA Guide to Core Configuration.

With the settings described above in place, you can trigger an action remotely via SMS:

  1. On the appropriate device, create a new SMS message.
  2. For the content of the SMS message, enter the alias. The alias is case sensitive and you the SMS message can only contain the alias string. Do not include any other string or character other than the alias in your SMS message as this will cause the SMS message to be disregarded by ClearSCADA (unless the alias and the characters you have added matches an action for the Root group item, in which case, that action will be triggered erroneously. That is why we strongly advise you to use aliases that are unique and not similar to existing actions for the Root group.
  3. Send the message to ClearSCADA.
    The message will be processed by the service provider and will be sent to ClearSCADA. ClearSCADA will then process the message and execute the action associated with the Method Call that has the alias that matches the alias in your SMS message.

NOTE: There may be a delay between sending the message and the required action being triggered. The length of the delay is dependent on how long it takes the service provider to process and send the message to ClearSCADA. In many circumstances, the action you wish to trigger with your SMS command will be performed seconds after you send your SMS message.


Pager Driver Guide - Issue an SMS Command by Referencing the Execute action of a Method Call (Using SMS to Trigger an Action)

Issue an SMS Command by Referencing the Execute action of a Method Call

Although not the recommend technique for triggering an action via SMS, it is possible for you to trigger an action by referencing the Execute method of a Method Call. When ClearSCADA receives an SMS message that references a Method Call’s Execute method, it will perform the action that is defined in the configuration of the Method Call. For example, let’s say that a Method Call named ‘Point 1 MC’ is associated with the Override action of a point named ‘DBP’. A user then sends an SMS message that references the Execute method of the ‘Point 1 MC’ Method Call. ClearSCADA processes the message and performs the Override action on the ‘DBP’ point, as these are the action and database point associated with the ‘Point 1 MC’ Method Call.

When you reference the Execute action of a Method Call, you need to include the FullName value of the Method Call, which includes its parent Group(s) as well as its name. You also need to reference its Execute action. As Method Calls can be nested in your system’s hierarchy, this can mean that the FullName and Execute reference can exceed the maximum size limit for a single SMS message. If your reference exceeds the maximum limit for an SMS, the reference is sent in parts in several SMS messages (this is called a multi-part SMS message).

Multi-part SMS messages have disadvantages when compared to using a Method Call with an alias:

  • They may consist of long strings that take longer to enter manually than an alias (which is a maximum of 32 characters).
  • Multi-part messages can be unreliable as ClearSCADA has to receive each part of the message before it can perform the required action. If the service provider is experiencing problems such as heavy network traffic or the network going down, there is an increased likelihood of delays and ClearSCADA may have to wait for a significant amount of time to receive all parts of a message. In some circumstances, such as a network failure, parts of the message may be lost entirely or may not be received by ClearSCADA within the expected time range of 1 hour. If ClearSCADA receives part of a message and does not receive the remaining parts of the message within 1 hour, the message is disregarded.
  • Increased cost. When an alias is used with a Method Call, the SMS command is one message (and so costs the price of sending a single SMS message). With a full reference to the Execute action of a Method Call, the SMS command may span several messages, with each part of the message costing the price of a single SMS message.

To issue an SMS Command by referencing the Execute action of a Method Call, the following configuration has to be in place:

  • An SMS Service has to be In Service and configured to define the appropriate message settings such as Maximum Message Length, number of Retries and the Timeout
  • An SMS Pager Channel has to be In Service and configured to have the appropriate settings for the ClearSCADA-service provider connection
  • Your user account has to have the appropriate Pager ID for the device you are going to use to send the SMS. It also has to be associated with the appropriate SMS Pager Service and have SMS Commands enabled

For more information on the User Form’s Contact Information properties, see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security.

  • Your user account has to be configured to have the appropriate permission for the database item that has the action that is to be triggered. The permission required will vary according to the action you are attempting to trigger. For example, if you are using SMS to acknowledge an alarm for a point, your user account needs the Acknowledge Alarms permission for that specific point, whereas if you are using SMS to Hand Control a point, your user account will need to have the Control permission for the point.

For more information on permissions, see Permissions for Database Items in the ClearSCADA Guide to Security.

  • A Method Call item has to be configured to reference the appropriate database item and action for your requirements. If there are parameters for the action, these also need to be defined in an expression within the Method Call item’s configuration.

For more information on the Method Call configuration, see Configure the Method Call’s Properties in the ClearSCADA Guide to Core Configuration.

With the settings described above in place, you can use a reference to a Method Call’s Execute method to trigger an action remotely via SMS:

  1. On the device that is associated with your user account, create a new SMS message.
  2. Enter the reference to the relevant Method Call’s Execute method as the content of your SMS message. The SMS message should only contain the characters for the reference and has to be in this format:
<Method Call Reference>.Execute()

Where:

<Method Call Reference> is the FullName value of the Method Call which includes all of its parent Group(s) as well as its name. Do not enter the angle brackets < >.

  3. Send the message to ClearSCADA.
    When ClearSCADA receives your SMS message via the service provider, it determines which Method Call is referenced in the SMS message. It then executes the action that is defined in the Method Call’s configuration.

Further Information

Issue an SMS Command by using an Alias on a Method Call.


Pager Driver Guide - Issue an SMS Command by Referencing the Action of a Database Item (Using SMS to Trigger an Action)

Issue an SMS Command by Referencing the Action of a Database Item

We recommend that you use a Method Call with an alias to issue SMS commands to ClearSCADA. However, there are also two other techniques you can use to issue SMS commands: you can reference the Execute method of a Method Call (see Issue an SMS Command by Referencing the Execute action of a Method Call) or you can reference the action of a specific database item.

When you reference the action of a specific database item, you need to include the FullName value of the database item, which includes its parent Group(s) as well as its name. You also need to reference the action (method) that is to be triggered, and any parameters for the action. As database items can be nested in your system’s hierarchy, this can mean that the FullName and action reference can exceed the maximum size limit for a single SMS message. If your reference exceeds the maximum limit for an SMS, the reference is sent in parts in several SMS messages (this is called a multi-part SMS message).

Multi-part SMS messages have disadvantages when compared to using a Method Call with an alias:

  • They may consist of long strings that take longer to enter manually than an alias (which is a maximum of 32 characters).
  • Multi-part messages can be unreliable as ClearSCADA has to receive each part of the message before it can perform the required action. If the service provider is experiencing problems such as heavy network traffic or the network going down, there is an increased likelihood of delays and ClearSCADA may have to wait for a significant amount of time to receive all parts of a message. In some circumstances such as a network failure, parts of the message may be lost entirely or may not be received by ClearSCADA within the expected time range of 1 hour. If ClearSCADA receives part of a message and does not receive the remaining parts of the message within 1 hour, the message is disregarded.
  • Increased cost. When an alias is used with a Method Call, the SMS command is one message. So the cost of sending the SMS command is the price of sending a single SMS message. With a full reference to an action, the SMS command may span several messages, with each part of the message costing the price of a single SMS message.

If, for some reason, you have a need to use a full reference to an action, the following configuration has to be in place:

  • An SMS Service has to be In Service and configured to define the appropriate message settings such as Maximum Message Length, number of Retries and the Timeout.
  • An SMS Pager Channel has to be In Service and configured to have the appropriate settings for the ClearSCADA-service provider connection.
  • Your user account has to have the appropriate Pager ID for the device you are going to use to send the SMS. It should also be associated with the appropriate SMS Pager Service and have SMS Commands enabled.

For more information on the User Form’s Contact Information properties, see Define the E-Mail, Pager, and Voicemail Contact Settings for a User in the ClearSCADA Guide to Security.

  • Your user account has to be configured to have the appropriate permission for the database item that has the action that is to be triggered. The permission required will vary according to the action you are attempting to trigger. For example, if you are using SMS to acknowledge an alarm for a point, your user account needs the Acknowledge Alarms permission for that specific point, whereas if you are using SMS to Hand Control a point, your user account will need to have the Control permission for the point.

For more information on permissions, see Permissions for Database Items in the ClearSCADA Guide to Security.

With the settings described above in place, you can use a full reference to trigger an action remotely via SMS:

  1. On the device that is associated with your user account, create a new SMS message.
  2. Enter the reference to the relevant database item’s action as the content of your SMS message. The SMS message should only contain the characters for the reference and needs to be in this format:
<Database Item Reference>.<Action>(Parameters)

Where:

<Database Item Reference> is the FullName value of the database item that has the action that is to be performed. The FullName includes the database item’s parent Group(s) as well as its name. Do not enter the angle brackets < >.

<Action> is the name of the action that is to be performed. If the action has parameters, you should include them after the <Action> within parentheses in the same way as you would when using an expression. For the action, do not include the angle brackets < >, but you have to include the parentheses for any parameters ( ). For more information on entering parameters, see Grammar for Expressions in the ClearSCADA Guide to Expressions.

  3. Send the message to ClearSCADA.
    When ClearSCADA receives your SMS message via the service provider, it determines which database item and action are referenced in the SMS message. It then executes the action.

Further Information

Issue an SMS Command by using an Alias on a Method Call.


Pager Driver Guide - SMS Command Failures (Using SMS to Trigger an Action)

SMS Command Failures

If you send an SMS command message and ClearSCADA does not respond as expected, your SMS message may have failed. There are several possible causes for failed SMS commands, and so if you suspect your SMS message has failed, you will need to investigate the problem.

  • If there are alarms relating to your SMS message shown in ViewX or WebX, the message has been rejected by ClearSCADA or the Pager Driver.

If the alarm Message contains:

  • 'SMS command rejected by pager driver', see SMS Messages Rejected by the Pager Driver.
  • 'Failed to process incoming SMS command', see SMS Messages Rejected by ClearSCADA.
  • If there are no alarms relating to your SMS message, there are two possible reasons for your SMS command failing to achieve the desired effect:
  1. The SMS message that you sent contained a valid command, but the command has been performed on a different database item. This can occur if your message is incorrect for the intended database item and action, but the mistake in the message means that the command is valid for a different database item. For example, if you gave an alias the same name as an action for the 'Root' Group (System), sending that action for the 'Root' Group as an SMS command would trigger the action for the alias instead (the action associated with the alias in the configuration of the Method Call takes precedence over the action for a database item).

If you suspect that the SMS command may have been accidentally performed on an incorrect database item, display the Events List and examine the entries. If the SMS command was processed and actioned, it will be logged in the Events List for the system (and the Events List for the SMS Service).

  2. The SMS message was not received by the Pager Driver. This can mean that the SMS service provider has not sent the message, cannot send the message, or the message is delayed in transit.

The cause of the problem is related to your device or your service provider. Please contact your service provider for assistance.

Further Information

Clearing an SMS Command Processor Excessive Failures Alarm.

Events in the ClearSCADA Guide to ViewX and WebX Clients.


Pager Driver Guide - SMS Messages Rejected by ClearSCADA (Using SMS to Trigger an Action)

SMS Messages Rejected by ClearSCADA

If you send an SMS command that is rejected by ClearSCADA, an alarm is raised. The alarm Message contains a description of the reason for rejecting the SMS command, which includes:

Failed to process incoming SMS command

NOTE: If an alarm Message includes SMS command rejected by Pager Driver, the SMS command has been rejected because it did not contain the required components for a valid SMS message. For more information, see SMS Messages Rejected by the Pager Driver.

There are several possible reasons for ClearSCADA to reject an SMS command:

  • ClearSCADA was unable to match the alias or database item and method in your SMS message to a corresponding alias or database item and method in the database. This usually indicates that the body of your message is invalid, for example, it may contain a spelling mistake.

In this situation, you should create a new SMS message and check that the correct alias or database item and method are defined. Send the SMS message again.

NOTE: There is also the possibility that your SMS command has triggered a control on a database item other than the database item you intended. This can occur if your message is incorrect for the intended database item and action, but the mistake in the message means that the command is valid for a different database item.

  • Your user account does not have the permissions required to initiate the command on the specified database item. You should contact your system administrator who may choose to allocate your user account the appropriate permissions or assign responsibility of sending the control to a different user.
  • There has been a number of successive SMS message failures and this has caused the internal Fail Count to exceed the Incoming SMS Fail Limit for the SMS Service. When the Fail Count exceeds the Incoming SMS Fail Limit, ClearSCADA does not attempt to process any incoming SMS messages (this is to help prevent potentially harmful SMS messages from being processed).

To remedy this situation, you should use the driver log files to investigate the incoming messages. If the messages being rejected contain errors rather than malicious commands, for example, you can manually reset the Fail Count. This will clear the alarm and allow ClearSCADA to process incoming SMS messages again.

For information on how to view the current value of the Fail Count and how to reset it manually, see Checking and Resetting the Fail Count for an SMS Service.

Further Information

SMS Messages Rejected by the Pager Driver.

Checking and Resetting the Fail Count for an SMS Service.


Pager Driver Guide - SMS Messages Rejected by the Pager Driver (Using SMS to Trigger an Action)

SMS Messages Rejected by the Pager Driver

If you send an SMS command that is rejected by the Pager Driver, an alarm is raised. The alarm Message contains a description of the reason for rejecting the SMS command, which includes:

SMS command rejected by Pager Driver

NOTE: If an alarm Message includes Failed to process incoming SMS command, the SMS command has been rejected by ClearSCADA. For more information, see SMS Messages Rejected by ClearSCADA.

The Pager Driver rejects any messages that do not contain the required components for the SMS protocol. The SMS protocol is defined in the document 'Digital cellular telecommunications system (Phase 2+); Use of Data Terminal Equipment - Data Circuit terminating; Equipment (DTE-DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) (GSM 07.05 versions 5.5.0.' which is available online at http://www.etsi.org.

If the Pager Driver has rejected your message, you will need to determine why the message did not contain the components expected in an SMS message. The reason for this will be related to your particular device or your service provider. We suggest you contact your service provider for assistance.

Your service provider may need the information in the Pager Driver log file for their investigation. You can access the driver log by following these steps:

  1. Run the ClearSCADA Server Configuration Tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Scroll down to the Registry branch.
  3. Select the DriverPager folder in the Registry branch.
    The contents of the DriverPager folder are shown in the right-hand pane.
  4. Look at the Data value of the LogFileBase file. This shows the location of the log file for your drivers.
  5. In Windows Explorer, browse to the log files for the drivers (at the location you discovered in step 3).
  6. Double-click on the DriverPager log(s) to display the log file(s) for the Pager Driver.
  7. Search the log file for the message that you sent. You can do this by searching for the body of your message.
  8. Examine the entry for your message. Information about the rejection will be included in the log file (in the details about your message). This information may help your service provider discover the cause of the problem.


Pager Driver Guide - Checking and Resetting the Fail Count for an SMS Service (Using SMS to Trigger an Action)

Checking and Resetting the Fail Count for an SMS Service

For each SMS Service, there is an internal Fail Count that is used in conjunction with the Incoming SMS Fail Limit (defined in the configuration of an SMS Service, see Define the Number of Times an SMS Service will attempt to Process Messages). The Fail Count increases by 1 each time an invalid SMS message is received via the SMS Pager Channel associated with the SMS Service—invalid messages can be rejected by the Pager Driver or by ClearSCADA. Each valid message causes the Fail Count to reset to 0. If the Fail Count exceeds the Incoming SMS Fail Limit, any incoming SMS messages for that SMS Service are disregarded (although they are logged).

The Fail Limit and Incoming SMS Fail Limit are used to:

  • Provide security against ongoing invalid SMS messages (which could be malicious)
  • Help prevent resources being wasted on attempts to process invalid SMS messages.

The Fail Limit and Incoming SMS Fail Limit offer greater protection and efficiency. However, they also stop ClearSCADA from processing any valid SMS messages that are received after the Incoming SMS Fail Limit has been exceeded. For example, if the Incoming SMS Fail Limit was set to 3 and 5 invalid SMS messages were received in succession and then a valid SMS message was received, ClearSCADA would only attempt to process the first 3 invalid messages. The fourth invalid SMS message would cause the Fail Count to exceed the Incoming SMS Fail Limit, and so an alarm would be raised. The fifth invalid message and the valid SMS that followed it would not be processed. As a result, the valid SMS would not be processed and so could not cause the Fail Count to be reset. In this situation, the alarm can only be cleared by a user manually resetting the Fail Count (this means that if the Fail Count is exceeded, there is user interaction and investigation into the cause of the invalid SMS messages).

NOTE: It is possible for the Fail Count to far exceed the Incoming SMS Fail Limit. For example, if the Pager Driver receives a high number of messages that it detects as being invalid SMS messages, it will reject each message. For each rejected message, the Pager Driver will instruct ClearSCADA to increase the count by 1—this may cause the Fail Count to rise significantly above the Incoming SMS Fail Limit, as the Pager Driver will reject each invalid message irrespective of the number of invalid messages received. ClearSCADA is different in that it will only process a set number of invalid messages (the Incoming SMS Fail Limit) before it stops processing messages.

In the following sections, we explain how to view the current value of the Fail Count and how to use the Reset Incoming SMS Command Failure Count action to reset the Fail Count manually:

  • Checking the Fail Count for Incoming SMS Commands
  • Resetting the Fail Count for Incoming SMS Commands.

NOTE: If you are seeking help with Clearing an SMS Command Processor Excessive Failures Alarm, you should refer to Resetting the Fail Count for Incoming SMS Commands.

Checking the Fail Count for Incoming SMS Commands

You can check the current value of an SMS Service’s internal Fail Count by using the OPC Data Explorer. Being able to view the current value of the Fail Count is useful as it allows you to see if the Fail Count is nearing the Incoming SMS Fail Limit that has been configured for the SMS Service. It also allows you to check that the Fail Limit has been reset to 0 after a manual reset (see Resetting the Fail Count for Incoming SMS Commands).

To check the current value of the Fail Count for an SMS Service:

  1. Log on to ClearSCADA via a User account that has the OPC Data permission (see User Account Permissions in the ClearSCADA Guide to Security).
  2. In the Database Bar, locate the relevant SMS Service database item and right-click on it to display its context sensitive menu.
  3. Select the Locate in OPC Data Explorer option.
    The OPC Data Explorer is displayed in place of the Database Bar. The OPC tags of the SMS Service are expanded automatically.
  4. Expand the $Config branch, and then right-click on the SMSCommandFailureCount tag and select the Display Value option from the context sensitive menu.
    A status dialog box is displayed that shows the Value of the Fail Count as well as other information such as its current Quality.
  5. Use the Copy or Copy All buttons to copy information from the dialog box to your computer’s clipboard area as required, or select the Close button to quit the dialog box. You can also update the information shown in the dialog box by selecting the Refresh button.

Further Information

Resetting the Fail Count for Incoming SMS Commands.

Resetting the Fail Count for Incoming SMS Commands

Each SMS Service has a Fail Count that increases by 1 when an invalid SMS message is received or resets to 0 when a valid SMS message is received. If a succession of invalid SMS messages are received, the Fail Count may exceed the SMS Service’s Incoming SMS Fail Limit (defined in the configuration of the SMS Service) and this will cause an alarm to be raised. Any messages received while the Fail Count exceeds the Incoming SMS Fail Limit are disregarded—ClearSCADA makes no attempt to process them as they may be malicious.

Should the Fail Count for an SMS Service exceed the SMS Service’s Incoming SMS Fail Limit, an SMS Command Processor Excessive Failures alarm is raised. The description for the alarm will include:

'SMS Command Processing suspended due to repeated failure(s) to process incoming SMS command(s)'.

If an SMS Command Processor Excessive Failures alarm is raised, you need to investigate the cause of the alarm by examining the entries in the driver log (see Display a Driver Log File in the ClearSCADA Guide to Server Administration). You should be able to use the information in the driver log to determine the source of the messages, which you can then use to investigate whether the messages pose a threat or are simply invalid due to error. For example, invalid messages may be being received because a user is consistently making the same mistake when typing in the text for the SMS.

Once you have discovered the cause of the alarm and have resolved the problem, you will need to clear the alarm by resetting the Fail Count manually. If you do not reset the Fail Count manually, ClearSCADA will continue to disregard incoming SMS messages for the SMS Service (as the alarm will not have cleared and the Fail Count will still be exceeding the Incoming SMS Fail Limit).

NOTE: You can reset the Fail Count manually when the Fail Count is higher than 0. There is no need to wait for an alarm to be raised.

To manually reset the Fail Count for an SMS Service:

  1. Log on to ClearSCADA via a User account that has the OPC Data permission (see User Account Permissions in the ClearSCADA Guide to Security).
  2. In the Database Bar, locate the relevant SMS Service database item and right-click on it to display its context sensitive menu.
  3. Select the Reset Incoming SMS Command Failure Count option.
    The Fail Count is reset to 0.

Further Information

Checking the Fail Count for Incoming SMS Commands.


Pager Driver Guide - Clearing an SMS Command Processor Excessive Failures Alarm (Using SMS to Trigger an Action)

Clearing an SMS Command Processor Excessive Failures Alarm

If the Fail Count for an SMS Service exceeds the Incoming SMS Fail Limit for the service, an alarm is raised. The alarm has a description that includes:

'SMS Command Processing suspended due to repeated failure(s) to process incoming SMS command(s)'.

To clear the alarm, you need to reset the Fail Count manually. For more information, see Resetting the Fail Count for Incoming SMS Commands.


Pager Driver Guide - Using Pager Specific Actions

Using Pager Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. These actions can be activated manually by a user (typically by selecting an action from a context-sensitive menu) or can be triggered automatically by ClearSCADA.

The Pager Driver provides two driver-specific actions that allow you to send messages to pager devices and mobile telephones:

  • Send Message
  • Send Pager Message.

Operators can access these actions by using the context sensitive menu for a:

  • Pager Service (see Actions Associated with Pager Services)
  • User account that has been configured to have Pager Contacts (see Pager Actions that are Associated with Users).

For more information on using context sensitive menus, see the ClearSCADA Guide to ViewX and WebX Clients.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)

NOTE: Users with the required permissions can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as 'methods').


Pager Driver Guide - Actions Associated with Pager Services (Using Pager Specific Actions)

Actions Associated with Pager Services

These actions are specific to Pager Services:

  • Send Message
  • Send Pager Message.


Pager Driver Guide - Send Message (Using Pager Specific Actions)

Send Message

Associated with:

  • TAP Pager Services that do not use Beep Codes
  • SMS Pager Services
  • UCP Pager Services.

Security permission required to access this pick action: Control

Use the Send Message pick action to send a message to a pager or mobile telephone.

For more information, see Sending a Message to a Pager or Mobile Phone.


Pager Driver Guide - Send Pager Message (Using Pager Specific Actions)

Send Pager Message

Associated with:

  • Multitone Pager Services
  • TAP Pager Services that use Beep Codes.

Security permission required to access this pick action: Control

Use the Send Pager Message pick action to send a text message to a pager or mobile telephone.

For more information, see Sending a Message to a Pager or Mobile Phone.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name SendMessageWithBeep.


Pager Driver Guide - Pager Actions that are Associated with Users (Using Pager Specific Actions)

Pager Actions that are Associated with Users

The following pager actions are specific to User accounts that have been allocated Pager Contacts (the Pager Contacts allow the users of the accounts to receive messages from ClearSCADA on their pager devices or mobile telephones).

  • Send Message
  • Send Pager Message.

For information on defining the Pager Contacts for a User account, see Configuring a User Account's Pager Properties.


Pager Driver Guide - Send Message (Using Pager Specific Actions)

Send Message

Available for User accounts that are associated with the following types of Pager Service:

  • TAP (Beep Codes not supported)
  • SMS
  • UCP.

Security permission required to access this pick action: Control

Use the Send Message pick action to send a message to a pager or mobile telephone.

For more information, see Sending a Message to a Pager or Mobile Phone.


Pager Driver Guide - Send Pager Message (Using Pager Specific Actions)

Send Pager Message

Available for User accounts that are associated with the following types of Pager Service:

  • Multitone
  • TAP (Beep Codes supported).

Security permission required to access this pick action: Control

Use the Send Pager Message pick action to send a text message to a pager or mobile telephone.

For more information, see Sending a Message to a Pager or Mobile Phone.

NOTE: If using this pick action with the Automation Interface, you need to specify the method name SendMessageWithBeep.


Pager Driver Guide - Pager Specific Alarm and Event Categories

Pager Specific Alarm and Event Categories

Each alarm and event on a ClearSCADA system has a Category that indicates the type of alarm or event. The Category is included in the Events List by default and, if applicable, is also included in the Alarms List and the Alarm Banner.

If required, you can filter the entries in the Events List or Alarms List by category. You can choose to filter the lists by a variety of ‘core’ categories as well as any categories that are specific to the drivers that are installed on your system.

On systems that have the Pager driver components installed, the ‘core’ alarm and event categories are available as well as these Pager-specific categories:

  • Pager Comms—Entries associated with events and alarms that relate to the communications status of a pager service. For example, an event is logged when there is an attempt to connect with a pager and an alarm is raised if there are failed communications between the ClearSCADA server and a pager.
  • SMS Pager Service—Entries associated with unexpected or erroneous responses from the GSM modem (the Pager Driver can still communicate with the GSM modem, but either the content of the SMS message being received is invalid or ClearSCADA is unable to process the SMS command).

Further Information

Filter Categories: see Filter a List in the ClearSCADA Guide to Alarms.

Alarm Banner: see Alarm Banner in the ClearSCADA Guide to Alarms.

Alarms Lists: see Alarms Lists in the ClearSCADA Guide to Alarms.

Events List: see Events Lists in the ClearSCADA Guide to Lists.


Pager Driver Guide - Pager Specific Status Display Attributes

Pager Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item, for example, the Status display for a Multitone Pager Channel provides information about the present state of the individual pager channel.

Use this section if you need information about the status of any Pager database items.

This section explains the Alarm Channel status attribute, which is Pager driver specific.

NOTE: Pager Services and Pager Channels do not have fleeting alarms.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


Pager Driver Guide - Alarm Channel (Pager Specific Status Display Attributes)

Alarm Channel

Associated with: Pager Channels

The Alarm Channel attribute indicates the health of a Pager Channel.

In normal conditions, ClearSCADA will detect that the Pager Channel is working correctly and has no alarms. In this situation, the Alarm Channel status shows Enabled Inactive (the channel has an alarm feature enabled so is being monitored by ClearSCADA, but has no active alarms).

If ClearSCADA detects a problem with the channel, such as a failure or disconnection, the Alarm Channel status will change to indicate that an alarm is raised.

Possible States: Displays one of the Standard Alarm States.


Pager Driver Guide - Pager-Specific Driver Log File Options

Pager-Specific Driver Log File Options

System Administrators and high-level engineers can use Log files for to investigate unexpected system behavior. Each driver can have its own Log file(s) which provides useful diagnostic information, including information about the driver's channels. You can configure the Log files to include various categories of information by using Log file options.

To produce Log files and define the Log file settings for the Pager driver, you need to use the ClearSCADA Server Status Tool:

  1. Run the ClearSCADA Server Status Tool (see Run the Server Status Tool in the ClearSCADA Guide to the Server Status Tool).
  2. Browse to the General>Modules section.
  3. In the Modules section, right-click on the Pager entry, then select the Logging option from the context-sensitive menu. This displays the Driver Pager Logging Window.

The Driver Pager Logging Window contains the following Log file options:

  • Application—Logs general information about the driver.
  • Errors—Logs any errors detected during driver operation. For example, communications failures or the connection to the ClearSCADA database failing.
  • Timers—Logs information about low-level internal thread timer queues.

ATTENTION: We recommend that you only enable the Timers feature when specifically asked to do so by Schneider Electric engineers. This is because, when enabled, the Timers feature can cause large amounts of data to be logged, which can make it more difficult to locate specific data in the files. It is also possible that the Timers logging could overwrite other log data that is needed by Schneider Electric engineers, and may affect system performance.

  • Events—Logs information about low-level internal thread event queues.

ATTENTION: We recommend that you only enable the Events feature when specifically asked to do so by Schneider Electric engineers. This is because, when enabled, the Events feature can cause large amounts of data to be logged, which can make it more difficult to locate specific data in the files. It is also possible that the Events logging could overwrite other log data that is needed by Schneider Electric engineers, and may affect system performance.

  • I/O—Logs information about low-level serial input and output.
  • Database Objects—Logs changes to database items.
  • Channels—Logs information about the channels on the system.
  • Modems—Logs information on modem exchanges and states.
  • Requests (Actions)—Logs information about any external requests from users, plus internal requests within the driver.
  • Client Sink—Logs information about the low-level interface from server to driver.
  • Server Sink—Logs information about the low-level interface from driver to server.
  • Browse Server—Logs information about the use of the browse options on configuration Forms. For example, the Comm Port browser on a Channel Form.
  • Pager Functions—Logs the current paging states.

As logging can affect system performance, we recommend that you enable the common logging options by selecting the Typical button (on new systems, the Typical logging options are enabled by default). This sets the Log file for the Pager Driver so that it contains the information needed to diagnose the majority of system problems. Using the Typical logging option also means that Pager Driver logging has less effect on system performance.

If you experience unexpected system behavior and need to contact Schneider Electric, you may be asked to change the Log file settings. In many cases, the Typical settings provide all the information we need.

NOTE: When troubleshooting on a ClearSCADA system, use the Events List to view diagnostics messages. These may help to identify the cause of any problems that ClearSCADA has detected.

Further Information

General information on analyzing a ClearSCADA system: see the ClearSCADA Guide to the Server Status Tool.

Producing log files and defining the log file settings: see Driver Logging in the ClearSCADA Guide to Server Administration.


SNMP Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SNMP Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


SNMP Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


SNMP Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


SNMP Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SNMP Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to use the Simple Network Management Protocol (SNMP) driver to allow ClearSCADA to retrieve point data, alarms and events using SNMP. It also explains how to:

  • Configure SNMP-specific features and items within the ClearSCADA database
  • Define whether users can set data values at the SNMP agents
  • Operate SNMP-specific actions
  • Filter the Alarms List and Events List to show only those entries that are associated with SNMP configuration errors
  • Use the SNMP driver-specific features for diagnosis and fault-finding

For more details on the content of this guide, see Introduction to the SNMP Driver.


SNMP Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is intended for use by all levels of user:

  • Engineers who are responsible for configuring SNMP-specific features
  • Operators who need to use SNMP-specific actions as part of their duties
  • System administrators when diagnosing unexpected behavior relating to SNMP and the SNMP driver


SNMP Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


SNMP Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Drivers

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Core Point Configuration

ClearSCADA Guide to Lists

ClearSCADA Guide to Alarms

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to the Server Status Tool.


SNMP Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


SNMP Driver Guide - Introduction to the SNMP Driver

Introduction to the SNMP Driver

The Simple Network Management Protocol (SNMP) is the standard network operations and maintenance protocol. The SNMP protocol can be used to remotely monitor and manage networked devices over a Local Area Network (LAN) or Wide Area Network (WAN). The protocol can run on top of other protocols, other than TCP/IP.

The syntax used for SNMP is Abstract Syntax Notation 1 (ASN.1). The syntax is used, for example, to define the type of data that is being retrieved using the SNMP protocol. The protocol works by using software ‘agents’ that are embedded into the networked devices in order to monitor various aspects of network status, such as events, network traffic, or device status. The SNMP driver acts as an SNMP Manager to retrieve such data from the SNMP agents, or control the data values. ClearSCADA’s SNMP driver supports SNMP 1.

Using ClearSCADA’s SNMP driver, you can retrieve current point data (by specifying a Poll action), or alarms and significant events (by specifying a Trap action—see Understanding Traps). You can also specify whether users can set data values at the SNMP agents.

For a list of data types supported by ClearSCADA, see ASN Data Type.

The SNMP documentation explains how to configure SNMP-specific features and items within the ClearSCADA database (see Configuring SNMP Items in ClearSCADA).

It also explains driver-specific features that may be of interest to system administrators and engineers when investigating unexpected system behavior (relating to the SNMP driver). The driver-specific features include:

  • SNMP Specific Status Display Attributes
  • SNMP Specific Driver Log File Options.

and driver-specific features that are of interest to operators using the system (see Using SNMP Specific Actions).

Operators can filter Alarm and Event Lists to display only those entries that are associated with SNMP Configuration Errors (see SNMP Specific Alarm and Event Categories).


SNMP Driver Guide - Understanding Traps (Introduction to the SNMP Driver)

Understanding Traps

‘Traps’ allow a large number of devices to be monitored by the SNMP driver, without the need to poll each of those devices. Instead, the SNMP agent on a device sends an unsolicited message—a ‘trap’ of an unusual or unexpected event—to the driver. Operators can then decide whether to separately poll the device, or other associated device(s), to obtain further information about the cause of the alarm or event.

SNMP supports several standard traps that are common to many networked devices. These are known as Generic Traps.

In addition to these Generic Traps, SNMP agents on different devices can be programmed to support any number of proprietary or enterprise Specific Traps. Such traps fall into three categories:

  • Technology-specific traps
  • Vendor-produced product-specific traps
  • Corporate management-specific traps

In each case, the SNMP agent at the device has to be programmed to send traps. Such information is incorporated into a Management Interface Base (MIB). A MIB is a logical database that incorporates the configuration status and statistical information that is stored at the device. MIBs for technology- and product-specific traps should be supplied with the product—see the product documentation for details. The production of MIBs is beyond the scope of this guide.

Within the ClearSCADA database, you define the SNMP agent’s Device ID and Community name. For Specific Traps, you also define the Object Identifier, and properties that define the trap-specific information that is to appear in any data packets sent by the SNMP agent. For more information, see Configuring Points on the SNMP Driver.

We recommend the use of a free tool called Getif for discovering the correct object identifiers (OIDs) for SNMP agents. You can download the tool from http://www.wtcs.org/snmp4tpc/getif.htm.

When an SNMP agent returns a trap message to the SNMP driver, the data packet that it sends contains:

  • The IP address (Device ID) of the device on which the SNMP agent is located
  • The Generic or Specific Trap Code
  • 0 or more binding packets that contain the Object Identifier (OID) for the MIB and the variable (which may also be the Object Identifier).


SNMP Driver Guide - Configuring SNMP Items in ClearSCADA (Introduction to the SNMP Driver)

Configuring SNMP Items in ClearSCADA

On a ClearSCADA system, you configure the ClearSCADA database so that entries in the database correspond to the devices on your system. In the case of the SNMP driver, you configure an SNMP point for each data value that ClearSCADA is to retrieve from an SNMP agent.

To configure the points and to retrieve data using the SNMP protocol, the SNMP Driver has to be installed and running on the ClearSCADA servers on your system. The driver is represented by the SNMP Manager component in the ClearSCADA Installation Wizard’s Setup window. The component is located within the Server branch of tree that is displayed in the window (see Install a Driver in ClearSCADA in the ClearSCADA Guide to Drivers).

You may also need to specify a delay to allow local SNMP agents on the server to start up before the driver polls them for data (for instance for information on disk space, or power supply). For further information, see Configuring SNMP Server Settings.

You then define SNMP points within the ClearSCADA database to define the values that ClearSCADA is to retrieve, and how that data is handled within ClearSCADA. The SNMP driver supports four types of SNMP point, which each handle different types of data (see Configuring Points on the SNMP Driver).

Many of the point settings need to correspond to the settings of the relevant SNMP agent, or the poll requirements for the data. Some of these settings are fixed, others are configured by an engineer. You need to have access to, or an understanding of the settings used on your system before you can configure SNMP points successfully.

For instance, you need to know the IP address of the SNMP agent with which each point is associated, the community, and the object identifier (OID) for the point value within the SNMP agent.

NOTE: We recommend the use of a free tool called Getif for discovering the correct object identifiers (OIDs) for SNMP agents. You can download the tool from http://www.wtcs.org/snmp4tpc/getif.htm.

You also need to be aware of which optional features are required for each SNMP point. These features include:

  • Alarm views
  • Alarm redirections
  • Historic data storage
  • User methods.

You can also use core ClearSCADA features with SNMP points, including Lists, Actions, and Mimics.

For actions that are specific to the SNMP driver, see Using SNMP Specific Actions. For further information on actions and for details on Lists and Mimics, see the core documentation.


SNMP Driver Guide - Tabs on Configuration Forms (Introduction to the SNMP Driver)

Tabs on Configuration Forms

Configuration Forms, such as the SNMP Cardinal Point Form, have several tabs for configuring different aspects of the item’s configuration. For each SNMP item that you configure, the configuration Form has a combination of these tabs:

  • Identification—Use to define a Help View and to indicate whether the point is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use to define any custom pick actions (‘methods’) for an item (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use to define optional features associated with alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use to define any alarm redirections for the item (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • Historic—Use to define historic storage features for SNMP points other than String points (see Defining Historic Details for a Point in the ClearSCADA Guide to Core Point Configuration).

In addition, further tab(s) are displayed in order for you to configure properties that are specific to the type of SNMP point. For information on these tabs, see the relevant configuration sections within this guide.


SNMP Driver Guide - Configuring SNMP Server Settings

Configuring SNMP Server Settings

Some driver-specific settings need configuring on the server by a system administrator when a ClearSCADA system is first installed. These settings are configured using the ClearSCADA Server Configuration Tool.

This section explains the settings that are specific to the SNMP driver. These settings are in addition to the common driver settings (see Use the ClearSCADA Server Configuration Tool to Specify the Common Driver Settings in the ClearSCADA Guide to Drivers).

To access the SNMP section of the tool and make any necessary configuration adjustments:

  1. Run the ClearSCADA Server Configuration tool (see Accessing the ClearSCADA Server Configuration Tool in the ClearSCADA Guide to Server Administration).
  2. Expand the Global Parameters branch in the Server Configuration tree-structure.
  3. In the Global Parameters hierarchy, select the SNMP Manager entry.

The SNMP Manager section is shown in the right-hand pane of the Server Configuration window.

  4. Enter the required Delay, in seconds, to allow any local SNMP agents to initialize, before the SNMP driver attempts to poll them for data.

Such a delay is required when monitoring SNMP values locally at the server (for example, disk space, or power supply). In such cases, a delay should be specified to allow the SNMP agents to start up before the driver polls them for data.

You need to define a delay that is less than the Driver Start/Stop Timeout that is specified on the Drivers section of the ClearSCADA Server Configuration Tool (see Driver Settings in the ClearSCADA Guide to Server Administration).

If the Start Up Delay is longer than the Start/Stop Timeout, this will cause the driver to keep stopping and then re-starting (as the server will time the driver out before it even starts).

  5. Right-click on the server (‘node’) entry in the hierarchical list in the Server Configuration window.
    A context sensitive menu is displayed.
  6. Select the Apply Changes option.
    The changes are applied to the server configuration.
  7. If the server is currently running as the main server, restart the driver for the changes to take effect (see Start and Stop a Driver in the ClearSCADA Guide to Server Administration).
  8. Repeat the above steps for each of the servers on your system (with the exception of Permanent Standby servers, which do not run the drivers).


SNMP Driver Guide - Configuring Points on the SNMP Driver

Configuring Points on the SNMP Driver

The SNMP driver supports the point types that are listed below. You need to configure those point types that correspond to the type of data that the SNMP driver is to retrieve from other network devices on your system.

You need to configure one point of the required type per data value. You need to specify whether a point is used to retrieve current point data, or trap messages (alarms and significant events). Within the point configuration, you define how that data is handled and presented within ClearSCADA.

You configure each point using fields on the appropriate SNMP Point Form.

For information on creating a point and displaying a Point Form, see Configuring a Point in the ClearSCADA Guide to Core Point Configuration.

For information on configuring fields on the <Point Type> tab (for example, the Digital Point tab of the SNMP Digital Point Form), see these references:

  • Configure the Common Point Properties
  • Configure the Poll and Link Status Properties
  • Configure the Trap Specific Properties
  • Configure Integer and Cardinal Point Scaling.

also see, as appropriate:

  • Cardinal Point—Use to accumulate values over time (see Configuring Cardinal Points)
  • Digital Point—Use to retrieve digital-type values (see Configuring Digital Points)
  • Integer Point—Use to retrieve analog-type values (see Configuring Integer Points)
  • String Point—Use to retrieve text strings (see Configuring String Points).

Other tabs on SNMP Point Forms contain fields that are common to points on many drivers—for information on configuring such fields, see Tabs on Configuration Forms.

For information on the minimal amount of configuration that you can undertake to produce a functional SNMP point in ClearSCADA, see Minimum Configuration.


SNMP Driver Guide - Minimum Configuration (Configuring Points on the SNMP Driver)

Minimum Configuration

For each point, you need to specify these features on the <Point Type> tab (as a minimum):

  • The Device name (or IP address) of the SNMP agent with which the point is to be associated.
  • The Object Identifier (OID) that links the point with a particular value in the SNMP agent.
  • If the point is to store technology-, product- or user-specific alarm or event data, you need to specify the Trap Specific properties.

If you want point data to be stored historically, you also need to:

  • Enable and configure logging on the Historic tab, if data is to be stored historically in the server database.

When you have specified the required settings, put the point In Service so that it is ‘active’ on your system, and then save the configuration.


SNMP Driver Guide - Configure the Common Point Properties (Configuring Points on the SNMP Driver)

Configure the Common Point Properties

Use the fields at the top of the <Point Type> tab on the appropriate SNMP Point Form to configure these common point properties:

  • In Service—Use to specify whether the point is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Confirm Disable/Enable—Users with the required permissions can disable a point that is In Service, or enable a point that is not In Service. Such actions are carried out using the Disable Point and Enable Point pick actions.

Use the Confirm Disable/Enable combo box to specify whether a confirmation dialog box is displayed whenever an operator requests that this point is disabled or enabled (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

  • Action—Use to specify the type of data retrieval that is associated with the point.
  • Poll—The point is used to retrieve current point values. If this option is selected, the driver updates the value in the ClearSCADA database whenever that point value changes. It does not update the point value in the database while the value remains unchanged.

If this option is selected, use the Device and Object Identifier fields (see below) to specify the value that this point is to monitor. You also need to Configure the Poll and Link Status Properties.

  • Link Status—Applies only to 1-bit Digital points. The point is used to determine whether a device is currently accessible via a particular link.

If this option is selected, use the Device field (see below) to specify the link that this point is to monitor. You also need to Configure the Poll and Link Status Properties.

You need to configure the point states such that State 0 indicates that the device is healthy and being polled for data, and State 1 indicates that the link has failed (either the device, or the network between the device and ClearSCADA, has failed).

  • Trap Generic—The point is used to retrieve alarm or significant event data using the generic SNMP trap (see Understanding Traps).

If this option is selected, each trap returns generic code in the data, which specifies which event has occurred.

  • Trap Specific—The point is used to retrieve alarm or significant event data using a trap that is technology-, product- or user-specific.

If this option is selected, you also need to supply the trap’s Object Identifier (see below) and Configure the Trap Specific Properties.

  • Device—Use to specify the name of the remote SNMP agent with which the point is associated. This is typically the IP address of the network device.

Example:

10.3.2.54

Use the browse button to display a Reference browse window and select the required entry from the window.

  • Community Name—Use to specify the access community for the point. The community name is, in effect, a password that is used to restrict access to the data within an SNMP agent. It is a name that is shared by the SNMP management work stations and hosts. You should be able to obtain the name from your network administrator.
  • Object Identifier—Not applicable for Trap Generic or Link Status actions. Use to specify the identifier that links this point to the appropriate value in the SNMP agent. The identifier is a string of numbers that is derived from a global naming tree, and is used to identify the object.

Example:

.1.3.6.1.2.1.1.1.0

NOTE: We recommend the use of a free tool called Getif for discovering the correct object identifiers (OIDs) for SNMP agents. You can download the tool from http://www.wtcs.org/snmp4tpc/getif.htm.

  • Severity—Use this combo box to define the severity of any events that are logged, or alarms that are raised for the point. For example, ClearSCADA raises an alarm if the point has invalid Device configuration or the Object Identifier is incorrect.

For more information on severities, see Defining Severities in the ClearSCADA Guide to Core Configuration.

  • Area of Interest—If the Area of Interest feature is enabled on your system, an Area of Interest field is displayed. Use the field to specify the Area of Interest with which the point’s alarms and events are associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).
  • Confirm Set Value—This field only applies if the point is used to retrieve current point data and has its Action set to Poll. Use this combo box to specify whether a confirmation dialog box is displayed whenever an operator attempts to set the point’ s value (see Requesting Confirmation of Action Requests in the ClearSCADA Guide to Core Configuration).

To specify whether a point value can be set, use the Set Value Enabled check box within the Poll/Link Status section of the tab (see Configure the Poll and Link Status Properties).

In addition to the fields listed above, the SNMP Digital Point Form displays these fields:

  • Number of Bits (see Single and Multi-Bit Digital Points in the ClearSCADA Guide to Core Point Configuration). Where a 1-bit Digital Point is used to monitor Link Status, configure the point states such that State 0 indicates that the device is healthy and being polled for data, and State 1 indicates that the link has failed (either the device, or the network between the device and ClearSCADA, has failed).
  • Format (see Define the Format of a Digital Point’s Values in the ClearSCADA Guide to Core Point Configuration).


SNMP Driver Guide - Configure the Poll and Link Status Properties (Configuring Points on the SNMP Driver)

Configure the Poll and Link Status Properties

If the point is used to retrieve Link Status, or current point data (as opposed to Trap notifications), you need to specify the poll properties in the Poll/Link Status section of the <Point Type> tab.

The fields within the Poll/Link Status section of the <Point Type> tab are only available for use when the point Action is set to Poll or Link Status (see Configure the Common Point Properties).

  • Poll Interval—Specify the frequency with which the SNMP driver scans the SNMP agent for changes in point value. Enter the period in the OPC Time Format, for example, 1M for one minute.
  • Timeout—Specify the maximum time that the driver waits for a response from the SNMP agent. If the SNMP agent does not send a response within this period, and the specified number of Retries (see below) has been exhausted, the point quality changes to indicate the failure.

On the SNMP driver, the Timeout period doubles for every retry. So, for example, a Timeout of 0.100S would double to 0.200S for a first retry. Take care to set the initial and subsequent Timeout periods appropriately. If they are too long, the SNMP driver could start back logging other poll requests, while it continues to attempt to contact a particular SNMP agent.

The SNMP driver uses a single thread to poll the SNMP agents. If an SNMP agent fails to respond to a poll and the retries, the polling of other SNMP agents will have been delayed for the period of those Timeouts and Retries. As the Timeout period doubles for every retry, having a large timeout period or more than one retry could cause an undesirable delay in polling SNMP agents should, for instance, the network on which the SNMP agent(s) reside, fail or run slowly.

Enter the required Timeout period in the OPC Time Format. If a device resides on the same network as the ClearSCADA server (a LAN), we recommend a Timeout of no higher than 0.100S (for one tenth of a second) and a single Retry (see below). If a device resides on another network to the ClearSCADA server (a WAN), or otherwise communicates via a slow link, we recommend that you calculate the average ‘ping time’ between the server and the device and specify a Timeout that is 5% to 10% greater than that value. Again, we recommend using a single Retry, if a retry is required (for instance, if a timeout occurs due to a busy network).

In either case, you may need to increase the Timeout period if there are a significant number of timeouts, but beware that the Timeout period doubles for every retry.

  • Retries—Specify the maximum number of times that the SNMP driver is to re-attempt scanning the SNMP agent if it receives no response to its poll request.

The number of Retries is used alongside the Timeout period (see above) to attempt to successfully poll a device if the initial attempt fails. Be aware that the Timeout period doubles with each retry and the SNMP driver polls the SNMP agents using the same thread. Therefore, if a SNMP agent fails to respond to a poll for a point that has a large Timeout period configured, or more than one retry specified, this could cause an undesirable delay in polling other SNMP agents.

We recommend that you specify only a single retry in the Retries field (if a retry is required), and that the Timeout period is kept as short as possible (see the Timeout field above for more detailed information).

Example:

An SNMP Integer Point is used to retrieve current data, and has this configuration:

Poll Interval: 10M
Timeout: 0.100S
Retries: 2

At 12:10:00.000, the driver polls the SNMP agent.

At 12:10:00.100, it has received no response from the agent, so it polls the device again. The Timeout period is doubled from 0.100S to 0.200S.

At 12:10:00.300, it has still not received a response, so it polls the device for the final time (as the point configuration specifies a maximum of 2 retries). The Timeout period is doubled again, to 0.400S.

At 12:10:00.700, the driver has still not received a response from the SNMP agent, so the point quality changes to Comms Failure.

(Throughout this time, from 12:10:00.000 until 12:10:00.700, the SNMP driver does not poll any other SNMP agents, as the driver uses a single thread to poll the SNMP agents.)

  • Set Value Enabled—Not applicable to Digital points that are used to retrieve Link Status information. Use this check box to specify whether ClearSCADA is able to set the value at the SNMP agent.

Select the check box if the ability to set a value from ClearSCADA is to be enabled. To set a value in this way, the SNMP agent has to be read/write, the Community has to have write privileges, and the Object Identifier requires write access.

When the Set Value Enabled check box is selected, operators can set the value manually, using the Set Value pick action. The value can also be set automatically, for instance, using a Method-type Alarm Redirection action (see Choose a Type of Alarm Redirection in the ClearSCADA Guide to Alarm Redirection).

Use the Confirm Set Value field (see Configure the Common Point Properties) to specify whether a Confirmation dialog is displayed whenever an operator requests a Set Value action.

Clear the check box to disable the ability to set the value from ClearSCADA.


SNMP Driver Guide - Configure the Trap Specific Properties (Configuring Points on the SNMP Driver)

Configure the Trap Specific Properties

If the point is used to retrieve technology-, product- or user-specific trap information (as opposed to Poll or Generic trap data), you need to specify the trap-specific details in the Trap Specific section of the <Point Type> tab. These properties define the trap-specific information that is to appear in any data packets sent by the SNMP agent, to identify which alarm or event the agent is reporting.

The fields within the Trap Specific section of the <Point Type> tab are only available for use when the point Action is set to Trap Specific (see Configure the Common Point Properties).

  • Position—Specify the identifier for the Trap variable with which the point is associated.
  • Location—Specify the position of the Object Identifier within the data packet that is sent from the SNMP Agent. Choose from:
  • Variable—The Object Identifier is located within the Variable part of the packet.
  • Value—The Object Identifier is located within the Value part of the packet.

If the Value option is chosen, you need to specify the value’s Variable type and Specific Code (see below).

  • Variable—Applicable if the Location (see above) is set to ‘Value’. Specify whether the data packet for the point value contains trap-specific code or the variable value. Select either Code or Value, as appropriate.
  • Specific Code—Applicable if the Location and Variable fields (see above) are set to ‘Value’. Specify the code that needs to be included in the trap message for the SNMP driver to process the message.


SNMP Driver Guide - Configure Integer and Cardinal Point Scaling (Configuring Points on the SNMP Driver)

Configure Integer and Cardinal Point Scaling

Use the fields within the Scaling section of the <Point Type> tab to configure an SNMP Integer or Cardinal Point’s scaling. The SNMP driver applies the scaling to each integer or cardinal value that it retrieves from an SNMP agent, before passing the resultant value to the ClearSCADA database. The driver applies the scaling in reverse whenever the Set Value pick action is used.

  • Multiplier—Use to specify the amount by which the SNMP driver is to multiply each value that it retrieves from the SNMP agent. The driver then applies the relevant Offset before passing the resultant value to ClearSCADA.

Leave at the default of 1 if the driver is not required to perform such a multiplication task.

  • Offset—Use to specify the amount that the SNMP driver is to add or subtract from each value, once the Multiplier has been applied.

Leave at the default of 0 is no addition or subtraction is required.

Example 1:

An SNMP Integer point’s configuration includes this Scaling:

Multiplier: 0.1
Offset: 5

The SNMP driver applies the scaling to each integer value that it retrieves from the SNMP agent with which the point is associated.

In this particular case, the driver multiplies the retrieved value by 0.1, then adds 5 to that value, before passing the resultant value to the ClearSCADA database.

So if the driver retrieves an integer value of 45, for example, it will pass a value of 9.5 to ClearSCADA (as (45 x 0.1) + 5 = 9.5).

Example 2:

Another SNMP Integer point has its Set Value Enabled check box selected in the Poll/Link Status section of the Point Form. The SNMP driver has read/write access to the SNMP agent with which the point is associated, and write access to the community specified in the point’s Community Name field.

The point’s configuration includes this Scaling:

Multiplier: 0.1
Offset: 5

An operator uses the Set Value pick action to set the point value to 20.

The ClearSCADA server passes the value to the SNMP driver, which applies the point’s scaling in reverse (deducting the Offset and dividing by the Multiplier).

This results in the driver sending a command to the SNMP agent to set its value to 150 (as (20 - 5) / 0.1 = 150).


SNMP Driver Guide - Configuring Cardinal Points

Configuring Cardinal Points

The SNMP driver supports Cardinal points. Cardinal points use counter-type processing. Use SNMP Cardinal points to accumulate values over time, where those values are retrieved from network devices on your system, using the SNMP protocol.

Configure the properties of a cardinal point using the fields on the SNMP Cardinal Point Form.

This section summarizes the fields on the Form’s Cardinal Point tab.

Use the fields at the top of the Cardinal Point tab to:

  • Configure the Common Point Properties
  • Configure the Poll and Link Status Properties
  • Configure the Trap Specific Properties
  • Configure Integer and Cardinal Point Scaling.

The remaining fields on the Cardinal Point tab are common to counter-type points on many drivers. For information on these fields, see Defining Counter Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on other tabs on the Form, see Tabs on Configuration Forms.


SNMP Driver Guide - Configuring Digital Points

Configuring Digital Points

The SNMP protocol does not directly support digital data. However, within SNMP, integer values can be assigned ‘enumeration’ values. This assignment is carried out within the MIB database at the SNMP agent, whereupon integers can be assigned pre-defined values.

Example:

An integer for a printer might be assigned these values within a MIB:

Other = 1
Unknown = 2
Idle = 3
Printing = 4
Warm Up = 5

In such a case, you can assign such integers to SNMP Digital points within the ClearSCADA database.

The SNMP driver supports 1-, 2-, and 3-bit digital input points. Use SNMP digital points to retrieve digital-type data values on network devices on your system, using the SNMP protocol.

Configure the properties of a digital point using the fields on the SNMP Digital Point Form.

For information on the fields at the top of the Digital Point tab that are specific to the SNMP driver, see Configuring Points on the SNMP Driver.

NOTE: Where a 1-bit Digital Point is used to monitor Link Status, configure the point states so that State 0 indicates that the device is healthy and being polled for data, and State 1 indicates that the link has failed (the device has failed or the network between the device and ClearSCADA has failed).

The remaining fields on the Digital Point tab are common to digital points on many drivers (see Defining Digital Point Details in the ClearSCADA Guide to Core Point Configuration).

For fields on other tabs on the Form, see Tabs on Configuration Forms.


SNMP Driver Guide - Configuring Integer Points

Configuring Integer Points

The SNMP driver supports Integer points. Integer points use analog-type processing. Use SNMP Integer points to retrieve analog-type data values from network devices on your system, using the SNMP protocol.

NOTE: Where an integer is assigned specific ‘enumeration’ values in a MIB, you may want to consider assigning that integer to an SNMP Digital point within the ClearSCADA database, rather than an SNMP Integer point (see Configuring Digital Points).

Configure the properties of an integer point using the fields on the SNMP Integer Point Form.

This section summarizes the fields on the Form’s Integer Point tab.

Use the fields at the top of the Integer Point tab to:

  • Configure the Common Point Properties
  • Configure the Poll and Link Status Properties
  • Configure the Trap Specific Properties
  • Configure Integer and Cardinal Point Scaling.

The remaining fields on the Integer Point tab are common to analog-type points on many drivers. For information on these fields, see Defining Analog Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on other tabs on the Form, see Tabs on Configuration Forms.


SNMP Driver Guide - Configuring String Points

Configuring String Points

The SNMP driver supports String points. Use SNMP String points to retrieve text string data values from network devices on your system, using the SNMP protocol.

Configure the properties of a string point using the fields on the SNMP String Point Form.

For information on the fields on the String Point tab that are specific to the SNMP driver, see Configuring Points on the SNMP Driver.

The remaining fields on the String Point tab are common to string points on many drivers. For information on these fields, see Defining String Point Details in the ClearSCADA Guide to Core Point Configuration.

For fields on other tabs on the Form, see Tabs on Configuration Forms.

NOTE: SNMP String points do not support historic functionality.


SNMP Driver Guide - SNMP Specific Alarm and Event Categories

SNMP Specific Alarm and Event Categories

Each alarm and event on a ClearSCADA system has a Category that indicates the type of alarm or event. The Category is included by default in the Events List and, if applicable, the Alarms List and the Alarm Banner.

You can optionally filter the entries in either List by category—the entries from which you can choose comprise various ‘core’ categories, along with any categories that are specific to the drivers that are installed on your system.

On systems on which the SNMP driver is installed, in addition to the ‘core’ alarm and event categories, this SNMP specific category is available:

  • SNMP Configuration Error—Entries associated with object identifier configuration problems. The SNMP driver generates such entries whenever it receives ‘invalid configuration’ messages from the device(s) that it is polling. Such a message might, for instance, indicate that a particular object identifier does not exist in a device.

Each SNMP point has an SNMP Config Alarm status attribute that indicates whether an SNMP Configuration Error was reported when the driver last attempted to retrieve the point’s data. You can ascertain the status of this attribute by viewing the point’s Status display (see SNMP Specific Status Display Attributes).

Further Information

Events Lists and ‘core’ filter categories: see the ClearSCADA Guide to Lists.

Alarms Lists and ‘core’ filter categories: see the ClearSCADA Guide to Alarms.


SNMP Driver Guide - SNMP Specific Status Display Attributes

SNMP Specific Status Display Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for an SNMP point provides information about the present state of that point.

Use this section if you need information on the status of any SNMP database items on your system.

This section covers those attributes that are SNMP-specific, and includes an Alphabetical List of SNMP Specific Status Display Attributes.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status Attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


SNMP Driver Guide - Alphabetical List of SNMP Specific Status Display Attributes (SNMP Specific Status Display Attributes)

Alphabetical List of SNMP Specific Status Display Attributes

This section lists those Status attributes that are specific to items on the SNMP driver.

If an attribute displays the state Enabled Inactive, it means that it has an alarm feature enabled, but there are no alarms currently active (for the attribute). ClearSCADA is monitoring the attribute and will raise an alarm if it detects a problem.

The attributes are listed in alphabetical order and comprise:

  • ASN Data Type
  • SNMP Config Alarm
  • Source.


SNMP Driver Guide - ASN Data Type (SNMP Specific Status Display Attributes)

ASN Data Type

Associated with: SNMP points

The syntax used for SNMP is Abstract Syntax Notation 1 (ASN.1). The syntax defines, for example, the type of data that is accessed using the SNMP protocol. ASN.1 is used within the MIB database at each SNMP database.

The ASN Data Type attribute indicates the data type with which the point is associated.

Possible States: These vary, depending on the point type:

Every type of point:

ASN NULL—the point does not have valid configuration

UNKNOWN—the data type value is not recognized by ClearSCADA.

SNMP Integer, Cardinal, and Digital points support these data types:

ASN RFC1155 COUNTER

ASN RFC1155 GAUGE

ASN RFC1155 TIMETICKS

Additionally, this Integer point is supported:

ASN INTEGER

SNMP String points support these data types:

ASN OCTETSTRING

ASN SEQUENCE

ASN RFC1155 IPADDRESS

ASN RFC1155 OPAQUE

NOTE: ClearSCADA does not support the data type ASN OBJECT IDENTIFIER.


SNMP Driver Guide - SNMP Config Alarm (SNMP Specific Status Display Attributes)

SNMP Config Alarm

Associated with: SNMP points

The SNMP Config Alarm attribute indicates whether there is incorrect configuration in the last request sent to the SNMP agent. For example, whether the message requests data for an Object Identifier that does not exist at the agent.

Possible States: Displays one of the Standard Alarm States. If an alarm state is displayed, this is followed by the time and date at which the alarm occurred.

Example:

Enabled Active Fleeting at 12/Mar/2004 at 10:03:59.839

If an alarm state is displayed, use the Events or Alarms List to ascertain further information about the cause of the alarm. You can filter either List so that it only shows those entries that are specifically related to such an alarm (see SNMP Specific Alarm and Event Categories).


SNMP Driver Guide - Source (SNMP Specific Status Display Attributes)

Source

Associated with: SNMP points

The Source attribute is common to all Point Status displays. The attribute summarizes information about the point source.

The information shown varies, depending on the type of point and the driver with which it is associated. For points on the SNMP driver, information is displayed in this format:

<Device Address>:<Community Name>:<Object Identifier (if used)>:<Point Type>

Examples:

10.1.10.66:public:.1.3.6.1.2.1.1.1.0:Cardinal

for a Cardinal point that is obtaining data from the SNMP agent that has an IP address of 10.1.10.66, which is in the public community. The Object Identifier for the point is .1.3.6.1.2.1.1.1.0

10.1.10.66:public::Integer

for an Integer point that is obtaining data from the SNMP agent that has an IP address of 10.1.10.66, which is in the public community. As the driver is trapping generic data for this point, the point does not have an Object Identifier.


SNMP Driver Guide - Using SNMP Specific Actions

Using SNMP Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see the ClearSCADA Guide to ViewX and WebX Clients).

This section covers use of the Set Value action on the SNMP driver.

Where a pick action is used with the Automation Interface, the method name is typically the pick action name minus any character spaces. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)

NOTE: Users with the required privileges can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as ‘methods’).

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


SNMP Driver Guide - Set Value (Using SNMP Specific Actions)

Set Value

Associated with: SNMP points that are configured to retrieve current point data, and on which the Set Value action has been enabled (see Configure the Poll and Link Status Properties).

Security permission required to access this pick action: Control

Use the Set Value pick action to set the value at the SNMP agent. For the Set Value action to be successful, the SNMP agent has to be configured so that:

  • The agent is read-write
  • The community has write privileges
  • The value’s Object Identifier is writeable.

To set a value, select the Set Value pick action to display the Set Value window. Enter or select the required value, and then select the OK button to confirm the entry and set the point value.

With Cardinal and Integer points, the SNMP driver applies any point Scaling in reverse, before sending a command to set the SNMP agent to the resultant value (see Configure Integer and Cardinal Point Scaling).

The value remains changed at the SNMP agent until another Set Value action is successfully executed, or the value changes at the SNMP agent through other external means.


SNMP Driver Guide - SNMP Specific Driver Log File Options

SNMP Specific Driver Log File Options

This section is designed for use by system administrators and high-level engineers when assessing the state of the ClearSCADA system. The section is specific to the SNMP driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

NOTE: When troubleshooting on a ClearSCADA system, use the Events List to view any diagnostics messages. These may help you to identify the cause of any unexpected system behavior.

Driver logging is useful for investigating unexpected system behavior relating to the SNMP driver. It provides useful diagnostic information for specific aspects of the system. For instance, the Points logging option provides diagnostic information for the points on a particular driver. Those driver logging options that are typically required for investigating driver problems are enabled by default. We suggest that the logging options are left at this default unless other logging options are specifically requested by Schneider Electric, or the default options are adversely affecting system performance.

If you need to contact Schneider Electric for assistance with resolving unexpected system behavior, our engineers may ask you to provide Log files. The Log files contain data that we can use when assessing your system. For information on Log files and defining the Log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration.

This section explains the driver logging options that are specific to the SNMP driver. This driver is listed as the SNMPManager in the Modules section of the ClearSCADA Server Status Tool. The driver supports these driver log file options:

  • Application—Logs general information about the driver.
  • Errors—Logs any errors detected during driver operation. For example, communications failures, or a failure of the connection to the ClearSCADA database.
  • Timers—Logs information about low-level internal thread timer queues.

ATTENTION: When enabled, the Timers option can cause a large amount of information to be logged. This can make it more difficult to locate information of interest, due to the high amount of data. It is also possible that the information required maybe overwritten if the log files become full very quickly. For this reason, we recommend that the Timers option is disabled and that you only enable it if specifically asked to do so by a Schneider Electric engineer.

  • Events—Logs information about low-level internal thread event queues.

ATTENTION: When enabled, the Events option can cause a large amount of information to be logged. This can make it more difficult to locate information of interest, due to the high amount of data. It is also possible that the information required maybe overwritten if the log files become full very quickly. For this reason, we recommend that the Events option is disabled and that you only enable it if specifically asked to do so by a Schneider Electric engineer.

  • I/O—Logs information about low-level I/O.
  • Database Objects—Logs changes to database items.
  • Points—Logs changes to point configuration within ClearSCADA.
  • Requests (Actions)—Logs information about any external requests from users, plus internal requests within the driver.
  • Point Updates (Data)—Logs information about point data retrieved by the driver.
  • Client Sink—Logs information about the low-level interface from server to driver.
  • Server Sink—Logs information about the low-level interface from driver to server.
  • Browse Server—Logs information about the use of the browse options on configuration Forms. For example, the Device browser on an SNMP Point Form.
  • SNMP Diagnostics—Logs information on received SNMP polls and traps.


SQL Export Driver Guide - Safety Information

Safety Information

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SQL Export Driver Guide - Important Information (Safety Information)

Important Information

Read these instructions carefully, and familiarize yourself with ClearSCADA before trying to install, operate, or maintain your system. The following special messages may appear throughout this documentation or on the ClearSCADA application to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure.


SQL Export Driver Guide - Please Note (Safety Information)

Please Note

Electrical equipment should be installed, operated, serviced, and maintained only by qualified personnel. No responsibility is assumed by Schneider Electric for any consequences arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction and operation of electrical equipment and the installation, and has received safety training to recognize and avoid the hazards involved.


SQL Export Driver Guide - Before You Begin (Safety Information)

Before You Begin

ClearSCADA is a Supervisory Control and Data Acquisition (SCADA) solution. It comprises software that is used to control and monitor various devices, applications and processes on your system. Due to ClearSCADA’s central control and processing role, you must appropriately design, commission and thoroughly test your system’s configuration for proper operation before placing it in service. Any further configuration changes made online (once ClearSCADA is commissioned, tested, and in service) must be thoroughly tested before being used in an operational setting.

WARNING

unintended equipment operation

The configuration of this product requires expertise in the design, configuration and programming of SCADA control systems. Only persons with such experience should be allowed to configure ClearSCADA. Only persons with the appropriate programming experience should be allowed to write any scripts, Logic programs, expressions, or SQL queries intended for use in ClearSCADA.

Follow all local and national safety codes and standards.

Failure to follow these instructions can result in death, serious injury, or equipment damage.


SQL Export Driver Guide - About the Guide

About the Guide

Copyright Control Microsystems Inc 2000 - 2011
ClearSCADA 2010 R2 build 4165, May 2011


SQL Export Driver Guide - Document Scope (About the Guide)

Document Scope

This guide explains how to:

  • Add and configure an SQL Export item in ClearSCADA
  • Use the actions that are specific to the SQL Export driver
  • Use the SQL Export driver’s statistics and colors for diagnosing unexpected behavior relating to the SQL Export driver.
  • Use the SQL Export driver-specific log file options.

For more details on the subjects covered in this guide, see Introduction to the SQL Export Driver.


SQL Export Driver Guide - Intended Audience (About the Guide)

Intended Audience

This guide is designed for use by all levels of user:

  • Engineers who are responsible for adding and configuring SQL Export items in ClearSCADA
  • Operators who use the actions that are specific to the SQL Export driver
  • System administrators who are responsible for investigating any unexpected behavior relating to the SQL Export driver.


SQL Export Driver Guide - Validity Note (About the Guide)

Validity Note

This guide is valid for ClearSCADA 2010 R2 running on computers that are using an appropriate Windows® operating system (see Operating Systems in the ClearSCADA Guide to Server Administration).

Further Information

Server Requirements: see System Server Requirements in the ClearSCADA Guide to Server Administration.

Client PC Requirements: see Client PC Requirements in the ClearSCADA Guide to Client Administration.

Recommended PC Configurations: see Recommended PC Configurations in the ClearSCADA Guide to Server Administration.


SQL Export Driver Guide - Related Documents (About the Guide)

Related Documents

This guide includes references to content in the following guides:

ClearSCADA Guide to Core Configuration

ClearSCADA Guide to Drivers

ClearSCADA Guide to Lists

ClearSCADA Guide to Alarms

ClearSCADA Guide to Alarm Redirection

ClearSCADA Guide to ViewX and WebX Clients

ClearSCADA Guide to QueryPad

SQL Technical Reference online Help

ClearSCADA Guide to the Database

ClearSCADA Guide to Server Administration

ClearSCADA Guide to Client Administration

ClearSCADA Guide to the Server Status Tool.


SQL Export Driver Guide - User Comments (About the Guide)

User Comments

We welcome your comments about this guide. You can reach us by e-mail at technicalsupport@controlmicrosystems.com.


SQL Export Driver Guide - Introduction to the SQL Export Driver

Introduction to the SQL Export Driver

The SQL Export driver enables you to write SQL queries to interrogate the ClearSCADA database and export the results of those queries to file. The SQL Export driver can export the SQL query results in either Comma Separated Value (CSV) or Tab Separated Value (TSV) format. You define the SQL queries that ClearSCADA is to execute and the format and location to which the results of those queries are to be exported, using fields on the relevant configuration Form—one Form per SQL Query.

This guide explains how to Add and Configure an SQL Export item in ClearSCADA.

It also explains the driver-specific features that are of interest to operators:

  • SQL Export Specific Alarm and Event Categories
  • Use SQL Export Specific Actions

and the SQL Export driver specific features may be of interest to system administrators and engineers when investigating unexpected system behavior (relating to the SQL Export Driver):

  • SQL Export Specific Status Attributes
  • SQL Export Specific Colors
  • SQL Export Specific Driver Log File Options.


SQL Export Driver Guide - Add and Configure an SQL Export

Add and Configure an SQL Export

In order to export the result of an SQL Query and define the location and format in which that result is to be exported, you need to configure at least one SQL Export item in the ClearSCADA database. You need to configure a separate SQL Export item per SQL Query.

To add an SQL Export item to your database:

  1. In the Database Bar, right click on the Group or Group Template within which you want to add an SQL Export.
    A context sensitive menu is displayed.
  2. Select the New option.
    A further menu is displayed.
  3. Select the Other option.
    A further menu is displayed.
  4. Select SQL Export option.
    An SQL Export item is added to the database. The entry is highlighted, ready for you to define its name.

Configure each SQL Export item using the SQL Export Form. For general information on working with Forms, see Working with Forms in the ClearSCADA Guide to Core Configuration.

The SQL Export Form has several tabs:

  • Identification—Use this tab to optionally define a Help View and to indicate whether the SQL Export is to be excluded from any Exclusive Control activity (see Defining Identification Details in the ClearSCADA Guide to Core Configuration).
  • User Methods—Use this tab to define any custom pick actions (‘methods’) for the SQL Export (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration).
  • Alarm—Use this tab to define optional features associated with SQL Export alarms (see Defining an Item or Group’s Alarm Properties in the ClearSCADA Guide to Core Configuration).
  • Redirection—Use this tab to define any SQL Export alarm redirections (see Configure Alarm Redirections for an Item or Group in the ClearSCADA Guide to Alarm Redirection).
  • SQL Export—Use this tab to Configure the SQL Export Properties.

Use the Export SQL Query Result pick action to export the result of an SQL Export item’s SQL Query, using the settings specified on the configuration Form.


SQL Export Driver Guide - Configure the SQL Export Properties (Add and Configure an SQL Export)

Configure the SQL Export Properties

Use the fields on the SQL Export tab of the SQL Export Form to configure the settings that define the data that is to be exported, along with the format and location to which that data is to be exported.

The SQL Export tab includes fields that enable you to:

  • Specify whether the SQL Query database item is active or inactive (see Placing an Item In Service in the ClearSCADA Guide to Core Configuration).
  • Specify the severity of any alarms and events associated with the SQL Export item (see Defining Severities in the ClearSCADA Guide to Core Configuration).
  • If the Area of Interest feature is enabled on your system, specify the area with which any of the SQL Export item’s alarms or events are to be associated (see Assign a Different Area of Interest to an Item’s Alarms and Events in the ClearSCADA Guide to Core Configuration).
  • Specify the SQL Query that ClearSCADA is to Execute, the result of which you export to file using the Export SQL Query Result pick action.
  • Specify the Locale that ClearSCADA is to Apply to the Exported SQL Query Result.
  • Specify the Output Format.
  • Specify the Name of the Output File.
  • Specify the Trip Sequence Time used for any date or time trip sequences that are included in the Output File Name.
  • Specify Whether the Output File Includes Column Names.
  • Specify the Character Set used to Encode the Exported SQL Query Result.


SQL Export Driver Guide - Specify the SQL Query that ClearSCADA is to Execute (Add and Configure an SQL Export)

Specify the SQL Query that ClearSCADA is to Execute

Use the SQL Query field on the SQL Export tab to enter the required SQL query. This is the SQL Query that ClearSCADA is to execute whenever the SQL Export item’s Export SQL Query Result pick action is triggered. The query determines the area of the database that ClearSCADA interrogates (‘queries’) for data, along with any restrictions that ClearSCADA is to apply to that interrogation, whenever the pick action is triggered.

ClearSCADA automatically exports the result of the SQL Query in the format and to the location specified using the rest of the fields on the SQL Export tab (see Configure the SQL Export Properties). The SQL Query determines the order in which the queried data values are listed in the output file.

ATTENTION: Any SQL queries should be written by engineers who have the appropriate experience and knowledge of the SQL language. Running a badly designed SQL query can have an adverse affect on the system. All queries should include suitable restrictions to limit the number of records that are retrieved from the database. An SQL query that queries vast amounts of data will affect the performance of the server while that query executes.

Full guidance on using SQL is outside the scope of this guide. A short example is given below.

ClearSCADA uses SQL to query the database in order, for example, to populate the various Queries Lists that you can display in ClearSCADA. Depending on the data that you want to query in the database, you may find it useful to base your SQL query on such a query. For more information, see Ascertain which SQL Query is Presently used by a List in the ClearSCADA Guide to Lists.

We recommend using QueryPad to test your SQL queries and improve their efficiency. QueryPad is an SQL query diagnostics tool that is supplied with ClearSCADA. For more information, see the ClearSCADA Guide to QueryPad.

Example:

The Configuration Changes Auditing feature is enabled on a particular ClearSCADA system, to enable ClearSCADA to keep a detailed record of the configuration changes that have occurred on that system.

An SQL Export item is used to export a list of those configuration changes that have occurred automatically over the last 24 hours, as a result of other configuration changes being made (configuration changes that have a ‘Database Internal’ origin).

When exported, the queried data is to be listed in ObjectName order, followed by RecordTime (the time that the change occurred).

The SQL Export item uses this SQL Query:

SELECT TOP( 500 )
"RecordId", "RecordTime", "ObjectName", "FieldName", "OldValue", "NewValue", "User"
FROM
CDBCONFIGCHANGES
WHERE
( "RecordTime" BETWEEN { OPC 'H-23H' } AND { OPC 'H+1H' } ) AND ( "OriginDesc" = 'Database internal change' )
ORDER BY
"ObjectName" DESC, "RecordTime" DESC

The Include Column Names check box on the SQL Export Form is used to specify whether the column names listed in the SQL Query’s SELECT Clause are included in output file (the file that is generated when the Export SQL Query Result pick action is triggered).

Further Information

Specify Whether the Output File Includes Column Names

Configuration Changes Auditing: see Configuration Changes Auditing in the ClearSCADA Guide to Core Configuration.

SQL features supported by ClearSCADA: see the SQL Technical Reference online Help.


SQL Export Driver Guide - Specify the Locale that ClearSCADA is to Apply to the Exported SQL Query Result (Add and Configure an SQL Export)

Specify the Locale that ClearSCADA is to Apply to the Exported SQL Query Result

Use the Locale field on the SQL Export tab to specify the basic format used for any time, date, numeric, or currency values that are exported as part of the SQL Query result. (With a Dutch Locale, for example, a comma is used to indicate a decimal place and with an American Locale dates are typically ordered MM/DD/YY rather than DD/MM/YY.)


SQL Export Driver Guide - Specify the Output Format (Add and Configure an SQL Export)

Specify the Output Format

Use the Output Format field on the SQL Export tab to specify the format in which ClearSCADA is to export the result of the SQL Query.

Choose from:

  • Comma Separated—ClearSCADA exports the result of the SQL Query in Comma Separated Value (CSV) format. With this format, the exported data values are separated by commas.
  • Tab Separated—ClearSCADA exports the result of the SQL Query in Tab Separated Value (TSV) format. With this format, the exported data values are separated by tabs.

Further Information

Specify the Character Set used to Encode the Exported SQL Query Result.


SQL Export Driver Guide - Specify the Name of the Output File (Add and Configure an SQL Export)

Specify the Name of the Output File

Use the Output File Name field on the SQL Export tab to specify the name of the file to which ClearSCADA is to export the result of the SQL Query.

You need to include the full path to the file. You can either specify:

  • a file name that is local to the main server

or

  • a UNC path to a shared directory on another computer.

If you omit the file extension, ClearSCADA will automatically apply a .csv or .tsv extension to the output file, based on the specified Output Format (see Specify the Output Format).

You can include trip sequences in the file name, in order to include specific SQL Export-related information (see Trip Sequences Supported by ClearSCADA).

Use the Trip Sequence Time field to specify the date/time information that is to be included in any date or time trip sequences (see Specify the Trip Sequence Time).

For an example of how to use the Trip Sequence Time in conjunction with the trip sequences that you can specify for an SQL Export item’s Output File Name, see Specify the Trip Sequence Time.


SQL Export Driver Guide - Specify the Trip Sequence Time (Add and Configure an SQL Export)

Specify the Trip Sequence Time

Use the Trip Sequence Time field on the SQL Export tab to specify the date and time that ClearSCADA uses for any date or time trip sequences specified in the Output File Name (see Specify the Name of the Output File).

The default of NOW results in a time of ‘now’ exactly and so indicates the actual time that ClearSCADA exported the result of the SQL Query.

When exporting the results of some SQL queries, you may want to specify an offset time. You need to enter the time in the OPC Relative Time Format.

Example:

On a ClearSCADA system, the results of SQL Exports that query data for the previous month are generated at the start of the following month.

The results are exported to CD and then stored in the company archives.

The directory into which each output file is archived indicates the year for which the SQL query data corresponds. The name of each output file includes the month and year to which the data corresponds. The directory and file name are specified using a trip sequence:

E:\ExportedData\%Dyyyy%\Data for %DMMM yyyy%

(where Data for %DMMM yyyy% is the name of the output file)

As the data for February is exported at the beginning of March, and the data for March is exported at the beginning of April, and so on, a Trip Sequence Time of NOW would result in the data for February being exported with a March file name.

In order to export the data to an output file with the appropriate file name, the Trip Sequence Time is specified as:

MO-1D

(the last day of the previous month)

This results in output files containing February’s data (which are exported at the start of March) being exported with a February file name (as the date with which ClearSCADA replaces the trip sequence %DMMM yyyy% is calculated using the last day of the previous month as the time source).

For further examples on using the OPC Relative Time format, and the time units that you can use to specify the Trip Sequence Time, see OPC Relative Time Format in the ClearSCADA Guide to Core Configuration.


SQL Export Driver Guide - Specify Whether the Output File Includes Column Names (Add and Configure an SQL Export)

Specify Whether the Output File Includes Column Names

The SQL query that is entered in an SQL Export’s SQL Query field defines the database table(s) that ClearSCADA is to query for data, along with the columns within those tables (see Specify the SQL Query that ClearSCADA is to Execute).

Use the Include Column Names check box on the SQL Export tab to specify whether the column names are to be included in the output file.

Select the check box for the output file to include the column names that are specified in the SQL Query.

Clear the check box for the column names to be omitted from the output file.


SQL Export Driver Guide - Specify the Character Set used to Encode the Exported SQL Query Result (Add and Configure an SQL Export)

Specify the Character Set used to Encode the Exported SQL Query Result

Use the Output using UTF-8 check box on the SQL Export tab to specify the character set that is used to encode the exported SQL Query result.

Select the check box for the exported result to be encoded using the UTF-8 character set.

Clear the check box for the exported result to use the Unicode character set.

The default for the Output using UTF-8 setting is for the check box to be cleared.

Further Information

Specify the Output Format.


SQL Export Driver Guide - Trip Sequences Supported by ClearSCADA (Add and Configure an SQL Export)

Trip Sequences Supported by ClearSCADA

An SQL Export’s Output File Name supports ‘Trip Sequences’ that allow you to specify:

  • A date, based on the date that the result of the SQL Query is exported (see Specify a Trip Sequence for a Date)
  • A time, based on the time that the result of the SQL Query is exported (see Specify a Trip Sequence for a Time)
  • Information about the SQL Export database item or any item that it references (see Specify a Trip Sequence for an SQL Export Object).

For example, you might want to export the result of an SQL Query on a monthly basis, to a file name that includes the month and year that the exported result covers. Or you might want to export the result of an SQL Query to a location based on the SQL Export item’s location in the ClearSCADA database.

You can enter any combination of trip sequences at any location within an SQL Export’s Output File Name.

You can include character spaces within each trip sequence—these will be included in the final string when ClearSCADA replaces the trip sequence with the actual information.

You can also include additional string characters—and symbols such as commas—in a trip sequence. For example, %Dddd the dd of MMMM yyyy%. To include string characters that would otherwise appear as trip code, enclose the characters in single quotation marks, for example, ‘MM’ (to print the characters MM).

To include the export date or time, you specify the relevant date or time trip sequence along with the Trip Sequence Time, to define the time or date information that is to be included.

With each trip sequence, ClearSCADA replaces the trip sequence with the required information when it exports the result of the SQL Query.

Further Information

Specify an SQL Export item’s Output File Name: see Specify the Name of the Output File.

Specify an SQL Export item’s Trip Sequence Time: see Specify the Trip Sequence Time.

Resolving any Trip Sequence Errors.


SQL Export Driver Guide - Specify a Trip Sequence for a Date (Add and Configure an SQL Export)

Specify a Trip Sequence for a Date

To specify a trip sequence for a date, you enter the trip code:

%D<format>%

where <format> is one or more of the Windows® picture string date formats that ClearSCADA supports (see Supported Trip Codes for Dates).

To specify the date that ClearSCADA substitutes for the trip code, you use the Trip Sequence Time field on the SQL Export Form’s SQL Export tab.

The default of NOW results in a time of ‘now’ exactly. If an offset time stamp is required, you can specify another time value in the OPC Relative Time Format.

For an example of how to use the Trip Sequence Time in conjunction with the trip sequences that you can specify for an SQL Export item’s Output File Name, see Specify the Trip Sequence Time.

Further Information

Resolving any Trip Sequence Errors.


SQL Export Driver Guide - Specify a Trip Sequence for a Time (Add and Configure an SQL Export)

Specify a Trip Sequence for a Time

To specify a trip sequence for a time, you enter the trip code:

%T<format>%

where <format> is one or more of the Windows® picture string time formats that ClearSCADA supports (see Supported Trip Codes for Times).

To specify the time that ClearSCADA substitutes for the trip code, you use the Trip Sequence Time field on the SQL Export Form’s SQL Export tab.

The default of NOW results in a time of ‘now’ exactly. If an offset time stamp is required, you can specify another time value in the OPC Relative Time Format.

For an example of how to use the Trip Sequence Time in conjunction with the trip sequences that you specify for an SQL Export item’s Output File Name, see Specify the Trip Sequence Time.

Further Information

Resolving any Trip Sequence Errors.


SQL Export Driver Guide - Specify a Trip Sequence for an SQL Export Object (Add and Configure an SQL Export)

Specify a Trip Sequence for an SQL Export Object

You can use an Object trip sequence to specify information about the SQL Export database item itself. This type of trip sequence can be used to include information on:

  • Any of the SQL Export item’s properties in the ClearSCADA database (such as the SQL Export item’s Id)
  • Any property of any database item that the SQL Export references directly (such as properties of the SQL Export item’s Parent Group)
  • Any property of any database item that the SQL Export references indirectly (such as the SQL Export item’s Grandparent Group (the Group in which the SQL Export item’s Parent Group is located)).

To specify the trip sequence for a SQL Export Object, you enter the trip code:

%O<field>[.<field>][;<format>]%

where:

the first <field> is one of the following:

  • A Reference field—A field that provides a link to an associated database item, such as an SQL Export’s parent Group (the database Group in which the SQL Export item is located).

With a Reference field, you can optionally specify a further <field> in the referenced database item.

  • An Aggregate field—A field that provides a link to an associated ‘aggregate’, or tab on a database item’s configuration Form. For instance, the AlarmRedirection aggregate on the SQL Export Form.

With an Aggregate field, you can optionally specify a further <field> in the referenced aggregate.

  • Any Configuration or Data field associated with the SQL Export database item, or a database item that the SQL Export item references.

If <field> is a reference field or an aggregate field, then you can include further <field>(s) in the trip sequence, in order to specify further database item(s), that are themselves referenced by the database item listed in the preceding <field>.

Use the final <field> in the trip sequence to specify the required Configuration or Data field (OPC property) in the database item or aggregate that is specified in the preceding <field>.

<format> is optional and can be used to control the appearance of the information that ClearSCADA substitutes in place of the Object’s trip sequence. You only need to specify a format if:

  • The format is to differ from the default for the type of field. (For instance, with a trip sequence that queries a String field, ClearSCADA will supply the value of that field, using whatever capitalization that applies to the string’s value, unless you specify a different format, such as > to force the whole string to appear in upper case.)

or if:

  • The final field is a Time field for which the default format includes a colon (:) (for instance, to produce a time in the form 12:30:00)

and the trip sequence is:

  • Used to specify a file name (as a colon is not a valid character for a file name)

or:

  • Used elsewhere, where similar restrictions exist (for instance, if used to specify an ODBC Table name).

The custom formats that you can specify for an Object field are the standard custom value formats that are supported by ClearSCADA (see Date and Time Syntax, see Numeric Syntax, see Text String Syntax, and see Boolean Syntax—all are sections in the ClearSCADA Guide to Core Configuration).

You can ascertain the configuration, data, reference, and aggregate fields that you can specify using an Object trip sequence, along with an indication of each field’s type, using either of the following:

  • The database Schema (see Working with the Database Schema in the ClearSCADA Guide to the Database)
  • The OPC Data Bar.

You can also click on the relevant configuration field on a Form and observe its name and type in the Status Bar. (Remember that a field’s name often differs from the label that is shown for that field on the configuration Form. (The label is displayed in the language that is associated with the logged on user’s specified Locale.) It is a field’s name, rather than its label, that has to be specified in any Object trip sequence.) Data fields (and some Configuration fields, such as ParentGroupName) are not displayed on configuration Forms—use the database Schema or OPC Data Bar to ascertain information about such fields.

Examples:

%OParentGroupId.Name%
(Provides the name of the Group or Group Instance in which the SQL Export is located. For instance, ‘Zone 1’, for an SQL Export that is located in the Group ‘Zone 1’.)

%OParentGroupId.ParentGroupId.FullName%
(Provides the full name (including the path) of the SQL Export’s ‘grandparent’ Group or Group Instance—the Group or Group Instance in which the SQL Export’s Group or Group Instance is located. For instance, ‘My Database.Eastern Region’, for an SQL Export that is located in the Group ‘Zone 1’, which itself is within the Group ‘Eastern Region’. (With ‘Eastern Region’ being in the Group ‘My Database’.))

%OAlarmRedirection.Trigger1%
(Provides the value of the Trigger1 property. ‘AlarmRedirection’ is the name of the field that links to the SQL Export’s Alarm Redirection aggregate. Trigger1 defines the first Trigger State on the Alarm Redirection aggregate. (On the Redirection tab, ‘Trigger State’ is the label that identifies the column of trigger state fields—the label is displayed in the language that is associated with the logged on user’s specified Locale.) This trip sequence can only be used if an SQL Export has Alarm Redirection enabled.)

%OId;000000%
(Provides the SQL Export item’s Id—the number that uniquely identifies the SQL Export item in the ClearSCADA database. The 00000 formatting is included to force the Id to be displayed as a series of five digits (if the Id is smaller then five digits, it will be preceded by one or more zeros).)

Further Information

Resolving any Trip Sequence Errors.


SQL Export Driver Guide - Supported Trip Codes for Dates (Add and Configure an SQL Export)

Supported Trip Codes for Dates

NOTE: Trip codes are case sensitive. If you need to specify a trip code, use the case that is indicated in the table below.

The format for a date trip sequence is %D<format>%, where <format> contains one or more of the trip codes listed below. The resulting date is affected by the Trip Sequence Time field on the SQL Export Form (see Specify the Trip Sequence Time).

ClearSCADA supports these trip codes for date strings in an SQL Export’s Output File Name (see Specify the Name of the Output File):
Trip Sequence | Description | Example
d | The day of the month as a digit. No leading zeros are included for single-digit days. | 3 (for the third day in a month)
dd | The day of the month as a digit.Leading zeros are included for single-digit days. | 03 (for the third day in a month)
ddd | The day of the week, abbreviated to three letters. | Tue (for Tuesday)
dddd | The full name for the day of the week. | Tuesday
M | The month as a digit.Leading zeros are excluded for single-digit months. | 4 (for April)
MM | The month as a digit.Leading zeros are included for single-digit months. | 04 (for April)
MMM | The month, abbreviated to three letters. | Aug (for August)
MMMM | The full name for the month. | August
y | The last two digits of the year. Leading zeros are not included for years below 10. | 5 (for the year 2005)
yy | The last two digits of the year. Leading zeros are included for years below 10. | 05 (for the year 2005)
yyyy | The year, presented as four digits. | 2005
gg | The era. | AD

Examples:

The code
%Dd MMM yy%

displays a date in the form
2 May 05
(to display the date of the month as two digits, you would use dd, rather than d)

The code
%Dddd, dd MMMM%

displays a date in the form
Fri, 04 March


SQL Export Driver Guide - Supported Trip Codes for Times (Add and Configure an SQL Export)

Supported Trip Codes for Times

NOTE: Trip codes are case sensitive. If you need to specify a trip code, use the case that is indicated in the table below.

The format for a time trip sequence is %T<format>%, where <format> contains one or more of the trip codes listed below. The resulting time is affected by the Trip Sequence Time field on the SQL Export Form (see Specify the Trip Sequence Time).

ClearSCADA supports these trip codes for time strings in an SQL Export’s Output File Name (see Specify the Name of the Output File):
Trip Sequence | Description | Example
h | The hour in the day, using a 12-hour clock. Leading zeros are excluded for single-digit hours. | 3 (for 3am or 3pm)
hh | The hour in the day, using a 12-hour clock. Leading zeros are included for single-digit hours. | 03 (for 3am or 3pm)
H | The hour in the day, using a 24-hour clock. Leading zeros are excluded for single-digit hours. | 3 (for 3am) 15 (for 3pm)
HH | The hour in the day, using a 24-hour clock. Leading zeros are included for single-digit hours. | 03 (for 3am) 15 (for 3pm)
m | The minutes past the hour. Leading zeros are excluded for single-digit minutes. | 4 (for four minutes past the hour)
mm | The minutes past the hour. Leading zeros are included for single-digit minutes. | 04 (for four minutes past the hour)
s | The seconds past the minute. Leading zeros are excluded for single-digit seconds. | 9 (for nine seconds)
ss | The seconds past the minute. Leading zeros are included for single-digit seconds. | 09 (for nine seconds)
t | A one-character string, A or P, to indicate whether the time is before or after midday. | A (to indicate that a time is before midday)
tt | A two-character string, AM or PM, to indicate whether the time is before or after midday. | AM (to indicate that a time is before midday)

Example:

The code
%THH:mm:ss%

displays a time in the form
14:25:06


SQL Export Driver Guide - Resolving any Trip Sequence Errors (Add and Configure an SQL Export)

Resolving any Trip Sequence Errors

An SQL Export’s Output File Name supports ‘Trip Sequences’ (see Trip Sequences Supported by ClearSCADA).

Use this section if ClearSCADA is unable to evaluate a trip sequence, or the trip sequence does not evaluate as expected.

Use the table below to determine the cause of any trip sequence errors:

Type of Trip Sequence

Message

Description

Date or Time

#ERROR#

The specified format is invalid (see Supported Trip Codes for Dates, or see Supported Trip Codes for Times, as applicable).

Object

#NO REFERENCE#

The referenced field is null (the field does not reference another item and is blank on the associated configuration Form).

This error would occur, for example, should %OParentGroupId.AlarmViewId.Name% be evaluated for an SQL Export for which the parent Group does not have an Alarm View associated with it.

#GET REFERENCE FAILED#

ClearSCADA was not able to read the value of the referenced field. This error is unlikely to occur.

#NOT REFERENCE#

The trip sequence incorrectly references a field that is not a reference field.

For example, %OAlarmRedirection.Trigger1.Id%, where ‘Trigger1’ is an integer field, rather than a reference field.

Refer to the database Schema, or the OPC Data Bar for a comprehensive list of fields and field types.

#AGGREGATE DISABLED#

The trip sequence references a database aggregate that is presently disabled, therefore ClearSCADA cannot display the referenced information.

#REFERENCE NOT FOUND#

The trip sequence contains a reference that is not a field or aggregate.

For example, %OAlarmVw.Id%, where there is neither a field or aggregate named ‘AlarmVw’.

Refer to the database Schema, or the OPC Data Bar for a comprehensive list of the fields that can be specified.

#VALUE ERROR#

ClearSCADA was not able to read the value of the referenced field. This error is unlikely to occur.

#FIELD NOT FOUND#

The trip sequence references a field that does not exist.

(Remember to specify a field’s property name (as listed in the Schema, or OPC Data Bar), rather than its ‘display name’, or the field label shown on the configuration Form, as the latter two vary with the Locale and language assigned to the logged on User).

#GET PROPERTY FAILED#

The SQL Export driver has been unable to retrieve the specified property from the database. This error is unlikely to occur.

Further Information

Specify a Trip Sequence for a Date.

Specify a Trip Sequence for a Time.

Specify a Trip Sequence for an SQL Export Object.

Specify the Trip Sequence Time.

For information on the database Schema, see Working with the Database Schema in the ClearSCADA Guide to the Database.


SQL Export Driver Guide - Use SQL Export Specific Actions

Use SQL Export Specific Actions

ClearSCADA supports a wide variety of operator-driven or automated actions and controls. When performed by an operator, the actions are typically selected from a context sensitive pop-up menu (see Object Menu in the ClearSCADA Guide to ViewX and WebX Clients).

This section explains the Export SQL Query Result action that is specific to the SQL Export driver.

NOTE: Users with the required permissions can add custom pick actions to a database item by using the User Methods tab on the relevant configuration Form (see Using the User Methods Tab to Define Custom Actions in the ClearSCADA Guide to Core Configuration). See a system administrator for the documentation associated with such custom actions (also known as 'methods').

Further Information

‘Core’ pick actions that are common to many database items: see Object Menu Options in the ClearSCADA Guide to ViewX and WebX Clients.

Pick actions that are common to items on many drivers: see Actions that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


SQL Export Driver Guide - Export SQL Query Result (Use SQL Export Specific Actions)

Export SQL Query Result

Associated with: SQL Exports

Security permission required to access this pick action: Control

NOTE: If the data is being exported to removable media, please check that the media is at the required location and is available for use. For example, if the data is to be stored on a CD-R, a suitable CD-R needs to be inserted in the CD-RW driver of the server before the SQL query result is exported.

Use this pick action to execute the SQL Query that is associated with an SQL Export item and export the result of that query. The location to which ClearSCADA exports the result and the format that the output file takes is pre-defined, using fields on the SQL Export Form (see Add and Configure an SQL Export).

NOTE: If you are using this pick action with the Automation Interface, you need to specify the method name Export. (Refer to the Database Schema for argument naming conventions used with the Automation Interface.)


SQL Export Driver Guide - SQL Export Specific Alarm and Event Categories

SQL Export Specific Alarm and Event Categories

Each alarm and event on a ClearSCADA system has a Category that indicates the type of alarm or event. The Category is included by default in the Events List and, if applicable, the Alarms List and the Alarm Banner.

You can optionally filter the entries in either List by category—the entries from which you can choose comprise various ‘core’ categories, along with any categories that are specific to the drivers that are installed on your system.

On systems on which the SQL Export driver is installed, in addition to the ‘core’ alarm and event categories, this driver specific category is available:

  • SQL Export—Entries associated with SQL Export activity.

Further Information

Events Lists and ‘core’ filter categories: see the ClearSCADA Guide to Lists.

Alarms Lists and ‘core’ filter categories: see the ClearSCADA Guide to Alarms.


SQL Export Driver Guide - SQL Export Specific Status Attributes

SQL Export Specific Status Attributes

Every item in the ClearSCADA database has its own Status display (also referred to as a View window or View dialog). The Status display provides information about the status of the selected item.

For instance, the Status display for an SQL Export provides information about the present state of that item.

Use this section if you need information on the status of any SQL Export database items on your system.

This section explains the SQL Export Alarm and Status attributes that are specific to the SQL Export driver.

Further Information

Working with Status Displays: see Status Displays in the ClearSCADA Guide to ViewX and WebX Clients.

Status attributes that are common to items on many drivers: see Status Attributes that are Common to Many Drivers in the ClearSCADA Guide to Drivers.


SQL Export Driver Guide - SQL Export Alarm (SQL Export Specific Status Attributes)

SQL Export Alarm

Associated with: SQL Exports

This attribute indicates whether the last Export SQL Query Result request completed successfully.

ClearSCADA clears an existing SQL Export Alarm at the time of the next successful export.

Possible states: Displays one of the Standard Alarm States.


SQL Export Driver Guide - Status (SQL Export Specific Status Attributes)

Status

Associated with: SQL Exports

This status attribute indicates the present state of an export request.

The possible states are:

  • Idle—No Export SQL Query Result request is in progress.
  • Pending—An Export SQL Query Result request associated with this SQL Export database item is awaiting execution.

This state is also indicated by the SQL Export item’s entry using the SQL Export Pending color on various ClearSCADA displays (unless another system color takes priority over that color).

  • In Progress—An Export SQL Query Result request associated with this SQL Export item is presently under way.

This state is also indicated by the SQL Export item’s entry using the SQL Export in Progress color on various ClearSCADA displays (unless another system color takes priority over that color).

  • Failed—This state indicates that the most recent Export SQL Query Result request failed. The status will remain Failed until another export is requested, whereupon the Status attribute will indicate the status of the new request. The cause of the failure will be indicated by an entry in the Alarms List and Alarm Banner (see SQL Export Specific Alarm and Event Categories).


SQL Export Driver Guide - SQL Export Specific Colors

SQL Export Specific Colors

Each ClearSCADA system is supplied with a set of default system colors. These colors comprise both ‘core system’ and driver-specific colors. Each color is used to indicate the state of an item in the database. The color is used on various ClearSCADA displays to indicate that the item is in a particular state.

This section covers the system colors that are specific to the SQL Export driver. ClearSCADA uses SQL driver-specific colors to indicate:

  • SQL Export in Progress
  • SQL Export Pending.

If required, you can change a default system color by altering its color in the color palette. However, if you decide to do this, you should take care to make the color different to other system colors. Users may become confused if you adjust default system colors so that they are the same as, or identical to other system colors. For information on configuring system colors, see Use the Color Palette to Define a Custom System Color in the ClearSCADA Guide to Core Configuration.

Further Information

Core system colors: see Alphabetical List of Core System Colors in the ClearSCADA Guide to Core Configuration.


SQL Export Driver Guide - SQL Export in Progress (SQL Export Specific Colors)

SQL Export in Progress

Associated with: SQL Exports

The SQL Export in Progress status is indicated by a flashing dark blue foreground color, by default.

The color indicates that an Export SQL Query Result request is in progress.


SQL Export Driver Guide - SQL Export Pending (SQL Export Specific Colors)

SQL Export Pending

Associated with: SQL Exports

The SQL Export Pending status is indicated by a blue background color, by default.

The color indicates that an Export SQL Query Result request is awaiting processing. ClearSCADA processes one SQL export request at a time. Any further requests remain as pending until the current SQL Export request completes.


SQL Export Driver Guide - SQL Export Specific Driver Log File Options

SQL Export Specific Driver Log File Options

This section is designed for use by system administrators and high-level engineers who need to use statistical and diagnostic information to assess the state of the ClearSCADA system. It contains information that is specific to the SQL Export driver. For more general information on analyzing a ClearSCADA system, see System Analysis in the ClearSCADA Guide to the Server Status Tool.

NOTE: When troubleshooting on a ClearSCADA system, use the Events List to view diagnostics messages. The messages may help you to identify the cause of any unexpected behavior relating to the SQL Export driver.

Driver logging is useful for investigating unexpected system behavior relating to the SQL Export driver. It provides useful diagnostic information for specific aspects of the system.

Should you need to contact Schneider Electric for assistance with resolving a problem on your system, you might be asked to provide Log files to help in assessing the cause of the problem. Be aware that existing warranty and support arrangements determine the level of help that you receive should you need to contact Schneider Electric.

This section explains the driver logging options that are available on the SQL Export driver.

Those driver logging options that are typically required for investigating unexpected driver behavior are enabled by default. We recommend that you leave the default options in place unless you are asked to change them by Schneider Electric, or the default options are adversely affecting system performance.

For information on log files and defining the log file settings, see Driver Logging in the ClearSCADA Guide to Server Administration.

The SQL Export driver log file options are:

  • Application—Logs general information about the driver.
  • Errors—Logs any unexpected failures that occur during driver operation.
  • Timers—Logs information about low-level internal thread timer queues.

ATTENTION: When enabled, the Timers option can cause a large amount of information to be logged. This can make it more difficult to locate information of interest, due to the high amount of data. It is also possible that the information required maybe overwritten if the log files become full very quickly. For this reason, we recommend that the Timers option is disabled and that you only enable it if specifically asked to do so by a Schneider Electric engineer.

  • Events—Logs information about low-level internal thread event queues.

ATTENTION: When enabled, the Events option can cause a large amount of information to be logged. This can make it more difficult to locate information of interest, due to the high amount of data. It is also possible that the information required maybe overwritten if the log files become full very quickly. For this reason, we recommend that the Events option is disabled and that you only enable it if specifically asked to do so by a Schneider Electric engineer.

  • Database Objects—Logs changes to database items.
  • Requests (Actions)—Logs information about any external requests from users, plus internal requests within the driver.
  • Client Sink—Logs information about the low-level interface from server to driver.
  • Server Sink—Logs information about the low-level interface from driver to server.
  • Browse Server—Logs information about the use of browse options on configuration Forms.
  • SQL Export—Logs SQL export-specific diagnostic information.


Disclaimer

© Control Microsystems Inc. All rights reserved.

Control Microsystems Inc. maintains a policy of continual product development and improvement. The information contained in any document or documents is to their best knowledge accurate at the date of issue. Control Microsystems Inc. reserves the right to review and change the content of the documentation at any time, without notice, and shall not be held liable for any direct or indirect consequences arising from such changes.

The hardware and software described in this and any other document issued by Control Microsystems Inc. is provided strictly under a license agreement. Except as permitted by such license agreement, no part of the said documents may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronically, mechanically, recording, or otherwise, without the prior written consent of Control Microsystems Inc.